Lighting solution that increases driver awareness of crossing pedestrians tested in Copenhagen.
The purpose of the project
The City of Copenhagen and Citelum wanted to test a dynamic lightning/dimming solution on the so called “Toronto” crossings. The “Toronto” crossing are pedestrian crossings that do not have traffic lights nor pedestrian lights.
To increase the safety on those crossings the aim is to increase the lights at the crossing when a pedestrian is approaching the crossing. The increase of light will allow the drivers to have more visibility of the movements of the pedestrians and so increasing the safety. Citelum has demonstrated, at the ITS 2017 fair, a solution using Silver Springs Network technology and radar as detection sensors for the dynamic lightning.
The aim of this Proof of Concept is to deploy the solution in Copenhagen for testing and demonstration. The objective is to increase the lights at the crossing when a pedestrian is approaching the crossing. Thus increasing the safety.
Copenhagen identified one solution that is able to fulfil the most typical scenarios when installing motion sensors. The solution proposed that is the combination of a motion sensor and a SSN node. It provides a high reliability while it decreases the installation efforts as it is wirelessly connected to the luminaires.
The 2 scenarios defined on this project are the installation of:
1) Motion sensor away from the crossing
- In the use case the motion sensor (radar or PIR sensor) will be installed away form the crossing – on a pole for example – connected to a “SSN-enabled” control node (Cincom control nodes have been tested so far).
- This control node connected to the sensor is the “master” control node
- Once the sensor detects movement will make the control node send a command – over the rf mesh – to the selected control nodes in the luminaires to dim up the light for a predefined time.
2) Motions sensor at the crossing
- The control node is installed on the luminaire itself and the sensor is also on the luminaire or on the arm near the luminaire
- Wiring is necessary from the control node to the motion sensor
- Once the sensor detects motion will dim up the light that it is connected to the control node
The high-level architecture diagram:
Citelum – solution design
City of Copenhagen, project owner & co-designer of solution
Itron – Supported the development of the technical solution
- A 7-pin SSN-enabled control node or photocell running NIC FW 3.10.1b (or newer) and appropriate FW on the control node component (example if CIMCON then FW 1.0.26 (or newer)) that serves as the Master device.
- This Master device is to be paired with a dimmable luminaire with 7-pin socket, with a digital motion sensor wired to the digital input of the socket.
- The dynamic lighting is triggered by a change in the digital input on the Master photocell. The photocell needs to be wired as shown in the diagram below. A typical PIR sensor provides a “clean” (voltage free) contact that changes state depending on whether motion has been detected. This needs to be coupled with a power supply such that a voltage of between 0.8 and 20V 2.7 and 24VDC is applied to the digital input on the photocell (note the CIMCON PRD (v13) states 0.8 to 20VDC for a logic “high”, but latest info from CIMCON is the unit will work up to 24VDC, and minimum voltage for logic high is 2.7VDC)
- Some PIR motion sensors will close the contact on detection of motion, while others may open the contact on detection of motion. The photocell should be configured for the appropriate mode by setting attribute 2074. By default, this is set to 0, where the photocell is configured to assert motion detect at Active Low, i.e. motion detected will be asserted with a 0V input on the DI. This is a common case for PIRs that are designed to “fail safe”, where the contact is normally closed, but is opened when motion is detected. The wiring diagram above shows a PIR with a normally closed contact. Conversely, if the PIR closes the contact on detection of motion, attribute 2074 on the photocell should be set to 1 (Active High).
- Regular dimmable control nodes running NIC FW 3.10.1b that serve as Slave device(s). The Slave device(s) can be paired with regular dimmable luminaire(s).
- Both the Master and Slave control nodes NICs must have time, a time zone defined, and active Talq calendars running on them.
- Note: the other NIC setting relevant to the dynamic dimming setup is attribute 41, being the minimum amount of time that the “motion detected” state is asserted upon change of state of the digital input pin. The appropriate setting for this value needs to be considered in the context of how long the lights are “brightened” for. The Lua script operates by sending a temporary override command to the lights to go to a higher brightness for a period of “x” seconds (the value of “x” is defined in the Lua script, as detailed below). Just prior to “time t = x”, the script checks if the motion detect attribute is still asserted. If still asserted, it sends another command for the lights to brighten for another “x” seconds. Consequently, attribute 41 should be set to a lower value than the override time specified in the Lua script.
- The dynamic lighting feature does not work for devices running legacy SLAPI schedules; it only works on devices running Talq calendars.
- The Lua scripts will only set devices to a higher lighting level
- Furthermore, the scripts will only adjust the brightness level when the Talq calendar is in an active period. Outside of an active calendar period the scripts have no effect.
- The script operates using link-local address; consequently, the Master can only send commands to slave devices that it can see directly (i.e. that are in its node or one-hop away).
We are expecting to see a higher awareness from the drivers to the people crossing through the street. At the same time, we hope to increase the attractiveness of the pedestrian crossings to the citizens.
We had the radar that was meant to detect only the pedestrians. It was capped to detect things moving slower than 5km/h. Also, we installed a PIR sensor, which means that it turns on when it detects some presence. The radar never turned on if a car or a bicycle was on the area. However, sometimes it had a little difficulty to detect. But in general, the radar worked much better than the PIR which turned on every single time if something was on the area which is a little bothering as well.
We had a drawback because one of the radars was not working properly, so we sent it for RMA but the delivery time was not going to be good enough, so we replace it with a PIR and it allowed us the possibility to understand the differences between the 2 kinds of detecting.
Date of opening: 01/09/2018
Emdrupvej 23, 2100 København
As the results seem positive, this solution could be implemented in all the other Toronto crossings
Email: firstname.lastname@example.org Phone: +45 61247106