1、November 2016DEUTSCHE NORM DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDEPreisgruppe 28DIN Deutsches Institut fr Normung e. V. Jede Art der Vervielfltigung, auch auszugsweise, nur mit Genehmigung des DIN Deutsches Institut fr Normung e. V., Berlin, gestattet.ICS
2、 35.240.95; 91.140.50!%NW“2435852www.din.deDDIN 43863-4Zhlerdatenkommunikation IPTelemetrieMeter data communication IPTelemetryCommunication des donnes de compteurs Tlmtrie IPAlleinverkauf der Normen durch Beuth Verlag GmbH, 10772 Berlin www.beuth.deGesamtumfang 72 SeitenDIN 43863-4:2016-11 2 Inhalt
3、 SeiteVorwort. 4 Einleitung . 4 1 Anwendungsbereich 4 2 Normative Verweisungen 5 3 Begriffe 5 4 Einteilung und Komponenten 8 5 Steuerungsprotokoll (IP-T-C) 8 5.1 Aufgaben . 8 5.2 Spezielle Nachrichten des Steuerungsprotokolls8 6 Transportprotokoll (IP-T-T) 8 6.1 Aufgaben . 8 6.2 Anforderungen an den
4、 Transportkanal 9 6.3 Zustandsautomat. 9 6.4 Verschlsselung/Verschleierung . 11 6.5 Spezielle Nachrichten des Transportprotokolls.12 7 Applikation (IP-T-A) . 12 7.1 Aufgaben . 12 7.2 Spezielle Nachrichten der Applikation. 12 8 Kodierung 12 9 Kommandos 14 9.1 Aufgaben . 14 9.2 Struktur 14 9.3 Kommand
5、ogruppe genereller Kommandos. 18 9.4 Kommandogruppe zu IP-T-C 18 9.5 Kommandogruppe zu IP-T-T. 26 9.6 Kommandogruppe zu IP-T-A. 40 10 Watchdog 47 10.1 Aufgaben . 47 10.2 Struktur 47 Anhang A (normativ) Kommandobersicht. 48 Anhang B (informativ) Allgemeine Hinweise zu Push 52 Anhang C (normativ) Proz
6、essbeschreibungen. 53 Anhang D (informativ) Allgemeine Erluterungen 71 Bilder Bild 1 Einsatzumfeld zu IP-Telemetrie 5 Bild 2 IP-T-Zustandsautomat 9 Bild 3 Grundmechanismus zur Verschleierung 11 Bild C.1 Liste der Kommandos mit zugehrigen Kommandoeigenschaften 53 DIN 43863-4:2016-11 3 SeiteBild C.2 Z
7、ustandsautomat, Slave-to-Slave-Kommunikation, Whlverbindung, bersicht54 Bild C.3 Zustandsautomat, Slave-to-Slave-Kommunikation, Standleitungsaufbau, bersicht.57 Bild C.4 Zustandsautomat, Slave-to-Slave-Kommunikation, Standleitungsabbau, Variante IptLogoutResponse“, bersicht 58 Bild C.5 Zustandsautom
8、at, Slave-to-Slave-Kommunikation, Standleitungsabbau, Variante IptConnectionCloseRequest“ von Slave an Master, bersicht.59 Bild C.6 Zustandsautomat, Slave-to-Slave-Kommunikation, Standleitungsabbau, Variante IptConnectionCloseRequest“ von Master an Slave, bersicht.60 Bild C.7 Zustandsautomat, Push-B
9、etrieb, Variante Point-to-Point“ .64 Bild C.8 Beispiel, Push-Betrieb, Varianten Point-to-Multipoint“ .66 Bild C.9 Ablauf der Datenbertragung im Stream-Mode“ 68 Bild C.10 Wechsel in die Betriebsart Server-Mode“.69 Tabellen Tabelle 1 Wertebereich zum Response“ der Login-Response 19 Tabelle 2 Wertebere
10、ich zum Element response“ der Logout-Response.23 Tabelle 3 Wertebereich zum Element response“ der Maintenance-Response .24 Tabelle 4 Wertebereich zum Element response“ der Push-Channel-Open-Response .27 Tabelle 5 Wertebereich zum Element response“ der Push-Channel-Close-Response.28 Tabelle 6 Wertebe
11、reich zum Element response“ der Push-Data-Transfer-Response 30 Tabelle 7 Wertebereich zum Element response“ der Connection-Open-Response38 Tabelle 8 Wertebereich zum Element response“ der Connection-Close-Response .39 Tabelle 9 Wertebereich zum Element response“ der Data-Transfer-Response40 Tabelle
12、10 Wertebereich zum Element deviceType“ .41 Tabelle 11 Wertebereich zum Element response“ der IP-Statistic-Response.43 Tabelle 12 Beispiele zur Filterfunktion bei pushTargetNameListFilter“ .45 Tabelle A.1 Liste der Kommandos mit zugehrigen Kommandoeigenschaften .48 Tabelle C.1 Zustandsautomat, Slave
13、-to-Slave-Kommunikation, Whlverbindung, Slave 55 Tabelle C.2 Zustandsautomat, Slave-to-Slave-Kommunikation, Whlverbindung, Master 55 Tabelle C.3 Zustandsautomat, Slave-to-Slave-Kommunikation, Standleitungsaufbau 61 Tabelle C.4 Zustandsautomat, Slave-to-Slave-Kommunikation, Standleitung, Master 61 DI
14、N 43863-4:2016-11 4 Vorwort Vorausgegangener Norm-Entwurf: E DIN 43863-4:2006-09. Fr dieses Dokument ist das nationale Arbeitsgremium K 461 Elektrizittszhler“ der DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDE (www.dke.de) zustndig. Die Verffentlichung dieser na
15、tionalen Norm wurde mglich, nachdem die Notifikation BT/DE0260/NOT“ abgeschlossen werden konnte und es Deutschland freigestellt wurde, eine rein nationale Norm zu erstellen. Es wird auf die Mglichkeit hingewiesen, dass einige Elemente dieses Dokuments Patentrechte berhren knnen. Das DIN ist nicht da
16、fr verantwortlich, einige oder alle diesbezglichen Patentrechte zu identifizieren. Einleitung Die zunehmende Bedeutung und die gute Verfgbarkeit der neuen, auf dem Internet-Protokoll (IP) basierenden Kommunikationsnetze (Internet, Intranet usw.) wecken den Bedarf, diese auch fr die Belange der klass
17、ischen Zhlerdatenkommunikation zu nutzen. Eine wesentliche Anforderung besteht darin, von konkreten Anwendungsprotokollen unabhngig zu sein und damit die Verwendung etablierter sowie knftiger Protokolle und Dienste gleichermaen zu erlauben. Hierzu wird ein standardisierter und allgemeingltiger Mecha
18、nismus bentigt, der dies gewhrleistet. Um diesen allgemeinen Ansatz zu unterstreichen, verwendet die vorliegende Spezifikation den Titel IP-Telemetrie“ und verzichtet bewusst auf die Bindung an bestimmte Kommunikationsprotokolle und Applika-tionen. 1 Anwendungsbereich Die Spezifikation zur IP-Teleme
19、trie hat ihren Ursprung in Produkten zur Zhlwertbeschaffung fr die Messung elektrischer Energieverbruche; sie lsst sich auch als generische Lsung fr viele vergleichbare Anwendungsflle in der Automatisierungstechnik einsetzen und ist damit allgemein im Bereich der Maschine-zu-Maschine-(M2M)-Schnittst
20、ellen nutzbar. Die Spezifikation zur IP-Telemetrie beschreibt das Protokoll zur Lsung dieser Aufgabe unter Verwendung mglichst abstrakter Begriffe, so dass einerseits Hersteller ihre Produkte zur Erfllung dieser Spezifikation mglichst frei gestalten knnen und andererseits deren Einordnung in das umg
21、ebende Normenwerk erleichtert wird. Fr den konkreten Transport von Nachrichten setzt die Spezifikation IP-Telemetrie gesicherte und mit Mechanismen zur Fehlererkennung ausgestattete, verbindungsorientierte Transportkanle voraus. Als Beispiel fr einen derart vorliegenden Anwendungsfall kann das Trans
22、mission Control Protocol (TCP) angesehen werden. Ergnzend sei explizit festgestellt, dass IP-Telemetrie auch jede andere im Grundverhalten mit gleicher Qualitt ausgestattete Verbindung als Transportmedium nutzen kann. Der Einsatz von IP-Telemetrie ber ungesicherte und/oder verbindungslose Kommunikat
23、ionsstrecken ist nicht vorgesehen. Damit kann das Einsatzumfeld von IP-Telemetrie wie in Bild 1 dargestellt skizziert werden. DIN 43863-4:2016-11 5 Bild 1 Einsatzumfeld zu IP-Telemetrie 2 Normative Verweisungen Die folgenden Dokumente, die in diesem Dokument teilweise oder als Ganzes zitiert werden,
24、 sind fr die Anwendung dieses Dokuments erforderlich. Bei datierten Verweisungen gilt nur die in Bezug genommene Ausgabe. Bei undatierten Verweisungen gilt die letzte Ausgabe des in Bezug genommenen Dokuments (einschlielich aller nderungen). ISO/IEC 8859-15:1999, Informationstechnik 8-Bit-Einzelbyte
25、-codierte Schriftzeichenstze Teil 15: Lateinisches Alphabet Nr. 9 RFC 2396:1998, Uniform Resource Identifiers (URI): Generic Syntax 3 Begriffe Fr die Anwendung dieses Dokuments gelten die folgenden Begriffe. 3.1 Applikation Unter Applikation werden sowohl Anwendungsflle subsumiert, die die Spezifika
26、tion IP-Telemetrie zum Transport serieller Datenstrme unter Einsatz bekannter Protokoll nutzen, als auch Einsatzgebiete erfasst, die die speziellen Mechanismen der Spezifikation IP-Telemetrie zum direkten, an Datenblcken orientierten, Versand verwenden 3.2 Device Der Begriff Device wird in diesem Do
27、kument aus funktionaler Sicht betrachtet. Je nach konkreter Aktion kann der Begriff damit sowohl den Slave wie auch den Master benennen 3.3 Direkter Kommunikationspartner Als direkter Kommunikationspartner soll der jeweilige Gegenber des Master oder Slave benannt werden. Zwei direkte Kommunikationsp
28、artner bilden damit eine Punkt-zu-Punkt-Verbindung. Sie sind jeweils die beiden Endstellen dieser Verbindung. DIN 43863-4:2016-11 6 3.4 Internet Als Internet sei das Internet“ im Sinne des auf dem Internet Protokoll basierenden, weltweiten Rechner-verbunds bezeichnet. Soweit nicht anders ausgefhrt,
29、betreffen Bezge auf das Internet immer auch lokale Rechnerverbnde, die gleichermaen das Internet Protokoll anwenden und im allgemeinen Sinne daher als ein Internet“ bezeichnet werden mssen. 3.5 Link-Betrieb Link-Betrieb“ bezeichnet eine Betriebsart, bei der zwischen den beiden direkten Kommunikation
30、spartner eine bidirektionale Verbindung erstellt wird, ber die beide direkte Kommunikationspartner, quasi wie ber eine Standleitung, im Fullduplex-Modus Bytes senden knnen. Der Link-Betrieb wird mit dem Anmeldeprozess durch den Slave am Master eingerichtet und hat fr die Dauer dieser Beziehung besta
31、nd. Der Link-Betrieb ist erreicht, wenn Anmeldung und Authentisierung erfolgt sind. Konkret bedeutet das, dass der Link-Betrieb beim Master erst nach Absenden des Login-Response und beim Slave nach Eintreffen des Login-Response angenommen werden darf. 3.6 M2M Mit Machine to Machine“, kurz M2M, solle
32、n technische Kommunikationsprozesse zwischen Maschinen bezeichnet werden, die automatisiert ber beliebige Kommunikationsnetze ablaufen knnen 3.7 Master Zum Einsatz dieser Spezifikation wird eine als zentrale Anlaufstelle fungierende Komponente bentigt, die mit Master bezeichnet werden soll. Der (ode
33、r die) Slaves stellen mit der Aufnahme ihres Betriebszustands eine Verbindung ber das Transport-protokoll zum Master her. Der dazu bentigte Verbindungsaufbau verwendet das Steuerungsprotokoll. 3.8 Transportkanal Diese Spezifikation ordnet dem Begriff Transportkanal eine bidirektionale, gesicherte un
34、d mit Funktionen zur Fehlererkennung ausgestattete verbindungsorientierte Kommunikationsstrecke1)zu. Der Transportkanal2)bietet aus Sicht der IP-Telemetrie keinerlei Strukturen fr die von IP-Telemetrie durch ihn zu bertragenden Daten an. Er bietet quasi die Funktion eines Rohrs“ (Pipe“) an, durch da
35、s von den jeweiligen direkten Kommunikationspartnern einzelne Bytes bertragen werden. Zur Erkennung von Strungen durch abgerissene“ Transportkanle werden mit IP-Telemetrie entsprechende Timeouts und damit Rahmenanforderungen an die fr IP-Telemetrie nutzbaren Transportkanle definiert. 3.9 Transportpr
36、otokoll Der Begriff Transportprotokoll wird fr den Teil der Spezifikation verwendet, der die Schnittstelle zwischen der Anwendungsseite (der Applikation“) und dem jeweils darunter verwendeten Kommunikationsnetz beschreibt. 1)Applikationshinweis: Fr den Einsatz dieser Norm in Verbindung mit Transport
37、kanlen ber ffentliche Netze (beispielsweise das Internet), wird zum Schutz vor Manipulation und Gewhrleistung der Privatsphre empfohlen, gesicherte Transportkanle (VPN-Tunnel oder vergleichbar) zu verwenden. 2)Applikationshinweis: Bei Einsatz von paketorientierten Transportkanlen sollte die Implemen
38、tation im Rahmen der jeweils konkret definierten Latenzzeit Pakete optimaler Gre bilden. DIN 43863-4:2016-11 7 Das Transportprotokoll spezifiziert den Mechanismus zum transparenten, seriellen Datentransport ber das jeweils darunter verwendete Kommunikationsnetz. 3.10 Push-Betrieb Push-Betrieb“ bezei
39、chnet eine Betriebsart, bei der einer der beiden direkten Kommunikationspartner einen singulren Datenblock an sein Gegenber sendet. Es handelt sich dabei um eine unidirektionale Aktion. Der Push-Betrieb ist damit ber die zum Zeitpunkt der Versendung bekannte Gre des Datenblocks durch eindeutige Star
40、t wie Ende-Bedingungen gekennzeichnet. 3.11 Response Als Responses werden die Antworten eines Slave oder Masters auf an diesen gerichtete Auftrge (Requests) bezeichnet. Enthalten diese Antworten eine Fehlermeldung, so sind zustzliche Elemente in der Response zu ignorieren, soweit sie nicht explizit
41、Teil der Fehlermeldung sind. 3.12 Server-Mode Ein Slave kann optional in die Betriebsart Server-Mode“ wechseln. Wechselt er in diese Betriebsart, so teilt er seinem Master die Adress-Informationen mit, unter denen er jederzeit vom Master ausgehend aus zu erreichen ist. Bei Einsatz von IP-Telemetrie
42、in einer TCP/IP-Umgebung, sind die Adress-Informationen mit der IP-Adresse und dem TCP-Port, unter der der Slave wieder erreichbar ist, gegeben. 3.13 Slave Die Endgerte, die mittels IP-Telemetrie eine Verbindung zu einer Applikation bentigen, werden als Slave bezeichnet. Sie stellen mit Aufnahme ihr
43、er Betriebsbereitschaft zunchst eine Verbindung zum Master her, wobei es danach die Aufgabe des Master ist, die seitens der Endgerte angebotene Verbindung zu einer konkreten Applikation weiterzureichen. 3.14 Steuerungsprotokoll Der Begriff Steuerungsprotokoll wird fr den Teil der Spezifikation verwe
44、ndet, der die Mechanismen zum Auf- und Abbau von Transportkanlen sowie die Prozesse zu Anmeldung und zum Umgang mit Strungen beschreibt 3.15 Stream-Mode Mit dem Begriff Stream-Mode wird ein Mechanismus vergleichbar reverse Push“ bezeichnet. Der mit Stream-Mode bezeichnete Anwendungsfall kann wie fol
45、gt beschrieben werden: Ein Slave, der Informationen anbieten will, registriert sich bei einem Master und stellt unter der Registrierung diese Informationen bereit. Andere Slaves, die diese Informationen haben wollen, greifen ber den Master auf die Steam-Source zu. Als primre Applikation fr den Strea
46、m-Mode ist der Firmware- oder Parameter-Download anzusehen. 3.16 Zugriffsschutz Es wird empfohlen, die Implementation eines IP-T-Masters mit einer Rechteverwaltung auszustatten, die den Zugriff auf einzelne IP-T-Kommandos von dem zugreifenden IP-T-Slave abhngig macht. Werden IP-T-Kommandos als Wirku
47、ng des Zugriffsschutzes abgelehnt, ist mit Unknown-Command-Response“ zu antworten DIN 43863-4:2016-11 8 4 Einteilung und Komponenten Die Spezifikation IP-Telemetrie ist in die Bereiche Applikation, Steuerungsprotokoll und Transportprotokoll einzuteilen. Die Kodierung der definierten Nachrichtenstruk
48、tur erfolgt nach Abschnitt 8. Zum Einsatz der Spezifikation IP-Telemetrie werden mindestens ein Master und ein Slave bentigt. Hierbei wird bewusst auf die Verwendung der Begriffe Client und Server verzichtet, da Client und Server stets aus dem Blickwinkel der Applikation definiert werden mssen, das
49、Werkzeug IP-Telemetrie hingegen diese Blickrichtung offen lassen sollte/muss. Letztlich knnen sowohl der Master als auch der Slave aus der Perspektive der Applikation gesehen die Funktionen Client oder Server wahrnehmen. 5 Steuerungsprotokoll (IP-T-C) 5.1 Aufgaben Das Steuerungsprotokoll legt die zum Betrieb des Werkzeugs IP-Telemetrie bentigten Prozesse und
