IoT Reference Architecture - Programmingoneonone

The Internet of Things (IoT) provides new opportunities for different IoT platforms to connect various devices together. The need to identify those devices is of foremost importance to performing any kind of operation. Many organizations and standard bodies that provide specifications and frameworks for the IoT currently have their own identification mechanisms.

Some existing industrial identification mechanisms can also be used in the IoT. There is no common Identification Scheme (IS) for the IoT as yet, because of the political and commercial differences amongst the standard bodies.

Since the emergence and rapid growth of the Internet of Things (IoT), many global organizations have been providing specifications and guidelines for creating IoT applications. Therefore, IoT applications are very different in nature due to the heterogeneity of the platforms available. An identifier has a string of characters used to identify any physical or virtual entity.

For example, an IP address is an identifier of a computer connected to the network. Basically, IoT devices or applications need to be recognized before being used in an IoT environment. There are many platforms that use a variety of globally unique Identification Schemes (ISs) or their own proprietary methods.

The problem arises when devices from different platforms need to exchange data or communicate with other applications. Due to the lack of an identification standard, interworking among IoT platforms remains challenging.

The first major contribution of the IoT Architectural Reference Model (IoT ARM) is the IoT Reference Model itself. Besides models, the IoT Reference Model provides the concepts and definitions on which IoT architectures can be built.

Reference Architecture

All other models and the IoT Reference Architecture are related to the IoT Domain Model. While certain models, such as the IoT Communication Model and the IoT Trust, Security, and Privacy Model might be less critical in specific application scenarios, the IoT Domain Model is mandatory for all usages of the IoT ARM.

An ARM consists of two main parts: a Reference Model and a Reference Architecture.
A reference model describes the domain using a number of sub-models

Interaction of All Sub-Models

The IoT Reference Model provides a platform for IoT architecture and IoT systems to build a common grounding and common language. The arrows show how to connect one model to another.

The foundation of the IoT Reference Model is the IoT Domain Model, which introduces the main concepts of the Internet of Things like Devices, IoT Services, and Virtual Entities (VE), and it also introduces relations between these concepts. The IoT Functional Model identifies groups of functionalities, of which most are grounded in key concepts of the IoT Domain Model.

A number of these Functionality Groups (FG) build on each other, following the relations identified in the IoT Domain Model. The Functionality Groups provide the functionalities for interacting with the instances of these concepts or managing the information related to the concepts, e.g. information about Virtual Entities or descriptions of IoT Services.

One of the characteristics of IoT systems is often the heterogeneity of communication technologies employed, which often is a direct reflection of the complex needs such systems have to meet. The IoT Communication Model introduces concepts for handling the complexity of communication in heterogeneous IoT environments. Communication also constitutes one FG in the IoT Functional Model. Finally, Trust, Security, and Privacy (TSP) are important in typical IoT use-case scenarios.

Requirements for a Reference Architecture

There are some specific requirements for IoT that are unique to IoT devices and the environments that support them, e.g. many requirements emerge from the limited form factors and power available to IoT devices. Requirements are as follows:

Connectivity and communications
Device management
Data collection, analysis, and actuation
Scalability
Security

Connectivity and Communications

Communication protocols, such as HTTP, are essential for many devices. Even an 8-bit controller can create simple GET and POST requests and HTTP provides important uniform connectivity. However, the overhead of HTTP and some other traditional Internet protocols can be an issue for two main reasons.

For smaller devices, the memory size of the program is a big problem and the second issue is the power requirement. So to overcome these issues we need a simple, small, and binary protocol. Furthermore, some devices connect directly via a gateway, so these devices require 2 protocols that connect via a gateway.

One to connect to the gateway, and then another from the gateway to the cloud. Once and for all, for the architecture, there is a requirement to support transport and protocol bridging, so we need a binary protocol to the device protocol the device but allow an HTTP-based API to control the device that we expose to third parties.

Device Management

We know that active management of PCs, mobile phones, and other devices become increasingly important, requirements for IoT devices are as follows:-

The ability to disconnect a stolen device
The ability to update the software on a device
Updating security credentials
Remotely enabling or disabling certain hardware capabilities
Locating a lost device
Wiping secure data from a stolen device
Remotely re-configuring Wi-Fi, GPRS, or network parameters

Data Collection, Analysis, and Actuation

Some IoT devices are based on UI but IoT devices are based on one or more sensors, one or more actuators, or a combination of both. The system requirement is that we collect data from very large numbers of devices, store it, analyze it, and then act upon it.

The principle behind designing the reference architecture is to manage very large numbers of devices. If these devices are creating constant streams of data, then this makes a significant amount of data. The requirement is for a highly scalable storage system, which can handle diverse data and high volumes.

Scalability

Any server-side architecture should be highly scalable and be able to support millions of devices all constantly sending, receiving, and acting on data. “High-scalability architectures” have come with an equally high price – both in hardware, software, and complexity.

For this architecture, the main requirement is to support scaling from a small deployment to a very large number of devices. The ability to scale the serverside out on small cheap servers is an important requirement to make this an affordable architecture for small deployments as well as large ones.

Security

For IoT architecture, security is the most important component. IoT devices are often collecting highly personal data, and by their nature are bringing the real world onto the Internet (and vice versa). Now three categories of risks are as follows:

Risks are inherent in any Internet system, but product/IoT designers may not be aware of that risks.
Specific risks that are unique to IoT devices.
Safety to ensure no harm is caused by, for instance, misusing actuators.

The first category includes simple things such as locking down open ports on devices. The second category is related to IoT hardware, for eg. the device may have its secure information read. Another example is the ability of someone to attack the hardware to understand security.

For IoT security, 2 important issues are concerned with identity and access management. Identity is an issue where there are often poor practices implemented. For example, the use of clear text/ Base64 encoded user IDs/passwords with devices and machine-to-machine (M2M) is a common mistake.

Another common issue is to hard-code access management rules into either client- or server-side code. A powerful approach is to utilize models such as “Attribute-Based Access Control” and “Policy-Based Access Control”. These approaches are provided by the XACML standard5. Such approaches remove access control decisions from hard-coded logic and externalize them into policies, which enabled the following:

More powerful and appropriate decisions
Can potentially be based on contexts such as location, which network is being used, or the time of day.
Access control can be analyzed and audited.
Policies can be updated and changed, even dynamically, without recording or modifying devices. Our security requirements should support this.
Encryption on devices that are powerful enough.
A modern identity model based on tokens and not user ids/passwords.
The management of keys and tokens as smoothly/remotely as possible.
Policy-based and user-managed access control for the system based on XACML

Other IoT Tutorials