The capabilities and power of small local computers have evolved so much that we now can have a very powerful “control center” on a single board device, credit card size. (see Raspberry Ecosystem)

This solution’s central system is based on the Raspberry Pi cpu.
The software is installed and runs in this Linux environment, fully solid state with no mechanical drives.

It includes an SQL database that handles all the information related to all the field information we need to process. Application programming is developed in python and takes advantage of the large library of code available for this setup.

The full solution uses a distributed approach. A central Raspberry PI5 contains the central SCADA functions and works as the “piscada master”. All other units, called Remote Terminal Units or RTU’s in SCADA language,  are based on the existing variants of the PI family – we call the the pi5rtu, the pizerortu and the picortu

The real time communication on the local network is based on the MQTT protocol. This is a publish subscribe solution that uses a central broker enabling all the devices to communicate with each other. We use the Mosquitto broker for it’s functionality and wide spread use that guarantees its maintenance and evolution.

piscada can also communicate with any device that supports MQTT even if they are not one of the pirtu units.
All this is defined in the SQL database presented above. Each digital or analog entity can have a MQTT definition that allows piscada to either publish or subscribe that entity on a specific MQTT “address” defined as an organized set of TOPICS and a variable name.

In the case of a pirtu unit the internal application allows for a seamless connection without any field configuration. Each pirtu at powerup connects to the local network as usual in new IoT devices.
Using wifi, the unit first generates a local wifi SSID, called “piscadawifi”, and the installer uses a phone or tablet to join that network and address a fixed ip on his browser. There he selects the wifi SSID required on that site and introduces its password. Done.

The pirtu now reaches out to the main piscada on the network and receives a set of information that defines the TYPE of device that the piscada expects to have at that particular MAC address.
This allows for an important software characteristic – we can have a single source code for all types of pirtu and activate the parts that are specific for that IoT device.

Another set of data from the SQL database is passed to the pirtu to define the mapping of its local variables, specific for that TYPE of pirtu, to the MQTT communication parameters, the TOPICS and SIGNAL name(s) needed.

So when you are defining the piscada database you are at the same time and without further actions, defining the database of all pirtu s.

Interested ? Contact us for more info and take a look at our YouTube videos.