Preiswertere Software durch Trennung von Konfiguration und Applikation
Universelle Geräteintegration und konfiguration
Fortsetzung des Artikels von Teil 3
Universelle Geräteintegration und konfiguration
Der Plattformadapter (PA) und die Plattformadapter-Erweiterung sind die Basismodule, um vom Betriebssystem und den damit verwalteten Kommunikationsschnittstellen unabhängig zu werden. Der Plattformadapter ist für jedes unterschiedliche Betriebssystem und die Erweiterung für bestimmte Typen von Kommunikationsschnittstellen zu entwickeln. Derzeit stehen am Markt Plattformadapter für Linux und Windows zur Verfügung und PA-Erweiterungen für RS 232, Ethernet-TCP/IP, USB und CAN. Hier wird der Vorteil der Spezialisierung sofort deutlich, denn es ist naheliegend, einen Plattformadapter von einem Experten für das betreffende Betriebssystem ausführen zu lassen.
Betrachten wir dazu einmal die möglicherweise anstehende Anpassung an die neue Windows-Variante Vista und denken daran, dass damit auch wieder neue Treiberkonzepte zu berücksichtigen wären. Die Portierung einer ASAM-GDI-Umgebung von einer älteren Windows-Variante auf die neue würde sich hier auf die Anpassung des Plattformadapters beziehungsweise der PA-Extension beschränken und könnte vom Vista-Spezialisten vorgenommen werden. Alle anderen Komponenten des GDI-Standards bleiben davon unberührt. Ähnliches gilt natürlich auch, wenn ein ganz anderes Betriebssystem zum Einsatz kommt, beispielsweise für Echtzeit-Anwendungen in abgesetzten Systemen. Auch hier wird man den Spezialisten für dieses Betriebssystem mit der Anpassung des Plattformadapters betrauen und erreicht damit eine hohe Qualität in der Softwareentwicklung.
Deutlich wird hieran auch die Kostenersparnis durch die Modularität des GDI-Standards, denn die Umstellung von einem Betriebssystem auf das andere beschränkt sich in der Entwicklung auf die Anpassung des Plattformadapters.
Plattformadapter sind universell einsetzbare Softwareprodukte und für ein Betriebssystem ausgelegt; die Anzahl verschiedener Arten ist überschaubar. Nicht jedoch die Anzahl unterschiedlicher Lieferanten, denn die Festlegung der Schnittstelle zum Gerätetreiber ermöglicht es jedem Betriebssystemspezialisten, ein solches Produkt zu entwickeln und anzubieten. Die PA-Erweiterungen sind für ein bestimmtes Betriebs- und Kommunikationssystem ausgelegt. Sie werden bei Bedarf vom Plattformadapter geladen. In der Regel enthält der Gerätetreiber die entsprechenden Informationen für sein Gerät und stößt das Laden der Erweiterung bei der Initialisierung an. Man beachte, dass auch das zum Konfigurationsvorgang gehört, der weiter unten noch erläutert wird.
Jobangebote+ passend zum Thema
Gerätetreiber und Gerätefähigkeitsbeschreibung
Der Gerätetreiber und die Gerätefähigkeitsbeschreibung (Device Capability Description, DCD) werden vom Gerätelieferanten erstellt. Auch hier sorgt die Spezialisierung wieder für entsprechende Qualität, denn das größte Know-how über Eigenschaften und Fähigkeiten eines Gerätes ist beim Hersteller zu erwarten. Der Programmierer des Gerätetreibers muss lediglich die nach oben zum Koordinator vorgegeben Schnittstelle einhalten und kann für die Kommunikation mit seinen Geräten auf die Dienste eines Plattformadapters und der passenden PA-Erweiterung zugreifen. Wie das Gerät dann aus Sicht der Anwendung zu bedienen ist, welche Fähigkeiten es anbietet und wie diese genutzt werden, wird in einer DCD hinterlegt, nach ebenfalls standardisiertem Format. Hier werden virtuelle Geräte (Virtual Device, VD) verwaltet.
Es ist allerdings zu beachten, dass in der Anwendung dieses Konzeptes zwei verschiedene Sichten auf Geräte existieren können. Einmal die Sicht aus der Applikation auf ein optimal geeignetes, zugeschnittenes Gerät und die Sicht auf das Gerät selbst, das der Gerätehersteller möglicherweise mit einer anderen Vorstellung der Applikation oder gegebenenfalls sogar für einen ganz anderen Anwendungsfall konzipiert hat. Der GDI-Standard soll hier auch die Anpassung ermöglichen, also über die Konfiguration nur eine bestimmte Sicht auf ein Gerät zu aktivieren oder diese durch die Kombination verschiedener Geräte darzustellen. Die Zuordnung von virtuellen Geräten zu den physikalischen Geräten ist deshalb von weiteren Randbedingungen abhängig (Bild 3).
Der einfachste Fall ist die 1:1-Zuordnung von virtuellem zu physikalischem Gerät. Hierbei ist anzumerken, dass die Gerätebeschreibungen in der DCD Klassenbeschreibungen sind, das heißt, es wird immer nur ein Gerätetyp dargestellt, unabhängig davon, wie viele Geräte dieser Art tatsächlich angeschlossen sind.
Mit der N:1-Zuordnung bietet sich die Möglichkeit, ein Gerät mit mehreren Facetten anzubieten oder eine ganze Gerätegruppe über eine Kommunikationsschnittstelle zu verwalten. Dieser Fall tritt auch dann auf, wenn ein Gerät mehrere entkoppelte Funktionsgruppen aufweist, die unabhängig voneinander verschiedene Zustände annehmen können.
Die 1:N-Zuordnung schließlich erlaubt es, anspruchsvolle Geräteanforderungen durch eine Gruppe sich ergänzender Geräte zu erfüllen. Hierdurch ergibt sich für den Geräteanbieter eine sehr hohe Flexibilität, um die Anforderungen einer Anwendung zu erfüllen. Betrachten wir dazu als einfaches Beispiel eine Leistungsmessung. Während Hersteller A hier seine Leistungsmessgeräte vorteilhaft ins Spiel bringt, kann Hersteller B dieselbe Aufgabe auch durch getrennte Strom- und Spannungsmessgeräte mit Software-Multiplikation im Gerätetreiber erfüllen. Das Anwendungsprogramm stellt hier keinen Unterschied fest.
Ganz ohne Zuordnung zu einem physikalischen Gerät kann über den GDI-Treiber ein Intelligenzausgleich vonstatten gehen, indem Software-funktionen, die das Gerät eines Herstellers hat, von einem anderen Hersteller im Gerätetreiber realisiert sind.
- Universelle Geräteintegration und konfiguration
- Universelle Geräteintegration und konfiguration
- Universelle Geräteintegration und konfiguration
- Universelle Geräteintegration und konfiguration
