Arm FuSa RTS in Production: MPU Isolation, Thread Watchdogs, and Safety Class API for Indian Medical and Industrial Firmware

The marketing-facing version of Arm FuSa Run-Time System is “TÜV-certified safety run-time for Cortex-M”. The production-engineering version is a stack of patterns, MPU-based spatial isolation, thread-watchdog idioms, Safety Class API tagging, event-recorder telemetry: that turn a normal-looking RTOS firmware into something whose behaviour under fault conditions is provable, testable, and trustable enough to ship into a regulated product.

This is the working-with-FuSa-RTS deep-dive GSAS Micro Systems shares with Indian medical-device, industrial-controls, and railway-signalling firmware teams when they ask: “we have the FuSa Compiler and FuSa RTS licensed, now what does the day-to-day firmware look like?”

GSAS is Arm’s authorized partner in India for Arm Development Tools. The patterns below are the ones we walk customers through during the FuSa adoption engagement, drawing on Arm’s published safety-class application notes available to Arm customers on developer.arm.com.

What FuSa RTS gives you that a normal RTOS doesn’t

Three pieces matter day-to-day:

Component	What it does	Why it matters in a safety case
FuSa CMSIS-Core	Qualified Cortex-M startup, exception handlers, core-peripheral abstraction	The boundary between application code and silicon is itself qualified, assessors can take the boundary as evidence rather than re-qualifying it per project
FuSa RTX kernel	Qualified preemptive RTOS, same API as standard CMSIS-RTOS2 RTX5 with safety-class extensions	Threads, mutexes, semaphores, timers all qualified; you build your safety case on a qualified scheduler rather than a custom one
FuSa C library	Qualified standard-library replacement	string.h / stdlib.h / math.h functions used in safety-critical code are individually qualified rather than blanket-trusted
FuSa Event Recorder	Qualified runtime telemetry capture	Black-box-recorder-equivalent for fault-injection testing, post-deployment safety analysis, and ASIL-D evidence

For Indian medical-device firmware (IEC 62304 Class C) and industrial-controls firmware (IEC 61508 SIL 3), this stack lets the safety case argue “the run-time foundation is qualified evidence-supplied; we built the application on top of it”, rather than re-qualifying the run-time per project, which is multi-month effort.

Pattern 1: MPU-based spatial isolation between threads

The single most-asked-for production pattern. Cortex-M cores from M0+ onwards include a Memory Protection Unit (MPU); FuSa RTS provides the qualified API to use it for spatial isolation between RTOS threads: one thread’s memory access bug cannot corrupt another thread’s state, and the MPU enforces it at the hardware level.

The pattern in production firmware:

• Each safety-class thread gets its own MPU region map: its code, its data, its stack are individually MPU-protected from the rest of the system.
• Inter-thread communication happens through shared regions: explicit, audited shared-memory areas with read-only or write-only attributes per direction.
• Faulting code triggers an MPU fault: the FuSa RTS qualified fault handler captures the fault, records it, and either resets the safety-class thread or initiates a controlled shutdown depending on the safety policy.

This is the pattern an Indian medical-device firmware team uses to confidently say: “the diagnostic-display thread cannot, even under arbitrary application bug, modify the dose-control thread’s state, the MPU prevents it at the hardware level, and the FuSa RTS handler is qualified to detect and respond when it tries.”

For application-note depth, refer to Arm’s safety-class API and MPU-based spatial-isolation guidance published on developer.arm.com (Arm customer login required for the deeper documentation).

Pattern 2: Thread watchdog with explicit liveness contracts

The second most-asked-for pattern. Watchdogs are not new in embedded; what FuSa RTS adds is a per-thread liveness contract that’s qualified and integrates with the safety case.

The pattern:

• Every safety-class thread has an expected period and an expected response time declared at thread-creation.
• The thread “kicks” the watchdog at known points in its loop: the FuSa RTS API records the timestamp.
• The watchdog supervisor (a separate qualified thread) checks each safety-class thread’s last-kick timestamp on a tick: if any thread has missed its expected liveness window, the supervisor escalates.
• Escalation is configurable per thread: thread restart, application restart, controlled shutdown, or external watchdog hardware reset, depending on the safety-class fault response.

For an Indian railway-signalling firmware (EN 50716 SIL 4, the current railway-software standard, superseding EN 50128) the typical configuration: signal-decode thread has a 50 ms expected period and a 75 ms timeout; if the watchdog misses, the system resets to a known-safe state via a qualified shutdown sequence.

Pattern 3: Safety Class API tagging

The third pattern Indian customers ask about, and the one that’s least obvious from the docs. Within FuSa RTS, API calls are tagged with their safety class: calling a non-safety-class API from a safety-class thread is detectable at code-review time and at runtime via the event recorder.

The mechanism:

• Each FuSa RTS API has a Safety Class designation in its qualification documentation.
• The application’s safety design declares which threads are safety-class and which are non-safety-class.
• During code review, calls from safety-class threads to non-safety-class APIs are flagged.
• During runtime, the event recorder captures the call pattern; cross-class calls show up as anomalies in the safety-evidence trail.

This pattern is what makes the FuSa RTS qualification useful in a project-specific safety case. The RTS itself is qualified at the API level; you make the case for your firmware by showing that safety-class threads only call safety-class APIs and that the runtime event log corroborates the static-analysis claim.

Pattern 4: Fault-injection testing with the event recorder

The fourth pattern, used during development and qualification, not always in production. The FuSa Event Recorder is a qualified telemetry framework that captures every event in the qualified system: thread state changes, mutex acquisitions, system-call entries, fault events.

For Indian Tier-1 / Tier-2 ECU programmes, this is the foundation of fault-injection testing:

• During pre-release verification, the team injects faults (memory corruption, stack overflow, divide-by-zero, MPU violation) at controlled points.
• The event recorder captures the system response.
• The captured event log demonstrates that the safety-case fault response actually fires as designed.

For ASIL-D / SIL-3 / SIL-4 / Class-C evidence packages, the event-recorder-captured fault-injection traces are the strongest single piece of operational-correctness evidence the safety case carries.

The eight Cortex-M cores FuSa RTS supports

FuSa RTS is qualified across the eight publicly-supported Cortex-M cores:

Core	Typical Indian use
Cortex-M0	Lowest-power industrial sensors
Cortex-M0+	Indian medical-device class-A/B; IoT-edge with SysTick/MPU
Cortex-M3	Long-running automotive body controllers; established programmes
Cortex-M4	Motor-control with DSP extensions; industrial drives
Cortex-M7	High-performance Cortex-M; medical imaging, audio
Cortex-M23	Armv8-M baseline; security-aware safety designs
Cortex-M33	Armv8-M mainline; Indian Tier-1 next-gen ECUs
Cortex-M55	Armv8.1-M with Helium MVE; edge-AI safety designs

For Cortex-R lockstep designs the strategy is different, the application provides its own safety run-time directly on the qualified compiler, and the safety case argues against the lockstep silicon’s diagnostic coverage rather than against an OS-level qualified runtime. See STL vs DCLS vs Hybrid Mode for Indian ASIL-B / ASIL-D programmes for the Cortex-R safety story.

What this looks like in MDK Professional

For Indian customers running Keil MDK Professional, the most common entry point, the FuSa RTS integration is:

1. The FuSa RTS qualified library is added to the project via the CMSIS-Pack manager (cpackget).
2. The application code targets the FuSa CMSIS-Core APIs in place of the standard CMSIS-Core surface where safety-class behaviour matters. The API surface is mostly identical, with safety-class extensions at boundary points.
3. The build is tagged for safety qualification in the csolution.yml, the safety-class compiler invocation flags are recorded for the safety case audit trail.
4. The Event Recorder is configured for the safety class: production builds capture safety-relevant events into a circular buffer that survives reset; development builds stream events to the host via SystemView for live analysis.
5. The Safety Qualification Kit artefacts ship with the project: Safety Manual, Defect Report, Test Report, Development Process Report, and the project’s safety case references them by version.

For the AC6.16 LTS → AC6.22 LTS migration story (which affects the FuSa Compiler generation and the matching FuSa RTS qualification), see Planning the AC6.16 LTS → AC6.22 LTS Migration for Indian FuSa Programs.

Three Indian customer scenarios

Medical-device firmware (IEC 62304 Class C)

A typical Pune-based Indian medical-device team building an infusion pump or imaging-system controller on Cortex-M4 / M7. FuSa RTS provides the qualified RTOS scheduler; MPU isolation separates the dose-control thread from the diagnostic-display thread; thread watchdogs ensure liveness; the event recorder captures the fault-response trail for the IEC 62304 evidence package.

Industrial drives / motor control (IEC 61508 SIL 3)

A typical Hyderabad / Bengaluru industrial-controls team building a variable-frequency drive or robotic-arm controller on Cortex-M4 / M33. FuSa RTS handles the safety-class state machine; MPU isolation separates the safety-monitor thread from the user-interface thread; safety-class API tagging enforces that the safety state machine never calls non-safety-class APIs.

Railway signalling (EN 50716 SIL 4: supersedes EN 50128)

A typical Indian railway-signalling firmware team on Cortex-M0+ / M3 for trackside controllers, or Cortex-M33 for newer designs. FuSa RTS provides the foundation; the team layers EN 50716-specific patterns on top (deterministic execution, formal validation of state-machine transitions). Watchdog liveness contracts are particularly tight, railway-signalling SIL 4 systems typically run on 10–25 ms safety margins.

When to talk to GSAS

• Your Indian team is starting an IEC 62304 Class-C / IEC 61508 SIL-3 / EN 50716 SIL-4 / ISO 26262 ASIL-D programme on Cortex-M and you want guidance on the FuSa RTS integration.
• You have a working safety case but the next product line needs to share architecture; we help with cross-product safety-evidence reuse strategies.
• You’re scaling from a single Cortex-M4 ECU to a multi-product platform; we help size the FuSa RTS / FuSa Compiler / Safety Qualification Kit licensing across the product line.
• Your safety-evidence trail needs the event-recorder telemetry pattern shipped into production firmware; we have working integration patterns.

Talk to GSAS about your FuSa RTS adoption →

GSAS Micro Systems is Arm’s authorized engineering partner in India for the Arm tools family, across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR, and Visakhapatnam.