XML – Hype oder Segen?

XML – ein „moving target“

Zu den Problemen, die allein durch eine Anwendung von XML nicht gelöst oder durch immanente Freiheitsgrade gar verschärft werden, gehören fehlende Einschränkungen in der Dokumentstruktur, fehlende Einschränkungen bei der Definition von Schemata sowie das Fehlen eines allgemeingültigen Modells im Automatisierungskontext. Zudem ist XML immer noch ein „moving target“. Das heißt: Es entstehen stetig neue Technologien und Spezifikationen, die hinsichtlich ihrer Nutzung im Automationsumfeld zu überprüfen sind. Basierend auf verschiedenen Einsatzszenarien wurden Anforderungen zusammengestellt, die für den effektiven, auf Wiederverwendung und Allgemeingültigkeit ausgelegten Einsatz von XML im Automatisierungsumfeld relevant sind. Dazu gehören:

• Allgemeingültiges, flexibles Inhaltsmodell;
• Objekt-bezogene Beschreibung;
• Versionierung von Schemata, Dokumenten und Inhalt;
• Applikationsspezifische Identifikation von Inhalt;
• Unterstützung von Mehrsprachigkeit;
• Vermeidung von Namenskonflikten;
• Erweiterbarkeit;
• Referenzmechanismen für Inhalt und Hierarchien;
• Referenzen zu externen Inhalten;
• Aufteilung auf mehrere Dokumente;
• Export von Informationen mit offenen Referenzen;
• Time-Stamp-Mechanismen auf verschiedenen Ebenen;
• Datenkompression von Dokumenten oder Inhalt;
• Verschlüsselung von Dokumenten oder Inhalt.

Neben den Anforderungen an das Modell selbst sind Aspekte der Wiederverwendbarkeit und des Workflow bei der Erstellung von XML-Beschreibungen zu beachten. Die Einführung von objektorientierten Konzepten wie Vererbung und Re-Definition in XML-Schema erlaubt die Entwicklung hierarchischer Schemata, die in Verbindung mit Versions- und Namespace-Regelungen sowie einer zugehörigen Infrastruktur geeignet sind, die oben erwähnten Probleme heterogener oder inkompatibler XML-Dokumente zu lösen oder zumindest zu entschärfen.

Eine wesentliche Voraussetzung hierfür ist ein einheitlicher Modellierungsansatz, der eine eindeutige Identifikation von Beschreibungselementen und eindeutige Referenzmechanismen beinhaltet. Die Offenheit eines solchen Ansatzes lässt sich durch Erweiterungsmöglichkeiten gemäß der W3C-Konzepte erreichen, durch die eigene Schemata in bestehende Definitionen eingehängt werden können, und somit die spezifische Nutzung auch von Teilen der XML-Dokumente in den Konsumenten erlauben.

Über die Entwicklung von domänenspezifischen Schemata ist eine gezielte Vereinheitlichung von Semantik in einem Umfeld erreichbar, wo dies sonst ohne erhebliche technische und zeitliche Aufwendungen kaum zu bewerkstelligen ist. So sind etwa einheitliche Identifikationsfunktionen für Geräte mit einer festgelegten Semantik wesentlich, um ein Gerät in seinem Lebenszyklus als Informationsquelle nutzen zu können. Auch wenn diese Domänen zunächst „klein“ erscheinen mögen, ist dieser Schritt dennoch sinnvoll – führt er doch als stetiger Prozess zu Bausteinen eines Gebäudes, in dem XMLDokumente mit einer deutlich höheren Qualität als ASCII-Text in spitzen Klammern austauschbar sind.

Wie bereits angedeutet, bestimmt das Spezifikum des jeweiligen Kontextes die auszutauschenden Inhalte und natürlich die Anforderungen, die an die Beschreibung gestellt werden. Daher ist es naheliegend, zunächst die typischen Einsatz-Szenarien im Automatisierungsumfeld zu skizzieren. Diese unterscheiden sich je nach „Anwender“-Klientel:

Gerätehersteller:
Der Gerätehersteller entwickelt ein Gerät. Dazu erarbeitet er Anforderungen und Spezifikationen aus der funktionalen und marktpolitischen Zielsetzung, definiert die Gerätestruktur und die Parameter und erstellt die Produktionsunterlagen. Auf dieser Basis produziert er das Gerät, erzeugt Informationen über das Gerät, vertreibt es und stellt Serviceleistungen bereit. An vielen Stellen dieses komplexen Prozesses erzeugt oder referenziert er Beschreibungen, insbesondere solche auf Basis von XML. Ergo muss der Gerätehersteller über seine Kernkompetenzen hinaus intensive Kenntnisse etwa der XML-basierten Gerätebeschreibungssprachen besitzen.

Systemintegrator:
Die Rolle des Systemintegrators adressiert umfangreiche Aufgaben, die im Life-Cycle zwischen Planung und Betrieb einzuordnen sind. Basierend auf den Planungsschritten ist der Applikations- und Funktionsentwurf durchzuführen, sind Geräte zu beschaffen, die Systemtopologie zu definieren und Anwendungsprogramme zu erstellen. Anschließend gilt es, die entstandenen Detail-Informationen in die Systemkomponenten zu integrieren (Konfigurierung, Implementierung). Daran schließt sich die schrittweise Inbetriebnahme des Gesamtsystems an, gefolgt von der Dokumentation des Ist-Zustands und einer eventuellen Anbindung an MES/ERP-Systeme. Bei den genannten Aufgaben sieht sich der Systemintegrator mit vielen unterschiedlichen XML-basierten Sprachen konfrontiert. So lassen sich funktionale Beschaffungsunterlagen aus den Planungsdokumenten gewinnen und die Parameter von Geräten aus Gerätebeschreibungen können in die Programmierung der Steuerungen integriert werden, ebenso in Visualisierungen und in ERP-Anwendungen. Auch hierbei wird die Komplexität der Aufgaben durch inkompatible XML-Formate und durch das Fehlen von geeigneten, semantisch begründeten Verknüpfungen zwischen den Sprachen erschwert.

Instandhalter:
Auch für Instandhaltungsaufgaben ist eine komplexe Verknüpfung von heterogenen Informationen erforderlich, die in früheren Phasen des Lebenszyklus entstehen. In gleicher Weise wie beim Szenario des Systemintegrators sind Funktionszuordnungen, Parameter, Planungs- und Bestellunterlagen und Gerätedokumentationen, aber auch Informationen über aktuelle Produktionsaufträge so aufzubereiten, dass der Instandhalter bestmöglich unterstützt wird. Durchgehende Lösungen sind auch hier nicht zu finden.

1. XML – Hype oder Segen?
2. Das „Wiki der Automation“
3. Die wichtigen Sprachen
4. XML – ein „moving target“