Transmisja danych licznika EQM protokół DLMS

Transkrypt

1 Zakład Elektronicznych Urządzeń Pomiarowych Pozyton sp. z o.o Częstochowa ul. Staszica 8 p o z y t o n tel , , , fax , pozyton@pozyton.com.pl Tytuł: Transmisja danych licznika EQM protokół DLMS Indeks dokumentacji: TK/2004/046/001 Nazwa urządzenia: Typ: Wersja wykonania: ELEKTRONICZNY TRÓJFAZOWY LICZNIK ENERGII ELEKTRYCZNEJ EQM 3x230/400 V 0,15-5(100) A 50 Hz v x57,7/100 V... 3x230/400 V 0,05-5(10) A 50 Hz v x57,7/100 V 0,05-5(6) A 50 Hz 3x57,7/100 V 0,01-1(1,2) A 50 Hz v Dokument zawiera 72 stron(y)

2 Spis treści 1 Wstęp Cel tego dokumentu Dokumenty związane Pojęcia ogólne Klient i serwer Urządzenie fizyczne, urządzenia logiczne i obiekty Profil komunikacyjny zastosowany w liczniku EQM Ustalenie połączenia między klientem a serwerem Warstwa fizyczna Wprowadzenie Parametry transmisji Interfejs optyczny (OPTO) łącze RS485 lub CLO (pętla prądowa) łącze Moduł instalowany w kieszeni licznika łącze Tryb automatycznej detekcji protokołu Tryb E tekstowego protokołu zgodnego z PN-EN Warstwa łącza danych Wprowadzenie Podwarstwa MAC protokół HDLC Ramka HDLC format Adresowanie w protokole HDLC Typy ramek HDLC Kolejność wysyłania bitów i bajtów w ramce HDLC Zestawienie połączenia Zakończenie połączenia Brak aktywności na łączu Wymiana danych Obsługa sytuacji wyjątkowych w liczniku EQM Zachowanie protokołu HDLC podczas długiego przygotowywania danych Podwarstwa LLC specyfikacja protokołu Warstwa aplikacji COSEM Wprowadzenie Struktura warstwy aplikacji COSEM Serwisy ACSE (Association Control Service Element) Serwisy xdlms ASE (xdlms Application Service Element) Kojarzenie aplikacji klienta i serwera Żądanie AARQ i initiaterequest oraz przykłady ich kodowania Odpowiedź AARE i initiateresponse oraz przykłady ich kodowania Raportowane błędy podczas kojarzenia aplikacji Dostęp do atrybutów obiektów COSEM Żądanie readrequest oraz przykłady jego kodowania Odpowiedź readresponse oraz przykłady jego kodowania Żądanie writerequest oraz przykłady jego kodowania Odpowiedź writeresponse oraz przykłady jego kodowania Raportowanie błędów confirmedserviceerror Obiekty dostępne w liczniku EQM Obiekty podstawowe Obiekty bieżącego okresu obrachunkowego Obiekty klasy Profile generic Strona 1 z 72

3 1 Wstęp 1.1 Cel tego dokumentu Dokument ten zawiera informacje dotyczące funkcjonowania protokołu DLMS w liczniku EQM. W liczniku EQM wykorzystano trójwarstwową zorientowaną połączeniowo architekturę COSEM. W ramach tej architektury w liczniku zaimplementowano następujące warstwy: 1. warstwa aplikacji COSEM (COSEM Application Layer); 2. warstwa łącza danych (Data Link Layer) w skład której wchodzą dwie podwarstwy: LLC (Logical Link Control), MAC (Medium Access Control) wraz z protokołem HDLC (High-level Data Link Control); 3. warstwa fizyczna (Physical Layer) realizowana w oparciu o interfejsy dostępne w liczniku, czyli: interfejs optyczny (OPTO) łącze 1, interfejs RS485 lub CLO (pętla prądowa) łącze 2, moduł instalowany w kieszeni licznika łącze 3. Opracowanie to zawiera jedynie opisy dotyczące wyżej wymienionych warstw i protokołów. Szerzej protokół DLMS opisany jest w dokumentacji dostarczonej przez DLMS User Association. 1.2 Dokumenty związane Nr dokumentu DLMS UA Ed. 7.0 DLMS UA Ed. 9.0 DLMS UA 1002:2003, First Edition ISO/IEC :2002(E) IEC Ed. 1.0:2000 ISO/IEC :2002(E) ISO/IEC 13239:2002(E) Tytuł COSEM Architecture and Protocol, Green Book COSEM Identification System and Interface Classes, Blue Book COSEM Glossary of Terms, White Book Information technology Abstract Syntax Notation One (ASN.1): Specification of basic notation Distribution automation using distribution line carrier systems Part 6: A-XDR encoding rule Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Strona 2 z 72

4 2 Pojęcia ogólne 2.1 Klient i serwer Licznik EQM gra rolę serwera udostępniającego dane. Serwer odpowiada jedynie na żądania klienta nigdy sam nie inicjuje połączenia i transmisji danych. Rolę klienta gra oprogramowanie uruchamiane w urządzeniu odczytowym, które inicjuje połączenie z wybranym licznikiem i generuje żądania np. odczytu określonych danych pomiarowych. 2.2 Urządzenie fizyczne, urządzenia logiczne i obiekty W architekturze COSEM urządzenie fizyczne (czyli np. licznik EQM) musi być identyfikowane w skali sieci unikalnym adresem urządzenia fizycznego. Przykładową sieć w jakiej może pracować licznik pokazuje rysunek 1. Urządzenie fizyczne COSEM 123 Urządzenie logiczne 1 Obiekty COSEM Urządzenie Management logiczne 2 Logical Device Obiekty COSEM Obiekty COSEM 1 Licznik EQM 456 Management Logical Device Obiekty COSEM 1 Licznik EQM 789 Management Logical Device Obiekty COSEM 1 Adres urządzenia logicznego Adres urządzenia fizycznego Rysunek 1: Urządzenia fizyczne, logiczne i obiekty Urządzenie fizyczne musi zawierać co najmniej jedno urządzenie logiczne (choć może być ich więcej). W nazewnictwie obowiązującym w COSEM, to obowiązkowe urządzenie logiczne nazywane jest Management Logical Device. Gdy urządzenie fizyczne zawiera więcej niż jedno urządzenie logiczne, konieczne jest aby urządzenie Management Logical Device posiadało obiekt o nazwie SAP assignment, który zawiera listę pozostałych urządzeń logicznych. W architekturze trójwarstwowej obsługiwanej przez licznik EQM, adresowania urządzeń logicznych i fizycznych dokonuje się na warstwie MAC (protokół HDLC). Do tego celu służą lower HDLC address (adres fizyczny) oraz upper HDLC address (adres logiczny dla Management Logical Device wynosi on zawsze 1). Oba adresy służą w protokole HDLC do identyfikacji serwera. Obiekty Klasa Register class_id=3 logical_name: octet-string value: zależny od instancji... reset(data,...) Liczydło sumaryczne energii P+ logical_name = [ ] value = Liczydło sumaryczne energii Q+ logical_name = [ ] value = Rysunek 2: Relacja między klasą a obiektami Każdemu urządzeniu logicznemu towarzyszy zbiór obiektów. Dostęp do nich można uzyskać po dokonaniu skojarzenia na warstwie aplikacji COSEM. Obiekty służą do reprezentowania funkcji reali- Strona 3 z 72

5 zowanych przez licznik. Każdy obiekt posiada atrybuty (pola, metody) zawierające różnorakie informacje (stan liczydła, jednostka miary, kod OBIS itp.) lub realizujące jakieś funkcje. Warstwa aplikacji COSEM zapewnia odpowiednie narzędzia pozwalające na korzystanie z owych atrybutów. Obiekty o tej samej strukturze grupowane są w klasy, np. obiekty reprezentujące bieżące liczydła energii, wielkości chwilowe itp. posiadają wspólny interfejs zapewniany przez klasę Register jak pokazuje to rysunek Profil komunikacyjny zastosowany w liczniku EQM Jak wspomniano we wstępie w liczniku EQM wykorzystano trójwarstwową zorientowaną połączeniowo architekturę COSEM. W ramach tej architektury wyróżnia się warstwy widoczne na rysunku 3. Warstwa aplikacji COSEM ACSE xdlms ASE Warstwa LLC (wybór protokołu) Warstwa MAC (HDLC) Warstwa łącza danych Warstwa fizyczna Rysunek 3: Profil komunikacyjny licznika EQM Funkcjonalność warstwy aplikacji podzielona jest na dwie części: ACSE (Association Control Service Element) zapewniająca serwisy potrzebne do skojarzenia aplikacji klienta i serwera (negocjowanie kontekstu aplikacji, negocjowania dostępnych serwisów DLMS, wykonanie uwierzytelniania). Użycie ACSE jest konieczne jedynie na początku sesji komunikacyjnej; xdlms ASE (xdlms Application Service Element) zapewniająca serwisy biorące udział w transmisji danych między aplikacjami klienta i serwera (np. Read, Write itp.). Warstwa łącza danych podzielona jest na dwie podwarstwy: LLC (Logical Link Control) w środowisku COSEM jest ona używana jedynie do wybierania (adresowania) protokołu; MAC (Medium Access Control) bazuje na protokole HDLC. Umożliwia adresowanie urządzeń fizycznych i logicznych, wychwytywanie błędów w transmisji, retransmisję uszkodzonych ramek, segmentację dużych bloków danych itp. Warstwa fizyczna zależna jest od rodzaju interfejsów dostępnych w liczniku. Licznik EQM posiada następujące interfejsy: interfejs optyczny (OPTO) łącze 1, interfejs RS485 lub CLO (pętla prądowa) łącze 2, moduł instalowany w kieszeni licznika łącze 3. Warstwy i protokoły odbierają lub generują właściwe dla siebie jednostki danych (PDU czyli Protocol Data Unit). PDU z warstwy aplikacji, wędrując przez kolejne warstwy, obudowywany jest jednostkami danych wymaganymi przez poszczególne warstwy. Dla przykładu, jeśli aplikacja kliencka Strona 4 z 72

6 chce wysłać żądanie odczytu, np. któregoś z liczydeł energii czynnej, to musi najpierw przygotować stosowną jednostkę danych warstwy aplikacji (A-pdu patrz rysunek 4). W kolejnym kroku PDU warstwy aplikacji musi trafić do warstwy łącza danych (Data Link Layer). W ramach tej warstwy obudowywany jest najpierw przez podwarstwę LLC (Logical Link Control) wynikiem jest L-pdu. L-pdu trafia następnie do podwarstwy MAC (Medium Access Control) i obudowywany jest w ramkę (bądź ramki) protokołu HDLC wynikiem jest M-pdu. Dopiero tak przygotowana informacja trafia do warstwy fizycznej, która sama tworząc Ph-pdu, wysyła ją do serwera. Klient Warstwa aplikacji Klient Warstwa łącza danych Klient Warstwa fizyczna Serwer Warstwa fizyczna Serwer Warstwa łącza danych Serwer Warstwa aplikacji Żądanie A-pdu M-pdu L-pdu A-pdu Ph-pdu M-pdu L-pdu A-pdu Wysyłka danych przez kanał fizyczny M-pdu L-pdu A-pdu A-pdu Wskazanie Rysunek 4: Droga PDU od klienta do serwera Po stronie serwera (licznika) odebrany Ph-pdu jest rozpakowywany przez kolejne warstwy profilu komunikacyjnego, aż dociera do warstwy aplikacji, gdzie zawarta w nim informacja jest interpretowana i powoduje stosowną reakcję serwera. 2.4 Ustalenie połączenia między klientem a serwerem Jeżeli możliwe ma być pozyskanie danych pomiarowych z licznika (serwera), konieczne jest ustanowienie połączenia na wszystkich trzech warstwach profilu komunikacyjnego. Proces ustalania połączenia rozpoczyna się od warstwy fizycznej i musi być przeprowadzony na warstwie łącza danych (szczególnie dotyczy to protokołu HDLC) oraz warstwie aplikacji COSEM (na warstwie aplikacji COSEM zestawienie połączenia nazywa się skojarzeniem aplikacji Application Association). Szczegóły dotyczące łączenia się z licznikiem EQM na różnych warstwach profilu komunikacyjnego umówiono w dalszej części tego dokumentu. Po zakończeniu wymiany danych między klientem a licznikiem, połączenia na wszystkich warstwach należy zakończyć. Strona 5 z 72

7 3 Warstwa fizyczna 3.1 Wprowadzenie Szczegółowe informacje dotyczące serwisów oraz procedur związanych z warstwą fizyczną w zorientowanej połączeniowo asynchronicznej wymianie danych znajdują się w DLMS UA Ed. 7.0 punkt 5. W liczniku EQM bezpośrednio z warstwą fizyczną współpracują dwa protokoły: HDLC omówiony w niniejszym opracowaniu, tekstowy zgodny z PN-EN omówiony w dokumencie TK/2004/028/008. Każdy z tych protokołów korzysta z serwisów udostępnianych przez warstwę fizyczną, obudowujących takie funkcje jak, np. konfiguracja kanału transmisyjnego, jego otwarcie, zamknięcie, wysyłanie i odbieranie danych. W profilu komunikacyjny zaimplementowanym w liczniku EQM możliwe jest dwojakie skorzystanie z warstwy fizycznej, celem uzyskania dostępu do warstw wyższych. Pierwszym sposobem jest po prostu skonfigurowanie i otwarcie kanału transmisyjnego, a następnie rozpoczęcie przesyłania poprzez warstwę fizyczną jednostek danych warstwy wyższej w naszym wypadku ramek protokołu HDLC. Taki scenariusz możliwy jest na łączu 2 i 3 licznika (patrz też punkt 3.3). W drugim sposobie, zanim możliwe będzie przesyłanie przez kanał transmisyjny ramek protokołu HDLC, konieczne jest uzyskanie połączenia na warstwie fizycznej za pośrednictwem protokołu tekstowego zgodnego z PN-EN Zgodnie z normą PN-EN , możliwe jest przy użyciu trybu E wyżej wymienionego protokołu, przejście do protokołu HDLC (patrz punkty 3.3 oraz 3.4). Ten sposób dotyczy wszystkich łączy komunikacyjnych licznika, przy czym obowiązkowy jest na łączu Parametry transmisji Interfejs optyczny (OPTO) łącze 1 Startowy protokół transmisji: tekstowy spełniający zalecenia normy PN-EN Początkowe parametry transmisji: Uwaga: Prędkość początkowa 300 bitów/sekundę Ilość bitów danych 7 Ilość bitów stopu 1 Kontrola parzystości Even Tabela 1: Parametry transmisji dla łącza 1 Prędkość początkowa transmisji na łączu 1 może być zmieniona na wyższą na etapie nawiązywania połączenia pomiędzy licznikiem a klientem w protokole tekstowym zgodnym z PN-EN RS485 lub CLO (pętla prądowa) łącze 2 Startowy protokół transmisji jest zależny od sposobu skonfigurowania licznika. Możliwe są następujące opcje: automatyczna detekcja protokołu (patrz punkt 3.3), protokół zgodny z PN-EN , protokół HDLC. Strona 6 z 72

8 Parametry transmisji w wypadku wyboru protokołu zgodnego z PN-EN : Prędkość programowalna Ilość bitów danych 7 Ilość bitów stopu 1 Kontrola parzystości Even Tabela 2: Parametry transmisji dla łącza 2 protokół zgodny z PN-EN Parametry transmisji w wypadku wyboru protokołu HDLC: Uwaga: Prędkość programowalna Ilość bitów danych 8 Ilość bitów stopu 1 Kontrola parzystości Brak Tabela 3: Parametry transmisji dla łącza 2 protokół HDLC Prędkość transmisji na łączu 2 jest stała (ustalana podczas konfiguracji licznika) i nie ma możliwości zmiany jej po nawiązaniu połączenia pomiędzy licznikiem a klientem Moduł instalowany w kieszeni licznika łącze 3 Startowy protokół transmisji jest zależny sposobu skonfigurowania licznika. Możliwe są następujące opcje: automatyczna detekcja protokołu (patrz punkt 3.3), protokół zgodny z PN-EN , protokół HDLC. Początkowe parametry transmisji w wypadku wyboru protokołu zgodnego z PN-EN : Prędkość początkowa programowalna Ilość bitów danych 7 Ilość bitów stopu 1 Kontrola parzystości Even Tabela 4: Parametry transmisji dla łącza 3 protokół zgodny z PN-EN Parametry transmisji w wypadku wyboru protokołu HDLC: Uwaga: Prędkość programowalna Ilość bitów danych 8 Ilość bitów stopu 1 Kontrola parzystości Brak Tabela 5: Parametry transmisji dla łącza 3 protokół HDLC Prędkość początkowa transmisji na łączu 3 może być zmieniona na wyższą na etapie nawiązywania połączenia pomiędzy licznikiem a klientem w protokole tekstowym zgodnym z PN-EN Strona 7 z 72

9 3.3 Tryb automatycznej detekcji protokołu W wypadku łącza komunikacyjnego 2 i 3 (RS485/CLO i moduł komunikacyjny w kieszeni licznika), licznik EQM może dokonywać automatycznej detekcji protokołu w jakim klient chce realizować transmisję danych. Licznik robi to na podstawie pierwszych odebranych przez siebie PDU warstwy fizycznej. Metodę automatycznej detekcji protokołu ilustruje rysunek 5. Start auto-detekcji NIE Czy licznik odebrał: /?AAA AAAAAAA![CR][LF] AAA AAAAAAA - numer fabryczny licznika TAK NIE Czy licznik odebrał: [7E]... TAK Start trybu PN-EN na okres od 8 do 60 s (timeout określany na etapie konfiguracji) Start trybu HDLC na okres od 8 do 60 s (timeout określany na etapie konfiguracji) Brak aktywności na łączu i upłynął timeout lub wymuszono zerwanie połączenia w którymś z protokołów Rysunek 5: Automatyczna detekcja protokołu 3.4 Tryb E tekstowego protokołu zgodnego z PN-EN Szczegółowe informacje dotyczące trybu E protokołu tekstowego zgodnego z normą PN-EN znajdują się w DLMS UA Ed. 7.0 punkt 6. Punkt ten jest wyciągiem fragmentu normy PN-EN(IEC) Rysunek 6 przedstawia kroki konieczne do uzyskania połączenia na warstwie fizycznej z udziałem protokołu tekstowego. PH-CONNECT.request Klient Warstwa fizyczna (PH-Layer) Ustaw prędkość początkową, 7, E, 1 Wyślij /?AAA AAAAAAA![CR][LF] gdzie AAA AAAAAAA to numer fabryczny licznika Wyślij /POZB\2EQM-VPvv.vv*[CR][LF] gdzie B to identyfikator prędkości proponowanej przez licznik, vv.vv to wersja oprogramowania licznika Ustaw B bodów, 7, E, 1 Wyślij [ACK]2B2[CR][LF] gdzie B to identyfikator prędkości Serwer Warstwa fizyczna (PH-Layer) PH-CONNECT.confirm PH-DATA.request PH-DATA.indication Wyślij [ACK]2B2[CR][LF] gdzie B to identyfikator prędkości Wyślij ramkę warstwy łącza danych Ustaw B bodów, 8, N, 1 Wyślij ramkę warstwy łącza danych PH-CONNECT.indication PH-DATA.indication PH-DATA.request Rysunek 6: Tryb E protokołu tekstowego zgodnego z PN-EN Strona 8 z 72

10 Występujący na rysunku 6 identyfikator prędkości B jest znakiem ASCII, który koduje prędkość łącza szeregowego wyrażoną w bodach. Może on przyjąć następujące wartości: bodów, bodów, bodów, bodów, bodów, bodów, bodów, bodów, bodów, bodów. Wartości od 0 do 6 są jednoznacznie zdefiniowane przez normę PN-EN Pozostałe wartości (od 7 do 9) norma PN-EN rezerwuje do innych zastosowań, natomiast licznik zinterpretuje je zgodnie z niniejszym opisem. Warto w tym miejscu przypomnieć, że łącze 1 i 3 pozwalają na zmianę prędkości na wyższą lub niższą od początkowej na etapie nawiązywania połączenia na warstwie fizycznej (łącze 1 ma prędkość początkową równą 300 bodów, w wypadku łącza 3 prędkość początkowa jest ustalana na etapie konfiguracji licznika). W wypadku łącza 2 nie ma takiej możliwość i prędkość musi pozostać na poziomie ustalonym podczas konfiguracji licznika. Strona 9 z 72

11 4 Warstwa łącza danych 4.1 Wprowadzenie Szczegółowe informacje dotyczące warstwy łącza danych (Data Link Layer), serwisów i procedur związanych z tą warstwą oraz protokołów w niej pracujących, znajdują się DLMS UA Ed. 7.0 punkt 8. Warstwa łącza danych podzielona jest na dwie podwarstwy: LLC (Logical Link Control) używana do wybierania (adresowania) protokołu warstwy aplikacji patrz punkt 4.3; MAC (Medium Access Control) bazuje na protokole HDLC. Umożliwia adresowanie urządzeń fizycznych i logicznych, wychwytywanie błędów w transmisji, retransmisję uszkodzonych ramek, segmentację dużych bloków danych itp. patrz punkt Podwarstwa MAC protokół HDLC Ramka HDLC format 3 Podwarstwa MAC używa ramek HDLC format 3, jak zdefiniowano w Annex H.4 normy ISO/IEC Wygląd tego typu ramki widoczny jest na rysunku 7. Ramki HDLC, które nie posiadają pola informacji, zamiast pól HCS i FCS wyposażone są tylko w pole FCS. Flaga Format ramki Adres docelowy Adres źródłowy Pole kontrolne HCS Informacja FCS Flaga Objaśnienie znaczenia pól ramki HDLC: Rysunek 7: Ramka HDLC format 3 Flaga pole o długości 1 bajta, przyjmujące zawsze wartość 7E H. Pole to rozpoczyna i kończy ramkę; Format ramki pole o długości 2 bajtów (patrz rysunek 8). Zawiera trzy pod-pola: Typ formatu (Format type) ramki cztery bity zawsze przyjmujące wartość 1010 B, S bit segmentacji (jego znaczenie omówione jest w dalszej części tego opracowania), Długość ramki (Frame lenght) długość ramki HDLC (11 bitów) z pominięciem otwierającej i kończącej ramkę flagi 7E H ; MSB S L L L L L L L L L L L LSB Typ formatu Długość ramki Rysunek 8: Pole Format ramki Adres docelowy i adres źródłowy pola o długości 1, 2 lub 4 bajtów (w wypadku licznika EQM 1 lub 4 bajty) służące do adresowania urządzeń fizycznych i logicznych, zarówno po stronie klienta, jak i serwera (licznika). Więcej informacji znajduje się w punkcie 4.2.2; Pole kontrolne (Control) pole o długości 1 bajta. Służy do określania typu ramki HDLC oraz zawiera numery sekwencji przydzielanych ramkom typu I, RR i RNR. Więcej informacji znajduje się w punkcie 4.2.3; HCS (Header check sequence) pole o długości 2 bajtów. Zawiera sumę kontrolną dotyczącą tylko nagłówka ramki HDLC. Suma kontrolna liczona jest z bajtów mieszczących się między flagą rozpoczynającą ramkę (7E H ) a polem HCS. Algorytm wyznaczania sumy kontrolnej znajduje się w DLMS UA Ed. 7.0 punkt 8.5. Jeżeli ramka nie posiada pola informacji lub jest ono puste, to ramka nie posiada pola HCS lecz tylko FCS; Strona 10 z 72

12 Informacja (Information) pole zawierające sekwencję bajtów o długości ograniczonej maksymalną długości całej ramki HDLC (patrz pole Format ramki ). W wypadku ramki typu I w polu tym transportowane są dane pochodzące z warstw wyższych; FCS (Frame check sequence) pole o długości 2 bajtów. Zawiera sumę kontrolną dla całej ramki HDLC. Suma kontrolna liczona jest z bajtów mieszczących się między flagą rozpoczynającą ramkę (7E H ) a polem FCS. Algorytm wyznaczania sumy kontrolnej znajduje się w DLMS UA Ed. 7.0 punkt Adresowanie w protokole HDLC Ramka HDLC format 3 posiada dwa pola adresowe: docelowy oraz źródłowy adres HDLC. W zależności od kierunku przesyłania ramki HDLC, zarówno adres klienta jak i serwera może być adresem docelowym lub źródłowym. Jak opisano to w normie ISO/IEC punkt 4.7.1, pole adresu może być rozszerzane od 1 do n bajtów. Osiągnięto to poprzez zarezerwowanie najmłodszego bitu każdego z bajtów adresu, na flagę mówiącą o tym czy należy spodziewać się kolejnego bajtu wchodzącego w skład pola adresu (wartość bitu wynosi 0), czy jest to ostatni bajt pola adresu (wartość bitu wynosi 1). W związku z tym na jednym bajcie można zakodować adresy z zakresu 00 H 7F H, z kolei na dwóch bajtach, adresy z zakresu 0000 H 3FFF H. Adres klienta wyrażany jest zawsze na jednym bajcie. W profilu komunikacyjnym zastosowanym w liczniku EQM, wymagane jest by adres klienta wynosił zawsze 10 H (adres zarezerwowany dla Public Client). W liczniku EQM adres serwera wyrażany jest na jednym lub czterech bajtach patrz rysunek 9 (DLMS UA Ed. 7.0 punkt mówi także o adresie serwera składającym się z dwóch bajtów). W wypadku użycia jedno-bajtowego adresu serwera, adresowane jest jedynie urządzenie logiczne LSB Upper HDLC address 1 LSB LSB LSB LSB Upper HDLC address 0 Upper HDLC address 0 Lower HDLC address 0 Lower HDLC address 1 Rysunek 9: Struktury adresów obsługiwanych przez licznik EQM (Upper HDLC address). Jeśli używane są adresy cztero-bajtowe, wtedy dwa młodsze bajty adresują urządzenie fizyczne (Lower HDLC address), z kolei dwa starsze urządzenie logiczne (Upper HDLC address). Adres fizyczny licznika EQM może być ustalony na etapie konfiguracji lub posiadać wartość domyślną bazującą na numerze fabrycznym licznika. W drugim wypadku adres ustalany jest w sposób pokazany na rysunku 10. W polu Typ licznika umieszczany jest identyfikator licznika (w wypadku Typ licznika Wartość określana na podstawie numeru licznika Rysunek 10: Adres fizyczny bazujący na numerze fabrycznym licznika licznika EQM jest to wartość 000 B ). Wartość pola Wartość określana na podstawie... określana jest jako suma liczby złożonej z trzech ostatnich (najmłodszych) cyfr numeru fabrycznego oraz liczby 16. Dodanie liczby 16 wynika z potrzeby ominięcia adresów zarezerwowanych (0000 H 000F H ). Zakładając, że licznik ma numer fabryczny , to trzy najmłodsze cyfry tego numeru tworzą liczbę 833. Po dodaniu do 833 liczby 16 otrzymujemy wynik 849, a szesnastkowo 0351 H. Otrzymaną wartość należy umieścić w polu Wartość określana na podstawie... adresu fizycznego. Dla licznika EQM pole Typ licznika jest równe 000 B, więc nie ma wpływu na wartość adresu fizycznego. Umieszczając wyliczony adres fizyczny (szesnastkowo 0351 H ) w ramce HDLC w wyniku otrzymujemy wartość 0CA3 H patrz rysunek 11. Strona 11 z 72

13 LSB LSB LSB LSB Upper HDLC address 0 Upper HDLC address Lower HDLC address: 0351 H B Rysunek 11: Przykład prezentacji adresu fizycznego 0351 H w ramce HDLC Jeżeli konieczna jest zmiana domyślnego adresu fizycznego na określony samodzielnie, należy pamiętać aby jego wartość nie należała do zbioru zarezerwowanych dolnych (lower) adresów HDLC. Tabele 6 i 7 prezentują zarezerwowane adresy HDLC. Zarezerwowane adresy HDLC 00 H No-station 01 H Client Management Process 10 H Public Client Tabela 6: Zarezerwowane adresy klienta Zarezerwowane górne (upper) adresy HDLC 0000 H No-station 0001 H Management Logical Device 0002 H 000F H Zarezerwowane do przyszłych zastosowań 3FFF H All-station (Broadcast) Zarezerwowane dolne (lower) adresy HDLC 0000 H No-station 0001 H 000F H Zarezerwowane do przyszłych zastosowań 3FFE H CALLING Physical Device 3FFF H All-station (Broadcast) Tabela 7: Zarezerwowane adresy serwera Licznik EQM posiada tylko jedno urządzenie logiczne Management Logical Device. Adres tego urządzenia jest określony w tabeli zarezerwowanych górnych (upper) adresów serwera i wynosi zawsze 0001 H Typy ramek HDLC Typ ramki określany jest za pomocą pola Pole kontrolne ramki HDLC (patrz rysunek 7). Wartości jakie przyjmuje to pole określone są w tabeli 8 (tabela 8 uwzględnia tylko typy ramek obsługiwane przez licznik EQM). Szczegółowy opis typów ramek znajduje się w DLMS UA Ed. 7.0 punkt Komenda Odpowiedź Pole kontrolne (bitowo) I I R R R P/F S S S 0 RR RR R R R P/F RNR RNR R R R P/F SNRM P DISC P UA F DM F FRMR F Tabela 8: Typy ramek i przypisane im wartości pola kontrolnego Bity RRR oznaczają 3-bitowy numer porządkowy odebranych ramek I (w skrócie N(R)). Bity SSS oznaczają 3-bitowy numer porządkowy wysłanych ramek I (w skrócie N(S)). Bit P/F (poll/final) pełni Strona 12 z 72

14 rolę flagi, która zapalona po stronie klienta oznacza zakończenie wysyłania komend(y), a po stronie serwera zakończenie wysyłania odpowiedzi. Komendy wysyła tylko klient, z kolei ramki odpowiedzi są domeną serwera HDLC (licznika). W wypadku licznika EQM bit P/F zawsze przyjmuje wartość 1. Dzieje się tak dlatego, że licznik obsługuje transmisję z rozmiarem okna (window size) wynoszącym 1. Więcej informacji na ten temat można znaleźć w DLMS UA Ed. 7.0 punktach oraz Ramka typu I (Information). Służy do transportu informacji generowanych przez warstwy wyższe (w naszym wypadku LLC i COSEM). Każda ramka I posiada dwa numery porządkowe: N(S), który jest numerem porządkowym przypisany do ramki I; N(R), który jest numerem porządkowym następnej spodziewanej ramki I, która ma być odebrana. Numer ten oznacza też, że poprzednio odebrane ramki I o numerach do N(R) 1 włącznie są poprawne. Domyślna maksymalna długość pola informacji dla ramek odbieranych i wysyłanych wynosi 128 bajtów. Inne wartości mogą być negocjowane na etapie zestawiania połączenia (patrz DLMS UA Ed. 7.0 punkt ). Ramka typu RR (Receive Ready). Służy do wskazania, że serwer (licznik) albo klient gotowy jest do odbierania ramek I. Zawiera także numer porządkowy N(R), służący do potwierdzania, że poprzednio odebrane ramki I o numerach do N(R) 1 włącznie są poprawne. Ramka typu RNR (Receive Not Ready). Służy do wskazania, że serwer (licznik) albo klient nie może aktualnie odbierać ramek I. Zawiera także numer porządkowy N(R), służący do potwierdzania, że poprzednio odebrane ramki I o numerach do N(R) 1 włącznie są poprawne. Ramka typu SNRM (Set Normal Response Mode). Jest to komenda służąca do ustawienia zaadresowanego serwera HDLC w tryb Normal Response Mode (NRM). Odpowiada to uzyskaniu połączenia na warstwie łącza danych. Po odebraniu ramki SNRM i zaakceptowaniu jej, serwer odpowiada ramką UA oraz zeruje zmienne V(R) i V(S) służące do nadawania numerów porządkowych N(R) i N(S) ramkom I. Ramka SNRM może zawierać opcjonalnie pole informacji. Jego zawartość służy do negocjowania parametrów połączenia (więcej informacji znajduje się w DLMS UA Ed. 7.0 w punktach i ). Ramka typu DISC (DISConnect). Jest to komenda służąca do zerwania połączenia na warstwie łącza danych. Po jej odebraniu serwer odpowiada ramką UA (jeśli jest w trybie NRM) i przechodzi w tryb Normal Disconnect Mode (NDM). Skutkuje to tym, że serwer na wszystkie komendy oprócz SNRM odpowiada ramką DM. Ramka DISC może zawierać pole informacji, które jest jednak ignorowane przez licznik EQM. Ramka typu UA (Unnumbered Acknowledge). Jest to odpowiedź generowana przez serwer HDLC (licznik) w wypadku odebrania i zaakceptowania komend SNRM i DISC. Ramka UA zawiera pole informacji używane do negocjowania parametrów połączenia (więcej informacji znajduje się w DLMS UA Ed. 7.0 punkt ). Ramka typu DM (Disconnected Mode). Jest odpowiedź generowana przez serwer HDLC (licznik) w wypadku gdy jest on w trybie Normal Disconnect Mode (NDM). Odpowiada to stanowi braku połączenia na warstwie łącza danych. W trybie NDM serwer na wszystkie komendy oprócz SNRM odpowiada ramką DM. Strona 13 z 72

15 Ramka typu FRMR (FRaMe Reject). Jest to odpowiedź generowana przez serwer HDLC (licznik) w wypadku wykrycia błędu spowodowanego jednym z następujących powodów: odebraniem niezdefiniowanej lub niezaimplementowanej komendy bądź odpowiedzi; odebraniem ramki I zawierającej zbyt długie pole informacji (przekraczające rozmiar wynegocjowany przy zestawianiu połączenia); odebraniem ramki zawierającej niepoprawny numer porządkowy N(R), np. N(R) identyfikujący ramkę I, która poprzednio została wysłana i potwierdzona lub ramkę I, która jeszcze nie została wysłana i nie jest następną w kolejce do wysyłki; odebraniem ramki, która posiada pole informacji choć specyfikacja protokołu tego nie przewiduje. Ramka FRMR zawiera pole informacji, które zapewnia informację o powodzie odrzucenia ramki. Sposób kodowania zawartości pola informacji opisano w ISO/IEC 13239:2002(E) punkt Kolejność wysyłania bitów i bajtów w ramce HDLC Wszystkie bajty wchodzące w skład ramki HDLC należy wysyłać z najmniej znaczącym bitem jako pierwszym. Pola ramki HDLC, które zajmują więcej niż jeden bajt powinny być wysyłane z najbardziej znaczącym bajtem jako pierwszym. Kolejność wysyłania poszczególnych pól ramki, zgodnie z rysunkiem 7 (strona 10), jest określona jako od lewej do prawej Zestawienie połączenia Aby możliwe było przystąpienie do łączenia się na warstwie łącza danych, trzeba wpierw uzyskać połączenie na warstwie fizycznej. Po spełnieniu tego warunku zarówno klient jak i serwer HDLC są w trybie NDM. W następnym kroku klient HDLC wysyła do serwera HDLC (licznika) komendę SNRM. Serwer, po zaakceptowaniu komendy, odpowiada ramką UA, przechodzi w tryb NRM oraz zeruje zmienne V(R) i V(S) służące do nadawania numerów porządkowych N(R) i N(S) ramkom I. Klient po zaakceptowaniu odpowiedzi UA również przechodzi w tryb NRM i zeruje swoje zmienne V(R) i V(S). Tabela 9 oraz 10 zawierają przykłady ramek HDLC wymienianych podczas łączenia się z licznikiem o adresie fizycznym 03BA H. Flaga Format Adr. doc. Adr. źródł. Kontrola HCS Informacja FCS Flaga SNRM 7E A00A 00020E A 7E UA 7E A E B Tabela 9: Przykład połączenia na HDLC bez negocjacji parametrów łącza danych 7E Flaga Format Adr. doc. Adr. źródł. Kontrola HCS Informacja FCS Flaga SNRM 7E A E F E UA 7E A E B667 7E Tabela 10: Przykład połączenia w HDLC z negocjacją parametrów łącza danych Strona 14 z 72

16 Tabela 9 pokazuje przykład nawiązywania połączenia, w którym klient nie podejmuje próby negocjacji parametrów łącza danych. W takim wypadku klient zmuszony jest zaakceptować parametry jakie narzuci mu serwer, czyli wartości domyślne przyjmowane przez licznik EQM. Domyślne parametry łącza danych dla licznika EQM przyjmują następujące wartości: maksymalna długość pola informacji, kierunek nadawanie 128 bajtów, maksymalna długość pola informacji, kierunek odbiór 128 bajtów, rozmiar okna, kierunek nadawanie 1 ramka, rozmiar okna, kierunek odbiór 1 ramka. W tabeli 10 widać z kolei przykład negocjowania przez klienta parametrów łącza danych. Materiałem wyjściowym w negocjacji są parametry domyślne właściwe dla licznika EQM (podane wyżej). W omawianym przykładzie klient proponuje następujące warunki połączenia (pole informacji ramki SNRM): maksymalna długość pola informacji, kierunek nadawanie 64 bajty, maksymalna długość pola informacji, kierunek odbiór 96 bajtów, rozmiar okna, kierunek nadawanie 1 ramka, rozmiar okna, kierunek odbiór 1 ramka. Wynikiem negocjacji są warunki połączenia określone przez licznik (pole informacji ramki UA): maksymalna długość pola informacji, kierunek nadawanie 96 bajtów, maksymalna długość pola informacji, kierunek odbiór 64 bajty, rozmiar okna, kierunek nadawanie 1 ramka, rozmiar okna, kierunek odbiór 1 ramka. Należy pamiętać, że wynik negocjacji podany w ramce UA jest właściwy dla punktu widzenia serwera (licznika). Dlatego klient musi przyjąć parametry dla kierunku nadawanie z ramki UA, jako swoje dla kierunku odbiór. Analogicznie należy postąpić z parametrami dla kierunku odbiór pochodzącymi z ramki UA. Uwaga: W liczniku EQM nie ma możliwości wynegocjowania rozmiaru okna większego niż 1. Sposób kodowania pola informacji zawierającego parametry łącza danych dla ramek SNRM i UA opisany jest w w DLMS UA Ed. 7.0 punkt Zakończenie połączenia Zakończenie połączenia na warstwie łącza danych inicjuje klient. Dokonuje tego poprzez wysłanie do serwera ramki DISC. Serwer po zaakceptowaniu ramki DISC, w odpowiedzi odsyła ramkę UA (jeśli był w trybie NRM) i przechodzi do trybu NDM. Podobnie klient po odebraniu i zaakceptowaniu ramki UA przechodzi do trybu NDM. Flaga Format Adr. doc. Adr. źródł. Kontrola HCS Informacja FCS Flaga DISC 7E A00A 00020E C4C 7E UA 7E A E Tabela 11: Przykład zakończenia połączenia w HDLC W tabeli 11 zaprezentowano przykład wymiany ramek DISC i UA między klientem a licznikiem o adresie fizycznym 03BA H. 533B 7E Strona 15 z 72

17 Uwaga: W trójwarstwowej zorientowanej połączeniowo architekturze COSEM zerwanie połączenia na warstwie łącza danych jest równoznaczne ze zwolnieniem skojarzenia na warstwie aplikacji COSEM Brak aktywności na łączu Uzyskanie połączenia na warstwie łącza danych powoduje uruchomienie mechanizmu timeoutu, który odpowiada za przejście serwera (licznika) do trybu NDM (zerwanie połączenia) w przypadku braku aktywności na łączu. Ilość czasu potrzebna do wystąpienia zdarzenia timeoutu określana jest na etapie konfiguracji licznika. W wypadku licznika EQM może on przyjmować wartość od 8 do 60 sekund. Mechanizm timeoutu resetowany jest po odebraniu ramki HDLC adresowanej do licznika. Kiedy klient nie dokonuje odczytu danych i chce podtrzymać połączenie, może do tego celu użyć ramki RR Wymiana danych Do transportu informacji używane są ramki I. Każda ramka I posiada numery porządkowe N(R) i N(S), używane do potwierdzania transferu informacji. Z punktu widzenia warstw wyższych, odpowiadające im PDU mogą nie mieścić się w jednej ramce HDLC. Z tego względu protokół przewiduje mechanizm segmentacji. Odpowiada za niego bit S w polu Format ramki patrz rysunek 8 na stronie 10. Poniżej prezentowane przykłady transferu informacji wyjaśniają sposób korzystania z tego mechanizmu. Notacja stosowana w przykładach transferu danych: ramka z informacją, = ramka bez informacji, P lub F bit pool/final, [n,n] wartości N(S) i N(R), [n] wartość N(R), S bit segmentacji. Przykłady transferu danych bez segmentacji. Klient Połączenie SNRM, P = Serwer = UA, F Potwierdzenie połączenia Żądanie 1 z warstw wyższych I[0,0], P, S=0 I[0,1], F, S=0 Odpowiedź 1 z warstw wyższych Żądanie 2 z warstw wyższych I[1,1], P, S=0 I[1,2], F, S=0 Odpowiedź 2 z warstw wyższych Rysunek 12: Połączenie i dwa żądania warstw wyższych i odpowiedzi na nie, bez segmentacji Klient Żądanie 1 z warstw wyższych I[0,0], P, S=0 I[0,1], F, S=0 Serwer Odpowiedź 1 z warstw wyższych Potwierdzenie RR[1], P = = RR[1], F Potwierdzenie Rozłączenie DISC, P = = UA, F Potwierdzenie rozłączenia Rysunek 13: Żądanie warstw wyższych i odpowiedź na nie, bez segmentacji oraz rozłączenie Strona 16 z 72

18 Klient Żądanie 1 z warstw wyższych I[0,0], P, S=0 I[0,1], F, S=0 Serwer Odpowiedź 1 z warstw wyższych Żądanie retransmisji RR[0], P = I[0,1], F, S=0 Odpowiedź 1 z warstw wyższych Potwierdzenie RR[1], P = = RR[1], F Potwierdzenie Rysunek 14: Żądanie warstw wyższych i odpowiedź na nie, bez segmentacji oraz z retransmisją Przykłady transferu danych z segmentacją. Klient Żądanie 1 z warstw wyższych I[0,0], P, S=0 Serwer I[0,1], F, S=1 Odpowiedź 1 z warstw wyższych, fragment 1 Potwierdzenie RR[1], P = I[1,1], F, S=1 Odpowiedź 1 z warstw wyższych, fragment 2 Potwierdzenie RR[2], P = I[2,1], F, S=0 Odpowiedź 1 z warstw wyższych, fragment 3 Potwierdzenie RR[3], P = = RR[1], F Potwierdzenie Rysunek 15: Żądanie warstw wyższych i odpowiedź na nie, z segmentacją Klient Żądanie 1 z warstw wyższych, fragment 1 I[0,0], P, S=1 Serwer = RR[1], F Potwierdzenie Żądanie 1 z warstw wyższych, fragment 2 I[1,0], P, S=0 Potwierdzenie RR[1], P = Potwierdzenie RR[2], P = Potwierdzenie RR[3], P = I[0,2], F, S=1 Odpowiedź 1 z warstw wyższych, fragment 1 I[1,2], F, S=1 Odpowiedź 1 z warstw wyższych, fragment 2 I[2,2], F, S=0 Odpowiedź 1 z warstw wyższych, fragment 3 = RR[2], F Potwierdzenie Rysunek 16: Żądanie warstw wyższych i odpowiedź na nie, z segmentacją Więcej informacji na temat wymiany danych w protokole HDLC znajduje się w DLMS UA Ed. 7.0 punkt Obsługa sytuacji wyjątkowych w liczniku EQM Zbyt długi czas między odbieranymi bajtami (inter-octet timeout). W liczniku EQM maksymalny czas między odbieranymi bajtami wchodzącymi w skład ramki wynosi 50 ms. Jeżeli w trakcie Strona 17 z 72

19 kompletowania ramki, w którymś momencie ten czas zostanie przekroczony, to taka ramka zostaje porzucona. Brak flagi rozpoczynającej lub kończącej ramkę. taką ramkę. W takim wypadku licznik EQM porzuca Nieprawidłowy format ramki. Jeżeli licznik EQM wykryje w polu format ramki niewłaściwy typ formatu (patrz rysunek 8), to taka ramka zostanie porzucona. Nieprawidłowa suma kontrolna FCS lub HCS. Jeżeli licznik EQM wykryje błąd którejś z wyżej wymienionych sum kontrolnych, to taką ramkę porzuca. Adres źródłowy dłuższy niż jeden bajt. porzuca taką ramkę. Po wykryciu takiej nieprawidłowości licznik EQM Adres źródłowy ma wartość inną niż 10 H (public client). licznik EQM porzuca taką ramkę. Po wykryciu takiej nieprawidłowości Nie zapalony bit P/F w polu kontrolnym. tabela 8). W takiej sytuacji licznik EQM porzuca ramkę (patrz Niewłaściwie sformatowane parametry HDLC w ramce SNRM. W takim przypadku licznik EQM nie podejmuje próby negocjacji błędnie zakodowanych parametrów i w ramce UA odpowiada parametrami domyślnymi. Przekroczenie wynegocjowanego maksymalnego rozmiaru pola informacji. Licznik w odpowiedzi na taką ramkę wysyła ramkę FRMR, która w polu informacji raportuje ten rodzaj błędu (patrz ISO/IEC 13239:2002(E) punkt ). Taka reakcja licznika będzie miała miejsce gdy przekroczenie rozmiaru pola informacji pozwoli na zmieszczenie całej ramki HDLC w buforze o rozmiarze 145 bajtów. Gdy ten warunek nie zostanie spełniony licznik porzuci taką ramkę. Uwaga: Zaleca się by po odebraniu ramki FRMR klient HDLC wydał polecenie SNRM przed kontynuowaniem wymiany danych. Uwaga ta ma zastosowanie w każdej następnej sytuacji wyjątkowej, w której serwer wysyła ramkę FRMR. Odebrana ramka posiada pole informacji choć nie powinna. Dotyczy to np. ramek RR i RNR. Licznik w odpowiedzi wysyła ramkę FRMR, która w polu informacji raportuje ten rodzaj błędu (patrz ISO/IEC 13239:2002(E) punkt ). Odebrana ramka nieznanego lub nieobsługiwanego typu. Dotyczy to np. ramki typu UI, której licznik EQM nie obsługuje lub nieznanej kombinacji bitów w polu kontrolnym. Licznik w odpowiedzi wysyła ramkę FRMR, która w polu informacji raportuje ten rodzaj błędu (patrz ISO/IEC 13239:2002(E) punkt ). Odebranie ramki z niepoprawnym numerem porządkowym N(R). Sytuacja dotyczy N(R) identyfikującego ramkę I, która poprzednio została wysłana i potwierdzona lub ramkę I, która jeszcze nie została wysłana i nie jest następną w kolejce do wysyłki. Licznik w odpowiedzi wysyła ramkę FRMR, która w polu informacji raportuje ten rodzaj błędu (patrz ISO/IEC 13239:2002(E) punkt ). Strona 18 z 72

20 Odebranie ramki I z nieprawidłowym numerem porządkowym N(S). Sytuacja taka jest rozpatrywana jeśli odebrana ramka ma prawidłowy numer porządkowy N(R). Jeżeli odebrana ramka jest opatrzona numerem N(S) wskazującym na ostatnio potwierdzoną ramkę I, to licznik ponownie wysyła ostatnią ramkę I (jeśli istnieje w buforze warstwy fizycznej). W każdym innym przypadku licznik EQM odpowiada ramką RR z N(R) wskazującym klientowi jak ma ustawić swoją zmienną V(S), żeby przywrócić prawidłową wartość N(S) Zachowanie protokołu HDLC podczas długiego przygotowywania danych W pewnych okolicznościach uzyskanie odpowiedzi z licznika może zająć pewien czas. Implementacja protokołu HDLC po stronie klienta zapewne przewiduje timeout w jakim licznik ma odpowiedzieć na żądanie danych. Jeżeli czas przygotowywania danych przez licznik przekracza ten timeout, klient może próbować ustalić co się dzieje z licznikiem (serwerem). W takim wypadku, zachowanie klienta w odniesieniu do licznika EQM obrazuje rysunek 17. Klient Serwer Żądanie 1 z warstw wyższych I[0,0], P, S=0 Rozpoczęte przygotowywanie danych Wystąpił timeout RR[0], P = = RR[1], P RR[0], P = = RR[1], P RR[0], P = Dane przygotowane Potwierdzenie RR[1], P = Potwierdzenie RR[2], P = Potwierdzenie RR[3], P = I[0,1], F, S=1 Odpowiedź 1 z warstw wyższych, fragment 1 I[1,1], F, S=1 Odpowiedź 1 z warstw wyższych, fragment 2 I[2,1], F, S=0 Odpowiedź 1 z warstw wyższych, fragment 3 = RR[1], F Potwierdzenie Rysunek 17: Zachowanie licznika EQM podczas długiego przygotowywania danych Istnieje ryzyko wystąpienia kolizji na warstwie fizycznej, w przypadku gdy klient rozpocznie wysyłanie ramki RR, a w tym samym czasie serwer ma już przygotowane dane i również rozpoczął ich wysyłkę. W takiej sytuacji klient powinien jeszcze raz wysłać ramkę RR z numerem N(R), wskazującym na utraconą w wyniku kolizji ramkę I. 4.3 Podwarstwa LLC specyfikacja protokołu Podwarstwa LLC (Logical Link Control) używana jest do wybierania (adresowania) protokołu warstwy aplikacji. Omówiona została w DLMS UA Ed. 7.0 punkt 8.3. Jednostka danych (PDU) tej warstwy zbudowana jest z trzech bajtów nagłówka i ciągu bajtów stanowiącego przenoszoną informację warstw wyższych (warstwy aplikacji COSEM). Rysunek 18 obrazuje szczegóły budowy PDU warstwy LLC. Docelowe LSAP Źródłowe LSAP LLC quality Informacja 8 bitów: E6 H 8 bitów: E6 H lub E7 H 8 bitów: 00 H n * 8 bitów Rysunek 18: PDU podwarstwy LLC Strona 19 z 72

21 Objaśnienie znaczenia pól PDU podwarstwy LLC: Docelowe LSAP (LLC sublayer Service Access Point) przyjmuje zawsze wartość E6 H ; Źródłowe LSAP przyjmuje wartość E6 H lub E7 H. Najmłodszy bit jest używany jako identyfikator komendy/odpowiedzi: 0 oznacza komendę i 1 oznacza odpowiedź; LLC quality jest zarezerwowany do przyszłych zastosowań. Musi zawsze być ustawiony na 00 H ; Informacja pole zawierające ciąg bajtów reprezentujący PDU warstwy aplikacji. Jeżeli serwer (licznik) odbierze PDU podwarstwy LLC z właściwymi adresami (docelowe LSAP: E6 H, źródłowe LSAP: E6 H ), to przekazuje zawartość pola informacji do warstwy aplikacji COSEM. Jeżeli serwer poprawnie zdekoduje żądanie warstwy aplikacji i przygotuje odpowiedź, to umieszcza ją w PDU podwarstwy LLC, nadając mu adresy: docelowe LSAP: E6 H, źródłowe LSAP: E7 H. Jeżeli serwer odbierze PDU podwarstwy LLC z błędnymi adresami, to zostaje on porzucony. Strona 20 z 72

22 5 Warstwa aplikacji COSEM 5.1 Wprowadzenie Szczegółowy opis dotyczący warstwy aplikacji COSEM oraz serwisów i procedur z nią związanych, znajduje się w DLMS UA Ed. 7.0 punkt 9. Opis dotyczący klas obiektów COSEM, typów danych w nich użytych oraz kodów OBIS identyfikujących obiekty, znajduje się w DLMS UA Ed Struktura warstwy aplikacji COSEM Funkcjonalność warstwy aplikacji podzielona jest na dwie części (patrz rysunek 19): ACSE (Association Control Service Element) zapewniająca serwisy potrzebne do skojarzenia między aplikacjami klienta i serwera; xdlms ASE (xdlms Application Service Element) zapewniająca serwisy biorące udział w transmisji danych między aplikacjami klienta i serwera (choć nie tylko). Warstwa aplikacji COSEM ACSE xdlms ASE Rysunek 19: Składowe warstwy aplikacji COSEM Niniejsze opracowanie zawiera jedynie opis serwisów zaimplementowanych w liczniku EQM. Do opisu jednostek danych warstwy aplikacji (APDU) generowanych przez te serwisy został użyty język ASN.1, którego specyfikację zawiera ISO/IEC :2002(E). Tworzenie APDU, na podstawie opisu w ASN.1, odbywa się w oparciu dwa sposoby kodowania: BER (opisany w ISO/IEC :2002(E)) lub A-XDR (opisany w IEC Ed. 1.0:2000). Kodowanie BER używane jest do generowania APDU serwisów wchodzących w skład ACSE. Kodowanie A-XDR stosowane jest natomiast w wypadku tworzenia APDU serwisów pochodzących z xdlms ASE Serwisy ACSE (Association Control Service Element) APDU serwisów wchodzących w skład ACSE prezentowane są w poniższym fragmencie kodu ASN.1. XDLMS-APDU ::= CHOICE the four ACSE APDUs aarq AARQ-apdu, aare AARE-apdu, rlrq RLRQ-apdu, -- OPTIONAL rlre RLRE-apdu, -- OPTIONAL... Serwis COSEM-OPEN. Zadanie serwisu COSEM-OPEN sprowadza się do skojarzenia (połączenia) aplikacji serwera i klienta. Jednostki danych generowane przez ten serwis to AARQ (Application Associate Request) i AARE (Application Associate Response). Strona 21 z 72

23 AARQ jest żądaniem generowanym przez aplikację klienta. Służy on do rozpoczęcia procedury kojarzenia aplikacji klienta i serwera (licznika). Poniżej przedstawiony kod ASN.1 opisuje budowę AARQ oraz towarzyszące mu typy danych. AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE -- [APPLICATION 0] == [ 60H ] = [ 96 ] protocol-version [0] IMPLICIT BIT STRING version1 (0) DEFAULT version1, application-context-name [1] Application-context-name, called-ap-title [2] AP-title OPTIONAL, called-ae-qualifier [3] AE-qualifier OPTIONAL, called-ap-invocation-id [4] AP-invocation-identifier OPTIONAL, called-ae-invocation-id [5] AE-invocation-identifier OPTIONAL, calling-ap-title [6] AP-title OPTIONAL, calling-ae-qualifier [7] AE-qualifier OPTIONAL, calling-ap-invocation-id [8] AP-invocation-identifier OPTIONAL, calling-ae-invocation-id [9] AE-invocation-identifier OPTIONAL, -- The following field shall not be present if only the kernel is used. sender-acse-requirements [10] IMPLICIT ACSE-requirements OPTIONAL, -- The following field shall only be present if the authentication functional unit is selected. mechanism-name [11] IMPLICIT Mechanism-name OPTIONAL, -- The following field shall only be present if the authentication functional unit is selected. calling-authentication-value [12] EXPLICIT Authentication-value OPTIONAL, implementation-information [29] IMPLICIT Implementation-data OPTIONAL, user-information [30] EXPLICIT Association-information OPTIONAL -- types used in the fields of the ACSE APDUs, in the order of their occurrence Application-context-name ::= OBJECT IDENTIFIER AP-title ::= OCTET STRING AE-qualifier ::= OCTET STRING AP-invocation-identifier ::= INTEGER AE-invocation-identifier ::= INTEGER ACSE-requirements ::= BIT STRING authentication(0) Mechanism-name ::= OBJECT IDENTIFIER Authentication-value ::= CHOICE charstring bitstring external other other-mechanism-name other-mechanism-value [0] IMPLICIT GraphicString, [1] IMPLICIT BIT STRING, [2] IMPLICIT EXTERNAL, [3] IMPLICIT SEQUENCE Mechanism-name, ANY DEFINED BY other-mechanism-name Implementation-data ::= GraphicString Association-information ::= OCTET STRING Opis żądania AARQ w kontekście licznika EQM oraz przykłady kodowania tego APDU znajdują się w punkcie AARE stanowi odpowiedź na żądanie AARQ i jest generowany przez aplikację serwera. APDU to kończy procedurę kojarzenia aplikacji klienta i serwera. Informacje w nim zawarte wskazują czy aplikacje serwera i klienta poprawnie się skojarzyły (połączyły), czy może z jakiegoś powodu jest to niemożliwe. Poniżej przedstawiony kod ASN.1 opisuje budowę AARE oraz towarzyszące mu typy danych. -- The user-information field shall carry an InitiateRequest APDU encoded in A-XDR, and then -- encoding the resulting OCTET STRING in BER. Strona 22 z 72

24 AARE-apdu ::= [APPLICATION 1] IMPLICIT SEQUENCE -- [APPLICATION 1] == [ 61H ] = [ 97 ] protocol-version [0] IMPLICIT BIT STRING version1 (0) DEFAULT version1, application-context-name [1] Application-context-name, result [2] Association-result, result-source-diagnostic [3] Associate-source-diagnostic, responding-ap-title [4] AP-title OPTIONAL, responding-ae-qualifier [5] AE-qualifier OPTIONAL, responding-ap-invocation-id [6] AP-invocation-identifier OPTIONAL, responding-ae-invocation-id [7] AE-invocation-identifier OPTIONAL, -- The following field shall not be present if only the kernel is used. responder-acse-requirements [8] IMPLICIT ACSE-requirements OPTIONAL, -- The following field shall only be present if the authentication functional unit is selected. mechanism-name [9] IMPLICIT Mechanism-name OPTIONAL, -- The following field shall only be present if the authentication functional unit is selected. responding-authentication-value [10] EXPLICIT Authentication-value OPTIONAL, implementation-information [29] IMPLICIT Implementation-data OPTIONAL, user-information [30] EXPLICIT Association-information OPTIONAL Association-result ::= INTEGER accepted (0), rejected-permanent (1), rejected-transient (2) Associate-source-diagnostic ::= CHOICE acse-service-user [1] INTEGER null (0), no-reason-given (1), application-context-name-not-supported (2), authentication-mechanism-name-not-recognised (11), authentication-mechanism-name-required (12), authentication-failure (13), authentication-required (14), acse-service-provider null (0), no-reason-given (1), no-common-acse-version (2) [2] INTEGER Opis odpowiedzi AARE w kontekście licznika EQM oraz przykłady kodowania tego APDU znajdują się w punkcie Serwis COSEM-RELEASE. W liczniku EQM nie zaimplementowano obsługi serwisu COSEM- RELEASE służącego do zwalniania skojarzenia (połączenia) aplikacji klienta i serwera. APDU serwisu COSEM-RELEASE, czyli RLRQ (Application Release Request) i RLRE (Application Release Response) nie są obsługiwane. W trójwarstwowej zorientowanej połączeniowo architekturze COSEM zerwanie połączenia na warstwie łącza danych jest równoznaczne ze zwolnieniem skojarzenia na warstwie aplikacji COSEM Serwisy xdlms ASE (xdlms Application Service Element) APDU serwisów wchodzących w skład xdlms ASE i obsługiwanych przez licznik EQM prezentowane są w następującym fragmencie kodu ASN.1. Strona 23 z 72