Scrapbooking

SINGLE NODE WIRELESS SENSOR NETWORK ARCHITECTURE AS A PLATFORM FOR DISTRIBUTED CONTROL SYSTEMS

Description
SINGLE NODE WIRELESS SENSOR NETWORK ARCHITECTURE AS A PLATFORM FOR DISTRIBUTED CONTROL SYSTEMS Abdul Haris Junus Ontowirjo 1, Wirawan 2 1, 2 Multimedia Communications Laboratory, Sepuluh Nopember Institute
Categories
Published
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
SINGLE NODE WIRELESS SENSOR NETWORK ARCHITECTURE AS A PLATFORM FOR DISTRIBUTED CONTROL SYSTEMS Abdul Haris Junus Ontowirjo 1, Wirawan 2 1, 2 Multimedia Communications Laboratory, Sepuluh Nopember Institute of Technology Kampus Sukolilo Surabaya , 2 ABSTRACT A simple control system model which includes time delay due to processes in communication networks is presented. Time delay in wireless sensor networks is described. As an embedded system every sensor node in wireless sensor networks has a specific operating system with specific scheduling scheme and certain programming paradigm and communication system which perform a specific protocol. Both aspects are considered in term of their contributions in generating time delay. Hardware platform is then implemented in a single node wireless sensor network architecture by taking time delay characteristics into account. The single node architecture is ready to accept any distributed control strategy in wireless sensor network environment. Keywords: time delay, TinyOS, S-MAC, distributed control, sensor node, actuator node. 1 INTRODUCTION The study of distributed control systems (DCSs) brings together the historically separate disciplines of computer networks and control theory. Recently attention to DCSs and its inherent real-time characteristics increases significantly [1,2]. Meanwhile technological advances have brought us to wireless era. DCSs have many chances to be developed by using wireless communication networks both in feedback loops and in forward loops to form wireless closed loops. The objectives of wireless DCSs development are to achieve high performance closed loop control systems that have an ability to stabilize unstable systems and to develop a system that can be used as a platform for exploring the advantages and limitations of wireless control systems. Factors which motivate the development of control systems that use wireless communication networks are cabling reduction and the possibility to centralize the controller in one single place. Furthermore the need to control plants with high mobility such as unmanned vehicle for hazardous environment exploration, unpiloted helicopters and planes for surveillance purposes and remote sensing. With all of the purposes above, control for specific wireless controls problems addressed. In term of the fields involved research direction on wireless control systems points to two directions [3]. One of the research directions is protocol development for communication networks while the other direction is analysis and design of wireless controllers. 2 DISTRIBUTED CONTROL SYSTEMS The basic model used in designing the platform in this paper is depicted in Figure 1. The actuators and sensors are connected to a communication network. These units receive respectively send control information to the centralized controller. The centralized controller is connected to the network, and communicates with sensors and actuators by sending messages over the network. Depending on the network and scheduling policy in the system this transfer time can have different characteristics. The transfer time can in some setups be nearly constant, but in many cases it is varying probabilistically. The length of the transfer delay can, for instance, depend on the network load, priorities of the other ongoing communications, and electrical disturbances [4]. Depending on how the sensor, actuator, and controller nodes are synchronized several setups can be found. Several previous authors have suggested such control schemes with slightly different timing setups. The different setups come from whether a node is event-driven or clockdriven. By event-driven we mean that the node starts its activity when an event occurs, for instance, when it receives information from another node over the data network. Clock-driven means that the node starts its activity at a prespecified time, for instance, the node can run periodically. There are 155 156 The 5 th International Conference on Information & Communication Technology and Systems essentially three kinds of computer delays in the system see Figure 1: Communication delay between the sensor and the controller, τ sc k Computational delay in the controller, c τ k Communication delay between the controller and the actuator, τ ca k information arrives from the sensor node and the controller node respectively. In Figure 2 the timing in such a system is illustrated. A drawback with this setup is that the system becomes time-varying. This is seen from Figure 2 in that the control signal is changed at irregular tines. Figure 1. Distributed digital control system basic model [6] The control delay for the control system, τ k, the time from when a measurement signal is sampled to when it is used in the actuator, equals sc c ca the sum of these delays, τk = τk + τk + τk. Many phenomenons can arise here but one important problem in this control system setup is the delays, which are varying stochastically. This makes the system time-varying and theoretical results for analysis and design for time- invariant systems can not be used directly. One way to get rid of the time variations is to introduce clocked buffers on the input in the controller node and the actuator node. If these buffers are chosen large enough, larger than the worst case delay, the delay for a transfer between two nodes is deterministic. This scheme was proposed in e.g. [5]. Introduction of buffers in the loop means that we sometimes are using older information than we need to. It can be shown that this can lead to a degradation of performance in comparison with an event-driven setup [6, 7]. From a discrete time control perspective, it is natural to sample the process output equidistantly with a sample period of h. It is also natural to keep the control delay as short as possible. The reason is that time delays give rise to phase lag, which often degenerate system stability and performance. This motivation suggests a system setup with eventdriven controller node and event-driven actuator node, which means that calculation of the new control signal respectively D/A conversion of the now control signal takes place as soon as the new Figure 2. Typical time diagram of distributed digital control system [7] 3 WIRELESS SENSOR NETWORKS Many things are important to be considered when we want to implement DCSs on wireless sensor networks whatsoever the architecture involved. Among those the significant ones are operating system and communication protocol used in every node. In this paper we consider TinyOS as the operating system and IEEE ZigBee as the communication protocol. The communication protocol applies S-MAC as the medium access control (MAC) protocol. 3.1 Operating System (TinyOS) TinyOS is an operating system designed explicitly for networked sensors and draws strongly from certain architectural work [8] on lightweight thread support and efficient network interfaces. Included in the TinyOS system architecture is an Active Messages communication system. We believe that there is a fundamental fit between the event based nature of network sensor applications and the event based primitives of the Active Messages communication model. When we are working with wireless sensor networks, two issues emerge strongly: these devices are concurrency intensive - several different flows of data must be kept moving simultaneously, and the system must provide efficient modularity - hardware specific and application specific components must snap together with little processing and storage overhead. A23 - Single Node Wireless Sensor Network Architecture As A Platform 157 For Distributed Control Systems- Abdul Haris Junus Ontowirjo Requirements for embedded systems those are small physical size, modest active power load, and micro stand by power load must be provided by the hardware design. However, an operating system framework is needed that will retain these characteristics by managing the hardware capabilities effectively, while supporting concurrency-intensive operation in a manner that achieves efficient modularity and robustness. Existing embedded device operating systems do not meet the size, power and efficiency requirements of this regime. These requirements are strikingly similar to that of building efficient network interfaces, which also must maintain a large number of concurrent flows and juggle numerous outstanding events. In spite of tackling these issue with physical parallelism and virtual machines, TinyOS tackle them by building an extremely efficient multithreading engine. TinyOS maintains a two-level scheduling structure, depicted in Figure 3, so a small amount of processing associated with hardware events can be performed immediately while long running tasks are interrupted. The execution model is similar to finite state machine models, but considerably more programmable. Figure 3. Two-level scheduling [10] To enable the vision of single-chip, a low cost sensor node, TinyOS combines a highly efficient execution model, component model and communication mechanisms. In order to provide the extreme levels of operating efficiency required in wireless sensor networks, TinyOS uses event based execution, as depicted in Figure 4. The event model allows for high levels of concurrency to be handled in a very small amount of space. In contrast, a thread based approach requires that stack space be pre-allocated for each execution context. Additionally, the context switch overhead of threaded systems is significantly higher than those of an event-base system. The efficiency of an event-based regime lends itself to these requirements. As a consequence in an event based system, a single execution context is shared between unrelated processing tasks. In TinyOS, each system module is designed to operate by continually responding to incoming events. When an event arrives, it brings the required execution context with it. When the event processing is completed, it is returned back to the system. Researchers in the area of high performance computing have also seen that event based programming must be used to achieve high performance in concurrency intensive applications. Figure 4. Event based programming model [11] Other than to efficient CPU allocation, event-based design results in low power operation. A key to limiting power consumption is to identify when there is no useful work to be performed and to enter an ultra-low power state. Event-based systems force applications to implicitly declare when they are finished using the CPU. In TinyOS all tasks associated with an event are handled rapidly after each event is signaled. When an event and all tasks are fully processed, unused CPU cycles are spent in the sleep state as opposed to actively looking for the next interesting event. Eliminating blocking and polling prevents unnecessary CPU activity. As an operating system for embedded systems TinyOS is divided into a collection of software components. A complete system configuration consists of a tiny scheduler and a graph of these components. A component has four interrelated parts: a set of command handlers, a set of event handlers, an encapsulated fixed-size frame, and a bundle of simple tasks. Tasks, commands, and handlers execute in the context of the frame and operate on its state. To facilitate modularity, each component also declares the commands it uses and the events it signals. These declarations are used to compose the modular components in a perapplication configuration. The composition process creates layers of components where higher level components issue commands to lower level components and lower level components signal events to the higher level components. Physical hardware represents the lowest level of components. Frames which have fixed size are statically allocated which allows us to know the memory requirements of a component at compile time. Additionally it prevents the overhead associated 158 The 5 th International Conference on Information & Communication Technology and Systems with dynamic allocation. This savings manifests itself in many ways, including execution time savings because variable locations can he statically compiled into the program instead of accessing state via pointers. All the commands are non-blocking requests made to lower level components. Typically, a command will deposit request parameters into its frame and conditionally post a task for later execution. It may also invoke commands on lower level components. However, it must not wait for long latency actions to take place. A command must provide feedback to its caller by returning status indicating whether it was successful or not, e.g., buffer overrun. Event handlers are invoked to deal with hardware events, either directly or mdi rectly. The lowest level components have handlers connected directly to hardware interrupts, which may he external interrupts, timer events, or counter events. An event handler can deposit information into its frame, post tasks, signal higher level events or call lower level commands. A hardware event triggers a fountain of processing that goes upward through events and can bend downward through commands. In order to avoid cycles in the command/event chain, commands cannot signal events. Both commands and events are intended to perform a small, fixed amount of work, which occurs within the context of their component s state. Tasks perform the primary work. They are atomic with respect to other tasks and run to completion, though they can he preempted by events. Tasks can call lower level commands, signal higher level events, and schedule other tasks within a component. The run-to-completion semantics of tasks make it possible to allocate a single stack that is assigned to the currently executing task. This is essential in memory constrained systems. Tasks allow us to simulate concurrency within each component, since they execute asynchronously with respect to events. However, tasks must never block or spin wait or they will prevent progress in other components. While events and commands approximate instantaneous state transitions, task bundles provide a way to incorporate arbitrary computation into the event driven model. The task scheduler is currently a simple FIFO scheduler, utilizing a hounded size scheduling data structure. Depending on the requirements of the application, more sophisticated priority-based or deadline-based structures can he used. It is crucial that the scheduler is power aware: our prototype puts the processor to sleep when the task queue is empty, hut leaves the peripherals operating, so that any of them can wake up the system. This behavior enables us to provide efficient battery usage (see Section 8). Once the queue is empty, another task can he scheduled only as a result of an event, thus there is no need for the scheduler to wake up until a hardware event triggers activity. More aggressive power Characteristics of TinyOS listed below are those which determine the characteristic of time delay: Small physical size. Concurrency-intensive operations Efficient modularity Limited physical parallelism and controller hierarchy 3.2 Communication System (S-MAC) Time delay in communication system section of a node is dominated by mechanisms in MAC layer protocol because it controls the radio. The states of a node related to communication are sending packet, receiving packet, idle or listening, and sleeping. Among the states idle state is the one that need to be minimized and sleeping duration must be increased because the later is the smallest energy consumer. Energy efficiency is single the most important objective in designing a MAC protocol. Potential factors that cause energy inefficiency are collision, overhearing, overhead, and idle listening. Collision consumes unnecessary sending and receiving energy and possibility to consume more for retransmission. Collision can be anticipated with fix assignment that is TDMA (Timd Division Multiple Access) or demand assignment [12]. Collision is a significant contributor in term of time delay. Protocol will always upper time and packet size limit for retransmission so there will be a data loss if this limit is exceeded. Overhearing occurs because wireless medium is a broadcast medium so in point to point transmission (uncast) there will be points which should not hear the messages and still hear them. Energy consumption will increase during receiving messages. In case of networks with high density node energy waste due to overhearing increases significantly. The phenomenon above affects the processing time in every node because the nodes will do the jobs that should not be done then disturbs the running process. A protocol sends data in frames or packets that contain information other than the data itself for identification and control purposes. This is called protocol overhead. This phenomenon increase the network load as well as energy consumed and of course generates time A23 - Single Node Wireless Sensor Network Architecture As A Platform 159 For Distributed Control Systems- Abdul Haris Junus Ontowirjo delay and increases the probability of packet losses for extending the packet size. On of the most popular MAC protocol design is Sensor-MAC or S-MAC [12, 13] handle the discourses with certain mechanism. It applies periodic wake up, that is, every node switches from idle or listening state to sleeping state in periodic fashion. Both idle state and sleeping state occupy some fix time durations and scheduled as depicted in Figure 5. S-MAC synchronizes the schedules from all nodes throughout the network so the listening period of all nodes start in the same time. Synchronization mechanism is the source of time delay as well as listening period. Listening period has 3 phases: Figure 5. Periodic wake up [11] In the first phase (SYNCH phase), node x accepts SYNCH packets from its neighbors. In these packets, the neighbors describe their own schedule and x stores their schedule in a table (the schedule table). Node x s SYNCH phase is subdivided into time slots and x s neighbors contend according to a CSMA scheme with additional back off, that is, each neighbor y wishing to transmit a SYNCH packet picks one of the time slots randomly and starts to transmit if no signal was received in any of the previous slots. In the other case, y goes back into sleep mode and waits for x s next wakeup. In the other direction, since x knows a neighbor y.s schedule, x can wake at appropriate times and send its own SYNCH packet to y (in broadcast mode). It is not required that x broadcasts its schedule in every of y.s wakeup periods. However, for reasons of time synchronization and to allow new nodes to learn their local network topology, x should send SYNCH packets periodically. The according period is called synchronization period. In the second phase (RTS phase), x listens for RTS packets from neighboring nodes. In S-MAC, the RTS/CTS handshake described in Section is used to reduce collisions of data packets due to hidden-terminal situations. Again, interested neighbors contend in this phase according to a CSMA scheme with additional backoff. In the third phase (CTS phase), node x transmits a CTS packet if an RTS packet was received in the previous phase. After this, the packet exchange continues, extending into x s nominal sleep time. 4 IMPLEMENTATION The implementation is to provide a platform for executing DCS algorithms on WSN environment or single node architecture for more precise. Many DCS strategies exist and have been implemented in many wired and wireless networks. The available models and strategies need to be adapted in WSN environment and the best way to start is from the simplest architecture that is single node architecture. The controller node is implemented in a general computer (like personal computer) which opens the possibility to write the DCS controller in many forms
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks