Automation Applications - Revision history

Sandra at 14:33, 12 March 2009

2009-03-12T14:33:20Z

← Older revision		Revision as of 14:33, 12 March 2009
Line 27:		Line 27:
	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.		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.

	Back to [[Main Page]]		Back to [[Main Page#Applications]]

Sandra at 15:17, 3 March 2009

2009-03-03T15:17:22Z

← Older revision		Revision as of 15:17, 3 March 2009
Line 27:		Line 27:
	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.		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.

	[[~~Back to~~ Main Page]]		Back to [[Main Page]]

Sandra at 15:16, 3 March 2009

2009-03-03T15:16:40Z

← Older revision		Revision as of 15:16, 3 March 2009
Line 26:		Line 26:

	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.		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.

			[[Back to Main Page]]

Dtneeme at 12:37, 25 January 2009

2009-01-25T12:37:50Z

← Older revision		Revision as of 12:37, 25 January 2009
Line 17:		Line 17:

	* 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 [[http://calendar.google.com Google Calendar]		* Time schedules for various purposes can be imported from external calendar server like [http://calendar.google.com 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 ]http://code.google.com/apis/chart/ Google Charts]).		* 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 [http://www.modbus-ida.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Modbus/TCP] Slave, meaning it can be polled by almost any [http://en.wikipedia.org/wiki/SCADA 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.		Barionet is a native [http://www.modbus-ida.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Modbus/TCP] Slave, meaning it can be polled by almost any [http://en.wikipedia.org/wiki/SCADA 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 [http://en.wikipedia.org/wiki/SCADA SCADA] systems, [http://en.wikipedia.org/wiki/Snmp 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 [http://en.wikipedia.org/wiki/Syslog syslog] messaging from Barionets to the monitoring server.		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 [http://en.wikipedia.org/wiki/SCADA SCADA] systems, [http://en.wikipedia.org/wiki/Snmp 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 [http://en.wikipedia.org/wiki/Syslog 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.		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.

Dtneeme: added some links

2009-01-25T12:36:16Z

added some links

Dtneeme at 12:18, 25 January 2009

2009-01-25T12:18:25Z

← Older revision		Revision as of 12:18, 25 January 2009
Line 23:		Line 23:
	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.		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 [http://en.wikipedia.org/wiki/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. Even lower traffic volumes are reachable when using simple syslog messaging from Barionets to the monitoring server.		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 [http://en.wikipedia.org/wiki/SCADA 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. 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.		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.

Dtneeme at 12:17, 25 January 2009

2009-01-25T12:17:53Z

← Older revision		Revision as of 12:17, 25 January 2009
Line 23:		Line 23:
	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.		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, 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 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 [http://en.wikipedia.org/wiki/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. 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.		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.

Dtneeme at 12:14, 25 January 2009

2009-01-25T12:14:14Z

← Older revision		Revision as of 12:14, 25 January 2009
Line 21:		Line 21:
	* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).		* 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/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.

	~~Barionet~~ is ~~a native Modbus RTU 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, 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 no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of 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, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionet 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.

	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 new configuration data~~ can be ~~easily distributed~~ this way.

Dtneeme at 13:51, 10 January 2009

2009-01-10T13:51:54Z

← Older revision		Revision as of 13:51, 10 January 2009
Line 26:		Line 26:
	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 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, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionet to the monitoring server.		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 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, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionet to the monitoring server.

	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.		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 new configuration data can be easily distributed this way.

Dtneeme at 13:49, 10 January 2009

2009-01-10T13:49:26Z

← Older revision		Revision as of 13:49, 10 January 2009
Line 21:		Line 21:
	* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).		* 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.		Barionet is a native Modbus RTU 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 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, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionet to the monitoring server.

	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.		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.

← Older revision		Revision as of 12:36, 25 January 2009
Line 1:		Line 1:
	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).		The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a [http://en.wikipedia.org/wiki/Programmable_logic_controller 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 [http://en.wikipedia.org/wiki/Programmable_automation_controller PAC] (Programmable Automation Controller).

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

	* Wastewater pump stations, independent or synchronized over internet		* Wastewater pump stations, independent or synchronized over the internet
	* Heating Control system with multiple PID loops		* Heating Control system with multiple [http://en.wikipedia.org/wiki/PID_controller PID] loops
	* Irrigation System Control		* Irrigation System Control
	* Remote Telecommunication Site Controller		* Remote Telecommunication Site Controller
Line 17:		Line 17:

	* 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		* Time schedules for various purposes can be imported from external calendar server like [[http://calendar.google.com 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).		* 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.		Barionet is a native [http://www.modbus-ida.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Modbus/TCP] Slave, meaning it can be polled by almost any [http://en.wikipedia.org/wiki/SCADA 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 [http://en.wikipedia.org/wiki/SCADA 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. Even lower traffic volumes are reachable when using simple syslog messaging from Barionets to the monitoring server.		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 [http://en.wikipedia.org/wiki/SCADA SCADA] systems, [http://en.wikipedia.org/wiki/Snmp 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 [http://en.wikipedia.org/wiki/Syslog 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.		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.