Jedem seine Sprache? #####
Fortsetzung des Artikels von Teil 2
Jedem seine Sprache?
XML – von Sprache zu Sprache unterschiedlich ausgeprägt
Die Vorteile und Möglichkeiten von XML, wie etwa eine einheitliche Basis- Syntax, einfache Darstellung von mehrsprachigen Informationen oder auch die aufwandsarme Software-Integration wurden bereits im ersten Teil der Artikelserie adressiert (Anm. d. Red.: siehe Computer&AUTOMATION 2007, H. 8, S. 22ff.). Diese fanden bei der Entwicklung von Gerätebeschreibungssprachen Berücksichtigung. Ergo existieren bereits heute – neben vielen proprietären XMLDialekten – eine Reihe von (quasi-)standardisierten XML-basierten Gerätebeschreibungssprachen wie GSDML oder FDCML. Andere Systeme, wie CANopen oder EDDL, werden derzeit mit unterschiedlichem Druck seitens der Anwender ganz oder als Subset in XML abgebildet.
Der Geräte-Entwickler mag diese Aktivitäten und ihre bisherigen Ergebnisse mit Wohlwollen und Befremdung gleichermaßen sehen – sind doch die einzelnen Sprachen nach wie vor strukturell und semantisch unterschiedlich! Angesichts der hohen Entwicklungsaufwendungen für ASCII-basierte Lösungen und für Werkzeuge sowie unter Berücksichtigung der Migrationsthematik ist auch kaum zu erwarten, dass sich die XML-basierten Sprachen der verschiedenen Systeme plötzlich vereinheitlichen lassen. Nichtsdestotrotz gilt das Gerätemodell nach ISO 15745 bei der Definition XML-basierter Gerätebeschreibungssprachen als Konsens beziehungsweise als grundlegender Rahmen. So sind zum Beispiel die GSDML, die XML-basierte CANopen- Beschreibung und FDCML auf dieser allgemeinen Ebene semantisch gleich – die konkrete Ausprägung in XML ist jedoch unterschiedlich.
Am Beispiel des Elements „Device-Identity“ lassen sich die erheblichen Unterschiede in der Syntax aufzeigen. Während GSDML hier lediglich den Herstellernamen und einen weiteren, das Gerät näher beschreibenden Text vorsieht, entsprechen die Strukturen für FDCML und für CANopen weitgehend den in der ISO 15745 definierten Inhalten. Allerdings sind auch hier Unterschiede hinsichtlich der Kardinalität, also der Anzahl des Auftretens der Elemente sowie Erweiterungen zu erkennen. Ein Gerätehersteller muss also nicht nur wissen, welche Inhalte er diesen Elementen zuordnet, sondern auch welche Elemente in den verschiedenen Sprachen die gleiche Semantik besitzen. So transportiert das Unterelement „InfoText“ in GSDML die gleichen Inhalte wie die Elemente „productText“ in FDCML und bei CANopen. Ein weiteres Beispiel: Die Zuordnung des Gerätes zu einer – herstellerspezifisch definierten! – Produktfamilie erfolgt bei FDCML und bei CANopen mittels des Elementes „deviceFamily“, während diese Information bei GSDML im Element „Family“ unter DeviceFunction abgelegt wird.
Während beim Thema „DeviceIdentity“ zumindest eine grundsätzliche Übereinstimmung erkennbar ist, gibt es hinsichtlich der Semantik des Gerätemodells nach ISO 15745 aber auch vollständig unterschiedliche Auffassungen – siehe zum Beispiel das Element „ApplicationProcess“ bei GSDML. Dieses enthält die eigentlichen Informationen zur Gerätestruktur (Module), zur Kommunikationsschnittstelle, zu den Prozessdaten (E/ADaten) und den Anlaufparametern sowie unterstützende Informationen (Texte, Grafikdateien), während die eigentlichen Geräteparameter nicht beschrieben sind. Bei CANopen erscheinen die Geräteparameter in Form von Parameterlisten im ApplicationProcess- Element. Bei FDCML hingegen ist hier lediglich ein Einhängpunkt für ein externes Schema definiert. Die eigentlichen Parameter liegen wie die Prozessdaten unterhalb des „communicationEntity“ am „DeviceManager“.
- Jedem seine Sprache? #####
- Jedem seine Sprache?
- Jedem seine Sprache?
- Jedem seine Sprache?
