Schieler, H.

KITopen

Das Kontrollsystem dient zurFernsteuerung und Überwa-chung einer Vielzahl von Einzel-vorgängen innerhalb der Be-schleunigeranlage ANKA. DasKontrollsystem für den Beschleu-niger basiert auf Client- und Ser-ver-PC’s mit dem BetriebssystemWindows NT (Microsoft) sowiedem LonWorks-Feldbus (Eche-lon) mit intelligenten Knoten undstandardisierten Ein-/Ausgabe-(I/O-Interface-)Modulen, mit de-nen die einzelnen Geräte direktan die Server-PC‘s angebundenwerden. Die Server-PC’s kommu-nizieren über CORBA (CommonObject Request Broker Architec-ture) mit den Client-PC’s im Kon-trollraum. Die gesamte Benutzer-oberfläche für die Operateurewurde mit Programmen in derProgrammiersprache Java alssog. Java Applets/Applicationsrealisiert. Der erste reale Test desSystems erfolgte in der Zeit zwi-schen Oktober 98 und März 99mit der Steuerung und Überwa-chung des Vakuumsystems undder Netzgeräte des 53-MeV-Microtrons von ANKA. Im Verlaufdes letzten Jahres wurde dasKontrollsystem durch die Einbin-dung von Diagnostik-Elementen,des Hochfrequenzsystems undder „gerampten“ (d.h. dynamischdem Strombedarf für ein verän-derliches Magnetfeld folgenden)Netzgeräte vervollständigt. Mo-mentan wird das Kontrollsystemweiter optimiert, während esgleichzeitig bei der Inbetriebnah-me der gesamten Beschleuniger-anlage, bestehend aus dem 53-MeV-Microtron, dem 500-MeV-Booster-Synchrotron und dem2,5-GeV-Speicherring, erfolg-reich eingesetzt wird.Die Struktur des Kontrollsystemswurde so geplant, dass das Kon-trollsystem aus der Sicht einesOperateurs so homogen wiemöglich erscheint. Das Designdes Kontrollsystems erlaubt dieVerwendung der gängigen Intra-net/Internet-Infrastruktur undWWW-Technologien wie HTML/-HTTP, WWW-Browser/-Servermit Java und CORBA/IIOP (Inter-net InterOrb Protocol). Die Ent-scheidung hierfür wurde getrof-fen, weil heutzutage WWW-Browser (z.B. Netscape, InternetExplorer) weit verbreitet sind undweil die WWW-Standards dafürsorgen, dass Informationen allerArt auf den verschiedenstenPlattformen gleichermaßen ver-fügbar und auf einheitlichen Be-Die allgemeine Strukturdes KontrollsystemsEinführung302(302)Das Kontrollsystem für den Beschleuniger von ANKAH. Schieler, IKNACHRICHTEN - Forschungszentrum Karlsruhe  Jahrg. 32  4/2000  S. 302-307Abb. 1: Schematische Darstellung der allgemeinen Struktur des Kontroll-systems. Der gelb unterlegte Bereich symbolisiert die Visualisierungs-Schicht,der orange unterlegte Bereich dagegen die Feldbus- und die Prozess-steuerungs-Schicht. Beschleuniger-Bereich LonWorks FeldbusLonWorks FeldbusGesteuerte GeräteLokalerService-PCServer-PCKommerziellesInterfaceSeriellesInterface I/O CrateVorstandGeschäftsführerOperateure/KontrollraumFremdfirmen-ServiceINTERNETINTRANETBüroInfo-BildschirmGästeKundenTCP/IP u. CORBAnutzeroberflächen darstellbarsind.Technisch gesehen folgt dasKontrollsystem einer 3-Schicht-Standardarchitektur:1) Feldbus-Schicht mit ihrer Ge-räteanbindung über Schnitt-stellen2) Prozesssteuerungs-Schicht mitden Beschleuniger-Objekten(z.B. ein Netzgerät)3) Visualisierungs-Schicht mit dergraphischen Benutzeroberflä-che.Abstrakt gesehen besteht dasKontrollsystem aus zwei Schich-ten, die miteinander über die sog.DeviceServer-Programme ver-bunden sind:1) aus der Feldbus-Schicht mitasynchroner, ereignisgesteu-erter Prozessdatenerfassungund Steuerung2) aus der objektorientiertenSchicht mit ihrem Modell vonGeräten (Devices), in dem dieBenutzer/Operateure (Clients)diese ansprechen, als ob diesedirekt vor Ihnen stehen.Abb. 1 zeigt schematisch die all-gemeine Struktur des Kontrollsy-stems.In den folgenden Abschnittenwerden die verschiedenenSchichten etwas genauer be-schrieben. Darüber hinaus ge-hende Details kann man aus [1],[2], [3], [4] entnehmen.Der LonWorks-Feldbus ist ein lei-stungsstarkes Datenerfassungs-und Netzwerk-System, das bis32000 intelligente Knoten überI/O-Interface-Module direkt an ei-nen Server-PC mit entsprechen-dem LonWorks-Feldbus-Interfa-ce unter Windows 98/NT anbin-det. Das PC-Interface ist mit allenGeräte-I/O-Interface-Modulendurch ein zweiadriges Kabel ver-bunden. Zur Verwaltung sämtli-cher Knoten wird auf dem Server-PC das LonWorks Network Servi-ce (LNS) Management Tool ver-wendet. Die LonWorks-Technolo-gie bietet dem Nutzer ein kom-plettes Netzwerk-System in Hard-ware und Software auf einem ein-zigen Microprozessor (dem „Neu-ron“ Chip) und erspart diesem so-mit jegliche Netzwerk-Program-mierung in dieser Schicht.Obwohl viele verschiedene Lon-Works-Module kommerziell er-hältlich sind, kann es durchaussinnvoll sein, eigene I/O-Interfa-ce-Module auf der Basis desNeuron-Chips zu entwickeln, umindividuellen Anforderungen bes-ser gerecht zu werden. Nach ei-ner sorgfältigen Analyse der An-forderungen an das ANKA-Kon-trollsystem wurden drei Typenvon I/O-Interface-Modulen spezi-ell für ANKA entwickelt und pro-duziert, welche die Anforderun-gen überwiegend abdecken:● Ariadne ist ein serielles Inter-face-Modul, das die StandardsRS-232, RS-422 und RS-485mit einer maximalen Baudratevon 115 kbit/s unterstützt. Eshat 16 kByte tiefe Pufferspei-cher an den Empfangs- undSende-Leitungen und eine ei-gene Stromversorgungs-Ein-heit für 230-V-AC- (Wechsel-spannung), ungeregelte 7–12-V-DC- (Gleichspannung)und geregelte 5-V-DC-Strom-quellen.● Zeus ist ein hochgenaues I/O-Interface-Modul mit einem 16-Bit breiten ADC (Analog-Digi-tal-Converter) mit 4 analogenEingangskanälen und einem16-Bit breiten DAC (Digital-Analog-Converter) mit einemdigitalen Eingangskanal, ei-nem DAC-Trigger-Eingangund mittels Optokopplern gal-vanisch getrennten Digital-Kanälen (8 Eingänge und 8Ausgänge). Die vier Analog-Kanäle mit einer nominellenRate von jeweils 1 kHz werdenauf den ADC gemultiplext. Beider Messung wird eine Genau-igkeit von 0,3 LSB (Least Sig-nificant Bit) erreicht. Der DACarbeitet mit einer maximalenRate von 10 kHz. Auf dem Mo-dul befindet sich ein zusätzli-cher Microcontroller speziellfür die Steuerung der Booster-und Speicherring-Netzgeräte.Dieser stellt einen mit demDAC-Trigger-Eingang syn-chronisierten Funktionsgene-rator, einen 32 kByte Daten-Speicher für DAC und ADCund einen Selbsttest zur Verfü-gung.● Hera ist ein reines Digital-I/O-Modul mit 24 Eingängen (50mA), 8 vordefinierbaren Ein-oder Ausgängen (50 mA) und8 Ausgängen (solid state re-lays, 1 A). Sämtliche Ein-/Aus-gänge (I/O) sind mittels Opto-kopplern galvanisch getrennt.Neben dem normalen Be-triebsmodus können über dieEingänge auch Frequenzengemessen werden. Hierzuwerden die Eingänge in einemweiteren Betriebsmodus zy-Die Feldbus-Schicht303(303)klisch auf einen internen Fre-quenzzähler (16-Bit breit;Messbereich 0-100 kHz; abso-luter Fehler 1,53 Hz) geleitet.Alle I/O-Interface-Module wurdenmit SMD-Technologie und mitden Abmessungen 160 mm x100 mm (Europa-Format) ge-baut. Sie benötigen eine 5-V-DC-Versorgungsspannung und ha-ben die Ein-/Ausgangs-Verbin-dungsstecker auf der Rückseiteund die LonWorks-Verbindungauf der Frontseite. Abb. 2 zeigtdie Module und ihren Einbau amBeispiel eines Schranks (Racks)mit Netzgeräten.Die für die Neuron-Chips ge-schriebene Software, die sog.Neuron-Programme, zur direktenAnsteuerung der Geräte beinhal-ten recht komplexe Funktionenwie eine Zustandsmaschine undAlarme, synchrones „Rampen“ in0.1-ms-Schritten und anderesmehr. Die Kommunikation zwi-schen Neuron und dem Server-PC erfolgt mittels der LNS-Biblio-thek mit ihren Netzwerkvariablenund -aufrufen, was gleichzeitigdas Management des Feldbus-Netzwerks erlaubt. Auf der Seitedes Server-PC’s übernehmen diesog. DeviceServer-Programme(siehe folgender Abschnitt) u.a.auch diese Aufgabe. Darüber hin-aus werden beim Systemstartsämtliche benötigten Laufzeit-Konstanten aus einer zentralenDatenbank, der sog. StatischenDatenbank, geladen und auf dierichtigen Knoten verteilt. In der Prozesssteuerungs-Schicht laufen die DeviceServer-Programme, worin die zu steu-ernden Geräte als Objekte mo-delliert werden. Diese Objekte(und damit auch die echten Gerä-te) sind an den entfernt stehen-den Client-PC’s (z.B. im Kontroll-raum) nur über deren in der Soft-ware-Schnittstelle offengelegtenParametern zugänglich. Dies be-deutet praktisch gesehen, dassnur diejenigen Eigenschaften derGeräte dem Nutzer/Operateurzur Einsicht oder Manipulation of-fengelegt werden, die für die Kon-trolle bzw. Steuerung der Anlageerforderlich sind, und dies auchnur in der vom Programmierervorgesehenen Form (z.B. könnensicherheitsrelevante Aktionen nurnach nochmaliger Bestätigungausgeführt werden). Alle anderenEigenschaften werden in der Re-gel vor dem Nutzer/Operateurverborgen gehalten. Das Accelerator Control Interface(ACI), eine von der Programmier-sprache unabhängige Sammlungvon Software-Schnittstellen, dieals Objekte über das gesamteNetzwerk verteilt sein können,benutzt den CORBA Standard alsNetzwerk-Transportprotokoll.Alle gängigen Beschleuniger-komponenten wie Netzgeräte,Vakuum- und Hochfrequenzkom-ponenten, Strahllage- und Strahl-strommonitore, usw. sind darinDie Prozesssteuerungs-Schicht304(304)Abb. 2: LonWorks I/O-Interface-Module und ihr Einbau am Beispiel eines der Schränke mit Netz-geräten.LonWorks I/O-Interface-ModuleZeus ● Hochgenaue 16-bit DAC und ADC● Datenerfassung bis 10 kHz● Funktionsgenerator● Je 8 digitale Ein-/AusgängeAriadne ● serielles Interface(RS-232, RS-422, RS-485)● bis zu 112 kbit/s● 32 kByte PufferspeicherHera ● 24 digitale Eingänge● 8 dig. Ausgänge (solid state relays)● 8 digitale Ein- oder Ausgänge● 16-bit-Zählerdurch ihre Funktionen und ihreParameter definiert. Jeder kon-trollierbare Parameter (z.B.Strom-Sollwert eines Netzgerä-tes), auch Geräteeigenschaft ge-nannt, ist wiederum ein eigen-ständiges Objekt, für das Aktio-nen wie Lesen/Setzen, Inkremen-tieren/Dekrementieren usw. im-plementiert sind. Alle mit einerGeräteeigenschaft verbundenenKonstanten wie Minimum-/Maxi-mum-Werte, Gerätenamen und -beschreibung, usw. erhält mandirekt aus dem Objekt, d.h. eineDatenbankabfrage ist daher nichtnotwendig. Die Parameter wer-den asynchron über sog. Monitor-objekte aktualisiert CORBA als Transportprotokollwurde wegen seiner objektorien-tierten Struktur und wegen seinerUnabhängigkeit von Betriebssy-stemen und Programmierspra-chen gewählt. Die Geschwindig-keitsanforderungen und die Not-wendigkeit mit externen Treibernzu kommunizieren führte zurWahl von C++ als Programmier-sprache für die DeviceServer-Programme auf den Server-PC’s.Die Kommunikation zwischen Be-nutzer/Operateur (Clients) undGeräten (Devices) läuft vollstän-dig asynchron ab. Die Antwortender DeviceServer auf Anfragendes Clients gehen über Rückrufe(Callbacks). Eine andere Art derCallbacks sind die „repeated call-backs“, die oben schon erwähn-ten Monitore. Hierbei registriertsich ein interessierter Client beieinem oder mehreren DeviceSer-ver, um gewünschte Informatio-nen mit einer bestimmten Aktuali-sierungsrate automatisch zuge-stellt zu bekommen.Vereinfacht ausgedrückt ist dieProzesssteuerungs-Schicht imWesentlichen ein Protokollum-setzer zwischen dem LonWorks-Feldbus, an dem die Geräte an-geschlossen sind und den überdas LAN (TCP/IP) und mittelsCORBA verbreiteten Objekten,welche die tatsächlichen Gerätefür den Benutzer/Operateur (Cli-ent) modellieren. Hierbei erfülltdiese Schicht auch die Filter-und Verteilfunktion im gesamtenSystem. Abb. 3 zeigt die auf ei-nem Server-PC von 5 verschie-denen DeviceServer bereitge-stellten Geräte (exportierten Ob-jekten).Jeder Zugriff eines Benutzers/Operateurs auf das Kontrollsy-stem erfolgt über die graphischeBenutzeroberfläche (GraphicalUser Interface, GUI), welches mitder Programmiersprache Javaerstellt wurde und aus sog. „Ap-plets/Applications“ zusammenge-setzt ist. In diesen „Applications“wurden sog. „Java beans“ be-nutzt, die bei Verwendung geeig-neter Entwicklungsumgebungengraphisch, d.h. ohne eine ZeileProgrammiercode, erstellt wer-den können. Diese „beans“ kannman als einzelne Steine einesBaukastens verstehen, die manuntereinander zu einem Gesamt-gebäude zusammensetzen kann,indem man die von außen zu-gänglichen Software-Schnittstel-len der „beans“ geeignet mitein-ander verbindet.Jede „Application“ kann aus zweiTypen von „beans“ bestehen:Die Visualisierungs-Schicht305(305)Abb. 3: Bildschirm eines Server-PC‘s mit den von 5 verschiedenen Device-Server-Programmen bereitgestellten Geräten (exportierten Objekten).● „Visual beans“ (GUI Objektewie Knöpfe, Scrollbars, Anzei-gen, Diagramme, ...);● „Accelerator beans“ (auch„Abeans“ genannt; jede „Abe-an“ repräsentiert ein realesBeschleuniger-Element, z.B.ein Netzgerät oder eine Vaku-um-Pumpe).Die Kommunikation zwischen Be-nutzer/Operateur am Client-PCund dem DeviceServer auf demServer-PC der Prozesssteue-rungs-Schicht ist in solch einem„Abean“ eingekapselt, d.h. fürden Nutzer bleibt das Netzwerkunsichtbar, und damit auch dieAufgaben der Netzwerk-Kommu-nikation wie öffnen und schließeneiner Verbindung, Übertragungvon Daten, Fehlerbehandlungusw.Während die „Abeans“ selbst er-stellt wurden, sind die meisten„Visual beans“ kommerziell er-hältlich. Daher ist die wesentlicheArbeit beim Erstellen eines Be-dienfeldes für ein Gerät das ge-eignete Verbinden des entspre-chenden „Abeans“ mit denbenötigten „Visual beans“ in einergraphischen Entwicklungsumge-bung. Abb. 4 zeigt den Bildschirmeines Client-PC’s mit drei geöff-neten „Applications“ für die Netz-geräte des Injektors von ANKA.Das Kontrollsystem ist in ver-schiedenen Ausbaustufen seitOktober 1998 im Betrieb. In derersten Stufe wurde mit je einemClient- und einem Server-PC, so-wie einem einzigen LonWorks-Feldbus-Strang das 53-MeV-Microtron getestet und in Betriebgenommen. Nach der Einbindungdes 500-MeV-Booster-Synchro-trons und des 2,5-GeV-Speicher-Das Kontrollsystem imBetrieb306(306)Abb. 4: Bildschirm eines Client-PC’s mit drei geöffneten Applikationen für die Netzgeräte des Injektorsvon ANKA.rings mit ihren normalen und „ge-rampten“ Netzgeräten, des Vaku-um- und Hochfrequenzsystemsund einigen Diagnostikelementenbesteht das Kontrollsystem heuteaus folgenden Hardware- undSoftwarekomponenten:● 9 Client- und 9 Server-PC‘s,alle mit dem BetriebssystemWindows NT 4.0 Workstationmit PII/266MHz bis PIII/-500MHz CPU‘s und 256 MBRAM. Dazu kommen noch et-wa 8-10 weitere Rechner mitden verschiedensten Aufga-ben (Personensicherheit, Do-simetrie, 20 KV-Anlage, Hei-zung/Klima/Lüftung, Timing-System, weitere Diagnostik-Elemente, Teststände, Serverfür die NT-Domäne, usw.), dieüberwiegend nicht dem hiervorgestellten Kontrollsystem-Konzept zuzurechnen sind. Al-le Rechner sind untereinanderin einem strukturierten Fast-Ethernet Netzwerk (100 Mbit)über TCP/IP verbunden.● Auf den Client-PC‘s läuft dieaus Java Applets/Applicationsbestehende graphische Be-nutzeroberfläche. Dies sind imwesentlichen Tabellen mit al-len Geräten gleichen Typs(z.B.: alle Netzgeräte) oderSchalttafeln, je eine für jedesGerät. Alle Client-PC‘s sindgleich konfiguriert und habenjeweils sämtliche Programmeverfügbar.● Die DeviceServer-C++-Pro-gramme laufen verteilt auf den9 Server-PC‘s. Für jedenGerätetyp gibt es eine Device-Server-Applikation. Diese fun-giert als Software-Interfacezwischen dem Client GUI unddem Gerät, indem sie Wertezum Client und Befehle zumGerät weitergibt.● DeviceServer-Programme undClient-Applikationen kommu-nizieren mittels der CORBA-Implementation „Visibroker“(Inprise).● Insgesamt 9 LonWorks-Feld-bus-Interfacekarten in den 9Server-PC‘s sind mit allen 199I/O-Interface-Modulen (144Zeus, 39 Ariadne, 16 Hera)durch zweiadrige Kabel ver-bunden. Dies ist der Feldbus,über den die DeviceServer-Programme mit den Interface-karten und den zugehörigenGeräten kommunizieren.Momentan wird das Kontrollsy-stem weiter optimiert, während esgleichzeitig bei der Inbetriebnah-me der gesamten Beschleuniger-anlage, bestehend aus dem 53-MeV-Microtron, dem 500-MeV-Booster-Synchrotron und dem2,5-GeV-Speicherring, erfolg-reich eingesetzt wird.307(307)[1] M. Dach, S. Hunt, B. Jeram, M. Juras, K. Kenda, I. Kriznar, B. Lesjak, K. Mele, T. Milharcic,M. Perko, M. Peternel, U. Platise,M. Plesko, H. Schieler, M. Smolej,R. Sabjan, G. Zkacik, I. Verstovsek, B. Zorko, K. Zagar,PCaPAC99 workshop, Tsukuba,Japan (January 12-15, 1999)[2] K. Kenda, I. Kriznar, M. Perko, U. Platise, M. Plesko, M. Smolej,PCaPAC99 workshop, Tsukuba, Japan (January 12-15, 1999)[3] M. Plesko,PCaPAC99 workshop, Tsukuba,Japan (January 12-15, 1999)[4] M. Dach, S. Hunt, M. Plesko, G. Tkacik, PCaPAC99 workshop, Tsukuba,Japan (January 12-15, 1999)Literatur

Das Kontrollsystem für den Beschleuniger von ANKA

https://publikationen.bibliothek.kit.edu/120049061/3814042

Das Kontrollsystem für den Beschleuniger von ANKA

Abstract

Similar works

Full text

Available Versions

KITopen