module ara::phm — Platform Health Management

As a central daemon, Platform Health Management monitors functional safety and runtime integrity of applications and platform services in accordance with AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. Supervised entities report their checkpoints cyclically or event-driven to the system, which evaluates deadlines, alive cycles, and logical control flows. When errors are detected, the module notifies State Management via [SWS_PHM_01142] to initiate targeted recovery actions. If recovery fails to occur or central instances fail, a watchdog trigger forces the machine into a safe state.

more ›

Platform Health Management (PHM) constitutes the central background service of the AUTOSAR Adaptive Platform for ensuring functional safety and software integrity according to ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. It monitors both application and platform processes via deterministic checkpoint reports and safeguards the hardware via cyclic watchdog triggers AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Context diagram: Architectural embedding of the PHM daemon in interaction with supervised applications, State Management, Execution Management, watchdog, and IdsM. Sources: AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

Functional supervision relies on the ara::phm::SupervisedEntity interface, via which processes report checkpoints using ReportCheckpoint() ([SWS_PHM_01123], [SWS_PHM_01127]). PHM divides verification into three supervision types [SWS_PHM_01138]:

• Alive Supervision for cyclic frequency monitoring AUTOSAR_FO_ASWS_HealthMonitoring p. 22,
• Deadline Supervision for monitoring maximum execution deadlines AUTOSAR_AP_SWS_PlatformHealthManagement p. 15,
• Logical Supervision for adherence to defined control flow graphs AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

These elementary results are aggregated per Function Group into an aggregated status GlobalSupervisionStatus ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39).

Upon detecting violations, PHM delegates error recovery to State Management via the RecoveryHandler() of interface RecoveryAction after the latter has reported its service readiness via Offer() ([SWS_PHM_01142], [SWS_PHM_01143]). If State Management cannot resolve the error or central daemons themselves fail, the safety escalation takes effect: via native WatchdogInterface with FireWatchdogReaction(), PHM triggers an immediate hardware reset ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 220).

Sequence diagram: Error escalation to State Management via the RecoveryHandler with branching to watchdog triggering in the event of an error. Sources: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

more ›

System Boundaries and Functional Embedding of Health Management

Within the AUTOSAR Adaptive Platform, Platform Health Management (PHM) constitutes the central functional entity for monitoring execution integrity, service availability, and functional safety according to ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement p. 15. As an independent, daemon-based background service, the module implements deterministic verification of temporal and logical control flows in safety-related processes AUTOSAR_AP_EXP_SWArchitecture p. 128. The system boundaries encompass three essential interaction axes: accepting checkpoint reports from supervised software entities, error escalation to State Management, and cyclically triggering keep-alive messages to a hardware-near watchdog AUTOSAR_AP_SWS_PlatformHealthManagement p. 46.

Supervision duties are not exclusively limited to regular user applications (Adaptive Applications). Rather, fundamental platform services such as Execution Management, State Management, Diagnostic Manager, and time synchronization are also subject to supervision by PHM, as they themselves function as supervised entities and transmit checkpoints to Health Management AUTOSAR_AP_EXP_SWArchitecture p. 130. For internal auxiliary functions, the PHM daemon relies on interfaces of Execution Management (ExecutionClient for process status reporting) and the logging subsystem (Logger from Log and Trace) AUTOSAR_AP_EXP_SWArchitecture p. 131.

Context diagram: Architectural embedding of the PHM daemon in interaction with supervised applications, State Management, Execution Management, watchdog, and IdsM. Sources: AUTOSAR_AP_SWS_PlatformHealthManagement p. 46, AUTOSAR_AP_SWS_PlatformHealthManagement p. 15, AUTOSAR_AP_EXP_SWArchitecture p. 131.

Instrumentation and Lifecycle of Supervised Entities

A logical supervision unit within a process is represented by the ara::phm::SupervisedEntity interface [SWS_PHM_01123]. Instantiation is performed explicitly by specifying a typed identifier of type ara::core::InstanceSpecifier, which references the configured port path in the system manifest AUTOSAR_TPS_ManifestSpecification p. 141. To protect instance integrity, the copy constructor and copy assignment operator are deleted ([SWS_PHM_01212], [SWS_PHM_01213]); however, instances may be moved ([SWS_PHM_01214], [SWS_PHM_01215]). During teardown, the destructor cleans up the entity [SWS_PHM_01211].

The instrumented software reports reaching defined program locations via the synchronous call ReportCheckpoint() [SWS_PHM_01127]. A typed checkpoint enumeration generated from the interface header serves as the parameter ([SWS_PHM_00424], [SWS_PHM_00425]). The PHM daemon verifies process authorization for every report; if a process not modeled in the manifest calls the method, an access violation is detected [SWS_PHM_01127]. In the case of security-critical anomalies, PHM can forward the access violation to the Intrusion Detection System Manager (IdsM) AUTOSAR_AP_EXP_SWArchitecture p. 236.

The supervision of an entity can be controlled in a state-dependent manner at runtime: supervision is activated via Enable(), provided the current state of the associated Function Group permits this [SWS_PHM_01130]. Supervision can be suspended again using Disable() [SWS_PHM_01380]. Both methods return a ara::core::Future<void> and signal asynchronous deployment errors, for example PhmErrc::kServiceNotReady [SWS_PHM_01130].

Sequence diagram: Checkpoint reporting sequence via SupervisedEntity with access rights check and security monitoring by the IdsM. Sources: [SWS_PHM_01127], AUTOSAR_AP_EXP_SWArchitecture p. 236.

Supervision Types and Multi-Level Status Aggregation

Platform Health Management distinguishes three primary elementary supervision types ([SWS_PHM_01138], AUTOSAR_AP_EXP_SWArchitecture p. 128):

• Alive Supervision (kAliveSupervision): Checks whether cyclic program parts emit a configured minimum and maximum number of checkpoint reports within defined time windows AUTOSAR_FO_ASWS_HealthMonitoring p. 22.
• Deadline Supervision (kDeadlineSupervision): Monitors the execution duration between two checkpoints for adherence to configured minimum and maximum deadlines AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.
• Logical Supervision (kLogicalSupervision): Validates execution order based on a modeled transition graph in order to identify impermissible jumps or control flow branches AUTOSAR_AP_SWS_PlatformHealthManagement p. 15.

Each individual supervision possesses its own state machine for its elementary status (ElementarySupervisionStatus) [SWS_PHM_01358]. When PHM starts, all elementary state machines are initialized in state kDEACTIVATED and error counters are set to zero SWS_PlatformHealthManagement p. 31. After activation, the supervision transitions to kOK as long as all check criteria are fulfilled. If a violation occurs, the status transitions to kFailed [SWS_PHM_01358].

State diagram: State transitions of the elementary supervision (ElementarySupervisionStatus) from kDEACTIVATED via kOK to kFailed. Sources: [SWS_PHM_01358], SWS_PlatformHealthManagement p. 31.

Multiple elementary supervisions are combined into a superordinate global supervision SWS_PlatformHealthManagement p. 24. According to the specification, exactly one GlobalSupervisionStatus exists per configured Global Supervision, which is strictly bound to a single Function Group and must not span multiple Function Groups ([SWS_PHM_01137], SWS_PlatformHealthManagement p. 39). The global status aggregates the results via states kDEACTIVATED, kOK, kFAILED, kEXPIRED, and kSTOPPED AUTOSAR_AP_SWS_PlatformHealthManagement p. 39. State kOK requires that at least one associated supervision operates without errors and not a single one remains in an error state [SWS_PHM_01137].

State diagram: State model of the global supervision status (GlobalSupervisionStatus) with kDEACTIVATED, kOK, kFAILED, kEXPIRED, and kSTOPPED. Sources: [SWS_PHM_01137], AUTOSAR_AP_SWS_PlatformHealthManagement p. 39, SWS_PlatformHealthManagement p. 39.

Cyclic Watchdog Service and Hardware Safeguarding

To safeguard the operability of the entire computing unit against hangs or fatal system crashes, PHM connects the hardware-near watchdog subsystem via the apext::phm::WatchdogInterface interface [SWS_PHM_01255]. This native platform extension (Platform Extension) is not realized via service middleware, but executed as a deterministic native driver call AUTOSAR_AP_EXP_SWArchitecture p. 130.

In a configurable cycle, PHM internally checks all active supervision metrics and, if the overall status is positive, emits a keep-alive message to the watchdog via AliveNotification() ([SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233). If this message fails to arrive within the configured time window—for example, because the PHM daemon is blocked or a critical supervision fails—the watchdog interface autonomously initiates a hardware safety reaction [SWS_PHM_01255].

Sequence diagram: Periodic evaluation of supervision results and alive signaling to the watchdog interface. Sources: [SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture p. 233, AUTOSAR_AP_EXP_SWArchitecture p. 130.

Coordination of Recovery Actions with State Management

If PHM detects a violation of supervision conditions, it does not initiate error recovery autonomously, but delegates the action to State Management as the central regulatory authority (AUTOSAR_AP_EXP_SWArchitecture p. 129, AUTOSAR_AP_EXP_SWArchitecture p. 220). This decoupling preserves the architectural principle that decisions regarding functional system states and process restarts remain with State Management AUTOSAR_AP_SWS_StateManagement p. 28.

State Management registers its readiness for error handling via the port interface ara::phm::RecoveryAction [SWS_PHM_01141]. Receipt of error reports is armed by calling Offer() [SWS_PHM_01143]; State Management can deactivate service readiness again using StopOffer() [SWS_PHM_01144]. To rule out fatal race conditions and undefined behavior caused by premature callback invocation prior to complete construction of derived classes, copy and move operations for RecoveryAction are explicitly prevented ([SWS_PHM_01149], [SWS_PHM_01150], [SWS_PHM_01151], [SWS_PHM_01152]).

In the event of an error, PHM calls the pure virtual callback function RecoveryHandler() of State Management, passing the error event ara::exec::ExecutionErrorEvent as well as the type of violated supervision TypeOfSupervision [SWS_PHM_01142]. State Management then determines the subsequent state of the Function Group and causes Execution Management to change state or restart affected processes (AUTOSAR_AP_EXP_SWArchitecture p. 169, AUTOSAR_AP_EXP_SWArchitecture p. 220).

Sequence diagram: Error escalation to State Management via the RecoveryHandler with branching to watchdog triggering in the event of an error. Sources: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 234, AUTOSAR_AP_EXP_SWArchitecture p. 220, AUTOSAR_AP_EXP_SWArchitecture p. 220.

Behavior in the Event of an Error and Multi-Level Escalation Paths

Platform Health Management implements a graduated escalation strategy for controlling runtime errors AUTOSAR_AP_EXP_SWArchitecture p. 200. If a supervision error occurs, the primary path is followed first: the supervision reports the error to State Management, which performs a controlled reconfiguration via RecoveryHandler() [SWS_PHM_01142].

If State Management cannot execute the recovery (for example, acknowledged with error code PhmErrc::kSMCanNotHandleRecovery) or the response times out, the secondary escalation path takes effect ([SWS_PHM_01240], AUTOSAR_AP_EXP_SWArchitecture p. 220). In this case, PHM bypasses the software level and forces an immediate hardware-near emergency reaction (system reset or transition to safe state) via FireWatchdogReaction() ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture p. 201).

Failure of the central platform daemons themselves is particularly critical: if Execution Management or State Management fails, coordinated recovery at the operating system level is no longer possible (AUTOSAR_AP_EXP_SWArchitecture p. 235, AUTOSAR_AP_EXP_SWArchitecture p. 235). PHM detects this state via erroneous or missing checkpoints from these daemons and triggers the watchdog reaction without delay [SWS_PHM_01256].

All error situations in the C++ API are typed via the error domain ara::phm::PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]). The error codes are summarized in the enum PhmErrc ([SWS_PHM_01240], [SWS_PHM_01245]). For synchronous interfaces and exceptions, helper functions such as MakeErrorCode() [SWS_PHM_01244] and the exception type PhmException are available ([SWS_PHM_01243], [SWS_PHM_01250]).

Manifest Modeling, ID Synchronization, and Instantiation

The correct linkage between application code and the PHM daemon is based on strict ID synchronization in the AUTOSAR manifest AUTOSAR_AP_TPS_ManifestSpecification p. 566. In application design, the entity is modeled as a PhmSupervisedEntityInterface with aggregated PhmCheckpoint elements AUTOSAR_AP_TPS_ManifestSpecification p. 208. For deployment at the machine level, a SupervisionCheckpoint is generated per process instance, resolving the instance reference to the port and the execution context (Process) TPS_ManifestSpecification p. 568.

If the same software component type is instantiated multiple times—whether within the same process or across multiple processes—the manifest configuration generates a unique InstanceSpecifier for each port AUTOSAR_AP_SWS_PlatformHealthManagement p. 51. This allows the PHM daemon to unambiguously map identical checkpoint IDs from source code to the respective component instance and process identity AUTOSAR_AP_TPS_ManifestSpecification p. 566. Interpretation: Interprocess communication between application user space and the PHM daemon is likely optimized in an OS-specific manner (such as via shared memory or POSIX domain sockets), as the C++ class SupervisedEntity transparently encapsulates the transport details [SWS_PHM_01123]. Question (open)

On the error handling side, the manifest models RecoveryNotification elements assigned to a PPortPrototype of State Management AUTOSAR_AP_TPS_ManifestSpecification p. 587. A timeout value (recoveryNotificationTimeout) is also defined here, upon expiry of which error handling is classified as failed AUTOSAR_AP_TPS_ManifestSpecification p. 587.

Further detailed evidence

The binding normative definition of Platform Health Management in release R25-11 relies in particular on the following specification anchors:

• Core elements of supervision: [SWS_PHM_01123] and [SWS_PHM_01127] define the C++ class SupervisedEntity and the reporting mechanism ReportCheckpoint(); [SWS_PHM_01130] and [SWS_PHM_01380] govern activation and deactivation.
• State models: [SWS_PHM_01358] specifies the elementary states (kDEACTIVATED, kOK, kFailed); [SWS_PHM_01137] anchors global status aggregation per Function Group SWS_PlatformHealthManagement p. 39.
• Recovery and escalation: [SWS_PHM_01141], [SWS_PHM_01142], and [SWS_PHM_01143] control deployment and execution of the RecoveryHandler() in State Management; [SWS_PHM_01256] safeguards emergency escalation via hardware watchdog.
• Error domain and exceptions: [SWS_PHM_01240] introduces the error codes (PhmErrc), which are transported via PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]) and PhmException [SWS_PHM_01243].