Thank you for Subscribing to Semiconductor Review Weekly Brief
× 
Semi Conductor Review Weekly Brief
Be first to read the latest tech news, Industry Leader's Insights, and CIO interviews of medium and large enterprises exclusively from Semi Conductor Review
WITTENSTEIN high integrity systems Ltd. has been recognized by Semiconductor Review Magazine as the exclusive recipient of “Top Safety-Critical Real-Time Operating Systems 2026,” based on our proprietary methodology, reflecting its position in the industry, and is also named among “,” reflecting its broader leadership. This profile has been developed by the Semiconductor Review research and editorial team based on insights from an interview with Andrew Longhurst, Managing Director.
WITTENSTEIN high integrity systems Ltd.
Andrew Longhurst, Managing DirectorAs Software Defined Vehicles (SDVs) become increasingly dependent on multicore processors, architects must decide how best to use the available computing resources. Modern automotive SoCs often combine high-performance application processors, such as Arm Cortex-A53 clusters, with dedicated real-time and safety cores, such as the Cortex-R52. The architectural choice between symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) has a direct impact on system performance, timing determinism and certification effort.
How does Safety Before Silicon influence SMP vs AMP decisions?
In SDVs, key architectural decisions are increasingly made before software development begins. This "Safety Before Silicon" approach focuses on defining safety goals, software partitioning, and timing requirements early in the programme lifecycle.
One of the most important decisions is whether workloads should share processing resources through SMP or be partitioned using AMP. The answer can influence system determinism, freedom-from-interference analysis, and the effort required to build a safety case.
Throughput vs determinism: What are the trade-offs between SMP and AMP?
SMP is attractive because it simplifies software development. Applications do not need to be assigned to specific cores, and the operating system can dynamically balance workloads across all processors. This approach maximises utilization and can deliver excellent throughput with relatively little software redesign.
However, SMP systems share hardware resources, including caches, memory subsystems, peripherals and interconnects. Even when processor affinity is used, workloads can still interfere with one another through contention for these resources. As a result, worst-case execution times and response times can be more difficult to analyse and guarantee.
For applications such as networking, data processing, and user interfaces, this is often an acceptable trade-off because overall throughput is the primary objective.
AMP takes a different approach. By assigning critical software to dedicated cores, interference can be reduced and timing behaviour becomes more predictable. This allows tighter response-time guarantees and can simplify system analysis, making AMP particularly attractive for control functions and other hard real-time workloads. However, these benefits come at the cost of additional architectural effort, as communication between software partitions often requires explicit inter-core communication mechanisms.
-
The architectural choice between symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP) has a direct impact on system performance, timing determinism and certification effort.
An automotive example
A Cortex-A53 cluster running SMP may be ideal for infotainment, connectivity, AI and domain applications where throughput is important.
By contrast, a Cortex-R52 safety island is typically used for functions that require deterministic behaviour and strong freedom-from-interference characteristics.
Although the A53 cluster may process a greater overall workload, the R52 environment can often provide more tightly bounded response times.
For safety-critical software, guaranteeing when work completes is usually more important than maximising processor utilization.
Certification considerations
Architecture also affects certification. For automotive systems developed to ISO 26262, demonstrating freedom from interference and showing that timing requirements are consistently met can form an important part of the safety case.
When software is statically partitioned onto dedicated cores, resource ownership and fault-containment boundaries are generally easier to define. While SMP can certainly be used in safety-certified systems, additional analysis is often required to demonstrate that critical functions remain unaffected by competing workloads.
Conclusion
Neither SMP nor AMP is universally better. SMP is often the best choice when throughput and resource utilization are the primary goals. AMP is frequently preferred when deterministic response times, freedom from interference, and certification objectives take priority.
As SDV architectures become increasingly complex, making these decisions early can reduce project risk and simplify certification activities. Selecting a Real Time Operating System that supports the target architecture is equally important. SAFERTOS® supports a range of automotive and safety-focused processor architectures, helping developers implement these architectural choices while maintaining predictable real-time behaviour.
Putting Safety Before Silicon into practice
Learn how safety islands support safety before silicon design principles, helping developers build deterministic, mixed-criticality systems while simplifying functional safety certification. Download the white paper.
Reducing Certification Friction in Safety-Critical RTOS Selection
An RTOS decision can become costly long before licensing is signed if certification evidence arrives late or fails to match the software actually deployed. In embedded programs governed by standards such as ISO 26262, IEC 61508, DO-178C or IEC 62304, the operating system becomes part of the assurance argument rather than a replaceable software utility. Procurement therefore has to look past scheduling performance. The harder question is whether the RTOS can be incorporated into the target architecture without creating avoidable verification work or uncertainty during external assessment.
Certification readiness should be judged at the level of evidence, not the presence of a certificate alone. Buyers need to understand how requirements map to tests and whether the supplied artifacts match the processor and compiler combination used in production. Evidence that was generated for a nearby configuration can still leave engineering teams with additional justification work. Traceability and test coverage matter because an auditor is evaluating the software actually integrated into the product, not a generic kernel description. A usable evidence package should also expose assumptions and installation conditions clearly enough that engineers can complete integration records without reconstructing the supplier’s development argument.
Hardware fit deserves the same scrutiny. Processor families change quickly, yet a safety program may remain tied to a chosen device for years. An RTOS supplier should be able to port its kernel without altering the behavior that has already been established and verified. A clear separation between common kernel code and hardware-specific code can reduce the amount of software that must change when a new processor is introduced. The buyer should also examine how the supplier validates compiler output and how much regression testing follows each port.
Migration effort can quietly determine whether a technically suitable RTOS is practical. Engineering teams often prototype before formal safety development begins, which creates a handoff risk if the production kernel uses a very different programming model. A familiar API structure can limit rework, but compatibility claims deserve close examination. The important measure is the amount of code that must change and whether the supplier provides a controlled route into the safety version rather than leaving the development team to reinterpret the differences alone.
“Wittenstein High Integrity Systems’ SAFERTOS offering is delivered for the customer’s processor and compiler combination, backed by verification at the object-code level and 100 percent MC/DC coverage.”
Long product lives make supplier continuity another purchasing issue. Safety-related products can remain in service well beyond a normal software refresh cycle, while processors and toolchains may be revised during that period. Source-code access can reduce dependency on continued vendor intervention, though buyers should also examine the support model around certification questions. Technical assistance is useful, but direct help with safety evidence and integration can be more consequential when an audit exposes an unfamiliar requirement. Renewal terms should not become a hidden lock-in mechanism.
For programs where certification effort carries as much weight as kernel performance, Wittenstein High Integrity Systems warrants priority consideration. Its SAFERTOS offering is delivered for the customer’s processor and compiler combination, backed by verification at the object-code level and 100 percent MC/DC coverage. Its Design Assurance Pack provides the lifecycle evidence needed to support certification while processor- and compiler-specific verification reduces uncertainty around the deployed build. The migration path from FreeRTOS can also shorten the move from prototyping into formal development. Buyers that want a tightly evidenced RTOS and direct safety support should place Wittenstein High Integrity Systems near the top of the shortlist.
...Read more
This content is copyright protected
However, if you would like to share the information in this article, you may use the link below: