Czym do jasnej anielki jest protokół DLMS?

W dobie nieustających zmian rynku energii i rosnącego zapotrzebowania na precyzyjne dane, liczniki energii przestały być prostymi urządzeniami pomiarowymi. Stały się zaawansowanymi serwerami danych, integralną częścią złożonych systemów pomiarowych, bilingowych i zarządzania siecią.

Odpowiedzią na potrzebę interoperacyjności jest standard DLMS/COSEM – fundament inteligentnego opomiarowania (smart metering) w Europie i na świecie.

Czym jest DLMS/COSEM?

DLMS (Device Language Message Specification) to protokół komunikacyjny definiujący sposób wymiany danych.

COSEM (Companion Specification for Energy Metering) to model obiektowy opisujący, jak reprezentować dane w urządzeniach pomiarowych.

Razem tworzą kompletny standard komunikacji, znormalizowany jako IEC 62056 – międzynarodowa norma dla wymiany danych w systemach pomiarowych.

Standard jest rozwijany i utrzymywany przez DLMS User Association – organizację zrzeszającą producentów liczników, operatorów sieci i integratorów systemów. Dokumentacja składa się z czterech głównych części (tzw. Color Books):

• Green Book – architektura, specyfikacja protokołu i profile komunikacyjne (TCP/IP, HDLC, PLC)
• Blue Book – definicje klas interfejsu COSEM
• Yellow Book – specyfikacja testów zgodności i zasady certyfikacji
• White Book – słownik terminów i indeksy

Trzystopniowe podejście: od modelu do bitów

Siła specyfikacji COSEM leży w uporządkowanym, trzywarstwowym podejściu do komunikacji:

1. Modelowanie (Modelling)

Najpierw definiuje się model licznika i identyfikację danych. Złożona funkcjonalność urządzenia jest dzielona na generyczne bloki zwane klasami interfejsu (Interface Classes).

Każda klasa opisuje konkretny typ funkcjonalności – rejestr energii, zegar, profil obciążenia, parametry taryfowe.

2. Tworzenie wiadomości (Messaging)

Model jest mapowany na jednostki danych protokołu (PDU). Definiuje się operacje:

• GET – odczyt atrybutów obiektów
• SET – zapis atrybutów
• ACTION – wywołanie metod

Dodatkowo protokół wspiera Selective Access – możliwość odczytu fragmentu danych, np. zakresu dat z profilu obciążenia, bez konieczności pobierania całości.

3. Transport (Transporting)

Bity i bajty są przesyłane przez kanał komunikacyjny przy użyciu warstw niższych protokołu – niezależnie od medium fizycznego.

Kluczowa zaleta: Ta separacja modelu danych od warstwy transportowej pozwala używać tego samego języka niezależnie od tego, czy komunikujemy się przez:

• Linię telefoniczną (PSTN)
• Sieć GSM/GPRS/LTE
• PLC (Power Line Communication)
• Nowoczesne sieci IP/Ethernet
• LoRaWAN, NB-IoT

Licznik jako serwer: obiektowy model danych

W środowisku DLMS/COSEM komunikacja opiera się na paradygmacie klient-serwer:

• Serwer – urządzenie pomiarowe (licznik), które udostępnia swoje zasoby
• Klient – aplikacja zewnętrzna (koncentrator danych, system HES, aplikacja inkasencka)

Protokół wspiera dwa modele komunikacji:

• Request-response – klient inicjuje żądanie, serwer odpowiada
• Push (DataNotification) – serwer samodzielnie wysyła dane do klienta (np. alarmy, przekroczenia progów)

Funkcjonalność licznika jest modelowana za pomocą obiektów interfejsu. Każdy obiekt jest instancją określonej klasy i posiada:

• Atrybuty – dane (wartości, parametry konfiguracyjne)
• Metody – akcje do wykonania (reset, synchronizacja)

Najważniejsze klasy interfejsu

Uwaga: W nowoczesnych licznikach AMI w Polsce standardem jest adresowanie Logical Name (LN), stąd klasa Association LN (15) jest powszechnie stosowana. Klasa Profile generic (7) ma kluczowe znaczenie dla CSIRE – to w niej przechowywane są wymagane profile 15-minutowe.

Przykład: obiekt rejestru energii

Klasa:        Register (class_id = 3)
OBIS:         1.0.1.8.0.255
Atrybuty:
  - logical_name: OBIS code
  - value: 1234567 (wartość surowa jako liczba całkowita)
  - scaler_unit: {scaler: -2, unit: 30} → kWh × 10^(-2)
Metody:
  - reset() → zerowanie rejestru

Uwaga o skalowaniu: Wartość scaler: -2 oznacza mnożnik 10⁻² (dzielenie przez 100). DLMS przesyła wartości jako liczby całkowite dla efektywności – rzeczywista wartość to 1234567 × 10⁻² = 12345,67 kWh. Jest to standardowy sposób reprezentacji liczb zmiennoprzecinkowych w protokole.

OBIS: kod, który mówi wszystko

OBIS (Object Identification System) to system unikalnej identyfikacji danych, niezależny od producenta urządzenia.

Każdy kod OBIS składa się z sześciu grup wartości (A-F):

A.B.C.D.E.F
│ │ │ │ │ └── F: Okres rozliczeniowy (dane historyczne)
│ │ │ │ └──── E: Taryfa / strefa czasowa
│ │ │ └────── D: Typ przetwarzania (wartość, max, średnia, energia)
│ │ └──────── C: Wielkość fizyczna (prąd, napięcie, moc)
│ └────────── B: Kanał / wejście pomiarowe
└──────────── A: Medium (1=prąd, 7=gaz, 8=woda, 4=ciepło)

Przykłady kodów OBIS dla energii elektrycznej

Dekodowanie kodu OBIS: 1.0.1.8.0.255

A = 1   → Energia elektryczna
B = 0   → Kanał ogólny (suma)
C = 1   → Moc czynna pobrana (import)
D = 8   → Energia całkowita (czas × moc)
E = 0   → Suma wszystkich taryf
F = 255 → Wartość bieżąca (nie historyczna)

Wynik: "Całkowita energia czynna pobrana, suma taryf, wartość bieżąca"

Uwaga o parametrze F: Wartość F = 255 oznacza aktualną wartość (current value). Dla danych historycznych (np. zamknięcia okresów rozliczeniowych odczytywane z profilu) parametr F przyjmuje wartości od 0 do 126, gdzie każda wartość odpowiada konkretnemu okresowi historycznemu.

Dzięki OBIS każdy system zgodny z DLMS może jednoznacznie zinterpretować dane z dowolnego licznika – niezależnie od producenta.

Bezpieczeństwo: od hasła do kryptografii

Współczesna energetyka wymaga nie tylko precyzji, ale i bezpieczeństwa. Liczniki inteligentne to potencjalne wektory ataku na infrastrukturę krytyczną.

Kontrola dostępu

Protokół DLMS/COSEM przewiduje mechanizmy kontroli dostępu poprzez obiekty asocjacji (Association LN/SN), które definiują:

• Kto ma dostęp do licznika
• Do jakich obiektów
• Z jakimi uprawnieniami (odczyt, zapis, wykonanie)

Poziomy uwierzytelniania

Uwaga: Poziomy 2 i 3 (MD5, SHA-1) są obecnie uważane za przestarzałe i nie powinny być stosowane w nowych wdrożeniach.

HLS: jak działa silne uwierzytelnianie?

Proces HLS to 4-etapowe wzajemne uwierzytelnienie:

1. Klient → Serwer: “Chcę się połączyć” + losowe wyzwanie CtoS
2. Serwer → Klient: Losowe wyzwanie StoC
3. Klient → Serwer: Odpowiedź f(StoC, klucz)
4. Serwer → Klient: Odpowiedź f(CtoS, klucz) + potwierdzenie

Obie strony weryfikują się nawzajem. Atakujący nie może:

• Podsłuchać hasła (nie jest przesyłane)
• Powtórzyć poprzedniej sesji (wyzwania są losowe)
• Podszyć się pod którąkolwiek stronę

Szyfrowanie komunikacji

Dla najwyższego poziomu bezpieczeństwa DLMS/COSEM wspiera:

• AES-128-GCM / AES-256-GCM – szyfrowanie z uwierzytelnieniem (authenticated encryption)
• AES-128-CBC – szyfrowanie blokowe
• GMAC – uwierzytelnianie bez szyfrowania (dla danych niepoufnych)

AES-GCM (Galois/Counter Mode) jest obecnie standardem wymaganym przez polskich OSD w specyfikacjach przetargowych AMI. Tryb GCM jest kluczowy, ponieważ zapewnia jednocześnie poufność i autentyczność danych w jednej operacji kryptograficznej.

Klucze kryptograficzne są zarządzane przez dedykowane obiekty Security setup (klasa 64). Polska specyfikacja AMI wymaga, aby licznik umożliwiał zdalną wymianę kluczy (Key Transfer) – DLMS obsługuje to przez dedykowane metody w klasie Security setup, co pozwala na rotację kluczy bez fizycznej wizyty u odbiorcy.

DLMS/COSEM w sieciach IP

Standard doskonale wpisuje się w erę Internetu Rzeczy. Dzięki profilom komunikacyjnym opartym na TCP-UDP/IP, liczniki mogą funkcjonować jako standardowe węzły sieciowe.

Warstwa “wrapper”

Komunikaty COSEM są “opakowane” w nagłówek IP wrapper:

┌─────────────────────────────────────────┐
│ TCP/UDP Header                          │
├─────────────────────────────────────────┤
│ DLMS/COSEM Wrapper Header (8 bajtów)    │
│ - Version (2B)                          │
│ - Source wPort (2B)                     │
│ - Destination wPort (2B)                │
│ - Length (2B)                           │
├─────────────────────────────────────────┤
│ COSEM APDU (dane)                       │
└─────────────────────────────────────────┘

Umożliwia to:

• Zdalny odczyt przez Internet
• Komunikację przez sieci GPRS/LTE
• Integrację z systemami IT przez standardowe protokoły
• Tunelowanie przez VPN

Porty standardowe

Uwaga o sieciach komórkowych: W sieciach LTE/NB-IoT często stosuje się dodatkowe optymalizacje (np. kompresję nagłówków), aby ograniczyć narzut transmisji na łączach o ograniczonej przepustowości. Standardowy port 4059 pozostaje jednak punktem wyjścia dla większości wdrożeń.

DLMS/COSEM vs inne protokoły

Modbus – prostszy, powszechny w automatyce, ale brak standardowej semantyki danych. W Modbusie rejestr 40001 może oznaczać temperaturę, napięcie lub cokolwiek innego – bez dokumentacji producenta interpretacja jest niemożliwa. W DLMS kod OBIS 1.0.32.7.0.255 to zawsze napięcie fazy L1, niezależnie od producenta.

IEC 61850 – kompleksowy dla automatyki stacji, ale zbyt “ciężki” dla masowego opomiarowania. Narzut XML/MMS jest zbyt duży dla milionów liczników komunikujących się przez łącza GSM o ograniczonej przepustowości.

DLMS/COSEM – optymalny dla smart metering: bogaty model danych, silne bezpieczeństwo, efektywny transport.

Zastosowania w Polsce

CSIRE i AMI

Centralny System Informacji Rynku Energii (CSIRE) to kluczowy element transformacji polskiego rynku energii. Choć system formalnie rozpoczął działanie, faktyczny start operacyjny zaplanowano na 19 października 2026 roku. Od tej daty OSD będą zobowiązani do przekazywania danych pomiarowych do centralnej bazy.

DLMS/COSEM jest domyślnym protokołem komunikacji z licznikami inteligentnymi w Polsce, stanowiąc fundament systemów AMI (Advanced Metering Infrastructure).

Wymagania regulacyjne

Zgodnie z rozporządzeniem “licznikowym”:

• Liczniki muszą wspierać DLMS/COSEM (IEC 62056)
• Wymagana jest autoryzacja oraz zabezpieczenie programowe przed odczytem i zmianami bez uprawnień
• Transmisja danych w systemie zdalnego odczytu musi być zabezpieczona
• Profile obciążenia z rozdzielczością 15 min

Praktyczne wyzwania wdrożeniowe

• Różnice implementacyjne – mimo standardu, producenci różnie interpretują niektóre elementy
• Zarządzanie kluczami – dystrybucja i rotacja kluczy dla milionów urządzeń
• Firmware updates – bezpieczna aktualizacja przez obiekt Image transfer
• Interoperacyjność – testowanie zgodności (DLMS Conformance Testing)
• Skalowalność push – obsługa masowych powiadomień DataNotification

Narzędzia dla programistów

Biblioteki open source

• Gurux DLMS (C#, Java, Python, C++) – najpopularniejsza implementacja
• jDLMS (Java) – OpenMUC project
• dlms-cosem – alternatywna implementacja w Pythonie

Przykład: odczyt energii przez Gurux (Python)

from gurux_dlms import GXDLMSClient
from gurux_dlms.enums import Authentication
from gurux_dlms.objects import GXDLMSRegister
from gurux_net import GXNet
from gurux_net.enums import NetworkType

# Inicjalizacja klienta
client = GXDLMSClient(useLogicalNameReferencing=True)
client.authentication = Authentication.HIGH_GMAC
client.ciphering.security = Security.AUTHENTICATION_ENCRYPTION
client.ciphering.systemTitle = bytes([0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48])
# Klucze w rzeczywistej aplikacji powinny być bezpiecznie przechowywane
client.ciphering.authenticationKey = bytes.fromhex("000102030405060708090A0B0C0D0E0F")
client.ciphering.blockCipherKey = bytes.fromhex("000102030405060708090A0B0C0D0E0F")

# Połączenie (TCP/IP)
media = GXNet(NetworkType.TCP, "192.168.1.100", 4059)
reader = GXDLMSReader(client, media)

try:
    reader.initializeConnection()
    
    # Odczyt energii czynnej pobranej
    register = GXDLMSRegister("1.0.1.8.0.255")
    reader.read(register, 2)  # Atrybut 2 = value
    
    print(f"Energia: {register.value} {register.unitAsString}")
    # Energia: 12345.67 kWh
    
finally:
    reader.close()

Podsumowanie

DLMS/COSEM to nie tylko protokół – to kompleksowy język komunikacji dla sektora multi-utility:

• ✅ Uniwersalność – prąd, gaz, ciepło, woda
• ✅ Interoperacyjność – niezależność od producenta dzięki OBIS
• ✅ Elastyczność – separacja modelu od transportu
• ✅ Bezpieczeństwo – HLS + AES dla infrastruktury krytycznej
• ✅ Skalowalność – od pojedynczego odczytu do milionów liczników
• ✅ Dwukierunkowość – request-response i push notifications

Dla operatorów sieci dystrybucyjnych w Polsce, znajomość DLMS/COSEM staje się kompetencją kluczową – zarówno przy wyborze dostawców liczników, jak i przy integracji z CSIRE.

Przydatne linki

• DLMS User Association – oficjalna dokumentacja
• IEC 62056 – normy międzynarodowe
• Gurux DLMS – biblioteki open source