Freedom From Interference, Built In: Memory Protection Arrives With Raptor 2026a

Melissa NewmanBlog, Commercial Vehicles, ECUs, Functional Safety, Passenger Vehicles, Raptor Software

Functional safety applications increasingly combine safety-critical (ASIL) and quality-managed (QM) software components on the same controller. This architecture can reduce hardware complexity and enable flexible system designs, but requires lower-criticality software to remain isolated from higher-criticality safety functions. 

ISO 26262 addresses this challenge through freedom from interference (FFI). Traditionally, development teams have designed, implemented, verified, and documented separation mechanisms themselves to prevent cascading failures. 

With Raptor 2026a, developers can use built-in operating system capabilities for mixed-ASIL architecture and functional safety development on supported RCM112 and CCM112 controllers. Integrated memory protection provides the foundation for software separation, eliminating the need to engineer and prove these mechanisms independently. 

Memory Protection, Explained 

Raptor 2026a introduces OS1, a new functional-safety-focused operating system configuration, a contrast to the fixed OS configuration of previous releases. OS1 adds isolation mechanisms needed for mixed-criticality functional safety applications, combining two key capabilities: hardware-level memory protection and protected tasks. 

Hardware-level memory protection monitors software access to defined memory regions and detects unauthorized reads or writes. When a violation occurs, the operating system is configured to shut down execution, preventing lower-criticality tasks from interfering with protected memory used by higher-criticality software. 

Protected tasks provide an additional layer of separation by allowing application functionality to execute within protected regions where separation is enforced by the operating system and hardware. 

Together, these features establish the foundation for building functionally safe applications that combine ASIL and QM software on the same controller. 

Partitioning for Mixed-Criticality Applications 

Memory protection is applied through software partitioning, where application components are separated according to their safety requirements. The guiding principle is simple: lower-criticality software cannot interfere with higher-criticality software. 

Raptor supports this architecture by separating QM and ASIL application content, reducing the risk of unintended data sharing and making partition boundaries explicit during development. Communication between partitions occurs through dedicated Partition Port Read and Partition Port Write blocks. 

These controlled interfaces maintain freedom from interference during data exchange, while the application remains responsible for validating transferred data before it’s used in safety-related functions. 

Choosing Between RCM112 and CCM112 

The RCM112 and CCM112 both provide memory protection and are developed using a MATLAB/Simulink-based workflow with Raptor-Dev. But their hardware capabilities address different application requirements. 

RCM112: I/O-Rich Control With Functional Safety Support 

The RCM112 is a general-purpose control module designed for applications requiring extensive integrated I/O from a single controller. It is well suited for applications that:

  • require rich I/O capability, including up to 30 analog inputs, 16 low-side drivers, 16 high-side drivers, and two H-bridges. 
  • have modest mixed-criticality separation requirements with fewer software partitions. 
  • require functional safety support using the HighTec compiler, while non-safety applications can use the free SPC5-STUDIO environment. 

CCM112: Advanced Safety-Critical and Fail-Operational Systems 

The CCM112 is designed for applications requiring advanced processing capability and the highest levels of functional safety. It features dual Infineon TriCore processors and a companion safety power system basis chip to support ASIL-D requirements. It is well suited for applications that: 

  • require strict ASIL-D functional safety or fail-operational operation. 
  • separate multiple software criticality levels on a single controller using up to five partitions (QM, A, B, C, D). 
  • require cybersecurity support. 
  • depend on high communication bandwidth. 
  • benefit from integrated timing and persistent data storage through the onboard real-time clock and external FRAM. 

In short, the RCM112 is optimized for general-purpose, I/O-rich control applications, while the CCM112 is designed for safety- and performance-critical systems requiring ASIL-D capability, multiple software partitions, redundancy, and cybersecurity support. 

Why Built-In Memory Protection Matters 

ISO 26262 allows safety-related and non-safety-related software components to run on the same controller, but requires that freedom from interference be demonstrated between components with different ASIL levels. Without appropriate separation, a failure in a lower ASIL component could cascade into a higher ASIL function and compromise a safety requirement. 

ISO 26262-6:7.4.8 states that when embedded software contains components with different ASIL levels, or safety-related and non-safety-related components, the software must be developed according to the highest ASIL unless the components meet the coexistence criteria defined in ISO 26262-9:2018, Clause 6. 

A more efficient approach is to develop each software component according to its allocated ASIL and establish the necessary separation mechanisms to support coexistence. 

The Challenge: Shared Memory 

Shared memory is a common source of potential interference between mixed-ASIL software components running on the same processor. A robust memory protection mechanism prevents unintended access between software components, helping eliminate cascading failures and support ISO 26262 freedom-from-interference requirements. 

But designing this mechanism is not a simple software feature. It requires design, implementation, verification, validation, and proof that the mechanism meets ISO 26262 requirements without compromising software timing or system performance. 

Freedom From Interference Through Integrated Memory Protection 

Raptor 2026a addresses this challenge by providing integrated memory protection as a platform-level safety mechanism. By enforcing memory access boundaries between software components, Raptor helps prevent failures in one component from propagating to another and supports mixed-ASIL architectures. 

Developing a memory protection scheme independently requires significant engineering effort beyond configuring processor features. Raptor 2026a reduces this complexity by providing an integrated approach to memory separation, allowing development teams to focus on application functionality rather than creating and proving the underlying protection architecture. 

Available Now in Raptor 2026a 

Raptor 2026a introduces functional safety capabilities for supported RCM112 and CCM112 targets, including memory protection and safety-focused blocks such as Partition Port Read, Partition Port Write, and Timed Trigger. 

For an introductory period, these functional safety capabilities—including memory protection—are included with an active Raptor-Dev subscription or 2026a maintenance coverage at no additional cost. This gives development teams the opportunity to evaluate memory protection in their own applications and see how it fits their functional safety workflows. Teams wanting more depth on Raptor for functional safety can contact New Eagle to learn more.