POLITECHNIKA ŚLĄSKA WYDZIAŁ AUTOMATYKI, ELEKTRONIKI I INFORMATYKI. Protokół M-Bus

POLITECHNIKA ŚLĄSKA WYDZIAŁ AUTOMATYKI, ELEKTRONIKI I INFORMATYKI Protokół M-Bus

1 Opis protokołu Protokół M-Bus został stworzony przez profesora Uniwersytetu w Paderbornie w Niemczech, Horsta Zieglera, przy współpracy z firmami Texas Instruments Deutschland GmbH i Techem GmbH [2]. Rysunek 1.2.1 Logo M-Busa M-Bus wykorzystywany jest w układach służących do akwizycji danych z różnych urządzeń pomiarowych np. mierników zużycia gazu, ciepła, prądu etc. Ze względu na specyfikę wykorzystania tego protokołu (duża ilość obsługiwanych urządzeń w odległościach kilku kilometrów), cechuje się on wysoką odpornością na zakłócenia. Jest to niezbędne, ponieważ błędy w transmisji mogłyby mieć ogromne skutki. Brak konieczności częstej wymiany danych między urządzeniami oraz dopuszczenie względnie dużej zwłoki w czasie rzeczywistym między wymianą komunikatów pozwala na stosowanie niskiej prędkości transmisji. Może ona wynosić od 300 do 9600 bodów [3]. Istotną zaletą wykorzystania M-Busa jest możliwość zasilania podłączonych urządzeń z magistrali. Pozwala na to specyficzna reprezentacja bitów. Dla zapewnienia odporności na zakłócenia wykorzystuje się napięcia do 36V.

2 Protokół M-Bus a model ISO OSI Koncepcję protokołu oparta jest o powszechnie znany, referencyjny model sieci OSI. Standard M-Bus, będąc jedynie magistralą, opisuje cztery z siedmiu warstw modelu OSI. Warstwa Funkcja Standard Aplikacji Struktury danych, typy danych, akcje EN1434-3 Prezentacji - - Sesji - - Transportowa - - Sieci Rozszerzona adresacja (opcjonalne) - Łącza danych Fizyczna Parametry transmisji, formaty telegramów, adresacja Kabel, reprezentacja bitów, topologia, wymagania elektryczne Tabela 2.1.1 Warstwy M-Bus w modelu OSI. IEC 870 M-Bus Uzupełnieniem standardu magistrali M-Bus są normy EN1434-3 oraz IEC 870.

W dokumentacji M-Busa [1] proponowana jest interpretacja opisywanego protokołu oparta o model OSI rozszerzony o warstwę zarządzania (Management layer). Tłumaczy się to możliwością zmian parametrów np. przepustowość lub adresacja przez wyższe warstwy modelu. Warstwa zarządzania (Management layer) Aplikacji Prezentacji Sesji Transportowa Sieci (dla adresu 253) Adres 253: dostępny/niedostępny CI = $52/$56 Łącza danych Fizyczna Adres 254 (255) Tabela 2.1.2 Warstwa zarządzania w M-Busie Obsługą adresów 254 oraz 255 zajmuje się warstwa fizyczna, a adres 253 jest dostępny dla warstwy sieci, przy czym używa się go rzadko i w szczególnych przypadkach. Ich opis znajduje się w rozdziale 2.5. Te osobliwe cechy M-Busa tłumaczą konieczność rozszerzenia modelu ISO o jedną warstwę.

2.1 Warstwa fizyczna 2.1.1 Reprezentacja bitów Protokół M-Bus jest hierarchiczny oraz wykorzystuje topologię magistrali. Z urządzenia nadrzędnego (Master) wyprowadzane są dwa przewody, do których równolegle podłączone są kolejne urządzenia podrzędne (Slave 1, 2,..., n). Tę strukturę przedstawia rysunek 2.2.1. Rysunek 2.1.1 Magistrala z urządzeniami Konsekwencją wykorzystania tylko dwóch przewodów jest ograniczenie transmisji danych do pojedynczych bitów. Aby zapewnić możliwość zasilania urządzeń z magistrali, przesyłanie bitów wygląda następująco: 1. Master Slave bity są reprezentowane przez zmianę napięcia w czasie: logicznej jedynce (1, H) odpowiada napięcie 36 V, logicznemu zeru (0, L) napięcie 24 V. 2. Slave Master bity reprezentowane są przez zmianę poboru prądu przez urządzenie podrzędne: logicznej jedynce (1, H) odpowiada natężenie 1,5 ma, logiczne zero (0, L) to pobór prądu zwiększony o 11 20 ma. Podczas trwania logicznego zera Slave zwiększony pobór prądu może wykorzystać do zasilania interfejsu lub miernika. Zmiany w poborze prądu skutkują zmianami impedancji wyjściowej dla Mastera. Powoduje to niewielką fluktuację napięcia na jego zaciskach wyjściowych.

Ze względu na różne zużycie prądu przez Slave-y oraz na rezystancję przewodów, która zależy od ich długości, napięcie dla logicznej jedynki Mastera nie będzie wynosiło dokładnie 36 V. Z tego powodu urządzenia podrzędne nie mogą reagować na dokładne wartości napięć (36 V dla 1 lub 12 V dla 0) dla stanów logicznych Mastera, a jedynie na zmianę o ± 12 V. Analogiczna sytuacja występuje w przypadku, gdy nadaje jedno z urządzeń podrzędnych Master reaguje na zmiany w natężeniu płynącego prądu większe niż 11 ma. Konsekwencją tego jest możliwość nadawania w danej chwili tylko jednego z urządzeń Mastera albo któregoś ze Slave ów. Jest to transmisja jednokierunkowa typu Half-Duplex.

2.1.2 Specyfikacja sieci M-Bus może składać się z kilku sekcji, z których każda ma swoją grupę adresów. Połączenia między nimi zapewniają sterowniki sekcji na poziomie sieci. Wszystkie sekcje podzielone są na segmenty połączone repeater ami. Najczęściej M-Bus składa się z jednego segmentu podłączonego przez repeater do komputera PC, który pełni rolę Mastera. Repeater konwertuje sygnał ze standardu M-Bus na interfejs RS232 lub inny. Do transmisji M-Bus używany jest standardowy, dwuprzewodowy kabel telefoniczny (JYStY N*2*0.8 mm). Maksymalna odległość między repeaterem a Slave m może wynosić 350 m, co odpowiada rezystancji do 29 Ω. Na tym dystansie przepustowość może wynosić od 300 do 9600 bodów, a maksymalna liczba Slave ów 250. Maksymalna długość może zostać zwiększona kosztem ilości urządzeń podrzędnych oraz szybkości transmisji, przy czym napięcie w żadnym z punktów magistrali nie może spaść poniżej standardowych 12 V ze względu na zasilanie Slave ów z M-Busa. Ponadto maksymalny dystans nie może być większy niż 1000 m, by pojemność między przewodami nie przekroczyła 180 nf. Dotychczas grupa Usergroup, która zajmuje się rozwijaniem M-Busa, nie zdefiniowała rekomendowanej wtyczki. 2.1.3 Specyfikacja urządzeń Szczegóły specyfikacji można znaleźć w dokumencie WG4N85R2.DOC, dostępnym na stronie internetowej grupy użytkowników [4]. 1. Master: Dokumentacja [1] nie podaje żadnych specjalnych wymagań, które musi spełnić urządzenie pełniące funkcję Mastera. 2. Slave: Interfejs M-Bus został zaprojektowany tak, żeby istniała możliwość zasilania Slave ów z magistrali. Ponadto zaleca się, w razie awarii instalacji M- Busa, żeby urządzenia podrzędne automatycznie przełączały się na tryb zasilania z baterii lub zapisały w pamięci wszystkie istotne informacje. Jeśli sieć zaprojektowano tak, że Slave y zawsze są zasilane z baterii, to należy zadbać, by jej żywotność wynosiła parę lat w celu zmniejszenia koszów utrzymania instalacji. W tym miejscu należy nadmienić, że urządzenia podrzędne są odporne na zmianę polaryzacji magistrali. Ta cecha została opracowana w celu zabezpieczenia urządzeń przed niepoprawnym podpięciem napięcia oraz by ułatwić montaż instalacji.

3. Konwerter: W celu ułatwienia podłączenia Slave a do magistrali, firma Texas Instruments Deutschland GmbH wyprodukowała konwerter Transceiver (od angielskich słów Transmitter i Receiver odpowiednio nadajnik i odbiornik) TSS721. Układ scalony zaprojektowany jest tak, żeby spełniał wymogi wszystkich protokołów z grupy UART. Odporność na zmianę polaryzacji została osiągnięta przez użycie standardowego mostka Graetza. Obniża on napięcie do 3.3 V, by zasilać mikroprocesor. Utrzymywanie napięcia umożliwiającego zasilanie uc osiąga się przed odpowiednie podłączenie kondensatorów podtrzymujących. Ramka M-Busa ma taki format by, maksymalnie, co jedenasty bit był logiczną jedynką (stan wysoki), dzięki temu napięcie na w/w kondensatorach nie spadnie poniżej poziomu pozwalającego na zasilanie mikroprocesora. Możliwa jest również konfiguracja układu z izolacją galwaniczną, w której stosuje się niezależne poziomy napięć oraz transoptory w celu transmisji. 2.2 Warstwa łącza danych Wymagania, które musi spełniać magistrala (sieć) na tym poziomie, wyszczególnione są w międzynarodowym standardzie IEC 870-5. M-Bus nie korzysta jednak ze wszystkich opcji opisanych w tej normie. 2.2.1 Parametry transmisji Protokół M-Bus wykorzystuje asynchroniczną transmisję bitów, w której synchronizacja zapewniona jest przez bity startu oraz stopu. Nominalnie napięcie na magistrali jest w stanie wysokim (logiczna jedynka), dlatego bit startu zawsze będzie logicznym zerem, a stop bitu jedynką. Po bicie startu przesyłane jest osiem bitów danych, bit parzystości oraz bit stopu będący zawsze jedynką. Taki format telegramu pozwala zawsze spełnić wymaganie, by, przynajmniej, co jedenasty bit był jedynką. Bity danych przesyłane są kolejno od najmniej znaczącego (LSB).

2.2.2 Format ramki W oparciu o normę IEC 870-5 wyróżnia się trzy klasy integralności danych (I1, I2 oraz I3). Warstwa łącza danych M-Busa korzysta z klasy formatu FT 1.2, która zalicza się do klasy integralności I2. W ramach formatu FT 1.2 dostępne są cztery typy ramek: Pojedynczy znak (Single character) Ramka krótka (Short frame) Ramka kontrolna (Control frame) Ramka długa (Long frame) E5h Start 10h Start 68h Start 68h Pole C Pole L = 3 Pole L Pole A Pole L = 3 Pole L Suma kontrolna Start 68h Start 68h Stop 16h Pole C Pole C Pole A Pole CI Suma kontrolna Stop 16h Tabela 2.3.1 Formaty ramek Pole A Pole CI Dane (0-252 bajty) Suma kontrolna Stop 16h 2.2.3 Znaczenie pól 1. Pole C (Control/Function Field ang. pole kontrolne/funkcyjne): W tym polu deklarowane są funkcje i akcje przez nie wykonywane. Ponadto określany jest kierunek transmisji. Nr bitu 7 6 5 4 3 2 1 0 Nadawanie/wezwanie 0 1 FCB FCV F3 F2 F1 F0 Odpowiedź 0 0 ACD DFC F3 F2 F1 F0 Tabela 2.3.2 Kodowanie Pola C

Bit siódmy, najbardziej znaczący, jest zarezerwowany dla przyszłych zastosowań. Kolejny, szósty, określa kierunek transmisji. Bit FCB mówi o bezbłędności transmisji. Pozwala to uniknąć wielokrotnego wysyłania komunikatu lub utraty danych. Master ustawia bit FCV, gdy używa bitu FCB. Gdy FCV jest zerem, Slave ignoruje FCB. Bit DFC (Data Flow Control ang. kontrola przepływu danych) informuje o tym, że Slave nie może odebrać więcej danych. Urządzenie podrzędne ustawia bit ACD (access demand ang. potrzeba dostępu), gdy chce wysłać dane pierwszej klasy (Class 1 data). Po otrzymaniu tego komunikatu, Master powinien tych danych zażądać odpowiednim komunikatem. Dane klasy 1 mają pierwszeństwo przed klasą 2 (Class 2 data) dlatego, że należy je bezzwłocznie dostarczyć do urządzenia nadrzędnego. Bity od 0 do 3 służą do kodowania pewnych funkcji, które są opisane w tabeli 2.3.3. Nazwa Kod binarny Kod heksadecymalny Format ramki Opis SND_NKE 0100 0000 40 Krótka Inicjalizacja Slave a SND_UD 01F1 0011 53/73 Długa/Kontrolna Wysyłanie danych do Slave a REQ_UD2 01F1 1011 5B/7B Krótka Żądanie danych 2 klasy REQ_UD1 01F1 1010 5A/7A Krótka Żądanie danych 1 klasy RSP_UD 00AD 1000 08/18/28/38 Długa/Kontrolna Transfer danych Slave a do Mastera Tabela 2.3.3 Kodowanie funkcji pola C (Legenda: F FCB, A ADC, D DFC) 2. Pole A (Address Field ang. pole adresacji): Pole zawiera adres odbiorcy, do którego ma dotrzeć ramka oraz adres nadawcy. Pole składa się z ośmiu bitów, więc może przyjmować wartości od 0 do 255. Slave y w sieci mają adresy w zakresie 1 250. Nieskonfigurowane urządzenia posiadają adres 0, nadany im podczas produkcji. Adresów 254 (FEh) oraz 255 (FFh) używa się w celu dostarczenia ramki do wszystkich odbiorców Broadcast (ang. tryb rozgłaszania). Dla adresu 255 Master nie oczekuje odpowiedzi od żadnego z urządzeń podrzędnych, dla 254 odpowiadają wszystkie Slave y. Powoduje to kolizje, gdy podłączonych jest więcej niż jedno urządzenie podrzędne, dlatego tego trybu używa się tylko w celach testowych lub specjanych. Adres 253 oznacza, że adresacja wykonana jest w warstwie sieci (rozdział 2.5), a nie w warstwie łącza danych. Pozostałe adresy 251 oraz 252 zarezerwowane są dla przyszłych rozwiązań.

3. Pole CI (Control Information Field ang. pole informacji kontrolnych): Pole CI jest częścią warstwy aplikacji. Opisane jest bardziej szczegółowo w rozdziale 2.4. Wykorzystywane jest ono rozróżnić ramkę długą od kontrolnej, ponadto informacje kontrolne pozwalają na implementację wielu akcji Mastera oraz Slave ów. 4. Pole L (Length Field ang. pole długości): Informuje o długości ramki. Podaje się ją w bajtach. Wynosi: ilość bajtów danych + 3 (pola C, A oraz CI). 5. Suma kontrolna W poprawnie wysłanej i dostarczonej ramce jest równa sumie modulo 255 z wszystkich danych oraz pól C,A oraz CI. 2.2.4 Przebieg komunikacji Warstwa łącza danych używa dwóch trybów wymiany danych: 1. Send/Confirm: SND/CON ang. Wyślij/Potwierdź odbiór 2. Request/Respond: REQ/RSP ang. Żądaj odpowiedzi/odpowiedz Procedury SND/CON: 1. SND_NKE Pojedynczy znak (E5h): Procedura mająca miejsce po przerwaniu lub podczas rozpoczęcia komunikacji. Ma na celu inicjalizację urządzeń podrzędnych. Na poprawnie odebraną ramkę Slave opowiada pojedynczym znakiem (E5h). 2. SND_UD Pojedynczy znak (E5h): Master wysyła dane do urządzenia podrzędnego. Slave informuje pojedynczym znakiem o poprawnie odebranej ramce lub informuje o błędzie. Procedura REQ/RES: REQ_UD2 RSP_UD: Master żąda danych klasy 2. Slave może odpowiedzieć na trzy sposoby: wysyła żądane dane, informuje, że żądanie nie zostało odebrane poprawnie lub o tym, że adres żądania się nie zgadza.

Standard EN1434-3 wymaga, by protokół obsługiwał co najmniej procedury REQ_UD2/RSP_UD oraz SNK_NKE/E5h. Reszta funkcji jest opcjonalna. Podczas transmisji mogą wystąpić błędy. Mogą one być wykryte przez urządzenie będące w danym momencie odbiornikiem (Master lub Slave) w następujących punktach: 1. Bity startu/parzystości/stopu w każdym z przesyłanych znaków, 2. Znaki startu/stopu oraz suma kontrolna w każdej z ramek, 3. Drugi znak startu, parzysta długość dwóch pól, ilość odebranych znaków (wartość Pola L + 6) w ramkach kontrolnych i długich. Procedura w przypadku wystąpienia błędu: Po detekcji błędu w transmisji na jeden z powyższych sposobów, transmisja zostanie nieprzyjęta, a odbiorca nie odpowie w żądany sposób. Po upływie czasu potrzebnego na przesłanie 330 bitów + 50 ms Master rejestruje brak odpowiedzi i wysyła telegram jeszcze maksymalnie dwa razy. Po drugiej, nieudanej próbie wysłania telegramu, Master dolicza dodatkowy czas potrzebny do wysłania 33 bitów. Następnie ponawia wysyłanie telegramu jeszcze maksymalnie trzy razy i w razie braku odpowiedzi lub zgłoszenia błędu przez urządzenie podrzędne odczekuje czas trwania 33 bitów. Następnie próbuje wykonać procedurę SND_NKE. Jeśli ona zawiedzie rozpoczyna transmisję ze Slave m o następnym adresie. 2.2.5 Bity FCB i FCV Bity FCB i FCV mogą służyć do obsługi wielotelegramowej wymiany danych między urządzeniami. W sytuacji, w której odpowiedź RSP_UD Slave a na żądanie REQ_UD Mastera nie zmieści się w pojedynczej ramce, urządzenie nadrzędne ustawia w zapytaniu bit FCV sygnalizujący o korzystaniu z mechanizmu FCB (dla FCV = 0 urządzenia ignorują bit FCB). Podczas wymiany danych w wielu telegramach, każde kolejne żądanie Mastera zawiera bit FCB o wartości przeciwnej do poprzedniej ramki (1 0 1 0 etc.). W momencie wysłania przez Mastera dwóch żądań z rzędu o tej samej wartości bitu FCB Slave powtórzy wcześniejszą odpowiedź. W pewnych przypadkach można celowo zażądać od Slave, by wysłał dane z poprzedniej wiadomości, natomiast jest to niezalecane. Wyżej opisany mechanizm znajduje zastosowanie również podczas przesyłania dużych ilości danych w kierunku Master Slave np. podczas inicjalizacji pamięci RAM/EEPROM Slave a lub podczas wgrywania nowego programu.

2.2.6 Mechanizm FCB a adresacja Master musi zachowywać w pamięci wartości bitów FCB z poprzednich żądań dla każdego z adresów urządzeń podrzędnych. Jest to konieczne do poprawnej wymiany informacji z każdym z nich. Po wysłaniu polecenia inicjalizacji SND_NKE bit FCB w następnym żądaniu zawsze jest ustawiony dla każdego z adresów. Rozwiązuje to problem, który może się pojawić po utracie pamięci o wartości tych bitów np. po awarii zasilania. Podsumowując: po utracie pamięci przez Mastera, wysyła on telegram SND_NKE w trybie rozgłaszania (broadcast, adres 255), po którym sekwencja odwracania bitów FCB dla każdego ze Slave ów w kolejnych telegramach rozpoczyna się od nowa. Część urządzeń podrzędnych może być skonfigurowana tak, że odpowiada na żądania dla kilku adresów np. gdy dany miernik ma zaimplementowaną dużą ilość funkcji. W takim przypadku musi on zachowywać w pamięci wartości opisywanych bitów dla każdego z adresów, który obsługuje.

2.3 Warstwa aplikacji Warstwa aplikacji protokołu M-Bus spełnia wymagania standardu EN1434-3, który opisuje komunikację z miernikami ciepła. Standard ten jest wykorzystywany również do komunikacji z miernikami innych wielkości np. zużycia gazu lub prądu. 2.3.1 Pole CI Pole CI opisuje funkcje i sekwencje ramki, w której się znajduje. Zawiera ono w sobie bit Mode-bit (M-bit). Definiuje on kolejność wysyłania kolejnych bajtów. Wyzerowany M-bit oznacza, że dane są przesyłane od najmniej znaczącego bitu (Tryb 1), ustawiony sygnalizuje, że od najbardziej znaczącego (Tryb 2). Nie jest zalecane korzystanie z Trybu 2. Tryb 1 Tryb 2 Funkcja 51h 55h Przesyłanie danych 52h 56h Wybór Slave a 50h 54h B8h B9h BAh BBh BCh BDh BEh BFh B1h B2h B3h B4h B6h 90h 97h Reset aplikacji Synchronizacja działania Ustawienie przepustowości na 300 bodów Ustawienie przepustowości na 600 bodów Ustawienie przepustowości na 1200 bodów Ustawienie przepustowości na 2400 bodów Ustawienie przepustowości na 4800 bodów Ustawienie przepustowości na 9600 bodów Ustawienie przepustowości na 19200 bodów Ustawienie przepustowości na 38400 bodów Żądanie odczytu całej pamięci RAM Wysłanie danych użytkownika Inicjalizacja trybu kalibracji Odczyt EEPROM Stert testu oprogramowania Kody do szyfrowania - przestarzałe i niezalecane Tabela 2.4.1 Kodowanie funkcji pola CI w wiadomości Mastera

Reset aplikacji CI = $50 Master może wymusić reset warstwy aplikacji Slave ów wysyłając ramkę z polem CI=50h. Każde z urządzeń podrzędnych samodzielnie decyduje, który z parametrów zmieni po otrzymaniu żądania resetu. Reset aplikacji wywołany wyzwolony w poleceniu SND_UD z polem CI=50h jest swoistym odpowiednikiem resetu/inicjalizacji w warstwie łącza danych SND_NKE. Parametry resetu Master może wywołać reset polem CI=50h z dodatkowymi parametrami. Pierwszy z nich definiuje funkcje telegramu, drugi numer telegramu. Parametry resetu wskazują na dane, których żąda Master tabela 2.4.2 przedstawia kodowanie 4 górnych bitów parametrów. Kod 0000b 0001b 0010b 0011b 0100b 0101b 0110b 0111b 1000b 1001b 1010b 1011b 1100b 1101b 1110b 1111b Znaczenie Wszystkie dane Dane użytkownika Billing prosty Billing rozszerzony Billing wielotaryfowy Wartości chwilowe Ładuj parametry zarządzania Zarezerwowane Instalacja i start Test Kalibracja Dane produkcji Rozbudowa Autotest Zarezerwowane Zarezerwowane Tabela 2.4.2 Kodowanie parametrów resetu

Synchronizacja działania CI = $54 Pole CI może być wykorzystane do zsynchronizowania funkcji urządzeń. Są nimi: ustawienie nowej przepustowości komunikacji, przesyłanie danych oraz wybór Slave a. Zostaną one opisane w kolejnych rozdziałach. Tryb 1 Tryb 2 Funkcja 70h Raport błędów aplikacji 71h Raport alarmów 72h 76h Odpowiedź zmienną strukturą danych 73h 77h Odpowiedź stałą strukturą danych Tabela 2.4.3 Kodowanie funkcji pola CI w wiadomości Slave a 2.3.2 Stała struktura danych Długa ramka może przyjmować dwie długości w kierunku odpowiedzi na żądanie. Wyniki pomiarów są zapisane w dwóch licznikach kodowanych w BCD. W strukturze danych o zmiennej długości można przesłać znacznie większą ilość informacji (większa liczba liczników) oraz może ona być przesyłana w obu kierunkach, dlatego w zastosowaniach w przyszłości nie zaleca się korzystania ze struktury o stałej długości. Pole CI w stałej strukturze danych przyjmuje wartości 73h/77h. Dzięki tym numerom Master wie, jak interpretować otrzymane dane. Nr indentyfikacyjny Nr dostępu Status Mierzona wielkośc/jednostka Licznik 1 Licznik 2 4 bajty 1 bajt 1 bajt 2 bajty 4 bajty 4 bajty Tabela 2.4.4 Znaczenie i rozmiar kolejnych bajtów w stałej strukturze danych Numer identyfikacyjny numer seryjny przypisany podczas produkcji. Kodowany na 4 bajtach w BCD (00000000 99999999). Numer dostępu kodowany binarnie. Inkrementuje się o jeden po każdej odpowiedzi RSP_UD. Status informacje dotyczące statusu liczników. Opis w tabeli 2.4.5:

Bit Bit ustawiony Bit wyzerowany 0 Liczniki kodowane binarnie Liczniki kodowane w BCD 1 Dane w licznikach ze stałą datą Aktualny stan liczników 2 Niski poziom baterii Dobry poziom baterii 3 Stały błąd Brak stałego błędu 4 Chwilowy błąd Brak chwilowego błędu 5 Zależne od producenta Zależne od producenta 6 Zależne od producenta Zależne od producenta 7 Zależne od producenta Zależne od producenta Tabela 2.4.5 Kodowanie pola statusu Mierzona wielkość/jednostka wartości zawsze przesyłane począwszy od najmniej znaczącego bajta. Informują o stanie obu liczników i jednostce mierzonej wielkości. Szczegóły kodowania tych pól przedstawia tabela 2.4.6. Bajt Bajt 2 Bajt 1 Bit 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Mierzona wielkość Jednostka licznika 2 Mierzona wielkość Tabela 2.4.6 Kodowanie pola mierzonej wielkości i jej jednostki Jednostka licznika 1 Przykład odpowiedzi RSP_UD dla stałej struktury danych w trybie 1 [1]: 68 13 13 68 nagłówek 08 05 73 pole C: 08 RSP_UD, 05 adres, 73 pole CI: stała struktura, przesyłanie począwszy od najmniej znaczącego bajta 78 56 34 12 numer identyfikacyjny: 12345678 0A licznik transmisji: 0A 00 status (liczniki w BCD, wartości bieżące, brak błędów) E9 7E wielkość i jednostka: woda, jednostka 1: 1l(bież.), jednostka 2: 1l(hist.) 01 00 00 00 licznik 1: 1l (bieżąca) 35 01 00 00 licznik 2: 135l (historyczna) 3C 16 suma kontrolna i znak końca

2.3.3 Zmienna struktura danych Drugi typ ramki długiej nie ma określonej długości. O jego stosowaniu informuje pole CI wartościami 72h/76h. Struktura rami przedstawiona jest w tabeli 2.4.7. Nagłówek Bloki danych MDH Blok danych producenta 12 bajtów zmienne 1 bajt Zmienne Tabela 2.4.7 Budowa ramki o zmiennej strukturze danych Nagłówek - ma stałą długość - 12 bajtów. Budowa zaprezentowana jest w tabeli 2.4.8. Nr identyfikacyjny Producent Wersja Medium Nr dostępu Status Sygnatura 4 bajty 2 bajty 1 bajt 1 bajt 1 bajt 1 bajt 2 bajty Tabela 2.4.8 Budowa nagłówka Nr identyfikacyjny ustawiony podczas produkcji ośmiocyfrowy kod BCD. Nr dostępu patrz rozdział 2.4.2. Producent numer producenta nadawany zgodnie z EN 61107. Wersja generacja lub wersja licznika. Zależy od producenta. Medium mierzona wielkość. Status informuje o błędach aplikacji. Sygnatura zarezerwowana dla przyszłych zastosowań. Obecnie wynosi 0000h. Bloki danych - zawierają informacje o pomiarach, kodowaniu i długości. Ich wielkość ogranicza 255 bajtów, w skład których wchodzą pola C, A i CI i bloki o stałym rozmiarze. Grupa użytkowników Usergroup zaleca ograniczyć wielkość tego pola do 234 bajtów, by cała ramka miała maksymalnie 255 bajtów. MDH (Manufacturer Data Header) nagłówek danych producenta. Sygnalizuje początek bloku danych producenta. Przyjmuje wartości 0Fh i 1Fh. Jest pomijany, gdy nie ma danych producenta. Każdy z bloków danych ma określoną strukturę. Składa się z rozbudowanego nagłówka oraz danych. Ich ogólna budowa przedstawiona jest w tabeli 2.4.9.

Nagłówek DRH (Data Record Header) DIB VIB DIF DIFE VIF VIFE Dane 1 bajt 0 10 bajtów 1 bajt 0 10 bajtów 0 N bajtów Tabela 2.4.9 Budowa bloku danych DIB (Data Information Block) opisuje długość, typ i kodowanie danych. VIB (Value Information Block) opisuje jednostkę i mnożnik danych pomiarowych. Blok DIB składa się z pól DIF (Data Information Field) i DIFE (Data Information Field Extensions), czyli rozszerzenia bloku podstawowego DIF. Blok DIF może zostać rozszerzony, w celu przesyłania danych historycznych z różnych chwil. Wartości dla danych historycznych przechowywane są w akumulatorach. Kodowanie pola DIF ilustruje tabela 2.4.10. Nr bitu 7 6 5 4 3 2 1 0 Znaczenie Bit rozszerzenia LSB Pole funkcji akumulatora Tabela 2.4.10 Znaczenie bitów pola DIF Pole danych Bit rozszerzenia bit informujący, że podstawowe pole DIF jest rozszerzone o przynajmniej jeden blok DIFE. LSB akumulatora najmniej znaczący bit akumulatora przechowującego ilość danych historycznych. W przypadku, gdy nie są przechowywane dane historyczne bit wyzerowany informuje o wartości bieżącej. Pole funkcji informuje o typie przesyłanych danych tabela 2.4.11. Kod 00b 01b 10b 11b Znaczenie Wartość chwilowa Wartość maksymalna Wartość minimalna Wartość podczas wystąpienia błędu Tabela 2.4.11 Znaczenie kodowania pola funkcji

Pole danych informuje urządzenie nadrzędne, jak ma interpretować dane. Informacje zawarte w tym polu dotyczą kodowania i długości. Tabela 2.4.12 przedstawia kodowanie czterobitowego pola danych. Szczegółowe informacje dotyczące kodowania znajdują się w dokumentacji [1]. Kod 0000b 0001b 0010b 0011b 0100b 0101b 0110b 0111b 1000b 1001b 1010b 1011b 1100b 1101b 1110b 1111b Znaczenie Brak danych 8 bitowy Integer 16 bitowy Integer 24 bitowy Integer 32 bitowy Integer 32 bitowy Real 48 bitowy Integer 64 bitowy Integer Wybór odczytu 2 cyfrowy BCD 4 cyfrowy BCD 6 cyfrowy BCD 8 cyfrowy BCD Zmienna długość 12 cyfrowy BCD Funkcje specjalne Tabela 2.4.12 Znaczenie kodowania pola danych Zmienna długość (1101b) możliwe jest używanie typów danych o zmiennym rozmiarze. Ich długość LVAR podawana jest w pierwszym bajcie danych pomiarowych. Znaczenie zakresów LVAR umieszczone jest w tabeli 2.4.13. LVAR Typ Wielkość 00h BFh ASCII LVAR znaków C0h CFh Dodatni kod BCD (LVAR C0h) 2 cyfry D0h DFh Ujemny kod BCD (LVAR D0h) 2 cyfry E0h EFh Kod binarny (LVAR E0h) bajtów F0h FAh Liczba zmiennoprzecinkowa (LVAR F0h) bajtów

FBh - FFh Zarezerwowane Zarezerwowane Tabela 2.4.13 Znaczenie zakresów LVAR

Funkcje specjalne (1111b) tabela 2.4.14. DIF 0Fh 1Fh 2Fh 3Fh 6Fh 7Fh Funkcja Dane producenta do końca bloku danych Dane producenta do końca bloku danych + dane w następnym telegramie Wypełnienie (bez znaczenia) Zarezerwowane Żądanie pełnego odczytu (wszystkie akumulatory, jednostki, taryfy, pola funkcji) Tabela 2.4.14 Znaczenie kodowania funkcji specjalnych Każdy blok DIFE ma taką samą strukturę. Składa się z 8 bitów. Jego budowę przedstawia tabela 2.4.15. Nr bitu 7 6 5 4 3 2 1 0 Znaczenie Bit rozszerzenia Urządzenie Taryfa Numer akumulatora (podsekcja) Tabela 2.4.15 Znaczenie bitów pola DIFE miernika. Wykorzystanie wszystkich dostępnych 10 bloków DIFE dostarcza 41 bitów dla akumulatorów, 20 bitów dla taryfy i 10 bitów dla podjednostki Blok VIB jest kolejnym po blokach DIF i DIFE (ostatni z nich nie ma ustawionego bitu rozszerzenia) w nagłówku bloku danych. VIF, podobnie jak DIF, może być rozszerzony o kolejny blok. Składa się z siedmiu bitów informujących o jednostce i mnożniku oraz bitu rozszerzenia, który jest ustawiony w przypadku potrzeby rozszerzenia. Znaczenie bitów bloku VIF w tabeli 2.4.16. Nr bitu 7 6 5 4 3 2 1 0 Znaczenie Bit rozszerzenia Jednostka i mnożnik Tabela 2.4.16 Znaczenie bitów pola VIF

Znaczenie kodowania pola VIF znajduje się poniżej w tabeli 2.4.17. Kod E000 0000b E111 1011b E111 1100b FDh i FBh 7Eh/FEh 7Fh/FFh Znaczenia Standardowe rozdział 8.4.3 dokumentacji The M-Bus: A Documentation. [1] VIF reprezentowany jest przez ciąg znaków ACSII, którego długość podawana jest w pierwszym bajcie. Pozwala to na zakodowanie jednostek nieujętych w standardzie M-Busa. Niestandardowe VIF kodowany jest w następnym bajcie. Patrz: 1. Rozdział 8.4.4. The M-Bus: A Documentation. [1] 2. Rozdział 2.4.6 niniejszej pracy Używane w kierunku Master Slave. Żądanie odczytu wszystkich VIF ów. Kodowanie VIFE według specyfikacji producenta. Tabela 2.4.17 Kodowanie pola VIF (Legenda: E bit rozszerzenia w kodowaniu binarnym) Blok VIFE może być wykorzystany do przesyłania innych danych, np. w kierunku Master Slave do specjalnej obsługi danych (rozdział 2.4.6) lub w kierunku Slave Master do raportowania błędów (rozdział 2.4.7). Ostatni blok VIFE z wyzerowanym bitem rozszerzenia kończy ciąg bloków VIF oraz VIFE i jest tym samym ostatnim blokiem nagłówka DRH. Blok MDH to w rzeczywistości blok DIF, którego wartość wynosi 0Fh lub 1Fh. Informuje on o tym, że kolejne bloki zawierają dane producenta. Ilość bajtów tych danych obliczana jest na podstawie pola L, od którego odejmuje się pola C, A, CI oraz bloki danych włącznie z nagłówkiem danych producenta (DIF = 0Fh). MDH = 1Fh oznacza, że ciąg dalszy jest w następnym telegramie i Master nie może zakończyć odczytu dopóki nie nadejdzie ramka bez nagłówka pola danych producenta o tej wartości.

Przykład odpowiedzi RSP_UD dla zmiennej struktury danych w trybie 1 [1]: 68 1F 1F 68 nagłówek (długość 1Fh = 31 bajtów) 08 02 72 pole C: 08 RSP_UD, 02 adres, 72 pole CI: zmienna struktura, przesyłanie począwszy od najmniej znaczącego bajta 78 56 34 12 numer identyfikacyjny: 12345678 24 40 01 07 24 40 - numer producenta (4024 EN61107), 01 generacja, 07 woda 55 00 00 00 55 numer dostępu (85 dziesiętnie), 00 status (brak błędów), 00 00 - sygnatura 03 13 15 31 00 blok danych 1: podsekcja 0, akumulator nr 0, brak taryfy, objętość chwilowa, 12565 l (24 bitowy integer) DA 02 3B 13 01 blok danych 2: podsekcja 0, akumulator nr 5, brak taryfy, maksymalny przepływ, 113 l/h (4 cyfrowy BCD) 8D 60 04 37 18 02 blok danych 3: podsekcja 1, akumulator nr 0, taryfa 2, energia chwilowa, 218,37 kwh (6 cyfrowy BCD) 18 6 suma kontrolna i znak końca 2.3.4 Konfiguracja urządzeń podrzędnych Protokół M-Bus oferuje szereg parametrów, które można modyfikować w urządzeniach podrzędnych. Mogą być nimi na przykład: adres podstawowy, adres rozszerzony, przepustowość sieci lub inne. Zmiana przepustowości: Każde z urządzeń musi potrafić skomunikować się z Masterem przy minimalnej dostępnej przepustowości 300 bodów. Przełączanie szybkości między nadaniem wiadomości a odebraniem jest zabronione. By dokonać zmiany przepustowości Master wysyła ramkę kontrolną (Control Frame) SND_UD z adresem FEh (tryb rozgłaszania z oczekiwanym potwierdzeniem E5h). Kodowanie pola CI dla zmiany szybkości transmisji znajduje się w tabeli 2.4.18.

Pole CI B8h B9h BAh BBh BCh BDh BEh BFh Szybkość 300 600* 1200* 2400 4800* 9600 19200** 38400** [bod] Tabela 2.4.18 Kodowanie pola CI dla zmiany szybkości transmisji (Legenda: * - niezalecane, ** - dostępne dla nowych wersji Repeater ów) Na wysłaną ramkę urządzenie podrzędne odpowiada znakiem potwierdzenia E5h ze starą szybkością transmisji. Po potwierdzeniu komunikacja przebiega już z nową. Master musi znać dostępne przepustowości Slave ów, by nie przełączyć szybkości transmisji na niedostępną dla podłączonego do niego urządzenia. Przykład: Master Slave: 68 03 03 68 nagłówek 53 FE BD 53 typ ramki, FE adres (254), BD 9600 bodów 0E 16 suma kontrolna i znak końca Slave Master: E5 potwierdzenie (od tego momentu transmisja odbywa się z szybkością 9600 bodów) Zmiana parametrów urządzenia podrzędnego: Zmiana danych Slave a odbywa się poprzez wysłanie odpowiedniej ramki SND_UD z polem CI = 51h dla trybu 1 lub CI = 55h dla trybu 2. W tym przypadku opuszcza się dwunastobajtowy nagłówek. Wysyła się dane zawarte w 4 rekordach, z których każdy może być pominięty. Rekordy danych: a) Rekord adresu podstawowego: DIF = 01h VIF = 7AH Adres (1 bajt kodowany binarnie) Master musi znać adresy wszystkich Slave ów, którymi zarządza, by nie przypisać żadnemu z nich adresu już będącego w użyciu.

b) Rekord adresacji rozszerzonej: Istnieją dwie możliwości zmiany adresu rozszerzonego: 1. Rekord zmiany tylko numeru identyfikacyjnego: DIF = 0Ch VIF = 79h Numer identyfikacyjny (8 - cyfrowy BCD 2. Rekord zmiany pełnego adresu: DIF = 07h VIF = 79h Pełny adres Tabela 2.4.19 przedstawia znaczenie kolejnych bajtów pola adresu w rekordzie. Numer identyfikacyjny Numer producenta Generacja Medium 4 bajty 2 bajty 1 bajt 1 bajt Tabela 2.4.19 Kodowanie pola adresu dla zmiany pełnego adresu rozszerzonego c) Rekord zwykłych danych: Tym rekordem można zmienić dane wysyłane na żądanie REQ_UD2. Przesyłane są z otrzymanymi blokami DIF i VIF. W tych rekordach można implementować specjalne funkcjonalności, których szczegóły opisane są w rozdziale 2.4.6. d) Dane tylko do zapisu: Dane, które nie mogą zostać przesłane w normalny sposób od Slave a, jedynie przy użyciu VIF = 7Fh i specjalnego kodowania ustalonego przez producenta. DIF musi zawierać informacje opisujące typ i ilość tych danych. Po otrzymaniu żądania zmiany danych Slave odpowiada znakiem potwierdzenia E5h. Sam decyduje o tym, czy i które dane ma zmienić. W przypadku wystąpienia błędów Slave może, ale nie musi, zmienić dane poprawnie zdefiniowane w żądaniu, a następnie raportuje błędy. Przykłady zmiany parametrów [1]: 1. Ustawienie adresu podstawowego na 8:

68 06 06 68 nagłówek 53 FE 51 53 pole C, FE adres, 51 pole CI 01 7A 08 01 DIF, 7A VIF, 08 nowy adres 25 16 suma kontrolna i znak końca 2. Zmiana pełnej adresacji rozszerzonej: 68 0D 0D 68 nagłówek 53 FE 51 53 pole C, FE adres, 51 pole CI 07 79 04 03 02 01 07 DIF, 79 VIF, 04 03 02 01 ID miernika (01020304) 24 40 01 04 24 40 ID producenta (4024), 01 generacja, 04 ciepło 95 16 suma kontrolna i znak końca 3. Ustawienie ID urządzenia podrzędnego na 12345678 i 8-cyfrowego BCD licznika na 107 kwh: 68 0F 0F 68 nagłówek 53 FE 51 53 pole C, FE adres, 51 pole CI 08 79 78 56 34 12 08 DIF, 79 VIF, 78 56 34 12 ID miernika (12345678) 0C 06 07 01 00 00 0C DIF, 06 VIF, 07 01 00 00 stan licznika (107), 55 16 suma kontrolna i znak końca 2.3.5 Konfiguracja odpowiedzi Slave a Urządzenia podrzędne domyślnie skonfigurowane są w taki sposób, że w odpowiedzi RSP_UD na żądanie wysyłają wszystkie dane. Możliwa jest też ich taka konfiguracja, że odpowiadają jedynie wybranymi rekordami danych. Istnieją dwa sposoby na wymuszenie takiej odpowiedzi: 1. Brak wskazania konkretnego rekordu: a) Dowolny VIF:

Żądanie zawierające blok VIF = 7Eh wymusza odpowiedź z dowolnym polem VIF. Slave sam wybiera, który blok wysłać. b) Odczyt generalny: Blok DIF = 7Fh w wiadomości Mastera jest interpretowany jako żądanie wszystkich danych. Jeśli blok DIF o takiej wartości jest ostatnim bajtem danych lub po nim występuje VIF = 7Eh, wtedy żądany jest odczyt wszystkich danych. Jeśli po bloku DIF = 7Fh odbierany jest VIF o wartości innej niż 7Eh, wtedy Slave odpowiada danymi dla tego pola VIF. c) Wszystkie taryfy: Wiadomość urządzenia zawierająca pole taryfy o wartości 1111b (w bloku VIFE) wymusza na Slave ie wysłanie odpowiedzi z danymi dla wszystkich taryf. d) Wszystkie akumulatory: Wybór największego dostępnego numeru akumulatora żąda od Slave a odpowiedzi dla wszystkich obsługiwanych akumulatorów. e) Wszystkie podsekcje: Wybór największego dostępnego numeru podsekcji żąda od Slave a odpowiedzi dla wszystkich obsługiwanych podsekcji. f) Odczyt z wysoką rozdzielczością: Istnieje możliwość wymuszenia odpowiedzi z największą możliwą rozdzielczością pomiaru. W tym celu wysyła się wiadomość z blokiem VIF = E000 0000b (E bit rozszerzenia). Na tak zdefiniowane żądania Slave odpowiada odpowiednio zmodyfikowaną odpowiedzią. W przypadku, gdy nie może odpowiedzieć (np. nie obsługuje danego akumulatora), wtedy wysyła standardową odpowiedź. Jest oto sygnał dla Master a, że źle sformułowano żądanie. 2. Wybór konkretnego rekordu: Master żąda odczytu konkretnego rekordu używając funkcji Dodaj do listy odczytu (patrz rozdział 2.4.6) VIFE = E000 1100b. W tym celu wysyła ramkę SND_UD z polem CI = 51h/55h, polem DIF wskazującym na żądany blok danych oraz polami VIF i VIFE = 0Ch/8Ch. Ten blok VIFE jest ostatnim bajtem danych, a jeśli jakieś dane następują po nim, Slave musi je zignorować, a następnie odpowiedzieć odpowiednią ramką. Jeśli urządzenie podrzędne nie obsługuje wymaganego pola danych (np. nieprawidłowy rozmiar danych lub klasa danych), to odsyła wiadomość z blokiem VIFE = E000 011x.

Master, chcąc powrócić do standardowej obsługi żądań przez Slave y (zwykła ramka RSP_UD), musi wyzwolić reset w warstwie aplikacji, wysyłając SND_UD z polem CI = 50h. Poszczególne rekordy danych mogą być usunięte z listy odczytu. W tym celu należy wysłać ramkę z odpowiednimi polami DIF i VIF oraz polem VIFE = E000 1101b, które wywołuje funkcję Usuń z listy odczytu. Wszystkie dane w odpowiedzi Slave a mogą nie zmieścić się w jednej ramce np. podczas odczytu danych historycznych. W takim przypadku urządzenie podrzędne w telegramie umieszcza blok DIF = 1Fh, który informuje o tym, że dalszy ciąg danych znajduje się w kolejnym telegramie. Po odebraniu takiego bloku Master musi odpytywać Slave a do momentu, gdy ten nie odeśle znaku potwierdzenia E5h lub w telegramie RSP_UD nie zamieści już bloku DIF = 1Fh. By uniknąć utraty danych podczas takiej wymiany wiadomości, zalecane jest obsługiwanie bitu FCB, który dla kolejnych ramek zmienia wartość na przeciwną. Master może przerwać taką sekwencję wymiany danych wyzwalając reset warstwy aplikacji (CI = 50h). Przykłady [1]: 1. Konfiguracja Slave a tak, żeby wysyłał dane dotyczące objętości i temperatury przepływu: 68 07 07 68 nagłówek 53 07 51 53 pole C, 07 adres, 51 pole CI 08 13 08 5A 08 DIF, 13 VIF (objętość, 1l), 08 DIF, 5A VIF (temperatura przepływu, 0.1 C) 28 16 suma kontrolna i znak końca 2. Slave pod adresem 1 ma wysyłać dane z wszystkich akumulatorów, wszystkich taryf dla każdego z bloków VIF z podsekcji 0: 68 06 06 68 nagłówek 53 01 51 53 pole C, 01 adres, 51 pole CI C8 3F 7E C8 DIF (odczyt danych), 3F DIFE (wszystkie akumulatory i taryfy), 7E VIF (wszystkie dane) 2A 16 suma kontrolna i znak końca 3. Slave nr 3 skonfigurowany do odczytu generalnego: 68 04 04 68 nagłówek 53 03 51 53 pole C, 03 adres, 51 pole CI

7F 7F DIF (żądanie odczytu generalnego) 26 16 suma kontrolna i znak końca

2.3.6 Obiekty w warstwie aplikacji W protokole M-Bus został zaimplementowany pewien poziom abstrakcji. Podczas konfiguracji Slave a wysyłane są w jednym rekordzie dane oraz instrukcje, co należy z tymi danymi zrobić. Te rekordy są nazywane obiektami w ramach standardu M-Bus. Obiekty definiuje się poprzez przypisanie blokom VIF i VIFE odpowiednich wartości. Dla bloku podstawowego VIF FDh (rozszerzona tablica kodów VIF) istnieje szereg wartości bloku VIFE opisujących funkcje tabela 2.4.20. VIFE Funkcja Opis E000 0000b Pisz/Zastąp (Write/Replace) Zastąp stare dane E000 0001b Dodaj (Add Value) Dodaj do poprzedniej wartości E000 0010b Odejmij (Substract Value) Odejmij od poprzedniej wartości E000 0011b OR Alternatywa logiczna E000 0100b AND Iloczyn logiczny E000 0101b XOR Alternatywa wykluczająca E000 0110b AND NOT Zaprzeczenie iloczynu logicznego E000 0111b Wyzeruj (Clear) Wyzerowanie danych E000 1000b Stwórz Rekord (Add Entry) Stworzenie nowego rekordu danych E000 1001b Usuń Rekord (Delete Entry) Usunięcie istniejącego rekordu danych E000 1010b - Zarezerwowane E000 1011b Zachowaj Dane (Freeze Data) Załaduj dane do akumulatora E000 1100 Dodaj do listy odczytu (Add to Readout List) Dodaj do listy odczytu RSP_UD E000 1101b Usuń z listy odczytu (Delete from Readout list) Usuń z listy odczytu RSP_UD E000 111xb - zarezerwowane E001 xxxxb - zarezerwowane Tabela 2.4.20 Kodowanie funkcji obiektów warstwy aplikacji

Przykłady [1]: 1. Ustawienie 8 cyfrowego BCD licznika (wartość chwilowa, wartość bieżąca, brak taryfy, podjednostka 0) na 107 kwh u Slave a pod adresem 1: 68 0A 0A 68 nagłówek 53 01 51 53 pole C, 01 adres, 51 pole CI 0C 86 00 0C DIF (wartość chwilowa, bieżąca, 8-cyf. BCD), 86 VIF (energia, kwh), 00 VIFE ( Pisz/Zastąp ) 07 01 00 00 07 01 00 00 wartość (00 00 01 07) 3F 16 suma kontrolna i znak końca 2. Dodanie 10 kwh do licznika z przykładu 1. 68 0A 0A 68 53 01 51 nagłówek, 53 pole C, 01 adres, 51 pole CI 0C 86 01 0C DIF (wartość chwilowa, bieżąca, 8-cyf. BCD), 86 VIF (energia, kwh), 01 VIFE ( Dodaj ) 10 00 00 00 10 00 00 00 wartość (00 00 00 10) 48 16 suma kontrolna i znak końca 3. Stworzenie rekordu 8 cyfrowego BCD licznika (wartość chwilowa, wartość bieżąca, brak taryfy, podsekcja 0, 1kWh) z wartością początkową 511kWh u Slave a pod adresem 5: 68 0A 0A 68 nagłówek 53 01 51 53 pole C, 01 adres, 51 pole CI 0C 86 08 0C DIF(wartość chwilowa, bieżąca, 8-cyf. BCD), 86 VIF (energia, kwh), 08 VIFE ( Stwórz Rekord ) 11 05 00 00 11 05 00 00 wartość (00 00 05 11) 59 16 suma kontrolna i znak końca

4. Zachowanie danych w akumulatorze: bieżąca temperatura przepływu (0.1 C: VIF = 5Ah); u Slave a z adresem 1 w akumulatorze 1: 68 06 06 68 nagłówek 53 01 51 53 pole C, 01 adres, 51 pole CI 40 DA 0B 40 DIF, DA VIF (temp. przepływu, 0.1 C), 0B VIFE ( Zachowaj Dane ) CA 16 suma kontrolna i znak końca 2.3.7 Status warstwy aplikacji Podczas wymiany danych mogą wystąpić błędy w warstwie aplikacji. Urządzenie podrzędne może zasygnalizować wystąpienie trzech różnych typów błędów: 1. Błąd statusu warstwy aplikacji: Za opis błędu w warstwie aplikacji odpowiedzialne są dwa najmniej znaczące bity baja w polu Status w nagłówku zmiennej struktury danych. Bity: 1 i 0 pola Status 00b 01b 10b 11b Status warstwy aplikacji Brak błędów Warstwa aplikacji zajęta Błąd warstwy aplikacji Zarezerwowane Tabela 2.4.21 Kodowanie statusu warstwy aplikacji 2. Błędy warstwy aplikacji: Slave może raportować zidentyfikowane błędy wykorzystując ramkę RSP_UD, której pole CI = 70h, a pole danych zawiera numer błędu: 68h 04h 04h 68h 08h Adres 70h Numer Suma 16h Numer błędu (dziesiętnie) Znaczenie 0 Niezidentyfikowany lub brak pola danych

1 Niezaimplementowane pole CI 2 Bufor za długi (obcięto dane) 3 Zbyt wiele rekordów 4 Przedwczesny koniec rekordu 5 Więcej niż 10 bloków DIFE 6 Więcej niż 10 bloków VIFE 7 Zarezerwowane 8 Warstwa aplikacji zbyt zajęta dla żądania odczytu 9 Zbyt wiele odczytów (dla Slave ów z ograniczoną ilością w danym czasie) 10-255 Zarezerwowane Tabela 2.4.22 Znaczenie numerów błędów warstwy aplikacji

3. Błędy rekordów: Do warstwy aplikacji należy obsługa błędów w przesyłanych danych. Raport o tego typu błędzie w warstwie aplikacji wysyła Slave umieszczając blok VIFE o odpowiedniej wartości w nagłówku bloku danych. Tabela 2.4.23 przedstawia kodowanie błędów rekordów. Kod VIFE Typ błędu Grupa błędów E000 0000b Brak błędu E000 0001b Zbyt wiele bloków DIFE E000 0010b Numer akumulatora niezaimplementowany E000 0011b Numer podjednostki niezaimplementowany E000 0100b Numer taryfy niezaimplementowany Błędy bloku DIF E000 0101b Funkcja niezaimplementowana E000 0110b Klasa danych niezaimplementowana E000 0111b Rozmiar danych niezaimplementowany E000 1000b - E000 1010b Zarezerwowane E000 1011b Zbyt wiele bloków VIFE E000 1100b Zabroniona grupa VIF E000 1101b Zabroniona eksponenta VIF E000 1110b Niezgodność VIF/DIF Błędy bloku VIF E000 1111 Akcja niezaimplementowana E001 000 - E001 0100b Zarezerwowane E001 0101b Brak danych (niezdefiniowana wartość) E001 0110b Nadmiar danych E001 0111b Niedomiar danych Błędy danych E001 1000b Błąd danych E001 1001b - E001 1011b Zarezerwowane E001 1100b Przedwczesny koniec rekordu E001 1101b - E001 1111b Zarezerwowane Inne błędy Tabela 2.4.23 Kodowanie błędów rekordów danych

W przypadku wystąpienia błędów danych Slave może uzupełnić dane nic niewnoszącymi kodami lub blokami: 1. Dane = 0000b: brak danych. 2. Dane = 0000b + DIF = 2Fh: brak danych i blok wypełnienia DIF. 3. Inne: a. Atrapa prawdziwych danych. b. Dane szacunkowe. 2.3.8 Cechy specjale Slave ów Norma EN1434-3, na której oparta jest warstwa aplikacji protokołu M-Bus opisuje pewne specjalne cechy urządzeń podrzędnych: 1. Autodetekcja szybkości transmisji (funkcja niezalecana przez twórców M-Busa): Slave może zidentyfikować szybkość transmisji poprzez analizę znaku startu ramki. Dla krótkiej jest to 10h, dla długiej 68h. Start LSB 1 2 3 4 5 6 MSB Parzystość Stop 0 0 0 0 0 1 0 0 0 1 1 Tabela 2.4.24 Kodowanie znaku startu ramki krótkiej - 10h Start LSB 1 2 3 4 5 6 MSB Parzystość Stop 0 0 0 0 1 1 0 0 0 1 1 Tabela 2.4.25 Kodowanie znaku startu ramki długiej - 68h W celu detekcji szybkości transmisji Slave zlicza długość trwania przerwy na początku ramki: cztery lub pięć zer, następnie porównuje ją z długościami trwania bitu dla różnych przepustowości i na tej podstawie określa szybkość transmisji.

2. Detekcja kolizji: Kolizja na magistrali zachodzi w momencie nadawania wiadomości przez więcej niż jednego Slave a. Bardzo małe kolizje (22 33mA) - 2-3 nadające urządzenia podrzędne - są niewykrywalne ani przez je same ani przez Master a (najnowsze wersje powinny być w stanie je zidentyfikować, a następnie nadawać przerwę przez 50ms). Średnie kolizje (70 500mA) są wykrywane przez wszystkie urządzenia w sieci. Najcięższe kolizje (90 5000mA) mogą spowodować awarię zasilania, dlatego urządzenie podrzędne powinno odłączyć magistralę (analogia do bezpiecznika nadprądowego). By uniknąć wystąpienia przepływu zbyt dużych prądów, stosuje się mechanizmy zabezpieczające: a. Pomiar prądu po wysłaniu logicznej jedynki gwarantuje szybką reakcję i jest zalecane przez grupę użytkowników Usergroup. b. Sprawdzanie, czy po każdym bicie stopu napięcia na magistrali odpowiada logicznej jedynce. c. Porównywanie wysyłanych bitów z rzeczywistymi wartościami prądu i napięcia na magistrali. d. Sprzętowy UART z detekcją kolizji. Po detekcji kolizji szybkość transmisji ustawiana jest na 300 bodów. 3. Wykorzystanie numeru fabrycznego: Numer fabryczny jest numerem seryjnym nadawanym podczas produkcji. Jest częścią bloku danych: DIF = 0Ch oraz VIF = 78h; kodowany jest na 8 cyfrach BCD. Przykład [1]: 68 15 15 68 nagłówek 08 02 72 08 pole C (RSP), 02 adres, 72 pole CI (zmienna struktura, przesyłanie począwszy od najmniej znaczącego bajta) 78 56 34 12 numer identyfikacyjny (12345678) 24 40 01 07 24 40 ID producenta (4024), 01- generacja, 07 medium (woda) 13 00 00 00 13 numer dostępu (19 dziesiętnie), 00 status, 00 00 sygnatura 0C 78 04 03 02 01 0C DIF, 78 VIF, 04 03 02 01 numer fabryczny (01020304) 9D 16 suma kontrolna i znak końca

Wykorzystanie numeru fabrycznego jest zalecane podczas używania adresacji rozszerzonej. Numer fabryczny, ID producenta, generacja i przetwarzana wielkość tworzą razem unikalny numer, który pozwala na nadawanie Slave om tych samych adresów w ramach adresacji rozszerzonej (patrz rozdział 2.5). 4. Kodowanie BCD znaków $A - $F: Standard EN1434 pozwala na kodowanie pól danych wielocyfrowym BCD. Obecnie obowiązujący standard nie definiuje, co ma się stać w przypadku odebrania przez urządzenie nadrzędne kodów $A - $F nie w kodzie BCD. Dokumentacja [1] proponuje sposób interpretacji tych kodów, jest to jednak tylko propozycja, a nie standard sensu stricto.

2.4 Warstwa sieci Implementacja warstwy sieci jest opcjonalna. Wdrożenie tej warstwy do struktury Mastera i urządzeń podrzędnych jest dokonywane w momencie nadania więcej niż jednemu ze Slave ów podstawowego adresu równego 253 (FDh). Od tego momentu do ich identyfikacji zostanie użyta adresacja rozszerzona. Wykorzystanie tej warstwy pozwala rozszerzyć paletę podstawowych 250 adresów. 2.4.1 Adresacja rozszerzona Do adresacji podstawowej używa się pola adresu w telegramie. Domyślnie urządzenia podrzędne mają nadany przez producenta adres 0. Ten adres po podłączeniu do magistrali należy zmienić, jeśli planowane jest podłączenie większej ilości Slave ów. Po wykorzystaniu puli podstawowych adresów (lub z innych powodów), można kolejne urządzenia adresować w warstwie sieci. W tym celu nadaje się urządzeniu adres podstawowy 253. Ogólna struktura wyboru adresacji rozszerzonej dla tych urządzeń zaprezentowana jest w tabeli 2.5.1. Nagłówek C A CI ID ID prod. Wersja Medium CS Stop 680B0B68h 53h FDh 52h 4 bajty 2 bajty 1 bajt 1 bajt xx 16h Tabela 2.5.1 Telegram uruchomienia mechanizmu adresacji rozszerzonej By przełączyć Slave a na adresację rozszerzoną, Master musi wysłać ramkę SND_UD z polem CI = 52h (tryb 1) oraz poprawnie wypełnionymi polami: ID urządzenia, ID producenta, Generacja oraz Medium. Po otrzymaniu poprawnego żądania Slave a potwierdza przełączenie znakiem potwierdzenia E5h i od tej pory komunikacja z tym urządzeniem przebiegała będzie z wykorzystaniem warstwy sieci. Numer pozwalający zidentyfikować Slave a w warstwie sieci składa się z czterech pól. Na każde z nich można nałożyć maskę, by nie było ono brane pod uwagę. Ponadto, każdy z czterech bajtów numeru identyfikacyjnego może zostać wykluczany osobno maska Fh. Maska dla pól ID producenta, Generacji i Medium to FFh. Po wysłaniu ramki inicjalizacji SND_NKE na adres 253, wszystkie urządzenia podrzędne wykorzystujące adresację rozszerzoną zostaną wykluczone z warstwy sieci, dlatego przy następnej próbie komunikacji należy najpierw wysłać telegram przedstawiony w tabeli 2.5.1.

Rozszerzona identyfikacja w warstwie sieci: W nowszych strukturach M-Bus istnieje możliwość posiadania tego samego adresu w warstwie sieci przez więcej niż jednego Slave a. W takich przypadkach ID jest rozszerzone o numer produkcji. Jest to numer seryjny, kodowany 8-mio cyfrowym BCD, nadawany podczas produkcji. Telegram uruchamiający adresację rozszerzoną z uwzględnieniem numeru produkcji przedstawiony jest w tabeli Nagłówek + C, A i CI Patrz tabela 2.5.1 ID 4 bajty ID prod. 2 bajty Wersja Medium DIF VIF Nr produkcji CS Stop 1 bajt 1 bajt 0Ch 78h 4 bajty xx 16h Tabela 2.5.2 Telegram uruchomienia adresacji rozszerzonej z numerem produkcji W przypadku posiadania numeru produkcji, Slave powinien umieszczać go w każdym telegramie RSP_UD. Na numer produkcji również można nakładać maskę. 2.4.2 Mechanizm FCB a adresacja rozszerzona 1. Slave: Urządzenie przełączone na adresację rozszerzoną, ze względu na więcej możliwości dostępu, przechowuje w pamięci odpowiednio większą ilość ostatnio otrzymanych bitów FCB. Dodatkowo istnieje możliwość skonfigurowania Slave a tak, żeby odpowiadał na telegramy dla innych adresów podstawowych dla każdego z nich przechowuje poprzednie wartości FCB. 2. Master: Master zarządzający urządzeniami adresowanymi w warstwie sieci musi przechowywać w pamięci przyszłe wartości bitów FCB dla każdego z nich.

2.5 Wyszukiwanie Slave ów 1. Adresacja podstawowa: Master musi znać adresy wszystkich obsługiwanych Slave ów. W przypadku wystąpienia błędu oprogramowania lub utraty danych dotyczących adresów, Master może uzupełnić informacje wysyłając REQ_UD2 do wszystkich dostępnych adresów (0-250) dla wszystkich szybkości transmisji. 2. Adresacja rozszerzona: Sposób wyszukiwania Slave ów użyty w adresacji podstawowej nie nadaje się do adresacji rozszerzonej, ponieważ istnieją miliony możliwych kombinacji pełnego adresu i takie przeszukiwanie sieci trwałoby zbyt długo. Z tego powodu wymyślono algorytm przyspieszający tę procedurę. Opis algorytmu: Stosowany algorytm polega na nakładaniu maski na kolejne części adresu rozszerzonego i sprawdzaniu kolejnych cyfr. W zależności od przeszukiwanej składowej adresu, stosowane są różne maski. W Numerze Identyfikacyjnym maska nakładana jest na kolejne cyfry (numer kodowany w BCD), a z kolei dla ID producenta, Wersji i Medium (kodowane binarnie) na cały bajt. Przeszukiwanie numeru identyfikacyjnego dokonywane jest w następujący sposób: maska nakładana jest na wszystkie cyfry z wyjątkiem pierwszej i wysyłany jest telegram SND_UD na adres o numerze identyfikacyjnym 0FFFFFFFFh. Po otrzymaniu potwierdzenia E5h Master wysyła REQ_UD2, wyłuskuje z odpowiedzi dokładny adres i dodaje do pamięci. Jeśli zostanie wykryta kolizja (odpowiedziało więcej niż jedno urządzenie), Master ściąga maskę z następnej cyfry i wysyła telegramy z numerami ID od 00FFFFFFh do 09FFFFFFh i w zależności od odpowiedzi zapamiętuje adres lub ściąga maskę z kolejnej cyfry. Po przeszukaniu wszystkich dostępnych Numerów Identyfikacyjnych, w przypadku występowania kolizji, rozpoczyna się przeszukiwanie kolejnych pól adresu rozszerzonego. Całe postępowanie należy przeprowadzić dla wszystkich szybkości transmisji i obu trybów przesyłania bajtów.