Historie

Ursprung von MetaDAQ

MetaDAQ wurde 2004 -nach 4 Jahren Berufserfahrung im Bereich der Schwingungsmesstechnik und Softwareentwicklung- als inhabergeführtes Ingenieurbüro gegründet. Seit 2004 wurden eine Vielzahl an Projekten mit Kunden aus den unterschiedlichsten Bereichen durchgeführt.

Alles begann am CERN. 1999/2000 wurde im Rahmen einer Physik-Diplomarbeit an der Johannes Gutenberg Universität Mainz (FB08 Physik) ein Projekt im Kontext des ATLAS-Experiments am Large Hadron Collider (LHC) am C.E.R.N durchgeführt. Hierbei wurden u.a. Erfahrungen mit Großprojekten und fachübergreifender Systemintegration gesammelt (SCADA).

Der ATLAS Detektor ist eines der vier Großexperimente am weltgrößten Speicherring LHC (ein 26.659 Meter langer, unterirdischer Protonen-Beschleunigerring):

LHC Ansicht aus der Luft. (C) CERN

(Visualisierung des LHC Beschleunigers aus der Luft © 2013 CERN)

Hardwareentwicklung: Bei dieser Arbeit ging es unter anderem um die Entwicklung eines strahlentoleranten, hochintegrierten 6 Kanal 40MHz Datenerfassungssystem das die Bestimmung der Verunreinigung von flüssigem Argon in den Kalorimetern des ATLAS Experiments ermöglichen sollte.

Teile der Messelektronik sind einer erhöhten Strahlenbelastung ausgesetzt, die das Verhalten von CMOS-Komponenten -bis hin zum Ausfall- verändern kann.Daher wurde die Auswertelogik und Signalbearbeitung in einen rekonfigurierbaren FPGA verlagert.

Die FPGA-Konfiguration (der „Bitstream“) wurde aber nicht lokal in einem EEPROM abgelegt, sondern via CAN-Bus in den verwendeten Spartan-II-FPGA geladen. Der EEPROM würde durch das Strahlenniveau zu schnell defekte Daten enthalten und ließe sich vor Ort nicht tauschen.

Die Konfiguration und die Kommunikation des Messsystems findet daher über eine CAN-Schnittstelle (SLIO) statt. Softwareseitig wurden für den Daueretrieb und die IBN, Applikationen und Tools in der grafischen Programmiersprache LabVIEW  von National Instruments entwickelt.

Das Großexperiment ATLAS ging 2008 in Betrieb und sucht(e) unter anderem nach dem Higgs-Boson.

Das folgende Bild gibt einen Überblick über den fast 7000 Tonnen schweren Detektor (siehe auch ATLAS facts):

  • ~ 44 Meter Länge
  • ~ 25 Meter Höhe
  • ~ 1 Milliarde Proton-Proton-Wechselwirkungen pro Sekunde
  • ~ 70TerraByte pro Sekunde interne Rohdatenrate (~100.000 CDs/s)
  • Reduktion durch Triggersysteme auf ~20GB/s
  • 3000 Physiker
  • 7000 Forscher
  • Kollaboration von über 200 Universitäten weltweit

The Atlas Detector

(ATLAS Experiment © 2011 CERN. Hinweis: 2 Personen zur Größeneinordnung links im Bild)

UPDATE  4.7.2012 : Das HIGGS-Boson scheint am CERN entdeckt worden zu sein. Beitrag bei SPON. Heise online.

UPDATE 14.3.2013: „Geneva, 14 March 2013. At the Moriond Conference today, the ATLAS and CMS collaborations at CERN1’s Large Hadron Collider (LHC) presented preliminary new results that further elucidate the particle discovered last year.“ (CERN)

UPDATE  8.10.2014 : Peter Peter Higgs und François Englert bekommen den Physik-Nobelpreis für ihre Arbeiten die zur Entdeckung des Higgs-Bosons am ATLAS-Detektors geführt haben.

Neben der Hardwareentwicklung wurde auch eine zugehörige Softwareanbindung der Messsysteme an das Detector Control System DCS  des Atlas-Experiments  entwickelt.

Seit dieser Zeit hat sich unsere Erfahrung im Umgang mit LabVIEW zusammen mit den Möglichkeiten dieser inhärent parallelen Programmiersprache in zahlreichen Projekten weiterentwickelt.

Design und Bau der 40MHz Purity-Frontend-Boards „LAr-P-FEB“ für ATLAS

Kontext: Zur Identifizierung von Elementarteilchen in Hochenergieexperimenten muss u.a. die Energie bestimmt werden die sie bei Wechselwirkung in Detektormedien deponieren. Das Purity-Subsystem an den Endkappenkalorimetern des ATLAS Experiments verwendet hierzu als Detektormedium flüssiges Argon (lAr). Kleinste elektronegative Verunreinigungen im Medium können jedoch die sehr kleinen Ladungssignale verfälschen und damit die Interpretation der Spurdaten erschweren. Daher muss die Reinheit des flüssigen Argons im ppm-Bereich kontinuierlich überwacht werden. Hierzu sind spezielle Messkammern und Datenerfassungssysteme für den ATLAS-Detektor entwickelt worden.

Das hier entwickelte P-FEB ist eine individuelle Datenerfassungshardware, die nur wenige 100ns langen Signalpulse digitalisiert und nach digitalem filtern (shaper)  in einem Cache-RAM histogrammiert. Diese Signale kommen aus speziellen, mit radioaktiven Quellen bestückten, Driftkammern (sog. Basic-Monitore). Die Analyse der Histogramme dieser Kammersignale ermöglicht die Bestimmung von Verunreinigungen in flüssigem Argon im ppm-Bereich und wird als Korrekturgröße für physikalische Berechnungen aus den Detektorsignalen benötigt.

Das P-FEB verstärkt, digitalisiert und filtert (via Shaper) die einlaufenden Kammerpulse mit 10 (12)Bit und 40MHz FADC-Wandlerrate. Dies entspricht der so genannten Beamcrossing-Rate im LHC: Alle 25ns kollidieren Protonenpakete in den beteiligten Experimenten. Die Protonen haben hierbei eine Energie von 7TeV (das entspricht 7.000 Milliarden eVolt)

Die verwendete FPGA-Firmware des verwendeten Xilinx Spartan FPGAs wurde ursprünglich mit den Xilinx Foundation Tools entwickelt und der resultierende Bitstream im Parallel-Expressmode des Spartan durch einen CAN-Controller per Netzwerk „geladen“. Ebenso wurde eine Programmierung per JTAG oder Onboard-Eprom implementiert. Im Betrieb am Experiment wird standardmäßig das Laden (und Rekonfigurieren) per CAN-Netzwerk verwendet, da das Board in einem Detektorbereich eingesetzt werden sollte, in dem die hochenergetische Teilchenstrahlung den Inhalt von EEPROMS schnell löschen würde. Ebenso kann mit angepasster Firmware einer möglichen Drift der CMOS-Komponenten unter Strahlenbelastung entgegen gewirkt werden.

Entwickelt wurden zwei Versionen des Purity FEBs.

Bau des Purity FPGA frontend boards P-FEB-I

FEB_neu

(c) MetaDAQ

Diese Variante hat einen Messkanal mit 40 MHz FADC und 10 Bit Auflösung.

Bau der 6-Kanal-Erweiterung: Purity frontend board Version P-FEB-II

(c) MetaDAQ

Diese Variante hat sechs Messkanäle mit 40 MHz FADC und 12Bit Auflösung.

Features

  • Analog/Digital mixed HF-Design, 4 Layer PCB
  • Signalabtastung : 3x2Känale simultan, 40MHz FADC, 12Bit
  • Echtzeitverarbeitung auf Sampleebene: XILINX (R) , Spartan II FPGA
  • Echtzeit-Histogrammierung in 12ns externem Cache-RAM
  • Busanbindung: CAN, P82C150 SLIO (Serial Linked IO), CAN phy: PCA82C250, optisch isoliert
  • Dynamisches Laden der Firmware (Bitfile) netzwerkgängig via CAN-Bus oder lokalem EEPROM
  • Watchdog und Energiesparmodus durch Taktreduktion
  • JTAG Interface
  • HD-Expansionsstecker

Der Strahlentest am Mainzer TRIGA-Reaktor (RAD-HARD-Test)

Zum Nachweis der Strahlenhärte sollte im Versuch die Strahlenbelastung (Neutronen und Gamma) von ~15 Jahren ATLAS-Betriebszeit im Zeitraffer auf die Elektronik einwirken.

Hierzu wurde die Elektronik wasserfest in einem PE-Gefäß verbaut und von der oberen Plattform betriebsbereit auf den TRIGA-Reaktorkern abgesenkt.

Mainzer TRIGA Reaktor

Schematischer Aufbau Strahlentest am TRIGA

Blick auf die Brennstäbe im TRIGA

Schematischer Überblick der entwickelten DAQ-Hardware

CACHE-RAM Ansteuerung

Histogramme im RAM

Entwicklung der FPGA-SLIO Kommunikation

CAN-SLIO Kommunikation

Softwareanbindung

Die Anbindung zu den im Detektorsystem verteilten P-FEBs an das Detektorkontrollsystem DCS geschieht über einen CAN-Bus.

Auf einem Purity-Steuerrechner mit einer CAN-I/O-Karte laufen die Signale und Histogramme der P-FEBs ein und werden von nachfolgender Software verarbeitet.

Die Kommunikation mit den FEBs am CAN-Bus geschieht durch eine in LabVIEW implementierte so genannte „CAN-Shell“.

CAN-Shell mit Busanbindung zum P-FEB

Sie stellt einen TCP-Port bereit, über den Befehle und Daten im ASCII-Format mit den FEBs ausgetauscht werden können. Dies kann z.B. per Telnet oder spezieller Clientsoftware geschehen. Ein in LabVIEW implementierter Parser analysiert und übersetzt die Klartextbefehle in Steuerkommandos auf dem lokalen CAN-Feldbus des FEB-Netzwerks.

DCS-Anbindung

LabVIEW – obwohl 1999 noch in den Kinderschuehen- war eine geeignete Wahl für die Umsetzung einer verteilten, parallelen Softwarearchitektur.

Der Neudorf-Canary ist präsent.