DLMS Source code Library
ANSI C Source Code Library to help you support DLMS on your metering hardware within a short time, with a field-proven and conformance tested protocol stack implementation
ANSI C Source Code Library to help you support DLMS on your metering hardware within a short time, with a field-proven and conformance tested protocol stack implementation
Kalkitech’s DLMS COSEM (IEC 62056) ANSI C Source Code Libraries are designed to help you support DLMS on your metering hardware within a very short time, with a field-proven and conformance tested protocol stack implementation. The libraries are DLMS UA attested and in ANSI C Source Code which can be cross-compiled into your target platform. The library has been tested on most of the microcontroller vendors such as Microchip, Atmel, ST Microelectronics, Texas Instruments, Renesas, NXP/Freescale, Maxim/Teridian, etc. The Source Code Libraries are available for both Client and Server DLMS-COSEM applications.
Application Contexts | Access Control (authentication) | DLMS Conformance block |
---|---|---|
|
|
|
Configuration Interface
The DLMS SCL provides a rich configuration interface. Implementers of the SCL can configure:
Multiple associations may be configured with different Application Contexts, Authentication Mechanisms and Conformance block services:
 Generic objects
Data interface:Â The Data interface to the Meter consists of a set of functions that are called on receipt of DLMS get/set or actions request from a client (or their SN equivalents). The SCL will process the request, take care of access-privilege checking and call appropriate methods in the data interface.
Security interface:Â Security interface interconnects DLMS stack with crypto library required for supporting the encryption/authentication/signature requirements as per DLMS security suite.
Integration to Meter data
The SCL as it ships, assumes a typical subset of object attributes to be static. Implementers can modify this subdivision and choose which all attributes of an object need to be dynamic (where values change dynamically and need to be updated from meter) by minor editing in certain source files.
The values for the static attributes of all supported objects are normally filled in the Configuration Interface. If the implementer chooses to modify the static/dynamic subdivision of objects, the implementer will have to modify the static initialization of the objects in the Configuration interface to suit the new arrangement.
The SCL will have a sample implementation to clarify the structure and semantics of each object and it’s supporting structures. The implementer’s role is to edit the initialization of structure variables to suit his requirement. The static information of requested objects will be retrieved by the SCL itself, and the implementer only needs to fill in the dynamic values from meter registers (using Data Interface functions).