Design Article
Smart street lighting
A. Bruno, F. Di Franco, G. Rasconà, C. Ruggieri, STMicroelectronics
6/12/2012 10:40 AM EDT
FIRMWARE CODE AND PC GUI
The firmware implementing the network model previously described is structured in several layers, each one performing different operations.
The top layer of the firmware is constituted by the user firmware, in this case implementing the street lighting protocol. The state machines for the lamp management, which send and receive commands to and from the lamp power supply are implemented at this stage. There are three types of frame that can be sent to the power line modem. The first are data frames, which contain the user data to send (such as lamp on, lamp off, lamp dimming) and the parameters read from the lamp power supply (such as lamp power, lamp voltage, ambient temperature). The second are programming frames, which contain the programming parameters of the node like node unique address and user data to store in the flash memory. The last are service frames, which contain parameters as well as the PLM stack parameters including timing and data repetitions, the node time clock. The service frames also include parameters setting the node working model that are dependent on the network model to implement (for example, with or without acknowledgement, broadcast behavior, repetition mode).
All those frames are managed by the application engine, the manager of the information transiting into the node. The data frames containing user data are transferred by the engine from the user level to the PLM stack level. Here the user information is packed and added with the needed information such as FEC and cyclic redundancy check - CRC, and sent to the PLM. This works both ways: if the PLM catches proper data packets, these are managed by the stack. The FEC is used to correct wrong data (if any), the CRC is also checked, and if valid data are decoded, these are sent to the engine to be treated and addressed. The PLM stack directly manages the repetitions, the necessary timing and acknowledgements.
If the target device does not acknowledge a data frame, each neighboring node, with the repetition feature enabled, that has sensed the transited data frame, will forward it, after the acknowledge timeout, as long as the band is not already taken. This repetition mechanism, managed directly by the PLM stack engine, is done once per each node until either the data frame is acknowledged or each node has repeated the data frame. The repetition mechanism is also implemented for the acknowledgement frame, when not received by the master.
As each firmware layer adds its own information to the original frame, 100 bytes of user data from the application engine become more than double that at the power line level. This is mainly because of the FEC redundancy added to each byte as soon as it arrives at a target node. Network traffic is therefore reduced if the power line is not overly noisy because the FEC algorithm can adjust the corrupted information.
Each frame also contains the target address, the source address, and other parameters. These might include a flag byte indicating the network model (the flag indicates if the repetition has to be ignored for this frame, or if the acknowledge is awaited), a frame ID to avoid multiple repetitions of the same frame, the CRC (CRC16) bytes, the modem preamble, header and postamble byte.
Another implemented mechanism related to repetitions is ‘hopping.’ The hop level is one of the user-defined PLM parameters and is employed to assign a certain hierarchy in the repetition. If a frame has to be repeated but the hop level is lower than the one stored in the PLM parameter, the frame is not forwarded. Normally, the hierarchy is set depending on the distance and the ambient noise condition. The closer the repetition-enabled node is to the concentrator, the higher the hop level, and in this way, the traffic of insignificant repetitions is reduced.
Network grouping is another feature that can be implemented by the user. If it is, the first two bytes of any frame address, which is 6 bytes long, are considered the group address. Each frame with a group address different from the assigned group is ignored. In this way it is possible that more than a network can share the same power line without interacting with each other.
The current firmware implementation is unique for any kind of device, master, slave, or repeater. The PLM stack is able to understand when the master, slave, or repeater state machine has to be executed, depending on the data context.
A dedicated graphic user interface (GUI) is available in order to test or manually manage the street lighting features. Using the GUI, the user is able to set all the PLM parameters, to operate on each lamp and directly address the target node or perform broadcast operations such as switching on/off/dimming the lamp, or to get all the lamp parameters (lamp status, lamp power, bus voltage). The GUI runs on a PC and communicates with each node via the RS232 interface. After the programming phase, where each node is set with a unique address, a local database is created and stored in the PC. All the installed nodes are shown in the appropriated list boxes of the GUI.
Figure 4: “Remote controller over PLM communication” graphic user interface.
In the HID section, the user can perform all the manual operations on each lamp connected to the node shown in the list box or perform broadcast operations simply by enabling the broadcast check box.
A dedicated section of the GUI, as shown in Figure 4, allows the user to set up a profile of on/off/dimming operations for a given node, associating a time clock to each lamp. Each occasion the stored clock time is reached, the node executes the associated operation on the lamp. Up to six steps can be stored and executed in the user data memory of the PLM.
A log window is used to verify the result of each completed operation by using the interface, modem results, and errors.
Next: Examples:
The firmware implementing the network model previously described is structured in several layers, each one performing different operations.
Figure 2: Firmware structure of the power line modem
The top layer of the firmware is constituted by the user firmware, in this case implementing the street lighting protocol. The state machines for the lamp management, which send and receive commands to and from the lamp power supply are implemented at this stage. There are three types of frame that can be sent to the power line modem. The first are data frames, which contain the user data to send (such as lamp on, lamp off, lamp dimming) and the parameters read from the lamp power supply (such as lamp power, lamp voltage, ambient temperature). The second are programming frames, which contain the programming parameters of the node like node unique address and user data to store in the flash memory. The last are service frames, which contain parameters as well as the PLM stack parameters including timing and data repetitions, the node time clock. The service frames also include parameters setting the node working model that are dependent on the network model to implement (for example, with or without acknowledgement, broadcast behavior, repetition mode).
All those frames are managed by the application engine, the manager of the information transiting into the node. The data frames containing user data are transferred by the engine from the user level to the PLM stack level. Here the user information is packed and added with the needed information such as FEC and cyclic redundancy check - CRC, and sent to the PLM. This works both ways: if the PLM catches proper data packets, these are managed by the stack. The FEC is used to correct wrong data (if any), the CRC is also checked, and if valid data are decoded, these are sent to the engine to be treated and addressed. The PLM stack directly manages the repetitions, the necessary timing and acknowledgements.
If the target device does not acknowledge a data frame, each neighboring node, with the repetition feature enabled, that has sensed the transited data frame, will forward it, after the acknowledge timeout, as long as the band is not already taken. This repetition mechanism, managed directly by the PLM stack engine, is done once per each node until either the data frame is acknowledged or each node has repeated the data frame. The repetition mechanism is also implemented for the acknowledgement frame, when not received by the master.
Figure 3: Data communication flow with a case of repetition
As each firmware layer adds its own information to the original frame, 100 bytes of user data from the application engine become more than double that at the power line level. This is mainly because of the FEC redundancy added to each byte as soon as it arrives at a target node. Network traffic is therefore reduced if the power line is not overly noisy because the FEC algorithm can adjust the corrupted information.
Each frame also contains the target address, the source address, and other parameters. These might include a flag byte indicating the network model (the flag indicates if the repetition has to be ignored for this frame, or if the acknowledge is awaited), a frame ID to avoid multiple repetitions of the same frame, the CRC (CRC16) bytes, the modem preamble, header and postamble byte.
Another implemented mechanism related to repetitions is ‘hopping.’ The hop level is one of the user-defined PLM parameters and is employed to assign a certain hierarchy in the repetition. If a frame has to be repeated but the hop level is lower than the one stored in the PLM parameter, the frame is not forwarded. Normally, the hierarchy is set depending on the distance and the ambient noise condition. The closer the repetition-enabled node is to the concentrator, the higher the hop level, and in this way, the traffic of insignificant repetitions is reduced.
Network grouping is another feature that can be implemented by the user. If it is, the first two bytes of any frame address, which is 6 bytes long, are considered the group address. Each frame with a group address different from the assigned group is ignored. In this way it is possible that more than a network can share the same power line without interacting with each other.
The current firmware implementation is unique for any kind of device, master, slave, or repeater. The PLM stack is able to understand when the master, slave, or repeater state machine has to be executed, depending on the data context.
A dedicated graphic user interface (GUI) is available in order to test or manually manage the street lighting features. Using the GUI, the user is able to set all the PLM parameters, to operate on each lamp and directly address the target node or perform broadcast operations such as switching on/off/dimming the lamp, or to get all the lamp parameters (lamp status, lamp power, bus voltage). The GUI runs on a PC and communicates with each node via the RS232 interface. After the programming phase, where each node is set with a unique address, a local database is created and stored in the PC. All the installed nodes are shown in the appropriated list boxes of the GUI.
Figure 4: “Remote controller over PLM communication” graphic user interface.
In the HID section, the user can perform all the manual operations on each lamp connected to the node shown in the list box or perform broadcast operations simply by enabling the broadcast check box.
A dedicated section of the GUI, as shown in Figure 4, allows the user to set up a profile of on/off/dimming operations for a given node, associating a time clock to each lamp. Each occasion the stored clock time is reached, the node executes the associated operation on the lamp. Up to six steps can be stored and executed in the user data memory of the PLM.
A log window is used to verify the result of each completed operation by using the interface, modem results, and errors.
Next: Examples:
|
|
|
|
|
Navigate to related information
elPresidente
6/13/2012 1:17 PM EDT
"The last block of a smart street lighting system we’ll discuss is smart sensing. What happens if a lamppost falls..." SERIOUSLY? Does it make a sound?
Sign in to Reply
docdivakar
6/20/2012 3:23 PM EDT
@elPresidente: your pun aside, there are benefits to using position/attitude sensing enabled light posts in the system. For example, if an area is undergoing settlement of the soil, seismic motions, etc., the sensor data can relay the current state of orientation.
MP Divakar
Sign in to Reply
Bert22306
6/13/2012 6:53 PM EDT
Dunno, sometimes I think that what could be simple is being made unnecessarily complicated, supposedly in the name of efficiency.
One example being remote control of the lights. Aren't street lights individually controlled now, via individual sensors? Those sensors perhaps can be improved, to include the same extra flexibility that the article claimed for the remote control case. Such as, dimming in brightly moonlit nights?
I like the idea of remote sensing that a light is out. But our local utility has gone one step "further." Remote sensing for free. They expect the customers to call it in, AND they have made it really easy to do so. Automatic phone call, 24 hours a day. Plenty of "remote sensing," and they use an existing network to boot!!
Sign in to Reply
docdivakar
6/20/2012 3:26 PM EDT
@Bert22306: you are right, the technology to dim based on ambient lighting and/or motion / occupancy sensing is so old that the products are available as commodities. These individual sensor no doubt can be improved to perform more functions.
MP Divakar
Sign in to Reply
gayatrikumar_1
6/14/2012 5:06 PM EDT
The potential of this application could be best explained with statastical data of a survey on current energy wastage and possible improvements in street light availability, Maintanace charges. Figures speak louder.
I our city cellular repeaters are mounted on to the street light lap posts on several flyovers and bridges.
Main Control point of a cluster of lamps located at one point which could be automated this way.
I think this should ramup slowy so that it doesnt cause jerk in empolyment.
Sign in to Reply
docdivakar
6/20/2012 3:18 PM EDT
Nice write up; though not all aspects of such a smart lighting system has been addressed, the authors describe a system that can be deployed today.
It would be nice to know more on the life cycle of the products mentioned in the smart lighting system -like field replacements, expansion of more functions, additional sensing, etc.
MP Divakar
Sign in to Reply
Zviak
8/27/2012 10:36 AM EDT
I think that the standard of smart street light should include motion sensors. Can any of you recommend best supplier of such system?
Sign in to Reply
anne-francoise.pele
7/26/2012 5:38 PM EDT
Click on the link below to check out the collection of Design Articles, Case Studies, Product How-To articles,... related to LEDs that have been published on Smart Energy Designline.
Check back frequently. The list will be updated as new articles arrive.
http://www.eetimes.com/design/smart-energy-design/4371743/LED-Focus
Sign in to Reply
trojes
1/7/2013 4:35 PM EST
Sorry it is not the same issue, but I need information to present a business case of Intelligent Street Light Project, can you help me.
Regards
Sign in to Reply