communication

The success of the internet is largely due to a set of standards which define the internet protocol (IP). Prior to IP, communication systems required their own domains, each with unique protocols and infrastructure. The key advantage of IP is that it acts as a foundation for multiple communication systems to interoperate over the same domain.

Many of the current systems of automation and control reside on proprietary domains which do not use IP. The installed base of such proprietary domains is often extensive and cannot easily be replaced. Such systems may be connected to the internet, but a gateway and (often bespoke) control software are needed to interface with IP-based IT infrastructure.

However, data from proprietary protocols can be carried over IP-based IT infrastructure, if a suitable framework can be devised. This would allow the existing installed base of proprietary domains to communicate seamlessly with newly installed infrastructure based on IP connectivity. Figure 1 shows what such a system might look like.

Figure 1. IP-based automation domain

The advantage is that the information from existing domains can easily be shared between domains and through public internet infrastructure to trusted cloud servers.

The ability to make such devices become accessible over the internet is known as the Internet of Things (IoT). Implementing effective IoT solutions often requires a more multidisciplinary approach, including the following considerations:

  • An understanding that IoT security is systemic
  • An awareness that interoperability is critical
  • A systematic approach to testing
  • A thorough cost/benefit analysis
  • Comprehensive documentation
  • An understanding of performance benefits

Open Connectivity Foundation (OCF) is a standardization organization specifying a set of technologies designed to make such IoT systems a reality. OCF provides a framework for carrying data from existing automation domains over IP, while providing device discovery, on-boarding, resource discovery, and control.

The OCF standard is highly secure and conforms to the security requirements as indicated in a report titled, “The C2 Consensus on IoT Device Security Baseline Capabilities” by the Council to Secure the Digital Economy (CSDE). The OCF specification is IP-based, and is built upon a large set of international standards defined by the Internet Engineering Task Force (IETF) for a sound technical basis.

The concept behind the OCF architecture is that application usage of the underlying software stack should be simple. OCF enables this by leveraging the representational state transfer (REST) model; the simplicity of which enabled mass adoption of Web services and is well known by today’s application developers. To make the stack more suitable for small devices, the HTTP is replaced by its binary variant CoAP, and the JSON data is compressed in CBOR to achieve smaller data transfers. All data transfers are secured by industry standard datagram transport layer security (DTLS).

OCF also sponsors IoTivity, an open-source stack implementation that keeps pace with the OCF standard. Having an open-source implementation of the standard greatly reduces the investment to develop IP IoT products. The IoTivity implementation of the OCF Core Framework defines most everything needed to create a secure IoT IP device.  You just bind your chosen IP wired or wireless network interface to the bottom and run your chosen application protocol over the top. This means the installed base of existing systems such as those from BACnet and KNX, for example, can continue to communicate in the same way, while taking advantage of modern wireless technologies such as Thread as they look to meet new energy efficiency targets such as the European Union’s Nearly Zero Energy Buildings mandate.

This IoTivity development helps teams concentrate on what their product does without wasting time on how the functions are securely communicated over IP. On top of that, this approach is portable to various platforms and operating systems by having a porting layer. Chances are, teams will already find the port they need in IoTivity, but if not, the porting layer allows them to support the exact combination of chip and operating system desired. To ensure interoperability, OCF has a certification program, and these conformance tests are implemented

in the OCF conformance test tool. The conformance test tool is used to certify OCF clients and servers. While the official certification of an OCF device is conducted by an independent test house, the conformance test tool is also available to developers to test for compliance during the development stage. The developer can integrate the compliance testing as part of the product development cycle, reducing the overall product development time by de-risking the certification stage. Having the conformance test tool accessible to development teams reduces the time-to-market for products.

The OCF specification can be used in various deployment scenarios, for example:

  • Communication between peers on the local (proximal) network
  • Communication between devices on the proximal network and cloud entities
  • Communication between cloud entities

All of these different communication mechanisms can transport the device application resource communication. Different communication mechanisms can be used, depending on the requirements of the deployment.

The various communication styles can be part of the deployment. Since IP communication is used, the control of the devices can be achieved by local control points or via the cloud. Also, cloud-to-cloud integrations are possible, reducing development time. Device-to-device communication is important because it can be used without the internet. It gives the advantage that, when the internet connection is down, local control is unaffected, which will allow a greater usability of the system. Additionally, the framework allows bridges to be made to existing non-OCF devices, which reduces development effort to connect to existing deployed systems.

Another factor of a successful deployment is having a choice in physical layers. Since the OCF specification is IP-based, the best physical-layer-connectivity solution can be chosen for a specific use-case. For example, Wi-Fi connectivity can be used by devices that have mains power, while battery-operated-devices will want to utilize ultra-low-power IP-based wireless technology such as Thread.

Thread has the advantage of offering intelligent (auto-reconfiguring) mesh networking and defines low power and sleep modes such that devices can be powered from inexpensive batteries or even energy-harvesting transducers. Power-over-Ethernet (PoE) connectivity can also be used where laying additional cables for mains power would be too expensive.

The mix of connectivity options gives more freedom in the deployment of systems and helps reduce installation and/or reconfiguration cost.

In conclusion, by providing true IoT interoperability and world-class security, OCF allows for the best mix of wired/wireless connectivity solutions to be chosen for the desired application, while enabling automation decisions to be made based on information from multiple domains. Such decision-making can now utilize a mix of local and/or cloud-based computing and analytics (such as Artificial Intelligence) to improve the efficiency with which we use our infrastructure. This allows operators to both cut costs by improving the efficiency with which we use our infrastructure, and to develop new revenue streams through business model innovation and without being hampered by the lead time and development cost of the secure communication framework.