Videocon 07 Sep 2017

2017-09-7 Weekly Meeting

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
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

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

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