In the previous parts (
part 1 ,
part 2 ,
part 3 ,
part 4 ,
part 5 ) the principles and mechanisms of libuniset2 were considered, using the example of a
spherical control problem. It remains to show what was not included in our field of vision ... Those who are not yet tired, please ...
Total
The goal of the previous parts was to show how simply and quickly you can write (
or even deploy ) a control system using
libuniset2 . To summarize, it all comes down to a few simple steps:
- Lay the project and fill it with sensors included in the system (filling configure.xml). By the way, this process can also be automated by generating a list of sensors (or settings) from some other more convenient formats (sources).
- Implement their own control algorithms, having previously described each in a special xml file, regarding its process as a black box with inputs and outputs
- Debug locally, while using various utilities that are part of libuniset2-utils
- Write tests using the test framework - uniset2-testsuite
And that's all ...
But many of the components included in libuniset2 have never been reviewed, so I’ll just briefly describe what else is included in libuniset2 (it
may sometime gain strength to describe them with examples of use )
Components not included in the review
- SharedMemory - The main element of the system through which all work is carried out. In fact, besides the actual storage of current values, SM is able to:
- Formation of notifications about changes in ordered sensors
- Formation of threshold sensors (analog)
- Implements a dependency mechanism between sensors
- Implements a heartbeat tracking mechanism for processes.
- Formation of an emergency trace, by event ( saving by the sensor trigger ("detonator"), values of the specified sensor group for the last N points )
- Data recovery from backup SM
- DBServer - Database maintenance. Save change history for each sensor. Work with MySQL, PostgreeSQL, SQLite, RRD
- Modbus TCP / RTU ( Master , Slave ) - Implementation of ready exchange processes using the Modbus TCP / RTU protocol in the Master and Slave modes. Multi-channel polling, channel switching in case of unavailability of slave nodes, etc.
- IOControl - Working with I / O cards. The work is based on the use of libcomedi . As part of this, drivers were developed to support I / O cards from the Russian manufacturer Fastwel.
- Mechanisms for processing input sensors - trigger and release delay, work on the leading and trailing edges of the signal, anti-bounce, simple digital filters for analog signals, calibration (linear and on calibration diagrams) and other transformations
- UNET is a proprietary protocol based on broadcast UDP. Provides synchronization of sensor status between nodes of a distributed system. Ready component, just set up and run. The very first article presented a block diagram of a system using UNET.
- LogicProcessor - Implementing a simple engine to support "simple" logic circuits. Creates a description of the logical scheme in the form of an xml-file. The elements “AND”, “OR”, “Delay”, “NOT” are available for use.
- MQTTPublisher - Ability to publish data from sensors in the system using the MQTT protocol. The implementation is based on the use of the mosquitto project.
- uniset-timemachine - This is a separate, very interesting project (in python). Its essence lies in playing back historical data stored in the database. Data is removed from the database and stored in SM in real time. For example, if you connect a graphical interface or control panel simulators, you can visually observe which buttons were pressed by the operator at one time or another, which lights were on, what was on the screen of the graphical interface, etc. Those. really "time machine" ( True, this project is still waiting in the wings, optimization is required for large databases, and so far only MySQL is supported. But this is all a matter of time ... )
In general,
there is some, but no documentation.
Little about real use
Of course, as you know,
any program contains errors . I think in libuniset2 not everything is perfect, but still it works. Works in real projects. To date, the “biggest system”
(just there haven't been any more projects yet) is a management system, where:
- About twelve thousand sensors
- About eighty polled ModbusSlave devices
- At the same time, the system itself consists of only 5 controllers and 2 graphic panels.
- Synchronization of the status of all sensors between nodes - 150 ms (UNET)
There were projects with about three thousand sensors, but there were about 18 controllers (nodes). These numbers are not intended to "impress", just want to show that it works. And it
digests large volumes without special optimization, although the mechanisms for this in libuniset2 also exist (there is not a survey on every cycle for low-priority or rarely changing sensors, etc.). In general, about thirty or forty projects.
So try libuniset2, it's easy :)
')
Links to the project: