Automation Applications

The possibilities for automation applications using Barix Barionet are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

• Wastewater pump stations, independent or synchronized over the internet
• Heating Control system with multiple PID loops
• Irrigation System Control
• Remote Telecommunication Site Controller
• Lightning Control
• Ventilation Control
• Remote Reading of utility consumption data (water, gas, electricity)
• etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

• Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
• Time schedules for various purposes can be imported from external calendar server like [Google Calendar
• User profiles (for access systems for example) can be centrally predefined and automatically distributed
• Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like ]http://code.google.com/apis/chart/ Google Charts]).

Barionet is a native Modbus/TCP Slave, meaning it can be polled by almost any SCADA server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of the traditional SCADA systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, http://www.nagios.org Nagios] being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionets to the monitoring server.

If low traffic volume to/from Barionets and high security level at the same while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". All important state changes can be reported immediately to the central server. If there are no state shanges to report, Barionets should still be programmed to periodically access the central server, letting the central server know they are alive. At the same the Barionets may receive possible instructions from the central "brain". For example, the new configuration data or even a new version of application software can be sent this way in addition to the preprogrammed commands.