Kurze Beschreibung
der Anwendungsdienste
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| <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.
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:
oder
Kapstadtring 2
D-22297 Hamburg
Tel./Fax: (030) 6441-587 / 6441-586
(Berlin)
Tel./Fax: (040) 639004-31 / 6300736 (Hamburg)
Supported by
BestWeb GmbH Automation and ADM
Last update: 03.01.1999