PC Linux (evtl. Workstation) Steuerprogramm, Auswertung, Schnittstelle Instrument-FRM II)

Konzept zur Instrumentsteuerung am FRM II

Jurgen Neuhaus

Zentrale Betriebseinheit FRM II-Bau

Technische Universitat Munchen

Version 1.0

14. August 1998

Zusammenfassung

Das hier beschriebene Konzept zur Instrumentsteuerung basiert auf einer Client- Server Strategie. Hierbei wird die Datenaufnahme sowie die Experimentsteuerung dezentral von sogenannten Servern ubernommen. Die Ablaufsteuerung des Experi- ments erfolgt von einem Clienten, der die vom Benutzer denierten Befehle uber- nimmt und sie an die entsprechenden Server weiterleitet. Daruber hinaus stehen die Server anderen Clienten zur Verfugung, die z.B. eine online Kontrolle des Instru- ments ermoglichen.

1

Inhaltsverzeichnis

1 Einleitung 3

2 Technische Anforderungen 4

3 Client Server Architektur 5

4 CORBA: Der Software Bus 6

4.1 Programmierwerkzeuge . . . 8

4.2 Fazit . . . 8

5 Das TACO Konzept der ESRF 9

5.1 Aufbau . . . 9

5.2 Sicherheitsvorkehrungen . . . 10

5.3 Platformen . . . 11

5.4 Schnittstellen . . . 11

5.5 TACO-BOX . . . 12

5.6 Weiterentwicklungen . . . 12

6 EMS System am FZ-Julich 12 7 Betriebssysteme 13 8 Steuerprogramm und graphische Benutzeroberache 14

8.1 Tcl/Tk . . . 15

8.2 IDL . . . 15

8.3 Motiv, wxWindows und andere . . . 15

9 Zusammenfassung 16

10 Danksagung 16

2

1 Einleitung

Die Instrumentsteuerung an der Neuen Forschungsneutronenquelle FRM II in Gar- ching ist durch besondere Randbedingungen des Konzeptes der Instrumentierung gepragt. Der Aufbau, sowie der Betrieb der einzelnen Instrumente wird auschlie- lich von externen Nutzergruppen realisiert. Die optimale Nutzung der fur die Instru- mentierung zur Verfugung stehenden Resourcen erfordert eine sorgfaltige Abwagung der moglichen Standardisierung einerseits und des exiblen Aufbaus und Erweiter- barkeit an neuen Komponenten andererseits. Neben einem soliden, d.h. zuverlaigen Betrieb soll die Besonderheit des kreativen Umfeldes einer Hochschule jederzeit in die Weiterentwicklung der Nutzung von Neutronen einieen. Neue Ideen konnen sich nur dann durchsetzen, wenn die Realisierung in kurzen Zeitraumen moglich ist. Ein starres, monolithisches Konzept bei der Integration vieler Komponenten ist hierfur nicht geeignet.

Neben der Verwirklichung neuer Ideen steht der Betrieb der Forschungsneutro- nenquelle als Grogerat zur Nutzung durch auswartige Forschergruppen im Vorder- grund. Hierbei mu das Instrument eine einfache, intuitiv zu bedienenden Benut- zerschnittstelle zur Verfugung stellen. Die Verwendung von etablierten Konzepten zur Eingabe von Befehlen und Darstellung von Medaten soll auch weniger erfah- renen Nutzer die optimale Ausnutzung seiner ihm zur Verfugung gestellten Mezeit gewahrleisten. Hierbei bekommen die Dokumentation des Instrumentes sowie jeder- zeit zur Verfugung stehende Hilfefunktionen (online help) eine besondere Rolle. Die mit groer Sorgfalt und auf dem neuesten Stand der Technik gebauten Instrumente konnen ihre Leistung nicht erbringen, wenn der Benutzer sie nicht zu jeder Tag- und Nachtzeit dem Meproblem anpassen kann. Die hierfur notwendige Unterstutzung mu zu einem nicht zu vernachlaigendem Teil von der Instrumentsteuerung gelei- stet werden.

Die Realisierung von Komponenten, die an nahezu allen Instrumenten verwen- det werden erfordert ein hohes Ma an Abstarktion und wohl denierter Schnittstel- len. Dies gilt nicht nur fur mechanische Komponenten, die zusammengefugt werden mussen, sondern in gleicher Weise fur Programmierbausteine, die zu einer Instru- mentsteuerung zusammengesetzt werden. Hierbei mu jedoch der besonders hohen Vielfalt von Programmiersprachen, Techniken sowie Computerarchitekturen Rech- nung getragen werden. Wahrend bei der Mechanik niemand auf die Idee kommen wurde linksdrehende Schrauben zu verwenden, so kann von einer allgemeinen Stan- dardisierung im Bereich der Geratesteuerung nicht ausgegangen werden. Neben ei- ner Vielzahl geeigneter Dialekte zur Programmierung, gibt es eine groe Anzahl von Schnittstellen (Busse) zur Datenubertragung, die mehr oder weniger fur bestimmte Aufgaben geeignet sind.

3

Das hier vorgestellte Konzept soll oen fur jede Anbindung von elektronischen Datenaufnahmesystemen sein. Es soll das Instrument uber einzelne Komponenten denieren, die von unterschiedlichsten Gruppen unabhangig voneinander erstellt werden konnen. Um ein langfristig tragbares Konzept zu erstellen sollen industriell erprobte Techniken und Werkzeuge zum Einsatz kommen. Ein solches Konzept kann mit einer Client/Server Architektur realisiert werden.

2 Technische Anforderungen

Eine wesentliche Anforderung an den Aufbau einer Instrumentsteuerung ist die Ein- beziehung aller notwendigen Bussysteme, uber die die Me- und Steuergerate an- gesprochen werden. Eine zukunftig sicherlich wachsende Anzahl von Bussen umfat unter anderen:

GPIB [1]

RS232

RS485

Probus [2, 3]

Interbus [4]

parallele Schnittstelle (PC)

VME,VXI

PCI, cPCI, PXI

ISA

Bedenkt man die Vielzahl an industriell vorhandenen Komponenten zur Da- tenerfassung, so empehlt sich nicht nur aus Kostengrunden die Verwendung einer PC-Architektur. Das Konzept mu jedoch so allgemein gefat werden, da prinzipi- ell

alle

Komponenten eingebunden werden koennen. Sei es eine leistungsstarke neue Workstation oder ein bereits vorhandenes alteres CAMAC-System. In Abbildung 1 ist der Aufbau einer derartigen Instrumentsteuerung skizziert.

Neben der Finanzierbarkeit von Losungen mu die Leistungsfahigkeit und Zu- verlasigkeit im Vordergrund stehen. Wahrend die anfallende Datenmenge bei Neu- tronenstreuexperimenten (leider) keine besonders hohen Anforderungen an Ubertra- gungsgeschwindigkeiten stellt, so soll eine Instrumentsteuerung jedoch keine unnoti- ge Zeit beim Umstellen einer Mekonguration verlieren. Unumgangliche Wartezei- ten, wie bei der Anderung von Probenparametern (z.B. Temperatur) oder Bewe- gungen des Instruments (z.B. Anderung der Proben- oder Detektorposition) sollten nicht unnotig durch die Kontrolle weiterer Parameter verlangert werden.

4

VME System VME System

2D Detektor mit eigener Elektronik und Rechner Probenumgebung

SubNet Instrument

Externes Gerät

Steuerkarte Steuerkarte Steuerkarte Steuerkarte Steuerkarte

Steuerkarte Steuerkarte Steuerkarte Steuerkarte Steuerkarte Encoder Encoder Encoder Encoder Encoder Encoder

Leistungs versorgung

externe

Leistungs versorgung

externe

Leistungs versorgung

externe

ADC DAC Dig I/O Seriell (RS232)

Eth ProfiBus GPIB Zählerkarte

XTerminal Hausnetz von Zapfstelle ( 100 MBit)

HV Ratemeter MCA

NIM Rack

SPS Steuerung

Temperaturregler Power supply mit Multiplexer

Multimeter Schrittmotor

steuerung Bedinfeld mit Anzeige

FlaschProm (Linux, evtl. real time) Steuer-PC (Industrie-PC mit PCI/ISA-Bus)

PC Linux (evtl. Workstation)

Steuerprogramm, Auswertung, Schnittstelle Instrument-FRM II) Switch (Ethernet 100 MBit, 10 Mbit)

Abbildung 1: Schematischer Aufbau einer Instrumentsteuerung unter der Verwendung unterschiedlichster Bussysteme

Neben der eigentlichen Steuerung zur Datenaufnahme mu das System in der Lage sein, jederzeit Auskunft uber den Zustand samtlicher Instrumentkomponenten zu geben. Diese Anforderung dient nicht nur zur Kontrolle des Instruments wahrend einer Messung sondern dient insbesondere auch zur Fehlerndung.

Das Konzept der Instrumentsteuerung darf weder an das verwendete Betriebs- system des Steuerrechners oder sonstige Rechnerarchitekturen gebunden sein. Die zu Beginn der Instrumentierung des FRM II vorgenommenen Standardisierungen sollen der Arbeitserleichterung und Kostensenkung dienen. Sie durfen auf keinen Fall zukunftige Entwicklungen behindern oder unnotig erschweren.

3 Client Server Architektur

Die Aufteilung einzelner Arbeiten innerhalb eines Steuerprogramms erfolgt norma- lerweise uber den Aufruf von Funktionen oder Unterprogrammen, welche die eigent- lichen Aufgaben erledigen. In einer geschlossenen Gruppe von Programmieren kann dann auch sicherlich die Arbeit in einzelne Komponenten aufgeteilt werden. Bei diesem monolithischen Ansatz legt man sich nicht nur auf eine Programmierspra- che sondern oft auch auf ein Rechnerbetriebssystem und Entwicklungswerkzeuge fest. Ein derartiges Konzept kann sich zwar fur ein einzelnes Instrument als eektiv erweisen, ist jedoch fur die Arbeitsteilung auf sehr heterogene Gruppen mit sehr unterschiedlichen Erfahrungen und Moglichkeiten nicht geeignet.

Die Verteilung der Aufgaben innerhalb eines Steuerprogramms sollte von der verwendeten Realisierung des Instruments (Hardware) unabhangig sein. Ein solches

5

Konzept kann in einer Client-Server-Architektur realisiert werden. Der Server stellt

uber eine denierte Schnittstelle Funktionen zur Verfugung, uber die Me- und Steuergerate angesprochen werden konnen (Device Server, DS). Der Client, z.B.

das Steuerprogramm, in das der Experimentator seine Steuerbefehle eingibt, sendet seine Anfrage, oder Befehl and den entsprechenden Server, der dann die eigentliche Arbeit ubernimmt. Fur den Clienten ist es unerheblich, wie diese Arbeit ausgefuhrt wird, er erwartet nur das sie ausgefuhrt wird. Der Server gibt nach Beendigung der Aufgabe eine Meldung, seien es Zahlraten, Motorpositionen oder ein einfaches OK, an den Clienten zuruck. Hierbei ist es unerheblich, wo sich die Server benden, oder unter welchem Betriebssystem sie arbeiten.

Als Ubertragungsprotokoll zwischen raumlich verteilten DS eignet sich das weit verbreitete Internet Protokoll TCP, das auch als Standard Protokoll am FRM II eingesetzt werden wird. Die unterschiedlichen Device Server konnen aber auch auf einem einzigen Rechner z.B. unter Linux laufen. Wenn mehrere solcher Prozesse auf einem Rechner laufen sollen, mu das Betriebssystem dazu naturlich in der Lage sein. Hierfur kommen nur moderne multi-tasking Betriebssysteme in Frage, was aber das Konzept im Prinzip kaum einschrankt. Das verwendete Betriebssystem mu naturlich in der Lage sein uber ein TCP/IP Protokoll zu kommunizieren.

Der Vorteil der Aufteilung der Arbeit auf DS zeigt sich auch in der raumlichen Unabhangigkeit von Client und Server. Auf jedem an das Internet angeschlossenen Rechner kann das Steuerprogramm oder ein Kontrollprogramm laufen. Hierbei ist es naturlich notwendig entsprechende Sicherheitsvorkehrungen zu treen, das ein unbefugter Zugri auf das Instrument unterbunden wird.

4 CORBA: Der Software Bus

Die Object Management Group (OMG) [5] ist ein 1989 gegrundeter, internationa- ler, nicht protorientierter Zusammenschlu von Softwareentwicklern, Netzwerkbe- treibern, Hardwareproduzenten und kommerziellen Anwendern von Computersyste- men. Mit der Object Management Architecture (OMA) hat die OMG eine Softwa- rearchitektur speziziert, die das Zusammenarbeiten von Anwendungen verschiede- ner Hersteller ermoglicht, und zwar unabhangig davon, von welchem Programmierer und an welchem Ort, fur welches Betriebssystem bzw. fur welche Hardware und mit welcher Programmiersprache sie entwickelt wurden.

Kern dieser Architektur ist die 1991 in der Version 1.1 herausgegebene Spezi- kation des Object Request Brokers (ORB). Er ist das von der OMA vorgesehene universelle Kommunikationsmedium fur beliebig geartete Objekte in verteilten hete- rogenen Systemen. Der zugehorige Standard heit Common Object Request Broker

6

device server bus (RS232) Gerät 10

device server bus (RS232) Gerät 11

device server bus (GPIB)

Gerät 20

device server bus (GPIB)

Gerät 21

Zählerkarte device server

Detektor 1-64

device server bus (profibus)

Motor 2 Encoder 2 device server

Motor 1 Encoder 1 bus (profibus)

Motor 3 Encoder 3 device server

bus (profibus) update daemon Steuerprogramm

(Spec, Datenaufnahme, TASPROG, ...)

device server bus (??) Probenparameter

device server extern (eth)

VME 1

device server extern (eth)

VME 2

device server extern (eth)

Chopper

device server extern (eth)

2D Detektor

Software-Bus (CORBA, TACO)

Abbildung 2: Schema der Kommunikation zu Me- und Steuergeraten im Client-Server- Modell.

Architecture (CORBA). Seit Sommer 1995 nunmehr in der Version 2.0, zeichnet er sich durch folgende Eigenschaften aus:

Objektorientierung

Die grundlegenden Einheiten der Architektur sind Objekte, wobei ein Objekt im Sinne der OMA eine beliebige, eindeutig identizierbare Einheit ist, also nicht notwendigerweise ein Objekt im Sinne einer Programmiersprache.

Verteilungstransparenz

CORBA-Programme greifen auf entfernte Objekte mit denselben Mechanis- men zu, wie auf lokale Objekte. Der genaue Aufenthaltsort eines Objekts bleibt fur seine Klienten in der Regel unbekannt.

Ezienz

Die Architektur fur den ORB ist von der OMG bewut so gehalten, da e- ziente Implementationen moglich sind, die z.B. im Falle rein lokaler Kommu- nikation dem traditionellen Funktionsaufruf nur unwesentlich nachstehen. Es gibt CORBA Anwendungen auch auf real-time Systemen.

Hardware-, Betriebssystem- und Sprachunabhangigkeit

Die Komponenten eines CORBA-Programms konnen auf verschiedenen Be- triebssystemen, Hardwarearchitekturen und mit verschiedenen Programmier- sprachen realisiert werden.

7

Oenheit

Uber den ORB konnen Programme verschiedener Hersteller zusammenarbei- ten. Man erhalt dadurch die Freiheit, fur Komponenten Entwicklungsumge- bungen von verschiedenen Anbietern verwenden zu konnen, die seinen indivi- duellen Bedurfnissen am besten gerecht wird.

4.1 Programmierwerkzeuge

Fur die Programmierung mit CORBA gibt es einige frei verfugbare Systeme, die sich bereits bewahrt haben.

OmniBroker

OmniBroker [7] ist eine CORBA-2.0 Entwicklungsumgebung der Firma OOC Inc., das fur nicht kommerziellen Gebrauch kostenlos ist und im Quellcode frei erhaltlich [7] ist. Das von der ESRF entwickelte TACO System hat ei- ne CORBA-Schnittstelle, die mit den OmniBroker Bibliotheken erstellt und getestet wurde. Dieses Software Paket unterstutzt die Umsetzung der IDL Be- fehle in C++ und Java. Zusatzlich existiert noch ein Dokumentations-tool mit HTML-Ausgabe.

MICO

MICO [8] ist eine Entwicklung des Lehrstuhls fur verteilte Systeme und Be- triebssysteme der Fakultat fur Informatik an der Universitat Frankfurt am Main. Auch dieses Projekt hat sich schon in vielen Industrieprojekten bewahrt und ist kostenlos und im Quellcode fur verschiedene Betriebssysteme erhaltlich [8].Die verfugbaren Portierungen zeichnen sich durch die Schnittstellen (X11 (Qt, Xt, Gtk) und Tcl/Tk) zu Graphischen Programmieroberachen aus. Es ver- wendet wie OmniBroker den CORBA-2.0 Standard.

4.2 Fazit

CORBA stellt zum einen eine beachtliche Menge technologischen Know-hows und zum anderen einen selten erreichten Konsens innerhalb der Computerindustrie dar.

Dieser Industriestandard wird in den unterschiedlichsten Anwendungen eingesetzt [6]. Auch wenn der Einsatz einer solchen Technologie eine wesentlichen erhoten Aufwand darstellt, so kann man jedoch davon ausgehen, das sich die Flexibilitat fur den Einsatz zukunftiger Rechnersysteme und Steuerprogramme auszahlen wird.

Negativbeispiele fur die schlechte Wartbarkeit und Transfermoglichkeit von beste- henden Systemen gibt es bereits genug. Eine standardisierte Softwareschnittstelle

8

allein macht jedoch noch keine fertige Instrumentsteuerung. Bei diesem Ansatz fehlt die zentrale Verwaltung der Server sowie ein Sicherheitskonzept (Zugrisrechte) das auf der Softwareschnittstelle aufbaut, von einer Umsetzung der in physikalischen Einheiten denierten Steuerbefehle ganz zu schweigen.

5 Das TACO Konzept der ESRF

TACO [9] ist der Name eines objekt orientierten Kontrollsystems, das an der ES- RF (European Synchrotron Radiation Facility, Grenoble) entwickelt wurde. In die- sem System wird jedes Kontrollelement (Instrumentkomponente) als ein Objekt deniert, da Kommandos ausfuhren kann. Solche Objekte werden als Device be- zeichnet und sind in sogenannten Device-Servern enthalten. Die Befehle, die ein derartiges Device ausfuhren kann, sind durch Device-Klassen implementiert. Eine Device-Klasse kann sowohl in C (durch ein Objektsystem OIC, Objects In C) als auch in C++ geschrieben werden. Zugang zu den implementierten Kommandos erhalt man uber eine kleine Anzahl von C- (oder C++) Befehlen, die uber eine vor- gegebene Schnittstelle (API, Application Programmer's Interface) zur Verfugung gestellt wird.

Das Programm, welches das System steuert (Client), greift auf die Device-Server

uber ein netzwerktransparentes Interface (DSAPI) zu. Neben den Device-Servern gibt es fur zentrale Aufgaben den System-Manager und eine Datenbank, in der die Device-Server verwaltet werden. Durch dieses Client-Server-Modell gibt es a- priori keine Grenzen fur die Anzahl der Device-Server oder Clients. Es zeichnet sich durch eine hervorragende Skalierbarkeit aus. Eingesetzt wird das TACO-System zur Steuerung des Synchrotrons (Steuerung hauptsachlich mit VME-Systemen), Teile der Experimentsteuerung an der ESRF sowie eines Radioteleskops (Hartebeesthoek Radio Astronomy Institute, Sudafrika) auf PC-Basis (Linux).

5.1 Aufbau

Der System-Manager ist die zentrale Einheit in einem TACO-Kontrollsystem. Der Manager startet und beendet das gesamte Kontrollsystem. Alle Clienten als auch alle Device-Server rufen als erstes den Manager auf, bevor sie ihre Arbeit aufnehmen.

Die Konguration der Device-Server wird durch eine einfache Datenbank verwaltet.

Die Kongurationsdatei liegt als ASCII-Datei vor und wird zur Laufzeit des Systems entsprechend von dem Datenbankprogramm umgewandelt. Als Datenbank dient das ndbm-Programm, das in allen UNIX Systemen (System V) vorhanden ist.

Das Device-Server-Modell stellt die Schnittstelle fur den Zugri auf die einzelnen 9

Device-Server dar. Fur den Benutzer prasentiert sich das System als eine black box, das uber eine Programmierhochsprache (C, C++, Tcl, ...) mittels des DSAPI oder eine graphische Benutzeroberache zuganglich wird. Die wesentlichen Befehle sind:

dev import() Import oder Aufbau einer Verbindung zu einem Device

dev putget() Ausfuhren eines Kommandos auf einem Device

dev putget async() Asynchrones Ausfuhren eines Kommandos auf einem De- vice

dev free() Beenden der Verbindung zu einem Device

Zusatzlich zu diesen Grundfunktionen gibt es Befehle zur Konguration der Ver- bindung Client-Server, zur Abfrage des Status eines asynchronen Kommandos oder zur Konguration der Zugrisrechte (Systemsicherheit).

Die Verbindung Client-Server werden durch Open Network Computing/Remote Procedure Call (ONC/RPC) von Sun realisiert. Die ONC/RPC Verbindung ist auf allen Systemen, die uber ein Network File System (NFS) verfugen, implementiert.

Um die Daten uber das TCP- oder UDP-Protokoll im Netz zu versenden werden sie im XDR-Format (eXternal Data Representation) kodiert.

Zur Puerung von Ergebnissen, die die Device-Server als Ruckgabewerte von Kommandos liefern, dient ein sogenannter data collector. Er besteht aus einem gros- sen shared memory, das auf mehreren Rechnern verteilt sein kann. Neben real exi- stierenden Device-Servern gibt es in diesem data collector auch sogennante Pseudo- Devices. Diese sind hilfreich zum Verteilen von Informationen, die normalerweise im Speicher der Programme abgelegt werden oder von ausgewerteten, berechneten Werten. Durch die Puerung von Daten konnen auch Engpasse vermieden werden, wenn beispielsweise mehrere Clienten auf Instrumente mit langsamen Schnittstellen zugreifen wollen. Der Zugri auf den data collector erfolgt uber eine API vergleichbar mit der DSAPI.

5.2 Sicherheitsvorkehrungen

Im TACO-System wird der Zugri auf die Device-Server durch ein Sicherheitskon- zept geregelt. Es ist auf dem Kommandoniveau der Device-Server implementiert.

Somit konnen die Zugrisrechte fur jeden Device-Server einzeln eingerichtet wer- den. Es gibt sechs verschiedene Sicherheitsstufen:

READ

WRITE

SINGLE WRITE

10

SUPER USER

SINGLE SUPER USER

ADMIN

5.3 Platformen

Das TACO-Konzept wurde ursprunglich unter Unix (Sun und HP) und OS9 (Echt- zeitbetriebssystem hauptsachlich auf 68xxx-CPU's in VME-Systemen) entwickelt.

Die aktuelle, von der ESRF unterstutzte Liste der Rechnerplattformen umfat:

HP-UX (9.x, 10.x)

Solaris (5.x.x)

OS9 (3.x)

Linux (2.x)

Winows/NT (3.5x)

SunOs (4.x.x)

Zudem gibt es Portierungen zu:

LynxOS

VxWorks

OS9000

Zur Langzeitarchivierung (Jahre) der Systemzustande wird eine kommerzielle Datenbank (Oracle) verwendet, die uber SQL-Befehle, C-Programme oder Tabellen- kalkulationsprogramme abgefragt werden kann. Fur ein lauahiges TACO-System ist diese Datenbank jedoch nicht erforderlich.

5.4 Schnittstellen

Der modulare TACO-Aufbau bietet sich gerade dazu an vielfaltige Schnittstellen zur Steuerung/Bedienung des Kontrollsystems zu realisieren. An der ESRF wurden bislang folgende Anbindungen geschaen:

CORBA-Gateway

Java (eigenstandige Programme, applets)

Tcl/Tk Scripte

ASCII

11

Labview (Windows/NT uber ASCII)

OLE2 (Windows/NT)

SPEC

5.5 TACO-BOX

Eine weitere interessante Entwicklung der TACO-Steuerung (TACO-box [10]) zielt auf eine Ausweitung der verteilten Objekte mit einem sogenannten embedded contro- ler. Hierfur werden preiswerte PC/104-Module verwendet, mit denen eigenstandige Kontrollsysteme realisiert werden. Als Betriebssystem wird z. Zt. VxWorks als Echt- zeitbetriebssystem verwendet. Eine Portierung auf Linux ist in Arbeit. Mit derarti- gen Systemen ist es denkbar, einzelne Instrumentkomponenten (Probenumgebung, Motorsteuerung, Choppersteuerung, ...) mit komfortablen und umfassenden Kon- trollmoglichkeiten auszustatten.

Das TACO-System ist inklusive des Quellcodes frei verfugbar. Eine aktive Un- terstutzung bei einer moglichen Verwendung bei der Instrumentsteuerung am FRM II wurde von der Programmierabteilung an der ESRF zugesagt.

5.6 Weiterentwicklungen

Augenblicklich wird an der ESRF an einer Weiterentwicklung des TACO-Systems gearbeitet. Hierbei wird das Grundgerust der RPC-Verbindungen zwischen Client und Server durch CORBA und/oder DCOM ersetzt. Die damit mvglichen Erweite- rungen wie dynamische Typenverwaltung, asynchrone Aufrufe, Thread-Unterstutzung, etc. ergeben das neue TANGO (TAco New Generation Objects) Device-Kontrollsystem [11].

6 EMS System am FZ-Julich

Die am Neutronen-Spin-Echo-Spektrometer am Forschungszentrum Julich einge- setzte Steuerung [12] basiert auf einer Software, die zur Datenerfassung und Kom- munikation fur COSY-Experimente entwickelt wurde. Die EMS (Experimentalizing Message Specication) Software arbeitet nach dem Client-Server-Prinzip und ver- wendet eine objektorientierte Sprache. Hierbei dient der Client wieder der Experi- mentkontrolle und der Server der Steuerung der Hardware. Die Verbindung Client Server wird uber TCP/IP hergestellt, wobei fur die Umsetzung Bibliotheken (EMS- Commlib, EMS-Serivelibrary) zur Verfugung stehen. Bei der Anwendung fur das NSE-Spektrometer werden dabei die Verbindung zu einem VME-Controller und

12

darin uber Einschubkarten Verbindungen zum Probus und GPIB-Bus realisiert.

Die verschiedenen Server werden auf dem VME-Controller unter OS/9 betrieben.

Sie stellen sich nach auen als VED (Virtual Experiment Device) dar und sind nur uber ihre Objekte zuganglich. Zu Beginn mussen die Server vom Clienten kon- guriert werden. Die dazu erforderlichen Daten werden in Kongurationsdateien abgelegt.

7 Betriebssysteme

Die Wahl des Betriebssystems fur eine Instrumentsteuerung in einem Client-Server- Modell ist eng mit der erforderlichen Hardware verbunden. Bei der Konzentration auf PC-Plattformen kommen neben den Unix-Derivaten (Linux, BSD, ..), Echt- zeitbetriebssystemen wie LynxOS, VxWorks, QNX, OS9/i86 auch Windows/NT in Betracht. Sind VME-Systeme erforderlich so werden ahnliche Echtzeitbetriebssyste- me oder Unix verwendet. Wahrend sich die Echtzeitbetriebssysteme besonders fur embedded control Systeme eignen ist Winows/NT eher als graphisches Frontend zur Benutzerschnittstelle geeignet.

Um hier zu einer moglichst einheitlichen Losung zu kommen sollten die erfor- derlichen Eigenschaften zusammengefat werden. Betrachtet man die bisherigen fur Neutronenstreuexperimente eingesetzten Steuerungen, so kann der Bedarf an einer Echtzeitsteuerung als eher gering eingestuft werden. Die unabdingbaren Eigenschaf- ten sind:

Stabilitat

Netzwerkfahigkeit

Verfugbarkeit von Programmierwerkzeugen

Graphische Benutzerschnittstellen

Langzeitverfugbarkeit (schnelle Weiterentwicklung der Rechnerplattformen)

Unterstutzung verschiedener Hardware (wunschenswert)

Das frei verfugbare Linux Betriebssystem erfullt alle oben angefuhrten Voraus- setzungen. Es gibt zudem Erweiterungen um Echtzeitprozesse zu ermoglichen (RT- Linux). Neben PC-Plattformen (Intel) ist es auch auf DEC-Alpha Workstations und Motorolla CPU's (68xxx und PowerPC) verfugbar. Fur eine moglichst um- fassende Vereinheitlichung ist es somit am besten geeignet. Bei der Realisierung eines Client-Server-Konzeptes ist aber die Einbindung von Komponenten mit ande- ren Betriebssystem unproblematisch. Es mu jedoch der nicht zu vernachlaigende Mehraufwand bei der Unterstutzung mehrerer Betriebsysteme berucksichtigt wer- den. Hier mu eine strenge Aufwand (Kosten)/Nutzen-Rechnung aufgestellt werden.

13

8 Steuerprogramm und graphische Benutze- roberache

Mit der Denition eines Client-Server-Konzeptes zur Instrumentsteuerung kann die Aufgabe der Einbindung unterschiedlichster Hardware in ein Steuerprogramm bewaltigt werden. Als wesentlicher Teil bleibt noch die Umsetzung einer Meab- folge in physikalischen Einheiten in die Anweisungen (Kommandos) an die Device- Server zu losen. Die Eingabe der Mebefehle erfolgt entweder uber die Tastatur in einer Scriptsprache oder mittels einer graphischen Benutzerschnittstelle. Fur vie- le Anwendungsfalle werden beide Eingabemethoden parallel von Vorteil sein. Ein Steuerprogramm mu daher beide Modi beherrschen.

Die Aufgabe der zuverlassigen Umsetzung eines Meweges im reziproken Raum (H,K,L,En) bei vorgewahlter Anzahl der auf die Probe auftreenden Neutronen (Vorwahl einer Monitorzahlrate) ist bereits in vielen Steuerprogrammen gelost wor- den. Es liegt folglich nahe bereits existierenden Programmcode zu verwenden. Bei naherer Betrachtung der existierenden Software bzw. bei der Diskussion mit den die Software betreuenden Programmierern mu man jedoch feststellen, da keines der existierenden Programme (MAD, ILL; CARESS, HMI; ChalkTalk, Chalk River, TASCOM, Ris; ...) sich fur eine Portierung eignet.

Eine gewisse Ausnahme macht hierbei das kommerziell erhaltliche SPEC-Programm [13]. Es hat eine direkte Schnittstelle zum TACO-System (esrf io() ). Das Spec- Programm wurde jedoch im wesentlichen fur Diraktionsexperimente (einschlie- lich 4-Kreis Modus) entwickelt und bedarf fur inelastische Neutronenstreuexperi- mente einiger Anpassungen. Hierzu mussen noch Verhandlungen mit dem Hersteller gefuhrt werden. Sollte eine derartige Losung nicht die Anforderungen an Neutronen- streuexperimente erfullen mu ein neues Programm geschrieben werden. Bei dieser Gelegenheit konnte eine objektorientierte, modular aufgebaute, einfach zu wartende und damit einfach erweiterbare Steuerungssoftware entstehen. Eine Zusammenar- beit mehrerer Gruppen an den entsprechenden Neutronenstreuzentren ware hier sicherlich begruenswert.

Sollte sich das Spec-Programm als geeignet erweisen, bleibt die Umsetzung der Befehle mit Hilfe einer graphischen Benutzeroberache zu losen. Das Problem stellt sich auch mit jeder anderen Scriptsprache zur Instrumentsteuerung. Als mogliche Scriptsprache bietet sich das auf vielen Rechnerplatformen frei verfugbare Tcl [14]

an. Die etwas ungewohnliche Syntax bedarf jedoch einer gewissen Eingewohnungs- phase.

14

8.1 Tcl/Tk

Bei der Steuerung jedes Experiments mit einer Scriptsprache mu die wesentlich langsamere Ausfuhrgeschwindigkeit der zur Laufzeit interpretierten Kommandos berucksichtigt werden. Groe Teile der Steuerung sollten daher in C realisiert und kompiliert von der Scriptsprache aufgerufen werden. Fur die Einbindung von C- Programmen in Tcl sind mehrere, teils frei verfugbare Entwicklungswerkzeuge (z.B.

SWIG [15] oder allg. VisualTcl [16]) erhaltlich. Erweiterungen der Tcl Programmier- sprache fur ein objektorientierten Ansatz (z.B. incr Tcl/Tk [17]) bzw. Erweiterun- gen im Funktionsumfang (z.B. tclx [18], Tix [19]) existieren, die den Programmcode

ubersichtlicher machen bzw. verkurzen. Der wesentliche Anreiz zur Verwendung von Tcl liegt, neben der bereits existierenden Schnittstelle zu TACO, in der Kombination mit Tk, das auf auerst einfache Weise eine graphische Benutzeroberache inklusive graphischer Darstellung der Meergebnisse [20] ermoglicht.

Graphische Darstellungen mit Tcl/Tk konnen auch uber aktuelle Browser mit entsprechenden Plug-Ins erstellt werden. Somit sind einfache Kontrollmoglichkeiten von beliebigen Plattformen aus moglich.

8.2 IDL

Bei einer gegebenen Scriptsprache fur die Programmsteuerung konnen auch andere Entwicklungsumgebungen zur Erstellung graphischer Benutzeroberachen verwen- det werden. Ein Beispiel ist die am ILL z.B. fur LAMB verwendete IDL-Bibliothek.

Hierbei mu aber der proprietre Charakter der Bibliothek und die hohen Lizenzko- sten berucksichtigt werden. Die Bibliothek ist fur verschiedene Rechnerplatformen und Betriebssysteme erhaltlich. Sie wird uber eine eigene Scriptsprache verwendet.

8.3 Motiv, wxWindows und andere

Neben der Verwendung einer weiteren Scriptsprache zur Erstellung einer graphi- schen Benutzeroberache kann eine Programmierung auch direkt aus dem Steuer- programm erfolgen. Hierzu eignen sich entsprechende Bibliotheken wie Motif, wx- Windows oder andere. Der hohe Programmieraufwand insbesondere fur die Ein- bindung einer uber die Tastatur eingegebenen Befehlsfolge ist jedoch nicht zu ver- nachlaigen.

15

9 Zusammenfassung

Fur eine langfristige Planung der Instrumentsteuerung gibt es zu einem Client- Server Konzept keine Alternative. Bedenkt man die begrenzten Resourcen, die zur Erstellung einer einheitlichen Steuerung am FRM II zur Verfugung stehen, so mu ein bereits bestehendes, erprobtes Konzept verwendet werden. Das TACO (TANGO) System der ESRF ist hierfur besonders geeignet. Bei der einheitlichen Verwendung des Linux Betriebssystems auf PC-Hardware kann eine auerst leistungsfahige und stabile Instrumentsteuerung aufgebaut werden. Die Entscheidung uber die Verwen- dung des SPEC-Programms als Benutzerschnittstelle bedarf noch einer genaueren Untersuchung.

Die Realisierung einer einheitlichen Instrumentsteuerung auf Basis des TACO- (TANGO) Systems erfordert eine wohldenierte Schnittstelle zwischen den einzel- nen Instrumentenbauern und einer zentralen Gruppe am FRM II. Diese Schnittstelle konnte nach Stand der Diskussionen im Bereich einer Scriptsprache (vorraussichtlich Tcl) erfolgen. Desweiteren mu eine enge Koordination bei der Programmierung so- wohl der Device-Server als auch der Clienten erfolgen. Die Einbindung von Geraten

uber Standardschnittstellen wie GBIP, serielle Schnittstellen, Feldbusse, etc. kann hierbei von der zentralen Gruppe am FRM II bewaltigt werden. Bei der Verwen- dung von speziallisierten I/O-Karten mit ISA-, PCI- oder VME-Busanbindung ist der Aufwand beim Programmieren eines Device-Servers bei vorhandenem Hardware- treiber (fur Linux) nicht wesentlich groer als bei der Einbindung in ein herkommli- ches Programm. Beim Einsatz von Elektronik Marke Eigenbau sollte das Schreiben eines Hardwaretreibers fur Linux jedoch nicht unterschatzt werden. Diese Arbeit mu jedoch fur jede Art von Steuerung erledigt werden. Fur derartige Projekte ist unbedingt ein Erfahrungsaustausch zwischen den Gruppen erforderlich.

Zum heutigen Zeitpunkt existiert eine erste Realisierung eines TACO-Systems am FRM II. Die aktuelle Entwicklung kann uber einen speziellen Web-Server [21]

verfolgt werden. Die jetzt begonnenen Arbeiten konnen jedoch nur dann zu einem Erfolg fuhren, wenn eine rege Wechselwirkung zu und zwischen den Instrumentie- rungsgruppen etabliert wird.

10 Danksagung

Beim Entwurf dieses Konzeptes habe ich wesentlich von der Diskussion mit zahlrei- chen Kollegen protiert, denen an dieser Stelle gedankt sei. Besonderer Dank gilt Jorg Klora und Andy Gotz von der ESRF, Herr Pohl und Zwoll vom ZEL, FZ-Julich und Herrn Wulf vom HMI.

16

Literatur

[1] General Purpous Instrumentation Bus (GPIB), auch IECbus oder IEEE-488.2 Bus genannt.

[2] PROcess FIeld BUS,

http://www.aut.sea.siemens.com/networks/probus.htm

[3] Probus-DP, Grundlagen, Tips und Tricks fur Anwender, M. Popp, Huthig Verlag, Heidelberg (1998)

[4] http://www.interbus.com

[5] http://www.corba.org/ und http://www.omg.org/

[6] http://www.infosys.tuwien.ac.at/Research/Corba/

[7] http://www.ooc.com/ob/

[8] http://diamant-atm.vsb.cs.uni-frankfurt.de/ mico/

[9] TACO: An object oriented system for PC's running Linux, Winows/NT, OS- 9, LynxOS or VxWorks, A. Gotz, W.-D. Klotz, P. Makijarvi, J. Meyer, E.

Taurel, J. Quick, http://www.esrf.fr/computing/cs/taco/taco.html. Unter die- ser Adresse sind auch weitere detailierte Dokumentationen zum TACO-System erhaltlich.

[10] http://www.esrf.fr/computing/cs/sysadmin/rtk/pc104project [11] TANGO

{ object oriented control implemented in CORBA and DCOM, W.-D. Klotz, A. Gotz, E. Taurel, J. Meyer, http://www.ersf.fr/cs/taco/tango/tango.html [12] NSE Software Anwender Handbuch V2.0, J. Twardowski, H.Pohl, K. Zwoll,

Interner Bericht FZJ-ZEL-IB-500397 (Februar 1997) [13] SPEC Softwarepacket http://www.certif.com

[14] http://www.tcltk.com

[15] http://www.cs.utah.edu/ beazley/SWIG/swig.html , Programm erhaltlich un- ter ftp://ftp.cs.utah.edu/pub/beazley/SWIG .

[16] http://www.neuron.com/stewart/vtcl [17] http://www.tcltk.com/itcl

[18] ftp.neosoft.com: /pub/tcl/tclx-distrib/tclX7.6.0.tar.gz [19] http://www.xpi.com/tix

[20] http://www.cs.uoregon.edu/ jhobbs/work [21] http://tacogate.frm2.tu-muenchen.de

17