Linux-based automation controller

Programmable Linux-based automation controller

IoT (internet of things) is a network of things connected via the internet, where technical devices share and exchange information with one another and fulfil certain tasks together. For example, smartphones, kitchen appliances, washing machines, cars, medical equipment, buildings – the list is endless. It is estimated that the number of IoT devices in the whole world may exceed 50 billion by 2020.

To facilitate logical and reasonable communication between devices, smartness is needed. For example, you build a house. Company A offers an excellent heating system and company B a ventilation system. Usually these systems are not eager to communicate with one another, as the heating system and ventilation system are provided with different automation systems. And in most cases, the technicians installing the systems also do not know how to make them communicate with one another. After all, why should the systems communicate with one another as there has been no need for this to date? Technical systems that are not communicating with one another and are not balanced or efficient waste energy. Another factor is user convenience, meaning making people’s lives more comfortable, more economical, safer, etc. via devices that communicate with one another over the network.

We can make different technical equipment communicate reasonably with one another – we connect successfully physical world with virtual.

The crown jewel of our hardware range is a freely programmable powerful Linux-based automatic controller, which can be used in very different applications and situations, such as from a smart house in Sydney to street lighting in Tartu.

The advantage of the controller is its versatility and expandability. With the help of channels added through expansion modules, it is possible to communicate in exactly the same way as with the channels provided with the controllers – this is a very important and rare feature among similar controllers.

Basically, our controller consists of our proprietary I/O card (which is the only content of the expansion module) and CPU module (not available in the expansion module). For a CPU board we use Olinuxino iMX233 Maxi, which fits in the standard 6M DIN rail without any screws. Compared with, for example Raspberry Pi, Olinuxinol sockets are arranged in a more reasonable way and the range of temperature resistance is also wider.

Each IO board has its own Modbus address, each board provides 8 analogue inputs, 8 binary inputs, 8 binary outputs and 1 onewire bus. Modbus RTU interface is always be there, but the board can also accommodate USR K3 Ethernet module, which also provides the ability to communicate via ModbusTCP. In addition, the I/O board can be equipped with a Wi-Fi module, which also facilitates ModbusTCP compatibility. It is a native ModbusTCP, not to a variant of ModbusRTU via TCP (although it is also possible, if requested).

The value and uniqueness of our controller lies in the I/O card. Any Modbus master can be used and it may be located as a server somewhere in the (local) network. I/O cards may be installed in an electrical board or where necessary, by receiving signals from switches and sensors and if needed creating binary or PWM control signals. Some of the binary inputs can be used with Wiegand readers. Analog inputs (with a resolution of 12 bits (with measuring ranges 0–2 V, 0–4 V, 0–5 V, 0–10 V, 0–20 mA) are individually configurable to function as binary inputs and they can also be used as high ohmic outputs. It is sufficient to have one expansion module with an Ethernet-interface in a group of I/O boards via RS485 to connect all I/O channels with Modbus Master located in the PC, if requested.

Analog inputs are ideal for use in the so-called DEOL (Dual end of the line) safety lines, in which changes in the line resistance are used to detect error conditions in the line (short circuit or interruption). To avoid reading it via analogue value reading (16-bit word per each sensor), the I/O board is equipped with comparators, an output (2 bits per each sensor) of which allows reading sensors 8 times faster. One bit represents the status of the signal and the other one the fault of the line – meaning combinations (short circuit/0/1/interruption).

The I/O board is provided with a 5 V supply stabiliser, which turns any DC voltage in a range of 9–28 V into a very stable 5 V 1.5 A power supply. The same 5 V can be used to supply the CPU board and, in case Modbus communication should be interrupted for some reason, the I/O board initiates an interruption in CPU 5 V supply (it is especially of great help to activate the CPU module in the case of such Embedded Linux boards, in which USB and Ethernet are designed by using the same die). The I/O board can also be provided separately with a binary output supply. This allows a 12 V battery supply, for example, but at the same time the use of 24 V actuators. Examples of such actuators are thermal drives of heating valves, which are controlled directly by the I/O board. The quality of the I/O board is also proven by the fact that, if needed, the firmware of the board can also be updated via a network by entering Modbus instructions in the special registry. Only the first programming related to the production is always done with PIC programmer.

The use of the controller or I/O modules alone is limited only by imagination. For example, one of our controllers with the highest load is in Väätsa elementary school, where with the help of five expansion modules it transmits over 550 signals (which come from 19 electricity meters, eight heat meters, thirteen temperature, humidity and CO2-sensors, PV inverter and wind meter) to the UniSCADA monitoring system, and it is amongst others that are also responsible for the cost-effective control of the ventilation and heating system of the school. Other applications based on this controller involve mostly either pumping systems or smart house applications or applications meant simply for collecting information regarding electricity consumption. In more simple cases, we use Barionet 100 controllers made by the Swiss manufacturer Barix instead of Linyx masters.

Benefits of our controller compared to other similar products:

• devices can be installed on DIN rails;
• use of Modbus RTU together with additional modules;
• use of Linux;
• all our modules also fit under the cover of the domestic electrical board;
• for example, in some of the similar controllers, the mother-board of a PC is used in a Linux controller and this increases the size of the device. We use small sized Embedded Linux boards;
• for example, other manufacturers let the users directly in the controller and the controller also displays SCADA views. We consider letting users directly in the controller to be a major safety risk and inefficient use of the network connection; therefore, we arrange everything needed to manage and use the system via a central server;
• we use one big SCADA application (UniSCADA) for different clients. This is always more efficient and safer than a separate SCADA (in our case an ASP or SaaS model) for every client;
• our controller can successfully cope with limited mobile data communication, as user interfaces are served only by a server. SCADA directly from the controller as used by similar manufacturers is problematic (due to the speed and unknown volume of data needed; thus, it is recommended to link the controllers with a mobile communication plan with unlimited data communication volume (meaning expensive);
• our controller does not have problems with mobile data communication, as the volumes are stable from month to month (starting with only 5MB per month!) and the slowness or references of the controller communication are never apparent in the user experience. Thus, for the internet connection of our controller, the most limited M2M sim-cards can be used with the cost starting from 1 euro per month + VAT;
• compared with the competitive products, the design of our controller is of a modular type, which allows to turn each controller by excluding CPU board, into an extension and to turn every extension into a controller;
• for example, connection of the expansion modules of some of the competitive controllers is designed only via RS485; however, in the case of our controllers, both LAN and Wi-Fi can be used and the controller (and I/O expansion module) also supports Wiegand and 1wire protocols;
• our controller also supports Mbus protocol via USB-Mbus or WiFi-Mbus intermediate module.

Technical data:

8 channels of sourcing outputs (DO) up to.24VDC, load current up to 200 mA

CPU architecture: ARM

RAM: 64MB
Op. system: ArchLinux

Communication Interfaces

• One10/100 aseT Ethernet interface

• Two High-speed USB interfaces

• One RS485 interface, from 9600 to 115200 bps, Modbus RTU protocol supported in firmware

• 1-wire interface for up to nine DS18B20 temperature sensors

The application software running on this controller can be written in any programming language supported by Linux OS.