Android Based Edge Computing Gateway : Design and Architecture
Note:- If you are new to Edge Computing , you can go through the blog — “Edge Computing for Data Driven IoT” to get a basic idea on what Edge Computing is. In order to get an overview idea on the Android Edge Computing Gateway, how this gateway is connected with WSO2 IoT Server and how to set-up this Edge Gateway, you can refer — Android Based Edge Computing Gateway for WSO2 IoT Server : Overview.
Understanding the Requirements
As shown in Fig. 1, there can be multiple Edge Computing Gateways connected to an IoT Server. These Edge Computing Gateways may be based on different platform such as Android, Linux, Yocto etc.
As shown in Fig. 2 , there can be multiple devices connected to an Edge Computing Gateway. When there is a need to add a new device to an Edge Computing Gateway, there should be no requirement to change the Source Code or the Implementation at that Edge Computing Gateway.
That is because it will be infeasible to change the implementations and source codes of each and every Edge Computing Gateway when large number of Edge Computing Gateways are connected to an IoT server (Hundreds or thousands of Edge Computing Gateways can be connected to a single IoT server).
Therefore, there should be a proper mechanism which will allow an IoT Server to control the behaviors of Edge Computing Gateways which are connected to that IoT Server. In other words, the IoT server should be able to change the configurations which control the behavior of an Edge Computing Gateway (which is connected to that particular IoT Server).
Therefore we can list the requirements which should be considered when developing the Android Edge Computing Gateway as follows.
1. The Android Edge Computing Gateway should be able to dynamically detect new devices and receive input data from those devices. The burden of changing the Android Implementation (Android Source Code) every time a new device was added (in order to detect the device and event streams of the device) should not be there in the Android Edge Computing gateway.
2. The Android Edge Computing Gateway should be able to support Edge Devices which sends data in multiple different data formats (JSON, Text Message, Comma Separated values, just the value etc.). Check Figure 3.
3. The Edge Computing Gateway should be able to process the event streams received by the connected edge devices in real time and should be able to make decisions based on those streams.
The mechanisms in which the events are processed may change from time to time. Therefore, the data processing mechanisms should be easily configurable.
4. The Output Event Streams which comes as the results of processed input event streams should be dynamically published into the relevant MQTT topics in the WSO2 IOT server.
New devices can be connected to the Edge Computing Gateway and new event streams will be needed. Therefore, the process of publishing data should be dynamical.
The burden of changing the Android Implementation of each Edge Computing Gateway whenever a new event stream is created for a device or when a new MQTT topic was added to WSO2 IOT server should not be there.
5. There are alert messages to be shown within the Android Edge Computing gateway.(eg: If AC is ON while a Window is open in a smart home, an alert can be shown in the TV screen of the smart home if those devices are connected to a common Edge Computing Gateway).
These alerts should also be easily configurable and the burden of modifying Android Implementation at the Edge Computing Gateway level to show a new alert should be eliminated.
6. Data caching mechanisms should be provided in the Android Edge Computing Gateway.
Design and Architecture
Considering the above mentioned requirements, the architecture was developed for the Android Edge Computing gateway. The High Level Architecture diagram of this Edge Computing gateway is shown in Figure. 3.
As shown in the diagram, this Android Edge Computing Gateway is designed to support lightweight Edge Devices which are sending data in multiple data formats, processed the receive data, publish necessary data to the IoT server and to persist necessary data inside the Edge Computing Gateway.
As shown in Figure 3, WSO2 Siddhi is run inside the Android Edge Computing Gateway. Actually all the functionalities related to Siddhi arecontrolled via the Siddhi App which is running in the Edge Computing Gateway Android App. Siddhi App is actually a String variable (just a text) which is written according to Siddhi Query Language.
A Siddhi App with relevant configurations can be sent to the Android Edge Computing gateway from the IOT server as a text message .
The Siddhi App which was sent by the IOT server can be saved in the Edge Computing Gateway. Then, that Siddhi App which was saved in the Edge Computing Gateway can be executed within that Edge Gateway.
The design was to use WSO2 Siddhi v4.0.0 inside the Android Edge Computing Gateway for following purposes., so All the behaviors described below can be handled by changing only the Siddhi App (Siddhi Query).
1. Detect inputs and data send by connected edge devices. Even if a new device is connected, Siddhi App should be modifiable to detect inputs and data which are sent by that device.
2. Siddhi App should be able to convert the inputs received by edge devices (in different data formats, eg: JSON, Text) to a compatible format that can be processed using Siddhi Stream Processor.
3. Processing of the received event streams from edge devices and making decisions according to those events should be done using Siddhi Query Language.
4. Siddhi app should be able to publish the output streams to the relevant MQTT topics in the IOT server. The MQTT topic relevant to a particular output stream can be provided as a parameter to the Siddhi App.
5. Siddhi app should facilitate data caching mechanisms in the Android Edge Computing gateway.
When these features are provided by the Siddhi App, the necessary changes relevant to these behaviors of the Edge Computing Gateway can be done remotely by creating a new Siddhi App at IOT server and then, the created Siddhi App can be sent to the Edge Computing gateway from the IOT server.
Then the new Siddhi App will be executed inside the Android Edge Computing gateway providing the required behavior. As a result, there will be no need to do changes to the Android implementations and to the Android source code which is run in the Edge Computing gateways.
1. Android services are running inside the Android Edge Computing Gateway to capture the events and data send by edge devices. Then those incoming messages will be sent to Siddhi Sources.
2. Siddhi Sources were used to detect inputs and data send by Edge Devices. Customized Siddhi Source ‘TextEdge’ was implemented inside the Edge Computing Gateway. A customized source was created to provide Edge Gateway specific tasks using Siddhi Sources.
3. Siddhi Source Mappers were used to convert input data comes in any format (by edge devices) to Siddhi Events. Siddhi-Text-Mapper can be used to extract events from text message in any format (JSON, XML, comma seperated etc). Siddhi JSON mapper can be used if a device sends data in JSON format. Similarly, other Source Mappers can also be used according to the requirement.
4.Siddhi Queries were used to process input event streams and to take relevant decisions based on the inputs.
5. Siddhi Sink were used to publish data to relevant MQTT topics in the IOT server.
“Edge Gateway” Sink (a customized Siddhi Sink)
Customized Siddhi Sink “Edge gateway” was developed inside the Android Edge Computing Agent.
The “Edge Gateway” sink handle the data publishing mechanisms as shown below.
(i). Every instance of the “Edge Gateway” Sink will use only the default MQTT Connection in the IOT server. (This connection will be established when the Edge gateway Sign In to the WSO2 IOT server).
(ii). “Edge Gateway” Sink has a parameter to provide the name of the MQTT topic . The Sink will publish data to that topic.
(iii). “Edge Gateway” sink has a JSON mapping mechanism, so it can dynamically convert the published data to a format which is accepted by the relevant Event Receivers in the IOT server.
(iv). Edge Gateway sink has the capability to check whether the MQTT connection between Edge Computing Gateway and IOT server exists or not.
(v). Edge Gateway sink has a parameter to enable or disable data persisting mechanisms.
6. Siddhi event streams and stream callbacks were used to display alert messages in the Android Edge Gateway.
The events which will trigger alerts can be identified using a siddhi query and the relevant alert message can be sent as an event of the output alert stream. Addition of a new alert and the relevant alert message do not need any modification in the Android Implementation. Those configurations can be handled by modifying only the Siddhi App.
The Basic flow of Data inside the Edge Computing gateway is shown in Figure 4.
This blog described the requirements, design decisions which were considered while developing the Android Edge Computing gateway for WSO2 IoT Server. The way in which the design decisions were implemented was also explained at a abstract level. Next blogs in this blog series on Edge Computing will describe the implementation procedure in a detailed manner while going through the source code when necessary. Thanks for reading and hope you enjoyed this.