Warum besteht unser Universum hauptsächlich aus Materie und nicht aus Antimaterie? Dieser Frage geht eines von vier Experimenten – das LHCb – im Teilchenbeschleuniger des Kernforschungszentrums CERN bei Genf nach. Das Experiment erforscht die kleinen Unterschiede der Teilchenphysik und  läuft noch mindestens bis ins Jahr 2018. Es nutzt ein 4500 Tonnen schweres Detektorsystem mit circa 1 Million Sensoren, welche die unterschiedlichen Teilchen registrieren, die bei der Kollision von nahezu lichtschnellen Protonen im rund 27 km langen Ringbeschleuniger entstehen. Das Detektorsystem setzt sich aus mehreren Subdetektoren zusammen. Jeder dieser Subdetektoren ist darauf spezialisiert, unterschiedliche Parameter wie Spurverläufe oder Energie-Werte zu messen. Bei 2000 Ereignissen pro Sekunde entsteht stündlich eine beträchtliche Datenmenge von 250 GByte.

Das Detektionssystem

Diese Daten werden von den Sensoren der Detektor-Elektronik über Lichtwellenleiter an modulare Rechnersysteme geleitet, welche die Daten des Experiments vorverarbeiten. Dabei hat jedes System seine eigene Aufgabe und verarbeitet bis zu 38 Gbit/s an Rohdaten. Diese sendet es dann über vier GbE-Links zu einem Datenaufnahmesystem. Die real genutzte totale Bandbreite der Rechnersysteme des Detektionssystems beträgt rund 50 bis 60 GByte/s und bildet die Datengrundlage für die Analyse und Resultate des Experiments. Ausgeführt sind diese Systeme in rund 100 VME- sowie rund 400 ELMB-Systemen (Embedded Local Monitor Board).

Lokale Überwachung durch CAN-Slaves

Ein Condition-Monitoring-System stellt stets die Verfügbarkeit des Detektionssystems sicher, um zu gewährleisten, dass die teuren Experimente auch Er­gebnisse in Form von Daten liefern. Das Kontrollsystem erfüllt zudem Aufgaben wie das Ein- und Ausschalten, das Setzen der Ausgangsspannungen, das Setzen der Grenzwerte für Ausgangsströme und die Änderung der Lüftergeschwindigkeit. Dabei folgt das Monitoring der VME- und ELMB-Systeme einem ein­fachen Prinzip: Solange das System bei der Überwachung der Komponenten ­keine Anomalität feststellt, werden alle nötigen Parametrierungen des Zustands der Elektronik automatisch ausgeführt. Nur wenn eine Anomalität auftritt, muss ein Mitarbeiter eingreifen und den ­Fehler beheben.

In jedem Rechner des Detektionssystems ist ein CAN-Slave integriert, welcher die lokale Überwachungsinstanz des vernetzten Monitoring-Systems ­darstellt. In der Vergangenheit haben Monitoring-Server mit einer direkten Verbindung – über USB – zu einem CAN-Master die Slaves überwacht und gesteuert. „Die Monitoring-Server sollten aufgrund ihres hohen Alters ersetzt werden“, erklärt Projektleiter Beat Jost. „Als Ersatz haben wir uns für eine Virtualisierungslösung entschieden, um die Ressourcenauslastung unserer Server-In­frastruktur zu optimieren und die ­Kapazitäten für das Experiment zu ­steigern.“

Virtualisierung auf zentralem Server

Früher war auf den dezentralen 1HE-Servern eine komplette WinCC-Scada-Software implementiert, auf die vom Leitstand aus zugegriffen wurde. Diese Dezentralisierung ist nun durch die Virtualisierung der Server auf einem zentralen System aufgehoben. Dieses System verwaltet nun alle Monitoring-Funktionen.

Der LHCb-Detektor: besteht aus einem 4500 Tonnen schweren Detektorsystem mit rund 1 Mio. Sensoren.

© CERN

Neben den allgemeinen Vorteilen der Virtualisierung wie Energieeffizienz und erhöhter Verfügbarkeit ist auch die Möglichkeit, die Hardware flexibel auszulegen, ein weiterer Pluspunkt. Außerdem lassen sich die virtuellen Maschinen flexibler auf die entsprechende Anwendung anpassen. Wenn die Forscher also weitere unerwartete Entdeckungen machen, können sie ein noch breiteres Spek-trum an Prozessen untersuchen, indem sie die Serverkapazität durch Virtualisierung einfach ausdehnen. Da auf den oberen Ebenen des Kontrollsystems die gesamte Kommunikation über Ethernet läuft, ist durch die Virtualisierung der entsprechenden Rechner auch der Ersatz eines defekten Rechners ohne direkte Hardware-Intervention möglich.

Die smarten Knotenpunkte

Vier Subsysteme auf COM-Express-Mini-Basis sind in einem 1HE-Rack zusammengefasst. Sie gewährleisten den Transfer der Condition-Monitoring-Daten und den ­zentralen, virtualisierten Condition-Monitoring-Servern.

© CERN

An der Stelle, wo früher die dezentralen Server standen, sind nun smarte Knotenpunkte am Werk, die den Transfer der Condition-Monitoring-Daten zwischen den dezentralen Rechnersystemen des Detektionssystems und den zentralen, virtualisierten Monitoring-Servern sicherstellen.

Hierfür bieten die Knotenpunkte x86er-Intelligenz und hosten einen integrierten ELMB-OPC-Server für je drei über CAN angeschlossene ELMB-Systeme und einen OPC-Server für die VME-Systeme, die ebenfalls über CAN angeschlossen sind. Zudem greift je ein WinCC-OPC-Client auf diese OPC-Server zu, um letztlich die Monitoring-Daten den zentralen virtualisierten Servern zur Verfügung zu stellen. Die Hauptaufgabe der nun eingesetzten neuen smarten Knotenpunkte liegt also darin, die CAN-Master zum Feld hin zu treiben und über Ethernet mit den zentralen virtuellen Servern zu kommunizieren.

Der Systemaufbau

Um nach den Vorgaben des Leiters des Experiments ein hochverfügbares Low-Power-System mit möglichst großer Dichte zu erreichen, wurde eine individuelle Lösung entwickelt, die vier Subsysteme beinhaltet. In einem 19-Zoll-1HE-System befinden sich vier unabhängige Carrierboards mit vier Computer-on-Modulen, sodass ein 4-in-1-System entstanden ist. Die vier Subsysteme verfügen über GPIO (General-purpose input/output), mit denen sie sich gegenseitig resetten können. Dadurch erhöhen sich Verfügbarkeit und Zuverlässigkeit der Systeminstallation. Zudem werden Wartungseinsätze vor Ort reduziert – und dies ist bei den Wegestrecken der dezentralen CERN-Infrastruktur essenziell. Die Auslegung mit vier vollwertigen Rechnersubsystemen in einem einzigen 1HE-Systemchassis ist zudem äußerst platzsparend.

Alle externen Interfaces wie 6 × USB, 1 × GbE und 1 × DVI pro Subsystem sind auf dem Carrierboard inte-griert und damit kabellos ausgeführt. Die im Gesamtsystem eingesetzten Carrierboards wurden spezifisch für diese Kundenanforderung entwickelt. Die Anbindung an die Systeme des Detektionssystems ­erfolgt über externe USB-to-CAN-­Konverter. An ein 4-in-1-System lassen sich über diese Konverter bis zu 32 CAN-Busse anschließen. Über einen CAN-Bus können wiederum bis zu 64 Slave-Module ­angesprochen werden. Damit lassen sich mit jedem 4-in-1-­System bis zu 2048 Slaves verwalten. Derzeit sind pro 4-in-1-System zwischen zehn und 20 CAN-Busse angeschlossen, sodass mit Hinblick auf die lange Laufzeit des Experiments noch hinreichend Kapa­zität zur umfassenden Erweiterung der gesamten Installation im CERN ­gegeben ist.

Autor: Peter Ahne ist Channel Marketing Manager bei Kontron.

Die technische Umsetzung

COM-Express-Mini-Computer-on-Modul

© Brunner Elektronik

Das virtuelle Serversystem ist eine Entwicklung  von Brunner Elektronik und Ineltro, einem Schweizerischen Kontron-Vertriebs­partner. Die Lösung umfasst vier Subsysteme, basierend auf COM-Express-Mini-Computer-on-Modulen, die in einem 1HE-System zusammengefasst sind, um hohe Ausfall­sicherheit, Systemstabilität und Performance zu erreichen.

Unter den verschiedenen am Markt verfüg­baren Modul-Spezifikationen entschied sich das CERN für den COM-Express-Standard, weil er die führende Spezifikation für Computer-on-Module weltweit ist. Zum anderen bietet dieser Standard mit COM Express mini auch einen sehr kleinen, scheckkartengroßen Formfaktor, der sich für das vom CERN geforderte kompakte Systemdesign anbot. Da Module, die den Schnittstellenspezifi­kationen von COM Express entsprechen, problemlos austauschbar sind und Carrierboard-Designs und Entwicklungserfahrung somit immer wieder verwendbar sind, gewährleistet COM Express sowohl eine hohe als auch ressourcen- und damit kosten­schonende Design-Sicherheit.
Zum Einsatz kommen die Boards von

Kontron unter anderem auch, weil der Hersteller mit KEAPI (Kontron Embedded Application Programming Interface) eine plattformübergreifende Middleware anbietet, die Zugriff und Steuerung von Hardware-Ressourcen in Embedded-Appli­kationen vereinfacht. Applikationsentwickler können eine Bibliothek von ausgefeilten ­API-Funktionen nutzen, die Hardware-Informationen aller neuen Embedded-Plattf­ormen von Kontron bereitstellen. So bieten KEAPI bereits vorintegrierte APIs, mit denen man via l²C das gegenseitige Reset der COMs ermöglichen kann. Nutzen Entwickler diese APIs, muss die Applikation beim Wechsel des Moduls nicht aufwendig umprogrammiert werden, um auf die unterschiedlichen APIs der eingesetzten Bauelemente angepasst zu werden. KEAPI beschleunigt damit auch Neudesigns und die Plattformintegration und reduziert den Arbeitsaufwand bei der Validierung und Verifikation. Zusätzlich bietet KEAPI auch Funktionalitäten zur Fernsteuerung und Fernüberwachung, was die Wartung erleichtert und die Total Cost of Ownership reduziert.