ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 3/4)

ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 3/4)

This blog is an continuation of the previous blog with the following link

ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 2/4)

Error Handling Mechanisms

ISO 26262-6:2011(E) – Clause 7.4.15:

*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

ISO 26262-6:2011(E) – Clause 7.4.15: Understanding

• Error handling refers to parking the functionality into the normal state or to safe state once the fault is detected.
• Static recovery mechanism
• Static recovery mechanism refers to actions that is decided before the software runs. For example the software reset after watchdog fault detection is a predefined action provided by the microcontroller. While sometimes it is possible to handle some interrupt at 75% of watchdog reset time before the actual watchdog reset happens. During this interrupt some steps like storing data in Keep Alive Memory (KAM) can be done.
• Graceful degradation
• Degradation refers to the systems running under reduced functionalities or performance or both.
• For example in case of fault is detected in the host IC then the host IC might shutdown the power to other modules/ICs and stay in sleep/dormant state as a safe state.
• Independent parallel redundancy
• A redundant method may be applied as a backup for the main path. In case of failure of the main path, the second redundant path kicks in and keeps the system running.
• Correcting codes for data
• Sometimes there are mechanisms where the error if detected can be corrected by means of adding redundant data as a level of protection.
• For example the features like Single bit Error Detection and Correction and Double bit Error Detection (SECDED) are now available in microcontrollers.

ISO 26262-6:2011(E) – Clause 7.4.16:

*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

ISO 26262-6:2011(E) – Clause 7.4.16: Understanding

• Sometimes the software architectural design may leads to constraints that cannot be resolved by safety mechanisms. This may result in hazards. This is evident from the safety analysis. In a reverse way this may lead to addition or modification of the original safety goal. IN such case the change management should be invoked to edit all the work products starting from the concept phase.

ISO 26262-6:2011(E) – Clause 7.4.17:

*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

ISO 26262-6:2011(E) – Clause 7.4.17: Understanding

• The detailed analysis for the available resources like memory, task scheduling should be designed.
• The memory map should be designed considering the allowed memory consumptions, functionalities, safety/non safety SW components etc.
• The task timings should be determined based upon functionalities, resource dependencies, sequence of data flow etc.

(...Continued in Next Part)