An Intelligent System for Street Lighting Control and ... - IEEE Xplore

An intelligent system for street lighting control and measurement Gustavo W. Denardin, Carlos H. Barriquello, Rafael A. Pinto, Marcelo F. Silva, Alexandre Campos and Ricardo N. do Prado, Member, IEEE 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 a ZigBee™ 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. Index Terms – Street lighting system, wireless sensor network, ZigBee™.

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 a ZigBee™ 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. II. NETWORK MODEL The street lighting systems feature 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 Fig. 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 Fig. 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 Fig. 2 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. To comply with this set of requirements it is preferable to rely on an existing standard like ZigBee, since this kind of solution is primarily designed with that intention. ZigBee standard was developed for wireless networks, focusing on low cost, low power consumption and demanding low data transmission rates with high reliability [5]. 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. 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, it was chosen to use commercially available off-theshelf modules. The module used was the XBee™ ZNet 2.5, manufactured by Digi Inc., which consists of a 16-bit microcontroller and a ZigBee compatible 2.4 GHz radio transceiver [6]. 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.

978-1-4244-3476-3/09/$25.00 ©2009 IEEE

Fig. 1. Intelligent street lighting system routing example

Fig. 2. Example of deviation due to obstructions

Although ZigBee routing schemes are reliably, it’s 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. III. SOFTWARE ARCHITECTURE When designing software and hardware architectures to intelligent street lighting systems, defining the desirable main features becomes important. There are several constrains to be analyzed, such as size, per-device cost and energy consumption. Although it is 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, 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 [7]. Some of them have even been designed specifically for such applications [8][9]. Another great advantage in implement 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 system 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 Fig. 3. The system consists in a HPS electromagnetic ballast connected with a low cost microcontroller, sensors, a ZigBee radio, a relay and AC/DC converter with transient and overvoltage 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 ZigBee radio through an UART port. The ZigBee radio services are accessed by a proprietary API. The radio receives and processes the microcontroller requisitions, turning the ZigBee stack transparent to the application software. The ZigBee radio is composed by an IEEE 802.15.4 compliant transceiver and a microcontroller, which implements network and MAC ZigBee layers. 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. 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.

Fig. 3. Intelligent street lighting system block diagram

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 In this section is presented the experimental results of the system at two levels: network and software. A. Network We analyze the addressing / routing schemes available on Zigbee in order to verify its performance in the street lighting system. The hierarchical addressing scheme it is not the better solution to geographic distributed networks. That scheme could lead the address range to end really fast (in case of network maximum routers > 1) or could not allow all nodes to join in the network, leaving them orphans (in case of network maximum routers = 1). This problem gets worse when we consider the topology of a street lighting system. The stochastic addressing scheme is a better solution, but the Ad hoc on-demand distance vector (AODV) routing algorithm used in this case has some deficiencies. The routing discovery mechanism issues broadcast messages to perform path discovery. This mechanism causes a lot of traffic in a network with kilometers of extension. Thus, since the low cost path is discovered, it will not change unless it is broken. That scenario could create overloaded paths. Due to these limitations, a new routing algorithm and addressing scheme are under development. It uses GPS information, node depth (distance to PAN coordinator) and traffic to define an optimized path. Always that messages are addressed to PAN coordinators, the first approach will be routing by node depth. If the link is lost during this process, a path discovery geographic algorithm is activated. Most of network messages will be in the coordinator direction, e.g. measurements and faults communications. In this way, most of network traffic will be generated by a simple routing protocol, which has no dead-end and obstacle avoidance problems. As the new routing algorithm is not fully tested yet, the system is operating with stochastic addressing and AODV routing algorithm. B. Software 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 the non-commercial RTOS implementation. Thus, the code and memory size have been reduced considerably. Table 1 and 2 presents the data obtained in tests with both operating systems.

TABLE I PROPOSED RTOS RESOURCE REQUIREMENTS

Context Switch Time

8 bit microcontroller @ 20 Mhz


30µs

10µs

Code Space

4 Kbytes

4 Kbytes

Data Memory

150 bytes + 20 bytes per active task


TABLE II TESTED NON-COMMERCIAL RTOS RESOURCE REQUIREMENTS

Context Switch Time



75µs

15µs

Code Space

5 Kbytes

8 Kbytes

Data Memory



It is important to know that lower context switch times can lead to lower power consumption, since the operating system computation time is reduced. Indeed, this fact is not the only advantage of the RTOS. When developing such system, one of the major challenges was the concurrency between the network services and the application software. For instance, when a packet is received during measurement tasks, the RTOS must handle the data (i.e. buffering data from the radio) before a new packet arrives. When the measurement task ends, the RTOS processes the pending packets. In this situation, the RTOS has shown to be very efficient to manage both sides, mainly due to its priority scheme. As can be seen, a bad priority allocation could lead to a poor system performance. 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. The proposed system was based on ZigBee standard, in order to satisfy requirements of interoperability, scalability, robustness and security. However, 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. Additionally, the above mentioned RTOS results opened many technical challenges and opportunities to improve the performance of a RTOS to use in such applications.

ACKNOWLEDGEMENT The authors thank CAPES and National Council for Scientific and Technological Development (CNPq) to the financial support for this research. REFERENCES [1]

[2] [3] [4] [5]

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. 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. 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. 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. ZigBee Specification (2006). ZigBee Document 053474r17. ZigBee Alliance. Available: http://www.zigbee.org

[6]

XBee™ ZNet 2.5 Datasheet. Available: http://www.digi.com/products/wireless/zigbee-mesh/xbee-zbmodule.jsp [7] A. Cunha, A. Koubaa, R. Severino, M. Alves, "Open-ZB: an opensource 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. [8] A. 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. [9] 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. [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.