DLMS Conformance Block Negotiation: Conformance Bits Demystified

[sarah_jenkins]

Understanding the 24-bit Conformance Block in AARQ

During Association establishment, the client proposes a set of service capabilities in the Proposed-Conformance bit-string. The meter responds with Negotiated-Conformance, which is the bitwise AND of supported features.

Conformance Bit Allocations (DLMS Green Book 10th Ed.)

Bit 0:  reserved
Bit 1:  reserved
Bit 2:  read (obsolete)
Bit 3:  write (obsolete)
Bit 4:  unconfirmed-write
Bit 5:  multipurpose-service
Bit 6:  read-access
Bit 7:  write-access
Bit 8:  variable-access-specification
Bit 9:  information-report
Bit 10: reserved
Bit 11: reserved
Bit 12: get (LN)
Bit 13: set (LN)
Bit 14: selective-access
Bit 15: event-notification
Bit 16: action
Bit 17: reserved
Bit 18: block-transfer-with-get
Bit 19: block-transfer-with-set
Bit 20: block-transfer-with-action
Bit 21: multiple-references
Bit 22: information-report-with-data
Bit 23: access-data

Standard 24-bit Proposed Conformance for Logical Name (LN) Referencing

00 7E 1F in hex:

• Enables: GET, SET, ACTION, SELECTIVE-ACCESS, BLOCK-TRANSFER-WITH-GET, BLOCK-TRANSFER-WITH-SET, BLOCK-TRANSFER-WITH-ACTION.

If your client forgets to set bit 14 (selective-access), any subsequent attempt to read profile buffers by date range will be rejected with Service-Error: service-not-supported!

[david_miller]

Excellent summary Sarah! A common mistake when writing custom client drivers is hardcoding Short Name (SN) conformance bits (Bit 6: read, Bit 7: write) while attempting to connect to a Logical Name (LN) referencing association. This causes immediate AARQ rejection (result: rejected-permanent, result-source-diagnostic: application-context-name-not-supported).