Quelltext betrachten

<div style="margin-bottom: 2px; border: 1px solid #808080;">
&nbsp;&nbsp; 
[[Main|English]] &nbsp;&nbsp;
[[Principal|Français]] &nbsp;&nbsp;
[[Hauptseite/jp|Japanisch]] &nbsp;&nbsp;
[[Hauptseite/cn|Chinesisch]] &nbsp;&nbsp;
[[Главная страница|Русский]] &nbsp;&nbsp;
[[Strona główna|Polski]] &nbsp;&nbsp;
</div> 
{{TOCright}}Dieses Wiki informiert über den Standard ASAM GDI (Generic Device Interface = Allgemeine Geräteschnittstelle), der von Vertretern der Automobilindustrie und ihren Zulieferern entwickelt wurde und vom [http://www.asam.net ASAM e.V.] gepflegt wird (''[http://de.wikipedia.org/wiki/ASAM_(Automobilbau) Wikipedia]''). [[Seitenbaum|''' [ Gesamtübersicht ]''']]
== Standard zur Integration von Geräten ==

[[Bild:GdiComponents.png|left]]
Der Standard beschreibt die vereinheitlichte Integration von Anlagen und Geräten in computergestützte Anwendungen auf Treiberebene, wie dies heutzutage z.B. für Drucker und standardisierte USB-Geräte am PC üblich ist.

Das '''Ziel dieses Standards''' ist es, dem Anwender die Integration von Geräten in seine Programme zu erleichtern und dabei unabhängig vom Gerätehersteller und von zukünftigen Geräteentwicklungen zu werden. Die optimale Bedienung des Gerätes kann über [[Gerätetreiber]] vom Hersteller vorgenommen werden, was eine entsprechend '''hohe Qualität''' erwarten lässt. Die Mehrfachverwendung der Gerätetreiber in möglichst vielen Anwendungen führt zur '''Kostenreduktion'''.

Bei der Entwicklung des Standards wurde besonders auf die Unabhängigkeit vom Betriebssystem des Computers und seiner Peripherieschnittstellen geachtet. Es wurde ein objektorientierter Ansatz gewählt und keinerlei Einschränkung bezüglich der Komplexität von Geräten vorgenommen. Damit ist der GDI Standard technologieunabhängig und kann auch für zukünftig entwickelte Geräte und Kommunikationssysteme eingesetzt werden.

== Anwendungen des Standards ==

Für die Anwendung des Standards können folgende Hauptbereiche dargestellt werden, die sich im Wesentlichen in den Gerätefähigkeitsbeschreibungen wiederfinden und über sog. [[virtuelle Geräte]] modelliert werden:

=== Fähigkeiten aus Gerätesicht ===

Dies ist die Sicht des Geräteherstellers, dem besonders daran gelegen ist, dass sein Gerät in möglichst vielen Anwendungsbereichen eingesetzt werden kann. Er wird also alle Gerätedetails beschreiben und über den [[Gerätetreiber]] dem Anwender zugänglich machen.
Ein gutes Beispiel für diese Art der Anwendung ist das [[LAPI-Projekt]].

=== Fähigkeiten aus Anwendersicht ===

Bei diesem Ansatz wird ein großer Teil der Entwicklungsarbeiten für die Geräteintegration an den Gerätehersteller übertragen. Der Anwender erstellt die Gerätefähigkeitsbeschreibung (ggf. Teile davon) aus seiner Sicht und der Gerätehersteller muss im Gerätetreiber die gewünschte Sicht auf das Gerät realisieren. Für allgemein übliche Anwendungsszenarien werden hierfür sog. [[GDI-Begleitstandards]] definiert. 
Ein gutes Beispiel für diese Art der Anwendung ist der Einsatz des GDI in der [[Volkswagen-Produktion]].

=== Universell anwendbare Sichten ===

Im Übergang von einer reinen Anwendungssicht zu einer reinen Gerätesicht sind weitere Ebenen für universeller geeignete Sichten möglich. Ein Beispiel ist das [[geräteunabhängiges Profil|geräteunabhängige Profil]] für messtechnische Anwendungen, das es dem Hersteller universell einsetzbarerer Automatisierungssysteme ermöglicht, denselben Integrationsansatz für unterschiedlichste Geräte zu verwenden.

=== Fähigkeiten ohne Geräteanschluss (Intelligenzausgleich) ===

Es ist auch vorgesehen, dass in einem Gerätetreiber zusätzliche Programme enthalten sind, die Fähigkeiten präsentieren, die nicht vom Gerät selbst zur Verfügung gestellt werden. Werden dadurch die Fähigkeiten eines einfachen Gerätes ergänzt, spricht man von einem Intelligenzausgleich. Der Ansatz über [[virtuelle Geräte]] beinhaltet diese Anwendung. So können auch Gerätetreiber existieren, die kein physikalisches Gerät unterstützen sondern Funktionsobjekte zur Datenverarbeitung (Formeln, Messverfahren, etc.) zur Verfügung stellen.

== Komponenten des Standards ==
Es wurden mehrere Komponenten (Treiberschnittstellen und Datenbeschreibungen) entwickelt, die zum Teil voneinander unabhängig gestaltet und gepflegt werden können. Das erleichtert die Erstellung wiederverwendbarer Software-Module bei Spezialisierung auf abgeschlossene Bereiche. Auf diesem Weg gelingt eine '''Kostenreduktion''' bei gleichzeitiger '''Qualitätsverbesserung''' durch den Einsatz des Standards.
=== [[Plattformadapter]] und [[PA-Erweiterung]] ===
Der Plattformadapter ermöglicht es, Gerätetreiber zu entwickeln, die für beliebige Computer-Betriebssysteme (Windows<sup>&reg;</sup>, LINUX, etc.) einsetzbar sind. Die Kommunikationsschnittstellen (WAN, LAN, USB, RS232, etc.) werden über sog. PA-Erweiterungen modular integriert, was eine weitere Spezialisierung und Entkopplung bei der Treiberentwicklung erlaubt.

Ein Plattformadapter wird gezielt für ein bestimmtes Betriebssystem entwickelt, eine PA-Extension für eine bestimmte darüber bediente Geräteschnittstelle. Es sind darin in der Regel keine sonstigen gerätespezifischen Programmteile enthalten.

=== [[Gerätetreiber]] ===
Im Gerätetreiber sind die gerätespezifischen Programmteile enthalten. Dazu gehören die Geräteverwaltung und die gerätespezifische Kommunikation (Aufruf standardisierter Protokolle in einer PA-Erweiterung oder komplette Behandlung des gerätespezifischen Protokolls). Die grundsätzliche Struktur eines sog. virtuellen Gerätes ist als Ansammlung von [http://de.wikipedia.org/wiki/Klasse_(objektorientierte_Programmierung) Klassen] festgelegt. Deren Attribute und Methoden werden über die Schnittstelle des Gerätetreibers genutzt. Dabei kann beim Datenaustausch der Attributinhalte (Lesen und Schreiben) die Aktivität auch vom Gerätetreiber (bzw. vom Gerät) ausgehen.
=== [[Gerätefähigkeitsbeschreibung]] (DCD) ===
Die in einem Gerät über den Geräteteiber nutzbaren Objekte werden in der Gerätefähigkeitsbeschreibung (DCD = Device Capability Description) dargestellt.
=== [[Koordinator]] ===
Die grundsätzliche Aufgabe des Koordinators ist, die Anwendung von der Gerätesicht zu befreien. Über den Koordinator wird der Zugriff auf die Gerätefähigkeiten über namentlich identifizierte Attribute (meist Prozessgrößen) und Methoden (meist Teilprozesse) ermöglicht. Die Namenszuordnung erfolgt durch eine Konfiguration des Koordinators und kann mit einem darauf zugeschnittenen Anwendungsprogramm erfolgen. Auf diese Weise wird die eigentliche Anwendung entlastet und kann ohne Änderung für unterschiedliche Geräte und Anlagen verwendet werden.

=== [[Konfigurationsbeschreibung]] (PID) ===
Über die Konfigurationsbeschreibung (PID = Parameter Instance Description) wird der Koordinator mit allen Daten versorgt, die für den Einsatz der ausgewählten Geräte mit einem bestimmten Anwendungsprogramm erforderlich sind. Dazu gehören neben den Daten zum Initialisieren der Gerätetreiber (und Geräte) auch die Anwendungsnamen der Objekte und ihre Zuordnung zu den Gerätefähigkeiten.

== Kooperation mit anderen Standards ==
Das Problem der Geräteintegration ist seit langem bekannt und wird immer wieder als Standardisierungsproblem unter verschiedenen Gesichtspunkten angegangen. Während früher die Lösung bei den sog. Feldbussen gesehen wurde, orientiert man sich heute, wie beim ASAM GDI deutlich wird, mehr am Problem der Integration in die IT-Landschaft ([http://www.process.vogel.de/msr_automatisierung/kommunikation/bus_systeme/articles/155528/ PROCESS-Roundtable-Gespräch: Quo vadis Feldbus?]).
=== Feldbussysteme ===
Eines der größten Normvorhaben der letzten Jahrzehnte waren die Festlegungen zu den physikalischen Geräteschnittstellen unter dem Thema [http://de.wikipedia.org/wiki/Feldbus Feldbus]. Da dies meist technologiegebundene Festlegungen in einem weiten Anforderungsspektrum sind, konnte sich kein tatsächlicher Standard durchsetzen. Zur Zeit sind sehr viele unterschiedliche Feldbussysteme in einem internationalen Standard IEC 61158 ("Digital data communication for measurement and control - Fieldbus for use in industrial control systems") verwaltet. 

Mit weiteren technologischen Fortschritten ist also auch mit neuen Feldbussen zu rechnen, die in der Regel von unten nach oben, also von ihren spezifischen Kommunikationseigenschaften ausgehend bis zur Gerätefähigkeitenbeschreibung spezifiziert werden. 

==== Einsatz der GDI [[PA-Erweiterung]] ====
Zur Entkopplung von der technologischen Fortentwicklung mit beliebigen neuen Feldbustechnologien kann der GDI Standard mit seinem Plattformadapter-Konzept besonders effizient eingesetzt werden. Indem die feldbusspezifischen Festlegungen (Schichten 1, 2 und 7 des [http://de.wikipedia.org/wiki/OSI-Modell OSI Modells]) vollständig in eine PA-Erweiterung integriert werden und im Gerätetreiber ein möglichst universeller Zugang geschaffen wird. Mit dem Einbau eines neuen Feldbussystems in ein Gerät kann der Hersteller einfach eine entsprechende PA-Erweiterung zur Verfügung stellen (wenn sie nicht schon am Markt verfügbar ist) und erspart damit dem Anwender jegliche Anpassungsarbeiten.

=== OPC/UA ===
Man könnte den OPC Client mit seiner Schnittstelle zum Anwendungsprogramm als Konkurrenz zum GDI [[Gerätetreiber]] sehen. Dies betrifft aber nur die Integration von OPC Servern. 
Der wesentlichen Unterschied liegt im Gesamtkonzept.

OPC legt das gesamte Kommunikationssystem fest und macht deren Parameter (nach Bedarf) zugänglich. Es werden auch Ansprüche an Funktionalität und Qualität gestellt ([http://de.wikipedia.org/wiki/OPC_Unified_Architecture wikipedia]).

GDI dagegen ist für beliebige Kommunikationssysteme einsetzbar und versteckt diese auch vor der Anwendung. Über eventuelle Zugangsmöglichkeiten entscheidet der Geräteanbieter mit entsprechend definierten Anwendungsobjekten. 

Aus Anwendersicht bietet sich für den GDI eine enge [[Kooperation mit OPC/UA]] an.

=== ORiN/RAPI ===
Einen ähnlichen Ansatz wie GDI hat die [http://de.wikipedia.org/wiki/Japan_Robot_Association Japan Robot Association] mit ihrem Robot/Resource API gewählt. Im Rahmen der internationalen Standardisierung bot sich eine enge Zusammenarbeit in ISO 20242 an, da der GDI hier in der internationalen Standardisierung schon vergleichsweise weit fortgeschritten ist ([[Kooperation mit ORiN]]).