Demonstration on Architecture of Internet of Things - An Analysis
- Dulitha Wijewantha
- Developer - WSO2
Table of contents
- Introduction
- IoT reference architecture
- Architectural flow of IoT demo
- Further work
- Resources
Introduction
Internet of Things (IoT) is evolving rapidly with Gartner predicting that by 2020, approximately 20 billion units will be operational. We have also seen many interesting fields, such as medical, agriculture, and welfare, utilizing the power of things.
At O'Reilly Solid Conference held in San Francisco, in May 2014, we carried out an IoT demo that explained the software architecture for IoT. The motivation to build a reference architecture came from a need to build a complete, scalable IoT project where the most important aspects were properly outlined. These included communication, security, device management, data collection and analysis, device actuation, and scalability.
With these requirements in mind, we brainstormed to find a solution, and the end result was the architecture depicted in Figure 1 and its mappings to WSO2’s suite of products.
IoT reference architecture
Figure 1
This architecture is further explained in the Reference Architecture for Internet of Things white paper as well. The demonstration we did at SolidCon features most of the aspects of the IoT reference architecture. The solution used WSO2 Complex Event Processor (CEP), WSO2 Message Broker (MB), and WSO2 Enterprise Mobility Manager (EMM), and demonstrated the following scenarios:
- Publishing temperature and humidity data to a MQTT message broker
- Running a CEP against the sensor data
- Switching on a fan from the cloud based on the output of the CEP
- Visual representation of sensor data from the EMM dashboard
- Operating the fan from the EMM
- Obtaining device management information from the enrolled Raspberry Pi devices
Architectural flow of IoT demo
Let’s further analyze how information flows from IoT devices to various layers of the reference architecture as illustrated in Figure 2.
Figure 2
- The Raspberry Pi 1 has an embedded agent. The agent runs and reads the sensor input and publishes MQTT messages to a topic in the MB.
- The CEP is subscribed to the topic and runs a real-time CEP query to find if the temperature has gone beyond a certain threshold. If it has, the CEP engine publishes a Switch On Message to another topic in the MB. And if not, it publishes a Switch Off Message.
- The Raspberry Pi 2 also has an embedded agent. The agent is subscribed to the topic in the MB that CEP published the Message before. If the Switch On message is sent, the Raspberry Pi will power the relay and it will switch on the fan.
- The EMM monitors the device information and sensor data in real time and displays them on a dashboard. The EMM also has control over the actuator.
In the above explanations, we threw in several buzzwords like MQTT and Raspberry Pis. Here’s a quick look at what these mean:
MQTT protocol
MQTT is a light-weight (2 bytes header) broker-based publish/subscribe messaging protocol designed for constrained environments. MQTT uses TCP/IP to provide networking. The message transport is agonistic of the content payload. MQTT allows users to specify Quality of Service (QoS) options as well to further optimize delivery. The WSO2 MB team was working on adding MQTT support; WSO2’s Co-Founder and CTO Paul Fremantle used this for MQTT interop test at EclipseCon, in San Francisco in March 2014, where he presented a talk. We decided that MQTT was the ideal message protocol for devices due to its open, less message overhead nature.
Raspberry Pi
Raspberry Pi is a low-cost, linux-based computer that can be used for many IoT projects. Due to its multi-process nature, it can be used to perform high-end computing as well. We used 2 Raspberry Pi computers where a sensor and an actuator were plugged in.
To obtain temperature and humidity data we used a DHT11 sensor (which can be powered with 3-5V), shown in Figure 3.
Figure 3
To actuate the fan - we needed to provide controlled power. Voltage circulation in the Raspberry Pi is 5V. To switch on a fan (which takes 12V) from the Raspberry Pi, we used a Relay Circuit (JQC-3F(T73)) as shown in Figure 4.
Figure 4
Agent on device for sensor
As explained earlier in the article, an agent code sits in the Raspberry Pi that does the computation. We came up with the initial idea of the agent because, in EMM, we wrote an agent for Android to perform device management. In this case, the agent code is written in Java and runs on the JVM installed in the Raspberry Pi. We used Java because we like Java, and have been working with it for a while now! The agent also uses Pi4j Library to talk to GPIO (General Purpose Input Output). We also toyed with the idea of creating an agent using Python, but we left that for future work.
If we analyze what the agent does, from a fixed-time interval, the agent reads a GPIO pin that the DHT11 sensor is connected to. It will return the temperature and humidity of the room. Next, an MQTT message is published to a topic in the MB with sensor data.
public void run() {
dhtSensor.read();
float temperature = dhtSensor.getTemperature(false);
int humidity = dhtSensor.getHumidity();
try {
String message = "Temperature:" + Float.toString(temperature);
String humidityMsg = "Humidity:" + Integer.toString(humidity);
mqttClient.publish(1,message.getBytes());
} catch (MqttException e) {
e.printStackTrace();
}
}
The role of WSO2 MB
The message broker is responsible for delivery of messages to subscribers of the MQTT topic. Other than MQTT support, WSO2 MB also provides AMQP capabilities and persistent and non-persistent messaging. WSO2 MB is highly scalable and supports elastic scalability.
The role of WSO2 CEP
WSO2 CEP is the under-the-radar detector. To put it simply, it’s one way to handle changes in data in real time. WSO2 CEP takes messages as input for data streams through a subscription. An MQTT adaptor is used to communicate with the message broker, which provides subscription and publishes features. Next, we have created an execution plan in the CEP to run a query on the input data stream. The CEP uses an SQL like language called Siddhi. Our query looks like what’s shown below:
from newmqttstream select convert(Temperature, double) as temperature insert into inStream; from inStream[temperature > 30] select "ON" as notification insert into mqttout1; from inStream[temperatureIn the above Siddhi query there are three streams:
- newmqttstream
- inStream
- mqttout1
The raw data stream is the newmqttstream. From this, we filter and obtain the temperature value as a double (this is because Humidity is also sent in the same data stream) and we insert that data to inStream. Thereafter, we check if the temperature in inStream is larger and or equal to 30. If so, we write “ON” signal to the mqttout1. The same happens to the “OFF” signal.
When the signal is written to the output stream (mqttout1), it triggers the earlier mentioned MQTT adaptor to publish the signal as an MQTT message to a topic.
Agent on device for actuator
The agent is subscribed to the previously used topic. Once a signal message arrives to the Actuator Raspberry Pi, it will perform the relevant action.
- ON - Set GPIO pin status to High
- OFF - Set GPIO pin status to Low
public class Receiver{
final GpioController gpio;
final GpioPinDigitalOutput pin;
{
gpio = GpioFactory.getInstance();
pin = gpio.provisionDigitalOutputPin(RaspiPin.GPIO_00, "Relay");
}
public void run(String message){
System.out.println("Message received "+message);
if(message.equals("ON")){
pin.high();
}else if(message.equals("OFF")){
pin.low();
}
}
}
The role of WSO2 EMM
WSO2 EMM was improved to handle the management of Raspberry Pi devices. Our agent runs periodically and it sends device information to EMM. This operation happens through HTTP protocol as WSO2 EMM currently supports HTTP protocol for receiving payloads from devices.
A sample payload looks like the image depicted in Figure 3.
{
"memory_info": {
"sdram_p_volate": 1.23,
"sdram_c_volate": 1.2,
"used_memory": 150163456,
"shared_memory": 0,
"total_memory": 459505664,
"sdram_i_volate": 1.2,
"cached_memory": 100642816,
"memory_buffers": 15024128,
"free_memory": 309215232
},
"hardware_info": {
"is_hard_float_abi": true,
"cpu_temperature": 50.3,
"cpu_core_voltage": 1.2,
"board_type": "ModelB_Rev2",
"hardware_revision": "000e",
"mips": "00000000f6c4aa70",
"processor": "ARMv6-compatible processor rev 7 (v6l)",
"cpu_revision": "",
"cpu_part": "0xb76",
"cpu_architecture": "7",
"serial_number": "00000000f6c4aa70"
},
"network_info": {
"nameserver": [
"192.168.1.1"
],
"ip_address": [
"192.168.1.3"
],
"hostname": "raspberrypi",
"fqdn": []
},
"java_info": {
"java_vm": "Java HotSpot(TM) Client VM",
"java_vendor_url": "https://java.oracle.com/",
"java_vendor": "Oracle Corporation",
"java_runtime": "Java(TM) SE Runtime Environment",
"java_version": "1.7.0_60-ea"
},
"clock_info": {
"dpi_frequency": 0,
"vec_frequency": 108000000,
"pixel_frequency": 0,
"arm_frequency": 700000000,
"uart_frequency": 3000000,
"emmc_frequency": 100000000,
"pwm_frequency": 0,
"core_frequency": 250000000,
"h264_frequency": 0,
"v3d_frequency": 250000000,
"isp_frequency": 250000000,
"hdmi_frequency": 0
},
"os_info": {
"os_name": "Linux",
"os_architecture": "arm",
"os_firmware_build": "4f9d19896166f46a3255801bc1834561bf092732 (clean) (release)",
"os_firmware_date": "Sep 1 2013 23:31:02",
"os_version": "3.6.11+"
}
}
A registered IoT device to WSO2 EMM will have a dashboard that displays information and sensor data as shown in Figure 5.
Figure 5
Both Raspberry Pis were enrolled to the EMM server. From the EMM server, we can operate the actuator attached to the second Raspberry Pi as illustrated in Figure 6.
Figure 6
Figures 7 and 8 are some visuals of the actual demo.
Figure 7
Figure 8
Further work
Through our demonstration unit, we discovered many points to base future work on. For example, the dashboards the EMM currently shows will have to be generic to work on different types of data streams that will be published from agents. Right now, the fixed dashboards was our starting point.
Another important aspect in IoT devices is Mesh Networks. This includes MQTT-SN and ZigBee style communication. This involves having multiple dumb devices connected to a hub device that is more intelligent. This gives us the power to run complex event processing on the edge rather than publishing all data.
Another part is to write an agent in Python, which allows easy installation on Raspberry Pi devices. This makes it more lightweight than the current Java-based agent because the de facto ways of accessing hardware on Raspberry Pi’s is via Python.
For EMM 2.0.0, we plan to introduce the concept we discovered through our IoT demo, plugging any type of device that needs management. This requires understanding the generic components in all device management and making an extensible framework for device management.
Conclusion
IoT is an evolving subject. New innovations keep flowing in each and everyday. Our effort was to isolate the major components and build a reference architecture where new innovations can plug into. This involves layers of architecture for different requirements, i.e. aggregation and bus layer, API management, analytics, device management, etc. This will allow us to build ‘connected things’ for consumers. And what’s connected things? They can be referred to as components connected to the internet performing an intelligent action/routine.