Difference between revisions of "Automation Applications"
m (some polishing) |
|||
Line 14: | Line 14: | ||
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. | 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. | 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 | * 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 | * 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 Google Charts for example | * Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts). | ||
Barionet is a native Modbus RTU Slave, meaning it can be polled by almost any SCADA server. This makes 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, but there will be added traffic caused by 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 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, Nagios being one of the most popular. | |||
If low traffic volume to/from Barionets and high security level 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". Barionets are programmed to periodically access the central server, sending their data to report and receiving the further instructions from the central "brain". Also a new version of application software or just configuration data can be easily distributed this way. |
Revision as of 13:43, 10 January 2009
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 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 Google Charts).
Barionet is a native Modbus RTU Slave, meaning it can be polled by almost any SCADA server. This makes 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, but there will be added traffic caused by 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 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, Nagios being one of the most popular.
If low traffic volume to/from Barionets and high security level 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". Barionets are programmed to periodically access the central server, sending their data to report and receiving the further instructions from the central "brain". Also a new version of application software or just configuration data can be easily distributed this way.