FESA Software fuer Magnetnetzgeraete: Ideen / Wuensche

Auf dieser Seite werden Ideen und Wuensche fuer die Realisierung von FESA Software fuer Magnetnetzgeraete festgehalten. Es handelt sich lediglich um eine Bestandsaufnahme des Status Quo und der Ideen und Wuensche um sich einer Loesung anzunaehern.

Aufgabe

Ideen/Wünsche

• Moeglichst wenig FESA Klassen fuer Geraete wie z.B. PowerSupplies um den Wartungsaufwand gering zu halten
• "Untergeraetemodelle" mit einem eingeschraenkten Satz an Uebergabeparametern einer Property fuer die Datenbank erfinden?
• Eine einzelne FESA-Klasse mit allen moeglichen und denkbaren Uebergabeparametern in einer Setting / Acquisition Property, die unterschiedlichen Geraetemodelle und deren benoetigte Daten innerhalb der FESA-Klasse (in FESL) abhandeln und je nach Geraetemodell das Interface innerhalb der Datenbank fuer die Applikationen unterschiedlich ablegen

Gründe

• Geraete wie PowerSupplies ähneln sich im Wesentlichen.
• Es gibt mehrere gleichartige Geraete die sich mitunter nur in einem einzigen Detail unterscheiden. Ein solches Detail liesse sich innerhalb der Software (FESA? + FESL) sehr leicht abhandeln.
• In FESA kann dies in einer Setting-Property ein einzelner Uebergabeparameter sein, z.B. benoetigt ein Magnet als Uebergabeparameter eine Spannung, ein anderer Magnet nur die Stromstaerke.
• Manche Geraete benoetigen beide Werte. Der Rest ist jeweils identisch. Es wird als zuviel Aufwand betrachtet fuer jedes einzelne Geraet dass sich nur in einem Parameter unterscheidet eine FESA-Klasse und die zugehoerige DeployUnit zu erstellen und langfristig zu pflegen.

Status Quo

Klassendesign

• In FESA wird das Interface zum Gerät designt. Es werden die Properties sowie deren Uebergabeparameter+Daten definiert. Diese Information wird in der FESA Datenbank abgelegt. Die Informationen in der Datenbank stehen für die Anwendungen und die Datenversorgung zur Verfuegung.
• Zur Laufzeit einer FESA-Klasse sind die "nach oben" abgebildeten Daten lediglich in Bezug auf Property-Namen und die Typen (!) der Uebergabeparameter an Properties relevant.

Setting / Setzen von Daten

• Das sog. "partial setting" von Uebergabeparametern ist technisch moeglich. D.h. es ist in FESA moeglich eine Property aufzurufen und dabei nicht fuer alle Uebergabeparameter einen Wert mit zu senden.
• Die Uebergabeparameter werden durch ihren Namen identifiziert innerhalb von FESA sowie beim Befuellen des RDA-Datencontainers durch eine Applikation (einen client).
• Verwendung von sog. Filtern zum Steuern des Datenflusses ist moeglich.

Acquisition / Lesen von Daten

• Es gibt in FESA das Konzept der sog. Filter. Mit Filtern ist es möglich sein lediglich einen Teil der Daten oder ausgewaehlte Daten vom Client anzufordern. Die Entscheidung was bei welchem verwendeten Filter zurueck gesendet wird ist dann allerdings in der FESA Software unterzubringen. Mehr dazu ist in der FESA Entwickler Guideline und in der FESA Dokumentation zu finden. Allerdings ist dann fuer den Client nicht anhand der Datenbankeintraege erkennbar mit was er es zu tun hat.
• Per default wird immer der komplette Datencontainer einer Property zurueck gesendet. Unabhaengig davon ob sinnvolle Werte darin vorhanden sind oder nicht. So waere nicht zu unterscheiden welcher zurueckgesendete Wert tatsaechlich zu verwenden ist wenn man immer alle potentiell moeglichen Werte fuer alle Magnetnetzgeraete in einer Acquisition-Property anbietet.

Instanziierung

Die Geraeteinstanzen sind in der Instanziierungsdatei pro FESA-Klasse hinterlegt. Diese Informationen werden zur Laufzeit einer FESA-Klasse benoetigt. Eine Zuordnung von Untergeraetemodellen mit einem eingeschraenkten Satz an Properties und Uebergabeparametern wird auf die Art und Weise schwierig.

Laufzeit

Zur Laufzeit von FESA Geraetesoftware werden die folgenden Informationen dem CMW directory server beim Starten mitgeteilt:

• Name der DeployUnit
• Name des FECs auf dem die DeployUnit ausgefuehrt wird

Zugriffe von Clients

Bei Zugriffen von Clients auf die FESA Geraetesoftware werden die folgenden Informationen verwendet:

• Name des Geraetes (in der Instanziierungsdatei festgelegt)
• Name der anzusprechenden Property
• (Entsprechende Daten)

Realisierungsideen

Zunächst einmal unterscheiden sich Netzgeräte durch Anzahl und Bezeichnung von Setting- und Acquisition-Werten: Es gibt Netzgeräte mit Stromvorgabe, mit Spannungsvorgabe, mit Strom- und Spannungsvorgabe (zwei Setting- und Acquisition-Werten), Netzgeräte mit Einzelwerten und gerampte Geräte, die ein ganzes Array von Setting-Werten benötigen (mal eine Rampe, mal zwei) und als Acquisition-Werte zurückliefern.

Deskriptive Beschreibung

Setting- und Acquisition-Properties habe ein Format, was auf eine beliebige Anzahl von Werten passt. Das kann dann nur ein Array sein (mit variabler Dimension?).

Damit Applikationen erkennen können, welche der Werte relevant sind, sind Zusatzinformationen nötig. Sie können

• in den Properties über zusätzliche Value-Items lesbar angeboten werden. Vieles ist denkbar:

  • als beschreibenden String: 'HV-Powersupply', 'Magnet-Powersupply'

  • als Anzahl der gültigen Array-Elemente, zusätzlich einem String-Array mit der Bedeutung (valueCount=2, Name[0]='current', Name[1]='voltage')

  • . . .

• oder auch, geschickt kodiert, in der LSA Datenbank abgelegt werden

  • kommen dann auch generische Applikationen außerhalb von LSA da dran (wenn sie z.B. nur was lesen wollen)?

Angepasste Klassenbeschreibung

Idee ist, in einer

Das FESA-Klassendesign wird als eine Obermenge der für jeden Typ von Netzgeräten passenden Value-Items (und möglicherweise auch Properties) angelegt. Das heißt, die Setting-Property (und entsprechend die Acquisition-Property) enthält Value-Items

• current
• voltage
• singleRamp
• doubleRamp
• . . .

Über Einträge im Instantiierungs-File konfigurierbar verwendet die FESA-Klasse je nach Typ des Netzgerätes einen oder mehrere dieser Value-Items.

Für Applikationen werden, in zwei Schritten, angepasste Beschreibungen der FESA-Klasse erzeugt, die für das jeweilige Gerät nur die Value-Items enthalten, die von dem jeweiligen Netzgerät tatsächlich verwendet werden. Dazu sind im Design der FESA-Klasse und in der Instantiierungs-Datei nur wenige Zusatz-Informationen erforderlich. Diese aus dem eigentlichen FESA Klassendesign erzeugten Beschreibungen werden hier als sub-class bezeichnet.

Im Design der FESA-Klasse:

• Eine Liste der möglichen sub-classes (PowerSupply _I, PowerSupply _V, PowerSupply IV, ...)
• Für jeden Value-Item eine Angabe, in welcher sub-class er enthalten sein soll.
  • Günstig wäre eine optionale Angabe, auf welche sub-class der Value-Item beschränkt sein soll - fehlt diese, gilt der Value--Item für alle sub-classes (die Value-Items der Status-Property gelten für alle sub-classes)

Aus diesen Angaben erzeugt FESA Beschreibungen für die sub-classes, die zusätzlich zu der eigentlichen Beschreibung der FESA-Klasse in die Datenbank eingetragen werden. Die Einträge erfolgen genauso, als wenn die sub-classes eigenständige FESA-Klassen wären. FESA selber arbeitet nur mit der kompletten Beschreibung.

Um die einzelnen Geräte nun den jeweilige sub-classes zuordnen zu können, sind weitere Angaben erforderlich.

Im Instantiierungsfile:

• Für jede Device-Instanz eine optionale Angabe, zu welcher sub-class das Geräte gehört

Diese sub-class Angabe wird ebenfalls in die LSA-Datenbank eingetragen, entweder als neue Zusatzangabe, oder (ganz genial) anstelle des sonst verwendeten Namens der FESA-Klasse.

Exemplarisch wird dies an einem Ausschnitt aus den entsprechenden FESA XML-Dateien gezeigt:

Zu beruecksichtigen

• Falls CERN das Konzept auch verwenden kann sollte es auch moeglich sein das komplette Design in die Datenbank einzutragen. Die Informationen daraus werden verwendet um auf dem FEC das richtige Binary auszuwaehlen.
• Auswahl von properties fuer ein subset
• Auswahl von items in einer property fuer ein subset *