General Legal Button Menu ✅

Content

This app defines the technical and functional-safety framework under which the EPS sub-system is developed, supplied and integrated. It establishes clear responsibility boundaries between supplier and OEM and provides the foundation for the subsequent ISO 26262 lifecycle activities (Harzard and Risk Assesment, Safety Concept, Sub-System, Hardware and Software Safety Design as well as Industrialisation).

Responsibility Allocation

The supplier is responsible for the correct implementation of the released hardware and software safety concepts within the sub-system, including compliance with the specified safety requirements, diagnostic mechanisms and architectural assumptions. The vehicle manufacturer is responsible for correct system-level integration, including boundary conditions, interfaces, vehicle functions and operational constraints.

Sub-System as Item and its Elements

The supplier provides an EPS sub-system according to ISO 26262 Part 4 consisting of hardware and software elements developed under ISO 26262 Part 5 (Hardware) and Part 6 (Software), and is released for series production ISO 26262 Part 7 (Production) based on defined saftey strategies. The vehicle manufacturer integrates this sub-system into the overall vehicle system, which is validated at vehicle level in combination with other sub-systems.

Quality, Warranty and Safety Integrity

All sub-system elements manufactured with series production tools shall meet the released technical, functional and safety requirements. The design shall ensure stable and safe operation over the intended lifetime under the specified environmental and operational conditions.

Series Application

Any deviation from the released safety concept, assumptions or interfaces may invalidate the safety assessment and shall require re-evaluation. Sub-systems that do not comply with the released technical and functional safety requirements are considered non-conformant and unsafe for series application.

Safety Responsibility & Defendability
Safety Question	Is the Sub-System incl. HW and SW sufficiently safe, and is the safety design technically and legally defendable?
a) Responsibility	Judicial responsibility applies to individuals who are technically or organizationally responsible for the safety of the item or element, independent of their position or rank within the organization.
b) Trigger Event	Responsibility may be assessed following accidents involving injury or loss of life, or in cases of demonstrable and reproachable safety-related failures.
c) Cause	Responsibility may arise if it can be demonstrated that: Known safety risks were identified but not adequately mitigated. Preventive technical or organizational measures were feasible but not implemented. Safety responsibilities were not accepted or acted upon in a timely and appropriate manner.
Typical Deficiencies	Examples of insufficient safety practice include: Incomplete FMEDA or failure mode analysis across all relevant components; Missing or insufficient reliability analysis (FIT/MTBF) for catastrophic failure modes; Lack of architectural measures (e.g. redundancy, monitoring) to control failure effects; No use of state-of-the-art safety mechanisms or proven safety concepts; Insufficient verification and validation, including fault injection or failure insertion testing or failure simulation testing; Design changes that reduce previously established fail-safe or safe-state strategies; etc.

Product Liability, Warranty & Safety Evidence

This application supports engineers in documenting and verifying functional safety work products. It summarizes how supplier evidence (requirements, safety concept, FMEDA, test and validation results) is used to justify series release of an EPS sub-system in alignment with ISO 26262.

Technical intent

Confirm that the delivered EPS sub-system meets the released technical safety concept and defined safe states for the mission profile [ISO 26262 Level 2,3,4,5 or 6].
Provide traceable reliability assumptions (Failure in Time [FIT] / Failure Rates [λ], derating notifications) and architecture rationale.
Provide verification and validation evidence (including fault injection / failure insertion tests where applicable and failure simulations as well as hardware in the loop).

Example of Jurisdiction-Dependent Liability

System delivery and operation are subject to country-specific legal and regulatory requirements. Liability allocation between the manufacturer, supplier, and vehicle operator may vary depending on national legislation and regulatory interpretation. These jurisdictional differences are addressed within the system safety concept, operational assumptions, and release conditions.

Final Statement

Supplier: responsible for desciption of delieferd sub-system design and its elements including the safety features.
OEM: responsible for vehicle-level integration (combination multiple sub-system), and operational constraints.

The following does not replace project-specific legal assessment, but it helps ensure the safety argument is technically defendable with complete evidence for audits and (if required) legal/judicial review.

Safety Responsibility & Defendability
Safety Question	Is the Sub-System including hardware and software sufficiently safe, and is the safety design technically and legally defendable?
a) Responsibility	Responsibility applies to individuals who are technically or organizationally responsible for the safety of the item or element, independent of position or rank.
b) Trigger Event	Responsibility may be assessed following accidents involving injury or loss of life, or in cases of demonstrable and reproachable safety-related failures.
c) Cause	Responsibility may arise if it can be demonstrated that: Known safety risks were identified but not adequately mitigated; Preventive technical or organizational measures were feasible but not implemented; Safety responsibilities were not accepted or acted upon in a timely manner.
Typical Deficiencies	Examples of insufficient safety practice include: Incomplete FMEDA or failure mode coverage; Missing or insufficient FIT / MTBF analysis; Lack of architectural safety measures (monitoring, redundancy); No use of state-of-the-art safety mechanisms; Insufficient verification and validation (e.g. fault injection tests); Design changes degrading established safe-state concepts.

Jurisdiction	Claim Structure	Legal Representation Model	Evidence & Disclosure Practice
United States (USA)	Group actions may be formed where one or more active plaintiffs represent a larger group of affected parties.	Attorneys may proactively contact affected parties. Fee models may include success-based remuneration depending on jurisdiction.	Once proceedings are admitted, extensive disclosure obligations apply. Defendants may be required to provide relevant technical and project documentation.
Germany	Claims are typically pursued individually. Each plaintiff carries their own procedural and financial risk.	Success-based remuneration models are generally prohibited. Legal representation follows strict statutory fee regulations.	Disclosure obligations are limited. Access to internal technical documents may be restricted unless explicitly required by court order.