Saturday 11 November 2017

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

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

Introduction:

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

Notations for Software Architectural Design (SAD):


ISO 26262-6:2011(E) – Clause 7.4.6, 7.4.7, 7.4.8:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

ISO 26262-6:2011(E) – Clause 7.4.6, 7.4.7, 7.4.8: Understanding

  • Each SW component should be defined as whether it is developed from scratch, or reused with or without modifications.
  • Based upon this the work products can be reused or freshly created.

Allocation of ASIL Levels:



ISO 26262-6:2011(E) – Clause 7.4.9, 7.4.10:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

ISO 26262-6:2011(E) – Clause 7.4.9, 7.4.10: Understanding

  • Once the SW/FW Elements is broken down into multiple SW Components, Sub-Components and Functionalities, it might happen that they may not be all safety related. 
  • A safety related SW Sub-Component might have multiple SW functionalities which may or may not be safety related. Even the level of ASIL of these functionalities might differ. In case there is difference in the level of ASILs then the SW development should be done with the highest ASIL level within that component,
  • In case you don’t want to use highest ASIL level as the base of development for SW Functionalities or don’t want any particular functionality to be safety based then you have to prove in-dependency through Dependent Failure Analysis (DFA).


Safety Analysis:
ISO 26262-6:2011(E) – Clause 7.4.11:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

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

  • One of the best way to ensure the Freedom Of Interference in the SW component are as follows:
    • Use separate micro controller handling independent functionalities.
      • Ensures no dependencies except for the power supply in case in the same PCB.
    • Use separate cores in the same micro controller handling independent functionalities.
      • Some dependencies still persists like the common shared area, data or memory bus or peripherals like timer.
    • Use separate memory sections (for code and data) handling independent functionalities.
      • Though the code and data are located in different memory locations still the memory is common, any defect will affect both of the functionalities.
      • The data and memory bus for accessing the data will be common hence a lot of dependency will be their which needs other methods to prove independence like applying safety mechanisms on memory, data bus
ISO 26262-6:2011(E) – Clause 7.4.12:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

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

  • The Dependency Failure Analysis (DFA) should also look into factors like Cascading and Common Cause Failures.
  • The Dependency Failure Analysis (DFA) can be analysed from following 2 points
    • Freedom from Interference (FFI)
    • Independency
  • Freedom from Interference (FFI) between SW components should also be analysed from following points.
    • Timing and Executions
    • Memory
    • Exchange of Information
  • Please refer my previous blog below for further details on DFA. ISO 26262 - Dependent Failure Analysis (DFA)

ISO 26262-6:2011(E) – Clause 7.4.13:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 

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

  • The FTA (Fault Tree Analysis) and FMEA (Failure Mode Effect Analysis) should be done on the basis of SW architectural elements. In case any failure detected it needs to be justified or safety mechanism needs to be added.

Safety Mechanism:

ISO 26262-6:2011(E) – Clause 7.4.14:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 6*** 


ISO 26262-6:2011(E) – Clause 7.4.14: Understanding
  • The FTA (Fault Tree Analysis) and FMEA (Failure Mode Effect Analysis) should be done on the basis of SW architectural elements. In case any failure detected it needs to be justified or safety mechanism needs to be added.
    • Range checks of input and output data
      • From the list of interfaces (both input and output) defined in the architecture design, the range check can be used as a safety mechanism.
      • However it doesn’t ensure detection of failures within the range.
    • Plausibility check
      • The plausibility check is carried out to check the validity of the data from multiple sources.
      • For example in case the voltage needs to be measured from a point, then it can be measured through ADC channel or a small circuit can be added to convert the DC voltage to PWM signal, This PWM signal can measured based on high and low period to determine the voltage. Hence plausibility check is based upon 2 different sources of signals.
    • Detection of data errors
      • The data errors are detected by methods like RAM ECC checks, Peripherals ECC checks and Flash ECC checks.
      • The detection style may be Single bit Error Detection and Correction and Double bit Error Detection (SECDED) based upon the feature available in the micro-controller.
    • External monitoring facility
      • External monitoring can be implemented by constantly monitoring the SW within a micro-controller.
      • Pair of Micro-controllers like Power Management IC and the Host IC has been developed as a method of external monitoring facility.



    • Control flow monitoring
      • Reference: https://vector.com/portal/medien/cmc/press/Vector/AUTOSAR_TTTech_ElektronikAutomotive_201204_PressArticle_EN.pdf
      • As per the above document from Vector.
        • The Safe Watchdog Manager (SWdgM) is the safety mechanism that is responsible for timing and program flow monitoring. Safety-relevant functions are monitored to ensure that the functions are executed in their correct sequential flow.
        • Checkpoints in all relevant software components regularly report to the Safe Watchdog Manager on the program flow.
        • This enables reliable detection of all types of run time interference.
        • If an application, interrupt or function is not activated in a timely manner, the Safe Watchdog Manager detects this and initiates a reaction to the error. 
        • Along with time duration, correct sequence in the program flow is also monitored.


      • Diverse software design
          • Diverse design of SW components can be developed so that the output of each can be compared to detect any mismatch between them. Once the mismatch id detected the system can be set to safety state.
        (...Continued in Next Part)


        Posted by at

        No comments:

        Post a Comment

        Subscribe to: Post Comments (Atom)