| |
Member |
|
| |
|
|
| |
 |
|
|
LON Interoperability
Intelligent networks of everyday devices are key for companies wishing to provide better, more cost effective service to customers. They enable the creation of new, service based revenue opportunities and new business opportunities.
There are many ways to create automation systems, from pneumatics to custom, proprietary hardware and software solutions, to open interoperable, standards-based control networks. Today’s automation market clearly calls for the latter.  These open device networks have common traits including an open protocol; flat peer-to-peer architectures; device level interoperability; and a network operating system for easy management, installation and remote services. Automation networks have evolved similarly to PC networks. Figure 1 illustrates how we have progressed from centralized single master many slave systems, e.g., mainframes and terminals; to multi-master/multi-slave, e.g., minis; to flat architectures, e.g. PC-based networks.
In aggregate, networks built with flat open network traits can deliver lower cost at integration and commissioning, have significantly lower life-cycle costs, allow for easier changes and enhancements, are more flexible, and finally are more adaptable to the end users.
 EIA/ANSI 709.1– An Open Control Protocol
An open, device networking communications protocol, such as EIA/ANSI 709.1 (the LonWorks Platform), assures manufacturers and end-users that they have made a technology decision that will be supported today and tomorrow. Thousands of companies today support the use of the protocol. Chip suppliers Toshiba and Cypress Semiconductor have competing families of microprocessors optimized for executing the protocol in cost imperative or performance imperative applications.
Flat Architectures
While there are many ways to architect networks and control networks, for automated controls flat, peer-to-peer (P2P) architectures are best. P2P architectures lack single points of failures inherent in any hierarchical architecture. In such architectures, messages from one device must go first to a controlling master or gateway BEFORE the signal can get to the target device. Therefore, every communication between two non-master devices includes an extra step, or fault possibility. P2P designs, by contrast, allow direct communication between two devices eliminating the fault possibility of the master controller and removing a potential performance bottleneck. Further, device failures in a P2P design are much more likely to affect just the one device, not the potentially many as one finds in non-flat, not peer-to-peer architectures.
[NEXT PAGE]
Copyright Echelon Corporation |
