Conserve It Chief Software Architect, Richard McElhinney serves as Vice President on the Project Haystack Board of Directors. McElhinney recently contributed to Haystack Connections Magazine, where he discusses the Real IIoT and its application to Project Haystack and Niagara.
“The adoption of newer technologies that have entered our Buildings IoT (BIoT) sector is not a unique occurrence. The Industrial sector has also been adopting IoT technologies, frameworks and mindsets for some time now as well and modern Supervisory Control and Data Acquisition (SCADA) systems. The IIoT is akin to our BMS/BAS installations and can leverage much of the work we’ve done on open protocols and standards in the IoT space.”
What is “real IIoT”?
IoT is an acronym that has become a standard part of our vernacular in the Building Automation industry. Indeed, this acronym has permeated many industries and often a prefix adorns the original acronym in an effort to identify the scope of reference when saying “IoT”. The adoption of newer technologies that have entered our Buildings IoT (BIoT) sector is not a unique occurrence. The Industrial sector has also been adopting IoT technologies, frameworks and mindsets for some time now as well and modern Supervisory Control and Data Acquisition (SCADA) systems. The IIoT is akin to our BMS/BAS installations and can leverage much of the work we’ve done on open protocols and standards in the IoT space. So, what exactly am I referring to when I talk about the “real IIoT”?
I view Industrial IoT (IIoT) spaces as involving the following types of industries:
Manufacturing
Food and beverage production
Utilities (electricity, water and gas) generation, distribution and management
Oil and gas production
Transportation
Mining
One of the unifying artifacts in the application of control systems in these industries is the use of SCADA systems. Even though it may be an over-simplification, a SCADA system is synonymous with a BAS in our world and it is on this part of the IoT technology space I would like to focus on in this article.
Brief Anatomy of a SCADA System
Ironically, when looking at what a SCADA system is, it is easy to recognise components in a SCADA system that a BAS would have.
Also somewhat ironically, SCADA systems have developed, in the architectural sense, in a similar way to the BAS world. The SCADA community has had a similar journey from centralised to distributed control systems, proprietary versus open protocols, vendor lock-in and now the advent of IoT technologies and architectures. These are all familiar discussions to those who have worked in the BAS market for a while. However, what is interesting is that when examining recent advancements in the IIoT space industrial control and automation systems seem to be moving ahead and adopting modern IoT architectures. They are also developing these approaches in an arguably more progressive fashion than that of the BAS market.
MQTT
Message Queue Telemetry Transport (MQTT) has established itself as one of the key components of many IoT systems. With its focus on reliable messaging, simplicity and scalability it is uniquely suited to address many of the challenges of IoT solutions. One problem remains with MQTT that has not been solved since its initial invention. In the BAS world many organizations, including Project Haystack, have gone to incredible lengths to not only define the protocols by which data is transferred but also the contents (payloads) of the messages. Whether it be sensor types, device profiles or more we are, in many ways, fortunate to have technologies at our disposal that ease the deployment of systems. Yet MQTT does not define the contents of a message. MQTT is purely a transport layer protocol and it does not care what the contents of each message are. There is a remarkable closeness in this property of MQTT with other web standards and technologies. For example, Hypertext Transport Protocol (HTTP), the protocol that transfers web pages from a server to our browser, has this same property. HTTP does not know or care of its payloads when transporting messages from client to server and back again.
The fact that MQTT doesn’t define a standard for its payloads is both a feature and a hindrance to its use. The lack of definition offers flexibility and the opportunity for many different applications to use a standardized transport protocol for messaging. On the other hand, the lack of definition for payloads creates problems for multi-vendor integrations. Project Haystack by default offers the possibility for standardizing the payloads for MQTT messaging by using one of the already available encoding schemes for tags, such as ZINC or the Project Haystack JSON encoding definition but the use of ZINC or JSON can be problematic for highly distributed IIoT applications where connectivity might be over low bandwidth technology and very expensive. In this case it is important to reduce the payload size through the use of binary encoding with a well-defined and standard format. This is the space the SparkplugB standard occupies and it is particularly suited to solving the problem of MQTT not having a standard payload definition as well as keeping payloads compact through the use of a binary encoding.
SparkplugB
SparkplugB is an application layer specification for the standardization of the MQTT topic namespace, device state management, and the MQTT payload. Originally developed by Cirrus Link founder Arlen Nipper (also one of the original authors of MQTT) SparkplugB is now an official project being guided by a group of companies under the umbrella of the Eclipse Foundation IoT project and is under active development for organizations to adopt. The key feature of interest to Project Haystack is the standardized payload definition. The topic namespace and device state management are also very useful but in the context of transporting Haystack tags it is the payload that is most useful. The SparkplugB standard defines a binary encoding using Google Protobufs (https://developers.google.com/protocol-buffers). Protobufs allow developers to define a message format through a simple declarative syntax and then have those message definitions compiled into source code that can be used by an application to generate messages. Protobufs supports the compilation of message definitions into a number of popular programming languages. SparkplugB uses Protobufs to define a standard binary encoding of messages that will be transported over MQTT. The messages have a number of attributes that allow the publication of things that we might be interested in.
Each Sparkplug message contains a Payload. Each Payload can contain one or more Metrics, a Metric being a value or piece of information being published. A Metric could be synonymous with a Control Point in Niagara for those familiar with that system and like a Niagara Control Point a Metric can be one of a number of different types. In fact, the Sparkplug standard defines around 20 different data types. A Metric is quite useful, but the real magic comes when diving further into the structure of a SparkplugB Payload containing one or more Metrics. The most useful aspect of a Metric is the possibility of adding a set of properties to a Metric, suitably named a PropertySet. In SparkplugB a PropertySet is a list of key/value pairs, a concept that Project Haystack practitioners are highly familiar with.
By using the SparkplugB standard, it is now possible to encode and decode Project Haystack tags for a particular data point (or Metric) and send them over MQTT in a well-defined way with open-source libraries in well-known programming languages such as Java, Javascript, C and Python.
Sparkplug for Niagara
Through recent work with partners in the electricity sector, to enable Demand Response for better electricity grid management, Conserve It has developed a Niagara 4 integration module that allows System Integrators to connect in Niagara Control Points to a Sparkplug Service and in turn this data can be published over MQTT using the SparkplugB standard. This new integration not only transmits the raw Niagara Control Point “value” it also collects any extra attributes about the point. Implied tags are collected as are tags explicitly added by a System Integrator. These are then automatically included in the Sparkplug Payload under each individual Metric enabling the tags on each Control Point to be transmitted, using a standard binary encoding, over MQTT.
By developing this integration in Niagara 4 new applications can be opened up to integrate data in a meaningful way in other markets or a simpler method of integrating distributed buildings can be established by using MQTT. There are further advantages of using this methodology. Inherently, MQTT is a “push” protocol. This means that it only requires an outbound internet connection and there is no requirement to open up an inbound TCP port through a firewall or router. Also, by including the tags configured on a Control Point in each SparkplugB Payload, any changes to the tags will be automatically pushed up to the MQTT broker and can be consumed by any application subscribing to the messages coming from Niagara.
Cloud Reference Architecture for Project Haystack
The Project Haystack community has put an incredible amount of work into the open-source project as it stands today. Semantic models and tags exist for a variety of systems and equipment, a well-defined REST API for transferring data between Haystack compliant systems, open-source software implementations in multiple programming languages and a number of products are on the market today that use Project Haystack technology. One area the community is yet to focus on is the best way to implement a cloud solution for Project Haystack systems. Whilst in some ways doing this is the “secret sauce” many in our community bring to their clients, it is difficult for those new to our community to get started and run up an end-to-end system. Cloud technologies now exist that make the testing and development of these
solutions much easier and, by providing something back to the community to enable a quick startup in our space and demonstrate an end-to-end solution, we enable more solutions and greater adoption of Project Haystack.
Project Haystack has always been an open, extensible system of conveying semantic models and metadata. It has found popularity and significant application in the Building Management and Automation markets, but this doesn’t mean it cannot be promoted and used to deliver new and exciting applications in other industries. By
leveraging and combining 3 significant open standards (Project Haystack, SparkplugB and MQTT) scalable and reliable infrastructure can be enabled to manage the large amounts of data coming from all types of facilities, not just buildings. Furthermore, by delivering a reference implementation for cloud-based solutions our community can further our goals of an open and interoperable world where data can be exchanged and managed, and value delivered back to our clients. Shortly I will be announcing a new open-source project that will be available for our community to use and to contribute to based on using Project Haystack, MQTT and SparkplugB for the implementation of device-to-cloud solutions.