IoT Layered Architecture

Reference IoT Layered Architecture (RILA) consists of 6 layers. In addition, to there are two “cross-section layers that affect all other layers, namely “Security” and “Management”.

Device Integration Layer

The device integration layer connects all the different device types and consumes device measurements as well as it communicates actions. This layer can also work as a translator that speaks many languages. The output of the sensors and tags depends on the protocol they implement. The input of the actuators is also defined by the protocol they implement. 

This layer comprises three components. The lowermost component is the driver component which communicates with the different sensors, tags, and actuators on low-level, vendor-specific, communication protocols. It contains driver instances for every type of low-level device known to the system. The next component is the device discovery component.

It can be triggered by two events, one from the device management layer, which tells this component to add a new device, and by the driver component, which notifies this component in case a new device is added. Similar to device discovery also handles the deregistration of devices. The last component is the device communication component. It behaves like a bridge between the device management layer and the driver component. This component decides which driver is called when the device management layer addresses a device. 

Device Management layer 

The working of the device management layer is to represent taking device registrations and sensor measurements from the device integration layer. It communicates status changes for actuators down to the device integration layer. The device integration layer then validates that the status change conforms with the actuator and then translates the status change to the actuator. 

The control of devices is in the hand of the device management layer so that it knows which devices are connected to the system. Each change to a device’s registration as well as incoming measurement data has to be communicated from the device integration layer to the device management layer, so the information can be updated and stored. So in this way, the device integration layer manages device registration and device communication.

Data Management Layer

The data management layer work as a central database that holds all data of a “thing”. But this is only one possible implementation. Data management can work as a data warehouse for larger things within the system. The implementation of the data management layer depends on the use case for the specific thing. 

Context Management Layer 

The context management layer defines the central business logic within RILA and is responsible for six tasks: 

1. Define the goals of the thing. 
2. Consume the context situation(s) of other things 
3. Produce the (own) context situation of the thing 
4. Evaluate the (own) context situation towards the goal. 
5. Trigger actions that help to fulfill the goal according to the evaluated rules. 
6. Publish context situations for other things. 

According to these tasks, we can divide context management into eight components.

From the above image, the components are as follows: 

1. Rule Engine & Artificial Intelligence (AI): Define and manage the necessary rules for context evaluation. It provides the goal as well as rules for creating the context of the situation and actions. 
2. Context Situation Integration Module: It listens to context situations of other things and integrates the incoming context situations.
3. Action Integration Module: In this component, incoming actions of other things are evaluated and passed on to the device management layer. Rules have to be considered, that define in which situations an action received from another thing can be passed on for triggering an actuator. 
4. Context Situation Creator Module: It collects data from the system and builds the context situation(s). This can also be driven by rules. 
5. Action Creator Module: It behaves like a context situation creator module, action objects have to be created once triggered during rule evaluation. 
6. Context Situation Publisher Module: It provides context situations to the thing integration layer. According to the context, the situation publisher can provide a set of context situations for different things that are subscribed or one context situation for everybody. In the context situation, the publisher module has to take care of data permission levels for other things. Only trustworthy should receive selected context information. In addition, this component also defines the context situation schemas that are communicated to other things that want to subscribe. The schema is used to decide whether a thing is capable of communicating with another thing.
7. Action Publisher Module: It is identical to the context situation publisher module. The work of this component is to communicate actions to the thing integration layer to be communicated to other things. Furthermore, this component is also managed by the action schema.
8. Context Evaluation Module: This component is used to check out the rules using the (current) context situation and triggers actions that are communicated down to the devices or to the action creator module. The action creator module in turn passes the created actions to the action publisher that communicates the actions to other things. One way to simply evaluate rules is to build decision trees from the rules defined by the rule engine. 

Thing Integration Layer 

The thing integration layer is responsible for finding other things and communicating with them. The thing integration layer has to evaluate if communication with the thing to be partnered with is possible. So context situation and/or action schema have to be compared. These are provided by the context management layer. If the schema match is considered positive, the thing can brief the other thing upon new contexts situations, or action creation. The context situations and actions to be communicated to other things are provided by the context management layer. The thing registration can be done in a central component or by the thing itself. 

Application Integration Layer 

The application integration layer connects the user to the thing. This layer is the topmost layer of the RILA. The application integration can be seen as a service layer, or even as a simple UI on top of the stack. The concrete implementation of the layer depends on the use case. 

When building an IoT system we have to consider security on all layers. Attack vectors have to be identified in order to identify appropriate security standards. 

The following attack vectors are as follows: 

1. User: The end-user is a possible attack vector because it can affect the system without its knowledge. One common attack of this type is a phishing attack, which attempts to acquire sensitive information from the victim. 
2. Web interface: If the application offers a web interface, then this is to ‘conventional’ attacks like SQL injection or XSS. 
3. Thing: Generally, smart devices communicate with an external system via an app, which relies on a form of the operating system. The two main liabilities are the app itself which might not offer sufficient security mechanisms or the operating system underneath that could be hacked or infected. 
4. Low-level hardware components: When we are thinking about hardware components and the security they provide, the main consideration is that computing power. That means low-power devices do not have the required CPU power for secure encrypted communication, If the correctness of the data provided by the sensors is essential, then more powerful hardware is required, increasing the cost of acquisition by an order of magnitude.

Communication Channels

• RFID and NFC: Communication between tag and reader is wireless and can easily be eavesdropped. The symmetric encryption algorithms considered secure are 3DES and AES-128. When writing data to a new tag, the default authentication key should be changed. The key management for the tags is done by the system that controls the reader. RFID tags themselves are very distinct and security is essential. for eg: The Mifare Plus tag is an upgrade from the Mifare Classic tag because it offers AES-128 encryption. 
• Zigbee: The communication channel between a Zigbee device and the application is secure because the algorithm used for encryption is AES-128. The initial key exchange on the other hand must be considered insecure. When a new device is added to the network, the key is sent to the device in plain text and can be found by sniffing, given the timing is right.
• Thread: The communication between two Thread devices is secured by AES encryption. The key establishment between a new device and the application is done in a secure way using a key exchange algorithm. 

The security triangle shows the dilemma of choosing the right amount of security according to our use case.

The security triangle represents a compromise that occurs in every use case, In this triangle, we can pick only one point that represents what we need in terms of security, cost, and business requirements.

Other IoT Tutorials

• Representational State Transfer (REST) in IoT
• Uniform Resource Identifier (URI) in IoT