<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[What is the biggest conceptual culture shock when transitioning from Modbus/DNP3 to DLMS/COSEM?]]></title><description><![CDATA[<blockquote>
<p dir="auto"><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f6e1.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--shield" style="height:23px;width:auto;vertical-align:middle" title="🛡" alt="🛡" />️ <strong>Technical Redaction &amp; Safe Harbor Warning</strong>:<br />
Industrial register maps and proprietary meter firmware architectures have been generalized.</p>
</blockquote>
<p dir="auto">After 5 years developing Modbus RTU firmware where reading a value was as simple as function code <code>0x03</code> on register <code>40001</code>, transitioning to DLMS / COSEM (IEC 62056-62 Clause 3.2) to read voltage <code>1.0.32.7.0.255</code> feels like a massive conceptual leap:</p>
<ul>
<li>First, SNRM/UA handshake on HDLC layer;</li>
<li>Then, AARQ association with ACSE mechanism names and conformance blocks;</li>
<li>Then, A-XDR nested structures, scalers, unit enums, and Class 3/4 register models;</li>
<li>Finally, AES-GCM encryption with Invocation Counters.</li>
</ul>
<p dir="auto">For embedded developers moving from flat industrial protocols to DLMS, what was the most surprising design philosophy difference?</p>
]]></description><link>https://dlms.sharur.org/topic/66/what-is-the-biggest-conceptual-culture-shock-when-transitioning-from-modbus-dnp3-to-dlms-cosem</link><generator>RSS for Node</generator><lastBuildDate>Fri, 16 Oct 2026 19:14:39 GMT</lastBuildDate><atom:link href="https://dlms.sharur.org/topic/66.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 23 Aug 2026 03:52:01 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to What is the biggest conceptual culture shock when transitioning from Modbus/DNP3 to DLMS/COSEM? on Sun, 23 Aug 2026 03:52:14 GMT]]></title><description><![CDATA[<p dir="auto">Looking closely at <a class="plugin-mentions-user plugin-mentions-a" href="/user/alex_turner" aria-label="Profile: alex_turner">@<bdi>alex_turner</bdi></a>'s explanation of self-describing legal contracts, the complexity makes sense now.<br />
Reading a scaled register value for <code>1.0.1.8.0.255</code>:</p>
<pre><code class="language-hex">02 02 06 00 00 03 E8 12 00 1E
</code></pre>
<p dir="auto">decodes to a structure containing integer <code>1000</code>, scaler <code>0</code>, and unit <code>30 (Wh)</code>. The overhead delivers interoperability per IEC 62056-62.</p>
]]></description><link>https://dlms.sharur.org/post/246</link><guid isPermaLink="true">https://dlms.sharur.org/post/246</guid><dc:creator><![CDATA[elena_rostova]]></dc:creator><pubDate>Sun, 23 Aug 2026 03:52:14 GMT</pubDate></item><item><title><![CDATA[Reply to What is the biggest conceptual culture shock when transitioning from Modbus/DNP3 to DLMS/COSEM? on Sun, 23 Aug 2026 03:52:05 GMT]]></title><description><![CDATA[<p dir="auto">On the other hand, the embedded footprint cost is substantial:<br />
A Modbus slave needs 200 lines of C and 512 bytes of RAM.<br />
A compliant DLMS stack with COSEM object dictionary, A-XDR dynamic decoder, HDLC segmentation buffers, and AES-GCM cryptography requires at least <strong>32KB RAM and 128KB Flash</strong> per Blue Book Section 4.4, driving the industry transition from 8-bit MCUs to ARM Cortex-M0+/M4.</p>
]]></description><link>https://dlms.sharur.org/post/245</link><guid isPermaLink="true">https://dlms.sharur.org/post/245</guid><dc:creator><![CDATA[david_miller]]></dc:creator><pubDate>Sun, 23 Aug 2026 03:52:05 GMT</pubDate></item><item><title><![CDATA[Reply to What is the biggest conceptual culture shock when transitioning from Modbus/DNP3 to DLMS/COSEM? on Sun, 23 Aug 2026 03:52:03 GMT]]></title><description><![CDATA[<p dir="auto">The fundamental divergence lies in <strong>PLC memory address mapping vs Legal Metrology Object Contracts</strong>:</p>
<ul>
<li>
<p dir="auto"><strong>Modbus (Process Control Philosophy)</strong>:<br />
A register like <code>40001</code> is purely raw bytes in PLC SRAM. The protocol does not know if it represents Celsius, Volts, or RPM. It relies entirely on external static Excel mapping sheets. There is zero security, zero timestamping, and zero non-repudiation.</p>
</li>
<li>
<p dir="auto"><strong>DLMS / COSEM (Self-Describing Legal Metrology Philosophy)</strong>:<br />
Every metering value is an object instance per IEC 62056-62. A Class 3 Register (<code>1.0.1.8.0.255</code>) contains its value, signed scaler exponent, engineering unit enum (<code>30 = Wh</code>), and access permissions. Any standard client worldwide can discover and interpret the data without a manufacturer manual.</p>
</li>
</ul>
<p dir="auto">When managing 20 million meters from 15 different vendors in a national smart grid, DLMS object standardization saves millions in integration costs.</p>
]]></description><link>https://dlms.sharur.org/post/244</link><guid isPermaLink="true">https://dlms.sharur.org/post/244</guid><dc:creator><![CDATA[alex_turner]]></dc:creator><pubDate>Sun, 23 Aug 2026 03:52:03 GMT</pubDate></item></channel></rss>