Temporal Safety and Deadline Monitoring

1. The Criticality of Time: Temporal Safety and FTTI

In a real-time system, a logically correct result delivered too late is a wrong result. Temporal safety is the property that ensures a system's actions and reactions are performed within their specified timing constraints. A failure to do so is a timing fault.

ISO 26262 provides a formal framework for thinking about this. Let's start with a key reading on the fault models associated with timing.

As the document explains, faults like blocking, deadlocks, and incorrect execution time can prevent a safety-critical function from completing on time. This leads to a crucial question: how much time do we have to handle a fault before something catastrophic happens?

ISO 26262 defines two key intervals for this:

• Fault Tolerant Time Interval (FTTI): The time span from a fault's occurrence to the potential occurrence of a hazardous event if a safety mechanism doesn't intervene.
• Fault Handling Time Interval (FHTI): The time a system has to detect the fault and transition to a safe state.

Crucially, FHTI must be less than FTTI. The following video explains this relationship clearly.

2. Mechanisms for Ensuring Temporal Safety

To ensure the FHTI is met, we need mechanisms to detect timing faults. These exist at different levels of the system. In an AUTOSAR context, which you are familiar with, these include:

• OS-Level Timing Protection: The OS can monitor task execution time, the time resources are locked, and the arrival rate of interrupts.
• Program Flow Monitoring: The AUTOSAR Watchdog Manager (WdgM) supervises the execution flow of software components, checking not just that they are running, but that they are executing correctly and on time.

Let's briefly review the OS-level protections before diving deep into program flow monitoring.

While OS protection is powerful, we will focus on Program Flow Monitoring, as it's a technique you can implement and manage directly within your driver and application logic. The primary mechanisms are:

1. Alive Supervision: Checks if a periodic task is running (i.e., "alive"). It's like a heartbeat monitor.
2. Deadline Supervision: Checks if a code segment between two points executes within a minimum and maximum time limit. This is ideal for aperiodic or event-driven tasks.
3. Logical Supervision: Checks if the execution path follows a valid sequence (e.g., block A is always followed by B or C, but never D).

3. Deep Dive: Deadline Supervision

Deadline supervision is particularly important for handling event-triggered functions, which are common in driver development (e.g., "process this received CAN message," "handle this SPI transfer completion interrupt"). You don't know when they will run, but you know how long they should take once they start.

The core concept is to place checkpoints in your code:

• A start checkpoint at the beginning of the critical section.
• An end checkpoint at the end of the critical section.

A monitoring entity, like the Watchdog Manager, measures the time elapsed between these two checkpoints and validates it against a configured [min_time, max_time] window.

The following video does an excellent job of distinguishing between alive and deadline supervision.

4. Implementing a Simple Deadline Monitor

To solidify the concept, let's implement a simple deadline monitor in C. This will demonstrate the core logic that a full-fledged system like the AUTOSAR WdgM abstracts away. We'll assume the existence of a function get_timestamp_us() that returns a microsecond-based timestamp from a hardware timer.

Our monitor will have a simple state machine for each supervised entity: IDLE, RUNNING, PASSED, FAILED.

#include <stdint.h>
#include <stdbool.h>

// Assume this function is provided by a hardware timer driver (e.g., SysTick).
extern uint32_t get_timestamp_us(void); 

typedef enum {
    MONITOR_STATUS_IDLE,
    MONITOR_STATUS_RUNNING,
    MONITOR_STATUS_PASSED,
    MONITOR_STATUS_FAILED_MIN, // Failed: finished too fast
    MONITOR_STATUS_FAILED_MAX, // Failed: finished too slow
    MONITOR_STATUS_FAILED_TIMEOUT // Failed: never finished
} deadline_status_t;

typedef struct {
    uint32_t min_us;
    uint32_t max_us;
    uint32_t start_time_us;
    deadline_status_t status;
} deadline_monitor_t;

/**
 * @brief Starts the deadline monitoring for a specific task.
 * @param monitor Pointer to the monitor instance for the task.
 */
void deadline_monitor_start(deadline_monitor_t* monitor) {
    monitor->start_time_us = get_timestamp_us();
    monitor->status = MONITOR_STATUS_RUNNING;
}

/**
 * @brief Ends the deadline monitoring and checks timing constraints.
 * @param monitor Pointer to the monitor instance for the task.
 */
void deadline_monitor_end(deadline_monitor_t* monitor) {
    if (monitor->status != MONITOR_STATUS_RUNNING) {
        // Cannot end a monitor that isn't running.
        return;
    }

    uint32_t end_time_us = get_timestamp_us();
    uint32_t execution_time_us = end_time_us - monitor->start_time_us; // Assumes no timer overflow for simplicity

    if (execution_time_us < monitor->min_us) {
        monitor->status = MONITOR_STATUS_FAILED_MIN;
    } else if (execution_time_us > monitor->max_us) {
        monitor->status = MONITOR_STATUS_FAILED_MAX;
    } else {
        monitor->status = MONITOR_STATUS_PASSED;
    }
}

/**
 * @brief Supervisor function to check for timeouts.
 * Should be called periodically by a low-priority task.
 * @param monitor Pointer to the monitor instance to check.
 */
void deadline_monitor_check_timeout(deadline_monitor_t* monitor) {
    if (monitor->status != MONITOR_STATUS_RUNNING) {
        return; // Only check running tasks
    }
    
    uint32_t current_time_us = get_timestamp_us();
    if ((current_time_us - monitor->start_time_us) > monitor->max_us) {
        monitor->status = MONITOR_STATUS_FAILED_TIMEOUT;
    }
}

// Example usage:
void process_critical_event(void) {
    static deadline_monitor_t my_monitor = {
        .min_us = 100,  // Should take at least 100 us
        .max_us = 500,  // Should take no more than 500 us
        .status = MONITOR_STATUS_IDLE
    };

    deadline_monitor_start(&my_monitor);

    // ... critical event processing code ...

    deadline_monitor_end(&my_monitor);

    if (my_monitor.status != MONITOR_STATUS_PASSED) {
        // Fault detected! Take action (e.g., report to DEM).
    }
}

5. Connecting to AUTOSAR WdgM

Your experience is in AUTOSAR, so let's map our simple implementation to the real world. The AUTOSAR Watchdog Manager provides a standardized service for exactly this purpose.

The key AUTOSAR elements are:

• WdgM_SupervisedEntity: The task or runnable being monitored.
• WdgM_Checkpoint: Points in the code, analogous to where we called our start and end functions.
• WdgM_CheckpointReached(SEID, CheckpointID): The function your code calls to signal passing a checkpoint.
• WdgM_MainFunction(): The periodic supervisor function, analogous to our deadline_monitor_check_timeout. It checks all active supervisions.
• Configuration: You define WdgMDeadlineMin and WdgMDeadlineMax for a transition between two checkpoints in the ARXML configuration.

The following document provides the official specification. It's dense, but browsing it will show you the real-world equivalent of the code we just wrote.

6. Advanced Topic: Determining Deadline Values

An obvious interview question is: "How do you choose the values for min_us and max_us?"
The maximum value should not be arbitrary. It should be based on a Worst-Case Execution Time (WCET) analysis of the code block being monitored. WCET analysis uses static code analysis, control flow graph analysis, and models of the processor architecture to calculate the longest possible execution path.

The minimum value is used to detect cases where the code finished too quickly, which might indicate an error path was taken or a calculation was skipped. It's often determined empirically or through analysis of the function's expected best-case execution.

Conclusion

In this lesson, we have moved from spatial to temporal safety, understanding its critical role in functional safety. You can now explain what temporal safety is, why it's necessary (FTTI/FHTI), and how to implement a key mechanism—deadline monitoring—to enforce it.

Key Takeaways:

• Temporal Safety ensures tasks execute within their specified timing constraints. Failures to do so are timing faults (e.g., blocking, deadlock).
• Deadline Monitoring is a program flow monitoring technique used to supervise aperiodic or event-driven tasks by measuring the time between a start and end checkpoint.
• A robust implementation must check for three conditions: execution that is too fast (underflow), too slow but finishes (overflow), or never finishes (timeout).
• The timeout check requires a separate, periodic supervisor entity that runs independently of the monitored task.
• In AUTOSAR, this is handled by the Watchdog Manager (WdgM) service, using WdgM_CheckpointReached calls and the periodic WdgM_MainFunction.
• Deadline values should be determined methodically, with the maximum value often derived from WCET analysis.

Next Lesson Preview

Detecting a fault is only half the battle. The system must then be notified so it can take corrective action. In our next lesson, we will integrate a driver with the AUTOSAR Development Error Tracer (DET) module for runtime fault reporting. This provides the standardized mechanism for reporting the MONITOR_STATUS_FAILED conditions we designed today to the rest of the system.