<p dir="auto">From the field triage and deployment perspective, there is a major practical trap: <strong>Cold-Start Invocation Counter Desynchronization</strong>.</p> <p dir="auto">Consider this real-world scenario:</p> <ol> <li>A meter undergoes a battery replacement or hardware power cycle in the field, resetting its volatile memory or rolling back its internal Invocation Counter ($IC$) to <code>1</code>.</li> <li>The Head-End System (HES) database still stores the last recorded meter counter, say $IC = 482,105$.</li> <li>When HES attempts an HLS 5 handshake, the meter sends its Server Challenge with $IC = 1$. The HES security gate rejects the frame because $IC_{\text{received}} < IC_{\text{expected}}$ (anti-replay defense per <strong>DLMS Green Book Section 9.2.7.2</strong>).</li> </ol> <h3>How to Recover Without Compromising Security:</h3> <p dir="auto">Before initiating HLS 5 on Management Logical Device:</p> <ul> <li>Connect as <strong>Public Client (Client ID 16)</strong> with <code>No Security</code> (<code>0x00</code>).</li> <li>Read <code>Association LN</code> (<code>0.0.40.0.0.255</code>, Class 15) Attribute 8 or <code>Security Setup</code> (<code>0.0.43.1.0.255</code>, Class 64) Attribute 4 (<code>invocation_counter</code>).</li> <li>If authorized by security policy, read and resynchronize the baseline $IC$ in the HES database before triggering High-Level Security.</li> </ul>

<p dir="auto">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.</p> <p dir="auto">If a field technician with an optical probe cannot trust what <code>0.0.15.0.1.255</code> 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.</p> <p dir="auto">We agree to abandon the rolling rewrite hack. Here is our finalized, standard-compliant path forward:</p> <ol> <li><strong>For Real-Time Demand Response</strong>: When online, the HES will issue explicit, synchronous <code>Action-Request-Normal</code> APDUs invoking Class 70 Method 1/2 directly, ensuring immediate transaction confirmation without corrupting schedule state.</li> <li><strong>For Autonomous Multi-Task Scheduling</strong>: We will submit an official engineering change request to the meter vendor to implement <strong>Class 10 (Schedule, OBIS <code>0-0:12.0.0*255</code>)</strong> per Blue Book Section 4.5.3, ensuring all recurring entries are verified and stored locally inside the meter's certified NVRAM.</li> <li><strong>For Current Fixed Cycles</strong>: We will strictly utilize the dual Class 22 slots (<code>0.0.15.0.1.255</code> for Disconnect, <code>0.0.15.0.3.255</code> for Reconnect) as static, auditable daily setpoints.</li> </ol> <p dir="auto">Engineering pragmatism cannot come at the expense of field maintainability and self-contained meter truth.</p>

<p dir="auto">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!</p> <p dir="auto">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!</p> <p dir="auto">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?</p>

<blockquote> <p dir="auto">[!WARNING]<br /> <strong>Technical Redaction & Safe Harbor Notice</strong>:<br /> 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.</p> </blockquote> <p dir="auto">Following our earlier deep dive where we confirmed that our deployed polyphase smart meters lock Class 22 Single Action Schedule (<code>0.0.15.0.1.255</code>) to Attribute 3 <code>Type 1</code> (allowing only a single execution time in Attribute 4), our systems engineering team brainstormed what seems like an ingenious architectural workaround.</p> <p dir="auto">Instead of waiting 6 months and paying the meter manufacturer $50k in NRE fees for a firmware OTA upgrade to implement Class 10 (<code>Schedule</code>), why not maintain an active <strong>Rolling Task Daemon</strong> on the Head-End System (HES)?</p> <p dir="auto">Here is the concept:</p> <ol> <li>The HES writes the <em>next immediate</em> scheduled load-shedding time (e.g. <code>08:00:00</code>) into <code>0.0.15.0.1.255</code> Attribute 4:</li> </ol> <pre><code class="language-hex">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 </code></pre> <ol start="2"> <li>The meter trips at 08:00:00.</li> <li>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 <em>subsequent</em> time (e.g. <code>12:00:00</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></li> </ol> <pre><code class="language-hex">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 </code></pre> <ol start="4"> <li>Both SET requests return <code>Data-Access-Result: success</code> (<code>0x00</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></li> </ol> <pre><code class="language-hex">00 01 00 01 00 01 00 04 C5 01 C1 00 </code></pre> <p dir="auto">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?</p>

<p dir="auto">David, you nailed it. We just ran a readback on Attribute 3 (<code>control_state</code>) and Attribute 4 (<code>control_mode</code>) on our bench unit:</p> <pre><code class="language-hex">00 01 00 01 00 01 00 06 C4 01 C3 00 16 02 16 03 </code></pre> <ul> <li><code>16 02</code>: <code>control_state = 2</code> (<code>Ready_for_reconnection</code>)</li> <li><code>16 03</code>: <code>control_mode = 3</code></li> </ul> <p dir="auto">As soon as we manually pressed the optical/display button on the meter front panel, the contactor gave a loud mechanical click, and <code>output_state</code> immediately flipped to <code>03 FF</code> (<code>true</code>).</p> <p dir="auto">This explains why this meter batch passed official DLMS CTT (Conformance Test Tool) certification with flying colors—CTT only checks that the APDU returns <code>0x00</code>, completely ignoring whether physical voltage was restored downstream! For our unmanned rooftop solar installations, we cannot have technicians pushing buttons. How do we safely reconfigure <code>control_mode</code> to Mode 2 over the air?</p>

<blockquote> <p dir="auto">[!WARNING]<br /> <strong>Technical Redaction & Safe Harbor Notice</strong>:<br /> 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.</p> </blockquote> <p dir="auto">We are troubleshooting an unexpected relay issue during field commissioning of 200 polyphase commercial smart meters over IEC 62056-47 TCP/IP (port 4059). After a remote load-shedding event, our HES sends a remote reconnection command via Class 70 (<code>Disconnect Control</code>, OBIS <code>0.0.96.3.10.255</code>), invoking Method 2 (<code>remote_reconnect</code>).</p> <p dir="auto">The meter returns an immediate <code>Action-Response-Normal</code> indicating success (<code>0x00</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></p> <pre><code class="language-hex">00 01 00 01 00 01 00 05 C7 01 C1 00 00 </code></pre> <p dir="auto">However, when we immediately read back Attribute 2 (<code>output_state</code>) to verify contact closure, the meter returns <code>03 00</code> (<code>boolean: false</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></p> <pre><code class="language-hex">00 01 00 01 00 01 00 04 C4 01 C2 00 03 00 </code></pre> <p dir="auto">The downstream load remains completely de-energized. We contacted the meter manufacturer's FAE, and the classic response was <em>"It works fine on our lab bench tool."</em> Meanwhile, the Wireshark DLMS dissector confirms our Action APDU is 100% syntactically valid. Why is the meter acknowledging reconnection with success (<code>0x00</code>) while physically refusing to close the breaker?</p>

<p dir="auto">This debate highlights the classic tension between pure data modeling standards and real-world embedded deployment constraints. In the field, we cannot assume how a meter binds <code>.3.255</code> without dynamic verification.</p> <p dir="auto">The reliable engineering solution for any Head-End System is to implement <strong>Attribute 2 Binding Verification</strong> during device discovery.</p> <p dir="auto">Instead of assuming <code>.3.255</code> controls auxiliary outputs or breaker reconnects, the HES must read Attribute 2 (<code>executed_script</code>) of both Class 22 objects. Here is the verified readback from <code>0.0.15.0.3.255</code>:</p> <pre><code class="language-hex">00 01 00 01 00 01 00 13 C4 01 C1 00 02 02 09 06 00 00 0A 00 6A FF 12 00 02 </code></pre> <p dir="auto">Dissecting the script reference:</p> <ul> <li><code>09 06 00 00 0A 00 6A FF</code>: Target script LN <code>0-0:10.0.106*255</code> (Disconnect Control Script Table)</li> <li><code>12 00 02</code>: Script selector <code>2</code> (Remote Reconnect)</li> </ul> <p dir="auto">And here is the production Python snippet demonstrating how to dynamically determine whether <code>.3.255</code> is safely wired to reconnect or auxiliary output:</p> <pre><code class="language-python">from gurux_dlms.objects import GXDLMSSingleActionSchedule def resolve_reconnect_schedule_obis(client): schedule_reconnect = GXDLMSSingleActionSchedule("0.0.15.0.3.255") # Read Attribute 2: executed_script client.read(schedule_reconnect, 2) target_ln = schedule_reconnect.executedScriptLogicalName script_selector = schedule_reconnect.executedScriptSelector # Verify if vendor mapped .3.255 to Disconnect Control Script 2 (Reconnect) if target_ln.to_bytes() == b'\x00\x00\x0A\x00\x6A\xFF' and script_selector == 2: return "0.0.15.0.3.255" # Confirmed safe reconnect slot raise NotImplementedError("Meter does not provide a dedicated Disconnect Control reconnect schedule.") </code></pre> <p dir="auto">By verifying the executed script pointer at runtime, the HES guarantees safe automated load management regardless of whether the meter implements unified Class 10 or split Class 22 slots.</p>

<blockquote> <p dir="auto">[!WARNING]<br /> <strong>Technical Redaction & Safe Harbor Notice</strong>:<br /> 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.</p> </blockquote> <p dir="auto">We are currently integrating automated daily load-shedding and reconnect schedules on three-phase polyphase smart meters over IEC 62056-47 TCP/IP (port 4059). According to our requirements, the meter must trip its internal breaker (Class 70, OBIS <code>0.0.96.3.10.255</code>) at 06:20:00 and again at 06:25:00.</p> <p dir="auto">We targeted Disconnect Control Single Action Schedule (Class 22, OBIS <code>0.0.15.0.1.255</code>), writing two time entries into Attribute 4 (<code>execution_time</code>). Since the DLMS UA Blue Book defines <code>execution_time</code> as <code>array of execution_time_type</code>, our HES generated the following sanitized <code>Set-Request-Normal</code> APDU:</p> <pre><code class="language-hex">00 01 00 01 00 01 00 24 C1 01 C1 00 16 00 00 0F 00 01 FF 04 00 01 02 02 02 09 04 06 14 00 00 09 05 FF FF FF FF FF 02 02 09 04 06 19 00 00 09 05 FF FF FF FF FF </code></pre> <p dir="auto">Dissecting the payload:</p> <ul> <li><code>C1 01 C1</code>: <code>Set-Request-Normal</code>, Invoke-ID <code>1</code></li> <li><code>00 16</code>: Class ID <code>22</code> (Single Action Schedule)</li> <li><code>00 00 0F 00 01 FF</code>: OBIS <code>0.0.15.0.1.255</code></li> <li><code>04 00</code>: Attribute <code>4</code> (<code>execution_time</code>), no selective access</li> <li><code>01 02</code>: Array with length <code>2</code></li> <li>Element 1 (<code>02 02</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /> Time <code>06:20:00.00</code> (<code>09 04 06 14 00 00</code>), Date wildcard (<code>09 05 FF FF FF FF FF</code>)</li> <li>Element 2 (<code>02 02</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /> Time <code>06:25:00.00</code> (<code>09 04 06 19 00 00</code>), Date wildcard (<code>09 05 FF FF FF FF FF</code>)</li> </ul> <p dir="auto">However, the meter persistently rejects this payload with <code>Data-Access-Result: read-write-denied</code>:</p> <pre><code class="language-hex">00 01 00 01 00 01 00 04 C5 01 C1 03 </code></pre> <p dir="auto">What is baffling is that if we send a single element (<code>01 01 02 02 09 04 06 14 00 00 09 05 FF FF FF FF FF</code>), the meter returns <code>Data-Access-Result: success</code> (<code>0x00</code>). If the data type is structurally an Array, why does setting two valid execution time structures fail with <code>read-write-denied</code> rather than <code>type-unmatched</code>?</p>

<p dir="auto">Spot on by <a class="plugin-mentions-user plugin-mentions-a" href="/user/alex_turner" aria-label="Profile: alex_turner">@<bdi>alex_turner</bdi></a>! The 'Asymmetric Handshake + Symmetric Session Stream' architecture follows the exact battle-tested model of TLS 1.3.<br /> Look at the standard HLS 7 AARQ frame structure for Association LN <code>0.0.40.0.0.255</code>:</p> <pre><code class="language-hex">60 81 92 A1 09 06 07 60 85 74 05 08 01 02 A6 0A 04 08 4D 4D 4D 00 00 00 00 01 BE 7F 04 7D 01 00 00 00 06 5F 1F 04 00 00 1E 1D 00 00 07 00 48 30 46 02 21 00 A1 B2 C3 D4 E5 F6 07 18 29 3A 4B 5C 6D 7E 8F 90 12 34 56 78 9A BC DE F0 12 34 56 78 9A BC DE F0 </code></pre> <p dir="auto">From a global tender procurement perspective:</p> <ul> <li>In 2025/2026 European and Middle Eastern smart grid tenders, <strong>over 80% mandate DLMS Security Suite 1 compliance</strong>;</li> <li>In India (RDSS 250M meter rollout) and Southeast Asia, tenders require hardware SE support for ECDSA P-256 as a mandatory qualification gate per Green Book Table 43.</li> </ul> <p dir="auto">Refusing to support Suite 1 in meter firmware locks manufacturers out of high-tier global AMI markets.</p>

<p dir="auto">Per IEC 60870-5-104 Clause 7.2 and IEC 62056-53 Clause 8.2, our gateway now translates the DLMS ACTION response:</p> <pre><code class="language-hex">C7 01 C1 00 00 </code></pre> <p dir="auto">into 104 ASDU confirmation within 120ms, eliminating SCADA command timeouts while preserving metrological security.</p>