In der Datenaufnahme für den 4 
-Detektor finden
sechs verschiedene
Rechnertypen Anwendung. Die
Prozessoren dieser Rechner stammen alle aus der 68000-Familie von Motorola:
Abbildung 2.10:
Das Datenaufnahmesystem TDAS von Phase1: TDASacquire kopiert die Subevents
synchron aus den Subsystemen CAMAC und FASTBUS und füllt den Ringpuffer, der
aus drei Puffern mit je 5.3MB besteht. Außerdem regelt er die Kommunikation
mit den Subsystemen.
TDASarchive liest die Daten aus dem
Ringpuffer und archiviert sie auf einem lokalen Exabyte Laufwerk.
TDASaccessd
organisiert die Kommunikation über TCP/IP mit den Analyse-Workstations.
Werden Daten angefordert, startet er TDASaccessdc Prozesse, die den
eigentlichen Transfer von Ereignissen zu einer Workstation übernehmen. Weil
immer nur eine kleine Untermenge aller Ereignisse so übertragen werden kann,
ist es möglich über Filterkriterien (z.B. Triggertyp) nur die interessanten
Ereignisse auszuwählen. Die Änderungen für die Phase2 Experimente
betreffen größtenteils
TDASacquire, der jetzt die Schnittstelle zwischen dem
GOOSY-VME-System und TDAS darstellt.
TDASstart erzeugt die Infrastruktur, die die anderen Prozesse benötigen.
Dazu gehören u.a. der Ringpuffer
, der
später die Daten aufnehmen soll, die Vorbereitung der Mechanismen, über die
die Prozesse miteinander kommunizieren, und schließlich das Anlegen der
Dateien,
in die Fehler- und Statusmeldungen geschrieben werden. Sind diese
Vorbereitungen fehlerfrei abgeschlossen worden, startet er die drei
anderen TDAS-Prozesse.
TDASacquire kopiert die Daten aus den Subsystemen in den Ringpuffer und
setzt sie zu einem Ereignis zusammen.
Handelt es sich
um einen passiven Controler (z.B. CAMAC-CAV oder -CBV), werden die Daten
über einen direkt angeschlossenen VSB/VSC-Bus ausgelesen.
Verfügt das Subsystem dagegen über
einen eigenen Ausleseprozessor (AEB, CVI, ...) erfolgt das Kopieren der
Daten über ein Dual-Ported-Memory.
Die Daten werden über einen
VSB/VSC-Bus vom Ausleseprozessor in das Dual-Ported-Memory geschrieben
und dann über den VME-Bus von TDASacquire gelesen.
Die notwendige
Kommunikation zwischen TDASacquire und dem jeweiligen Ausleseprozessor erfolgt
über einen vorher festgelegten Adressenbereich im selben
Dual-Ported-Memory.
Der große Vorteil dieser Schnittstelle ist,
daß fremde Auslesesysteme externer Gruppen
sehr leicht über ein Dual-Ported-Memory
in die Datenaufnahme integriert werden können.
TDASarchive archiviert die Daten auf einem lokalen Exabyte Laufwerk. Die maximale Schreibrate beträgt für diese Laufwerke 500kB/sek. Auf einem Band können bis zu 4GB gespeichert werden. Da eine Datei dieser Größe sehr umständlich zu handhaben wäre, werden die Daten in Dateien (Run-Files) mit einer typischen Größe von 150MB gespeichert. Ist diese Größe erreicht, wird die Datei automatisch geschlossen und eine neue geöffnet. TDASacquire wird kurz vor Erreichen der Maximalgröße über ein Signal informiert, damit das später vorgestellte Parameterevent getriggert werden kann.
TDASaccessd koordiniert die Datenübertragung an Workstations, die online Daten analysieren. Sobald auf einer Workstation eine Analyse gestartet und Daten angefordert werden, startet TDASaccessd einen Subprozeß (TDASaccessdc) und gibt eine Portnummer zurück, unter der die Verbindung zwischen dem Analyseprogramm und TDASaccessdc zustande kommt. TDASaccessdc schickt dann Ereignisse über das TCP/IP Protokoll an die jeweilige Workstation. Ein großer Vorteil dieser Art der Übertragung ist die Unabhängigkeit vom Typ der benutzten Workstation. Die einzige Vorraussetzung ist die Unterstützung des TCP/IP-Protokolls. Weil nur immer ein kleiner Teil aller Ereignisse über diesen Mechanismus verschickt werden kann, gibt es die Möglichkeit, durch Filterkriterien nur die für die Analyse interessanten Ereignisse auszuwählen. Genügt ein Ereignis den Filterkriterien, wird es, um den Ringpuffer nicht zu blockieren, in einen separaten Puffer kopiert und erst von dort übertragen. Dieser Prozeß läuft mit sehr niedriger Priorität, um die Datenaufnahme möglichst wenig zu behindern.
Es gibt keinen
prinzipiellen Unterschied zwischen
Online- und Offline-Analyse, deren Struktur in
Kapitel 3.1 beschrieben wird.
Wird die Analyse beendet, terminiert der
dazugehörige TDASaccessdc-Prozeß auf der E6.
Die TDAS-Prozesse arbeiten völlig unabhängig voneinander. Koordiniert
werden sie über einen Verriegelungsmechanismus für die Puffer, die
den Ringpuffer bilden.
Ist ein Puffer von TDASacquire oder TDASarchive abgearbeitet,
allokiert der jeweilige Prozeß zuerst
den nächsten Puffer, bevor er den alten freigibt.
So wird sichergestellt, daß dieser Ringpuffer
sukzessive von TDASacquire gefüllt und dann von TDASarchive archiviert
wird und sich die Prozesse nicht ''überholen'' können. Da ein Lesen der
Daten unkritisch ist, können sich TDASarchive und die diversen
TDASaccessdc-Prozesse
einen Puffer teilen. TDASacquire dagegen
belegt einen Puffer exklusiv.
Ein gültiger Trigger generiert in einem CAMAC-Crate über eine IOL-Box einen Hardware-Interrupt, durch den die Auslese mit TDASacquire gestartet und die Totzeit gesetzt wird. Ist die Auslese aller Subsysteme beendet, wird die Totzeit zurückgesetzt. Dieses Konzept bedingt eine streng synchrone Auslese, d.h. erst wenn das Ereignis vollständig in den Ringpuffer kopiert wurde, wird die Totzeit zurückgenommen und der Detektor ist für den nächsten Trigger bereit.
Neben diesen Hardware-Triggern wurde die Möglichkeit von Software-Triggern
bereitgestellt,
die von TDASacquire ausgelöst werden können. Diese Software-Trigger
werden eingesetzt, um am Beginn und Ende eines Run-Files wichtige
Parameter
als eigenes Ereignis (Parameterevent) abzuspeichern. Damit
diese Parameter, trotz einmaliger Auslese am Anfang jedes neuen Runs,
für die Online-Kontrolle permanent zur Verfügung stehen, wird das aktuelle
Parameterevent in einen separaten Memorybereich kopiert, der nicht
gelöscht wird. Fordert eine Workstation das Parameterevent an, wird eine
aktuelle Kopie aus diesem Memorybereichs übertragen.
Die Steuerung von TDAS wurde in einer Weise implementiert, daß die Kontrolle der Datenaufnahme an keine Masterkonsole gebunden ist. Kommandos können so von jedem Terminal mit einer Verbindung zur TDAS-E6 abgeschickt werden. Dies ist insbesondere zur Statuskontrolle bzw. Ferndiagnose nützlich.
Mit dem Ausbau des 4 -Detektors wurde eine Neukonzeption der
Datenaufnahme notwendig, wobei die Funktionalität des bisherigen
Datenaufnahmesystems beibehalten werden sollte. Das eigentliche Problem
war nicht so sehr das gestiegene Datenvolumen, als
vielmehr die extrem unterschiedlichen
Verarbeitungszeiten der Subevents.
Das alte Datenaufnahmesystem liest die
Subevents synchron aus, d.h. die Subevents werden nacheinander in den
Ringpuffer kopiert und dann erst wird
die Totzeit zurückgesetzt. Eine solche Mimik
hätte wegen der im folgenden beschriebenen Online-Reduktion für die
Driftkammerdaten unakzeptable
Totzeiten zur Folge gehabt. Die Umstellung auf eine asynchrone Auslese
war daher eine unabdingbare Voraussetzung für die Durchführung der Phase2
Experimente. Die Realisierung dieser
asynchronen Auslese wurde im Rahmen dieser Arbeit geleistet.