Anforderungen an Gerätetreiber

Nach Fertigstellung der Drei-Spektrometer-Anlage werden mehr als 200 Geräte zu steuern und zu überwachen sein. Für jedes dieser Geräte gibt es auf den verschiedenen Rechnern jeweils einen Steuerungsprozeß. Es ist daher erforderlich, daß bei der Programmierung der Gerätetreiber nach einem einheitlichen Konzept vorgegangen wird [Kra92b].

Die Geräte bestehen oft aus mehreren funktionellen Untereinheiten, die unabhängig voneinander sind und damit auch einzeln bestehen könnten. Die Steuerungselektronik der Targetposition z.B. besteht aus den Untereinheiten Höhensteuerung und Winkelsteuerung (siehe Abschnitt ). Manche Geräte besitzen nur eine, manche mehrere dieser Untereinheiten, die den Ausgangspunkt des Gerätekonzepts bilden. Der Zustand einer Untereinheit wird durch die Werte ihrer Zustandsvariablen beschrieben. Solche Variablen sind z.B. Höhe, Winkel, Spannung, Stromstärke, Magnetfeldstärke, Temperatur und Druck. Alle Handlungen, die man an einem Gerät ausführen kann, beziehen sich auf diese Zustandsvariablen. Ihre Werte können dabei ausgegeben oder auch verändert werden. An der Höhensteuerung für das Target kann man z.B. den Istwert der Höhe auslesen und den Sollwert einstellen.

Diese Struktur der Geräte muß in den Programmen, die diese Geräte steuern sollen, berücksichtigt werden. Diese sogenannten Gerätetreiber bilden als ,,virtuelle Geräte`` die Gegenstücke zu den physikalischen Geräten. Die Funktionalität der Untereinheiten wird damit im Computer als sogenannter Service (Dienst) zur Verfügung gestellt. Solch ein Service beinhaltet Felder, die die Werte der Zustandsvariablen aufnehmen. Spezielle Prozeduren, sogenannte Aktionen, implementieren die Befehle, um auf die Felder zugreifen zu können. Tabelle zeigt diesen Aufbau am Beispiel der Targetsteuerung.

Für gleiche Geräte bzw. Untereinheiten braucht nur ein Servicetyp implementiert zu werden. Dadurch, daß das entstandene Programm mehrfach gestartet wird, erhält jede Untereinheit ihren eigenen Service. Services vom gleichen Servicetyp benutzen damit zwar die gleichen Routinen, ihre Felder können aber unterschiedliche Werte haben.

Alle Gerätetreiber haben also einige wesentliche Merkmale gemeinsam:

• Ein Gerätetreiber kann aus einem oder mehreren logischen Untereinheiten, den Services, bestehen.
• Jeder Service gibt gemäß der Service-Feld-Aktion-Hierarchie die Struktur des Gerätes wieder und stellt dessen Funktionalität zur Verfügung.
• Jeder Prozeß besitzt einen Kommunikations-Kanal zum Messagesystem, und jeder Service ist über seinen eigenen Messagesystem-Namen, der dem Kommunikations-Kanal seines Prozesses zugeordnet ist, bekannt (z.B. hat der Service für die Target-Höhen-Steuerung den Namen target/height).
• Die Nachrichten, die die Gerätetreiber untereinander austauschen, verwenden ein festgelegtes Protokoll, das zusätzlich zum Message-System-Namen, der dem Servicenamen entspricht, Feld und Aktion angibt, um eindeutig festzulegen, welche Aktion ausgeführt werden soll [Hak93].
• Statusmeldungen und eventuelle Fehlermeldungen werden über das Messagesystem an den opcon-Prozeß ausgegeben (siehe Abschnitt ).
• Konfigurationen werden aus einer zentralen Datenbank erfragt. Diese Informationen sind dort auch nach der Service-Feld-Aktion-Hierarchie organisiert. Ein Gerätetreiber kann damit durch einfache Änderungen in der Datenbank mit verschiedenen Konfigurationen betrieben werden und muß dafür nicht neu implementiert werden.

Es ist daher sinnvoll, für die Programmierung solcher Gerätetreiber eine einheitliche Umgebung zu schaffen. Diese Umgebung sollte möglichst einfach sein, damit auch Anwender (d.h. Programmierer), die sich mit Details des Messagesystems nicht auskennen, ein Treiberprogramm erstellen können. Daraus ergeben sich folgende Anforderungen:

• Die Programmteile, die immer gleich bleiben (wie Kommunikationskanal verwalten, Nachrichten empfangen und die angeforderte Aktion ausführen), sollten so verborgen zur Verfügung gestellt werden, daß der Programmierer sich auf die Implementierung der eigentlichen Aktionen seines Gerätes konzentrieren kann.

• Die Service-Feld-Aktion-Hierarchie und damit die Programmierung eigener Aktionen sollte so weit unterstützt werden, daß nur noch der eigentliche Algorithmus erstellt werden muß.

• Durch Datenbankfunktionen könnten wichtige Konstanten (z.B. Grenzwerte, Eichtabellen etc.) für die Aktionen zur Verfügung gestellt werden.

• Fehlerausgaben sollten über das Messagesystem und auf Terminals möglich sein, um die Geräte sowohl gemeinsam an einem zentralen Platz als auch separat überwachen zu können.

• Alle Treiber sollten mit den gleichen Optionen aufrufbar sein, damit kein Spezialwissen für den Aufruf notwendig ist.

Ein Teil dieser Funktionalität wurde bereits früher am Institut für Kernphysik realisiert (siehe [Kun92]). Hiermit wurde bisher ein Großteil der Treiber implementiert. Leider blieben aber einige der Anforderungen unberücksichtigt, vor allem was die einfache Programmierbarkeit betrifft. Auch die Flexibilität in bezug auf die Anzahl, Kombination und Konfigurierbarkeit von Services und Aktionen ist beschränkt. Da das Nachrichtenprotokoll für die Steuerung nicht sauber implementiert wurde, können zwar mehrere Aktionen definiert werden, diese sind aber nicht nach Feldern aufgeteilt, und nur eine dieser Aktionen kann per Datenbank konfiguriert werden [Hak93]. Außerdem können keine unterschiedlichen, aber zusammengehörigen Services in einem Treiber vereinigt werden.