Safe API Framework
Layered API framework for safety-related applications (ERTMS RBC reference targeting CENELEC EN 50128 SIL 4)
Loading...
Searching...
No Matches
Reboot Module - Architecture

Design Overview

  • Minimal layer providing single entry point: sapi_reboot_request(reason).
  • Integrator registers platform-specific backend via sapi_reboot_register_backend().
  • No dynamic allocation; single backend pointer storage.

Public API

  • * sapi_status_t sapi_reboot_request(uint16_t reason_code);
    *
  • Requests controlled system restart. Does not return on success (CPU resets).
  • * sapi_status_t sapi_reboot_register_backend(const sapi_reboot_backend_t *backend);
    *
  • Registers platform-specific reboot implementation. Called at startup.

Backend Interface

  • * typedef struct {
    * sapi_status_t (*request)(uint16_t reason_code);
    * } sapi_reboot_backend_t;
    *
  • Backend implements platform-specific reset mechanism:
  • - Trigger hardware watchdog
  • - Execute CPU reset instruction
  • - Send command to supervisory processor
  • - etc.

Reboot Flow

  •  * sapi_reboot_request(reason)
 *     │
 *     └─ Retrieve registered backend
 *        ├─ If no backend: return NOT_INITIALIZED
 *        └─ If has backend: call backend->request(reason)
 *               │
 *               ├─ On success: CPU resets (no return)
 *               └─ On failure: return error code
 *

Reason Code Handling

  • 16-bit reason code identifies why reboot requested. Backend can:
  • - Log to syslog
  • - Persist to NVM/flash (black box)
  • - Send to supervisory processor
  • - Use in post-reboot diagnostics
  • Reason code is backend-interpreted; framework defines none.

Resource Model

  • Single static backend pointer. No allocation. Minimal state:
  •  * backend_ptr: NULL or pointer to sapi_reboot_backend_t
 *

MISRA Compliance

  • ✓ No dynamic allocation
  • ✓ Single responsibility (request only)
  • ✓ Function pointer via struct (vtable pattern)
  • ✓ No global function pointers

See Also