Health Monitoring#

Alive Supervision#

The Alive Interface provides a basic watchdog functionality interface that delivers essential monitoring capabilities for system health and responsiveness tracking. It implements core watchdog operations including heartbeat signals to ensure reliable operation and automatic recovery from unresponsive states.

SCORE Application Liveliness Reporting

SCORE applications can periodically signal their liveliness to the Launch Manager through the Alive Interface. This mechanism allows the Launch Manager to:

Detect application failures or hangs
Trigger recovery actions when liveliness is lost
Maintain accurate process health status

The liveliness mechanism includes:

Configurable heartbeat intervals per application
Timeout detection and failure handling

The corresponding configuration parameters are shown as AliveSupervision in Configuration Structure.

The alive interface is defined here: logic_arc_int__lifecycle__alive_if

The Launch Manager starts the Alive Supervision at the exact time when the Application reports its Running state via the Lifecycle Interface. As a consequence the Liveliness Reporting is only available to SCORE applications that also use the Lifecycle Interface.

Dynamic architecture#

Alive Monitoring Start		status: valid security: YES safety: ASIL_B
version: 1 belongs to: feat__lifecycle fulfils: feat_req__lifecycle__liveliness_detection

feat_arc_dyn__lifecycle__alive_monitor_start		Feature Sequence Diagram

Alive Monitoring Stop		status: valid security: YES safety: ASIL_B
version: 1 belongs to: feat__lifecycle fulfils: feat_req__lifecycle__liveliness_detection

feat_arc_dyn__lifecycle__alive_monitor_stop		Feature Sequence Diagram

In-Process Supervision#

The Health Monitor is a library, that together with the Launch Manager provide a way to monitor the application health in similar fashion as the AUTOSAR Platform Health Manager (PHM).

The main features of the Health Monitor are the following monitoring functions:

Checkpoint supervision - Periodic monitoring of checkpoints, which must fit the pre-configured expected number of notifications in the given interval (not too many, not too few) - Protecting from running checks too often or too rarely
Deadline supervision - Timing requirement between two checkpoints.
Logical - Specifies in which order two or more checkpoints must be called

The Health Monitor itself is monitored via the Launch Manager with via alive supervision only.

Error Reactions#

When the Health Monitor detects a failed supervision, it shall stop triggering alive notifications to the Launch Manager.
Additionally, when the error occurs, the Health Monitor triggers a failure notification to the Launch Manager to reduce the time to react on the error. This obviously will only work if the Health Monitor is still working and correctly scheduled. Thus the worst case reaction time calculations must be made on the monitoring rules specified in the Launch Manager for the monitored application.

Deadline Monitor API#

Interface#

The deadline monitor interface is defined here: logic_arc_int__lifecycle__deadline_monitor_if

Dynamic Architecture#

Application health monitoring

status: valid
security: YES
safety: ASIL_B

version: 1

belongs to: feat__lifecycle

fulfils: feat_req__lifecycle__hm_checkpoint, feat_req__lifecycle__hm_deadline, feat_req__lifecycle__liveliness_detection

The most important interactions are the following:

Sequence number	Description
001	Launch Manager configuration for the alive monitoring of the Monitored application is parsed. This contains for example, what is the expected interval of alive notifications, how long grace period is given before failing to a missed (never received) alive notification etc.
002	Start the startup grace period timer to allow the application to startup, before timing out to a missed alive notification
003	The Monitored application is started. (To simplify, no startup checks drawn here)
004	The Monitored application instantiate and configure the HealthMonitor
006	Cyclic reporting aliveness to the monitor.
007	HealthMonitor waking up and checking if the checkpoint(s) have been called
008	Report aliveness to the LM’s application specific supervision, observing the health of the HealthMonitor itself
009	Checkpoint sent, but not on time
010	Wake up and check if the checkpoint(s) have been triggered. In this case it was not, and thus actions 011 and 012 are triggered.
011	Trigger a failure event to the Launch Manager. This event allows the monitor react faster than waiting for the timeout to expire.
012	Additionally, triggering alive must be stopped

Logical control flow monitoring		status: valid security: YES safety: ASIL_B
version: 1 belongs to: feat__lifecycle fulfils: feat_req__lifecycle__hm_checkpoint, feat_req__lifecycle__hm_logical, feat_req__lifecycle__liveliness_detection

feat_arc_dyn__lifecycle__app_ctrl_flow_mon		Feature Sequence Diagram