1 node Composition
A node is an object that is deployed in the research area of a wireless sensor network to collect and forward information and collaborate to complete a specified task. The program running on each node can be identical, and the only difference is its ID.
1.1 nodes
The wireless sensor node consists of the sensor module, the processor module, the radio communication module, and the energy supply module. The entire structure is 1.
Figure 1 Diagram of wireless sensor nodes
In essence, wireless sensor nodes are a networked distributed embedded system that enables communication between networks through wireless channels. To reduce the traffic, computation is required locally for Data Fusion, so as to collaborate to complete data collection in the deployment space. In applications, the network is the center, and node functions are represented by the network. Therefore, the traditional embedded design concept has encountered many challenges in Wireless Sensor Networks: there are a large number of parallel and node collaborative computing programs running on nodes.
1.2 node features
Wireless sensor networks are application-related networks. They are implemented using different network technologies in different application fields. Because wireless sensor nodes are used for monitoring and have a large distribution density and a wide range of fields, low costs, low power consumption, and small sizes are required. Considering the existing technical conditions, it is worth considering the node cost and energy supply. It is impossible for a node to adopt a high frequency because the frequency is positively correlated with the energy consumption. If the frequency is high, the energy consumption is high. In addition, the energy consumption of the radio communication module is also large, and the transfer distance is positively correlated with the energy consumption. Therefore, we must make a balance between the transmission distance and the number of nodes.
1.3 mica Node
Mica, a low-power wireless sensor node developed by UC Berkeley, uses the *** R series of ATMEL (TI's MSP430 is also a good choice ), the radio transceiver module uses tr1000 or cc10000 and corresponding sensor interfaces to implement wireless sensor nodes, as shown in figure 2. Nodes communicate with each other in a no-wire mode to collaborate to complete specified tasks. The nodes themselves perceive external data through the ADC channel.
Figure 2 Physical Map of the mica Node
The mica node can perceive multiple physical quantities: light intensity, temperature, and geomagnetic intensity. Bytes.
The biggest difference between wireless sensor networks and current sensor technologies is that existing sensor technologies are networked to better apply sensor technologies and provide updated solutions for current sensor technologies.
2-node micro-OS
The storage capacity of wireless sensor network nodes is limited. Through research, it is found that a new embedded system and embedded software can be used to meet the needs of network operation.
2.1 Operating System Requirements
From the node structure analysis, we can see that the hardware of wireless sensor nodes is simple and can be programmed directly on the hardware. However, this has caused many problems in engineering practice: the difficulty of application development is greatly increased, and programmers must be familiar with hardware. Programmers cannot inherit the existing software achievements and prolong the development cycle; it is impossible to form a scale. The upper-layer modules must be rewritten when new chips are used.
From the perspective of existing software technology, wireless sensors can directly use existing embedded operating systems. Most of the existing embedded operating systems are real-time operating systems, and the energy supply is seldom considered. One critical aspect of wireless sensors is that the energy supply cannot be solved. Most of the existing embedded operating systems occupy a large space, another critical point of wireless sensors is the limited storage capacity.
Wireless sensor nodes have two outstanding features: one is the concurrency of message arrival, which is very intensive, that is, there are multiple logic controls that need to be executed at the same time, the operating system needs to complete these frequent operations in a short period of time; the other is the high modular program of wireless sensor nodes, requiring the operating system to provide convenient hardware control for applications.
2.2 tinyos Operating System
The operating system provides a good user interface. Based on the above analysis, developers have designed a new embedded system tinyos with limited processing and storage capabilities of wireless sensor nodes, with a stronger network
And resource collection capabilities to meet the requirements of wireless sensor networks.
To meet the requirements of wireless sensor networks, researchers have introduced four technologies in tinyos: light thread, active message, event-driven, and componentized programming.
Light threads are mainly used for node concurrent operations that may be frequent and have short threads, traditional process/Thread Scheduling cannot meet the requirement (using traditional scheduling algorithms will generate a lot of energy for ineffective process swapping.
Active messages are concepts in parallel computers. When a message is sent, the corresponding processing function ID and processing data of the message are sent. After receiving the message, the receiver can process the message immediately to reduce the traffic.
The whole system runs because it is event-driven. When no event occurs, the microprocessor enters the sleep state to save energy.
A component is a functional abstraction of software and hardware. The entire system is composed of components. By improving software reuse and compatibility through components, programmers only care about the functions of components and their own business logic, rather than the specific implementation of components, this improves programming efficiency.
2.3 Implementation of tinyos
The tinyos operating system was originally implemented in C language and the generated target code is relatively long. Later, the NESC language based on componentized and parallel models was designed, and the generated target code was relatively small. You can use the NESC language to develop the tinyos operating system and applications running on it.
2.3.1 Interface
An interface is a two-way channel that indicates that the interface has two-way functions and event notification capabilities. It provides the caller with commands and Event Notification by implementing the command.
Interface Name {
Asy commandresult_t cname (pram p );
Asy eventresult_tename (pram p );
}
3.
Figure 3 Interface
Declare commands and events in an interface to implement different functions. commands are the functions of interfaces, and events are the ability of interfaces to notify events. Asy can be called by commands or events in the interrupt handler.
The interface represents the event-driven function and modularity. Event Notification allows the user to respond to the event. Any implementer that meets the interface function can be called by other components that need this interface function.
2.3.2 Components
A component is a wiring file or module file, which is an abstraction of logical functions. Programmers can directly call components for program development.
The wiring file only connects components through interfaces. The module File implements commands and events in interfaces. The provides and uses statements can be used in both files. Provides indicates the interfaces that the component can provide and the commands and Event Notifications for these interfaces. Uses indicates the interfaces used by this component. The component can provide commands in the interface and respond to events in the interface.
Based on the idea of components, a component can implement certain logic functions through multiple components, and declare the required interfaces and interfaces. Figure 5 shows the new function component D formed by components A, B, and C.
Figure 5 component D structure diagram
2.3.3 parallel model
The tinyos parallel processing capability is embodied through tasks and interrupt hander events. Tasks are added to a FIFO queue. During execution, there is no competition between tasks. However, interrupt handlers can interrupt the execution of tasks. Tinyos uses a level-2 scheduling mechanism to meet the running characteristics of wireless sensor networks. The entire program scheduling process is shown in 6. Components to complete the task submission, scheduling is completed by the operating system.
Figure 6 tinyos program structure diagram
Based on the above analysis, Diagram 7 of the application on a node is shown. The operating system only provides the queue service in the background.
Figure 7 Application Structure Diagram
3. specific instance
The following uses the value in the node receiving and receiving counters as an example to describe how the network protocol is implemented through active message transmission.
The program requires that, after the node is started, the counter count starts to broadcast its own count value every second, and receive the counter value on other nodes.
3.1 main component
The tinyos application starts from the main component and completes the specific implementation of the three commands Init (), start (), and stop () of the stdcontrol interface of the main component. In this interface, the command execution order can be init * (START | stop) *. Before the application executes the init () command to complete the necessary initialization. Start is the task to be completed by this program, stop is the action to be executed before the system is shut down. This interface is a standard interface for tinyos applications. Other components related to hardware operations must use this interface to implement commands in the interface.
3.2 interfaces used
The stdcontrol interface starts the application and initializes related hardware.
Interface stdcontrol {
Command result_t Init ();
Command result_t start ();
Command result_t stop ();
}
The timer interface provides the counting function.
Interface timer {
Command result_t start (char type, uint32_t interval );
// Set the trigger type and counter value
Command result_t stop ()
// Abort the counter
Event result_t fired ();
// Counter trigger event
}
The sendmsg API sends messages.
Interface sendmsg {
Command result_t send (uint16_t address, uint8_t length, tos_msgptr MSG );
// Send a message
Event result_t senddone (tos_msgptr MSG, result_t success );
// Events after the message is sent
}
The receivemsg interface receives messages.
Interface receivemsg {
Event tos_msgptr receive (tos_msgptr m );
// Receives a message event.
}
3.3 components used
The main, test5m, timerc, and genericcomm components implement logical functions. Main is required by the system. Test5m provides interface commands and responds to interface events. Genericcomm sends messages and sends notifications to receive messages. The wiring file is as follows:
Main. stdcontrol-> test5m. stdcontrol;
Main. stdcontrol-> timerc. stdcontrol;
Test5m. Timer-> timerc. Timer [unique ("timer")];
Test5m. subcontrol-> comm;
Test5m. Send-> comm. sendmsg;
Test5m. Receive-> comm. receivemsg;
3.4 test5m module files
The test5m Module Interface is as follows:
Module test5m {
Provides {
Interface stdcontrol;
}
Uses {
Interface timer;
Interface sendmsg as send/[uint8_t ID/]; // message sending Interface
Interface receivemsg as receive/[uint8_t ID/]; // receives messages
Interface stdcontrol as subcontrol; // sub-component: completes sending Initialization
}
}
Provides declares the generation of commands and notifications related to the interfaces implemented by this component. You need to implement the commands Init (), start (), and stop () in the stdcontrol interface ().
Uses declares that this component calls commands in the interface and responds to the events in the interface. The event to be responded to is the fired () event of the timer interface, the senddone event of the sendmsg interface, and the receive event of the receivemsg interface.
Size = 2> provides declares the generation of commands and notifications related to the interfaces implemented by this component. You need to implement the commands Init (), start (), and stop () in the stdcontrol interface ().
Uses declares that this component calls commands in the interface and responds to the events in the interface. The event to be responded to is the fired () event of the timer interface, the senddone event of the sendmsg interface, and the receive event of the receivemsg interface.
3.5 communication implementation
Test5m sends and receives messages through the genericcomm component. Genericcomm calls other components to transmit data from message packets to active messages, byte data transmission, and BIT data transmission to the radio transceiver module. We will not analyze the implementation process in depth here. We will use the MAC protocol of the CSMA/AD protocol that is scaled back randomly. We only need to understand the component genericcomm to send and receive messages.
Genericcomm provides 256 message sending and receiving interfaces. That is to say, the system can use 256 types of messages or 256 states for conversion. Because the system is in non-blocking mode, once a message arrives in the test5m component, the receive event is immediately called. Therefore, different messages are converted in this event to achieve handshaking between the communication parties:
Event tos_msgptr receive. Receive/[uint8_t ID/] (tos_msgptr m ){
Switch (ID ){
Case 1: // status Transition 1
Case 2: // status conversion 2
��
}
Return m;
}
4. Conclusion
This article describes the architecture of wireless sensor network nodes by analyzing the wireless sensor node mica and the tinyos operating system running on it, and illustrates the idea of establishing the communication model through application development, describe the application architecture and message communication mechanism of wireless sensor network nodes.