The worldwide protocol is open, fair, and easy to implement.
The concept of a control networking architecture, which provides fair competitive bidding on all levels of a system and over the life of the system, is something the user market has been demanding for years. Network protocols, such as BacNet, LON, ModBus, and ZigBee, have been developed to deliver on this need. In this vein, defining new rules and a structure for interoperation allowed for competing manufacturers to sit down at a neutral table and design for the betterment of their industry. Though a monumental task, it was fueled by the desire to grow the market from a level playing field–irrespective of company size and market dominance.
By creating a common language, which lets developers focus on their applications, development times for new products are reduced and the effort to make products interoperable is simplified. It also enables many different control systems to work more cohesively in the same system. Functions such as HVAC, lighting, access, security, energy monitoring, irrigation, and more can now be integrated into a common graphical interface without any aspect of the system being locked into a sole source provider. This answers the plea from the market for more options, more open bidding, and greater intelligence in control systems.
I don't believe that any other protocol covers as many industry applications as LON, which was fixed in the early 1990s, and hasn't changed since. A device built then will interoperate on the same network as a device built today. The official name of the protocol is ANSI CEA 709.1 or EN-14908 protocol and is under control of the US and European standards bodies. The basic rules state that to implement the protocol, the entire protocol must be implemented according to the specification. There are no “optional” elements, which would make implementations by different developers non-interoperable. Competitive standards allow for optional elements to be implemented at the developer's discretion. This poses problems for the integrator when attempting to match devices from different vendors.
Technically, the LON standard covers all seven layers of the OSI (Open Systems Interconnect) reference model from the physical interfaces, such as wired, power line, RF, and IP, to the application layer and all layers between. The main difference between the LON protocol and other languages of equal recognition like BacNet, ModBus, and ZigBee is that LON was designed from the bottom up as a controls communication platform. It wasn't limited to a specific application area like building controls or HVAC. The concept extends from commercial buildings, to industrial plants, home/apartment automation, utility/energy monitoring, transportation, retail, and military applications. The concept was to drive the cost of the devices down by reducing the engineering time needed to “rebuild” communications protocols by each vendor and at the same time, provide a comprehensive powerful set of services for a wide range of applications. LON includes various options for the physical connection to the network and allows for the selection of a multitude of service options depending on the application.
LonMark International defines the rules for interpretation of data on the communications network, and refers to the core data types as Standard Network Variable Types (SNVTs) and Standard Configuration Property Types (SCPTs). These types provide the functional language and definitions devices use to communicate with each other. Combinations of SNVTs are used to define device objects (temperature, humidity, etc.). And combinations of objects define unique device profiles. A profile typically represents a type of device and provides a common definition of a device's interface. For example, a device built to the variable air volume (VAV) profile can be swapped with any other VAV device using the same profile, and the system will respond appropriately. This is due to the commonality of the interface. It doesn't define the controller's internal functionality or algorithms used in its software. This provides the best of both worlds: a common interface to simplify the system integration requirements and broad flexibility for the device developer to implement unique internal algorithms and hardware functionality.
The use of SNVTs and SCPTs also simplifies a system's network management and provides one standard mechanism for data and object types. For example, without a firm definition of temperature, some manufacturers would implement in Celsius in 0.1 degree resolutions, while others would implement in Fahrenheit in 0.01 degree resolutions. Internal type translation and scaling would significantly add to the cost and time to implement a system, not to mention the inherent risk of error. In the world of LON, this isn't left up to chance. There are just over 160 SNVTs, which define most every type of data variable commonly used in most every industry around the planet. The process of adding SNVTs is straightforward, and new ones are added annually as needed. A master list of SNVTs and SCPTs referred to as “resource files” is posted on the LonMark International Web site.
All aspects of the LON protocol are open to development fairly to any manufacturer anywhere in the world. LonMark International assists interested parties in developing and certifying products through the process. LonMark works with many organizations to support their design efforts and to ensure the integrity of the protocol and the implementation of interoperable devices. LonMark International is currently pursuing ISO level standards for several aspects of the protocol. This is an important initiative and step in the evolution of LON. Once LON becomes an ISO standard, the protocol will likely be under the control and direction of the ISO team. LonMark International will continue to work closely with ISO to enhance and extend the usage of LON.
The common protocol language lets vendors of devices, software, tools, interfaces, etc. to focus on their core competency rather than having to build all of the system's components. It's impractical to expect an expert in HVAC controls to also be an expert in network management or security, for example.
Will there ever be a single protocol over which all systems will communicate? Maybe. The most likely candidate is some sort of IT solution, but there's minimal market evidence of a pure building controls IT solution. There are many problems with IP everywhere, such as the wiring costs, the costs of maintaining IP addressing and implementing a powerful IP stack on simple devices like light switches and thermostats. In the foreseeable future, there might just be an intelligent controls communication backbone, which will be bridged to an IT platform mainly for the graphical user interface and other system connections and applications.
Ron Bernstein is the executive director of LonMark International and has been working with LON solutions for over 20 years. He has given lectures around the world on open systems and is a published author with articles appearing in various industry magazines. Bernstein can be reached at.