ISO 26262-1: VOCABULARY   

ISO 26262-2: MANAGEMENT OF FUNCTIONAL SAFETY   

2.1 OVERALL SAFETY MANAGEMENT (ISO 26262-2 5)

The organisation shall create, foster, and sustain a safety culture that supports and encourages the effective achievement of functional safety. This includes institution, execution and maintenance of specific processes and guidelines, for resource management, a continuous improvement process and an escalation plan for functional safety issues. This is reached by assignment of authorities and responsibilities to safety managers. Communication channels between FS, cyber security and other disciplines touching FS shall be implemented.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.1.1 SAFETY CULTURE (ISO 26262-2 5.4.2)

The organization shall create, foster, and sustain a safety culture that supports and encourages the effective achievement of functional safety. This includes institution, execution and maintenance of specific processes and guidelines, for resource management, a continuous improvement process and an escalation plan for functional safety issues. This is reached by assignment of authorities and responsibilities to safety managers.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.1.2 MANAGEMENT OF SAFETY ANOMALIES (ISO 26262-2 5.4.3)

The organization shall institute, execute and maintain processes to ensure that identified safety anomalies are explicitly communicated to the persons responsible for achieving or maintaining functional safety during the safety lifecycle. A safety anomaly shall only be considered as managed to closure if it is solved by a safety measure or it is evaluated as not constituting an unreasonable risk.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.1.3 COMPETENCE MANAGEMENT (ISO 26262-2 5.4.4)

Assurance of adequate qualification of responsible persons in the safety lifecycle.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.1.4 QUALITY MANAGEMENT (ISO 26262-2 5.4.5)

A quality management system for processing safety related products is to be established, complying to a standard as IATF 16949, ISO 9001 or adequate.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.1.5 PROJECT INDEPENDENT TAILORING OF THE SAFETY LIFECYCLE (ISO 26262-2 5.4.6)

The organisation may tailor the Safety Lifcycle for project independent application to various item developments. E.g. a safety management structure (responsibilities) shall be implemented as well as a generic safety process (process description, safety management, develop-ment of templates and tools) and training guidelines/ concepts. Restrictions are stated in ISO 26262-2 5.4.6.1.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2 SAFETY MANAGEMENT DURING CONCEPT PHASE AND PRODUCT DEVELOPMENT (ISO 26262-2 6)

Safety management roles and responsibilities shall be defined. The requirements to the safety management shall be defined, too.

2.2.1 ROLES AND RESPONSIBILITIES (ISO 26262-2 6.4.2)

At first, a project manager shall be appointed at initiation of product development, equipped with authority to ensure performance of FS activities and ISO 26262 compliance. The project manager may appoint a functional safety manager who takes over the FS responsibility and authority. In this case, the project manager stays responsible to ensure that the organisation provides required resources for safety activities.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.2 IMPACT ANALYSIS AT ITEM LEVEL (ISO 26262-2 6.4.3)

At beginning of the SLC, an impact analysis shall be performed to evaluate the item being a new development, a modified item, or a not modified item in a modified environment. In case of modification, an impact analysis shall be carried out to identify and describe in-tended modification applied to the item or its environment to assess the impact of modifi-cation. The impact analysis shall identify and address areas affected by modification considering operational situations and modes, interfaces, installation characteristics, and range of environmental conditions. In case of new development, no impact analysis is needed.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.3 REUSE OF AN EXISTING ELEMENT (ISO 26262-2 6.4.4)

In case of reuse of an existing element, an impact analysis is needed to figure out modifications to the operational context, the capability of the element to cope with the allocated safety requirements, the resulting safety activities considering all kinds of modifications and the sufficiency of existing safety documentation of the element.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.4 TAILORING OF SAFETY ACTIVITIES (ISO 26262-2 6.4.5)

If a safety activity is not being performed as required by ISO 26262 standard (e.g. just editing documentations of a modified element), the tailoring shall be defined and justified in the safety plan.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.5 PLANNING AND COORDINATION OF THE SAFETY ACTIVITIES (ISO 26262-2 6.4.6)

The FS manager shall be responsible for coordination of FS activities. Thus, the FS man-ager shall create and maintain a safety plan, containing all safety activities (see ISO 26262-2 6.4.6.5).
Planning of safety activities shall include describing objective, dependencies on other ac-tivities/ information, responsible and required resource and person for activity performance, starting point and duration, and identification of corresponding work products.
For Safety Goals higher than ASIL A, an authorized person has to approve the safety plan. Identified anomalies have to be reported to the responsible persons.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.6 PROGRESSION OF THE SAFETY LIFECYCLE (ISO 26262-2 6.4.7)

If information of a pertinent preceding subphase of the SLC is missing, the next subphase shall not be started, if the lack of information causes an unreasonable risk regarding FS.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.7 SAFETY CASE (ISO 26262-2 6.4.8)

The safety case is a document containing an argumentation chain for a safety-related product, why it should be considered as achieving a suitable functional safety and not con-taining unreasonable risks. Such an argumentation chain might include arguments for the absence of unreasonable risks due to a suitable HARA being performed with defined safety goals where functional and technical safety concept base on as well as the HW and SW requirements. All together should imply that every inherent risk potential was analysed and faced by the requirements and resulting measures.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

2.2.8 CONFIRMATION MEASURES: TYPES, INDEPENDENCY AND AUTHORITY (ISO 26262-2 6.4.9)

CMs are divided into reviews (examination of work products), audits (examination of implementation of functional safety processes) and assessments (examination of functional safety before release for production). Required CMs for ASILs and dependency requirements for executors are shown in ISO 26262-2 6.4.9.1 and below.

Process: 10_CONFIRMATION MEASURES.
Work products: \10_CONFIRMATION.

2.2.9 CONFIRMATION REVIEW (ISO 26262-2 6.4.10)

Confirmation reviews shall be performed according to Table 1 and results shall be documented in a confirmation review report. The person responsible shall be appointed according to the level of independence (Table 1).

Process: 10_CONFIRMATION MEASURES.
Work products: \10_CONFIRMATION.

2.2.10 FUNCTIONAL SAFETY AUDIT (ISO 26262-2 6.4.11)

Functional safety audit shall be carried out for items with highest ASIL higher than A. It shall be carried out by one or more persons who provide a report containing an evaluation of the implementation of functional safety required processes.

Process: 10_CONFIRMATION MEASURES.
Work products: \10_CONFIRMATION.

2.2.11 FUNCTIONAL SAFETY ASSESSMENT (ISO 26262-2 6.4.12)

Functional safety assessment shall be done for items with highest ASIL higher than A. It has to be carried out by one or more persons who provide a report containing their judgement of the achieved functional safety. The assessment shall examine work products required by safety plan, FS required processes and the appropriation and effectiveness of implemented safety measures.
FS assessment considers the planning of other CMs, the results of FS audits and confirmation reviews, recommendations resulting from former FS assessments.

Process: 10_CONFIRMATION MEASURES.
Work products: \10_CONFIRMATION.

2.2.12 RELEASE FOR PRODUCTION (ISO 26262-2 6.4.13)

For the release for production the safety case shall be available and completed. Confirmation measure reports shall be available. Documentation shall offer name and signature of responsible person, version number, configuration and release date.

Process: 10_CONFIRMATION MEASURES.
Work products: \10_CONFIRMATION.

2.3 SAFETY MANAGEMENT AFTER THE ITEM'S RELEASE FOR PRODUCTION

Responsibilities of organisations and persons for the safety lifecycle after the item´s release for production shall be defined.

Process: Process: 01_MANAGEMENT, 11_PRODUCTION, 12_OPERATION.
Work products: \11_PRODUCTION.

2.3.1 ROLES AND RESPONSIBILITIES (ISO 26262-2 7.4.2)

Determination of responsibilities after the release for production (responsibilities for additive activities in production and operation as well as in case of variations at return flows).

Process: 01_MANAGEMENT, 11_PRODUCTION, 12_OPERATION.
Work products: \01_MANAGEMENT.

2.3.2 PLANNING OF SAFETY ACTIVITIES (ISO 26262-2 7.4.2)

Planning of safety activities after the release for production have to be started at initiation of system development (P-FMEA, control plan, end of line test, documentation of safe implementation and installation with safety advices for operation).

Process: 01_MANAGEMENT, 11_PRODUCTION, 12_OPERATION.
Work products: \01_MANAGEMENT.

ISO 26262-3: CONCEPT PHASE   

3.1 ITEM DEFINITION (ISO 26262-3 5)

The scope of the E/E-system on vehicle level, its dependencies on and interactions with environment and other items shall be defined as well as requirements from and to other items to and from the item in scope. This contains legal and functional requirements, operation conditions, a functional concept describing purpose and functionality as well as operational modes and states, constraints, expected behaviour, and consequences in case of failures.
Enough attention shall be paid to the analysis of requirements by relevant legacy and standards. Such an analysis shall be periodically updated and contain name, date, scope (geographical and technical), and content of the requirement sources.

Process: 03_ITEM.
Work products: \03_ITEM.

3.2 HAZARD ANALYSIS AND RISK ASSESSMENT (ISO 26262-3 6)

The hazard analysis and risk assessment shall be based on item definition and be carried out without considering internal safety mechanisms. Operational modes and situations have to be examined for correct and foreseeable incorrect use of vehicle.
Hazards shall be determined by using adequate techniques and be defined in terms of condition/ behaviour observable on vehicle level. Even combinations of hazardous events and operational situations have to be analysed and consequences be defined.
If needed, measures for hazards out of ISO 26262´s scope have to be highlighted and announced to responsible persons.

Process: 04_HAZARDS & RISKS.
Work products: \04_HAZARDS.

3.2.1 HAZARD IDENTIFICATION AND SITUATION ANALYSIS (ISO 26262-3 6.4.2)

Operational situations and operating modes in which an item´s malfunctioning will result in a hazardous event shall be described for intended and foreseeable unintended use. Hazards shall be determined systematically and be defined in terms of conditions/ behaviour to be observed at the vehicle level.

Process: 04_HAZARDS & RISKS.
Work products: \04_HAZARDS.

3.3.2 CLASSIFICATION OF HAZARDOUS EVENTS AND ASIL DETERMINATION (ISO 26262-3 6.4.3 and 6.4.4)

All identified hazardous events shall be classified in ASILs. Therefore, potential harm is rated in severity levels, probability of exposure, and controllability.
Safety goals shall be specified by derivation from hazardous events. Each hazardous event classified with an ASIL has to get related to a safety goal.
Calculation of exposure probability shall be carried out without considering the number of cars equipped with the item.

PProcess: 04_HAZARDS & RISKS.
Work products: \04_HAZARDS.

See ISO 26262-3 Pages 8 - 10.

3.2.3 VERIFICATION (ISO 26262-3 6.4.6)

HARA and safety goals shall be verified according to ISO 26262-8 9 to show completeness, compliance, and consistency.

Process: 04_HAZARDS & RISKS.
WWork products: \04_HAZARDS.

3.3 FUNCTIONAL SAFETY CONCEPT (ISO 26262-3 7)

The FS concept shall derive FS requirements from SGs and allocate the SReqs to elements of the preliminary architecture of the item or external measures. The functional safety concept elaborates fault detection and failure mitigation, transition to a safe state, safety mechanisms, fault tolerance mechanisms, fault detection and driver warning, arbitration logic to select most appropriate control request. Resulting specifications of FS requirements have to be compliant with ISO 26262-8 Clause 6.

PProcess: 05_CONCEPT.
Work products: \05_CONCEPT.

3.3.1 DERIVATION OF FUNCTIONAL SAFETY REQUIREMENTS (ISO 26262-3 7.4.2)

FS requirements shall be derived from safety goals and safe states, considering preliminary architectural assumptions. FS requirements shall be specified considering operational modes, fault tolerant time interval, safe states, emergency operation interval, and functional redundancies.
If a safety goal violation can be prevented by transitioning to, or by maintaining one or more safe states, then the corresponding safe state(s) shall be specified including transition to the safe state, the fault tolerant time interval and emergency operation interval. If safe states are not reachable by transition in acceptable time interval, emergency operations, warnings and degradation concepts shall be specified.

Process: 05_CONCEPT.
Work products: \05_CONCEPT.

3.3.2 ALLOCATION OF FUNCTIONAL SAFETY REQUIREMENTS (ISO 26262-3 7.4.2.8)

FS requirements shall be allocated to elements of the item.

Process: 05_CONCEPT.
Work products: \05_CONCEPT.

3.3.3 VALIDATION AND VERIFICATION (ISO 26262-3 7.4.3 and 7.4.4)

The acceptance criteria for item´s safety validation is to be specified based on FS requirements. The FS concept shall be verified in accordance with ISO 26262-8 Clause 9 for consistency and compliance with SGs and its ability to avoid/ mitigate hazardous events.

Process: 05_CONCEPT, , 09_VERIFICATION.
Work products: \05_CONCEPT.

ISO 26262-4: PRODUCT DEVELOPMENT AT SYSTEM LEVEL   

4.1 SPECIFICATION OF TECHNICAL SAFETY REQUIREMENTS (ISO 26262-4 6.4.1)

Technical SReqs shall be specified, based on FS concept and preliminary architectural assumptions. Technical SReqs shall specify safety related dependencies between the item and its surrounding. TSReqs shall be allocated to system elements, HW and SW.
ASIL decomposition may be carried out in this phase, according to ISO 26262-9 5.
Safety requirements out of the scope of ISO 26262 (e.g. laws, custom requirements, other standards) shall be documented, too.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.1.1 SAFETY MECHANISMS (ISO 26262-4 6.4.2)

Technical SReqs shall specify response of system/ elements (safety mechanisms) to impacts affecting the achievement of SGs. This includes failures and relevant combinations of stimuli in combination with each relevant operating mode and defined system state, measures for detection, indication and control of external and internal faults as well as measures to enable the system to achieve safe states and emit warnings. For safety mechanisms enabling the item to reach a safe state, the transition to a safe state, the fault tolerant time interval, emergency operation interval and a measure to maintain the safe state have to be defined.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2 SYSTEM DESIGN (ISO 26262-4 6.4.3)

The development of the system design shall be compliant with the functional and technical SReqs of the item. The verification of item afterwards shall be compliant with the technical SReqs specifications.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.1 SYSTEM DESIGN SPECIFICATION AND TECHNICAL SAFETY CONCEPT (ISO 26262-4 6.4.3)

The system design shall be based on the functional concept, preliminary architectural assumptions, and technical SReqs. Technical SReqs shall be allocated to the system design elements. The system design shall implement technical SReqs. The system design has to consider the ability of system design verification, technical capability of intended HW, and SW design achieving FS and the ability to carry out tests during system integration.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.2 SYSTEM ARCHITECTURAL DESIGN CONSTRAINTS (ISO 26262-4 6.4.3.5)

The system and subsystem architecture shall comply with the technical SReqs at their (highest) ASIL. If ASIL decomposition is applied to the SReqs during the system design, it shall be applied according to ISO 26262-9 Clause 5.
Internal and external interfaces of safety-related elements shall be defined, in order to avoid other elements having adverse safety-related effects on the safety-related elements.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.3 SAFETY ANALYSES AND AVOIDANCE OF SYSTEMATIC FAILURES (ISO 26262-4 6.4.4)

Safety analyses for identification of systematic design failures shall be compliant with ISO 26262-9 Clause 8 and the table below. Identified external and internal failures shall be eliminated or mitigated.
To avoid systematic failures, well-trusted automotive design principles shall be applied: reuse of well-trusted technical safety concepts, element designs including HW and SW components, mechanisms for failure detection and control, standardized interfaces.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

SYSTEM DESIGN PROPERTIES (ISO 26262-4 6.4.4.4 to 6.4.4.6)

ASIL rated requirements have to avoid failures resulting from high complexity by showing modularity, adequate level of granularity, and simplicity, due to the use of the principles as reuse of well-trusted technical safety concepts, element designs, detection and control measures, standardised interfaces. Furthermore, modularity, simplicity, and an adequate level of granularity can help to avoid systematic faults.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.4 MEASURES FOR CONTROL OF RANDOM HW FAILURES DURING OPERATION (ISO 26262-4 6.4.5)

Measures for detection and control or mitigation of random HW failures shall be specified with respect to system design. Target values of fault metrics and diagnostic coverages shall be specified for the final evaluation at item level.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.5 HW-SW INTERFACE (HSI) SPECIFICATION (ISO 26262-4 6.4.7)

The HSI shall be specified by specifying HW and SW interactions including HW devices controlled by SW and HW resources supporting SW execution, all being compliant with the technical safety concept.

HSI specifications shall include:

HW devices controlled by SW and HW resources supporting SW execution, all being compliant with the technical safety concept
Relevant operation modes and configuration parameters
HW ensuring independence between SW and HW
Shared and exclusive HW use
Access mechanism to HW
Timing constraints for each service included in technical safety concept.

Relevant diagnostic capabilities of HW and their use by SW shall be specified including HW diagnostic features driven by HW and SW.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.6 REQUIREMENTS FOR PRODUCTION, OPERATION, SERVICE AND DECOMMISSIONING (ISO 26262-4 6.4.8)

Diagnostic features enabling field monitoring during operation shall be specified. For FS maintenance, diagnostic features are needed to enable fault identification by workshop staff.
Requirements for all above named phases of the safety lifecycle have to be specified including assembly instructions, safety-related special characteristics, proper identification of systems or elements, verification methods and measures for production, diagnostic data and service notes as well as decommissioning.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.2.7 SYSTEM DESIGN VERIFICATION (ISO 26262-4 6.4.9)

Using methods of table below, system design shall be verified for completeness and compliance to the technical safety concept. New identified hazards of system design not covered by a SG shall be handled in hazard analysis and risk assessment. Detected anomalies or incompleteness regarding the functional safety concept shall be reported to the responsible persons.

Process: 06_SYSTEM, 09_VERIFICATION & VALIDATION.
Work products: \06_SYSTEM.

4.3 SYSTEM AND ITEM INTEGRATION AND TEST (ISO 26262-4 7)

The objective is to integrate HW and SW components to elements of the item, integrate elements to items to form a system, and afterwards to integrate the system to the vehicle.
Compliance of system (elements) with SReqs shall be tested and system design verification shall be carried out. This is elaborated after sufficient completion of HW and SW development according to ISO 26262-5 and ISO 26262-6.
Detected anomalies or incompleteness regarding the functional safety concept shall be reported to responsible persons.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.3.1 SPECIFICATION OF INTEGRATION AND TESTING (ISO 26262-4 7.4.1)

To demonstrate system design compliance with the technical SReqs, integration testing activities shall be performed according to ISO 26262-8 9.
A strategy is to be defined, covering E/E components and other technologies considered in the safety concept. Every functional and technical SReq shall be verified at least once in the complete integration sub-phase. Appropriate specification of test cases for integration tests shall be derived using a combination of methods listed below and shall refine the integration and testing plan.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

4.3.2 HW-SW INTEGRATION AND TESTING (ISO 26262-4 7.4.2)

HW and SW shall be integrated to get tested.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

TEST GOALS AND METHODS DURING HW-SW TESTING (ISO 26262-4 7.4.2.2)

For detecting systematic faults during HW-SW integration, test goals resulting from requirements (ISO 26262-4 7.4.2.2.2 to 7.4.2.2.6) shall be addressed by application of test methods given in corresponding tables.

Accurate timing of safety mechanisms at HW-SW level has to be shown with test methods given in the table below.
Consistent and correct implementation of external and internal interfaces at HW-SW level has to be shown using methods in the table below.
Effectiveness of HW fault detection mechanisms´ DC at HW-SW level has to be demonstrated using methods in the table below.
Robustness level of elements at HW-SW level has to be shown using test methods in the table below.

4.3.3 SYSTEM INTEGRATION AND TESTING (ISO 26262-4 7.4.3)

Individual elements shall get integrated to the system according to the system design and shall be exposed to tests, according to system integration tests and requirements of ISO 26262-5 and ISO 26262-6.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

TEST GOALS AND TEST METHODS DURING SYSTEM INTEGRATION (ISO 26262-4 8.4.3.2)

Accurate timing of safety mechanisms at system level has to be shown with test methods given in the table below.
Consistent and correct implementation of external and internal interfaces at system level has to be shown using methods in the table below.
Robustness level of elements at system level has to be shown using test methods in the table below.

4.3.4 VEHICLE INTEGRATION AND TESTING (ISO 26262-4 7.4.4)

The item shall be integrated into the vehicle and vehicle integration tests shall be completed. The verification of interface specifications of the item with in-vehicle communication network and power supply network shall be performed.

Process: 06_SYSTEM.
Work products: \06_SYSTEM.

TEST GOALS AND TEST METHODS DURING VEHICLE TESTING (ISO 26262-4 7.4.4.2)

For detecting systematic faults, test goals resulting from requirements (ISO 26262-4 7.4.4.2.2 to 7.4.4.2.5) shall be addressed by application of test methods given in the corresponding tables.
Accurate timing of safety mechanisms at the vehicle level has to be shown with test methods given in the table below.
Consistent and correct implementation of external and internal interfaces at vehicle level has to be shown using methods in the table below.
Robustness level of elements at vehicle level has to be shown using test methods in the table below.

4.4 SAFETY VALIDATION (ISO 26262-4 8)

Providing evidence of the item's compliance with SGs and the item´s FS concept appropriation, furthermore providing evidence of correctness of the SGs and complete achieve-ment of the SGs at vehicle level. That means item integration to a representative vehicle.

Process: 06_SYSTEM, 09_VERIFICATION & VALIDATION.
Work products: \06_SYSTEM.

4.4.1 SAFETY VALIDATION SPECIFICATION (ISO 26262-4 8.4.2)

The SGs shall be validated for the item integrated into a representative vehicle. The validation specification (=plan) includes the item configuration according to ISO 26262-6 Annex C, specification of validation procedures, test cases, driving manoeuvres, acceptance criteria as well as required equipment and environmental conditions.

Process: 06_SYSTEM, 09_VERIFICATION & VALIDATION.
Work products: \06_SYSTEM.

4.4.2 EXECUTION AND EVALUATION OF VALIDATION (ISO 26262-4 8.4.3)

SG validation execution contains evaluation of controllability and safety measure effectiveness (internal and external). Metric validation of random HW failures is to be carried out at the vehicle level. An appropriate set of repeatable tests, long-term tests, analyses user tests, and reviews has to be applied. A good procedure is to coordinate the FMEA with FS activities by providing the functional and technical safety concept to the FMEA and to consider those documents as required functionalities of the item, system or components. Results have to get evaluated.

Process: 06_SYSTEM, 09_VERIFICATION & VALIDATION.
Work products: \06_SYSTEM.

ISO 26262-5: PRODUCT DEVELOPMENT AT HARDWARE LEVEL   

5.1 GENERAL TOPICS FOR PRODUCT DEVELOPMENT AT HW LEVEL (ISO 26262-5 5)

This section aims to plan FS activities for each HW development phase. The reuse of HW or parts shall be identified and the resulting tailoring of the safety activities shall be described considering ISO 26262-8 13. Figure 2 in ISO 26262-5 5.2 shows the reference phase model for product development at HW level.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.2 SPECIFICATION OF HW SAFETY REQUIREMENTS (ISO 26262-5 6)

This clause aims to specify HW SReqs by derivation from functional and technical safety concept/ requirements as well as system architecture. HW safety requirements are to be specified according to ISO 26262-8 clause 6.
Target values for fault metrics specified according to ISO 26262-4 7 shall be considered when deriving values for HW elements of the item. Criteria for HW design verification has to be specified including environmental conditions and operation environment, before performing it.
HSI specification initiated in ISO 26262-4 clause 7 shall be refined describing SR dependencies between HW and SW.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.3 HW DESIGN (ISO 26262-5 7)

Development and verification of HW design architecture needs to be compliant with sys-tem specifications and SReqs.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.3.1 HW ARCHITECTURAL DESIGN (ISO 26262-5 7.4.1)

HW architecture shall implement the HW´s SReqs and inherit the highest ASIL related to it for each HW element. Traceability from HW SReqs and ASIL rating to HW architectural design elements shall be provided down to lowest HW level. Even non-functional causes for failure of SR HW shall be considered during HW architectural design such as temperature, vibrations, water, etc. (mission profile).

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

AVOIDANCE OF SYSTEMATIC HW FAULTS (ISO 26262-5 7.4.1.6)

For avoidance of systematic faults, HW design has to show modularity, adequate granularity and simplicity by using principles listed in the table below.

5.3.2 DETAILED HW DESIGN (ISO 26262-5 7.4.2)

Safety-related HW failures due to non-functional causes have to be considered. It shall be ensured that HW parts operate compliant to their specifications and limits by considering robust design principles.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.3.3 SAFETY ANALYSES (ISO 26262-5 7.4.3)

According to ISO 26262-9 clause 8, safety analyses have to be applied on HW components to figure out failures and fault effects (see table below). By doing so, safe faults, single-point faults and multiple-point faults should be identified and evidence of effectiveness of safety mechanisms shall be provided. Identified hazards not related to a SG yet have to be exposed to HARA according to change management process (ISO 26262-8 8).

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

EVIDENCE CONCERNING SAFETY MECHANISMS (ISO 26262-5 7.4.3.4)

To show evidence of effectiveness of safety mechanisms for SPF avoidance, their ability of maintaining a safe state (or switch to it) and diagnostic coverage with respect to residual faults shall be evaluated. To show evidence of effectiveness of safety mechanisms for MPF avoidance, their ability of maintaining a safe state (or switch to it) and diagnostic coverage with respect to latent faults shall be evaluated. In case of MPFs, the evidence of failure detection and ability of notifying the driver within MPF detection time interval has to be evaluated (in order to distinguish between faults remaining latent and not latent faults).
Evidence to HW independence compliance has to be provided basing on dependent failure analysis according to ISO 26262-9 clause 7.

5.3.4 HW DESIGN VERIFICATION (ISO 26262-5 7.4.4)

HW design shall be verified according to ISO 26262-8 clause 9 to provide evidence of compliance with HW SReqs, considering methods in the table below.

Process: 07_HARDWARE, 09_VERIFICATION & VALIDATION.
Work products: \07_HARDWARE.

5.3.5 PRODUCTION, OPERATION, SERVICE AND DECOMMISSIONING (ISO 26262-5 7.4.5)

SR special characteristics have to be specified, when relevance shown by analyses. SR special characteristic specification includes verification measures (to be applied during production and operation) and measure acceptance criteria. Instructions for assembly, disassembly, decommissioning and maintenance of safety-related hardware elements need to be specified, if impact to technical safety concept is possible.
Traceability of SR HW elements shall be ensured. This serves containment of affected assemblies in case of safety concerns.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.4 EVALUATION OF THE HARDWARE ARCHITECTURAL METRICS (ISO 26262-5 8)

Evaluation of the item´s HW architecture against fault handling requirements (= HW architectural metrics).

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.4.1 REQUIREMENTS TO ASILS (B), C AND D (ISO 26262-5 8.4)

Estimated failure rates of HW parts used in analyses have to be determined by using failure rate data of either recognized industry source, or statistics based on field returns, or tests, or expert judgement founded on engineering approach. If no failure rates of a HW part are available, additive safety measures for detection and control of HW failure shall be implemented.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

SINGLE-POINT FAULT METRIC (SPFM) (ISO 26262-5 8.4.5)

For each SG a quantitative target value for SPFM shall be determined, according to ISO 26262-4 7.4.4.2. It can be derived from HW architectural metrics calculation or taken from the table below.

LATENT FAULT METRIC (LFM) (ISO 26262-5 8.4.6)

For each SG a quantitative target value for LFM has to be determined, according to ISO 26262-4 7.4.4.2. It can be derived from HW architectural metrics calculation or taken from the table below.

5.4.2 VERIFICATION OF EVALUATION (ISO 26262-5 8.4.7 to 8.4.9)

For each SG either the item´s entire HW shall meet the SPFM requirement or each HW element shall meet the appropriate target values for the task it is responsible for (see ISO 26262-5 8.4.7).
For each SG either the item´s entire HW shall meet the LFM requirement or each HW element shall meet the appropriate target values for the task it is responsible for or it shall comply with the target values for diagnostic coverage (see ISO 26262-5 8.4.8).
A verification review report shall document the applied methods performed in order to provide evidence of its technical correctness and completeness in accordance with ISO 26262-8, clause 9.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.5 EVALUATION OF SAFETY GOAL VIOLATIONS DUE TO RANDOM HARDWARE FAILURES (ISO 26262-5 9)

Requirements of this clause have to be applied to ASILs B, C and D and are intended to provide criteria for rationales, that the residual risk of SG violation due to random HW failures of the item is sufficiently low. The evaluation shall be carried out either by the method of probabilistic metric of random HW failures (PMHF), or by individual evaluation of each residual and single-point fault, and of each dual-point failure leading to the violation of the considered safety goal. Acceptance criteria for SPFs of HW parts with ASIL C or D are described in ISO 26262-5 9.4.1.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.5.1 EVALUATION OF THE PROBABILISTIC METRIC OF RANDOM HARDWARE FAILURES (PMHF) (ISO 26262-5 9.4.2)

Quantitative target values for maximum probability of SG violation due to random HW failures shall be defined by deriving from the table below or from field data from similar well-trusted design principles or from quantitative analysis techniques. Target values are shown in the table below.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

QUANTITATIVE ANALYSIS OF HW ARCHITECTURE (ISO 26262-5 9.4.2.4)

Quantitative analysis of HW architecture considering single-point faults, residual faults, and dual-point faults has to provide evidence of target value achievement. This quantitative analysis shall consider:

Item architecture,
Estimated FR for failure modes of each HW part causing single-point fault, dual-point fault or residual fault,
Diagnostic coverage of safety-related HW elements by safety mechanisms,
Exposure duration in case of dual-point faults.

5.5.2 EVALUATION OF EACH CAUSE OF SAFETY GOAL VIOLATION (ISO 26262-5 9.4.3)

A method for evaluation of SG violation causes due to random HW failures is illustrated in flowcharts given in ISO 26262-5 9.4.3.1. SPFs are evaluated using fault occurrence criteria, residual faults are evaluated using criteria combining occurrence of fault and efficiency of safety mechanism. An individual evaluation of each SPF, RF and DPF violating a SG shall be performed at HW part level to provide evidence of accordance to requirements of ISO 26262-5 9.4.3 for SG violation.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

FAILURE RATE CLASSIFICATION (ISO 26262-5 9.4.3.3)

The failure rates ranking of HW parts corresponding to class i has to be less than or equal to ASIL D´s target value multiplicated with 10(i-3) with i as a natural number. For example, a failure rate corresponding to failure rate class 1 shall be less than the target for ASIL D divided by 100 (= D*10(1-3)). If justified, a failure rate class ranking may be divided by a number lower than 100.

SINGLE-POINT FAULT HANDLING (ISO 26262-5 9.4.3.5)

An SPF occurring in a HW part may only be considered as acceptable, if corresponding HW part failure ranking complies with targets given in the table below.

RESIDUAL FAULT HANDLING (ISO 26262-5 9.4.3.6)

An RF occurring in a HW part may only be considered as acceptable, if corresponding HW part failure ranking complies with targets given in the table below.

DUAL-POINT FAULT HANDLING (ISO 26262-5 )

A dual-point fault occurring in a HW part and contributing to a plausible dual-point failure shall be considered acceptable, if the corresponding hardware part complies with the targets for the failure rate class ranking and diagnostic coverage (with respect to latent faults) given in the table below.

5.5.3 VERIFICATION REVIEW (ISO 26262-5 9.4.4)

The analysis performed (one of both methods mentioned above, 5.5.1 or 5.5.2) shall be reviewed to provide evidence of its technical correctness and completeness, according to ISO 26262-8 clause 9.

Process: 07_HARDWARE, 09_VERIFICATION & VALIDATION.
Work products: \07_HARDWARE.

5.6 HW INTEGRATION AND VERIFICATION (ISO 26262-5 10)

Evidence of HW’s compliance with HW SReqs by testing. Integration and verification activities have to comply with ISO 26262-8 clause 9, coordinated by the integration and testing strategy (=plan) required in ISO 26262-4 7.4.1.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.6.1 HW TESTING METHODS (ISO 26262-5 10.4.4)

An appropriate combination of test cases listed in the table below might be sufficient to enable appropriate HW integration testing.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.6.2 COMPLETENESS AND CORRECTNESS OF HW (ISO 26262-5 10.4.5)

To verify completeness and correctness of safety mechanism implementation considering HW SReqs, HW integration and testing activities shall consider the table below.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

5.6.3 DURABILITY AND ROBUSTNESS OF HW (ISO 26262-5 10.4.6)

HW integration and testing activities shall verify HW robustness against external stresses considering methods in the table below.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

ISO 26262-6: PRODUCT DEVELOPMENT AT SOFTWARE LEVEL   

6.1 GENERAL TOPICS FOR PRODUCT DEVELOPMENT AT SW LEVEL (ISO 26262-6 5)

Planning and initiation of FS activities for SW development. If configurable SW is developed, consider ISO 26262-6, Annex C (6.8 Development of configurable softwarE). Activities shall be oriented towards V-model for SW development (ISO 26262-6 5.2 Figure 2).
For each SW development sub-phase, methods and corresponding tools, considering their application guidelines, shall be carried out.
Programming language shall be selected considering criteria as unambiguous definition, support for embedded real time SW, support for modularity abstraction and structured constructs. Modelling and coding guidelines shall address topics listed in the table below, to support design implementation correctness.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.2 SPECIFICATION OF SOFTWARE SAFETY REQUIREMENTS (ISO 26262-6 6)

Each SW-based function potentially violating a technical or functional safety requirement allocated to SW needs to be addressed by SReqs. Specifications of SW SReqs shall be derived from technical safety concept and system design, compliant with ISO 26262-4 6.4.1 and 6.4.3, considering:

Specification and management of SReqs,
Specified system and HW configurations,
HSI specification,
Relevant requirements of HW design specification,
Timing constraints,
External interfaces,
Each operating mode of vehicle/ system/ HW, having impact on SW.

SW SReqs and refined HSI requirements are to verify according to ISO 26262-8 clauses 8 and 9, showing compliance with technical SReqs, system design and consistency with HSI. Refined HSI specifications shall be verified jointly by responsible persons for system, HW, and SW development.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.3 SW ARCHITECTURAL DESIGN (ISO 26262-6 7)

The SW architectural design shall be developed realising the SW SReqs which shall be verified, either. The SW architectural design represents all SW components and their interactions in a hierarchical structure, including static aspects (interfaces) as well as dynamic aspects (process sequences, timing behaviour).

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.3.1 REQUIREMENTS TO SW ARCHITECTURAL DESIGN (ISO 26262-6 7.4)

The SW architectural design shall be described with appropriate levels of abstraction (see table below), to ensure that necessary information is captured for correct and efficient subsequent development activities. Attributes listed in ISO 26262-6 7.4.1 shall be considered, either.

In general, SW shall be verifiable, feasible, testable, maintainable, and, if configurable, suitable. To avoid failures resulting from high complexity, SW shall be modular, capsuled, and simple. This is to be realized by using principles listed in the table below.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

SW SAFETY ANALYSIS (ISO 26262-6 7.4.9 to 7.4.11)

Partitioning of SW architectural design may be used for implementation of freedom of interference between SW components. In this case, it shall be ensured that shared resources are used free from interference, SW partitioning is supported by dedicated HW features, SW implementing partitioning is developed according to highest ASIL of partitioned components and verification of SW partitioning during SW integration and testing is performed.
Safety analysis at SW level shall be carried out according to ISO 26262-9, clause 8, to identify/ confirm safety-related parts of SW, support specification, and verify efficiency of safety measures. An analysis of dependent failures according to ISO 26262-9 7 shall be carried out, if SW implementation relies on freedom from interference.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

SAFETY MECHANISMS AT SW LEVEL (ISO 26262-6 7.4.12)

If necessary, dependant on analysis results (see above), safety mechanisms for error detection and error handling shall be implemented and applied.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE, Safety_Analysis_Report.

RESOURCE ESTIMATION FOR SW OPERATION (ISO 26262-6 7.4.13)

Execution time, storage space and communication resources shall be estimated.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

SW ARCHITECTURAL DESIGN VERIFICATION (ISO 26262-6 7.4.14)

Verification of the SW architectural design, according to ISO 26262-8 9, shall be carried out using methods listed in the table below for demonstration of compliance with SW SReqs, compatibility with the target HW and adherence to the design guidelines.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE, Verification_Plan.

6.4 SW UNIT DESIGN AND IMPLEMENTATION (ISO 26262-6 6.8)

Specification of SW units according to SW architectural design and associated SW SReqs shall be performed as well as implementation of specified SW units and static verification of SW unit design and implementation.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.4.1 REQUIREMENTS TO SW DESIGN AND IMPLEMENTATION (ISO 26262-6 8.4.1 to 8.4.4)

To ensure that SW architectural design captures all necessary information for correct and effective subsequent SW development activities, it shall be described using notations listed in the table below. The specification of the SW units shall describe functional behaviour and internal design to the level of detail necessary for implementation.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

DESIGN PRINCIPLES FOR SW UNIT DESIGN (ISO 26262-6 8.4.5)

Design principles for SW unit design and implementation at source code level as listed below are to apply to achieve correct order of execution, consistency of SW-SW interfaces, correct data flow and control flow between and within SW units, simplicity, readability and comprehensibility, robustness, suitability for SW modification, and testability.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.5 SW-UNIT VERIFICATION (ISO 26262-6 9)

This clause aims to evidence compliance with SW unit specifications and absence of unwanted functionality. Thus, a procedure for testing the SW unit against its design specifications shall be established and tests be performed.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE.

6.5.1 REQUIREMENTS TO SW-UNIT VERIFICATION (ISO 26262-6 9.4)

SW unit verification shall be planned, specified, and executed according to ISO 26262-8 9. Therefore, appropriate combinations of methods listed in the table below shall be applied for demonstration of achievement of compliance with specifications. Test conditions shall correspond as close as possible to target environment.

Enabling appropriate test case specification for SW unit testing, test cases shall be derived from methods listed in the table below.

Evaluation of test case completeness and demonstration of absent of unwanted function-ality shall be executed by measuring structural coverage with metrics listed below. Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE, Verification_Plan.

6.6 SW INTEGRATION AND VERIFICATION (ISO 26262-6 10)

Integration of SW elements and demonstration of SW architectural design realisation by embedded SW is handled in this clause. Particular integration levels and interfaces between SW elements shall be tested against the SW architectural design. Test conditions shall correspond as close as possible to target environment.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE.

6.6.1 REQUIREMENTS TO SW INTEGRATION AND VERIFICATION (ISO 26262-6 10.4)

SW integration planning shall describe hierarchical integration steps considering functional dependencies and dependencies between SW integration and HW-SW integration. It shall be ensured that only specified functionalities are implemented and undesired functionalities are without impact on achievement of FS. Methods listed below shall be applied for integration to demonstrate compliance achievement with the SW architectural design, HSI specification, specified functionality, and property and effective safety measures to satisfy SReqs.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE.

TEST CASE SPECIFICATION AND EVALUATION (ISO 26262-6 10.4.3 to 10.4.5)

Enabling appropriate test case specification for SW integration testing, test cases shall be derived from methods listed in the table below.

Evaluation of test case completeness and demonstration of absence of unwanted functionality shall be executed by measuring structural coverage with metrics listed below. Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.7 TESTING OF EMBEDDED SW (ISO 26262-6 11)

Evidence of SW achieving SReqs in specified target environment without containing undesired functionalities.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.7.1 REQUIREMENTS TO SW TESTING (ISO 26262-6 11.4)

To verify embedded SW´s achievement of SReqs, tests listed below shall be executed. Tests have to be executed on target HW. Results have to be evaluated considering compliance with expected results, coverage of SW SReqs, pass or fail criteria.

Testing of embedded SW shall be performed using methods listed below.
To enable a suitable test case specification, test cases shall be derived by methods listed below.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE.

6.8 DEVELOPMENT OF CONFIGURABLE SOFTWARE (ISO 26262-6 Annex C)

The normative Annex C of ISO 26262-6 gives advice for development of configurable and calibratable software. The aim of those developments is to enable controlled changes in the SW behaviour according to ASIL rating and SReqs, dependent on the application. The environment for development of SW being configurable and calibratable shall be documented.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.8.1 REQUIREMENTS TO CONFIGURATION DATA (ISO 26262-6 Annex C C.4.1)

Configuration data shall be specified to ensure correct usage of configurable SW during SLC, containing:

Valid values of configuration data,
Intent and usage of configuration data,
Range, scaling, units,
Interdependencies between different elements of configuration data.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.8.2 VERIFICATION OF CONFIGURATION AND CALIBRATION DATA (ISO 26262-6 Annex C C.4.2)

Configuration data verification shall be carried out to ensure the usage of values within their specified range as well as the compatibility with other configuration data. Verification of those configurable SW shall be planned, specified, and executed according to ISO 26262-8 9. Configurable SW shall be verified for the configuration data set used for item development. For flow charts see figures C.2 and C.3 in ISO 26262-6 C.4.5.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE.

6.8.3 GENERATION AND SPECIFICATION OF CALIBRATION DATA (ISO 26262-6 Annex C C.4.6, C.4.7 and C.4.11)

Calibration data associated with SW components shall be specified to ensure correct operation and expected performance of configured SW. That contains:

Valid values of calibration data,
Intent and usage of calibration data,
Range, scaling, and units, if applicable, with their dependence on the operating state,
Known interdependencies between different calibration data,
Known interdependencies between configuration data and calibration data.

Calibration data shall comply with highest ASIL potentially being affected by calibration data. Generation and application of calibration data shall consider procedures for generation, generation tools and verification procedures.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

6.8.4 VERIFICATION OF CALIBRATION DATA (ISO 26262-6 Annex C C.4.8 and C.4.9)

Verification of specified calibration data shall be planned, specified and executed according to ISO 26262-8 9 to examine whether:

It complies with SW SReqs,
It complies with SW architectural design,
It is consistent and compatible with specification of other calibration data.

Calibration data released for production shall be verified to comply with own requirements (ISO 26262-6 Annex C C.4.6) and it provides specified safety-related SW functionalities.

Process: 08_SOFTWARE, 09_VERIFICATION & VALIDATION.
Work products: \08_SOFTWARE.

6.8.5 PROTECTION OF CALIBRATION DATA (ISO 26262-6 Annex C C.4.10)

For detection of unintended changes of safety-related calibration data, mechanisms for detecting those changes shall be applied (see table below).

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

ISO 26262-7: PRODUCTION AND OPERATION   

7.1 PROTECTION OF CALIBRATION DATA (ISO 26262-7 5)

This chapter focuses on the development and maintenance of production process for safety-related elements or items and the achievement of FS during the production process. Compliance with safety-related special characteristics during production is necessary for FS achievement.

Process: 11_PRODUCTION, 12_OPERATION.
Work products: \11_PRODUCTION.

7.1.1 PRODUCTION PLANNING (ISO 26262-7 5.4.1)

The production process shall be planned by evaluating the item and considering requirements listed in ISO 26262-7 5.4.1.1. The production plan shall describe production steps, sequences, and methods required for FS achievement:

Production process flow,
Production process instructions,
Production tools and means,
Implementation of traceability measures.

A procedure is to be defined to ensure correct SW and calibration data transfer to ECUs. Sequence and methods of control steps shall be described in the production control plan considering aspects listed in ISO 26262-7 5.4.1.5 and 5.4.1.6. If FS achievement can be improved by dedicated measures, they shall be taken (e.g. poka-yoke connectors).

Process: 11_PRODUCTION.
Work products: \11_PRODUCTION.

PRE-PRODUCTION (ISO 26262-7 5.4.2)

Pre-production process and control measures shall correspond to the target production process. Differences between shall be analysed to find out, which part of production process can be assessed at this stage to accelerate the release of the target production process.

Process: 11_PRODUCTION.
Work products: \11_PRODUCTION.

7.1.2 PRODUCTION (ISO 26262-7 6.4.1)

Process failures occurring while production shall be analysed according to their impact on FS, safety measures shall be taken and verified. Production process, tools and test equipment shall be evaluated regarding FS. Test equipment shall be controlled according to the implemented and applied quality management system.
It shall be ensured that only approved configurations are produced.
Changes to the production process after its beginning shall be handled according to ISO 26262-8 8 Change Management.

Process: 11_PRODUCTION.
Work products: \11_PRODUCTION.

7.2 OPERATION, SERVICE (MAINTENANCE AND REPAIR), AND DECOMMISSIONING (ISO 26262-7 6)

Specification of:

Customer information,
Instructions for maintenance and repair, and
Instructions for disassembly,

to maintain FS over the entire vehicle lifecycle are handled in this clause. During decommissioning, the phases “before disassembling”, “disassembling” and “after disassembling” can be distinguished. This clause only addresses those activities “before disassembling”.

Process: 12_OPERATION.
Work products: \12_OPERATION.

7.2.1 PLANNING OF OPERATION, SERVICE (MAINTENANCE AND REPAIR), AND DECOMMISSIONING (ISO 26262-7 5.4.3)

Operation, repair and maintenance processes shall be planned by evaluating the item considering requirements and measures listed in ISO 26262-7 5.4.3.1. Requirements to the maintenance plan and repair instructions are described in ISO 26262-7 5.4.3.3.
The required user information´s content is listed in ISO 26262-7 5.4.3.4. Amongst others, it shall include warnings, descriptions of relevant functions and customer actions to ensure controllability of the item.
Instructions for activities and measures to be applied before and during decommissioning to avoid SG violations due to decommissioning shall be developed (ISO 26262-7 5.4.3.5). If FS achievement can be improved by dedicated measures, they shall be taken (e.g. error logger for diagnosis simplification).

Process: 12_OPERATION.
Work products: \12_OPERATION.

7.2.2 OPERATION, SERVICE (MAINTENANCE AND REPAIR), AND DECOMMISSIONING (ISO 26262-7 7.4.1)

The field monitoring process shall be implemented as planned, according to ISO 26262-2 7.4.1.1. This aims to provide field data to be analysed for detection of present FS issues and, if found, to trigger actions addressing those issues. Furthermore, evidence is provided for later application of the proven in use argument to the item monitored.
Performance and documentation of maintenance, repair and decommissioning of the item shall comply with the maintenance plan and as well with the maintenance and repair instructions.

Process: 12_OPERATION.
Work products: \12_OPERATION.

ISO 26262-8: SUPPORTING PROCESSES   

Chapters 8 and 9 provide guidance for performance of activities expected by several requirements of ISO 26262 series of standards to be conducted.

8.1 INTERFACES WITHIN DISTRIBUTED DEVELOPMENTS (ISO 26262-8 5)

Description of procedures and allocation of associated responsibilities within distributed developments for items/ elements. Customer and supplier shall jointly comply with requirements of ISO 26262, responsibilities shall be agreed with by customer and supplier. Subcontracting is permitted, if all phases of the safety lifecycle comply to ISO 26262 requirements.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.1.1 APPLICATION OF REQUIREMENTS (ISO 26262-8 5.4.1)

Requirements of clause ISO 26262-8 5 shall apply to each item/ element developed according to ISO 26262, except off-the-shelf HW parts if either no specific HW SReqs are allocated to the HW part or off-the-shelf HW parts are qualified according to ISO 26262-8 12 or the HW part was developed as a safety element out of context (SEooC).

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.1.2 SUPPLIER SELECTION CRITERIA (ISO 26262-8 5.4.2)

Selection criteria shall include evaluation of supplier capability to develop and produce items/ elements of comparable complexity and ASIL, according to ISO 26262. Thus, a request for quotation from customer to supplier candidates shall include formal request to comply with ISO 26262, item definition or functional specification, safety goals and functional/ technical SReqs.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.1.3 INITIATION AND PLANNING OF DISTRIBUTED DEVELOPMENT (ISO 26262-8 5.4.3)

Costumer and supplier shall specify a Development Interface Agreement (DIA) described in ISO 26262-8 5.4.3.1. If the supplier conducts HARA, the costumer shall approve it. The party responsible for the item development creates the FS concept compliant with ISO 26262-3. Functional SReqs have to be agreed between both parties.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.1.4 EXECUTION OF DISTRIBUTED DEVELOPMENT (ISO 26262-8 5.4.4)

The customer shall support the supplier with all needed documents and information for safety-related development. The supplier shall report to the costumer each anomaly and deviation from the project plan, especially regarding FS. An agreement is to reach, which party performs which action, e.g. the safety validation.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.1.5 FUNCTIONAL SAETY ASSESSMENT IN A DISTRIBUTED DEVELOPMENT (ISO 26262-8 5.4.5)

One or more FS assessment(s) shall be carried out upon reaching defined milestones, including each phase of the item development. The responsibility for that shall be specified. The assessment report shall be available to both, supplier and customer.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.1.6 AGREEMENT FOR PRODUCTION, OPERATION, SERVICE AND DECOMMISSIONING (ISO 26262-8 5.4.6)

The supplier shall provide evidence to costumer that the process capability is being met and maintained compliant with ISO 26262. Responsibilities after release for production shall be allocated between customer and supplier.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.2 SPECIFICATION AND MANAGEMENT OF SAFETY REQUIREMENTS (ISO 26262-8 6)

Ensure correct specification of SReqs considering attributes and characteristics as well as consistent management of SReqs throughout the entire safety lifecycle.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.2.1 SPECIFICATION OF SAFETY REQUIREMENTS (ISO 26262-8 6.4.1)

For achievement of SReq characteristics listed in ISO 26262-8 6.4.2.4, SReqs have to be specified by combination of natural language and methods listed below.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.2.2 ATTRIBUTES AND CHARACTERISTICS OF SAFETY REQUIREMENTS (ISO 26262-8 6.4.2)

SReqs shall be unambiguously identifiable as SReqs, have a status, contain the ASIL, shall be tracable (which SReq are they derived from), and allocated to an item or element. Furthermore, SReqs have to be comprehensible, atomic, internally consistent, feasible, and verifiable.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.2.3 MANAGEMENT OF SAFETY REQUIREMENTS (ISO 26262-8 6.4.3)

SReqs shall have following attributes:

Hierarchical structure,
Organisational structure, according to a grouping scheme,
Completeness,
External consistency,
No duplication of information within any structure level,
Maintainability, and
Traceability.

Methods for SReq verification are listed below and shall be applied in an appropriate combination.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.3 CONFIGURATION MANAGEMENT (ISO 26262-8 7)

Configuration management shall be planned and comply with respective requirements of quality management system and specific requirements for SW development according to IATF 16949, ISO 10007 or ISO/IEC 12207.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.4 CHANGE MANAGEMENT (ISO 26262-8 8)

Change management analyses and controls changes to safety related work products throughout the entire safety lifecycle. Change management ensures systematic planning, control, monitoring, implementation and documentation of changes while maintaining consistency of each work product.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.4.1 PLANNING AND INITIATING CHANGE MANAGEMENT (ISO 26262-8 8.4.1)

The change management process shall be planned before changes to work products are made. WPs to be subjected to change management shall be identified. Change management process shall include:

Change requests, according to ISO 26262-8 8.4.2,
Analysis of change requests, according to ISO 26262-8 8.4.3,
Decisions and rationale regarding change requests, according to ISO 26262-8 8.4.4,
Implementation and verification of accepted changes, according to ISO 26262-8 8.4.5, and
Documentation of the change management process and its results, according to ISO 26262-8 8.4.5.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.4.2 CHANGE REQUEST (ISO 26262-8 8.4.2)

A unique identifier is to assign to each request, as minimum date, reason, exact description and configuration the request is based on.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.4.3 CHANGE REQUEST ANALYSIS (ISO 26262-8 8.4.3)

An impact analysis shall be carried out for the involved item, interfaces, and connected items. Each work product change has to initiate the return to the applicable phase of the safety lifecycle.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.4.4 CHANGE REQUEST EVALUATION (ISO 26262-8 8.4.4)

A change request is to be evaluated using results of the impact analysis in compliance with ISO 26262-8 8.4.3.1. A decision regarding change acceptance, rejection, or delay shall be made by authorised persons as well as responsibility for change performance and date.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.4.5 CHANGE PERFORMANCE AND DOCUMENTATION (ISO 26262-8 8.4.5)

If a change has an impact on safety-related functions, the FS assessment and applicable confirmation reviews shall be updated before the item´s release. Change documentation shall contain a list of changed work products, details of change carried out, and planned date for change deployment. Furthermore, all aspects handled in this chapter shall be documented.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.5 VERIFICATION (ISO 26262-8 9)

The compliance of work products with their requirements shall be verified. This is applicable in all phases of the entire safety lifecycle.

Process: 09_VERIFICATION & VALIDATION.
Work products: 09_VERIFICATION.

8.5.1 VERIFICATION PLANNING (ISO 26262-8 9.4.1)

Verification planning shall be carried out for each (sub-)phase of the safety lifecycle, addressing the:

Content of the work product,
Verification methods,
Pass and fail criteria,
Verification environment,
Equipment and resources needed for verification,
Actions to be taken in case of detected anomalies, and
Regression strategy.

Process: 09_VERIFICATION.
Work products: 09_VERIFICATION.

8.5.2 VERIFICATION SPECIFICATION (ISO 26262-8 9.4.2)

Verification specification means detailing performance and evaluation of the verification process. It shall select and specify verification methods including either review or analysis checklists, or simulation scenarios or test cases, test data and test objects (see ISO 26262-8 9.4.2).
For testing, specifications of test scenarios shall contain unique identification, reference to the version of the associated work product to be verified, preconditions and configurations, environmental conditions, input data, expected behaviour which includes output data, acceptable ranges of output values, time behaviour, and tolerance behaviour. Test cases shall be grouped concerning test environment, logical and temporal dependencies, and resources.

Process: 09_VERIFICATION.
Work products: 09_VERIFICATION.

8.5.3 VERIFICATION EXECUTION AND EVALUATION (ISO 26262-8 9.4.3)

Verification shall be executed as planned and specified in accordance with ISO 26262-8 9.4.1 and 9.4.2. Its evaluation shall contain:

Unique identification of verified work product,
Reference to the verification plan and specification,
Configuration of verification environment and verification passed or failed,
Compliance level of verification results with expected results,
Unambiguous statement of verification passed or failed, and
Reasons for not executed verification steps.

Process: 09_VERIFICATION.
Work products: 09_VERIFICATION.

8.6 DOCUMENTATION (ISO 26262-8 10)

The documentation management strategy for the entire SLC shall be developed and aims to facilitate an effective and repeatable documentation management process (focus on information, not layout or medium). Duplicated information within a document as well as between documents shall be avoided (difficult to maintain).

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.6.1 REQUIREMENTS FOR DOCUMENTATION (ISO 26262-8 10.4)

The documentation process shall be planned to make documentation available during each phase of the entire safety lifecycle, for FS management, as an input to confirmation measures. Documentation has to be precise and concise, structured in clear manner, easy to understand by intended users, verifiable, and maintainable.
Each work product has to be associated with title (referring to scope of content), author and approver, unique identification of each different revision, change history, and status. A document management tool or chart might be helpful.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.7 CONFIDENCE IN THE USE OF SOFTWARE TOOLS (ISO 26262-8 11)

Providing criteria to determine required level of confidence in SW tools and means for qualification of SW tools is handled by ISO 26262-8 11. If SW output is not examined for each applicable process step, SW tool shall be confidential. Was a confidence level evaluation or qualification of a SW tool performed independently from the particular development of a special item/ element, the validation shall be confirmed for the intended use case. SW tool usage shall be planned, according to ISO 26262-8 11.4.4.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.7.1 SW TOOL COMPLIANCE WITH ITS EVALUATION CRITERIA OR ITS QUALIFICATION (ISO 26262-8 11.4.3)

SW tools used for development of safety-related components shall be used compliant to their environmental and functional constraints as well as to their general operating conditions.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.7.2 PLANNING OF USAGE OF A SW TOOL (ISO 26262-8 11.4.4)

SW tool usage shall be planned. This planning shall contain:

Identification and version number of SW tool,
Configuration of SW tool,
Use cases of SW tool,
Environment for execution of SW tool (required and applied),
The maximum ASIL of all SReqs, allocated to item or elements potentially being affected, if SW tool generates erroneous output, and
Methods to qualify the SW tool.

Further descriptions are to be read in ISO 26262-8 11.4.4.2.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.7.3 EVALUATION OF SW TOOL BY ANALYSIS (ISO 26262-8 11.4.5)

The usage of a SW tool shall be described, compliant to ISO 26262-8 11.4.5.1. The analysis of the intended usage shall result in a Tool Impact classification (TI) and a Tool error Detection level (TD), which determine the Tool Confidence Level (TCL) together (table below).

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.7.4 QUALIFICATION OF A SW TOOL (ISO 26262-8 11.4.6)

For TCL1 classified SW tools, no qualification method is needed. For TCL2 and TLC3 classified SW tools, methods listed in the table below are to apply. Documentation of SW tool qualification shall comply with ISO 26262-8 11.4.6.2.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.7.5 INCREASED CONFIDENCE FROM USE (ISO 26262-8 11.4.7)

A SW tool shall only be argued as having increased confidence from use, if evidence is provided for:

SW tool previously was used for same purpose,
Justification for increased confidence from use is based on sufficient adequate data,
SW tool specification is unchanged, and
Occurrence of malfunctions and corresponding erroneous outputs are accumulated/ documented in a systematic way.

Increased confidence from use only is valid for the considered version of SW tool.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.7.6 EVALUATION AND VALIDATION OF THE SW TOOL (DEVELOPMENT PROCESS) (ISO 26262-8 11.4.8 and 11.4.9)

See ISO 26262-8 11.4.8 and 11.4.9. The aim is to check confidence of SW tool in different ways (by tool validation or development process evaluation), if necessary.

Process: 09_VERIFICATION.
Work products: 09_VERIFICATION.

8.8 QUALIFICATION OF SW COMPONENTS (ISO 26262-8 12)

Provide evidence for suitability of SW component reuse in items developed compliant to ISO 26262.
For considering a SW component as qualified, it shall be available:

SW component specification,
Evidence that SW component is suitable for intended use,
Evidence that SW component complies with its requirements,
Evidence that SW development process for component is based on appropriate standards, and
A qualification plan for SW component.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

8.8.1 SW COMPONENT QUALIFICATION PLANNING (ISO 26262-8 12.4.2)

Planning of SW component qualification shall determine different aspects to ensure each relevant detail is considered during qualification. Amongst others, this contains unique identification of the SW component, maximum target ASIL of any SReqs potentially violated by incorrect SW performance and activities to be carried out for SW component qualification.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

8.8.2 QUALIFICATION OF A SW COMPONENT (ISO 26262-8 12.4.2.5)

SW components shall be qualified as described in ISO 26262-8 12.4.2.5.

Process: 08_SOFTWARE.
Work products: \08_SOFTWARE.

8.8.3 VERIFICATION OF QUALIFICATION OF A SW COMPONENT (ISO 26262-8 12.4.3)

According to ISO 26262-8 12.4.3, the SW component qualification shall be verified together with its result´s validity. Consider ISO 26262-8 12.4.2.2 to 12.4.2.5.

Process: 09_VERIFICATION.
Work products: 09_VERIFICATION.

8.9 EVALUATION OF HW COMPONENTS (ISO 26262-8 13)

Provide evidence of suitability of HW components and parts to their use in safety-related items and systems. Goals to be achieved are:

Adequate functional performance,
Identification of failure modes and models,
Identification or confirmation of limits for use of HW components, and
Provide an argument for risk of SG violation due to random HW failure or that the systematic failure is sufficiently low.

See ISO 26262-8 13.4, also. The evaluation report shall state whether part/ component passed or failed the evaluation.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

8.9.1 HW COMPONENTS CLASSIFICATION (ISO 26262-8 13.4.1)

Class I: simple component with only a few states to be characterised (resistor, capacitor, transistor, diode, quartz, resonator).

Class II: intermediate component with a few operating modes, small value ranges and few parameters which can be analysed without knowing implementation details (fuel pressure sensor, temperature sensor, stand-alone Analog Digital Converter (ADC) without internal safety mechanisms relevant for the safety concept).

Class III: complex component with many operating modes, wide value ranges and many parameters impossible to analyse without knowledge of implementation details (Micropro-cessor, microcontroller, Digital Signal Processor).

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

8.9.2 EVALUATION OF CLASS I HW ELEMENTS (ISO 26262-8 13.4.2)

Since the HW component is quite simple, it is sufficient to evaluate it integrated in the next higher complex part.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

8.9.3 EVALUATION OF CLASS II HW ELEMENTS (ISO 26262-8 13.4.3)

Evaluation shall be performed by using the methods testing or analysis, as required in ISO 26262-8 13.4.3.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

EVALUATION PLAN (ISO 26262-8 13.4.3.2)

The Evaluation process shall be planned, containing:

Unique identification and version of HW component/ part,
Specification of environment component/ part is intended to be used in,
Evaluation strategy and rationale,
Necessary tools and equipment,
Party responsible for strategy performance, and
Pass/ fail criteria used to assess qualification of HW part/ component.

EVALUATION ARGUMENT (ISO 26262-8 13.4.3.3)

The HW component or part shall comply with its specification in the reuse application. Thus, a comprehensive argument that the performance of HW component or part complies with its specification shall be made available. It shall be based on a combination of analytical methods, data from operational experience and existing testing results. Assumptions shall be justified.

EVALUATION BY ANALYSIS (ISO 26262-8 13.4.3.4)

The analysis shall be expressed in a comprehensible way. Environmental target conditions, their limits and additional stresses related to operation shall be considered. It shall be figured out whether the component or part is appropriate for its intended reuse case.

EVALUATION BY TESTING (ISO 26262-8 13.4.3.5)

A test plan shall be developed, according to ISO 26262-8 13.4.3.5.1. Testing aims to verify the HW´s robustness against external stresses. It shall be figured out whether the component or part is appropriate for its intended reuse case.

EVALUATION REPORT (ISO 26262-8 13.4.3.6)

The evaluation report shall state pass or fail of the HW component in the evaluation process. The report shall be verified according to ISO 26262-8 9.

8.9.4 EVALUATION OF CLASS III HW ELEMENTS (ISO 26262-8 13.4.4)

Class III HW should be developed according to ISO 26262 FS requirements. If not, requirements stated in ISO 26262-8 13.4.3 (8.9.3 Evaluation of class II HW elements (ISO 26262-8 13.4.3)) shall be met. It shall be argued (e.g. by measures), why the risk of SReq violation due to systematic faults is sufficiently low.

Process: 07_HARDWARE.
Work products: \07_HARDWARE.

8.10 PROVEN IN USE ARGUMENT (ISO 26262-8 14)

An alternate means of compliance to ISO 26262 is used in case of reuse of existing items/ elements with available field data. This argument is applicable for products (and their work products), which are identical or have a high degree of commonality with a product already released and operating. Since a sufficient amount of statistic data and field data is needed to use this method, it is mostly inappropriate.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.10.1 PROVEN IN USE CREDIT (ISO 26262-8 14.4.2)

A credit is to apply only on safety lifecycle sub-phases covered by the proven in use argument of the candidate. Safety validation of items with embedded proven in use elements are to carry out compliant with ISO 26262-2 6.4.5. Any changes to a proven in use item/ element shall comply with ISO 26262-8 14.4.4 for the corresponding credit to be maintained.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.10.2 MINIMUM INFORMATION ON CANDIDATE (ISO 26262-8 14.4.3)

A description of the previous candidate use has to be available including:

Identification and traceability of the candidate with catalogue of internal components/ elements,
Corresponding FIT,
Form and function requirements describing interface(s) and performance characteristics, and
SReqs of the candidate in previous use with corresponding ASILs.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.10.3 ANALYSIS OF MODIFICATIONS TO CANDIDATE (ISO 26262-8 14.4.4)

Changes to the candidate and its environment are to be identified. If introduced by purpose for future application, changes have to comply with ISO 26262-2 6.4.3 or 6.4.4. When changes are made independent of future use, evidence of remaining validity of the proven in use status is required.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.10.4 ANALYSIS OF FIELD DATA (ISO 26262-8 14.4.5)

When evidence of persistent configuration and change management is available, the current state of the candidate can be established.
The calculated evaluation period shall be justified and result from addition of observation periods of all specimens taken.
For proven in use status to be obtained by the candidate, its evaluation period shall demonstrate compliance with each safety goal that can be violated by the candidate in accordance with the table below with a single-sided lower confidence level of 70 % (using a chi-square distribution) (see ISO 26262-8 14.4.5.2.4 to 14.4.5.2.7).

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

FIELD PROBLEMS (ISO 26262-8 14.5.4.3)

An implemented problem reporting system shall ensure that any observed incident which is caused by the candidate in field and potentially impacts a SG gets recorded and is retrievable during the operation period of the candidate.

Process: 01_MANAGEMENT.
Work products: \01_MANAGEMENT.

8.11 INTERFACING AN APPLICATION THAT IS OUT OF SCOPE OF ISO 26262 (ISO 26262-8 15)

This chapter applies to trucks and busses developed according to ISO 26262, whose applications are not in scope of ISO 26262. The manufacturer/ supplier of the base vehicle (developed according to ISO 26262) shall communicate all necessary details to the integrator which are needed to keep functional safety achieved.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

8.12 INTEGRATION OF SAFETY-RELATED SYSTEMS NOT BEING DEVELOPED ACCORDING TO ISO 26262 (ISO 26262-8 16)

This chapter applies to trucks and busses developed according to ISO 26262, incorporating components not being developed according to ISO 26262. It shall be justified, how the integrated item is able to satisfy FS requirements. Thus, the integrator and supplier shall agree on a relevant set of measures to ensure that criteria are met.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

ISO 26262-9: ASIL- AND SAFETY-ORIENTED ANALYSES   

Chapters 8 and 9 provide guidance for performance of activities expected by several requirements of ISO 26262 series of standards to be conducted.

9.1 REQUIREMENTS DECOMPOSITION CONSIDERING ASIL TAILORING (ISO 26262-9 5)

ISO 26262-9 5 provides rules and guidelines for SReq and ASIL tailoring (decomposition). During the allocation process, benefit can be obtained from architectural decisions including the existence of sufficiently independent architectural elements. This offers the opportunity to satisfy safety requirements by these independent architectural elements, and to assign a potentially lower ASIL to these decomposed safety requirements.

Process: 02_SUPPORT.
Work products: \06_SYSTEM.

9.1.1 REQUIREMENTS AND RECOMMENDATIONS (ISO 26262-9 5.4)

ASIL decomposition is to perform considering each initial SReq individually. Initial SReqs shall be decomposed to redundant SReqs implemented by sufficient independent elements. Each decomposed SReq shall comply with SReqs initialized by itself.

Process: 02_SUPPORT.
Work products: \06_SYSTEM.

ASIL DECOMPOSITION (ISO 26262-9 5.4.6 to 5.4.12)

Rules for ASIL decomposition as paragraphs and flow charts with examples are given in ISO 26262-9 5.4.6 to 5.4.12.

9.2 CRITERIA FOR COEXISTENCE OF ELEMENTS (ISO 26262-9 6)

Providing criteria for coexistence within the same element of safety-related sub-elements with sub-elements without ASIL and SR subelements having different ASILs.
In case of the coexistence of sub-elements of an item that have different ASILs assigned or the coexistence of sub-elements of an item that have no ASIL assigned with safety-related ones, it can be beneficial to avoid raising the ASIL for some of them to the (highest) ASIL of the element (effort and costs). For this purpose, this clause provides guidance for determining the ASIL of sub-elements of an element. This clause is based on the analysis of interference of a sub-element with the other sub-elements of an element.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

9.2.1 REQUIREMENTS (ISO 26262-9 6.4)

SReqs are to allocate to sub-elements of element before applying the following.
During element analysis, each SReq allocated to the element and each sub-element that is part of the element is to be considered. If sub-elements of different ASIL are coexisting in the same item, evidence shall be given that no interference of lower ASIL sub-elements on higher ASIL sub-elements exists. Otherwise, each sub-element is to assign with the highest existing ASIL in the item.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

9.3 ANALYSIS OF DEPENDENT FAILURES (ISO 26262-9 7)

The aim of this chapter is the confirmation that required independencies or freedom from interference between sub-elements/ components/ failures are achieved or otherwise to define appropriate measures to mitigate plausible dependent failures.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

9.3.1 REQUIREMENTS (ISO 26262-9 7.4)

The potential of failures to be dependent can be derived from results of safety analyses, acccording to ISO 26262-9, clause 8. Each identified potential is to be evaluated to determine its plausibility (existence of a foreseeable cause for a dependent failure). Evaluation shall consider (if applicable):

Random HW failures,
Development faults,
Manufacturing faults,
Installation faults,
Service faults,
Environmental factors,
Failures of common external factors,
Failures of common external resources,
Stress due to specific situations,
Aging, and
Wear.

A rationale for the plausibility of dependent failures and impact is to provide.
Measures against independent failures are to specify during the development phase. The analysis results shall be verified according to ISO 26262-8 9 to ensure their plausibility.

Process: 02_SUPPORT.
Work products: \02_SUPPORT.

9.4 SAFETY ANALYSES (ISO 26262-9 8)

According to ISO 26262-9 8, safety analyses aim to ensure that the risk of SG violation due to random HW faults and systematic faults is sufficiently low. According to the note in ISO 26262-5 9.1, sufficiently low means a residual risk comparable to the ones of items in use which are known to be safe.

Process: 02_SUPPORT, 06_SYSTEM, 07_HARDWARE, 08_SOFTWARE.
Work products: \06_SYSTEM, \07_HARDWARE, \08_SOFTWARE.

9.4.1 REQUIREMENTS (ISO 26262-9 8.4)

Safety analysis results shall indicate, whether respective SGs or SReqs are complied with. If not, results are to use for deriving prevention, detection or effect mitigation measures.
Fault models used for safety analyses shall be consistent with appropriate development sub-phases.
According to ISO 26262-9 8.4.9, qualitative safety analyses shall include:

Systematic identification of faults or failures,
Evaluation of fault consequences,
Identification of fault causes, and
Identification of potential safety concept weakness.

If applicable, according to ISO 26262-9 8.4.10, quantitative safety analyses shall include:

Quantitative data for support of evaluations,
Systematic identification of faults leading to SG violation,
Evaluation and ranking of potential safety concept weaknes, and
Several time intervals.

Safety analyses results shall be verified, according to ISO 26262-8 9.

Process: 02_SUPPORT, 06_SYSTEM, 07_HARDWARE, 08_SOFTWARE.
Work products: \06_SYSTEM, \07_HARDWARE, \08_SOFTWARE.