|
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.
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.
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.
Assurance of adequate qualification of responsible persons in the safety lifecycle. Process:
01_MANAGEMENT.Work products:
\01_MANAGEMENT.
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.
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.
Safety management roles and responsibilities shall be defined. The requirements to the safety management shall be defined, too. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.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.
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.
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.
FS requirements shall be allocated to elements of the item. Process: 05_CONCEPT.Work products:
\05_CONCEPT.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 conceptRelevant operation modes and configuration parametersHW ensuring independence between SW and HWShared and exclusive HW useAccess mechanism to HWTiming 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.
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.
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.
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.
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.
HW and SW shall be integrated to get tested. Process: 06_SYSTEM.Work products: \06_SYSTEM.
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. 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.
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. 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.
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. 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.
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.
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.
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.
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.
Development and verification of HW design architecture needs to be compliant with sys-tem specifications and SReqs. Process: 07_HARDWARE.Work products: \07_HARDWARE.
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.
For avoidance of systematic faults, HW design has to show modularity, adequate granularity and simplicity by using principles listed in the table below. 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.
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.
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. 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.
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.
Evaluation of the item´s HW architecture against fault handling requirements (= HW architectural metrics). Process: 07_HARDWARE.Work products: \07_HARDWARE.
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.
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. 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. 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.
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.
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 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.
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.
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. 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. 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. 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. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Execution time, storage space and communication resources shall be estimated. Process: 08_SOFTWARE.Work products: \08_SOFTWARE.
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.
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.
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 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.
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.
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.
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.
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.
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.
Evidence of SW achieving SReqs in specified target environment without containing undesired functionalities. Process: 08_SOFTWARE.Work products: \08_SOFTWARE.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
Specification of: Customer information,Instructions for maintenance and repair, andInstructions 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.
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.
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.
Chapters 8 and 9 provide guidance for performance of activities expected by several requirements of ISO 26262 series of standards to be conducted. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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, andTraceability.
Methods for SReq verification are listed below and shall be applied in an appropriate combination. Process: 02_SUPPORT.Work products:
\02_SUPPORT.
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.
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.
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, andDocumentation of the change management process and its results, according to ISO 26262-8 8.4.5.
Process: 01_MANAGEMENT.Work products:
\01_MANAGEMENT.
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.
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.
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.
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.
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.
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, andRegression strategy.
Process: 09_VERIFICATION.Work products:
09_VERIFICATION.
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.
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, andReasons for not executed verification steps.
Process: 09_VERIFICATION.Work products:
09_VERIFICATION.
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.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.
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.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.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, andMethods 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.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.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.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, andOccurrence 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.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.
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, andA qualification plan for SW component.
Process: 08_SOFTWARE.Work products:
\08_SOFTWARE.
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.
SW components shall be qualified as described in ISO 26262-8 12.4.2.5. Process: 08_SOFTWARE.Work products:
\08_SOFTWARE.
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.
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, andProvide 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.
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.
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.
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.
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, andPass/ fail criteria used to assess qualification of HW part/ component.
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. 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. 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. 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. 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.
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.
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.
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, andSReqs of the candidate in previous use with corresponding ASILs.
Process: 01_MANAGEMENT.Work products:
\01_MANAGEMENT.
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.
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.
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.
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.
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.
Chapters 8 and 9 provide guidance for performance of activities expected by several requirements of ISO 26262 series of standards to be conducted. 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.
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.
Rules for ASIL decomposition as paragraphs and flow charts with examples are given in ISO 26262-9 5.4.6 to 5.4.12. 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.
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.
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.
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, andWear.
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.
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.
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, andIdentification 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, andSeveral 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.
|