Critical status fallback during a Linux fault
If Linux stops responding, the last application frame may look normal even though the system is no longer healthy. This study explores detecting a failed health contract and returning the display to a defined real-time fallback with approved warnings and critical status information.

Intended outcome
Replace a stale application frame with an explicit fallback state
The real-time side would evaluate a narrow, project-defined Linux health contract. If that contract expires, it could select a known fallback frame instead of leaving an apparently healthy dashboard frozen on screen.
The fallback might present warning indicators and the last trustworthy status data available to the real-time domain. The exact indicators, priority, and restoration policy would be defined for the target product.
Proposed behavior
A project-defined operating sequence
- Healthy operation
Linux publishes the agreed heartbeat and state while the real-time side supervises timing and validity.
- Contract failure
A missed deadline, invalid state, or explicit fault crosses a project-defined threshold.
- Fallback presentation
The real-time display owner selects a known frame and shows only information available within the trusted fallback boundary.
- Controlled restoration
Linux output returns only after restart, health qualification, and UI readiness conditions have been satisfied.
Architecture
Responsibilities stay explicit
A versioned heartbeat and state contract defines what the real-time side can conclude about Linux health.
Only signals available and validated in the real-time domain can be used as current status during the fault.
The display switch, warning hierarchy, latching, acknowledgement, and recovery rules are part of the product integration.
Project inputs
Integration points to define and validate
- Heartbeat source, deadline, sequence counter, validity rules, and startup grace period.
- Signals available independently of Linux and their freshness guarantees.
- Fallback graphics, warning priority, latching, and operator acknowledgement.
- Watchdog ownership and any permitted Linux or system restart request.
- Rules for requalifying Linux and returning to the application frame.
- Fault injection, stale-data, reboot, and repeated recovery tests.
Assess the concept
Could this fit your platform?
Share the target SoC, display path, BSP, Linux UI stack, and the state or failure you need to make visible.


