Control Operating System (COS)
Our Control Operating System (COS), which is a central element of our energy control networking platform, unifies the many devices, networks and systems involved with energy supply and demand. COS allows control across previously stove piped system boundaries. This requires that new devices and packaged applications be easily incorporated, and new custom applications be enabled.
Built on a Proven Approach
In developing COS, we drew on our experience developing the LonWorks® protocol, now an open international standard for integrating many very different applications. However the real world consists of many protocols, including rudimentary master-slave models that are notoriously difficult to work with to extract and share data among applications. In addition, systems around the world differ in the protocols they use for the same applications.
For smart, efficient unified control systems, applications will need to be written without developers knowing the details of each of these systems. We solve this problem by converting data to a common format.
The Common Data Model for Energy Control Networking
Control nodes have dedicated drivers that convert data into a common format we call data points. Data points are similar to the network variables used in LonWorks. But rather than the fixed predefined semantics of network variables, data points are XML encoded with well-defined schema and access methods, and carry everything that is needed by a smart-grid application, for example, equipment and its location, configuration, alarm limits, and relationship to other control objects.
Control nodes also communicate to the IT systems using standards familiar to the IT world. It plays the role of translating the IT world to the control network world. To do so, it contains the knowledge of the various control protocols. At a basic level, this is a protocol converter, but for the Smart Grid, that isn’t enough. To support decision making at the edge, applications that can control and monitor the devices speaking the various control protocols must run in the control node. The unified data model enforces how data moves through the system, where and how it is converted from the canonical format to the network specific format, and enforces high fidelity of semantics for the conversions.
The generality of the data model and the availability of drivers for the different protocols enable new cross-domain application development. Anyone can write drivers, anyone can add new hardware interfaces and anyone can write applications. Within the control node, the control operating system publishes the data on the internal, virtual network. All the applications are connected to this virtual network and can receive any data point that they have been provisioned to work with. Similarly when applications write to a data point on the virtual network, it can go to any reader of that data point, whether they are other local applications on the same control node, remote applications on another control node, enterprise-class applications running in the data center, or devices on one of the networks attached to the control node.
At present drivers exist for Modbus, DNP/DNP3, BACnet (third party), OSGP, M-Bus, and LonWorks. More drivers will be added by Echelon and 3rd parties going forward.