Skip to content

Videocon 07 Sep 2017

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
  • Webserver should check validity after an amount of time defined by the specific alarm timeout
  • 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
  • Every operator should 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

Short-term Tasks:

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

Clone this wiki locally