How do your hardware and software interact?
We have posted blogs on the topic of dependent failure analysis (DFA) over a number of years. The subject is covered to varying degrees in different industries, but one aspect that is not as well addressed is the interference that can exist between hardware and software. However, there is a well known analysis technique in the space and aviation industries called Hardware Software Interaction Analysis (HSIA), that addresses this topic. There are aspects in HSIA that could help support DFA in automotive ISO 26262 projects and in the medical device sector according to IEC 60601.
The subject of DFA (both common cause and cascading failures) is addressed to different degrees in ISO 26262, IEC 61508 and IEC 60601. ISO 26262 is taking the most technical approach, with examples and definition of how to address the challenges at system, hardware and software levels. Part 11 of ISO 26262, which covers semiconductors, has added significantly more detail to the standard and has good coverage of how to analyse each of the 3 architectural areas, albeit as isolated topics. There is one small section 4.7.8 that briefly introduces the concept without really putting any meat to the bones. Figure 1 indicates the DFA workflow for either software or hardware elements.
Figure 1 DFA Workflow Semiconductors ISO 26262 Part 11
This approach in ISO 26262 supports detailed analysis in far more technical detail than IEC 61508, which focusses more on the top-level systematic considerations such as the Independence between designers and field data from similar products with the defined architecture. IEC 60601 in the medical device sector really just Introduces the topic of common cause failures with no detail on how to approach the subject.
Hardware Software Interaction Analysis
By no means a new methodology, HSIA has been used in the aviation and space industries for decades, but it does introduce concepts that none of the 3 standards listed above cover. In good old ‘state of the art’ fashion, some of these concepts could also be used in other industries such as automotive or medical to assess the interaction between hardware and software and the impact on safety.
The concept behind HSIA – it is performed concurrently with a Failure Mode and Effects (Criticality) Analysis FMEA/FMECA for all hardware products incoporating software. The hardware failues identified in the FMECA are then analysed in the HSIA to ensure the software requirements adequately address these hardware failures:
- Symptoms triggering the software action
- The action take by the software – isolating the failure or recovering from It
- Independence between the failure mode and the ability of the software to react as intended
- Effect of the software action on the intended functionality (cascading failures i.e. sequence of failures)
- The identification of additional means to mitigate
The HSIA is supported by a list of questions to apply to each identified failure mode of the hardware. The list in Figure 2 can be adapted based on the project, compexity etc.
| Question | Rationale |
| Will sufficient and reliabale information about the failure be provided to the software? | Sufficient information to detect the failure and also considering worst case conditions |
| Will the software initiate a corrective action that safe-keeps the product? | Check that the safe state can be maintained. |
| Will the operator/driver be able to fully recover the product following the software action? | There is not a loss of control such that the operator or driver cannot manage the situation. |
| Is the failure recovery fully independent of operator or driver action? | A fully autonous recovery. If not, the case may still be acceptable, dependent on the application. |
| Can the operator/driver intervene if the system recovery fails? | If the software safety mechanism cannot recover the situation can the operator/driver |
| Is the sampling frequency and filtering in line with time criticality of the failure? | The solution shall be implemented within the allowable fault reaction time. |
| Is the communication independent of the nominal control of the failed item? | That the failure can not block communication to a master system, if required to maintain safety. |
| Has the software been verified to ensure it does not initiate actions that may stress the hardware? | That the implications of a software action can not overstress the hardware. |
| Is the immediate recovery action independent of the function that has failed? | Check that no failure can inhibit/block the safe state. |
| Does the software function remove the possibility of a single point fault? | Check the questions above to ensure that no single point fault can result in an unrecoverable situation in the product. |
The HSIA questions supporting the FMECA give additional considerations to the DFA activities, particularly In Figure 1, where the activity of identifying dependent failure initiators (DFI) is not always that clear. It also gives an input to the activities in the IEC 60601 process where there is no clear guidance given on how to approach dependent failures.
By Alastair Walker, Consultant & Owner
If you would like to learn more about Dependent Failure Analysis in the automotive or medical device sectors, please contact us at info@lorit-consultancy.com about attending one of our ISO 26262 or IEC 60601 Advanced training courses.
