Definition
DLMS/COSEM (Device Language Message Specification / Companion Specification for Energy Metering) is a smart metering and energy management protocol developed by the International Electrotechnical Commission (IEC), corresponding to the IEC 62056 series of standards. DLMS defines the application layer communication protocol (request-response, push, etc.), COSEM defines the data model (OBIS object identification, interface classes, etc.), and supports remote meter reading, parameter configuration, remote control, event reporting, and other functions for smart meters, water meters, gas meters, heat meters, and other devices.
DLMS/COSEM supports various physical layers and data link layers: PLC, RS-485, GPRS, NB-IoT, etc. In cellular communication scenarios, concentrators or collectors communicate with the cloud platform via 4G/NB-IoT IoT SIM cards, transmitting DLMS/COSEM data transparently or parsing it before uploading.
Technical Features
DLMS/COSEM adopts an object-oriented model and supports various interface classes (clock, register, load profile, event log, etc.). It has a security authentication mechanism (HLS, AES-GCM, etc.) to ensure data security. Together with standards such as IEC 61850 and IEC 61968, it can support smart grid and energy Internet applications.
Use Cases
DLMS/COSEM is widely used in smart grids, AMI, smart metering, multi-meter reading, and other scenarios. Smart meters communicate with data collectors or concentrators through DLMS/COSEM, and the data is uploaded to cloud platforms via IoT SIM cards or LoRa, supporting applications such as time-of-use billing, load forecasting, demand-side response, and loss analysis. SimtoLink provides AMI collection devices with stable network connectivity and dedicated APN to ensure reliable transmission of metering data.
What the head-end reads when an object is cut short
When DLMS/COSEM is carried over an IoT SIM, what usually runs on the card is not the meter protocol itself. A concentrator or an in-meter module hands application data that is already encoded to the cellular bearer. The head-end has to see a complete object. Registers, profile blocks, the clock, and the event log each have their own class and OBIS identifier. If the bearer cuts a long message in the middle, the head-end does not get “energy that is slightly off.” It may get half an object that cannot be parsed, or it may take the next block as the end of the previous one. The security suite has to arrive whole as well. If authentication and encryption exist only on the local bus and the data leaves cellular as clear pass-through, the site can still be read and the security property has already changed.
The meter, the concentrator, and the head-end need the same security suite, the same clock, and an acceptable block size. The block size has to be smaller than the message length that is actually stable on the cellular path, not only what a wired serial port allowed in the lab. A profile read should be able to continue from a missing block, not resend the whole day from the start and fill the channel. Keep the event log apart from the periodic profile. A power loss or an opened cover should not wait for the profile window. Bind the SIM to the concentrator and the district. When equipment is replaced, migrate or revoke the security material under the procedure. Do not leave the old key in a module that has been removed. If public pass-through must be used, still limit the peer address, and confirm the head-end can detect truncation and replay rather than writing any byte stream into the billing store.
A common error is to treat “the concentrator is online” as proof that objects can be read. Online only means the bearer. Reading the clock, reading a profile, and executing a control are different requests, and only the first may succeed. Another error is a block sequence that returns to zero after reconnect. The head-end overwrites the old last block with the new first block, the daily freeze loses a slice, and the read still shows success. Manufacturers that disagree on the unit and scaler of the same OBIS leave values online and off by a factor of one thousand, which wrecks the loss calculation. A firmware upgrade that changes the security suite halfway, while the old head-end still uses the old key, looks like a mass of authentication failures, and operations goes to check the base station. Acceptance should read the clock, one profile block, and one event, then drop the session in the middle of transfer, and confirm the head-end does not store half an object. How the concentrator organizes these objects is described under AMI head-end and concentrator return. How events are compressed for reporting is described under smart meter events.
Before the head-end stores an object, check that it is complete, that block sequence numbers are continuous, and that the security suite matches the archive. Put an incomplete response in a reject area. Do not let it enter billing or the loss calculation. The reject reason should show truncation, authentication failure, or clock skew. Those three go to different people. Retest block size on the cellular path in the field. A length that passes a lab serial port may not pass the path from concentrator to head-end. During key rotation, keep a window that can still decrypt old messages until catch-up ends. Otherwise profiles from the outage all fail authentication. Write each manufacturer’s scaler into the archive and check it on the first read. Correct a meter that is off by an order of magnitude before it enters the loss calculation. Authorize control commands apart from profile reads. Being able to read does not mean remote connect and disconnect is allowed. In pass-through mode, limit the peer as well, and record the raw length of each rejected segment, so truncation on the radio can be told apart from a concentrator packing error.
Check units and scalers on the first read and write the result into the archive. A later scaler change is a parameter change, not a sudden jump in energy. Count read failures apart from reads that return an empty object. An empty object may mean the meter does not support that interface class, and retrying only fills the cellular link. After a control command, read the status back. A command that was sent is not a command that was executed. If the read-back fails, the command is in an unknown state. A person confirms the meter’s actual position before deciding whether to send it again. A command in an unknown state is not counted as a successful read, and it is not resent automatically, so the same meter is not connected and disconnected in a run.