1.1.1.

IoT Software Architecture

1.1.1.1. Software Opportunities in IoT Systems

Let us find out where all there exist opportunities of software development in IoT system. We will try
to take some configurations and analyse the software opportunities there.

Let us take the configuration shown in Fig 1.1.1.1.

Fig. 1.1.1.1. Software Opportunities in IoT System – Configuration (a)

In the system shown in Fig 1.1.1.1, the edge devices are connected to the sensors and actuators. They
communicate with a local device gateway. The necessary computing and decision making happens in
the device gateway. Also data storage happens in the local device gateway. It is a typical Level 1 IoT
system. If one wants to view the data or the decisions made or if it is required to control the system,
from a remote desktop or laptop, it can be done through a web application. For that the device
gateway must have a web server running on it. The same can also be accessed from any mobile hand
held device (such as a smart phone or a smart tablet) through a mobile app.
Let us try to locate the software opportunities in this system. Edge devices must have a software
running. The device gateway of course will have a software system. And the devices for viewing and
controlling the system the corresponding software.

Fig 1.1.1.2 shows another configuration.

Fig. 1.1.1.2. Software Opportunities in IoT System – Configuration (b)

In this configuration, certain part of decision making and storage is happening in cloud. What amount
of storage and decision making needs to happen in the device gateway or cloud is a designers choice,
which depend upon the IoT System under design. This configuration caters to IoT Level 2 to Level 6
applications. Please note that in the diagram only one device gateway is shown, but there can be
multiple as well. Here the devices for viewing and controlling (such as desktop, laptop, smartphones,
smart tablets etc) interact with cloud, not with the device gateway directly.

Here the software systems are required at the edge device, device gateway, cloud and at the devices
meant for viewing and controlling.

Fig 1.1.1.3 shows another configuration.

 Fig. 1.1.1.3. Software Opportunities in IoT System – Configuration (c)

Here the edge devices are directly connected to the cloud. Please note that these edge devices have
the capabilities of being device gateway or co-ordinators. It is a quite heterogeneous and distributed
system. Such a system caters to IoT Levels 4, 5 and 6 systems.

It is again very easy to conclude here that software systems are required at the edge device level,
cloud level and at the level of devices meant for viewing and controlling.

One can come up with more such configurations and analyse the software opportunities in an IoT
system.

1.1.1.2. IoT Software Architecture Views

We understood from the previous section that Software is a very essential component of any level of
IoT system. Let us try to visualize the Software stack from various perspectives.

Fig 1.1.1.4 shows one such view.

 Fig. 1.1.1.4. IoT Software Stack – View (a)

In this view, the software stack at device level will have an Operating Systems and required
applications for the device. Above that Network Services are needed for communicating with other
devices and Cloud. At the outer layer, Cloud related software stack should be present. This includes
the software required at cloud and the software required at device level to interact with the cloud. IT
also includes the software to interact with the cloud for viewing and controlling.

Fig 1.1.1.5 shows another view.

 Fig. 1.1.1.5. IoT Software Stack – View (b)

This is another way of looking at the IoT Software Stack running on various components of the IoT
system. The lowest level, it is the device specific software. For example different software are required
on different devices like a smartphone, Raspberry Pi, automotive, laptop of Arduino board. They all
need to communicate with each other in a common way. Hence corresponding software must be
present. Application interface like CoAP and REST must be present for interacting with the Web based
services, which require underlying communication interfaces like MQTT or HTTP. At the top of the
software stack, there will be application software meant for analysis, analytics, user interface etc.
These software components are running on various devices present in the IoT system. Please note
that all the software components need not run on all the devices.

Fig 1.1.1.6 presents yet another view.

 Fig. 1.1.1.6. IoT Software Stack – View (c)

This view shows different layers of an IoT software stack. At the bottom level, there are sensors and
actuators, where the software requirement is a little. Above this layer, there are device level software
components. Then comes software for device management and the software required in the device
gateway. This layer may be present on the device gateway and/or in cloud. Above that, software layer
for data aggregation and data management exists.

The upper three layers are related to applications. Application Run-time is responsible for translating
application code to the format understood by the lower layer. Example of such a component is Java
Virtual Machine. API interfaces are used by the upper layer application to access the functionalities of
the lower layers. Data analytics module is meant for doing analytics on the data aggregated. Above
these there exist an Application PaaS, which is more relevant for the cloud software. At the top, there
are application to access the analysed data and for controlling the system. These are in the form of
Websites, Web Applications and Mobile Apps.

This a typical software stack. Of course there are possibilities of variations. But generally most of the
software stacks involving cloud will fit into this framework with minor variations.

1.1.1.3. IoT Software Architecture

Fig 1.1.1.7 shows a picture, categorizing the IoT software into three levels denoted by L1, L2 and L3.
 Fig. 1.1.1.7. IoT Software Levels

As we observe from Fig 1.1.1.7, the software for IoT system can be categorized into following types.

 Level 1 (L1) : Edge Device Level Software Stack

 Level 2 (L2) : Device Gateway Level Software Stack
 Level 3 (L3) : Cloud Level Software Stack

Characteristics of these software stacks are discussed in the subsequent sections.

1.1.1.3.1. Edge Device Level Software Stack

Characteristics of the Edge Devices are:

 Low Processing Power

 Low Power Requirements

  Limited Communication Capabilities

 Low Memory

Hence the software for these device should cater to these characteristics. Considering these, the
architecture of a typical software stack for edge devices look like the own in Fig 1.1.1.8.

Fig. 1.1.1.8. Software Architecture for Edge Devices

At the lowest level of the stack, there exists operating system (OS) or real time operating system
(RTOS). If a full-fledged OS is not required, some sort of a stripped down version of OS is needed. Over
this, there must be a hardware abstraction layer (HAL) in order to make the upper layer of the
software architecture independent. Since the edge device needs to communicate with the other
devices / cloud in the system, communication software stack is also needed. At the top of the
software stack, applications required for the device to perform the desired tasks must be present.
There should also be software components for auxiliary tasks like device management, software
upgrade, remote debugging etc.

1.1.1.3.2. Device Gateway Level Software Stack

The Gateway Devices need to have following characteristics.

 They collect data from edge devices (Sensor Data)

 They consolidate the data collected and send it to the cloud via external network

 They send control signals to the edge devices connecting to the actuators, as directed by the
corresponding Cloud level IoT Software.

 The edge devices may depend on this device for external network connectivity.

Because of the above activities, data processing, reliability of data transfer, data security etc become
important at this level. Considering these, the architecture of a typical software stack for edge devices
look like the own in Fig 1.1.1.9.
 Fig. 1.1.1.9. Software Architecture for Device Gateways

This is similar to the one for the edge devices, with some additional components. The ‘application
runtime’ component is responsible for translating the upper layer application code to the code
understandable by the lower layers. Since this is a complex software stack, the application writer must
be allowed to use user friendly programming languages like Java, Python etc. That is the reason
‘application runtime’ is required. Apart from this component, there is a component shown for ‘data
management and processing’. This is needed since the device gateway is usually responsible for
collecting data from the edge devices and sending it to the cloud after performing required level of
aggregation and processing. In some cases, it may do the complete data processing inside it. Apart
from these two components, it will have device gateway specific applications.

1.1.1.3.3. Cloud Level Software Stack

The Cloud level IoT Software has following characteristics.

 It should be able to interface with large number of IoT Gateways and Edge Devices through
multiple network protocols simultaneously.

 It should maintain a centralized registry for device registrations and de-registrations for large
number of devices and device gateways.

 It should be capable of handling huge amount of data and should be scalable in terms of data
storage

 It should have capability of data analytics and event management

 It should have adequate security for data.

 It should appropriate user interface for the users to access the information from different
devices with different operations systems and configurations

 Application enablement, such as dashboard showing graphs, report generation, sending

notification etc. should be provided to the user.
Considering these, the architecture of a typical software stack for edge devices look like the own in
Fig 1.1.1.10.

Fig. 1.1.1.10. Software Architecture for Cloud Level IoT Software

One can observe the presence of many different software components here. Since it is at cloud level,
the operating system can be replaced with a PaaS (Platform as a Service). Since the could level
software manages different heterogeneous devices joining and leaving asynchronously, it needs to
maintain a device registry. It should have the device management component to manage and
configure different devices. It should have software components for data management, data
aggregation, data analytics, event management etc. As we all aware, software component for
connectivity must be there. Since it has to allow communication between various software
components within its software stack, it should have appropriate mechanism, which is shown as
‘message routing’ in the diagram. Last, but not the least, it should provide application software for
user to view and control. Also it should provide facility to the user to develop and deploy his/her own
applications related to the IoT system on the cloud.

1.1.1.4. Roles of Open Source Hardware Boards and Smart Devices

In order to learn the software development for IoT, it is a good idea to use the available open source
hardware boards and also the smart devices available with us.

Open Source Hardware like Raspberry Pi can be used as both edge device and device gateway.

As a Device Gateway, Raspberry Pi has following roles.

  Role 1: Collect data from the edge devices and send to the cloud via Network

 Role 2: Collect data from the edge devices, process it and publish it to outside world via web-
server installed on it.

As an Edge Device, Raspberry Pi has following roles.

 Role 1: Act as an web-client and send the sensor data to an web-server

 Role 2: Send the sensor data to the IoT Cloud through MQTT/HTTP.

Arduino, being a device having low processing power, is more suitable for an Edge Device role. One
important advantage of Arduino is that analog sensors can be interfaced with it. It can communicate
to Device Gateways via Bluetooth, Zigbee, WiFi, Ethernet etc.

Smart devices like Smartphones, Tablets, Wearables etc have very important roles in IoT.

They can be used as:

 Edge Devices, collecting data using inbuilt sensors, e.g. Smartphone sending Location
information,

 Device Gateways, e.g. Interface with edge devices through WiFi, Bluetooth etc, consolidate
the data and send it to the Cloud

 Interface with IoT Cloud Software directly running applications showing statistics, status,
analytics etc.

1.1.1.5. Design Challenges

Followings are some of the guidelines we should follow while designing the software components for
IoT systems.

 Reduce the network traffic between edge devices, device gateways and the cloud, wherever
possible.

 Reduce the computing at the edge devices wherever possible.

 Reduce the data storage at the edge devices wherever possible.

Fig. 1.1.1.11 shows a hypothetical view of storage and computing loads to be present at these three
levels of software.
Fig. 1.1.1.11. Storage and Computing Load for Different Levels of IoT Software