There are four ASILs - ASIL-D, ASIL-C, ASIL-B , ASIL-A, NO ASIL (QM)in ISO 26262.

ASIL-D is highest, ASIL-A is lowest, QM (quality management) denotes no requirement to comply with ISO 26262.

QM (quality management) denotes no requirement to comply with ISO 26262.

Systems falling in QM category do not have to comply with any specific objectives in ISO 26262 because the risks associated are acceptable for safety. The QM systems just need to follow quality management process such as ISO 9001, ISO/TS 16949 etc.

The ISO 26262, 2011 edition has 10 parts as follows:

• Part 1 on Terms and definitions
• Part 2 onFunctional safety Management
• Part 3: Concept phase
• Part 4: System level development
• Part 5: Hardware level development
• Part 6: Software level development
• Part 7: Production and operation
• Part 8: Supporting processes
• Part 9: ASIL-oriented and safetyanalyses
• Part 10: Guideline on ISO 26262

ISO 26262 Part 2 is on Functional safety management (FSM) entailing the Safety culture, Quality management system,Organization level roles and responsibilities for safety management, Safety plan, Safety case and Confirmation measures(Confirmation reviews, Functional Safety Audit, Functional Safety Assessment).

Safety plan is prepared at the inception of development to list all the safety activities to be performed during the development cycle along with the corresponding methods, measures, tools, resources, prerequisites, ownership details etc. required to carry out these tasks.It is planned at all levels of development, the plans are Overall Safety plan (at management level), System safety plan, Hardware safety plan and Software safety plan. The safety plan is tracked and managed throughout development by the Safety manager.

During hazard analysis and risk assessment, credit can be taken for the actions of the vehicle driver or other traffic participants to avert the hazard and reduce risk of harm. This factor is called controllability. However, it needs to be validated during Safety validation phase at the end of development.

Each hazard identified by HARA is assigned with a controllability rating ranging from C0 to C3.

External measures are the elements of the functional safety concept that lie outside the boundary of the ISO 26262 item. They contribute to the safety concept but need to be validated during Safety validation phase at the end of development.

E.g. devices external to the vehicle, like crash barriers.

Elements of other technologies are the elements of non-E/E technology e.g. mechanical, hydraulic, pneumatic etc. that contribute to the functional safety concept. The contribution however needs to be validated during Safety validation phase at the end of development. These elements do not come under the scope of ISO 26262.

Verificationreviews are performed for selected Work Products as specified in ISO 26262 Part 2.These reviews are intended to verify that these work products meet the projectrequirements, and the technical requirements.

• Prepare safety plan, manage, and track its progress throughout the ISO 26262 safety life cycle
• Safety anomaly resolution

An argument stating how the safety case – compilation of all Work products generatedduring the safety lifecycle, meets the Safety goals.

• Confirmation reviews – checks if the Work Products conform to the corresponding ISO 26262 requirements ( ASIL A, B, C or D)
• Functional Safety Audit – checks if the implementation of the process is in accordance with activities process specified in Safety plan ( ASIL (B) (optional), C or D)
• Functional Safety Assessment – assesses the functional safety achieved by the item ( ASIL (B), C or D)

Confirmation reviews check if the select work products identified by ISO 26262 meet the corresponding requirements for form, contentetc.

The level of independency required for the review depends on the ASIL.

It is to check if the implementation of processes required for functional safety is as per the safety plan.

ISO 26262 Part 3 is on the Concept phaseof product development entailing theItem Definition of the ISO 26262 item, Hazard analysis and Risk assessment (HARA) to derive Safety goals and their attributes, including ASIL and Functional safety concept including functional safety requirements

Item definition is an important artefact that needs to be prepared by OEM/Tier1 which holds. The item definition contains functional requirements, non-functional requirements, environment requirements, regulatory requirements and known failure modes.

In HARA phase, performssituation analysis(operational and environmental)and Hazard identification in each of these situations in the item.Classify the hazardous events and assign severity (i.e. effect on driver, passenger, pedestrians), probability of exposure (i.e. occurrence) and controllability (possible control by driver or other passengers at risk)

Hazards are classified based on the severity (i.e. effect on driver, passenger, pedestrians), probability of exposure (i.e. occurrence)and controllability (possible control by driver or other passengers at risk)

ASILs are assigned as per ISO 26262 standard based on the Severity, Probability of exposure and controllability ratings.

Severity is assigned to a hazard during HARA depending on the effect of the hazard on the vehicle driver, passengers, and other traffic participants. It ranges from S0 to S3.

Probability of exposure is assigned to a hazard during HARA depending on the frequency of the situation (operational or environmental) exposing to risk (of hazard) or the duration of exposure to the same. It ranges from E0 toE4.

Each hazardous event is translated to a Safety goal which represent the top-level safety requirements for the item.One safety goal can be related to several hazardsand several safety goals can be related to a single hazard.

Each safety goal is associated with attributes such as ASIL, FTTI (Fault tolerance time interval), Safe state etc.

Safety goals are not technological solutions, but functionalobjectives.

E.g. Unintended deactivation of low beam headlamp shall be detected and prevented.

ASIL–ASIL is derived based on the severity, probability of exposure and controllability ratings for each Safety goal as per the standard

Safe state – a state of the item in which the safety goal violation is prevented e.g. switched off, locked, and maintained functionality in the case of a failure over a defined time.

FTTI – Fault tolerant time interval – maximum time interval for which a fault(s) can reside in a system before a hazardousevent or safety goal violation occurs i.e. the fault(s) must be detected and safe state achieved (fault(s) removed)within FTTI.

Condition to be met: Diagnostic test interval + Fault reaction time <= FTTI, for every Safety goal

The objective of the functional safety concept is to derive the functional safety requirements (FSR), from the safety goals, and to allocate them to the preliminary architectural elements of the item, or to external measures.The FSC contains safety mechanisms, to be implemented in the architecture and specified in the FSRs.The functional safety concept addressesFault detection and mitigation mechanism, Fault tolerance, Fault tolerant time interval, Interface between elements within the item and elements in other technology and Functional redundancy

• Feedback/Loop back:Feedback is used for fault detection. Loop back is an application of feedback that is used for the purpose of self-testing.
• Partitioning: Partitioning technique is used to prevent fault propagation, which in turn also prevents cascaded failures.
• Redundancy:Redundancy is used when the safety goal is about the availability of the function i.e. to prevent unintended deactivation.
• Dissimilar HW or SW: Dissimilar SW or HW is used prevent common cause failures in redundant systems, arising from the use of same or similar SW or HW.
• Interlocks: Interlocking is used to reduce the probability of safety goal violation by interlocking the intended functionality with another functionality.

ISO 26262 Part 4 is on Product development at the system level entailing theSpecification of Technical safety requirements , System design Specification, Technical Safety concept, System design safety analysis (System FMEA), Hardware software interface specification (HSIS), Item integration testing and Functional Safety assessment

Technical safety requirements (TSR)are derived from the Functional safety concept, External interfaces, constraints(environmental or functional) and system configuration(s).The TSRs specify safety-related dependencies between Systems or Elements within an item, safety mechanisms (detection, indication and control) for faults internal to system and external, Safe state, FTTI, Emergency time interval for each safety mechanism and mechanism to avoid Latent faults.

The conditions for transitioning, switching to the safe state and recovering from the safe state are described in the warning and degradation concept.E.g. Fault detection and failure mitigation by switching to a safe state, anddriver warning to reduce the exposure time e.g. engine malfunction indicator lamp.

System design is developed based on functional safety requirements, Functional safety preliminary architecture (FSA) and Technical safety requirements (TSR. System design elements (HW and SW) are chosen based on their technical capability to achieve functional safety. System design covers Measures to avoidsystematic failures are considered to assist the design process. System FMEA analysis is performed to identify such measures.

is Technical Safety concept in ISO 26262? Technical safety concept (TSC) is theallocation of Technical Safety Requirements(TSRs)to the system elements (HW, SW).

System design safety analysis is performed to identify and eliminate internal and external causes of systematic failures or mitigate their effects.Inductive analysis method i.e.System FMEA is used to analyzethese failuresusing J1739 standard. System Block diagram (B-diagram) and Parameters diagram (P-diagrams) are used to assist the analysis.

Inductive analysis method i.e. System design FMEA is used to analyzesystematic failuresoccurringin the system design using standard e.g. J1739.The analysis is used to identify and eliminate internal and external causes of systematic failures or mitigate their effects.The same analysis can later be used for Verification of system design.

The HSIS specifies the hardware and software interaction as per the technical safety concept. It includes the hardware devices that are controlled by software and hardware resources that support the execution of software.It specifies the diagnostic capabilities of the hardware and their use by the software.

Integration testing activities are performed to prove that the system design complies with its technical and functional safety requirements. It consists of three phases of integration (1) Hardware software integration (Integration of the hardware and software of each element that the item comprises) (2) System integration( Integration of the elements that comprise an item to form a complete system) (3) Vehicle integration (Integration of the item with other systems within a vehicle and with the vehicle itself).

An Item integration and testing plan is prepared based on the system design specification, the functional and technical safety concept such that test goals are covered sufficiently. It covers both E/E elements and elements of other technologies considered in the safety concepts.The system and vehicle level integration and testing plan considers interfaces between vehicle sub-systems and the environment.The verification of the interface of the item with the in-vehicle communication network and the in-vehicle power supply network isplanned.

Safety validation provides evidence that safety goals are correct, complete and fully achieved at the vehicle levelfor a class or set of vehicles.It validates the item integrated in representative vehicle(s) which provides evidence of appropriateness of the safety goals for the intended use.

The validation plan consists of Configuration of the item to be validated including its calibration data, Specification of test cases, pass/fail criteria etc. for each safety goal, Equipment, required environmental conditions, operational use cases, and Validation methodse.g. testing, analyses etc.

Testing (Similar to vehicle level testing) , Analyses (FMEA, FTA, ETA, simulation) and Reviews

The safety goals of the ISO 26262 item are validatedfor the intended use at the vehicle level by evaluating the effectiveness of safety measures in controlling random and systematic failures (including controllability, external measures, elements of other technologies).Validation report is prepared capturing the above results and is evaluated

The purposeis to assess the functional safety that is achieved by the item.It can be done progressively during development, or in a single block. Itis conducted as follows:

• A functional safety assessment plan is prepared
  • The specific topics to be addressed by the functional safety assessment are identified.
• The scope of assessment includes
  • confirmation reviews, functional safety audit(s), reviewing the appropriateness and effectiveness of the implemented safety measures
• A functional safety assessment report is prepared at the end.

A report is prepared at the end of functional safety assessment stating a recommendation for acceptance, conditional acceptance, or rejection of the functional safety of the item.

The release is only approved if the functional safety assessment report and safety caseartefactsare available (based on the ASIL) and they provide confidence of functional safety. A Release for production report is prepared documenting all details about the item version, configuration etc.

ISO 26262 Part 5 is onProduct development at the hardware levelentailing theSpecification of Hardware safety requirements, Hardware design specification, Hardware Safety analyses, Evaluation of hardware architectural metrics, Evaluation of safety goal violations due to random hardware failures and Hardware integration and testing.

The HSRsare derived from the technical safety requirements allocated to hardware.The requirements allocated to both HW and SW are refined to yield hardware only safety requirements. The HSRs are further refinedbased on HWdesign constraints.The specification includes Safety mechanisms (SMs) and their attributes, such as FTTI or multiple-point fault detection interval of the SMs, Non-safety requirements e.g. those implementing the intended functionality, Specification of target values for the HW architectural metrics SPFM, LFM and PMHFand HW design verification criteria, such as environmental conditions, operational profileetc.

Safety mechanisms (SMs) specified in HSR are intended tocontrol internal hardware failures, such as transient faultse.g. glitch filter, provide tolerance to external failures e.g. open circuit on an input and also comply with the safety requirements of interfacing elementse.g. Diagnosis of sensors or actuators.

This level of HW design represents all hardware components and their interfaces with one another.

• Each component inherits the highest ASIL of all the requirements it implements.
  • Traceabilityfrom requirementsis maintained down tothe lowest level of components without assigning ASILs to hardware parts.
• To avoid failures from high complexity the design is made simple, modular, etc.
• The design is protected from non-functional causes of failure such as environmental factors liketemperature, vibrations, EMI etc.

This level of design is theHW schematics representing the connections between HW parts comprising the components. It covers design is protected from non-functional causes of failure such as environmental factors.

Each fault occurring in a safety-related hardware component/part is classified as follows:

• safe fault – do not violate safety goal
• single-point fault – have no safety mechanism in place to control the fault
• residual fault –violate safety goal and have safety mechanism in place to control the fault, but covers only certain failure modes
• multiple-point fault – violate safety goal in combination with an independent failureof another component

It is the effectiveness of safety mechanisms in preventing single-point faultsor latent faults, expressed in percentage i.e. percentage of failure modes covered by the safety mechanism.

Depending on the ASIL, an inductive analysis like FME(D)A and deductive analysis like FTA of the design is carried out to identify the effects of random hardware faults.This information is used to support the designspecification process to detect and control these failures occurring randomly during operation.

Method of analysis of FMEDA (Failure modes, effects, and diagnostics analysis):

• For each safety goal, the safe faults, single-point faults, residual faultsand multiple-point faults (either perceived, detected, or latent)are identified.
• Effectiveness of SMsto avoid single-point and latent faults is analysed.

Verification methods are Simulation, Hardware prototyping and Safety analyses that was used for HW design specification can beeventuallyused for verification.

The failure rates and failure modes distribution (FMD) for hardware parts are estimated and determined respectively from a recognised industry source.E.g. IEC/TR 62380, MIL HDBK 217 F notice 2, RIAC HDBK 217 Plus, NPRD 95, RIAC FMD97 and MIL HDBK 338.These databases yield generally pessimistic values.

Two metrics are described to evaluate the effectiveness of the HW architecture in handling random hardware failures.

• The FMEDA analysis is further quantified by plugging in the estimated failure rates, followed by the calculation of the overall failure rates for the design:
  • • Sum of failure rate of all safety relevant (SR) faults–∑λSR
  • • Sum of failure rate of all single-point faults–∑λSPF
  • • Sum of failure rate of all residual faults–∑λRF
  • • Sum of failure rate of all multiple-point faults (either perceived, detected, or latent) –∑λMPF, LATENT and∑λMPF, DETECTED
• The above values are used in calculating the two metrics
  • • Single point fault metric
  • • Latent fault metric

SPFM target values, based on ASIL, mandatory for C and D

• • ASIL B - 90%, ASIL C - 97%, ASIL D - 99%

LFM target values, based on ASIL, mandatory only for D

• • ASIL B - 60%, ASIL C - 80%, ASIL D - 90%

This analysis is to check if theresidual failure rateof a safety goal violation, from random hardware failures, is sufficiently low. It is complementary to the ‘Evaluation of hardware architectural metrics.’The two alternative methods of evaluation are:

• • “Probabilistic Metric for random Hardware Failures” (PMHF), using, e.g.quantified FTA and comparing the result with a target value.
• • Individually evaluating each residual, single-point fault, and dual-point failure leading to the violation of the safety goals. This method is known ascut-set analysis.

SPFM and LFM are relative values whereas PMHF is an absolute value.

It is the individual evaluation of each residual, single-point fault, and dual-point failure leading to the violation of the safety goals.

PMHF target values, based on ASIL, mandatory for C and D

• • ASIL B – 10-7/h ,ASIL C – 10-7/h, ASIL D – 10-8/h

The target values are expressed in unitsof average probability per hour over the operational lifetime of the item.E.g. for an item that is operational only 10 h each day, the remaining 14 h are not considered in the PMHF calculation.

An MPF is a combination of ‘n’ independent faults that lead to a safety goal violation. Usually, analysis is limited to n=2 i.e. dual-point faults as n>2 faults do not contribute significantly to the system failure rate. E.g. fault in Safety mechanism(SM) followed by fault in corresponding functional block(Mission block, M) it is protecting, represented as SM => M

• • ASIL B – 10-7/h ,ASIL C – 10-7/h, ASIL D – 10-8/h

The target values are expressed in unitsof average probability per hour over the operational lifetime of the item.E.g. for an item that is operational only 10 h each day, the remaining 14 h are not considered in the PMHF calculation.

A latent fault is a fault that cannot be detected without dedicated measures e.g. power-on, power-down, run time built in tests. It does not have an immediately visible effect.In this context, only multiple point faults have the potential to include latent faults.E.g. fault in Safety mechanism (SM) followed by fault in corresponding functional block (Mission block, M) it is protecting, represented as SM =>M .Here, fault in SM cannot be detected until fault in M occurs. The SM fault does not have a direct impact on output of M, hence cannot be detected i.e. it is latent.

Exposure duration is defined for a latent fault (multiple point fault) and it starts the moment the fault occurs and lasts until it is detected, corrected, and the system is fault-free again. It includes the :

• Multiple-point fault detection interval – diagnostic test interval i.e. time taken for the system diagnostic tests (safety mechanisms) to detect the fault which is otherwise latent, and
• Reaction time

The exposure duration hence depends on the kind of monitoring and reaction to the fault.

• Continuous monitoringwith a detection interval of few milliseconds
• Periodic self-tests with a detection interval of few seconds
• Driver monitoring with a detection interval of few hours
• No monitoring, with exposure duration equal to lifetime of the vehicle (latent fault)

No,failure rates from multiple sources cannot be combined unless a scaling factor with a proper rationaleexists between them.This avoids bias in calculation.

ISO26262 provides guidance on application of scaling factors.

Hardware integration testing is verification by testing of the integrated hardware design w.r.titssafety requirements.It is different from the verification done during design phase, which is through prototyping, simulation, analyses etc.The goal of HITis to verify the HWsafety mechanismsw.r.t theirrequirementsalong with environmental robustness.The test methods vary based on the ASIL, getting stringent with higher ASILs.A hardware integration and testing report recording the results is generated on completion.

Fault injection testing is a method effective in testing safety mechanisms (SMs) handling random hardware faults. This is because SMs are not invoked during normal operation rather only under fault conditions. This method involves injecting a fault in the hardware or its simulation and recording the response of the corresponding SM to check whether it was activated or not.This is especially useful when injecting faults in the hardware is not possible e.g. MCU. The faults in this case are injected in the RTL or gate-level simulationof the hardware. This method is called model-based, gate-level netlist fault injection.

A development interface agreement (DIA) is prepared between the customer and supplier to agree on acertain distributed development. It addresses the following :

• Appointment of safety managers from both parties
• Activities and processes to be performed by the two parties
• Information and artefacts to be exchanged
• Communication of target values at sub-system level, derived from system level targets to each party (to meet the SPFM, LFM and PMHF targets)

Based on the confidence level of the software tool TCL, the software is qualified as below:

TCL1 needs no qualification methods,

TCL2 and TCL3 need qualification methods such as increased confidence from use, evaluation of the tool development process etc.

Software component qualification provides evidence of suitability of a software component for re-use in an ISO 26262 item.E.g. software libraries from third-party suppliers [commercial off-the-shelf (COTS) software], in-house components already in use in electronic control units.

Software component qualification provides evidence of suitability of a software component for re-use in an ISO 26262 item.E.g. software libraries from third-party suppliers [commercial off-the-shelf (COTS) software], in-house components already in use in electronic control units.

Methods of Qualification

• Testing e.g. using ISO 16750 or analysis
• These methods can be used individually or in combinations

Qualification can be applied to HW components or parts of intermediate complexity if their failure modes are known and can be tested.

ASIL decomposition is an ASIL tailoringmeasure that can be applied to safety requirements at all levels of development of the ISO 26262 item to assign a potentially lower ASIL to the decomposed requirements (to reduce cost). It follows the decomposition rules specified in the standard.

The decomposed architectural elements must be independent with evidence providedin the form of a dependent failure analysis.

This purpose of DFA is to identify potential single causes that can violate the independencerequired between certain elements leading to violation of a safety goal.The potential sources of dependent failures include development or manufacturing faults, common external sources, environmental factors etc.

Each work product of ISO 26262 is verified for compliance with its requirements. The Verification plan, Verification specification and Verification report must be prepared:

ISO 26262 Part 6 is on Product development at the software level entailing the Specifying design and coding guidelines, Derivingsoftware safety requirements, software architecture design specification, Software safety analysis, Software unit design and Software implementation (Code), Software verification , Static code analysis, Requirements review, Architecture review, Design review andCode review.

Software safety requirements are derived from the technical safety requirements allocated to software.The requirements allocated to both HW and SW are refined to yield softwareonly safety requirements. The software safety requirements covers functions that enable the system to achieve or maintain a safe state, functions related to the detection, indication and handling of faults of safety-related hardware elements or the software itself, functions related time-critical operations, the timing constraints, operating mode of the vehicle.

Freedom from interference is the absence of interference between software components to avoid propagation of failures such as cascaded faults e.g. use ofSoftware partitioning.SW architecture must address the below faults, which cause interference between components:

• Timing and execution : e.g. blocking of execution; deadlocks
• Memory:e.g. corruption of content; read or write access to memory allocated to another software element.
• Communication :e.g. repetition of information; loss of information;

For ASIL D software, partition must besupported by dedicated HW or equivalent means.

The software is divided into related domains e.g. Initialization, Built in test, Communication, Utilities, Core processing, Protocols…etc. Each domain is decomposed into components, maintaininghigh cohesion within each. Each component decomposes into sub-components where applicable.The components are structured in a hierarchical manner.

Software verification plan specifies verification activities, methods, environment that will be used in verifying the software.

• Low complexity
• Strong typing
• Use of defensive implementation techniques

MISRA C and MISRA AC AGC can be used.

An inductive analysis i.e. FMEA is performed on Software design according to the international standard J1739.

• Error detection mechanisms e.g. Range checks, Monitoring control flow
• Error Handling mechanisms e.g. Degrading functionality gracefully

Item is a system or group of systems that implements a function in vehicle.

Item definition defined by manufacturer with the details item functionality, item interaction with other systems and dependencies.

In the ISO 26262, Part 2: Management of functional safety needs to be complied at organization level. The following work products needs to be produced as part of Part 2 compliance at organization level.

ISO 26262 Part 6 provides safety guidelines and methods to be used in software activities. Note that, software related information in the below parts also needs to be considered in software development :

• Part 2: Management of functional safety,
• Part 8: Supporting processes,
• Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

The following work products needs to be produced by software :

Note : Some of the listed work products are from ISO 26262 Part 8, which are required for software development.

Software failures may source from the following safety lifecycle phases:

• Development (E.g. Requirements and Design)
• Process (E.g. Schedule, Resources, Customer clarification …etc.)
• Production ( E.g. Program loading..etc.)
• Installation or service (E.g. Usage )

ISO 26262 Part 9(Safety analysis) concentrate on safe failures from Development phase.

Inductive analysis(bottom up) method ‘Software failure mode effect analysis (SFMEA)’ is one of the best method for software safety analysis. The following are the steps to perform SFMEA:

• Identify software failure modes and its causes
• Analyze each fault effect on the system safety
• For each fault that impacts safety, provide fault prevention, detection, mitigation mechanisms, and fault tolerance where applicable.

The following are the possible Software Failure mode categories:

• Data
• Timing
• Interface
• Logic or computation
• Resource

Note: The software failure mode categories are not limited to above list, project can find other categories where applicable.

Software failures may source from the following safety lifecycle phases:

• Development (E.g. Requirements and Design)
• Process (E.g. Schedule, Resources, Customer clarification …etc.)
• Production ( E.g. Program loading..etc.)
• Installation or service (E.g. Usage )

ISO 26262 Part 9(Safety analysis) concentrate on safe failures from Development phase.

Inductive analysis(bottom up) method ‘Software failure mode effect analysis (SFMEA)’ is one of the best method for software safety analysis. The following are the steps to perform SFMEA:

• Identify software failure modes and its causes
• Analyze each fault effect on the system safety
• For each fault that impacts safety, provide fault prevention, detection, mitigation mechanisms, and fault tolerance where applicable.

The following are the possible Software Failure mode categories:

• Data
• Timing
• Interface
• Logic or computation
• Resource

Note: The software failure mode categories are not limited to above list, project can find other categories where applicable.

Yes, the COTS need to be complied with Clause 12 (12 Qualification of software components) in Part 8 Part 8 (Supporting processes).

If a software is using qualified reusable software components , the following shall be available from COTS manufacturer:

• Specification (Requirement specification, configuration details, interfaces description, application manual, integration details, dependencies, anomalies) of the software component;
• Verification reports
• Compliance shows component developed to national or international standard.

Tool qualification is required when a software tool is replacing system, hardware or software activities in ISO 26262 and the tool output is not examined or verified.

ISO 26262 Part 8 (Supporting processes ) clause 11 (Verification of software safety requirements) provides details about the Tool qualification level and process to be followed.

In Fault injection testing, faults injected into source code or executable by code mutation (at source level ) or simulation/emulation (at executable level). This verifies robustness of the safety requirements and its implementation. E.g.

Software Unit level:

• Corrupt global variable values
• Corrupt CPU register values
• Corrupt input parameters

Software components level:

• Corrupt component interface (shared global data, messages and function parameters and return values)
• Corrupt component protocol state and timing

System executable level:

• Corruption of memory space: RAM and processor registers
• Corruption of memory space: RAM and processor registers

Fault injection testing before software implementation ( i.e. during design phase ) improves the design by adding proper fault prevention, detection and mitigation mechanism for faults that effects safety.

Fault injection testing after software implementation verifies fault prevention, detection and mitigation mechanism are implemented correctly.

The ISO 26262 specifies a V-model (product lifecycle) at system, hardware and software levels, all three of which are executed in parallel.

For e.g., product development at the system level specifies system design and item integration and testing whereas product development at hardware level specifies Hardware design and Hardware integration and testing.

An example of system design specification is the vehicle ECU shall generate an alert packet on tamper detection, whereas an example of hardware design specification is the hardware of the vehicle ECU shall have a tamper detection circuit. Briefly, the product development at hardware level consists of

• Initiation
• Hardware safety requirements specification
• Hardware design
• Qualification of hardware parts of intermediate complexity
• Evaluation of hardware architectural metrics
• Evaluation of safety goals violation due to random hardware failures
• Hardware integration and testing

The basic safety related hardware parts such as resistors and other discrete need only standard qualification such as ISO 16750, AEC-Q100, AEC-Q200 and so on.

Safety related hardware parts of intermediate complexity such as fuel sensors need qualification as per ISO 26262, part 8, clause 13 to provide evidence of suitability of the part for use in the safety related system.

Complex safety related hardware parts such as ECUs shall comply with ISO 26262, parts 4 (system level) and 5 (hardware level).

ISO 26262, part 5 specifies evaluation of two hardware architectural metrics which are used to assess the effectiveness of the hardware architecture in coping with random hardware failures namely, Single point fault metric (SPFM) and Latent fault metric (LFM).

Single point faults are the individual parts whose failure can lead to violation of the safety goals of the system. For e.g., a single resistor failing short can lead to overcurrent on a safety critical output - safety goal violation.

Latent faults are the multiple point faults that can lead to safety goal violation, if not detected.

For e.g., a high side driver MOSFET stuck HIGH on a safety critical output and the corresponding low side driver MOSFET stuck ON (dual point fault) can lead to unintended drive - safety goal violation.faults are the multiple point faults that can lead to safety goal violation, if not detected.

In the context of reliability analysis, cut set is a set of basic events whose occurrence leads to the occurrence of the top event.

ALTEN Global is working on ASIL B compliance for one of the automotive item development.

Item developed to ASIL A : functional safety assessment is not recommended.

Item developed to ASIL B : functional safety assessment is optional , it can be done by the customer, another organization or by the supplier

Item developed to ASIL C and D : functional safety assessment can be done by the customer, or by an organization or person designated by the customer.