Embed Size (px)
Citation preview
Electronic Device Description Language -Basis für eine einheitliche und platt-formunabhängige GerätebedienungMartin Augustin, Kurt Polzer und Wolfgang Ott, Siemens AG
Für die Bedienung von Feldgeräten gibt es heute unterschiedliche Ansätze. Eine Methodik ist die Beschreibungder Feldgeräteeigenschaften mit der Electronic Device Description Language (EDOL), die eine Weiter-entwicklung der Device Description Language darstellt. In diesem Aufsatz werden die Anforderungen diskutiert,die seitens aller Beteiligten - angefangen vom Feldgerätehersteller bis hin zum Anwender - an die Ge-rätebedienung gestellt werden. Anhand eines Fallbeispiels für eine EDD-Erstellung werden die Möglichkeitenvon EDOL als plattformunabhängige Gerätebeschreibung erläutert und anschließend bewertet.
Electronic Device Description Language - Basis for a common and platform-independent deviceoperationToday, there are various ways to operate field devices. One system uses the description of the data andfeatures of the field device via the Electronic Device Description Language (EDDL) which is a development ofthe Device Description Language. This paper discusses the requirements set for device operation by all inte-rested parties - from field device manufacturer to user. EDDL capabilities, as regards device description inde-pendent from the operating system and the hardware platform, are explained and subsequently assessed byusing a case example for an EDD generation.
1. Einleitung
Zur Bedienung kommunikationsfähiger Prozessgeräte lie-fern Gerätehersteller den Kunden bis heute spezielle Be-dienprogramme. Diese sind in aller Regel auf das zubedienende Gerät oder die Gerätefamilie abgestimmt undin Bezug auf Bedienoberfläche und Benutzerführung starkvom jeweiligen Hersteller geprägt.
Für das Automatisierungs- oder Leitsystem ergebensich dadurch folgende Nachteile:• Die Bedienung der Feldgeräte von Fremdherstellern ist
nicht oder nur mit großem Aufwand möglich.• Die Bedienphilosophie und die Bedienoberfläche diffe-
rieren von einem Feldgerätehersteller zum anderen.• Mit jeder Änderung im Gerät muss ein Software-Update
einhergehen.• Diese Software-Updates sind mit viel Aufwand, Risiken
und hohen Kosten verbunden.• Die Software wird meistens nur für ein spezielles Be-
triebssystem oder eine Betriebssystemversion angebo-ten.
Vor diesem Hintergrund wurde im lnterOperableSy-systemsTMProject (ISP) [4] schon 1993 eine Device De-scription Language (DDL) entwickelt, die auf der HART-Technik (Highway Addressabie Remote Transducer) auf-baut. (Die in diesein Beitrag verwendeten speziellenBegriffe und Abkürzungen sind in Tabelle 1 erläutert.)Ähnlich wie bei HTML oder JAVA wurde mit dieser DOLeine Sprache festgelegt, um den Forderungen nachPlattform- und Betriebssystemunabhänqiqkeit gerecht zuwerden. So wie HTML zur Beschreibung von Texten dient,wird die DDL zur
Bild 1: Der Hersteller liefert für sein Gerät eine ElectronicDevice Description (EDD). Diese EDD beschreibt alleGerätefunktionen und -daten und wird von einemParametrierwerkzeug (irn Bild der Process DeviceManager von Siemens) zur Bedienung des Gerätsverwendet.
Beschreibung der kommunizierbaren Parameter einesFeldgeräts mit allen Abhängigkeiten sowie derenGruppierung in logisch zusammenhängenden Blöckenangewandt.
Die Device Description kann im Feldgerät oder aufeinem Datenträger abgelegt sein. EinParametrierwerkzeug extrahiert die zur Bedienung desFeldgeräts erforderlichen Informationen aus der DeviceDescription. Dadurch lassen sich mit einer einzigengenerischen Bediensoftware verschiedene Feldgeräteunterschiedlicher Hersteller plattformübergreifendbedienen.
Die EDD-Language (EDDL) [6] ist dieWeiterentwicklung der in ISP festgelegten DeviceDescription Language für PROFIBUS-Geräte. Diezugelassene Richtlinie ist derzeit -Stand August 1999 - imReviewverfahren; sie soll offizielle PNO-Richtlinie werden.Bild 1 gibt einen Überblick über die Geräteparametrierungauf Basis von EDDL.
Mit dem Process Device Manager von Siemens (SIMA-TIC PDM) wurde ein erstes leistungsfähiges Parametrier-werkzeug für die Interpretation und Darstellung der Electro-nic Device Description (EDD) entwickelt, das dieBedienung von Feldgeräten ermöglicht.
Bevor auf den Aufbau einer Electronic Device Descrip-tion näher eingegangen wird, werden im folgenden Ab-
schnitt die Anforderungen der verschiedenen EDD-Anwen-der erläutert.
2. Anforderungen aus dem Umfeld derGerätebedienung
Neben dem Gerätehersteller und dem Anlagenprojektierernehmen eine ganze Reihe weiterer Personen auf die Gerä-tebedienung Einfluss. Dies erfolgt durch deren Produkteund die daran geknüpften Anforderungen. In diesemAbschnitt werden die wichtigsten Akteure genannt undderen Interessen beleuchtet.
2.1 Der Gerätehersteller
Der Hersteller parametrierbarer Geräte muss sicher seinkönnen, dass dem Anwender sämtliche Daten undFunktionen seines Geräts zur Verfügung stehen. Dies kanndurch eine in das Gerät integrierte Bedienmöglichkeiterfolgen. Bei dieser Variante ist er unabhängig vonanderen Komponenten, wie zum Beispiel Leitsystemenoder Parametrierwerk
Tabelle 1:Glossar
ActiveX-Steuerelemente sichtbare oder nicht sichtbare Objekte, die unter Microsoft Windows in sogenannten Container-Anwendungen
ablauffähig sind. Container-Anwendungen können hier z.B. Visual Basic, Internet Explorer oder eigene
Anwendungen sein.
COM (Component Object Model) ist eine Spezifikation der Firma Microsoft, die die Kommunikation zwischen
Programmen und Prozessen regelt. COM definiert eine Schnittstelle, mit der es möglich ist, Programmsysteme
aus einzelnen unabhängigen Komponenten aufzubauen. Die COM-Technologie legt fest, wie ActiveX-
Steuerelemente und deren Schnittstellen aufgebaut sind.
DCOM (Distributed Component Object Model) ist eine Erweiterung von COM für die Arbeit im lokalen Netz und in
globalen Netzen.
DD (Device Description) ist eine Gerätebeschreibung, basierend auf einer formalen Beschreibungssprache.
DDE (Dynamic Data Exchange) ist ein Protokoll, das den Anwendern den dynamischen Datenaustausch gestattet.
Die Grundlage bilden hier die Windows-Nachrichten-Mechanismen.
DDL (Device Description Language) ist eine Sprache zur Beschreibung von Geräteobjekten. Geräteobjekte sind zum
Beispiel Parameter, wie Grenzwerte oder Zeitkonstanten, aber auch Gerätefunktionen.
EDD (Electronic Device Description) ist eine Gerätebeschreibung, erstellt mit EDDL.
EDDL (Electronic Device Description Language) ist eine Gerätebeschreibungssprache. Die EDD-Language ist die
Weiterentwicklung der in ISP festgelegten Device Description Language für PROFIBUS-Geräte.
HART (Highway Addressable Remote Transducer) definiert das HART-Protokoll, mit dem Parameter zwischen
Feldgerät und den sogenannten HART-Mastern kommuniziert werden können. Zur Beschreibung der
Feldgeräteeigenschaften wird die HART-DDL verwendet.
HMI (Human Machine Interface) ist das Erscheinungsbild eines Systems, wie es sich dem Anwender auf der Bedien-
und Beobachtungsplattform darstellt.
HTML (Hypertext Markup Language) ist eine Dokumentbeschreibungssprache, um Formatierungen innerhalb eines
Web-Dokuments mit dem eigentlichen Dokumenttext zu beschreiben.
ISP InterOperableSystemsTMProject.
OCX-Controls sind Software-Komponenten, die über die in COM definierte Software-Schnittstelle ihre Dienste zur Verfügung
stellen. Internetfähige OCX-Controls heißen heute ActiveX-Controls.
PNO Profibus Nutzer Organisation (http:\\www.profibus.com).
Profile bestehend aus einer Beschreibung der Kommunikationsschnittstelle (Kommunikationsprofil) und den - über den
Feldbus zugänglichen - branchenspezifischen Gerätefunktionen wie Messen und Parametrieren
(Anwendungsprofil).
SIMATIC PDM (Process Device Manager) ist ein Parametrierwerkzeug für die Interpretation und Darstellung der Electronic
Device Description, das die Bedienung von Feldgeräten ermöglicht.
modales Fenster bedeutet, dass der Benutzer so lange keine Aktionen mit anderen Fenstern der gleichen Anwendung ausführen
kann, bis er den Dialog durch einen Mausklick auf die Schaltflächen OK oder Abbrechen schließt.
zeugen. Moderne Geräte sind bereits seit geraumer Zeitüber unterschiedliche Kommunikationsschnittstellenbedienbar. Anfangs waren diese meist proprietär, oftbasierend auf RS232 oder RS485. Diese werden aberimmer mehr von Standardlösungenzurückgedrängt.Standardlösungen sind dabei HART oderBussysteme, wie zum Beispiel der PROFIBUS.
Mit der wachsenden Bedeutung von Standardlösungenvollzogen sich weitere Entwicklungen. So werden seit meh-reren Jahren Softwareprodukte von Geräteherstellernangeboten, die nicht nur eigene Geräte, sondern auch dieGeräte anderer Hersteller bedienen können. AufKundenwunsch sind nun viele Geräteherstelleraufgefordert, ihre Geräte in die unterschiedlichstenParametrierwerkzeuge einzubinden.
Das Interesse des Geräteherstellers ist es, seineGeräte nur einmal zu beschreiben, unabhängig von Tools,Leitsystemen und Betriebssystemen. Modifikationendieser Beschreibung sollen nur dann erfolgen, wenn imGerät Änderungen durchgeführt wurden. Dabei sollen dieKosten für die Erstellung und Pflege derGerätebeschreibung minimal sein. Die Bedienung derGeräte auf Basis dieser Beschreibung soll umfassend aufdie Geräte abgestimmt sein und bezüglich der Oberflächedas eigene Corporate Design optimal unterstützen.
2.2 Der Toolhersteller
Mit wachsender Standardisierung der Kommunikationsan-bindung und der Gerätefunktionalitäten wurde die tech-nische Grundlage geschaffen, mit einem einzigenSoftwareprodukt eine Vielzahl von Geräten bedienbar zumachen. Ein Ansatz dazu war bei HART die Definition derUniversal und Common Practice Commands. Mit diesenKommandos waren die Grundfunktionalitäten eines jedenHART-Geräts bedienbar, unabhängig von Typ undHersteller. Im Umfeld des PROFIBUS befinden sich mitStand August 1999 die sogenannten PA-Profile mit derVersion V3.0 im Review. Diese Profile gehen weit über dieUniversal und Common Practise Commands hinaus undvereinheitlichen Geräteparameter und -funktionen fürbestimmte Messaufgaben, wie zum Beispiel für Druck,Temperatur, Durchfluss bis hin zu den Analysegeräten. DieInteressen eines Toolherstellers liegen nun darin, neueGeräte ohne Änderungen der eigenen Software integrierenzu können. Die Bedienung der Geräte sollte im Tooleinheitlich sein. Einheitlich heißt, dass Geräte unabhängigvom Hersteller, der Messaufgabe und demKommunikationsinterface auf die gleiche Art und Weisebedienbar sein müssen. Beispiel: einDruckmessumformer des Herstellers A mit HART-Interfacemuss auf die gleiche Art und Weise bedienbar sein wie einelektropneumatischer Stellungsregler des Herstellers Bmit einem PROFIBUS-PA-Interface. Normen wie die DIN V19259, die in eine IEC-Norm überführt werden wird, sindhierbei eine große Hilfe, da sie Aussagen zur Taxonomieund zur Begriffswelt beinhalten.
Ein weiteres Interesse des Toolherstellers ist es, dasssein Tool nicht nur in eigenen Leitsystemen - sofern vor-handen - ablauffähig ist, sondern mittels definierter Schnitt-stellen in beliebige Leitsysteme integriert werden kann. Im
PNO Arbeitskreis PLT sollen mit dem "Fieldbus DeviceTool (FDT)" [1] diese Schnittstellen spezifiziert werden.
Ein Bedientool für Geräte läuft im Kontext eines be-
stimmten Betriebssystems oder einerBetriebssystemfamilie ab. Heute sind dies imWesentlichen Windows 95, 98 und NT. Zukünftig wirdWindows 2000 dazu kommen. Inwieweit sich Linux indiesem Umfeld behaupten wird, bleibt abzuwarten. Wichtigfür den Toolhersteller ist dabei die Kompatibilität desunterlagerten Betriebssystems. Leider ist diese Kompa-tibilität oftmals auch innerhalb von Betriebssystemfamiliennicht gegeben. So ist es z.B. dringend geboten, ein ent-wickeltes ActiveX-Control sowohl unter Windows 95 alsauch unter Windows NT zu testen, da sich deren Verhal-tensweisen erheblich unterscheiden können.
2.3 Der Leitsystemhersteller
Oftmals sind heute noch in einer Automatisierungslösungdie Feldinstrumentierung und das Leitsystem unterschied-liche Welten. Ein Messumformer wird aus Sicht des Leit-systems zu einem 4 ... 20 mA Signal degradiert. Der Mess-umformer liefert sein 4 ... 20 mA Signal, unabhängig davon,wann dieses von wem oder wie ausgewertet wird. DieserAnsatz reicht bis in die Prozesse des Anwenders hinein.Heute gewinnen allerdings zunehmend Bussysteme anBedeutung, an die Instrumente direkt oder überKommunikationskomponenten angeschlossen werdenkönnen. Mit Remote-1/0-Systemen, wie zum Beispiel derET 200M von Siemens ist es möglich, HART-Geräte vomPROFIBUS aus zu bedienen. Auch die Durchgängigkeitvom Anlagenbus zum Feldbus ist bei einzelnen Systemenbereits verfügbar. Die Bereiche Leitebene undFeldinstrumentierung rücken mehr und mehr zusammen.Damit wächst die Notwendigkeit, Feldgeräte vomLeitsystem aus bedienen zu können. Was läge also inZeiten der Kostenreduzierung näher, als bestehende Toolsin das eigene Leitsystem zu integrieren, statt mit einerrisikobehafteten und teuren Neuentwicklung zu beginnen.Dabei sollte natürlich die Bedienung der Geräte einheitlichsein, ein spezifisches Geräte-Know-how darf nichtVoraussetzung sein. Trotzdem sollte die Möglichkeitbestehen, von der Leitsystemsoftware aus über definierteSchnittstellen auf die Parameter eines jeden Feldgerätszugreifen zu können.
Eine wichtige Forderung ist, dass bei eventuell notwen-digen Problemlösungen die Verantwortlichkeiten für dieeinzelnen Komponenten klar definiert sind und die Zahl derAnsprechpartner sich auf einen kleinen Kreis beschränkt.
2.4 Der Betriebssystemhersteller
Betriebssystemlösungen sind heute einem rasantenInnovationstempo unterworfen. So war Windows 95 kaumfertiggestellt, als das Internet plötzlich enorm anBedeutung gewann. Microsoft musste darauf unmittelbarreagieren, wollte es nicht seine Position am Marktgefährden.
Solche neuen Rahmenbedingungen führen notwendi-gerweise zu immer neuen Technologien, die in aller Regel
nicht aufwärtskompatibel sind. War vor etwa zwei Jahrenunter Windows noch DDE (Dynamic Data Exchange) Standder Dinge, so ist man mittlerweile über Distributed DDE,OCX, COM, DCOM bei ActiveX angelangt, und niemandkann sagen, welche Technologien und Schnittstellen inzwei oder gar in fünf Jahren aktuell sein werden.
Daraus ergibt sich unmittelbar die Konsequenz, Konzepteund Lösungen im Umfeld von Gerätebedienungen soweitwie möglich betriebssystemunabhängig zu gestalten.
2.5 Der Anwender
Die zur Bedienung der Geräte entwickelten Parametrierpro-gramme, die meist unter DOS oder Windows liefen, führtenbeim Anwender zu einer ungewollten Vielfalt an unter-schiedlichsten Bedienphilosophien, Oberflächen undFunktionen.
Die Richtlinie VDI/VDE 2187 sollte dabei helfen, durchdie Vereinheitlichung der Human Machine Interfaces (HMI)Ordnung in dieses Umfeld zu bringen. Aber längst nichtalle Toolhersteller richteten und richten sich danach [10].Außerdem konnte die Richtlinie aus grundsätzlichen Über-legungen heraus das HMI von Bedienwerkzeugen nicht bisins Detail beschreiben. Dem Hersteller mussten viele Frei-heiten eingeräumt werden. So findet der Anwender auchheute noch diese Situation vor: unterschiedlichste Tools,Bedienphilosophien und Oberflächen, teilweise sogar inein und demselben Tool.
Aus Sicht des Anwenders ist dies untragbar. Er forderteine einheitliche Bedienung seiner Geräte, z.B. wegen Re-duzierung der Ausbildungskosten, Fehlerminimierung, ein-heitl icher Dokumentation.
Die Anzahl der erforderlichen Ansprechpartner muss -aus den gleichen Gründen wie beim Leitsystemherstellergenannt - klein bleiben.
Ein weiterer Wunsch seitens der Anwender besteht na-türlich darin, laufzeitstabile Lösungen zu erhalten. DasRisiko, dass eine Gerätebedienung ein komplettesEngineeringsystem zum Absturz bringt, muss schon vomAnsatz her minimiert sein.
3. Gerätebeschreibung mit der EDDL
An einem konkreten Beispiel sollen hier dieErstellungsphasen und die Möglichkeiten einer EDD fürein PROFIBUS-DP-Gerät vorgestellt werden. Bei demGerät handelt es sich
Bild 2: Beispiel füreine Variablen-Deklaration mitEDDL
um ein SIMOCODE DP aus der Familie der Niederspan-nungsschaltgeräte. Im folgenden wird die methodischeVorgehensweise zur Erstellung einer EDD beschrieben.Die Voraussetzungen dafür sind ein Texteditor und eineEDD-Ablaufumgebung, in diesem Fall SIMATIC PDM.
Im allgemeinen ist eine Gerätebeschreibung mit EDDLwie folgt aufgebaut:1. Definition aller kommunizierbaren Gerätevariablen,2. Definition der Menüs, in denen die Gerätevariablen
nach funktionellen Gesichtspunkten gruppiert werden,3. Schreiben von Methoden zu Skalierungszwecken, Plau-
sibilisierungschecks,4. Adressierung der Gerätedatensätze.
3.1 Beispiel für die Erstellung einer EDD
Ein EDD-Entwickler hat den Auftrag erhalten, für dasSIMOCODE eine EDD zu erstellen. Der Entwickler kenntden Funktionsvorrat dieses Geräts nicht sehr gut, abersein Auftraggeber hat ihm das Handbuch und eineBeschreibung der Datensätze gegeben. Das sollte ihm fürdie Erstellung genügen. Im Anhang des Handbuchs findeter Listen mit Beschreibungen der unterschiedlichenDatensätze und in der Entwicklerdokumentation dieAbhängigkeiten der Gerätevariablen. Er beginnt nungemäß der oben genannten Auflistung mit der Deklarationder Gerätevariablen in EDDL (Bild 2).
Die Deklaration einer Variablen wird mit demSchlüsselwort VARIABLE eingeleitet, gefolgt von einembeliebigen Namen. Die Variable bekommt nun ein Label,mit dem der Name im HMI festgelegt wird. Zusätzlich kanndie Variable einen Hilfetext erhalten, der mit der rechtenMaustaste aufgerufen werden kann. In der EDD gibt eszwei Möglichkeiten, Texte zu hinterlegen. Zum einenkönnen die Texte direkt in der EDD hinterlegt werden, wasallerdings den Nachteil hat, dass bei langen Texten dieEDD unübersichtlich wird und die Texte nur für diesesGerät genutzt werden können. Zum anderen können dieTexte in einem sogenannten Dictionary hinterlegt werden.Dazu wird der Text mit einer in eckigen Klammernstehenden Referenz versehen, die im Dictionary wiedererscheinen muss. Dabei können unterschiedliche Geräteauf ein oder mehrere Dictionaries zugreifen, was einenhohen Grad an Wiederverwendung bestehenderDictionary-Einträge gewährleistet.
Unter CLASS wird die Variable klassifiziert. CONTAI-NED bedeutet hier, dass es sich um eine Gerätevariablehandelt.
Nun muss der Typ der Variablen festgelegt werden, wiezum Beispiel float, integer oder asci. In diesem Fall ist dieVariable vom Typ ENUMERATED, was einen Aufzählungs-typ kennzeichnet. Der Benutzer bekommt bei Auswahl derVariablen eine Liste mit den Texten Class 5, Class 10, ...aus der er die Triggerklasse auswählt.
Am Ende seiner Deklaration definiert der Entwicklerüber das Attribut HANDLING, ob die Variable Lese-,Schreib- oder beide Zugriffsrechte besitzt.
Im SIMOCODE-Handbuch findet der EDD-Programmie-rer bei der Variablen-Warngrenze die Angabe, dass derWert nur in 20-er-Schritten editiert werden darf. Deshalbmuss er eine Methode schreiben, die die Überwachungdieser Eingabe sicherstellt. Jeder beliebige Wert, den der
Benutzer eingibt, soll in 20er-Schritten auf- oderabgerundet werden.
Nebenbei hat der Entwickler festgestellt, dass es im Geräteine ganze Reihe von Variablen gibt, die nur in bestimmtenSchritten verändert werden dürfen. Er entschließt sich des-halb, eine Methode mit Variablenübergabe zu schreiben,die mehrfach anwendbar ist. Die Methodenaufrufe, diehinter dem Schlüsselwort POST-EDIT - ACTIONS stehen,werden unmittelbar nach dem Editieren der Variablenausgeführt. Dabei wird für die Syntax der Methode ANSI Cverwendet.
Bei der Variablendeklaration gibt der Entwickler mitMIN_VALUE und MAX_VALUE dieBereichsgrenzen für die Variableein. Damit wird sichergestellt,dass der Benutzer keine Werteeingeben kann, die außerhalb desWertebereichs liegen. Mit demSchlüsselwort CONSTANT_UNITist außerdem eine festeZuordnung der physikalischenEinheit der Variable möglich. DasSchlüsselwort UNIT gestattet demBediener eine variable Zuordnungder physikalischen Einheit, wobeidie automatischeEinheitenumrechnung vomBedienwerkzeug übernommenwird.
Nachdem der Entwickler alleVariablen deklariert und dafürSorge getragen hat, dass Be-reichsgrenzen und Skalierungenkorrekt definiert wurden, müssendie Abhängigkeiten der Variablenimplementiert werden. In der Ent-wicklerdokumentation finden sicheine ganze Reihe von Regeln, diefür den Plausibilitäts-Check benö-tigt werden.Eine Regel besagtbeispielsweise, dass bei derGerätevariante mit monostabilenAusgangsrelais die beidenVariablen "Verhalten bei AusfallSteuerspannung" und "Verhaltenbei Ausfall 3UF50-CPU" denZustand "AUS" besitzen müssen.
Dazu schreibt der Entwickler eineMethode, die wie im BeispielBild 3: Prinzipieller
Aufbau zum Aufrufeiner Methode fürdie Skalierung vonGerätevariablen
Bild 5: Darstellung der Variablen und Menüs in SIMATIC PDM
von Bild 3 mit einer POST_EDIT_ACTIONS bei der ent-sprechenden Variablendeklaration aufgerufen wird. Wirdgegen eine dieser Regeln verstoßen, bekommt der Benut-zer eine Meldung, die ihm die Abhängigkeit erklärt und, dieVariable wird auf den alten Wert zurückgesetzt.
Der Entwickler hat nun alle Variablen mit allenPlausibilitätsabfragen in der EDD implementiert. Alsnächstes werden die Gerätevariablen in Menüs gruppiert.Damit der Benutzer des bisher verwendetenParametrierwerkzeugs sich nicht umstellen muss, wurdevereinbart, dass die Anord-
Bild 6: Beispiel für einen Anwenderdialog
nung der Menüs in der gleichen Weise erfolgen soll. LautEDD-Spezifikation gibt es für den Einstieg zwei Möglich-keiten:• Table_Main_Maintenance• Table_Main_Specialist
Unter Table_Main_Maintenance erfolgt der Einsprung indie Bedienung für den Instandhalter und mitTable_Main_Specialist für den Spezialisten. Für daskonkrete Beispiel zeigt Bild 4, wie eine Menü-Hierarchieaufgebaut wird.
Nun ist der Entwickler unmittelbar in der Lage, das Er-gebnis seiner Gerätebeschreibung zu kompilieren und daserste Ergebnis in SIMATIC PDM zu testen. Ein Screenshotdieses ersten Entwicklungsstands ist in Bild 5 zu sehen.SIMATIC PDM interpretiert die EDD wie gezeigt, ein ande-res Tool könnte die EDDL in anderer Weise interpretieren.
Für jede Variable kann nun getestet werden, ob alleMethoden korrekt arbeiten und die Menüanordnung den
Bild 7: Beispiel für die grafische Darstellung vonMesswerten
Vorgaben entspricht. Diesen Entwicklungsstand liefert derEntwickler seinem Auftraggeber aus, damit dieser schonvorab die Bedienung testen kann.Im nächsten Schritt sollen nun die Benutzerdialogeumgesetzt werden. Die Syntax für den Menüaufbau istdieselbe wie für den Tabellenaufbau, außer dass dieEinsprünge folgendermaßen benannt werden müssen:• Table_Main_Maintenance• Table_Main_Specialist
Bei der Gestaltung der Menüs können unter ITEMSsogenannte• OnlineWindow, OfflineWindow• OnlineDialog, OfflineDialog
verwendet werden. Wird ein modales Fenster (sieheTabelle 1) geöffnet, so wird On(Off)lineDialog verwen-det, möchte man ein nicht modales Fenster, benutzt manOn(Off)lineWindow. Neben diesen Dialogen könnenunter ITEMS auch Methoden eingefügt werden. Wird eineMethode innerhalb eines Dialogfensters verwendet, wirdsie als Button interpretiert und bei Mausklick ausgeführt.Bild 6 zeigt einen nicht modalen Dialog, bei dem dieTestpunkte für die unterschiedlichen geräteinternenAusgänge gesetzt werden. Wird dabei der Button "RefreshOutputs" betätigt, wird der aktuelle Stand im Fensterdargestellt.
Neben Variablen und Methoden stehen dem EDD-Pro-grammierer noch grafische Elemente wie eineMesswertanzeige und ein Bargraph zur Verfügung. Auchhier gilt wiederum, dass von der EDD-Syntax nichtabgewichen wird. Lediglich bei der Namensgebung fürMENU werden einfache Konventionen vereinbart, die dannbeispielsweise zur Darstellung solcher Dialoge wie in Bild7 führen.
Es sei hier besonders darauf hingewiesen, dass ohneÄnderung oder Erweiterung der EDDL-Syntax neue grafi-sche Objekte hinzugefügt werden können, um so den spe-ziellen Kundenwünschen gerecht zu werden.Beispielsweise werden zukünftig auch die Darstellungvon Trendkurven,
Zeitverläufen und weiteren grafi-schen Objekten möglich sein.
Als nächstes füllt der Entwicklerdie Menüs Datei, Extras und Hilfe.Hier kopiert er aus schon bestehen-den Menüs den EDD-Code, damitsein Gerät in den Grundfunktionenein einheitliches Erscheinungsbildmit bereits integrierten Geräten be-sitzt. Die Methoden für Datei-Spei-chern oder Datei-Drucken sind so-genannte Standardmethoden, dienicht in der EDD implementiert wer-den müssen, da sie fester Bestand-teil des Werkzeugs sind. Die Ent-wicklung der grafischen Oberflächeist damit abgeschlossen.
Zum Schluss müssen die Vari-ablen adressiert werden. Bei demPROFIBUS-DP-Gerät erfolgt dasAdressieren über SLOT und INDEX.Der Compiler von SIMATIC PDMbietet darüber hinaus die Möglich-keit, auch die kommunikationsspezi-
fischen Teile der Gerätebeschrei-bung von PROFIBUS-PA- undHART-Geräten zu übersetzen.Nun ist das Feldgerät komplett mitEDD beschrieben. Die Einträge imDictionary nimmt der Auftraggeberselbst vor. Da für alle Texte Refe-renzen gesetzt wurden, muss ander EDD nichts mehr geändertwerden. Aus den Hilfetexten undLables des Dictionary wird eineWindows-Hilfedatei erzeugt, dieaus einem Tool wie SIMATIC PDMaufgerufen werden kann. Anhandder generierten Hilfedateien ist esmöglich, die Texte weiter zu modi-fizieren.
3.2 Resümee
Der zeitliche Aufwand für die Ent-wicklung der SIMOCODE-EDDbetrug insgesamt etwa acht Wo-chen. Darin enthalten war eineEinarbeitung in das Gerät und indie EDDL-Syntax. Stellt man hierden Aufwand für die Entwicklungdes ursprünglichen Parametrier-werkzeugs entgegen, so liegt das Einsparpotential in derGrößenordnung um den Faktor zehn. Die Gerätebeschrei-bung mit EDD bleibt von der permanenten Entwicklungneuer Technologien wie ActiveX unberührt, so dass zu-künftig keine weitere Einarbeitungszeit o.ä. anfällt.Dadurch wird dieses Einsparpotential auf Dauer nochgesteigert.
Die vorliegende Gerätebeschreibung ist in ihremAufbau klar und übersichtlich. Selbst für einen EDD-Anfänger wird es einfach sein, in diese Beschreibungbeispielsweise neue Variablen einzufügen oderÄnderungen an den Hilfetexten vorzunehmen. Für denGerätehersteller bedeutet dies, dass bei einer neuenGeräteversion nur die EDD und nicht dasParametrierwerkzeug geändert werden muss.
Abschließend sollen hier die Merkmale derentstandenen EDD zusammengefasst werden:
• Es werden alle Gerätevariablen in EDDL beschrieben.Dabei werden die Abhängigkeiten und Regeln für dieParametrierung durch EDDL oder C-Methoden imple-mentiert.
• Nach der Eingabe eines Parameterwerts werden sofortPlausibilitätsprüfungen durchgeführt und der Wert,wenn nötig, automatisch korrigiert. Somit sind Fehler inder Off-line-Parametrierung ausgeschlossen. Dabeistellt die EDDL-Syntax einfache Mechanismen zurVerfügung, wie zum Beispiel die Angabe derBereichsgrenzen bei der Variablendeklaration. Durchden Aufruf von Methoden, die in ANSI C erstellt werden,sind auch komplexere Abhängigkeiten beschreibbar.
• Die gesamten Anwendungsdialoge und Diagnosefunk-tionen werden dem bisherigen Parametrierwerkzeugnachempfunden.
Bild 8: Bei Änderung der Betriebssystemversion können sich auch die grauunterlegten Be reiche (Schnittstellen, Programme) ändern. Bei derGerätenbedienung mit der EDDL-MethoTechnologien oder Betriebssystemwechsel nicht berührt
• Die gesamten Datensätze können mit dem Parame-trierwerkzeug gelesen oder geschrieben werden. Dadiese Lese- und Schreibfunktionen inclusive derFehler-
behandlung vom Tool übernommen werden, müssensie nicht vom EDD-Entwickler programmiert werden.
• Vor jedem Schreibvorgang wird eineGeräteidentifikation durchgeführt, bei der spezielleParameter mit dem Off-line-Parametersatz verglichenwerden. Auf diese Weise werden Parametrierfehlervermieden.
4. Zusammenfassung
Einzellösungen und Einzelkomponenten zurParametrierung und Bedienung von Feldgeräten müssenheutzutage zu einem Gesamtsystem zusammengeführtwerden. Natürlich liegt der Gedanke nahe, das "Plug andPlay" von Microsoft auch in der Anlagenwelt zuverwirklichen.
Betrachtet man einen Windows-PC mit umfangreicherPeripherie wie Soundkarte, Bildschirm, Grafikkarte, Mouse,Joystick oder Drucker, so funktioniert das "Plug and Play"im allgemeinen recht zuverlässig. Man schließt das Gerätan und wird, falls nicht schon vorhanden, nach dementsprechenden Treiber gefragt. Ändert sich allerdings dieBetriebssystemversion, so ist das Funktionieren derGeräte schon nicht mehr sicher gewährleistet; man hatsich daran gewöhnt, in diesem Fall neue Treiber von denGeräteherstellern anzufordern.
Der wesentliche Unterschied zur Feldtechnik liegt darin,dass in einer Automatisierungsanlage die Zahlunterschiedlicher Geräte sehr viel höher ist als bei einem
PC. Bei einer Änderung der Betriebssystemversion odereiner Schnittstelle ist es zum einen dem Benutzer nichtzuzumuten, die Einzelkomponenten für die Bedienung undParametrierung seiner Geräte auszutauschen (Bild 8).Zum anderen muss der Gerätehersteller einenerheblichen Aufwand für die Aktualisierung seiner Softwaretreiben, wenn sein Gerät unterschiedlicheBetriebssysteme unterstützen soll.
Vorbild kann hier das Internet sein, bei dem eine Vielzahlunterschiedlichster Plattformen miteinander kommuni-zieren. Als in den 90er Jahren HTML geboren wurde, standman auch vor dem Problem, wie Dokumenteneigenschaf-ten, also zum Beispiel Textformate, beschrieben werdensollten, um auf unterschiedlichen Plattformen undBetriebssystemen auch noch in zehn oder mehr Jahrenlesbar zu sein.
Wie HTML noch heute eine Lösung für das formale Be-schreiben von Eigenschaften darstellt, nutzt auch die Elec-tronic Device Description diese Methodik. Das nach außensichtbare Verhalten des Feldgeräts findet man in der Ge-rätebeschreibung EDD wieder. Und ähnlich wie ein Brow-ser, extrahiert ein Tool (z.B. SIMATIC PDM) die jeweiligenGeräteressourcen und -funktionen.
Bleibt die Frage, wie solche Tools künftig in heterogeneEngineeringsysteme integriert werden können. Ein Ansatzwird zur Zeit im PNO-ZVEI-Arbeitskreis "Feldbus Enginee-ring" diskutiert. Hier wird eine Definition für Engineering-Schnittstellen erarbeitet, die eine Einbindung unterschied-lichster Planungs-, Inbetriebnahme-, Bedien- und Parame-trierwerkzeuge in ein Gesamtsystem erlauben.
Bei kritischer Betrachtungsweise stellt man allerdingsfest, dass auch Beschreibungssprachen wie HTML einerkontinuierlichen Weiterentwicklung aufgrund wachsenderAnsprüche unterliegen. Wie aber stellt man sicher, dassdie EDDL nicht einer ähnlichen Dynamik unterliegen wird?
Dem kann man entgegnen, dass die EDDL auf derHART- und ISP-Spezifikation aufsetzt und damit eine ge-wachsene, ausgereifte und verbreitete Methodik darstellt.Für besondere Funktionalitäten wie Diagnose- oderSimulationsmodi bieten die C-Methoden alleFreiheitsgrade einer Programmiersprache.
Inwieweit können die Anforderungen aus Abschnitt 2mit dem vorliegenden Konzept erfüllt werden? InterneUntersuchungen haben ergeben, dass sich das EDD-Konzept im Vergleich zu anderen Konzepten (z.B. demAusprogrammieren von Einzellösungen) mit denForderungen bei weitem am besten deckt.
Am Beispiel in Abschnitt 3 wurden die Möglichkeitender EDDL für einige Problemstellungen demonstriert.Dabei wurde bewusst kein Profilgerät verwendet, um dengesamten Weg einer EDD-Erstellung zu zeigen.
Beschreibt man dagegen ein Profilgerät, so kann manauf vorhandene Profil-EDDs zurückgreifen und diese alsBasis verwenden: optionale Teile des Profils, die im Gerätnicht realisiert sind, werden herausgelöst und durcheigene Geräteeigenschaften ersetzt. Somit wird mitWiederverwendung der Profil-EDDs eine Senkung derKosten erreicht.
EDDL ist auf dem Wege zu einem offenen Standard,der in der PNO durch die zunehmende Unterstützung derFeldgerätehersteller ein hohes Maß an Zukunfts- und In-vestitionssicherheit bietet.
Literatur[1] Bruns, H., Hempen U., Ott, W., und Vahldieck, R.: Ein
Konzept für eine COM/DCOM-basierte herstellerunabhängigeIntegration von Feldgeraten in Engineeringsysteme. atp -Automatisierungstechnische Praxis 41 (1999) H. 10, S. 34-40.
[2] Deutsches Institut für Normung e.V.: DIN V 19259.Datentypen mit Klassifiktionsschema für Messeinrichtungen
mit analogem und digitalem Ausgang für die industrielleProzessmesstechnik.
[3] Heidel, R., und Polzer, K.: Plug and Play auch in der atp -Automatisierungstechnik? AutomatisierungstechnischePraxis 40 (1998), H. S.
[4] ISP Foundation: InterOperableSystems TMProject. FieldbusSpecification. Device Description Language. (1993).
[5] NAMUR-Ernpfehlung NE 53: Software von Feldgeräten undsignalverarbeitenden Geräten mit Digitalelektronik.
[6] PNO-Arbeitskreis Gerätebeschreibung: Specification of PRO-FIBUS Electronic Device Description Language(Reviewphase). (1999).
[7] Polzer K..: Einheitliches Bedienen, Beobachten und Paramet-rieren von Prozessgeräten. atp -Automatisierungstechnische Praxis 40 (1998) - H. 3, S. 57-64.
[8] Schneider H.-J.: ACHEMA 94: Sensorsysteme und die Kom-munikation im Feld. atp - Automatisierungstechnische Praxis36 (1994) H. 9, S. 10-31.
[9] Stadter, W.: Device Description Language. atp - Automatisie-rungstechnische Praxis 34 (1992) H. 1, S. 21-27.
[10] Stieler, S.: Einheitliche Anzeige-Bedienoberfläche für digitaleFeldgeräte: Was tut sich bei Herstellern undFeldbusorganisationen? atp - AutomatisierungstechnischePraxis 40 (1998), H. 3, S. 65-66.
[11] VDI/VDE-Richtlinie 2187: Einheitliche Anzeige- und Bedien-oberfläche auf Personalcomputern für digitale Feldgeräte.Beuth Verlag, Berlin, Best.-Nr. 00926.
[[12] Waldschmidt H.: Eiriheitliche Anzeige-und Bedienoberflächeauf Personalcomputern für digitale Feldgeräte. atp -Automatisierungstechnische Praxis 36 (1994) H. 9, S. 32-38.
Dipl.-Ing. Martin Augustin ist bei der SiemensAG im Bereich A&D GT (Gemeinsame Technik) inKarlsruhe beschäftigt und ist unter anderemmaßgeblich an der Spezifikation der ElectronicDevice Description Language beteiligt.
Adresse: [email protected]
Dipl.-Ing. Kurt Polzer ist Leiter der Gruppe Sys-temintegration Feldgeräte des GeschäftsgebietsProzessautomatisierung und -instrumente (PA)im Bereich A&D der Siemens AG, Karlsruhe. Erist stellvertretender Leiter des GMA-Fachausschusses "Einheitliche Anzeige- undBedienoberflächen für Feldgeräte" sowie Gastim NAMUR AK 3.1.3 "Digitale Geräte inSchutzeinrichtungen".
Adresse: [email protected]
Dipl.-Ing. (FH) Wolfgang Ott ist verantwortlichfür die Spezifikation von Engineeringsystemenfür Prozessleitsysteme im Siemens-BereichEnergieerzeugung. Er ist Mitglied im ZVEI-AK-Feldbus-Engineering.
Adresse: [email protected]
