Kurze Beschreibung der Anwendungsdienste
nach DIN 66348-3

Die in DIN 66 348 Teil 2 festgelegten OSI-Schichten 1 und 2 zum DIN-Meßbus legten bisher fest, wie Daten von der Leitstation gelesen oder geschrieben werden, auf welche Weise der Buszugriff erfolgt und wie die Sicherheit der Datenübertragung gewährleistet wird.

Der Inhalt eines Telegramms ist dort nur durch seine Start- und Abschlußzeichen festgelegt:

<STX> Inhalt: 0 - 128 Byte <ETB/ETX> <BCC>

In Teil 3 der Normenreihe DIN 66348 werden nun die "Dienste" beschrieben, die zur Kommunikation zwischen zwei Geräten auf der Anwendungsebene erforderlich sind.

Als kurze Übersicht soll nun beschrieben werden, welche Dienste diese Norm zur Verfügung stellt, wie die Kommunikation zwischen zwei Anwendungsprozessen abläuft und wie die entsprechenden Telegramme aufgebaut sind.

Basis für die Anwendungsdienste zum DIN-Meßbus ist die seit 1990 international genormte "Manufacturing Message Specification" MMS (ISO 9506-1/-2). Der erhebliche Umfang der MMS-Norm wurde für DIN 66348-3 stark reduziert, die Beschreibung der Dienstparameter und Telegramme wurde zusammengefaßt, eine Dienstprozedur-Beschreibung erläutert die funktionellen Zusammenhänge. Es werden nur ASCII-Zeichen übertragen, so daß Wartung und Fehlersuche mit einem einfachen Zeichenmonitor wenig aufwendig sind.

MMS sieht eine sogenannte Client-Server-Kommunikation vor, d.h. unabhängig von der tatsächlichen Art des Datentransports besteht eine Kommunikationsbeziehung zwischen zwei Busteilnehmern, von denen der eine (der Auftraggeber) einen Dienst (z.B. VariableLesen) anfordert, den der andere Teilnehmer in dieser Beziehung (als Auftragnehmer) ausführt. Bild 1 zeigt diese Grundstruktur.

Bild zur Grundstruktur

Für die einzelnen Anwendungsdienste werden also jeweils ein Anforderungstelegramm, ein Antworttelegramm und ein Fehlertelegramm beschrieben. Neben diesen "bestätigten" Diensten gibt es einige "unbestätigte" Dienste, z. B. für Statusmeldungen oder Grenzwertüberschreitungen (siehe Tabelle 1).

<DC4> VN1 VN2 <DC2> Anwendungstelegramm <FS>

Voraussetzung für den Austausch von Anwendungstelegrammen ist der Aufbau einer Kommunikationsbeziehung durch die Verbindungsverwaltung (Dienste: Verbindungsaufbau, Verbindungsabbau, Verbindungsabbruch). Durch die Vergabe einer zweistelligen Verbindungsnummer (VN1, VN2), die genau zwei systemweit eindeutige Anwendungsprozesse miteinander logisch verbindet, sind alle folgenden Telegramme eindeutig zwei Teilnehmern in einem beliebigen Netz (Bus, Baum) zugeordnet; lediglich dem Bus-Management (z.B. beim DIN-Meßbus die Leitstation oder Unterleitstationen) müssen die Hardwareadressen der beteiligten Geräte bekannt sein. Neue Teilnehmer können die Verbindungsnummer für eine gewünschte Beziehung von der übergeordneten Management-Station erfragen (Dienst: STS-Verbindungsnummer). Der Inhalt eines Telegramms nach DIN 66348-3 sieht daher mit den darin vorgesehenen Start- und Abschlußzeichen wie folgt aus:

Jedes Anwendungstelegramm ist durch ein Telegrammkennzeichen (TK) und - je nach Art des Telegramms - durch mehrere Parameter festgelegt, die in der Norm jeweils in einer Tabelle beschrieben werden.

Insgesamt wurden 29 Dienste ausgewählt, die für meß- und prüftechnische Anwendungen besonders wichtig und geeignet sind. Tabelle 2 zeigt diese Dienste:

   
Anwendungstelegramm - Grundtyp TK
Anforderung

Auftragsbearbeitung Antwort

Fehlertelegramm

<0>

<1>

<2>

Ereignis Meldung <3>
Ablauffehler Meldung <4>
Anforderung

Dienstausführungsabbruch Antwort

Fehlertelegramm

<5>

<6>

<7>

Anforderung

Verbindungsaufbau Antwort

Fehlertelegramm

<8>

<9>

<A>

Anforderung

Verbindungsabbau Antwort

Fehlertelegramm

<B>

<C>

<D>

Verbindungsabbruch Meldung <E>
   

Tabelle 1: Anwendungstelegramm-Grundtypen
(TK = Telegrammkennzeichen)

Anwendungsdienst/Auftrag DK1 DK2
Status

ÜbermittleNamenliste

Identifikation

<0>

<0>

<0>

<0>

<1>

<2>

VariableLesen

VariableSchreiben

DefiniereVariablenliste

LöscheVariablenliste

<0>

<0>

<0>

<0>

<4>

<5>

<B>

<D>

BeginneLadesequenz

LadeSpeichersegment

BeendeLadesequenz

BeginneRückladesequenz

RückladeSpeichersegment

BeendeRückladesequenz

LöscheSpeicherbereich

<1>

<1>

<1>

<1>

<1>

<1>

<2>

<A>

<B>

<C>

<D>

<E>

<F>

<4>

ProgrammAktivieren

ProgrammDeaktivieren

ProgrammStarten

ProgrammStoppen

ProgrammFortsetzen

ProgrammRücksetzen

ProgrammAbbrechen

<2>

<2>

<2>

<2>

<2>

<2>

<2>

<6>

<7>

<8>

<9>

<A>

<B>

<C>

AktionAuslösen <3> <4>
     

Tabelle 2: Auftragsdienste
(DK1 und DK2: Dienstkennungszeichen)

Die Telegramm-Grundtypen dienen der Verbindungsverwaltung (3 Dienste), der Meldung von Ablauffehlern und Ereignissen (2 Dienste) und der Auftragsbearbeitung (1 Dienst). Ihre Kennzeichnung wird im Telegramm nur durch ein ASCII-Zeichen "TK" sichtbar.

Zu unterscheiden ist, ob einzelne Dienste als Auftraggeber und/oder als Auftragnehmer implementiert werden sollen, da dies die spätere Einsatzfähigkeit eines Gerätes beeinflußt.

Als Pflichtdienste sind lediglich die Dienste

- Verbindungsaufbau (als Auftragnehmer),

- Verbindungsabbruch (als Meldender und Empfänger),

- Ablauffehler (als Meldender und Empfänger),

- Identifikation (im Rahmen der Auftragsbearbeitung als Auftragnehmer)

vorgeschrieben.

Die ausgewählten Anwendungsdienste sind in Tabelle 2 mit den zugehörigen Kennzeichen DK1 und DK2 angegeben. Als Telegramm-Grundtyp steht diesen Anwendungsdiensten stets die TK der Auftragsbearbeitung voran, d.h. jeder Anwendungsdienst kennt ein Anforderungs-, Antwort- und Fehlertelegramm.

Die Anwendungsdienste lassen sich in die fünf Gruppen der allgemeinen Dienste, der Variablen-Dienste, der speicherbereichsbezogenen Dienste, der Dienste zur Programmablaufsteuerung und der Ereignisdienste gliedern.


Ein einfaches Meßgerät wird z. B. neben dem Pflichtdienst der Identifikation nur den Dienst VariableLesen benötigen, ein Gerät mit ladbaren Meßprogrammen wird auch die speicherbereichsbezogenen Dienste benötigen, und eine Gerät mit steuerbaren Abläufen wird zusätzlich Dienste aus der Gruppe der Programmablaufsteuerung enthalten. Es bleibt dem Anwender überlassen, in welchem Umfang er die vorgesehenen Dienste implementiert, und ob er sie jeweils in der Rolle als Auftraggeber, als Auftragnehmer oder in beiden unterstützen will. Auch die Anzahl der gleichzeitig bearbeitbaren Dienste kann zwischen 1 und 63 realisiert werden; beim Verbindungsaufbau wird diese Zahl zwischen den Kommunikationspartnern ausgetauscht.

Im Folgenden soll anhand von Beispielen der tatsächliche Aufbau einiger Telegramme dargestellt werden, wodurch deutlich wird, daß die zunächst eher aufwendig erscheinende Dienstprimitiv- und Dienstparameterbeschreibung zu relativ einfachen und vor allem kurzen Telegrammen führt. Gleichzeitig ist diese Struktur so leistungsfähig, daß auch lange Variablenlisten oder umfangreiche Dateien problemlos übertragen werden können.

Es soll zunächst eine Verbindung zwischen den Anwendungsprozessen mit den systemweit geltenden Namen "P1" und "P2" aufgebaut werden. Dabei möge "P1" der Auftraggeber sein. Als Verbindungsnummer ist im Auftraggeber die Nr. "1" (codiert als @A) gegeben, die Anzahl der offenen Dienste (codiert als ASCII-Zeichen des Dezimalwerts + 64) möge mit "4" bzw. "3" angefordert und mit "2" bzw. "1" beantwortet werden. Als "Version" ist die Angabe "66348.3/V100" im Auftragnehmer gespeichert. Damit lautet das Anforderungstelegramm zum Verbindungsaufbau:

DC4 @A DC2 8 P2 US P1 US D C FS

wobei die Zeichen DC4, DC2, US und FS auf einem PC-Bildschirm als ein Zeichen entsprechend dem IBM-Zeichensatz dargestellt werden (z. B. DC4 = ¶).

Das Antworttelegramm lautet dann bei Annahme der Verbindungsanforderung:

DC4 @A DC2 9 B A 66348.3/V100 FS

Ein Verbindungsaufbau ist nur einmal, z.B. beim Einschalten der Anlage oder beim Anschluß eines neuen Gerätes durchzuführen und gilt bis zum Verbindungsabbau oder -abbruch, der von beiden Partnern ausgelöst werden kann.

Als nächstes soll "P1" als Auftraggeber von Gerät "P2" eine Identifikation anfordern, die fortlaufende Auftragsnummer, die jedem Auftragsdienst vorangestellt wird, sei "1" (codiert als "A"):

DC4 @A DC2 0 A 0 2 FS

Der Auftragnehmer antwortet mit Herstellernamen ("Laengenmess GmbH"), Modellnamen ("Messtaster 4711") und einer Versionsangabe ("SW-Rev. 08-15") unter derselben Auftragsnummer:

DC4 @A DC2 1 A 0 2 Laengenmess GmbH US  
Messtaster 4711 US SW-Rev. 08-15 FS

Unter der Annahme, die Variablennamen von "P2" seien "P1" bekannt (oder "P1" hat mit dem Dienst ÜbermittleNamenliste die Namen aller Variablen von "P2" erfragt), fordert "P1" jetzt (mit der Auftragsnummer "2", codiert "B") seinen Partner auf, den Inhalt der Variable "Var_1" zu übertragen. Das Anforderungstelegramm für diesen Dienst zum Lesen von Variablen (für eine oder mehrere Variable oder Variablenlisten, deren Namen und Zusammenstellung vereinbart und gelöscht werden können) lautet (mit einigen Datentyp- und Zugriffsparametern, die in der Norm näher erläutert sind):

DC4 @A DC2 0 B 0 4 0 0 Var_1 FS

Diese Variable habe im Gerät "P2" den Wert "23.64 mm" und sei vom Datentyp "Textzeichenfolge" (visible string, codiert durch den Datentypcode "A"). Dann lautet die Antwort:

DC4 @A DC2 1 B 0 4 A 23.64 mm FS

Es besteht auch die Möglichkeit, Ereignisse wie das Überschreiten eines Grenzwertes durch ein Meldungstelegramm mit Hilfe des Dienstes UnangeforderterBericht unaufgefordert von Gerät "P2" an das Gerät "P1" zu übertragen. Dies kann als Boolsche Zahl für einen Meßkanalzustand, als Meßwert, als Textausgabe zur Anzeige auf einem Display oder in jeder anderen zugelassenen Datenform für eine oder mehrere Variable geschehen; durch das vorherige Schreiben einer vorgesehenen Einstellvariablen kann dieser Meldungsdienst frei "programmiert" werden für Ereignisse, Bedingungen oder regelmäßige Meldungen. Das Meldungstelegramm lautet für den Fall eines Temperatur-Meßwertes "81.2 grd "in "Var_2", die in einem Speicherbereich mit dem Namen "Speicher1" abgelegt ist:

Als Beispiel für ein Fehlertelegramm sei angenommen, daß in Gerät "P2" festgelegt sei, daß der Kommunikationspartner "P1" kein Leserecht auf die Variable "Var_1" hat. Dann sendet "P2" statt der Antwort mit dem Leseergebnis das Fehlertelegramm:

DC4 @A DC2 3 0 0 1 Speicher1 US Var_2 RS A 81.2 grd FS
DC4 @A DC2 2 B 7 3 FS

Die Auswertung der Fehlerangaben bedeutet: Fehlerklasse 7 zeigt ein Zugriffsproblem an, Fehlercode 3 bedeutet, daß der Zugriff auf ein Objekt wegen nicht gegebener Zugriffsrechte verweigert wurde.

Vor dem Abschalten eines Kommunikationspartners sollte die Verbindung geordnet abgebaut werden, damit nicht unerledigte oder nur teilweise ausgeführte Dienste in einem Partner bestehen bleiben. Dies geschieht mit der Anforderung zum Verbindungsabbau unter der vereinbarten Verbindungsnummer:

DC4 @A DC2 B FS

Die Antwort lautet:

DC4 @A DC2 C FS

Die Kommunikationsverbindung zwischen "P1" und "P2" ist nach dem Verbindungsaufbau grundsätzlich gleichberechtigt, d. h. auch "P2" kann bei "P1" Variable lesen oder schreiben oder andere Dienste anfordern, wenn diese Fähigkeit (für Dienste als Auftragnehmer und Auftraggeber) in "P2" implementiert und vom Anwendungsprozeß benötigt wird. Ebenso kann vorgesehen sein, daß ein Anwendungsprozeß mit mehreren anderen Prozessen Verbindungen unterhält. Sie werden jeweils getrennt verwaltet und bearbeitet.

EPSI - Kommunikationsschnittstelle für Tankstellen

Für den Anwendungsbereich Tankstellen wurde auf der Basis von DIN 66348 Teil 2 und DIN 66348 Teil 3 bereits ein vollständiges Anwendungsprofil in Zusammenarbeit mit der PTB, der DGMK (Deutsche Wissenschaftliche Gesellschaft für Erdöl, Erdgas und Kohle e.V.) und dem Mineralölwirtschaftsverband erarbeitet. Für unterschiedliche Gerätegruppen wie Zapfsäulen, Tankautomaten, Füllstandsmessung, Preistransparente, Tankwagenelektronik, Kartenverarbeitungseinrichtungen und Waschanlagen wurden alle erforderlichen Befehle und Variablen festgelegt, die herstellerunabhängig eine einheitliche Kommunikation bis zur Anwendungsoberfläche ermöglichen. Nach mehrjähriger Erprobung und der Entwicklung entsprechender EPSI-Anschaltungen durch eine wachsende Zahl von Firmen werden 1996 die ersten Tankstellen serienmäßg mit EPSI (European Petrol Station Interface) ausgerüstet.

Die EPSI-Festlegungen wurden als DGMK-Forschungsberichte 463-1 bis 463-3 herausgegeben und können dort angefragt werden.

Weitere Informationen zu EPSI:

Physikalisch Technische Bundesanstalt DGMK
Gruppe 10.4, Dr.-Ing. H. Schumny, Dr. Altmann

Fürstenwalder Damm 388
D-12587 Berlin
eMail:
Schumny@Berlin.PTB.de

oder
Kapstadtring 2
D-22297 Hamburg

Tel./Fax: (030) 6441-587 / 6441-586 (Berlin)
Tel./Fax: (040) 639004-31 / 6300736 (Hamburg)

 


INFIDA Home Page


Supported by BestWeb GmbH Automation and ADM
Last update: 03.01.1999