An Introduction to Internet of Things (IoT) and Lifecycle Management – Interoperability Architecture and Standards
When looking from a Systems of Systems perspective, IoT covers many ecosystems and enterprises. In order to develop compatible enterprises and ecosystems that enable Boundaryless Information Flow, an architected approach is required – necessitating the minimum definition of architecture required to support the guidance and standards that follow.
Conceptual Connectivity based on IoT Work Group Standards
There is a huge and continuing growth of instrumented devices for sensing the world around us, attached and connected to many parts of huge ecosystems including not only traditionally acknowledged items like engines, machines, or meters, but now including people and livestock or pets, as well as monitoring sensors that locate and feed back all sorts of information around status and environment. The connected car was once a vision that would enable the sensing of information from a car’s engine to be fed back to the manufacturer in order to predict and prevent any failures through preventative maintenance, but has since then moved on to consolidating that feedback through Closed-Loop PLM to better inform engine design.
However, today as an example the data that is being sensed in cars includes the ability in near real-time to observe weather conditions through the activation of windscreen wipers on multiple vehicles across our road and highway networks. These kind of interconnected ecosystems that IoT would foster are hard to imagine but are increasingly emerging – and demanding common standards and interoperability on an infrastructure that connects these devices, manages the sensor data and the devices themselves, and enables intelligence at the edge and in the data center, as illustrated in Conceptual Connectivity based on IoT Work Group Standards.
The IoT Work Group was formed as a working group under the auspices of The Open Group in 2010, in order to formalize the results of the EU PROMISE Project [7] and convert them to published open standards. In recent years, most other standardization bodies have launched similar initiatives, such as ISO, IEEE, IETF, OMG, etc. Two Open Group IoT standards were published in 2014:
- Open Messaging Interface (O-MI): Specifies simple read, write, and subscription handling operations for any kind of IoT information (in the Systems of Systems sense).
- Open Data Format (O-DF): Generic format for publishing and exchanging any kind of IoT information, independently of the underlying hardware and protocol (e.g., HTTP, TCP, ZigBee, 6loWPAN, 1-wire, KNX, etc.).
Work is now in progress on a specification for Open Lifecycle Management, which will extend O-DF with concepts for representing Closed-Loop PLM-related concepts and semantics. Similar extensions have also been considered for other domains, such as healthcare. Work is also ongoing regarding the use of existing taxonomies, such as those developed by the Open Data Element Framework (O-DEF) project of The Open Group, as well as other technologies for semantic modeling. Finally, business perspectives, ecosystem building, security, and other relevant aspects of the IoT interoperability architecture are considered notably in the context of The Open Group Open Platform 3.0™ Forum.
Open Messaging Interface
The O-MI/O-DF connectivity model is similar to that of the Internet itself. Where the Internet uses the HTTP protocol for transmitting HTML-coded information mainly intended for human users, O-MI is used for transmitting O-DF data structures mainly intended for automated processing by information systems.
The Open Messaging Interface (O-MI) standard [9] provides a flexible interface for making and responding to requests for instance-specific information. A defining characteristic of O-MI is that nodes do not have predefined roles, as it follows a peer-to-peer communications model. This means that products can communicate directly with each other or with back-end servers, but O-MI can also be used for server-to-server information exchange of sensor data, events, and other information. This is one of the features that makes O-MI suitable for Systems of Systems communication, which gives it a much broader area of use than other IoT standards such as MQ Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) which are mainly specified for machine-to-machine communication on resource-constrained embedded devices. O-MI can be used as a standardized REST API to most IoT and/or lifecycle information services, as well as an API for embedded systems, in online and offline applications as well as mobile, wired, wireless, and most other imaginable IoT applications. This is to a great extent because O-MI can use virtually any underlying protocol as transport protocol, including HTTP, HTTPS, SMTP, XMPP, FTP, or even file transfer using removable memories (USB sticks and similar).
O-MI allows one-off or standing information request subscriptions to be made. Subscriptions can be made for receiving updates at regular intervals or on an event basis – when the value or status changes for the information subscribed to. O-MI also supports read and write operations of the value of information items.
Open Data Format
The Open Data Format (O-DF) standard [8] is specified using XML Schema, and is generic enough for representing any object and information that is needed for information exchange in the IoT. It is intentionally defined in a similar way as data structures in object-oriented programming.
O-DF is structured as a hierarchy with an Objects element as its top element. The Objects element can contain any number of Object sub-elements. O-DF Generic Object Tree gives insight into the generic hierarchy/object tree. An example of an O-MI message with O-DF content whose structure relies on that object tree is shown in Generic Object Tree and Example of O-MI write Message with O-DF Payload. In this example, a unique object of type Refrigerator (see row 6 of the message) is considered. Object elements can have any number of properties, referred to as InfoItems, as well as Object sub-elements. In our example, the object Refrigerator has two InfoItems named FridgeTemperatureSetpoint and FreezerTemperatureSetpoint (see row 8 and 11 respectively). The resulting Object tree can contain any number of levels. The most important attribute of an Object is type, which specifies what kind of object it is. Every Object has a compulsory sub-element called id that identifies the Object (see row 7). The id should preferably be globally unique as described in [3], or at least unique for the specific application, domain, or network of the involved organizations. InfoItems can contain the following optional sub-elements:
- Description: Text intended mainly for human user interfaces that explains what the InfoItem is.
- MetaData: Sub-element that provides metadata information about the InfoItem, such as value type, units, and other similar information.
- Value: Arbitrary number of values for the InfoItem, possibly with timestamps.
Even though it is possible to include all these sub-elements in the InfoItem, only one of them is usually included. MetaData is typically requested only once when encountering a previously unknown InfoItem. The MetaData element can contain an arbitrary number of elements. MetaData elements are also of InfoItem type because they are syntactically similar to Object InfoItems, even though MetaData InfoItems are conceptually different from Object InfoItems. The Description element could also be considered as MetaData. However, it has been left as a separate element mainly due to experiences that have shown the utility of including a simple-to-use free-form text element for user interface and debugging purposes. Value elements contain actual data.
Generic Object Tree and Example of O-MI write Message with O-DF Payload
The high flexibility of the Objects tree makes it possible to respect a precise structure or data model defined in an application or by a standard. O-DF defines an extension mechanism that makes it possible to use class inheritance in similar ways as in object-oriented programming. This extension mechanism enables the creation of domain-specific extensions of O-DF, while preserving a basic compatibility between different domain extensions. For the moment, the IoT Work Group is creating one such extension, for Open Lifecycle Management, which provides specifications for representing product lifecycle-related information [6].
In object-oriented programming, objects are aware of each other both by object containment hierarchies and by reference or pointers. In O-DF, such object references are made by using the Object id element. However, in the IoT the id does not refer to a specific memory location but to an IoT object whose information may even be spread over several information systems and organizations. Different methods and systems have been proposed for the discovery of such distributed information; e.g., in [1]. The simplest mechanism is to include a URL in the identifier itself as proposed in [4], and then to retrieve the information by object linking as proposed in [1].
Open Lifecycle Management
The Open Lifecycle Management model was initially conceived as the basis for the information model for the Product Data Knowledge Management/Decision Support System (PDKM/DSS), one of the most important components of the overall PLM system developed by the former EU PROMISE Project [4].
It enabled detailed information about each and every instance of a product to be augmented with field data; i.e., detailed information about the usage and changes to each instance during its life.
It also allowed the aggregation of instance-specific data from many different software systems; e.g., CAD, CRM, and/or SCM and other legacy systems as part of a company’s IT infrastructure in order to allow specific decision support information to be generated and made available through the PDKM system.
The first step undertaken by the PROMISE Project was to analyze the relevant industrial standards in the field of product lifecycle data modeling. This study also provided many useful ideas for the development of the model.
The most relevant standards that were analyzed are:
- Standard for the Exchange of Product Model Data (STEP) (ISO 10303)
- STEP-NC AP238 (ISO 10303-238:2007)
- Product Life Cycle Support (PLCS) AP239 (ISO 10303-239:2005)
- MANDATE (ISO 15531)
- PLM XML
- ANSI/ISA-95 (IEC 62264-1:2013)
These standards have some properties and features in common, but are also distinguishable by many remarkable differences. First of all, they were designed by different organizations, with different scopes and for different targets. STEP, STEP NC, PLCS, and MANDATE can at first sight be grouped together, because they are all ISO (International Organization for Standardization) standards; furthermore, PLCS is an application protocol of STEP.
STEP is an industry standard for product data representation and it is composed of several parts (application protocols) whose aim is to focus on a specific industrial context. There are application protocols for product design, for mechanical and electrical engineering, for sheet-metal manufacturing, for product assembly, for the automotive industry, etc.
PLM XML is an open standard, developed mainly by EDS (Electronic Data Systems Corporation) and later by Siemens PLM Software, dealing with the product design phase.
ISA-95 is an ANSI (American National Standard Institution) standard, except for its first part, ANSI/ISA-95.00.01, which is also an ISO standard (IEC 62264-1:2013). Altogether, ANSI/ISA-95 Parts I, II, and III describe the interfaces and activities between an enterprise’s business systems and its manufacturing control systems: it mainly focuses thus on the area corresponding to the production phase of a product.
Another interesting standard, which is not included in the list given above because it focuses on the exchange of product type lifecycle data, is PLM Services. PLM Services is mainly focused on the design phase. The underlying data model itself is compliant to STEP AP214.
While PLCS does address some areas required by Open Lifecycle Management, a much simpler, more “lightweight” model is required for the majority of application domains. However, interoperability with PLCS and STEP remains an important objective.
Semantic Modeling for Enhancing Information Sharing and Knowledge Extraction
The lifecycle management of products and services is getting more interest nowadays due to the environmental concerns and highly competitive market shares. Recent progress in ICT technologies has enabled many innovative tools, human beings, and infrastructure to connect and work together resulting in highly developed information management.
Closed-Loop PLM addresses the ability of collecting useful product information during its full lifecycle phases for the purpose of re-using such information in developing product qualities and enhancing business opportunities. This issue requires first of all collecting all possible and potentially interesting data about products and services for the whole lifecycle. Afterward, the collected data should be shared and understood interchangeably, from which knowledge can be extracted. Gained knowledge makes it possible to adjust the solution to the varying customer needs, to improve the solution performance, as well as to provide optimization to improve the provider’s business processes. In today’s innovative ICT environments, such an issue requires the open infrastructure including the Internet, cloud computing, and big data, with a view to creating an open ecosystem.
ICT-enabled evolving products, such as connected vehicles (see the Open Platform 3.0™ White Paper, published by The Open Group in May 2014), show other challenges: IoT and various types of sensor data which can be generated from the products themselves as well as each part of the product. Each product and its sub-parts constitute the world of IoT. Services also have a separate lifecycle as in the case of some particular products such as electric vehicles and their batteries. A rich set of IoT data might be available covering the physical product at its instance level providing the availability of a large amount of data.
A strategic approach to manage a product’s MOL is mandatory for the purpose of achieving the overall goal. In the context of IoT Work Group activities, our main interests are:
- To develop a methodological and technical framework of closed-loop lifecycle management for products and services in IoT environments
- To understand the role of semantics in the IoT standards
- To understand and describe the use of the TOGAF® standard in IoT