Preiswertere Software durch Trennung von Konfiguration und Applikation
Universelle Geräteintegration und konfiguration
Fortsetzung des Artikels von Teil 2
Universelle Geräteintegration und konfiguration
Companion Standards sind beim ASAM GDI vordefinierte virtuelle Geräte aus der Sicht einer bestimmten Anwendung. Hier wird eine komplette DCD definiert; damit liegt ein Pflichtenheft für eine Standard-Gerätesicht vor. Hersteller können dafür Gerätetreiber schreiben. Die Gerätefähigkeitsbeschreibung kann vom ASAM-Server heruntergeladen werden, sobald ein Companion-Standard vom Technical Advisory Board (TAB) des ASAM freigegeben wurde. Derzeit sind drei Companion-Standards verfügbar:
- Crash-Versuche,
- Rollenprüfstände,
- Vielfach-Messstellengeräte
Jobangebote+ passend zum Thema
In Arbeit ist aktuell eine universelle Ankopplung an die im ASAM AE standardisierte Schnittstelle MCD3 zur Anbindung von Kfz-Steuergeräten. An dieser Stelle werden Synergieeffekte der ASAM-Standards deutlich, denn eine inhaltliche Festlegung zu den virtuellen Geräten ist beim GDI nicht mehr erforderlich. Das Objektmodell des MCD3 wird so, wie es im ASAM AE spezifiziert wurde, in ein virtuelles Gerät des GDI gekapselt. Dieser Companion-Standard beschreibt also lediglich eine bestimmte Methode, die sich neutral zu weiteren möglichen zukünftigen Entwicklungen beim MCD3-Standard verhält.
Daneben werden aber auch von Anwendern Companion-Standards definiert, die nicht oder noch nicht über ASAM laufen und schnellstmöglich einen konkreten Standardisierungsbedarf decken. Ein Beispiel dafür sind die umfangreichen Aktivitäten bei Volkswagen, wo der ASAM GDI inzwischen auch in der Produktion eingesetzt wird (Bild 4).
Die konkrete Implementierung des ASAM GDI an der Fertigungslinie hat Besonderheiten aufgezeigt, die sicher auch an anderer Stelle der Automobilproduktion noch in Erscheinung treten werden. Es wird deutlich, dass die fortschreitende Entwicklung der Steuergeräte und die Aufrüstung der Sensorik in den Kraftfahrzeugen zu einer Rückkopplung zum Produktionsprozess führen und damit höhere Anforderungen an die Flexibilität der Produktionsautomatisierung stellen. Dies wurde bei VW in einer GDI-Pilotimplementierung für Befüllprozesse besonders deutlich. Nach Meinung des Autors wird diese Neugestaltung von Prozessen mit Rückkopplung über die OBD-Schnittstelle (On-Board-Diagnose) zu flexibleren Automatisierungssystemen und einer Reduktion der Produktionszeiten führen. Wenn sich jetzt noch weitere Spareffekte durch modularisierte Gerätetreiber ergeben, hat sich für VW der Einsatz des Standards schnell bezahlt gemacht.
Koordinator und Konfigurationsdatei
Der Koordinator stellt die Schnittstelle zur eigentlichen Anwendung dar und soll diese von systematischen und allgemein formulierbaren Aufgaben entlasten. Dazu gehören die Entkopplung von der Gerätesicht und die Konfiguration der Anlage. Man kann die aktive Funktion des Koordinators zusammen mit der Konfigurationsdatei (Parameter Instance Description, PID) in etwa mit dem Hochfahr-Vorgang eines modernen Computer-Betriebssystems vergleichen. Die benötigten Treiber werden geladen und die angeschlossenen Geräte werden im Sinne der geplanten Anwendung initialisiert. Die eigentliche Anwendung wird erst dann aktiv, wenn alle von ihr benötigten Ressourcen bereitgestellt und parametriert sind.
Mit diesem Vorgehen gelingt ein weiterer entscheidender Schritt der Modularisierung, denn bislang hatten Anwendungsprogramme immer beide Aufgaben zu erfüllen, nämlich die Inbetriebnahme der Gerätschaften und die eigentliche Nutzung. Es ist naheliegend, dass auf dem Weg über den Konfigurator auch noch Diagnose und Wartung der Ressourcen in eigene Anwendungsprogramme ausgelagert werden können.
Wie erfährt aber der Koordinator, welche Ressourcen eine Anwendung benötigt und wie diese zu parametrieren sind? Hier wird die Konfigurationsdatei wirksam, denn zu ihrer Erstellung werden neben den DCDs auch noch Eingaben durch den Projektierer der Anwendung herangezogen (Bild 5).
Offline-Konfiguration
Das Konzept des GDI, für die Konfiguration ein Dateiformat zu definieren und dem Konfigurator als Interpreter dieser Datei den Hochlauf einer Anlage zu ermöglichen, legt die Offline-Konfiguration nahe. Also eine eigenständige Applikation, mit der eine Anwendung projektiert und alle dafür notwendigen Ressourcen beschrieben werden.
Um hier den Anschluss an die immer mehr in den Vordergrund tretenden Web-Technologien zu erreichen, wurde für die Konfigurationsdatei XML als Format gewählt. Als Vorlage für die Konfigurationsdatei dienen aufbereitete Gerätefähigkeitsbeschreibungen im Format XML-Schema. Dieses Format wurde gewählt, um ähnliche Beschreibungsmöglichkeiten zu bekommen, wie sie das ursprüngliche DCD-Format des ASAM GDI mit einer an CORBA-IDL angelehnten Syntax hat. Zwar wäre das grundsätzlich auch mit einem eigenen XML-Dialekt machbar gewesen, dennoch verspricht der Einsatz von XML-Schema den Vorteil, Standard-XML-Werkzeuge für die Erstellung bzw. Bedienung der Konfigurationsdatei heranzuziehen (siehe Kasten S. 50).
Für den Einsatz von XML-Schema zur Gerätebeschreibung spricht auch noch das grundsätzliche Klassenmodell des GDI, bei dem in der DCD die Klassen virtueller Geräte beschrieben werden und deren Instanziierung über die Kommunikation mit dem Gerätetreiber erfolgt. Die Konfigurationsdatei enthält entsprechend alle diese Instanzen. Ein ähnliches Bild wird auch allgemein beim Einsatz von XML und XML-Schema gezeichnet. XML-Schema wird als Klassenbeschreibung geführt und die damit erstellten XML-Dateien sind die Instanzen.
- Universelle Geräteintegration und konfiguration
- Universelle Geräteintegration und konfiguration
- Universelle Geräteintegration und konfiguration
- Universelle Geräteintegration und konfiguration
