dsferruzza
commented
4 years ago I'll try to sum up my understanding.
Alarms have:
- a trigger predicate: it can depend on various parameters, and may need an internal counter of the number of cycles in a row the predicate was true along with a threshold that will raise an alarm when exceeded
- an error code (unique)
- a severity: low, medium, high
When an alarm is triggered it has effects depending on its severity:
- buzzer (already implemented)
- LEDs
- display error codes on the third line of the LCD screen (using horizontal auto-scrolling?)
When several alarms are triggered at the same time, only the alarms of the higher triggered severity have effects.
If a user press the alarm OFF button, it snoozes the buzzer for 2 minutes. If an alarm of higher severity is then triggered, snoozing is interrupted and buzzer rings.
If an alarm's predicate becomes false, it is not to be considered active anymore. Effects can continue to happen according to the higher severity of the remaining active alarms, or stop if there are no remaining active alarms.
I believe we need some kind of alarm controller (singleton?) that could:
- be called if the predicate of an alarm is true (this might trigger effects)
- be called if the predicate of an alarm is false (this might stop effects)
It would then keep track and handle:
- inner state of alarms (number of cycles in a row it was triggered)
- active alarms
- snooze status (if snoozed, we need to keep track of the timing and the severity that was snoozed)
- LEDs effects
- LCD display
RomainBlanc
French version
Mefl
hbs
Alarms logic is currently missing.
Related issues describing alarms individually (alarms definition is still work in progress):
Alarming system behavior:
Test benches protocols: https://docs.google.com/document/d/1A3L-puGiDQOrkns229-GeCmOXisWVPol59NXHKI1Foo/edit