In the beginning there was pneumatics, and everything was interoperable. From the time automatic temperature control was first invented in the early 1800's until the early 1970's pneumatic controls reigned as the undisputed king of large system control. Electrical controls had been available since before the turn of the century, but could not easily provide the capabilities such as averaging or high signal selection being asked for by customers in large control systems. Additionally pneumatics had evolved to the point where virtually all manufacturers equipment used the same simple protocol, 3 to 17 pounds of compressed air per square inch or PSI. This allowed the savvy mechanic to "Hot Swap" controllers regardless of manufacturer on the same system.

The Age of SCADA (Supervisory Control and Data Acquisition)
Through the early 1970's, microprocessors started to become less expensive allowing for the first time, computers to be considered by many for new roles. As processing power skyrocketed and prices dropped, data collection software and hardware began to appear for first Mainframe Computers, then Mini Computers, and eventually a new category known as the "Personal" Computer. First used just to collect data, later these systems began to provide rudimentary control in the form of relay contacts to start whole buildings or systems in very large applications.

From these meager beginnings, the term SCADA was born. These new commercial SCADA systems were not as reliable as either pneumatics or electrical controls due to the reliance on a single central computer. If the computer failed, so did the system. Each system was also completely proprietary in its methods. No longer could devices from alternate sources replace existing equipment as was prevalent with pneumatic controls.

These novel systems possessed a new capability though that was very useful for some applications. The ability to store historical data electronically, instead of using scrolls of paper drawn by a spring wound scribe or by paid personnel manually writing in logs, made these systems less expensive to operate when logging of large amounts of data was required.

The Dawn DDC (Direct Digital Control)
Direct Digital Control, commonly known as DDC, began to make a strong showing in the late 1980's as dozens of companies produced systems that distributed some of the processing power to the device level and networked the semi intelligent devices together under a master or "area" controller. In this architecture a master controller would provide many of the functions formerly performed by the PC. This new controller was better suited though for the task. Typically these units held their programs on a chip instead of a mechanical storage disk and the programs were "backed up" by a battery in case the system lost power. More than a few programs were lost on systems of this nature due to lengthy power outages or simply from "bad batteries", and eventually the DDC industry learned from their failures. Now most systems are capable of keeping their programs in silicon for an infinite time without power, and are considered very reliable for commercial and industrial applications.

The Dark Ages of DDC
As DDC became more useful and eventually indispensable in modern day buildings, an interesting thing began to happen. The innovation that vendors were putting into their systems began to pay off in ways they did not originally expect. The large vendors quickly found that once these systems were in place, they had a "Proprietary Lock" on the customer. The customer now needed them to perform any additions or changes to the system because only the original vendor's equipment could communicate with the system. Even the routine maintenance required expertise and products that only the manufacturer's representative could supply.

So important was this change, that whole business models were spawned on this new paradigm. Since control systems normally last 10 to 15 years (the life of the mechanical equipment they control) the control contractor would very nearly "own" this customer for this amount of time. They could then charge anything less than the installed cost for changes and maintenance. The original cost of the installation and materials was all of a sudden insignificant when there was 10 to 15 years to make up any losses and produce large profits. Since all the vendors had proprietary systems the customer had no choice, because every supplier could enslave them the same way.

The Seed of Interoperability
As with any proprietary technology, time is the enemy. Over many years large DDC customers began to feel the pain of their proprietary chains and sought answers. In the industrial control arena where costs are typically higher than in commercial controls, entrepreneurial developers began to make software that would first talk to multiple vendors equipment and eventually pass values from system to system through either a PC or a hardware based gateway.

This form of interoperability allowed customers to have some choice in suppliers of control hardware, but added difficulty in the process and took a step backward in reliability since the system again had a single point of failure, the gateway. Whether the gateway was the PC itself or another piece of hardware, any changes made to the systems on either side could also cause complications in communication. Even with these serious problems a certain number of end users migrated to this approach due to the limited relief it provided them by allowing multiple bidders on large additions.

This budding trend did not go unnoticed by the large control manufacturers though, and they quickly started to create their own gateways to each other's equipment. Customers however started to become disenchanted with the approach since the manufacturers concept of this model was to "connect to the other guy" but keep control of the network. This scenario made sure that the system providing the gateway to the other devices remained in control and in effect locked out the other vendor from the GUI (Graphical User Interface) and therefore access to the customer.

More importantly was that neither of the aforementioned methods of interoperability actually provided significant monetary relief to the customer since he or she remained enslaved by the original supplier for every facet of the system once it was installed. Any reprogramming or replacement parts must again come only from the original supplier. These facts allowed the proprietary model to continue for more than a decade. During this time it was possible for the manufacturer to charge a premium for additions to large systems once the customer was locked, since no one else could provide the necessary products and services. The larger the system, the greater was the barrier for any other vendor, and therefore the larger the premiums being charged for the system.

Protocols and Public Entities
Eventually every new technology matures and standards begin to form. With so much consumer pain from proprietary control systems it was inevitable that such an event would happen with DDC. The question wasn't so much if it would happen, but rather when it would happen, and how.

In the early 1980's the Association of Heating and Refrigeration Engineers (ASHRAE) took up the interoperability cause. It seemed a good place for discussions on the topic since ASHRAE is a standards body and all of the major control vendors were members, as were the mechanical engineers who would later specify the interoperable designs. After all, the working committees in ASHRAE had tackled hundreds of standards issues in the past surrounding the way mechanical equipment should run. So the committee was formed and sure enough, every major supplier of building HVAC controls became involved. Even the government gave support to the project. This was a very good start indeed.

Several major problems loomed with this scenario though and they would take years to unfold. Many people that were part of the process say that the members really didn't want to have a standard. Others would tell you that the control manufacturers built their systems so differently that they just could not agree on how it should be done. Still another group will tell you that the ASHRAE working group process is the real culprit that caused so much time to pass. What is clear is that it took 11 ½ years to create a 501-page specification that loosely describes a hierarchical control system.

So loosely in fact that few manufacturers have implemented the specification since the 1995 release. One of the problems is that the document is "what everyone in building controls could agree on". Since the control manufacturers couldn't seem to agree on much, it leaves to question what the document actually does contain. The BACnet document (HPC 135-1995) in large part describes the vocabulary of a control language. In order to get agreement from everyone concerned, it also details several different networking methods. It seems that different vendors had fundamentally different views about networking.

The resulting specification actually allows different types of networking without much discussion about the overall architecture of the system. This problem was compounded by the long period of time that the body took to create the standard. Networking technology has come very far since 1995 and the specification did not take advantage of most of those changes.

Because manufacturers also looked at control systems in different ways and the specification allowed each of these, different suppliers built systems that have wholly separate architectures from each other. Four vendors today supply complete control systems they claim are based on BACnet. Of these four, each has a different way of implementing the architecture. What that means is that the control devices from one vendor's BACnet system will not exist on the other vendors BACnet network. Unfortunately it is not possible now to "Hot Swap" terminal devices on different BACnet networks as was the benefit of pneumatic controls. The best that can be hoped for with BACnet is the passing of values between entire systems or buildings through a relatively expensive media converter or router.

Even the idea of a common host becomes problematic on such systems since each system requires its own tools to configure the system and with all the systems mentioned, the programming tools are married to the individual vendors GUI. This means that each vendor must have their GUI on the site to configure their network. In other words, current BACnet systems must be put in using the vendor's proprietary software and maintained by that vendor for the life of the system. Worse yet is that all of the current BACnet system manufacturers have proprietary relationships with specific distributor\contactors or branch offices. This means that the local supplier is the only company that can get the products and software or provide authorized service.

These facts remove most of the benefits and reasoning for an "open" system in the first place. If an owner can't get competitive bidding on phased projects then what good is the open system? If they are stuck with one product family for the life of the system then what has been gained? If they must go to the original installer to get maintenance at whatever cost, then what exactly do they get from interoperability?

Private Enterprise to the Rescue
If someone had told you back in 1980 that a startup company formed by a former computer executive and the CEO of telephone PBX hardware would change the entire control world in the 1990's you would have called them crazy. Well crazy they may be, but that is precisely what happened.

While the BACnet committee was being formed to discuss only building controls, Mike Markkula formerly of Apple Computer and Ken Oshman formerly of Rolm Telephone were looking at controls from a very different angle. The question was simple; since microprocessor based systems are all just computers, why can't we make them all talk the same language? A very good question, but one without a simple answer. Millions of microprocessors had been built over the years by different manufacturers, all of them with different designs, but only recently had they been asked to actually speak to each other.

Getting everything with a microchip to speak the same language was a very large goal for any company, much less a fledgling start up. It was exactly what the new company Echelon Corporation set out to do. The first task was (like BACnet) to define a protocol or control language. Echelon came up with the LonTalk protocol specifically designed for inexpensive, extensible, high-speed control networks. Many people had designed protocols in the past though and interoperability was nowhere to be found. The team soon decided that creating a document explaining how to speak a language was clearly not sufficient. In addition to BACnet several vendors had invented their own languages and published them, calling that interoperability. Many vendors also had taken previously public protocols and "tweaked" them slightly so that only they could speak the lingo.

For their grand goal they would need much more than a mere control language. They would need to make the whole process more fool proof. They would need to entice the manufacturers, by making the whole implementation process cheaper and easier. Some way would need to be devised so that interpretation of a specification was not necessary thereby guaranteeing interoperability at the device level. Last but not least, they would need to propel the technology to every industry. To do this, they decided they would need some piece of hardware to easily translate between all different kinds of microprocessors. A device that could be inexpensively manufactured and easily embedded in products by the device manufacturer.

Thousands of man-hours later, the Neuron Chip was born. This aptly named device was small, inexpensive and could be put in any microprocessor-based device. It would allow the device manufacturer to concentrate on building their device and not on interpreting a communications specification. Once embedded, interoperability could be guaranteed since every device had the same chip and protocol implementation regardless of its function. Anything from a car to a VCR could be connected together and share information on an inexpensive network.

So how would these devices connect? The answer is an astounding, "any way you want". One of the beauties of private industry is that decisions are not made by committee. One of the things decided early, was to keep the "transceiver" separate from the system. Simply put, the transceiver is the device that decides what kind of wire or "media" the device can connect to. In this way, the manufacturer could make a single device and have it connect via twisted pair or by wireless RF, the only difference being the transceiver. They also decided to make sure that small inexpensive media translators (routers) were available for each media type. This would allow a control contractor to connect all devices to each other on the same network regardless of the media each used. This family of software, chips and technology created by Echelon was given the name we now know as LonWorks.

LonWorks systems today span the entire globe. Millions of devices from thousands of manufacturers and dozens of industries coexist on common networks, sharing information with each other. Almost every control industry is now well represented including Industrial, Process, Lighting, Security, Transportation, Home, Fire, Semiconductor and many more. Surprisingly, over 60% of all building controls manufacturers are shipping LonWorks based products today.

Interoperable Associations and Industry Innovation
Many advances have also been made to LonWorks and the underlying standards that ensure interoperability. Not the least of which is the formation of the LonMark Interoperability Association (LonMark). This non-profit organization is made up of hundreds of manufacturers and integrators and has the charter of furthering interoperability. This body has added layer upon layer of standards to the original LonWorks networking.

One of most recent advancements made by LonMark is the concept of network profiles. The idea is simple, no matter who makes a particular product; each class of product performs the same function. Put differently, a VAV box controller from manufacturer A actually does the same basic thing as the one from manufacturer B, and so it goes for all types of equipment. If this premise is true, then one could define what a device should look like on the network, what points it should have, their names etc. and it wouldn't matter who's controller you chose from a networking standpoint. Each would look identical on the network. The physical boxes may be a different color or even of different quality but on the network they would be equals. If this could be done, then one device could actually be "Hot Swapped" for another even if a different manufacturer produced it.

What about innovation? What about the manufacturers desire to build a better mousetrap? LonMark profiles provide the best of both worlds. The end user has a guarantee of a minimum "profile" knowing what will be minimally visible from the device on the network. The manufacturer also has the ability to add value since the standard is a minimum requirement. They must have a minimum number and type of points, but they can also add as many as they wish outside the profile. Flexibility, and guaranteed interoperability.

There are over 300 LonMark devices available today. These devices can all exist seamlessly on the same network and share information with each other. This allows end users to get competitive bidding on multiple buildings or phased implementations. Owners can also choose their favorite products from different industries and integrate them into a single inexpensive network. While not having LonMark devices does not necessarily mean they will not interoperate on a LonWorks network, having LonMark devices does give the assurance that the devices will interoperate more easily.

The Dark Side 
With such a rosy picture painted, what's the hold up? Certainly there are hurdles to get over with interoperable LonWorks systems. Some vendors sell different variations of their systems with different levels of interoperability. It resembles the old shell game, where the goal is to uncover the proprietary part. After all it only takes one bottleneck in any system to keep the network proprietary and keep the customer in control.

To find any proprietary link it is necessary to understand a little about how LonWorks is intended to operate. LonWorks (like the Internet) is a peer-based system. This means that in its true form; any device can speak directly with any other device on the network without the need for a master or "area" controller. In fact in a "flat" LonWorks network or "LON" an area controller is not needed or desired.

The functions that were previously performed by the area controller in a hierarchical system are distributed in devices across the network. Functions such as scheduling, alarming, trend logging, remote access etc. are modular and can be added in any number and placed anywhere on the network. This allows unprecedented flexibility and redundancy, while allowing for a nearly linear cost curve to grow the network. If more I\O is needed, it can be purchased and placed on the network without the cost of a supervisory controller beyond a specific number of devices. If additional services are needed they can be purchased from the vendor of choice and simply placed on the network. If more logging is needed, simply purchase an additional logger and place it on the network. If another system is desired such as card access, it can be added to the existing network infrastructure without the added cost of creating another network. The new access control system can then be "integrated" into the current control sequence.

The Proprietary Shell Game 
The first place to look for the proprietary "gotcha" is an area controller. Typically these devices spell trouble on a LonWorks network. The obvious clue for this type of device is that they speak LonTalk (EIA 709.1) on only one side and some other protocol on the other. This device is in fact an unwanted gateway to a different language, in many cases a proprietary protocol. A gateway with a proprietary protocol on one side is a fairly obvious death sentence to interoperability. What isn't so obvious is that regardless of what language is on the other side, every time a gateway is put in place there is a bottleneck in the system. In addition there must be a translation every time communication travels through the gateway. This fact will disallow use of all standard tools through the gateway, allowing only a subset of "vendor friendly" tools to pass data to the other side. This is another way to subtly control the devices on the network. Regardless of which protocols are on either side of a gateway, gateways increase the likelihood of problems and make troubleshooting and upgrades more difficult.

The second potentially proprietary Trojan horse is the software. This software includes applications that configure the system, as well as the GUI (Graphical User Interface) that is used on a daily basis by the building operator. Both are important to make sure your system remains interoperable. If the wrong software choices are made options open for future additions and changes will be reduced or eliminated all together.

In a LonWorks system, having tools that create a common database is a mandatory prerequisite to interoperability. The database is the record of the network and is the starting point for additions and changes made by other vendors. Every vendor's tools that would make changes and additions to the network must be able to read and write to this database. Some vendors have chosen to create tools that generate their own database hierarchy instead of using the LNS (LonWorks Network Services) database created and recommended by Echelon (the creator of LonWorks). Much like SQL (Structured Query Language) is a defacto standard in computer industry, LNS is the defacto standard in the LonWorks networking industry with by far the largest number of software tool vendors building tools and application plug in's that use the LNS database. Without a common LNS database to record the LonWorks network, the chance of interoperability is also decreased.

The remaining place to hide a proprietary component is the GUI (Graphical User Interface). While over a dozen GUI software packages that will communicate with LonWorks networks in a standard way are available on the open market, some hardware vendors have chosen to create their own GUI to work with their hardware. In some cases these packages incorporate all aspects, of the system including the configuration tools, much like proprietary systems. Many of these package deals are in fact proprietary in that they must use their hardware and their software to create the system. Many of these "All in One" systems can incorporate other vendor's devices on the network to some degree and therefore claim interoperability even if not completely. The greatest flexibility comes when ANY part of the system can be replaced by a component from another vendor. Software is no exception to this rule. Many hardware vendors make software that either works in conjunction with or is a direct plug into the LNS database. For these configuration tools, interoperability is guaranteed, since they read and write from the common database. If the software tools are independent of any GUI, a third party monitoring software can be chosen from a large field of contenders and can be replaced in the future if desired.

Even though GUI software from independent vendors has proliferated in the control industry with many packages available, again the key for interoperability is standards. The key standard to look for in an interoperable GUI is the connection method to the control system. DDE (Dynamic Data Exchange) has been the defacto standard for many years and the preferred method for open GUI software to communicate to control systems.  There are thousands of DDE drivers available, many to proprietary systems. Another newer standard way for control systems to communicate with software packages is OPC (Object Linking and Embedding for Process Control). This standard was created by a non-profit industry organization to enhance the capabilities of interface software beyond that of DDE. Although the specification is relatively new, many drivers being created today use this standard.

Most GUI software that sells on the open market seizes every opportunity to use standards. Open market GUI applications use industry standard graphics such as the BMP, GIF, or JPG formats and uses standard historical databases such as SQL to keep trend data. One of the key attributes of this class of software does not however have anything to do with the databases or graphic files. In fact one of the most important features of this software has nothing to do with the operation at all. One of the key factors linking software of this type to interoperability is how it is distributed and procured. Unlike control software of the past, open market or "third party" GUI software is available to anyone. Any contractor can purchase the software and receive training on its use. This includes the documentation and training necessary for a technician to build an entire system. Vendor specific software is only available through one provider. Typically training of the depth necessary to create systems is only available to the manufacturer's branch offices or dealer network. If vendor specific software is chosen to cap an otherwise interoperable system, every vendor after that is at a nearly insurmountable disadvantage since they have no knowledge of the GUI and have no way of getting it. Even if the original vendor is contracted to perform work on the GUI, again they are the only entity that can provide this service. The fact that they have no competition for this work increases the likelihood that they may raise prices.

Even as the control industry moves toward Internet standards where data can be seen in a common web browser, these issues remain. Most vendors that promise web server capability do so in a proprietary piece of software or hardware. The network below the web server may still be captive to the system provider if they are the only body capable of providing additions or changes. Being able to replace products between manufacturers at the device level and have multiple bidders for new systems gives the customer what they want.

Light at the End of the Network
The good news is that thousands of truly interoperable systems exist around the world and more are being built every day. Any part of these systems can be replaced with products from multiple vendors and specifications for additions receive responses from multiple bidders. Control contractors that have in the past provided proprietary systems from a single manufacturer are increasingly seeing their role as that of a solutions provider. They assist in choosing the hardware and software that provides the owner with the best answer to their needs regardless of the manufacturer.

While great care is needed to create the systems described in the proceeding pages, the difficult is getting easier. The demand for interoperability is increasing and manufacturers are responding with LonMark products. With careful specification and resolve on the part of the owners to accept only interoperable systems, they can for the first time achieve "Control System Independence"

[Click Banner To Learn More]

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