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 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.
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.
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:
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.
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:
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.
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.
Data requests and design display
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.
The command $.get(“./ getdevice. json”, function (data)) requests a reply in the following format (device information, such as ipv6 address).