SMART-IO

Abstract

This article explains how to engineer an IoT on Edge solution, a multisensor scenario with a wide range of communication protocols. The solution proposed is about an implementation of the complete stack to satisfy hardware and software requirements needed for IoT with massive data exchange. The engineering samples proposed is a unique System On Module (SOM) or MultiProcessor System On Chip (MPSoC) solution based on Xilinx Zynq family which allows to manage a high data throughput and low latency when it comes to data processing.

Statement of the problem

The evolution of IoT to modern days has enlightened the necessity complex hardware solutions to satisfy the high throughput of data coming from the sensor to be processed with low latency where the data is collected, to avoid massive data transfer to the cloud server. 

The hardware, then, must not be able just to manage some network or sensor interfaces, but also to provide a high compute capability, i.e. fit the data collected from the sensor with a trained model or providing high quality cybersecurity with big encryption keys.

The cloud services chosen for this project are Microsoft Azure services. Azure is a cloud computing service which offers to the end-user a wide range of services, from the classical storage utilities to also machine learning services.

The engineer sample was chosen to be based on two different FPGAs, the Microzed 7010 plus Arduino Carrier Board and the Ultra96, both based on the Zynq family. The first board is a SOM, where you have the Carrier board extending the Microzed interfaces, and is part of the Zynq-7000 family. The second board is a MPSoC, part of the Zynq UltraScale+ family. The Programmable Logic (PL) of the board has been mainly used for the embedded of the project, because of its versatility and easy integration with the I/O peripherals. Also, having the I/O managed by the PL, it becomes very easy to integrate machine learning algorithms in the process.

Progresses

Physical Architecture

We now dig a little bit in the architecture details, explaining the hardware and software stack used. Here below a simple view of the setup:

System Architecture for Ultra96
System Architecture for Ultra96

The pivotal component in this project is represented by the Ultra96 board because it is responsible for both intra/inter-net events management.

The board can be divided into two main components, the Processing System (PS), which is the part managed by the CPU, and the PL side, where the hardware reconfigurable part lies.

The PS was selected to manage the internet connection and the backend/frontend part, which would be explained later. 

The PL part manages directly the I/O and the operations performed on the data collected from the sensor. 

According to the project goals, the network connection is assured by the use of two different channels. The first interface is ethernet and is directly accessible on Ultra96, whereas the wifi interface is provided by an external module of ESP-IDF

The communication between the ESP and Ultra96 is granted by the pmod adapter.   

We have then the PMOD adapter TEP00006-001, which converts the 40 header pins of the Ultra96 into 3 PMODs, one the PMOD was chosen to be the one which communicates with the Modbus PMOD, using UART protocol. The I2C was connected using the pins already existing. Here below the physical setup:

 
Physical Setup of the board

For what concerns the other board, the Microzed, we used the same architecture:

System Architecture for Microzed 7010

As it can be seen the structures are really similar to each other, so the PS manages internet connection and backend/frontend, whereas the PL manages the I/O from peripherals and data manipulation. Here below the physical setup of Microzed:

Physical setup of Microzed

Hardware Architecture

The PL side of the boards had been reconfigured in such a way that he can be interfaced with the various pins and communication protocols. The process was done using the GUI interface of Vivado and worked directly on the block design using the Xilinx LogiCORE suites. 

The LogiCORE suite offers blocks which already implement the protocols needed for this project, or rather, I2C, UART and a block for GPIO management. 

To connect all the blocks with the board and between themselves we used the AXI interconnection, a gold standard protocol of communication used in hardware. 

To set the pins for I/O peripheral data management we set the constraint file to interface the pins to the block which implement their communication protocol respectively.

Here the block design for ultra96 with its constraints:

 
Block Design of Vivado for Ultra96
Constraints of Vivado for Ultra96
Constraints of Vivado for Ultra96
Addresses of Vivado for Ultra96
Addresses of Vivado for Ultra96

Here the block design for Microzed7010 with its constraints:

Block Design of Vivado for Microzed 7010
Block Design of Vivado for Microzed 7010
Constraint of Vivado for Microzed 7010
Constraint of Vivado for Microzed 7010
Addresses of Vivado for Microzed 7010

Software Architecture

This part is managed by the Processing System (PS). The duties of this portion of the project is to manage the internet/cloud connection, the access point provided by the ESP32 and the demonized processes by pm2 for communication with PL and backend/frontend software stack.
Everything except the frontend, which is based on NodeJS, is written in Python.
To interface the PL side it was chosen to use a python framework called PYNQ. This library allows the user to simply access the PL side using very simple Python calls, allowing to integrate hardware functions in software projects, like this one. Link: http://www.pynq.io/
The other processes can be divided in three sections:

  1. Backend server: we built a little Flask server, which receives GET and POST methods to send or receive some information. The server stores the current state of the configuration of the sensors every time there is a POST in a JSON file. This last job is very important in offline configuration to update the frontend.
  2. Communication with Azure: in the configuration is fundamental to exchange data with the cloud, and so if the board is online, there are two processes, one for sending data and one for receiving the data from the cloud.
  3. Frontend: this part is fundamental for what concerns the user experience, so we built an interface which aims to be together the most explanatory and the most easy to use possible.

We create two types of interfaces, one for the offline portion and one for the online portion, both of them with a login homepage.

Online dashboard interface
Online dashboard interface
Offline dashboard interface
Offline dashboard interface