Dynamic Rolling Single-Action Schedules vs Firmware OTA: Ingenious Workaround or Field Maintenance Nightmare?

[carlos_mendez]

[!WARNING]
Technical Redaction & Safe Harbor Notice:
All communication captures, system titles, and cryptographic parameters in this thread have been sanitized and neutralized. Real utility meter identifiers, production encryption keys (GUEK/GAK/MK), SIM IMSIs, and proprietary network envelopes have been substituted with standard IEC 62056 synthetic test vectors. Do not post unredacted production captures or live cryptographic keys.

Following our earlier deep dive where we confirmed that our deployed polyphase smart meters lock Class 22 Single Action Schedule (0.0.15.0.1.255) to Attribute 3 Type 1 (allowing only a single execution time in Attribute 4), our systems engineering team brainstormed what seems like an ingenious architectural workaround.

Instead of waiting 6 months and paying the meter manufacturer $50k in NRE fees for a firmware OTA upgrade to implement Class 10 (Schedule), why not maintain an active Rolling Task Daemon on the Head-End System (HES)?

Here is the concept:

1. The HES writes the next immediate scheduled load-shedding time (e.g. 08:00:00) into 0.0.15.0.1.255 Attribute 4:

00 01 00 01 00 01 00 1B C1 01 C1 00 16 00 00 0F 00 01 FF 04 00 01 01 02 02 09 04 08 00 00 00 09 05 FF FF FF FF FF

2. The meter trips at 08:00:00.
3. Upon receiving the Class 40 Push event or when the HES clock passes 08:00, the daemon immediately transmits a follow-up SET request overwriting Attribute 4 with the subsequent time (e.g. 12:00:00

00 01 00 01 00 01 00 1B C1 01 C2 00 16 00 00 0F 00 01 FF 04 00 01 01 02 02 09 04 0C 00 00 00 09 05 FF FF FF FF FF

4. Both SET requests return Data-Access-Result: success (0x00

00 01 00 01 00 01 00 04 C5 01 C1 00

This dynamically shifts the execution window forward, effectively delivering infinite multi-point scheduling capability over legacy single-shot firmware without touching the meter hardware. Isn't this the ultimate zero-cost cloud workaround?

[marcus_vance]

From a cloud backend perspective, I have to admit this is tempting. We already maintain the master customer tariff and load-shedding schedules in our cloud MDMS and Redis caches.

By treating the meter's Class 22 Attribute 4 as a single-item hardware execution mailbox that the HES periodically repopulates, we bypass the immense headaches of debugging Class 10 schedule_table_entry calendar math and Daylight Saving Time edge cases across multiple vendor stacks. We could deploy this service across our 40,000 meters tomorrow.

[alex_turner]

Marcus, Carlos, look closely at the fatal flaw in your assumption. From a distributed systems and security perspective, this proposal breaks the most fundamental tenet of smart grid engineering: local autonomy.

You are converting an autonomous metrological device into a distributed state-machine slave tethered to continuous cellular availability. Consider what happens during a severe winter storm or cellular base-station failure: the meter successfully executes the 08:00 load trip, but the HES fails to deliver the 12:00 follow-up rewrite due to backhaul packet loss. The schedule halts permanently, leaving industrial consumers disconnected or in an undefined state.

Furthermore, per DLMS UA Green Book 10th Ed Section 9.3.4, every SET request consumes cryptographic Invocation Counters (IC) and triggers non-volatile flash sector writes. You are introducing continuous network traffic and active attack surface for a job that should be statically autonomous.

[elena_rostova]

As an embedded firmware lead who has maintained smart meters over 15-year lifecycles, I am genuinely horrified by this hack. This is the textbook definition of technical debt that metastasizes into an operational catastrophe.

Let me lay out two devastating operational realities that you will face:

1. Field Triage & Optical Probe Blindness

When a communication concentrator fails in a substation and a field technician drives out to troubleshoot with a handheld optical probe (IEC 62056-21 Mode E), what will they see? They will read 0.0.15.0.1.255 Attribute 4 and see a single timestamp from 3 days ago. They will have zero visibility into your cloud Redis queue, conclude that the meter's schedule table is broken or corrupt, and needlessly replace perfectly good meters.

2. Documentation Rot & Knowledge Evaporation (Loss of Historical Context)

However, consider the long-term flaw in this approach. In 3 to 5 years, when the original developers who built this HES daemon leave the utility and the backend is refactored into a new cloud platform, nobody will remember that these 40,000 physical meters depend on a proprietary rolling overwrite loop. The first time the background worker crashes, the entire metering fleet becomes unmanageable.

Per DLMS UA Blue Book (17th Ed.) Section 4.5.4 and IEC 62056-62 Clause 4.5.4, COSEM objects are designed to be self-contained and auditable. Turning Class 22 into a volatile scratchpad violates the integrity of the meter as the legal system of record.

[carlos_mendez]

Elena, Alex, aren't you being slightly dogmatic here? In the real world, utilities have strict deadlines and cannot wait 9 months for meter vendors to recertify firmware through CTT and MID laboratories!

We have RabbitMQ dead-letter queues, exponential backoff retries, and high-availability database clusters. Modern smart meter SPI NOR Flash / EEPROM typically has an endurance of 100,000 write cycles. Writing 4 timestamps a day equals 1,460 writes per year—giving us over 68 years of flash endurance!

Why is a battle-tested, pragmatic cloud queue worse than telling the utility executive board that our $15M AMI infrastructure cannot perform basic automated load control today?

[carlos_mendez]

You know what... after walking through our substation failure runbook with our lead field supervisor this afternoon, I have to step back and concede. Elena's point about the optical probe blindspot and documentation rot hit home.

If a field technician with an optical probe cannot trust what 0.0.15.0.1.255 says locally because the true schedule lives only in our cloud Redis instance, we are creating an untraceable split-brain condition. When cellular towers go dark during a typhoon, having meters stranded because their schedule loop was severed upstream is unacceptable for grid reliability.

We agree to abandon the rolling rewrite hack. Here is our finalized, standard-compliant path forward:

1. For Real-Time Demand Response: When online, the HES will issue explicit, synchronous Action-Request-Normal APDUs invoking Class 70 Method 1/2 directly, ensuring immediate transaction confirmation without corrupting schedule state.
2. For Autonomous Multi-Task Scheduling: We will submit an official engineering change request to the meter vendor to implement Class 10 (Schedule, OBIS 0-0:12.0.0*255) per Blue Book Section 4.5.3, ensuring all recurring entries are verified and stored locally inside the meter's certified NVRAM.
3. For Current Fixed Cycles: We will strictly utilize the dual Class 22 slots (0.0.15.0.1.255 for Disconnect, 0.0.15.0.3.255 for Reconnect) as static, auditable daily setpoints.

Engineering pragmatism cannot come at the expense of field maintainability and self-contained meter truth.