Rtos Patterns

RTOS Patterns for Medical Devices

Purpose

Provide safe RTOS usage patterns: task design, priorities, IPC, deadlines, priority inversion avoidance, and timing analysis for medical devices.

When to Apply

• RTOS-based firmware for safety-related functions.
• Designing task sets, IPC, or timing-sensitive features.

Requirements (testable)

1. Task Design: Each task has a defined purpose, period/deadline, and priority justified by safety impact. Rationale: predictability.
2. Priority Assignment: Higher priority for safety-critical/timing-critical tasks; avoid priority inversion; document scheme. Rationale: timely execution.
3. IPC Discipline: Use bounded queues; validate message sizes; avoid blocking indefinitely; check return codes. Rationale: robustness.
4. Synchronization: Use mutexes with priority inheritance/ceiling; avoid holding locks in high-priority tasks; no blocking in ISRs. Rationale: avoid inversion/deadlocks.
5. Deadline Handling: Monitor execution times; detect overruns; degrade or go safe on sustained misses. Rationale: meeting safety timing.
6. Stack Sizing: Size stacks with margin based on analysis/measurement; enable stack overflow detection where available. Rationale: prevent corruption.
7. Timing Analysis: Perform schedulability or worst-case response analysis for critical tasks; revisit on changes. Rationale: timing assurance.

Recommended Practices

• Use deferred interrupt handling (ISR signals a task).
• Keep IPC schemas versioned; include length and CRC.
• Avoid dynamic memory for queues in safety paths; statically allocate.
• Instrument runtime (e.g., trace hooks) to measure execution and latency.

Patterns

Deferred ISR work:

// REQ-RTOS-ISR-01; TEST-RTOS-03
static SemaphoreHandle_t data_sem;
void UART_IRQHandler(void) {
    BaseType_t hpw = pdFALSE;
    clear_irq();
    xSemaphoreGiveFromISR(data_sem, &hpw);
    portYIELD_FROM_ISR(hpw);
}

Bounded queue send with timeout:

// REQ-RTOS-IPC-02; TEST-RTOS-05
bool send_cmd(cmd_t *cmd) {
    return xQueueSend(cmd_queue, cmd, pdMS_TO_TICKS(10)) == pdPASS;
}

Deadline monitor:

// REQ-RTOS-TIME-04; TEST-RTOS-09
void vTaskControl(void *arg) {
    for (;;) {
        TickType_t start = xTaskGetTickCount();
        run_control_loop();
        if (xTaskGetTickCount() - start > pdMS_TO_TICKS(5)) {
            log_overrun();
            enter_safe_state();
        }
        vTaskDelayUntil(&start, pdMS_TO_TICKS(10));
    }
}

Anti-Patterns (risks)

• Same priority for critical and non-critical tasks -> risk: starvation or jitter.
• Blocking calls without timeout in control tasks -> risk: deadlock/hang.
• ISRs doing heavy work or taking mutexes -> risk: latency, inversion.
• Unbounded queues or unchecked send/recv -> risk: overflow, data loss.
• Ignoring stack usage -> risk: silent corruption.

Verification Checklist

• Task priorities/periods documented and justified; critical tasks highest feasible.
• IPC uses bounded queues; timeouts set; return codes checked.
• Mutexes with PI/ceiling; no blocking in ISRs; lock durations minimized.
• Deadline/overrun monitoring implemented for critical tasks.
• Stack sizes analyzed/measured; overflow detection enabled.
• Timing/schedulability reviewed after changes to tasks or priorities.

Traceability

• Map REQ-RTOS-### to tasks and tests (TEST-RTOS-###); record timing evidence.

References

• FreeRTOS, Zephyr, ThreadX safety notes (vendor safety manuals if available).
• IEC 62304 timing and segregation considerations.
• ISO 14971 risk basis for timing failures.

Changelog

• 1.0.0 (2026-01-04): Initial RTOS patterns with priority, IPC, deadline, and stack guidance.

Audit History

• 2026-01-04: Audit performed. Verified:
  • FreeRTOS API examples are accurate (xSemaphoreGiveFromISR, portYIELD_FROM_ISR, xQueueSend, etc.)
  • Priority inversion concepts correctly explained
  • Deadline monitoring patterns technically sound