Participants

Topics

• FESA-Forum
  • Timo Milosic proposed to introduce a Forum, where FESA-developers can exchange knowledge with each other
  • After some discussion we decided that Alexander Schwinn will check if our IN-department offers such a service ( or if there is some easy zero-cost solution which can be used without much effort )
  • If this is the case, a FESA-forum will be established

• detailedStatus - "severity"-information of the bits
  • The application-department asked for a fixed rule, in order to see if a bit has the severity "ok" (green) or "error" (red)
  • Since there are status-bits for which it makes no sense to have an ok/error state, we discussed different other solution-proposals. E.g:
    • Usage of a separate property for bits which have no clear severity
      • --> Not very nice, since we want to have all important bits in the detailedStatus and not somewhere else
    • No coloring of the detailed-status-bits by the applications
      • --> I dont remember the contra-argument here ... probably the coloring-feature just is desired.
    • An additional value-item in order to mask the bits (int-array)
      • --> To many different value-items for the same purpose
    • We dont send an array of bits, but an array of integers in the value-item "detailedStatus"
      • --> This is the solution we finally all agreed on.
      • Each integer will have a severity-info-part and a true/false part
      • "O" or "false" = "Error" should be used for all bits with ok/error severity ! ( To be added to the FESA-Guideline )
      • E.g. a usage of the detailedStatus could look like that:
        • myDetailedStatus[13] = TRUE + RATEABLE
        • myDetailedStatus[14] = FALSE + NOT_RATEABLE // naming has to be discussed

• Naming of value-items related to the timing-receiver
  • On one of the previous meetings we discussed to add the following two value-items into the "Status"-property:
    • statusTimingReceiver ( ok/warning/error/notAvailable )
    • deviceNameTimingReceiver
  • On top we concluded that the timing-receiver will have its own devicename and a own FESA-class.
  • Today, after some discussion we found out that we dont want to overload the property "Status". Here some of the arguments:
  • It does not make much sense to have a fix configuration-value, like "deviceNameTimingReceiver" in "Status"
  • If the device-name of the timing-receiver can be requested, it is not necesarry to as well provide info about its status. The client can do so on his own.
  • Generally one could say: As soon as one FESA-device depends on another FESA-device, it should be sufficient to know the device-name of the other device.
  • We finally agreed on the following:
    • We will introduce an additional GSI-Specific Property "Info", which will consist of the value item "deviceNameTimingReceiver". ( Information about the different properties and devices, hosted by the class could be added to this property in a later step )
    • There will be no value-item "statusTimingReceiver", neither in the property "Status", nor in the property "Info"
    • Alexander Schwinn will ask Dietrich Beck and Udo Krause if they are fine with the outcome, or if more discussion is required
• Misc
  • Peter Kainberger raised the proposal to add a convention to display the status of required hardware, controlled by a class (E.g. ok/error/disconnected/? )
    • The state of the hardware should not cause the FESA-class to crash. The operating needs to be able to communicate with the device as well, when the required hardware is missing.
    • --> This will be topic of the next fesa-meeting