astronomicalclocks1

Street lighting control system — using the internal clock of AMI meters to replace conventional astronomical clocks

Cooperation: Research Office, Mashhad Electricity Distribution Company


Abstract

This report proposes a practical industrial solution to replace standalone astronomical clocks in street lighting controllers by using the internal clock of AMI (Advanced Metering Infrastructure) smart meters installed in street distribution panels. Time and date are read from the meter via the RS-485 port using the DLMS/COSEM protocol (Low Security Level — LLS). This reduces maintenance (battery replacement), avoids clock drift and noise-induced errors, and leverages existing infrastructure for more reliable on/off scheduling.


1. Problem statement

Problems observed with conventional astronomical clocks:

  • Internal battery failure causing clock resets and incorrect sunrise/sunset calculations.
  • Susceptibility to electrical noise and interference that corrupts timekeeping.
  • Result: street lamps ON during daylight or OFF after dark → energy waste and safety issues.
NighTime
DayTime

Desired behaviour: accurate automatic switching aligned to true local sunrise/sunset, with low maintenance and high reliability.


2. Proposed solution (high level)

Use the internal real-time clock of AMI smart meters (already present in street distribution panels) as the authoritative time source for the lighting controller. The lighting controller polls the meter over RS-485 using DLMS/COSEM (LLS) to read the meter clock (COSEM Clock object). The controller then applies local sunrise/sunset logic (or a schedule) to actuate street lights.


3. Why this is viable — standards & technologies


4. Protocol & security considerations

  • DLMS/COSEM security modes: Lowest/LLS/High. For reading a meter’s clock in low-risk contexts, utilities commonly use LLS (password/basic). However, LLS provides minimal protection and should be assessed with corporate cyber policies. See discussion of DLMS security basics:
    DLMS security basics (overview)

  • Best practice:

    • Prefer authenticated sessions where possible.
    • Validate time values (e.g., monotonic checks, cross-check with a secondary source occasionally).
    • Maintain logging and tamper-detection (e.g., sudden large time jumps should trigger fallbacks).
    • Use LLS only if organizational risk assessment permits it for time reads; otherwise use higher DLMS security (HLS).

The system architecture consists of three main components:

  • AMI Smart Meter (Clock): Provides the internal time.

  • Lighting Controller: Reads the clock from the meter via RS-485 using DLMS/COSEM protocol.

  • Switch/Relay Unit: The controller actuates this to turn street lights ON/OFF.

flowchart A[AMI Smart Meter (Clock)] – RS-485 / DLMS-COSEM –> B[Lighting Controller] B –> C[Switch / Relay / Contactor] C –> D[Street Lights]

Flowchart_AMI11

Key components

  • Meter: exposes COSEM Clock object via DLMS/COSEM (LN or SN referencing).
  • Lighting controller: small embedded controller or PLC with RS-485 interface and DLMS/COSEM client stack.
  • Communication: twisted-pair RS-485 cable with proper termination, biasing resistors and surge protection.
  • Fallback: maintain local astronomical schedule (on-board astronomical clock) to use when meter time is unavailable or invalid.

6. Implementation steps (practical)

  1. Inventory & compatibility check: identify meter models in the target panels and confirm DLMS/COSEM support and accessibility via the meter RS-485 port.
  2. Obtain DLMS object addresses: find the meter’s Clock logical name / attribute index (Clock Class ID = 8). Test with a DLMS client tool (e.g., Gurux tools).
  3. Develop controller client: implement a lightweight DLMS/COSEM client supporting LN or SN referencing and RS-485 physical layer. Poll the clock at a safe interval (e.g., every 1–5 minutes).
  4. Time validation logic: implement sanity checks (e.g., leap checks, drift thresholds, monotonic time), and a fallback to local astronomical calculation if invalid.
  5. Security & operations: choose appropriate DLMS security level; maintain password storage and audit logs; test for failure modes and cyber-hardening.
  6. Pilot deployment: run a small pilot in a subset of panels; log results (uptime, false ON/OFF events, latency), tune polling interval and validation thresholds.
  7. Roll-out & monitoring: deploy widely if pilot is successful; include remote monitoring dashboards.

7. Advantages & limitations

Advantages

  • Uses existing meter infrastructure — reduces extra hardware and maintenance (no battery swaps).
  • Potentially more accurate and synchronized time (especially if meters are NTP/GPS-synced at the head-end).
  • Centralized management possibility through head-end systems.
Hardware 1
Hardware 2
Hardware 3

Limitations & risks

  • If meter clock is itself wrong (misconfiguration or attack), lights may misbehave — require validation/fallback.
  • RS-485 cabling practices must be robust (termination, surge protection) to avoid noise-induced errors.
  • DLMS LLS has weak security — evaluate against organizational policy.

Installation of a prototype and testing in one of the electricity corridors of District 9 of Mashhad.

MashhadCon1

Manufacturing 30 samples of the aforementioned device based on changing the structure of existing watches (by reverse engineering and changing the program of existing microcontrollers and adding the required hardware components) Installation in 30 locations in the holy city of Mashhad and successful exit from this test. Efforts to finalize the design and present the design in a national format for mass production

8. References (select)


9. Appendix — Example DLMS Clock read (conceptual)

A DLMS LN-read request for the Clock (Class ID = 8) attribute (AttributeIndex = 2, depending on vendor) will return a COSEM DateTime structure. Use existing DLMS client libraries (e.g., Gurux, vendor SDKs) to decode the returned DateTime to UTC/local time, then apply local timezone/astronomical rules.