PRZYKŁAD WYKORZYSTANIA PROTOKOŁU DATA CONCENTRATOR SIMPLE ACQUISITION PROTOCOL (DCSAP)
|
|
- Zofia Markiewicz
- 10 lat temu
- Przeglądów:
Transkrypt
1 PRZYKŁAD WYKORZYSTANIA PROTOKOŁU DATA CONCENTRATOR SIMPLE ACQUISITION PROTOCOL (DCSAP) 1/89
2 Spis treści Spis treści Słownik pojęć Wstęp Założenia protokołu Utrzymywanie sesji sieciowej z DCU Idempotentne operacje i separacja sesji Asynchroniczne przekazywanie odpowiedzi Wykorzystanie protokołu DLMS/COSEM Rozszerzona adresacja DLMS Opcjonalne zabezpieczenie za pomocą SSL Komunikacja Polecenia Zapytanie o A+ licznika o identyfikatorze Żądanie ustawienia rozmiaru bufora na pomiary zatrzaskiwane w profilu z drugim okresem zatrzaskiwania do licznika o identyfikatorze Żądanie rozłączenia stycznika licznika o identyfikatorze Odpowiedzi Odpowiedź na zapytanie o A+ licznika o identyfikatorze Odpowiedź na żądanie ustawienia rozmiaru bufora na pomiary zatrzaskiwane w profilu z drugim okresem zatrzaskiwania od licznika o identyfikatorze Odpowiedź na żądanie rozłączenia stycznika licznika o identyfikatorze Notyfikacje Powiadomienie o zdarzeniu zarejestrowanym przez licznik o identyfikatorze 127 w pierwszym dzienniku zdarzeń Obiekty COSEM Reguły numerowania nowych klas i obiektów Dobór nowych identyfikatorów klas interfejsów (class_id) Dobór nowych kodów OBIS Klasy Interfejsów Klasa String list Klasa Meter list /89
3 5.2.3 Klasa Device firmware Klasa Device basic information Klasa Device run information Klasa Event list Klasa DCSAP network statistics Globalne obiekty koncentratora Obiekt Data concentrator meter list Obiekt Data concentrator firmware Obiekt Data concentrator run information Obiekt Data concentrator event list Obiekt Data concentrator NTP server list Obiekt Data concentrator network statistics Sesyjne obiekty koncentratora Obiekt Data concentrator meter data caching enable Obiekt Data concentrator asynchronous notification enable Globalne obiekty liczników realizowane przez koncentrator Obiekt Meter information Obiekt Meter firmware Wykorzystanie protokołu DCSAP Rozpoczęcie sesji DCSAP z koncentratorem Zamknięcie sesji DCSAP Synchronizacja topologii Odczyt rejestru układu Zapis rejestru układu Konfiguracja układu Pobieranie parametrów konfiguracyjnych układu Bezpośrednia komunikacja z układem Restart koncentratora Aktualizacja oprogramowania koncentratora Aktualizacja oprogramowania licznika Wyłączenie stycznika Odbieranie zdarzeń układu Rekomendacje dla implementacji serwera protokołu DCSAP Port TCP /89
4 7.2 Ilość obsługiwanych, równoległych sesji DCSAP Rozmiar listy liczników Rozmiar dziennika zdarzeń Bezpieczeństwo sesji DCSAP Synchronizacja czasu Przepływność pojedynczej sesji DCSAP Model serwera DCSAP Sterowanie przepływem w połączeniu TCP Opis implementacji referencyjnej Kodowanie A-XDR Obsługa gniazd TCP Serwer DCSAP Podsystem połączeń DCSAP Podsystem obiektów DCSAP Podsystem liczników Literatura: /89
5 Spis tabel Tab. 1 Kody błędów dostępne w komunikatach protokołu DCSAP Tab. 2 Reguły doboru kodów OBIS dla nowych obiektów Tab. 3 Klasy interfejsów wprowadzone na potrzeby protokołu DCSAP Tab. 4 Klasa String list (class_id = 40100) Tab. 5 Opis atrybutów klasy String list (class_id = 40100) Tab. 6 Klasa Meter list (class_id = 3300) Tab. 7 Opis atrybutów klasy Meter list (class_id = 40000) Tab. 8 Klasa Device firmware (class_id = 40101) Tab. 9 Kody statusowe aktualizacji oprogramowania jakie może przyjmować atrybut last_update_status klasy Device firmware Tab. 10 Opis atrybutów i metod klasy Device firmware (class_id = 40101) Tab. 11 Klasa Device basic information (class_id = 40102) Tab. 12 Opis atrybutów klasy Device basic information (class_id = 40102) Tab. 13 Klasa Device run information (class_id = 40103) Tab. 14 Opis atrybutów i metod klasy Device run information (class_id = 40103) Tab. 15 Klasa Event list (class id = 40001) Tab. 16 Opis atrybutów i metod klasy Event list (class_id = 40001) Tab. 17 Kody powodów wystąpienia lub zapisania zdarzenia jakie może przyjmować pole reason struktury event_list_entry i opisy pól stowarzyszonych Tab. 18 Klasa DCSAP network statistics (class id = 40002) Tab. 19 Opis atrybutów klasy DCSAP network statistics (class id = 4002) Tab. 20 Globalne obiekty koncentratora Tab. 21 Sesyjne obiekty koncentratora Tab. 22 Globalne obiekty liczników realizowane przez koncentrator /89
6 Spis rysunków Rys. 1 Akwizycja danych oparta o protokół DCSAP... 9 Rys. 2 Sesja DCSAP Rys. 3 Diagram sekwencji operacji wykonywanych przez system akwizycji po rozpoczęciu pierwszej sesji DCSAP z koncentratorem Rys. 4 Diagram sekwencji operacji wykonywanych przez system akwizycji po rozpoczęciu sesji DCSAP z koncentratorem Rys. 5 Diagram sekwencji podtrzymywania połączenia z koncentratorem Rys. 6 Diagram sekwencji próby podtrzymywania połączenia z koncentratorem i bezczynności sesji w przypadku problemów z łączem Rys. 7 Diagram sekwencji odczytu z licznika wariant pomyślny Rys. 8 Diagram sekwencji odczytu z licznika wariant nieprawidłowego atrybutu Rys. 9 Diagram sekwencji odczytu z licznika wariant nieistniejącego obiektu Rys. 10 Diagram sekwencji odczytu z licznika wariant nieznanego identyfikatora licznika Rys. 11 Diagram sekwencji zapisu do licznika wariant pomyślny Rys. 12 Diagram sekwencji zapisu do licznika wariant niepomyślny Rys. 13 Diagram sekwencji zapisu do koncentratora i odczytu bezpośredniego z układu Rys. 14 Diagram sekwencji restartowania koncentratora wariant niepomyślny Rys. 15 Diagram sekwencji restartowania koncentratora wariant pomyślny Rys. 16 Diagram sekwencji aktualizacji oprogramowania koncentratora wariant pomyślny Rys. 17 Diagram sekwencji aktualizacji oprogramowania koncentratora 1. wariant niepomyślny Rys. 18 Diagram sekwencji aktualizacji oprogramowania koncentratora 2. wariant niepomyślny Rys. 19 Diagram sekwencji aktualizacji oprogramowania koncentratora 3. wariant niepomyślny Rys. 20 Diagram sekwencji aktualizacji oprogramowania koncentratora 4. wariant niepomyślny Rys. 21 Diagram sekwencji aktualizacji oprogramowania koncentratora 5. wariant niepomyślny Rys. 22 Diagram sekwencji aktualizacji oprogramowania koncentratora 6. wariant niepomyślny Rys. 23 Diagram sekwencji aktualizacji oprogramowania licznika wariant pomyślny Rys. 24 Diagram sekwencji aktualizacji oprogramowania licznika 1. wariant niepomyślny Rys. 25 Diagram sekwencji aktualizacji oprogramowania licznika 2. wariant niepomyślny Rys. 26 Diagram sekwencji aktualizacji oprogramowania licznika 3. wariant niepomyślny Rys. 27 Diagram sekwencji aktualizacji oprogramowania licznika 4. wariant niepomyślny Rys. 28 Diagram sekwencji aktualizacji oprogramowania licznika 5. wariant niepomyślny Rys. 29 Diagram sekwencji aktualizacji oprogramowania licznika 6. wariant niepomyślny Rys. 30 Diagram sekwencji aktualizacji oprogramowania licznika 7. wariant niepomyślny Rys. 31 Diagram sekwencji rozłączenia stycznika w liczniku Rys. 32 Diagram sekwencji odbierania nowych zdarzeń z licznika /89
7 1 Słownik pojęć Termin/skrót AES Objaśnienie Advanced Encryption Standard symetryczny szyfr blokowy przyjęty przez National Institute of Standard and Technology. AMI Advanced Metering Infrastructure (Zaawansowana Infrastruktura Pomiarowa) kompleksowy system liczników, systemów komunikacyjnych i aplikacji do gromadzenia, przechowywania i analizowania danych pomiarowych oraz zarządzania infrastrukturą pomiarową. ASN.1 Abstract Syntax Notation One standard służący do opisu struktur przeznaczonych do reprezentacji, kodowania, transmisji i dekodowania danych. A-XDR Adapted Extended Data Representation metoda serializacji danych. COSEM DCU DLMS idempotentność OBIS PDU PRIME SAK SSL TCP/IP COmpanion Specification for Energy Metering zbiór specyfikacji opracowanych przez DLMS UA definiujący model informatyczny obiektów m.in. liczników energii elektrycznej. Data Concentrator Unit (koncentrator) element infrastruktury licznikowej, prowadzi m.in. lokalną akwizycję danych z liczników w swoim obszarze, urządzenie ma za zadanie automatycznie wykrywać i adresować liczniki. Device Language Message Specification zorientowany połączeniowo protokół warstwy aplikacji przeznaczony m.in. do dwukierunkowej wymiany danych z licznikami energii elektrycznej. Własność pewnych operacji, która pozwala na ich wielokrotne stosowanie bez zmiany wyniku. OBject Identification System system kodowania obiektów modelu COSEM. Protocol Data Unit jednostka danych w protokole. PoweRline Intelligent Metering Evolution otwarta specyfikacja definiująca łączność w najniższych warstwach systemu komunikacyjnego po PLC od urządzeń końcowych (liczników) do koncentratora danych umieszczonego w stacji transformatorowej SN/nn. System Akwizycji część Aplikacji AMI odpowiedzialna za pozyskiwanie odczytów z liczników energii elektrycznej poprzez koncentratory danych. Secure Socket Layer protokół mający na celu zapewnienie poufności i integralności transmisji danych oraz zapewnienie uwierzytelnienia, opiera się na szyfrach asymetrycznych oraz certyfikatach standardu X.509. Transmission Control Protocol/Internet Protocol zestaw protokołów warstwy transportowej (TCP) oraz sieciowej (IP), zapewniający ujednolicony sposób 7/89
8 URL przesyłania danych w różnych typach sieci. Uniform Resource Locator format adresowania zasobów w sieci. 8/89
9 2 Wstęp Protokół DCSAP został opracowany z myślą o komunikacji pomiędzy systemem akwizycji danych pomiarowych (SAK) a koncentratorami liczników energii elektrycznej (DCU), pośredniczącymi w komunikacji z licznikami. U podstaw akwizycji za pomocą protokołu DCSAP leży założenie o komunikacji z koncentratorami za pomocą strumienia instrukcji akwizycji przekazywanego poprzez dwukierunkowe, bezstratne połączenie utrzymywane z każdym koncentratorem. Instrukcja akwizycji (operacja) to pojedyncze polecenie zapisu/odczytu atrybutu lub wywołanie metody rejestru układu pomiarowego/koncentratora. Akwizycja za pomocą DCSAP została schematycznie przedstawiona na Rys. 1. Rys. 1 Akwizycja danych oparta o protokół DCSAP System akwizycji (SAK) nawiązuje połączenia ze wszystkimi koncentratorami, a następnie zleca im wykonywanie różnych operacji. Są wśród nich operacje zmieniające stan koncentratorów i liczników. Większość operacji dotyczy jednak odczytu danych pomiarowych. Za pomocą tego samego połączenia odbierane są wyniki zleconych operacji pomiarowych oraz asynchroniczne notyfikacje zdarzeń pochodzące od koncentratora i liczników. 9/89
10 Komunikacja z koncentratorami i licznikami realizowana jest w jednolity sposób, tzn. instrukcje akwizycji dla układów pomiarowych i koncentratorów maja taki sam format oraz dotyczą obiektów pomiarowych albo kontrolnych, dostępnych zarówno w układach pomiarowych oraz na koncentratorach. Sposób przekazywania instrukcji akwizycji do koncentratora i układów pomiarowych przedstawiono schematycznie na Rys. 2. Rys. 2 Sesja DCSAP Na Rys. 2 zaznaczono strumień instrukcji adresowanych do obiektów koncentratora oraz do obiektów układów pomiarowych. Założono, ze struktura obiektów koncentratora oraz układów pomiarowych (klasy tych obiektów) jest zgodna ze standardem COSEM [1], [7]. Obiekty koncentratora służą do realizacji jego podstawowych funkcji takich jak pobieranie listy dostępnych układów pomiarowych, informacji o topologii sieci tych układów, aktualizacji oprogramowania, itp. W ramach obiektów koncentratora wyróżniono obiekty globalne, współdzielone pomiędzy sesjami oraz obiekty sesyjne, dostępne wyłącznie w ramach danego połączenia. Obiekty sesyjne wprowadzono w celu sterowania parametrami pojedynczej sesji z systemem akwizycji. Obiektem globalnym jest np. obiekt zawierający listę dostępnych układów pomiarowych. Obiekty układów pomiarowych to standardowe obiekty realizujące funkcje pomiarowe i sterujące. W kolejnych rozdziałach dokumentu opisano: założenia dla komunikacji za pomocą protokołu DCSAP, syntaktykę i semantykę komunikacji, strukturę obiektów koncentratora (globalnych i sesyjnych), przykłady wykorzystania protokołu DCSAP (przypadki użycia), rekomendacje dla implementacji protokołu oraz opracowaną implementację referencyjną serwera protokołu DCSAP, która może zostać zintegrowana z oprogramowaniem koncentratora. 10/89
11 3 Założenia protokołu Protokół został opracowany zgodnie z następującymi założeniami. 3.1 Utrzymywanie sesji sieciowej z DCU Komunikacja pomiędzy serwerem systemu akwizycji a koncentratorem odbywa się poprzez pojedyncze połączenie TCP/IP tworzące sesje. Sesja nie jest ograniczona czasowo i może być podtrzymywana tak długo jak tylko pozwalają na to warunki telekomunikacyjne. Przy tym nie jest zakładana obecność opcji keepalive połączenia TCP system akwizycji, w przypadku braku żądań, okresowo wysyła pusty komunikat, który koncentrator musi odesłać w niezmienionej postaci. Pozwala to sprawdzić czy połączenie z koncentratorem nie zostało utracone. Połączenie nawiązywane jest od strony systemu akwizycji. Z tego względu wszystkie koncentratory musza być osiągalne adresowo w warstwie IP dla systemu akwizycji. System akwizycji może nawiązać wiele sesji z pojedynczym DCU. 3.2 Idempotentne operacje i separacja sesji Wszystkie operacje i ich wyniki przesyłane są w ramach jednej sesji i nie propagują się na kolejne. W przypadku zamknięcia lub zerwania połączenia TCP/IP anulowane są wszystkie niezrealizowane polecenia. Zakłada się, ze system akwizycji po rozpoczęciu kolejnej sesji ponownie zleci operacje, których wykonanie nie zostało do tej pory potwierdzone. Takie rozwiązanie powoduje możliwość wielokrotnego zlecenia danej operacji jeżeli została ona wykonana w poprzedniej sesji, a potwierdzenie nie zostało dostarczone. Nie zdecydowano się na przeciwdziałanie takim sytuacjom na przykład poprzez użycie unikalnych identyfikatorów operacji. Dzięki temu protokół i jego implementacja staja się prostsze i nie ma potrzeby utrzymywania po stronie koncentratora żadnego kontekstu propagującego się pomiędzy sesjami. Z tego względu wszystkie polecenia musza być idempotentne, a odpowiedzialność za utrzymanie pożądanego stanu koncentratorów i liczników przeniesiona jest na system akwizycji. 11/89
12 3.3 Asynchroniczne przekazywanie odpowiedzi Odpowiedzi na zlecone polecenia przekazywane są z powrotem do systemu akwizycji tym samym połączeniem TCP/IP. Proces ten odbywa się asynchronicznie w stosunku do kolejno przekazywanych operacji, dzięki czemu system akwizycji może zlecać kolejne operacje zanim otrzyma potwierdzenie wykonania poprzednich. Tą samą drogą co odpowiedzi przekazywane są asynchroniczne notyfikacje pochodzące z koncentratora i liczników. 3.4 Wykorzystanie protokołu DLMS/COSEM Protokół DCSAP musi zapewnić możliwość wywoływania poleceń DLMS na poszczególnych licznikach. Dlatego zdecydowano się użyć protokołu DLMS jako bazy, a wszystkie dodatkowe funkcjonalności osiągnięto poprzez zdefiniowanie specyficznych obiektów COSEM reprezentujących logikę koncentratora. Istnieje możliwość definiowania dodatkowych, specyficznych obiektów służących do sterowania unikalnymi mechanizmami opracowanymi przez producentów koncentratorów. Oznacza to, ze protokół DCSAP jest łatwo rozszerzalny i będzie nadążał za nowymi potrzebami. 3.5 Rozszerzona adresacja DLMS W warstwie komunikacyjnej protokół DLMS rozszerzono o identyfikator / adres urządzenia, którego dotyczy dane polecenie. Dzięki temu po nawiązaniu sesji z koncentratorem przekazywane mogą być polecenia DLMS dla wszystkich liczników obsługiwanych przez dany koncentrator. Sam koncentrator również posiada dobrze określony identyfikator w tej przestrzeni i może być adresatem poleceń DLMS. 3.6 Opcjonalne zabezpieczenie za pomocą SSL Szyfrowanie komunikacji może zostać zrealizowane za pomocą protokołu SSL na poziomie połączenia TCP/IP. Jest ono jednak opcjonalne i zakłada się, ze zarzadzanie kluczami i inne zagadnienia związane z szyfrowaniem zostaną rozwiązane poza protokołem DCSAP. Istnieje też możliwość sterowania opcjonalnymi mechanizmami koncentratora dotyczącymi szyfrowania poprzez protokół DCSAP, o ile tylko producent zdefiniuje odpowiednie obiekty COSEM do tego przeznaczone. 12/89
13 4 Komunikacja W komunikacji pomiędzy systemem akwizycji a koncentratorami używane są komunikaty kodowane zgodnie ze standardem A-XDR [3]. Pierwotnie planowane było użycie kodowania BER, ale ponieważ to A-XDR jest używany w komunikacji DLMS jak i w warstwie aplikacji COSEM, kodując przy tym te same dane w mniejszej liczbie bajtów niż pozwalają na to inne protokoły komunikacji dedykowane do rozwiązań Smart Metering [10], postanowiono ostatecznie zastosować efektywniejsze kodowanie. Podstawę stanowi komunikat DLMS, do którego dodane zostały identyfikator urządzenia, identyfikator komunikatu oraz rozmiar komunikatu DLMS stający się kodem błędu w przypadku wartości ujemnych. Na listingu 1 przedstawiono opis w formacie ASN.1. Typy Unsigned32, Unsigned64 i Integer32 zdefiniowano w dokumencie [2], [5] i są to typy INTEGER z odpowiednimi zakresami przyjmowanych wartości, przez co w postaci zakodowanej zajmują odpowiednio 4, 8 i 4 bajty. Tym samym nagłówek komunikatu ma zawsze stały rozmiar wynoszący 16 bajtów. Typ xdlms- APDU zdefiniowano w tym samym dokumencie. DCSAP-PDU ::= SEQUENCE { } device-id Unsigned32 -- identyfikator urządzenia message-id Unsigned64 -- identyfikator komunikatu data-size Integer32 -- rozmiar danych DLMS lub kod błędu dlms-data xdlms-apdu -- dane DLMS (pole obecne tylko gdy data-size > 0) Listing 1. Struktura komunikatu protokołu DCSAP Komunikaty DCSAP-PDU służą do przesyłania poleceń z systemu akwizycji do koncentratora, a także do przesyłania odpowiedzi i notyfikacji o zdarzeniach z koncentratora do systemu akwizycji. Komunikaty przesyłane są asynchronicznie w obu kierunkach. Znaczenie kolejnych pól komunikatu wyjaśniono w komentarzach na Listing 1. Identyfikator urządzenia wskazuje na koncentrator lub licznik w nim zarejestrowany, który jest adresatem polecenia. W przypadku odpowiedzi pochodzącej z koncentratora, identyfikator urządzenia wskazuje na nadawcę komunikatu. W przypadku odpowiedzi lub notyfikacji określa, z którego licznika lub koncentratora pochodzi. Wartość 0 oznacza koncentrator, natomiast kolejne wartości są dynamicznie przydzielane przez koncentrator wykrytym i zarejestrowanym licznikom. Polityka przydzielania identyfikatorów zależy od producenta koncentratora. Identyfikator komunikatu polecenia musi być użyty przez koncentrator w komunikacie będącym odpowiedzią na niego. Polityka używania identyfikatorów komunikatów zależy od systemu akwizycji, ale powinna być wykorzystana do powiązania odpowiedzi z poleceniem, zwłaszcza jeżeli system akwizycji wysyła kolejne polecenia nie czekając na odpowiedzi do poprzednich. W komunikacie notyfikacji to pole musi przyjmować wartość 0. 13/89
14 Rozmiar danych DLMS musi być zgodny z dalszą zawartością komunikatu. Wartość ta służy do separowania komunikatów bez potrzeby analizy struktury danych DLMS. Wartości niedodatnie oznaczają brak danych DLMS, czyli brak pola dlms-data. Wartość 0 służy do kontroli połączenia i taki komunikat koncentrator musi odesłać w niezmienionej postaci. Wartości ujemne mogą się pojawić jedynie w odpowiedzi koncentratora na żądania źle zaadresowane, źle wypełnione, nieotrzymujące odpowiedzi z docelowego urządzenia w maksymalnym czasie przewidzianym przez koncentrator lub zaadresowane do urządzeń, w których zostały wcześniej zainicjowane czynności utrzymaniowe (jak aktualizacja oprogramowania), wymagające zaprzestania na pewien czas pełnienia przez te urządzenia ich standardowych funkcji. Zwracane wówczas kody błędów przedstawiono w Tab. 1. [7]. Typy danych używane w komunikatach DLMS zostały szczegółowo opisane w dokumencie [2], KB Symbol Opis -1 EUNKNOWN Nieznany identyfikator urządzenia. -2 EWRONGSIZE Nieprawidłowy rozmiar danych (ujemny). -3 EPARTIAL Niekompletne dane. -4 EINVALID Nieprawidłowe dane. -5 ETIMEOUT Czas oczekiwania na odpowiedź z urządzenia uległ przekroczeniu. -6 EINACCESSIBLE Urządzenie jest świadomie niedostępne (np. z powodu aktualizacji). Tab. 1 Kody błędów dostępne w komunikatach protokołu DCSAP Kody błędów może zgłaszać jedynie koncentrator. Powinien ich używać tylko wtedy, gdy komunikat jest źle zaadresowany, niepoprawnie zbudowany, próba uzyskania odpowiedzi na wyrażone w nim żądanie do docelowego urządzenia nie powodzi się w czasie, który konc entrator uznaje za maksymalny lub też koncentrator zainicjował uprzednio zlecenie, którego realizacja wymaga tymczasowego zaprzestania świadczenia przez to urządzenie dedykowanych usług. Nie należy tych błędów mylić z błędami przewidzianymi w typach Data-Access-Result i Action-Result (używanymi w odpowiedziach), dotyczącymi komunikacji w warstwie DLMS/COSEM. 14/89
15 4.1 Polecenia W poleceniach DCSAP mogą zostać użyte następujące typy i warianty komunikatów DLMS: get-request [192] IMPLICIT Get-Request get-request-normal [1] IMPLICIT Get-Request-Normal get-request-with-list [3] IMPLICIT Get-Request-With-List set-request [193] IMPLICIT Set-Request set-request-normal [1] IMPLICIT Set-Request-Normal set-request-with-list [4] IMPLICIT Set-Request-With-List action-request [195] IMPLICIT Action-Request action-request-normal [1] IMPLICIT Action-Request-Normal action-request-with-list [3] IMPLICIT Action-Request-With-List DLMS definiuje dodatkowo warianty komunikatów, które mają zastosowanie w przypadku, gdy ramki w protokole łącza danych mają ograniczony maksymalny rozmiar. DCSAP działa w warstwie wyższej i wykorzystuje strumieniowy protokół TCP, który nie ma takiego ograniczenia. Jednakże w komunikacji koncentratora z licznikami bardzo prawdopodobne jest wystąpienie wspomnianego ograniczenia, dlatego koncentrator musi wówczas przepakować żądanie do licznika tak, by mógł je przesłać używanym medium. Komunikaty DLMS poleceń w polu invoke-id-and-priority posiadają bit priority, który oznacza żądania o zwiększonym priorytecie. Koncentrator odbierając komunikat z ustawionym bitem priority powinien obsłużyć zawarte w nim żądanie przed dotychczas niezrealizowanymi jeszcze żądaniami, które nie mają tego bitu ustawionego. Kolejność obsługi żądań o zwiększonym priorytecie w koncentratorze powinna być zgodna z kolejnością ich otrzymywania. Pozostałe bity w polu invoke-id-and-priority nie są używane przez system akwizycji, dlatego koncentrator w razie konieczności może je dowolnie modyfikować pole invoke-id-and-priority w odpowiedzi nie musi być zgodne z invoke-id-and-priority polecenia. Dalej przedstawiono przykłady poleceń oraz sposób ich kodowania: 15/89
16 4.1.1 Zapytanie o A+ licznika o identyfikatorze 1 DCSAP-PDU device-id (= 1) message-id (= 257) D data-size (= 13) xdlms-apdu C0 get-request Get-Request 01 get-request-normal Get-Request-Normal 00 invoke-id-and-priority (priority = 0) Cosem-Attribute-Descriptor cosem-attribute-descriptor (= 3/1-0:1.8.0*255/2) Cosem-Class-Id class-id (= 3) Cosem-Object-Instance-Id instance-id (= 1-0:1.8.0*255) FF Cosem-Object-Attribute-Id attribute-id (= 2) 02 Selective-Access-Descriptor access-selection (= nothing) OPTIONAL 00 (= not present) 16/89
17 4.1.2 Żądanie ustawienia rozmiaru bufora na pomiary zatrzaskiwane w profilu z drugim okresem zatrzaskiwania do licznika o identyfikatorze 11 DCSAP-PDU B device-id (= 11) message-id (= 65537) data-size (= 18) xdlms-apdu C1 Set-Request set-request 01 set-request-normal Set-Request-Normal 00 invoke-id-and-priority (priority = 0) Cosem-Attribute-Descriptor cosem-attribute-descriptor (= 7/1-0:99.2.0*255/8) Cosem-Class-Id class-id (= 7) Cosem-Object-Instance-Id instance-id (= 1-0:99.2.0*255) FF Cosem-Object-Attribute-Id attribute-id (= 8) 08 Selective-Access-Descriptor Data OPTIONAL access-selection (= nothing) 00 (= not present) value 06 double-long-unsigned (= 200) C8 17/89
18 4.1.3 Żądanie rozłączenia stycznika licznika o identyfikatorze 15 DCSAP-PDU F device-id (= 15) message-id (= 258) C data-size (= 12) xdlms-apdu C3 Action-Request action-request 01 action-request-normal Action-Request-Normal 80 invoke-id-and-priority (priority = 1) Cosem-Method-Descriptor cosem-method-descriptor (= 70/0-0: *255/1) Cosem-Class-Id class-id (= 70) Cosem-Object-Instance-Id instance-id (= 0-0: *255) A FF Cosem-Object-Method-Id method-id (= 1) 01 18/89
19 4.2 Odpowiedzi W odpowiedziach na polecenia DCSAP mogą zostać użyte następujące typy i warianty komunikatów DLMS: get-response [196] IMPLICIT Get-Response get-response-normal [1] IMPLICIT Get-Response-Normal get-response-with-list [3] IMPLICIT Get-Response-With-List set-response [197] IMPLICIT Set-Response set-response-normal [1] IMPLICIT Set-Response-Normal set-response-with-list [5] IMPLICIT Set-Response-With-List action-response [199] IMPLICIT Action-Response action-response-normal [1] IMPLICIT Action-Response-Normal action-response-with-list [3] IMPLICIT Action-Response-With-List Jeżeli duża odpowiedź z licznika zostanie rozbita na wiele ramek przy transmisji do koncentratora, powinna zostać przepakowana w jedną odpowiedź przesyłaną do systemu akwizycji. Na jeden komunikat polecenia wysyłany przez system akwizycji do koncentratora powinien w odpowiedzi zawsze przyjść jeden komunikat z odpowiedzią operacji. Przykłady odpowiedzi dla prezentowanych wcześniej przykładów poleceń oraz sposób ich kodowania przedstawiono na kolejnej stronie tego podrozdziału. 19/89
20 4.2.1 Odpowiedź na zapytanie o A+ licznika o identyfikatorze 1 DCSAP-PDU device-id (= 1) message-id (= 257) D data-size (= 13) xdlms-apdu C4 Get-Response get-response 01 get-response-normal Get-Response-Normal 00 invoke-id-and-priority Get-Data-Result result (= 54132) 00 data Data 15 long64-unsigned D3 74 (= 54132) Odpowiedź na żądanie ustawienia rozmiaru bufora na pomiary zatrzaskiwane w profilu z drugim okresem zatrzaskiwania od licznika o identyfikatorze 11 DCSAP-PDU B device-id (= 11) message-id (= 65537) data-size (= 4) xdlms-apdu C5 set-response Set-Response 01 set-response-normal Set-Response-Normal 00 invoke-id-and-priority (priority = 0) Data-Access-Result result (= 3 - read-write-denied) 03 20/89
21 4.2.3 Odpowiedź na żądanie rozłączenia stycznika licznika o identyfikatorze 15 DCSAP-PDU F device-id (= 15) message-id (= 258) data-size (= 5) xdlms-apdu C7 action-response Action-Response 01 action-response-normal Action-Response-Normal 80 invoke-id-and-priority Action-Response-With-Optional-Data single-response Action-Result result (= 0 - success) 00 Get-Data-Result return-parameters (= nothing) OPTIONAL 00 (= not present) 21/89
22 4.3 Notyfikacje Notyfikacje zawierają następujący typ komunikatu DLMS: event-notification-request [194] IMPLICIT EventNotificationRequest Mechanizm notyfikacji służy do asynchronicznego powiadamiania systemu akwizycji o zdarzeniach i zmianach zachodzących w koncentratorze oraz licznikach. Jest to mechanizm opcjonalny z punktu widzenia użytkowego (i domyślnie wyłączony w każdej nowej sesji), ale jego obsługa na koncentratorze jest obowiązkowa. System akwizycji może alternatywnie cyklicznie sprawdzać stan odpowiednich obiektów. Takie sprawdzanie jest dużo mniej wydajne, ale może się okazać jedynym rozwiązaniem dla tych koncentratorów, z którymi komunikacja odbywa się poprzez medium bez algorytmów unikania i wykrywania kolizji. W takim przypadku system akwizycji musi w pełni kontrolować transmisję w obu kierunkach. Można to zagwarantować wykonując pojedyncze polecenia i czekając na odpowiedzi do nich oraz nie uaktywniając asynchronicznego przesyłania notyfikacji. Przykład notyfikacji oraz sposób jej kodowania podano w dalszej części tego podrozdziału Powiadomienie o zdarzeniu zarejestrowanym przez licznik o identyfikatorze 127 w pierwszym dzienniku zdarzeń DCSAP-PDU F device-id (= 127) message-id (= 0) C data-size (= 12) xdlms-apdu C2 Event-Notification-Request OCTET STRING OPTIONAL event-notification-request time (= nothing) 00 (= not present) Cosem-Attribute-Descriptor cosem-attribute-descriptor (= 7/0-0: *255/2) Data Cosem-Class-Id class-id (= 7) Cosem-Object-Instance-Id instance-id (= 0-0: *255) FF Cosem-Object-Attribute-Id attribute-id (= 2) FF 02 attribute-value dont-care 22/89
23 5 Obiekty COSEM Koncentrator, żeby spełniać swoją funkcję, musi realizować kilka podstawowych mechanizmów. Sterowanie oraz pobieranie wyników działania tych mechanizmów odbywa się poprzez specyficzne atrybuty i metody odpowiednich obiektów COSEM zdefiniowanych dla koncentratora. Te atrybuty i metody są generalizowane za pomocą klas interfejsów COSEM stowarzyszonych z tymi obiektami. System akwizycji korzysta z obiektów dla koncentratora tak samo jak z obiektów przewidzianych dla liczników. Specyfikacja protokołu DCSAP zawiera minimalny zestaw takich obiektów i opisuje ich semantykę. Producenci urządzeń mogą przedstawiać swoje specyficzne mechanizmy i związane z nimi obiekty realizujące dodatkową funkcjonalność. W ten sposób protokół DCSAP jest łatwo rozszerzalny. Specyficzne obiekty COSEM koncentratora zostały podzielone na dwie główne kategorie. Pierwsza z nich dotyczy globalnych mechanizmów, pozwala odczytać oraz zmienić aktualny stan koncentratora. Druga grupa to obiekty sesyjne, związane ze stanem aktualnej sesji. Ich zmiany nie propagują się pomiędzy sesjami zarówno tymi nawiązanymi po sobie jak i utrzymywanymi równolegle. Można powiedzieć, że z każdą sesją związane są tymczasowe obiekty, które można odczytywać i używać do sterowania tą konkretną sesją. Dodatkowo zdefiniowane zostały globalne obiekty liczników realizowane przez koncentrator. Są one realizowane przez oprogramowanie koncentratora, ale istnieją w niezależnych instancjach dla każdego zarejestrowanego licznika. Dostęp do nich z poziomu protokołu DCSAP, poza standardowym podaniem deskryptora atrybutu lub metody COSEM w stosownym typie komunikatu DLMS, wymaga posłużenia się w nagłówku tego komunikatu identyfikatorem urządzenia należącym do licznika (zamiast koncentratora, a więc różnym od 0). Wszystkie obiekty realizowane przez koncentrator i zdefiniowane w ramach tej dokumentacji mają następujące cechy: 1. Żądania ich dotyczące i operujące na wielu obiektach (tj. Get-Request-With-List, Set-Request- With-List lub Action-Request-With-List) nie mogą odwoływać się w jednym i tym samym żądaniu do obiektów nierealizowanych przez koncentrator (np. obiektów zaimplementowanych w licznikach). 2. Realizacja żądań odwołujących się do nich jest bezzwłoczna i do tego synchroniczna, tzn. są obsługiwane natychmiastowo (jedyne zwłoki wynikają z opóźnień dostępu do pożądanych lub zmienianych obiektów) i bez sięgania do zewnętrznych zasobów (tj. znajdujących się poza koncentratorem lub wymagających komunikacji z urządzeniami zewnętrznymi), co dodatkowo ułatwia implementację. 3. Dotyczące ich powiadomienia wysyłane są dopiero po zakończeniu zmiany czy aktualizacji, której dotyczą, a nie w jej trakcie bądź też przy rozpoczęciu jej wykonywania. 23/89
Data Concentrator Simple Acquisition Protocol
Data Concentrator Simple Acquisition Protocol Wersja: 1.0.4 Data: 2014-10-17 Mając na uwadze, że niniejszy materiał jest udostępniany nieodpłatnie, zostaje on udostępniany w takiej formie w jakiej zapoznał
Data Concentrator Simple Acquisition Protocol Wersja: Data:
Data Concentrator Simple Acquisition Protocol Wersja: 2.0.2 Data: 2016-07-15 Wyłącznie do użytku wewnętrznego w projekcie. 1 Historia zmian dokumentu Projekt Tytuł dokumentu Aplikacja AMI Data Concentrator
4. Podstawowa konfiguracja
4. Podstawowa konfiguracja Po pierwszym zalogowaniu się do urządzenia należy zweryfikować poprawność licencji. Można to zrobić na jednym z widżetów panelu kontrolnego. Wstępną konfigurację można podzielić
Przesyłania danych przez protokół TCP/IP
Przesyłania danych przez protokół TCP/IP PAKIETY Protokół TCP/IP transmituje dane przez sieć, dzieląc je na mniejsze porcje, zwane pakietami. Pakiety są często określane różnymi terminami, w zależności
TRX API opis funkcji interfejsu
TRX Krzysztof Kryński Cyfrowe rejestratory rozmów seria KSRC TRX API opis funkcji interfejsu Kwiecień 2013 Copyright TRX TRX ul. Garibaldiego 4 04-078 Warszawa Tel. 22 871 33 33 Fax 22 871 57 30 www.trx.com.pl
Model OSI. mgr inż. Krzysztof Szałajko
Model OSI mgr inż. Krzysztof Szałajko Protokół 2 / 26 Protokół Def.: Zestaw reguł umożliwiający porozumienie 3 / 26 Komunikacja w sieci 101010010101101010101 4 / 26 Model OSI Open Systems Interconnection
1 Moduł Inteligentnego Głośnika
1 Moduł Inteligentnego Głośnika Moduł Inteligentnego Głośnika zapewnia obsługę urządzenia fizycznego odtwarzającego komunikaty dźwiękowe. Dzięki niemu możliwa jest konfiguracja tego elementu Systemu oraz
1 Moduł Inteligentnego Głośnika 3
Spis treści 1 Moduł Inteligentnego Głośnika 3 1.1 Konfigurowanie Modułu Inteligentnego Głośnika........... 3 1.1.1 Lista elementów Modułu Inteligentnego Głośnika....... 3 1.1.2 Konfigurowanie elementu
Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP
Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie
Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP
Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw
Specyfikacja HTTP API. Wersja 1.6
Specyfikacja HTTP API Wersja 1.6 1. Wprowadzenie Platforma PlaySMS umożliwia masową rozsyłkę SMS-ów oraz MMS-ów marketingowych. Umożliwiamy integrację naszej platformy z dowolnym systemem komputerowym
Konfiguracja parametrów pozycjonowania GPS 09.05.2008 1/5
Konfiguracja parametrów pozycjonowania GPS 09.05.2008 1/5 Format złożonego polecenia konfigurującego system pozycjonowania GPS SPY-DOG SAT ProSafe-Flota -KGPS A a B b C c D d E e F f G g H h I i J j K
SERWER AKTUALIZACJI UpServ
Wersja 1.12 upserv_pl 11/16 SERWER AKTUALIZACJI UpServ SATEL sp. z o.o. ul. Budowlanych 66 80-298 Gdańsk POLSKA tel. 58 320 94 00 serwis 58 320 94 30 dz. techn. 58 320 94 20; 604 166 075 www.satel.pl SATEL
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl wersja.2.9 data 2014-11-21 Opis usług: P24 KOD P24 KLUCZ P24 WAPA SEND SMS Strona 1 z 8 P24 KOD Przebieg transakcji Operacje po stronie Sprzedawcy
Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc
Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...
System DiLO. Opis interfejsu dostępowego v. 2.0
System DiLO Opis interfejsu dostępowego v. 2.0 Warszawa 2015 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie możliwości przejścia z wydania karty w POZ (WK-POZ) do zabiegu operacyjnego (ZAB-OPER)
INSTRUKCJA OBSŁUGI DLA SIECI
INSTRUKCJA OBSŁUGI DLA SIECI Zapisywanie dziennika druku w lokalizacji sieciowej Wersja 0 POL Definicje dotyczące oznaczeń w tekście W tym Podręczniku użytkownika zastosowano następujące ikony: Uwagi informują
1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail
1 Moduł E-mail Moduł E-mail daje użytkownikowi Systemu możliwość wysyłania wiadomości e-mail poprzez istniejące konto SMTP. System Vision może używać go do wysyłania informacji o zdefiniowanych w jednostce
SKRÓCONA INSTRUKCJA PROGRAMU W ASPEKCIE WSPÓŁPRACY Z CENTRALNĄ EWIDENCJĄ POJAZDÓW I KIEROWCÓW CEPIK 2.0. Wrocław październik 2017 r.
BATECH 2.0 SKRÓCONA INSTRUKCJA PROGRAMU W ASPEKCIE WSPÓŁPRACY Z CENTRALNĄ EWIDENCJĄ POJAZDÓW I KIEROWCÓW CEPIK 2.0 Wrocław październik 2017 r. Program BATECH 2.0, przystosowany do współpracy z CEPiK 2.0,
Uproszczony opis obsługi ruchu w węźle IP. Trasa routingu. Warunek:
Uproszczony opis obsługi ruchu w węźle IP Poniższa procedura jest dokonywana dla każdego pakietu IP pojawiającego się w węźle z osobna. W routingu IP nie wyróżniamy połączeń. Te pojawiają się warstwę wyżej
Polityka prywatności Spółdzielni Mieszkaniowej Słoneczny Stok
Polityka prywatności Spółdzielni Mieszkaniowej Słoneczny Stok Spółdzielnia Mieszkaniowa Słoneczny Stok szanuje prawo do prywatności Użytkowników serwisu sm-slonecznystok.pl. W szczególności dba o ochronę
Rozdział ten zawiera informacje na temat zarządzania Modułem Modbus TCP oraz jego konfiguracji.
1 Moduł Modbus TCP Moduł Modbus TCP daje użytkownikowi Systemu Vision możliwość zapisu oraz odczytu rejestrów urządzeń, które obsługują protokół Modbus TCP. Zapewnia on odwzorowanie rejestrów urządzeń
Materiały dodatkowe Krótka charakterystyka protokołu MODBUS
Katedra Inżynierii Systemów Sterowania Materiały dodatkowe Krótka charakterystyka protokołu MODBUS Opracowali: mgr inż. Tomasz Karla Data: Luty, 2017 r. Dodatkowe informacje Materiały dodatkowe mają charakter
Rozdział ten zawiera informacje o sposobie konfiguracji i działania Modułu OPC.
1 Moduł OPC Moduł OPC pozwala na komunikację z serwerami OPC pracującymi w oparciu o model DA (Data Access). Dzięki niemu można odczytać stan obiektów OPC (zmiennych zdefiniowanych w programie PLC), a
Wymagania bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3-fazowych liczników energii elektrycznej. Wymaganie techniczne
Wymagania bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3-fazowych liczników energii elektrycznej Lp. 1. Wymagania ogólne Wymaganie techniczne 1.1 Licznik musi posiadać aktywną funkcję Watchdog
Spis treści. 1 Moduł Modbus TCP 4
Spis treści 1 Moduł Modbus TCP 4 1.1 Konfigurowanie Modułu Modbus TCP................. 4 1.1.1 Lista elementów Modułu Modbus TCP............ 4 1.1.2 Konfiguracja Modułu Modbus TCP.............. 5 1.1.3
Klient-Serwer Komunikacja przy pomocy gniazd
II Klient-Serwer Komunikacja przy pomocy gniazd Gniazda pozwalają na efektywną wymianę danych pomiędzy procesami w systemie rozproszonym. Proces klienta Proces serwera gniazdko gniazdko protokół transportu
Referencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37
Referencyjny model OSI 3 listopada 2014 Mirosław Juszczak 37 Referencyjny model OSI Międzynarodowa Organizacja Normalizacyjna ISO (International Organization for Standarization) opracowała model referencyjny
Sieci komputerowe Warstwa transportowa
Sieci komputerowe Warstwa transportowa 2012-05-24 Sieci komputerowe Warstwa transportowa dr inż. Maciej Piechowiak 1 Wprowadzenie umożliwia jednoczesną komunikację poprzez sieć wielu aplikacjom uruchomionym
Elektroniczna Skrzynka Podawcza
Elektroniczna Skrzynka Podawcza Instrukcja dla administratora Wersja 1.6.0 Przewodnik przeznaczony jest dla użytkowników, którzy administrują kontem urzędu w systemie Elektronicznej Skrzynki Podawczej.
MODEL WARSTWOWY PROTOKOŁY TCP/IP
MODEL WARSTWOWY PROTOKOŁY TCP/IP TCP/IP (ang. Transmission Control Protocol/Internet Protocol) protokół kontroli transmisji. Pakiet najbardziej rozpowszechnionych protokołów komunikacyjnych współczesnych
Projekt AMIplus Opis modelu komunikacji modułu wireless M-BUS wersja r.
Wpisz ID i nazwę Projektu Projekt AMIplus Opis modelu komunikacji modułu wireless M-BUS wersja 1.0 01.10.2016r. Spis treści 1. KOMUNIKACJA WIRELESS M-BUS W LICZNIKACH AMI... 3 2. KARTA KATALOGOWA MODUŁU
Programator Kart Master - klient
Programator Kart Master - klient Kraków 2002.11.27 SPIS TREŚCI 1 WSTĘP... 2 2 ROZPOCZĘCIE PRACY Z PROGRAMEM... 3 3 ZMIANA KLUCZA DOSTĘPU.... 4 4 GENEROWANIE KART UŻYTKOWNIKÓW... 5 1 1 Wstęp Programator
Remote Quotation Protocol - opis
Remote Quotation Protocol - opis Michał Czerski 20 kwietnia 2011 Spis treści 1 Streszczenie 1 2 Cele 2 3 Terminologia 2 4 Założenia 2 4.1 Połączenie............................... 2 4.2 Powiązania z innymi
Brinet sp. z o.o. wyłączny przedstawiciel DrayTek w Polsce www.brinet.pl www.draytek.pl
1. Firmware Upgrade Utility 1.1. Metoda 1 (standardowa) 1.2. Metoda 2 (niestandardowa) 2. Serwer FTP 2.1. Lokalny serwer FTP 2.2. Zdalny serwer FTP 3. Upgrade przez Web Procedury aktualizacji zostały oparte
Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark
Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark Topologia Cele Część 1: Zapisanie informacji dotyczących konfiguracji IP komputerów Część 2: Użycie programu Wireshark do przechwycenia
Projekt wymagań bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3- fazowych liczników energii elektrycznej:
Projekt wymagań bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3- fazowych liczników energii elektrycznej: Lp. 1. Wymagania ogólne Wymaganie techniczne 1.1 Licznik musi posiadać aktywną funkcję
Podręcznik użytkownika
Podręcznik użytkownika Moduł kliencki Kodak Asset Management Software Stan i ustawienia zasobów... 1 Menu Stan zasobów... 2 Menu Ustawienia zasobów... 3 Obsługa alertów... 7 Komunikaty zarządzania zasobami...
Opracowanie protokołu komunikacyjnego na potrzeby wymiany informacji w organizacji
Opracowanie protokołu komunikacyjnego na potrzeby wymiany informacji w organizacji Robert Hryniewicz Promotor: dr inż. Krzysztof Różanowski Cele pracy Opracowanie protokołu komunikacyjnego służącego do
Instrukcja integratora - obsługa dużych plików w epuap2
Instrukcja integratora - obsługa dużych plików w epuap2 Wersja: 1.1 Strona 1 z 18 Spis treści SPIS TREŚCI... 2 WPROWADZENIE ORAZ INFORMACJE OGÓLNE... 3 1.1 WSTĘP... 3 1.2 WARUNKI KONIECZNE DO SPEŁNIENIA
Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc
Warszawa, 09 grudnia 2014 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.3 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...
Spis treści. 1 Moduł RFID (APA) 3
Spis treści 1 Moduł RFID (APA) 3 1.1 Konfigurowanie Modułu RFID..................... 3 1.1.1 Lista elementów Modułu RFID................. 3 1.1.2 Konfiguracja Modułu RFID (APA)............... 4 1.1.2.1
Program dla praktyki lekarskiej
Program dla praktyki lekarskiej ErLab Instrukcja konfiguracji i obsługi Spis Treści 1. Wstęp... 2 2. Konfiguracja... 3 2.1. Serwer... 3 2.2. Laboratorium... 3 2.3. Punkt pobrań... 4 3. Wysyłanie skierowania...
DOKUMENTACJA TECHNICZNA SMS API MT
DOKUMENTACJA TECHNICZNA SMS API MT Mobitex Telecom Sp.j., ul. Warszawska 10b, 05-119 Legionowo Strona 1 z 5 Ten dokument zawiera szczegółowe informacje odnośnie sposobu przesyłania requestów do serwerów
EXSO-CORE - specyfikacja
EXSO-CORE - specyfikacja System bazowy dla aplikacji EXSO. Elementy tego systemu występują we wszystkich programach EXSO. Może on ponadto stanowić podstawę do opracowania nowych, dedykowanych systemów.
Zdalne wywoływanie procedur RPC
Zdalne wywoływanie procedur Zagadnienia projektowe Zagadnienia realizacyjne main(int argc, char* argv[]){ int id, status; id = atoi(argv[1]); status = zabij_proc(id); exit(status) }... int zabij_proces
Automatyczne anulowanie zleceń w wyniku odłączenia od CCG
Automatyczne anulowanie zleceń w wyniku odłączenia od CCG Specyfikacja techniczna wersja: 1.0 data:2013.08.06 OPIS DOKUMENTU Cel Dokument zawiera techniczny opis automatycznego anulowania zleceń w wyniku
Zdalne wywoływanie procedur RPC
Zdalne wywoływanie procedur Zagadnienia projektowe Zagadnienia realizacyjne main(int argc, char* argv[]){ int id, status; id = atoi(argv[1]); status = zabij_proc(id); exit(status)... int zabij_proces (int
DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ
DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ PROTOKOŁY TCP I UDP WSTĘP DO SIECI INTERNET Kraków, dn. 12 grudnia 2016 r. PLAN TCP: cechy protokołu schemat nagłówka znane numery portów UDP: cechy protokołu
Laboratorium 6.7.2: Śledzenie pakietów ICMP
Topologia sieci Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Domyślna brama R1-ISP R2-Central Serwer Eagle S0/0/0 10.10.10.6 255.255.255.252 Nie dotyczy Fa0/0 192.168.254.253 255.255.255.0
Zdalne wywoływanie procedur RPC. Dariusz Wawrzyniak 1
Zdalne wywoływanie procedur Zagadnienia projektowe Zagadnienia realizacyjne main(int argc, char* argv[]){ int id, status; id = atoi(argv[1]); status = zabij_proc(id); exit(status)... int zabij_proces (int
TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko
TCP/IP Warstwa aplikacji mgr inż. Krzysztof Szałajko Modele odniesienia 7 Aplikacji 6 Prezentacji 5 Sesji 4 Transportowa 3 Sieciowa 2 Łącza danych 1 Fizyczna Aplikacji Transportowa Internetowa Dostępu
Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science
Systemy internetowe Wykład 5 Architektura WWW Architektura WWW Serwer to program, który: Obsługuje repozytorium dokumentów Udostępnia dokumenty klientom Komunikacja: protokół HTTP Warstwa klienta HTTP
Baza numerów Wersja 1.1
Baza numerów Wersja 1.1 SPIS TREŚCI 1. Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją 1.2 Informacje zwrotne wysyłane z API w odpowiedzi na odebrane odwołania I. Zarządzanie grupami Bazy Numerów
Instrukcja obsługi Konfigurator MLAN-1000
Instrukcja obsługi Konfigurator MLAN-1000 Strona 2 z 8 SPIS TREŚCI 1. Logowanie... 3 2. Diagnostyka... 4 3. Konfiguracja sterownika... 5 3.1 Konfiguracja sterownika aktualizacja oprogramowania... 5 4.
Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV
Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium
Kalipso wywiady środowiskowe
Kalipso wywiady środowiskowe Instrukcja obsługi INFO-R Spółka Jawna - 2017 43-430 Pogórze, ul. Baziowa 29, tel. (33) 479 93 29, (33) 479 93 89 fax: (33) 853 04 06 e-mail: admin@ops.strefa.pl Spis treści:
System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch
System Rozproszone Komunikator Dokumentacja Maciej Muszkowski Jakub Narloch Wymagania Zgodnie ze wstępnymi założeniami komunikator musi, realizowad następujące funkcje: 1. Jest oparty o model Peer2Peer,
Dokumentacja interfejsu MySQL. Platforma BSMS.PL Instrukcja podłączenia po przez mysql
Dokumentacja interfejsu MySQL Platforma BSMS.PL Instrukcja podłączenia po przez mysql Dokumentacja interfejsu mysql (strona 2) SPIS TREŚCI 1. Zawartość dokumentu str.3 2. Informacje ogólne 2.1 Zastosowanie
Sieci komputerowe. Zajęcia 3 c.d. Warstwa transportu, protokoły UDP, ICMP
Sieci komputerowe Zajęcia 3 c.d. Warstwa transportu, protokoły UDP, ICMP Zadania warstwy transportu Zapewnienie niezawodności Dostarczanie danych do odpowiedniej aplikacji w warstwie aplikacji (multipleksacja)
2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego
2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego produktu. 23 czerwca 2014 Spis treści 3 Spis treści...5
Aplikacja Sieciowa wątki po stronie klienta
Aplikacja Sieciowa wątki po stronie klienta Na ostatnich zajęciach zajmowaliśmy się komunikacją pomiędzy klientem a serwerem. Wynikiem naszej pracy był program klienta, który za pomocą serwera mógł się
Pobieranie komunikatów GIF
Spis treści Wstęp... 2 1. Ustawienia harmonogramu zadań... 3 1.1. Tryby pracy AswPlan... 3 2. System KS-EWD... 4 2.1. Instalacja KS-EWD... 5 3. Inauguracja OSOZ... 6 3.1. Zdefiniowanie zadania pobierania
Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T
Skąd dostać adres? Metody uzyskiwania adresów IP Część sieciowa Jeśli nie jesteśmy dołączeni do Internetu wyssany z palca. W przeciwnym przypadku numer sieci dostajemy od NIC organizacji międzynarodowej
Zdalne wywoływanie procedur RPC 27. października Dariusz Wawrzyniak (IIPP) 1
Zagadnienia projektowe Zagadnienia realizacyjne main(int argc, char* argv[]){ int id, status; id = atoi(argv[1]); status = zabij_proc(id); exit(status)... int zabij proces (int pid){ int stat; stat = kill(pid,
Specyfikacja 1.2.1. Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań.
Specyfikacja 1.2.1 Płatności CashBill Instrukcja podłączenia płatności elektronicznych do typowych zastosowań. CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie
Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center
Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Spis treści Konfiguracja Microsoft Outlook 2007... 3 Konfiguracja dla POP3... 7 Konfiguracja dla IMAP... 11 Sprawdzenie poprawności
Serwis jest dostępny w internecie pod adresem www.solidnyserwis.pl. Rysunek 1: Strona startowa solidnego serwisu
Spis treści 1. Zgłoszenia serwisowe wstęp... 2 2. Obsługa konta w solidnym serwisie... 2 Rejestracja w serwisie...3 Logowanie się do serwisu...4 Zmiana danych...5 3. Zakładanie i podgląd zgłoszenia...
Zdalne wywoływanie procedur RPC 27. października 2010
Zagadnienia projektowe Zagadnienia realizacyjne main(int argc, char* argv[]){ int id, status; id = atoi(argv[1]); status = zabij_proc(id); exit(status) }... int zabij_ proces (int pid){ int stat; stat
ArtPlayer oprogramowanie do odtwarzania plików video sterowane Artnet/DMX V1.0.1
Instrukcja obsługi ArtPlayer oprogramowanie do odtwarzania plików video sterowane Artnet/DMX V1.0.1 1 ArtPlayer to proste oprogramowanie umożliwiające odtwarzanie plików video i ich wybór poprzez protokół
Zarządzanie licencjami dla opcji Fiery na komputerze klienta
Zarządzanie licencjami dla opcji Fiery na komputerze klienta Aby udostępnić opcję Fiery zainstalowaną na komputerze klienta, należy aktywować jej licencję. Opcja Fiery wymaga unikalnego kodu aktywacyjnego
Podstawy Informatyki. Inżynieria Ciepła, I rok. Wykład 13 Topologie sieci i urządzenia
Podstawy Informatyki Inżynieria Ciepła, I rok Wykład 13 Topologie sieci i urządzenia Topologie sieci magistrali pierścienia gwiazdy siatki Zalety: małe użycie kabla Magistrala brak dodatkowych urządzeń
Opcje Fiery1.3 pomoc (klient)
2015 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego produktu. 28 stycznia 2015 Spis treści 3 Spis treści...5
Fiery Remote Scan. Uruchamianie programu Fiery Remote Scan. Skrzynki pocztowe
Fiery Remote Scan Program Fiery Remote Scan umożliwia zarządzanie skanowaniem na serwerze Fiery server i drukarce ze zdalnego komputera. Programu Fiery Remote Scan można użyć do wykonania następujących
Veronica. Wizyjny system monitorowania obiektów budowlanych. Instrukcja oprogramowania
Veronica Wizyjny system monitorowania obiektów budowlanych Instrukcja oprogramowania 1 Spis treści 1. Aplikacja do konfiguracji i nadzoru systemu Veronica...3 1.1. Okno główne aplikacji...3 1.2. Edycja
1 Moduł Konwertera. 1.1 Konfigurowanie Modułu Konwertera
1 Moduł Konwertera Moduł Konwertera zapewnia obsługę fizycznego urządzenia Konwertera US- B-RS485. Jest elementem pośredniczącym w transmisji danych i jego obecność jest konieczna, jeżeli w Systemie mają
Odczyty 2.0 Spis treści
Opracowanie i skład: MMSoft s.c Copyright MMSoft s.c. Wszelkie prawa zastrzeżone. All Rights Reserved Powielanie w jakiejkolwiek formie całości lub fragmentów podręcznika bez pisemnej zgody firmy MMSoft
MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP
MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...
SSL (Secure Socket Layer)
SSL --- Secure Socket Layer --- protokół bezpiecznej komunikacji między klientem a serwerem, stworzony przez Netscape. SSL w założeniu jest podkładką pod istniejące protokoły, takie jak HTTP, FTP, SMTP,
S P I S T R E Ś C I. Instrukcja obsługi
S P I S T R E Ś C I Instrukcja obsługi 1. Podstawowe informacje o programie.................................................................................... 2 2. Instalacja programu.....................................................................................................
Wpisz ID i nazwę Projektu. Instalacja AMIplus. Opis modelu komunikacji modułu wireless M-BUS w licznikach AMI. wersja r.
Wpisz ID i nazwę Projektu Instalacja AMIplus Opis modelu komunikacji modułu wireless M-BUS w licznikach AMI wersja 2.1 20.08.2018r. Spis treści 1. Komunikacja wireless M-BUS w licznikach AMI.. str.3 2.
Aukcja trwa od momentu, gdy informacje o przedmiocie są dostępne dla klientów, a kończy się wraz z wysłaniem opisanego dalej komunikatu FINISH_MSG.
Jan Inowolski - ji262511 Protokół komunikacji YouPAY! Wersja 1 Spis treści: * Streszczenie * Cele * Model komunikacji * Założenia * Format komunikatów * Pomocnicze typy danych * Komunikaty specjalne *
Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3
Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...
Przewodnik użytkownika (instrukcja) AutoMagicTest
Przewodnik użytkownika (instrukcja) AutoMagicTest 0.1.21.137 1. Wprowadzenie Aplikacja AutoMagicTest to aplikacja wspierająca testerów w testowaniu i kontrolowaniu jakości stron poprzez ich analizę. Aplikacja
Kielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce
Kielce, dnia 27.02.2012 roku HB Technology Hubert Szczukiewicz ul. Kujawska 26 / 39 25-344 Kielce Tytuł Projektu: Wdrożenie innowacyjnego systemu dystrybucji usług cyfrowych, poszerzenie kanałów sprzedaży
1 Moduł Modbus ASCII/RTU 3
Spis treści 1 Moduł Modbus ASCII/RTU 3 1.1 Konfigurowanie Modułu Modbus ASCII/RTU............. 3 1.1.1 Lista elementów Modułu Modbus ASCII/RTU......... 3 1.1.2 Konfiguracja Modułu Modbus ASCII/RTU...........
1 Moduł Modbus ASCII/RTU
1 Moduł Modbus ASCII/RTU Moduł Modbus ASCII/RTU daje użytkownikowi Systemu Vision możliwość komunikacji z urządzeniami za pomocą protokołu Modbus. Moduł jest konfigurowalny w taki sposób, aby umożliwiał
Sprawozdanie nr 4. Ewa Wojtanowska
Sprawozdanie nr 4 Ewa Wojtanowska Zad.1 Korzystając z zasobów internetu zapoznałam się z dokumentami: RFC 1945 i RFC 2616. Zad.2 Badanie działania protokołu http Zad.3 Zad.4 URL (ang. Uniform Resource
Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online)
Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online) Spis treści Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online)...1
Specyfikacja API Runtime BAS 3.0
Specyfikacja API Runtime BAS 3.0 Spis treści Wstęp... 4 Informacja o dokumencie... 4 Opis usługi... 4 Typowy sposób wywołania usługi... 5 Udostępniane funkcje... 6 Funkcje liczące... 6 Execute... 6 SafeExecute...
5. Model komunikujących się procesów, komunikaty
Jędrzej Ułasiewicz str. 1 5. Model komunikujących się procesów, komunikaty Obecnie stosuje się następujące modele przetwarzania: Model procesów i komunikatów Model procesów komunikujących się poprzez pamięć
Protokół wymiany sentencji, wersja 1
Protokół wymiany sentencji, wersja 1 Sieci komputerowe 2011@ MIM UW Osowski Marcin 28 kwietnia 2011 1 Streszczenie Dokument ten opisuje protokół przesyłania sentencji w modelu klientserwer. W założeniu
Wywoływanie procedur zdalnych
Mechanizm wywołania Wywoływanie procedur zdalnych main(int argc, char* argv[]){ int id, status; id = atoi(argv[1]); status = zabij_proc(id); exit(status) int zabij_proces (int pid){ int stat; stat = kill(pid,
SERWER AKTUALIZACJI UpServ
upserv_pl 02/14 SERWER AKTUALIZACJI UpServ SATEL sp. z o.o. ul. Schuberta 79 80-172 Gdańsk POLSKA tel. 58 320 94 00 serwis 58 320 94 30 dz. techn. 58 320 94 20; 604 166 075 info@satel.pl www.satel.pl SATEL
Sieci komputerowe. Wykład 5: Warstwa transportowa: TCP i UDP. Marcin Bieńkowski. Instytut Informatyki Uniwersytet Wrocławski
Sieci komputerowe Wykład 5: Warstwa transportowa: TCP i UDP Marcin Bieńkowski Instytut Informatyki Uniwersytet Wrocławski Sieci komputerowe (II UWr) Wykład 5 1 / 22 Warstwa transportowa Cechy charakterystyczne:
Skąd dostać adres? Metody uzyskiwania adresów IP. Statycznie RARP. Część sieciowa. Część hosta
Sieci komputerowe 1 Sieci komputerowe 2 Skąd dostać adres? Metody uzyskiwania adresów IP Część sieciowa Jeśli nie jesteśmy dołączeni do Internetu wyssany z palca. W przeciwnym przypadku numer sieci dostajemy
Brinet sp. z o.o. wyłączny przedstawiciel DrayTek w Polsce
1. Firmware Upgrade Utility 1.1. Metoda 1 (standardowa) 1.2. Metoda 2 (niestandardowa) 2. Upgrade przez Web 3. Serwer FTP 3.1. Lokalny serwer FTP 3.2. Zdalny serwer FTP Procedury aktualizacji zostały oparte
Materiały do laboratorium MS ACCESS BASIC
Materiały do laboratorium MS ACCESS BASIC Opracowała: Katarzyna Harężlak Access Basic jest językiem programowania wykorzystywanym w celu powiązania obiektów aplikacji w jeden spójny system. PROCEDURY I