Fesa, Fokus der Controls

Bei der Evaluierung von FESA sollten verschiedene Aspekte untersucht werden: $ Eignung für GSI-Betrieb (siehe hier):: Wie weit ist die Funktionalität von FESA für den GSI-Betrieb geeignet, was müsste für die GSI geändert werden? $ Schnittstellen (siehe hier):: FESA ist nur ein Teil eines Kontrollsystems - wie sehen die Verbindungen zum Rest aus? $ Anpassung (siehe hier):: Was müsste konkret für die GSI geändert werden, soweit schon absehbar? $ User-Unterstützung (siehe hier):: Wie komfortabel ist FESA, wie einfach lassen sich nicht-triviale Geräte anschließen? $ Wartbarkeit (siehe hier):: Wie einfach wartbar und erweiterbar ist FESA, was bedeutet es, wenn FESA langfristig betreut werden muss? $ Unterschiede zum GSI-System (siehe hier):: Gibt es Unterschiede zu Design Prinzipien des GSI-Kontrollsystems? Macht FESA Dinge anders, an die wir uns ganz selbstverständlich gewöhnt haben? Und wenn: Welche sind das?

Es ist völlig klar: In der begrenzten Zeit werden sich diese Fragestellungen nicht umfassend beantworten lassen. Trotzdem müssen wir, soweit es halt geht, ein Gefühl dafür bekommen und wenigstens eine Abschätzung machen. Dazu sollen einfach gehaltene Modell-Implementierungen realisiert werden, die in geeigneter Weise näher untersucht werden können.

Im Einzelnen ist zu beachten:

Modell-Implementierungen

Mögliche Modell-Implementierungen sind

1. Ein Register auf einer VME-Karte als Simulation eines Netzgerätes und zur Zeitmessung.
2. Exemplarische Eigenschaften des Gerätemodells MX.
   • Ein oder zwei Properties (Lesen und Schreiben) realisieren
   • Werte Eventgesteuert auf VME-Adresse schreiben bzw. davon lesen
   • State Maschine im Realtime-Teil der Software u.a. zur Erkennung von Eventsequenzfehlern.
3. Möglicherweise: Besonderheiten des Gerätemodlls MX
   • Zeitversetztes (interlaced) Istwert-Lesen (Unilac, Hochstrom)
   • Lastumschaltung (fünf Magnete an einem Netzgerät; also eine Interfacekarte, aber bis zu 5 Nomenklaturen und möglicherweise bis zu 5 Hallsonden (und damit bis zu 5 ADC-Karten), die immer lesbar sein müssen unabhängig von der Stellung des Lastschalters.)
   • Varianten: 1 oder 2 ADCs, mit oder ohne Feldregelung
   • Wie kommen die gerätespezifischen Polynomsätze aus einer DB automatisiert zum Geräteobjekt?
4. . . .

Eignung für GSI-Betrieb

Wie weit deckt FESA die für die GSI benötigte Funktionalität ab?

• Lassen sich typische Anforderungen aus der GSI realisieren (und wie?)?
  • Was für die bestehende GSI wichtig ist
  • Was für FAIR wichtig ist (was davon heute schon bekannt ist)
• Was müsste dafür erweitert werden?
• Beispiele:
  • FAIR: Mindestens 255 virtuelle Beschleuniger
  • FAIR: Subindexing (Variation einer Grundeinstellung, ähnlich Therapiebetrieb)
  • FAIR: Explizite Zyklusphasen
    • Daten mal geziehlt aus Zyklusphase, mal aus ganzem Zyklus
  • FAIR: Umschaltung Hoheit über Anlagenteile (Bedienung mal vom HKR, mal vom Experiment, z.B. der Fragmentseparator)
  • Wie ließe sich der heutige GSI-Gerätezoo anschließen?
    • Wie lassen sich geringfügige Unterschiede behandeln (Geräte-Varianten)?
    • Wie flexibel ist Geräte-Umfang?
      • Kicker: Alle gerade ansprechbaren Module (1..9)
      • Oft: Eine HW bedeutet mehrere Geräte
    • was ist, wenn Geräte nicht voneinander unabhängig sind?
      • eine HW soll als mehrere Geräte erscheinen
        • wie Magnete mit Lastumschaltung
        • Ionenquellen (ISAU)
        • Strahldiagnose (PLA, DGX, ...)
      • Integrator-DGX: Integrationszeit gemeinsam schalten
  • Interrupts/Meldungen vom Gerät, wie reagieren?
    • derzeit bei MIL: DRD-/DRQ-Interrupt, Interlockleitung
  • Datenkorrelation, wieweit unterstützt (siehe Punkt Datenaufnahmesystem in diesem Abschnitt)?
  • Konnektierte Aufträge, gibt es sowas wie Event-Konnektierung?
  • Wie flexibel sind die Strukturen der Property-Daten?
• In der GSI immer mal wieder in der Diskussion gewesen, und für eine große Anlage wie FAIR sicherlich von größerer Bedeutung als für die letztlich noch übersichtliche heutige GSI:
  • Gerätereservierung: Eine Anwendung kann sich den exclusiven Zugriff auf ein Gerät holen (d.h. andere Anwendungen können das Gerät dann nicht mehr verstellen). Natürlich muss einen Ober-Master geben, der versehentlich nicht aufgehobene Reservierungen aufheben kann.
  • Umschaltung der Hoheit: Gemeint ist: Zugriffe auf eine Gerätgruppe können mal nur von einer Stelle (wie dem HKR), mal nur von einer anderen Stelle (z.B. der lokalen Fragmentseparator-Konsole) durchgeführt werden.
    Ist was ähnliches wie die Geräte-Reservierung, aber hier müssen verschiedene Applikationen zugreifen können (die alle an derselben Konsole laufen).
• Datenaufnahmesystem: Am GSI-System wurde von der Strahldiagnose angemerkt, dass das Kontrollsystem als Steuersystem ausgelegt ist. Die Datenrichtung ist vom Operating (Steuerdaten) zum Gerät (Sollwerte einstellen).
  Was nicht so gut funktioniert, ist die Gegenrichtung, bei der im Gerät Istwerte aufgenommen werden, die zum Operating zu transportieren sind. Dabei ist vor allem an den Anwendungsfall Strahldiagnose zu denken. Wichtige Punkte sind:
  • Daten aus allen ablaufenden Zyklen (kein Überschreiben von Daten durch neue, solange die alten nochh nicht abgeholt sind). Braucht sicherlich so was wie einen Puffer, in dem Datensätze von mehreren aufeinanderfolgenden Zyklen aufgehoben werden können.
  • Genaue Timestamps.
  • Datenkorrelation. Von unterschiedlichen Geräten die Daten, die aus demselben Zyklus stammen, zusammenführen zu können.
  • Als Beispiel für weitere Anforderungen bezüglich Datenaufnahmesystem kann vielleicht das ABLASS-System der Strahldiagnose-Abteilung dienen.

Schnittstellen

Was gibt es, wie sehen sie aus?

• Timing
• Middleware
  • CORBA
  • Messaging
• Alarmsystem
• Datenbank

Anpassung

CERN verwendet etwas andere Begriffe, Konzepte, ..., als die GSI. Wo geht das ein, was müsste angepasst werden, wenn FESA als Teil des bestehenden GSI-Kontrollsystems lauen sollte?

• Timing (virtuelle Beschleuniger / User)
• Alarmsystem
• Zugriffsrechte

User-Unterstützung

FESA ist attraktiv, weil die Einbindung von neuen Geräten ganz einfach geht. Wie einfach geht das wirklich, wenn es sich um nicht-einfache Geräte oder nicht-einfache Aufgaben handelt?

• Ein typisches GSI-Gerät über FESA anschließen
• Wer hat gute Ideen, was besonders typisch ist?
• Folgende Ideen hatten wir schon mal angesprochen:
  • Gerät mit hartem Timing realisieren, z.B. FG, und gucken, ob der Jitter in der Interrupt-Latency klein genug ist, um damit Umlenker und HF im SIS so wie bisher zu betreiben (Stichwort Beschleunigung ohne B-Train). Garantierte Reaktionszeiten < 100us?
  • Ein "Spezial"-Gerät realisieren. Das wäre etwa ein Gerät mit einer Nomenklatur und n Elektroniken, oder n Nomenklaturen an einer Elektronik.
  • Interlaced Mode der gepulsten Magnete im HSI realisieren.
  • Fesa auf der MBox.

Wartbarkeit

Wenn FESA bei GSI eingesetzt wird, muss die langfristige Unterstützung sichergestellt sein, und zwar für den gesamten Einsatzzeitraum von 10, 20 oder 30 Jahren. Das bedeutet, dass die GSI zumindest im Notfall in der Lage sein muss, alle Teile von FESA eigenständig an neue Front-End Platformen, neue Betriebssystemversionen, neue Versionen von Datenbanken, usw usw anpassen zu können.
Darüberhinaus wird FESA im Lauf der Einsatzzeit mehr oder weniger stark erweitert werden müssen. Diese Erweiterung wird vorwiegend durch die GSI vorangetrieben werden müssen, da sich der GSI-Betrieb dynamischer entwickeln wird als der Betrieb im CERN - das heisst, derartige Erweiterungen werden schwerpunktmäßig oder sogar ganz alleine durch dei GSI erfolgen müssen.
Dann werden Fragen wichtig wie:

• Leichtgewichtig / schwergewichtig?
  • Je umfangreicher der Code, desto umfangreicher sind oftmals Anpassungen
• Wie stark sind Komponenten verzahnt, was muss man bei Änderungen an einer Stelle alles anpassen?
  • Wo überall geht die Datenbank ein?
• Wie starr sind Strukturen, Abläufe in FESA vorgegeben?
• Wieweit ist vorgesehen (zur Erinnerung: Bei GSI kann jedes standardmäßig vorhandene EQM, und jede standardmäßig implementierte USR, durch eine spezifische ersetzt werden):
  • Es gibt eine standardmäßige Default-Behandlung
  • Bei Bedarf kann sie durch eine spezifische Behandlung ersetzt werden

Unterschiede zum GSI-System

Viele Eigenschaften des GSI-Kontrollsystems sind schlicht in Vergessenheit geraten oder werden als völlig selbstverständlich angesehen. Es sollte versucht werden, sich diese Selbstverständlichkeiten zu verdeutlichen, und dann zu sehen, wie FESA an entsprechender Stelle vorgeht.

Dass FESA vieles anders macht, als das GSI-Kontrollsystem, ist erst mal durchaus erwünscht. Hinter vielen Implementationsdetails des GSI-Kontrollsystems verbirgt sich aber ein tieferer Grund: Oftmals soll durch genau diese Implementation ein spezielles Verhalten erreicht werden. Auf welchem Wege dieses Verhalten erreicht werden soll, ist natürlich nicht wirklich wichtig. Ist aber dieses Verhalten für den Betrieb (d.h. die Bedeinung der Geräte im Betrieb) wichtig, muss geprüft werden, ob auch in FESA ein entsprechendes Verhalten erreicht wird.

Das betrifft z.B. Punkte:

• Konsistenter Update von Gerätedaten (GSI: "Synch-Puffer"): Mit einer Property werden mehrere Daten geschrieben, die in der Real-Time Ebene zur Steuerung des Gerätes dienen. Im GSI-System gibt es einen Mechanismus, der die mit einer Property nacheinander geschriebenen Daten erst mit einem Befehl (einer Code-Zeile) gemeinsam gültig setzt. Auch nach diesem Umsetzten in der Property arbeitet die Real-Time Seite mit dem Dartensatz weiter, der zu Beginn des Zyklus gegolten hat. Entsprechendes gilt für Ist-Werte, die möglicherweise nach und nach von der Real-Time Ebene gelesen werden und gesammelt in einer Property gelesen werden sollen.
  • Wird entweder erreicht, indem entweder alle Daten doppelt in einem Feld der Größe 2 gehalten werden. Ein Index 0 oder 1 zeigt jeweils auf das Element, mit dem die Real-Time Ebene arbeitet. Gibt es neue Daten, werden sie in das jeweils andere Element geschrieben und am Ende nur der Injex umgesetzt, der in die gültigen Daten zeigt.
  • Oder wird ereicht, indem Zugriffe per Property mit dem Zyklus synchronisiert werden: Daten für eine Property werden über ein (Kommando-) EQM in die Real-Time Ebene geschrieben bzw. davon gelesen. Dieses EQM,wird, weil es als Kommando-EQM aufgerufen wird, nur in der Pause zwischen zwei Zyklen aufgerufen: Dann, wenn die Real-Time Ebene nicht mit den Daten arbeitet.
• Strukturierung von Property/Geräte-Daten: GSI hat sich teilweise ausgetobt, sowohl die Gerätedaten im DPR als auch die Property-Daten sinnvoll zu strukturieren. Im Code wird teilweise mit Datenstrukturen gearbeitet wie Structures von Arrays von Structures. Das muss zwar nicht sien, denn letztlich lässt sich alles abbilden über flache Strukturen wie die Aneinanderreihung von Grundtypen sowie Arrays davon. Die erwähnten 'wilden' Typen machen en Code aber in vielen Fällen deutlich übersichtlicher.
  Was ist mit FESA möglich?
• Die GSI-Properties arbeiten mit sogenannten "Daten" (bei Schreib-Properties zum Gerät, bei Lese-Properties vom Gerät) und mit sogenannten "Parametern", die immer zum Gerät transferiert werden und mit denen man die Ausführung einer Property parametrisieren kann.
  Gibt es das auch bei FESA? Ist ja zunächst eine Eigenschaft der Middleware, aber wenn es diese Eigenschaft gibt (oder wenn so was eingeführt wird), muss FESA auch damit umgehen.

Zurück: Allgemeines FESA-Wiki