Das Datenaufnahmesystem von Phase2 des 4 -Detektors

Die im CDC-VME-System realisierte parallele asynchrone Verarbeitung vieler Subevents gleichzeitig, macht es notwendig die Subevents der anderen Subsysteme CAMAC und FASTBUS zwischenzuspeichern und dann die kompletten Ereignisse synchron zusammenzusetzen. Gerade dieses ``Pipelining'' ist im TDAS von Phase1 mit seiner streng synchronen Auslese nicht implementiert.

Dieses Pipelining wurde für die VME-Komponente des bei der GSI entwickelten Datenaufnahmesystems GOOSY [Ess91a] verwirklicht. Hier wird für jedes Subsystem ein eigener Frontendprozessor (FEP) vom Typ FIC8230 verwendet, der die Subevents nacheinander in einer internen Queue speichert. Der ebenfalls auf einem FIC8230 arbeitende Eventbuilder setzt dann anhand der Subeventnummern synchron die vollständigen Ereignisse zusammen und transferiert sie in Form von GOOSY-Puffern über ein HVR-Interface zu einer DEC-Microvax, wo sie auf einem Exabyte Laufwerk archiviert werden. Gesteuert wird dieses System vom Transportmanager, einem auf einer VAX residierenden Prozeß. Die Kommunikation zwischen dem Transportmanager und dem VME-System erfolgt durch eine E5, über die auch die Programme in die FIC8230 geladen werden.

Problematisch beim Pipelining ist, daß alle Subsysteme weitgehend unabhängig voneinander arbeiten und die Zugehörigkeit der Subevents zum selben Ereignis vom Eventbuilder nur anhand einer Subeventnummer entschieden werden kann. Geht ein Trigger für ein Subsystem verloren, werden die Subevents später falsch kombiniert. Ein solcher Fehler kann vom Eventbuilder prinzipiell erst diagnostiziert werden, wenn die Pipeline geleert wird und dann Subevents fehlen. Dies ist insofern problematisch, da im Experiment angestrebt wird, immer Ereignisse in der Pipeline zu haben und ein aufgetretener Fehler dadurch erst sehr spät bemerkt wird.

 
Abbildung:   Schematisches Bild des Datenaufnahmesystems für den 4 -Detektor: Die Daten der einzelnen Subsysteme CAMAC, FASTBUS und des VME-Systems für die CDC werden von den Frontendprozessoren (FEPs) des GOOSY-Systems gesammelt. Sobald alle Subevents eines Ereignisses in den FEPs vorhanden sind, wird das Ereignis vom GOOSY-Eventbuilder zusammengesetzt und dann vom TDAS-System, das in Abbildung 2.10 skizziert ist, auf einem lokalen Exabyte-Laufwerk archiviert. Die angestrebte Datenrate von 1MB/sek machte die parallele Archivierung mit zwei TDAS-Systemen notwendig.

Der Triggersynchronisation kommt daher eine besondere Bedeutung zu. Zu diesem Zweck wurde bei der GSI der Triggerbus entwickelt [Ess91b]. Es handelt sich um FASTBUS bzw. CAMAC Module, die untereinander über einen schnellen 16Bit-Bus verbunden sind. Der Trigger wird von einem vorher mit Software konfigurierten Master-Modul an die anderen Triggerbus-Module weitergegeben, die ihrerseits einen Interrupt im jeweiligen Ausleseprozessor auslösen. Zusätzlich ermöglicht dieser Triggerbus die Definition von 15 verschiedenen Readout-Typen, die an den Ausleseprozessor übermittelt werden. Ist die individuelle Auslese beendet, setzt der Prozessor die Totzeit in ''seinem'' Triggerbus-Modul zurück. Erst wenn in allen Triggerbus-Modulen die Totzeit zurückgenommen wurde, wird der Trigger vom Master-Modul wieder freigegeben.

Das schließlich realisierte Datenaufnahmesystem für den 4 -Detektor ist in Abbildung 2.12 skizziert. Insgesamt mußten zwei CAMAC-Crates (Parabola, Scaler), drei FASTBUS-Crates (PLAWA, Zero Degree, Barrel) und das VME-System der CDC in den Datenstrom integriert werden. Von diesen befanden sich, wie durch die Umrahmung angedeutet, das FASTBUS-Crate des Barrels und das VME-System der CDC direkt am Detektor im Cave. Das zum Datentransfer nötige 50M lange VSB-Kabel reduzierte die maximal mögliche Übertragungsrate auf ca. 1MB/sek.

Die Auslese der CAMAC-Crates wird durch Rechner vom Typ CVI bewerkstelligt. Das Betriebssystem der CVIs ist pSOS, weshalb die Ausleseprogramme wie die GOOSY-Software für die FIC8230 unter VMS entwickelt und kompiliert werden müssen. Die Programme werden wie durch die punktierten Pfeile angedeutet von einer VAX über eine Terminalleitung in den CVI geladen.

Die FASTBUS-Crates werden durch Aleph-Eventbuilder (AEB) ausgelesen. Sie führen nach der Auslese eine erste Reduktion der Daten durch Subtraktion einer Schwelle (Pedestal) durch. Da sie unter dem Betriebssystem OS9 arbeiten, konnte eine Auslesesoftware implementiert werden, die auch als eigenständiges Datenaufnahmesystem fungieren kann. Durch die Implementierung von TCP/IP ist mit diesen Rechnern ein Transfer von Subevents an Analyse-Workstations möglich. Auch das im vorigen Kapitel beschriebene VME-System der CDC läßt eine solche Datenübertragung zu.

Der Trigger wird durch Triggerbus-Module an die CAMAC und FASTBUS Systeme distributiert. Da die VME-Version zum Zeitpunkt dieses Experiments noch nicht verfügbar war, wurde der Trigger direkt an das Flash-ADC-System der CDC weitergegeben.

Die zentrale Datenaufnahme befindet sich in einem VME-Crate, das durch den Rahmen in Abbildung 2.12 angedeutet ist. Das Kopieren der Daten aus den Subsystemen und das Zusammensetzen der Ereignisse wird von der schon beschriebenen GOOSY-Komponente übernommen. Durch eine Modifikation der Software war es möglich, mehr als einen Ausleseprozessor mit einem Frontendprozessor (FEP) zu verbinden. Aufgrund des Betriebssystems pSOS müssen die Programme der FEPs und des GOOSY-Eventbuilders von einer VAX geladen werden. Dies geschieht, wie die punktierten Pfeile andeuten über eine E5 mit Ethernet Adapter.

Nachdem der GOOSY-Eventbuilder aus den Subevents in den Frontendprozessoren ein komplettes Ereignis erzeugt hat, wird dieses in der vorher beschriebenen Weise von TDAS weiterverarbeitet. So konnte die Funktionalität von TDAS beibehalten und die gesamte Online-Datenanalyse unverändert übernommen werden. TDASacquire hat im neuen System nicht mehr die Funktion eines Eventbuilders sondern ist nunmehr die Schnittstelle zwischen GOOSY und TDAS.

Diese prinzipiell andere Funktion von TDASacquire machte eine Änderung für die Erzeugung des Parameterevents notwendig. Da TDASacquire keinen direkten Zugriff mehr auf die Ausleseprozessoren über ein Dual-Ported-Memory hat, können die benötigten Parameter nicht mehr direkt angefordert werden. Dieses Problem wurde im Rahmen eines Server-Client Konzepts gelöst.

Auf den Rechnern, die Daten für das Parameterevent liefern, arbeitet ein Server-Prozeß. Am Beginn und Ende eines Runs wird von TDASacquire nacheinander eine TCP/IP-Verbindung zu den jeweiligen Rechnern aufgebaut und die erforderlichen Daten werden transferiert. Hierfür wurde ein Softwarepaket entwickelt, daß das Programmieren eines solchen Serverprozesses erlaubt, ohne eine genaue Kenntnis der zugrunde liegenden TCP/IP-Programmierung zu besitzen. Mit diesem Konzept können jetzt alle Rechner, die über eine TCP/IP-Implementierung verfügen, Daten für das Parameterevent bereitstellen.

Die angestrebte Datenrate von 1MB/sek machte die Archivierung auf zwei Exabyte-Laufwerken mit je 500kB/sek notwendig. Es müssen daher zwei CPUs zur Archivierung eingesetzt werden. Dies bedeutet aber auch zwei unabhängig voneinander arbeitende TDAS-Systeme, die koordiniert werden müssen. Die Koordination erfolgt über eine Liste im GOOSY-Eventbuilder, in die sich jedes aktive TDAS einträgt. Der GOOSY-Eventbuilder verteilt die Daten spillweise an die jeweils aktiven TDAS-CPUs. Über diese Liste werden auch die TDASacquire-Prozesse über die Anzahl der aktiven TDAS-Systeme informiert, da die erforderlichen Aktionen für einige Kommandos je nach Anzahl der aktiven TDAS-Systeme durchaus verschieden sind.

Das gesamte Datenaufnahmesystem wird im laufenden Betrieb von nur zwei Konsolen, für jedes aktive TDAS-System eine, gesteuert. Die eben geschilderte selbstständige Konfiguration auf die Anzahl der aktiven TDAS-Systeme macht beide Konsolen gleichberechtigt und eine bestimmte Reihenfolge bei der Benutzung unnötig. Die Steuerung der GOOSY-Komponente, die im GOOSY vom Transportmanager übernommen wird, wurde im TDASacquire-Prozeß implementiert. Nur auf diese Weise können die von TDASarchive getriggerten automatischen Runwechsel ausgeführt werden.

Um das oben geschilderte noch einmal kurz zusammenzufassen: Zur Durchführung der Experimente mit Phase2 des 4 -Detektors war es notwendig, ein spezielles Datenaufnahmesystem zu entwickeln, mit dem eine Rate von 1MB/sek archiviert werden kann. Dies wird durch massive Pufferung der Daten erreicht, die während des Spills mit einer Rate von 2MB/sek anfallen. Die extrem unterschiedliche Verarbeitungszeit der Daten der einzelnen Subdetektoren wurde durch ''Pipelining'' aufgefangen. Das System läßt sich leicht konfigurieren und die Subsysteme können zu Testzwecken als eigenständige Datenaufnahmesysteme fungieren. Es können auf allen Ebenen Daten über eine TCP/IP-Verbindung an Analyse-Workstations transferiert werden. Aus allen Rechnern, die über eine TCP/IP-Implementierung verfügen, können Daten in den Datenstrom einfließen. Unter Experiment-Bedingungen konnten bisher Datenraten von 600kB-700kB und Ereignisraten bis 40Ereignisse pro Sekunde erreicht werden.