Entwicklung eines Kontrollsystems für die Strahllagemessung am ...

Entwicklung eines Kontrollsystems
für die Strahllagemessung am
Protonenring des
HERA-Beschleunigers
Meßprinzip und Datennahme
Martin Weber
August 1998
Diplomarbeit in Physik
vorgelegt der
Mathematisch-Naturwissenschaftlichen Fakultät der
Rheinisch-Westfälischen Technischen Hochschule
Aachen
angefertigt im
III. Physikalischen Institut
Lehrstuhl für Experimentalphysik IIIA
(Hochschuldozent Dr. J. Tutas)

2 INHALTSVERZEICHNIS
Inhaltsverzeichnis
1 Einleitung und Überblick 5
2 Grundlagen 7
2.1 Teilchenbewegung im Speicherring . . . . . . . . . . . . . . . . 7
2.2 Arbeitspunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Luminosität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Strahlverluste und Quench . . . . . . . . . . . . . . . . . . . . 10
3 Meßprinzip 11
3.1 Messung der Strahllage . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Triggerung der Lagemessung . . . . . . . . . . . . . . . . . . . 18
3.3 Messung des Strahlverlusts . . . . . . . . . . . . . . . . . . . . 19
3.4 Alarme, Strahldump und Freeze . . . . . . . . . . . . . . . . . 21
4 Entwicklung des Kontrollsystems 22
4.1 Analyse des HERA-Kontrollsystem . . . . . . . . . . . . . . . 22
4.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Grundlegende Konzepte . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 Modularität . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2 Echtzeitfähigkeit . . . . . . . . . . . . . . . . . . . . . 25
4.3.3 Portabilität . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.4 Nebenläufigkeit . . . . . . . . . . . . . . . . . . . . . . 29
4.3.5 Wartungsfreundlichkeit . . . . . . . . . . . . . . . . . . 31
4.4 Beschleunigung der Datenauslese . . . . . . . . . . . . . . . . 32
5 Das Klassenkonzept 36
5.1 Die Klassen für den Feldbus . . . . . . . . . . . . . . . . . . . 36
5.1.1 Simulation eines Feldbusses . . . . . . . . . . . . . . . 38
5.1.2 Die SEDAC-Busklasse . . . . . . . . . . . . . . . . . . 39
5.1.3 Anpassung an andere Feldbussysteme . . . . . . . . . . 39
5.2 Module am Feldbus . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Basisklasse . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.2 Spezialisierung für HERA . . . . . . . . . . . . . . . . 43
5.2.3 Abstraktion von Registerzugriffen . . . . . . . . . . . . 43
5.2.4 Spezialisierung zur Datennahme . . . . . . . . . . . . . 45
5.3 Gruppenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 Kommunikation mit den Clients . . . . . . . . . . . . . . . . . 48

ABBILDUNGSVERZEICHNIS 3
6 Datennahme 48
6.1 Das Lagekontrollsystem . . . . . . . . . . . . . . . . . . . . . 48
6.1.1 Injektionsbetrieb . . . . . . . . . . . . . . . . . . . . . 48
6.1.2 Speicherbetrieb . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Das Verlustkontrollsystem . . . . . . . . . . . . . . . . . . . . 55
6.3 Alarme, Archivierung . . . . . . . . . . . . . . . . . . . . . . . 56
7 Tests 58
7.1 Messung der Busgeschwindigkeit . . . . . . . . . . . . . . . . . 58
7.2 Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2.1 Das Testprogramm . . . . . . . . . . . . . . . . . . . . 64
7.3 Messungen mit dem Lagekontrollsystem . . . . . . . . . . . . 66
7.3.1 Messung des Orbits . . . . . . . . . . . . . . . . . . . . 67
7.3.2 Untersuchung des zeitlichen Verhaltens . . . . . . . . . 68
7.3.3 Messungen an einer Beule . . . . . . . . . . . . . . . . 69
7.4 Messungen mit dem Verlustkontrollsystem . . . . . . . . . . . 73
7.5 Automatische Archivierung bei Freeze . . . . . . . . . . . . . . 76
7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 78
A Das Pthread-Interface für VxWorks 79
Abbildungsverzeichnis
1 Mitbewegtes Koordinatensystem im Speicherring . . . . . . . 7
2 Position der Elektroden in der Strahlröhre . . . . . . . . . . . 13
3 Prinzip der Strahlankopplung . . . . . . . . . . . . . . . . . . 14
4 Signalverhältnis V1/V2 der Elektroden . . . . . . . . . . . . . . 15
5 Konvertierung Amplitudenverhältnis in Betrag und Phase . . . 15
6 Schematischer Aufbau des PPD-Moduls . . . . . . . . . . . . . 17
7 Das Client-Server Modell . . . . . . . . . . . . . . . . . . . . . 22
8 Die zur DAQ verwendeten Threads . . . . . . . . . . . . . . . 31
9 Übersicht über den HERA-Beschleuniger . . . . . . . . . . . . 32
10 Verschiedene mögliche Netztopologien mit SEDAC . . . . . . . 34
11 SEDAC-Verbindungen des alten und neuen Kontrollsystems . 34
12 Übersicht über die Klassenstruktur . . . . . . . . . . . . . . . 37
13 Fehler durch nichtabgesicherte Zugriffe . . . . . . . . . . . . . 42
14 Durch Schloßvariablen abgesicherte Zugriffe . . . . . . . . . . 44
15 Datennahme im Injektionsmodus . . . . . . . . . . . . . . . . 50
16 Ablauf der Datennahme im Single-Turn-Modus . . . . . . . . 52
17 Ablauf der Datennahme im Orbit-Modus . . . . . . . . . . . . 54

4 TABELLENVERZEICHNIS
18 Automatische Anpassung der Alarmschwellen . . . . . . . . . 57
19 Das vom DESY zur Verfügung gestellte Testsystem in Aachen 59
20 Durchschnittliche SEDAC-Übertragungsfrequenz . . . . . . . . 63
21 Die grafische Oberfläche des Testprogramms . . . . . . . . . . 65
22 Ein mit dem neuen Kontrollsystem gemessener Orbit . . . . . 67
23 Zeitliche Entwicklung der zuletzt gemessenen Positionsdaten . 68
24 Zeitliche Entwicklung von gemittelten Positionsdaten . . . . . 69
25 Beule in der x-Ebene, maximal positive Auslenkung . . . . . . 70
26 Beule in der x-Ebene, maximal negative Auslenkung . . . . . 71
27 Dreidimensionale Darstellung einer Beule in der x-Ebene . . . 71
28 Zeitlicher Verlauf einer Beule in der x-Ebene . . . . . . . . . . 72
29 Dreidimensionale Darstellung einer Beule in der y-Ebene . . . 74
30 Zeitlicher Verlauf einer Beule in der y-Ebene . . . . . . . . . . 74
31 Eine Strahlverlustmessung im Quadranten West . . . . . . . . 75
32 Noch eine Strahlverlustmessung im Quadranten West . . . . . 75
33 Strahlverlustmessung mit dem CERN-Verlustmonitor . . . . . 76
Tabellenverzeichnis
1 Kritische kontinuierliche Proton-Verlustraten . . . . . . . . . . 12
2 Maximale SEDAC-Übertragungsraten (1 Busleitung) . . . . . 58
3 Maximale parallele SEDAC-Übertragungsraten (2 Busleitungen) 61
4 Liste von Monitoren . . . . . . . . . . . . . . . . . . . . . . . 69
5 Unterstütze Funktionen des Pthread-Interface . . . . . . . . . 79

1 Einleitung und Überblick
Neben der Bedeutung der Physik als reine Grundlagenforschung und dem
Nutzen ihrer Ergebnisse zur Erweiterung unseres Weltbildes ist ein markantes
Merkmal der heutigen Physik, daß sie die gegebenen technischen Möglichkeiten
nicht nur ausschöpft, sondern sogar erweitert. Um der Natur immer
weitere ihrer vielen Geheimnisse abzuringen, werden z. B. in den Großforschungszentren
der Elementarteilchenphysik wie dem CERN 1 in Genf und
dem DESY 2 in Hamburg komplexe Theorien mit ausgeklügelten Experimenten
überprüft, deren Ziel darin besteht
Daß ich nicht mehr, mit sauerm Schweiß,
Zu sagen brauche, was ich nicht weiß,
Daß ich erkenne, was die Welt
Im Innersten zusammenhält,
Schau’ alle Wirkenskraft und Samen,
und tu’ nicht mehr in Worten kramen. [8]
Oft werden dabei bisher unbekannte Wege begangen. Neue Impulse für Wirtschaft
und Technik sind als “spin-offs” dieser Forschungstätigkeit nicht selten.
Man denke z. B. an das WWW 3 , dessen Ursprung am CERN liegt und dessen
Siegeszug durch die Gesellschaft gerade erst begonnen hat.
Speziell am DESY werden seit 1992 im Speicherring HERA 4 Protonen und
Elektronen 5 an zwei Stellen zur Kollision gebracht und die Reaktionsprodukte
mit Hilfe der Universaldetektoren H1 und ZEUS untersucht. Zwei Fixed-
Target-Experimente, HERMES und HERA-B, die nur Elektronen bzw. Protonen
verwenden, vervollständigen die Forschung mit HERA.
Die Aufgaben dieser Experimente liegen darin, die Vorhersagen der Quantenfeldtheorien
QED 6 , QCD 7 und QFD 8 zu überprüfen, aber auch nach Physik
zu suchen, die über diese im “Standardmodell der Teilchenphysik” zusammengefaßten
Theorien hinausgeht. Dies alles geschieht bei einer bisher im
e-p-System von anderen Beschleunigern nicht erreichten Schwerpunktsenergie
von ECMS = 300 GeV bei einer Protonenergie von Ep = 820 GeV und
einer Elektronenergie von Ee = 27.5 GeV [17].
1Conseil Européen pour la Recherche Nucléaire
2Deutsches Elektronen- Synchrotron
3World Wide Web
4Hadron-Elektron Ring-Anlage
5bzw. von 1994 bis 1997 deren Antiteilchen, die Positronen
6Quantenelektrodynamik 7 Quantenchromodynamik
8 Quantenflavordynamik
5

6 1 EINLEITUNG UND ÜBERBLICK
Die Protonen müssen präzise durch die in einem unterirdischen Tunnel untergebrachte,
zu einem Ring geschlossene Strahlröhre geführt werden, damit
sie nicht frühzeitig verloren gehen und möglichst lange für die Experimente
zur Verfügung stehen. Dafür müssen viele Parameter von HERA laufend gesteuert
und überwacht werden. Dies ist Aufgabe des HERA-Kontrollsystems.
Die vorliegende Diplomarbeit stellt ein neues Kontrollsystems für die Messung
der Strahllage und des Strahlverlustes im Protonring vor. Denn deren
Überwachung ist Grundlage für eine gezielte Kollision der Teilchen und eine
sichere Funktion des Beschleunigers. Beide Systeme sind hardwaremäßig so
eng miteinander verbunden, daß eine Neuentwicklung des Lagekontrollsystem
eine gleichzeitige Neuentwicklung des Verlustkontrollsystems mit einschließt.
Die für das Verständnis der vorliegenden Diplomarbeit nötigen Grundlagen
werden in Kapitel 2 gelegt. In Kapitel 3 wird das Meßprinzip der Strahllageund
Strahlverlustmessung erläutert. Dann wird nach einer kurzen Analyse
des HERA-Kontrollsystems die Entwicklung des neuen Kontrollsystems
in Kapitel 4 vorgestellt. In Kapitel 5 wird das zur Realisierung verwendete
Klassenmodell genauer vorgestellt. Kapitel 6 erläutert die Datennahme für
die verschiedenen Betriebsarten des Kontrollsystems. Abschließend werden
in Kapitel 7 Testergebnisse vorgestellt.
Am Ende der vorliegenden Diplomarbeit befindet sich ein ausklappbares
Glossar, das häufig verwendete Begriffe und Abkürzungen enthält. Die dort
aufgeschlüsselten Abkürzungen werden zwar auch in Fußnoten erklärt, sind
aber im Glossar noch mit einer zusätzlichen Erklärung versehen. Leider mußte
die Schriftgröße sehr klein gewählt werden, um alle Begriffe auf einer Seite
unterzubringen.
Danken möchte ich an dieser Stelle Hochschuldozent Dr. J. Tutas für das
interessante Thema, für die bereitwillige Hilfe bei Problemen und für den
Freiraum, den er mir bei meiner Arbeit gab, Timm Steinbeck und meinen
Eltern für viele nützliche Hinweise zur Niederschrift, Manfred Wendt für seine
gute Betreuung am DESY und für seinen Einsatz während der Messungen,
Steve Herb für zahlreiche Tips und das mehrfach ausgeborgte VME-Crate,
Matthias Werner für die zur Verfügung gestellte Grafik, vor allem aber meiner
Frau für die Unterstützung meiner Arbeit und das geduldige Warten, wenn
mich die Arbeit wieder einmal länger als geplant aufhielt, und allen anderen,
die bei der Entwicklung meiner Diplomarbeit geholfen haben.

2 Grundlagen
2.1 Teilchenbewegung im Speicherring
Die Beschreibung der Protonbewegung im Speicherring erfordert die Einführung
von zwei Koordinatensystemen: Eines, in dem der durch die Beschleunigerkonstruktion,
d. h. die Anordnung der Magnete, vorgegebene Idealweg
durch den Beschleuniger beschrieben wird und ein zweites, das diesem
Weg folgt und die Abweichung der Protonen gegenüber dem Idealweg angibt
(Abb. 1). Die Wahl der Koordinatenachsen geschieht so, daß der Vek-
x
x
y
y
tatsächliche Teilchenbahn
z
ideale Teilchenbahn
Abbildung 1: Mitbewegtes Koordinatensystem im Speicherring
tor z tangential zur Idealbahn ist und in die Flugrichtung des Teilchens
zeigt. Die verbleibenden Vektoren x und y wählt man so, daß y senkrecht
auf der Beschleunigerebene steht und x in dieser Ebene liegt. Dabei bilden
(x, y, z) ein rechtshändiges System. Diese Wahl vereinfacht die Form der Bewegungsgleichungen.
Die Koordinaten des Protons im mitbewegten System
sind xp = (x, y, 0). Anstatt der zeitlichen Veränderung von x und y betrachtet
man die Änderung entlang der dritten Komponente, d. h. die Größen dx/dz
und dy/dz.
Ohne Einwirkung einer äußeren Kraft bewegen sich Teilchen stets gleichförmig
und geradlinig. Die Protonen müssen sich in HERA aber stets auf
einer geschlossenen Kreisbahn bewegen. Die dafür nötige Krümmung erreicht
man mit Hilfe der Lorentzkraft
F = q( E + v × B) (1)
In der Praxis verwendet man zur Bahnkrümmung stets magnetische Felder,
so daß E = 0 gesetzt wird. Um das Kreuzprodukt vereinfachen zu können,
7

8 2 GRUNDLAGEN
wird das Magnetfeld B = (Bx(y), By(x), 0) in einer Multipolentwicklung angenähert:
e
p By(x) = e
p By0 + e
p
e
2! p
d 2 By
dx 2 x 2 + · · ·
dBy 1
x + dx
= − 1
1
+ kx + R 2! mx2 + · · ·
= Dipol + Quadrupol + Sextupol + · · ·
Für die Herleitung der Bewegungsgleichungen nimmt man zunächst nur Dipol-
und Quadrupolfelder an. Weiterhin sollen Dipole nur zur Bahnkrümmung
in der Beschleunigerebene y = 0 benutzt werden, das bedeutet Bx0 = 0.
Diese Annahme ist bei HERA (und den meisten anderen Teilchenbeschleunigern)
erfüllt. Die Bewegungsgleichungen9 erhalten dann die Form
x ′′ (z) +
1
R2
− k(z)
(z)
x(z) =
1 ∆p
R(z) p
(2)
(3)
y ′′ (z) + k(z)y(z) = 0 (4)
Der Faktor ∆p/p gibt die relative Impulsabweichung des Protons vom Sollwert
an. Die Bewegungsgleichungen sind Differentialgleichungen zweiter Ordnung,
deren Lösung durch die Angabe zweier Konstanten festgelegt ist. Um
die einfachste Lösung von (4) zu erhalten, betrachtet man nur Teilchen mit
Sollimpuls, d. h. ∆p = 0, und vernachlässigt den Einfluß der Dipole gegenüber
den Quadrupolen, da10 1/R2 ≪ k. Die Gleichungen für die horizontale und
vertikale Teilchenbewegung erhalten damit die gleiche Form. Da sie einer
Schwingungsgleichung ähnlich sind, macht man den physikalisch motivierten
Ansatz einer Schwingung, deren Amplitude und Phase durch die Änderung
von Dipol- und Quadrupolstärke entlang der Teilchenbahn von der Koordinate
z abhängig ist:
x(z) = √
ɛ β(z) cos(Ψ(z) + ψ0) (5)
Da die in der Schwingungsgleichung als ω 2 bekannte Konstante durch eine
Funktion ersetzt wird, erwartet man auch nur eine neue Funktion in der
Lösung. Dementsprechend erhält man durch Einsetzen für die Phase Ψ(z)
die von β(z) abhängige Lösung
Ψ(z) =
z
0
dσ
β(σ)
9 Für eine Herleitung siehe z. B. [22, 24]. Man beachte bei [24], daß ein linkshändiges
Koordinatensystem verwendet wird, bei der Berechnung des Vektorproduktes aber
ein rechtshändiges System zugrundegelegt wird, was zwischenzeitlich zu Vorzeichenfehlern
führt. Die Herleitung in [22] ist korrekt.
10 Bei HERA ist k ≈ 0.033 m −2 , 1/R 2 ≈ 2.9 · 10 −6 m −2 [15]
(6)

2.2 Arbeitspunkt 9
und für β(z) die Differentialgleichung
2β ′′ (z)β(z) − β ′ (z) − 4k(z) = 0, (7)
die nur numerisch gelöst werden kann. Man nennt β(z) die Betafunktion oder
Betatronamplitude, ψ(z) nennt man Betatronphase. Die Betafunktion wird
durch k(z), also die Anordnung der Quadrupolmagnete bei HERA, vorgegeben.
Sie bestimmt die maximale Amplitude, die die Teilchen beim Durchlaufen
der Beschleunigerstruktur haben können. Alle tatsächlich vorkommenden
Teilchenbahnen laufen innerhalb dieser Einhüllenden.
2.2 Arbeitspunkt
Eine weitere wichtige Größe für den Betrieb von HERA ist der Arbeitspunkt
oder Q-Punkt des Beschleunigers. Er ist eng mit der Betafunktion verknüpft
und definiert durch
Q = 1
2π
dz
β(z)
1 L dz ∆Ψ
= =
2π 0 β(z) 2π
und entspricht anschaulich der Anzahl von Schwingungen, die der Strahl
bei einem Umlauf durch den Beschleuniger um seine Sollbahn ausführt. Sein
Wert ist für die Stabilität der Teilchenbewegung wichtig. Der Nachkommaanteil
von Q bestimmt, wie sich die Betatronphase ψ von Umlauf zu Umlauf
verschiebt. Kommt nach einer Anzahl n von Umrundungen des Beschleunigers
wieder dieselbe Phasenlage ψ vor, so können sich Magnetfehler, die eine
Ablenkung der Teilchen von der Sollbahn bewirken, resonant verstärken. Dadurch
kann der Strahl verloren gehen. Die Resonanzbedingung ist
(8)
n∆ψ = 2π bzw. n∆Q = 1 (9)
Dementsprechend müssen Werte Q = m + 1/n (wobei m und n ganze Zahlen
sind) vermieden werden. Je kleiner n ist, desto mehr verstärken sich die
Fehler (da bei mehr Umrundungen die gleiche Phasenlage vorherrscht). Ideal
wäre als Q-Wert eine irrationale Zahl. Da irrationale Zahlen aber sehr
dicht an Bruchzahlen liegen, versucht man, nur die stärksten Resonanzen
(etwa von n = 1..7) zu vermeiden [24]. Die Kenntnis und damit die Messung
des Q-Wertes ist damit von entscheidender Bedeutung für die Stabilität des
Beschleunigers. Eine Möglichkeit, den Arbeitspunkt zu bestimmen, ist die
Strahllage im Beschleuniger über viele Umläufe zu beobachten und die Anzahl
der Nulldurchgänge zu zählen. Um diese auflösen zu können, dürfen die
Lagemonitore maximal 90 ◦ in der Betatronphase auseinanderliegen, denn
sonst können nicht alle Schwingungen rekonstruiert werden. Der Q-Wert von
HERA ist Q = 31.3 sowohl für die horizontale als auch die vertikale Teilchenbewegung.

10 2 GRUNDLAGEN
2.3 Luminosität
Der für die Experimente wichtigste HERA-Parameter ist die Luminosität L,
weil sie die Rate der zu untersuchenden Ereignisse über
dN
dt
= σL (10)
bestimmt. Der Wirkungsquerschnitt σ der zu untersuchenden Reaktion ist
durch die Natur vorgegeben und wird von den Quantenfeldtheorien vorhergesagt,
d. h. er läßt sich nicht durch die Experimentieranordnung verändern.
Um die Meßzeiten für statistisch signifikante Aussagen gering zu halten, muß
deshalb eine ausreichende Luminosität vorhanden sein. Die Luminosität berechnet
man im Fall von HERA zu
L = 1 fuNpNe
4π σxσy
(11)
mit der Umlauffrequenz fu und den Teilchenzahlen Np und Ne für Protonund
Elektronstrahl. Daß bei HERA das Ziel einer Luminosität von 1.5 ·
10 31 cm −2 s −1 mit L = 1.4 · 10 31 cm −2 s −1 fast erreicht wurde, ist nur dem
geringen Strahlquerschnitt von σx = 200 µm und σy = 54 µm an den Wechselwirkungspunkten
von H1 und ZEUS zu verdanken, denn die Werte von Np
und Ne blieben hinter dem gesteckten Ziel zurück [17, 25]. Für die Zukunft ist
eine Erhöhung der Luminosität geplant, bei der der Strahlquerschnitt weiter
auf σx = 118 µm und σy = 32 µm verkleinert werden soll [17, 25, 34].
Das Erreichen solch kleiner Strahlquerschnitte, d. h. kleiner Betafunktion
β(z), ist nur mit einer exakten Fokussierung durch Quadrupolmagnete möglich.
Dafür müssen die Protonen möglichst genau auf dem “Orbit”, dem durch
die Beschleunigerkonstruktion vorgegebenen Idealweg, geführt werden — eine
schwierige Aufgabe. Erst durch die Messung der Strahllage (BPM 11 ) können
Abweichungen vom Orbit erkannt werden und der Protonstrahl durch Orbit-
Korrekturen präzise durch die Mitte der Quadrupolmagnete geführt werden
[18].
2.4 Strahlverluste und Quench
Um die Protonen bei Energien von bis zu Ep = 820 GeV durch den Protonring
zu führen, sind Magnetfelder mit einer Feldstärke von B = 4.68 T
erforderlich, die nur durch supraleitende Magnete erzeugt werden können. Bei
HERA werden 1819 supraleitende Magnete verwendet, was weltweit erstmalig
in dieser Anzahl geschah [23]. Die Verwendung supraleitender Magnete
11 Beam Position Measurement

irgt in sich die Gefahr eines “Quenches”, d. h. den plötzlichen Übergang
vom supraleitenden in den normalleitenden Zustand [24]. Dieser Übergang ist
nicht nur von der Temperatur abhängig, wie oft fälschlicherweise angenommen
wird, sondern zusätzlich von der magnetischen Feldstärke. Man kann
den Verlauf der Grenzfeldstärke, ab der es zu einem Zusammenbruch der
Supraleitung kommt, beschreiben als
T
Bc(T ) = Bc(T = 0) 1 −
Tc
2
11
(12)
Bei einer geringen Erhöhung der Temperatur T , die dann immer noch unter
der kritischen Temperatur Tc liegen kann, verringert sich die kritische
Feldstärke Bc. Liegt diese dann unterhalb der im Magneten vorhandenen
Feldstärke B, so kommt es zu einem Zusammenbruch der Supraleitung. Dabei
wird der Magnet durch die abgegebene ohmsche Wärme erhitzt. Die Wärmeleitung
in eventuell noch nicht gequenchte Teile des Magneten führt zu einer
Ausbreitung des normalleitenden Bereiches. Da bei zu großer Erwärmung der
Magnet zerstört werden kann, ist der Schutz der Magneten vor einem Quench
eine wichtige und sicherheitsrelevante Aufgabe des HERA-Kontrollsystems.
Ein Grund, durch den es zu einem Quench kommen kann, sind Verluste
von Protonen und nachfolgende Teilchenschauer in die Magnete, die dort
Energie deponieren. Beim Betrieb von HERA wird deshalb der Strahlverlust
überwacht und bei Gefahr für die Magnete der Strahl ejiziert. Dies geschieht
durch die Strahlverlustmessung.
Strahlverluste entstehen hauptsächlich an Stellen mit großer Betafunktion
β(z) und an den Kollimatoren, an denen der Durchmesser des Strahles —
z. B. zum Schutz der Universaldetektoren — begrenzt werden soll [28]. Die
bei Ep = 820 GeV im HERA-Protonring gespeicherte Energie beträgt E =
1.8 MJ, wohingegen das Quench-Limit eines supraleitenden Magneten bei
etwa Ecrit,quench = 1 mJ/g liegt [16].
Durch die Kühlung mit flüssigem Helium kann jedoch bei länger andauernder
Energiedeposition Wärme abgeführt werden. Deshalb kann der Magnet kontinuierliche
Verluste bis hin zu einer kritschen Verlustrate aufnehmen. Erst
bei Überschreitung dieser kritischen Verlustrate, die von der Protonenergie
abhängig ist, kommt es zu einem Quench. Für einige Energien sind die kritischen
Raten für kontinuierliche Protonverluste in Tabelle 1 wiedergegeben.
3 Meßprinzip
Der Protonstrahl besteht aus 180 Protonpaketen mit jeweils 7.7 · 10 10 Protonen.
Der zeitliche Abstand zwischen zwei Paketen beträgt 96 ns. Die La-

12 3 MESSPRINZIP
Impuls Kritische Verlustrate
GeV/c Protonen/s
40 320 · 10 11
100 11.2 · 10 11
400 0.48 · 10 11
820 0.032 · 10 11
Tabelle 1: Kritische kontinuierliche Proton-Verlustraten
gemessung ist dafür ausgelegt, die Ablage eines einzelnen, frei auswählbaren
Protonpaketes durch den gesamten Beschleuniger zu verfolgen [18]. Das
erfordert ein intelligentes Timing-System, das die Messung in genau dem
Augenblick auslöst, in dem das ausgewählte Protonpaket vorbeifliegt.
Außerdem kann für jede Stelle, an der die Lage gemessen wird, ein Limit
für die maximale Ablage des Strahles eingestellt werden, bei dessen Überschreitung
ein Alarm ausgelöst wird. Das kann zu einer kontrollierten Ejektion
benutzt werden, bevor der intensive Protonstrahl z. B. in den Magneten
Schaden anrichten kann. Es hat sich jedoch herausgestellt, daß die Strahllagemonitore
durch ihre komplexe Elektronik fehleranfällig sind und diese Art
der Kontrolle keinen guten Schutz vor einem Quench gewährleisten kann,
weil falsche Alarme erzeugt werden. Deshalb wird die Erzeugung von Alarmen
durch die Lagemonitore nicht mehr benutzt.
Stattdessen wurden spezielle Strahlverlustmonitore entwickelt, die diese Aufgabe
übernehmen. Sie sind an den supraleitenden Quadrupolen, an den normalleitenden
Quadrupolen und an den Kollimatoren installiert [16]. Die Strahlverlustmonitore
können — ähnlich wie die Lagemonitore — bei Überschreitung
einer wählbaren Verlustschwelle einen Alarm auslösen. Die von den
Verlustmonitoren gemeldeten Alarme werden dazu benutzt, bei zu großen
Verlusten den Protonstrahl zu ejizieren.
Alle für diese Aufgaben nötigen Geräte wurden auf Basis von NIM-Modulen
entwickelt und für die Auslese mittels SEDAC 12 , einem DESY-eigenen Feldbussystem,
vorgesehen. Deshalb werden sie häufig als SEDAC-Module bezeichnet.
Die Module zur Lage- und Verlustmessung sind mit dem Modul,
das die von ihnen erzeugten Signale registriert und an die Alarmzentrale
weiterleitet, jeweils in einem Crate untergebracht. Zusätzlich befindet sich in
jedem solchen Crate ein Crate-Controller, der die Kommunikation über eine
SEDAC-Leitung ermöglicht. Die Module müssen deswegen über dieselbe
SEDAC-Leitung angesprochen werden. Da nur jeweils ein Computer Daten
12 Serial Data Acquisition and Control

3.1 Messung der Strahllage 13
über die Leitung senden kann, ist das Lagekontrollsystem auch gleichzeitig
das Verlustkontrollsystem und für die Auslese des Alarmstatus zuständig.
3.1 Messung der Strahllage
Zur Messung der Strahllage werden Elektroden benutzt, die an das elektromagnetische
Feld der vorbeifliegenden Protonpakete koppeln und innerhalb
der Strahlröhre angebracht sind. Ihre Position wird so ausgewählt, daß sie
zum einen zur Berechnung des Q-Werts maximal 90 ◦ in der Betatronphase
auseinanderliegen und zum anderen zur Überprüfung der Fokussierung
durch die Quadrupolmagnete stets hinter einem fokussierenden Quadrupol
angebracht sind. Da ein Quadrupol, der in einer Ebene stets fokussiert, stets
in der anderen Ebene defokussiert [24], wechseln sich die Meßpositionen von
x- und y-Ablage wechselseitig ab.
Die Abb. 2 zeigt die Position der Elektroden in der Strahlröhre für eine
Messung der horizontalen bzw. vertikalen Ablage. Es gehören jeweils zwei
Elektroden zusammen, sie sind in der Strahlröhre an gegenüberliegenden Positionen
angebracht. Die Elektroden bilden zusammen mit dem Strahl einen
Antennen
y y
Aufbau horizontale Messung
Protonstrahl
Vakuumkammer
Antennen
x x
Aufbau vertikale Messung
Abbildung 2: Position der Elektroden in der Strahlröhre
Sechspol. Dabei sind Ein- und Austrittspunkt des Strahles sowie Ein- und
Ausgang der beiden Elektroden jeweils ein Pol. Diese Situation wird in Abb. 3
gezeigt. Die Berechnung der Kopplungskoeffizienten ist kompliziert. Wie in
[11] gezeigt wird, ist das Verhältnis der an den Punkten 1 und 2 abgegriffenen

14 3 MESSPRINZIP
Teilchenstrahl
6 5
Vakuumkammer
3 (Masse)
4 (Masse) Antenne
Abbildung 3: Prinzip der Strahlankopplung
Signalspannungen V1 und V2 näherungsweise durch die Funktion
V1
V2
[dB] = 20 log 10
f(ɛx, −ɛy, φ0) − f(ɛx, −ɛy, −φ0)
f(−ɛx, ɛy, φ0) − f(−ɛx, ɛy, −φ0)
1
2
(13)
gegeben. Dabei sind ɛx = x/R die normierte horizontale Position, ɛy = y/R
die normierte vertikale Position, R = 27.65 mm der Radius der Vakuumkammer
und φ0 = 0.628 die der Elektrodenlänge entsprechende elektrische
Phase. Die Funktion f(ɛx, ɛy, φ0) ist gegeben durch
f(ɛx, ɛy, φ0) = arctan
((1 + ɛx) 2 + ɛ2 y ) tan(φ0/4)
+ 2ɛy
1 + ɛ 2 x − ɛ2 y
(14)
Das Signalspannungsverhältnis ist in Abb. 4 dargestellt. Für eine Strahlablage
|x| < 10 mm erhält man angenähert ein lineares Verhältnis. Für größere
Strahlablagen weicht das Verhältnis leicht davon ab. Die von den Elektroden
aufgenommenen Spannungspulse müssen für eine Auswertung natürlich noch
weiterverarbeitet werden. Das geschieht durch zwei verschiedene SEDAC-
Module, nämlich durch PPA 13 und PPD 14 . Beide SEDAC-Module enthalten
jeweils zwei Kanäle, die an benachbarten Quadrupolen messen. Deshalb mißt
ein Kanal stets die x-Ablage und der andere die y-Ablage. Der Aufbau der
beiden Kanäle ist dabei identisch.
Das PPA wandelt das Amplitudenverhältnis der Spannungen V1/V2 in Betrag
und Phase um. Die Funktionsweise des Phasenkonverters ist aus Abb. 5
ersichtlich. Dabei ist der Betrag eine Funktion der Intensität (d. h. der Teil-
13 Proton-Position Analog Module
14 Proton-Position Digital Module

3.1 Messung der Strahllage 15
V1/V2 in dB
30
20
10
-20 -10 0
10
x in mm
20
-10
-20
-30
Abbildung 4: Signalverhältnis V1/V2 der Elektroden
✻
☞
✚ ✁
✚✚✚✚✚
|V2|
|r|
φ
|V1|
Abbildung 5: Konvertierung Amplitudenverhältnis in Betrag und Phase
✲

16 3 MESSPRINZIP
chenzahl) des Protonpakets, und die Phase eine Funktion der Strahlablage
[11]. Anschließend werden die Intensitäts- und Lageinformationen werden mit
einer Auflösung von 8 Bit digitalisiert und an das PPD weitergereicht.
Der analoge Teil der Elektronik (PPA) ist in der Lage, jedes vorbeikommende
Protonpaket zu messen. Das entspricht bei 96 ns Paketabstand einer
Frequenz von etwa 10.4 MHz. Die Digitalelektronik ist mit dieser Datenrate
überfordert. Deshalb werden nicht alle Pakete gemessen, sondern alle bei HE-
RA installierten PPD-Module messen dasselbe Paket. Das geschieht mit Hilfe
des HIT 15 -Systems. Alle Positionsmonitore erhalten durch das HIT-System
genau dann einen Trigger, wenn das ausgewählte Protonpaket vorbeifliegt.
Damit über den gesamten HERA-Ring ein spezieller Umlauf selektiert werden
kann, wurde das folgende Schema implementiert: In jedem PPD-Modul
befindet sich ein Zähler, der sogenannte SID 16 -Zähler. Er wird bei jedem vom
HIT-System ankommenden Triggersignal erhöht und zählt somit die Umläufe
der Protonpakete. Intern werden alle Aktionen auf den Stand dieses Zählers
synchronisiert. Werden vom HIT-System für eine gewisse Zeit keine Trigger
gesendet, so wird in allen PPD-Modulen der SID-Zähler auf Null zurückgesetzt.
Von da an enthalten alle PPD-Module denselben Zählerstand [11].
Der Aufbau des PPD-Moduls ist in Abb. 6 schematisch wiedergegeben. Es
befindet sich direkt neben dem PPA-Modul in demselben Crate. Es erhält die
Positions- bzw. Intensitäts-Daten beider Kanäle des PPA-Moduls über den
oberen, normalerweise unbenutzten Stecker an der Rückseite des SEDAC-
Crates. Die Positionsdaten gelangen in einen Ringpuffer, der bis zu 1024
aufeinanderfolgende Positionen abspeichern kann. Dieser Ringpuffer ist für
die Post-Mortem-Analyse nach einer Ejektion des Protonstrahles vorgesehen.
Er kann aber auch dazu verwendet werden, den Arbeitspunkt des Beschleunigers
zu bestimmen.
Ein kleinerer Ringpuffer, der 256 Positionen speichern kann, kann wie der
Post-Mortem-Speicher Daten aufeinanderfolgender Positionen aufnehmen.
Wahlweise können aber auch Mittelwerte von jeweils 128 aufeinanderfolgenden
Umläufen abgespeichert werden, so daß insgesamt Informationen über
256 · 128 = 32768 Umläufe eines Protonpaketes vorliegen. Dies entspricht
einem Zeitraum von 688 ms.
Wie das PPA-Modul, besteht auch das PPD-Modul aus zwei Kanälen. Deshalb
sind die Speicher doppelt vorhanden: Einmal für die Messung der x-
Ablage und einmal für die Messung der y-Ablage. Beide Kanäle teilen sich
aber eine Steuer- und Kontrolleinheit.
Die Einstellung der verschiedenen Parameter sowie die Auslese der Speicher,
15 HERA Integrated Timing
16 Synchrotronic Identification

3.1 Messung der Strahllage 17
Abbildung 6: Schematischer Aufbau des PPD-Moduls. Mit freundlicher Genehmigung
von Manfred Wendt, DESY MKI

18 3 MESSPRINZIP
der Mittelwerte, der Positionsdaten und der Intensität, die nicht zwischengespeichert
wird, geschieht durch die Steuer- und Kontrolleinheit über SEDAC.
3.2 Triggerung der Lagemessung
Das HIT-System generiert aus der Hochfrequenz von HERA eine zeitliche
Abfolge von Triggerpulsen, die über ein Koaxialkabel entlang dem Beschleuniger
propagieren. Für jeden Positionsmonitor ist ein Triggerpuls in dieser
Kette gedacht. Da sich die Protonen mit nahezu Lichtgeschwindigkeit c bewegen,
elektrische Signale sich aber nur mit etwa v = c/3 übertragen lassen,
werden die Pulse gegen die Flugrichtung der Protonen losgeschickt. Die
Laufzeiten der Signale sind so berechnet, daß die Ankunftszeit dieses Pulses
mit dem Vorbeifliegen des ausgewählten Paketes übereinstimmt. Der für das
PPA-Modul zugedachte Puls wird von einem im selben Crate untergebrachten
weiteren SEDAC-Modul, dem MTM 17 aus der Triggerkette herausgefiltert.
Wie es jedoch manchmal so geht, wurde nach der Planungsphase dieser
Module am DESY beschlossen, die Anzahl der SEDAC-Crates für die Lagemessung
um den Faktor zwei zu reduzieren. Statt einem Paar von PPAund
PPD-Modul sind deshalb in den meisten Crates jeweils zwei Paare untergebracht.
Das oben erwähnte Triggerschema funktionierte zwar noch, war
aber sehr unflexibel, da sich die Triggerpulse in der vom HIT-System erzeugten
Triggerkette nicht beliebig verschieben lassen und deshalb zusätzliche
Kabel zur Verzögerung eingebaut werden mußten. Deshalb ging man den folgenden
Weg: In jedes dieser Crates wurde noch ein zusätzliches Modul, das
DLY 18 -Modul, eingebaut, das aus einem von dem MTM eingehenden Puls
zwei Pulse für die beiden PPA-Module generiert. Da die PPA-Module an
zwei unterschiedlichen Positionen messen, sind die Laufzeiten der von den
Elektroden aufgenommenen Signale unterschiedlich. Dementsprechend muß
der von dem MTM herausgefilterte Triggerpuls für ein PPA verzögert werden.
Das geschieht über Delays in dem DLY-Modul, die sich über SEDAC
auslesen und setzen lassen.
Ein weiteres Modul, das PMST 19 -Modul, ist für die Triggerung der Lagemonitore
wichtig. Alle vom HIT-System erzeugten Pulsketten passieren das
PMST-Modul, bevor sie zu den Monitor-Trigger-Modulen in den Hallen gelangen.
Das PMST-Modul erlaubt, die ansonsten kontinuierliche Folge von
Trigger-Pulsen gezielt zu unterbrechen.
Es kann in zwei Betriebsarten benutzt werden. Der “kontinuierliche Mode”
ist für die Synchronisation der PPD-Module im Speicherbetrieb gedacht (vgl.
17 Monitor-Trigger-Modul
18 Delay-Modul
19 PM-Bit-Steuerung

3.3 Messung des Strahlverlusts 19
Abschnitt 3.1). Dabei werden alle vom HIT-System übermittelten Pulse standardmäßig
durchgelassen. Mit einem Signal über SEDAC kann diese Triggerkette
für 100 Pulse unterbrochen werden. Dadurch wird der SID-Zähler in
allen PPD zurückgesetzt, die damit synchronisiert sind.
Im “getriggerten Mode” werden standardmäßig keine Triggerpulse durchgelassen.
Erst nachdem ein Signal über SEDAC das PMST-Modul erreicht,
oder eine Injektion von PETRA 20 erfolgt, wird eine genau definierte Anzahl
von Triggerpulsen durchgelassen. Diese Anzahl kann vorher im Bereich von
1-9999 beliebig gesetzt werden. Nachdem die gewählte Anzahl Pulse durchgelassen
wurde, werden wieder alle Pulse unterdrückt.
3.3 Messung des Strahlverlusts
Protonen wechselwirken — anders als Elektronen — auch durch die starke
Wechselwirkung. Das führt dazu, daß die Protonen in inelastischen Reaktionen
beim Zusammenstoß mit Atomkernen hadronische Teilchen erzeugen.
Diese wechselwirken in der Materie über verschiedene Mechanismen wie
Spallation und Spaltung und erzeugen einen hadronischen Schauer. Dabei
entstehen auch geladene Teilchen, die durch Ionisation Elektronen aus dem
Material auslösen. In nachfolgenden elektromagnetischen Reaktionen werden
Schauer von Photonen und Elektronen erzeugt, die sich über Paarbildung,
Comptoneffekt und Photoeffekt immer weiter verzweigen. Eine weitere Quelle
von Photonen sind die in hadronischen Reaktionen erzeugten neutralen
Pionen, die in zwei Photonen zerfallen. Diese tragen auch zu dem elektromagetischen
Schauer bei.
Die in den Schauern entstehenden Teilchen werden zur Messung des Protonverlustes
benutzt. Die prinzipielle Idee bei ist, die durch den Protonverlust
entstandenen Teilchen an einem ausgewählten Ort zu zählen und daraus auf
die Gesamtanzahl der verlorenen Protonen zurückzuschließen.
Die Schwierigkeit beim Nachweis der Proton-Strahlverluste liegt nun darin,
daß von dem Elektron-Ring, der direkt unter dem Proton-Ring angebracht
ist, ein hoher Synchrotronstrahlungshintergrund von etwa 3.03 · 10 8 Photonen/cm
2 /s ausgeht. Die aus den hadronischen Schauern erzeugten Photonen
sind über diesem Untergrund nicht mehr nachzuweisen und können deshalb
nicht zur Messung benutzt werden, allein die Anzahl der Elektronen läßt
einen Rückschluß auf den Protonverlust zu.
Demnach können nur solche Detektoren verwendet werden, die auf Photonen
nicht sensitiv sind, aber Elektronen mit genügender Empfindlichkeit nach-
20 Positron-Elektron Tandem Ring-Anlage. PETRA ist ein Vorbeschleuniger für HERA,
der die Protonen bis auf eine Energie von 40 GeV beschleunigen kann.

20 3 MESSPRINZIP
weisen. Bei HERA werden als Verlustdetektoren großflächige PIN 21 -Dioden
verwendet, die in Sperrichtung betrieben werden. PIN-Dioden zeichnen sich
durch eine in der Zwischenschicht existierende große Verarmungszone an Ladungsträgern
aus, so daß beim Betrieb der Diode in Sperrichtung nur ein
kleiner Sperrstrom (verglichen zu herkömmlichen Dioden) fließt.
Fliegen Photonen oder ionisierende Teilchen durch die Diode, so erzeugen sie
in der Sperrschicht Elektron-Loch-Paare. Diese werden durch die Sperrspannung
abgesaugt, so daß ein kurzer Strompuls entsteht.
Die Unterdrückung der Photonen geschieht durch die Verwendung zweier
Dioden, die nur durch einen hauchdünnen Spalt getrennt und in Koinzidenz
geschaltet sind. Die Photonen bleiben in einer der beiden Dioden stecken,
minimalionsierende Teilchen können jedoch beide Dioden durchqueren [15].
Durch die Koinzidenzschaltung werden deshalb nur Pulse durchgelassen, die
durch Teilchen aus dem Protonverlust ausgelöst werden.
Die von den PIN-Dioden gelieferten Signale werden in TTL-Pulse umgewandelt
und an eine Elektronik weitergereicht, die neben der Koinzidenzschaltung
beider Signale auch Einzelpulse beider Dioden verarbeiten kann. Die
Pulse werden jeweils in einem Zeitintervall von 5.208 ms mit 16 Bit breiten
Zählern gezählt und dann in einem Speicher niedergelegt, der 128 Werte
fassen kann.
Neben diesem sogenannten “Kurzzeitspeicher” gibt es einen “Langzeitspeicher”,
der gemittelte Werte aufnimmt. Dabei wird jeweils, wenn der Kurzzeitspeicher
gefüllt ist, ein Mittelwert des Kurzzeitspeichers im Langzeitspeicher
abgelegt. Auch der Langzeitspeicher faßt 128 Werte. Der Kurzzeitspeicher
enthält somit Information über einen Zeitraum von 666 ms, der Langzeitspeicher
über 85.3 Sekunden.
Bevor die Anzahl der gezählten Pulse im Speicher abgelegt wird, wird sie mit
einer vom Benutzer über SEDAC setzbaren Alarmschwelle verglichen. Wird
diese überschritten, wird ein Alarm ausgelöst. Das Alarmsignal wird an ein
Alarm-Modul weitergeleitet, das sich im selben Crate befindet. Es handelt
sich dabei um dasselbe Alarm-Modul, das die Alarme von den Lagemonitoren
empfängt.
Jeweils vier dieser Zähleinrichtungen sind in einem SEDAC-Modul untergebracht.
Alle vier Kanäle teilen sich gemeinsam eine Steuer- und Logikeinheit,
auf die über SEDAC zugegriffen werden kann.
Die Zuordnung der durch die PIN-Dioden gemessenen Rate und der tatsächlichen
Verlustrate der Protonen ist sowohl durch numerische Berechnungen
als auch durch direkte Kalibrierungen erfolgt [15, 16]. Obwohl PIN-Dioden
unterschiedlicher Hersteller für Messungen an den supraleitenden und nor-
21 Positive Dotierung, intrinsische Ladungsdichteverteilung, negative Dotierung

3.4 Alarme, Strahldump und Freeze 21
malleitenden Quadrupolen benutzt wurden, kann die Anzahl verlorener Protonen
NP rotons durch den einfachen Zusammenhang
NP rotons = k
· NDiode
Ep
(15)
beschrieben werden. Dabei bezeichnet k den Kalibrierungsfaktor, der von Diodentyp
und Aufstellungsort abhängig ist, sowie Ep die Energie der Protonen.
So ergibt sich z. B. für die an den supraleitenden Quadrupolen angebrachten
Verlustmonitore
k = 3.3 · 10 8 GeV (16)
3.4 Alarme, Strahldump und Freeze
Die von Lage- und Verlustmonitoren erzeugten Alarmsignale bei Überschreitung
einer voreingestellten maximalen Ablage bzw. Verlustrate werden vom
ALM 22 -Modul, das sich stets im selben Crate befindet, registriert. Alle Alarm-
Module sind untereinander über eine elektrische Leitung miteinander verbunden,
an der eine konstante Spannung von 100 V anliegt. Für jeden Alarm,
der dem Alarm-Modul von BLM oder PPD gemeldet wird, wird ein Widerstand
in diese Leitung geschaltet. Durch Messung der Stromstärke in einem
zentralen Gerät, dem A ∗ -Gerät, kann somit die Gesamtzahl der Alarme festgestellt
werden [1, 32]. Bei Überschreitung einer gewissen Anzahl wird ein
Strahldump ausgelöst. Die ALM-Module erfahren dies über den Zusammenbruch
der 100 V-Spannung. Dann frieren sie den Speicherinhalt der Lageund
Verlustmonitore ein, so daß keine neuen Daten mehr genommen werden.
In diesem Status lassen sich die Speicherinhalte der Lage- und Verlustmonitore,
die Informationen über die Vorgeschichte des Strahldumps enthalten,
auslesen. Damit kann systematisch nach der Ursache für den Strahldump
gesucht werden kann.
22 Alarm

22 4 ENTWICKLUNG DES KONTROLLSYSTEMS
4 Entwicklung des Kontrollsystems
4.1 Analyse des HERA-Kontrollsystem
Die Struktur des jetzigen HERA-Kontrollsystems ist nach dem Prinzip eines
Client-Server-Modells [10, 12] gestaltet. Die bei HERA benutzte Implementierung
ist in Abb. 7 dargestellt. Dabei ist jeweils ein Server für ein spezielles
Stück Hardware, das eine Komponente des Beschleunigers repräsentiert,
zuständig [6]. Diese Server haben zum einen die Aufgabe der Steuerung der
Hardware (z. B. Steuerung des HERA Timings, der Hochfrequenz, der Dipolund
Quadrupol-Magnete, des Kühlsystems etc.) als auch die Aufgabe der
Überwachung. Als Beispiel für letzteres seien z. B. die Überwachung der Tunneltemperatur,
der Strahllage, des Strahlverlustes oder auch des Strahlstromes
und der Lebensdauer genannt. Die Server werden im DESY-Sprachjargon
FEC 23 genannt. Die Server verfügen über zwei Kommunikationskanäle. Zum
einen sind sie über einen Feldbus (in der Regel SEDAC) mit der Hardware
verbunden. Über den Feldbus erfolgt die Steuerung, Regelung und Datennahme.
Nur ein Server kann somit direkt auf die Hardware zugreifen. Zum anderen
sind die Server an ein lokales Netz, das auf Ethernet basiert, angeschlossen.
Über das Netz können die Clients auf die Funktionen des Servers zugreifen.
Die Clients stellen eine grafische Benutzeroberfläche für die verschiedenen
Hardware
Server
Feldbus
Lokales Netz (Ethernet)
Client 1 Client 2 Client n
Abbildung 7: Das Client-Server Modell
Funktionen der Server zur Verfügung. Mehrere Client-Programme, die auf unterschiedlichen
Computern auf dem gesamten DESY-Gelände laufen können,
dürfen gleichzeitig auf die Daten eines Servers zugreifen. Die Steuerfunktio-
23 Front-End-Computer

4.2 Anforderungen 23
nen der Front-End-Computer dürfen aber nur von autorisierten Personen wie
den Schichtgängern im Beschleuniger-Kontrollraum benutzt werden.
Die Aufgabenteilung in Clients und Server hat vor allem einen Hintergrund:
Der Server soll ständig die Hardware überwachen und Daten nehmen [6].
Wenn ein Client dann einen Datensatz verlangt, muß nicht erst die Hardware
ausgelesen werden, sondern es werden die vom Server lokal gespeicherten
Daten übertragen, was einen wesentlichen Geschwindigkeitsvorteil bedeutet.
Im Laufe der Jahre ist am DESY eine gewachsene Struktur von Servern und
Clients entstanden, die unterschiedlichste Computertypen, Betriebssysteme
und Software verbindet. Vorrangige Aufgabe ist es, trotz dieser Unterschiede
ein einheitliches Konzept für ein Kontrollsystem zu entwickeln. Die Vorteile
eines einheitlichen Konzepts sind offensichtlich: Eine Erleichterung der
Wartung, eine schnelle Einarbeitung neuer Mitarbeiter und die Möglichkeit,
Änderungen oder Erweiterungen schneller umzusetzen.
Auf Client-Seite wurde mit ACOP 24 [3] in diesem und dem letzten Jahr
in Zusammenarbeit mit dem CERN ein neues, einheitliches Kontrollsystem
entwickelt. Es wurde beim Anlauf von HERA dieses Jahr zum ersten Mal
eingesetzt.
Auf Server-Seite steht ein Schritt in Richtung eines einheitlichen Kontrollsystems
noch aus. Im Rahmen dieser Diplomarbeit werden im folgenden Kapitel
Strukturen und Wege aufgezeigt, wie ein einheitliches Kontrollsystem
aussehen könnte.
4.2 Anforderungen
Es ist klar, daß der Entwurf eines neuen Konzepts für das HERA-Kontrollsystem
nicht unabhängig von dem zur Zeit existierenden geschehen kann. Das
hier entwickelte Kontrollsystem paßt sich deshalb in die vorhandene Client-
Server-Struktur ein, ohne eine Änderung auf der Client-Seite nach sich zu
ziehen. Das erfordert eine Kompatibilität im Client-Server-Interface. Dies
wurde durch die Benutzung des ACOP-Netz-Kernels [3] in seiner neuesten
Version 3.02 (Juli 1998) erreicht.
Die Lage- und Verlustmessung soll die verschiedenen HERA-Betriebsmodi
Injektion, Energie-Ramping und Speicherbetrieb unterstützen, indem geeignete
Daten genommen und dem Benutzer (den Clients) zur Verfügung gestellt
werden. Dafür müssen die aus den Verlust- und Lagemonitoren entnommenen
Digitalwerte mit Hilfe von Kalibrationstabellen in eine Ablage bzw. eine Anzahl
verlorener Protonen konvertiert werden. Weiterhin sollen die von Lageund
Verlustmonitoren gemeldeten Alarme ausgelesen werden. Kommt es zu
24 Accelerator Component Oriented Programming

24 4 ENTWICKLUNG DES KONTROLLSYSTEMS
einem Strahldump, soll dieser automatisch erkannt werden und die Daten für
eine Post-Mortem-Analyse abgespeichert werden.
Eine vom DESY gewünschte Änderung ist die Erhöhung der Auslesegeschwindigkeit
gegenüber der des vorhandenen Kontrollsystems. Eine Untersuchung
des vorhandenen Kontrollsystems hat ergeben, daß die Auslesegeschwindigkeit
nicht durch eine mangelnde Prozessorleistung des Front-End-
Computers begrenzt ist, sondern durch die Transferrate der Daten über den
SEDAC-Feldbus [9]. Mit einer maximalen Transferrate von 4000 Hz, mit der
16 Bit breite Worte gelesen bzw. geschrieben werden können, ist SEDAC verglichen
mit heute üblichen Feldbussystemen langsam. Die einfachste Lösung
wäre somit, einen schnelleren Feldbus zur Datennahme zu benutzen. Das ist
aber mit großem technischen Aufwand verbunden, da jeder Crate-Controller
ausgetauscht und zusätzliche Komponenten installiert werden müßten. Deshalb
soll SEDAC noch für einige Zeit als Feldbus behalten werden, und es
wurde entschieden, die Anzahl der pro Feldbus übertragenen Daten zu verringern.
Dafür werden vier neue Server statt wie bisher einem benutzt. Trotzdem
soll das System offen für einen Wechsel auf ein neues Bussystem sein, der für
die entferntere Zukunft notwendig sein wird.
Außerdem sollte das Kontrollsystem leicht von einer Hardwareplattform auf
eine andere portiert werden können, um an zukünftige Rechnergenerationen
und andere Anforderungen angepaßt werden zu können. Neue Module sollten
sich nicht nur ohne großen Aufwand in das vorhandene System einpassen
lassen, sondern deren Integration sogar erleichtert werden.
4.3 Grundlegende Konzepte
4.3.1 Modularität
Um das Kontrollsystem leicht erweiterbar und offen für Änderungen zu machen,
wird es modular entwickelt. Das bedeutet eine Strukturierung in verschiedene
Einheiten (Module), die genau definierte Schnittstellen haben. Der
modulare Aufbau wird durch die Verwendung des Klassenmodells der objektorientierten
Programmiersprache C++ unterstützt [13]. Eine Klasse faßt
dabei die Eigenschaften (Funktionen) eines Moduls und die dazugehörigen
Daten zusammen.
Klassen eignen sich, um logische Einheiten zu schaffen und spiegeln die Struktur
des tatsächlichen Aufbaus des Kontrollsystems wider. Genauso wie die
Module in voneinander getrennten Einschüben im Crate untergebracht sind,
sind ihre Daten und Funktionen in getrennten Klassen untergebracht. So
existieren eigene Klassen für die Lagemonitore, Trigger- und Delaymodule
sowie die Verlustmonitore und die Alarmmodule. Eine Änderung des Kon-

4.3 Grundlegende Konzepte 25
trollsystems bei entsprechender Änderung an der Hardware ist damit so einfach
(oder schwierig) wie das Hinzufügen oder Entfernen eines Einschubs
aus einem Crate. Eine genaue Diskussion des Klassenmodells befindet sich
in Kapitel 5.
Durch die Vererbung von gemeinsamen Eigenschaften der Module läßt sich
der Aufwand für das Hinzufügen eines neuen Moduls auf die Modellierung
der speziellen Fähigkeiten reduzieren. Die “Erfindung des Rades von Neuem”
ist damit nicht mehr notwendig.
Konkretes Beispiel: Alle für die Lage- und Verlustmessung benutzten Module
kommunizieren über den Feldbus SEDAC. Die Klasse CBusBoard enthält
Routinen, um diese Kommunikation abzuwickeln. Durch die Vererbung dieser
Routinen an spezialisierte Modulklassen haben diese automatisch die
Möglichkeit, über den Bus zu kommunizieren (vgl. Abb. 12).
Die einzelnen Module werden dabei von dem Kontrollsystem als unabhängige
Einheiten akzeptiert, die ihre Aufgaben ebenso unabhängig voneinander erledigen.
Sollten z. B. in Zukunft die Lage- und Verlustmonitore in getrennten
Systemen untergebracht werden, so kann eine entsprechende Änderung des
Programmes mit wenig Aufwand erfolgen.
Die Unabhängigkeit der einzelnen Modulklassen voneinander wird durch die
Client-Server-Struktur erleichtert. Der Server muß keinen Zusammenhang
zwischen den verschiedenen Modultypen herstellen. Erst der Client muß die
nötigen Zusammenhänge herstellen. Eine geeignete Anwendung für einen Client
wäre z. B. die Optimierung der Einstellungen des Delay-Moduls. Dazu
könnte der Client die Delaywerte in einem Delay-Modul Schritt für Schritt
verändern und anhand der vom PPD-Modul gelieferten Intensitätswerte überprüfen,
welche Verzögerung optimal ist 25 . Dabei ist gleichgültig, ob die Daten
von demselben Server oder gar aus demselben Crate kommen oder nicht.
4.3.2 Echtzeitfähigkeit
In verschiedenen Situationen ist es nötig, daß auf ein eingehendes Signal
in bestimmter Zeit reagiert werden muß. Ein echtzeitfähiges Betriebssystem
garantiert bei richtiger Programmierung eine maximale Antwortzeit. In der
speziellen Situation der Proton-Strahllagemessung muß im Speicherbetrieb
von HERA in regelmäßigen Abständen überprüft werden, ob neue Orbit-
Daten vorliegen. Wird ein Datensatz verpaßt, lassen sich die Lageinformationen
nicht mehr eindeutig einem bestimmten Umlauf zuordnen, und es
kommt zu Fehlern in der Anzeige der Strahlabweichung. Echtzeitfähigkeit ist
25 Zur Zeit wird die Delayoptimierung noch von dem Front-End-Computer durchgeführt.
Der hier vorgestellte Vorschlag ist der vorhandenen Lösung jedoch konzeptionell vorzuziehen.

26 4 ENTWICKLUNG DES KONTROLLSYSTEMS
eine Funktion, die vom Betriebssystem des Computers unterstützt werden
muß. Das schränkt die Anzahl der Betriebssysteme, auf denen das Kontrollsystem
eingesetzt werden kann, ein. Nicht eingeschränkt wird jedoch die zur
Verfügung stehende Hardware, da es Echtzeit-Betriebssysteme für nahezu alle
Computertypen gibt. Aktuelle Echtzeit-Betriebssysteme sind unter anderem
LynxOS, QNX, Digital Unix, OSF/1, Solaris, RT-Linux und VxWorks.
Für die ersten Schritte der Entwicklung wurde ein VME-basierter Real-Time-
PowerPC RTPC-8067 mit dem Betriebssystem LynxOS als Entwicklungsplattform
verwendet. Die Kommunikation mit den Modulen erfolgte durch
ein SEDAC-IP 26 -Interface abgewickelt, das nicht direkt von dem RTPC 8067
angesprochen werden konnte. Es mußte auf einem IP-Carrier-Boards angebracht
werden, dieses konnte dann über VME angesprochen werden. Durch
diesen etwas umständlichen Aufbau kam es zu einer Hardware-Unverträglichkeit,
so daß eine Übertragung der Daten nur in etwa 10% der Fälle fehlerfrei
erfolgte. Deshalb mußte die Entwicklung nach drei Monaten abgebrochen
werden. Leider bestand nicht die Möglichkeit, ein anderes SEDAC-Interface
zu benutzen, deshalb mußte ein anderer Aufbau entworfen werden.
In Absprache mit den verantwortlichen Personen am DESY wurde entschieden,
für die weitere Entwicklung auf Hardware und Betriebssysteme zurückzugreifen,
die beim DESY bereits erfolgreich eingesetzt wurden. Deshalb
wurde für die Implementierung als Hardware-Entwicklungsplattform eine
MVME-162-12a, eine VME-basierte Motorola-CPU 27 , gewählt. Das SEDAC-
IP-Interface wird direkt auf dem VME-Board befestigt und ist mit diesem
Computer bereits erfolgreich eingesetzt worden. Dieser Aufbau funktioniert
auch mit dem in dieser Diplomarbeit entwickelten Kontrollsystem einwandfrei.
Die Wahl des Betriebssystems VxWorks wurde hauptsächlich durch die zwei
folgenden Argumente entschieden: Einerseits wird zur Zeit am DESY verstärkt
mit VxWorks gearbeitet 28 , so daß die am DESY beschäftigten Personen
den Umgang mit VxWorks gewöhnt sind und sich nicht auf ein neues
Betriebssystem umstellen müssen. Die Verwendung eines anderen Betriebssystems
hätte außerdem zusätzliche Kosten für Lizenzen verursacht. Für das
hier entwickelte Kontrollsystem konnte eine noch freie Lizenz verwendet werden,
so daß auch finanzielle Gründe für die Verwendung von VxWorks sprachen.
26 Industry Pack
27 Central Processing Unit
28 Unter anderem wurde das Quench Protection System und die Magnetsteuerung auf
VxWorks entwickelt.

4.3 Grundlegende Konzepte 27
4.3.3 Portabilität
Soll das hier für Lage- und Verlustmessung entwickelte Kontrollsystem Vorbild
für andere Teile des HERA-Kontrollsystems sein, so ist aufgrund der
verschiedenen Hardwareplattformen und Betriebssysteme, die zur Zeit am
DESY existieren, auf eine leichte Portierbarkeit zu achten. Spezielle Eigenschaften
bestimmter Hardware oder eines Betriebssystems dürfen nur dann in
das Kontrollsystem einfließen, wenn der Zugriff darauf standardisiert ist. Dadurch
läßt sich der Aufwand einer Portierung bei einem Wechsel der Hardware
oder des Betriebssystems beträchtlich reduzieren. Wichtige Institutionen,
die solche Standards entwickeln und festschreiben, sind IEEE 29 , ANSI 30 und
das internationale Analogon ISO 31 . Eine hundertprozentige Portabilität läßt
sich jedoch bei komplexen Programmen auch damit nicht erreichen [7]. Durch
die Konformität zu Standards läßt sich aber der Aufwand einer Portierung
beträchtlich vermindern.
Es gibt hauptsächlich drei Faktoren, die die Portabilität eines Computerprogrammes
bestimmen, nämlich
1. die Hardware,
2. das Betriebssystem, und
3. die Programmiersprache.
So bestimmt z. B. die Hardware die Ausführungsgeschwindigkeit, die Zeitauflösung
bei Zeitmessungen, den verfügbaren Speicher, das Byte-Ordering
oder auch den Zugriff auf externe Geräte wie das SEDAC-Interface.
Das Betriebssystem regelt z. B. den Zugriff auf diese Ressourcen, bestimmt
das Prozeßmanagement und ermöglicht Prioritätsregelungen bei gleichzeitiger
Ausführung verschiedener Aufgaben.
Mögliche Portierungsprobleme bei der Verwendung einer Programmiersprache
ergeben sich unter anderem aus der unterschiedlichen Implementation
der Datentypen. So kann z. B. in der Programmiersprache “C” der Datentyp
“long” bei der Implementierung auf einer Alpha AXP 64 Bit breite Werte 32 ,
bei einer Implementation auf einem PC jedoch nur 32 Bit breite Werte 33
aufnehmen. Vielfach kann es auch sein, daß eine Programmiersprache nicht
für das gewählte Betriebssystem verfügbar ist.
29 The Institute of Electrical and Electronics Engineers, INC.
30 American National Standards Institute
31 International Organisation for Standardisation
32 Das entspricht Zahlen von -9223372036854775808 bis 9223372036854775807
33 Das entspricht Zahlen von -2147483648 bis 2147483647

28 4 ENTWICKLUNG DES KONTROLLSYSTEMS
Alle diese Faktoren müssen bei der Entwicklung des Kontrollsystems berücksichtigt
werden. Durch die am DESY vorhandenen Rahmenbedingungen und
die in Abschnitt 4.3.2 vorgestellte Notwendigkeit der Echtzeitfähigkeit wurde
das Betriebssystem VxWorks und die Hardware MVME-162-12a vorgegeben.
Die Verwendung der Programmiersprache C++, mit der die Entwicklung auf
dem RTPC 8067 begonnen wurde, ist auch unter VxWorks möglich. C++
ist eine sehr weit verbreitete und sowohl durch die ANSI als auch durch die
ISO standardisierte Programmiersprache [2]. Das Lage- und Verlustkontrollsystem
beschränkt sich auf den im ANSI-Standard festgelegten Dialekt [13].
Dieser ist für alle oben genannten Betriebssysteme und für eine große, weitere
Anzahl von anderen Betriebssystem, wie z. B. DOS, OS/2 und Windows
verfügbar. Neben der Möglichkeit, die Fähigkeiten des OOP 34 auszunutzen,
bietet sie auch Zugriff zu standardisierten Echtzeitfähigkeiten der Betriebssysteme,
insbesondere zu POSIX 35 .
In dem Lage- und Verlustkontrollsystem werden die Echtzeitfunktionen des
POSIX.4-Standards [7] (definiert durch die Option POSIX TIMERS) und die
Funktion nanosleep, die die Ausführung des Programms für kurze Zeit unterbricht,
benutzt. Da diese Funktionen teilweise zur Verfügung stehen, auch
wenn andere POSIX-Optionen nicht vorhanden sind, läßt sich mittels einfacher
Konfigurationsdateien das Kontrollsystem an neue Systeme anpassen.
Als Beispiel folgt hier die Konfigurationsdatei system/linux.hpp, mit der
das Kontrollsystem auf einem RedHat-Linux-System Version 5.0 lauffähig
wird:
/*
ORGANISATION: RWTH-Aachen
III. Physikalisches Institut
PROJECT: HERA Beam Position Measurement (BPM)
BELONGS TO: platform.hpp
DESCRIPTION: This header file is used for the
Linux operating system.
KEYWORDS: platform independency, RedHat Linux
VERSION: 1.0
STATUS: tested ok
MODIFICATION HISTORY:
34Object Oriented Programming
35Portable Operating System Interface. Es ist speziell für den Einsatz unter UNIXähnlichen
Betriebssystemen gedacht.

4.3 Grundlegende Konzepte 29
05.05.98 mkw created file
*/
#ifndef _linux_hpp
#define _linux_hpp
// Linux has most of the POSIX options, therefore
// include the POSIX header file
#include "posix.hpp"
// Linux has nanosleep, although it
// not defines _POSIX_TIMERS
#define HAVE_NANOSLEEP
#endif /* _linux_hpp */
Ein weiteres Beispiel zur Vermeidung von betriebssystemspezifischen Eigenschaften
ist die Nichtbenutzung von Gerätetreibern (“Device drivers”). Die
Einbindung und das Erzeugen von Gerätetreibern, die zum Zugriff auf Hardware
dienen, ist bei den verschiedenen Betriebssystemen höchst unterschiedlich.
Ein Vorteil von dem in dieser Arbeit verwendeten Kontrollsystem ist es,
daß der Zugriff auf die Hardware direkt durch das Programm geschieht (siehe
Kapitel 5.1) und die Erzeugung von Gerätetreibern dadurch vermieden wird.
Weiterhin werden in der Datei platform.hpp systemunabhängige Datentypen
geschaffen, durch die die Inkompatibilität der Standard-Datentypen
umgangen wird.
4.3.4 Nebenläufigkeit
Für den Fall der Lage- und Verlustmessung ist es notwendig, daß das Kontrollsystem
mehrere voneinander quasi unabhängige Aufgaben gleichzeitig
bearbeiten muß. Lage- und Verlustmessung sind zwar logisch unabhängig
voneinander, aber hardwaremäßig miteinander verbunden. Das Kontrollsystem
muß eine sinnvolle Kooperation und Aufgabenteilung ermöglichen, damit
kritische oder sicherheitsrelevante Programmteile bei der Zuteilung der
Ressourcen eine höhere Priorität als weniger wichtige Programmteile erhalten.
Alle modernen oder echtzeitfähigen Betriebssysteme unterstützen Nebenläufigkeit
36 , d. h. die quasi-gleichzeitige 37 Ausführung von unterschiedlichen
36Bekannter sind sicherlich die englischen Ausdrücke “concurrency” bzw. “multithreading”
und “multi-tasking”.
37Quasi-gleichzeitig deshalb, weil bei Vorhandensein nur einer CPU auch immer nur ein

30 4 ENTWICKLUNG DES KONTROLLSYSTEMS
Programmteilen. Die nebenläufig ausgeführten Programmteile werden häufig
“Threads” oder “Tasks” genannt. Zumeist liegen dem aber unterschiedliche
Konzepte zugrunde, so z. B. unter Solaris die “Solaris-Threads”, während
VxWorks wieder ein anderes Thread-Konzept verwendet.
Wegen der in Abschnitt 4.3.3 vorgestellten Portabilität des Kontrollsystems
kann nicht auf für das jeweilige Betriebssystem spezifische Konzepte eingegangen
werden. Für das Lage- und Verlustkontrollsystem wird deshalb der
seit einigen Jahren existierende und verbreitete Pthread-Standard 38 [14] verwendet.
Implementationen sind z. B. für LynxOS, Solaris und Linux verfügbar.
Für VxWorks existiert eine kommerziell erwerbliche Version [33]. Aus finanziellen
Gründen wurde aber gegen deren Einsatz entschieden. Deshalb wurde
in der vorliegenden Diplomarbeit ein eigenes Pthread-Interface entwickelt.
Dieses stellt alle für das Kontrollsystem wichtigen Funktionen des Pthread-
Standards für VxWorks bereitstellt. Die genaue Implementation und Einbindung
in das VxWorks-Betriebssystem ist in Anhang A beschrieben.
Der Einsatz von Nebenläufigkeit zieht zwangsläufig die Notwendigkeit zur
Synchronisation nach sich, die mit erhöhtem Aufwand bei der Programmierung
verbunden ist und sich durch den zusätzlichen Programmcode auch verlangsamend
auf die Programmausführung auswirkt. Zusätzlich benötigt das
Betriebssystem Zeit, um den Wechsel zwischen den verschiedenen Threads
zu ermöglichen.
Zwei Gründe sprechen jedoch für Nebenläufigkeit: Überlappende Ein- und
Ausgabe sowie unterschiedliche Prioritäten von Lage- und Verlustmessung.
Beide Gründe werden in [12] als wichtige Voraussetzungen für den Einsatz
von Nebenläufigkeit genannt. Die überlappende Ein- und Ausgabe entsteht
bei dem vorliegenden Kontrollsystem dadurch, daß es gleichzeitig über zwei
Feldbusleitungen Daten übertragen muß (vgl. Abschnitt 4.4).
Würde das Kontrollsystem bei der Ein- und Ausgabe auf jeweils einer Leitung
blockieren, so könnten über den anderen Feldbus keine Daten übertragen
werden! Es ist deshalb viel sinnvoller, einen parallelen, nebenläufigen
Zugriff auf beide Feldbusse zuzulassen. Dies sorgt für eine Aufteilung der
Datennahme auf zwei DAQ 39 -Threads.
Andererseits bedingen die unterschiedlichen Prioritäten der ständigen Datennahme
von Lage-, Verlustmonitoren und Alarmmodulen eine zusätzliche
Aufteilung. In Abb. 8 ist diese Aufteilung in einem zweidimensionalen Schema
verdeutlicht. Die Ordnung nach Prioritäten erfolgt durch die Wichtigkeit
Befehl nach dem anderen abgearbeitet werden kann. Das Betriebssystem wechselt aber
zwischen den Abarbeitung der unterschiedlichen Aufgaben so schnell, daß es dem Benutzer
wie die gleichzeitige Ausführung erscheint.
38 POSIX-Threads
39 Data Acquisition

4.3 Grundlegende Konzepte 31
der Auslese von Alarmen, Verlust und Lage. Die oben angesprochene Aufteilung
in zwei Threads erfolgt aufgrund der überlappenden Ein- und Ausgabe
auf zwei Feldbusleitungen.
Überlappende Ein- / Ausgabe
Bus 0
Bus 1
ALM
Bus 0
ALM
Bus 1
Unterschiedliche Prioriäten
ALM BLM PPD
BLM
Bus 0
ALM
Bus 1
PPD
Bus 0
ALM
Bus 1
Abbildung 8: Anordnung der zur DAQ verwendeten Threads in einem zweidimensionalen
Schema
Daneben existiert noch der Netz-Kernel des ACOP-Systems als eigenständiger
Thread. Dieser erlaubt es den Clients, über RPC 40 eine Funktion des
Servers aufzurufen, als würde diese lokal bei dem Client ausgeführt.
4.3.5 Wartungsfreundlichkeit
Soll das Kontrollsystem von vielen verschiedenen Arbeitsgruppen eingesetzt
werden, muß es leicht verständlich sein. Darüberhinaus sollte es auch einfach
zu warten sein. Das ist mit vertretbarem Aufwand nur möglich, wenn
es genügend Informationen über die Zusammenhänge und den Ablauf des
Systems gibt.
Es versteht sich von selbst, daß der Quelltext des Kontrollsystems ausführlich
dokumentiert wird. Zu fast jeder Zeile bzw. logischen Einheit von Zeilen
existiert ein kurzer englischer Kommentar, der wiedergibt, zu welchem
Zweck der Programmtext dient. Weiterhin sind alle Funktionen mit einer
Kurzbeschreibung dokumentiert, die die Funktion der Ein- und Ausgabeparameter
erklärt. Um dem Programmierer das Arbeiten zu erleichtern, werden
hauptsächlich Namen für Funktionen verwendet, die keine Akronyme (z. B.
40 Remote Procedure Call

32 4 ENTWICKLUNG DES KONTROLLSYSTEMS
almrst) sind, sondern beschreiben, was die Funktion tatsächlich macht. Als
Beispiele seien Bus.Write, eine Funktion, die Daten auf den Feldbus schreibt,
CGroup.ReadInfo, die Informationen über eine Gruppe von Modulen aus
einer Datei liest, oder auch CAlarm.ResetFreeze, die im Strahllage- und
Strahlverlust-Modul das Einfrieren der Daten aufhebt, genannt.
Der objektorientierte Entwurf des Kontrollsystems, das dem Quelltext die
logische Struktur des Kontrollsystems aufprägt, unterstützt das Verständnis
des Programms wesentlich.
Zusätzlich ist jede Datei am Anfang mit einem Kommentar versehen, der
den Sinn und Zweck der Datei beschreibt sowie Angaben zum Autor, zur
Modifikation, zur aktuellen Version und eine Liste von Schlagwörtern enthält,
nach denen man z. B. mit dem Programm Grep suchen kann. Beispielhaft
zeigt der in Abschnitt 4.3.3 gezeigte Quellcode einen solchen Kommentar.
4.4 Beschleunigung der Datenauslese
Strahlverlustmonitore und Strahllagemonitore sind etwa gleichmäßig über die
Beschleunigerstruktur von HERA, die als Übersicht in Abb. 9 dargestellt ist,
verteilt. Bei einer Tunnellänge von L = 6.34 km fallen die Daten an räumlich
Abbildung 9: Übersicht über den HERA-Beschleuniger
weit entfernten Punkten an. Da aber z. B. für die Berechnung des Q-Wertes
die Daten aller Monitore benötigt werden, müssen die Daten an einer Position
gesammelt und weiterverarbeitet werden. Natürlich kann man an jedes Modul

4.4 Beschleunigung der Datenauslese 33
ein Kabel anschließen und dieses bis zu dem Front-End-Computer legen. Bei
der großen Anzahl von etwa 8000 Modulen [21], die für HERA installiert worden
sind, entsteht nicht nur ein unübersichtliches Gewirr von Kabeln, sondern
explodieren auch die Kosten mit wachsender Entfernung zum Front-End-
Computer. Deshalb ist es viel sinnvoller, die Daten seriell über ein Kabel mit
Hilfe eines standardisierten Protokolls zu übertragen. Diese Aufgabe erfüllt
ein Feldbus. Er ist dafür gedacht, mehrere räumlich entfernte Geräte über
eine Leitung miteinander zu verbinden und deren Kommunikation über ein
standardisiertes Protokoll zu ermöglichen. Die Strahllage- und Verlustmonitore
sowie Trigger-, Delay- und Alarm-Module sind über den DESY-Feldbus
SEDAC mit dem Server verbunden. SEDAC ist ein Single-Master-Bus [21].
Das bedeutet, daß an einer SEDAC-Leitung Schreib- und Lesebefehle nur von
einem Server, dem Front-End-Computer, ausgehen können. Da, wie bereits
erwähnt, alle für die Lage- und Verlustmessung benötigten Module in einem
Crate untergebracht sind, und der Crate-Controller mit dem Computer über
eine SEDAC-Leitung verbunden ist, muß der angeschlossene Server sowohl
Lagemonitore, als auch Verlustmonitore, Delay-Modul, Trigger-Modul und
Alarm-Modul auslesen bzw. steuern.
Die Daten werden über SEDAC in Form von Telegrammen verschickt. Dabei
werden 46 Bits übertragen, von denen 16 Bit die tatsächlichen Daten
repräsentieren (Die restlichen 30 Bits werden zur Adressierung und Fehlererkennung
benutzt). Die Übertragung eines Lese- oder Schreibtelegramms
dauert 250 µs, wovon aber 66 µs für die Synchronisation in Form einer Austastlücke
vorgesehen sind [21, 19]. Daraus ergibt sich eine maximale Übertragungsfrequenz
von 4 kHz für 16 Bit breite Werte, was einer Datenrate von
64000 bps 41 entspricht.
In Abb. 10 sind einige Beispiele für mögliche Netzkonfigurationen dargestellt.
Zunächst unterstützte SEDAC nur eine Reihenschaltung; durch die
Einführung von Line-Splittern wurde jedoch auch eine Sternschaltung möglich.
Die Kombination von Reihen- und Sternschaltung führt zu einer großen
Anzahl von Möglichkeiten, SEDAC-Module miteinander zu verbinden (sogenannte
“Mix-Topologien”).
Das bisherige Lage- und Verlustkontrollsystem kommuniziert mit den Modulen
über vier SEDAC-Leitungen, die von dem Front-End-Computer jeweils
in eine Halle (West, Süd, Ost, Nord) gehen. In jeder Halle splittet sich die
Leitung auf in eine in den Oktanten rechts und eine in den Oktanten links
(Abb. 11 links).
Die Steigerung der Geschwindigkeit wird erreicht, indem die Anzahl der über
den Bus zu übertragenden Daten verringert wird. Man nutzt aus, daß sich
41 bits per second

34 4 ENTWICKLUNG DES KONTROLLSYSTEMS
Abbildung 10: Verschiedene mögliche Netztopologien mit SEDAC. Mit freundlicher
Genehmigung von Matthias Werner, DESY MKI
Injektion
Elektronen
Halle West
(HERA-B)
Halle Nord (H1)
Injektion
Protonen
BPM-FEC
SEDAC
Elektronen
Protonen
Halle Süd (ZEUS)
Halle Ost
(HERMES)
Injektion
Elektronen
Halle West
(HERA-B)
Halle Nord (H1)
BPM-FEC 1
Injektion
Protonen
BPM-FEC 4
BPM-FEC 2
BPM-FEC 3
SEDAC
Elektronen
Protonen
Halle Süd (ZEUS)
Halle Ost
(HERMES)
Abbildung 11: SEDAC-Verbindungen des alten und neuen Kontrollsystems. Links
dargestellt ist der bisherige Aufbau, rechts der in dieser Diplomarbeit entwickelte
neue Aufbau.

4.4 Beschleunigung der Datenauslese 35
der SEDAC-Feldbus in den Hallen jeweils in zwei Leitungen aufteilt. Durch
die Installation eines Front-End-Computers in jeder Halle kann man somit
die Anzahl der auszulesenden Module pro Bus halbieren und damit auch die
Zeit, die zum Sammeln der Daten benötigt wird. Denn die Prozessorleistung
reicht aus, zwei SEDAC-Leitungen mit nahezu Maximalgeschwindigkeit auszulesen
42 . Diese Situation ist in Abb. 11 auf der rechten Seite dargestellt.
Weiterhin werden, um den Datenfluß über den Feldbus so gering wie möglich
zu machen, so wenig Buszugriffe wie möglich durchgeführt. Das ist bei der
Entwicklung des Kontrollsystems durch die Zwischenspeicherung von Daten
berücksichtigt worden (vgl. Abschnitt 5.2).
42 Meßergebnisse befinden sich in Abschnitt 7.1

36 5 DAS KLASSENKONZEPT
5 Das Klassenkonzept
In diesem Kapitel wird das für das Kontrollsystem verwendete Klassenkonzept
beschrieben. Einen Überblick über die Klassenhierarchie zeigt die
Abb. 12. Insgesamt existieren 23 verschiedene Klassen, die über 300 verschiedene
Funktionen enthalten. Der gesamte Quelltext des Kontrollsystems
besteht aus mehr als 25.000 Zeilen 43 (ohne das Pthread-Interface und ohne
alle Initialisierungsdateien), so daß es wenig Sinn macht, Klasse für Klasse
die verschiedenen Funktionen zu erläutern. Stattdessen werden hier die
wichtigsten Grundzüge erklärt.
5.1 Die Klassen für den Feldbus
Der Feldbus wird in dem Strahllage-Kontrollsystem durch die Klasse CBus
repräsentiert. Die Klasse stellt dem Benutzer Routinen zum Schreiben und
Lesen von beliebigen Adressen auf dem Bus zur Verfügung. Dabei erfolgt der
Zugriff synchron, d. h. der Programmablauf wird erst nach dem Erreichen
der Antwort wieder fortgesetzt. Das hat scheinbar den Nachteil, daß viel
Zeit mit dem Warten auf eine Antwort verschwendet wird, wobei doch in
der Zwischenzeit Aufgaben wie das Konvertieren oder Sichern von Daten auf
Datenspeicher oder auch die Ausgabe von wichtigen Systeminformationen
für den Benutzer durchgeführt werden könnten.
Scheinbar deshalb, weil ja nur dieser eine Thread unterbrochen wird. Durch
die Nebenläufigkeit können alle anderen Threads weiterarbeiten, sie werden
nicht blockiert, so daß es sich also in Wirklichkeit um keinen Nachteil handelt.
Im Gegenteil, die synchrone Abarbeitung in einem Thread hat den Vorteil,
daß eine genaue Fehlerzuordnung möglich ist. So kann unmittelbar nach dem
Aufruf überprüft werden, ob bei der Übertragung ein Fehler entstanden ist.
Die Busklasse definiert einen Fehlertyp (BusError), der verschiedene Fehler,
wie z.B. Prüfsummenfehler (Parity / CRC), einen Timeout (keine Antwort)
oder auch den Status “beschäftigt” beschreiben kann. Der Benutzer der Klasse
kann nach der Übertragung den Fehlerstatus abfragen und eine eventuelle
Neuübertragung auslösen. Um dem Benutzer diese Arbeit abzunehmen, wird
in der Busklasse eine Standardfehlerfunktion (DefaultBusErrorFunction)
deklariert, die bei Auftreten eines Übertragungsfehlers aufgerufen wird. Diese
löst eine Rückübertragung der Daten aus und behebt so den entstandenen
Fehler.
Nur wenn wiederholt Fehler auftreten, wird an das aufrufende Programm
eine Fehlermeldung weitergegeben. Damit wird die Benutzung der Busklasse
43 Zum Vergleich: Der TEX-Quelltext dieser Diplomarbeit enthält etwa 3000 Zeilen

Abbildung 12: Übersicht über die Klassenstruktur. Die verwendete Symbolik wird
zu Beginn des Abschnitts 5.2 beschrieben.
CAlarm
CALMDAQ
CBusBoard
CHERABoard
CBLM CBLMPickup CDelay
CBLMDAQPickup CDLYDAQ
BUS
CMTM
CMTMDAQ
CBusDummy
CSedacIPIO
neuer Bus
CALMGroup CBLMGroup
CDLYGroup
CMTMGroup CPPDGroup
CGroup
CPPD
CPMST
CPPDDAQ CPMSTDAQ
5.1 Die Klassen für den Feldbus 37

38 5 DAS KLASSENKONZEPT
sehr einfach, denn es ist nicht mehr nötig, kleinere Fehler abzufangen. Nur
beim Auftreten schwerer Fehler wird die aufrufende Funktion benachrichtigt
und kann so geeignete Maßnahmen ergreifen.
Damit nicht genug, kann der Benutzer auch die Standard-Fehlerprozedur deaktivieren
und eine eigene Fehlerbehandlungsroutine installieren, ohne die
Busklasse ändern zu müssen. Diese wird dann bei jedem Übertragungsfehler
anstatt der Standardfehlerfunktion aufgerufen und erlaubt, flexibel auf
bestimmte Fehler zu reagieren, ohne direkt die gesamte Busklasse ändern
zu müssen. Die eigene Fehlerroutine muß dabei der Busklasse mitteilen, wie
auf den Fehler reagiert werden soll: Entweder eine Neuübertragung auslösen
(RETRY), den Fehler ignorieren und fortfahren (IGNORE) oder aber die aufrufende
Routine beenden (ABORT).
Neben den Routinen zum Schreiben und Lesen von Daten und zur Fehlerbehandlung
existieren noch weitere Routinen, die den Umgang mit einem
Feldbus erleichtern. So überprüft z. B. die Routine IsValid, ob eine übergebene
Busadresse auch eine gültige Busadresse darstellt. Das kann dazu
benutzt werden, schon vor dem eigentlichen Buszugriff Fehler zu vermeiden.
Die beiden Routinen UseExclusive und EndExclusive arbeiten Hand in
Hand, um einen exklusiven Buszugriff zu gewährleisten. Grundsätzlich ist
es durch die parallele Ausführung verschiedener Threads nämlich nicht gewährleistet,
daß in einem Thread zwei aufeinanderfolgende Schreibbefehle
tatsächlich direkt nacheinander ausgeführt werden können. Stattdessen ist es
möglich, daß ein anderer Thread zwischenzeitlich Daten überträgt. In zeitkritischen
Situationen kann es jedoch möglich sein, daß mehrere Schreibbzw.
Lesebefehle direkt hintereinander ausgeführt werden müssen. Nach einem
Aufruf von UseExclusive kann sich der Thread sicher sein, daß außer
ihm niemand auf den Bus zugreifen kann. Mit EndExclusive kann er den
Feldbus für andere Threads wieder freigeben.
5.1.1 Simulation eines Feldbusses
Für Testzwecke kann es erforderlich sein, einen Feldbus zu simulieren. Dafür
wurde eine eigene Test-Busklasse entwickelt, die Klasse CBusDummy. Sie stellt
das oben beschriebene Interface der Busklasse komplett zur Verfügung, ohne
tatsächlich auf den Bus zuzugreifen. Durch die Benutzung dieser Klasse
können somit Programmteile getestet werden, ohne daß das echte Feldbussystem
benutzt werden muß. Das ist nützlich, wenn der Feldbus für die geplante
Anwendung nicht ununterbrochen zur Verfügung steht, sei es aus Kostengründen,
Platzmangel etc.
Bei der vorliegenden Diplomarbeit konnten nicht alle Programmfunktionen
an dem Testaufbau in Aachen überprüft werden. Die Busklasse CBusDummy

5.1 Die Klassen für den Feldbus 39
hat sich als hervorragendes Mittel, Tests ohne Verfügbarkeit des DESY-
Testaufbaues durchzuführen, herausgestellt. Dabei ist ihre Funktionsweise
sehr einfach: Alle mit ihrer Hilfe geschriebenen Daten verschwinden im Nichts,
ohne jemals einen Fehler zu generieren. Mit ihrer Hilfe gelesene Daten enthalten
als Wert stets die Null, auch hier ohne Fehlererzeugung.
5.1.2 Die SEDAC-Busklasse
Für die vom DESY zur Verfügung gestellte Entwicklungsplattform (MVME-
162-12a mit VxWorks und einem SEDAC-IP-Interface, vgl. Abschnitt 4.3.2
und 4.3.3) wurde die Busklasse CSedacIPIO entworfen, die die Ein- und Ausgabe
über SEDAC ermöglicht.
Sie erfüllt alle oben genannten Spezifikationen. Die Standardfehlerfunktion
DefaultBusErrorFunction korrigiert bis zu drei Übertragungsfehler pro Sekunde,
ohne daß ein schwerer Fehler ausgelöst wird. Diese geringe Anzahl
von erlaubten Fehlern ist absichtlich gewählt, damit der Programmfluß nur
sehr gering (mit SEDAC weniger als 0.1 %) verzögert wird und alle Echtzeitbedingungen
eingehalten werden können.
Dieser Mechanismus funktioniert so gut, daß während aller Tests nur noch
dann schwere Fehler auftraten, wenn die Leitung zu den Modulen physikalisch
unterbrochen wurde. Meßergebnisse zur Untersuchung der SEDAC-
Übertragungsrate bei Verwendung der Klasse CSedacIPIO befinden sich in
Abschnitt 7.1.
5.1.3 Anpassung an andere Feldbussysteme
Das vorgestellte Klassensystem ist für andere Feldbussysteme offen. Es benutzt
Eigenschaften, die nicht nur bei der Verwendung von SEDAC funktionieren,
sondern allgemein für Feldbussysteme charakteristisch sind. Soll
für eine zukünftige Anwendung ein neuer Feldbus zu dem bestehenden System
hinzugefügt werden, so muß bei der Entwicklung einer neuen Busklasse
allerdings darauf geachtet werden, daß alle im oben vorgestellten Interface
beschriebenen Funktionen für den Benutzer zur Verfügung gestellt werden.
Die Funktionen müssen so ausgelegt sein, daß sie in einer nebenläufigen Umgebung
andere Threads nicht blockieren. Natürlich muß auch eine geeignete
Standard-Fehlerbehandlungsroutine entworfen werden, die kleinere Fehler
abfängt und nur schwere Fehler an das Programm weiterreicht.
Trotz aller Bemühungen, das Kontrollsystem unabhängig von SEDAC zu
machen, sind einige SEDAC-spezifische Teile vorhanden. Dies geschah vor
allem, um die Geschwindigkeit des Buszugriffs zu steigern und die Sicherheit
des Kontrollsystems zu erhöhen. Damit aber ein Wechsel auf ein neues Feld-

40 5 DAS KLASSENKONZEPT
bussystem möglichst problemlos vollzogen werden kann, sind die SEDACspezifischen
Teile des Quelltextes mit dem Schlüsselwort SEDAC gekennzeichnet.
Durch eine Suche z. B. mit dem Programm Grep nach diesem Schlüsselwort
können die Stellen gefunden werden. Dort befindet sich ein kurzer
Kommentar, der die Eigenschaft von SEDAC beschreibt, auf die zurückgegriffen
wird. Eine entsprechende Änderung kann dann vorgenommen werden.
5.2 Module am Feldbus
Die für das Kontrollsystem entwickelte Klassenhierarchie ist in Abb. 12 dargestellt.
Durchgezogenen Linien zeigen die Ableitungshierarchie. Gepunktete
Linien bedeuten, daß die entsprechende Klasse einen oder mehrere Zeiger
bzw. Referenzen einer anderen Klasse enthält. Letzendlich bedeuten gestrichelte
Linien, daß eine Erweiterung an dieser Stelle erfolgen kann.
Da alle Meßsysteme der Strahllage- und Verlustmessung als SEDAC-Module
ausgelegt sind, liegt es nahe, eine Basisklasse CBusBoard zu schaffen, die
die grundlegenden Eigenschaften von Modulen definiert, die nur über einen
Feldbus erreichbar sind. Als wichtigstes Element enthält sie eine Referenz auf
die Busklasse, mit der die Datenübertragung über den Feldbus geschieht.
Ob das in der speziellen Anwendung eine Testklasse (CBusDummy) ist, oder die
Kommunikation über SEDAC (CSedacIPIO) oder über einen völlig anderen
Bus (anderer Bus) geschieht, ist wegen des einheitlichen Interfaces, das in
Abschnitt 5.1 vorgestellt wurde, gleichgültig.
Von der Basisklasse CBusBoard werden die zur Strahllage- und Verlustmessung
nötigen Module in drei Abstraktionsstufen abgeleitet. In der ersten
Stufe wird die HERA-spezifische Identifizierung der Module durch die Klasse
CHERABoard ermöglicht. In der zweiten Stufe werden die am HERA-Protonring
verwendeten Module deklariert. Diese stellen nur solche Methoden zur Verfügung,
die stets direkt auf die Hardware zugreifen.
In der dritten Abstraktionsstufe (der Klassenname trägt dann die Erweiterung
DAQ) werden Funktionen hinzugefügt, die speziell für die Datennahme
geeignet sind.
Natürlich existieren stets mehrere Module des gleichen Typs. Die Klasse
CGroup stellt deshalb Routinen zur Verfügung, die zur Verwaltung einer
Gruppe gleichartiger Module gedacht sind. Dies betrifft vor allem die Initialisierung,
die Steuerung der Datennahme und die gegenseitige Synchronisation.
Da immer noch spezielle Eigenschaften der jeweiligen Module berücksichtigt
werden müssen, werden von der Klasse CGroup weiter spezialisierte Klassen
abgeleitet, die auf diese Eigenschaften eingehen.

5.2 Module am Feldbus 41
5.2.1 Basisklasse
Basisklasse für alle diese Module ist die Klasse CBusBoard. Sie enthält einen
Verweis auf die Busklasse, mit der die Ein- und Ausgabe erfolgt und stellt die
Routinen Read und Write zur Verfügung, mit der die verschiedenen Register
dieses Moduls direkt adressiert werden können. Die Basisadresse des Moduls
ändert sich während der Programmlaufzeit nicht, deshalb wird sie nur einmal
zur Initialisierung der Klasse benutzt. Die Routinen Read und Write berücksichtigen
die Basisadresse automatisch, so daß nur noch die relative Adresse
angegeben werden muß. Diese ist aber für alle Module gleich, was den Zugriff
auf die Module transparenter macht.
CBusBoard dient dazu, die grundlegenden Funktionen der Module zu vereinheitlichen.
So definiert diese Klasse eine Routine Print, die den aktuellen
Status des Moduls auf dem Bildschirm ausgibt. Dies ist sehr nützlich zur Fehlersuche,
da die Ausgabe als Text erfolgt und die Richtigkeit der Angaben so
leicht überprüft werden kann.
Zwei Routinen, Reset und Connect, dienen zur Initialisierung. Da beim Start
des Programmes der Status der Hardware unbekannt ist, gibt es zwei Möglichkeiten
der Initialisierung: Entweder werden die Module ausgelesen und die
Software entsprechend initialisiert (Connect), oder die Module werden auf
einen vordefinierten Zustand gebracht (Reset). Letztere Routine ist nötig,
da sich der Status mancher Module (so z. B. bei PPD- und BLM-Modul) gar
nicht oder nicht vollständig auslesen läßt. Damit das Programm stets mit
korrekten Daten arbeitet, wird in allen anderen Funktionen mit Hilfe der
Funktion IsInitialized überprüft, ob das Modul mit Reset oder Connect
initialisiert wurde. Falls nicht, wird das Programm mit einer entsprechenden
Fehlermeldung beendet. Es liegt dann ein Fehler in der Programmierung des
Kontrollsystems vor, der zu Fehlfunktionen beim HERA-Betrieb führen kann
und behoben werden muß.
Weiterhin wird eine Routine Test definiert. Diese hat die Aufgabe, das Modul
zu überprüfen und eine Fehlermeldung auszugeben, wenn es defekt ist.
Denn während des Betriebs von HERA kann es vorkommen, daß ein Modul
wegen eines Schadens ausfällt und für die weitere Benutzung nicht mehr zu
gebrauchen ist. Da HERA dann nicht angehalten werden kann, um das betreffende
Modul auszubauen, muß es in dem Kontrollsystem eine Möglichkeit
geben, defekte Module abzuschalten. Sofern die Hardware eine solche Funktion
unterstützt, erledigen diese Aufgabe die Routinen Disable, Enable und
IsEnabled. Mit Disable wird das Modul in einen solchen Zustand versetzt,
in dem es keine Fehler in noch funktionierender Hardware auslösen kann.
Danach wird jeder Hardwarezugriff auf das Modul mit einer Fehlermeldung
beendet, mit zwei Ausnahmen: Zu Diagnosezwecken dürfen die oben genann-

42 5 DAS KLASSENKONZEPT
ten Routinen Print und Test aufgerufen werden.
Um das Kontrollsystem auch bei nebenläufiger Ausführung sicher zu machen,
existieren die Routinen Lock und Unlock. In Abb. 13 ist dargestellt,
was passieren kann, wenn zwei Threads auf die Routinen eines Moduls abwechselnd
zugreifen. Die gezeigte Situation ist in der Fachliteratur als “Race-
Client-Aufruf Datennahme
Disable!
CPU
Thread 1 Thread 2
IsEnabled? -> JA!
Read -> FEHLER
Abbildung 13: Fehler durch nichtabgesicherte Zugriffe
Condition” bekannt [10, 12]. In dieser Situation existieren zwei Threads: Ein
Client möchte ein Modul mit Disable abschalten, während die Datennahme
das Modul auslesen möchte. Am Anfang wird die CPU der Datennahme zugeteilt.
Sie überprüft mit IsEnabled, ob das Modul aktiviert ist, und erhält
eine positive Antwort. Jetzt passiert das Entscheidende: Die Datennahme
wird an dieser Stelle unterbrochen und der Aufruf des Clients bedient. Dieser
deaktiviert das Modul mit Disable. Nachdem die Datennahme wieder
den Prozessor zugeteilt bekommt, möchte sie das (jetzt deaktivierte) Modul
auslesen. Das führt zu einem Fehler mit Programmabruch.
Damit so etwas nicht passiert und die Daten eines Moduls stets in einem konsistenten
Zustand sind, werden Schloßvariablen benutzt. Diese werden oft als
“Locks”, manchmal auch als “Semaphoren 44 ” oder “Mutexes 45 ” bezeichnet.
Eine Lösung als Monitor, wie in [10] vorgeschlagen, kann hier nicht verwendet
werden. Ein Monitor sichert jeweils nur einen Funktionsaufruf gegen
die gleichzeitige Ausführung eines anderen ab. Nicht geschützt werden aber
44 Zur Kommunikation auf hoher See benutzte Signale
45 Mutual exclusion
Zeit

5.2 Module am Feldbus 43
aufeinanderfolgende Aufrufe, wie sie hier erfolgen (IsEnabled und Read).
Deshalb existieren die Funktionen Lock und UnLock. Vor dem Zugriff auf
die Routinen eines Moduls muß stets der Zugriff auf das Modul mit einem
Schloß verschlossen werden (Lock), und nachdem alle Aufgaben erledigt wurden,
wird das Schloß wieder geöffnet (Unlock). Der obige Programmablauf
sieht dann aus wie in Abb. 14. Falls eine Schloßvariable bereits von einem
Thread benutzt wird, so wird der andere angehalten, wenn er versucht, das
Schloß zu schließen. Er darf erst dann das Schloß verschließen, wenn das
Schloß von dem anderen Thread geöffnet wurde. Die Implementation der
Locks geschieht mit den im Pthread-Standard bereitgestellten Funktionen
pthread mutex lock und pthread mutex unlock [12].
5.2.2 Spezialisierung für HERA
Das bei HERA benutzte Kontrollsystem ordnete bis zu der erst kürzlich
mit ACOP [3] erschienenen Version jedem Modul eines speziellen Typs eine
Nummer, die sogenannte “Equipment Number” zu, mit der es identifiziert
wird. Außerdem wurde für jedes Modul ein Name vergeben, der die Halle,
den Oktanten und Position des Crates, in dem sich das Modul befindet,
angibt. So bezeichnet z. B. der Name WL131 das Modul im Crate Oktant
West links, von der Halle aus gemessen 131 Meter den Tunnel entlang. Der
Name ist nicht eindeutig, da in einem Crate durchaus mehrere Module des
gleichen Typs sein können.
Die Klasse CHERABoard ist abgeleitet von BusBoard, enthält also alle in
CBusBoard beschriebenen Funktionen. Erweitert wird die Basisklasse durch
die Aufnahme der Identifikationsnummer und den Namen des Moduls. Die
Routine Print ruft die Ausgabe der Basisklasse auf und gibt zusätzlich die
Crateposition des Moduls aus.
Die neue Version des Kontrollsystems benutzt nur noch Identifikationsnamen
wie z. B. “PPD/WL131-1X”. Da aber viele Client-Anwendungen, darunter
auch alle, die auf das Strahllage-Kontrollsystem zugreifen, noch mit
Nummern arbeiten, wurde die jetzige Implementierung mit Nummern beibehalten.
Für zukünftige Versionen können die in CHERABoard enthaltenen
Crate-Positionen jedoch durch eindeutige Zeichenketten ersetzt werden und
so zusätzlich die neuen Fähigkeiten von ACOP verwendet werden.
5.2.3 Abstraktion von Registerzugriffen
Die Klassen CAlarm, CBLM, CBLMPickup, CDelay, CMTM, CPPD und CPMST sind
alle von CHERABoard abgeleitet. Diese Klassen definieren Routinen, die von
dem speziellen Hardwarezugriff abstrahieren. Die nach außen zur Verfügung

44 5 DAS KLASSENKONZEPT
CPU
Thread 1 Thread 2
Client-Aufruf Datennahme
Lock -> WARTEN
Disable! -> OK
UnLock -> OK
Lock -> OK
IsEnabled? -> JA!
Read -> OK
UnLock -> OK
Abbildung 14: Durch Schloßvariablen abgesicherte Zugriffe
Zeit

5.2 Module am Feldbus 45
gestellten Routinen repräsentieren Funktionen des Moduls. So exisitiert z. B.
die Routine CAlarm::ResetFreeze, die das Einfrieren der Daten der Strahllageund
Verlustmonitore aufhebt, oder die Routine CBLM::SetLimit, die die
Schwelle für das Erzeugen eines Alarms bei zu hohem Strahlverlust setzt, oder
CPMST::InsertGap, die die vom HIT-System gesendete Triggerkette für die
Synchronisierung der PPD-Module kurz unterbricht, oder auch CDelay::ReadDelay,
die den momentan gesetzten Wert eines Delays aus dem Delay-Modul ausliest.
Beim Aufruf braucht man nicht in Erinnerung zu haben, daß z. B. im
Falle von CAlarm::ResetFreeze das Register 1 mit dem Wert 255 beschrieben
werden muß.
Die Namen der Routinen beginnen mit Set, wenn ein Schreibbefehl an das
Modul gesendet wird, und mit Read, wenn ein Wert aus dem Modul ausgelesen
wird. Es werden keine Daten zwischengespeichert, so daß bei zwei
aufeinanderfolgenden Read- oder Set-Aufrufen immer wieder auf den Bus
zugegriffen wird.
Auf diese Art und Weise wird die Funktionsweise des Moduls durch die Funktionen
der Klasse repräsentiert, die Kenntnis der Registerzugriffe ist für eine
Benutzung der Klasse nicht mehr notwendig.
5.2.4 Spezialisierung zur Datennahme
In einer weiteren Abstraktionsebene werden weitere, speziell für die Datennahme
geeignete Funktionen hinzugefügt. Dazu werden die in der ersten Abstraktionsstufe
geschaffenen Read- und Set-Routinen erweitert, so daß gelesene
bzw. geschriebene Daten im Arbeitsspeicher des Computer zwischengespeichert
werden. Das ist sinnvoll, da dadurch viele Buszugriffe vermieden
werden können. Damit dieses Konzept vollständig wird, wird zu jeder der
vorhanden Read-Routinen noch eine Get-Routine entworfen. Die Routinen
Read, Set und Get arbeiten Hand in Hand. Mit der Routine Read werden
die Daten aus der Hardware ausgelesen und im Arbeitsspeicher niedergelegt.
Die Routine Set sendet die Daten zur Hardware und legt eine Kopie der
gesendeten Daten im Arbeitsspeicher ab. Auf diese Art und Weise sind die
aktuellen Daten stets im Arbeitsspeicher des Computers verfügbar. Mit der
Routine Get können sie aus dem Arbeitsspeicher ausgelesen werden, ohne
daß dazu ein Buszugriff nötig wäre. Das ist besonders für das im Abschnitt
4.1 zur Steigerung der Geschwindigkeit Gesagte wichtig.
Der Server wird nämlich in einer Schleife stets Read-Routinen aufrufen, um
die Module auszulesen und die Daten im Arbeitsspeicher zur Verfügung zu
stellen. Die Clients rufen dann nur noch Get-Routinen auf, die nicht mehr
auf die Hardware zugreifen.

46 5 DAS KLASSENKONZEPT
5.3 Gruppenverwaltung
Die bisher geschaffenen Klassen repräsentieren stets ein Modul. Von jedem
der oben angesprochenen Module existiert aber nicht nur ein einziges Exemplar,
sondern stets eine ganze Gruppe. Oft muß für alle Module eine Aufgabe
wiederholt durchgeführt werden, so z. B. bei der Initalisierung, beim Starten
bzw. Stoppen der Datennahme, beim Setzen eines neuen Modus etc.
Die Klasse CGroup ist Basisklasse für alle verwendeten Gruppenklassen. Sie
definiert allgemeine Funktionen, die für die Verwendung von Feldbusmodulen
typisch sind. Die Klasse soll verschiedene Modultypen aufnehmen und muß
deshalb als Template entworfen werden [13].
Aufgrund einer Inkompatibilität zwischen dem Compiler und Linker, die
für das Betriebssystem VxWorks mitgeliert wurden, konnten die im ANSI-
Standard [2] enthaltenen Templates nicht verwendet werden. Deshalb wurde
eine für alle C++-Compiler anwendbare Methode entwickelt, die mit Hilfe
des C++-Präprozessors Templates erzeugen kann. Die Instantiierung der
Templates muß aber dann im Quelltext explizit erfolgen. So erzeugt z. B. der
der Datei ClassPPDGroup.hpp entnommene Quelltextauszug
// start with a clean state
#undef CGroup
#undef T
#undef Max
// now we define manually the template values
#define CGroup CGroupCPPDDAQMAX_NUMBER_PPD
#define T CPPDDAQ
#define Max MAX_NUMBER_PPD
eine Gruppenklasse, die eine maximale Anzahl Max = MAX NUMBER PPD Module
des Typs T = CPPDDAQ aufnehmen kann. Die Wirkungsweise dieser Zeilen
ist identsich zur Instantiierung der Templates im ANSI-Standard, muß aber
stets vor Einbindung der Klasse CGroup in der oben beschriebenen Weise
erfolgen.
Intern werden die Module über ein Array verwaltet, das Zeiger auf die einzelnen
Module enthält. Die Routinen ReadInfo, ReadSpecific und ClearInfo
dienen zur Schaffung der einzelnen Module, die in der Klasse enthalten sind.
Die Routine ClearInfo löscht alle vorhanden Module aus der Klasse heraus,
so daß die mit ReadInfo anschließend eine Initialisierungsdatei eingelesen
werden kann, die Informationen über die Module enthält. Das Format dieser
Datei ist konform zum DESY-Standard ein CSV-Format. Die Dateien können
deshalb einfach und mit DESY-üblichen Mitteln verändert werden. Jede Zeile

5.3 Gruppenverwaltung 47
in dieser Datei beschreibt ein einzelnes Modul. Der erste Wert in jeder Zeile
entspricht der Nummer, mit der das Modul über RPC angesprochen wird.
Der zweite Wert bestimmt, über welchen Bus das Modul angesprochen wird
(Bus 0 oder 1). Der dritte Wert ist die Busadresse, der vierte die Position
des Crates, in dem das Modul untergebracht ist. Nach diesen Informationen,
die für alle Feldbus-Module gleich sind, können in der Datei modulspezifische
Informationen folgen. Nach dem Einlesen der Standard-Informationen
wird die Routine ReadSpecific aufgerufen, die von den abgeleiteten Klassen
überschrieben wird und die modulspezifischen Informationen ausliest. Sie erzeugt
anschließend die Module, die dann in dem internen Array gespeichert
werden.
Nachdem die Initialisierungsdatei gelesen wurde, kann mit Hilfe von Connect
die Software an den Status der Module angepaßt werden. Ist dies nicht
möglich, so sorgt Connect dafür, daß die Module in einen definierten Status
gesetzt werden. Intern geschieht dies durch einen Aufruf der in der Klasse
CBusBoard definierten Routinen Connect und Reset.
Wenn die Initialisierung erfolgreich durchgeführt wurde, kann die Datennahme
mit StartDAQ begonnen bzw. mit StopDAQ beendet werden. Die Datennahme
selbst geschieht in der Routine DAQTask, die durch die abgeleiteten
Klassen überschrieben und für die jeweiligen Module angepaßt wird.
Damit die Clients mit Hilfe der RPC-Aufrufe auch einzelne Module ansprechen
können, existiert der operator[]. Er übergibt an die aufrufende Routine
einen Zeiger auf das gewünschte Modul, so daß diese das Modul direkt
ansprechen kann.
Dabei muß wegen der in Abb. 13 dargestellten und in Abschnitt 5.2.1 beschriebenen
Problematik eine Schloßvariable benutzt werden. Dies geschieht
mit Hilfe der Routinen ModuleThere und LeaveModule. Vor einem Zugriff
auf ein Modul wird mit ModuleThere überprüft, ob das verlangte Modul
tatsächlich von diesem Server aus erreichbar ist (Es könnte ja von einem der
drei anderen Server verwaltet werden). Ist das Modul angeschlossen, wird
die Schloßvariable verschlossen und dem Aufrufer mitgeteilt, daß das Modul
da ist. Nach beendigtem Zugriff muß die Routine LeaveModule aufgerufen
werden, die die Schloßvariable wieder öffnet.
Von der Basisklasse CGroup werden die Gruppenklassen CALMGroup für die
Alarm-Module, CBLMGroup für die Verlustmonitore, CDLYGroup für die Delay-
Module, CMTMGroup für die Lagemonitor-Trigger-Module und CPPDGroup für
die Lagemonitore abgeleitet. Da nur ein PMST-Modul existiert, ist keine
Gruppe für dieses Modul nötig.
Die abgeleiteten Klassen erweitern die Funktionen der Klasse CGroup in der
für das jeweilige Modul nötigen Art und Weise.

48 6 DATENNAHME
5.4 Kommunikation mit den Clients
Ideal wäre es, wenn die Kommunikation mit den Clients über eine Funktion
geschehen könnte, die in der Klasse CGroup enthalten ist. Leider sieht die
neueste Version des ACOP-Systems eine solche Möglichkeit nicht vor [4], so
daß Funktionen geschaffen werden mußten, die außerhalb des Klassensystems
liegen. Diese greifen aber immer auf die in der Klasse deklarierten Funktionen
zurück, so daß es sich um ein eher nebensächliches Problem handelt. Die
Routinen rpc alm, rpc blm, rpc dly, rpc mtm und rpc ppd bilden das zum
HERA-Kontrollsystem kompatible Interface.
Die Dokumentation dieses Interface geschah besonders ausführlich, da es für
ein korrektes Zusammenspiel von Clients und Servern von entscheidender Bedeutung
ist. Jede über RPC aufrufbare Funktion wurde im Quelltext der oben
genannten Funktionen mit einer genauen Beschreibung ihrer Wirkungsweise
sowie ihrer Ein- und Ausgabeparameter versehen. Die Funktionen sind — bis
auf kleinere Abweichungen — mit dem jetzigen Interface [30, 5] des zur Zeit
noch verwendeten Kontrollsystems identisch. Da manche dieser Funktionen
nur noch historische Bedeutung haben, werden in dem neuen Kontrollsystem
nicht alle Funktionen des alten Systems unterstützt.
6 Datennahme
In den folgenden Abschnitten werden die von dem Kontrollsystem in den verschiedenen
Betriebsmodi von HERA bereitgestellten Datennahmefunktionen
erläutert.
6.1 Das Lagekontrollsystem
Die Aufgabe der Strahllagemessung untergliedert sich in mehrere verschiedene
Unteraufgaben, die von der HERA-Betriebsart abhängig sind. Die Überwachung
und Steuerung von Injektion und Speicherbetrieb erfordert unterschiedliche
Daten, die aus den Modulen ausgelesen und vom Kontrollsystem
zur Verfügung gestellt werden müssen.
6.1.1 Injektionsbetrieb
Bei der Protoninjektion kommt es vor allem darauf an, den zu injizierenden
Strahl möglichst genau auf seine Sollbahn, den Orbit, zu bringen. Deshalb
ist der Verlauf der Strahlablage besonders während der ersten Umläufe im
Protonring interessant. Das hier entwickelte System bietet für den Injektionsbetrieb
zwei verschiedene Arten der Datennahme.

6.1 Das Lagekontrollsystem 49
Im “Injection-Modus” werden nach erfolgter Injektion von jedem Monitor die
ersten 1024 aufeinanderfolgenden Umläufe aufgenommen. Das erlaubt eine
genaue Verfolgung der Strahllage und eine Analyse des zeitlichen Verhaltens.
Ein Ablaufschema des Datennahmezyklus ist in Abb. 15 dargestellt. Der
Client setzt den Server mit Hilfe eines Prozedurfernaufrufs (RPC) in den
Injektionsmodus. Dabei wird eine eventuell noch laufende Datennahme gestoppt.
Anschließend wird die Triggerkette mit Hilfe des PMST-Moduls gestoppt.
Damit wird verhindert, daß während des anschließenden Zugriffs auf
die PPD-Module diese unsynchronisiert anlaufen. Nachdem der Modus, mit
dem der 1024 Umläufe fassende Post-Mortem-Speicher beschrieben wird, in
allen PPD-Modulen gesetzt worden ist, wird das PMST-Modul in den getriggerten
Mode gesetzt, so daß es mit Beginn der Injektion von PETRA
nach HERA 1024 aufeinanderfolgende Triggerpulse durchläßt. Anschließend
wird die Datennahme gestartet und dem Clienten mitgeteilt, daß der Modus
erfolgreich gesetzt wurde.
Nach erfolgter Injektion dauert es etwa 22 ms, bis der SID-Zähler in den
PPD-Modulen den Stand von 1024 Umläufen anzeigt. Der Zählerstand wird,
damit die Anzahl der Buszugriffe gering bleibt, nur von dem Thread für
Bus 0 abgefragt. Dies geschieht periodisch in 17 ms-Intervallen 46 . Die Bedingung,
daß die Datennahme beginnen kann, wird dem wartenden Thread für
Bus 1 mitgeteilt. Daraufhin fangen beide an, ihre Daten über den Feldbus
einzusammeln.
Währenddessen wird der Client in periodischen Intervallen über RPC-Aufrufe
herauszufinden versuchen, ob die Daten bereits ausgelesen worden sind.
Wurden alle PPD-Module ausgelesen, synchronisieren sich die DAQ-Threads
untereinander, bevor sie die Beendigung ihrer Auslesetätigkeit über das Setzen
eines Flags bekanntgeben. Die Synchronisation ist notwendig, damit nicht
frühzeitig von einem Thread die Beendigung der Datenauslese angezeigt wird,
bevor der andere tatsächlich fertig ist.
Jetzt wird dem Clienten, der ständig über RPC die Verfügbarkeit der Daten
prüft, die erfolgte Datennahme angezeigt. Der holt daraufhin seine Daten ab,
wobei noch einmal sichergestellt wird, daß tatsächlich neue Daten vorhanden
sind.
Die übertragene Datenmenge ist in dieser Betriebsart jedoch sehr groß, da
von durchschnittlich 17 Monitoren pro Bus 2 Kanäle mit 1024 Werten ausgelesen
werden müssen. Es dauert entsprechend lange, ehe die Daten für die
Benutzer im Kontrollraum zur Verfügung stehen. Auch wenn nur zwei bestimmte
Umläufe zum Vergleichen ausgewählt werden (diese Möglichkeit ist
in dem Kontrollsystem vorgesehen), müssen aufgrund der technischen Ge-
46 Das ist das kleinste auf der MVME-162-12a einstellbare Intervall.

50 6 DATENNAHME
Client
Set Mode:
Injection Mode
OK
Data ready?
No
Data ready?
No
Data ready?
Yes
Get Data
OK
Server
RPC DAQ Bus 0 DAQ Bus 1
StopDAQ
PMST-Mode:
Stop Trigger
Forall PPD:
Mode: Memory
PMST-Mode:
1024 Trigger
Start DAQ
Check Flag
Check Flag
Check Flag
Check Flag
Send Data
WaitForSID Await condition
= 1024 Got SID?
Set condition
Got SID!
Read complete
memories
Await condition
Bus 1 ready
Set Flag
Data Ready
Read complete
memories
Set condition
Bus 1 ready
HERA
INJEKTION!
Abbildung 15: Ablauf der Datennahme im Injektionsmodus. Gepunktete Linien
stehen für räumliche Trennung. Die Programmausführung geschieht im Server nebenläufig
in drei Threads: RPC und DAQ für Bus 0 und Bus 1. Durchgezogene
Linien stehen für eine ununterbrochene Programmausführung. Gestrichelte Linien
bedeuten, daß der Thread auf den Eintritt einer Bedingung wartet. Andere
Threads werden dadurch nicht blockiert und werden vom Betriebssystem weiter
ausgeführt. Sobald die Bedingung erfüllt ist, werden die wartenden Threads automatisch
vom Betriebssystem fortgesetzt. Die “Schleife” im Zeitablauf bedeutet, daß
die Programmausführung am Endpunkt der Schleife wieder aufgenommen werden
kann.
Zeit

6.1 Das Lagekontrollsystem 51
gebenheiten des Strahllagemonitors alle 1024 Werte pro Kanal ausgelesen
werden [31].
Nimmt man als untere Abschätzung für die Dauer des Auslesevorgangs die
SEDAC-Maximalgeschwindigkeit als Bustransferrate an 47 , so erhält man den
erschreckenden Wert von mindestens 9 Sekunden!
Deshalb ist in dem hier entwickelten Kontrollsystem ein zweiter Modus, der
sogenannte “Single-Turn-Modus” integriert. Bei diesem werden die Intensitäts-
und Lagedaten eines einzelnen Umlaufs von allen Lagemonitoren ausgelesen,
so daß die Daten entsprechend schneller für den Client zur Verfügung
stehen. Dies geschieht intern durch die Verwendung eines anderen Betriebsmodus
des PPD-Moduls. Die Nummer des für die Datenauslese gewählten
Umlaufs muß aber im PMST-Modul vor der Injektion festgelegt werden, damit
die Daten in den Registern des PPD nicht überschrieben werden. Mögliche
Werte für den ausgewählten Umlauf liegen im Bereich von der ersten bis
zur 1024ten Umrundung. Da hier nur sechs Werte pro Monitor ausgelesen
werden, ergibt eine untere Abschätzung für die Dauer der Datennahme etwa
25 ms. Der Ablauf in dieser Betriebsart ist in Abb. 16 dargestellt.
6.1.2 Speicherbetrieb
Ist der Protonstrahl gespeichert, soll in regelmäßigen Abständen die aktuelle
Abweichung vom Orbit gemessen werden. Im Kontrollsystem existiert deshalb
ein “Orbit-Modus”, der mehrfach pro Sekunde aktuelle Lageinformationen
von allen Lagemonitoren zur Verfügung stellt. Mit deren Hilfe kann
z. B. von einem Client der Orbit korrigiert werden. Andererseits bieten die
Daten auch die Möglichkeit, sogenannte “Orbitbeulen” zu überwachen. Eine
“Orbitbeule” entsteht, wenn die Protonen mit Hilfe von mehreren Korrekturspulen
absichtlich von ihrer Sollbahn abgelenkt und anschließend wieder
auf die Sollbahn zurückgelenkt werden. Je nach Anzahl der zur Ablenkung
verwendeten Magnete entstehen dabei auf der ursprünglichen Protonbahn
ein oder mehrere Buckel, die der Orbitbeule ihren Namen geben.
Daneben existieren für spezielle Messungen und zur Berechnung des Q-Wertes
zwei weitere Betriebsmodi des Lagekontrollsystems. Sie werden mit “Q-
Modus” bzw. “Small-Q-Modus” bezeichnet. Im Q-Modus werden — ähnlich
wie im “Injection-Modus” — 1024 aufeinanderfolgende Umläufe von allen
Lagemonitoren aufgenommen und ausgelesen. Der Unterschied zwischen Q-
Modus und Injection-Modus besteht lediglich im Start der Triggerkette. Der
geschieht im Q-Modus nicht über eine Proton-Injektion, sondern wird vom
Kontrollsystem selber ausgelöst. Wegen dieses minimalen Unterschiedes wur-
47 Meßergebnisse befinden sich in Kapitel 7.

52 6 DATENNAHME
Client Server
Set Turn "n"
OK
Set Mode:
Single Turn Mode
OK
Data ready?
No
Data ready?
No
Data ready?
Yes
Get Data
OK
RPC DAQ Bus 0 DAQ Bus 1
Store Turn "n"
StopDAQ
PMST-Mode:
Stop Trigger
Forall PPD:
Mode: Turn
PMST-Mode:
"n" Trigger
Start DAQ
Check Flag
Check Flag
Check Flag
Check Flag
Send Data
WaitForSID
= "n"
Set condition
Got SID!
Read
6 Registers
Await condition
Bus 1 ready
Set Flag
Data Ready
Await condition
Got SID?
Read
6 Registers
Set condition
Bus 1 ready
HERA
INJEKTION!
Abbildung 16: Ablauf der Datennahme im Single-Turn-Modus. Eine Erklärung
der verwendeten Symbolik findet sich bei Abb. 15
Zeit

6.1 Das Lagekontrollsystem 53
de auf ein eigenes Ablaufdiagramm verzichtet. In Abb. 15 entfällt die Injektion,
und bevor der Thread für Bus 0 auf den konstanten Wert des SID-Zählers
wartet, sendet er einen Befehl an das PMST-Modul, der die Triggerkette startet.
Da die gleiche Anzahl von Daten ausgelesen wird, lautet auch hier die
Abschätzung für die Dauer der Datennahme: Mindestens 9 Sekunden.
Für spezielle Messungen existiert ein weiterer Modus, der Small-Q-Modus.
Dabei werden nicht aufeinanderfolgende Positionen abgespeichert, sondern
Mittelwerte über die letzten 128 Positionen. Insgesamt können 256 Mittelwerte
abgespeichert werden, so daß insgesamt Daten über eine Vergangenheit
von 32768 Umläufen vorhanden sind.
Die Datennahme unterscheidet sich hier nicht wesentlich von der des Q-
Modus. Es wird im PMST-Modul eine Anzahl von 128·256 Triggern statt
bisher 1024 eingestellt. Entsprechend länger wird auch auf den konstant bleibenden
Wert des SID-Zählers gewartet (etwa 0.7 s).
Die DAQ-Threads lesen im Small-Q-Modus einen anderen, kleineren Speicher
als im Q-Modus aus (vgl. Abb. 6. Entsprechend kürzer ist die Abschätzung
für die Dauer der Datennahme: Etwa zweieinhalb Sekunden.
Der Ablauf der Datennahme im “Orbit-Modus” ist in Abb. 17 wiedergegeben.
Er ist grundsätzlich verschieden von dem Ablauf der bisherigen Modi, da
er als einziger kein getriggerter Modus ist. Das PMST-Modul wird durch den
RPC-Aufruf des Client in den kontinuierlichen Modus gesetzt. Ebenso werden
alle PPD-Module in einen internen Betriebsmodus gesetzt, der für die kontinuierliche
Folge von Triggerpulsen gedacht ist. Das PPD-Modul verhält sich
dabei wie folgt [31]: Nachdem 128 Lagemessungen durchgeführt wurden, wird
ein Mittelwert über diese Messungen berechnet und ein Flag in einem Statusregister
gesetzt. Dieses “Data-Ready”-Flag bleibt für etwa 36 ms sichtbar
und verschwindet dann. Mit Beginn des Erscheinens dieses Flags startet eine
Timeout-Phase, deren Dauer man in Einheiten von 86.5 ms variieren kann,
wobei eine Mindestdauer von 137 ms eingehalten werden muß. Während dieser
Timeout-Phase lassen sich der Stand des SID-Zählers, die Intensität, die
Position des letzten Umlaufs und die über die letzten 128 Umläufe gemittelte
Position aus den Registern des PPD-Moduls auslesen. Nach dem Ende der
Timeout-Phase startet ein neuer Datennahmezyklus. Dieser Ablauf ist im
rechten, mit “PPD” bezeichneten Teil der Abb. 17 gezeigt.
Einer der Gründe für die Benutzung eines echtzeitfähigen Betriebssystems
war die kurze Zeitdauer von 36 ms, in der das PPD-Modul den Beginn
der Timeout-Phase anzeigt. Verpaßt nämlich einer der vier Server des Lagekontrollsystem
das Setzen des “Data-Ready”-Flags, so sind dessen Daten
gegenüber den Daten der anderen Server veraltet. Werden dann von einem
Clienten die Daten aller Server abgerufen, so müssen alle auf der Synchronität
der Server basierenden Berechnungen falsche Ergebnisse liefern.

54 6 DATENNAHME
Client
Set Mode:
Orbit Mode
OK
Data ready?
No
Data ready?
No
Data ready?
Yes
Get Data
Server
RPC DAQ Bus 0 DAQ Bus 1
StopDAQ
PMST-Mode:
Stop Trigger
Forall PPD:
Mode: Register
PMST-Mode:
Continuous
Start DAQ
Check Data "A"
Exchange Data
"A" "B"
Check Data "A"
Send Data "A" Set condition
OK Got Timeout!
WaitForTimeout Await condition
Got Timeout?
Set condition
Got Timeout!
Read Data "B" Read Data "B"
6 Registers 6 Registers
Await condition
Bus 1 ready
Check Data "A"
Set Flag
Data "A" Ready
Check Data "A"
WaitForTimeout
Set condition
Bus 1 ready
Await condition
Got Timeout?
PPD
Abbildung 17: Ablauf der Datennahme im Orbit-Modus. Eine Erklärung der Symbolik
findet sich in Abb. 15
Timeout
Take Data
Take Data
Flag!
Flag!
Zeit

6.2 Das Verlustkontrollsystem 55
Damit das nicht passiert, wird der Datennahme von den Lagemonitoren gegenüber
der Datennahme von Verlustmonitoren und Alarmmodul eine höhere
Prioriät eingeräumt. Das Betriebssystem garantiert durch seine Echtzeitfähigkeit
die Unterbrechung der Datennahme von Verlustmonitoren und
Alarm-Modulen, sobald das Lagesystem das “Data-Ready”-Flag auslesen
will. Dies geschieht, um eine sichere Detektion zu gewährleisten, in 17 ms-
Intervallen. Ein gesetztes “Data-Ready”-Flag (Dauer: 36 ms) sollte somit
mindestens zweimal entdeckt werden. (In [10] wird ein solches Vorgehen empfohlen.)
Da neue Daten etwa viermal pro Sekunde bereitstehen, ist eine Kommunikation
mit dem Client wie bei den getriggerten Modi nicht sinnvoll. Fragt
der Client nämlich zuerst nach, ob neue Daten bereitstehen, und holt sie
erst anschließend ab, so kann der Server in der Zwischenzeit schon mit einer
erneuten Auslese begonnen haben. In diesem Fall würde ein inkonsistenter,
aus zwei verschiedenen Umläufen bestehender Datensatz abgeholt werden.
Zur Lösung dieses Dilemmas wurden zwei getrennte Speicherbereiche in dem
Server für die Aufnahme der Datensätze jeweils eines Umlaufs bereitgestellt
(Double-Buffering). Der Datensatz “A” ist stets gefüllt mit einem kompletten
Satz von Lageinformationen und kann an den Client übergeben wird, sobald
dieser nach neuen Daten verlangt. Der Datensatz “B” wird in der Zwischenzeit
durch die beiden DAQ-Threads angefüllt. Nach beendeter Datennahme
existieren zwei vollständige Datensätze. Durch einen Austausch der beiden
Datensätze erhält der Client beim nächsten Aufruf mit dem Datensatz “A”
die frisch gesammelten Daten, während die DAQ-Threads bereits wieder mit
der Datennahme des Datensatzes “B” beschäftigt sind. So ist sichergestellt,
daß der Client stets die Daten aus einem zusammenhängenden Umlauf erhält.
6.2 Das Verlustkontrollsystem
Durch den gemeinsamen Anschluß von Verlustmonitoren und Lagemonitoren
am gleichen Feldbus wird die Situation noch komplizierter gemacht, als
sie schon ist. Die Verlustmonitore von HERA waren nämlich ursprünglich
nicht für ein Online-Monitoring gedacht [26], für das sie jetzt aber benutzt
werden. Die Verlustmonitore haben nämlich die unangenehme Eigenschaft,
daß stets ein kompletter Speicher in einem Schwung ausgelesen werden muß.
Tritt während zweier aufeinanderfolgender Zugriffe eine Pause von mehr als
2.3 ms auf, so sind die Daten nicht mehr in der zeitlich richtigen Abfolge,
da sie mit neuen Daten überschrieben werden. Deshalb wird für die Auslese
von einem solchen Speicher der Bus exklusiv zur Verfügung gestellt.
Bei einer Speichergröße von 128 16-bit-Werten entspricht das bei einer angenommenen
SEDAC-Transferrate für 16-bit-Werte von 4 kHz einer Zeit von

56 6 DATENNAHME
mindestens 32 ms. Bedenkt man, daß das Zeitintervall zum Feststellen des
“Data-Ready”-Flags im PPD-Modul 36 ms beträgt, bleibt nach dem Auslesen
eines Verlustmonitors nur noch sehr wenig Zeit übrig, bevor es wieder verschwindet.
Während dieser Zeit muß die Detektion des “Data-Ready”-Flags
geschehen. Deshalb erhält das Lagekontrollsystem die höchste Priorität unter
allen Datennahme-Threads.
Strahlverluste werden beim Betrieb von HERA ständig überwacht, hier ist
keine Unterscheidung für Injektions- und Speicherbetrieb nötig. Wegen der
Energieabhängigkeit der maximalen Verlustraten ist aber eine Steuerung des
Systems entsprechend der aktuellen HERA-Energie wichtig. Während der
Proton-Injektion bei 40 GeV dürfen höhere Verlustraten gemessen werden
als bei der endgültigen Energie von 820 GeV. Deshalb werden die Alarmschwellen
der Strahlverlustmonitore ständig nachgeregelt.
Wie dies geschieht, ist in Abb. 18 gezeigt. Der Server wartet auf einen Broadcast
des HERA-Kontrollsystems über Ethernet. Trifft ein solcher Broadcast
ein, so wird zunächst überprüft, ob es sich um einen Broadcast der HERA-
Energie handelt. Ist das der Fall, so wird für alle BLM-Module eine Routine
aufgerufen, die die Alarmschwellen an die aktuelle HERA-Energie anpaßt.
Diese Routine berechnet das der neuen Energie entsprechende Limit.
Nur wenn dieses von dem zur Zeit gesetzten abweicht, wird die Hardware
angesprochen. Dieses Vorgehen entlastet den Feldbus von der Übertragung
unnötiger Daten und sorgt so für eine größere Schnelligkeit bei der Datennahme
von Lage- und Verlustmonitoren.
Die Verlustdaten werden von zwei DAQ-Threads ständig ausgelesen. Dabei
läßt sich von den Clients einstellen, ob jeweils der Speicher mit Mittelwerten
oder der Speicher mit Einzeldaten ausgelesen werden soll. Der Grund für die
Auslese nur eines Speichers ist die Dauer des Auslesevorgangs. Würden beide
ausgelesen, wäre die Aktualisierungsrate der Anzeige im Beschleunigerkontrollraum
halbiert. Da schon die Auslese nur eines Speichers bei 40 Modulen
pro Bus mindestens 1.3 Sekunden dauert, wäre eine Verdoppelung dieser Zeit
für die Benutzer im Kontrollraum unangenehm, vor allem da die Daten beider
Speicher zum Online-Monitoring nicht nötig sind. Standardmäßig wird
von allen Strahlverlustmonitoren der Einzeldatenspeicher ausgelesen.
6.3 Alarme, Archivierung
Neben der ständigen Datennahme von Lage- und Verlustmonitoren gibt es
ein drittes Paar von Threads, die während der gesamten Strahlzeit von HE-
RA Daten nehmen. Das Auslesen der Alarm-Module und die Anzeige der
von den Lage- und Verlustmonitoren ausgelösten Alarme können dazu benutzt
werden, Probleme in der Steuerung des Beschleunigers zu erkennen und

6.3 Alarme, Archivierung 57
HERA
Broadcast
current energy
wait for
broadcast
Is Energy
Broadcast?
forall BLM:
Adjust Limits
NO
compute new
limit value
SERVER
YES NO
new limit
!= old limit?
YES
set new
limit value
Abbildung 18: Darstellung des Algorithmus für die automatische Anpassung der
Alarmschwellen an die HERA-Energie. Eckige Boxen kennzeichnen auszuführende
Funktionen, Abgerundete Boxen stellen eine Programmverzweigung aufgrund einer
Bedingung dar. Der Programmfluß erfolgt in der Richtung der eingezeichneten
Pfeile.
rechtzeitig vor einem Strahldump Gegenmaßnahmen zu ergreifen.
Eine weitere Aufgabe der DAQ-Threads ist es, einen erfolgten Strahldump
festzustellen und eine Archivierung der Daten der Verlustmonitore auszulösen.
Dazu werden die Status-Register der Alarm-Module ausgelesen und untersucht,
ob ein “Freeze”, ein Einfrieren der Daten von Lage- und Verlustmonitoren,
eingetreten ist. Dies ist nur dann der Fall, wenn ein Strahldump eingetreten
ist. Wird eine gewisse Anzahl von Alarm-Modulen, die einen Freeze signalisieren,
festgestellt, so wird dies durch das Setzen eines “Freeze”-Flags im
Kontrollsystem signalisiert. Die Anzahl von Modulen, bei der dies geschieht,
kann in der zentralen Steuerdatei global.hpp beliebig festgelegt werden.
Das Setzen des Freeze-Flags wird von den DAQ-Threads der Verlustmonitore
nach dem Auslesen eines jeden Monitors überprüft. Ist das “Freeze”-Flag gesetzt,
dann werden alle aktuellen Verlustdaten sowohl aus dem Kurzzeitspeicher
als auch aus dem Langzeitspeicher ausgelesen und anschließend von dem
Kontrollsystem in einer Datei abgespeichert. Das Dateiformat entspricht dem
am DESY üblichen Format für “event-driven archiving”. Deshalb können die
auf diese Weise gespeicherten Daten mit den am DESY vorhandenen Mitteln
ohne weitere Probleme analysiert werden.

58 7 TESTS
7 Tests
In Abb. 19 ist das Crate abgebildet, das vom DESY für Tests in Aachen
zur Verfügung gestellt wurde. Ganz links befindet sich der SEDAC-Crate-
Controller, rechts daneben ein BLM-Modul mit einem am obersten Anschluß
angeschlossenen Verlustmonitor, der oben auf dem Crate liegt. Dann folgen
(nach rechts) das Monitor-Trigger-Modul, das Delay-Modul und das PPD-
Modul. In dem Spalt zwischen Delay- und PPD-Modul ist normalerweise das
PPA-Modul untergebracht, das für einen Versuchsaufbau in Aachen jedoch
nicht notwendig war. Alle für das Lagekontrollsystem relevanten Funktionen
werden nämlich vom PPD-Modul gesteuert. Ganz rechts im Crate befindet
sich das Alarm-Modul.
7.1 Messung der Busgeschwindigkeit
Eine wesentliche Anforderung an das Kontrollsystem war, die theoretisch
maximale SEDAC-Übertragungsrate von 4 kHz für die Datennahme so weit
wie möglich auszunutzen. Um festzustellen, welche Übertragungsrate von
dem Kontrollsystem erreicht wird, wurden mehrere Messungen durchgeführt.
Für die Messung der Übertragungsrate auf einer SEDAC-Leitung wurde das
Testprogramm (test register) entwickelt. In Tabelle 2 sind die Meßergebnisse
für die in dem hier entwickelten Kontrollsystem verwendete SEDAC-
Busklasse CSedacIPIO zusammengefaßt.
Meßort Nur Lesen Nur Schreiben Lesen & Schreiben
Aachen 4395.6 ± 1.6 Hz 4394.0 ± 1.6 Hz 4394.8 ± 1.6 Hz
DESY — — 4381.2 ± 1.6 Hz
Tabelle 2: Maximale SEDAC-Übertragungsraten (1 Busleitung)
Der angegebene Fehler ist durch die Zeitauflösung des MVME-162-12a gegeben.
Ein weiterer, aber nicht berücksichtigter Fehler ist die Ausführungsdauer
für den Programmcode zwischen den Schreib- und Lesebefehlen. Dieser
Fehler ist jedoch vernachlässigbar.
Die Meßergebnisse sind nach Art des Zugriffs (Lesen, Schreiben und gemischter
Zugriff Lesen:Schreiben im Verhältnis 1:1) geordnet. Bei der Interpretation
der Meßergebnisse fällt als erstes auf, daß die in [19, 21] genannte maximale
Datenrate von 4 kHz um fast 10 % überschritten wird. Andererseits
sind die Daten untereinander konsistent, denn die Geschwindigkeit für gleichzeitiges
Lesen und Schreiben liegt genau zwischen denen für nur Lesen und
nur Schreiben.

7.1 Messung der Busgeschwindigkeit 59
Abbildung 19: Das vom DESY zur Verfügung gestellte Testsystem in Aachen

60 7 TESTS
Die Erklärung ist, daß der SEDAC-Standard die Datenübertragung mit der
Frequenz von 4 kHz bei der Verwendung von Standard-50 Ω-Kabeln (RG 213)
über einen Kilometer Entfernung garantiert, in der Testanordnung jedoch nur
ungefähr zwei Meter Übertragungsweg vorlagen.
Um diese zunächst nur hypothetische Annahme zu überprüfen, wurde im
Rahmen dieser Diplomarbeit am DESY ein Test vorgenommen. Leider konnte
kein Kabel von 1 km Länge an das Testsystem angeschlossen werden, so
daß ein anderer Weg begangen werden mußte. Dazu wurde eine vorhandene
SEDAC-Leitung vom Kontrollraum zu den Modulen in der Halle West in
einer Anordnung, wie sie der in Abb. 11 auf der linken Seite entspricht, benutzt.
Die Länge des Übertragungsweges vom Kontrollraum zur Halle ist unbekannt,
ebenso wie die Übertragungsgeschwindigkeit. Einen Teil der Strecke
vom Kontrollraum bis zur Halle West legen die Daten nämlich auch über
Lichtwellenleiter zurück. Die Meßidee liegt nun darin, den Laufzeitunterschied
zwischen dem ersten Crate-Controller (der sich bei 93 m befindet)
bis zu dem letzten Crate-Controller (bei 718 m) zu messen. Bei der Messung
des Laufzeitunterschiedes heben sich die unbekannte Laufzeit bis Halle West
und die unbekannte Totzeit zwischen zwei SEDAC-Übertragungen heraus.
Eine Messung am 29. Januar 1998 der (damals noch nicht so gut optimierten)
Übertragungsfrequenz ergab:
ν718 = 3692 ± 2 Hz und ν93 = 3809 ± 2 Hz (17)
Als Laufzeitunterschied erhält man unter Verwendung des Fehlerfortpflanzungsgesetzes
etwa ∆T = 8.3 ± 0.3 µs. Dieser Laufzeitunterschied entspricht
einem Weg von mindestens ∆L = 625 m. Die gesamte Kabellänge wird zwar
größer sein, da die Kabel nicht den kürzesten Weg nehmen. Unter Verwendung
der minimalen Kabellänge ∆L erhält man jedoch wegen ν = 1/∆T ∼
1/∆L eine Abschätzung der maximalen Übertragungrate ν. Für eine Strecke
von einem Kilometer muß somit mit einer maximalen Verlängerung ∆Tmax
einer jeden Übertragung von
∆Tmax =
1
ν718
− 1
1000
= 13.3 ± 0.5 µs (18)
ν93 625
gerechnet werden. Der in Tabelle 2 für gemischte Zugriffe angegebene Wert
würde sich damit auf 4152 Hz erniedrigen. Dieser Wert weicht nur noch um
knapp 4% von dem erwarteten Maximalwert ab, liegt aber immer noch über
dem erwarteten Maximalwert.
Wie ist dies möglich? Eine Überprüfung der Echtzeituhr der MVME-162-12a
ergab eine Mindestgenauigkeit von mehr als 0.5 Promille. Das kann also nicht
die Ursache für den Fehler sein. Das Testprogramm test register wurde

7.1 Messung der Busgeschwindigkeit 61
von drei verschiedene Personen auf Fehler untersucht, es konnte aber keiner
gefunden werden.
Eine mögliche Erklärung für den verbleibenden Unterschied könnte die Neuentwicklung
von Sendern (IP-Interface) und Empfängern (CC2, CC3, CC4 48 )
sein, die eine geringfügig über das Design von SEDAC 1976 [19] hinausgehende
Übertragungsrate zulassen könnten.
Ein wichtiges Prüfungskriterium, ob die Einführung der Parallelität und die
Aufspaltung des Kontrollsystems in mehrere, unabhängige Threads sinnvoll
war, ist die Messung der maximalen Übertragungsrate über zwei SEDAC-
Leitungen gleichzeitig. Die dazugehörigen Messungen wurden mit dem eigens
dafür entwickelten Programm test parallel durchgeführt. Die Meßergebnisse
befinden sich in Tabelle 3. Auch hier ist der angegebene Fehler durch
Meßort Nur Lesen Nur Schreiben Lesen & Schreiben
Aachen 4064.4 ± 1 Hz 4126.6 ± 1 Hz 4104.0 ± 1 Hz
DESY — — 4027.5 ± 1 Hz
Tabelle 3: Maximale parallele SEDAC-Übertragungsraten (2 Busleitungen)
die Zeitauflösung der Uhr im MVME-162-12a gegeben. Der kleinere Fehler
wurde durch eine längere Meßdauer erreicht. Der Vergleich mit den Daten
für ein Businterface offenbart eine Merkwürdigkeit bei den Meßwerten am
Aachener Teststand: Der Schreibzugriff ist jetzt schneller als der Lesezugriff.
Außerdem entspricht der Mittelwert aus Lese- und Schreibzugriff bei getrennter
Messung nicht mehr genau dem Wert bei abwechselnden Schreiben und
Lesen.
Die Erklärung dafür ist, daß hier keine wirklich “parallele” Auslese stattgefunden
hat. Im Aachener Teststand (Abb. 19) ist nämlich nur ein Crate-
Controller (ein CC4) vorhanden. Dieser besitzt Anschlüsse für zwei SEDAC-
Leitungen, die auch zu dem Test benutzt wurden. Bei dieser Betriebsart
können beide Bus-Interface “gleichzeitig” auf den CC4-internen Speicher zugreifen
[20]. Intern muß der Zugriff vom CC4 jedoch in irgendeiner Art und
Weise synchronisiert werden. Da nun über beide Interface gleichzeitig Lesebzw.
Schreibanforderungen kommen, muß der CC4-Controller über den Zugriff
auf die Daten entscheiden. Dies führt zu dem beobachteten Phänomen.
Die Messung am DESY erfolgte mit zwei voneinander getrennten Crate-
Controllern, so daß dieses Problem hier nicht auftrat. Dieser Meßwert ist
deshalb aussagekräftiger.
48 Crate Controller 2, Crate Controller 3, ...

62 7 TESTS
Die Geschwindigkeit bei parallelem Zugriff ist bei gemischtem Schreib- und
Lesezugriff um 6.6% bei der Messung am Aachener Testaufbau bzw. um 9.2%
bei der Messung am DESY zurückgegangen.
Für den Dauerbetrieb des Kontrollsystems sind jedoch nicht nur die maximalen
Übertragungsraten interessant, sondern vor allem der während des
Betriebs durchschnittlich erreichte Wert. Berechnet man eine Korrektur für
eine mittlere Entfernung der Module von 500 m, so erhält man für die erwartete
Maximalgeschwindigkeit des Kontrollsystems
νmax,parallel = 3932 Hz (19)
Die Übertragungsrate liegt also bei parallelem Zugriff auf zwei Busleitungen
nur gerinfügig unter der SEDAC-Spezifikation von 4 kHz. Der durch das
Umschalten und die Synchronisierung zwischen den verschiedenen Threads
hervorgerufene Aufwand ist demnach recht gering. Dies rechtfertigt die nebenläufige
Auslegung des Kontrollsystems bei gleichzeitig hoher Modularität.
Um Informationen über das Laufzeitverhalten des Kontrollsystems zu gewinnen,
wurden Funktionen eingebaut, die während des Betriebs in periodischen
Abständen zahlreiche Parameter ausgeben, die zur Performance-Analyse verwendet
werden können. Diese Ausgabe kann in der zentralen Steuerdatei
global.hpp durch #define PERFORMANCE eingeschaltet werden.
Während der Testmessungen am DESY konnten so Daten über die durchschnittliche
Geschwindigkeit des Buszugriffs genommen werden. In Abb. 20
ist eine Verteilung dargestellt, die die Ergebnisse von etwas mehr als zwei
Stunden Meßzeit zeigt. Die durchschnittliche Zugriffsfrequenz pro Businterface
liegt demnach bei
νavg = 3777 ± 216 Hz, (20)
das ist ein erstaunlich hoher Wert. Auffällig ist jedoch, daß es einen Häufungspunkt
bei etwa 3825 Hz gibt, ein paar Werte jedoch auch darunter liegen. Die
geringen Werte sind hauptsächlich durch den Start des Kontrollsystems entstanden,
bei dem sehr viele Initialisierungsdateien eingelesen werden müssen,
bevor auf den Bus zugegriffen wird. Der Datendurchsatz ist zu diesem Zeitpunkt
entsprechend gering.
Bemerkenswert ist, daß die eigentliche Programmausführung, in der die gesamte
Logik des Kontrollsystems steckt, so schnell geschieht, daß die Geschwindigkeitsverringerung
gegenüber dem erwarteten mittleren Wert aus
Gleichung (19) nur 4 (vier!) Prozent beträgt. Die Anforderung einer hohen
Auslesegeschwindigkeit wird somit durch das hier entwickelte Kontrollsystem
erfüllt. Da am DESY keine Daten über Messungen der SEDAC-Übertragungsrate
des bisherigen Kontrollsystems vorliegen [9], können leider auch
keine Vergleiche gezogen werden.

7.1 Messung der Busgeschwindigkeit 63
Durchschnittliche SEDAC-Uebertragungsfrequenz
18
16
14
12
10
8
6
4
2
sedac-histo
Nent = 150
Mean = 3777.16
RMS = 215.678
0
2800 3000 3200 3400 3600 3800 4000
Abbildung 20: Durchschnittliche SEDAC-Übertragungsfrequenz. Auf der horizontalen
Achse sind die verschiedenen gemessenen Frequenzen aufgetragen, auf
der vertikalen Achse die Häufigkeit des Auftretens einer bestimmten Frequenz.

64 7 TESTS
7.2 Testaufbau
Leider war es nicht möglich, alle Funktionen des hier entwickelten Kontrollsystems
am laufenden Beschleuniger zu testen. Das lag vor allem an den Anlaufschwierigkeiten
von HERA durch die Installation von zahlreichen neuen
Komponenten im langen Winter-Shutdown 1997-1998, durch den sich der
Zeitplan der HERA-Inbetriebnahme um einen Monat verschob.
Da das Verlustkontrollsystem eine entscheidende Funktion für die Sicherheit
von HERA hat, kontrollierte das am DESY vorhandene Kontrollsystem
während des Tests drei Quadranten, so daß der Einsatz von allen vier für
das neue Kontrollsystem nötigen Servern nicht möglich war. Deshalb ist nur
Server Nummer 3 getestet worden, der in der Halle West wie in Abb. 11
rechts dargestellt installiert wurde. Zweitens war es nicht möglich, von dort
das für die getriggerten Betriebsmodi des Lagekontrollsystems notwendige
PMST-Modul, das sich direkt neben dem Beschleuniger-Kontrollraum im
Elektronikraum I befindet, zu erreichen. Das bisherige Kontrollsystem behielt
den Zugriff auf dieses Modul, ein gleichzeitiger Zugriff ist durch das
Single-Master Prinzip von SEDAC nicht möglich gewesen. Dadurch waren
nur Tests im “Orbit-Modus” des Kontrollsystems möglich. Die dritte und
letzte einschränkende Bedingung war, daß der Betrieb von HERA zu der für
den Test bereitgestellten Zeit nicht mit voller Protonfüllung möglich war.
Dadurch konnten nur sehr wenige Informationen über die Funktionsweise
des Verlustkontrollsystems gewonnen werden, da auch nur ein entsprechend
geringer Protonverlust vorhanden war.
7.2.1 Das Testprogramm
Für den Test wurde im Rahmen dieser Diplomarbeit ein eigenes Testprogramm
entwickelt, das die Rolle des Client spielt. Ein während des Tests
aufgenommenes Bild ist in Abb. 21 dargestellt. Nur die für den Test wichtigsten
Funktionen wurden integriert. Auf Knopfdruck kann im Alarmteil
des Kontrollsystems ein künstlicher Freeze ausgelöst werden. Das wurde benutzt,
um die automatische Archivierung der Daten der Strahlverlustmonitore
auszulösen und die Datennahme anschließend zu stoppen. Ebenso kann
der Freeze-Zustand wieder aufgehoben werden, wodurch die Datennahme von
den Lage- und Verlustmonitoren erneut gestartet wird.
Speziell für diesen Test wurde sowohl im Lage- als auch im Verlustkontrollsystem
eine zusätzliche Funktion integriert, die sogar über diesen Test hinaus
nützlich ist. Diese Funktion erlaubt es, wie in einem Film in regelmäßigen,
über die zentrale Steuerdatei global.hpp einstellbaren Intervallen die aktuellen
Werte der Monitore in eine Datei abzuspeichern. Das erlaubt die Ver-

7.2 Testaufbau 65
Abbildung 21: Die grafische Oberfläche des Testprogramms. Die Skalierung entlang
der vertikalen Achse, die die Abweichung vom Orbit in Millimetern angibt,
ist leider verborgen. Dies ist ein beim Vergrößern des Bildaussschnitts entstandener
Fehler in der aktuellen ACOP-Version. Aus dem Vergrößerungsverhältnis
läßt sich schließen, daß die vertikale Achse von etwa −12 mm bis +12 mm für
die x-Ablage und von etwa −10 mm bis +10 mm für die y-Ablage geht. Die
senkrechten Linien gehen von der Ideallage (x = 0 bzw. y = 0) aus, ihre Länge
ist somit die Ablage vom Orbit. Die horizontale Achse entspricht dem Weg, den
die Protonen nach ihrer Injektion zurücklegen: Vom Oktanten West links, Position
197 m, über die Quadranten Süd, Ost und Nord und den Oktanten West rechts
bis in den Oktanten West links, Position 44 m. Da das Kontrollsystem nur im
Quadranten West installiert war, sind auch nur dort Daten vorhanden.

66 7 TESTS
folgung von zeitlich sich verändernden Strahl-Lagen oder Verlusten über die
knappen Grenzen der Post-Mortem-Analyse hinaus. Prinzipiell lassen sich
“Filme” mit einer Länge erstellen, die nur durch die Speicherkapazität des
Datenträgers, auf dem der Film niedergelegt wird, begrenzt ist.
Das Datenformat dieser Dateien entspricht auch nicht dem DESY-üblichen
Standard für “event-driven archiving”, sondern ist ein unter fast allen Tabellenkalkulationen
verbreites Format, das CSV 49 -Format. Die von dem Kontrollsystem
erzeugten Dateien können damit sofort in eine Tabellenkalkulation
eingelesen und analysiert werden.
Zur Darstellung der mittels Prozedurfernaufrufe vom Lagekontrollsytem abgeholten
aktuellen Lagedaten wurden zwei Grafikfenster in das Testprogramm
eingebunden, die die Abweichung vom Orbit grafisch darstellen.
Das Testprogramm ist in Visual Basic 5.0 geschrieben und verwendet die
ACOP-ActiveX Controls [3] für die Kommunikation mit dem Kontrollsystem.
In Abb. 21 ist ein während des Tests am 10. Juli 1998 aufgenommes
Bild des Testprogramms gezeigt. Links oben erkennt man die besprochenen
Steuerfunktionen für Alarmteil sowie Verlust- und Lagekontrollsystem. Die
zwei waagerechten Grafiken zeigen die momentane Ablage vom Orbit, oben
in der x-Ebene, unten in der y-Ebene. Über die Schaltknöpfe rechts neben
den Grafiken läßt sich die Übertragung der Daten vom Kontrollsystem zum
Testprogramm starten bzw. stoppen.
7.3 Messungen mit dem Lagekontrollsystem
Zur Überprüfung des Lagekontrollsystems wurden drei verschiedene Messungen
vorgenommen: Messung der Abweichung des Protonstrahles vom Orbit,
Untersuchung des zeitlichen Verhaltens der Strahlablage an einigen Monitoren,
und die sowohl zeitliche als auch räumliche Untersuchung einer Beule.
Daneben wurde auch überprüft, ob das Lagekontrollsystem fähig ist, eine
synchrone Messung mit vier Servern zuzulassen. Grundlegend dafür ist, daß
die Server jeden Timeout messen, der von den PPD-Modulen erzeugt wird.
Im Kontrollsystem wurde deshalb eigens dafür eine Funktion eingebaut, die
den Benutzer davon unterrichtet, wie lange auf das “Data-Ready”-Flag des
PPD-Moduls gewartet wurde. Eine Überprüfung der Logdateien des Lagekontrollsystems
ergab, daß stets zwischen 68 ms und maximal 136 ms auf das
Auftreten des Timeout-Flags gewartet wurde. Da zwischen dem zweimaligen
Auftreten des “Data-Ready”-Flags ein Mindestintervall von 173 ms liegen
muß [31] und bei sämtlichen Test des Kontrollsystems ein Wert von 259 ms
eingestellt war, kann ein verpaßtes Timeout-Flag somit ausgeschlossen wer-
49 Comma Separated Value

7.3 Messungen mit dem Lagekontrollsystem 67
den. Damit ist das Kontrollsystem in der Lage, auch bei einem Einsatz von
gleichzeitig vier Servern eine synchrone Messung der Strahllage über den
gesamten HERA-Beschleuniger durchzuführen.
7.3.1 Messung des Orbits
Der Orbit wird von dem Kontrollsystem laufend aus den PPD-Modulen
ausgelesen, wie in Kapitel 6 erklärt und in Abb. 17 dargestellt. Eine vom
Kontrollsystem über #define PERFORMANCE in global.hpp automatisch ausgeführte
Messung ergab, daß neue Werte alle 260 ± 2 ms vorlagen. Als Fehler
wurde die maximale Abweichung angegeben. Das Auslesen eines gemessenen
Orbits vom Kontrollsystem durch das Testprogramm geschah in einem
Abstand von 1000 ms. Ein von dem Testprogramm dargestellter Orbit ist
in Abb. 21 zu sehen. Durch die Fähigkeit, “Filme” der Ablage aufzunehmen,
konnten die Daten jedoch genauer dargestellt werden. Abb. 22 zeigt
einen solchen Orbit. Die große Abweichung von 14 mm bei z = 44 m ist
wahrscheinlich ein Artefakt durch einen defekten oder schlecht kalibrierten
Monitor.
Abweichung vom Orbit in mm
8
6
4
2
0
-2
-4
-6
-8
-10
-12
10.07.98 12:50
-14
-800 -600 -400 -200 0 200
Position in Metern
400 600 800
Abbildung 22: Ein mit dem neuen Kontrollsystem gemessener Orbit. Für den
Quadranten West links wird die Position positiv gezählt, für West rechts negativ.
Bei dieser Auftragung entspricht die Flugrichtung der Protonen der Richtung
aufsteigender Positionsangaben.

68 7 TESTS
7.3.2 Untersuchung des zeitlichen Verhaltens
Für einige ausgewählte Monitore wurde die zeitliche Veränderung der Strahlablage
mit Hilfe der aufgenommenen “Filme” untersucht. In Abb. 23 sind
die Positionen des jeweils zuletzt gemessenen Umlaufs als Funktion der Zeit
dargestellt. Während des dargestellten Zeitraum von 22 Sekunden ist keine
systematische Veränderung des Orbits zu erkennen, lediglich statistische
Schwankungen. Diese sind bei den verschiedenen Monitoren unterschiedlich
groß und seltsamerweise nicht mit der Ortsauflösung der Monitore korreliert,
die mit wachsender Entfernung vom Idealweg sinkt. Das bedeutet, daß die
Schwankung nicht durch ein Rauschen in der Elektronik verursacht wird,
sondern tatsächliche Schwankungen der Strahlablage darstellt.
x-Ablage in mm
4
3
2
1
0
-1
-2
-3
WL 582
WL 347
WL 197
WL 676
WR 673
WR 086
WL 394
-4
0 5 10
Zeit in Sekunden
15 20
Abbildung 23: Zeitliche Entwicklung der zuletzt gemessenen Positionsdaten
Die Schwankungen lassen sich sehr stark reduzieren, wenn statt des letzten
Umlaufs im Beschleuniger ein Mittelwert über die letzten 128 Umläufe dargestellt
wird. Eine solche Messung ist in Abb. 24 dargestellt. Diese eignet sich
somit besser für die Online-Darstellung im Kontrollraum, da sie sich durch
ein stabileres Bild auszeichnet 50 . Beide Abbildungen zeigen Daten derselben
Monitore und Umläufe.
50 Die von dem Testprogramm dargestellten Werte sind solche Mittelwerte

7.3 Messungen mit dem Lagekontrollsystem 69
x-Ablage in mm (Mittelwerte)
4
3
2
1
0
-1
-2
-3
WL 582
WL 347
WL 197
WL 676
WR 673
WR 086
WL 394
-4
0 5 10
Zeit in Sekunden
15 20
Abbildung 24: Zeitliche Entwicklung von gemittelten Positionsdaten
7.3.3 Messungen an einer Beule
Für eine weitere Messung wurden mit Hilfe von Korrekturmagneten Beulen
in der Protonbahn separat in der x- und der y-Ebene erzeugt. Die Erzeugung
und das Verschwinden der Beule wurde zweifach überwacht: Zum einen durch
die Anzeige des Testprogramms, zum anderen durch die “Filme”, die während
des laufenden Betriebs aufgenommen werden.
In der x-Ebene wurde die Beule durch die drei Korrekturmagnete WL252CX,
WL299CX und WL440CX erreicht. Dementsprechend sollten die Lagemonitore,
die sich zwischen 252 Metern und 440 Metern befinden, eine Änderung
der Ablage zeigen. Aus Tabelle 4 liest man ab, daß vier Monitore mit den
Nummern 1–4 eine Abweichung feststellen können.
Monitor-Nr. 0 1 2 3 4 5 6
Position z in m (x-Messung) 197 253 300 347 394 441 488
Position z in m (y-Messung) 164 226 276 323 370 418 465
Tabelle 4: Liste von Monitoren, die zum Ausmessen der Beule geeignet sind.
In Abb. 25 und Abb. 26 wurde die Beule in der x-Ebene jeweils maximal in
entgegengesetzte Richtungen ausgelenkt. Die Unterschiede der beiden Mes-

70 7 TESTS
sungen sind besonders deutlich bei den Monitoren Nr. 2 und 4. Die Monitore
Nr. 1 und Nr. 5 befinden sich zu nahe an den Ablenkmagneten, um eine Abweichung
registrieren zu können. Monitor Nr. 3 befindet sich offensichtlich
genau in der Mitte der Beule und zeigt eine konstante Ablage an.
Abbildung 25: Beule in der x-Ebene, maximal positive Auslenkung
Die Überwachung der Anzeige des Testprogramms ermöglicht jedoch nur
eine qualitative Analyse der Beule zu einem festen Zeitpunkt. Quantitative
Aussagen über das Verhalten der Beule lassen sich jedoch mit Hilfe der
aufgenommenen “Filme” machen. Dabei wurden für alle folgenden Grafiken
“Differenz-Orbits” dargestellt. Damit ist gemeint, daß von allen gemessenen
Ablagen die Strahllage, bei der die Magnete keine Beule erzeugen, abgezogen
wird. Man sieht in den Grafiken deshalb nur die durch die Magnete erzeugte
Beule.
Die Abb. 27 zeigt die zeitliche Entwicklung einer solchen Beule. Aufgetragen
sind die Differenz-Meßwerte von allen Monitoren, die sich zwischen den drei
oben genannten Magneten befinden. Die Position der Monitore ist in Metern
angegeben. Zu Beginn der Messung (t = 0) ist keine Beule vorhanden.
Diese wird während der Messung zunächst maximal in die eine Richtung
ausgelenkt, dann auf Null zurückgefahren und kurz danach maximal in die
andere Richtung ausgelenkt. Die Höhenlinien haben einen Abstand von einem
halben Millimeter. Mit ihrer Hilfe kann die Größe der Auslenkung zu
etwa ∆x = 2.5 mm abgelesen werden.

7.3 Messungen mit dem Lagekontrollsystem 71
Abbildung 26: Beule in der x-Ebene, maximal negative Auslenkung
2
1
x / mm 0
-1
-2
0
2
4
6
8
Zeit in Sekunden
10
Beule in x-Richtung
12
14
16
400
350
250
200
300
Monitorposition in m
Abbildung 27: Dreidimensionale Darstellung einer Beule in der x-Ebene

72 7 TESTS
Ein Schnitt durch diese dreidimensionale Darstellung ist in zwei Ebenen
möglich, einmal für t = const und einmal für z = const, d. h. einen festen
Monitor. Ein Schnitt für t = const ist wegen der zwei Monitore, die eine
Veränderung zeigen, nicht sehr interessant, und zeigt nichts, was man nicht
auch in den Abbildungen 25 und 26 erkennen kann. Als Beispiel für einen
z = const-Schnitt ist in Abb. 28 der zeitliche Verlauf der Orbit-Differenz für
den Monitor WL300X darstellt. Man erkennt, wie sich die Strahllage nach
Differenz in mm
3
2
1
0
-1
-2
Monitor WL 300X
-3
0 2 4 6 8 10 12 14 16 18
Zeit in Sekunden
Abbildung 28: Zeitlicher Verlauf einer Beule in der x-Ebene
und nach durch den Einfluß des Magnetfeldes verändert und der Strahl auf
seine neue Position gezwungen wird.
Für die Erzeugung der Beule in y-Richtung wurden die Korrekturmagnete
WL225CY, WL370CY und WL464CY benutzt. Laut Tabelle 4 sollten demnach
fünf Monitore, nämlich Nr. 1 bis Nr. 5, eine Veränderung zeigen. Die
Abb. 29 zeigt, wie die Beule in drei zeitlich aufeinanderfolgenden Schritten
auf ihren Maximalwert gebracht wird. Den Hauptteil zu der Beule tragen die
Ablenkungen durch die Magnete bei 370 m und 464 m bei. Dazwischen befindet
sich leider nur ein einziger Monitor, so daß die Beule sehr unförmig dargestellt
wird. Das Durchschwingen der Beule in die andere Richtung ist wesentlich
schwächer ausgeprägt. Die Positionen der Monitore sind hier ungünstiger
verteilt, so daß in z-Richtung lineare Interpolation der Meßwerte die Form
der Beule nicht richtig wiedergibt. Der zeitliche Verlauf der Strahlablage für

7.4 Messungen mit dem Verlustkontrollsystem 73
den Monitor WL418Y ist in Abb. 30 dargestellt. Mit einer Orbitdifferenz von
knapp 6 mm ist die Beule dort recht groß.
7.4 Messungen mit dem Verlustkontrollsystem
Durch die geringe Protonfüllung in HERA zum Zeitpunkt dieses Tests und
den damit verbundenen geringen Strahlverlusten liegen nur sehr wenige Messungen
mit dem Verlustkontrollsystem vor. Alle eigens für HERA entwickelten
PIN-Diodenstrahlverlustmonitore haben während der gesamten Meßzeit
nur sehr geringe Verluste gemessen. Sämtliche Mittelwerte über 666 ms enthielten
keinen einzigen Eintrag. Lediglich die in 5.2 ms-Zeitintervallen gezählten
Werte zeigten ab und zu ein oder zwei Ereignisse. Dementsprechend sind
die gemessenen Werte statistisch nicht signifikant. Sie liegen aber immerhin
um einen Faktor 10 über der bei den PIN-Dioden sehr geringen Dunkelzählrate
von 0.01 Hz [29]. Die Messung ergab nämlich, daß von 75 Monitoren nur
vier jeweils ein oder zwei Werte in einem Zeitintervall von 666 ms aufgenommen
haben. Dies entspricht einer Rate von etwa 0.1 Hz. Die Daten zeigen,
daß die Auslese der Monitore und damit das Kontrollsystem funktionierte.
In den Abb. 31 und 32 ist der maximale Strahlverlust im Quadranten West
für zwei verschiedene Uhrzeiten dargestellt. Die Meßwerte wurden über einen
Zeitraum von 666 ms gesammelt.
Bei genauem Hinsehen fällt auf, daß die Verlustmonitore bei z = 126 m und
z = 153 m in beiden Abbildungen dieselbe Zählrate anzeigen. Dies ist bei
den wenigen Werten, die dargestellt sind, zu auffällig, um ein Zufall zu sein.
Beide Monitore zeichnen sich durch eine größere Empfindlichkeit aus, wobei
der Monitor bei z = 126 m eine besondere Überraschung bereithält.
Dieser Monitor ist nämlich keiner der üblichen bei HERA eingesetzten Verlustmonitore,
sondern ein vom CERN entwickelter Typ mit unbekannter Eichung.
Dieser ist für Strahlverluste wesentlich empfindlicher als die anderen
Monitore. Er zeigt nämlich nicht nur ein oder zwei Ereignisse an, sondern
seine Zählraten liegen etwa bei 183 Ereignissen in 5.2 Millisekunden. Die
Abb. 33 zeigt den Strahlverlust, der von diesem Monitor gemessen wurde,
in Abhängigkeit der Zeit. Gezeigt sind gemittelte Verlustdaten, die in eine
Vergangenheit von 86.5 Sekunden vor Beginn der Auslese des Monitors
zurückreichen.
Eine automatisch über #define PERFORMANCE in global.hpp ausgeführte
Messung der Dauer der Datennahmeergab, daß neue Daten von allen Verlustmonitoren
nach ∆t = 1.5 ± 0.3 Sekunden vorliegen.

74 7 TESTS
6
5
4
3
y / mm
2
1
0
16
14
12
10
Zeit in Sekunden
8
6
Beule in y-Richtung
4
2
0
200
250
300
500
450
400
350
Monitorposition in m
Abbildung 29: Dreidimensionale Darstellung einer Beule in der y-Ebene
Differenz in mm
6
5
4
3
2
1
Monitor WL 418Y
0
0 2 4 6 8 10
Zeit in Sekunden
12 14 16 18
Abbildung 30: Zeitlicher Verlauf einer Beule in der y-Ebene

7.4 Messungen mit dem Verlustkontrollsystem 75
Anzahl verlorener Protonen (Maximalwert)
1e+08
1e+07
1e+06
100000
10000
1000
100
10.07.98 13:32
-600 -400 -200 0
Position in Metern
200 400 600
Abbildung 31: Eine Strahlverlustmessung im Quadranten West
Anzahl verlorener Protonen (Maximalwert)
1e+08
1e+07
1e+06
100000
10000
1000
100
10.07.98 14:01
-600 -400 -200 0 200 400 600
Position in Metern
Abbildung 32: Noch eine Strahlverlustmessung im Quadranten West
cd

76 7 TESTS
Anzahl verlorener Protonen (arb. u.)
200
180
160
140
120
10-07-98 13:32
100
-90 -80 -70 -60 -50 -40 -30 -20 -10 0
Zeit in s
Abbildung 33: Strahlverlustmessung mit dem CERN-Verlustmonitor
7.5 Automatische Archivierung bei Freeze
Die Darstellung der Abb. 33 ist nur durch die automatische Archivierung
der Strahlverluste bei einem Freeze möglich gewesen. Normalerweise werden
nämlich von den Clients nur Mittelwerte des Strahlverlustes bzw. Maximalwerte,
wie sie z. B. in den Abb. 31 und 32 gezeigt sind, abgefragt.
Zur genaueren Analyse bei einem Strahldump werden jedoch die kompletten
Speicherinhalte eines BLM-Moduls ausgelesen, so daß Informationen über
einen zeitlichen Verlauf dargestellt werden können. Die Abb. 33 zeigt, daß
eine solche Analyse mit dem hier entwickelten Kontrollsystem möglich ist.
Diese Daten wurden nämlich durch einen künstlich ausgelösten Freeze von
dem Kontrollsystem in einer Datei abgelegt. Der Freeze-Zustand konnte mit
dem in Abschnitt 7.2.1 vorgestellten Testprogramm ausgelöst und wieder
aufgehoben werden.
Dies zeigt aber noch nicht, daß das Kontrollsystem in der Lage ist, einen
tatsächlichen Freeze zu entdecken, sondern nur, daß es in der Lage ist, bei
einem solchen die Daten zu archivieren.
Glücklicherweise konnte aber auch ein echter Freeze mit dem Kontrollsystem
festgestellt werden. Dies geschah in einem Test am 27. Mai 1998, als

7.5 Automatische Archivierung bei Freeze 77
gleichzeitig ein Test des Kontrollsystems mit Arbeiten an der Alarm-Loop
zusammenfiel. Ein Ausschnitt aus der Log-Datei des Kontrollsystems zeigt
die Meldungen, die durch den Freeze ausgelöst worden sind:
ALM: DAQ Task run every 361 milliseconds...
ALM: DAQ Task run every 361 milliseconds...
Got Trigger in try #1168
Time difference is 1683 ms
Time difference is 1716 ms
ALM: FREEZE detected with 14 Alarms
BLM: DAQTask waiting for unfreeze.
BLM: DAQTask waiting for unfreeze.
Reading timeout between 4 and 4 ms.
PPD: Polling PPD is frozen.
Reading timeout between 0 and 1 ms.
PPD: Polling PPD is frozen.
ALM: DAQ Task run every 28 milliseconds...
Reading timeout between 0 and 1 ms.
PPD: Polling PPD is frozen.
ALM: DAQ Task run every 31 milliseconds...
ALM: DAQ Task run every 4 milliseconds...
Reading timeout between 0 and 1 ms.
PPD: Polling PPD is frozen.
Reading timeout between 0 and 1 ms.
PPD: Polling PPD is frozen.
ALM: DAQ Task run every 3 milliseconds...
Reading timeout between 0 and 1 ms.
PPD: Polling PPD is frozen.
Reading timeout between 0 and 1 ms.
PPD: Polling PPD is frozen.
ALM: DAQ Task run every 7 milliseconds...
ALM: DAQ Task run every 4 milliseconds...
Nach der Detektion des Freeze-Zustands wird die Archivierung der beiden
Threads für die Strahlverlustmonitore (BLM) gestartet. wird. Nach erfolgter
Archivierung wird die Datennahme gestoppt und die Strahlverlustmonitore
warten auf ein Aufheben des Freeze-Zustands. (Meldung: “BLM: DAQTask
waiting for unfreeze”). Gleichzeitig wird von dem Lagekontrollsystem
(PPD) festgestellt, daß die Speicherinhalte der PPD-Module eingefroren wurden.
Dadurch werden auch dort keine Daten mehr genommen. Das Anhalten
der Datennahme von Verlustmonitoren und Lagemonitoren führt zu einem
enormen Geschwindigkeitszuwachs der Auslese der Alarm-Module, da der

78 7 TESTS
Bus nur noch für deren Auslese benutzt wird. Das führt zu einer Verringerung
der Aktualisierungszeit von 361 ms auf unter 10 ms!
Da diese Messungen jedoch zu einem Zeitpunkt entstanden sind, als sich
das Kontrollsystem noch im Entwicklungsstadium befand, wurde im Abschlußtest
die Aktualisierungsrate der Alarmdaten neu bestimmt, die durch
eine geänderte Priorisierung geringer wurde. Es ergab sich ein Wert von
∆t = 411 ± 19 ms.
7.6 Zusammenfassung
Das hier entwickelte Kontrollsystem konnte seine Einsatzfähigkeit unter Beweis
stellen. Es ist durch sein Konzept in das HERA-Kontrollsystem integriert.
Zahlreiche Untersuchungen über die Leistungsfähigkeit und Schnelligkeit
des Systems ergaben folgende Werte: Neue Daten über den Gesamtstatus
der Alarmmodule liegen alle
∆tALM = 411 ± 19 ms (21)
vor, neue Daten von den Verlustmonitoren sind nach
∆tBLM = 1500 ± 300 ms (22)
verfügbar, und im Orbit-Modus werden Intensität, mittlere Ablage und Ablage
des zuletzt gemessenen Umlaufs alle
∆tP P D = 260 ± 2 ms (23)
für interessierte Clients zur Verfügung gestellt. Das Kontrollsystem gewährleistet
dabei die eindeutige Zuordung der Daten zu einem speziellen Umlauf
auch bei der Verwendung von vier Servern. Die mittlere Daten-Transferrate
des Kontrollsytems bei parallem Zugriff auf beide Busleitungen beträgt
νavg = 3777 ± 216 Hz (24)
und liegt etwa 4% Prozent unter dem erwarteten Maximalwert, so daß die
Forderung nach einer schnellen Datenauslese erfüllt wird. Im Falle eines
Strahldumps werden die Daten der Verlustmonitore archiviert und stehen für
eine Post-Mortem-Analyse mit DESY-üblichen Mitteln zur Verfügung. Die
Fähigkeit, “Filme” von Strahlverlust und Strahllage aufnehmen zu können,
ermöglicht eine Analyse des Systems auch über die Hardware-Grenzen von
Verlust- und Lagemonitoren hinaus.

A Das Pthread-Interface für VxWorks
In Tabelle 5 ist eine Liste der im Pthread-Standard [14] beschriebenen Funktionen
angegeben, die von dem hier entwickelten Pthread-Interface unterstützt
werden. Dort sind zuerst die Funktionen aufgeführt, die zum Erzeu-
Funktion Bedeutung
pthread create Erzeugt einen neuen Thread
pthread join Wartet auf die Beendigung eines anderen
Threads
pthread cancel Beendet einen anderen Thread
pthread testcancel Überprüft, ob der laufende Thread gestoppt
werden soll
pthread attr init Initialisiert ein Thread-Attribut
pthread attr setinheritsched Neuer Thread erbt die Prioriät des erzeugenden
Threads
pthread attr setschedpolicy Bestimmt die Ausführungsreihenfolge
von Threads mit gleicher Priorität
pthread attr setschedparam Setzt die Priorität eines Threads
pthread mutex init Erzeugt eine Schloßvariable
pthread mutex lock Schließt eine Schloßvariable zu
pthread mutex unlock Schließt eine Schloßvariable auf
pthread mutex trylock Prüft, ob eine Schloßvariable verfügbar
(offen) ist
pthread mutex destroy Löscht eine Schloßvariable
pthread cond init Erzeugt eine Bedingungsvariable
phtread cond wait Wartet auf das Eintreten einer Bedingung
pthread cond signal Signalisiert einem wartenden Thread
das Eintreten einer Bedingung
pthread cond broadcast Signalisiert allen wartenden Threads
das Eintreten einer Bedingung
pthread cond destroy Löscht eine Bedingungsvariable
Tabelle 5: Unterstütze Funktionen des Pthread-Interface
gen und Beenden von Threads verwendet werden. Dann folgen Funktionen,
mit denen die Eigenschaft der Threads bestimmt werden kann. Die letzten
zwei Blöcke von Funktionen regeln das Zusammenwirken von Threads untereinander.
Für das Verhindern eines gleichzeitigen Zugriffs auf Daten werden
Schloßvariablen benutzt, die vor dem Zugriff auf die Variable verschlossen
79

80 LITERATUR
werden und nach Beendigung des Zugriffs wieder geöffnet werden. Die Bedingungsvariablen
werden zur Synchronisation benutzt, indem ein (oder mehrere
Threads) auf das Eintreten einer Bedingung wartet, die von einem anderen
Thread signalisert wird.
Die Funktionen entsprechen in ihrer Spezifierung dem Pthread-Standard. Bei
ihrer Implementation im VxWorks-Betriebssystem sind aber folgende Besonderheiten
zu beachten:
• Das Pthread-Interface benutzt die für Erweiterungen von VxWorks vorgesehene
Variable spare1 im VxWorks Task-Control-Block. Deshalb
dürfen keine anderen laufenden Programme den Wert dieser Variablen
ändern.
• Die Implementierung der Schloß- und Bedingungsvariablen geschieht
durch die von VxWorks bereitgestellten binären Semaphoren. Diese
zeichnen sich durch ihre besonders hohe Ausführungsgeschwindigkeit
aus [27].
• Die Implementierung der Bedingungsvariablen mit binären Semaphoren
führt dazu, daß die Signalisierung einer Bedingung auch wirksam
ist, wenn die auf diese Bedingung wartenden Threads erst nach
der Signalisierung mit dem Warten beginnen. Dies ist im Pthread-
Standard nicht vorgesehen und führt zu “spurious wake ups”. Jede
Anwendung, die den Pthread-Standard benutzt, sollte jedoch “spurious
wake ups” durch das explizite Überprüfen der Bedingung ausschließen
[12]. Dementsprechend sollte dieser Unterschied nicht zu Problemen bei
der Verwendung führen.
• Interne Fehler des Pthread-Interfaces werden mit einer genauen Fehlerangabe
stets auf dem Bildschirm ausgegeben (zusätzlich zu dem Fehlercode,
wie er im Pthread-Standard vorgesehen ist.
Das Pthread-Interface sollte separat compiliert werden und vor dem dynamischen
Linken der Anwendung in das VxWorks-Betriebssystem geladen werden.
Es ist zwar auch möglich, es statisch in die Anwendung zu linken, aber
nicht empfohlen, da es als Erweiterung des Betriebssystem nicht einer speziellen
Anwendung zugeordnet werden sollte.
Literatur
[1] J. Bengtsson. Alarm-Schleife am HERA-Protonen-Speicherring. DESY
internal note (F51 H), 1989.

LITERATUR 81
[2] ISO/IEC DIS 14882 Programming Languages — C++.
[3] I. Deloose, P. Duval, and H. Wu. The use of ACOP tools in writing
control system software. In Proceedings of the International Conference
on Accelerator and Large Experimental Physics Control Systems (ICA-
LEPCS 97), 1997. CERN-PS-97-067.
[4] P. Duval. Notes on the latest release of the PKTR control system software.
DESY internal note (MKI), 1998.
[5] P.D. Duval, K.H. Mess, and H.G. Wu. Software interface to the HERA
proton beam position monitors. Technical report, DESY, 1991. DESY-
HERA-91-16.
[6] Philip Duval. The PKTR control system guide. DESY internal note
(MKI).
[7] Bill O. Gallmeister. POSIX.4. O’Reilly & Associates, Inc., 1995.
[8] Johann Wolfgang Goethe. Meisterwerke der Weltliteratur, volume 3,
Sammelband Faust — Der Tragödie erster Teil. Neuer Kaiser Verlag –
Gesellschaft m. b. H., 1997.
[9] Persönliche Unterredung mit Steve Herb (DESY MKI).
[10] Ralf Guido Herrtwich and Günter Hommel. Nebenläufige Programme.
Springer Verlag, 1994.
[11] A. Jacob, K.H. Mess, V. Nedic, and M. Wendt. The Hera-P BPM
readout system. In Proceedings of the European Particle Accelerator
Conference (EPAC 90), volume 1, pages 16–18, 1990. DESY-HERA-90-
11.
[12] Bradford Nichols, Dick Buttlar, and Jacqueline Proulx Farrell. Pthreads
Programming. O’Reilly & Associates, Inc., 1996.
[13] Peter Prinz and Ulla Kirch-Prinz. Objektorientiert programmieren mit
ANSI-C++. Prentice Hall, 1998.
[14] IEEE Standard for Information Technology Portable Operating System
Interface (POSIX) Part 1: System Application Programming Interface
(API) Amendment 2: Threads Extension [C Language].
[15] S. Schlögl. Einsatz von PIN-Photodioden als Proton-Strahlverlustmonitore
bei HERA. Master’s thesis, II. Institut für Experimentalphysik der
Universität Hamburg, 1992.

82 LITERATUR
[16] S. Schlögl and K. Wittenburg. A beam loss monitor system for HERA. In
International Journal of Modern Physics A, Proc. Suppl. 2A, volume 1,
pages 254–256, 1992. DESY-HERA-92-19.
[17] U. Schneekloth. Recent HERA results and future prospects. Technical
report, DESY, 1998. DESY-98-060.
[18] W. Schütte, M. Wendt, and K.H. Mess. The new directional coupler
pickup for the Hera proton beam position monitoring system. In Proceedings
of the IEEE Particle Accelerator Conference: Accelerator Engineering
And Technology, pages 1725–1727, 1987. DESY-HERA-87-08.
[19] Autor unbekannt. Prozeßdatenerfassung — SEDAC. DESY internal
note (MKI).
[20] Matthias Werner. SEDAC-Crate-Controller CC4. DESY internal note
(MKI, DOK-CC4), 1992.
[21] Matthias Werner. SEDAC — Ein Überblick. DESY internal note (MKI),
1996.
[22] Helmut Wiedemann. Particle Accelerator Physics. Springer Verlag,
1993.
[23] B. H. Wiik. HERA status. In Physics at HERA, volume 1, pages 1–16,
1992.
[24] Klaus Wille. Physik der Teilchenbeschleuniger und Synchrotronstrahlungsquellen.
B. G. Teubner Stuttgart, 1992.
[25] F. Willeke. HERA status and upgrade plans. In Proceedings of the
17TH IEEE Particle Accelerator Conference (PAC 97), 1997. DESY-
M-97-10S.
[26] K. Willner. Dioden Strahlverlust Monitore — Technische Informationen
zur Inbetriebnahme, Test, Programmierung. Technical report, DESY
(F51, PKTR), 1991. PKTR Note No. 71.
[27] WindRiver Systems, Inc. VxWorks 5.3.1 Programmer’s Guide, 1 edition,
1997.
[28] K. Wittenburg. Beam loss monitors for the HERA proton ring. In
Proceedings of the European Particle Accelerator Conference (EPAC 90),
volume 1, pages 789–790, 1990. DESY-HERA-90-11.

LITERATUR 83
[29] K. Wittenburg. Preservation of beam loss induced quenches, beam lifetime
and beam loss measurements with the HERA-p beam loss monitor
system. Nuclear Instruments & Methods in Physics, A(345):226–229,
1994. DESY-94-003.
[30] H. G. Wu. Description for HERA-P BPM front-end equipment function
calls. DESY internal note (MKI, BPMFEC.DOC).
[31] Honggong Wu. HERA proton position monitor digital (PPD) interface
module. DESY internal document for PPD Users (MKI), 1990.
[32] Konzept der Alarm-Loop. Leider nur lokal vom DESY erreichbar.
http://mkiwww.desy.de/export.www/pktr/hera qp/dokument/alnt01.htm.
[33] Informationen über das kommerziell verfügbare Pthread-Interface gibt
es bei der Firma Dot4. Sie ist im Internet unter http://www.dot4.com
erreichbar.
[34] Aktuelle Informationen über das Projekt HERA-Luminosity-Upgrade
gibt es im Internet unter http://www.desy.de/hera/lumiup/lumi.html.