How to Develop Safety

Element Out of
Context (SEooC)
Solutions
Automotive Functional
Safety | ISO 26262
The concept of SEooC emerges from the need to develop certain
automotive software and hardware which are not specific to a
vehicle model, type, and use-case.

For instance, a radar system can be used in a vehicle with advanced

Level 2 ADAS features such as adaptive cruise control. Such
use-cases would warrant the component to be developed as a
safety-critical automotive solution.

SEooC as a concept, operates by designing these components with

generic safety requirements that are not specific to any one vehicle
model.

Another way to define SEooC is, “E/E systems that are not
developed based on the specific requirements provided by the
OEM, suppliers or technology vendors, rather on assumptions”.

In such systems, hardware or software are developed for an

assumed context, not a specific vehicle, OEM or industry.
Part-10 of the ISO 26262 standard has the recommendations for
development of safety elements out of context.

Examples of Safety Element Out of Context

• Anti-lock Braking System (ABS) Modules: Designed to prevent

wheel lockup during braking.

• Electronic Stability Control (ESC) Units: Helps maintain vehicle

control during extreme steering manoeuvres.

• Airbag Control Units: Manages the deployment of airbags in

the event of a collision.

• Battery Management Systems for EVs: Monitors and manages

the health and state of electric vehicle batteries.

• Steering Angle Sensors: Measures the angle of the steering

wheel for advanced driver assistance systems.

• Adaptive Cruise Control Systems: Automatically adjusts

vehicle speed to maintain a safe distance from other vehicles.

• Tire Pressure Monitoring Systems (TPMS): Monitors the pres

sure inside automotive tires.

• Driver Monitoring Systems: Assesses the driver’s alertness to

prevent accidents caused by inattention.

• Lane Departure Warning Systems: Alerts the driver when the

vehicle begins to move out of its lane.

• Automotive Radar Systems: Used for collision avoidance and

adaptive cruise control.
How is SEooC Different from Safety Element Developed ‘In Context’?

Aspect SEooC (Safety Safety Element

Element Out of developed in Context
Context)

Safety Goals Defined generically, Defined within the specific

independent of specific system context and
system or application application needs.

Context of Developed without a Developed with a specific

Use predefined application application and
context. environment in mind.

Functional Assumed broadly to be Tailored specifically to meet

Safety applicable to a range of the detailed needs of the
Requirements contexts. application.

Technical Established as a base Defined based on the

Safety standard that could be specific context and
Requirements adapted to various integration requirements.
systems.

Safety Contains generic Includes detailed

Manuals guidelines and usage instructions and
restrictions. constraints for specific use.
Development Follows ISO 26262 parts Follows ISO 26262 with a
Process that can be adapted to focus on parts specific to
various contexts, focusing the context, such as Part 4:
on flexible, generic Product development at the
standards and system level, integrating
methodologies (e.g., Part specific safety and
6: Product development at environmental
the software level). considerations.
Qualification Focus on potential Qualification for specific
qualification for various use cases, conditions, and
scenarios and systems. integration.
How to Classify an Automotive Solution as SEooC?
Whether an automotive software, hardware or system is ideal to be
developed as SEooC depends on various factors, viz. the product's
intended usage, flexibility, and applicability across different
platforms or models.

Let’s break it down with a few examples-

1) ABS Module as SEooC

Generic Nature of the Component:

• Reusable Across Platforms: The fundamental operation of ABS

is consistent across various vehicle types and models, making
it ideal for SEooC development.

• Standardized Functionality: ABS modules consistently perform

critical functions like monitoring wheel speed and controlling
brake fluid pressure.

Safety Requirements:

• Broad Safety Goals: The main goal is to prevent wheel lock-up

during braking, enhancing control and reducing stopping
distances, applicable universally.

• Adaptability of Safety Features: Core functions remain

constant, but the system can be calibrated to suit different
vehicle dynamics and weight distributions.

Development and Integration Complexity:

• Simplification of Development: Developing the ABS as SEooC

allows manufacturers to create a robust, tested module that
can be adapted with minimal changes to a range of vehicle
models, reducing development time and costs.
• Integration Versatility: Interfaces with the vehicle’s hydraulic
system and wheel sensors, with adaptations primarily in
software or sensor placement.
2) Low-level drivers as SEooC

Low-level drivers are software components that manage the

hardware interfaces of microcontrollers in vehicles.
These components typically handle tasks like reading sensor data,
controlling actuators, or managing communication protocols.
Attributes that make low-level drivers an ideal case for SEooC
development:

• Reusable Across Platforms: Low-level drivers can be designed

to interface with common automotive hardware, such as CAN
(Controller Area Network) bus controllers or ADC (Analog to
Digital Converters). This makes them suitable for use across
different vehicle models and systems.

• Standardized Functionality: The basic functionalities of these

drivers (like sending and receiving data over CAN bus,
converting analog signals to digital) are consistent across
different applications, making them ideal candidates for
development as SEooC.

Safety Requirements:

• Broad Safety Goals: The safety goal for a low-level driver might
be to ensure reliable and error-free communication or data
conversion, crucial for the correct operation of safety-critical
systems like braking or engine management.

• Adaptability of Safety Features: While the fundamental safety

features of low-level drivers are consistent, specific
parameters like timing constraints or error handling
mechanisms can be configured according to the needs of the
particular application they are integrated into.
Development and Integration Complexity:

• Simplification of Development: Developing low-level drivers as

SEooC simplifies the process by using a standard approach to
manage common automotive hardware, which can later be
adapted for specific hardware configurations or additional
functionalities.

• Integration Versatility: These drivers are typically integrated at

the software level with minimal hardware dependencies,
allowing them to be easily adapted to various microcontrollers
or peripherals through configuration or minor modifications.

SEooC Development Under ISO 26262 Standard: Key Insights

The development of a Safety Element out of Context (SEooC)

product begins with foundational assumptions about the target
environment, guiding the product's design and development.

Key Assumptions for SEooC Development:

• Application area and component function

• System's technical architecture
• Functional and technical safety requirements
Assigned Automotive Safety Integrity Level (ASIL)

From these assumptions, developers derive detailed safety

requirements, establish safety goals, and commence product
development. This approach contrasts with the typical safety
lifecycle's concept phase, where Hazard Analysis and Risk
Assessment (HARA) usually defines safety goals and ASIL values.
For SEooC, these elements are predetermined based on the initial
assumptions.

Validation of Assumptions Before Integration:

To ensure that the SEooC product integrates seamlessly into the

target system, validations are performed at three levels:

Confirms that the SEooC product fulfills the system's requirements.

Architecture Level: Ensures compatibility with the target system

architecture.

ASIL Level: Verifies that the SEooC product meets the necessary
ASIL standards (A, B, C, or D).

Our Capabilities in Development of SEooC as per ISO 26262

Standard

Embitel Technologies has been a market leader in offering ISO

26262 compliant development services. From FuSa consulting to
safety-critical software, hardware and system development, we
have an array of ISO 26262 related services.

As part of our ISO 26262 offerings, we provide end-to-end support

for the development of SEooC products as per ISO 26262 standard.
Staying Ahead of the Curve

Functional safety for road vehicles is constantly evolving. With

Level-2 ADAS features getting common in passenger cars, the
number of safety-critical components are increasing consistently.
At such as juncture, we are fully equipped and excited to contribute
to this revolution.
Our ISO 26262 compliant services along with ready-to-integrate ISO
26262 compliant protocol stacks (UDS, DoIP, CAN, J1939 and
more) can ensure swift integration and compliance with current and
future standards. Our team's expertise in the development of SEooC
products, combined with cutting-edge tools and methodologies,
positions us to lead advancements in vehicle safety, making the
roads safer for everyone.