· Web viewna świecie istnieje kilka ośrodków laboratoryjnych certyfikacji urządzeń na...

Standard komunikacji pomiędzy Aplikacją AMI i Infrastrukturą Licznikowąopracowano dla ENERGA-Operator SA

Wersja: 0.03

Data: 2011-07-31

Spis treści1 Słownik pojęć i skrótów...................................................................................................................52 Wstęp................................................................................................................................................83 Koncepcja standardu komunikacji w DSO.......................................................................................9

3.1 Założenia dla standardu komunikacji.......................................................................................9

3.1.1 Założenia ogólne...............................................................................................................93.1.2 Założenia techniczne........................................................................................................9

3.2 Ogólna koncepcja standardu komunikacji..............................................................................10

3.2.1 Obszar komunikacji SAK – koncentratory.....................................................................113.2.2 Obszar komunikacji koncentratory – liczniki.................................................................113.2.3 Obszar komunikacji SAK – liczniki...............................................................................123.2.4 Priorytetyzacja ruchu......................................................................................................133.2.5 Podpisy cyfrowe.............................................................................................................173.2.6 Koncepcja transportu......................................................................................................17

4 Licznikowe Przypadki Użycia........................................................................................................20

4.1 Kategorie, Identyfikatory i Statusy Licznikowych Przypadków Użycia................................204.2 Lista Licznikowych Przypadków Użycia...............................................................................214.3 Analiza Licznikowych Przypadków Użycia...........................................................................21

4.3.1 Kategoria Instalacja........................................................................................................234.3.2 Kategoria Konfiguracja..................................................................................................304.3.3 Kategoria Odczyty..........................................................................................................344.3.4 Kategoria Sterowanie......................................................................................................384.3.5 Kategoria Zgłoszenie......................................................................................................43

5 Protokół komunikacyjny DCSML..................................................................................................45

5.1 Opis Komunikatów.................................................................................................................455.2 Gramatyka Protokołu..............................................................................................................45

5.2.1 Podstawowe definicje struktur danych SML..................................................................465.2.2 Podstawowe struktury danych DCSML.........................................................................535.2.3 Funkcje DCSML – związane z obsługą koncentratora...................................................555.2.4 Funkcje DCSML – związane z obsługą licznika............................................................57

6 Przykłady zapytań i odpowiedzi w DCSML (w postaci APDU i źródłowej)................................61

6.1 Definicja ASN.1.....................................................................................................................616.2 Przykłady................................................................................................................................63

6.2.1 Przykład 1-1-1................................................................................................................636.2.2 Przykład 1-1-4................................................................................................................656.2.3 Przykład 1-5-1................................................................................................................676.2.4 Przykład 1-5-4................................................................................................................696.2.5 Przykład 5-1-1................................................................................................................716.2.6 Przykład 5-1-4................................................................................................................746.2.7 Przykład 5-5-1................................................................................................................796.2.8 Przykład 5-5-4................................................................................................................83

Tytuł dokumentu: Standard komunikacji pomiędzy Aplikacją AMI i Infrastrukturą Licznikową 2 z 93

Spis tabelTabela 1. Słownik pojęć i skrótów...........................................................................................................5Tabela 2. Kategorie Licznikowych Przypadków Użycia.......................................................................20Tabela 3. Licznikowe Przypadki Użycia o statusie „A”.........................................................................21Tabela 4. Lista komunikatów DCSML...................................................................................................45Tabela 5. Znaczenie bitów pierwszego bajtu w polu TL-Field..............................................................47Tabela 6. Znaczenie bitów kolejnych bajtów w polu TL-Field..............................................................48

Spis rysunkówRysunek 1. Obszary komunikacji w systemie AMI...............................................................................10Rysunek 2. Obszary komunikacji w systemie AMI – warstwy protokołu.............................................11Rysunek 3: Diagram sekwencji – pojedyncza sesja komunikacyjna PULL...........................................14Rysunek 4: Diagram sekwencji –dwie sesje komunikacyjne PULL + PULL........................................14Rysunek 5: Diagram sekwencji – dwie sesje komunikacyjne PULL + PUSH......................................15Rysunek 6: Diagram sekwencji – pojedyncza sesja komunikacyjna PUSH..........................................15Rysunek 7. LPU w Kategorii Instalacja.................................................................................................23Rysunek 8. Diagram sekwencji dla LPU01 – sytuacja prawidłowa.......................................................24Rysunek 10. Diagram sekwencji dla LPU02..........................................................................................25Rysunek 11. Diagram sekwencji dla LPU03..........................................................................................25Rysunek 12. Diagram sekwencji dla LPU04 – tryb serwisowania.........................................................26Rysunek 13. Diagram sekwencji dla LPU04 – bez trybu serwisowania................................................27Rysunek 14. Diagram sekwencji dla LPU05..........................................................................................28Rysunek 15. Diagram sekwencji dla LPU06..........................................................................................29Rysunek 16. LPU w Kategorii Konfiguracja..........................................................................................30Rysunek 17. Diagram sekwencji dla LPU07..........................................................................................31Rysunek 18. Diagram sekwencji dla LPU08..........................................................................................32Rysunek 19. Diagram sekwencji dla LPU09..........................................................................................33Rysunek 20. Diagram sekwencji dla LPU20..........................................................................................33Rysunek 21. LPU w Kategorii Odczyty.................................................................................................34Rysunek 22. Diagram sekwencji dla LPU10 – tryb „push”...................................................................35Rysunek 23. Diagram sekwencji dla LPU10 – tryb ”pull”.....................................................................35Rysunek 24. Diagram sekwencji dla LPU011........................................................................................36Rysunek 25. Diagram sekwencji dla LPU13 – tryb „push”...................................................................37Rysunek 26. Diagram sekwencji dla LPU13 – tryb ”pull”.....................................................................38Rysunek 27. LPU w Kategorii Sterowanie.............................................................................................39Rysunek 28. Diagram sekwencji dla LPU012 – odczyt w trybie „push”...............................................39Rysunek 29. Diagram sekwencji dla LPU012 – odczyt w trybie „pull”................................................40Rysunek 30. Diagram sekwencji dla LPU012 – zmiana danych w trybie „push”.................................40Rysunek 31. Diagram sekwencji dla LPU012 – odczyt w trybie „pull”................................................41Rysunek 32: Diagram sekwencji dla LPU016........................................................................................42Rysunek 33. Diagram sekwencji dla LPU17..........................................................................................43Rysunek 34. LPU w Kategorii Zgłoszenie.............................................................................................43Rysunek 35. Diagram sekwencji dla LPU18..........................................................................................44Rysunek 36. Diagram sekwencji dla LPU19..........................................................................................44Rysunek 37: Definicja gramatyki w notacji ASN.1...............................................................................63


Rysunek 38: Zapytanie 1-1-1 w postaci APDU.....................................................................................63Rysunek 39: Zapytanie 1-1-1 w notacji ASN.1......................................................................................64Rysunek 40: Odpowiedź 1-1-1 w postaci APDU...................................................................................64Rysunek 41: Odpowiedź 1-1-1 w notacji ASN.1...................................................................................65Rysunek 42: Zapytanie 1-1-4 w postaci APDU.....................................................................................65Rysunek 43: Zapytanie 1-1-4 w notacji ASN.1......................................................................................65Rysunek 44: Odpowiedź 1-1-4 w postaci APDU...................................................................................66Rysunek 45: Odpowiedź 1-1-4 w notacji ASN.1...................................................................................67Rysunek 46: Zapytanie 1-5-1 w postaci APDU.....................................................................................67Rysunek 47: Zapytanie 1-5-1 w notacji ASN.1......................................................................................67Rysunek 48: Odpowiedź 1-5-1 w postaci APDU...................................................................................68Rysunek 49: Odpowiedź 1-5-1 w notacji ASN.1...................................................................................68Rysunek 50: Zapytanie 1-5-4 w postaci APDU.....................................................................................69Rysunek 51: Zapytanie 1-5-4 w notacji ASN.1......................................................................................69Rysunek 52: Odpowiedź 1-5-4 w postaci APDU...................................................................................70Rysunek 53: Odpowiedź 1-5-4 w notacji ASN.1...................................................................................71Rysunek 54: Zapytanie 5-1-1 w postaci APDU.....................................................................................72Rysunek 55: Zapytanie 5-1-1 w notacji ASN.1.....................................................................................72Rysunek 56: Odpowiedź 5-1-1 w postaci APDU...................................................................................73Rysunek 57: Odpowiedź 5-1-1 w notacji ASN.1...................................................................................74Rysunek 58: Zapytanie 5-1-4 w postaci APDU.....................................................................................74Rysunek 59: Zapytanie 5-1-4 w notacji ASN.1.....................................................................................75Rysunek 60: Odpowiedź 5-1-4 w postaci APDU...................................................................................75Rysunek 61: Odpowiedź 5-1-4 w notacji ASN.1...................................................................................79Rysunek 62: Zapytanie 5-5-1 w postaci APDU.....................................................................................79Rysunek 63: Zapytanie 5-5-1 w notacji ASN.1......................................................................................80Rysunek 64: Odpowiedź 5-5-1 w postaci APDU...................................................................................81Rysunek 65: Odpowiedź 5-5-1 w notacji ASN.1...................................................................................83Rysunek 66: Zapytanie 5-5-4 w postaci APDU.....................................................................................83Rysunek 67: Zapytanie 5-5-4 w notacji ASN.1......................................................................................84Rysunek 68: Odpowiedź 5-5-4 w postaci APDU...................................................................................84Rysunek 69: Odpowiedź 5-5-4 w notacji ASN.1...................................................................................90


1 Słownik pojęć i skrótówTabela 1. Słownik pojęć i skrótów

Termin Wyjaśnienie

AES Advanced Encryption Standard – symetryczny szyfr blokowy przyjęty przez National Institute of Standard and Technology.

AES-GCM 128 Advanced Encryption Standard - Galois/Counter Mode - GCM jest trybem o podwójnej funkcjonalności, szyfrująco-uwierzytelniającym. AES wykonuje 10 (klucz 128 bitów) rund szyfrujących substytucja-permutacja. Składają się one z substytucji wstępnej, permutacji macierzowej (mieszanie wierszy, mieszanie kolumn) i modyfikacji za pomocą 128-bitowego klucza.

AMI Advanced Metering Infrastructure – Zaawansowana Struktura Pomiarowa.Kompleksowy system liczników, systemów komunikacyjnych i aplikacji do gromadzenia, przechowywania i analizowania danych pomiarowych oraz zarządzania infrastrukturą pomiarową.

APDU Application layer Protocol Data Unit - jednostka danych protokołu w warstwie aplikacji

Aplikacja Scentralizowana aplikacja AMI – odpowiada za gromadzenie i zarządzanie danymi pomiarowymi

ASN.1 Abstract Syntax Notation One - standard służący do opisu struktur przeznaczonych do reprezentacji, kodowania, transmisji i dekodowania danych

BER Basic Encoding Rules – metoda kodowania danych opisywanych specyfikacją ASN.1

CA Certification Authority – zaufana instytucja, urząd certyfikacjiCBP Centralna Baza PomiarowaCAZ Centralna Aplikacja Zarządzająca.Certyfikat Klucz publiczny i informacje o tożsamości podmiotu podpisane

cyfrowo przez urząd certyfikacjiCOSEM Companion Specification for Energy Metering – zbiór specyfikacji

opracowanych przez DLMS UA definiujący model informatyczny obiektów m.in. liczników energii elektrycznej

DCSML Data Concentrator Smart Message Language – protokół komunikacyjny stanowiący rozszerzenie standardowej specyfikacji SML o dodatkowe funkcjonalności (np. multicast, broadcast). Powstał na potrzeby wdrożenia Systemu AMI w DSO

DLMS Device Language Message Specification – zorientowany połączeniowo protokół warstwy aplikacji przeznaczony m.in. do dwukierunkowej wymiany danych z licznikami energii elektrycznej

DSO Distribution System Operator – Operator Sieci DystrybucyjnejGSM Global System for Mobile Communications (pierwotnie Groupe


Termin Wyjaśnienie

Spécial Mobile) – standard telefonii komórkowejGPRS General Packet Radio Service – sposób pakietowego przesyłania

danych w sieciach GSMGZIP Program służący do kompresji plików, oparty o algorytm Deflate,

stanowiący kombinację algorytmów LZ77 oraz algorytmu kodowania Huffman’a

HAN Home Area Network – – Sieć Domowa – obejmująca urządzenia w ramach infrastruktury Inteligentnego Budynku wyposażone w możliwość sterowania z zewnątrz oraz udostępniania danych (ogrzewanie, klimatyzacja, sprzęt AGD i RTV). Dodatkowo w skład HAN mogą wejść komputery osobiste i terminale domowe służące do monitorowania zużycia energii i zarządzania urządzeniami i licznikami.

Infrastruktura Licznikowa/ Infrastruktura Pomiarowa

Infrastruktura techniczna, w tym sprzęt oraz oprogramowanie, której celem jest zapewnienie odpowiedniej komunikacji pomiędzy odbiorcami energii a DSO, w tym przekazywania informacji nt. zużycia energii. Infrastruktura Licznikowa łączy się z Systemem Aplikacyjnym za pośrednictwem Infrastruktury Pośredniczącej. W skład Infrastruktury Licznikowej wchodzić będą liczniki energii oraz koncentratory i inne powiązane z nimi urządzenia, w tym urządzenia HAN i liczniki innych mediów.

KDL Koncentrator Danych Licznikowych.KDLP Koncentrator Danych Licznikowych – Programowy.LE Licznik Energii Elektrycznej.LPU Licznikowy Przypadek Użycia.nN Niskie napięcie.OBIS Object Identification System system kodowania obiektów modelu

COSEM.OSI Open System Interconnection. – zdefiniowany przez organizacje ISO

oraz ITU-T standard opisujący strukturę komunikacji sieciowej.PKI Public Key Infrastructure – struktura zaufania oparta na

potwierdzaniu autentyczności za pomocą certyfikatów wystawianych przez hierarchię urzędów certyfikacji.

PLC Power Line Communication/Carrier – technika komunikacyjna, umożliwiająca przesyłanie informacji na odległość za pomocą przewodów sieci elektroenergetycznych.

PRIME PoweRline Intelligent Metering Evolution – otwarta specyfikacja definiująca łączność w najniższych warstwach systemu komunikacyjnego po PLC od urządzeń końcowych (liczników) do koncentratora danych umieszczonego w stacji transformatorowej SN/nn.

SAK System Akwizycyjny.SML Smart Message Language – protokół warstwy aplikacji, opracowany

przez grupę projektową MeKo, przeznaczony m.in. do


Termin Wyjaśnienie

dwukierunkowej wymiany danych z licznikami energii elektrycznej.W skład grupy projektowej MeKo wchodzą: Dr. Neuhaus Telekommunikation GmbH, E.ON Mitte AG, E.ON Netz GmbH, Emsycon GmbH, EnBW Vertriebs und Servicegesellschaft mbH, Landis+Gyr GmbH, RWE Rhein-Ruhr Netzservice GmbH.

SN Średnie napięcie.SSH Secure Shell (bezpieczna powłoka) – standard protokołów

komunikacyjnych wykorzystywanych w sieciach komputerowych TCP/IP, w architekturze klient - serwer. Służy do łączenia się ze zdalnym komputerem, zapewnia szyfrowanie oraz umożliwia autentykację użytkownika wieloma metodami.

S-FSK Spread Frequency Shift Keying – jedna z technik transmisji danych przez sieć PLC.

TCP/IP Transmission Control Protocol/Internet Protocol – zestaw protokołów warstwy transportowej (TCP) oraz sieciowej (IP), zapewniający ujednolicony sposób przesyłania danych w różnych typach sieci.

TLS/SSL TLS (ang. Transport Layer Security) – przyjęte jako standard w Internecie rozwinięcie protokołu SSL (ang. Secure Socket Layer), ma na celu zapewnienie poufności i integralności transmisji danych oraz zapewnienie uwierzytelnienia, opiera się na szyfrach asymetrycznych oraz certyfikatach standardu X.509.

WS-RT Web Services Resource Transfer – protokół bazujący na popularnej technologii WebServices stosowanej w przypadku wymiany danych pomiędzy aplikacjami pracującymi w sieci TCP/IP, stworzony w ramach standardu DSMR.

xDLMS Extended DLMS – rozszerzenie protokołu DLMS do standardu DLMS/COSEM określonego normą IEC 62056-53.

XML Extensible Markup Language – jest językiem znacznikowym służącym do opisu danych. Jest on sposobem na przedstawienie hierarchicznej struktury węzłów oraz ich atrybutów za pomocą "płaskiego" pliku tekstowego o ściśle określonej strukturze.


2 WstępNiniejszy dokument jest wyciągiem z dokumentu „Standard komunikacji Aplikacji z Infrastrukturą Licznikową” (wersja 2.00).

Dokument zawiera koncepcję i podstawowe założenia dla standardu komunikacji z propozycją autorskiego protokołu komunikacyjnego DCSML, utworzonego na potrzeby Energa-Operator SA. Opracowany standard uwzględnia potrzeby oraz charakterystykę Systemu AMI.

W ramach dokumentu przedstawiono:

przypadki użycia dla komunikacji pomiędzy Aplikacją i Infrastrukturą Licznikową,

opis komunikatów,

gramatykę protokołu, przykłady zapytań i odpowiedzi w DCSML (w postaci APDU i źródłowej).

Opracowanie standardu komunikacji uwzględnia wytyczne zawarte w dokumencie:

[1] Stanowisko Prezesa URE w sprawie niezbędnych wymagań wobec wdrażanych przez OSD E inteligentnych systemów pomiarowo-rozliczeniowych z uwzględnieniem funkcji celu oraz proponowanych mechanizmów wsparcia przy postulowanym modelu rynku. URE 2010. http://www.ure.gov.pl/download.php?s=1&id=4295P1.3 Aplikacja AMI. Koncepcja Zintegrowanego Systemu Aplikacyjnego. Centralna Aplikacja Zarządzająca. 2011.05


3 Koncepcja standardu komunikacji w DSOW niniejszym rozdziale przedstawiono założenia, jakie przyjęto w pracach nad propozycją standardu komunikacji oraz przedstawiono koncepcję standardu, opartą na przyjętych założeniach.

3.1 Założenia dla standardu komunikacji

3.1.1 Założenia ogólnePrzyjęto następujące założenia ogólne:

1. Musi zapewniać wystarczającą funkcjonalność na to, aby spełniać wszystkie wymagania dla Systemu AMI w DSO.

2. Musi być otwarty na zastosowania dotyczące wszelkich urządzeń pomiarowych, a nie jedynie liczników energetycznych (liczniki zużycia gazu, wody, ciepła).

3. Musi zapewniać komunikację pomiędzy urządzeniami różnych producentów (stosujących ten standard).

4. Musi być precyzyjnie zdefiniowany, aby możliwe było przeprowadzenie testów gwarantujących współpracę pomiędzy urządzeniami.

5. Musi zapewnić komunikację pomiędzy:a. KDL a SAK – jeśli odczyty będą się odbywały poprzez KDL (PLC).b. LE a SAK – jeśli odczyty będą wykonywane bezpośrednio przez SAK (GPRS, GSM,

LAN/WAN).

Dodatkowo proponuje się poniższe wskazania, które dobrze byłoby spełnić, ale nie są one obligatoryjne, aby nie została zamknięta droga do rozwiązania autorskiego.

1. Protokół powinien być normowany przez standardy, aby gwarantowana była jego otwartość i rozwój.

2. Użycie protokołu powinno być zweryfikowane we wcześniejszym implementacjach na dużą skalę.

3.1.2 Założenia technicznePrzyjęto następujące założenia techniczne:

1. Ze względu na ograniczenie w przepustowości połączeń pomiędzy KDL a SAK konieczna jest:

a. minimalizacja rozmiaru wiadomości (zapytań i odpowiedzi),b. minimalizacja ruchu w sieci pomiędzy SAK a KDL (komunikaty typu broadcast

i multicast).2. KDL jest „nieprzezroczysty”, co oznacza, że SAK komunikuje się z KDL w sposób

minimalizujący ruch w sieci (patrz założenie powyższe), a KDL jest odpowiedzialny za optymalną organizację komunikacji z LE.

3. Należy dążyć do ujednolicenia sposobu komunikowania się SAK z LE niezależnie od wykorzystywanego kanału komunikacji. W związku z tym w przypadku, gdy licznik nie komunikuje się z infrastrukturą poprzez PLC (a np. poprzez GPRS), a więc gdy pomiędzy LE a SAK nie będzie KDL, funkcjonalnie w miejscu KDL będzie umieszczony Koncentrator Programowy, spełniający funkcje KDL.

4. SAK musi mieć możliwość przekazania do LE komunikatu w trybie „KDL przezroczysty”.5. Konieczne jest odpowiednie zabezpieczenie danych:

a. uwierzytelnianie,


b. autoryzacja i prawa dostępu,c. szyfrowanie,d. integralność danych (mechanizmy kontroli i korekcji błędów),

6. Proponujemy stosowanie otwartych rozwiązań w zakresie implementacji zabezpieczeń danych.

7. Proponujemy stosowanie priorytetyzacji zarówno na poziomie niższych warstw komunikacji jak i warstwy aplikacji.

3.2 Ogólna koncepcja standardu komunikacjiStandard komunikacji należy rozpatrywać w następujących obszarach.

Rysunek 1. Obszary komunikacji w systemie AMI

1. Obszar I - komunikacja pomiędzy systemem SAK a KDL – dostępnym połączeniem komunikacyjnym będzie połączenie oparte o protokół TCP/IP o przepustowości minimalnej 64 kbit/s (w jednej z dwóch podstawowych technik komunikacyjnych: PLC MV lub WiMax).

2. Obszar II - komunikacja pomiędzy KDL a LE – dostępnym połączeniem komunikacyjnym będzie technologia PLC.

3. Obszar III - komunikacja pomiędzy systemem SAK a LE – dostępnym połączeniem komunikacyjnym będzie połączenie oparte o protokół TCP/IP poprzez GPRS o przepustowości rzędu 30 – 80 kbit/s.


SAK - KDL KDL - LE KDLP - LE

Warstwa Aplikacyjna COSEM



(PLC SN, WiMax, GPRS))

PLC OFDM

DCSML

PN/EN 61334-4-32

Warstwa Wrappera

UDP

TCP

GPRS, …

DLMS

PRIME MAC

PRIME PHY

DLMS

PLC OFDM

IP IP

TLS

TCP

UDP

Rysunek 2. Obszary komunikacji w systemie AMI – warstwy protokołu

3.2.1 Obszar komunikacji SAK – koncentratory

Proponujemy opracowanie i implementację języka i standardu komunikacji z koncentratorem, opartego na strukturach i rozwiązaniach stosowanych w języku i protokole SML (Smart Message Language). Definicja języka SML jest oparta na notacji ASN.1, co pozwala na rozszerzenie podstawowych, dostępnych funkcji o nowe, niezbędne dla nas funkcjonalności. Dlatego proponujemy adaptację SML do potrzeb tego projektu.

Zgrupowane komunikaty SML (protokół warstwy aplikacji) przekazywane są w formie plików-strumieni binarnych, w których komunikaty SML zakodowane są zgodnie z ASN.1 do postaci binarnej. Nie będzie stosowany format zapisu bazujący na XML ze względu na duże rozmiary plików oraz ze względu na długi czas przetwarzania i interpretacji zawartości plików XML przez systemy komputerowe.

Ze względu na fakt, że propozycja języka komunikacji pomiędzy SAK a KDL bazuje na języku SML, proponujemy nowemu językowi nadać nazwę DCSML – Data Concentrator Smart Message Language.

W warstwie prezentacji do przekazywania plików DCSML wykorzystany zostanie protokół TLS lub SSL, jako standard zabezpieczenia komunikacji między Systemem Aplikacyjnym a koncentratorem. TLS/SSL zapewniają takie mechanizmy, jak uwierzytelnianie użytkowników oraz kodowanie wysyłanej treści na bazie algorytmu kryptograficznego AES 128.

3.2.2 Obszar komunikacji koncentratory – liczniki

Proponujemy, aby w warstwie komunikacji pomiędzy KDL a licznikami stosować otwarte, unormowane standardy komunikacji. Rekomendujemy zastosowanie w warstwie fizycznej i łącza danych protokołu PRIME, a w warstwie aplikacji zastosowanie standardu DLMS/COSEM.

Protokół warstwy fizycznej i warstwy łącza danych PRIME jest odpowiedni ze względu na następujące cechy:

o jest dobrze zdefiniowanym i opisanym standardem,o na świecie istnieje kilka ośrodków laboratoryjnych certyfikacji urządzeń na zgodność

ze specyfikacją PRIME,


o standard nie narusza praw patentowych firm trzecich,o jest nowoczesnym rozwiązaniem, który w warstwie fizycznej bazuje na technice

modulacji OFDM, dodatkowo charakteryzuje się niewielkim narzutem na rozmiar przesyłanych danych, kontrolą błędów ramek MAC PDU oraz dynamiczną adaptacją struktury logicznej sieci w celu optymalizacji komunikacji oraz w sytuacjach zakłóceń i/lub uszkodzeń poszczególnych węzłów sieci (sieci typu mesh),

o zapewnia mechanizmy związane z bezpieczeństwem przesyłanych danych.

Protokół warstwy aplikacji DLMS/COSEM jest najbardziej odpowiedni ze względu na następujące właściwości:

o jest zdefiniowanym standardem, rozwijanym i utrzymywanym przez stowarzyszenie DLMS User Association,

o sprawdzenie zgodności ze standardem polega na wykonaniu szeregu testów zdefiniowanych w tzw. „Yellow book” DLMS User Association,

o posiada zwięzły format pakietów danych APDU w stosunku do innych protokołów wykorzystywanych w komunikacji licznikowej (np. IEC1107, IEC61056-21, itp.),

o zapewnia wszystkie niezbędne mechanizmy zabezpieczeń pakietów (uwierzytelnianie, autoryzacja, szyfrowanie i integralność danych),

o zapewnia opis danych pomiarowych dla różnych rodzajów dostarczanych mediów (energia elektryczna, woda, ciepło, gaz).

Zarekomendowane dla warstwy komunikacji pomiędzy koncentratorami i licznikami energii, standardowe technologie komunikacyjne mają na celu:

1. Zapewnienie wymienności sprzętu licznikowego między różnymi dostawcami na rynku, a co za tym idzie, uniezależnienie się od pojedynczego dostawcy, który mógłby próbować dyktować swoje ceny w przyszłości.

2. wyeliminowanie problemów z zakłócaniem komunikacji z urządzeniami pracującymi w różnych technologiach PLC w ramach tego samego segmentu sieci energetycznej.

3. Wykorzystanie wiedzy i wieloletniego doświadczenia producentów i stowarzyszeń pracujących nad standardowymi, ujętymi w normach rozwiązaniami.

3.2.3 Obszar komunikacji SAK – liczniki

Ze względu na zachowanie jednolitej formy komunikacji zarówno z koncentratorami, jak również z grupą tych liczników energii elektrycznej, które będą miały być odpytywane bezpośrednio przez system SAK oraz ze względu na protokół komunikacyjny TCP/IP warstwy transportowej, planujemy i w tym wypadku zastosowanie protokołu DCSML, jako protokołu warstwy aplikacji w komunikacji pomiędzy SAK, a koncentratorem programowym (KDLP)..

W celu ujednolicenia komunikacji pomiędzy SAK a LE, czyli w celu objęcia proponowanymi standardami również tych LE, które mogą (lub muszą) komunikować się innym kanałem niż PLC, przyjęto, że w takich przypadkach komunikacja będzie się odbywała za pośrednictwem Koncentratora Programowego (KDLP). Zaletą takiego rozwiązania jest wyodrębnienie procesu komunikacji z licznikami poza System Akwizycji. W chwili obecnej założenie komunikacji tą drogą dotyczy około 2% wszystkich liczników energii. Jednak nie ma pewności, że w przyszłości liczba liczników komunikujących się tą drogą nie ulegnie zwiększeniu. Co więcej w trakcie wdrażania infrastruktury licznikowej może okazać się, że istnieją miejsca (obszary geograficzne), w których zastosowanie PLC okaże się niemożliwe. Wyodrębnienie Koncentratora Programowego KDLP zapewni możliwość obsługi większej, niż założona, liczby liczników. Co więcej w systemie może istnieć więcej niż jeden KDLP w różnych lokalizacjach geograficznych oraz na wielu maszynach (stacjach komputerowych).


Proponujemy, aby w warstwie komunikacji pomiędzy KDLP, a licznikami stosować otwarte, unormowane standardy komunikacji. Rekomendujemy zastosowanie kompletnego standardu DLMS/COSEM. Ze względu na stosowanie łączy GPRS z protokołem TCP/IP, w warstwie prezentacji powinien zastosowany zostać wrapper DLMS ujęty w standardzie DLMS/COSEM.

3.2.4 Priorytetyzacja ruchuSzeroko pojęta priorytetyzacja ruchu ma na celu umożliwienie przesyłania wiadomości o różnym stopniu ważności w różnych reżymach czasowych, tak aby transmisja mniej istotnych wiadomości nie blokowała tych ważniejszych.

Przed opisaniem zasad i realizacji priorytetyzacji ruchu podano założenia przyjęte dla realizowanych (i w związku z tym priorytetyzowanych) Zadań.

3.2.4.1 ZadaniaPrzyjęto następujące założenia dotyczące Zadań:

1. Zadania mają następującą charakterystykę:a. mogą obejmować jedną lub wiele czynności,b. jeśli zadania obejmują wiele czynności, muszą mieć one określoną kolejność

wykonywania; c. zadania mogą być adresowane do jednego, wielu (multicast) lub wszystkich

(broadcast) liczników.2. Zadanie może być zlecone przez CAZ do SAK w następujący sposób:

a. jednorazowo wydane polecenie wykonania zadania dla jednego lub wielu liczników (zarówno z terminem wykonania natychmiastowego jak i w przyszłości)

b. jednorazowo wydane polecenie wykonania cyklicznego zadania (subskrypcji, np. dziennej) dla jednego lub wielu liczników

3. Głównymi atrybutami pojedynczego zadania są:a. priorytet: standardowy, wysoki, krytyczny (domyślnie przyjmowany jest

standardowy),b. sposób realizacji:

i. pojedyncza sesja komunikacyjna: PULL (przewidziane do realizacji krótkich zadań w ramach pojedynczego licznika, np. wyłącz stycznik). [Patrz Rysunek 3]

ii. dwie sesje komunikacyjne: PULL + PULL (przewidziane do realizacji złożonych zadań przy założeniu podjęcia decyzji o odczycie wyników przez SAK); pierwsza sesja do przekazanie zadania do KDL, druga to przekazanie wyników do SAK. [Patrz Rysunek 4]

iii. dwie sesje komunikacyjne: PULL + PUSH (przewidziane do realizacji złożonych zadań przy założeniu podjęcia decyzji o odczycie wyników przez KDL); pierwsza sesja do przekazanie zadania do KDL, druga to przekazanie wyników do SAK. Metoda ta jest podstawową metodą stosowaną przy masowym odczycie danych z LE. [Patrz Rysunek 5]

iv. pojedyncza sesja komunikacyjna: PUSH (do odczytu danych zdarzeniowych o sytuacjach alarmowych). [Patrz Rysunek 6]


sd PULL

SAK

(from Aktorzy SAK)

KDL

(from Aktorzy SAK)

LE

(from Aktorzy SAK)

Get data()

ack()

Get data()

Send data()

Send data()

ack + disconnect()

Rysunek 3: Diagram sekwencji – pojedyncza sesja komunikacyjna PULL

sd PULL PULL

SAK

(from Aktorzy SAK)

KDL

(from Aktorzy SAK)

LE

(from Aktorzy SAK)

Get data()

ack + disconnect()

Get data()

Send data()

Get data()

Send data()

ack + disconnect()

Rysunek 4: Diagram sekwencji –dwie sesje komunikacyjne PULL + PULL


sd PULL PUSH

SAK

(from Aktorzy SAK)

KDL

(from Aktorzy SAK)

LE

(from Aktorzy SAK)

Get data()

ack + disconnect()

Get data()

Send data()

Send data()

ack + disconnect()

Rysunek 5: Diagram sekwencji – dwie sesje komunikacyjne PULL + PUSH

sd PUSH

SAK

(from Aktorzy SAK)

KDL

(from Aktorzy SAK)

LE

(from Aktorzy SAK)

ALARM()

ALARM()

ack + disconnect()

Rysunek 6: Diagram sekwencji – pojedyncza sesja komunikacyjna PUSH

4. Konfiguracja sposobu realizacji zadań odbywać się będzie po stronie systemu CAZ, z zastrzeżeniem, że jedynie Administrator systemu będzie miał dostęp do konfiguracji sposobu realizacji zadania (p. 3b), natomiast użytkownicy będą jedynie wybierać konkretne zadania z dostępnej, wcześniej skonfigurowanej listy.

3.2.4.2 Zasady priorytetyzacjiW ramach wymiany danych wyszczególniono następujące możliwości parametryzacji priorytetów

1. Priorytet na poziomie komunikacji SAK-KDL i przetwarzania przez KDL (komunikacja KDL-LE)

2. QoS dla danych na poziomie TCP/IP

Priorytet na poziomie komunikacji SAK-KDL pozwala określić, które zadania na poziomie centralnym będą przetwarzane w pierwszej kolejności w zakresie komunikacji z Koncentratorami i Licznikami. Priorytet pozwala określić również, które czynności komunikacyjne z poszczególnymi licznikami winny być wykonane przez KDL w pierwszej kolejności.QoS dla danych na poziomie TCP/IP jest zaleceniem dla sesji komunikacyjnych (o ile mechanizm ten jest wspierany przez koncentrator), które są nawiązywane przez Koncentratory w celu przesłania


wyników do SAK. W odróżnieniu od możliwości kolejkowania zadań przez SAK w wypadku transmisji inicjowanej w drugą stronę (KDLSAK) takiej możliwości nie ma, dlatego też nadanie priorytetów na poziomie pakietów danych (QoS) umożliwi dostarczenie wyników zadań określonych jako pilne i dalsze ich przetwarzanie przez SAK w pierwszej kolejności.

Priorytety mogą przyjmować następujące wartości:

1. Standardowy, w normalnym trybie dla przepływu typowych informacji, dla których nie postawiono wysokich reżymów czasu

2. Wysoki, dla przepływu informacji o wysokim stopniu ważności, które winny być niezwłocznie dostarczone

3. Krytyczny, dla przepływu informacji o najwyższym stopniu ważności, np. w celu anulowania wykonania zadań o priorytecie wysokim – do wykorzystania w szczególnych przypadkach.

Przetwarzanie w pierwszej kolejności będzie obejmować zadania o priorytecie najwyższym, następnie wysokim. Zadania o priorytecie standardowym będą wykonywane w ostatniej kolejności.

Należy zaznaczyć również, że w przypadku pojawienia się zadania o wyższym priorytecie inne zadania, które są aktualnie wykonywane, nie zostaną przerwane i będą dokończone. Nie będą natomiast rozpoczynane kolejne zadania o niższym priorytecie. Zadania o wyższych priorytetach zaczną być przyjmowane do realizacji dopiero po zwolnieniu wymaganych zasobów. Po przyjęciu ostatniego zadania o wyższym priorytecie rozpocznie się proces przyjmowania do realizacji zadań o priorytetach niższych.

W przypadku wykorzystania QoS na poziomie pakietów TCP/IP priorytetem jest liczba z przedziału 0-65535. Po stronie koncentratora leży zarządzanie parametrem QoS. Zalecane jest wprowadzenie obsługi przez koncentrator trzech priorytetów na poziomie QoS odpowiadających priorytetom zdefiniowanym dla warstwy aplikacyjnej. Liczba określająca priorytet winna być parametrem zdalnie konfigurowalnym na koncentratorze (z poziomu SAK). W celu umożliwienia działania mechanizmu winna być ustawiana flaga URG na poziomie pakietu TCP/IP oraz konfigurowana wartość liczbowa reprezentująca priorytet.

Z uwagi na fakt różnych możliwości realizacji zadań oraz priorytetów na kilku poziomach poniżej zamieszczono możliwości konfiguracji zadań:

L.P. Realizacja zadania Priorytet QoS

1. PULL TAK TAK

2. PULL + PULL TAK TAK

3. PULL + PUSH TAK TAK

4. PUSH NIE TAK

Priorytety można konfigurować dla zadań realizowanych w ramach pojedynczych sesji komunikacyjnych (PULL) oraz w ramach podwójnych sesji komunikacyjnych (zarówno podwójny PULL jak i PULL + PUSH). Priorytet obejmuje zarówno komunikację na styku SAK-KDL w zakresie kolejkowania zadań i ich przetwarzania jak również w zakresie przetwarzania danych przez KDL, w tym komunikacji na styku KDL-LE.Priorytet nie może być konfigurowany dla transmisji zdarzeń alarmowych w trybie PUSH, ponieważ z uwagi na wysoką wagę zdarzeń te zadania przetwarzane są przez SAK w pierwszej kolejności.


W celu umożliwienia realizacji mechanizmów priorytetyzacji zaleca się wdrożyć następujące mechanizmy na Koncentratorach:

1. Koncentrator winien mieć zaimplementowaną równoległą obsługę sesji TCP/IP na poziomie komunikacji pomiędzy SAK i KDL.

2. W przypadku otrzymania kolejnego zadania równoległego (sesja SAK-KDL o wyższym priorytecie), Koncentrator winien zamrozić wykonywanie aktualnych zadań z priorytetem niższym do czasu zakończenia zadania o priorytecie wyższym.

3. W przypadku kolejnej równoległej sesji SAK-KDL z identycznym priorytetem, koncentrator winien umożliwić równoległe przetwarzanie wszystkich zadań o tym samym priorytecie.

4. W przypadku pojawienia się wielu sesji SAK-KDL, z czego jedna z nich będzie posiadać wyższy priorytet niż pozostałe, zadania pozostałych sesji o niższym priorytecie winny zostać wstrzymane do czasu zakończenia wykonywania zadania z sesji o wyższym priorytecie.

5. W przypadku wstrzymywania wykonywania zadania przez Koncentrator, powinien on dokończyć wykonywanie atomowej operacji na poziomie sieci PLC, np. odczyt pojedynczego parametru z danego Licznika, przed rozpoczęciem wykonywania czynności w ramach innego zadania o większym priorytecie.

6. W przypadku wykonywania zadań w ramach pojedynczych sesji komunikacyjnych, pojawienie się kolejnego zadania z wyższym priorytetem nie powinno wstrzymać realizacji tego pierwszego zadania, tak aby nie wstrzymywać niepotrzebnie nawiązanej sesji SAK-KDL. Wstrzymywanie wykonywania zadań winno dotyczyć jedynie tych, realizowanych w ramach podwójnych sesji komunikacyjnych (zlecenie + odczyt wyników).

W przypadku bezpośredniej komunikacji SAK z licznikami komunikacja będzie się odbywać przez programowy koncentrator i zostaną zastosowane reguły opisane powyżej dla przypadku komunikacji SAK – Koncentrator – Licznik.

3.2.5 Podpisy cyfroweZabezpieczenie komunikacji SAK-KDL wykorzystuje mechanizm TLS/SSL oparty o klucze infrastruktury PKI. CA powinno być zapewnione przez służby IT DSO.

3.2.6 Koncepcja transportu

I. Transport danych na drodze Serwer Akwizycji – Koncentrator

Do wymiany danych w warstwie aplikacji wykorzystano protokół DCSML (Data Concentrator Smart Message Language, będącego modyfikacją języka SML pod kątem optymalizacji przetwarzania na potrzeby wdrożenia systemu AMI w DSO).

Protokół umożliwia elastyczne definiowanie zadań i odpowiedzi na nie. Jest platformą wymiany danych w zestandaryzowany sposób na drodze Serwer Akwizycyjny – Koncentrator. Dane, zarówno zadania jak i wyniki, formowane są w elementarne jednostki binarne APDU, które przeznaczone są do przesłania w jednolitej formie z Serwera Akwizycyjnego (SAK) do Koncentratora (KDL) lub odwrotnie.

W ramach warstwy sesji modelu ISO OSI jako warstwę strumienia danych zastosowano protokół TLS/SSL z algorytmem szyfrującym AES oraz uwierzytelnianie za pomocą kluczy publicznych i prywatnych. Proces zestawiania połączenia przebiega w następujący sposób:


1. Połączenie Serwera Akwizycyjnego z Koncentratorem na poziomie gniazd (sockets) TCP/IP na określonym porcie.

2. Uwierzytelnianie:a. Serwer AMI inicjuje połączenie do koncentratora i wysyła liczbę losowąb. Koncentrator wysyła do serwera swój certyfikat (klucz publiczny) i liczbę losowąc. Serwer AMI wysyła do koncentratora swój certyfikat (klucz publiczny)d. Serwer AMI generuje klucz sesji (używany w szyfrowaniu AES), szyfruje go

publicznym kluczem koncentratora i wysyła do koncentratorae. Serwer AMI podpisuje wymienione wcześniej liczby losowe swoim kluczem

prywatnymf. Koncentrator deszyfruje klucz sesji swoim kluczem prywatnym (fakt posiadania

odszyfrowanego klucza sesji, czyli w konsekwencji posiadania klucza prywatnego zgodnego z publicznym jest dowodem tożsamości koncentratora)

g. Koncentrator weryfikuje podpis wysłany przez serwer AMI kluczem publicznym serwera (poprawność podpisu dowodzi, że serwer AMI posiada klucz prywatny zgodny z publicznym czyli potwierdza tożsamość serwera)

h. Uwierzytelnione strony rozpoczynają transmisję danych przy użyciu algorytmu AES i klucza wymienionego w punkcie 4.

i. W przypadku błędu uwierzytelniania (np. niewłaściwe klucze) zarówno Serwer Akwizycyjny jak i Koncentrator natychmiast zrywają połączenie na poziomie TCP/IP.

3. Zestawienie szyfrowanej sesji transmisji na podstawie klucza symetrycznego i prowadzenie cyklicznego dialogu:

a. Wysłanie przez Serwer Akwizycji żądania w formie pakietu danych APDU,b. Odesłanie odpowiedzi przez Koncentrator w formie pakietu danych APDU,c. Zamknięcie sesji transmisyjnej.

Istnieje możliwość optymalizacji procesu uwierzytelniania o brak każdorazowej wymiany kluczy publicznych (przechowywane są lokalnie po stronie SAK i KDL), o ile zaistnieją możliwości techniczne realizacji takiego algorytmu.

II. Transport zdarzeń na drodze Koncentrator - Serwer Akwizycyjny

Zarówno w warstwie aplikacji jak i transportowej komunikacja w obie strony jest symetryczna. Komunikacja odbywa się protokołem DCSML (opisany w rozdziale ), zabezpieczonym poprzez protokół TLS/SSL.

Ze względu na asynchroniczność zdarzeń, występuje możliwość pojawienia się dużej ilości prób nawiązania połączenia w małej jednostce czasu. Po stronie serwera akwizycyjnego będzie zastosowany load balancer, którego zadaniem jest rozkładanie obciążenia pomiędzy poszczególne węzły klastra SAK, które niezależnie od siebie zajmują się przetwarzaniem zgłoszonych zdarzeń.

Obecność wielu węzłów SAK i rozkładanie obciążenia nie są dla Koncentratora z punktu widzenia komunikacji istotne. Koncentrator wykonuje połączenie na skonfigurowany wcześniej adres Serwera Akwizycyjnego tak jakby to był pojedynczy serwer.

III. Wymagania z zakresu infrastruktury sieciowej

Komunikacja pomiędzy Serwerami Akwizycyjnymi a Koncentratorami odbywa się na poziomie protokołu TCP/IP. W celu umożliwienia jednoznacznego zaadresowania koncentratora lub licznika (w przypadku 2% liczników, z którymi komunikacja odbywać się będzie bezpośrednio) niezbędne jest nadanie im unikalnej adresacji IP w skali globalnej sieci DSO. Istnieją dwie możliwości nadawania adresów IP – statycznie i dynamicznie. Pierwsza metoda zakłada ręczne skonfigurowanie parametrów


sieci na koncentratorach przed instalacją w terenie. Druga zakłada wykorzystanie serwerów DHCP, do automatycznego nadawania adresów IP i pozostałych parametrów konfiguracyjnych sieci.

Z uwagi na fakt dużej skali przedsięwzięcia i konieczności przeprowadzenia konfiguracji około 60 tysięcy Koncentratorów istnieje ryzyko występowania znacznego odsetka błędnych konfiguracji z powodu czynnika ludzkiego. Dlatego też rekomenduje się zastosowanie automatycznego nadawania adresów IP za pośrednictwem serwerów DHCP.

1. Spełnienie następujących wymagań umożliwi odejście od ręcznej konfiguracji w zakresie adresów IP Koncentratorów na stołach montażowych na rzecz automatycznej: nadawanie koncentratorom adresów IP przez serwery DHCP z globalnej puli adresowej, przewidzianej dla sprzętu pomiarowego. Przez globalną pulę adresową rozumiana jest pula adresów dedykowana dla infrastruktury pomiarowej w ramach sieci DSO, jednak nie oznacza to konieczności wykorzystania fragmentu globalnej puli adresowej sieci Internet.

2. Automatyczne wykonywanie rezerwacji adresów IP dla danego adresu MAC koncentratora (lub licznika z puli 2%) tak, aby przy kolejnych żądaniach nadania adresu IP przez to samo urządzenie adres ten był niezmienny.

3. Przechowywanie rezerwacji adresów przez okres 90 dni w przypadku braku aktywności urządzeń. Dopiero w przypadku dłuższego braku aktywności urządzeń adres IP może zostać zwolniony i przydzielony innemu koncentratorowi (lub licznikowi z puli 2%)

4. Synchronizacja rezerwacji adresów IP pomiędzy serwerami DHCP tak, aby zapewnić unikalną adresację dla poszczególnych urządzeń. Ewentualnie wykorzystanie jednego centralnego serwera DHCP dla całej sieci pomiarowej.

Szczegóły polityki zarządzania infrastrukturą sieciową muszą być zgodne z polityką korporacyjną DSO w tym zakresie.


4 Licznikowe Przypadki UżyciaW niniejszym rozdziale przedstawiono wyniki prac analitycznych związanych ze zdefiniowaniem przypadków użycia, które są związane z Infrastrukturą Licznikową.Opracowano listę Licznikowych Przypadków Użycia.Dla każdego przypadku przeanalizowano komunikaty i dane wymieniane pomiędzy SAK, KDL i LE.Na podstawie wyników tej analizy opracowano składnię języka DCSML, czyli zestaw komunikatów, który powinien być wystarczający do obsłużenia wszystkich zidentyfikowanych Licznikowych Przypadków Użycia (LPU).

4.1 Kategorie, Identyfikatory i Statusy Licznikowych Przypadków UżyciaPoniższa tabela prezentuje kategorie, które określono dla Licznikowych Przypadków Użycia.

Tabela 2. Kategorie Licznikowych Przypadków Użycia

Kod Nazwa OpisI Instalacja LPU dotyczące instalacji i deinstalacji KDL i LE, wymiany,

aktualizacji oprogramowania, itp.

K Konfiguracja LPU związane z konfigurowaniem KDL i LE.

O Odczyt LPU dotyczące odczytów danych licznikowych.

S Sterowanie LPU wymagające przekazania do LE i/lub KDL żądań sterujących pracą urządzeń.

Z Zgłoszenie LPU realizowane poprzez zgłoszenie alarmu przez LE i KDL. Tę kategorię wyróżniono, ponieważ LPU z nią związane wymagają specjalnego przepływu komunikatów pomiędzy urządzeniami.

Każdemu LPU przypisano:

Identyfikator, Kategorię, Status.

Identyfikator ma następującą strukturę: LPUnna, gdzie:

LPU to napis stały, nn to numer (z nieznaczącym zerem); ze względu na to, że lista będzie aktualizowana, LPU

mogą być z niej usuwane, zatem numery nn niekoniecznie muszą być numerami kolejnymi, a to mała litera (opcjonalna), umożliwiająca wstawianie nowych LPU w kolejności logicznej

pomiędzy już istniejące LPU.

Statusy mogą mieć następujące wartości:

A – LPU aktywny, do obsłużenia w pierwszej wersji DCSML, B – LPU do obsłużenia w przyszłości, W – LPU wątpliwy, decyzję co do jego istnienia należy podjąć w trakcie dalszych prac

analitycznych, X – LPU skasowany, logicznie usunięty z listy LPU; nie jest usuwany z niej fizycznie, aby nie

było możliwe ponowne użycie jego identyfikatora, co może prowadzić do nieporozumień.


W dalszej analizie związanej z projektem języka DCSML pod uwagę brane były jedynie LPU o statusie „A”.

4.2 Lista Licznikowych Przypadków UżyciaPoniższa tabela zawiera spis LPU o statusie „A”.

Tabela 3. Licznikowe Przypadki Użycia o statusie „A”

Identyfikator NazwaLPU01 Instalacja nowego LE, zgłoszenie się LE po awarii zasilaniaLPU02 Instalacja nowego KDLLPU03 Brak łączności z LELPU04 Wyłączenie/Awaria KDLLPU05 Aktualizacja oprogramowania LELPU06 Aktualizacja oprogramowania KDLLPU07 Konfiguracja LELPU08 Konfiguracja KDLLPU09 Definicja subskrypcjiLPU10 Odczyt rejestrów LELPU11 Odczyt konfiguracji i danych z KDLLPU12 Realizacja subskrypcjiLPU13 Odczyt konfiguracji LELPU14 Sprawdzenie połączenia z LELPU15 Sprawdzenie połączenia z KDLLPU16 Bezpośrednia komunikacja z LE (tryb przezroczystego koncentratora)LPU17 Restart KDLLPU18 Zgłoszenie alarmu przez LELPU19 Zgłoszenie alarmu przez KDLLPU20 Synchronizacja / zmiana czasu LE

Pełna lista Licznikowych Przypadków Użycia – wraz ze wskazaniem Kategorii – została podana w Załączniku nr 2 do niniejszego dokumentu w Arkuszu „LPU”.

4.3 Analiza Licznikowych Przypadków UżyciaDla każdego LPU określono:

1. Zakres.2. Wymieniane dane i komunikaty (diagramy sekwencji).

Na diagramach sekwencji wymianę danych pomiędzy SAK a KDL opisano proponowanymi komunikatami DCSML. Pod diagramami umieszczono opisy poszczególnych przepływów, przy czym kolejne punkty dotyczą kolejnych przepływów oznaczonych numerami punktów.

Przyjęto następujące zasady komunikacji pomiędzy SAK a KDL:


1. Zasadniczym celem do osiągnięcia jest minimalizacja przepływów danych z jednoczesną minimalizacją czasu oczekiwania na odpowiedzi z LE.

2. Założono, że z reguły dane z KDL do SAK będą przekazywane niezwłocznie po ich skompletowaniu w KDL. Do tego celu zostanie zastosowana metoda „push”, czyli przesyłanie danych z KDL do SAK bez oczekiwania na żądanie ze strony SAK.

3. Możliwa będzie realizacja odczytów danych z LE z wykorzystaniem trybu „pull”. Wymuszenie trybu „pull” będzie możliwe:

a. na poziomie pojedynczego Zadania odczytu danych z LE – w takim przypadku Zadanie będzie opatrywane atrybutem „realizacja w trybie pull”,

b. na poziomie KDL – w takim przypadku w parametrach konfiguracyjnych KDL będzie ustawiona wartość „realizuj Zadania odczytu danych z LE w trybie pull”,

c. na poziomie SAK – wtedy wszystkie Zadania odczytu danych z LE będą opatrywane atrybutem „realizacja w trybie pull”,

d. na poziomie Subskrypcji – wtedy wszystkie Zadania odczytu danych z LE generowane przez KDL w ramach Subskrypcji będą opatrywane atrybutem „realizacja w trybie pull”,

4. W konfiguracji KDL będzie określony maksymalny czas oczekiwania na skompletowanie odpowiedzi od LE. Po przekroczeniu tego czasu KDL przekaże dotychczas zebrane dane do SAK – bez względu na to, ile LE do tego czasu odpowiedziało.

5. SAK po otrzymaniu odpowiedzi od KDL sprawdza kompletność otrzymanych danych. W przypadku, gdy są niekompletne, podejmuje odpowiednie akcje: sprawdzenie stanu LE w CAZ (na podstawie danych z SID), sprawdzenie połączenia z LE, dopytanie o brakujące dane.

6. W trybie subskrypcji inicjatorem zadań w kolejnych cyklach jest KDL. Informacje o subskrypcje są zaewidencjonowane zarówno w SAK i KDL, tak aby SAK był w stanie kontrolować przekroczenie maksymalnych czasów przesyłania danych przez KDL.

7. Założono, że LE może być widziany tylko przez jeden KDL. Sytuacja, gdy ten sam LE zostanie zgłoszony przez różne KDL jest uznana za błędną i powinna zostać zasygnalizowana z priorytetem krytycznym do CAZ.

8. Zadania odczytu danych z LE. konfigurowania oraz wymiany firmware LE mogą być adresowane do:

a. pojedynczego LE,b. wielu LE (multicast),c. wszystkich LE (broadcast).

Uwaga: Przeprowadzona analiza miała na celu opracowanie języka komunikacji pomiędzy SAK a KDL. Z tego względu diagramy sekwencji dotyczą jedynie komunikacji pomiędzy SAK a pojedynczym KDL oraz obsługiwanymi przez ten KDL licznikami. Nie zajmujemy się w tej analizie sposobem generacji komend DCSML typu multicast i broadcast kierowanych do poszczególnych KDL na podstawie zleceń otrzymywanych przez SAK od Centralnej Aplikacji Zarządzającej.

Przedstawione w dalszej części dokumentu diagramy sekwencji dla poszczególnych Licznikowych Przypadków Użycia należy traktować jako propozycję sposobu wymiany danych pomiędzy poszczególnymi aktorami LPU. W rzeczywistości szczegóły dotyczące zarówno kolejności, jak i wymienianych danych, będą zależały od konkretnych rozwiązań poszczególnych producentów, a także od wyników dalszych prac analityczno-projektowych.


4.3.1 Kategoria Instalacja

Poniższy diagram przedstawia Licznikowe Przypadki Użycia w Kategorii Instalacja.

uc Kategoria Instalacja

LPU01 Instalacja nowego LE,

zgłoszenie sie LE po awarii

LPU02 Instalacja nowego KDL

LPU03 Brak łączności z LE

LPU04 Wyłączenie/Awaria

KDL

LPU05 Aktualizacja oprogramowania LE

LPU06 Aktualizacja oprogramowania KDL

Rysunek 7. LPU w Kategorii Instalacja


4.3.1.1 LPU01: Instalacja nowego LE, zgłoszenie się LE po awarii

Zakres zgłoszenie się nowego LE do KDL, zgłoszenie się LE do KDL po awarii zasilania/wyłączeniu planowym.

Diagramy sekwencji sd LPU01 Instalacja nowego LE, zgłoszenie się LE po awarii zasilania

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

CAZ

(from Aktorzy LPU)

KDL2

(from Aktorzy LPU)

1. Zgłoszenie się LE()

2. Sprawdzenie czy LE jest w tabeli routingowej()

3. DCAttentionResponse()

4. Sprawdzenie czy LE jest w tabeli routingowej innego KDL()

5. DCAttentionRequest()


6. Alarm o wysokim priorytecie()


8. DCAttentionRequestt()

Rysunek 8. Diagram sekwencji dla LPU01 – sytuacja prawidłowa

1. LE zgłasza się do KDL jako nowy lub po awarii. Zgłoszenie zawiera identyfikator LE oraz kod komunikatu związanego ze zgłoszeniem. Kod komunikatu zgłoszenia wskazuje na przyczynę zgłoszenia się LE do KDL.

2. KDL sprawdza, czy LE jest w jego tabeli routingowej. a. Jeśli LE zgłosił się jako nowy i nie ma go w tabeli routingowej => przejście do punktu

nr 7.b. Jeśli LE zgłosił się po awarii i jest w tabeli routingowej => przejście do punktu nr 7.

3. KDL wysyła do SAK informację o zgłoszeniu się LE i o problemie z tym związanym.4. SAK sprawdza, czy nowy LE znajduje się w tabeli routingowej innego KDL. 5. Jeżeli LE znajduje się w tablicy routingowej innego KDL, wówczas SAK odpytuje ten KDL

w celu upewnienia się, że LE jest dostępny z dwóch KDL. 6. Jeżeli taka sytuacja ma miejsce, wówczas SAK zgłasza do CAZ alarm o wysokim priorytecie.7. KDL zgłasza do SAK, że do niego zgłosił się LE.8. SAK przekazuje do KDL potwierdzenie otrzymania danych.

W przypadku, gdy zgłasza się nowy LE, o odczycie i zakresie odczytywanych danych decyduje CAZ.


4.3.1.2 LPU02: Instalacja nowego KDL

Zakres zgłoszenie się KDL (nowego lub po planowym wyłączeniu/awarii) do SAK, uzgodnienie przez KDL z SAK konfiguracji.

Diagram sekwencji sd LPU02 Instalacja nowego KDL

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

CAZ

(from Aktorzy LPU)

1. DCGetParamResponse()

2. Info o zgłoszeniu się KDL()


Rysunek 9. Diagram sekwencji dla LPU02

1. KDL zgłasza się do SAK. W zgłoszeniu przekazuje swoje dane identyfikacyjne.2. SAK informuje CAZ o zgłoszeniu się KDL.3. SAK odpowiada do KDL. W przypadku nowego koncentratora przekazuje dane

konfiguracyjne.

4.3.1.3 LPU03: Brak łączności z LE

Zakres odinstalowanie LE, sytuacje awaryjne powodujące utratę łączności z LE.

Diagram sekwencji sd LPU03 Brak łączności z LE

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

CAZ

(from Aktorzy LPU)


2. Sprawdzenie stanu LE()

2. Sprawdzenie stanu LE()




1. KDL rozpoznaje LE jako problematyczny (brak łączności). Wysyła do SAK informację o tym fakcie, podając dane problematycznego LE.

2. SAK sprawdza w CAZ (na podstawie danych z SID) stan LE. 3. SAK przekazuje do KDL informację dotyczącą problematycznego LE. LE mógł być

wyłączony, zdjęty, itp. – w takim przypadku KDL kończy próby nawiązywania łączności z tym LE.

CAZ decyduje o strategii dalszej komunikacji.

4.3.1.4 LPU04: Wyłączenie/Awaria KDL

Zakres Serwis (poniższy scenariusz jest uwarunkowany posiadaniem przez KDL odpowiedniej

funkcjonalności):o monter przez interfejs lokalny wprowadza KDL w stan serwisowania,o do SAK wysyłana jest informacja o wprowadzeniu KDL w stan serwisowania, co

może spowodować akcję odczytu z KDL wszystkich nieodczytanych jeszcze danych (patrz LPU11),

o następuje zamknięcie systemu operacyjnego KDL, o po komunikacie (lokalnie) zakończenia zamykania następuje demontaż lub serwis, o po zakończeniu serwisu i restarcie KDL informuje SAK, że już jest aktywny (patrz

LPU02). Awaria: Sytuacja awaryjna, awaria sprzętu koncentratora uniemożliwiająca działanie systemu

operacyjnego, serwis KDL nieposiadającego opisanej powyżej funkcjonalności, awaria kanału komunikacyjnego do KDL;

o awaria KDL lub wyłączenie koncentratora przez serwisanta,o SAK podejmuje próby wznowienia łączności (parametr czasu i liczby prób),o SAK sprawdza stan KDL w CAZ (na podstawie danych z SID),o jeśli w CAZ brak informacji o planowanym serwisowaniu KDL, zmienia kanał na

rezerwowy – jeśli jest dostępny; po określonym czasie zgłasza awarię do CAZ,

Diagramy sekwencji sd LPU04 Wyłączenie/Awaria KDL - tryb serwisowania

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

1. Tryb serwisowania()



4. Wyłączenie()

Rysunek 11. Diagram sekwencji dla LPU04 – tryb serwisowania


1. Monter za pośrednictwem interfejsu lokalnego wprowadza KDL w tryb serwisowania. Czeka na odpowiedź KDL, że zakończone zostało informowanie SAK o planowanej przerwie.

2. KDL informuje SAK, że będzie przerwa w łączności. 3. SAK potwierdza otrzymanie tej informacji.4. Monter demontuje KDL lub wykonuje serwis.

sd LPU04 Wyłączenie/Awaria KDL - bez trybu serwisowania

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

CAZ

(from Aktorzy LPU)

1. Awaria lub wyłączenie()

2. DCGetParamRequest()

3. Sprawdzenie stanu KDL()

3. Sprawdzenie stanu KDL()


5. Przekazanie informacji o problemie()

Rysunek 12. Diagram sekwencji dla LPU04 – bez trybu serwisowania

1. Następuje awaria KDL lub jego wyłączenie przez montera.2. SAK stwierdza brak łączności. Usiłuje nawiązać połączenie z KDL – bez powodzenia.3. SAK sprawdza w CAZ (na podstawie danych z SID) stan KDL. 4. Jeśli nie ma w CAZ informacji o planowanym serwisie, a jest określony rezerwowy kanał

komunikacji z KDL, SAK usiłuje nawiązać połączenie z wykorzystaniem tego kanału.5. Jeśli próby nawiązania łączności się nie powiodą, SAK informuje CAZ o zaistniałej sytuacji.

4.3.1.5 LPU05: Aktualizacja oprogramowania LE

Zakres wystawienie obrazu oprogramowania do KDL i wydanie polecenia przez SAK do KDL

wymiany oprogramowania w LE ze wskazaniem terminu przełączenia na nowe oprogramowanie,

przetransferowanie oprogramowania do licznika, ustawienie momentu przełączenia na nową wersję oprogramowania,

potwierdzenie wykonania.


Diagram sekwencji sd LPU05 Aktualizacja oprogramowania LE

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterFirmwareRequest()


3. Przekazanie oprogramowania()



4. Potwierdzenie otrzymania oprogramowania()



5. DCMeterAttentionResponse()

6. Potwierdzenie wykonania aktualizacj i()





1. SAK wysyła do KDL obraz oprogramowania dla LE z określeniem czasu aktualizacji.2. KDL wysyła do SAK potwierdzenie otrzymania obrazu oprogramowania.3. KDL wysyła do LE obraz oprogramowania z określeniem czasu aktualizacji. Poniższe

działania są wykonywane dla wszystkich LE, do których zostało wysłane nowe oprogramowanie.

4. LE wysyła do KDL potwierdzenie otrzymania obrazu oprogramowania.5. KDL wysyła do SAK potwierdzenie otrzymania obrazu oprogramowania przez poszczególne

LE.6. W oznaczonym czasie LE wykonuje aktualizację oprogramowania i informuje KDL o tym

fakcie, przekazując jednocześnie identyfikator wersji zainstalowanego oprogramowania.7. KDL informuje SAK o fakcie aktualizacji oprogramowania w poszczególnych LE, podając

identyfikatory wersji zainstalowanego oprogramowania.

4.3.1.6 LPU06: Aktualizacja oprogramowania KDL

Zakres wystawienie obrazu oprogramowania do KDL i wydanie polecenia przez SAK do KDL

wymiany oprogramowania ze wskazaniem terminu przełączenia na nowe oprogramowanie, potwierdzenie wykonania.


Diagram sekwencji sd LPU06 Aktualizacja oprogramowania KDL

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

1. DCFirmwareRequest()


3. Aktualizacja oprogramowania()

4. DCGetParamResponse()


1. SAK wysyła do KDL obraz oprogramowania z określeniem czasu aktualizacji.2. KDL wysyła do SAK potwierdzenie otrzymania obrazu oprogramowania.3. KDL wykonuje aktualizację swojego oprogramowania i od odpowiedniego terminu pracuje na

nowym oprogramowaniu.4. KDL przekazuje do SAK identyfikator wersji zainstalowanego oprogramowania.


4.3.2 Kategoria KonfiguracjaPoniższy diagram przedstawia Licznikowe Przypadki Użycia w Kategorii Konfiguracja.

uc Kategoria Konfiguracja

LPU07 Konfiguracja LE

LPU08 Konfiguracja KDL

LPU09 Definicja Subskrybcj i

LPU20 Synchronizacja / zmiana czasu LE

Rysunek 15. LPU w Kategorii Konfiguracja

4.3.2.1 LPU07: Konfiguracja LE

Zakres Zmiana parametrów (konfiguracji) LE:

o kalendarz (strefy),o ograniczenie mocy,o zmiana stanu stycznika (wyłączenie, zazbrojenie),o synchronizacja lub ustawienie czasu,o definicja momentu rejestracji danych w profilach/archiwach,o definicja struktury rejestrów złożonych (profile, archiwa),o wyświetlenie komunikatu na wyświetlaczu LE,o przekazanie komunikatu do HAN,o inne.


Diagram sekwencji sd LPU07 Konfiguracja LE

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterSetParamRequest()

2. Żądanie zmiany konfiguracji()


3. Potwierdzenie realizacji/przyjęcia żądania()

3. Potwierdzenie realizacji/przyjęcia żądania()


5. Aktywacja nowej konfiguracji()

5. Aktywacja nowej konfiguracji()


1. SAK wysyła do KDL żądanie ustawienia określonych wartości parametrów w LE. W żądaniu może być określony termin, od którego nowe parametry mają zacząć obowiązywać.

2. KDL generuje żądania parametryzacji do wszystkich LE podanych w żądaniu od SAK. 3. LE potwierdza realizację żądania (lub jego przyjęcie – jeśli jest określony termin rozpoczęcia

obowiązywania nowych parametrów).4. Po otrzymaniu potwierdzeń od wszystkich LE, KDL potwierdza do SAK, że dane zostały

przekazane. 5. Jeśli jest określony termin rozpoczęcia obowiązywania nowych parametrów: w terminie

określonym w żądaniu LE aktywuje nową konfigurację (zaczynają w tym momencie obowiązywać nowe dane).

Zazwyczaj po LPU07 będzie wykonywany LPU13 „Odczyt konfiguracji LE” w celu sprawdzenia, czy nowa konfiguracja została skutecznie zainstalowana w LE. O przeprowadzeniu odczytu decyduje CAZ.

4.3.2.2 LPU08: Konfiguracja KDL

Zakres zmiana

o maksymalnego czasu oczekiwania na odpowiedzi od LE,o czasu koncentratora (wymuszenie synchronizacji czasu z wykorzystaniem protokołu

NTP),o sposobu realizacji odczytów (tryb „push” lub tryb „pull”),o innych parametrów koncentratora.


Synchronizacja czasu KDL z czasem SAK będzie realizowana z wykorzystaniem mechanizmów protokołu NTP. W przypadku braku implementacji tego protokołu w KDL, zostanie zrealizowany alternatywny algorytm.

Diagram sekwencji sd LPU08 Konfiguracja KDL

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

1. DCSetParamRequest()


3. Aktywacja nowych danych()


1. SAK wysyła do KDL żądanie ustawienia określonych wartości parametrów. W żądaniu może być określony termin, od którego nowe parametry mają zacząć obowiązywać.

2. KDL potwierdza realizację żądania (lub jego otrzymanie, jeśli mają zacząć obowiązywać od określonego terminu).

3. Jeśli jest określony termin rozpoczęcia obowiązywania nowych parametrów: W terminie wskazanym przez żądanie KDL aktywuje nową konfigurację.

Zazwyczaj po LPU08 będzie wykonywany LPU11 „Odczyt konfiguracji i danych z KDL” w celu sprawdzenia, czy zmiana konfiguracji była efektywna.

4.3.2.3 LPU09: Definicja subskrypcjiSubskrypcja ma następujące podstawowe atrybuty:

identyfikator, zakres dostarczanych danych, częstotliwość i harmonogram rejestracji danych (z LE do KDL), częstotliwość i harmonogram dostarczania danych (z KDL do SAK), czas rozpoczęcia obowiązywania. czas zakończenia obowiązywania.

Subskrypcja może być przypisana do jednego LE, do wielu LE (multicast) lub do wszystkich LE (broadcast).

ZakresObejmuje:

tworzenie nowej definicji subskrypcji, zmianę definicji subskrypcji, deaktywację subskrypcji, usunięcie subskrypcji.

Realizacja akcji definiowanych przez subskrypcję jest objęta przez LPU12.


Diagram sekwencji sd LPU09 Definicja Subskrybcj i

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

1. DCSubscribeRequest()

2. DAttentionResponse()


1. Nowa subskrypcja jest konfigurowana w SAK, a następnie odpowiednia definicja jest przesyłana do KDL. Konfiguracja może polegać na utworzeniu nowej definicji, zmianie parametrów definicji (np. listy LE, dla których ta definicja obowiązuje), deaktywacji lub usunięciu definicji na stałe.

2. Definicja jest konfigurowana w KDL. KDL potwierdza do SAK skonfigurowanie subskrypcji.

Realizacja subskrypcji jest opisana w przypadku użycia LPU12.

4.3.2.4 LPU20: Synchronizacja / zmiana czasu LE

Zakres synchronizacja czasu LE ustawienie czasu LE.

Diagram sekwencji sd LPU20 Synchronizacja / zmiana czasu LE

CAZ

(from Aktorzy LPU)

SAK

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

1. DCMeterSetParamRequest()

2. Odczyt czasu LE()

2. Czas LE()

3. Wyliczenie uchybu czasu LE względem czasu KDL()


5. Info o większym uchybie niż dopuszczalny()

6. Ustawienie czasu()

7. Potwierdzenie ustawienia czasu()




1. SAK inicjuje synchronizację / zmianę czasu LE.2. KDL odczytuje czas LE.3. KDL wylicza uchyb czasu LE względem czasu KDL.

a. uchyb jest mniejszy lub równy niż zadany dopuszczalny uchyb czasu (parametr KDL). Przejście do punktu 4.

b. uchyb czasu jest większy niż zadany dopuszczalny uchyb czasu. Przejście do punktu 6.

4. KDL informuje SAK o większym uchybie niż dopuszczalny.5. SAK informuje CAZ o większym uchybie niż dopuszczalny.6. KDL ustawia czas LE.7. LE potwierdza ustawienie czasu.8. KDL potwierdza do SAK wykonanie zlecenia synchronizacji / zmiany czasu.

4.3.3 Kategoria OdczytyPoniższy diagram przedstawia mapę Licznikowych Przypadków Użycia w Kategorii Odczyty.

uc Kategoria Odczyt

LPU10 Odczyt rejestrów LE

LPU11 Odczyt danych z KDL

LPU14 Sprawdzenie połączenia z LE

LPU15 Sprawdzenie połączenia z KDL

LPU13 Odczyt konfiguracj i LE

Rysunek 20. LPU w Kategorii Odczyty

4.3.3.1 LPU10: Odczyt danych z LE

Zakres Odczyt danych pomiarowych i danych niepomiarowych.


Diagramy sekwencji sd LPU10 Odczyt rejestrów LE - tryb "push"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterGetDataRequest()


3. Żądanie podania danych()

4. Przekazanie żądanych danych()



5. DCMeterGetDataResponse()


Rysunek 21. Diagram sekwencji dla LPU10 – tryb „push”

1. SAK żąda od KDL zgromadzenia zawartości rejestrów z LE.2. KDL potwierdza otrzymanie żądania.3. KDL generuje odpowiednie żądania do odpowiednich LE.4. LE dostarczają do KDL odpowiednie dane.5. KDL dostarcza zgromadzone dane.6. SAK potwierdza otrzymanie danych.

sd LPU10 Odczyt rejestrów LE - tryb "pull"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterGetDataRequest()









Rysunek 22. Diagram sekwencji dla LPU10 – tryb ”pull”


1. SAK żąda od KDL zgromadzenia zawartości rejestrów z LE.2. KDL potwierdza otrzymanie żądania.3. KDL generuje odpowiednie żądania do odpowiednich LE.4. LE dostarczają do KDL odpowiednie dane.5. SAK żąda dostarczenia danych zgromadzonych przez KDL.6. KDL dostarcza zgromadzone dane.7. SAK potwierdza otrzymanie danych.

4.3.3.2 LPU11: Odczyt konfiguracji i danych z KDL

Zakres przesłanie od SAK do KDL komunikatu z żądaniem przekazania określonych danych:

o konfiguracji,o dzienników zdarzeń,o tabel routingowych,o zgromadzonych danych licznikowych przed terminem ich „normalnego” dostarczenia,

na przykład z powodu konieczności wyłączenia KDL (patrz LPU04) przesłanie od KDL do SAK żądanych danych.

Diagram sekwencji

sd LPU11 Odczyt danych z KDL

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)


2. DCGetParamResponse+DCMeterGetDataResponse()

3. DCAttentionRequest+DCAttentionRequest()


1. SAK przesyła do KDL komunikat z żądaniem podania danych.2. KDL przesyła do SAK odpowiedź zawierającą odpowiednie dane.3. SAK potwierdza otrzymanie danych.

4.3.3.3 LPU13: Odczyt konfiguracji LE

Zakres Odczyt parametrów (konfiguracji) LE:

o kalendarz (strefy),


o ograniczenie mocy,o stan stycznika (wyłączony, załączony, zazbrojony),o czas,o definicja momentów rejestracji danych w profilach/archiwach,o definicja struktury rejestrów złożonych (profile, archiwa),o inne.

Odczyt dziennika zdarzeń.

Diagramy sekwencji sd LPU13 Odczyt konfiguracj i LE - tryb "push"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterGetParamRequest()


3. Żądanie podania konfiguracji()




5. DCMeterGetParamResponse()


Rysunek 24. Diagram sekwencji dla LPU13 – tryb „push”

1. SAK żąda od KDL odczytu parametrów z LE.2. KDL potwierdza otrzymanie żądania.3. KDL generuje odpowiednie żądania do odpowiednich LE.4. LE dostarczają do KDL odpowiednie dane.5. KDL dostarcza zgromadzone dane.6. SAK potwierdza otrzymanie danych.


sd LPU13 Odczyt konfiguracj i LE - tryb "pull"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterGetParamRequest()







6. DCMeterGeParamResponse()


Rysunek 25. Diagram sekwencji dla LPU13 – tryb ”pull”

1. SAK żąda od KDL odczytu parametrów z LE.2. KDL potwierdza otrzymanie żądania.3. KDL generuje odpowiednie żądania do odpowiednich LE.4. LE dostarczają do KDL odpowiednie dane.5. SAK żąda dostarczenia danych zgromadzonych przez KDL.6. KDL dostarcza zgromadzone dane.7. SAK potwierdza otrzymanie danych.

4.3.3.4 LPU14: Sprawdzenie połączenia z LE

Zakres odczyt rejestru numeru seryjnego z LE,

Diagramy sekwencjiDiagram sekwencji podany jest w opisie przypadku LPU10.

4.3.3.5 LPU15: Sprawdzenie połączenia z KDL

Zakres odczyt rejestru numeru identyfikacyjnego z KDL,

Diagram sekwencjiDiagram sekwencji jest podany w opisie przypadku LPU11.

4.3.4 Kategoria SterowaniePoniższy diagram przedstawia mapę Licznikowych Przypadków Użycia w Kategorii Sterowanie.


uc Kategoria Sterowanie

LPU12 Realizacja Subskrybcj i

LPU16 Bezpośrednia komunikacja SAK z LE (tryb przezroczystego

koncentratora)

LPU17 Restart KDL

Rysunek 26. LPU w Kategorii Sterowanie

4.3.4.1 LPU12: Realizacja subskrypcjiSubskrypcja jest to zamówienie na cykliczne wykonywanie pewnych akcji. Mogą one polegać na:

dostarczaniu określonych danych przez LE do SAK, zmianie konfiguracji w LE.

Zakres cykliczną realizację odczytów z LE, cykliczną realizację zmian konfiguracji LE.

Zadania cykliczne, wynikające z definicji subskrypcji są generowane przez KDL. Mogą być wykonywane w trybie „push” lub „pull”.

Diagramy sekwencji sd LPU12 Realizacja Subskrybcj i odczytu w trybie "push"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. Żądanie odczytu danych()

2. Dostarczenie żądanych danych()





Rysunek 27. Diagram sekwencji dla LPU012 – odczyt w trybie „push”

1. Na podstawie definicji subskrypcji KDL generuje żądania odczytu danych i przesyła je do LE.2. LE przesyłają żądane dane.3. KDL przesyła zgromadzone dane do SAK.


4. SAK potwierdza otrzymanie danych.

sd LPU12 Realizacja Subskrybcj i odczytu w trybie "pull"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)








Rysunek 28. Diagram sekwencji dla LPU012 – odczyt w trybie „pull”

1. Na podstawie definicji subskrypcji KDL generuje żądania odczytu danych i przesyła je do LE.2. LE przesyłają żądane dane.3. SAK żąda dostarczenia zgromadzonych danych.4. KDL przesyła zgromadzone dane do SAK.5. SAK potwierdza otrzymanie danych.

sd LPU12 Realizacja Subskrybcj i zmiany konfiguracj i LE w trybie "push"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)


2. Potwierdzenie zmiany konfiguracji()





Rysunek 29. Diagram sekwencji dla LPU012 – zmiana danych w trybie „push”

1. Na podstawie definicji subskrypcji KDL generuje żądania zmiany konfiguracji i przesyła je do LE.

2. LE potwierdzają zmianę konfiguracji.


3. KDL przesyła potwierdzenie realizacji zmiany konfiguracji do SAK.4. SAK potwierdza otrzymanie potwierdzenia (w celu domknięcia logicznej transakcji

zainicjowanej przez KDL).

sd LPU12 Realizacja Subskrybcj i zmiany konfiguracj i LE w trybie "pull"

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)








Rysunek 30. Diagram sekwencji dla LPU012 – odczyt w trybie „pull”

1. Na podstawie definicji subskrypcji KDL generuje żądania zmiany konfiguracji i przesyła je do LE.

2. LE potwierdzają zmianę konfiguracji.3. SAK żąda od KDL potwierdzenia zmiany konfiguracji przez LE.4. KDL przesyła potwierdzenie realizacji zmiany konfiguracji do SAK.5. SAK potwierdza otrzymanie potwierdzenia (w celu domknięcia logicznej transakcji

zainicjowanej przez KDL).

4.3.4.2 LPU16: Bezpośrednia komunikacja z LE (tryb przezroczystego koncentratora)Jednym z wymagań na język DCSML jest możliwość przesyłania do LE komunikatów w trybie przezroczystego koncentratora. Oznacza to, że musi istnieć możliwość sformułowania przez SAK polecenia w takiej postaci, która nie będzie interpretowana przez KDL, natomiast będzie zrozumiała dla LE. Polecenie takie jest przez KDL dekapsułowane, a następnie przesyłane do LE. I na odwrót: odpowiedzi uzyskiwane od LE są przez KDL enkapsulowane w DCSML i przekazywane do SAK.

Zakres przesłanie przez SAK do KDL komunikatu, który może być adresowany do jednego, wielu

lub wszystkich LE, dekapsulacja komunikatu przez KDL i rozesłanie go do LE, zebranie odpowiedzi od LE przez KDL, enkapsulacja i odesłanie ich do SAK.


Diagram sekwencji sd LPU16 Bezpośrednia komunikacja SAK z LE (tryb przezroczystego koncentratora)

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

LE2

(from Aktorzy LPU)

LEn

(from Aktorzy LPU)

1. DCMeterTransparentRequest()


3. Dekapsulacja DLMS z DCSML()

4. Wysłanie DLMS()

5. Odesłanie odpowiedzi w DLMS()

4. Wysłanie DLMS()

5. Odesłanie odpowiedzi w DLMS()

6. Kapsulacja DLMS w DCSML()

7. DCMeterTransparentResponse()


Rysunek 31: Diagram sekwencji dla LPU016

1. SAK przekazuje do KDL polecenie w formie APDU DLMS opakowane w DCSML.2. KDL potwierdza otrzymanie polecenia.3. KDL dokonuje dekapsulacji z DCSML polecenie sformułowane w APDU DLMS.4. KDL wysyła do LE zdekapsułowane polecenie.5. LE odpowiadają do KDL w formie APDU DLMS.6. KDL dokonuje enkapsulacji odpowiedzi w DCSML7. KDL przekazuje do SAK odpowiedzi zenkapsułowane w DCSML.8. SAK potwierdza otrzymanie danych.

4.3.4.3 LPU17: Restart KDL

Zakres restart KDL wymuszony przez SAK.

Diagram sekwencjiRestart wykonywany jest z inicjatywy SAK. Restart odbywa się poprzez ustawienie odpowiednich parametrów w KDL, które powodują restart natychmiastowy lub w określonym terminie.


sd LPU17 Restart KDL

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

1. DCSetParamRequest()


3. Restart()



1. SAK przesyła do KDL komunikat z żądaniem wykonania restartu.2. KDL potwierdza otrzymanie komunikatu.3. Następuje restart KDL.4. KDL zgłasza wykonanie restartu do SAK.

4.3.5 Kategoria ZgłoszeniePoniższy diagram przedstawia mapę Licznikowych Przypadków Użycia w Kategorii Zgłoszenie.

uc Kategoria Zgłoszenie

LPU18 Zgłoszenie alarmu przez LE

LPU19 Zgłoszenie alarmu przez KDL

Rysunek 33. LPU w Kategorii Zgłoszenie

4.3.5.1 LPU18: Zgłoszenie alarmu przez LE

Zakres zgłoszenie alarmu przez LE .


Diagram sekwencji sd LPU18 Zgłoszenie alarmu przez LE

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)

1. Zgłoszenie alarmu()




1. LE zgłasza alarm do KDL.2. KDL zgłasza do SAK alarm od LE.3. SAK potwierdza otrzymanie alarmu.

4.3.5.2 LPU19: Zgłoszenie alarmu przez KDL

Zakres zgłoszenie alarmu przez KDL.

Diagram sekwencji sd LPU19 Zgłoszenie alarmu przez KDL

SAK

(from Aktorzy LPU)

KDL

(from Aktorzy LPU)

LE1

(from Aktorzy LPU)




1. KDL zgłasza alarm do SAK.2. SAK potwierdza otrzymanie alarmu.


5 Protokół komunikacyjny DCSMLProtokół komunikacyjny DCSML powstał jako rozszerzenie funkcjonalności protokołu (języka) SML. W celu zapewnienia komunikacji z koncentratorami danych (KDL) zdefiniowany został zestaw dodatkowych funkcji zapewniających współpracę SAK z KDL.

DCSML jest stosowany do komunikacji pomiędzy SAK a KDL. Jednocześnie jest medium umożliwiającym transport struktur protokołu DLMS/COSEM, co umożliwia:

przesyłanie danych odczytanych z obiektów COSEM w LE do SAK,

w razie potrzeby enkapsulację poleceń DLMS/COSEM na poziomie SAK w celu przekazania ich przez KDL wprost do LE (komenda DCMeterTransparent).

5.1 Opis KomunikatówNa podstawie analizy przekazywanych poleceń i danych opracowano listę komunikatów DCSML, którą prezentuje poniższa tabela.

Tabela 4. Lista komunikatów DCSML

Komunikat ZnaczenieDCAttentionRequest Przekazanie informacji, żądania, itp. Typowym zastosowaniem jest żądanie

odczytu zgromadzonych danych w trybie "pull". Także potwierdzenie otrzymania informacji.

DCAttentionResponse Zgłoszenie alarmu, potwierdzenie odbioru danych lub wykonania żądania, odpowiedź na DCAttentionRequest.

DCFirmwareRequest Żądanie aktualizacji oprogramowania w KDL.DCGetParamRequest Żądanie odczytu konfiguracji i/lub zgromadzonych danych licznikowych z KDL.DCGetParamResponse Odpowiedź z danymi konfiguracyjnymi KDL.DCMeterAttentionResponse Potwierdzenie odbioru danych lub wykonania żądania przez poszczególne LE.DCMeterFirmwareRequest Żądanie aktualizacji oprogramowania w LE.DCMeterGetDataRequest Żądanie odczytu danych z LE.DCMeterGetDataResponse Odpowiedź z danymi odczytanymi z LE.DCMeterGetParamRequest Żądanie odczytu konfiguracji z LE.DCMeterGetParamResponse Odpowiedź z danymi konfiguracyjnymi LE.DCMeterSetParamRequest Żądanie zmiany konfiguracji LE.DCMeterTransparentRequest Żądanie przesłania do LE danych w formie APDU DLMS.DCMeterTransparentResponse Odpowiedź z danymi LE w formie APDU DLMS.DCSetParamRequest Żądanie zmiany konfiguracji KDL.DCSubscribeRequest Żądanie utworzenia, zmiany, usunięcia lub deaktywacji definicji subskrypcji.

Lista komunikatów została podana w Załączniku nr 2 w Arkuszu „DCSML”. W Arkuszu „LPU” poszczególne LPU zostały powiązane z komunikatami DCSML, jakie będą wykorzystywane do ich realizacji.W Arkuszu „LPU<=>DCSML” przedstawiono macierz powiązań pomiędzy LPU a komunikatami DCSML.

5.2 Gramatyka Protokołu


Ze względu na wymaganie dotyczące możliwości współpracy koncentratorów z licznikami różnych producentów przyjęto założenie, że stosowane liczniki będą zgodne z modelem COSEM. Oznacza to, że w fizycznym urządzeniu zamodelowane są urządzenia logiczne, w których z kolei są zdefiniowane obiekty COSEM. Każdy obiekt należy do określonej klasy interfejsowej i jest identyfikowany poprzez kod OBIS.

Do komunikacji z licznikami COSEM stosuje się protokół DLMS/COSEM. Jest on przygotowany na rejestrowanie i przesyłanie wszystkich danych identyfikowanych kodami OBIS, a więc wszystkich danych podlegających rejestracji w licznikach energii elektrycznej.

Z tego względu implementacja protokołu DCSML umożliwia następujące operacje warstwy aplikacji:

Tworzenie w LE obiektów COSEM na podstawie klas interfejsowych zdefiniowanych w LE, usuwanie tych obiektów.

Wykonywanie na obiektach COSEM operacji typu:o GET – pobranie wartości atrybutu obiektu COSEM, np. profilu dobowego wartości

rejestrowanych co 15 minut, aktualnej wartości napięcia, itp.,o PUT – ustawienie wartości atrybutu obiektu COSEM, np. taryf licznikowych,

stosowanego kalendarza, itp.,o ACTION – uruchomienie metody zdefiniowanej w obiekcie COSEM.

Parametry i rezultaty tych operacji są również enkapsulowane w komunikatach DCSML w celu przekazania między KDL a SAK.

5.2.1 Podstawowe definicje struktur danych SML

Koncepcja gramatyki składni protokołu DCSML bazuje na rozwiązaniach użytych w protokole SML. DCSML stanowi rozszerzenie protokołu SML o dodatkowe funkcje. Funkcje protokołu SML będą mogły być wykorzystywane na równi z funkcjami protokołu DCSML. Dlatego w opisie gramatyki protokołu DCSML stosujemy podstawowe struktury (typy) danych takie same, jak w oryginalnym protokole SML. Dotyczy to następującego zakresu definicji podstawowych struktur danych SML:

OctetString Integer8 Integer16 Integer32 Integer64 Unsigned8 Unsigned16 Unsigned32 Unsigned64 Boolean List of … EndOfSmlMessage SML_Time SML_TimeStamp SML_Value SML_ValueEntry SML_Unit SML_Message SML_TreePath SML_Tree


List_of_SML_Tree List_of_SML_ObjReqEntry SML_ObjReqEntry List_of_SML_ProfObjHeaderEntry List_of_SML_ProfObjPeriodEntry List_of_SML_ValueEntry SML_ProfObjHeaderEntry SML_ProfObjPeriodEntry

Opis gramatyki protokołu DCSML przedstawiono w takiej samej notacji, jaka została zastosowana w opisie SML (dokument: SML Smart Message Language Version1.03). W opisie użyto następujących cech definiujących metodę postępowania i interpretacji struktur elementów ujętych w klamry:

CHOICE – oznacza możliwość wyboru jednego i tylko jednego elementu ujętego w klamrach. Element musi posiadać swój indywidualny kod - pole TL definiujące, jakiego typu jest dany element (wszystkie dostępne podstawowe typy danych mają przyznany niepowtarzalny kod TL (pole TL-Field),

SEQUENCE – oznacza, że użyte mają być wszystkie elementy struktury ujęte w klamrach, SEQUENCE OF – oznacza nieograniczoną listę powtarzających się elementów ujętych

w klamrach, OPTIONAL – oznacza, że element wskazany przez tą właściwość nie musi być użyty w

strukturze.

Wszystkie podstawowe typy danych stosowane w SML posiadają zdefiniowane jednoznacznie pole typu TL-Field Pole TL-Field ma rozmiar 1 bajtu (8 bitow). W polu tym zakodowany jest typ danej oraz jej długość wyrażona w liczbie bajtów. W polu TL-Field 4 bardziej znaczące bity kodują typ danej, natomiast 4 mniej znaczące bity kodują informację o rozmiarze danej przedstawionym w bajtach. Pole TL-Field skonstruowane jest w ten sposób, że jeżeli rozmiar danych opisywanych przez pole TL-Field jest większy niż 14 bajtów, wówczas najbardziej znaczący bit ustawiany jest na 1 i oznacza on, że kolejny bajt za polem TL-Field przenosi dodatkową informację o długości danych. W przypadku kiedy użyte są dodatkowe bajty pola TL-Field, 4 bity pierwszego bajtu określające długość pola danych powinny być przesunięte w lewo o 4 i na prawo dodać 4 bity z kolejnego bajtu pola TL-Field. W ten sposób na 2 bajtach pola TL-Field można zakodować maksymalnie długość pola danych równą 254.

Kodowanie pola TL-Field (pierwszy bajt)

Tabela 5. Znaczenie bitów pierwszego bajtu w polu TL-Field

Index bitów MSBb7 6 5 4 3 2 1

LSBb0

Kolejny bajt jest przedłużonym polem TL-Field 1 X X X X X X X

Kolejny bajt jest wartością danej 0 X X X X X X X

Kodowanie typu danych Octet String X 0 0 0 L L L L

Kodowanie typu danych Boolean 0 1 0 0 L L L L

Kodowanie typu danych Integer X 1 0 1 L L L L

Kodowanie typu danych Unsigned X 1 1 0 L L L L



LSBb0

Kodowanie typu danych List of … X 1 1 1 L L L L

Kolejny bajt pozwala na zdefiniowanie dodatkowych typów danych - zarezerwowane

1 1 0 0 L L L L

Zarezerwowane na przyszlość X 0 0 1 L L L L

Zarezerwowane na przyszłość X 0 1 0 L L L L


X – bit nie znaczący (dowolna wartość bitu)L – bity długości danych (długość w bajtach)

Kodowanie pola TL-Filed (każdy kolejny bajt)

Tabela 6. Znaczenie bitów kolejnych bajtów w polu TL-Field


LSBb0

Kolejny bajt jest przedłużonym polem TL-Field 1 X X X X X X X

Kolejny bajt jest wartością danej 0 X X X X X X X

4 bity użyte jako długość danych X 0 0 0 L L L L




Zarezerwowane na przyszłość X 1 X X L L L L

5.2.1.1 OctetStringOctetString ::= SEQUENCE{

TL-Field 0x0z (‘z’ = liczba bajtów danych)dataValue 0xAA..0xNN (0xAA – najstarszy bajt,

0xNN – najmłodszy bajt)}

5.2.1.2 Integer8Integer8 ::= SEQUENCE{

TL-Field 0x52dataValue 0xYY

}


TL-Field 0x53dataValue 0xAA 0xBB (0xAA – najstarszy bajt,


0xBB – najmłodszy bajt,Format: Big Endian)

}


TL-Field 0x55dataValue 0xAA 0xBB

0xCC 0xDD (0xAA – najstarszy bajt,0xDD – najmłodszy bajt,Format: Big Endian)

}


TL-Field 0x59dataValue 0xAA..0xHH 0xAA – najstarszy bajt,

0xHH – najmłodszy bajt,Format: Big Endian)

}

5.2.1.6 Unsigned8Unsigned8 ::= SEQUENCE{

TL-Field 0x62dataValue 0xYY

}


TL-Field 0x63dataValue 0xAA 0xBB (0xAA – najstarszy bajt,

0xBB – najmłodszy bajt,Format: Big Endian)

}


TL-Field 0x65dataValue 0xAA 0xBB

0xCC 0xDD (0xAA – najstarszy bajt,0xDD – najmłodszy bajt,Format: Big Endian)

}


TL-Field 0x59dataValue 0xAA..0xHH 0xAA – najstarszy bajt,


0xHH – najmłodszy bajt,Format: Big Endian)

}

5.2.1.10 BooleanBoolean ::= SEQUENCE{

TL-Field 0x42dataValue 0xAA (0x00 = ‘false’

inna wartość = ‘true’)}

5.2.1.11 List of …List of… ::= SEQUENCE{

TL-Field 0x7z (‘z’ = liczba elementów)}

5.2.1.12 EndOfSmlMessageEndOfSmlMessage ::= 0x00 (0x00 = brak pola TL-Field

= koniec)

5.2.1.13 SML_TimeSML_Time ::= CHOICE{

secIndex 0x01 Unsigned32timestamp 0x02 SML_Timestamp

}

secIndex Czas w sekundach, zliczona liczba sekund

timestamp SML_Timestamp (w sekundach)

5.2.1.14 SML_TimeStampPodstawą czasu SML_TimeStamp jest sekunda. SML_TimeStamp liczony jest od czasu 01.01.1970 00:00:00 (czas referencyjny systemów UNIX).

SML_TimeStamp ::= Unsigned32

5.2.1.15 SML_ValueSML_Value ::= IMPLICIT CHOICE{

Boolean-Value BooleanByte-List OctetString8-Bit-Integer Integer816-Bit-Integer Integer1632-Bit-Integer Integer3264-Bit-Integer Integer648-Bit-Unsigned Unsigned816-Bit-Unsigned Unsigned1632-Bit-Unsigned Unsigned3264-Bit-Unsigned Unsigned64

}


5.2.1.16 SML_ValueEntrySML_ValueEntry ::= SEQUENCE{

value SML_ValuevalueSignature SML_Signature OPTIONAL

}

5.2.1.17 SML_SignatureSygnatura służy do ustawienia podpisu profilu, parametru lub wartości. Sygnatury zależą od indywidualnej implementacji systemów.

SML_Signature OctetString

5.2.1.18 SML_UnitTabela wartości numerycznych przypisanych poszczególnym jednostkom fizycznym znajduje się w dokumentach opisujących DLMS (PN-EN 62056-62).

SML_Unit ::= Unsigned8

5.2.1.19 SML_Message

Podstawowa struktura wiadomości SML służy za razem do przesyłania zapytań i odpowiedzi w procesie komunikacji po protokole SML.

SML_Message ::= SEQUENCE{

transactionID OctetStringgroupID Unsigned8abortOnError Unsigned8messageBody SML_MessageBodycrc16 Unsigned16endOfSmlMsg EndOfSmlMsg

}

5.2.1.20 SML_TreePathSML_TreePath ::= SEQUENCE OF{

Path_Entry OctetString}

5.2.1.21 SML_TreeSML_Tree pozwala uzyskać rożne informacje o parametrach. Dzięki strukturze drzewa i polu child_list możemy uzyskać informacje o:

pojedynczym parametrze, parametrze wraz z listą parametrów zależnych, parametrze wraz z listą drzew parametrów zależnych.

Nazwa parametru jest odpowiednim kodem OBIS.

SML_Tree ::= SEQUENCE{

parameterName OctetString


parameterValue SML_ProcParValue OPTIONALchild_list List_of_SML_Tree OPTIONAL

}

5.2.1.22 List_of_SML_TreeList_of_SML_Tree ::= SEQUENCE OF{

tree_Entry SML_Tree}

5.2.1.23 List_of_SML_ObjReqEntryList_of_SML_ObjReqEntry ::= SEQUENCE OF{

object_List_Entry SML_ObjReqEntry}

5.2.1.24 SML_ObjReqEntryNazwa parametru, którego wartość ma zostać odczytana (kod OBIS).

SML_ObjReqEntry ::= OctetString

5.2.1.25 List_of_SML_ProfObjHeaderEntryList_of_SML_ProfObjHeaderEntry ::= SEQUENCE OF{

Header_List_Entry SML_ProfObjHeaderEntry}

5.2.1.26 List_of_SML_ProfObjPeriodEntryList_of_SML_ProfObjPeriodEntry ::= SEQUENCE OF{

Period_List_Entry SML_ProfObjPeriodEntry}

5.2.1.27 List_of_SML_ValueEntryList_of_SML_ValueEntry ::= SEQUENCE OF{

Value_List_Entry SML_ValueEntry}

5.2.1.28 SML_ProfObjHeaderEntryStruktura opisuje właściwości pojedynczego parametru, którego wartość lub zestaw wartości odczytujemy. Informacje zawarte w SML_ProfObjHeaderEntry są statyczne dla określonego parametru o nazwie objName.

SML_ProfObjHeaderEntry ::= SEQUENCE{

objName OctetStringunit SML_Unitscaler Integer8

}

5.2.1.29 SML_ProfObjPeriodEntryStruktura sluży do zwrucenia zestawu wartości parametrów określonych w liście List_of_SML_ProfObjHeaderEntry w powiązaniu ze wskazaną wartością czasu LE, w której


zmierzone zostały te dane. Zestawowi danych z określonego czasu LE przypisać może sygnaturę zgodności (podpis) danych.

SML_ProfObjPeriodEntry ::= SEQUENCE{

valTime SML_Timestatus Unsigned64value_List List_of_SML_ValueEntryperiodSignature SML_Signature OPTIONAL

}

5.2.1.30 SML_MessageBody

Definicja składni SML_MessageBody została rozszerzona o dodatkowe rodzaje struktur wiadomości. W definicji SML_MessageBody pozostawione zostały dotychczasowe rodzaje struktur zdefiniowanych w SML (identyfikatory od 0x00000100 do 0x0000FF01).

SML_MessageBody ::= CHOICE{

OpenRequest [0x00000100] SML_PublicOpen.ReqOpenResponse [0x00000101] SML_PublicOpen.ResCloseRequest [0x00000200] SML_PublicClose.ReqCloseResponse [0x00000201] SML_PublicClose.ResGetProfilePackRequest [0x00000300] SML_GetProfilePack.ReqGetProfilePackResponse [0x00000301] SML_GetProfilePack.ResGetProfileListRequest [0x00000400] SML_GetProfileList.ReqGetProfileListResponse [0x00000401] SML_GetProfileList.ResGetProcParameterRequest [0x00000500] SML_GetProcParameter.ReqGetProcParameterResponse [0x00000501] SML_GetProcParameter.ResSetProcParameterRequest [0x00000600] SML_SetProcParameter.ReqSetProcParameterResponse [0x00000601] SML_SetProcParameter.ResAttentionResponse [0x0000FF01] SML_Attention.ResDCFirmwareRequest [0x10000300] DCFirmware.ReqDCGetParamRequest [0x10000400] DCGetParam.ReqDCGetParamResponse [0x10000401] DCGetParam.ResDCSetParamRequest [0x10000500] DCSetParam.ReqDCSubscribeRequest [0x10000600] DCSubscribe.ReqDCAttentionRequest [0x10000700] DCAttention.ReqDCAttentionResponse [0x10000701] DCAttention.ResDCMeterGetDataRequest [0x10000800] DCMeterGetData.ReqDCMeterGetDataResponse [0x10000801] DCMeterGetData.ResDCMeterGetParamRequest [0x10000900] DCMeterGetParam.ReqDCMeterGetParamResponse [0x10000901] DCMeterGetParam.ResDCMeterSetParamRequest [0x10001000] DCMeterSetParam.ReqDCMeterTransparentRequest [0x10001100] DCMeterTransparent.ReqDCMeterTransparentResponse[0x10001101] DCMeterTransparent.ResDCMeterFirmwareRequest [0x10001200] DCMeterFirmware.ReqDCMeterAttentionResponse [0x10001301] DCMeterAttention.Res

}

5.2.2 Podstawowe struktury danych DCSMLPodstawowe struktury danych DCSML wraz z podstawowymi strukturami gramatyki protokołu SML stanowią bazę opisującą wszystkie konstrukcje gramatyczne zapytań i odpowiedzi DCSML.


5.2.2.1 List_of_DCSML_ServerID

Struktura listy ID serwerów danych (LE).

List_of_DCSML_ServerID ::= SEQUENCE OF{

serverID OctetString{

serverID ID serwera danych (LE).

5.2.2.2 DCSML_ServerIDData

Zestaw zwróconych danych dla określonego LE.

DCSML_ServerIDData ::= SEQUENCE{

serverID OctetStringheader_List List_of_SML_ProfObjHeaderEntryperiod_List List_of_SML_ProfObjPeriodEntry

}


header_List Lista nagłówków opisujących parametr (standardowa struktura SML).

period_List Lista wartości parametru (standardowa struktura SML).

5.2.2.3 List_of_DCSML_ServerIDData

Lista struktur DCSML_ServerIDData.

List_of_DCSML_ServerIDData ::= SEQUENCE OF{

serverIDAnswers DCSML_ServerIDData}

5.2.2.4 DCSML_ServerIDParams

Zestaw informacji niezbędnych do zapisania określonych parametrów ze wskazanego licznika.

DCSML_ServerIDParams ::= SEQUENCE{

serverID OctetStringparameterTree SML_Tree

}


parameterTree Drzewo parametrów LE wraz z ich wartościami.

5.2.2.5 List_of_DCSML_ServerIDParamsLista struktur DCSML_ServerIDParams.

List_of_DCSML_ServerIDParams ::= SEQUENCE OF{

serverParams DCSML_ServerIDParams


}

5.2.2.6 DCSML_MeterAttention

Komunikat typu attention z pojedynczego LE.

DCSML_MeterAttention ::= SEQUENCE{

serverID OctetStringattentionNo OctetStringattentionDetails SML_Tree OPTIONAL

}


attentionNo Kod komunikatu przekazywanego przez ten komunikat.

attentionDetails Struktura umożliwiająca przeniesienie dodatkowych atrybutów, które są w danym przypadku wymagane.

5.2.2.7 List_of_DCSML_MeterAttention

Lista komunikatów DCSML_MeterAttention dla określonej grupy (wielu) LE.

List_of_DCSML_MeterAttention ::= SEQUENCE OF{

meterStatus DCSML_MeterAttention}

5.2.2.8 DCSML_CycleTimeDCSML_ReadCycleTime ::= CHOICE{

cycle 0x01 SML Timedayofmonth 0x02 Unsigned8

}

5.2.2.9 DCSML_IndexTimeDCSML_IndexTime ::= CHOICE{

time 0x01 SML Timeindex 0x02 Unsigned16

}

5.2.3 Funkcje DCSML – związane z obsługą koncentratora

5.2.3.1 DCFirmwareDCFirmware.Req ::= SEQUENCE{

priority Unsigned8startTime SML_Time


rawData Octet String}

priority Priorytet zadania.

startTime Data kiedy KDL ma dokonać przeładowania firmware.

rawData Dane surowe – pakiet danych zawierający firmware dla KDL.

5.2.3.2 DCGetParamDCGetParam.Req ::= SEQUENCE{

priority Unsigned8parameterTreePath SML_TreePath

}DCGetParam.Res ::= SEQUENCE{

parameterTreePath SML_TreePathparameterTree SML_Tree

}


parameterTreePath Drzewo parametrów KDL.

parameterTree Drzewo parametrów wraz z ich wartościami.

5.2.3.3 DCSetParamDCSetParam.Req ::= SEQUENCE{

priority Unsigned8function Unsigned8startTime SML_Time OPTIONALparameterTreePath SML_TreePathparameterTree SML_Tree

}


function Kod określający, jakie czynności mają zostać wykonane: np. stworzenie i konfiguracja nowego obiektu, zmiana wartości parametrów, usunięcie obiektu (kodowanie na bitach, co oznacza, że możliwe jest wydanie kilku poleceń za pomocą pojedynczej komendy).

startTime Data określająca czas, kiedy KDL ma dokonać zmiany ustawień.

parameterTreePath Identyfikatory parametrów KDL do ustawienia.

parameterTree Wartości parametrów KDL do ustawienia.


5.2.3.4 DCSubscribeDCSubscribe.Req ::= SEQUENCE{

priority Unsigned8listserverID List_of_DCSML_ServerIDsubscribeID Octet Stringfunction Unsigned8beginTime SML_Time OPTIONALendTime SML_Time OPTIONALreadCycleTime DCSML_CycleTimesendCycleTime DCSML_CycleTime OPTIONALdataTreePath SML_TreePath OPTIONALdataTree SML_Tree OPTIONAL

}

priority Priorytet zadania

listserverID Lista serwerów danych (LE), dla których ma zostać utworzona, zmieniona, zdeaktywowana lub usunięta subskrypcja.

subscribeID Identyfikator subskrypcji.

Function Kod określający, jakie czynności mają zostać wykonane ne definicji subskrypcji.

beginTime Czas początkowy okresu, który ma obejmować subskrypcja (początek subskrybowania); jeżeli parametr nie jest podany, koncentrator ma rozpocząć realizację subskrypcji od momentu otrzymania zlecenia.

endTime Czas końcowy okresu, który ma obejmować subskrypcja (koniec subskrypcji); jeżeli parametr nie jest podany, wówczas koncentrator ma prowadzić subskrypcję aż do jej odwołania lub deaktywacji.

readCycleTime Parametr do wyboru: cykl wykonywania subskrypcji (przedział czasu w minutach albo określony dzień miesiąca).

SendCycleTime Parametr do wyboru: cykl wysyłania zebranych (przedział czasu w minutach albo określony dzień miesiąca). Jeżeli parametr nie występuje, wówczas dane zostaną wysłane od razu po ich zgromadzeniu.

dataTreePath Identyfikatory konfigurowanych parametrów LE lub subskrybowanych danych.

dataTree Wartości parametrów LE przeznaczonych do ustawiania w subskrypcji.

5.2.3.5 DCAttentionDCAttention.Req ::= SEQUENCE{

priority Unsigned8attentionNo OctetStringattentionDetails SML_Tree OPTIONAL

}


DCAttention.Res ::= SEQUENCE{

priority Unsigned8attentionNo OctetStringattentionDetails SML_Tree OPTIONAL

}


attentionNo Kod komunikatu przekazywanego przez ten komunikat DCAttention.

attentionDetails Struktura umożliwiająca przeniesienie dodatkowych atrybutów, które są w danym przypadku wymagane.

5.2.4 Funkcje DCSML – związane z obsługą licznika

5.2.4.1 DCMeterGetDataDCMeterGetData.Req ::= SEQUENCE{

priority Unsigned8subscribeID Octet String OPTIONALlistserverID List_of_DCSML_ServerIDbeginindextime DCSML_IndexTimeendindextime DCSML_IndexTimeparameterTreePath SML_TreePath OPTIONAL

}DCMeterGetData.Res ::= SEQUENCE{

subscribeID Octet String OPTIONALparameterTreePath SML_TreePathlistserverIDData List_of_DCSML_ServerIDData

}


subscribeID ID subskrypcji (parametr opcjonalny).

listserverID Lista serwerów danych (LE).

beginindextime Czas początkowy okresu, o który pytamy lub index początkowy danych.

endindextime Czas końcowy okresu, o który pytamy lub index końcowy danych.

parameterTreePath Drzewo parametrów LE.

listserverIDData Lista odpowiedzi z danymi od serwerów (LE).

5.2.4.2 DCMeterGetParamDCMeterGetParam.Req ::= SEQUENCE{

priority Unsigned8listserverID List_of_DCSML_ServerIDparameterTreePath SML_TreePath

}


DCMeterGetParam.Res ::= SEQUENCE{

parameterTreePath SML_TreePathlistserverIDParams List_of_DCSML_ServerIDParams

}



listserverIDParams Lista odpowiedzi z parametrami od serwerów (LE).

5.2.4.3 DCMeterSetParamDCMeterSetParam.Req ::= SEQUENCE{

priority Unsigned8function Unsigned8startTime SML_Time OPTIONALparameterTreePath SML_TreePathlistserverParams List_of_DCSML_ServerIDParams

}


function Kod określający, jakie czynności mają zostać wykonane: stworzenie i konfiguracja nowego obiektu COSEM, zmiana wartości parametrów, usunięcie obiektu COSEM; wywołanie akcji (kodowanie na bitach, co oznacza, że możliwe jest wydanie kilku poleceń za pomocą pojedynczej komendy).

startTime Data, kiedy LE mają dokonać zmiany ustawień. Jeżeli parametr nie jest ustawiony, wówczas przełączenie parametrów następuje natychmiast.


listserverParams Lista LE wraz z listą parametrów odczytanych z LE.

5.2.4.4 DCMeterTransparentDCMeterTransparent.Req ::= SEQUENCE{

priority Unsigned8serverID Octet StringrawData Octet String

}DCMeterTransparent.Res ::= SEQUENCE{

serverID Octet StringrawData Octet String

}




rawData Dane surowe – pakiet danych do wysłania do LE (lub odpowiedź z LE) w formacie APDU DLMS.

5.2.4.5 DCMeterFirmwareDCMeterFirmware.Req ::= SEQUENCE{

priority Unsigned8listserverID List_of_DCSML_ServerIDstartTime SML_TimerawData Octet String

}



startTime Data określająca, kiedy LE ma dokonać przeładowania firmware.

rawData Dane surowe – pakiet danych zawierający firmware dla LE.

meterList Lista struktury opisującej status wymiany firmware LE.

5.2.4.6 DCMeterAttentionResponseDCMeterAttention.Res ::= SEQUENCE{

attentionID List_of_DCSML_MeterAttention}

attentionID Lista komunikatów z wielu liczników LE


6 Przykłady zapytań i odpowiedzi w DCSML (w postaci APDU i źródłowej)

Niniejszy rozdział prezentuje przykładowe dane testowe użyte w przeprowadzonych testach oraz wynikowe APDU. Wszystkie przykłady dotyczą języka DCSML.

Zaprezentowane w tym załączniku przykłady APDU zostały wygenerowane przy użyciu narzędzia napisanego w języku Java. Narzędzie działa w ten sposób, że na podstawie definicji w ASN.1 konstruowane są w aplikacji obiekty dla poszczególnych APDU, i wypełniane danymi. Następnie generowane jest plik z APDU. Zbudowane w oparciu o ogólnie dostępną bibliotekę freeware narzędzie opisano w dokumencie P.1.4. w punkcie 7.4.

Poniżej przedstawione APDU zostały wygenerowane dla 1 i 5 liczników w następujących sytuacjach (x oznacza liczbę liczników):

1. Zapytanie o pojedynczą wartość i jej odczytanie (dalej oznaczamy x-1-1).2. Zapytanie o profil z jedną wartością (kolumną) i odczytanie 15minutowego profilu

jednogodzinnego (4 odczyty rejestrowane co 15 minut) (dalej oznaczamy x-1-4).3. Zapytanie o 5 wartości i ich odczytanie (dalej oznaczamy x-5-1).4. Zapytanie o profil z 5 wartościami (kolumnami) i odczytanie 15minutowego profilu

jednogodzinnego (4 odczyty rejestrowane co 15 minut) (dalej oznaczamy x-5-4).

W dokumencie zamieszczono następujące przykłady:

1. Zawartość pliku definicji ASN.1, której użyto do wygenerowania przykładów zawartych w niniejszym dokumencie.

2. Dokumentacja poszczególnych wymienionych wyżej przypadków dla 1 i 5 liczników.a. APDU zapytania w postaci szesnastkowej oraz – dla ułatwienia analizy – w postaci

nawiasowej.b. APDU odpowiedzi w postaci szesnastkowej oraz nawiasowej.c. Dla ułatwienia analizy w postaci nawiasowej przekodowano liczby (czas i dane) do

postaci szesnastkowej.

Należy zaznaczyć, że użyte narzędzia oferują kodowanie do postaci standardowego formatu BER. W standardzie SML używane jest kodowanie BER nieco zoptymalizowane – w przypadkach, gdy jest to możliwe, Type i Length są kodowane na pojedynczym bajcie. Daje to potencjalne dodatkowe możliwości zmniejszenia rozmiaru pliku APDU.

6.1 Definicja ASN.1Poniżej przedstawiono definicję gramatyki, jakiej użyto do wygenerowania zamieszczonych dalej przykładów. Definicja jest zapisana w notacji ASN.1.

DCSMLTest DEFINITIONS AUTOMATIC TAGS ::= BEGIN

INTEGER8 ::= INTEGER (-128..127)UNSIGNED8 ::= INTEGER (0..255)UNSIGNED16 ::= INTEGER (0..65535)UNSIGNED32 ::= INTEGER (0..4294967295)UNSIGNED64 ::= UNSIGNED32


SMLPublicOpen-Req ::= SEQUENCE{

clientId OCTET STRING,serverId OCTET STRING OPTIONAL

}

SMLPublicOpen-Res ::= SEQUENCE{

clientId OCTET STRING,serverId OCTET STRING OPTIONAL

}

DCMeterGetData-Req ::= SEQUENCE{

listserverID List-of-DCSML-ServerID,subscribeID OCTET STRING OPTIONAL,questionID UNSIGNED32,answerID UNSIGNED16,beginTime UNSIGNED32 OPTIONAL,endTime UNSIGNED32 OPTIONAL,parameterTreePath SMLTreePath

}

DCMeterGetData-Res ::= SEQUENCE{

subscribeID OCTET STRING OPTIONAL,questionID UNSIGNED32,answerID UNSIGNED16,parameterTreePath SMLTreePath,listserverIDAnswers List-of-DCSML-ServerIDAnswers

}

SMLPublicClose-Req ::= SEQUENCE{

globalSignature SMLSignature OPTIONAL}

SMLPublicClose-Res ::= SEQUENCE{

globalSignature SMLSignature OPTIONAL}

SMLTreePath ::= SEQUENCE OF OCTET STRING

ListOfSMLHeader ::= SEQUENCE OF SMLHeaderEntry

ListOfSMLPeriod ::= SEQUENCE OF SMLProfObjPeriodEntry

SMLProfObjPeriodEntry ::= SEQUENCE

{valTime UNSIGNED32,status UNSIGNED64,valueList ListOfSMLValueEntry

}

ListOfSMLValueEntry ::= SEQUENCE OF UNSIGNED16

SMLHeaderEntry ::= SEQUENCE{

objName OCTET STRING,unit INTEGER8,scaler INTEGER8

}

SMLSignature ::= OCTET STRING


List-of-DCSML-ServerID ::= SEQUENCE OF OCTET STRING

List-of-DCSML-ServerIDAnswers ::= SEQUENCE OF DCSML-ServerIDAnswers

DCSML-ServerIDAnswers ::= SEQUENCE{

serverID OCTET STRING,header-List SEQUENCE OF SMLHeaderEntry,period-List SEQUENCE OF SMLProfObjPeriodEntry

}Rysunek 36: Definicja gramatyki w notacji ASN.1

6.2 Przykłady

6.2.1 Przykład 1-1-1

6.2.1.1 Zapytanieoffset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ascii

00000000 30 24 80 10 43 4C 49 45 4E 54 2D 5A 33 44 57 59 0$€.CLIENT-Z3DWY00000010 34 34 35 35 81 10 53 45 52 56 45 52 2D 5A 55 31 4455.SERVER-ZU1�00000020 54 4B 44 54 57 42 30 33 A0 12 04 10 53 45 52 56 TKDTWB03 ...SERV00000030 45 52 2D 52 56 4C 47 35 39 55 31 34 82 04 0F 89 ER-RVLG59U14‚..‰00000040 35 E6 83 02 55 31 84 04 4D F0 9F FF 85 04 4D F0 5ć.U1„.Mđź˙….Mđ�00000050 A3 83 A6 07 04 05 31 2E 38 2E 30 30 00 00 00 00 Ł¦...1.8.00....�

Rysunek 37: Zapytanie 1-1-1 w postaci APDU

Powyższy rysunek prezentuje zawartość wygenerowanego APDU w postaci szesnastkowej i znakowej. Zastosowane zostało kodowanie BER, a dokładniej – kodowanie zaimplementowane w wykorzystanym ogólnie dostępnym narzędziu „ASN.1 to Java Compiler” firmy ASNLab.

Poniżej opis zawartości tego APDU – dokładnością do danych, które udało się zidentyfikować:

30 SEQUENCE SMLPublicOpen-Req24 liczba bajtów w SEQUENCE (36)80 niezidentyfikowany10 liczba bajtów clientId (16)43 do 35 clientId (CLIENT-Z3DWY4455)81 niezidentyfikowany10 liczba bajtów serverId (16) (SERVER-ZU1TKDTWB03)30 SEQUENCE DCMeterGetData-Req33 liczba bajtów SEQUENCE (51)A0 SEQUENCE OF listserverID12 liczba bajtów SEQUENCE OF (18)04 niezidentyfikowany10 liczba bajtów pierwszego (i w tym przypadku ostatniego)

elementu listserverID (16)53 do 34 pierwszy element listserverID (SERVER-RVLG59U14)82 niezidentyfikowany04 liczba bajtów questionID (4)0F do E6 questionID (260650470)83 niezidentyfikowany02 liczba bajtów answerID (2)55 31 answerID (21809)84 niezidentyfikowany04 liczba bajtów beginTime (4)4D do FF beginTime (1307615231)85 niezidentyfikowany04 liczba bajtów endTime (4)


4D do 83 endTime (1307616131)A6 SEQUENCE OF parameterTreePath07 liczba bajtów SEQUENCE OF (7)04 niezidentyfikowany05 liczba bajtów pierwszego (i w tym przypadku ostatniego)

elementu parameterTreePath (5)31 do 30 kod OBIS (1.8.0)30 SEQUENCE SMLPublicClose-Req00 liczba bajtów SEQUENCE (0)00 koniec danych00 00 00 uzupełnienie do wielokrotności 4 bajtów

Ponownie należy podkreślić, że w przypadku DCSML zastosowane zostanie nieco efektywniejsze kodowanie APDU, stosowane dla APDU w języku SML.

SMLPublicOpen_Req {CLIENT-Z3DWY4455,SERVER-ZU1TKDTWB,

}DCMeterGetData_Req {

listserverID {SERVER-RVLG59U14,

}260650470 [HEX: 0F 89 35 E6],21809 [HEX: 55 31],1307615231 [HEX: 4D F0 9F FF] (Thu Jun 09 12:27:11 CEST 2011),1307616131 [HEX: 4D F0 A3 83] (Thu Jun 09 12:42:11 CEST 2011),parameterTreePath {

1.8.0,}

}SMLPublicClose_Req {}

Rysunek 38: Zapytanie 1-1-1 w notacji ASN.1

6.2.1.2 Odpowiedźoffset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ascii

00000000 30 24 80 10 43 4C 49 45 4E 54 2D 5A 33 44 57 59 0$€.CLIENT-Z3DWY00000010 34 34 35 35 81 10 53 45 52 56 45 52 2D 5A 55 31 4455.SERVER-ZU1�00000020 54 4B 44 54 57 42 30 4D 81 04 50 29 4B 35 82 02 TKDTWB0M.P)K5‚.�00000030 4E 97 A3 07 04 05 31 2E 38 2E 30 A4 38 30 36 80 N—Ł...1.8.0¤806€00000040 10 53 45 52 56 45 52 2D 52 56 4C 47 35 39 55 31 .SERVER-RVLG59U100000050 34 A1 0F 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 4ˇ.0.€.1.8.0..‚�00000060 01 01 A2 11 30 0F 80 04 4D F0 9F FF 81 01 08 A2 ..˘.0.€.Mđź˙..˘�00000070 04 02 02 6B 0B 30 00 00 00 00 00 00 00 00 00 00 ...k.0..........

Rysunek 39: Odpowiedź 1-1-1 w postaci APDU

SMLPublicOpen_Res {CLIENT-Z3DWY4455,SERVER-ZU1TKDTWB,

}DCMeterGetData_Res {

1344883509 [HEX: 50 29 4B 35],20119 [HEX: 4E 97],


parameterTreePath {1.8.0,

}DCSML_ServerIDAnswers {

SERVER-RVLG59U14,{

SMLHeaderEntry { 1.8.0, 5, 1 }}{

SMLProfObjPeriodEntry {1307615231 [HEX: 4D F0 9F FF] (Thu Jun 09 12:27:11 CEST

2011),8,{

27403 [HEX: 6B 0B],}

}}

}}SMLPublicClose_Res {}

Rysunek 40: Odpowiedź 1-1-1 w notacji ASN.1



00000000 30 24 80 10 43 4C 49 45 4E 54 2D 38 5A 4A 31 34 0$€.CLIENT-8ZJ1400000010 49 45 56 42 81 10 53 45 52 56 45 52 2D 43 4F 47 IEVB.SERVER-COG�00000020 39 34 49 32 36 45 30 33 A0 12 04 10 53 45 52 56 94I26E03 ...SERV00000030 45 52 2D 55 4D 36 30 4A 4D 59 44 34 82 04 5B 25 ER-UM60JMYD4‚.[%00000040 A6 88 83 02 17 C3 84 04 4D F0 A5 CF 85 04 4D F0 ¦..Ă„.MđĄĎ….Mđ��00000050 B3 DF A6 07 04 05 31 2E 38 2E 30 30 00 00 00 00 łß¦...1.8.00....


SMLPublicOpen_Req {CLIENT-8ZJ14IEVB,SERVER-COG94I26E,


listserverID {SERVER-UM60JMYD4,

}1529194120 [HEX: 5B 25 A6 88],6083 [HEX: 17 C3],1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),1307620319 [HEX: 4D F0 B3 DF] (Thu Jun 09 13:51:59 CEST 2011),parameterTreePath {

1.8.0,}





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 38 5A 4A 31 34 0$€.CLIENT-8ZJ1400000010 49 45 56 42 81 10 53 45 52 56 45 52 2D 43 4F 47 IEVB.SERVER-COG�00000020 39 34 49 32 36 45 30 81 82 81 04 49 48 55 C4 82 94I26E0‚.IHUÄ‚� �00000030 02 65 9A A3 07 04 05 31 2E 38 2E 30 A4 6D 30 6B .ešŁ...1.8.0¤m0k00000040 80 10 53 45 52 56 45 52 2D 55 4D 36 30 4A 4D 59 €.SERVER-UM60JMY00000050 44 34 A1 0F 30 0D 80 05 31 2E 38 2E 30 81 01 05 D4ˇ.0.€.1.8.0..�00000060 82 01 01 A2 46 30 10 80 04 4D F0 A5 CF 81 01 08 ‚..˘F0.€.MđĄĎ..�00000070 A2 05 02 03 00 D6 28 30 0F 80 04 4D F0 A9 53 81 ˘....Ö(0.€.Mđ©S �00000080 01 08 A2 04 02 02 2B CA 30 10 80 04 4D F0 AC D7 ..˘...+Ę0.€.Mđ¬×00000090 81 01 08 A2 05 02 03 00 9D 8F 30 0F 80 04 4D F0 ..˘....ťŹ0.€.Mđ�000000A0 B0 5B 81 01 08 A2 04 02 02 59 8B 30 00 00 00 00 °[..˘...Y‹0....�


SMLPublicOpen_Res {CLIENT-8ZJ14IEVB,SERVER-COG94I26E,


1229477316 [HEX: 49 48 55 C4],26010 [HEX: 65 9A],parameterTreePath {

1.8.0,}DCSML_ServerIDAnswers {

SERVER-UM60JMYD4,{


SMLProfObjPeriodEntry {1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST

2011),8,{

54824 [HEX: D6 28],}

}SMLProfObjPeriodEntry {

1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 13:06:59 CEST 2011),

8,{

11210 [HEX: 2B CA],}


1307618519 [HEX: 4D F0 AC D7] (Thu Jun 09 13:21:59 CEST 2011),

8,{

40335 [HEX: 9D 8F],}


1307619419 [HEX: 4D F0 B0 5B] (Thu Jun 09 13:36:59 CEST


2011),8,{

22923 [HEX: 59 8B],}

}}





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 45 4B 4C 44 46 0$€.CLIENT-EKLDF00000010 4E 33 5A 50 81 10 53 45 52 56 45 52 2D 4F 4B 53 N3ZP.SERVER-OKS�00000020 4C 44 53 54 48 54 30 50 A0 12 04 10 53 45 52 56 LDSTHT0P ...SERV00000030 45 52 2D 47 54 45 35 31 4C 34 42 32 82 04 5D 0B ER-GTE51L4B2‚.].00000040 57 5C 83 03 00 9A F6 84 04 4D F0 A5 CF 85 04 4D W\..šö„.MđĄĎ….M�00000050 F0 A9 53 A6 23 04 05 31 2E 38 2E 30 04 05 32 2E đ©S¦#..1.8.0..2.00000060 38 2E 30 04 05 35 2E 38 2E 30 04 05 36 2E 38 2E 8.0..5.8.0..6.8.00000070 30 04 05 37 2E 38 2E 30 30 00 00 00 00 00 00 00 0..7.8.00.......


SMLPublicOpen_Req {CLIENT-EKLDFN3ZP,SERVER-OKSLDSTHT,


listserverID {SERVER-GTE51L4B2,

}1561024348 [HEX: 5D 0B 57 5C],39670 [HEX: 9A F6],1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 13:06:59 CEST 2011),parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,

}}SMLPublicClose_Req {}


6.2.3.2 Odpowiedź00000000 30 24 80 10 43 4C 49 45 4E 54 2D 45 4B 4C 44 46 0$€.CLIENT-EKLDF


00000010 4E 33 5A 50 81 10 53 45 52 56 45 52 2D 4F 4B 53 N3ZP.SERVER-OKS�00000020 4C 44 53 54 48 54 30 81 BA 81 04 7C ED 10 F9 82 LDSTHT0ş.|í.ů‚� �00000030 03 00 98 63 A3 23 04 05 31 2E 38 2E 30 04 05 32 ..cŁ#..1.8.0..2�00000040 2E 38 2E 30 04 05 35 2E 38 2E 30 04 05 36 2E 38 .8.0..5.8.0..6.800000050 2E 30 04 05 37 2E 38 2E 30 A4 81 87 30 81 84 80 .0..7.8.0¤‡0„€� �00000060 10 53 45 52 56 45 52 2D 47 54 45 35 31 4C 34 42 .SERVER-GTE51L4B00000070 32 A1 4B 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 2ˇK0.€.1.8.0..‚�00000080 01 01 30 0D 80 05 32 2E 38 2E 30 81 01 07 82 01 ..0.€.2.8.0..‚.�00000090 01 30 0D 80 05 35 2E 38 2E 30 81 01 08 82 01 01 .0.€.5.8.0..‚..�000000A0 30 0D 80 05 36 2E 38 2E 30 81 01 04 82 01 01 30 0.€.6.8.0..‚..0�000000B0 0D 80 05 37 2E 38 2E 30 81 01 01 82 01 01 A2 23 .€.7.8.0..‚..˘#�000000C0 30 21 80 04 4D F0 A5 CF 81 01 08 A2 16 02 02 55 0!€.MđĄĎ..˘...U�000000D0 46 02 02 50 D1 02 03 00 BE F1 02 02 0A 2F 02 03 F..PŃ...ľń.../..000000E0 00 D9 D2 30 00 00 00 00 00 00 00 00 00 00 00 00 .ŮŇ0............


SMLPublicOpen_Res {CLIENT-EKLDFN3ZP,SERVER-OKSLDSTHT,


2095911161 [HEX: 7C ED 10 F9],39011 [HEX: 98 63],parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,


SERVER-GTE51L4B2,{

SMLHeaderEntry { 1.8.0, 5, 1 }SMLHeaderEntry { 2.8.0, 7, 1 }SMLHeaderEntry { 5.8.0, 8, 1 }SMLHeaderEntry { 6.8.0, 4, 1 }SMLHeaderEntry { 7.8.0, 1, 1 }

}{


2011),8,{

21830 [HEX: 55 46],20689 [HEX: 50 D1],48881 [HEX: BE F1],2607 [HEX: 0A 2F],55762 [HEX: D9 D2],

}}

}}

}SMLPublicClose_Res {


}





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 56 34 56 41 35 0$€.CLIENT-V4VA500000010 4E 38 48 34 81 10 53 45 52 56 45 52 2D 38 41 32 N8H4.SERVER-8A2�00000020 4A 49 56 32 44 33 30 4F A0 12 04 10 53 45 52 56 JIV2D30O ...SERV00000030 45 52 2D 39 49 31 53 44 41 44 33 53 82 04 52 F7 ER-9I1SDAD3S‚.R÷00000040 E8 FF 83 02 5E E9 84 04 4D F0 A5 CF 85 04 4D F0 č˙.^é„.MđĄĎ….Mđ�00000050 B3 DF A6 23 04 05 31 2E 38 2E 30 04 05 32 2E 38 łß¦#..1.8.0..2.800000060 2E 30 04 05 35 2E 38 2E 30 04 05 36 2E 38 2E 30 .0..5.8.0..6.8.000000070 04 05 37 2E 38 2E 30 30 00 00 00 00 00 00 00 00 ..7.8.00........


SMLPublicOpen_Req {CLIENT-V4VA5N8H4,SERVER-8A2JIV2D3,


listserverID {SERVER-9I1SDAD3S,

}1391978751 [HEX: 52 F7 E8 FF],24297 [HEX: 5E E9],1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),1307620319 [HEX: 4D F0 B3 DF] (Thu Jun 09 13:51:59 CEST 2011),parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 56 34 56 41 35 0$€.CLIENT-V4VA500000010 4E 38 48 34 81 10 53 45 52 56 45 52 2D 38 41 32 N8H4.SERVER-8A2�00000020 4A 49 56 32 44 33 30 82 01 26 81 04 12 96 6D 57 JIV2D30‚.&..–mW�00000030 82 02 02 0E A3 23 04 05 31 2E 38 2E 30 04 05 32 ‚...Ł#..1.8.0..200000040 2E 38 2E 30 04 05 35 2E 38 2E 30 04 05 36 2E 38 .8.0..5.8.0..6.800000050 2E 30 04 05 37 2E 38 2E 30 A4 81 F4 30 81 F1 80 .0..7.8.0¤ô0ń€� �00000060 10 53 45 52 56 45 52 2D 39 49 31 53 44 41 44 33 .SERVER-9I1SDAD300000070 53 A1 4B 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 SˇK0.€.1.8.0..‚�00000080 01 01 30 0D 80 05 32 2E 38 2E 30 81 01 07 82 01 ..0.€.2.8.0..‚.�00000090 01 30 0D 80 05 35 2E 38 2E 30 81 01 08 82 01 01 .0.€.5.8.0..‚..�000000A0 30 0D 80 05 36 2E 38 2E 30 81 01 04 82 01 01 30 0.€.6.8.0..‚..0�000000B0 0D 80 05 37 2E 38 2E 30 81 01 01 82 01 01 A2 81 .€.7.8.0..‚..˘� �000000C0 8F 30 22 80 04 4D F0 A5 CF 81 01 08 A2 17 02 02 Ź0"€.MđĄĎ..˘...�000000D0 17 61 02 03 00 83 A0 02 03 00 8C 43 02 03 00 B3 .a... � ...ŚC...ł000000E0 51 02 02 10 33 30 23 80 04 4D F0 A9 53 81 01 08 Q...30#€.Mđ©S..�000000F0 A2 18 02 03 00 DC E3 02 02 04 92 02 03 00 94 DC ˘....Üă...’...”Ü00000100 02 03 00 99 C8 02 03 00 9B BC 30 20 80 04 4D F0 ...™Č...›Ľ0 €.Mđ00000110 AC D7 81 01 08 A2 15 02 02 1F 1D 02 02 2A 0C 02 ¬×..˘.......*..�00000120 02 4A 65 02 03 00 88 7D 02 02 48 D3 30 22 80 04 .Je...}..HÓ0"€.�00000130 4D F0 B0 5B 81 01 08 A2 17 02 03 00 C3 09 02 02 Mđ°[..˘....Ă...�00000140 26 7E 02 03 00 E4 38 02 03 00 A3 71 02 02 58 7B &~...ä8...Łq..X{00000150 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0...............


SMLPublicOpen_Res {CLIENT-V4VA5N8H4,SERVER-8A2JIV2D3,


311848279 [HEX: 12 96 6D 57],526 [HEX: 02 0E],parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,


SERVER-9I1SDAD3S,{


}{


2011),8,


{5985 [HEX: 17 61],33696 [HEX: 83 A0],35907 [HEX: 8C 43],45905 [HEX: B3 51],4147 [HEX: 10 33],

}}SMLProfObjPeriodEntry {


8,{

56547 [HEX: DC E3],1170 [HEX: 04 92],38108 [HEX: 94 DC],39368 [HEX: 99 C8],39868 [HEX: 9B BC],



8,{

7965 [HEX: 1F 1D],10764 [HEX: 2A 0C],19045 [HEX: 4A 65],34941 [HEX: 88 7D],18643 [HEX: 48 D3],


1307619419 [HEX: 4D F0 B0 5B] (Thu Jun 09 13:36:59 CEST 2011),

8,{

49929 [HEX: C3 09],9854 [HEX: 26 7E],58424 [HEX: E4 38],41841 [HEX: A3 71],22651 [HEX: 58 7B],

}}

}}

}SMLPublicClose_Res {}



6.2.5.1 Zapytanie

offset 0 1 2 3 4 5 6 7 8 910

11

12

13

14

15 ascii

00000000

30

24

80

10

43

4C

49

45

4E

54

2D

4C

4A

32

54

59

0$€.CLIENT-LJ2TY

0000001 5 5 4 5 8 1 5 4 5 5 4 5 2 4 5 4 ZZLR.SERVER-MVH�


0 A A C 2 1 0 3 5 2 6 5 2 D D 6 800000020

4F

35

37

35

43

52

30

7C

A0

5A

04

10

53

45

52

56

O575CR0| Z..SERV

00000030

45

52

2D

31

30

32

46

58

57

4F

5A

53

04

10

53

45

ER-102FXWOZS..SE

00000040

52

56

45

52

2D

35

33

32

55

56

55

51

32

51

04

10

RVER-532UVUQ2Q..

00000050

53

45

52

56

45

52

2D

30

51

33

59

41

59

36

4F

33

SERVER-0Q3YAY6O3

00000060

04

10

53

45

52

56

45

52

2D

49

47

4D

49

4A

4A

45

..SERVER-IGMIJJE

00000070

38

39

04

10

53

45

52

56

45

52

2D

42

4B

45

43

52

89..SERVER-BKECR

00000080

31

46

43

36

82

04

25

93

B7

52

83

03

00

D5

4C

84 1FC6‚.%“·R..ŐL„�

00000090

04

4D

F0

A5

CF

85

04

4D

F0

A9

53

A6

07

04

05

31

.MđĄĎ….Mđ©S¦...1

000000A0

2E

38

2E

30

30

00

00

00

00

00

00

00

00

00

00

00

.8.00..........

.Rysunek 53: Zapytanie 5-1-1 w postaci APDU

SMLPublicOpen_Req {CLIENT-LJ2TYZZLR,SERVER-MVHO575CR,


listserverID {SERVER-102FXWOZS,SERVER-532UVUQ2Q,SERVER-0Q3YAY6O3,SERVER-IGMIJJE89,SERVER-BKECR1FC6,

}630437714 [HEX: 25 93 B7 52],54604 [HEX: D5 4C],1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 13:06:59 CEST 2011),parameterTreePath {

1.8.0,}




00000000 30 24 80 10 43 4C 49 45 4E 54 2D 4C 4A 32 54 59 0$€.CLIENT-LJ2TY00000010 5A 5A 4C 52 81 10 53 45 52 56 45 52 2D 4D 56 48 ZZLR.SERVER-MVH�00000020 4F 35 37 35 43 52 30 82 01 34 81 04 14 7F 04 A6 O575CR0‚.4...¦� �00000030 82 03 00 C2 29 A3 07 04 05 31 2E 38 2E 30 A4 82 ‚..Â)Ł...1.8.0¤‚00000040 01 1C 30 37 80 10 53 45 52 56 45 52 2D 31 30 32 ..07€.SERVER-10200000050 46 58 57 4F 5A 53 A1 0F 30 0D 80 05 31 2E 38 2E FXWOZSˇ.0.€.1.8.00000060 30 81 01 05 82 01 01 A2 12 30 10 80 04 4D F0 A5 0..‚..˘.0.€.MđĄ�00000070 CF 81 01 08 A2 05 02 03 00 DC 79 30 37 80 10 53 Ď..˘....Üy07€.S�00000080 45 52 56 45 52 2D 35 33 32 55 56 55 51 32 51 A1 ERVER-532UVUQ2Qˇ00000090 0F 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 01 01 .0.€.1.8.0..‚..�000000A0 A2 12 30 10 80 04 4D F0 A5 CF 81 01 08 A2 05 02 ˘.0.€.MđĄĎ..˘..�


000000B0 03 00 98 0E 30 37 80 10 53 45 52 56 45 52 2D 30 ...07€.SERVER-0�000000C0 51 33 59 41 59 36 4F 33 A1 0F 30 0D 80 05 31 2E Q3YAY6O3ˇ.0.€.1.000000D0 38 2E 30 81 01 05 82 01 01 A2 12 30 10 80 04 4D 8.0..‚..˘.0.€.M�000000E0 F0 A5 CF 81 01 08 A2 05 02 03 00 F8 A2 30 36 80 đĄĎ..˘....ř˘06€�000000F0 10 53 45 52 56 45 52 2D 49 47 4D 49 4A 4A 45 38 .SERVER-IGMIJJE800000100 39 A1 0F 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 9ˇ.0.€.1.8.0..‚�00000110 01 01 A2 11 30 0F 80 04 4D F0 A5 CF 81 01 08 A2 ..˘.0.€.MđĄĎ..˘�00000120 04 02 02 58 6D 30 37 80 10 53 45 52 56 45 52 2D ...Xm07€.SERVER-00000130 42 4B 45 43 52 31 46 43 36 A1 0F 30 0D 80 05 31 BKECR1FC6ˇ.0.€.100000140 2E 38 2E 30 81 01 05 82 01 01 A2 12 30 10 80 04 .8.0..‚..˘.0.€.�00000150 4D F0 A5 CF 81 01 08 A2 05 02 03 00 86 D9 30 00 MđĄĎ..˘....†Ů0.�


SMLPublicOpen_Res {CLIENT-LJ2TYZZLR,SERVER-MVHO575CR,


343868582 [HEX: 14 7F 04 A6],49705 [HEX: C2 29],parameterTreePath {


SERVER-102FXWOZS,{



2011),8,{

56441 [HEX: DC 79],}

}}

DCSML_ServerIDAnswers {SERVER-532UVUQ2Q,{



2011),8,{

38926 [HEX: 98 0E],}

}}

DCSML_ServerIDAnswers {SERVER-0Q3YAY6O3,{

SMLHeaderEntry { 1.8.0, 5, 1 }


}{


2011),8,{

63650 [HEX: F8 A2],}

}}

DCSML_ServerIDAnswers {SERVER-IGMIJJE89,{



2011),8,{

22637 [HEX: 58 6D],}

}}

DCSML_ServerIDAnswers {SERVER-BKECR1FC6,{



2011),8,{

34521 [HEX: 86 D9],}

}}





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 4C 4A 32 54 59 0$€.CLIENT-LJ2TY00000010 5A 5A 4C 52 81 10 53 45 52 56 45 52 2D 4D 56 48 ZZLR.SERVER-MVH�00000020 4F 35 37 35 43 52 30 7C A0 5A 04 10 53 45 52 56 O575CR0| Z..SERV00000030 45 52 2D 31 30 32 46 58 57 4F 5A 53 04 10 53 45 ER-102FXWOZS..SE00000040 52 56 45 52 2D 35 33 32 55 56 55 51 32 51 04 10 RVER-532UVUQ2Q..00000050 53 45 52 56 45 52 2D 30 51 33 59 41 59 36 4F 33 SERVER-0Q3YAY6O300000060 04 10 53 45 52 56 45 52 2D 49 47 4D 49 4A 4A 45 ..SERVER-IGMIJJE


00000070 38 39 04 10 53 45 52 56 45 52 2D 42 4B 45 43 52 89..SERVER-BKECR00000080 31 46 43 36 82 04 25 93 B7 52 83 03 00 D5 4C 84 1FC6‚.%“·R..ŐL„�00000090 04 4D F0 A5 CF 85 04 4D F0 A9 53 A6 07 04 05 31 .MđĄĎ….Mđ©S¦...1000000A0 2E 38 2E 30 30 00 00 00 00 00 00 00 00 00 00 00 .8.00...........



SMLPublicOpen_Req {CLIENT-LJ2TYZZLR,SERVER-MVHO575CR,


listserverID {SERVER-102FXWOZS,SERVER-532UVUQ2Q,SERVER-0Q3YAY6O3,SERVER-IGMIJJE89,SERVER-BKECR1FC6,

}630437714 [HEX: 25 93 B7 52],54604 [HEX: D5 4C],1307616719 [HEX: 4D F0 A5 CF] (Thu Jun 09 12:51:59 CEST 2011),1307617619 [HEX: 4D F0 A9 53] (Thu Jun 09 13:06:59 CEST 2011),parameterTreePath {

1.8.0,}




00000000 30 24 80 10 43 4C 49 45 4E 54 2D 4C 4A 32 54 59 0$€.CLIENT-LJ2TY00000010 5A 5A 4C 52 81 10 53 45 52 56 45 52 2D 4D 56 48 ZZLR.SERVER-MVH�00000020 4F 35 37 35 43 52 30 82 01 34 81 04 14 7F 04 A6 O575CR0‚.4...¦� �00000030 82 03 00 C2 29 A3 07 04 05 31 2E 38 2E 30 A4 82 ‚..Â)Ł...1.8.0¤‚00000040 01 1C 30 37 80 10 53 45 52 56 45 52 2D 31 30 32 ..07€.SERVER-10200000050 46 58 57 4F 5A 53 A1 0F 30 0D 80 05 31 2E 38 2E FXWOZSˇ.0.€.1.8.00000060 30 81 01 05 82 01 01 A2 12 30 10 80 04 4D F0 A5 0..‚..˘.0.€.MđĄ�00000070 CF 81 01 08 A2 05 02 03 00 DC 79 30 37 80 10 53 Ď..˘....Üy07€.S�00000080 45 52 56 45 52 2D 35 33 32 55 56 55 51 32 51 A1 ERVER-532UVUQ2Qˇ00000090 0F 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 01 01 .0.€.1.8.0..‚..�000000A0 A2 12 30 10 80 04 4D F0 A5 CF 81 01 08 A2 05 02 ˘.0.€.MđĄĎ..˘..�000000B0 03 00 98 0E 30 37 80 10 53 45 52 56 45 52 2D 30 ...07€.SERVER-0�000000C0 51 33 59 41 59 36 4F 33 A1 0F 30 0D 80 05 31 2E Q3YAY6O3ˇ.0.€.1.000000D0 38 2E 30 81 01 05 82 01 01 A2 12 30 10 80 04 4D 8.0..‚..˘.0.€.M�000000E0 F0 A5 CF 81 01 08 A2 05 02 03 00 F8 A2 30 36 80 đĄĎ..˘....ř˘06€�000000F0 10 53 45 52 56 45 52 2D 49 47 4D 49 4A 4A 45 38 .SERVER-IGMIJJE800000100 39 A1 0F 30 0D 80 05 31 2E 38 2E 30 81 01 05 82 9ˇ.0.€.1.8.0..‚�00000110 01 01 A2 11 30 0F 80 04 4D F0 A5 CF 81 01 08 A2 ..˘.0.€.MđĄĎ..˘�00000120 04 02 02 58 6D 30 37 80 10 53 45 52 56 45 52 2D ...Xm07€.SERVER-00000130 42 4B 45 43 52 31 46 43 36 A1 0F 30 0D 80 05 31 BKECR1FC6ˇ.0.€.100000140 2E 38 2E 30 81 01 05 82 01 01 A2 12 30 10 80 04 .8.0..‚..˘.0.€.�00000150 4D F0 A5 CF 81 01 08 A2 05 02 03 00 86 D9 30 00 MđĄĎ..˘....†Ů0.�


SMLPublicOpen_Res {CLIENT-GO0A3OBPF,SERVER-XADE3KLQA,



2078902676 [HEX: 7B E9 89 94],8750 [HEX: 22 2E],parameterTreePath {


SERVER-QS9YICBYI,{


SMLProfObjPeriodEntry {1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST

2011),8,{

42429 [HEX: A5 BD],}



8,{

58574 [HEX: E4 CE],}



8,{

62488 [HEX: F4 18],}


1307619418 [HEX: 4D F0 B0 5A] (Thu Jun 09 13:36:58 CEST 2011),

8,{

12680 [HEX: 31 88],}

}}

DCSML_ServerIDAnswers {SERVER-9CSFCRDH5,{



2011),8,{

53621 [HEX: D1 75],}




8,{

15381 [HEX: 3C 15],}



8,{

57326 [HEX: DF EE],}



8,{

28371 [HEX: 6E D3],}

}}

DCSML_ServerIDAnswers {SERVER-2KBGFPDQA,{



2011),8,{

2127 [HEX: 08 4F],}



8,{

12857 [HEX: 32 39],}



8,{

18283 [HEX: 47 6B],}



8,{


28557 [HEX: 6F 8D],}

}}

DCSML_ServerIDAnswers {SERVER-C0IO84PZS,{



2011),8,{

39227 [HEX: 99 3B],}



8,{

44251 [HEX: AC DB],}



8,{

23239 [HEX: 5A C7],}



8,{

24035 [HEX: 5D E3],}

}}

DCSML_ServerIDAnswers {SERVER-EQWS32GHO,{



2011),8,{

57436 [HEX: E0 5C],}


1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST


2011),8,{

637 [HEX: 02 7D],}



8,{

51808 [HEX: CA 60],}



8,{

8985 [HEX: 23 19],}

}}





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 45 46 42 46 33 0$€.CLIENT-EFBF300000010 33 4C 56 33 81 10 53 45 52 56 45 52 2D 54 50 41 3LV3.SERVER-TPA�00000020 4B 47 4E 43 43 45 30 81 98 A0 5A 04 10 53 45 52 KGNCCE0 �� Z..SER00000030 56 45 52 2D 39 53 32 50 45 4F 34 4E 46 04 10 53 VER-9S2PEO4NF..S00000040 45 52 56 45 52 2D 41 43 49 58 47 57 35 4E 57 04 ERVER-ACIXGW5NW.00000050 10 53 45 52 56 45 52 2D 35 50 34 4E 52 38 32 55 .SERVER-5P4NR82U00000060 30 04 10 53 45 52 56 45 52 2D 41 31 57 32 52 33 0..SERVER-A1W2R300000070 46 56 41 04 10 53 45 52 56 45 52 2D 48 4B 38 5A FVA..SERVER-HK8Z00000080 30 4C 32 45 49 82 04 23 80 E1 43 83 03 00 F4 B4 0L2EI‚.#€áC..ô´�00000090 84 04 4D F0 A5 CE 85 04 4D F0 A9 52 A6 23 04 05 „.MđĄÎ….Mđ©R¦#..000000A0 31 2E 38 2E 30 04 05 32 2E 38 2E 30 04 05 35 2E 1.8.0..2.8.0..5.000000B0 38 2E 30 04 05 36 2E 38 2E 30 04 05 37 2E 38 2E 8.0..6.8.0..7.8.000000C0 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00..............


SMLPublicOpen_Req {CLIENT-EFBF33LV3,SERVER-TPAKGNCCE,


listserverID {SERVER-9S2PEO4NF,SERVER-ACIXGW5NW,


SERVER-5P4NR82U0,SERVER-A1W2R3FVA,SERVER-HK8Z0L2EI,

}595648835 [HEX: 23 80 E1 43],62644 [HEX: F4 B4],1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST 2011),1307617618 [HEX: 4D F0 A9 52] (Thu Jun 09 13:06:58 CEST 2011),parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,




00000000 30 24 80 10 43 4C 49 45 4E 54 2D 45 46 42 46 33 0$€.CLIENT-EFBF300000010 33 4C 56 33 81 10 53 45 52 56 45 52 2D 54 50 41 3LV3.SERVER-TPA�00000020 4B 47 4E 43 43 45 30 82 02 DB 81 04 1A 14 D7 12 KGNCCE0‚.Ű...×.�00000030 82 02 4E BD A3 23 04 05 31 2E 38 2E 30 04 05 32 ‚.N˝Ł#..1.8.0..200000040 2E 38 2E 30 04 05 35 2E 38 2E 30 04 05 36 2E 38 .8.0..5.8.0..6.800000050 2E 30 04 05 37 2E 38 2E 30 A4 82 02 A8 30 81 86 .0..7.8.0¤‚.¨0†�00000060 80 10 53 45 52 56 45 52 2D 39 53 32 50 45 4F 34 €.SERVER-9S2PEO400000070 4E 46 A1 4B 30 0D 80 05 31 2E 38 2E 30 81 01 05 NFˇK0.€.1.8.0..�00000080 82 01 01 30 0D 80 05 32 2E 38 2E 30 81 01 07 82 ‚..0.€.2.8.0..‚�00000090 01 01 30 0D 80 05 35 2E 38 2E 30 81 01 08 82 01 ..0.€.5.8.0..‚.�000000A0 01 30 0D 80 05 36 2E 38 2E 30 81 01 04 82 01 01 .0.€.6.8.0..‚..�000000B0 30 0D 80 05 37 2E 38 2E 30 81 01 01 82 01 01 A2 0.€.7.8.0..‚..˘�000000C0 25 30 23 80 04 4D F0 A5 CE 81 01 08 A2 18 02 03 %0#€.MđĄÎ..˘...�000000D0 00 82 05 02 02 23 58 02 03 00 D1 9F 02 03 00 E5 .‚...#X...Ńź...ĺ000000E0 1C 02 03 00 B9 24 30 81 84 80 10 53 45 52 56 45 ....ą$0„€.SERVE�000000F0 52 2D 41 43 49 58 47 57 35 4E 57 A1 4B 30 0D 80 R-ACIXGW5NWˇK0.€00000100 05 31 2E 38 2E 30 81 01 05 82 01 01 30 0D 80 05 .1.8.0..‚..0.€.�00000110 32 2E 38 2E 30 81 01 07 82 01 01 30 0D 80 05 35 2.8.0..‚..0.€.5�00000120 2E 38 2E 30 81 01 08 82 01 01 30 0D 80 05 36 2E .8.0..‚..0.€.6.�00000130 38 2E 30 81 01 04 82 01 01 30 0D 80 05 37 2E 38 8.0..‚..0.€.7.8�00000140 2E 30 81 01 01 82 01 01 A2 23 30 21 80 04 4D F0 .0..‚..˘#0!€.Mđ�00000150 A5 CE 81 01 08 A2 16 02 02 02 18 02 03 00 E8 87 ĄÎ..˘........č‡�00000160 02 03 00 EC A2 02 02 5C 4F 02 02 24 94 30 81 85 ...ě˘..\O..$”0…�00000170 80 10 53 45 52 56 45 52 2D 35 50 34 4E 52 38 32 €.SERVER-5P4NR8200000180 55 30 A1 4B 30 0D 80 05 31 2E 38 2E 30 81 01 05 U0ˇK0.€.1.8.0..�00000190 82 01 01 30 0D 80 05 32 2E 38 2E 30 81 01 07 82 ‚..0.€.2.8.0..‚�000001A0 01 01 30 0D 80 05 35 2E 38 2E 30 81 01 08 82 01 ..0.€.5.8.0..‚.�000001B0 01 30 0D 80 05 36 2E 38 2E 30 81 01 04 82 01 01 .0.€.6.8.0..‚..�000001C0 30 0D 80 05 37 2E 38 2E 30 81 01 01 82 01 01 A2 0.€.7.8.0..‚..˘�000001D0 24 30 22 80 04 4D F0 A5 CE 81 01 08 A2 17 02 02 $0"€.MđĄÎ..˘...�000001E0 74 EF 02 02 78 48 02 03 00 BE B9 02 03 00 CB A7 tď..xH...ľą...Ë§000001F0 02 03 00 C5 5D 30 81 84 80 10 53 45 52 56 45 52 ...Ĺ]0„€.SERVER�00000200 2D 41 31 57 32 52 33 46 56 41 A1 4B 30 0D 80 05 -A1W2R3FVAˇK0.€.


00000210 31 2E 38 2E 30 81 01 05 82 01 01 30 0D 80 05 32 1.8.0..‚..0.€.2�00000220 2E 38 2E 30 81 01 07 82 01 01 30 0D 80 05 35 2E .8.0..‚..0.€.5.�


SMLPublicOpen_Res {CLIENT-EFBF33LV3,SERVER-TPAKGNCCE,


437573394 [HEX: 1A 14 D7 12],20157 [HEX: 4E BD],parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,


SERVER-9S2PEO4NF,{


}{


2011),8,{

33285 [HEX: 82 05],9048 [HEX: 23 58],53663 [HEX: D1 9F],58652 [HEX: E5 1C],47396 [HEX: B9 24],

}}


SERVER-ACIXGW5NW,{


}{


2011),8,{

536 [HEX: 02 18],


59527 [HEX: E8 87],60578 [HEX: EC A2],23631 [HEX: 5C 4F],9364 [HEX: 24 94],

}}


SERVER-5P4NR82U0,{


}{


2011),8,{

29935 [HEX: 74 EF],30792 [HEX: 78 48],48825 [HEX: BE B9],52135 [HEX: CB A7],50525 [HEX: C5 5D],

}}


SERVER-A1W2R3FVA,{


}{


2011),8,{

24847 [HEX: 61 0F],58828 [HEX: E5 CC],26551 [HEX: 67 B7],3180 [HEX: 0C 6C],41280 [HEX: A1 40],

}}


SERVER-HK8Z0L2EI,{

SMLHeaderEntry { 1.8.0, 5, 1 }SMLHeaderEntry { 2.8.0, 7, 1 }SMLHeaderEntry { 5.8.0, 8, 1 }


SMLHeaderEntry { 6.8.0, 4, 1 }SMLHeaderEntry { 7.8.0, 1, 1 }

}{


2011),8,{

63424 [HEX: F7 C0],45317 [HEX: B1 05],60807 [HEX: ED 87],8757 [HEX: 22 35],49005 [HEX: BF 6D],

}}

}}





00000000 30 24 80 10 43 4C 49 45 4E 54 2D 4C 36 48 42 45 0$€.CLIENT-L6HBE00000010 43 56 43 52 81 10 53 45 52 56 45 52 2D 5A 36 36 CVCR.SERVER-Z66�00000020 38 4B 33 50 48 37 30 81 98 A0 5A 04 10 53 45 52 8K3PH70 �� Z..SER00000030 56 45 52 2D 39 43 33 35 34 59 41 46 57 04 10 53 VER-9C354YAFW..S00000040 45 52 56 45 52 2D 36 47 43 4C 49 43 43 44 31 04 ERVER-6GCLICCD1.00000050 10 53 45 52 56 45 52 2D 4F 44 5A 38 39 4A 4B 4B .SERVER-ODZ89JKK00000060 44 04 10 53 45 52 56 45 52 2D 55 50 42 33 35 57 D..SERVER-UPB35W00000070 57 58 57 04 10 53 45 52 56 45 52 2D 49 43 5A 39 WXW..SERVER-ICZ900000080 49 34 55 30 30 82 04 3E 8D A8 35 83 03 00 C9 13 I4U00‚.>Ť¨5..É.�00000090 84 04 4D F0 A5 CE 85 04 4D F0 B3 DE A6 23 04 05 „.MđĄÎ….MđłŢ¦#..000000A0 31 2E 38 2E 30 04 05 32 2E 38 2E 30 04 05 35 2E 1.8.0..2.8.0..5.000000B0 38 2E 30 04 05 36 2E 38 2E 30 04 05 37 2E 38 2E 8.0..6.8.0..7.8.000000C0 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00..............


SMLPublicOpen_Req {CLIENT-L6HBECVCR,SERVER-Z668K3PH7,


listserverID {SERVER-9C354YAFW,SERVER-6GCLICCD1,SERVER-ODZ89JKKD,SERVER-UPB35WWXW,SERVER-ICZ9I4U00,

}1049471029 [HEX: 3E 8D A8 35],51475 [HEX: C9 13],


1307616718 [HEX: 4D F0 A5 CE] (Thu Jun 09 12:51:58 CEST 2011),1307620318 [HEX: 4D F0 B3 DE] (Thu Jun 09 13:51:58 CEST 2011),parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,




00000000 30 24 80 10 43 4C 49 45 4E 54 2D 4C 36 48 42 45 0$€.CLIENT-L6HBE00000010 43 56 43 52 81 10 53 45 52 56 45 52 2D 5A 36 36 CVCR.SERVER-Z66�00000020 38 4B 33 50 48 37 30 82 04 EC 81 04 69 8A D5 E5 8K3PH70‚.ě.iŠŐĺ�00000030 82 02 21 A1 A3 23 04 05 31 2E 38 2E 30 04 05 32 ‚.!ˇŁ#..1.8.0..200000040 2E 38 2E 30 04 05 35 2E 38 2E 30 04 05 36 2E 38 .8.0..5.8.0..6.800000050 2E 30 04 05 37 2E 38 2E 30 A4 82 04 B9 30 81 EE .0..7.8.0¤‚.ą0î�00000060 80 10 53 45 52 56 45 52 2D 39 43 33 35 34 59 41 €.SERVER-9C354YA00000070 46 57 A1 4B 30 0D 80 05 31 2E 38 2E 30 81 01 05 FWˇK0.€.1.8.0..�00000080 82 01 01 30 0D 80 05 32 2E 38 2E 30 81 01 07 82 ‚..0.€.2.8.0..‚�00000090 01 01 30 0D 80 05 35 2E 38 2E 30 81 01 08 82 01 ..0.€.5.8.0..‚.�000000A0 01 30 0D 80 05 36 2E 38 2E 30 81 01 04 82 01 01 .0.€.6.8.0..‚..�000000B0 30 0D 80 05 37 2E 38 2E 30 81 01 01 82 01 01 A2 0.€.7.8.0..‚..˘�000000C0 81 8C 30 21 80 04 4D F0 A5 CE 81 01 08 A2 16 02 Ś0!€.MđĄÎ..˘..� �000000D0 02 46 C2 02 02 49 31 02 02 59 F9 02 03 00 AB 52 .FÂ..I1..Yů...«R000000E0 02 03 00 F4 B8 30 21 80 04 4D F0 A9 52 81 01 08 ...ô¸0!€.Mđ©R..�000000F0 A2 16 02 03 00 F2 18 02 02 37 37 02 02 53 44 02 ˘....ň...77..SD.00000100 02 57 2E 02 03 00 A6 9C 30 21 80 04 4D F0 AC D6 .W....¦ś0!€.Mđ¬Ö00000110 81 01 08 A2 16 02 02 77 DB 02 03 00 84 A8 02 02 ..˘...wŰ...„¨..�00000120 78 45 02 03 00 FA 3D 02 02 00 CC 30 21 80 04 4D xE...ú=...Ě0!€.M00000130 F0 B0 5A 81 01 08 A2 16 02 02 2F 1D 02 02 4C 7E đ°Z..˘.../...L~�00000140 02 02 1C F9 02 03 00 F2 C6 02 03 00 88 8A 30 81 ...ů...ňĆ...Š0� �00000150 F1 80 10 53 45 52 56 45 52 2D 36 47 43 4C 49 43 ń€.SERVER-6GCLIC00000160 43 44 31 A1 4B 30 0D 80 05 31 2E 38 2E 30 81 01 CD1ˇK0.€.1.8.0.�00000170 05 82 01 01 30 0D 80 05 32 2E 38 2E 30 81 01 07 .‚..0.€.2.8.0..�00000180 82 01 01 30 0D 80 05 35 2E 38 2E 30 81 01 08 82 ‚..0.€.5.8.0..‚�00000190 01 01 30 0D 80 05 36 2E 38 2E 30 81 01 04 82 01 ..0.€.6.8.0..‚.�000001A0 01 30 0D 80 05 37 2E 38 2E 30 81 01 01 82 01 01 .0.€.7.8.0..‚..�000001B0 A2 81 8F 30 24 80 04 4D F0 A5 CE 81 01 08 A2 19 ˘Ź0$€.MđĄÎ..˘.� �000001C0 02 03 00 DD 1C 02 03 00 9A 56 02 03 00 A6 CA 02 ...Ý....šV...¦Ę.000001D0 03 00 87 92 02 03 00 91 C3 30 20 80 04 4D F0 A9 ..‡’...‘Ă0 €.Mđ©000001E0 52 81 01 08 A2 15 02 02 69 9B 02 02 51 C2 02 03 R..˘...i›..QÂ..�000001F0 00 EE F9 02 02 49 A8 02 02 29 65 30 21 80 04 4D .îů..I¨..)e0!€.M00000200 F0 AC D6 81 01 08 A2 16 02 02 2E 9B 02 03 00 F1 đ¬Ö..˘....›...ń�00000210 7D 02 02 24 DD 02 02 4F EE 02 03 00 AB 8D 30 22 }..$Ý..Oî...«Ť0"00000220 80 04 4D F0 B0 5A 81 01 08 A2 17 02 03 00 E3 90 €.Mđ°Z..˘....ă� �



SMLPublicOpen_Res {CLIENT-L6HBECVCR,SERVER-Z668K3PH7,


1770706405 [HEX: 69 8A D5 E5],8609 [HEX: 21 A1],parameterTreePath {

1.8.0,2.8.0,5.8.0,6.8.0,7.8.0,


SERVER-9C354YAFW,{


}{


2011),8,{

18114 [HEX: 46 C2],18737 [HEX: 49 31],23033 [HEX: 59 F9],43858 [HEX: AB 52],62648 [HEX: F4 B8],



8,{

61976 [HEX: F2 18],14135 [HEX: 37 37],21316 [HEX: 53 44],22318 [HEX: 57 2E],42652 [HEX: A6 9C],



8,{

30683 [HEX: 77 DB],33960 [HEX: 84 A8],30789 [HEX: 78 45],64061 [HEX: FA 3D],


204 [HEX: CC],}



8,{

12061 [HEX: 2F 1D],19582 [HEX: 4C 7E],7417 [HEX: 1C F9],62150 [HEX: F2 C6],34954 [HEX: 88 8A],

}}


SERVER-6GCLICCD1,{


}{


2011),8,{

56604 [HEX: DD 1C],39510 [HEX: 9A 56],42698 [HEX: A6 CA],34706 [HEX: 87 92],37315 [HEX: 91 C3],



8,{

27035 [HEX: 69 9B],20930 [HEX: 51 C2],61177 [HEX: EE F9],18856 [HEX: 49 A8],10597 [HEX: 29 65],



8,{

11931 [HEX: 2E 9B],61821 [HEX: F1 7D],9437 [HEX: 24 DD],20462 [HEX: 4F EE],


43917 [HEX: AB 8D],}



8,{

58256 [HEX: E3 90],15518 [HEX: 3C 9E],40582 [HEX: 9E 86],40451 [HEX: 9E 03],31787 [HEX: 7C 2B],

}}


SERVER-ODZ89JKKD,{


}{


2011),8,{

17488 [HEX: 44 50],52224 [HEX: CC],41762 [HEX: A3 22],17906 [HEX: 45 F2],38778 [HEX: 97 7A],



8,{

6706 [HEX: 1A 32],40163 [HEX: 9C E3],13280 [HEX: 33 E0],61217 [HEX: EF 21],17106 [HEX: 42 D2],



8,{

16208 [HEX: 3F 50],26068 [HEX: 65 D4],14902 [HEX: 3A 36],39920 [HEX: 9B F0],


26979 [HEX: 69 63],}



8,{

28938 [HEX: 71 0A],874 [HEX: 03 6A],27005 [HEX: 69 7D],56566 [HEX: DC F6],30630 [HEX: 77 A6],

}}


SERVER-UPB35WWXW,{


}{


2011),8,{

37388 [HEX: 92 0C],45669 [HEX: B2 65],61276 [HEX: EF 5C],12436 [HEX: 30 94],46896 [HEX: B7 30],



8,{

49294 [HEX: C0 8E],23480 [HEX: 5B B8],7800 [HEX: 1E 78],28070 [HEX: 6D A6],18557 [HEX: 48 7D],



8,{

52907 [HEX: CE AB],40185 [HEX: 9C F9],8909 [HEX: 22 CD],10991 [HEX: 2A EF],


60658 [HEX: EC F2],}



8,{

42543 [HEX: A6 2F],51178 [HEX: C7 EA],53586 [HEX: D1 52],55569 [HEX: D9 11],64530 [HEX: FC 12],

}}


SERVER-ICZ9I4U00,{


}{


2011),8,{

11298 [HEX: 2C 22],29078 [HEX: 71 96],28706 [HEX: 70 22],19155 [HEX: 4A D3],30849 [HEX: 78 81],



8,{

58615 [HEX: E4 F7],61694 [HEX: F0 FE],8230 [HEX: 20 26],22636 [HEX: 58 6C],15448 [HEX: 3C 58],



8,{

15493 [HEX: 3C 85],52823 [HEX: CE 57],54491 [HEX: D4 DB],34185 [HEX: 85 89],


5962 [HEX: 17 4A],}



8,{

28791 [HEX: 70 77],22704 [HEX: 58 B0],1492 [HEX: 05 D4],13972 [HEX: 36 94],16694 [HEX: 41 36],

}}

}}




· Web viewna świecie istnieje kilka ośrodków laboratoryjnych certyfikacji urządzeń na...

Documents

Transcript of · Web viewna świecie istnieje kilka ośrodków laboratoryjnych certyfikacji urządzeń na...