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)

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

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

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.
• TPS65381-Q1 (PMIC) & TMS570 (Host IC) (Reference: http://www.ti.com/lit/an/slva528b/slva528b.pdf)

• Safety Watch Dog IC (CIC61508) and Tricore (Host IC) (Reference : https://www.infineon.com/dgdl/TriCore%E2%84%A2-and-CIC61508-Powerful-Safety-Computing-Platform-CN.pdf?fileId=db3a3043338c8ac80133b6b7a17912a7)

• 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)

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

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

Introduction:

This blog tries to explain the clauses in Software Architectural Design (SAD) in detail. After that a sample template for the SAD is given for reference. This template for SAD tries to capture all the requirements from ISO26262 Part 6.7, however the reader might add/ delete any section as required.

In order to save the readers from a long blog, this blog has been divided into 4 Parts based on the clauses and their categories. All the clauses in ISO 26262-6:2011(E) can be grouped into following categories based upon their applicability.

ISO 26262-6:2011(E) Clauses	Applicability/ Categories	Covered in which part of this Blog?
-	Introduction	ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 1/4)
Clause 7.4.1	Notations for Software Architectural Design (SAD)
Clause 7.4.2, Clause 7.4.3, Clause 7.4.4, Clause 7.4.5	Principles of software architectural design
Clause 7.4.6, Clause 7.4.7, Clause 7.4.8	Category of software components	ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 2/4)
Clause 7.4.9, Clause 7.4.10	Allocation of ASIL level
Clause 7.4.11, Clause 7.4.12, Clause 7.4.13	Safety Analysis
Clause 7.4.14	Safety Mechanism
Clause 7.4.15	Error handling mechanism	ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 3/4)
Clause 7.4.16	Change requests arising from design activity
-	Sample SAD template	ISO 26262 Part 6.7: Software Architectural Design - Detailed Explanation (Part 4/4)

* References are mentioned in the last part.

Notations for Software Architectural Design (SAD):

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

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

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

1a. Informal notations:

• Informal notations refers to plain basic/natural language.

1b. Semi-formal notations:

• Semi-formal notations refers to plain basic/natural language along with pictorial/diagrammatically way of representations.
• This will include
• System design diagrams (Hierarchical Design)
• Data Flow Diagram (External Software Design, Internal Software Design)
• Sequence Diagrams
• Flow Charts
• Software Code Structure (Driver, Middle, Application etc.)
• Call Hierarchy

1c. Formal notations:

• Formal notations refers to mathematical expressions like design through MATLAB design.
• These MATLAB design can be later verified through formal verification methods.

Principles for Software Architectural Design (SAD):

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

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

• The various Design Principles are listed below.
• Design Principle 1: System design diagrams (Hierarchical Design)
• Design Principle 2: Data Flow Diagram (External Software Design, Internal Software Design)
• Design Principle 3: Sequence Diagrams
• Design Principle 4: Flow Charts
• Design Principle 5: Software Code Structure (Driver, Middle, Application etc.)
• Design Principle 6: Call Hierarchy
• The above Design Principles are mapped against their applicability for the points mentioned in the Clause 7.4.2.

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

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

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

• 1a. Hierarchical structure of software components:
• This is achieved by breaking the large size design blocks into smaller ones.
• System Level SW Elements -> SW Components -> SW Sub Components -> SW Functionality -> SW Unit Functions
• These blocks needs to be created based upon the modularity, independency and testability.
• 1b. Restricted size of software components:
• Software blocks should be decided based upon their independent identities and functionalities
• Only when this independency is maintained it will be easier in future to propose/implement any particular safety mechanism for the block in case need arises.
• 1c. Restricted size of interfaces:
• The size and kind of data to be exchanged between various SW blocks must be limited
• Every interface signal needs to be analysed from the point of Safety Analysis (FTA, FMEA) and Dependent Failure Analysis. Hence more the interfaces higher is the chances of Failure arising due to exchange of data.
• 1d. High cohesion within each software component:
• 1e. Restricted coupling between software components:
• The high cohesion of the SW block is decided based upon the functionality to be implemented.
• The SW block should be independent enough to be verifiable.
• By this principle the independency between the main implementation path and redundant (safety mechanism) path can be maintained.
• 1f. Appropriate scheduling properties:
• The sequence of data exchange between the SW blocks depends upon the origin and time taken for processing the data.
• Hence proper scheduling of data needs to be maintained.
• For example in case the ADC data conversion SW block (1) is done in 5msec, then the temperature determination SW block (2) should be scheduled after (1) or scheduled at a lower frequency (like 10msec) so that ADC data is available for processing.
• 1g. Restricted use of interrupts:
• The interrupt based handling causes SW to jump to different locations very frequently and may result in undesired behaviour if not correctly handled.
•  It may also affect the scheduling sequence of the SW, hence it is advised to avoid interrupt based handling and prefer the polling based handling.
• Polling based handling gives more control for the flow of the software.

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

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

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

• The SW Architecture must detail down the blocks until its implementation by SW functions.
• This assignment of SW functions to each blocks provides the linkage between the SW Architecture Design phase and SW Detailed Design phase.
• The detailed block wise explanation for hierarchy has already been explained in previous blog : ISO 26262 Hierarchical Components - A Software Perspective

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

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

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

Static Design Aspects:

The Design Aspects which comes to picture while the software is not being executed are called Static Design Aspects.

• The software structure including its hierarchical levels
• As explained in the above this part must contain the hierarchical breakdown of the major blocks starting from the
• Concept level – Items/ Systems/ Subsystems,
• System level – HW/ SW/ FW elements
• Software level – SW Components/ Sub-Components/ Functionalities/ Unit functions.
• In the SW Architecture Design document this section comes first where this break down is shown with each SW system level elements.
• The logical sequence of data processing:
• At the System level, during the System Design the HW/SW/FW elements are shown to interact with each other using data/signals.
• The sequence of data flow is based upon the functionality of the SW block.
• The data types and their characteristics;
• The interfaces their type and their values needs to be defined in the External Software Design diagram.
• The direction of the interface is also mentioned.
• The interfaces should be defined based upon optimum utilization of available resources like memory.
• The external interfaces of the software components;
• The external interfaces of the software; and
• The software blocks interact with other blocks that may be within same functionalities or blocks outside the functionalities through data interfaces.
• For example if calibration SW block can provide the data interface for Temperature Monitoring enable/ disable data signal to Temperature Monitoring SW block.
• The constraints including the scope of the architecture and external dependencies.
• Sometimes the SW blocks created has dependencies on other SW blocks that may or may not be part of analysis.
• For example if an ECU1 for which the ISO 26262 based designing is being done, depend on another ECU2 for data through CAN channel. Hence the SW Architecture Design document should note that the analysis of ECU2 is not under scope and it has dependency on the CAN signal as an external interface. So it might not be required to check the integrity of this external interface data assuming it would be received properly.

Dynamic Design Aspects:

The Design Aspects which comes to picture while the software is being executed are called Dynamic Design Aspects.

• The functionality and behaviour;
• Of course the division of the SW blocks are made from the primary aim of functionalities and the role they are going to play.
• The control flow and concurrency of processes;
• The control flow of the software functionalities are decided by their call tree beginning at the Task Scheduling.
• Hence a section should be present in the Software Architectural Design document containing all the scheduling happening and the tasks (like 1msec, 5msec, 10msec etc.) from where rest of the functions called.
• Though this section would also reappear when the design for the “OS scheduler” SW component is created.
• The data flow between the software components;
• The data flow at external interfaces;
• The data flow between the other SW blocks is explained along with their properties and range of values.
• The temporal constraints.
• In case the data interfaces are time based, then proper justification should be provided for determining the frequency of the call for the SW block in the design.
• Below are the examples where temporal constraints needs to be considered during design formulation.
• Sometimes temporal constraints arises due to polling of some microcontroller registers where you have for the registers to be set (like waiting for the PLL to lock in a while loop). Designing come to picture in such scenario when you have to design time out of the while loop.
• Temporal constraint also arises when you have to implement a power on sequence, where in the microcontrollers and others ICs (like the ECU, power supply, CAN transceivers etc.) have to power on in a particular sequence of events.

Both the static and dynamic design aspects reflects in the design principles that were earlier explained. Hence the coverage of each aspect through design principles is explained below.

(...Continued in Next Part)

ISO 26262 Hierarchical Components - A Software Perspective

ISO 26262 Hierarchical Components - A Software Perspective

Introduction:

The hierarchy in ISO26262 based design begins from the Concept Phase. At every part the components are broken down further to reach the lowest unit of implementation. 

For example the lowest unit for Software are the functions while that of the hardware are hardware components like resistors, capacitors etc.

In the below section the hierarchical components are explained in details from software perspective.The probable ID of each blocks are also suggested so that they can be linked and tracked upstream and down stream.

The basic hierarchy for deriving the SW architecture modules is shown as below.

Phase wise distribution of components:

ISO Part	Section No.	Work product details	Description
Part 3: Concept Phase	3.5	Item Definition	Define the Item at the vehicle level
Part 4: Product development at the system level	4.6	Specification of technical safety requirements	Define the System Level Elements, which can be Hardware (HW) Elements, Software (SW) Elements or Firmware (FW) Elements
	4.7	System design
Part 6: Product development at the system level	6.7	Software architectural design	Each Software (SW) Elements or Firmware (FW) Elements is divided into ·         Software Component (SWC) ·         Software Sub-Component (SSWC) ·         Firmware Component (FSWC) ·         Firmware Sub-Component (FSWC) Each SWC or FWC is further divided into ·         Software Functionality (SF) ·         Firmware Functionality (FF)
	6.8	Software unit design and implementation	Each Software Functionality (SWF) or Firmware Functionality (FWF) is divided into ·         Software Unit functions (SUF) ·         Firmware Unit functions (FUF)

Concept, System Level Hierarchy:

Basic structure:

Example:

Software Level Hierarchy:

Basic structure: