August 2008
News Release
AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)


 

Unified System Architecture

Articles
Interviews
Releases
New Products
Reviews
Blogs
Sponsors
Archives
Past Issues
AutomatedBuildings.com

[an error occurred while processing this directive]

How specifying an open building automation system reduces costs and increases flexibility.

By: Ron Bernstein, Executive Director, LonMark International

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 sub-system 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 with over 600 member companies who are manufacturers, designers, and system integrators, as well as end users committed to the development, manufacture, and use of open, interoperable LON® products and networks.

A good open building automation system specification will define the requirements for each of 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:

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.

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.

[an error occurred while processing this directive] 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.

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.

Enterprise Connectivity – The method for connecting the building control network into the data network – 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 the LonMark International website, www.lonmark.org.

About LonMark International
Since its inception in 1994 and new corporate structure in 2003, LonMark International has become a major driving force in the establishment of interoperable guidelines for building, industrial, transportation, residential, and utility automation.

LonMark membership is open to any manufacturer, distributor, engineer, system integrator, or end user committed to the development, specification, and use of open, interoperable products utilizing ANSI/CEA 709.1 and related standards.

LonMark International is a non-profit, mutual-benefit trade association with close to 600 members worldwide, and local affiliates in the Americas, Asia, and Europe. LonMark's mission is to create, support, and promote the standards for open, interoperable LON-based products, systems, and professionals. For more information about LonMark International, testing, and educational opportunities please visit www.lonmark.org.

Products, which have been verified to conform to the LonMark interoperability guidelines, are eligible to carry the LonMark logo.

LonMark and the LonMark logo are registered trademarks in the U.S. and other jurisdictions. Other marks belong to their respective holders.

footer

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources