10
A Systematic Study of Security of Industrial IoT
Ravi Gedam* and Surendra Rahamatkar†
Amity University Chhattisgarh, Raipur, India
Abstract
During the Industry 4.0 era, Internet-of-Things (IoT) played the leading role in the first industrial revolution, comparable to steam energy. IoT offers the possibility to merge the connection between machine-to-machine (M2M) and Realtime manufacturing data collection. The implementation of IoT in the industry therefore improves dynamic optimization, control and decision-making powered by data. Domain suffered, however, due to interoperability problems. In the absence of communication standards, large numbers of IoT devices link to the Internet. The heterogeneity in IoT ranges from high to low (device connectivity, network connectivity, communication protocols) (services, applications, and platforms). In order to understand the interoperability problems and current solutions to help IoT’s smart manufacturing, the project examines the current state of the industrial IoT (IIoT) ecosystem. On the basis of a literary analysis, interoperability problems at IIoT were divided into four levels: technical, syntactic, semanticized and organization. With regard to each interoperability standard, existing interoperability solutions have been grouped and evaluated. In the sense of promoting industrial interoperability, nine reference architectures have been compared. The study identified the patterns and challenges of interoperability research.
Keywords: Industrial IoT, smart manufacturing, Industry 4.0, interoperability
10.1 Introduction
During the last decade, numerous smart physical objects (so called “things”) have been connected and communicate through the internet and form the global network of connected devices called the Internet of Things (IoT). According to Cisco’s forecast, 500 billion devices are expected to be connected to the Internet by 2030 [1]. The smart physical devices usually contain sensors 1that can sense, collect, and communicate data, and/or actuators that can react to internal and external control signals. The features of connected devices enable IoT applications to monitor, aggregate, analyze, deliver business insights, increase efficiency, and provide more informed decisions. The IoT technologies are permeating ubiquitously in a wide range of applications in multiple domains and revolutionizing almost all aspects of society, such as healthcare, agriculture, transportation, weather forecasting, smart home and smart city, etc. For industry, IoT [34, 35] provides the potential to combine machine-to-machine (M2M) interaction, real time data collection, and big data analyzation within the field of manufacturing. This would further enhance dynamic optimization, control, and data-driven decision making [2].
A cyber-physical system (CPS) is a mechanical system where physical components (mechanical systems, electrical systems, human operators, etc.) and cyber components (communication, computation, control, etc.) are deeply intertwined, and different components interact with each other to exchange information [3]. There is tremendous adoption of CPSs in manufacturing industry, occasionally referred to as cyber-physical production system (CPPS). A CPPS usually consists of a physical shop-floor coupled with a digital twin, which uses the monitoring data collected from the shop-floor to build a digital replica as a “twin” of the physical shopfloor. Therefore, CPPS supports more informed decision making by combining the knowledge from both available physical shop floor conditions and big data analysis.
The concepts of IoT and CPS have distinct origins, with IoT mainly emerging from an information and communication technology (ICT) perspective, while CPS has primarily emerged from system engineering and control [4]. Despite their origins from different domains, there are overlaps between the concepts of IoT and CPS, since they both are concerned about connecting & interacting with the physical objects and with digital entities to realize functionality and to enhance performance. The industrial Internet of Things (IIoT) and CPS together are key enablers for accelerating the ongoing digital business transformation in the so called fourth industrial revolution (Industry 4.0) [2]. Figure 10.1 presents a unified perspective of IoT and CPS. The lower half of the figure represents the physical part of the IoT/CPS, which usually includes machinery, equipment, and smart devices. These devices capture the data about the physical state of the engineered system and send it via networks for further use. The upper half of the figure represents the virtual realm of the ICT systems, where the core functionality is communication, computation and control (3C). The data collected from various sources are fused and analysed to support overall decision making. Control decisions can be made, and actuating signals can be sent via networks to actuate effectors on the physical state. In another words, CPS/IoT aims to integrate the physical world with the digital world by using Internet as media to communicate and exchange information.
Figure 10.1 Components model showing a unified perspective of IoT and CPS.
10.2 Overview of Industrial Internet of Things (Smart Manufacturing)
Modern industrial manufacturing has experienced three revolutions so far. Dating back to late 18th century, the use of steam power and waterpower enabled the transition from traditional hand production to mechanized manufacturing factories. The second revolution leads a phase of rapid industrialization in mass manufacturing using assembly lines in early 20th century. The third industrial revolution enables automation and was powered by the development of electronics and information technology in the 1970s. Today’s manufacturing automation systems are mainly shaped during the third industrial revolution. The hierarchical ISA-95 architecture is currently the de facto architectural style for building industrial production and control systems [4]. The automation pyramid of the ISA-95 architecture is illustrated in Figure 10.2. Five layers are defined by ISA-95, from the lowest layer of the actual physical production process to the first layer of status monitoring and data acquisition using sensors/actuators and controlling with programmable logical controller (PLC). The information collected from level 1 goes to the distributed control system (DCS), supervisory control and data acquisition (SCADA) which realize supervisory control of the production process in level 2, and up to third level of manufacturing execution and towards business level resource planning (enterprise resource planning - ERP) in the top level.
In 2011, the Germany federal government first used the term “Industrie 4.0” in a technical strategy to promote the computerization of traditional industries, such as manufacturing. Subsequently, the term “Industry 4.0” is usually used to describe the ongoing fourth industrial revolution. Similar to Germany’s “Industrie 4.0” which promoted the digitalization revolution in Europe, “smart manufacturing” is yet another term with a similar essence. This latter term was introduced by the United States National Institute of Standards and Technology (NIST). Despite the dissimilar terms used by different initiatives from several nations, all the terms have a similar essence of supporting the transition to smart manufacturing and can be all described under the umbrella of the fourth industrial revolution. To simplify the usage of different terminologies, this project uses “Industry 4.0” and “smart manufacturing” to refer to the current worldwide digitalization revolution in manufacturing industry.
Figure 10.2 The traditional automation hierarchy of ISA-95.
Smart manufacturing includes a set of technologies, among which the major components are IoT, CPS, cloud computing, fog computing, and machine learning. As previously mentioned, the technological foundation of smart manufacturing is IoT and CPS, which together aim to integrate the physical world with the digital world by enabling seamlessly information exchange and communication through the network infrastructure. The adoption of IoT and CPS concepts in manufacturing has evolved control systems from their classic centralized hierarchy to a more open decentralized approach with the possibility of information exchange between multiple applications and systems. To present an overview of smart manufacturing, several key terms and enabling technology will be introduced in the following subsection, with more detailed insight about de facto industrial communication standard OPC UA in Section 10.2.2.
10.2.1 Key Enablers in Industry 4.0
Over the last decades, a lot of new terms have emerged within Industry 4.0. As already mentioned in the previous sections, all these paradigms are built around the concept of CPS through digitalization and integration between engineered systems and ICT systems. In this section, some key terms and enabling technology in smart manufacturing are briefly introduced:
Cloud Manufacturing: Cloud manufacturing was first introduced in [34] by Xun Xu. It utilizes cloud computing and shifts the focus from production-oriented manufacturing towards service-oriented manufacturing. Cloud manufacturing can be defined as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable manufacturing resources (e.g., manufacturing software tools, manufacturing equipment, and manufacturing capabilities) that can be rapidly provisioned and released with minimal management effort or service provider interaction”.
Predictive Maintenance: Maintenance of machine components and manufacturing systems are usually based on diagnosis and prognosis. Diagnosis relates to the detection and identification of fault, while prognosis refers to the prediction of possible failures or forecasting of likely outcomes. In the context of manufacturing, prognosis is realized by calculating the remaining useful life (RUL) of machine tools or systems. Predictive maintenance (or condition-based maintenance) refers to maintenance
Process: Process before a detected fault and includes the steps of data acquisition, data processing, and maintenance decision making. Predictive maintenance is enabled by cloud manufacturing and massive data analysis. According to Mourtzis and Vlachou, maintenance accounts for as much as 60 to 70% of a production lifecycle’s total costs. Comparing to traditional periodically performed scheduled maintenance or corrective maintenance after detection of a fault, predictive maintenance significantly increases product quality, system safety, and maintenance efficiency while minimizing machinery downtime and possible loss due to equipment or system failures.
Fog/Edge Computing: To expand the capabilities of cloud computing, fog computing (also known as edge computing) was introduced as a distributed architecture that bridges the connected things to the cloud. Fog computing moves the storage, computation, and networking services from the cloud of the edge of the network. In the context of smart manufacturing, fog computing allows flexibility to be located at different levels. The benefits of adopting fog computing in manufacturing include many aspects. For example, fog nodes support real-time services for latency-sensitive applications by storing data close to the data sources. By storing data locally, fog computing can also enhance security and reduce network loads compared to sending everything directly to the cloud. Fog computing can also enhance data fusion and advanced analytics by sharing computational power at the network’s edge.
10.2.2 OPC Unified Architecture (OPC UA)
Open Platform Communications Unified Architecture (OPC UA) is a data exchange protocol designed for manufacturing and automation communications. It was introduced as a successor of the classic Object Linking and Embedding (OLE) for Process Control (OPC) model, which is a client/server communication model first designed in 1996 by Microsoft as a Microsoft Windows COM/DCOM (Distributed Component Object Model) bounding to standardize communication between software components in industrial environment. The OPC classic specifications, namely OPC Data Access (OPC DA), OPC Alarms &Events (OPC AE), and OPC Historical Data Access (OPC HDA), provide separate definitions for accessing process data, alarms and events, and historical data [5]. IT spread widely in the automation industry through the past decades.
As the technology evolves, the OPC foundation introduced platform independent OPC UA Service-Oriented Architecture (SOA) a decade ago. OPC UA does not rely on Microsoft OLE nor DCOM technology as classic OPC does. Therefore, OPC UA is operating system independent and hardware platform independent. It is designed to be backward compatible with OPC classic specifications yet offers more capabilities.
The OPC UA specifications are layered and independent of the underlying transport protocols and computing technology, which opens the possibilities of mapping to future technologies. Figure 10.3 presents the OPC UA stack. As for transport layer, OPC UA TCP, SOAP/HTTP, OPC UA HTTPS, and Web Sockets are supported for the users to choose from. To provide a secure channel layer, several security protocols can be personalized to secure a communication channel to realize application level security. Three data encodings are defined: OPC UA Binary, OPC UA XML, and OPC UA JSON.
The OPC UA system is based on the client–server architecture. Applications use the OPC UA Client API and/or Server Application Programming Interface (API) to exchange messages. The client/server API handles the request and response messages between the servers and clients. It isolates the OPC UA application code from the underlying communication entity. In the most recent OPC UA specifications, the OPC UA PubSub model has been added – and supports either a broker mode or a brokerless mode in order to support message exchange in several scenarios that do not require the system components to acknowledge each other.
In OPC UA, address space provides a standard way for servers to represent objects to clients. In address space, every entity is represented as a node. OPC UA defines eight non-extensible node classes: Object, Variable, Method, View, ObjectType, VariableType, ReferenceType, and dataType. A node is uniquely identified by a NodeId and is described by a set of attributes and connected to other nodes by references.
Security is a major concern of OPC UA. A suite of controls is provided to address security at different levels. Encryption and OPC UA provides a security model where security settings can be configured by the user to meet different security requirements. Encryption and signatures assure integrity and confidentiality at the transport layer. The security mechanism of the communication layer is to establish a secure channel utilizing X.509 to provide application layer authentication. The application layer manages the authorization and authentication of the servers and clients.
Figure 10.3 OPC UA stack overview.
Figure 10.4 OPC UA information modeling framework.
Another important feature of OPC UA is that it offers an information model to represent structure, behavior, and semantics. The multi-lever information modeling framework of OPC UA is shown in Figure 10.4. The OPC classic specifications can be extended with industry standards. With close collaboration with many standards organizations from different domains (for example, MTconnect, ISA-95, PLCopen, IEC6186, …), the OPC Foundation created different OPC UA information models to support semantic interoperability. The UA information models can also be extended by users to create personalized vendor information models.
10.3 Industrial Reference Architecture
Numerous reference models and architectures have been developed to fulfil the highly dynamic requirements of IIoT. Most reputable ICT vendors have developed their own commercial cloud IoT platforms based on public cloud approach, to name a few: AWS IoT by Amazon, Azure IoT suit by Microsoft, Google Cloud IoT by Google, Prefix IIoT by GE Digital and Watson Internet of Things by IBM.
The following part of this section gives a summary of several popular emerging IoT frameworks for industrial applications. Note that the frameworks are presented in alphabetical order, hence there is no ranking.
10.3.1 Arrowgead
The EU Arrowhead project started in 2013 and recently continued as a part of the ongoing EU project called Productive 4.0. The resulting Arrowhead framework is a SOA based framework for building scalable and interoperable IoTbased automation systems. In Arrowhead, a service can be implemented to use a number of SOA protocols, such as MQTT, CoAP, XMPP and OPC UA.
Arrowhead features a local cloud approach as its key concept to provide core automation services in a protected manner. A minimal local cloud includes three mandatory systems: service registry and discovery system, orchestration system, and authentication and authorization system. These systems enable data exchange between two applications within a local cloud. To serve all the automation demands, simultaneously interactions between multiple clouds are required. The GateKeeper handles the communication between these local clouds. Additional automation systems and services are also available, such as plant description, QoS manager, event handler, and translation.
10.3.2 FIWARE
FIWARE is an open source framework of a set of standards for context data management to support the development of smart solutions beyond IoT use cases. Figure 10.5 shows the principle components of FIWARE. The core feature of FIWARE is the handling and management of context information. The FIWARE Context Broker is the main component used to achieve this feature. Around this broker there is a suit of complementary FIWARE components available.
Figure 10.5 The FIWARE principle components.
Next Generation Services Interface (NGSI) is a standardized API for RESTful interactions between the Context Broker and other components. The NGSI API defines a data model, a context data interface, and a context availability interface. The current specifications of FIWARE reference data models are NGSI-v2 and NGSI-LD. For IoT use cases, FIWARE describe a FIWARE I0T architecture, which consists of the Orion Context Broker (OCB) and IoT Agents. IoT Agents bridge between NGSI and typical IoT protocols, such as HTTP/MQTT, LWM2M, LoRaWAN, and OPC UA. The specifications of the FIWARE APIs and reference implementations of FIWARE components are publicly available for developers to use.
10.3.3 Industrial Internet Reference Architecture (IIRA)
IIRA is an open architecture published by Industrial Internet Consortium (IIC) for IIoT systems regardless of specific their domains. It has four viewpoints: Business, Usage, Functional, and Implementation. Three typical examples of architecture patterns are introduced: three-tier architecture pattern, gateway-mediated edge connectivity and management architecture pattern, and layered databus pattern. However, concrete open source implementations of this architecture are lacking. In their connectivity framework, DDS, OPC UA, MQTT, CoAP, and HTTP are the recommended connectivity standards. Among the standards, OPC UA is regarded as originated from the manufacturing industry while MQTT and CoAP are based on telecommunication vertical. DDS and Web service are regarded as general-purpose; hence, they are usually applied to multiple domains. IIRA addresses interoperability by introducing core gateways to connect the recommended core standards.
10.3.4 Kaa IoT Platform
Kaa is an open source middleware platform based in the US and it is designed for multipurpose enterprise IoT development. The concept of the Kaa platform is to break the features of the platform into different components, or in other words, into a range of microservices that are functionally packaged in Docker images. The flexibility of this microservice architecture helps the Kaa platform support plug and play when implementing different use cases; therefore, reducing development time and cost. The core features of Kaa include device management, communication, data collection, data visualization, and configuration management. Kaa adopts MQTT as its default protocol while also offering possibilities of future CoAP bindings. Kaa currently supports transport using plain MQTT, MQTTS, and MQTT over Websocket.
10.3.5 Open Connectivity Foundation (OCF)
OCF is an American international industry group promoting interoperability for industrial connectivity. The core specification is based on a RESTful architecture and adopts a specific transport protocol suite (CoAP over UDP over IPv6). OCF has a Concise binary object representation (CBOR) based on the JSON data model as the default encoding scheme.
An implementation of the OCF specification called IoTvity and a lightweight version IoTvity Lite are available [6]. The ancestor of IoTivity is another open source software framework called AllJoyn, which was initially designed for industrial lighting and smart homes. Detailed specifications of the OCF core and tutorials about IoTivity tools are available online for developers. With a fixed transport protocol suite and a rather fixed structure, OCF is more of a technical standard for a developer than a general-purpose industrial reference architecture.
10.3.6 Reference Architecture Model Industrie 4.0 (RAMI 4.0)
RAMI 4.0 is an SOA proposed by the German Platform Industrie 4.0 especially for smart manufacturing and CPS. This model consists of a three-dimensional map combining a six-layer architecture (namely asset, integration, communication, information, functional, and business) with the product life circle axis (namely development, maintenance usage, production, and maintenance usage) and the factory hierarchy axis (namely product, field device, control device, station, work centers, enterprise, and connected world).
RAMI 4.0 mainly serves as guidance for entrepreneurial and technical concerns in industry internet. RAMI 4.0 does not propose a detailed technical implementation but rather recommends standards for each layer with a focus on the manufacturing domain. Architecture alignment and cooperation between RAMI 4.0 and other similar frameworks (such as IIRA) are available.
10.3.7 ThingsBoard
ThingsBoard is another open source platform for data collection, processing and visualization for IoT solutions. It enables the developer to customize rich real-time IoT dashboards for data visualization and device remote control. The ThingsBoard Rule Engine allows user to create complex rule chains in order to process data and build event-based workflows that suit different use cases.
ThingsBoard Inc. is a Ukraine-based US corporation founded in 2016. The ThingsBoard IoT platform has gained popularity over the past few years. It supports connectivity via MQTT, CoAP, and HTTP. Integrations with OPC UA server, the SigFox backend, and the LoRaWAN backend are also available to convert payloads into the ThingsBoard format. Devices connecting to AWS IoT broker, IBM Waston IoT broker, and Azure Hub can also be accessed through ThingsBorad. ThingsBorad has been successfully applied in fleet tracking, smart metering, smart farming, and the smart energy domain.
10.3.8 ThingSpeak
ThingSpeak is an IoT analytic platform for data aggregation, data analysis, and data visualization from MathWorks. Its main features are advanced data analysis and visualization directly using MATLAB. ThingSpeak allows devices to update and receive update via MQTT API or REST APIs.
10.3.9 ThingWorx
ThingWorx is an IIoT platform designed by PTC Inc. for rapidly development of IoT solutions with adequate capability and flexibility. The ThingWorx platform offers a complete set of IIoT functionalities including connecting, building, analysis, management, and experience. ThingWorx proposed a data model defining three entities (including Things, Thing Template, and Thing Shapes) and four components (including Properties, Services, Events, and Subscriptions) to describe connected devices.
To connect devices with ThingWorx, the major connectivity methods are a REST API and Edge Micro Server. The ThingWorx Edge Micro Server is available as a binary executable for Linux and Windows. It establishes an always on bidirectional connection with the ThingWorx platform. For IoT devices that cannot run Edge Micro Server, there are MQTT and CoAP protocol adapters to communicate with native protocol devices and ThingsWorx. To integrate with existing infrastructures, ThingWorx offers IoT connectors to connect devices using AWS or Azure cloud. As an industry oriented IIoT platform, ThingWorx offers a suite of 150+ industrial device drivers to connect with multiple types of industrial equipment via Windows clients.
Notably, ThingWorx offers three pre-built manufacturing applications to help improve operational efficiency and productivity. These applications are role-based: Controls Advisor offers seamlessly connectivity with PLCs and assets via the OPC server; Asset Advisor provides real-time monitoring of asset status and health to improve maintenance efficiency; and Operator Advisor helps increase workforce productivity.
10.4 FIWARE Generic Enabler (FIWARE GE)
FIWARE is a project sponsored by the European Commission with ICT industry to accelerate the deployment of smart solutions in various domains as a part of their Future Internet programme.
As mentioned in Section 10.3.2, the core feature of FIWARE is context management. The Context Broker is the core and only mandatory component for developing any “Powered by FIWARE” solutions. Around the core context management, there is a rich suite of complementary FIWARE Generic Enabler (GEs) that can be added to build smart solutions, as shown in Figure 10.5. For example, in the catalogue of context processing, analysis, and visualization using, FIWARE GE Cosmos supports big data context analysis, Kurento supports real-time processing of media streams, Knowage offers business intelligence and data visualization, and FogFlow [8] can be used for building IoT edge computing networks. In the catalogue of context data/API management, publication and monetization, GEs such as Keyrock, Wilma, and AuthZForce PDP/PAP offers add-on security to a smart solution. FIWARE offers interfaces to connect to IoT devices, robotics, and third-party systems to gather context information or trigger actuations. For example, the IDAS GEs offers a wide range of IoT-agents with interfaces to the most used IoT protocols. Fast Real Time Publish-Subscribe (RTPS) is an incubated GE that helps interface with robotic systems.
The following subsections give details about the main components and key concepts of FIWARE GEs.
10.4.1 Core Context Management GE
To support smart solutions, the FIWARE provides means of produce, collect, publish and consume context information. The FIWARE core context management is based on OMA Next Generation Service Interface (OMA NGSI) specifications using NGSI-9 and NGSI-10 interfaces. The NGSI-10 interface is used for exchanging entities and attributes. The NGSI-9 interface is used for exchanging availability information about the entities and attributes.
The context information is characterized by entities with their attributes and the values of the attributes using the FIWARE context data model. FIWARE harmonized data models offer guidelines and predefined data models for several use cases (devices, alerts, point of interests, environment, key performance indicator, etc.). The FIWARE context data model is introduced in Section 10.4.2. Orion Context Broker (OCB) is an open source C++ implementation as part of FIWARE platform. OCB offers management of context information including updates, queries, registration and subscription. The Context Broker holds only the latest value of the entities and attributes. In order to store and get historical context information, other FIWARE GEs like QuantumLeap, Cygnus and Daraco can connect with OCB to generate context history and store historical data.
10.4.2 NGSI Context Data Model
The FIWARE NGSI context data model is defined in NGSIv2 Open API specifications. As summarized in Figure 10.6, NGSI data model consists of three major elements: entity, attribute, and metadata. Entities and attributes in NGSIv2 are represented by JSON Objects. An entity is the core element of NGSI context data model. An entity represents a physical or logical object (e.g., a sensor, a machine, a room, an alarm in a system, etc.). Each entity is uniquely identified by a combination of entity id and entity type. Entity type describes the type of the thing represented by the entity. For example, an entity with id “KistaObserved_001” could be of type “EnviromentObserved”.
Context attributes describe the properties of a context entity. An entity can have multiple attributes. For example, “Temperature” and “Humidity” can be the attributes of the entity “KistaObserved_001”. An attribute is characterized by its name, type, and value. The attribute type is the NGSI value type of the attribute value. NGSI has its own value type system for attribute values, so that NGSI value types are not the same as JSON types. Finally, attribute values contain the actual data of the attributes. Optional metadata can also be added to an attribute value when needed.
Figure 10.6 NGSIv2 data model conceptual diagram.
Context metadata describes the properties of the attribute. The context metadata is characterized by its name, type, and value similar to context attributes. Multiple metadata can be optionally included in the value part of an attribute. For example, the “Temperature” attribute can have “accuracy” and “timestamp” metadata within its value. The metadata type is a NGSI value of the type of the metadata value.
To further support linked context data, an extension of NGSIv2 called NGSI-LD is defined using JSON-LD by ETSI Context Information Management (CIM). It supports more complex context data management by using linked data. The UML representation of NGSIv2 data model is shown in Figure 10.7. A simple mapping script between NGSIv2 and NGSI-LD is offered by FIWARE Community.
The main elements of NGSI-LD are entity, property, and relationship. In the context of traditional NGSIv2, attributes and their value in NGSIv2 can been migrated to properties in NGSI-LD. Relationships establish associations between instances by linked data. The core class is entity. An entity can be the subject of properties and relationships while relationships and properties can be the subject of other relationships and properties (called “relationships-of relationships” or “properties-of-relationships” or “relationships-of-properties” or “properties-of properties”). All elements are identified with an ID and type by using Uniform Resource Identifiers (URIs).
Figure 10.7 UML representation of NGSI-LD information model.
10.4.3 IDAS IoT Agents
As mentioned in the previous section, one big challenge in IoT is to overcome the heterogeneity of devices talking different protocols. Instead of trying to solve the battle of protocols at the device level, FIWARE offers solutions which allow coexistence of standards. The simplest and most common FIWARE IoT use case scenario is represented in Figure 10.8. In this use case, the FIWARE Context Broker manages the context information. Applications and services can reach the Context Broker through its northbound interface using NGSI. On the southside of the Context Broker, different IDAS IoT Agents are connected using NGSI. These IoT Agents allow a group of devices to talk to the Context Broker while using their own native protocols, i.e., an IoT Agent translates an IoT specific protocol into or from the NGSI context information model. Currently, most widely used IoT protocols (such as HTTP, MQTT, and LoRaWAN) have ready to be used official FIWARE IoT agents. For unsupported protocols, costume agents can be built using a FIWARE IoT Agent Node.js module. By mapping different protocols into the NGSI context model, IoT agents offer interoperability without requiring the devices or gateways to support NGSI natively.
Figure 10.8 FIWARE IoT stack (Inspired by FIWARE Tour Guide).
In FIWARE, all IoT end nodes and resources are represented in the end as NGSI context entities and related attributes in the Context Broker. Third party users can access measurement data or send commands to devices via the Context Broker—regardless of the underlying devices or protocols. Figure 10.9 shows a sequence diagram of different interactions between IoT agents and the Context Broker. When a device connects to the IoT Agent, it needs to be provisioned with the IoT agent. The IoT agent will register the device with the Context Broker. Measurements are readings from the sensors that can be grouped into active attributes and lazy attributes. Measurements are sent to the IoT Agent using the devices’ native protocols and pass through the southbound to the Context Broker using the NGSI protocol. The transmission of active attributes is initiated by the device. The active attribute’s value is sent to the IoT Agent and then updated to the Context Broker. Lazy attributes can be accessed by third-party users via a query from the northbound interface of the stack. Commands to actuate devices propagate from the north port of the Context Broker and flow south down to the north port of the IoT Agents using NGSI. Commands are translated to different protocols by IoT Agents and then sent to the device using the device’s native protocols. Once the device performs the command, the device can send an acknowledgement (ACK) to the IoT Agent who will in turn update the device’s status information in the Context Broker. Details of several IoT Agents used in this project will be illustrated in the following subsections.
Figure 10.9 Device to NGSI mapping interactions.
10.4.3.1 IoT Agent-JSON
The IoT Agent for JSON based protocol provides the bridge between the Context Broker NGSI interface and JSON. It acts as a gateway for devise talking the JSON-based protocol (such as MQTT, HTTP and AMQP) and the NGSI Context Broker.
Figure 10.10 MQTT binding interactions of IoT Agent-JSON.
For communication using MQTT protocol, provision of the devices is needed in order to let the IoT Agent know which topic it should subscribe to. Each MQTT topic has the prefix following the form: /<apiKey>/<deviceID>/topicSpecificPart. Where the “apiKey” is an alphanumerical string used to group devices and “deviceID” is the ID identifies the device. The device id and API keys must be provisioned in the IoT Agent before sending any information. The “topicSpecificPart” is used where different topics are used to separate the different types of messages. For instance, MQTT interactions are grouped into three types: measure reporting, configuration retrieval, and commands. The MQTT interactions’ sequence diagram is shown in Figure 10.10.
10.4.3.2 IoT Agent-OPC UA
As introduced in Section 10.2.2, OPC UA is a widely adopted by industry client–server protocol. On the factory floor, an OPC UA server is responsible for gathering data from machinery and making this data available to OPC UA clients. In the case of FIWARE, the IoT Agent-OPC UA acts as an OPC UA client and bridge between the OPC UA server and the Context Broker.
Before the IoT Agent-OPC UA can interact with the OPC UA server, it needs to become aware of the variables and methods that are available at the OPC UA server. Provisioning can be done by retrieving a configuration file via the REST API. The OPC UA variables will be mapped into NGSI active attributes and OPC UA methods will be configured as commands.
10.4.3.3 Context Provider
Apart from storing data in Orion’s internal database, FIWARE context availability management can record entities and attributes sources via registration operation. The registration operation registers the context (entities and attributes) with context provider. A context provider is a URL that identifies the source of context data information. When Orion receives a context query or update with its targeted context unfindable locally. The Orion will look up its registration to check if there are any context providers registered for the targeted element. In other words, context provider should be registered before any context query or update request is made [33].
Figure 10.11 shows the requesting forwarding diagram of context provider. Firstly, the registration is made by a POST operation to /v2/registrations/specifying the context provider’s URL, entity and attribute being provided. Then, the request forwarding is triggered by a GET request from context consumer. The Orion will forward a query via a POST /v2/op/query to the context provider. The context provider will respond the Orion with payload. Lastly, The Orion will forward the response to the context consumer.
Figure 10.11 Request forwarding diagram of context provider.
10.4.4 FIWARE for Smart Industry
With the efforts of FIWARE to breaking up the information silos and simplifying data management, FIWARE’s reference architecture is expected to accelerate the digital transformation of manufacturing industries. Based on the existing industrial reference architectures (such as IIRA and RAMI 4.0), a FIWARE-powered smart industry reference architecture is presented in Figure 10.12.
From a CPS shop floor, IDAS IoT Agents connect to sensors and machinery in the physical world. IoT Agents handle data via multiple IoT and industry protocols (such as MQTT, LwM2M, OPC-UA, oneM2M, etc.). Fast RTPS works as middleware in robot operating systems 2 (ROS2) and offers interface for robotic systems [9]. There are also other incubated system adapters that are under development that can offer additional connectivity alternatives from the physical shop floor to the information cloud. An example of such an alternative is FIROS which works as a translator between ROS and the cloud. It transforms ROS messages into NGSIv2 and vice versa [11].
The FIWARE OCB integrates the data coming from machinery, sensors, robotic systems, coordinate-measurement machine (CMM) systems with management information from information systems; therefore, breaking the previous information silos. Historical data can be processed using processing engines (such as Flink, Hadoop, or Spark) and be fed to advanced AI, big data analysis, and complex event processing services to deliver more valuable insights. Knowage enables KPI monitoring and other business intelligence functions. Operational dashboards can be created using FIWARE GE WireCloud mashup platform. A FIWARE OCB can also integrate with another OCB or connect to third organizations’ applications. To address security, access control ensures that the context data are only accessible by authorized parties. API management and business support frameworks audit the system.
Figure 10.12 A reference architecture for smart industry powered by FIWARE.
10.5 Discussion
Previous work related to the project includes surveys focusing on interoperability and on IoT reference architectures. Interoperability solutions adopting FIWARE and IoT interoperability testing are also related to the topic area of this work.
A number of surveys of IIoT related standards and frameworks have been published. For example, Kuila et al. studied several popular and commercially used IoT frameworks and platforms. In 2015, Derhamy et al. surveyed 17 commercial IoT frameworks and compared them in terms of their architectural approaches and supporting protocols. A more in-depth survey of eight IoT frameworks by major players was presented by Ammar, with the emphasis on the security mechanisms employed. Reference architectures for interoperable manufacturing are discussed in [10], with a focus on interoperability challenges in smart factories. Fahmideh and Zowghi presented a detailed analysis on 63 IoT approaches using a proposed evaluation framework, in which the characteristic like context, lifecycle coverage, roles and modeling are addressed. To present relations among different frameworks, a visual methodology to structure, align and compare existing reference architectures in IIoT domain is introduced in [7]. This work presents a configurable visual view showing the relations and characteristics between the surveyed reference frameworks.
The following subsections introduce related work in industrial solutions that have been adopted by FIWARE and are suitable for IoT interoperability testing.
10.5.1 Solutions Adopting FIWARE
This subsection presents four related industrial solutions that have adopted FIWARE GE, with two solutions in the manufacturing domain, one in the agriculture domain, and the last one related to cross-domain interoperability.
MASAI is a middleware designed to support IoT data collection and pre-filtering in manufacturing environment. The approach is presented using FIWARE IoT Hub. The solution consists of two main components: FIWARE IoT hub and IoT gateway. Factory floor devices integrated with the IoT hub through an IoT gateway using MQTT. The data coming from the devices is then filtered and streamed to a cloud platform called Cloud Collaborative Manufacturing Networks (C2NET) using WebSocket. A use case with MASAI deployment is conducted in a laboratory with an assembly line. The case study verified the proposed approach enables the collection and monitoring of the factory floor data streams from the cloud platform. According to the roadmap on MASAI’s factsheet, more manufacturing-oriented protocols (such as OPC UA) are being added to the MASAI.
Alonso et al. present an implementation of the Industrial Data Space (IDS) Association Reference Architecture using the FIWARE GE. The core component of the proposed solution is an IDS Connecter, which is implemented by a conjunction of OPC UA IoT Agents and FIWARE OCB. The OPC UA IoT Agents map between the objects from the OPC UA servers on the shop floor and the domain specific data model defined by NGSI. A zero-defect manufacturing use case is deployed for analysis and the required data is retrieved from the milling machines and CMMs. The results showed improvements via a quality control service on produced objects, and a predictive maintenance system on the milling machine. The olution ensures confidentiality and authenticity of the exchanged data by using encryption, identity management, and access control.
To explore the challenges in IoT enabled precision agriculture, Martinez et al. designed a FIWARE-based farm management system as a use case scenario. A comprehensive testbed was implemented to test the performance of the FIWARE platform in the context of supporting background agriculture applications. The testbed represents the most important part of the use case, with virtual IoT nodes acting as context generating nodes, FIWARE OCB and Cygnus acting as the IoT middleware connecting to the Cosmos big data analysis, and a sample application querying context from Cosmos. Latency and throughput of Orion were evaluated and showed positive result of FIWARE supporting scalability in agriculture domain.
In supporting decision making, a platform for early wildfire detection was designed by Kalatzis et al. It realizes cross-domain and cross-platform organizational interoperability by utilizing data from various different sources (such as sensors, cameras, weather forecasts, and twitter). It introduces an interoperability IoT2Edge agent between the underlying platforms and server. The IoT2Edge agent translates the data derived from different platforms into a NGSI-LD context information model. Next the NGSI-LD data is sent to the server through an NGSI API and stored in the IoT2Edge server. The IoT2Edge server mainly consists of FIWARE OCB, FIWARE Cygnus, and decision-making algorithms. Intelligent decision making to estimate the wildfire’s danger level is based on the semantic reasoning over the collected data. The system succeeded in detecting an actual wildfire incident in Greece (on 23 July 2018).
10.5.2 IoT Interoperability Testing
Testing and evaluation of IoT systems has always been a challenge. Among the testing efforts in IoT domain, the following works were identified to be most relevant to address IoT interoperability.
ETSI has conducted a series of plug test events to validate standards in IoT domains. According to the ETSI specification, interoperability testing aims to prove the end-to-end functionality of at least two communicating systems. The testing method is referred to as passive interoperability testing, which means only observing the behavior of the system under test at the interface that offer only normal user control. Datta et al. proposed an approach for semantic interoperability testing between IoT systems. In their study, two scenarios regarding semantic interoperability testing are defined: interoperability tests between two systems and interoperability tests at data level.
With regard to testing a specific IoT platform—such as FIWARE, the performance of FIWARE has been tested using functional testing and stress testing during its quality assurance activities. Aaujo et al. evaluated performance of FIWARE deployment considering vertical and horizontal scalability. A conformance testing of FIWARE was conducted by Ahmad et al. who adopted model-based testing in IoT systems.
While the ETSI approach in interoperability testing can be used to validate the interoperability of protocols and standards, when testing IoT platforms and middleware, efforts have mainly focused on functional and performance testing, with a few tests addressing interoperability.
10.6 Conclusion
Regarding the incompatibility issues in IIoT, interoperability can be classified into technical, syntactical, semantic, and organizational levels. There have been many efforts and attempts realize greater interoperability by pursuing standardization of technologies, using gateways or middleware, adopting semantic web technologies, developing compatible platforms, etc. We studied nine industrial frameworks as a sample of the current IIoT ecosystems. Among these nine frameworks we found that most IoT platforms address interoperability by adding support for more communication technologies and protocols. Some platforms (such as ThingWorx and FIWARE) define data models to support semantic interoperability. Most platforms are domain-based with only a few pursuing cross-domains organizational interoperability. The IoT domain and industrial domain are still mostly isolated. The conclusion is that we are still at an early stage of IIoT interoperability; therefore, it is vital for standardization organizations and major industrial players to work together to increase the interoperability of existing solutions rather than proposing numerous new (isolated) platforms. Additionally, it is important for developers to take interoperability into consideration when developing IIoT applications.
Based on the knowledge gained from the solutions that have been studied during this project, FIWARE was identified as a potential platform to support IIoT interoperability. In the specific scenario used for our case study, the FIWARE OCB offers core context management for the proposed smart factory scenario while FIWARE IoT Agents serve as interoperability providers for IoT devices. The MQTT and OPC UA protocols were chosen and tested as representatives of the IoT domain and the industrial domain. IoT Agent JSON and IoT Agent OPC UA map MQTT messages and OPC UA messages into the NGSI v2 data model and interact with the OCB.
Among our proposed nine key scenarios for testing interoperability of FIWARE GEs, our testbed meets the requirements in eight out of these nine key scenarios. The results show that FIWARE GEs have the potential to support interoperability for Industry 4.0.
References
1. Raptis, T.P., Passarella, A., Conti, M.J.I.A., Data Management in Industry 4.0: State of the Art and Open Challenges. IEEE Access, 7, 97052–97093, 2019.
2. Zhong, R.Y., Xu, X., Klotz, E., Newman, S.T., Intelligent Manufacturing in the Context of Industry 4.0: A Review. Engineering, 3, 5, 616–630, 10/01/2017. https://doi.org/10.1016/J.ENG.2017.05.015.
3. Greer, C., Burns, M.J., Wollman, D.A., Griffor, E.R., Cyber-physical systems and Internet of Things, Special Publication (NIST SP)—1900-202, 2019. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1900-202.pdf
4. Yaqoob, I. et al., Internet of Things Architecture: Recent Advances, Taxonomy, Requirements, and Open Challenges. IEEE Wirel. Commun., 24, 3, 10–16, 2017.
5. Noura, M., Atiquzzaman, M., Gaedke, M.J., Interoperability in Internet of Things: Taxonomies and Open Challenges. Mob. Netw. Appl., 24, 3, 796–809, June 01, 2019.
6. Lelli, F., Interoperability of the Time of Industry 4.0 and the Internet of Things. Future Internet, 11, 2, 36, 2019.
7. Derhamy, H., Rönnholm, J., Delsing, J., Eliasson, J., Deventer, J.V., Protocol interoperability of OPC UA in service-oriented architectures, in: 2017 IEEE 15th International Conference on Industrial Informatics (INDIN), pp. 44–50, 24–26 July 2017.
8. Han, B., Cao, X., Shi, H., Modeling the throughput of IEEE 802.15.4 based wireless networks under interference, in: 2017 32nd Youth Academic Annual Conference of Chinese Association of Automation (YAC), pp. 1014–1019, 19–21 May 2017.
9. IEEE Standard for Low-Rate Wireless Networks. IEEE Std 802.15.4-2015 (Revision of IEEE Std 802.15.4-2011), pp. 1–709, Apr. 2016. http://www.jatit.org/volumes/Vol99No15/13Vol99No15.pdf
10. Kim, S.H., Chong, P.K., Kim, T., Performance Study of Routing Protocols in ZigBee Wireless Mesh Networks. 95, 2, 1829–1853, July 01 2017.
11. Radmand, P., Talevski, A., Petersen, S., Carlsen, S., Comparison of industrial WSN standards, in: 4th IEEE International Conference on Digital Ecosystems and Technologies, pp. 632–637, 13–16 April 2010.
12. Adame, T., Bel, A., Bellalta, B., Barcelo, J., Gonzalez, J., Oliver, M., Capacity Analysis of IEEE 802.11ah WLANs for M2M Communications, in: Multiple Access Communications, pp. 139–155, Springer International Publishing, Cham, 2013.
13. Gomez, C., Oller, J., Paradells, J., Overview and Evaluation of Bluetooth Low Energy: An Emerging Low-Power Wireless Technology. Sensors (Basel), 12, 9, 11734–11753, 2012.
14. Rama, Y. and Özpmar, M.A., A Comparison of Long-Range Licensed and Unlicensed LPWAN Technologies According to Their Geolocation Services and Commercial Opportunities, in: 2018 18th Mediterranean Microwave Symposium (MMS), pp. 398–403, 31 Oct.–2 Nov. 2018.
15. Deering, S. and Hinden, R., RFC 2460: Internet protocol, version 6 (IPv6) specification, December, 1998. https://datatracker.ietf.org/doc/html/rfc2460
16. MQTT Version 5.0., Edited by Andrew Banks, Ed Briggs, Ken Borgendale, and Rahul Gupta. 25 December 2017. OASIS Committee Specification 01. http://docs.oasisopen.org/mqtt/mqtt/v5.0/cs01/mqtt-v5.0-cs01.html. Latest version: http://docs.oasisopen.org/mqtt/mqtt/v5.0/mqtt-v5.0.html.
17. Shelby, Z., Hartke, K., Bormann, C., The Constrained Application Protocol (CoAP), Internet Request for Comments, vol. RFC 7252, Jun. 2014. https://www.scirp.org/(S(351jmbntvnsjt1aadkposzje))/reference/ReferencesPapers.aspx?ReferenceID=1598461
18. Saint-Andre, P., Extensible Messaging and Presence Protocol (XMPP): Core, Internet Request for Comments, vol. RFC 6120, Mar. 2011.
19. Winter, E.T. et al., RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, Internet Request for Comments, vol. RFC 6550, Mar. 2012. https://www.rfc-editor.org/info/rfc6550
20. Hartig, O. and Pérez, J., Semantics and complexity of GraphQL, in: Proceedings of the 2018 World Wide Web Conference, pp. 1155–1164, 2018.
21. Monostori, L. et al., Cyber-physical systems in manufacturing. CIRP Ann., 65, 2, 621–641, 01/01/2016. 2016. https://doi.org/10.1016/j.cirp.2016.06.005.
22. Xu, X., From cloud computing to cloud manufacturing. Robot. Comput. Integr. Manuf., 28, 1, 75–86, 02/01/2012. https://doi.org/10.1016/j.rcim.2011.07.002.
23. Gao, R. et al., Cloud-enabled prognosis for manufacturing. CIRP Ann., 64, 2, 749–772, 01/01/2015 2015. https://doi.org/10.1016/j.cirp.2015.05.011.
24. Schmidt, B. and Wang, L., Cloud-enhanced predictive maintenance. Int. J. Adv. Manuf. Technol., 99, 1, 513, 10/01/2018.
25. Mourtzis, D. and Vlachou, E., A cloud-based cyber-physical system for adaptive shop floor scheduling and condition-based maintenance. J. Manuf. Syst., vol, 179–198, 04/01/2018. 2018. https://doi.org/10.1016/j.jmsy.2018.05.008.
26. Chen, B., Wan, J., Celesti, A., Li, D., Abbas, H., Zhang, Q., Edge Computing in IoT Based Manufacturing. IEEE Commun. Mag., 56, 9, 103–109, 2018.
27. Fonseca, J.M.C., Marquez, F.G., Jacobs, T. (Eds.), FIWARE-NGSI v2 Specification, (accessed Sep. 9, 2019). http://fiware-ges.github.io/orion/api/v2/stable/
28. Context Information Management (CIM); NGSI-LD API. 2001. Retrieved 11 February 2022, from https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v 010101p.pdf.
29. KAA-Enterprise IoT Platform for Exceptional Cloud Experience, https://www.kaaproject.org/ (accessed Jun. 15, 2019). https://kaaproject.github.io/
30. Schweichhart, K., Reference architectural model Industrie 4.0 (rami 4.0), An introduction, vol. 40, 2016, [Online]. Available: https://www.plattform-i40.de, https://ec.europa.eu/futurium/en/system/files/ged/a2-schweichhartreference_architectural_model_industrie_4.0_rami_4.0.pdf
31. ThingsBoard Open-source IoT Platform, thingsboard.io (accessed Jul. 15, 2019). https://thingsboard.io/
32. ThingSpeak for IoT Projects, thingspeak.com (accessed Jul. 15, 2020). https://thingsboard.io/
33. P.E.I. Solutions, Platform technology: ThingWorx, https://www.thingworx.com/ (accessed Jul. 13, 2019). https://developer.thingworx.com/en
34. Jha, S., Kumar, R., Chatterjee, J.M., Khari, M., Collaborative handshaking approaches between internet of computing and internet of things towards a smart world: A review from 2009–2017. Telecommun. Syst., 70, 4, 617–634, 2019.
35. Yadav, M. and Chatterjee, J.M., Study of Privacy Issues in Internet of Things. Global J. Appl. Data Sci. Internet Things, 2, 2, 31–40, 2018.
- *Corresponding author: [email protected]
- †Corresponding author: [email protected]