class apext::phm::WatchdogInterface

As a platform extension, the class apext::phm::WatchdogInterface forms the interface between Platform Health Management and the physical hardware watchdog. During normal operation, the PHM cyclically notifies the interface via AliveNotification(), whereby the interface must independently trigger a watchdog reaction if the notification fails to arrive [SWS_PHM_01255]. In the event of critical system errors, the PHM can also directly force an error reaction of the watchdog hardware via FireWatchdogReaction() [SWS_PHM_01256]. As a key constraint, both methods are specified as thread-safe, but not exception-safe.

more ›

Context

In the Platform Health Management (PHM) of AUTOSAR Adaptive, the C++ class apext::phm::WatchdogInterface represents the interface to the physical watchdog hardware. As a platform extension (PlatformExtension), it does not represent a modeled AUTOSAR port interface, but serves as a vendor-specific bridge between the PHM service and the underlying hardware. The PHM monitors the execution of processes and platform components. To also reliably safeguard against a failure or blockage of the PHM itself, the WatchdogInterface connects the external or internal hardware monitoring. Via the method AliveNotification(), the PHM cyclically reports its functionality to the interface [SWS_PHM_01255]. If a critical system error occurs, the PHM can specifically request the hardware-side error reaction via the function FireWatchdogReaction() [SWS_PHM_01256].

Context diagram: Integration of the WatchdogInterface between PHM and hardware watchdog. Sources: [SWS_PHM_01255], [SWS_PHM_01256]

Lifecycle

Since apext::phm::WatchdogInterface functions as a platform extension, the instantiation of the interface implementation and the connection to the hardware driver are likely to occur in a platform-specific manner during the initialization of the PHM service. Question Q-c2235d5c87e0a675 (open) The lifetime of the instance is typically tied to the runtime of the PHM, so that no dynamic life cycle with multiple creation or destruction during platform operation is intended. Regarding concurrency, both interface functions AliveNotification() and FireWatchdogReaction() are explicitly declared as thread-safe (thread-safe) [SWS_PHM_01255], [SWS_PHM_01256]. This allows the PHM to pass keep-alive signals and error messages from different internal worker threads to the watchdog interface in parallel and without caller-side synchronization.

Usage Path

The typical interaction between the PHM and the interface is divided into the regular monitoring cycle and error escalation:

• Cyclic keep-alive reporting: The PHM calls AliveNotification() repeatedly within a configured cycle time [SWS_PHM_01255]. This cycle time does not have to match the real trigger period of the hardware; the implementation presumably buffers or scales the intervals internally for controlling the physical watchdog [SWS_PHM_01255]. Question Q-a6c08f102f09c8c1 (open)
• Hardware triggering: Given regular messages, the WatchdogInterface ensures timely servicing of the hardware watchdog unit.
• Targeted error indication: If the PHM detects an unrecoverable state in the monitored entities, it immediately calls FireWatchdogReaction() [SWS_PHM_01256].

Sequence diagram: Regular keep-alive transmission and triggering of the watchdog reaction. Sources: [SWS_PHM_01255], [SWS_PHM_01256]

Error Scenarios

The interface supports two complementary mechanisms for handling system failures:

On the one hand, a passive absence of messages leads to a system reaction: If the PHM does not report via AliveNotification() within the configured time span, the WatchdogInterface is obliged to autonomously initiate the watchdog reaction [SWS_PHM_01255]. In this way, crashes or deadlocks of the PHM service itself are reliably intercepted by the hardware.

On the other hand, the active error path exists: Via the explicit call to FireWatchdogReaction(), a defined error reaction of the watchdog is triggered [SWS_PHM_01256]. In both cases, the final effect at system level is likely to typically consist of a hardware reset or a transition into a safe state. Question Q-817baa072cc94a19 (open)

Regarding the error behavior in code, both member functions are specified as not exception-safe (not exception safe) [SWS_PHM_01255], [SWS_PHM_01256]. The calling component can therefore rely on no exception handling guarantees, and the implementation of the interface must not emit any unhandled C++ exceptions.