* Die Implementierung der USRs geht bisher (21.Sep.04) davon aus,
  dass  *nur ein* Gerätemodell bearbeitet wird. Weitere Gerätemodelle 
  müssen "in einem eigenen main()" implementiert werden!

-> Ok! Jetzt (12.Nov.04) gehen auch zwei Gerätemodelle (MX, PLA).
   Aber siehe die Punkte zu "Shared Library" weiter unten.


* In <epmod>-usrs und <epmod>-device den namespace aktivieren
  und testen.

-> Ok, allerdings bisher *nicht* für <eqmod>-dev-def.h


* Was machen wir mit den Default- und den Therapie-USRs?

-> Ok, die werden (im Moment, Jan.05) inkludiert, wie bisher.


* Kann man nicht statt zwei Klassen ReadFieldS und WriteFieldS
  *nur eine* Klasse FieldS machen, die *beide* Methoden, read()
  *und* write() implementiert?

->Das geht nicht so einfach, weil jede USR u.a. mit den Eigenschaften
  PROP_MODE_READ/WRITE/CALL und MEDLOCK_NONE/VRTACC/ALL instanziiert 
  wird. Lese- und Schreib-USR unterscheiden sich aber in diesen 
  Eigenschaften. Belassen wir's also zunächst mal bei der Zuordnung
  eine Klasse, eine Methode.


* Es gibt ein *kleines* Kompatibilitätsproblem, wenn wir Istwert-
  Properties nun mit "A" statt "I" am Ende (CURRENTI -> CURRENTA)
  bezeichnen. Userface wird nach wie vor auf TK1MU1(CURRENTI)
  zugreifen wollen. Behalten wir also die deutschen Bezeichnungen
  "I" (für Istwert) bei, statt die englische Bezeichnung "A" (für 
  Actual Value) zu benutzen?

  "S" kann man ja glücklicherweise sowohl als Sollwert als auch
  als Set Value begreifen.

-> Ok! Alles heißt wieder "SowiesoI".


* USR-Support: Wie kann ich in checkAccessState() (ehemals
  getStandardParameter()) testen, ob ein Gerät gerade gelockt
  ist? Dazu brauche ich die Property-Kategory, die 'N', 'V' oder
  'L' sein kann. Diese ist bisher im XSR-Header mitgekommen. Die
  zweite Info ist 'security' im DPR der SE. Das müsste eine
  Methode (der Klasse ???) sein.

-> Ok! Info kriegt die USR beim Instanziieren mit.


* Eine weitere Methode muss das Gerätemodell der SE-Software 
  zurückgeben, damit gecheckt werden kann, ob die USRs dazu
  passen.

-> Ok! Mit der Methode eqModNum().


* Default-USRs können nicht mehr auf die gerätespezifischen Daten
  im DPR zugreifen, z.B. um Status zu lesen, da die Methode devDataP(),
  die den Pointer auf die Gerätedaten liefert, zur Geräteklasse (z.B. 
  MX) gehört und nicht zur Klasse VmeDevice. Einziger Ausweg: Status 
  und alles andere über die Command-Communication-Area übergeben bzw.
  weitere Methoden der Klasse DevInfo (oder EcInfo?) erfinden. 

  Betroffen sind folgende Default-USRs:
    RDefStatus
    RDefActive
    RDefInfostat
    RDefPower
    RDefEqmError
    RDefVersion

-> Ok, DevInfo-Methoden bzw. Status via CmdComArea.


* Die Klasse DevInfo (oder welche?) muss folgende Methoden zur Verfügung 
  stellen.
    bool isMedMember();              // Gerät ist Therapie-Teilnehmer
    UWord workMode();                // Gerät ist im Normal-, Analyse-, Parameter- oder 
                                     // Einstell-Modus; evtl. EnumMedOpermode als Returntyp
    ULong dataId();                  // DataID des Gerätes aus dem DPR 
                                     // (bisher mpDevDefDisp[logDev].dataId)
    bool hasLocalMemory();           // dpr.eqmodLocalMemoryType != LOCMEM_NO_NEED; ist 
                                     // eigentlich geräte-MODELL-spezifisch, also 
                                     // *SE* "has local Memory", nicht Device
    void getVersion(EcComponent c,   // mit "enum EcComponent {ECP_ECM, ECP_MIL, ECP_EQMS, 
                    &VersString v);  // ECP_EQMVARIANT};" oder so. Man könnte evtl. auch 
                                     // 4 verschiedene Methoden machen.
    UWord activeStates();            // Aktivzustand aller VrtAccs

-> Ok! Und weitere Methoden.


* Welchen Namespace sollen die Default- und die Therapy-USRs bekommen?
  Zur Zeit haben sie keinen. Zur Zeit werden sie noch von den 
  gerätemodell-spezifischen USRs includiert. Was ist, wenn man sie einfach
  innerhalb des "namespace EqModGm { ... }" includiert? Sie wären
  damit im jeweiligen Namespace der gerätemodell-spezifischen USRs.

-> Ok, genau so isses realisiert.


* Die Includes add-xxx-usrs.cc für die Default- und die 3 Therapie-
  USR-Dateien erfinden.

-> Ok, erfunden.

* Wie kommt denn eigentlich die Default-USR REqmError an die EQM-Errors? 
  Bisher wurde alles direkt aus dem DPR gelesen. Und jetzt?

  - Direkt lesen geht nimmer
  - Eine Command-Communication-Area ist zu klein, readCommand() scheidet also aus.
  - Eine Methode devErrorP() entsprechend devDataP() erfinden?

  Brauchen wir (dann) eigentlich auch eine Methode devDefP()? "DevData", 
  "DevErr" und "DevDef" sind jedenfalls die Bereiche im DPR, die es für 
  jedes Gerät gibt. Falls es devDefP() geben wird, entfällt die eine 
  oder andere oben erwähnte Methode, z.B. workMode(), da man dann via 
  Pointer direkt auf das Element zugreifen kann.

  Die gleiche Frage, wie kommt man an die Daten, gilt auch für die
  Default-USR InfoStat.

-> Ok! Es gibt entsprechende Klassen und Methoden


* Im Zuge der Anpassung von =WDefActive= - es wird nur noch vrtAcc 
  als Parameter übergeben, nicht mehr logDev - muss auch das =ActiveEQM= 
  entsprechend angepasst werden.

-> Ok, erledigt.


* Die Therapie-USR "Write Security" haben wir als "hidden property"
  implementiert. D.h., für sie gibt es keinen Eintrag in der Mapping-
  Tabelle, so dass man, etwa via NODAL, nicht so einfach zugreifen
  kann. Hintergrund ist, dass man ein gelocktes Gerät damit jederzeit
  wieder freigeben kann, was nur in Problemfällen von Spezialisten
  genutzt werden soll. Die Property ist im Therapiebetrieb _nicht_
  gelockt!

  Das wird im Zusammenhang mit Access Rights noch mal bedacht.

-> Ok, kommt mit Access Rights.


* Die Doku der USR =EqmError= in default-usrs.hh muss ergänzt werden. Ein
  Element des Error-Ringpuffers besteht aus _2_ ULongs! Im ersten sind
  4 Bytes, die vrtAcc, logDev, eqmNr und intSts enthalten. Im zweiten
  ULong ist der eigentliche Fehler.

-> Ok, erledigt.