22 Int. J. Grid and Utility Computing, Vol. 8, No. 1, 2017

Copyright © 2017 Inderscience Enterprises Ltd.

Design and implementation of IOT gateway based on embedded μTenux operating system

Xiaofeng Yao* and Lei Wang School of Electrical and Information Engineering, DaLian JiaoTong University, No.794 Huanghe Road, Dalian City, China Email: yxf811@163.com Email: 529791672@qq.com *Corresponding author

Abstract: Among the three layers of the Internet of Things (IoT), perceptual layer and network layer belong to the heterogeneous network, which can’t communicate directly; they need an IoT gateway to realise the communication protocol conversion between the two layers. Because the gateway does not have a unified standard in the field of IoT, the gateway of each manufacturer has certain limitations. In this paper, combining actual gateway requirements definition in the network, small intelligent gateway was accomplished based on an OSI model that integrated ZigBee and TCP/IP protocols. The gateway provides Wi-Fi control interface for the user, and supports OTA, risk management and behaviour analysis operation etc. The STM32F439NI development board of ST company was adopted as the test platform, and the test was completed through cooperating with the Wi-Fi module and the ZigBee module. The results indicate that the design has better stability and higher performance.

Keywords: IOT gateway; OS; μTenux; μT/studio.

Reference to this paper should be made as follows: Yao, X. and Wang, L. (2017) ‘Design and implementation of IOT gateway based on embedded μTenux operating system’, Int. J. Grid and Utility Computing, Vol. 8, No. 1, pp.22–28.

Biographical notes: Xiaofeng Yao is currently an Associate Professor of DaLian JiaoTong University. He has received his BSc and MSc degrees from same university in 1997 and 2003, respectively. His research interests include CAN FieldBus control system, and Internet of Things.

Lei Wang is currently working as a network engineer in Ericsson GSC China. He has received his BSc degrees from the North University of China in 2009 and MSc degrees from DaLian JiaoTong University in 2014. His research interests include IP-networking, micro-operation system and Internet of Things.

1 Introduction

The Internet of Things (IoT) was the network that made the internet as the basis and core, which extended to all the items and complete the information exchange. The IoT can be divided into three levels: perception layer, network layer, application layer (Sun and Liu, 2010; Luo and Zhou, 2011; Wang, 2011). At the end of the IoT, the perceptual layer contained a variety of terminal local area networks (e.g. ZigBee network), which were composed of various sensing devices, executive device, and its functions were information collection and controllable operation. The network layer contains a lot of backbone transmission network (such as internet, GPRS etc.), which was responsible for data transmission and control between

perception layer and application layer, and it relied on the existing private or public, wired or wireless network, network management services and cloud computing ubiquitous network platform. The application layer includes business management network, which was the direct interface used to provide services for user. Among the three level of the IoT, perception layer carried a large number of network nodes, it cannot communicate with network layer directly, so it needs a IoT gateway to realise the communication protocol conversion between the two layers. Because the gateway does not have a unified standard in the field of IoT, so the gateway of each manufacturer has certain limitation. At present, most gateways used in the intelligent system are special equipment, and trade protection has also increased the R&D cost and production

Design and implementation of IOT gateway 23

cycle (Chen and Han, 2011; Qiu, 2013). In this paper, small intelligent gateway was accomplished based on OSI model and which integrated ZigBee and TCP/IP protocol, the open software and hardware platform framework of gateway was built in this paper, and µT/Studio compiler environment was constructed through applying the Eclipse and GCC/GDB tool chain based on ARM Cortex M3/M4 architecture and embedded real-time µTenux OS, and at the same time, transplant method of TCP/IP, GUI, FatFS middleware based on the kernel were proposed. Test results indicate that µTenux operating system and middleware have high performance and the gateway based on ZigBee and TCP/IP has better stability.

2 Design of IOT gateway open platform

2.1 GW-open platform

The GW-Open Platform framework was shown in Figure 1 (Wang, 2011; Zou, 2011; Zeng and Han, 2011). The ARM Cortex was adopted in the hardware architecture, ARM CMSIS C Lib was the standardised code offered by ARM Company, and manufacturer will make the chip to adapt the CMSIS interface definition according to this specification (Li, 2013; Ma, 2010). μT/OS and μT/Lib were the code core of μTenux, together with ARM CMSIS C Lib, Standard C Lib and Midware, constitute μTenux operating system architecture. GW-Open Platform adaptation layer based on the μTenux framework can be regarded as the interface layer of gateway, which integrated the API interface, embedded operating system interface and middleware API firstly, and then removed the useless API, finally optimised and unified interface definition, thus provided service for upper IOT application. The μT/Studio was adopted as the cross compiler environment in the framework of GW-Open Platform; IOT Gateway Solution was the application layer of the GW-Open Platform system structure.

2.2 Gateway solution based on the interconnection of ZigBee and ethernet

The gateway based on GW-open platform proposed in this paper followed the Gateway Specification of ZigBee Alliance, and the overall gateway solution is shown in Figure 2. In the figure, the expression layer protocol SOAP, REST and GPIP that provided by ZigBee protocol stack were all remote interface. ZigBee module with SPI interface and integrated protocol stack was selected in this design. Application layer of TCP/IP protocol contains the expression layer and session layer, so the figure marked as default, it should be designed through adopting the expression layer and session layer protocol that equivalence to ZigBee according to the actual remote control device and the application mode.

Figure 1 GW-open platform architecture

 

IOT Gateway Solution

GW-Open Platform Adaption Layer

Midware

μT/OS μT/Lib

ARM CMSIS C Lib

 

Standard C Lib

μT/Studio

GCC

Eclipse

ICE

J-LINK

Systick

NVIC JTAG

External Extension Modle

Ethernet UART SPI

Wi-Fi Modle

Cortex Core

Figure 2 ZigBee/TCP/IP gateway solution

ZigBee/TCP/IP Gateway Solution OSI Model

Application layer

Expression layer

Session layer

Transport layer

Network layer

Data link layer

Physical layerZigBee Model

Ethernet Model

ZigBee

Protocol Stack

TCP/IP

Protocol Stack

APS/ZDO/ZCL/COM

M

SOAP/REST/GRIP

Application layer

Default

2.2.1 ZigBee network access

STM32W108CB module was adopted as the ZigBee module in this design, the module was integrated with the ZigBee coordinator application and Ember protocol stack, and it connects with the gateway platform through SPI interface.

2.2.2 The ZigBee and TCP/IP protocol fusion

Fusion of ZigBee protocol and TCP/IP protocol was completed in the expression layer from Figure 3. Two different patterns should be selected in this design according to different data flow. Mode 1: receive data from the

24 X. Yao and L. Wang

ZigBee, and sent to the Ethernet. Mode 2: receive data from the Ethernet, and sent to the ZigBee. The gateway would send the parsed data to ZigBee coordinator by the way of bit stream through SPI interface.

Figure 3 Gateway software level-dependency relationship

GW-open platform

Uniform API

Midware API

GW-open platform adaption layer

IwIP/em Win/FatFS  

application solution 

μT/OS

CMSIS IF Per IF

CMSIS BSP

μT/OS API

Gateway Application Solution

netif//GUI/DiskIO

Driver interface

2.2.3 TCP/IP network layer access

TCP/IP server would start and be ready to receive the external data request after the device initialises. When ZigBee data request happened, first determine the type of ZigBee data request, and then transmit information through the UDP client when security circumstances permit. IOT Gateway should provide TCP/IP server and client mode in the normal condition, but the application based on two kinds of modes was separate. Software interrupt operation of system will periodically check the state of TCP/IP server.

2.2.4 Gateway management

Gateway stores static data on the basis of file system, it concluded temperature and humidity information gathered by ZigBee node, some gateway factory information, and system key etc. The gateway extends Wi-Fi module through

the UART interface, Wi-Fi module uses station protocol, and mobile phone communicates with the gateway by Wi-Fi, Gateway would run other tasks normally without influence during the period of parameter setting, different strategy would be adopted according to the different parameters security level. In addition, remote management through Ethernet was also allowed, and gateway provided the basic parameters that Web server interface required.

3 The software design of IOT gateway

The overall software structure of IOT gateway was given out through adopting the embedded operating system and hierarchical software design thought, and then, the software design from top to bottom in all levels was realised, finally, the packaging of the entire framework of GW-Open Platform was completed, and the specific application solutions of ZigBee and TCP/IP network convergence were implemented.

3.1 The overall software structure

The overall software structure of IOT gateway is shown in Figure 3. The software dependency relationship was described as follows: because the gateway was designed based on the embedded μTenux operating system, so transplant of its μT/OS kernel should be completed first of all. TCP/IP protocol stack, touch screen control and file system management relies on peripheral interface provided by μT/OS and the board support package. GW-Open Platform Adaption Layer integrated the API resources of operating system and middleware, which provide uniform interface for upper applying and complete the package of the GW-Open Platform. The software structure reduces the software coupling at all levels, which made it easy to upgrade and replacement the individual components.

3.2 Transplantation of µT/OS kernel and middleware

3.2.1 Transplantation of µT/OS kernel

Many adaptive optimise to the system kernel was conducted by μT/OS, when the kernel was transplant to Cortex M architecture, the work concentrated in the system clock, flash, watchdog, the GPIO and the serial port initialisation. The main work is shown in Figure 3.

1 Makefile modification

2 Config file configuration

3 System clock initialise

4 FLASH initialise

3.2.2 Transplantation of middleware

Middleware was a software package with special function, such as network, graphics, USB, file system. Middleware

Design and implementation of IOT gateway 25

can utilise some characteristics of operating system to improve the ability to process information and enhance the real-time performance. Middleware of GW-Open Platform provide IP communication support through using the network function, graph GUI provide touch screen display, the file system provides static parameters storage and configuration. The main work was shown as follows:

1 Transplantation of network middleware: lwIP (lightweight IP) designed by Adam Dunkels was adopted as Network middleware, the protocol stack achieve a variety of network protocols such as IP, ICMP, UDP , TCP, IGMP, ARP, PPPoS, PPPoE; DHCP, DNS client;AutoIP/APIPA and SNMP agent can also be achieved. lwIP has friendly interface, Transplantation of lwIP and μT/OS related code were all locate in Sys_arch.c function of simulation layer in the operating system, This involves the transplantation of operating system tasks, mailbox, semaphore and time management (Wang, 2014).

2 Transplantation of graphic middleware: emWin component of Segger was adopted as Graphic middleware based on GW-Open platform. EmWin provides the typical driver package, it generally need to modify the address about the memory management area of emWin in GUIConf.c file , it required to realise two interrupt function (DMA2D and LTDC) in the LCDConf.c file.

3 Transplantation of file middleware: Gateway has the function of data acquisition and management, and file system would organise these data for the convenience of searching and storing. File system includes create, delete, read, write, search, encrypt and other basic operations. The design adopted the open FatFS source file system, transplantation of FatFS need three files, this design apply the NandFlash file management system, the underlying NandFlash partition take 2K bytes for an erase lock. Diskio.c Put 2K bytes into four sectors, each new file occupies 512 bytes. In order to make full use of the sector, it required to estimate the contents of the file when the upper application management files through the file system, or adopt the necessary strategy to store multiple parameters uniformity in one sector.

3.3 Implementation of GW-open platform adaptation layer

Adaption layer of GW-open platform was the middle structure between the μTenux operating system and the solution, which provide the API for the upper application, the adaptation layer re-encapsulate the interface function and counted all the resources mechanisms the platform used. Adaptation layer adopts 131 API of μT/OS such as the task scheduling, message synchronisation, memory management, etc., 9 associated lwIP network configurator API, 37 relevant emWin graphics API, 11 related file system API. The interface provides perfect support for gateway development scheme based on GW-Open Platform.

3.4 Design of gateway application layer software

It should carry on the division of function module firstly for the software design of IoT gateway, and then the task allocation should be completed according to the function. From the demand analysis of ZigBee and TCP/IP gateway, the design should include the following modules: the main control, display refresh, touch screen response, ZigBee receive, ZigBee transmission, Ethernet receive, Ethernet transmission, Wi-Fi management, risk management and detection, periodic processing. Each module existed as an independent task, the higher the priority the smaller the number in μT/OS (Hong, 2012).

3.4.1 The main task

The main task was the first task after the system start, which has the lowest priority in addition to the default system background tasks. It mainly complete the start of other tasks and monitoring of important events. The main task firstly judge whether it required to restore image data, if illegal power down or restart caused by abnormal program interruption happened at the last operation process, image data restore can ensure the gateway running in the final steady state. The function of boot loader and task start would be finished in the implementation process zone. If the OTA program needs to be loaded, the mark of the global variable should be set. Subsequent processing would be executed after judge it was Wi-Fi or Ethernet loading. RAM space releasing made well initialisation preparation for file storage and stack application. Touch screen refresh task will be triggered firstly when the gateway task start, In order to monitor Ethernet request, it should establish a gateway server, then call network interface that network adaptive layer provide, it communicate with ZigBee module through SPI interface. The Wi-Fi module received the data through the serial port, at the command the module establish a Wi-Fi Station and monitor Wi-Fi connection. At through the serial port, at the command the module establish a Wi-Fi Station and monitor Wi-Fi connection. At the same time, task management function of adaptive layer would be called to create other tasks. When the task was started, the main task has the lowest priority, which will be grabbed immediately by the higher priority tasks.

Only during the task idle cycle, the main task can be reactivated. Global state register values will be determined at this time, channel was switched and corresponding processing was also executed according to the current state. Tasks will be activated immediately when the corresponding event markers were triggered in each channel, otherwise. The main task will be in a NOP loop that was used to monitor global variables.

3.4.2 Design of data transceiver module

According to the behaviours analysis of the gateway, the gateway has two main data channels, one in which data

26 X. Yao and L. Wang

comes from Zigbee_in_task and then is sent out via Ethernet_out_task; the other in which data comes from the Ethernet_in_task and then is sent out through the Zigbee_out_task. The two channels were reversible, and the operation was similar too, so only the second cases are described in this paper.

After the main task create the other task module, because the priority of data transceiver module was second to the display refresh operation, so the data transceiver function will be started firstly when the screen display was completed.

When Ethernet_in_task was activated, first, data storage space will be applied by the way of fixed size memory pool. Then create and wait the event flag. When the Ethernet interrupt or periodic task occurs and one of the two kinds of Ethernet data was detected, the task was activated again to running, received the data and stored in the p_buf data structure. The Ethernet_in_task diagram was shown in Figure 4. If it need send request to node through ZigBee, then the Zigbee_out_flag event flag will be triggered. The Zigbee_out_task diagram was shown in Figure 5.

Figure 4 Ethernet_in_task diagram

Start

 Judge whether the Ethernet event flag was set?

Apply receive-data buffer

Trigger zigbeeflag event Trigger ethernetflag event

Receive the data

Create event flag

 Judge data type?

Y 

ZigBee

data

N 

Management

Command

Protocol conversion Command response

Figure 5 Zigbee_out_task diagram

Start

Judge whether the Ethernet event flag was set?

Apply transmit-data buffer 

Transmit the zigbee data

Create ethernetoutflag event flag

Y 

N

Data transmission does not need protocol conversion, when the event flag was triggered, data was send out from the specified port. the process that request uttered firstly by a ZigBee node was the inverse process of above process, The only difference was data from the ZigBee must be send out only through the UDP interface, at this time, as the client, the gateway needs to connect the external device. When the data request entered first from external, gateway was used as a server. So it needs to judge which pipeline should be used according to the transfer state in the Ethernet transmission process. The important data were all stored in the global status unified in this design.

3.4.3 Design of other module

Display refresh processing (Gui_out_task) only needs call a window redraw function, the display screen will be forced to refreshed when switched the task. The redraw function would monitor the redraw event marks.

Touch screen response (Touch_in_task) was mainly used in the circumstance of parameter configuration, the task has the lowest priority by default, but the priority can be upgraded dynamically when it required to connect a Wi-Fi device or to conduct remote configuration.

Soft interrupt, the task was awakened according to the time limit that each task need. Periodic treatment has the highest priority, wake up once each 50 ms. As the existence of periodic processing, so it need not worry about the deadlock or blocking of transceiver interface during task switching, periodic processing would repair and abandon the original operation promptly.

Design and implementation of IOT gateway 27

4 System test of IOT gateway

4.1 The hardware test platform

Test platform includes many hardware objects: main control module: OEM development board STM32F439; ZigBee module: STM32W108CB;Wi-Fi module:EMW3162 module of MXCHIP; ZigBee module connect with the main control module by SPI interface, Wi-Fi module connect with the main control module by UART serial interface. STM32F439 integrates LCD control module. OEM development board integrates network control chip DP83848 and JTAG interface. DPS3S48 chip provides MAC layer and interface of Ethernet, the specific connection is shown in Figure 6.

Figure 6 Hardware platform

ZigBee Modle

Wi-Fi Modle

STM32F439NI

Ethernet interface

JTAG

4.2 TCP/IP network simulation layer test

In order to detect whether the underlying network driver can work properly, the running state of ARP, ICMP, IP and TCP protocol should be tested. Writing a WEB interface with HTML language in the case one directory, automatically connecting and displaying the WEB interface would be conducted after the running of script on the PC, it can be proved that the TCP/IP network protocol stack runs normally if the WEB interface was displayed correctly, at the same time, the validity of ARP, ICMP, IP and TCP protocol was examined too.

4.3 File system test

In order to detect whether the file system can work normally, which need to inspect some basic function, such as create, delete, search and other operation. First, PC sends the commands used for system detection, and then, the gateway returns the testing data of file system to PC through the serial port. File system testing was the self-inspection script that stored in the internal storage of gateway in advance, the running state of the file system can be detected through creating new files and automatically reading and writing operations. The test results indicate that the file system can run normally, the driver of the underlying SDRAM was normal too.

4.4 Static resource test

The gateway provides GRIP/SOAP/REST interface request service for outside world, the static data that would be read was stored in a resources directory. When the outside sending http URL, for example: http://192.168.0. 110:1792/ restifc/zgd/version, the data would be read and return by the gateway from the zgd/version. Test results show that the static resources were available and free to read in the gateway system. Users can also send direct URL requests and view the specific content in the resource directory.

4.5 Connection test

The connection between Ethernet and ZigBee network has been verified indirectly in the previous test, this section focuses on the connection between Wi-Fi and intelligent equipment. Open the Wi-Fi interface in mobile phone which uses Android system, IP address was 192.168.0.99, port number was 2014, Slave ID was 1, gateway address was 192.168.0.110. The current state of gateway would be read after the test platform sending the command. The state would be rewritten in the corresponding document when the gateway was in the interior initialisation or the connection state switching happened. When the PC needs to view the connection status, the gateway just need to find the appropriate file and returned the parameter to PC. Test results indicate that the gateway interface connection was normal.

4.6 Protocol conversion test

The main function of gateway was protocol conversion between ZigBee and TCP/IP, this test adopts the gateway testing platform that introduced above, the data was write from the PC, and the GetVersion command was sends out in order to read the ZigBee version information. During the test process, the data was input firstly through the TCP/IP protocol, and then, the related parameters of gateway was configured by ZigBee coordinator, and finally, the data was read through the PC, and the conversion from the ZigBee protocol to the TCP/IP protocol was completed. The test results shows that data conversion was correct.

4.7 Communication distance and delay test

IOT gateway obtained the field data through the routing node, two Zigbee nodes were selected to complete the test, one of them sends data as the terminal node, and another forward data to the gateway. The test parameters was shown as follows: communication channel: 11 (2405 MHz), transmit gain: 4 dB, number of packets:1000, emission rate: 50 bps, test sites: the square in front of the teaching building., 1000 packets were sent out at intervals under barrier-free environment in the test, the distance from the routing node to the gateway and the packet loss rate were shown in Table 1, when the distance increases to 55 m, the packet loss rate reaches to 1% (according to documents provided

28 X. Yao and L. Wang

by TI, RF signal sensitivity threshold limit was 1%). So the wireless transmission distance should be restricted within 55m under barrier-free environment.

Table 1 Accessibility distance test

Communication range (m) Packet loss rate

5 0/1000

15 0/1000

20 1/1000

30 2/1000

55 10/1000

Time delay refers to the time interval from the serial port reading a complete data to the completion of the forwarding data. In this test, we place 10 sensor nodes. The data transmission period is 5 seconds. In the experiment, we calculate a delay time when the gateway forwarding 1000 data packets, the average delay of the 10 experiments is 10.15 ms, which is far less than the CCSA standard (100 ms).

5 Conclusion

In this paper, IOT gateway open platform was built based on ARM Cortex M3/4 chip and the μTenux operating system, the platform provides perfect API support for application layer and the packaging protection for underlying protocol. Lots of in-depth research had been done to the transplant method of μT/OS kernel and various functional components, and the constructional process of μT/Studio environment and the overall design of GW-Open Platform framework were all gave out. The connection test, protocol conversion test and the communication distance and delay test results show that the gateway designed in this paper based on above software and hardware platform has better performance, which can be applied in the ZigBee and TCP/IP protocol conversion system.

Acknowledgement

This work is supported by the Education Department of Liaoning Province (L2015100).

References

Chen, Q. and Han, B. (2011) ‘Design and implementation of the IOT gateway based on ZigBee GPRS protocol’, Journal of Computer Research and Development, Vol. 48, No. 3, pp.367–372.

Hong, Y. (2012) ‘The application of embedded system based on ARM’, Microcomputer Information, No. 32, pp.27–29.

Li, Z. (2013) STM32 Embedded System Development Practical Guide, China Machine Press.

Luo, J. and Zhou, Y.(2011) ‘Design for gateway system in Internet of Things’, Telecommunications Science, No. 2, pp.105–110.

Ma, Z. (2010) ARM Cortex Microcontroller Tutorial, Beihang University Press.

Qiu, M. (2013) ‘Design and evaluation of general industrial IoT gateway’, Communications Technology, Vol. 46, No. 3, pp.58–70.

Sun, Q. and Liu, J. (2010) ‘Internet of Things: summarize on concepts, architecture and key technology problem’, Journal of Beijing University of Posts and Telecommunications, Vol. 33, No. 3, pp.1–9.

Wang, L. (2014) ‘lwIP porting on real-time operating system μTenux’, Microcontrollers & Embedded Systems, No. 3, pp.5–8.

Wang, T. (2011) ‘Hetrogeneous information integrations from internet ofthings based on PML and Hedge automata’, Journal of SouthEast Unibersity (Natural Science Edition), Vol. 41, No. 2, pp.301–304.

Zeng, G and Han, X. (2011) ‘Wireless heterogeneous network convergence scheme based on mode awareness’, Journal of Nanjing University of Posts and Telecommunications (Natural Science), Vol. 31, No. 3, pp.14–20.

Zou, J. (2011) ‘An open architecture for converged Internet of Things’, China Communications, No. 1, pp.151–155.