Get Started
- Alexander Beate (Unlicensed)
- Sebastian Koch
Introduction
Azeti Site Controller is azeti´s response to the need of monitoring and communicating directly with devices and sensors at the edge of infrastructures. We bring the capability of interacting with sensors and devices, executing actions and programming complex rules that will be executed even if the cloud connectivity is lost. It allows a seamless integration of sensors and devices with cloud services. The current document gives an overview of the internals of the Site Controller. It will give you a general description of the architecture of the system, its modules, and how every part of the system interacts with the other. It concentrates in describing the architecture and flow of information inside the Site Controller.
In this section we will go over the installation of the Site Controller on different operating systems and the Quick Start guide, which covers the basic setup to enable the Site Controller to communicate with the Engine. Additionally there is an overview of the architecture and the terminology used.
Basic architecture
The following diagram shows a basic description of the architecture inside the Site Controller.The complete architecture is built around a MQTT broker that is used as messaging system among the modules. All modules are connected to the broker, where they get configuration and data and deliver their information. Data acquisition modules are connecting to external devices (see picture below) and publishing the information they gather to the broker in order to be processed by the rest of the modules. There is also a module responsible for the communication with the cloud.
Definitions
The following terms will be used across this document and other documentation regarding the Site Controller. As some of them are common terms, like gateway, we have introduced this definition lists in order that you know what they mean internally to our system.
Term | Definition |
|---|---|
| Sensor | A sensor can be any type of sensor ranging from a temperature measurer to an snmp device. |
| Action | An action is a set of instructions that will be executed by a module. An action can generate events, can use physical and virtual actuators and publish calibrated results. |
| Calibrated result | A calibrated result is a processed piece of information. The sensors and the modules in the system (like the Automation Controller) will use this information to generate events, state changes or perform their tasks. |
| Device | A physical interface that connects to our system. Depending of its technology, it will be managed by a specific module (for example, a modbus device and a snmp sensor are configured in a different way). When we configure a device, we detail the way in which we connect to it (baud rate, IP, passwords, or whatever information is necessary to connect to it). |
| Event | An event is either a state change in a sensor (for example, a door changes from "closed" to "open"), either physical or virtual. Virtual sensors events are generally used to show combined information in modules like the Automation Controller. |
| Gateway | A gateway is a subset of a Device, that includes which information we want to get from the device as well as the frequency at which we will gather this information. A gateway will generally define a group of internal addresses inside of a device that will be read simultaneously. A device can have one or multiple gateways. |
| Physical actuator | A physical actuator is a part of a device that can perform some action based on the information that we send to it. Typical actuators are digital outputs capable of activating/deactivating devices. Other actuators may have some parametrization done through registers in the device, that can be configured and performed by our system. |
| Physical sensor | A physical sensor is a transducer whose purpose is to sense/detect some characteristics of its environment. A physical sensor can measure light, humidity, temperature, time, depth, weight, vibration, magnetic fields, electrical fields, sound, movement and any other environmental characteristic. Typically a physical sensor will belong to a device that will let us read its value, therefore in our system we will configure a device to connect to the physical device, a gateway to indicate how often we want to read the values, and the sensor itself, where we will indicate how to calibrate the raw measurement, what the calibrated value means and if/when we should generate an event based on its measurement. |
| Raw result | A raw result is a piece of information that comes without any processing from a gateway (for example, the reading of 10 registers in a device). Our system will then process the information, deliver it to the corresponding sensors and generate a calibrated result or an event if neccesary. |
| Rule | A rule is a set of instructions that are executed by the Automation Controller. |
| Virtual sensor/actuator | The virtual sensor/actuators are the complement of the physical sensors and actuators. They can combine information of physical sensors to generate a complex information, or they can generate information on their own, like in the case of simulators. |