SEooC: Safety Element Out of Context (ISO 26262) Explained

Hello, automotive safety engineers, semiconductor developers, and AUTOSAR software engineers! If you work for a microcontroller supplier, an RTOS vendor, an AUTOSAR stack provider, or any organization that develops components intended for use across multiple vehicle platforms and OEM customers, then SEooC (Safety Element out of Context) is one of the most important concepts in ISO 26262 that you need to master.

In this comprehensive practical guide at PiEmbSysTech, we will explain what SEooC is, why it exists, how it differs from “in-context” development, how to formulate assumptions of use, how to develop and document an SEooC, what goes into the safety manual, and how the integration process works – all with real-world examples from microcontrollers, AUTOSAR software, and sensor ICs. Let us begin.

1. What is SEooC? – Definition and Core Concept

A Safety Element out of Context (SEooC) is a safety-related element (hardware component, software component, or system) that is developed without the context of a specific vehicle item. Instead of receiving concrete safety requirements from a specific vehicle-level HARA and safety concept, the SEooC developer formulates assumptions about the target application, the safety goals, the ASIL level, and the operating environment, and develops the element based on these assumptions in accordance with ISO 26262.

The ISO 26262 definition from Part 1 states that an SEooC is “a safety element that is not developed in the context of a specific item.” The key distinction is: in normal “in-context” development, the safety requirements flow top-down from the vehicle-level HARA through the FSC and TSC to the component. In SEooC development, the flow is reversed – the developer starts from the bottom, makes assumptions about the top-level context, and develops the element against those assumed requirements.

2. Why SEooC Exists – The Business and Engineering Need

SEooC development exists because of a fundamental reality of the automotive supply chain: many safety-relevant components are developed by suppliers who do not know the specific vehicle, the specific OEM, or the specific safety goals for which their component will be used. Consider a microcontroller manufacturer like Infineon, Renesas, or NXP. They develop safety microcontrollers that will be used in dozens of different ECUs (EPS, ABS, airbag, engine management, battery management) across hundreds of vehicle platforms from multiple OEMs. They cannot perform a vehicle-level HARA for each potential application. Similarly, an AUTOSAR MCAL (Microcontroller Abstraction Layer) supplier develops software that will be configured and integrated into many different ECU projects.

Without SEooC, these suppliers would have two options: either develop a separate safety-qualified version of their component for every single customer application (economically impractical), or not claim ISO 26262 compliance at all and leave all safety qualification burden to the integrator (which makes integration extremely difficult and expensive). SEooC provides the middle path — the supplier develops the component to ISO 26262 standards based on reasonable assumptions, documents those assumptions clearly in a safety manual, and the integrator verifies the assumptions during integration.

3. Where SEooC Appears in ISO 26262

SEooC guidance is provided in several parts of the standard:

Part 10, Clause 9: Provides the primary guidance on SEooC development, including example development processes for system, hardware, and software SEooC elements.

Part 8, Clause 12: Addresses the qualification of software components, including SEooC software.

Part 8, Clause 5: Covers the Development Interface Agreement (DIA), which is the formal agreement between the SEooC supplier and the integrator that defines responsibilities, assumptions, and deliverables.

Part 11: Provides specific guidance for semiconductor components developed as SEooC, including the semiconductor safety manual structure.

4. In-Context vs Out-of-Context Development – The Key Differences

Aspect	In-Context Development	SEooC (Out-of-Context) Development
Requirements source	Derived top-down from specific vehicle HARA → FSC → TSC	Based on assumptions formulated by the developer
Development direction	Top-down (vehicle → system → component)	Bottom-up (component → assumed system context)
Safety goals	Known – provided by OEM/system integrator	Assumed – formulated by SEooC developer
ASIL	Determined by HARA for the specific item	Assumed by developer (typically highest expected ASIL)
Target application	Specific ECU, specific vehicle, specific OEM	Generic – intended for multiple applications and customers
Key deliverable	Safety case (complete)	Safety manual with assumptions of use
Integration burden	Shared per DIA – typically less on integrator	Significant – integrator must validate all assumptions
Standard reference	Parts 3–9 (standard lifecycle)	Part 10 Clause 9, Part 8 Clause 12, Part 11

5. Common SEooC Examples in the Automotive Industry

Hardware SEooC examples: Safety microcontrollers (Infineon AURIX TC3xx, Renesas RH850, NXP S32K/S32G), Power Management ICs (PMICs), gate driver ICs, sensor ICs (torque sensors, current sensors, position sensors), and System Basis Chips (SBCs). These are developed by semiconductor companies for use across many different automotive applications.

Software SEooC examples: AUTOSAR MCAL (Microcontroller Abstraction Layer) software, Real-Time Operating Systems (RTOS – such as FreeRTOS Safety, QNX Safety, ETAS RTA-OS), AUTOSAR Basic Software (BSW) stacks, communication protocol stacks (CAN driver, LIN driver, Ethernet driver), and cryptographic libraries for ISO 21434 cybersecurity compliance.

System-level SEooC examples: Complete electric parking brake modules, complete sensor assemblies (radar modules, camera modules), complete power stage modules, and complete motor driver assemblies that are developed as self-contained units for integration into multiple vehicle platforms.

6. Assumptions of Use – The Foundation of SEooC Development

Assumptions of Use are the single most important element of SEooC development. Since the developer does not have the actual vehicle-level safety requirements, every safety-relevant decision is based on assumptions. These assumptions must be clearly documented, technically justified, and communicated to the integrator through the safety manual. The quality and precision of the assumptions directly determines the reusability and integrability of the SEooC.

Assumptions must cover the assumed application area and intended functions, the assumed ASIL level (typically the highest ASIL the SEooC is expected to support), the assumed safety goals that the SEooC is expected to contribute to, the assumed operating environment (temperature, voltage, EMC, vibration), the assumed system architecture in which the SEooC will be integrated, and the assumed responsibilities of the integrator (what the integrator must do for the SEooC to achieve its claimed safety capability).

7. Categories of Assumptions – Environment, Use, Architecture

Assumptions on the operating environment: Temperature range (e.g., −40°C to +150°C junction temperature), supply voltage range (e.g., 4.5V to 5.5V with specified transient tolerance), electromagnetic compatibility environment (e.g., ISO 11452 test levels), vibration and shock profiles, and expected mission profile (e.g., 15-year vehicle lifetime, 8,000 operating hours).

Assumptions on use (functional): The intended application domain (e.g., chassis control, powertrain, body electronics), the safety functions the SEooC is expected to support (e.g., “the MCU supports safety functions up to ASIL D when used in a lockstep dual-core configuration”), the operating modes (normal, degraded, startup, shutdown), and the expected diagnostic test intervals.

Assumptions on system architecture: The expected system topology (e.g., “the MCU is used as a single primary controller with an external monitoring IC”), the expected redundancy strategy (e.g., “the system uses dual-MCU architecture for ASIL D decomposition”), the expected communication interfaces (e.g., “CAN FD with E2E protection for safety-relevant messages”), and the expected allocation of safety mechanisms between the SEooC and the rest of the system.

Assumptions on integrator responsibilities: What the integrator must configure, verify, test, or implement for the SEooC to function safely. Examples: “The integrator shall configure the MPU (Memory Protection Unit) to prevent non-safety software from corrupting safety-relevant memory regions,” “The integrator shall implement a software watchdog servicing routine within the safety task with a maximum period of 5 ms.”

8. The SEooC Development Process – Step by Step

Step 1 – Define the scope and boundary: Clearly define what the SEooC includes and excludes. Define all external interfaces. Document the boundary in the safety manual.

Step 2 – Formulate assumptions of use: Document all assumptions across the categories described above. These assumptions replace the vehicle-level safety requirements that would normally flow down from the HARA/FSC/TSC.

Step 3 – Derive assumed safety requirements: From the assumptions, derive the technical safety requirements (TSRs) for the SEooC, just as you would in a normal Part 4/5/6 development – but based on the assumed context rather than an actual context.

Step 4 – Develop according to ISO 26262: Develop the SEooC (hardware, software, or system) following the full ISO 26262 lifecycle requirements for the assumed ASIL. This includes safety analysis (FMEA/FMEDA/FTA), design, implementation, verification, and testing – exactly as for an in-context element.

Step 5 – Create the safety manual: Document all work products, all assumptions, all safety requirements, and all conditions that the integrator must fulfill. The safety manual is the primary deliverable to the customer.

Step 6 – Undergo assessment (if required): For ASIL C and D SEooC elements, an independent functional safety assessment by a qualified assessor (e.g., TÜV, SGS, exida) may be performed to provide additional confidence to customers. The assessment results in a functional safety certificate or compliance letter.

9. Hardware SEooC – Microcontrollers and Semiconductor Components

Semiconductor components are the most common type of hardware SEooC. A safety microcontroller developed as SEooC (such as the Infineon AURIX TC3xx family) makes assumptions about the application domain it will support (chassis, powertrain, ADAS), the maximum ASIL it can contribute to (typically ASIL D with specific configuration requirements), the on-chip safety mechanisms it provides (lockstep CPU cores, ECC on memories, clock monitoring, voltage monitoring, BIST), and the diagnostic coverage these mechanisms achieve.

The semiconductor safety manual (as described in Part 11) documents the assumed failure rates (in FIT), the FMEDA results showing the failure mode distribution and diagnostic coverage of each on-chip safety mechanism, the hardware metric contributions (the MCU’s contribution to SPFM, LFM, and PMHF), and the conditions under which these metrics are valid – including which safety features must be enabled and how they must be configured by the integrator.

10. Software SEooC – AUTOSAR, RTOS, and Middleware

Software SEooC development presents unique challenges because software components are highly configurable and their behavior depends on the configuration chosen by the integrator. An AUTOSAR MCAL developed as SEooC, for example, assumes a specific microcontroller family it targets, the ASIL capability it supports, the safety mechanisms it implements (e.g., read-back verification for register writes, timeout monitoring for peripheral access), and the configuration parameters that must be set correctly by the integrator.

ISO 26262 provides two lifecycle options for configurable software SEooC. Simplified Lifecycle I requires the integrator to verify the configured software in the target context. Simplified Lifecycle II requires the SEooC developer to verify all relevant configurations. In practice, the SEooC developer typically verifies a set of reference configurations and provides verification guidelines for the integrator to cover project-specific configurations. A particular challenge for software SEooC is handling unused functionality – code that is present in the SEooC but not needed by a specific integrator. ISO 26262 requires that either the deactivation of unused functions is assured, or the unused code is analyzed to confirm it does not interfere with safety functions.

11. System-Level SEooC – Subsystems and Modules

System-level SEooC elements are complete subsystems (e.g., an electric parking brake actuator module, a radar sensor module) developed as self-contained units with their own internal hardware and software. The system-level SEooC developer makes assumptions about the vehicle-level safety goals, the communication interfaces (CAN messages, electrical connector pinout), the power supply characteristics, and the mechanical mounting environment. The system-level SEooC typically provides a more complete safety case than a component-level SEooC, because the developer controls both the hardware and software and can verify the internal safety concept end-to-end. However, the integration assumptions still must be validated by the vehicle-level integrator.

12. The Safety Manual – Contents and Best Practices

The safety manual is the primary deliverable from the SEooC developer to the integrator. It contains everything the integrator needs to safely use the SEooC. ISO 26262 Part 11 Clause 5 (for semiconductors) provides guidance on the content, which applies conceptually to all SEooC types:

1. SEooC description: Functional description, boundary definition, interface descriptions, operating modes.

2. Assumed ASIL capability: The maximum ASIL the SEooC supports and under what conditions.

3. Assumptions of use (complete list): All assumptions across all categories – environment, functional use, system architecture, and integrator responsibilities.

4. Safety mechanisms and their diagnostic coverage: Description of all internal safety mechanisms, their failure coverage, and the diagnostic test intervals required.

5. Hardware metric contributions (for hardware SEooC): FMEDA results, failure rate data, SPFM/LFM/PMHF contributions.

6. Configuration requirements: Which features must be enabled, which parameters must be set, and what configuration values are required for the claimed safety capability.

7. Integration requirements: What the integrator must do – specific verification tests, specific configuration checks, specific software implementation requirements.

8. Known limitations: Any known restrictions, exclusions, or conditions under which the SEooC’s safety claims do not apply.

Best practice: Write the safety manual from the integrator’s perspective – as if they need to use it to build a safe system without being able to ask you questions. Clear, specific, unambiguous language is essential. Vague assumptions like “the system shall be used in a typical automotive environment” are insufficient – specify the temperature range, voltage range, and EMC levels explicitly.

13. Integrating an SEooC – The Integrator’s Responsibilities

When an integrator (typically a Tier-1 supplier or OEM) incorporates an SEooC into their vehicle-level item, they must perform several critical activities:

1. Obtain and review the safety manual: Understand all assumptions, requirements, and limitations documented by the SEooC developer.

2. Validate assumptions of use: Systematically verify that every assumption in the safety manual is valid in the actual application context. If the SEooC assumes ASIL D and the application requires ASIL D – that assumption is valid. If the SEooC assumes a supply voltage of 5V ±10% and the actual supply is 3.3V – that assumption is invalid.

3. Allocate the SEooC within the system safety concept: Incorporate the SEooC into the FSC/TSC, ensuring its safety mechanisms are correctly accounted for in the system-level safety analysis.

4. Perform system-level safety analysis: Include the SEooC in the system-level FMEA and FTA, using the failure rate data and diagnostic coverage information from the safety manual.

5. Fulfill integrator responsibilities: Implement all requirements specified in the safety manual – configure safety features correctly, implement required software routines, perform specified verification tests.

6. Document the integration evidence: Record the assumption validation results and integration verification evidence in the safety case.

14. Validating Assumptions of Use During Integration

Assumption validation is a systematic, documented process. For each assumption in the safety manual, the integrator must determine whether the assumption is valid (the actual context matches or exceeds the assumed context), partially valid (the actual context mostly matches but has minor deviations that require analysis), or invalid (the actual context does not match the assumption). A traceability matrix linking each assumption to its validation evidence is a common best practice. Validation methods include analysis (comparing assumed parameters to actual design values), testing (verifying assumed behavior through system-level tests), and review (expert assessment of whether qualitative assumptions are met).

15. What Happens When Assumptions Are Not Valid?

When an assumption is found to be invalid during integration, several options exist:

Option 1 – Modify the system design: Change the integrating system to make the assumption valid. For example, if the SEooC assumes a 5V supply and the system provides 3.3V, add a voltage regulator. This is often the simplest solution for environmental or interface assumptions.

Option 2 – Request SEooC modification: Negotiate with the SEooC supplier to modify the element or provide an alternative configuration that matches the actual context. This triggers a change management activity per Part 8 and may require re-verification of the affected safety mechanisms.

Option 3 – Perform additional safety analysis: Analyze the impact of the invalid assumption on the system safety. If the analysis demonstrates that the safety goals are still achieved despite the assumption mismatch (perhaps because other system-level safety mechanisms compensate), the SEooC may be usable as-is with documented justification.

Option 4 – Reject the SEooC: If the assumptions are fundamentally incompatible and none of the above options are feasible, the SEooC cannot be used in this application. An alternative component must be selected.

16. SEooC vs Proven-in-Use vs Qualification

Approach	Description	ISO 26262 Reference	Best For
SEooC	Developed to ISO 26262 based on assumptions; safety manual provided	Part 10 Clause 9	New components developed specifically for ISO 26262 compliance across multiple applications
Proven-in-Use	Existing component with sufficient field experience demonstrating acceptable safety performance	Part 8 Clause 14	Legacy components with extensive field history being reused in new applications
Qualification (SW Component)	Software not developed to ISO 26262 but qualified for use through additional analysis and testing	Part 8 Clause 12	COTS software components not originally developed to ISO 26262

17. Hardware Metrics for SEooC – SPFM, LFM, PMHF Allocation

For hardware SEooC elements, the Part 5 hardware metrics present a unique challenge: the SEooC developer can calculate the metrics contribution from the SEooC itself, but the overall system-level metrics depend on the entire system architecture – which the SEooC developer does not know. The common approach is for the SEooC developer to provide the raw FMEDA data (failure rates per failure mode, diagnostic coverage per safety mechanism, failure classification per failure mode) in the safety manual, along with a calculated metric contribution assuming a reference system architecture. The integrator then uses this data in their system-level FMEDA to calculate the actual SPFM, LFM, and PMHF for the complete system.

18. Common Mistakes and How to Avoid Them

Mistake 1: Vague or incomplete assumptions. Assumptions like “typical automotive environment” or “standard ASIL D development” are insufficient. Every assumption must be specific, measurable, and verifiable. Specify exact temperature ranges, voltage ranges, timing constraints, and configuration requirements.

Mistake 2: Assuming the integrator will “figure it out.” The safety manual must provide everything the integrator needs. If a configuration parameter must be set to a specific value for safety, state that explicitly – do not assume the integrator will deduce it from general principles.

Mistake 3: Not considering all potential applications. If the SEooC is too narrowly assumed, it may not be usable in many target applications. If the assumptions are too broad, the development effort increases. Finding the right balance requires understanding the target market and typical application scenarios.

Mistake 4: Integrator not validating assumptions. Some integrators treat the SEooC as a “black box” and assume it is safe without validating the assumptions. This is a compliance gap – every assumption must be systematically validated against the actual application context.

Mistake 5: Not maintaining traceability from assumptions to requirements. Every assumed safety requirement must trace to the assumption it is based on. If an assumption changes or is found invalid, the impact on all derived requirements must be immediately identifiable.

Mistake 6: Confusing SEooC certification with system-level safety. An SEooC with a TÜV certificate is not automatically safe in every application. The certificate confirms that the element was developed according to ISO 26262 based on its stated assumptions – it does not confirm that those assumptions are valid in any specific system. System-level safety is always the integrator’s responsibility.

19. Frequently Asked Questions

Q1: Can any component be developed as SEooC?

Yes – ISO 26262 allows systems, hardware components, and software components to be developed as SEooC. The key requirement is that assumptions of use are clearly formulated, the element is developed according to the appropriate ISO 26262 requirements for the assumed ASIL, and the safety manual provides all information needed for integration.

Q2: Is SEooC development easier or harder than in-context development?

It depends. SEooC development avoids the dependency on vehicle-level requirements (which may not be available when the component development needs to start). However, formulating correct assumptions is challenging, and the SEooC developer must consider a wider range of potential applications, which may increase the scope of safety analysis and testing.

Q3: Does the integrator need to redo the FMEA/FMEDA from the SEooC?

No — the integrator uses the FMEDA data provided in the safety manual as input to their system-level analysis. However, the integrator must verify that the assumptions underlying the FMEDA (operating conditions, failure rates, diagnostic test intervals) are valid in their application context.

Q4: What is the relationship between SEooC and AUTOSAR?

While SEooC and AUTOSAR are independent concepts, many AUTOSAR software components (MCAL, OS, communication stacks) are developed as SEooC because they are developed by software suppliers for use across many different ECU projects. AUTOSAR’s standardized interfaces actually facilitate SEooC development by providing well-defined boundaries and interface specifications.

Q5: Can an SEooC be developed to multiple ASIL levels?

Yes. A common approach is to develop the SEooC to the highest assumed ASIL (e.g., ASIL D) and state in the safety manual that the element supports applications up to ASIL D. Applications at lower ASILs can use the same element with the confidence that it exceeds their requirements.

20. Conclusion

SEooC (Safety Element out of Context) is a pragmatic and essential concept in ISO 26262 that enables the automotive supply chain to develop reusable, safety-qualified components without requiring complete vehicle-level context at the time of component development. The key to successful SEooC development is the quality of the assumptions of use – specific, complete, justified, and clearly documented in the safety manual. The key to successful SEooC integration is the systematic validation of every assumption against the actual application context.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For related topics, see Part 8 – Supporting Processes, Part 10 – Guidelines, and Part 11 – Semiconductors.

Stay safe. Stay assumption-aware. Keep engineering the future.

— The PiEmbSysTech Team