Safe API Framework
Layered API framework for safety-related applications (ERTMS RBC reference targeting CENELEC EN 50128 SIL 4)
Toggle main menu visibility
Loading...
Searching...
No Matches
System Architecture Overview
Layering
The framework is organized in three layers. Applications only ever call
into SAPI - never directly into the OS/RTOS - so retargeting to a
different platform means registering a different backend (ADR-005), not
rewriting application code.
-#
OS Abstraction Layer (OAL)
- one service per OS/RTOS primitive:
Timer Service
,
Non-Volatile Memory
,
Static Memory Reservation
,
Task/Thread Scheduling
,
Inter-Process Communication
,
Point-to-Point Network Link
,
Logging and Diagnostics
,
Controlled Reboot
. Every service validates parameters, then
dispatches to an integrator-supplied backend (ADR-005); the framework
itself ships no OS-specific code.
-#
Common utilities
- layer-agnostic building blocks with no OS
dependency:
Cross-Layer Data Buffer
,
Bounded String Manipulation
,
Checked Integer Casting
,
Common Types
,
Common Status and Error Codes
,
Safe-State Transitions and Checked Assertions
.
-#
Redundancy / vital communication
- built on top of the first two
layers:
Channel Link (single redundant link)
(one point-to-point redundant link),
Voter (N-way channel voting)
(N-way 2oo2/2oo3/NMR voting across registered
Channel Link (single redundant link)
instances),
Cross-Comparator (2-way channel comparison)
(2-way
consistency check between two independent peer channels, ADR-025),
Checkpoint Rendezvous
(bounded checkpoint-ID rendezvous for cross-node
agreement),
Clock Synchronization (diagnostic/timeout-sizing only)
(diagnostic-only wall-clock offset,
never a correctness dependency),
Checksum & CRC Utilities
(CRC-64 data
integrity), and
Watchdog Mechanism
(hang detection and recovery,
including SAPI_WATCHDOG_ACTION_FAILOVER for redundant-peer-loss
reactions).
Application Manager
sits above all three layers, giving an application a
single init/execute/shutdown lifecycle entry point.
Common-Cause-Failure Mitigation
For SIL 3/4 dual-channel deployments, ADR-008 covers build-diversity
mitigation (two independently-configured toolchains compiling channel A
and channel B);
Cross-Comparator (2-way channel comparison)
(ADR-025) is the framework
primitive that answers "do channel A's and channel B's results agree?"
for exactly that kind of independent peer pair - it supersedes the
ADR-008-era standalone comparator module, which was never built and has
since been removed outright.
Where to Go Next
- Getting started integrating a backend:
App Manager Integration with Channels
- Per-module architecture and user guides: see the "Related Pages" list
(each module under
include/safeapi/<module>/
ships an
ARCHITECTURE.md and USER_GUIDE.md pair).
- IPC transport choice:
IPC Transport Selection Guide
,
Channel Configuration Guide
- Channel topologies:
Channel Topologies and Redundancy Patterns
- Architecture Decision Records (design rationale, one per major
decision):
docs/architecture/ADR-*.md
- Requirements traceability:
Software Requirements Specification (SRS)
- MISRA C:2012 conformance status:
docs/MISRA_COMPLIANCE_REPORT.md
- Cross-compilation (Linux, QNX, etc.):
docs/CROSS_COMPILATION.md
*/
Generated by
1.18.0