ENHANCED INTELLIGENCE OF WIRELESS SENSOR AND ACTUATOR NETWORKS IN LOGISTICS BY APPLICATION OF CONTEXT-AWARENESS Vo Que Son1*, Bernd-Ludwig Wenning1, Carmelita Görg1, and Andreas Timm-Giel2 1
Communication Networks University of Bremen Otto-Hahn-Allee 1, Bremen, Germany e-mail: {son, wenn, cg}@comnets.uni-bremen.de 2
Communication Networks Hamburg University of Technology Schwarzenbergstr. 95E Hamburg, Germany e-mail:
[email protected] Abstract: Wireless Sensor and Actuator Networks (WSANs) are designed to operate with low power consumption and can react to changes of the physical environment by actuators. The optimization of efficient resource usage is of great importance in many research works. In real deployments, most applications of WSANs are configured to monitor and transmit the observed data periodically. This can lead to a waste of resources due to the duplication of traffic in the network if the physical environment does not change over time under normal conditions. In addition, most sensing applications only monitor the physical environment passively without making any reaction to unexpected changes of the environment. In this paper, a flexible context-aware model of WSANs is presented for use in logistic contexts to reduce unnecessary information overhead. Moreover, unexpected events happening in the environment can create warnings, e.g. by triggering a distributed local alarm system, activating an external controlling system or remotely alerting operators via emails or SMS. For flexibility of usage, this model is designed to be used at node level or central management system which is run at the sink. Logistics scenarios are simulated to illustrate the advantages of the proposed context-aware model.
1. INTRODUCTION With the help of rapid development in digital electronics, sensor nodes with many advantages such as low-cost, low-power, distributed processing have been proposed for many applications such as environmental monitoring, asset tracking, and logistics. Sensor nodes are electronic devices which typically contain sensors, a microcontroller, a radio communication chip and other peripherals such as actuators and flash memory. They can both communicate with other nodes to form selforganizing WSANs and control the environmental surroundings by their actuators. Inheriting features from sensing, computation and communication technologies such as ad-hoc networking and distributed processing, WSANs allow telemetry, data collection and actuation, which can be suitable for logistic applications. This can contribute to a new logistic system which consists of intelligent logistic items that can autonomously control their transport processes (Son et al., 102009). A WSAN is context-aware if it can use context to provide relevant information to the user, to other sensors or also to itself (Huaifeng et al., 2005). A lot of research on context-awareness has focused on two main fields: routing and applications. The Privacy-Aware Location algorithm (Gruteser et al., 2003) is proposed to prevent collection of privacy-sensitive data, other metrics (e.g. energy per packet, time to network partition) of Power-Aware routing are considered to prolong the lifetime of sensor nodes (Singh et al., 1998). The remaining battery charge of nodes is also taken into account as a routing metric in this research. Environmental Monitoring Aware Routing (Wenning et al., 2008) uses a multiplicative combination of environmental conditions and other context criteria for routing, which can be useful in disaster scenarios such as forest fires. A model of WSAN context-awareness (Marin-Perianu et al., 2006) (Son et al., 10-2009) is also proposed to use business rules in sensor nodes which can be applied for logistic transportation. However, all of the mentioned approaches are node centric and cannot be context-aware with respect to the whole deployed scenario.
Different from most of the above research works, which are studied in the area of routing, the model presented in this paper is designed in the application layer. The goals include some key points (Son et al., 10-2009) as follows: • Because of the dynamics in logistics, an adaptive proactive routing protocol could be used with this context-aware model to adapt to the changes of the network topology and support the mobility of logistics items. However, the context-aware application model should be independent from the routing layer. • This model supports environmental and external conditions such as surrounding temperature, node positions, or connectivity between the sensor network and the infrastructure network (e.g. IP network). • The context-awareness should be implemented in distributed nodes and at the central management system because the decisions to react to events from the environment have to be made in both the sensor nodes and the central manager. • A rule-based context model should be used because this model is simple enough to be implemented in resourcelimited sensor nodes and demands little computing and storage requirements (Marin-Perianu et al., 2006). • Supporting triggering or activating external sources such as alarm and HVAC (Heating-Ventilation, and AirConditioning) systems (HVAC). • The contexts have to be easily programmable and the contexts are independent for each node. In this paper, a context-aware model of WSANs is proposed to adapt to the collected environmental data. Moreover, this model does not eliminate the self-organization goal of WSANs by building the context model in the application layer while using the proactive routing protocol in (Son et al., 08-2009). Besides the monitoring features based on contexts, this model also supports warning mechanisms such as triggering the alarm system. This paper is structured in 5 sections: section I is the introduction to the scope of this paper, and related work. Contextawareness in logistics is discussed in section II. Section III describes the context-awareness model and underlying issues. Simulation results are shown in section IV. Finally, conclusions are given at the end of this paper.
2. CONTEXT-AWARENESS IN LOGISTICS Although WSANs can generally be used in many fields, in the logistics domain WSANs can be applied in the following areas: • Transportation: originating from the fact that WSNs have been deployed in smart containers (Jedermann et al., 2007) to collect information about temperature, humidity or pressure of the good items, WSANs are becoming a promising technology for logistics. This requires sensor nodes to be attached to goods, shelves, Returnable Transport Items (RTIs) and containers to form a multi-hop sensor network. In addition, a container that is equipped with a WSAN must have a gateway to bridge the information from its WSAN to an external network (e.g. WLAN, UMTS) to make it accessible from outside (Son et al., 10-2009). • Warehouse: WSANs are also used on the warehouse floor where RTIs intended for a specific destination are grouped together. All rooms of the warehouse which store the logistic goods can be equipped with WSANs to allow users to monitor the physical environment of the warehouse completely. This requires a local alarm in each room and a HVAC system for alerting or controlling the environment changes. Normally, all nodes in the network monitor and transmit data to a central management system via a gateway or a sink node. In the real world, there are many contexts which need to be taken into account in deployments. However, in logistics, the context information can be obtained from some of the following sources (Son et al., 10-2009): • Physical environmental conditions such as temperature, humidity, pressure. For example, deep-frozen food must be kept at a temperature of -18 °C or below. If the sensed temperature is higher than this threshold because of unknown reasons, the sensor nodes should send a message to users. • Security issues: the goods packages or the container door can be secured by sensor nodes. If the security states are violated, the sensor nodes can trigger an alarm to warn about this event. • Position: the location information is useful for the data collected, especially during the transportation. The absolute location can be used to determine the position of the container, or the relative location can provide the position of each item inside the container. This information can be useful for example when a problem is detected that requires an intervention at the specific location. • Long-distance connection: a container using WSANs usually has a gateway to bridge the information between the WSANs inside the container and the outside network (e.g. WLAN, UMTS). In case there is no available connection to bridge the information, e.g. because of the signal coverage of the outside network, sensor nodes should temporarily store the data to prevent information loss. • Timing: time is also a source of context. Sensors can be programmed to sample the environment at specific points of time.
3. MODEL OF CONTEXT-AWARENESS IN WSANS In this section, a model is proposed to satisfy the previously mentioned issues. In our design the context-aware architecture is formed from the two following parts: 3.1 Context-awareness at sensor node level
Figure 1: Model of context-aware application at node level Figure 1 shows the architecture of the context-aware model at node level. It has main parts with the following functions: • Sensor: all the internal and external sensors used by nodes for environment monitoring or other missions. • Rule database contains a set of pre-defined rules which are run to trigger corresponding actions for the contexts. • Rule engine runs all the rules retrieved from the Rule database to validate the data coming from sensors. • Configuration contains the configuration for the operation of sensor nodes. • Request identification is used to recognize the requests which can be used for updating rules, configuring the operation or retrieving the packets stored in Storage and other tasks. • Storage is used to buffer the packets if necessary. • External interfaces are used to communicate with external systems such as alarm or HVAC systems. • Routing layer interface provides an interaction between the context-aware application and the routing layer to make it independent from the routing layer. 3.2 Context-awareness at central management level When the context-aware model is applied in each node, it means that only that node can be aware of the environment surroundings. However, one or a few nodes cannot be aware of contexts of the entire network. For example, when the temperature of one room in a warehouse exceeds a predefined threshold, the sensor node which manages this room can know this event, but it cannot activate the central HVAC system of the entire warehouse since that node does not know the context conditions in other rooms. On the other hand, in case the contexts need a heavy computation, it is unwise to perform this computation at the node level. Moreover, the context information sources do not come only from WSANs, for example the GPS signal identifying the global position of a sensor-equipped container is coming from outside the network. Hence, if the context-awareness is also implemented at a central management system, the reactions to unexpected events are more accurate because information of all nodes in the network is available there. In order to support context-awareness at this level, the gateway (sink node) usually runs a management system which can interact with the WSAN for data collection and management. This system is more powerful when carrying out complicated algorithms. It also has extra interfaces such as controlling the HVAC system, warning users by sending an alert SMS (Short Message Service) or an email. These interfaces cannot be distributed to sensor nodes because of many reasons such as the expensiveness, the node size, and the power supply.
3.3 Context-aware rules at a node level In order to support the context sources mentioned previously, a compact format for context rules is shown in Figure 2, which has been presented in a previous publication (Son et al., 10-2009).
Figure 2: Format of context rules In this context rule format, there are the following fields: • Rule ID (6 bits): this unique number identifies the rule in the rule set. Hence, nodes can have many rules (up to 64 if they have enough memory) describing the actions for specific contexts. • Sensor Type (4 bits): is used to determine which sensor will be used in this rule. The table 1 shows the values of this field. Table 1: Values of Sensor Type field (Son et al., 10-2009) Sensor Type
Value
NO_SENSOR TEMPERATURE HUMIDITY LIGHT
0 1 2 3
INVOLTAGE
4 5-15
•
• •
Meaning If the sensor node has no sensor If the testing sensor is Temperature If the testing sensor is Humidity If the testing sensor is Light If the testing sensor is Internal Voltage which measures the battery level Reserved for future use
Condition (4 bits): the logical condition is used to check whether the rule applies. The pre-defined values of this field are shown in Table 2. Table 2: Logical condition of rule (Son et al., 10-2009) Condition
Value
Meaning
BETWEEN GREATER LESS OUT_OF GW_DISCONNECTED GW_CONNECTED TRIGGER_TIME
0 1 2 3 4 5 6 7-15
If the checking value is in range [Min..Max] If the checking data value of the checking packet is greater than Max If the checking value of the checking packet is less than Min If the checking value of the packet is out of range [Min..Max] If there is no connection between the Gateway and outside networks If the Gateway is connected to any infrastructure network If the local time in a node is equal to the trigger time Reserved for future use
Min (16 bits), Max (16 bits): the minimum and maximum values which are combined with the Condition field to form a logic condition. If the source of the context is the trigger time, both these two fields are used to describe a time stamp which indicates the time when the action in the rule is triggered. Action (4 bits): the corresponding action will be executed when the Condition is true. Pre-defined actions are shown in Table 3. Table 3: Values of Action field (Son et al., 10-2009) Action
Value
Meaning
DO_NOTHING SEND_PACKET STORE_PACKET TRIGGER_ALARM
0 1 2 3
ACTIVATE_HVAC
4
Do not apply any actions with the current packet Send the checking packet to the next-hop Store current packet to memory Trigger the local alarm when the context-aware rule is matched Activate the HVAC system (if available) when the context-aware rule is matched Reserved for future use
5-15
•
Next rule (6 bits) is provided to construct logically linked chains to check the contexts. This helps to define a context from a set of rules by making a link chain between rules to shorten the processing time.
For example, a food package needs to be kept under the temperature lower than 4°C during the transportation. Any value of the monitored temperature greater than this threshold has to be reported. If sensor motes are used in this scenario, the context rule can be set as following: IF TEMPERATURE GREATER THAN +4 °C THEN SEND_PACKET Because sensor nodes usually only understand raw ADC values (12 bits or 16 bits), the human-understandable value (e.g. +4 °C) has to be converted to a raw ADC value by the context interpretation process. The rule size is only 7 bytes; thus, sensor nodes with limited memory can still have many rules to describe contexts and related actions. In comparison to the context-aware application model in (Son et al., 10-2009), this proposed architecture includes several improvements as follows: • Instead of using the round robin technique to execute the rules, this proposal uses a logic link chain to create a rule sequence. This helps to define many contexts in a set of rules by linking them together. • Both distributed and centralized context-awareness are used to enable the customization of context settings for the scenario and the creation of alert procedures. • This architecture can be used in both WSNs and WSANs, where actuators are necessary to react to changes of the physical environment. 3.4 Context interpretation and programmability The context interpretation should be performed at the central management system, which has the overall picture of the entire network. This also helps to reduce the computation at nodes that have limited resources. From the context descriptions, users have to define a set of rules which need to be executed in each sensor node. After that, the central management system will translate these rules into the rule format that the sensor node can understand using the numeric values in Table 1, 2, 3. Because the contexts can change at any time, the rules must have the flexibility of being programmable to adapt to these changes. For the best flexibility, they can be programmed at any necessary time. Although the proposed model supports the rule programming at compilation time, it also supports remote programming of rules by sending commands (in control messages) to reconfigure the set of rules which describe the contexts. These control messages are implemented by using the dissemination technique (Levis et al., 2010), which is not only for programming context rules but also for other management purposes.
4. COMPUTER SIMULATION 4.1 Scenario 1: context-awareness of connection in transport logistics at node level In this scenario, 20 packages equipped with sensor nodes are loaded into a container to form a WSAN. The container has a gateway to connect to the IP network and it is assumed to be transported to the destination in 3 hours. During the transportation, the connections between sensor nodes inside the container are always established thanks to the routing protocol (Son et al., 08-2009). However, the connection between the gateway and the IP network may be disconnected in the second hour because of the coverage (shown in Figure 3). The other nodes in network are aware of the disconnection by a notification message sent from the gateway. In this context, the best solution is that nodes should transmit their sensed data when the connection between gateway and IP network is available. Otherwise, nodes store their packets in memory for the next transmission when the gateway connects to the IP network again. Nodes can be configured with normal or context operation mode. For evaluation, all data packets are monitored and logged at the gateway and at local nodes during 3 hours for analysis. The scenario is simulated in TOSSIM (Levis et al., 2003) and TinyOS (TOS). All nodes except node 18 are configured to run in the normal operation mode, which report the sensed temperature in a data packet every 10 seconds. Only node 18 runs in context-aware mode with two following rules: (1) IF GW_DISCONNECTED THEN STORE_PACKET (2) IF GW_CONNECTED THEN SEND_PACKET
For comparison, the number of sent packets and received packets of node 13 which are captured at the gateway, is shown in Figure 3. It can be seen that node 13 lost all its packets (370 packets) during the time that the gateway disconnected because it is not configured to react with the surrounding context. In contrast, Figure 4 shows the data collected from one node (node 18) and its local actions. One can see in the figure that the sensor node 18 only sends the packets when the connection is available in the first hour, afterwards it stores packets in local memory (if the memory is not full) in the second hour to avoid the loss of packets. This is indicated by the increase of received packets and the stored packets in the figure. When the gateway can reconnect to the IP network in the last hour, node 18 transmits all its sensed packets and its stored packets. Hence, the number of stored packets decreases in Figure 4 and the number of sent packets and received packets are the same which means that node 18 does not lose any packet during the simulation time.
Figure 3: Connection and number of received, sent packets of node 13
4.2 Scenario 2: context-awareness of environment in a warehouse at node level A food warehouse with the dimensions of 80m x 80m is used in this scenario for simulation. It has 16 equallydimensioned square rooms as shown in Figure 5. Each room has a sensor node to monitor the environment inside and a local alarm system to warn in case of unexpected events such as high temperature. All sensor nodes (1..16) form a sensor network to report the sensed data to the sink node (node 0) using the routing protocol (Son et al., 08-2009). Only node 0 is connected to a central HVAC system so that it can regulate the temperatures in all rooms of the warehouse. In the simulation, it is assumed that the room 8 Figure 4: Connection and number of sent, receiving, and contains frozen food which requires a temperature of -18 °C stored packets of node 18 inside, while the others keep the temperature at +4 °C. Because the details of controlling the HVAC system are out of this paper’s scope, for simplicity, it is assumed that the HVAC system is controlled by a digital signal. If this control signal is 1, it means that the HVAC system is activated. In the scenario, node 8 uses the following rule in its context-aware mode: (3)
IF TEMPERATURE GREATER THAN -18 °C THEN TRIGGER_ALARM
IF TEMPERATURE GREATER THAN -18 °C THEN SEND_PACKET (4) Meanwhile, node 10 is configured as follows:
(5)
IF TEMPERATURE GREATER THAN +4 °C THEN TRIGGER_ALARM
IF TEMPERATURE GREATER THAN +4 °C THEN SEND_PACKET (6) The above rule (4) or (6) only processes the originating packets of a local node. It is not applied for the forwarding packets from the neighbors because the local node does not know the contexts of the neighbors.
The environmental temperatures in rooms 8 and 10 are assumed to change following the template charts in Figure 6 and 7. These figures also show that the local alarm signal is triggered immediately when the temperatures increase above the defined thresholds in both node 8 and node 10. Besides the warming features, the context-awareness helps to reduce the generated traffic in each originating node and the forwarding traffic in intermediate nodes. Table 4 shows that in the simulated scenarios, the traffic generated by node 8 or 10 is lower than the traffic generated by those nodes which are configured in normal operation mode. Theoretically, the generated traffic reduction is equal to the rate of total time when the context rules are matched over the total running time of each node. This factor is also shown in the Table 4 with the same values. Hence, the definition of context rules is very important because it can affect the efficiency of the network.
Scenario 2 2
Table 4: Traffic generated by nodes Number of transmitted packets (packets) Reduction Node (%) Normal Context mode mode 10 1053 349 66.85 8 1056 351 66.76
4.3 Scenario 3: context-awareness management system
at
Figure 5: Layout of the warehouse and connectivity of nodes
central
Different from the two previous scenarios, in this scenario, the context-awareness is applied at the central management system level. Actuators are used to react to the changes of environment from the central management system. All nodes except node 0 in scenario 2 are configured to report their sensed temperature every 10 seconds. The preset temperatures in rooms are +3°C. However, node 0 acting as the central manager will monitor all the data from rooms (via sensor nodes) in this warehouse. If more than 10 rooms have temperatures higher than +6 °C, this node will trigger the HVAC system to adjust the temperatures in rooms of the warehouse. Figure 8 shows the monitored temperatures of node 1, 2, 3, and 4 (other nodes have similar temperature curves). At the time of the 60th minute, the temperatures in the rooms suddenly increase due to unknown reasons, and exceed a value of +6°C some minutes later. Because node 0 can monitor all these changes, it triggers the HVAC signal to adjust the air-conditioning system to keep the temperatures in rooms at +3°C again. When the temperatures go down, node 0 turns off the HVAC system since the monitored values are in the normal state again. This process is running in real time so the overall temperature is automatically kept at the temperature below the defined setting.
Figure 6: Change of temperature and alarm signal of node 8
Figure 7: Change of temperature and alarm signal of node 10
5. CONCLUSIONS AND OUTLOOK With the proposed context-aware application model, it is believed that the logistic items are becoming more intelligent when they are equipped with WSANs. They not only know the conditions of surrounding environments, but also react to corresponding activities or communicate with other similar entities to send data. Combining the implementation of this model in distributed sensor nodes and at the central management system provides users the flexibility in describing contexts, collecting data and controlling the physical environment. Both logistics applications and others can utilize this model for many flexible targets to increase the communication as well as energy efficiency. Synergy between sensor nodes can be considered in the Figure 8: The change of temperature is reacted by HVAC future to enhance the communication efficiency. Each control sensor node not only uses its own context-awareness, but also interacts with others to improve the information quality. In addition, the context interpreter should support script files. Instead of configuring separated rules manually, the context interpreter can be improved so that it can translate a script file of context descriptions to a set of rules for each node.
ACKNOWLEDGEMENTS This research is partially funded by the German Research Foundation (DFG) within the Collaborative Research Centre 637 ”Autonomous Cooperating Logistic Processes: A Paradigm Shift and its Limitations" (SFB 637) at the University of Bremen, Germany.
6. REFERENCES Huaifeng, Q., and Xingshe, Z. (2005). Context aware sensornet. In Proceedings of the 3rd international workshop on Middleware for pervasive and ad-hoc computing, pp. 1-7, Grenoble, France, November 2005. Gruteser, M., Schelle, G., Jain, A., Han, R., and D. Grunwald (2003). Privacy-aware location sensor networks. In Proceedings of the 9th conference on Hot Topics in Operating Systems, pp. 28, Berkeley, USA, 2003. Singh, S., Woo, M., and Raghavendra, C. S. (1998). Power-aware routing in mobile ad hoc networks. In Proceedings of the 4th Annual ACM/IEEE International Conference on Mobile Computing and Networking, pp. 181-190, Texas, USA, 1998. Wenning, B.L., Pesch, D., Timm-Giel, A., and Görg, C. (2008). Environmental Monitoring Aware Routing in Wireless Sensor Networks. In Wireless and Mobile Networking. Proceedings of the IFIP joint conference on Mobile and Wireless Communications Networks (MWCN 2008) and Personal Wireless Communications (PWC 2008), pp. 5-16, Toulouse, France, September 2008. Marin-Perianu, M., Meratnia, N., Lijding, M., and Havinga, P. (2006). Being Aware in Wireless Sensor Networks. In Proceedings of the 15th IST Mobile & Wireless Communication Summit, Capturing Context and Context Aware Systems and Platforms Workshop, Myconos, Greece, June 2006, Son, V.Q., Wenning, B.L., Timm-Giel, A., and Görg, C. (08-2009). A Model of Wireless Sensor Networks using Opportunistic Routing in Logistic Harbor Scenarios. In Proceedings of 2nd International Conference on Dynamics in Logistics, pp 214-223, Bremen, Germany, August 2009. Jedermann, R., Behrens, C., Laur, R., and Lang, W. (2007). Intelligent Containers and Sensor Networks Approaches to apply Autonomous Cooperation on Systems with limited Resources. In Understanding Autonomous Cooperation & Control in Logistics – The Impact on Management, Information and Communication and Material Flow. Springer, pp. 365-392, Berlin, 2007.
Son, V.Q., Wenning, B.L., Timm-Giel, A., and Görg, C. (10-2009). A model of Wireless Sensor Networks using Contextawareness in Logistics Applications”. In Proceedings of the ITST2009 Conference, pp. 2-7, Lille, France, October 2009. Levis, P., Lee, N., Welsh, M., and Culler, D. (2003). TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications. In Proceedings of the First ACM Conference on Embedded Networked Sensor Systems, pp. 126-137, Los Angeles, USA, November 2003. Levis, P., Tolle, G (2010). Dissemination of Small Values. TEP118, http://www.tinyos.net/tinyos-2.x/doc TOS: TinyOS, www.tinyos.net HVAC: http://www.hvachome.net
