Reference Architectures and Open Group Standards for the Internet of Things – Four Internet of Things Reference Architectures

 

The London Workshop included presentations of four emerging standard reference architectures: the Draft ISO IoT Reference Architecture, the IIC Industrial Internet Reference Architecture (IIRA), the Reference Architecture Model for Industry 4.0 (RAMI 4.0), and the Web of Things. This chapter contains a comparison of them. The comparison represents the views of the author of this White Paper. It does not necessarily represent the views of any of the organizations responsible for the materials that are compared. Nor does it necessarily represent the consensus of The Open Group, or of the Open Platform 3.0 Forum.

Note that the diagrams in this chapter present ideas from the reference architectures that are compared, but are not copies of diagrams from those reference architectures. They use the ArchiMate modeling language as a common graphical language, to facilitate comparison between architecture descriptions that use different diagrammatic notations.

The Four Reference Architectures

This section introduces the four architectures that are compared. They are described in more detail in later sections of this chapter.

Draft ISO IoT RA

The Draft ISO IoT RA covers the IoT in general. It defines system characteristics, a conceptual model, a reference model, and architecture views for the IoT.

It is being developed by Work Group 10 of the Joint Technical Committee 1 of the International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC JTC1 WG10).

If and when it becomes an International Standard, it will be an authoritative reference for terminology and concepts for the IoT.

The analysis of characteristics covers, at the time of writing, 33 characteristics in nine groups. Examples are Auto Configuration (in the System Characteristics group), Integrity (in the Security group), and Consumer Protection (in the Other Characteristics group).

The conceptual model contains (at the time of writing) an overall model for IoT concepts (the big picture) plus five important IoT concepts: Domains concept, Identity concept, Service and Communication concept, IoT-User concept, and IoT Device concept.

There is an Entity-based Reference Model, and a Domain-based Reference Model. The Entity-based Reference Model shows how users, systems, networks, gateways, devices, and physical entities relate to each other. The Domain-based Reference Model shows the relations between the User, Operations and Management, Application Service, IoT Resource and Interchange, Sensing and Control, and Physical Entity domains.

As described in the Viewpoints Comparison, the Draft ISO IoT RA has Usage, Functional, Information, System, and Communication views.

IIC Industrial Internet Reference Architecture (IIRA)

The IIRA defines the Industrial Internet as “an internet of things, machines, computers, and people, enabling intelligent industrial operations using advanced data analytics for transformational business outcomes”, and states that “it embodies the convergence of the global industrial ecosystem, advanced computing and manufacturing, pervasive sensing, and ubiquitous network connectivity”.

It assumes a definition of “Internet of Things” that is similar to the ISO definition, and focuses on industrial applications.

The IIRA was published in June 2015. It is a concise and comprehensive description of the end-to-end IoT architecture for the Industrial Internet industry space. It provides a definition of constituent components and interfaces, with functional requirements and implementation technologies. It was inspired and validated by core use-cases, and has been implemented and tested in an IIC test bed.

Delivery and assurance of key end-to-end system characteristics – safety, security, trust, privacy, and resilience in particular – is a major focus of the IIRA.

The IIRA Technical Report has two parts. The first part describes the several viewpoints and the various functional domains needed to evaluate Industrial Internet Systems. These viewpoints are discussed in the Viewpoints Comparison of this White Paper. The second part contains an analysis of key system concerns, including delivery and assurance of the key system characteristics.

The key system concerns described in the second part of the report are:

  • Safety
  • Security, Trust, and Privacy
  • Resilience
  • Integrability, Interoperability, and Composability
  • Connectivity
  • Data Management
  • Analytics
  • Intelligent and Resilient Control
  • Dynamic Composability and Automatic Integration

RAMI 4.0

The Reference Architecture Model for Industry 4.0 (RAMI 4.0) focuses on the IoT and cyber-physical systems in the industrial manufacturing domain.

Platform Industrie 4.0 considers that we are currently undergoing the fourth industrial revolution, and that it is based on the IoT and cyber-physical systems. The focus is on industrial applications, on the use of computerized tooling, and on the implications of this.

RAMI 4.0 is a reference architectural model for this fourth industrial revolution. It is a three-dimensional matrix that can be used to position standards and describe use-cases. It addresses integration within and between factories, end-to-end engineering, and human value-stream orchestration.

The German national academy of science and engineering (ACATEC) delivered a study on Platform Industrie 4.0 in April 2013. The Platform Industrie 4.0 organization was then launched to manage implementation. There are some reference implementations, and there has been industry take-up.

There are similar initiatives in China and the USA.

No full English translation of the ACATEC study appears to be available at the time of writing. The Zvei RAMI 4.0 Status Report does, however, contain a summary of the RAMI 4.0 architecture in English.

RAMI 4.0 has two horizontal dimensions and a vertical dimension.

The horizontal dimensions are:

  • Life Cycle and Value Stream
  • Hierarchy

The vertical dimension has six layers:

  • Business
  • Functional
  • Information
  • Communication
  • Integration
  • Asset

The layers of the vertical dimensional, and the two horizontal dimensions, are discussed as viewpoints in the Viewpoints Comparison of this White Paper.

Web of Things

W3C explains its Web of Things activities in the following way (W3C Web of Things website, 2016): “The Internet of Things (IoT) suffers from a lack of interoperability across platforms. As a result, developers are faced with data silos, high costs, and limited market potential. This can be likened to the situation before the Internet when there were competing non-interoperable networking technologies. The Internet makes it easy to develop networked applications independently of those technologies. W3C is seeking to do the same for the Internet of Things.

Here, the Internet is seen as a model, rather than as an essential component (though in practice it usually is also an essential component). The focus is on interoperability in general, rather than on any particular application area.

The Web of Things defines an interoperability layer for the IoT that can be used across different platforms and standards. It is analogous to the relationship between the Internet and the underlying network technologies. The Internet defines an abstraction layer with IP addresses and packets, along with the socket API that is independent of those technologies. The Web of Things likewise simplifies application development and delegates the burden of platform interoperability to platform developers, based upon the extensive use of metadata. The Web of Things uses the Resource Description Framework (RDF) as the interlingua for metadata, and supports discovery, service composition, and validation based upon semantic models of services.

The Web of Things is a community initiative supported by W3C. It provides a framework for interoperability between IoT systems, based on inter-platform standards, using the concepts of the World-Wide Web. There is an unofficial draft architecture, as of September 2016, but it is not yet formally documented as a reference architecture.

The Web of Things activities of W3C are described in the Web of Things section of the W3C website. The main web page contains a discussion of the important considerations. The material linked to from that page, including the presentation Countering Fragmentation with the Web of Things that was given at the London Workshop, gives further explanation of the ideas.

Three key aspects of the Web of Things are discussed in the Viewpoints Comparison in this White Paper:

  • Software Objects
  • Descriptions and Metadata
  • Communication

The discussion in this White Paper is based on the material presented at the London Workshop, rather than on the unofficial draft architecture or other, later W3C drafts. The reader is invited to investigate the W3C website to understand recent developments.

Common Basic Model

The four reference architectures assume a common basic model, which is illustrated in the figure.

Basic IoT Concepts

Beyond this basic model, the reference architectures differ. They are not contradictory; they do not disagree; but they look at the IoT in different ways.

Viewpoints Comparison

To compare the reference architectures, this White Paper considers the different viewpoints that they have.

A view is a representation of a related set of concerns. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture, but does not have to be visual or graphical in nature. A viewpoint is a definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view, often by means of an appropriate schema or template – see the TOGAF 9.1 standard, Sections 3.75 (View) and 3.76 (Viewpoint). Although the two terms identify distinct concepts, the distinction is unfortunately often blurred, and they are sometimes used interchangeably.

The Draft ISO IoT RA lists the views that it covers; they correspond to viewpoints. The IIRA lists the viewpoints that it includes. For RAMI 4.0, the two horizontal dimensions of the model, and the layers of the vertical dimension, correspond to viewpoints. The Web of Things does not identify viewpoints explicitly, but some are implicit in its descriptions. The table shows the viewpoints included in each reference architecture, with corresponding viewpoints in each row.

Note that, even where viewpoints in different reference architectures that are placed in the same row have the same name or similar names, they generally have different definitions. The table is useful as an overview comparison, but not at a detailed level. The following sections give more detailed descriptions that bring out some of the similarities and differences between the viewpoints. For full details, the reader should consult the descriptions produced by the bodies responsible for the reference architectures.

Note also that, while the IIRA does not have specific Information and Communication viewpoints, its System viewpoint covers many of the aspects addressed by those viewpoints in other reference architectures.

The Viewpoints of the Reference Architectures

Draft ISO IoT RA

IIRA

RAMI 4.0

Web of Things

 

Business

Business

 

Usage

Usage

 

 

Functional

Functional

Functional

Software Objects

Information

 

Information

Descriptions & Metadata

Communication

 

Communication

Communication

System

Implementation

Integration

 

 

 

Asset

 

 

 

Lifecycle/Value Chain

 

 

 

Hierarchy

 

Business Viewpoints

IIRA Business Viewpoint

The IIRA Business viewpoint addresses business-oriented concerns such as value proposition, expected return on investment, cost of maintenance, and product liability.

RAMI 4.0 Business Layer

The RAMI 4.0 Business layer is concerned with the realization of business processes.

Use Viewpoints

Draft ISO IoT RA Usage View

The Draft ISO IoT RA Usage view focuses on how the IoT system is developed, tested, operated, and used from a user perspective. It identifies three IoT user groups: Service Provider, Service Developer, and User. It describes the users in these groups, and their activities and roles.

Service Provider users include Business Managers, Service Delivery Managers, System Operators, Security Analysts, Operations Analysts, and Data Scientists.

Service Developer users include Solution Architects, DevOps Managers, Application Developers, Device Developers, and System Integrators.

The Users group includes Human Users and Digital Users.

IIRA Usage Viewpoint

The IIRA Usage viewpoint is concerned with how an Industrial Internet System realizes the key capabilities identified in the Business viewpoint. It describes concepts related to usage: Party (which corresponds to User in the Draft ISO IoT RA), System, Activity, Role, and Task. It describes the activities that coordinate various units of work over various system components. It also describes some specific activities related to security.

Functional Viewpoints

The Draft ISO IoT RA Functional view and the IIRA Functional viewpoint both identify and describe functional domains. Their approaches are similar in this respect, although the domains that they identify are different. The RAMI 4.0 Functional Layer and the Web of Things Software Objects also have approaches that are somewhat similar to each other, although they are different to the domain-oriented approaches of the Draft ISO IoT RA and the IIRA.

Draft ISO IoT RAFunctional View

The Draft ISO IoT RA Functional view is a technology-neutral view of the functions necessary to form an IoT system. It describes the distribution of functions and dependencies among functions for support of activities described in the User view. It describes the functions in each domain of the domain-based reference model, and the cross-domain functions. The domains are: User, Operations and Management, Application Service, IoT Resource and Interchange, Sensing and Control, and Physical Entity.

IIRA Functional Viewpoint

The IIRA Functional viewpoint considers five functional domains: Control, Operations, Information, Application, and Business.

RAMI 4.0 Functional Layer

The RAMI 4.0 Functional layer contains services that support the business processes and provide functional access to the physical assets. RAMI 4.0 has a concept of administration shell that provides access to assets, as illustrated in the figure. There are a number of International Standards related to administration shells.

RAMI 4.0 Administration Shell

Assets are factory plant and machinery, including sensors, actuators, mechanical parts, etc. Sensors can monitor, and actuators can control, assets and the products to be built or assembled in the factory. An asset is part of a RAMI 4.0 component, which has two parts: the asset, and the asset’s administration shell. The administration shell is the virtual representation of the asset in the IT world. It includes data and digital processes related to the asset and serves as a kind of avatar. A component manager can easily integrate this into a service-oriented architecture.

An administration shell has two parts: a manifest, and a component manager. The manifest describes the asset. The component manager handles requests for actions related to the asset’s capabilities, and responds to them.

An administration shell can contain other administration shells. A whole factory can have an administration shell, and every machine in it can also have an administration shell.

Web of Things Software Objects

The basic functional and information concepts of the Web of Things are illustrated in the next figure.

Web of Things Basic Concepts

In this model, the description describes the physical entity, and the software object represents it. They are in some respects similar to the manifest and component manager of a RAMI 4.0 administration shell. The entity can be measured or controlled by the software object, which interacts with sensors and actuators that monitor and act on it. The script manipulates the software object to perform application-related processing of the entity. Scripts can run on servers or as part of web pages in web browsers.

Information Viewpoints

Draft ISO IoT RA Information View

The Draft ISO IoT RA Information view describes the flow of information within and between the domains of an IoT system.

RAMI 4.0 Information Layer

The RAMI 4.0 Information layer is about the data about the assets. This can be contained in the manifests in the assets’ administration shells. The manifest describes what the asset is, and where it fits into the system, including its communication interfaces and capabilities.

Web of Things Descriptions and Metadata

Descriptions of things constitute one of the basic concepts of the Web of Things; they can be formal machine-readable descriptions following W3C standards. Software objects that represent the physical entities could be generated from these descriptions.

A good approach to metadata is to tag data as belonging to an ontology that describes the relationships between concepts in a machine-interpretable way:

  • What kind of a thing is it (e.g., a temperature sensor)?
  • What are the domain constraints? (Temperature sensors must describe their physical units, which must be from the set {Kelvin, Celsius, Fahrenheit}. Other ontologies could describe the location of the sensor and what it is measuring.)

Communication Viewpoints

Draft ISO IoT RA Communication View

The Draft ISO IoT RA Communication view describes the principal communications networks that are involved in IoT systems, and the entities that they connect. The communications aspects of the conceptual model are illustrated below.

Communications Aspects of the Draft ISO IoT RA Conceptual Model

The Communication view identifies four kinds of network:

  • Proximity Network: The main task of such a network is to connect sensors and actuators to a gateway. Proximity networks are typically local and limited in range, and may use specialized protocols, to cater for device and environmental limitations.
  • Access Network: These networks connect devices to services and applications. Today, this is usually via gateways, but when sensors and actuators are more capable, they may connect to access networks directly. An access network is typically a wide area network, often the Internet.
  • Services Network: These networks interconnect services and applications. They are typically intranets or parts of the Internet, or both.
  • User Network: These networks provide connections to human users, digital users, and external systems. They are typically parts of the Internet.

RAMI 4.0 Communication Layer

The RAMI 4.0 Communication layer is about how components communicate through networks. It provides standardization of communication, using a uniform data format. OPC UA (IEC 62541) is identified as an approach for implementing this layer, but neither this nor any other standard is mandated.

Web of Things Communications

A model for distributed operation in the Web of Things is shown in the next figure.

Distributed Web of Things

A remote software object can act as proxy for the software object that is local to the IoT device, enabling a remote script to interact with the device. The software object local to the device acts as server, with the remote object as its client.

A communications stack model presented for the Web of Things at the London Workshop was felt by participants to be very useful, and is shown in the table.

Web of Things Communications Stack

Layer

Content

Application

Scripts that define “thing” behavior in terms of properties, actions, and events, using APIs for control of sensor and actuator hardware.

Things

Software objects that hold their state.

Abstract thing-to-thing messages.

Semantics and metadata, data models and data.

Transfer

Bindings of abstract messages to mechanisms provided by each protocol, including choice of communication pattern; e.g., pull, push, pub-sub, peer-to-peer, etc.

Transport

REST-based protocols (e.g., HTTP); CoAP Pub-Sub protocols (e.g., MQTT, XMPP).

Others, including non-IP transports (e.g., Bluetooth).

Network

Underlying communication technology with support for exchange of simple messages (packets).

Many technologies designed for different requirements.

Component Viewpoints

Although the Draft ISO IoT RA System view, the IIRA Implementation viewpoint, and the RAMI 4.0 Integration layer have different names, they all correspond to viewpoints that include system components. The RAMI 4.0 Asset layer shows the physical components that are monitored and acted on by the IoT systems.

Draft ISO IoT RA System View

The Draft ISO IoT RA System view describes the generic physical components (such as devices, sub-systems, and networks) in each domain to form an IoT system.

IIRA Implementation Viewpoint

The IIRA Implementation viewpoint is concerned with the technical representation of an Industrial Internet System, and the technologies and system components required to implement the activities and functions prescribed by the usage and functional viewpoints.

The system components include sensors, actuators, controllers, platforms, data services, analytic services, operation services, management services, asset descriptions, and metadata.

The IIRA identifies three tiers of components, Edge, Platform, and Enterprise, with different networks connecting the tiers (compare this with the Draft ISO IoT RA Communication view):

  • The proximity network connects the sensors, actuators, devices, control systems, and assets, collectively called edge nodes. It typically connects these edge nodes as one or more clusters related to a gateway that bridges to other networks.
  • The access network enables connectivity for data and control flows between the edge and the platform tiers. It may be a corporate network, or an overlay private network over the public Internet, or a 4G/5G network.
  • The service network enables connectivity between the services in the platform tier and the enterprise tier. It may be an overlay private network over the public Internet, or the Internet itself.

RAMI 4.0 Integration Layer

The RAMI 4.0 Integration layer is about how assets connect to IT systems. Platform Industrie 4.0 is particularly concerned to address integration: both horizontal, between factories, and vertical, within them. The RAMI 4.0 Integration layer contains many of the components that might be shown in the Draft ISO IoT RA System view, or from the IIRA Implementation viewpoint, but considers them from a substantially different viewpoint.

RAMI 4.0 Asset Layer

The RAMI 4.0 Asset layer contains the machines that are operated by the IT system. These appear in other reference architectures, but not in their own viewpoints.

Industry-Specific Viewpoints

While much of RAMI 4.0 is generic, and can be applied to other vertical areas, the Life Cycle/Value Streams and Hierarchy dimensions of its matrix are specific to the manufacturing industry.

RAMI 4.0 Life Cycle and Value Streams Dimension

The first horizontal axis of RAMI 4.0 represents Life Cycle and associated Value Streams, based on the emerging IEC 62890 standard for life cycle management. A life cycle is viewed together with the value­adding processes it contains, across the manufacturing, servicing, and customer organizations involved.

RAMI 4.0 Hierarchy Dimension

The second horizontal axis of RAMI 4.0 follows the IEC 62264 and IEC 61512 standards. It shows a hierarchy of assets: product, field device, control device, station, work center, enterprise, connected world.

Conclusions

The four architectures have significant overlap, but different coverage and different emphasis, and often look at the same things in different ways. The Viewpoints Comparison section gives an overview, and the sections following it give more detailed descriptions that bring out some of the similarities and differences.

The bodies producing these reference architectures are aware of, and often build on, each others’ work. There is some formal collaboration: representatives of Platform Industrie 4.0 and the Industrial Internet Consortium have agreed on cooperation that includes the future interoperability of the systems and the use of common test environments.

It is to be hoped that future developments will retain the different viewpoints and differences of approach. Different situations require different approaches. The availability of a range of reference architectures is of value to architects.