an intelligent system for street lighting monitoring and ... - IEEE Xplore

AN INTELLIGENT SYSTEM FOR STREET LIGHTING MONITORING AND CONTROL Gustavo W. Denardin, Carlos H. Barriquello, Alexandre Campos and Ricardo N. do Prado Federal University of Santa Maria - UFSM Electronic Ballast Researching Group - GEDRE Santa Maria, RS, 97105-900, Brazil [email protected], [email protected] Abstract – One of the major challenges at the moment is the improvement of the present street lighting system. These systems are considered outdated due the lack of communication capabilities, not allowing system feedback. This work aims to add communication capabilities to the systems already in use, through the integration of an IEEE 802.15.4 compatible transceiver to the photoelectric relay used to turn the HPS lamps on/off. This change will turn each device into a node of a large wireless network across the city. Keywords – IEEE 802.15.4, Street Lighting system, wireless sensor network. I. INTRODUCTION Most of street lighting systems today do not have communication capabilities. Its energy consumption, which is currently estimated by number of installed devices, and status information, can not be readily obtained. Lights are switched ON/OFF by photoelectric relays and there are no ways of transfer control commands. The goal of this work is to improve these outdated street lighting systems. The main idea is the integration of an IEEE 802.15.4™ compatible transceiver to the relay used to turn the HPS lamps ON/OFF, turning each device into a node of a large wireless network across the city. The proposed system makes easier to read sensor measurements (current, voltage, power, illumination, etc.) and it can reduce total system power consumption and maintenance costs. Also it enables the system to be used in a variety of other public services. A few contributions in the literature suggest the use of similar systems to control the street lighting system. Some use the power lines for data transmission (PLC) [1][2], while others use wireless communication [3][4]. However, these systems actually need a customized solution. In case of Brazil, the street lighting system is mostly comprised on HPS lamps with electromagnetic ballasts and photoelectric relays. This reality makes unsuitable to integrate a transceiver to the HPS ballast because of the great amount of change needed in the system and due to its high cost. A better option is the integration of the transceiver to the photoelectric relay, because of its lower cost, easier installation and much less changes to the current system. Indeed, concerning to the choice of technology to be used (PLC or wireless), it is hard to say which is the best one. Both have pros and cons, leading that question to be answered based more on a marketing/economical approach than technical considerations.

978-1-4244-3370-4/09/$25.00 © 2009 IEEE

II. NETWORK MODEL The street lighting systems features a large number of independent devices, with geographic distribution depending on the city streets. Then, adding communication capabilities to these devices requires a complex network topology, as well as interoperability, scalability, security, robustness, ease of use and maintenance. An example of such system is presented in Figure 1. As the electromagnetic line-of-sight is limited due to the large number of obstacles in a city landscape, it is necessary to implement a network with mesh topology. The network model adopted is similar to that used in sensor networks, however, in the street lighting case, nodes are fixed and deployed in a two-dimensional field with many obstructions. Due to obstructions, the ideal communication range r of a node x is significantly reduced, as show in Figure 2. In this way, the number of neighbors of node x and possible routes to reach the utility power substation are also reduced. Even in Figure 2 it is possible to verify that although the node y is within theoretical communication range of node x, due to obstructions is necessary to realize a deviation. When performing the diversion by node a, two possible paths must be analyzed (by node b or c). One of these paths can lead to a dead end. The IEEE 802.15.4™ standard defines MAC and PHY layers of the OSI model and it is intended to be used on low rate wireless personal area networks (LR-WPAN) [5]. However, that standard does not include network and application layers, which should be properly specified. To comply with this set of requirements it is preferable to rely on an existing standard, like DALI™, ZigBee™ or 6LoWPAN™. DALI stands for Digital Addressable Ligthing Interface. IEC has adopted it as a lighting standard for ballast control of fluorescent lamps (IEC60929 Appendix E). It is a proven technology, used by many manufacturers in the world. However, it is restricted to home or commercial buildings. As the protocol can address just a few nodes (limited to 64), it is not suitable for a large network like a street lighting system, which can have thousands of nodes [6]. By the other hand, a ZigBee network can have up to 65000 nodes. Zigbee standard was developed for wireless networks, focusing on low cost, low power consumption and demanding low data transmission rates with high reliability [7]. Zigbee implements network layer (NWK) and an application framework (APL sub-layer) over the MAC and PHY layers already defined by the IEEE 802.15.4 standard.

274

Fig. 1. Intelligent street lighting system routing example

Fig. 2. Example of deviation due to obstructions

Concerning to the network topology, Zigbee allows topologies ranging from a simple end-to-end connection to a mesh topology, which provides resources to establish a network with multiple routers and complete peer-to-peer (P2P) communication. In order to reduce the development time, there are commercially available off-the-shelf modules which have the Zigbee stack already programmed. For instance, Digi Inc. manufactures the XBee™ modules, which consists of a 16-bit microcontroller and a Zigbee compatible 2.4 GHz radio transceiver, deploying a full ZigBee stack [8]. Regarding the application layer, ZigBee defines what is called an application profile. It is, in short, an agreement on the messages and their format, which allows building a distributed and interoperable system for a given application. Although ZigBee routing schemes are reliable, its geographic routing capabilities are limited. In order to improve these schemes, a routing modification must be proposed, where constraints such as traffic and dead end must be addressed. A possible approach is the use of Global Positioning System (GPS) information in the node installation, since nodes are fixed.

978-1-4244-3370-4/09/$25.00 © 2009 IEEE

Besides Zigbee, there is another option to implement the network layer. It is called 6LoWPAN and stands for IPv6 protocol over IEEE 802.15.4 [9]. Its main purpose is to compress IPv6 packets and send them over an IEEE 802.15.4 link. Like ZigBee, 6LoWPAN is intended for deploying low cost, low power and low data rate wireless sensor networks. Also, it brings the internet connection capability to the network nodes with no additional hassle. Because the payload length supported by MAC in IPv6 is much greater than IEEE 802.15.4 MAC layer, 6LoWPAN works as an adaptation layer. It connects MAC layer to the network layer through header compression, fragmentation, reassembly and mesh route forwarding. Comparing Zigbee and 6LoWPAN standards, we conclude that Zigbee is itself not really a one-fits-all solution able to fully meet the constraints of the system, mainly due to its routing protocol. The Zigbee routing protocol has many drawbacks [10][11] that must be correctly addressed. A sub-optimized routing protocol may lead to several problems as high end-to-end delay and low packet delivery ratio, which severely decreases network performance. To achieve much better results, a new routing scheme must be proposed. Main features of a street lighting system may be used to find an optimized solution. In contrast, 6LoWPAN does not define routing protocol [12]. It is left opened for implementation, making easier to adapt for the specific system purposes. 6LoWPAN technology is already in use to achieve fragmentation and reassembly, mainly in industrial wireless scenarios. WirelessHART and ISA100.11a standards are examples of such application. Figure 3 depicts ZigBee and 6LoWPAN stacks reference model. III. SOFTWARE ARCHITECTURE When designing software and hardware architectures to intelligent street lighting systems, defining the desirable main features becomes important. There are several

275

constrains to be analyzed, such as size, per-device cost and energy consumption. Although it’s important to design a hardware independent architecture, the specified main features limit the hardware to microcontrollers with few amount of memory and limited processing capabilities. The proposed system must be capable to handle common requisitions in a lighting system, per example, on/off, dimming (in case of ballast which offer this option), measuring consumption and lamp life span, as well as the mandatory network functions (join the network, form the network, allow others to join the network, pair devices, enable identification mode, create scenario, and so on). All of these functions should run concurrently, due the system’s characteristics. Thus, the software structure should allow easy scalability and enable hardware abstraction, in order to meet the necessary requirements. In this context, the use of a real-time operating system (RTOS) becomes attractive. The integration of a RTOS can solve a variety of problems that can occur in the application code, since it provides multitasking capability and allows the application to be broken down into smaller pieces. Some studies proposed in the literature already use RTOS systems for wireless data network applications and present favorable results [13]. Some of them have even been designed specifically for such applications [14][15]. Another great advantage in implementing a real-time operating system for this type of system is to make the network stack transparent to the application designer. In this way, the designer can concentrate its efforts in the end goal, without worrying about the network management. Some key characteristics are desirable in a RTOS for low cost embedded systems with communication capabilities: • Light-weight kernel and network stack: since low cost embedded systems uses microcontrollers with limited amount of RAM and code memory, a good RTOS must occupy the least possible data and program memory; • Fast context switch: a RTOS with fast context switch avoids waste of execute time during the kernel scheduling; • Power management: using a RTOS in combination with idle tasks may significantly reduce power consumption and the CPU overhead by ensuring that the CPU is in its lowest possible power mode whenever it is idle; • Flexible Hardware Abstraction Layer (HAL): a HAL implementation helps porting the RTOS to different hardware platforms; • Application Programming Interface (API): a RTOS must provide a framework on which it is possible to build and organize the features of the system. Even for systems that have no need of the real-time capability, the code can be cleaner and better organized if based on a RTOS, partly because it promotes code reuse; • Reliability: Each task on a real-time operating system must be isolated from the others. In this way you can keep the system in operation even if a particular task no longer operates. Furthermore, it must correct faults wherever possible, avoiding system failures; • Upgradeability: a real-time operating system must provide the ability to be upgraded without interfering

user applications, that is, on-the-fly installation and removal of tasks, and possibly even the RTOS itself. IV. PROPOSED CIRCUIT A block diagram of the proposed system is presented in Figure 4. The system consists in a HPS electromagnetic ballast connected with a low cost microcontroller, sensors, an IEEE 802.15.4 compatible radio, a relay and AC/DC converter with transient and over-voltage protection. For the AC/DC converter we have chosen a Flyback topology because it can offer high efficiency and low cost. Also, we based the converter design on a monolithic IC with an integrated high-voltage MOSFET switch and a peak current mode controller operating at a high-frequency. This led us to achieve a very small form factor. The microcontroller communicates with the IEEE 802.15.4 radio through a SPI port. The IEEE 802.15.4 radio services are accessed by a software driver. The radio receives and processes the microcontroller requisitions, which in turn implements the network layer and the application software. The network layer is based in 6LoWPAN standard and must integrate the logic link control sub-layer. Thus, the application host microcontroller is responsible for reading the ballast sensors and driving the lamp ON/OFF relay. An application layer was implemented in order to coordinate the exchanged messages, such as ON/OFF command, dimming, voltage sensing, current sensing, etc. V. REAL-TIME OPERATING SYSTEM A wide variety of operating systems are available to suit most of projects today. Commercial operating systems form a range of functionality, performance, and price. The lower end RTOSs offer just a basic preemptive scheduler and a few other key system calls. These operating systems are usually inexpensive, come with source code, and do not require payment of any royalties. Higher end operating systems typically include a lot of functionality beyond the basic scheduler. These operating systems can be quite expensive.

Fig. 3. ZigBee and 6LoWPAN stack reference models

978-1-4244-3370-4/09/$25.00 © 2009 IEEE

276

Fig. 4. Intelligent street lighting system block diagram

With such a variety of operating systems and features to choose from, it can be difficult to decide which one is the best for the given case. Minimum and maximum memory requirements, availability of add-on software modules (for example, networking protocol stacks and device drivers), and compatibility with third-party development tools are some of the main features to be examined. For comparative purposes we choose one of the available non-commercial RTOS for the first tests. This RTOS was successfully executed on an 8-bit microcontroller, which is intended to be the application host. However, several drawbacks were found, as great amount of code size and slow context switch. In order to improve these RTOS deficiencies, an operating system with the minimum features to meet the system requirements has been proposed. The developed RTOS supports classical operating system preemption multitasking. The tasks are associate with priorities i.e, a task can be preempted by a higher-priority task that becomes eligible to run. The priority-based preemptive scheduling is used to implement the rate-monotonic algorithm so that a periodic task set with timing deadlines can be honored. Thus, the RTOS implements a network stack API and drivers to the most common debug devices. An idle task ensures that the CPU is in its lowest possible power mode whenever it is idle, disabling the CPU clock. Most peripheral continues with active clock, generating interrupts that exits the CPU from standby state. In each timer tick of the RTOS the CPU is wakeup to verify if there are any tasks ready to run. VI. EXPERIMENTAL RESULTS The proposed RTOS was ported to HCS08 (8 bits) and Coldfire (32 bits) Freescale® microcontroller families. A better context switch time was achieved in both microcontrollers, comparing with a non-commercial RTOS implementation. Thus, the code and memory size have been

978-1-4244-3370-4/09/$25.00 © 2009 IEEE

reduced considerably. Table I and II presents the data obtained in tests with both operating systems. It is important to know that lower context switch times can lead to lower power consumption, since the operating system computation time is reduced. To characterize the developed network we performed tests of link quality, delivery rate and obstacle avoidance. The evaluation shows that using LQI (Link Quality Indicator) compared to the RSSI (Receive Signal Strength Indicator) presents better relationship with packet delivery rate. Based on the literature [16] and our results we decided to use the LQI as the parameter employed for link establishment and maintenance between neighbor nodes. Thus, the implemented network stack makes use of LQI to define the most reliable path, assisting the obstacle avoidance algorithm. The integration of the network stack into the RTOS shows to be efficient and reliable, achieving data rates up to 230kbps. Other similar architectures present results limited to 30kbps [16]. To add robustness to the system, the stack monitors the radio operation. If a malfunction is verified, a self-healing routine is executed. Figure 5 shows the timing diagram of the packets reception. When a packet is received by the radio, a RTOS service must copy the data from the radio memory before a new packet arrives. During this process, the radio is disabled, leading to data rate degradation. In the worst case we were able to reaches a 93% of effective use of the maximum IEEE 802.15.4 data rate. The system power saving techniques are accomplished by the RTOS. Generally the system’s consumption is about 100mW, reaching no more than 220mW at heavy load. In the realized scheduling tests we obtained 100% of packet delivery due to a packet acknowledge scheme. Furthermore, the system was capable of restoring the communication link in mains fault conditions. TABLE I Proposed RTOS resource requirements Context Switch Time Code Space Data Memory

8 bit microcontroller @ 20 Mhz


30µs

10µs

4 Kbytes

4 Kbytes

250 bytes + 30 bytes per active task


TABLE II Tested non-commercial RTOS resource requirements Context Switch Time Code Space Data Memory



75µs

15µs

5 Kbytes

8 Kbytes



277

Fig. 5. Timing diagram of the packets reception

VII. CONCLUSION This work has presented the design of a wireless data network-based intelligent system capable of controlling and monitoring a street lighting system. It deploys a 6LoWPAN protocol, in order to realize the fragmentation and reassembly of the IPv6 messages. As 6LoWPAN does not define the routing protocol, a new routing scheme is under development. The main features of a street lighting system are being considered to find an optimized solution. We intend to use the Global Positioning System in the routing protocol to support the geographic distribution of data on the street lighting system. Additionally, the above mentioned RTOS results opened many technical challenges and opportunities to improve the performance of a RTOS to use in such applications. The set of solutions proposed in this work is being enhanced to satisfy requirements of interoperability, scalability, robustness and security as desirable in such system. ACKNOWLEDGEMENT The authors thank CAPES and National Council for Scientific and Technological Development (CNPq) to the financial support for this research. REFERENCES [1] G.B. Maizonave, F.S. Dos Reis, J.C.M. Lima, A.J. Bombardieri, F.E. Chiapetta, G.B. Ceccon, R.R.N. Souza, Jr. Tonkoski, R.W. Dos Reis, “Integrated System for Intelligent Street Lighting”, IEEE International Symposium on Industrial Electronics. Vol. 2, pp. 721726. [2] G. W. Denardin, R. P. Silveira, A. Campos, R. N. do Prado, “Specifications for a Power Management Fieldbus”, in Proc. of COBEP, pp. 166-171, 2003. [3] C. Jing, D. Shu, D. Gu, “Design of Streetlight Monitoring and Control System Based on Wireless Sensor Networks”, Industrial Electronics and 2nd IEEE Conference on Applications, 2007. pp 57-62.

978-1-4244-3370-4/09/$25.00 © 2009 IEEE

[4] J.D. Lee, K.Y. Nam, S.H. Jeong, S.B. Choi, H.S. Ryoo, D.K. Kim, “Development of Zigbee based Street Light Control System”, IEEE PES Power Systems Conference and Exposition, 2006. pp. 2236-2240. [5] Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), IEEE Std. 802.15.4, 2003. [6] DALI AG Digital Addressable Lighting Interface. DALI Manual. DALI AG of ZVEI, Division Luminaires. Germany, 2001, pp. 62. Available at http://www.daliag.org/c/manual_gb.pdf [7] ZigBee Specification (2006). ZigBee Document 053474r17. ZigBee Alliance. Available at http://www.zigbee.org [8] XBee™ ZNet 2.5 Datasheet. Available at http://www.digi.com/products/wireless/zigbeemesh/xbee-zb-module.jsp [9] X. Ma, W. Luo, "The Analysis of 6LoWPAN Technology", Computational Intelligence and Industrial Application, 2008. PACIIA '08. Pacific-Asia Workshop on , vol.1, no., pp.963-966, 19-20 Dec. 2008. [10] K. K. Lee, S.H. Kim, Y.S. Choi, H.S. Park, "A Mesh Routing Protocol using Cluster Label in the ZigBee Network," Mobile Adhoc and Sensor Systems (MASS), 2006 IEEE International Conference on, pp.801-806, Oct. 2006. [11] K. K. Lee, S.H. Kim, H.S. Park, "An Effective Broadcast Strategy for Route Discovery in the ZigBee Network," Advanced Communication Technology, 2008. ICACT 2008. 10th International Conference on, vol.2, pp. 1187-1191, 17-20 Feb. 2008. [12] 6LoWPAN Working Group. Problem Statement and Requirements for 6LoWPAN Routing. http://www.ietf.org/internet-drafts/draft-ietf-6lowpanrouting-requirements-00.txt. November 2008. [13] Cunha, A. Koubaa, R. Severino, M. Alves, "Open-ZB: an open-source implementation of the IEEE 802.15.4/ZigBee protocol stack on TinyOS," Mobile Adhoc and Sensor Systems, 2007. MASS 2007. IEEE Internatonal Conference on, pp.1-12, 8-11 Oct. 2007. [14] Dunkels, B. Gronvall, T. Voigt, "Contiki - a lightweight and flexible operating system for tiny networked sensors," Local Computer Networks, 2004. 29th Annual IEEE International Conference on, pp. 455-462, 16-18 Nov. 2004. [15] P.A. Levis, "TinyOS: An Open Operating System for Wireless Sensor Networks (Invited Seminar)," Mobile Data Management, 2006. MDM 2006. 7th International Conference on, pp. 63-63, 10-12 May 2006. [16] M.M. Holland, R.G. Aures, W.B. Heinzelman, “Experimental investigation of radio performance in wireless sensor networks”, Wireless Mesh Networks, 2006. WiMesh 2006. 2nd IEEE Workshop on, pp.140150, 25-28 Sept. 2006.

278