How an Open Building Automation System Cuts Costs, Increases Flexibility
Having a specification that allows for any system option and protocol leads
to a more complex system, one that is more cumbersome to install, commission,
and maintain. It can be compared to allowing all employees in a company to use
PCs, Macs, UNIX, and Linux computers, while also allowing Ethernet, ARCNET, and
Token Ring as network communications media, and insisting that the IT department
maintain and service all of these. The workload becomes unbearable, which is
typically why IT departments pick one platform and stick with it.
Likewise, it is typically recommended to pick one common protocol for the entire building control system infrastructure and stick with it. The costs go down and the maintainability goes up. If there is a specific application or subsystem component that is not available on this standard protocol or if there is a specific need for using an alternate, this should be justified and a gateway (protocol translator) identified and specified. However, this should be the exception, not the norm.
Defining a common system architecture using standard, open methods is important and more appropriate than specifying the “buffet” style that allows anything to be used. An open building automation system provides interoperability where software and hardware from multiple vendors can communicate and coexist without the use of protocol converters and gateways. There is a variety of open protocols on the market including an interoperable protocol from LonMark International. LonMark is a non-profit association made up of member companies who are manufacturers, designers, and system integrators, as well as end users committed to the development, manufacture, and use of open, interoperable products and networks.
A good open building automation system specification will define the requirements for each aspect of the system. When defining an open spec, try to remember it is more than just the protocol that needs to be specified. There are five elements that need to be defined:
1. The Infrastructure - Including the protocol, routers, media type, IT connectivity, etc. All these should be specified based upon open standards, not on one vendor’s specific product. A single system infrastructure provides the benefits of a reduction in construction costs, lower life cycle and maintenance costs, as well as providing an improvement in performance for the whole building.
2. The Devices - These are the controllers in the network that produce, consume, or manipulate data and control/monitor the system. In an open system, it is possible to use devices from different vendors, because they all conform to a uniform industry standard, such as LON. This means that the system is not locked into a single supplier, allowing the best and most cost-effective equipment to be used. In this way, suppliers are able to concentrate on developing products, which focus on their core competency and not have to develop a complete system. Conversely, an integrator who is capable of working with the open protocol will be able to install a complete system selecting the most suitable products from different suppliers. This way, only one integrator is required for the entire system instead of multiple integrators, which can be expensive and cause isolation of the subsystems. An open system also makes upgrading easier and more flexible.
3. The Tools - These are the software or network management tools that configure, commission, and maintain the system. The tools on the system need to be able to co-exist. Device configuration plug-ins (modules) have been developed to allow use of any standard network management tool. This allows vendors to configure their devices with an open tool, meaning users are free to use tools from any vendor they choose.
4. Graphical User Interfaces - These are typically the visualization tools that the user or controls manager uses to obtain a view into the system. User interfaces allow control, monitoring, reporting, alarming, scheduling, and diagnostics. An operator workstation (user interface) affords the means to efficiently and effectively manage operations as well as display and print a graphical representation of the control network. A user interface provides the same look and feel for monitoring and control regardless of which vendor’s system or subsystem an operator is viewing. As a result, system operators need only become proficient with one user interface.
5. Enterprise Connectivity - The method for connecting the building control network into the data network - also known as the LON-LAN-WAN architecture. This ensures that the control system becomes an element of all the data sources available to the enterprise. Open interfaces have been developed to ensure data communication between the LON (the building control network) and LAN (Local Area Network) is accessible by a vendor. To provide this connectivity, enterprise level infrastructure devices are needed, and they must be specified as open. Standard routers are used which means no gateways are required.
Given this summary, it is strongly suggested to limit the main system specification to just one methodology for communication. To ensure a truly open system, all five systems elements must be open. This means each element must be interoperable and all training and servicing must be specified as open, in other words not locked into one system service provider. This, of course, is assuming there is a desire to reduce costs, improve flexibility and choice of products, provide the option for choosing the best system integrator, and allow for open bidding on both the initial installation and the long-term service contract.
For more information on open system architecture and on LonMark interoperable open systems, visit www.lonmark.org.
Publication date: 09/08/2008
Likewise, it is typically recommended to pick one common protocol for the entire building control system infrastructure and stick with it. The costs go down and the maintainability goes up. If there is a specific application or subsystem component that is not available on this standard protocol or if there is a specific need for using an alternate, this should be justified and a gateway (protocol translator) identified and specified. However, this should be the exception, not the norm.
Defining a common system architecture using standard, open methods is important and more appropriate than specifying the “buffet” style that allows anything to be used. An open building automation system provides interoperability where software and hardware from multiple vendors can communicate and coexist without the use of protocol converters and gateways. There is a variety of open protocols on the market including an interoperable protocol from LonMark International. LonMark is a non-profit association made up of member companies who are manufacturers, designers, and system integrators, as well as end users committed to the development, manufacture, and use of open, interoperable products and networks.
A good open building automation system specification will define the requirements for each aspect of the system. When defining an open spec, try to remember it is more than just the protocol that needs to be specified. There are five elements that need to be defined:
1. The Infrastructure - Including the protocol, routers, media type, IT connectivity, etc. All these should be specified based upon open standards, not on one vendor’s specific product. A single system infrastructure provides the benefits of a reduction in construction costs, lower life cycle and maintenance costs, as well as providing an improvement in performance for the whole building.
2. The Devices - These are the controllers in the network that produce, consume, or manipulate data and control/monitor the system. In an open system, it is possible to use devices from different vendors, because they all conform to a uniform industry standard, such as LON. This means that the system is not locked into a single supplier, allowing the best and most cost-effective equipment to be used. In this way, suppliers are able to concentrate on developing products, which focus on their core competency and not have to develop a complete system. Conversely, an integrator who is capable of working with the open protocol will be able to install a complete system selecting the most suitable products from different suppliers. This way, only one integrator is required for the entire system instead of multiple integrators, which can be expensive and cause isolation of the subsystems. An open system also makes upgrading easier and more flexible.
3. The Tools - These are the software or network management tools that configure, commission, and maintain the system. The tools on the system need to be able to co-exist. Device configuration plug-ins (modules) have been developed to allow use of any standard network management tool. This allows vendors to configure their devices with an open tool, meaning users are free to use tools from any vendor they choose.
4. Graphical User Interfaces - These are typically the visualization tools that the user or controls manager uses to obtain a view into the system. User interfaces allow control, monitoring, reporting, alarming, scheduling, and diagnostics. An operator workstation (user interface) affords the means to efficiently and effectively manage operations as well as display and print a graphical representation of the control network. A user interface provides the same look and feel for monitoring and control regardless of which vendor’s system or subsystem an operator is viewing. As a result, system operators need only become proficient with one user interface.
5. Enterprise Connectivity - The method for connecting the building control network into the data network - also known as the LON-LAN-WAN architecture. This ensures that the control system becomes an element of all the data sources available to the enterprise. Open interfaces have been developed to ensure data communication between the LON (the building control network) and LAN (Local Area Network) is accessible by a vendor. To provide this connectivity, enterprise level infrastructure devices are needed, and they must be specified as open. Standard routers are used which means no gateways are required.
Given this summary, it is strongly suggested to limit the main system specification to just one methodology for communication. To ensure a truly open system, all five systems elements must be open. This means each element must be interoperable and all training and servicing must be specified as open, in other words not locked into one system service provider. This, of course, is assuming there is a desire to reduce costs, improve flexibility and choice of products, provide the option for choosing the best system integrator, and allow for open bidding on both the initial installation and the long-term service contract.
For more information on open system architecture and on LonMark interoperable open systems, visit www.lonmark.org.
Publication date: 09/08/2008
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!
