As in-cabin systems become more sophisticated, demonstrating functional safety is no longer just about meeting compliance requirements.
Modern software-defined vehicle architectures demand safety to be built into the platform from the very beginning, with careful attention to partitioning, isolation, verification and traceability. In this interview, Ofra Bechor, Regional Field Application Engineer at Green Hills Software, explains the architectural principles behind safety-certified in-cabin systems, the realities of ISO 26262 assessment, and how development teams can reduce certification effort while building scalable, future-ready platforms.
1. What are the most common misconceptions about ISO 26262 compliance?
Perhaps the biggest misconception is that ISO 26262 is primarily a documentation exercise. In reality, documentation is simply the visible outcome of sound engineering decisions that should have been made much earlier in the development lifecycle. If safety considerations are not built into the system architecture from the start, it is impossible to compensate later through additional analysis or paperwork.
Another common misconception is that using safety-certified software components automatically makes the complete system compliant. While certified operating systems, software components, and development tools can significantly reduce development efforts and provide supporting safety evidence, ISO 26262 ultimately assesses the safety of the complete system. Integrators must still demonstrate that the overall system architecture, safety mechanisms, assumptions of use, and verification activities collectively satisfy the applicable safety goals.
Finally, many organizations still work in silos, with hardware and software development being decoupled for most of the development cycles. However, modern in-cabin platforms integrate hardware, operating systems, middleware, applications, and virtualization technologies on shared multicore devices. Functional safety is therefore a true system engineering challenge that depends on architectural decisions, particularly around partitioning, resource isolation, and deterministic behavior, made from the very beginning of the project.
2. How does software complexity impact safety certification?
Software complexity has always driven verification effort, but today’s integrated in-cabin platforms add a significant new dimension: applications with widely different criticality levels now share the same processors, memory, and communication infrastructure.
The challenge extends beyond verifying individual software components; teams must also demonstrate that safety-related functions remain protected from faults originating in other parts of the system. This requires demonstrating that shared resources, communication paths, scheduling behavior, and fault containment and isolation mechanisms cannot compromise safety functions.
A well-designed software architecture can substantially reduce this burden. Clearly defined partitioning, deterministic behavior, controlled communication interfaces, and robust isolation mechanisms make system behavior far easier to analyze and verify. They also limit the number of interactions that need exhaustive examination during safety assessment.
In practice, certification effort grows less with the sheer number of software components and more with the complexity of their interactions. Managing those interactions through thoughtful architecture is typically far more effective (and efficient) than attempting to verify every possible behavior after implementation.
3. Which evidence is most difficult to generate during assessment?
The most challenging evidence is rarely a single test report or analysis document. More often, it is the ability to present a complete, consistent, and coherent safety argument across the entire development lifecycle.
Assessors expect clear traceability from hazards and safety goals through technical safety requirements, implementation, verification activities, and final validation. While producing the individual artifacts matters, demonstrating that they collectively support the intended safety case is where many projects face difficulties.
For modern in-cabin platforms, demonstrating freedom-from-interference is frequently one of the more demanding aspects. When safety-related and QM applications run on shared multicore hardware, teams must provide objective evidence that timing behavior, memory access, communication channels, and resource sharing cannot undermine the required safety functions. The effort required depends heavily on the strength of the underlying software architecture and the isolation mechanisms it provides.
Projects that treat traceability, verification planning, and evidence collection as integral parts of normal development, generally experience a smoother assessment than those that attempt to assemble the safety case at the end of the project.
4. How can development teams reduce certification effort?
The most effective way to reduce certification effort is to make safety an architectural design objective from the earliest stages of development, rather than something addressed primarily during the later stages of development. Early decisions on software partitioning, execution architecture, communication mechanisms, and system modularity largely determine the volume and complexity of evidence that will be required later.
Architectures that intrinsically separate safety-related and QM functionality simplify verification, integration, and future evolution. Development teams also benefit greatly from selecting software platforms and development environments designed for safety-oriented development. Capabilities such as strong partitioning, deterministic real-time behavior, secure virtualization technologies, and comprehensive safety documentation can significantly simplify both engineering activities and the construction of the safety case.
Equally important are development workflows that maintain continuous traceability between requirements, implementation, verification, and validation throughout the project.
A significant opportunity lies in designing for reuse. By developing software elements with well-defined assumptions of use, modular integration, and reusable safety artifacts, organizations can build on previous certification work instead of starting from scratch for every new vehicle program. As software-defined vehicles grow in complexity, this architectural approach becomes essential for achieving both scalability and certification efficiency. Ultimately, successful ISO 26262 projects are distinguished not by producing more safety evidence, but by establishing architectures and engineering workflows in which the required evidence is generated naturally as part of the development process.
Interested in exterior vehicle sensing technology?
With a pass to InCabin Europe, you’ll also get full access to our
co-located sister event, AutoSens. Find out more here >>
