Skip to content

Videocon 07 Sep 2017

Jump to bottom
Alessandro Caproni edited this page Sep 8, 2017 · 11 revisions

2017-09-7 Weekly Meeting

Participants:

  • Alessandro Caproni (ESO)
  • Maximiliano Olivares (Inria Chile)
  • Jazmine Maldonado (Inria Chile)
  • Sebastián Fehlandt (Inria Chile)

Summary of discussed topics:

  • Repository and development environment configuration
  • Some tests (e.g. Cdb tests) require Oracle Express to be run -> proposal to change to MySQL
  • InOut.scala is transformed into a IASValue.java by the Converter
    • Ale: monitor point values and alarms provided by plugins are published in the T queue as MonitorPointData; the Converter takes a MonitorPointData, converts it into a IASValue and finally publishes it into the IASIO queue. The InOut (old name used in the prototype, now it is a IASIO) is the object representing a monitor point value or alarm inside a alarm system component (ASCE). The ASCE produces an IASIO after applying the transfer function to its inputs and such a value is converted into a IASValue and published into the IASIO queue. So the same IASValue is used for publishing monitor point values and alarms received by plugins and the output produced by ASCEs
  • Validity:
    • Reliable: the alarm is still working ok
    • Unreliable: the alarms is not working properly, e.g. value way out of range or exceeded timeout
  • Discusssed Operational Modes and what each of them mean
  • Values runningID contain at their ends an identifier of the device that triggers the alarm. This identifier is unique and should be used to map to the real device representation for GUI purposes
    • Ale: note that apart of runningID, there is the fullRunningID; the difference is that the latter has the type of each identifier close to its id string (@see Identifier)

Conclusions and Decisions:

Core:

  • Validity property is lost when converting InOut.scala to IASValue.java
  • Alessandro is working on a test that mocks Plugin messages, in order to test the whole architecture upwards

UI:

  • Webserver for GUIs should listen to the Kafka queue and expect instances of IASValue objects in JSON format
    • Ale: the web server consumes instances of IASValue from the IASIO queue in the same way the ASCEs do. The same library to be developed for ACSEs will be used by the web server that will not get directly a string but a java object. If really needed we can let the library offer to the listener a JSON string.
    • We use jakson2 for marshalling/unmarshalling java objects into JSON
  • Webserver should check validity after an amount of time defined by the specific alarm timeout
    • Ale: the library will update the validity before passing the value read from the queue to the listener. This ensures that the same logic is applied everywhere in the IAS (i.e. in the core and in the web server).
  • Webserver must be fast, if we need a DB, we should use one in memory (e.g. Redis)
  • Only Operator on duty should be able to Acknowledge an alarm
    • Ale: we concluded that we need 3 type users instead of 2:
      • Operator on duty: operator view with ACK and SHELVE capability
      • Operator: operator view with SHELVE capability only
      • Enginer: engineer view with SHELVE capability only
  • Every operator should shelve be able to shelve the alarms by their own and only for themselves
  • Inria team will either extend the configuration database or create a new one to define the graphical display of monitoring points in the GUIs
    • Ale: IMO the same database server must be used for the GUIs. A new set of table will be added aside of the ones defined for the core. This allows to check for consistency (for example be sure that the identifier of a IASIO used by the GUI really exists in the core)

Short-term Tasks:

  • Inria team will create this wiki page and git branching wiki page
  • Alessandro will create issue: Add validity to the IASValue

Follow us on twitter

Clone this wiki locally