The key part of the system is the remote transmission and display of collected data. This system applies IPv6 technology to the embedded environment monitoring platform of the system and realizes node data visualization through an embedded web server. Taking into account the limited resources, real-time operation and data security of the embedded system, the realization of the IPv6 protocol stack and IPv6-based web server in the embedded system is the key technology of the system design. To enable nodes to connect to the IPv6 network and consume minimal resources, the system uses the LWIP protocol stack, which is a set of open source TCP/IP protocols for embedded systems developed by Adam Dumkels et al.30 of the Swiss Academy of Computer Sciences. To date, version 2.1.0 has realized the IPv4/IPv6 dual stack protocol. The lwIP implements the basic communication protocol, but to apply it to a specific system, targeted research is needed, including the porting of the hardware interface layer, realization of upper-layer applications, and joint debugging of the system. This system uses the lwIP protocol stack to access the IPv6 network, and on the basis of this protocol stack, it realizes the HTTP web server for the visualization of the environmental data collection.

Brief Introduction of the IPv6 Protocol in sensor networks

The IPv6 protocol was proposed to solve the problems of the IPv4 protocol. The IPv6 protocol stack is a well-established standard, which can be understood in related articles8,31.

The implementation of IPv6 in sensor networks is very different from those of general network protocol stacks. Table 2 gives the breakdown and detailed content of each layer in the IPv6 sensor network and TCP/IP protocol in the general PC and compares them with the OSI (Open System Interconnect) seven-layer model.

Table 2 Comparison of each layer of the IPv6 sensor network, TCP/IP protocol and OSI model.

As shown in Table 2, the TCP/IP protocol is simplified to four layers: the application layer, transport layer, network layer, and network interface layer. In the IPv6 sensor network, all layers except the network interface layer are implemented by a pure software protocol stack. The network interface layer in an embedded system is mainly formed by specific network peripherals and PHY control chips to control the transmission medium and data packets32.

IPv6 in the embedded system comprises software and a low-level configuration of hardware peripherals. It has four complete hierarchical functions and contains important components, such as ICMPv6, IPv6 message processing and TCP/IP communication. IPv6 lies between the real-time embedded operating system and the functional program, and its working position in the system is shown in Fig. 6. The embedded real-time operating system provides the basic service functions of thread management, thread synchronization and message transmission for the protocol stack. The upper application and the protocol stack are independent of each other. The application only needs to call the function to satisfy the functional requirement. Therefore, this layered design method is also used in the system to simplify the system design. Under different application requirements, it is only necessary to focus on the design of the upper-layer application, while details of the specific implementation of the protocol stack are not needed. The hardware equipment includes MCUs, ethernet physical layer chip PHYs, and memory. The embedded operating system manages hardware resources through the drivers of the different hardware peripherals, thereby providing services for the protocol stack and other upper-layer applications.

Figure 6
figure 6

The position and layered model of the IPv6 protocol stack in the system.

Simplification of the IPv6 protocol

Simplification of the IPv6 protocol mainly solves the problem of monitoring nodes that access the IPv6 backbone network. Because the hardware storage space and processing speed of the monitoring node are very limited, the original protocol must be streamlined to achieve access at the IP layer. Meanwhile, a compromise is made in terms of carrying capacity and maintenance difficulty.

The simplification of the IPv6 protocol stack in the system mainly involves the connection between layers and the mutual exchange of internal data. The IPv6 protocol stack itself is designed with a four-layer hierarchical structure. In implementation, the more independent the hierarchical modules are, the higher the performance usually is, but the more resource overhead is required. Under normal circumstances, the embedded system has a single application scenario, so strict layering may not be required. When the connections between different layers are implemented, design methods such as function calls can be directly used to save system resources.

The protocol stack processes the message data through the data buffer pBuff. The functions of the data buffer include: (1) providing a management structure for network data packets, which can improve the processing efficiency of packets, and at the same time can improve data processing performance and save memory resources by reducing the number of data memory copies; (2) controlling the throughput of data through the design size of the buffer. In practical application, a buffer of appropriate size is designed in accordance with the data communication requirements of the device to save available memory for other applications in the system. Therefore, the memory management module provided by the protocol stack can better manage the memory resources required by the protocol, reclaim and reallocate the used memory, and ensure that the system will not cause task interruption and failure due to memory resources being run out by network applications. The LwIP protocol stack uses shared memory, message queues and semaphores to connect various layers in order to save resources. Although such a design will lead to less strict and independent layers, it can effectively reduce the resource consumption of embedded devices. The design can fully meet the communication requirements of embedded devices, since they have relatively specific functions, and usually have very clear application scenarios and specific application requirements. The code of LwIP protocol stack is open source. The functional requirements should be fully considered during the porting process, and the buffer size and application modules should be adjusted for different processors and memory resources. The protocol stack adopts modular layering, which enables or disables different modules through global macro configuration to achieve better resource allocation.

Transplantation of the IPv6 Protocol onto ARM

When the system transplants the protocol stack, the timer is implemented by the timer peripheral inside the STM32F10XX controller to provide time management functions for the protocol stack. The synchronization of this process is realized by the semaphore of the real-time operating system. Therefore, the responsibilities of IPv6 on ARM in the system mainly include providing the functional modules required by the protocol stack, including the semaphore, timer, message mailbox and thread functions; maintaining the receiving and sending interface for data on the network interface layer; initializing the protocol stack; driving the network card of the physical layer; and setting basic parameters for IPv6.

The semaphore is used for task synchronization and resource management. Through the semaphore, events between two independent tasks can be processed synchronously. The message mailbox is an abstract method of message transmission provided by the operating system for the protocol stack, with a similar implementation process to that of the semaphore. However, the memory address pointer of the message is included in the message mailbox delivery process, so the data transfer within the protocol stack can be realized. The mailbox can operate message mailing and message reading. Neither the semaphore nor the message mailbox blocks the process. The task is in a suspended state while waiting for the semaphore or message, and the thread is dormant in this state. When the semaphore or message mailbox is released, it looks for the corresponding thread in the dormant thread queue and then wakes it up. After the thread wakes up, it starts to process the tasks after the semaphore or the message is successfully received. The realization of the semaphore and message mailbox in this system is as follows:

  1. (a)

    Semaphore: The err_t sys_sem_new(sys_sem_t *sem, u8_t count) function creates a semaphore. The sem of the semaphore is transmitted by the pointer, and the semaphore function can be provided to the system after it is completely created. There are two ways to call the semaphore in the application thread. One is to limit the waiting time, that is, if the semaphore is not received within the set time, the task is deleted or other operations are performed. The second is infinite waiting, that is, the task is in a suspended state until the signal is received. The u32_t sys_arch_sem_wait (sys_sem_t *sem, u32_t timeout) function is used to wait for the semaphore in the thread. The parameter “timeout” is the waiting time of the semaphore. When the value is set to 0, it means the system is waiting for the semaphore indefinitely.

  2. (b)

    Message mailbox: The err_t sys_mbox_new(sys_mbox_t *mbox, int size) function creates a message mailbox. The difference between the message mailbox and semaphore is that the creation of the message mailbox involves opening up a new memory pointer to provide a data transmission channel, while the semaphore does not occupy memory space and provides synchronous processing signals for system tasks through count variables.

The protocol stack also needs to create threads, which mainly include TCP packet processing threads and UDP message processing threads. Therefore, the operating system must provide thread management functions for the protocol stack.

Thread creation: The sys_thread_t sys_thread_new(const char *name, lwip_thread_fn thread, void *arg, int stacksize, int prio) function creates a thread for the lwIP stack. The thread created by the lwIP always exists in the application. For example, the data receiving and data sending processes are divided into two application threads. When the data are not received or are not sent, the two threads are in a suspended state. After receiving the data from the message mailbox, the thread activates the task and starts to send or receive IP packets for processing.

The initialization of the network interface layer mainly involves the addition of netif to the lwIP stack. The transplantation configuration process is shown in Fig. 7:

Figure 7
figure 7

Network driver layer initialization and configuration process.

Check whether the hardware network card has been initialized successfully. If it is not initialized, then proceed with the network card initialization process.

Configure the network interface, receive and send data, process functions, and write two function pointers into the network structure to provide an interface for the upper layer protocol.

Configure the MLD (multicast listener discovers) to enable IPv6 to discover network devices on the LAN segment.

Configure the DHCP (dynamic host configuration protocol) to automatically configure IPv6 addresses for the device.

Set various protocol flags, call netifapi netif_add, and add the configured netif to the protocol stack to complete the configuration of the network interface layer.

The initialization of the protocol stack mainly creates two thread tasks: data sending and receiving. By creating a corresponding message mailbox for each thread and providing buffer space for the data at the same time, the thread and message mailbox are executed after the creation process is completed. So far, the lwIP has been transplanted on the embedded system. In actual applications, the upper-level user application can directly call related modules for direct use, such as socket connection, HTTP, TFTP and other application modules. This system uses the HTTP module to implement an embedded web server.

Design and implementation of an Embedded Web Server

Introduction to Embedded Web Server Programs

Unlike the traditional sensor network topology, this system adopts an embedded web server network structure33,34. The network connection topology is shown in Fig. 8. All nodes are designed as single web servers and do not require management by a central server. Each sensor node can be directly accessed through a browser to obtain monitoring data and device statuses. This program distributes the traditional background server tasks to each node, and a single node can directly collect, store and display data. On the basis of the rapid development and wide application of IPv6 network technology, each sensor node can obtain a fixed IPv6 address to realize the actual Internet of Things.

Figure 8
figure 8

Network topology of the embedded web server.

HTTP webpage design

In embedded systems, there are usually only simple real-time operating systems or direct bare metal programs with limited storage space. Therefore, embedded web design requires tailoring a large number of modules to achieve the desired functions.

The webpage of this system is designed with the HTML + CSS + JavaScript architecture. HTML (Hypertext Markup Language) is a markup language rather than a programming language. An HTML text is a webpage. CSS (cascading style sheets) is a programming language for HTML web pages that is used to statically decorate web pages and dynamically format web page elements by cooperating with different scripting languages. Different web page styles can be realized through CSS programming. The JavaScript programming language enables HTML to dynamically request data, change the display text of the web page, and render the display style. Rich, powerful and stable web pages can be displayed through these three languages. The webpage of this system is designed with DreamWeaver software. The specific design process is shown in Fig. 9. First, the web page html file is created on the client computers. The dedicated makefsdata tool is used to convert the HTML file into an ARM-recognizable C-language array file. The array file is stored statically in flash memory or other external memory in the ARM. After receiving the web page connection request, the ARM processor reads the data of the web file. Then, the data is transmitted to the requested webpage through the HTTP protocol, and the webpage automatically parses the HTML file data and then displays the webpage.

Figure 9
figure 9

Embedded web page design process.

After the web page is embedded in the monitoring node, the HTTP protocol sends the web page data. Figure 10 shows the actual working process of the web server when the node device is actually used. When the lwIP protocol stack and network card driver are initialized, the software system creates an HTTP monitoring service thread. Users can directly access the IPv6 address of the node through a browser in an IPv6 network environment to obtain the monitoring node’s web page. The node uploads static webpage data when it detects an HTTP connection. When the browser receives the HTML format file, it automatically parses the file and displays it. At the same time, the browser parses and executes the JavaScript program in the HTML document and may request the node device to send data again under different functional requirements.

Figure 10
figure 10

Workflow of the embedded web server.

Data requests and design display

Embedded web pages usually use static arrays to store HTML documents. The data collected each time in this system need to be dynamically displayed on the web page, so JavaScript programs need to be embedded in the HTML document to dynamically request node data. The workflow of the browser connecting to the node once is shown in Fig. 11. The sensor data are sent in JSON (JavaScript Object Notation) format, which is currently a common format used for communication and exchanging data and is independent of programming languages. JSON formatted data are represented by characters, which is conducive to debugging in the development process. At the same time, a standard data exchange format can also improve software compatibility. The format of the JSON package is as follows:

Figure 11
figure 11

Workflow of the browser connection.

The $.get(“./ getair. json”, function (data)) command responds to the sensor data in the following format: The data for each field in this example changes based on the actual sensor data.

figure a

The command $.get(“./ getdevice. json”, function (data)) requests a reply in the following format (device information, such as ipv6 address).

figure b

As shown in Fig. 11, at the beginning, users first access the embedded webpage of a node through the node’s IPv6 address in the browser. After the node monitors the HTTP connection, it first reads the indexed static web page data directly from the stored data and then sends them. After receiving the HTML formatted file, the browser parses and displays it. To obtain and display the sensor data again, this system adds JavaScript program code to the HTML and sends a fixed URL request to the device. The “$.get(“./GetAir.json”, function (data))” function requests sensor data from the device. After receiving the request, the device sends sensor data in JSON format to the browser. The browser parses the data and displays it. Then, the browser executes the “$.get(“./GetDevice.json”, function (data))” function again to request the connection information of the device so that the IPv6 addresses of the device node and client computers can be seen on the web page, which is convenient for users to manage. Finally, the process is executed to obtain a complete display of the web page as shown in Fig. 12, where you can see the nodes accessed through the http://[2001:da8:207:e219:280:e1ff.:fe18:2635]/ URL and the AQI (air quality index) calculated based on sensor data.

Figure 12
figure 12

Leave a Reply

Your email address will not be published.