DE19955306C1 - Kommunikationsteilnehmer bzw. Kommunikationsverfahren - Google Patents

Abstract

Als Schnittstelle zwischen einem Netzwerk (N) und einem Feldbus (BU) geeigneter Kommunikationsteilnehmer (P), der zur Repräsentation über den Feldbus anschließbarer Geräte (A, B) Software-Objekte (A', B') aufweist, die über das Netzwerk (N) wie die Geräte (A, B) selbst ansprechbar sind, so daß eine transparente Einbindung von Geräten mit ausschließlich Feldbusanschluß auch in "leistungsfähige" Netzwerke gelingt.

Description

Die vorliegende Erfindung betrifft einen Kommunikations­ teilnehmer gemäß den im Anspruch 1 angegebenen Maßnahmen. Darüber hinaus betrifft die Erfindung ein Kommunikations­ verfahren gemäß den im Anspruch 6 angegebenen Maßnahmen.

Aus der DE 196 15 190 A1 ist eine netzwerkbasierende Steue­ rung bekannt, die als Schnittstelle zwischen einem Netzwerk und einem Feldbus geeignet ist.

Aus der DE 196 45 861 A1 ist ein plattformunabhängiges Kommu­ nikationsverfahren für ein heterogenes Netzwerk bekannt. Ein Kommunikationsteilnehmer ist mit Mitteln versehen, die einen gleichzeitigen Anschluß an mehrere Übertragungsmedien ermög­ lichen.

Die Aufgabe der vorliegenden Erfindung besteht darin, es zu ermöglichen, daß ein erster Kommunikationsteilnehmer, der an ein erstes Netzwerk angeschlossen ist, mit einem zweiten Kommunikationsteilnehmer, an den ein zweites, mit dem ersten Netzwerk nicht direkt verbundenes Netzwerk anschließbar ist, auf komfortable Art Daten austauschen kann.

Dazu ist zunächst ein spezieller, zusätzlicher Kommunika­ tionsteilnehmer vorgesehen, der einerseits an das erste Netz­ werk, im folgenden kurz Netzwerk, angeschlossen ist und an den andererseits das zweite Netzwerk, im folgenden kurz Feld­ bus, anschließbar ist. Der zusätzliche Kommunikationsteil­ nehmer dient damit quasi als Schnittstelle zwischen dem Netz­ werk und dem Feldbus.

Die Aufgabe, eine besonders komfortable Möglichkeit des Datenaustausches anbieten zu können, wird dadurch gelöst, daß der an das Netzwerk angeschlossene spezielle Kommunikationsteilnehmer zur Repräsentation von an den Feldbus anschließ­ baren Endgeräten - den potentiellen zweiten Kommunikations­ teilnehmern - Software-Objekte aufweist. Der Feldbus syn­ chronisiert einen zumindest den Endgeräten und dem speziellen Kommunikationsteilnehmer gemeinsamen Adreßraum, der zumindest in einem dafür vorgesehenen Speicher des speziellen Kommuni­ kationsteilnehmers abbildbar ist. Die Software-Objekte des speziellen Kommunikationsteilnehmers sind über das Netzwerk mittels eines für das Netzwerk definierten Übertragungs­ protokolls genau wie der spezielle Kommunikationsteilnehmer selbst oder weitere Kommunikationsteilnehmer ansprechbar. Das adressierte, ein Endgerät als zweiten Kommunikationsteil­ nehmer repräsentierende Software-Objekt führt im Falle eines über das Netzwerk beim speziellen Kommunikationsteilnehmer eintreffen­ den Telegramms die Abwicklung der gemäß dem für das Netzwerk definierten Übertragungsprotokoll erforderlichen Schritte zum Empfang des Telegramms aus. Ferner wird entweder als Reaktion auf das Telegramm ein Datum in den obengenannten Speicher des speziellen Kommunikationsteilnehmers eingeprägt, wobei die Änderung des Inhaltes des Speichers dem zweiten Kommunika­ tionsteilnehmer im Rahmen des zyklischen Datentransfers über den Feldbus übermittelbar ist oder das Telegramm, insbesonde­ re nach dessen Transformation in eine für das Übertragungs­ protokoll des Feldbusses geeignete Form, an den durch das Software-Objekt repräsentierten zweiten Kommunikationsteil­ nehmer übermittelt.

Die Anzahl der Software-Objekte des speziellen Kommunika­ tionsteilnehmers ist vorzugsweise frei projektierbar, insbe­ sondere jedoch auf die Anzahl der an den Feldbus angeschlos­ senen Endgeräte abgestimmt.

Vorteilhaft sind den jeweiligen Software-Objekten innerhalb des Netzwerks eindeutige, zur zielgerichteten Datenübertra­ gung gemäß dem für das Netzwerk vorgesehenen Übertragungspro­ tokoll geeignete Adressen zuordenbar.

Das adressierte Software-Objekt führt vorzugsweise je nach Art der mit dem Telegramm übermittelten Daten eine Vorverar­ beitung der Daten des empfangenen Telegramms durch.

Weitere Merkmale, Vorteile und Anwendungsmöglichkeiten der Erfindung ergeben sich aus den Unteransprüchen, der nachfol­ genden Beschreibung eines Ausführungsbeispiels anhand der Fi­ guren und der Figuren selbst. Dabei bilden alle beschriebenen und/oder bildlich dargestellten Merkmale für sich oder in be­ liebiger Kombination den Gegenstand der vorliegenden Erfin­ dung, unabhängig von ihrer Zusammenfassung in den Ansprüchen oder deren Rückbeziehung.

Gemäß Fig. 1 sind an das Netzwerk N mehrere Kommunikations­ teilnehmer LR, P, S angeschlossen, wobei ein Kommunikations­ teilnehmer LR z. B. ein Leitrechner ist.

Der spezielle Kommunikationsteilnehmer P stellt eine Schnitt­ stelle zwischen dem Netzwerk N und dem Feldbus BU dar. Über den Feldbus BU sind an den Kommunikationsteilnehmer P Endge­ räte A, B angeschlossen, wobei die Endgeräte unterschiedlich­ ste technologische Funktion (Aktoren, Sensoren, etc.), die bei der Automatisierung technischer Prozesse erforderlich sind, realisieren.

Für die weitere Beschreibung wird davon ausgegangen, daß an das Endgerät A ein Motor M und an das Endgerät B ein Ventil V angeschlossen ist. Der Motor M und das Ventil V sind Elemente eines zu steuernden technischen Prozesses TP; in der Fig. 1 nur schematisch durch die Trennlinie angedeutet.

Im Kommunikationsteilnehmer P sind zur Kommunikation mit den Endgeräten A, B Software-Objekte A', B' vorgesehen, die aus Netzwerksicht die über das Netzwerk nicht direkt erreichbaren Endgeräte A, B repräsentieren.

In einer ersten vorteilhaften Ausgestaltung ist vorgesehen, daß, um der speziellen Funktionalität der jeweiligen Endgerä­ te A, B Rechnung zu tragen, als Software-Objekt A' ein auf die Motorenfunktionalität des Endgerätes A abgestellter Ob­ jekttyp A" instanziiert und als Software-Objekt B' ein auf die Ventilfunktionalität des Endgerätes B abgestellter Ob­ jekttyp B" instanziiert wird.

Die jeweiligen Objekttypen A", B" stellen eine auf die je­ weils zu realisierenden Funktionalität abgestellte Kollektion von Eingangsdaten, Ausgangsdaten und Methoden (Elementfunk­ tionen, Properties) M11, M12, M13, M14, V11, V12 zur Verfü­ gung, mittels derer auf bestimmte Funktionalitäten der Endge­ räte bzw. der diese repräsentierenden Objektklassen zugegriffen werden kann. Um z. B. den an das Endgerät A angeschlosse­ nen Motor M abzuschalten, übermittelt der Leitrechner LR über das Netzwerk N an das Software-Objekt A' ein Telegramm, das die entsprechende Elementfunktion des Software-Objektes A' anspricht. Die entsprechende Elementfunktion kann z. B. lauten "Motor aus". Analog verhält es sich für die Ventilfunktiona­ lität des Endgerätes B.

Die Fig. 2 und 3 zeigen eine graphische Darstellung der Objekttypen, die als Software-Objekte A', B' im Kommunika­ tionsteilnehmer B zur Repräsentation eines Endgerätes A mit daran angeschlossenem Motor M bzw. zur Repräsentation eines Endgerätes B mit daran angeschlossenem Ventil V instanziiert werden. Gemäß Fig. 2 weist der Objekttyp A" vier exportierte Daten bzw. Elementfunktionen M11, M12, M13, M14 auf. Als ex­ portierte Daten M11, M12 kommen z. B. die Soll- und die Ist­ drehzahl des Motors M in Frage; als exportierte Elementfunk­ tionen M13, M14 kommen z. B. Funktionen zum Ein- bzw. Aus­ schalten des Motors in Frage. Selbstverständlich kann man sich noch weitere exportierte Daten bzw. Elementfunktionen vorstellen, etwa Elementfunktionen zum Anfahren des Motors entsprechend einer vorgebbaren oder vorgegebenen Kennlinie, Daten zur Vorgabe des Bremsverhaltens etc.

Fig. 3 zeigt den zur Repräsentation des Endgerätes B mit daran angeschlossenem Ventil V vorgesehenen Objekttyp B", mit zwei exportierten Daten bzw. Elementfunktionen V11, V12, wobei als Elementfunktionen V11, V12 z. B. Funktionen zum Öffnen bzw. zum Schließen des Ventils vorgesehen sein können.

Die jeweiligen Software-Objekte A', B' enthalten Programm­ code, der geeignet ist, entweder übertragene Daten direkt in den gemeinsamen Speicherraum M des Feldbusses BU zu übertra­ gen, oder aber Telegramme auszulösen, mittels derer die ent­ sprechenden Daten direkt an die Endgeräte A, B übermittelt werden.

Beim Eintragen der Daten in den gemeinsamen Speicherraum M werden veränderte Daten im Rahmen der zyklischen Übertragung über den Feldbus BU an die Endgeräte A, B übermittelt, so daß auch ein zunächst nur in dem Speicherraum M geändertes Datum schließlich beim eigentlichen Adressat, z. B. dem Endgerät A, ankommt.

Beim Auslösen von Telegrammen für eine Datenübertragung über den Feldbus BU übernimmt das Software-Objekt A', B' die Transformation des über das Netzwerk N empfangenen Telegramms in das für den Feldbus BU vorgesehene Datenformat. Beim soge­ nannten Profibus BU, einem weit verbreiteten Feldbus BU, wür­ den solche Telegramme als sogenannte azyklische, den zykli­ schen Datenaustausch nicht beeinflussende Telegramme versen­ det.

Alternativ oder zusätzlich ist es denkbar, daß entgegen dem oben beschriebenen Beispiel, bei dem die Software-Objekte A', B' Instanzen jeweils unterschiedlicher Objekttypen A", B" wa­ ren, die Software-Objekte A', B' Instanzen ein und desselben Objekttyps AB" sind, wobei der Objekttyp AB" dann zumindest Methoden AB11, AB12 zum Senden und Empfangen von Telegrammen über das Netzwerk N bereitstellt; vgl. Fig. 4.

Zum Einschalten des an das Endgerät A angeschlossenen Motors M wird dann z. B. ausgehend vom Leitrechner LR ein Telegramm an das Software-Objekt A' gesendet und damit die Elementfunk­ tion "Receive" AB11 der Instanz des entsprechenden Objekttyps AB" aktiviert, wobei die Elementfunktion "Receive" AB11 mit­ tels im Software-Objekt A' vorgesehenen Codes dafür sorgt, daß das über Netzwerk N empfangene Telegramm in eine für den Feldbus BU geeignete Form transformiert wird und schließlich an das Endgerät A übermittelt wird.

In einer dritten Ausprägung ist es möglich, daß auch für un­ terschiedliche Schnittstellenfunktionalität der jeweils zu adressierenden Endgeräte A, B als Repräsentanz Instanzen ein und desselben Software-Objektes verwendet werden.

Dazu ist im Software-Objekt eine Tabelle T vorgesehen, wobei die einzelnen Tabelleneinträge T1, T2 zumindest zwei Positio­ nen S1, S2 umfassen. Die erste Position T1S1 eines Tabellen­ eintrags T1, T2 repräsentiert eine Adresse des gemeinsamen Adreßraums der an den Feldbus BU angeschlossenen Kommunika­ tionsteilnehmer P, A, B, die zweite Position T1S2 den Spei­ cherbedarf des Datums an der spezifizierten Adresse.

Wenn z. B. exemplarisch die Drehzahl des an das Endgerät A an­ geschlossenen Motors M verändert werden soll, kann die Soll­ drehzahl, die an einer definierten Position, z. B. der Adresse #768, des gemeinsamen Adreßraums M hinterlegt wird, durch ei­ ne entsprechende, auf einer zugehörigen Kommunikation basie­ renden Anweisung modifiziert werden.

Dazu wird z. B. an der die erste Position T1S1 der Tabelle repräsentierenden Adresse, hier exemplarisch #768, der mit dem Tele­ gramm übermittelte neue Sollwert eingetragen. Die Datenände­ rung im gemeinsamen Speicher M wird dem Endgerät A im Rahmen der zyklischen Datenübertragung über den Feldbus BU mitge­ teilt.

Um die Benutzerfreundlichkeit noch weiter zu erhöhen, werden die einzelnen Einträge T1, T2 um eine zusätzliche Position S3 erweitert. Diese Position S3 umfaßt eine Struktur, die zumin­ dest Raum für eine deklarative Bezeichnung der entsprechenden Position der Tabelle T bietet. So kann z. B. eine erste Posi­ tion T1 der Tabelle T als "Sollwert" T1S3 und eine weitere Position T2 der Tabelle T als "Istwert" T2S3 bezeichnet wer­ den. Diese Bezeichner werden exportiert und zwar z. B. da­ durch, daß sogenannte type-Libraries, die weitgehend den z. B. von der Programmiersprache C++ bekannten sog. "Header- Dateien" entsprechen, die die Bezeichner und die zugehörigen Daten enthalten, projektglobal bei allen Kommunikationsteil­ nehmern vorliegen.

Nachdem damit z. B. die Bezeichner "Sollwert" T1S3 und "Ist­ wert" T2S3 im Leitrechner LR vorliegen, ist ein besonders übersichtliches Ansprechen des an das Endgerät A angeschlos­ senen Motors möglich, indem zum Abfragen des Istwertes über das Protokoll des Netzwerkes N das exportierte Datum Istwert des Software-Objektes A' abgefragt wird. Intern wird bei Ab­ fragen des Datums Istwert über die Verknüpfung anhand der Ta­ belle T das in der durch die Deklaration Istwert repräsen­ tierten Zeile T1 eingetragene Datum anhand der zugehörigen Adresse T1S1 ausgelesen. Das Auslesen kann dabei wieder aus dem globalen Speicherbereich M erfolgen. Der Istwert im Spei­ cherbereich M ist aufgrund des zyklischen Datenaustausches über den Feldbus FB stets aktuell.

Ein spezielles Ausführungsbeispiel wird nun abschließend mit Bezug auf Fig. 6 beschrieben:

Eine mögliche Umsetzung einer solche Konfiguration benutzt als Feldbus BU den sogenannten PROFIBUS DP mit einem DP- Master P und einem oder mehreren DP-Slaves A.

Der Leitrechner LR initiiert in dieser Umsetzung eine Kommu­ nikation über den Objektbus DCOM über TCP/IP und Ethernet N an den DP-Master P und adressiert das Software-Objekt A'.

Das Software-Objekt A' ermittelt anhand von in einer Projek­ tierungstabelle gespeicherten Daten den am besten für den PROFIBUS DP BU zu nutzenden Übertragungsweg. Die Projektie­ rungstabelle enthält dabei für jede der Funktionen, die am DCOM Interface des Software-Objektes A' definiert sind, den Zugriffsweg und die für den Zugriff nötigen Zugriffsparame­ ter.

Handelt es sich bei der aufgerufenen Funktion um einen soge­ nannten DCOM Propertyzugriff auf ein lokal verfügbares Datum, bedient sich das Software-Objekt A' dabei des gemeinsamen Speichers M. Dieses trifft genau dann zu, wenn das DCOM Property auf ein E/A-Signal des DP-Slaves A abgebildet ist. Die E/A-Signale von DP-Slaves werden entsprechend der DP-Norm zy­ klisch in den gemeinsamen Speicher M am DP-Master P transpor­ tiert. Diese Funktion kann somit komplett auf dem DP-Master abgearbeitet werden, es ist keine Kommunikation zu diesem DP- Slave A nötig. Der Bus BU wird von der Kommunikation für den Zugriff auf diese Daten entlastet.

Handelt es sich um eine Funktion, die nur durch den DP-Slave abgearbeitet werden kann, d. h. Propertyzugriffe auf Daten, die sich nicht in den E/A-Signalen befinden oder Aufrufe von Methoden, wird das DCOM-Protokoll in ein speziell auf den PROFIBUS DP abgestimmtes Echtzeitprotokoll umgewandelt (quasi eine "Kurzform" der DCOM PDU, um die übertragenen Daten zu minimieren). Dieses Echtzeitprotokoll nutzt den PROFIBUS DPV1 Mechanismus "Datensätze schreiben", um die Protokolleinheiten an den DP-Slave A zu übertragen. Dieser empfängt das Proto­ koll und führt die Implementation der jeweiligen Funktion als Reaktion auf das empfangene Telegramm aus. Nach der Bearbei­ tung werden die Antwortparameter rückwärts vom DP-Slave A über das Echtzeitprotokoll unter Nutzung der PROFIBUS DPV1 Mechanismen "Alarm" in Kombination mit "Datensatz lesen" zum DP-Master P und dort in das Software-Objekt A' transportiert. Das Software-Objekt A' gibt die Antwortparameter an den Auf­ rufer LR über den Bus N und die dort verwendeten Kommunikati­ onsmechanismen (DCOM) zurück.

Claims (10)

1. Als Schnittstelle zwischen einem Netzwerk (N) und einem Feldbus (BU) geeigneter Kommunikationsteilnehmer (P),

• - wobei einerseits der Kommunikationsteilnehmer (P) an das Netzwerk (N) und andererseits an den Kommunikationsteil­ nehmer (P) der Feldbus (BU) anschließbar ist,
• - wobei der Kommunikationsteilnehmer (P) zur Repräsenta­ tion von an den Feldbus (BU) angeschlossenen Endgeräten (A, B) Software-Objekte (A', B') aufweist,
• - wobei die Software-Objekte (A', B') über das Netzwerk (N) mittels des für das Netzwerk (N) definierten Über­ tragungsprotokolls genau wie der Kommunikationsteilneh­ mer (P) selbst oder weitere Kommunikationsteilnehmer (S) ansprechbar sind,
• - wobei der Feldbus (BU) einen den Kommunikationsteilneh­ mern (P, A, B) gemeinsamen Adreßraum synchronisiert, der zumindest im Speicher (M) des Kommunikationsteilnehmers (P) abbildbar ist,
• - wobei im Falle eines über das Netzwerk (N) beim Kommuni­ kationsteilnehmer (P) eintreffenden, ein Software-Objekt (A', B') adressierenden Telegramms das Software-Objekt (A', B')
• - die Abwicklung der gemäß dem für das Netzwerk (N) de­ finierten Übertragungsprotokoll erforderlichen Schritte zum Empfang eines Telegramms ausführt und
• - entweder als Reaktion auf das Telegramm ein Datum in den Speicher (M) eingeprägt, wobei die Änderung des Inhaltes des Speichers (M) den Endgeräten (A, B) im Rahmen des zyklischen Datentransfers über den Feldbus (BU) übermittelbar ist
• - oder das Telegramm, insbesondere nach dessen Trans­ formation in eine für das Übertragungsprotokoll des Feldbusses (BU) geeignete Form, an das jeweilige durch das Software-Objekt (A', B') repräsentierte Endgerät (A, B) übermittelt.

2. Kommunikationsteilnehmer nach Anspruch 1, wobei die An­ zahl der Software-Objekte (A', B') frei projektierbar, insbesondere auf die Anzahl der an den Feldbus (BU) ange­ schlossenen Endgeräte (A, B), abgestimmt ist.

3. Kommunikationsteilnehmer nach Anspruch 1, wobei den Soft­ ware-Objekten (A', B') innerhalb des Netzwerks (N) ein­ deutige, zur zielgerichteten Datenübertragung gemäß dem für das Netzwerk (N) vorgesehenen Übertragungsprotokoll geeignete Adressen zuordenbar sind.

4. Kommunikationsteilnehmer nach Anspruch 1, wobei das adressierte Software-Objekt (A', B') eine Vorverarbeitung der Daten des empfangenen Telegramms durchführt.

5. Kommunikationsteilnehmer nach Anspruch 1, wobei das Soft­ ware-Objekt (A', B') eine Tabelle mit mindestens einem Tabellenelement aufweist, wobei in dem Tabellenelement zumindest eine Adresse (ADR) und eine Dimensionsinforma­ tion (DIM) eines Datums (DAT) abspeicherbar ist, wobei als Adresse (ADR) die auf den gemeinsamen Adreßraum des Feldbusses (BU) bezogene Adresse eines vom Endgerät (A, B) exportierten Eingangs- oder Ausgangswertes und als Di­ mensionsinformation (DIM) der Speicherplatzbedarf dieses Eingangs- oder Ausgangswertes im Adreßraum eintragbar ist.

6. Kommunikationsverfahren zur Kommunikation zwischen einem ersten Kommunikationsteilnehmer (LR) und einem zweiten Kommunikationsteilnehmer (A, B),

• - wobei der erste Kommunikationsteilnehmer (LR) an ein Netzwerk (N) angeschlossen ist,
• - wobei der zweite Kommunikationsteilnehmer (A, B)
• - nicht an das Netzwerk (N) angeschlossen ist, sondern
• - über einen einen den Kommunikationsteilnehmern (P, A, B) gemeinsamen Adreßraum synchronisierenden, zumindest im Speicher (M) eines weiteren, als Schnittstelle geeigneten Kommunikationsteilnehmers (P) abbildbaren Feldbus (BU) mit diesem weiteren, an das Netzwerk (N) angeschlossenen Kommunikationsteilnehmer (P) verbunden ist,
• - wobei der weitere, an das Netzwerk (N) angeschlossene Kommunika­ tionsteilnehmer (P) zur Repräsentation des zweiten Kom­ munikationsteilnehmers (A, B) ein entsprechendes Soft­ ware-Objekt (A', B') aufweist,
• - wobei das Software-Objekt (A', B') über das Netzwerk (N) mittels eines für das Netzwerk (N) definierten Über­ tragungsprotokolls genau wie der weitere Kommunikationsteilneh­ mer (P) selbst oder andere Kommunikationsteilnehmer (S) ansprechbar ist,
• - wobei im Falle eines über das Netzwerk (N) beim weiteren Kommu­ nikationsteilnehmer (P) eintreffenden, den zweiten Kom­ munikationsteilnehmer (A, B) adressierenden Telegramms das Software-Objekt (A', B')
• - die Abwicklung der gemäß dem für das Netzwerk (N) de­ finierten Übertragungsprotokoll erforderlichen Schritte zum Empfang des Telegramms ausführt und
• - entweder als Reaktion auf das Telegramm ein Datum in den Speicher (M) eingeprägt, wobei die Änderung des Inhaltes des Speichers (M) dem zweiten Kommuni­ kationsteilnehmer (A, B) im Rahmen des zyklischen Datentransfers über den Feldbus (BU) übermittelbar ist
• - oder das Telegramm, insbesondere nach dessen Trans­ formation in eine für das Übertragungsprotokoll des Feldbusses (BU) geeignete Form, an den durch das Software-Objekt (A', B') repräsentierten zweiten Kommunikationsteilnehmer (A, B) übermittelt.

7. Kommunikationsverfahren nach Anspruch 6, wobei die Anzahl der Software-Objekte (A', B') frei projektierbar, insbe­ sondere auf die Anzahl der an das Teilnetzwerk (T) ange­ schlossenen Endgeräte (A, B) abgestimmt, ist.

8. Kommunikationsverfahren nach Anspruch 6, wobei den Soft­ ware-Objekten (A', B') innerhalb des Feldbusses (B) ein­ deutige, zur zielgerichteten Datenübertragung gemäß dem für den Feldbus (B) vorgesehenen Übertragungsprotokoll geeignete Adressen zuordenbar sind.

9. Kommunikationsverfahren nach Anspruch 6, wobei das den zweiten Kommunikationsteilnehmer (A, B) repräsentierende adressierte Software-Objekt (A', B') eine Vorverarbeitung der Daten des empfangenen Telegramms durchführt.

10. Kommunikationsverfahren nach Anspruch 6, wobei das Soft­ ware-Objekt (A', B') eine Tabelle mit mindestens einem Tabellenelement aufweist, wobei in dem Tabellenelement zumindest eine Adresse (ADR) und eine Dimensionsinforma­ tion (DIM) eines Datums (DAT) abspeicherbar ist, wobei als Adresse (ADR) die auf den gemeinsamen Adreßraum des Feldbusses (BU) bezogene Adresse eines vom Endgerät (A, B) exportierten Eingangs- oder Ausgangswertes und als Di­ mensionsinformation (DIM) der Speicherplatzbedarf dieses Eingangs- oder Ausgangswertes im Adreßraum eintragbar ist.