A Reference Architecture for the IIoT
Posted by: Varun Nagaraj | Posted on: Wednesday, July 1, 2015
This month, let’s take a break from our obsession about business models, and focus on technology instead. Perhaps some of you have heard about and are actively following the Industrial Internet Consortium. The organization was founded in March 2014 to bring together the organizations and technologies necessary to accelerate growth of the Industrial Internet by identifying, assembling and promoting best practices.
A few weeks ago, the consortium published the first version of the “Industrial Internet Reference Architecture Technical Report” to drive interoperability and to simplify development of Industrial Internet Systems (IIS). The consortium believes that traditional industrial and commercial control systems will be brought online, connecting them with people, and fully integrating them with processes, enterprise IT systems, and data analytics solutions. The data generated by sensors and human-machine interaction will be combined with other organizational or public information (think about outside temperature and humidity information from weather.com for example) to yield more significant insights. We couldn’t agree more.
The report outlines an “implementation viewpoint” or a generally applicable view (but allowing for use case specific variations) of the components required to put a solution together along with the distribution and interplay between the various components. I encourage you to turn to Page 36 of this report and read the excellent description. To whet your appetite, let me liberally borrow from the original text and summarize the key points.
IIS implementations will generally display the following architectural patterns:
- A three-tier architecture consisting of the Edge, Platform, and Enterprise Tiers.
- Three networks: Proximity network (for devices within the Edge tier), Access network (to connect the Edge tier to the Platform tier), and Service network (to connect the Platform tier to the Enterprise tier).
- Edge Gateways as a core component of the Edge tier, pulling together all the devices in the proximity, providing data aggregation and management services.
- The Platform tier as the long-term repository of structured and unstructured field data. You could think of this as a local server implementation or a cloud-based implementation.
- The Enterprise tier that implements the domain specific application functionality, acting not only upon the field data from the Platform Tier, but also interfacing with other data elements and systems that make up the IIS.
These architectural guidelines are consistent with our practical experience.
In our FieldServer Protocol Gateway business, we are actively looking to offer our OEM customers (the device makers), not just the gateway to connect devices, but an integrated platform and application tier with value-added applications. We are looking at implementations where all three tiers could be resident on the gateway, or could be distributed between the gateway and the cloud. But in all cases, we recognize that the implementation must be “open” enough to incorporate best-of-breed technology from other vendors.
In our Sentry IT Fire and Gas Solutions business, we are eating our own cooking – adding the gateway, platform, and application tiers to the Sentry IT Controller (the Sentry Controller is a specialized PLC for fire and gas). Here too, we recognize that some of our customers (safety managers at facilities with a higher-than-normal risk of gas and fire) might prefer to keep all elements of the 3 tier architecture local (on-premise), while some will be enterprising enough to leverage the cloud for some of the tiers.
Hopefully, the consortium’s report will provide end customers with a common vocabulary as they discuss technology with vendors pushing their latest wares. Clarity on technology will allow the extended community to get back to the more vexing issue of business models! More on that next month.