Workshop UNILAC Controls Roadmap 2024-26

Datum: 19. und 20.07.2023

Teilnehmer: R. Bär, J. Fitzek, P. Gerhard, T. Habermann, K. Höppner, H. Hüther, S. Jülicher, M. Kreider, S. Krepp, H. Liebermann, R. Müller, D. Ondreka, J. Pforr, A. Schaller, M. Skorsky

Protokoll: P. Gerhard, H. Hüther

Status: Angenommen

Prüfungszeitraum: 02.08. bis 25.08.2023

1 Motivation und Agenda

Auszug aus der Beschreibung der Indico-Veranstaltung:

Dieser Workshop soll dazu dienen, unsere aktuellen Planungen der beteiligten Teams für die Softwarekomponenten des neuen UNILAC Kontroll-/Timingsystems abzugleichen und zu synchronisieren. Ziel soll es sein, die ersten Schritte in Richtung einer integrierten Gesamtplanung für die Meilensteine "Strahlzeit 2025" (Emergency System) und "Strahlzeit 2026" (erste Strahlzeit mit dem neuen Kontrollsystem) zu gehen. Details zur kürzlich beschlossenen Strategie, auf der wir aufbauen wollen, findet ihr im Wiki: https://www-acc.gsi.de/wiki/ProjectMgmt/StrategieUndPlanungsworkshopUnilac.

Die Teilnehmer sollen jeweils themen-/systembezogen ihre aktuellen Annahmen bezüglich der Planung ihrer jeweiligen Systeme/Services/Anwendungen vorstellen:

• Data Master (Mathias, Martin)
• LSA Framework (Raphael, Andreas)
• BSS (Stefan)
• MASP (Tobias)
• Applikationen (Jutta)
• LSA Modell (Peter, Susi)
• Quellen (Peter)

Diese Präsentationen sollen möglichst kurz sein (ca. 10 Minuten, grob 2-3 Folien) um Raum für Nachfragen zu lassen.

Mit den gewonnenen Erkenntnissen würden wir gerne mit euch gemeinsam überlegen, wie eine abgestimmte Planung unter Berücksichtigung der oben genannten Meilensteine aussehen könnte.

2 Beiträge

Die Präsentationen der jeweiligen Teilnehmer sind in der detaillierten Agenda der Indico-Veranstaltung abgelegt und oben verlinkt. Zusätzlich haben Peter und Hanno Präsentationen erstellt zu den Themen:

• Einführung
• Brainstorming: Fehlende Konzepte

3 Ergebnisse und Entscheidungen

3.1 Integrierte Gesamtplanung

Nach dem ersten Workshoptag haben Peter und Hanno die nach ihrem Verständnis wesentlichen Meilensteine aus den von den Teilnehmern vorgestellten Einzelplanungen und der Diskussion extrahiert und auf einem Miro-Board zusammengeführt. Untenstehend ist der PDF-Export der nach dem Workshop überarbeiteten Version dieses Boards zu sehen, zum Zugriff auf das Original wird ein Miro-Account benötigt.

Die drei Zeilen des Boards ("Engineering Run 2023", "Beamtime 2025" und "Beamtime 2026") repräsentieren grundlegende Meilensteine des Injector Controls Upgrade-Projekts, die sich nach den jeweils 2023, 2025 und 2026 stattfindenden Strahlzeiten richten. Dabei ist zu beachten, dass sich der Entwicklungszeitraum zwar nach der folgenden Strahlzeit richtet, die Entwicklung aber mit entsprechendem Vorlauf für interne Tests, Integrationstests und Dry Runs abgeschlossen sein muss. Dies soll beispielsweise für den Meilenstein "Beamtime 2025" durch den Hinweis "Development Milestone: Integration Test 2024" verdeutlicht werden. Die konkreten Zeitpunkte der Integrationstests sowie der Dry Runs nach der Strahlzeit 2024 sind noch festzulegen (siehe dazu auch den Punkt "Projektplanung" im Abschnitt "nächste Schritte").

Die Anforderungen bzw. Entwicklungsziele, die von den in den Spalten genannten Teams bis (spätestens) zum jeweiligen Meilenstein erreicht werden sollen, sind durch "virtuelle Post-Its" dargestellt. Die Strahlzeiten 2025 und 2026 stellen jeweils spezifische Anforderungen an das neue Kontrollsystem, die sich aus dem Einsatzszenario ergeben (2025 als "Emergency System", 2026 als produktiver Ersatz für das aktuelle System). Für das Jahr 2023 ergeben sich die Anforderungen aus selbstgesteckten Zielen für Tests im Rahmen des Engineering Run. Für 2024 sind noch keine Meilensteine geplant, diese ergeben sich voraussichtlich aus den bevorstehenden Detailplanungen in den jeweiligen Teams.

Dabei ist zu beachten, dass die Anforderungen/Entwicklungsziele dem Meilenstein zugeordnet wurden, zu dem sie (spätestens) gebraucht werden. Bei der konkreten Planung bleibt es aber natürlich dem jeweiligen Team überlassen, die konkreten Fertigstellungszeitpunkte, die auch wesentlich früher liegen könnten, festzulegen. In vielen Fällen wäre es unrealistisch, alle genannten Anforderungen bzw. resultierenden Features ausschließlich im zum Meilenstein gehörigen Entwicklungszeitraum zu realisieren (z.B. das Jahr 2025 für die Strahlzeit 2026), sodass insbesondere bei Abhängigkeiten zwischen Teams eine feinere Abstimmung der Detailplanung notwendig sein wird. Diese Abhängigkeiten werden durch Pfeile dargestellt, die verdeutlichen sollen, an welchen Stellen Teams jeweils auf Arbeitsergebnisse anderer Teams angewiesen sind.

Am zweiten Workshoptag haben die Teilnehmer die erste Version des Boards gemeinsam durchgesprochen, korrigiert und ergänzt. Der aktuelle Stand soll als Rahmen für die Detailplanung innerhalb der Teams dienen.

3.2 Termine

• Umzug FCC 10-2025 bis 02-2026, Inbetriebnahme FCC Anfang 2026

3.3 Timing Groups

• Mathias schätzt (basierend auf bisherigen Messungen), dass die Eventrate / CPU-Last bei 1:1-Mapping von Particle Transfer zu Timing Groups nicht zu hoch werden wird
• Sollten Limits bei Eventrate / CPU-Last doch überschritten werden, gibt es Ideen zur Lösung (z.B. Versand von Events in mehrere Timing Groups)
• Sollten diese Ideen nicht greifen, wäre ein alternatives Mapping weiterhin umsetzbar
• Ein 1:1-Mapping lässt sich jetzt kurzfristig umsetzen, der Aufwand für die spätere Umsetzung eines anderen Mappings wäre nach aktueller Einschätzung nicht wesentlich höher als bei einer sofortigen Umsetzung
• Arbeitshypothese: 1:1-Mapping jetzt umsetzen, Ergebnisse prüfen, ggf. nachsteuern

3.4 Data Master

• bis 32 Threads ohne größeren Aufwand möglich
• Benötigte ca. 10 SCU-WR-MIL-Bridges möglich (3 zusätzliche für Quellenteststände)
• Data Master für UNILAC (Annahme: 1x Produktion, 1x Integration, evtl. 1x Teststände, zu klären) können bereitgestellt werden (ggf. auf Basis SuperMicro)

3.5 DeviceAccess

• UNILAC DevAcc-Geräte müssen zwecks Kompatibilität mit JAPC (für LSA & Java-Anwendungen) auf einfache Properties umgestellt werden
  • Betrifft komplexe Parameter ("complex types") in den Properties
  • Arbeiten zur Anpassung der DevAcc-Modelle werden voraussichtlich durch Peters Abwesenheit wesentlich aufwendiger
  • Laut Jutta gab es bei den Quellengeräten relativ viel Anpassungsbedarf
• Gasstripper kann für Notfallsystem 2025 manuell lokal bedient werden; ab 2026 gepulster Gasstripper

3.6 LSA Framework

• Konzept für 2025: Pattern Groups für UNILAC
  • nur ein Pattern/Chain pro Zyklus, keine parallelen Stabilisierer
  • kein paralleler Betrieb aus HLI und HSI, weil HLI strikten 50Hz-Takt erfordert
  • keine (parallelen, unabhängigen) Stabilisierer für Quellen
  • Kommentar David: "Default-Pattern" für Warmhaltepulse nutzen, wenn "sonst nichts läuft"?
• Möglichkeit zur "Aufweichung" der Einschränkung, dass keine parallelen Chains geplant werden können (aber mit zusätzlichem Aufwand verbunden):
  • Man könnte evtl. auch mehrere Chains in ein Pattern planen (nur für UNILAC; für Stabilisierer Quellen/HF), Sinnhaftigkeit/Machbarkeit zu klären (siehe "Nächste Schritte")

3.7 BSS

• Hoher Aufwand geschätzt für Verlagerung von Funktionalität/Features von LSA nach BSS
• Enge Zusammenarbeit zwischen BSS und LSA-Teams (voraussichtlich auch Mitarbeit von Raphael und Andreas an BSS)
• Alleinige Verantwortlichkeit von Stefan für BSS stellt durch gestiegene Relevanz für Betrieb ein Risiko dar (betrifft auch Rufbereitschaft)

4 Fehlende Konzepte

In diesem Abschnitt finden sich die Ergebnisse des Brainstormings zum Thema "Fehlende Konzepte", das Hanno am zweiten Workshoptag angesetzt hatte, um potentiell noch nicht bekannte Defizite in dieser Hinsicht zu beleuchten.

Zu beachten: Susi ist nicht mehr verfügbar nach Ende 2024 (falls von ihr noch Mitarbeit/Informationen benötigt werden)!

4.1 Beam / Accelerator Modes "anlagenweit"

• Insbesondere für MASP relevant
• Offene Frage: Wo / von wem werden die Modes verwaltet? Wenn nicht LSA, wie können Modes dann in Trims berücksichtigt werden (z.B. NO_BEAM -> Anforderung ohne Strahl). Oder ist das vielleicht doch nicht (unbedingt) notwendig?
• Frage bzgl. LSA Modell/Framework: Ist der Beam Mode Chain-spezifisch oder "Chain-Slot-spezifisch" (d.h. z.B. potentiell unterschiedlich für denselben UNILAC-Strahl zu unterschiedlichen Zielen)?

4.2 Nicht-gemultiplexte Geräte

• Im Allgemeinen (vor allem Magnete)
• MAZ-Magnete im Besonderen: das (globale) MAZ-Setting wird in jeder Chain zur Berechnung weiterer Settings benötigt (nochmal spezielle Anforderungen?)
• Nach Ansicht von David und Raphael besonders kritische Punkte

4.3 Quellen

• Teststände
  • Mathias: Teststände-Events sollten nicht mit ins produktive Timing-Netz (Weiteres separates Netz? Was würde das außerdem bedeuten? Zu klären)
  • Es gibt 3 Teststände. Zu klären: Wie hoch ist die Eventrate der Teststände?
  • Annahme: Weitere 3 WR-to-MIL-Gateways benötigt
  • Eigene, vom UNILAC-Kontrollsystem unabhängige Lösung vielleicht besser, weil sonst noch ein Datamaster von LSA zu versorgen und von BSS zu steuern ist, noch mehr Events im Timing-Netz unterwegs sind?
  • Jutta/Hanno: Möglichst konsistent mit den "normalen" Quellen handhaben
  • Stichwort: Ersatz "Software-Pulstzentralen"
• Warmhaltepulse

4.4 "Handling Corrections"

• Traditionell wird am UNILAC öfter an nicht-top level-Parametern gedreht (kann/soll das in Zukunft anders gehandhabt werden?)
• David: Bessere Bezeichnung wär gut (Gab es einen Vorschlag?)
• Besprechen im Rahmen des FAIRDV-Meetings?

4.5 Sonstiges

Evtl. mit niedrigerer Priorität?

• Kopieren von Settings
  • Stichworte: "Puls Copy" und "IBHS"
  • Besprechen im Rahmen des FAIRDV-Meetings?
• Stromsparen

5 Offene Punkte

Hier finden sich Punkte, für die noch zu Klären ist, wie das konkrete weitere Vorgehen aussehen soll.

Themen(bereiche), für die dies bereits ausreichend klar zu sein scheint, sind im folgenden Abschnitt ("Nächste Schritte") aufgeführt.

5.1 UNILAC DevAcc-Gerätemodelle

• Anpassungen von FEC am "Chopper-System" notwendig?

5.2 Timing

• Prüfen, ob Events (wie am SIS) zwischen White Rabbit und MIL "gedoppelt" werden sollen/müssen oder nicht
• Anforderungen aus Interlock und PG-Schutz (Beam, Short-Beam, No-Beam)
• Intention für Graph-Template klären
• Zielplattform/-architektur für Peter-Gerhard-Algorithmus festlegen
  • Referenzimplementierung in Java "übersetzen"?
  • Umsetzung als Bibliothek/Modul/Service?
  • Wo/wie integrieren? BSS?
• Timing für Quellen klären
• Timing für Quellenteststände klären
  • Eigener DM? Eigenes Netz?
  • Erzeugung des Graphen, Bedienung? Integriert in UNILAC oder eigenständig, anders?

5.3 "Emergency System": Einschränkungen 2025

• Keine "echte" Parallelität in LSA für 2025 vorgesehen
• Dafür aber bis zu ca. 15 Patterns "round robin" im Wechsel (Achtung: zu klären, ob "Dummy Patterns" für Warmhaltepulse o.ä. genutzt werden können/müssen)
• Annahme: Damit wäre kein Mischbetrieb HLI und HSI möglich
• 2025: Möglichkeit prüfen, mehrere Chains in ein Pattern zu packen (Stabilisierer für HF und Quellen parallel zu einer beam chain)
• Konsequenzen für Notbetrieb klären
  • Wie lang/komplex kann eine Patterngroup sein? Wie komplex kann der Ablauf werden bzw. welche Untersetzungen und Muster lassen sich realisieren?
  • Nur eine chain pro Zyklus?
  • HF-Stabilisierer
  • Quellen-Stabilisierer
  • TK-Anforderung
  • Betrieb aus mehr als einer Quelle
  • Betrieb aus HSI und HLI parallel
• Mit Strahlzeitplanung/Betrieb klären, ob das akzeptabel ist
• Betriebskonzept erstellen: Lebenszyklus eines Strahls
  
  • Extra Patterngroups für Einstellphase (PG-Schutz?) und danach für Betriebsphase notwendig?
  • Erzeugung der Patterns/Patterngroup

5.4 MASP

• Anforderungen für 2025 (Notfall-System) definieren
  • Schnittstellen zu Interlocksystem und/oder Choppersteuerung benötigt?
  • Soll der MASP weitere Schaltfunktionen steuern oder nicht (z.B. Profilgitterschutz)?
• Anforderungen für 2026 (Produktionssystem) definieren
  • Schnittstelle vom MASP direkt zum DM notwendig oder nicht? Falls ja, bis wann (betrifft DM-Planung!)?

5.5 Applikationen

• Festlegen des benötigten Funktionsumfangs pro Meilenstein
  • Idee/Ansatz: Prototyp / "abgespeckte" Version 2025, "Vollversion" 2026
  • Vorgehensweise klären

5.6 LSA Modell

• Liste der Geräte erstellen, die (zusätzlich, für DeviceControl) in LSA importiert werden sollen
• Hierarchie für Tests 2024
• Timing-Hierarchie
• Hierarchie für 2025
  • Datenversorgung "Chopper-System"?
  • Datenversorgung "Strahlverlustüberwachung"
  • Kommentar Susi: Es gibt weitere Überwachungen/Kontrollen (in UPZ). Zu klären, welche davon für 2025 relevant sind (s.u.)
• Hierarchie für 2026
  • Datenversorgung Fast Beam Loss Control (FESA)

5.7 PG-Schutz

• Konzept, wie PG-Schutz im neuen Kontrollsystem funktionieren soll
• Ggf. vereinfachtes Konzept für Notfallsystem 2025
• Benötigt Beam Modes?

5.8 Überwachungs- bzw. Kontrollmechanismen aus UPZ-Programm

• Wo werden diese in Zukunft angesiedelt? LSA, BSS, MASP?

5.9 Integration gepulster Gasstripper für Strahlzeit 2026

• Entwicklung/Erweiterung Stripper-App
• FESA-Klasse für neuen Stripper
• Settings/Timing-Events

6 Nächste Schritte

Für die folgenden Punkte ist die Annahme, dass ihre Bearbeitung kurzfristig durch die in Klammern genannten Personen erfolgen kann (ggf. abhängig von Arbeitsergebnissen darüberstehender Punkte).

6.1 Projektplanung

6.2 Anwendungen

6.3 Front End

6.4 LSA-Framework

6.5 LSA-Modell

6.6 Timing