Стандарт ISO 26262-11: как архитектурные решения и автоматизация снижают риски разработки безопасных чипов

The most challenging aspect of functional safety isn’t achieving certification. It’s making the architectural decisions that determine whether compliance will be straightforward or painful, long before the first line of RTL is written. ISO 26262 Part 11 provides semiconductor-specific guidance to help architects make those decisions, while showing how modern SoC architecture and automation can reduce development risk. What Part 11 covers ISO 26262 Part 11 translates the broader functional safety framework into guidance for semiconductor development. It covers topics that include semiconductor technologies, hardware architectural considerations, random hardware failures, diagnostic coverage, safety mechanisms, assumptions of use, and the information required to support a complete functional safety case. Unlike vehicle manufacturers or Tier 1 suppliers, semiconductor companies rarely develop the final safety-critical system. Instead, they provide a key building block that is integrated into a much larger automotive platform. Part 11 recognizes this shared responsibility by guiding semiconductor suppliers on how to communicate with downstream customers, including the assumptions made during device development, the intended operating conditions, available diagnostic capabilities, and limitations that system integrators need to consider. As a result, functional safety extends well beyond the silicon itself. Clear documentation, end-to-end traceability, and consistent communication become just as important as hardware implementation. These artifacts provide evidence that OEMs and Tier 1 suppliers need to understand how the device was developed and how it should be integrated into their own safety architectures. Part 11, therefore, encourages semiconductor suppliers to define operating assumptions, document the safety mechanisms implemented, identify safety-related constraints, and provide supporting evidence that downstream customers can incorporate into their own safety cases. By establishing a common framework for exchanging this information, the standard helps improve collaboration across the automotive supply chain while reducing ambiguity during system integration and functional safety assessments. Why ISO 26262 Part 11 matters now Automotive semiconductors are changing faster than almost any other class of integrated circuit. Software-defined vehicles, AI-assisted driving, centralized compute architectures, and heterogeneous SoCs have dramatically increased design complexity. As a result, the interconnect fabric is moving more data than ever, more IP blocks must work together correctly, and safety requirements extend across every subsystem. This means functional safety is no longer a verification exercise performed near tape-out, but an architectural discipline that influences decisions from the first system diagrams onward. The guidance in ISO 26262 Part 11 is designed to help bridge the gap between high-level vehicle safety goals and practical silicon implementation. Rather than introducing entirely new concepts, it explains how the broader ISO 26262 framework applies to semiconductor development, helping architects think systematically about safety mechanisms, assumptions of use, documentation, and evidence throughout the development lifecycle. This is increasingly important because automotive customers expect silicon suppliers to provide not only high-performance devices, but also the information needed to integrate them safely into complete vehicle systems. Teams that consider these requirements early generally avoid expensive redesigns and simplify later certification processes. Early collaboration between architecture, safety, verification, and software teams helps align assumptions, reduce rework, and ensure that safety objectives remain visible throughout the project. As automotive devices become increasingly AI-enabled and heterogeneous, these cross-functional conversations become even more valuable. Building functional safety into the architecture Architecting a modern automotive SoC is an exercise in balancing competing priorities. Performance, power, area, cost, security, and functional safety must all be optimized simultaneously, often with decisions that improve one objective while affecting another. Incorporating redundancy, parity, or error-correcting codes (ECC), fault detection, safety islands, lockstep processing, and system monitoring all contribute to achieving functional safety goals, but they also consume valuable silicon resources. Striking the right balance requires careful architectural planning from the outset. Those early decisions have far-reaching consequences. Choices around NoC topology, memory hierarchy, IP integration, and data movement influence how faults are detected, contained, and prevented from propagating across the system. When these considerations are addressed early, safety mechanisms can be integrated naturally into the design rather than layered on as an afterthought. This is why functional safety is fundamentally an architectural challenge, not simply a verification exercise. Interconnect design, subsystem partitioning, traceability, verification planning, and IP selection all shape the effectiveness of a safety strategy. A well-planned architecture and a structured design process not only strengthen fault detection and diagnostic coverage but also simplify verification, reduce downstream complexity, and create a more efficient path toward ISO 26262 compliance and certification. Reducing development risk through automation As automotive SoCs continue to grow in complexity, manual development processes become increasingly difficult to sustain. Register maps, RTL, specifications, verification plans, and documentation must all remain synchronized throughout the design cycle, often across multiple engineering teams. Even small inconsistencies between these artifacts can create unnecessary rework, complicate safety assessments, and delay project schedules. Automation helps address these challenges by maintaining consistency across specifications, RTL, register maps, and documentation while reducing the potential for manual errors. Automated workflows also preserve traceability between requirements, design implementation, and verification activities, making it easier to demonstrate compliance and assemble the evidence required for functional safety assessments. As SoCs continue to scale in size and complexity, repeatable, automated processes become just as important as the underlying hardware technologies. Automation alone, however, is not enough. Successful functional safety programs also depend on close collaboration between architecture, functional safety, verification, hardware, and software teams from the earliest stages of development. Aligning assumptions, safety goals, and implementation strategies before detailed design begins helps reduce costly redesigns. It ensures that functional safety remains an integral part of the development process rather than a late-stage validation exercise. The need for this alignment grows as automotive devices incorporate AI accelerators, heterogeneous compute architectures, and increasingly sophisticated software stacks. When engineers work from a shared understanding of safety objectives and are supported by automated, traceable development workflows, they are better positioned to deliver designs that meet both performance goals and the rigorous requirements of ISO 26262. How Arteris supports ISO 26262 workflows Arteris approaches functional safety through both infrastructure IP and development automation. FlexGen® and FlexNoC® provide safety capabilities, documentation, and development processes intended to help customers implement ISO 26262-compliant systems efficiently. Ncore™ goes a step further by offering a cache-coherent interconnect with push-button ASIL safety-level selection and safety certification from Exida. The distinction is important: safety-ready IP gives customers flexibility to build and certify complete systems, while certified IP provides independently assessed evidence that can reduce qualification effort where appropriate. These approaches are designed to complement each other and, when combined with automation for system integration, register generation, and traceability, help engineering teams reduce development risk while supporting functional safety objectives. Practical takeaways for architects The most successful functional safety programs begin long before verification or certification. They start with architects asking the right questions at the outset of the project: - Where should faults be detected and contained? - Which safety mechanisms are needed to support the target ASIL? - How will data move safely between subsystems? - What assumptions will downstream customers need to understand when integrating the device into a larger vehicle platform? - Which development activities can be automated to improve consistency, maintain traceability, and reduce the potential for manual errors? Answering these questions early helps establish an architecture that supports both performance and functional safety while reducing the likelihood of costly redesigns later in the development cycle. It also creates a stronger foundation for verification, documentation, and collaboration with Tier 1 suppliers and OEMs throughout the safety lifecycle. The most important takeaway from ISO 26262 Part 11 is that functional safety should not be viewed as a compliance exercise. It is an architectural discipline that influences decisions across the entire SoC development process. Teams that use ISO 26262 Part 11 to make informed architectural decisions, supported by robust automation, clear documentation, and cross-functional collaboration, are better positioned to deliver safer automotive semiconductors while reducing development risk, simplifying certification efforts, and accelerating time-to-market.