ISO 26262 Part 3.7: Functional safety concept (FSC) - Detailed Explanation (Part 1/3)

ISO 26262 Part 3.7: Functional safety concept (FSC) - Detailed Explanation (Part 1/3)

Introduction:

• This blog tries to explain the clauses in Functional Safety Concepts (FSC) and Functional Safety Requirements (FSR) in detail. 
• The reader can easily compile the various necessary sections of the blog to derive at a template for the FSR/FSC work product. 
• In order to save the readers from the ordeal of going through a long blog, this blog has been divided into 4 Parts based on the clauses and their categories. All the clauses in ISO 26262-3:2017(E) for FSC can be grouped into following categories based upon their applicability.

ISO 26262-3:2017(E) Clauses	Applicability/ Categories	Covered in which part of this Blog?	Blog Link
-	Introduction	ISO 26262 Part 3.7: Functional safety concept - Detailed Explanation (Part 1/3)	EmbeddedInEmbedded: ISO 26262 Part 3.7: Functional safety concept (FSC...
-	Sample Safety Goals for Antilock Braking System (ABS)
7.4.1, 7.4.2.1 ~7.4.2.7	Functional Safety Requirements derivation
-	Sample Functional Safety Requirements for Antilock Braking System (ABS) Item
7.4.2.8 ~7.4.2.10 7.4.3	Functional Safety Concepts derivation	ISO 26262 Part 3.7: Functional safety concept  - Detailed Explanation  (Part 2/3)	EmbeddedInEmbedded: ISO 26262 Part 3.7: Functional safety concept (FSC...
-	Sample Functional Safety Concepts for Antilock Braking System (ABS) Item
7.4.4	Verification of the Functional Safety Concept	ISO 26262 Part 3.7: Functional safety concept  - Detailed Explanation  (Part 3/3)

* References are mentioned in the last part.

Sample Safety Goals for Antilock Braking System (ABS) Item:

• Taking the item identified in the previous blog for "Anti Lock Braking System", the following Safety Goals (SG) are presumed for further analysis.
• Blog: EmbeddedInEmbedded: ISO 26262 Part 3.5: Item Definition
• * - Currently the below ASIL levels are assumed. detailed analysis in terms of Hazard Analysis and Risk Assessment (HARA)

SG ID	SG Description	ASIL *
SG1	The ABS module shall prevent locking of the wheel.	D
SG2	The ABS module shall prevent any unintended actuation	D
SG3	The ABS module shall be able to detect malfunction which will prevent it from acting.	D

Functional Safety Requirements (FSR):

• FSR shall be derived from the Safety Goal.
• The FSR shall be attributable to a module derived during the Item Diagram/ Preliminary Architecture Diagram.
• The FSR define the functional part of the implementation. Technical details like how to do it is not mentioned here. For example, if the vehicle speed is being shared between ECU at FSR/FSC level whether this is done through CAN or LIN or SPI is not decided. This is decided during the Technical Safety Requirements (TSR)/ Technical Safety Concepts (TSC).

How to derive Functional Safety Requirements (FSRs)

ISO 26262-3:2017(E) – Clause 7.4.2.1, 7.4.2.2, 7.4.2.5 :
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

• Derived from Safety Goals.
• Requirements related to Faults, Safe State, Timing, Warning and Degradation etc.
• Requirements related to Driver Actions.

Requirements related to Faults, Safe State, Timing, Warning and Degradation etc.

ISO 26262-3:2017(E) – Clause 7.4.2.3:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

Each FSR should be derived from the Safety Goal so that following requirements are covered.

a) fault avoidance:

• The Fault should not take place in the first case. This is the basic purpose of the Safety Goal and why the safety life cycle is being followed.
• For example: In case of ABS system is assumed as an Item, the Locking of the wheels (considered as the Fault) should be avoided. This is the primary function of the Item is to avoid locking of the wheels.

b) fault detection and control of faults or the resulting malfunctioning behavior:

• The Fault should be detected and if necessary employ correct control mechanism in order to avoid any safety goal violation.
• For example: In order to avoid the Locking of the wheel, the Item should be able to detect the locking well before time and try to prevent locking and its resulting malfunctioning behavior.

c) transitioning to a safe state, and if applicable, from a safe stated) fault tolerance

• Safe state is defined as an operating mode in case of failure of an Item without an unreasonable level of risk. 
• Different safety goals may have same or different safe states based upon there targeted functionality. Hence different FSRs tagged to these Safety Goals have different safe states.
• The FTTI (Fault Tolerant Time Interval) is associated with every safety goal. The sum of Fault Detection Time (TFD) and Fault Reaction Time (TFR) for the Safety Goal should be well within the FTTI specified for the goal. i.e. (TFD + TFR < FTTI). If this is not satisfied then Safety Goal is violated.
• The time difference between FTTI and (TFD + TFR) is spent by the Item in the Safe State.
• Please refer the Blog for more details of FTTI.  iso-26262-warning-and-degradation
• The below diagram explains the above points.

• For example: 
• Consider the first Safety Goal (SG) for ABS i.e. “SG1: The ABS module shall prevent locking of the wheel.”. In this SG, the ABS Item shall detect the locking of the wheels and react to prevent the locking of wheels within the FTTI and transit to the Safe State of “Wheel not locked” (Normal Function).
• Consider the second Safety Goal for ABS i.e. “SG2: The ABS module shall prevent any unintended actuation.”. In this SG, the ABS Item shall prevent any unintended activation of the ABS functionality. The ABS Item should detect and prevent unintended activation within FTTI. Here also the Safe State is “Wheel not locked” (Normal Function).
• But for the third Safety Goal for ABS i.e. “SG3: The ABS module shall be able to detect malfunction which will prevent it from acting.”. In this SG, ABS should detect a malfunctioning ABS module and shut it down without affecting the normal functioning of the brake. Hence the Safe State should be “ABS Turned Off”.

e)the degradation of the functionality in the presence of a fault and its interaction with f) or g); EXAMPLE Maintaining the vehicle in a limp-home mode until the ignition has been switched from "on" to "off".

• In case the ABS is deactivated, then the normal brake should be active. Here we can consider the “Normal Braking” as a degraded functionality from the Safety Goal point of view (Though it is an absolute necessity).

f)driver warnings needed to reduce the risk exposure time to an acceptable duration
g)driver warnings needed to increase the controllability by the driver (e.g. engine malfunction indicator lamp, ABS fault warning lamp)

• The FSRs should also cover requirements related to driver warning, which enables the driver to take informed decision effectively.
• For Example: For ABS Item, in case of the Safety Goal “SG3: The ABS module shall be able to detect malfunction which will prevent it from acting.”. If the malfunction is detected, then the ABS warning light is enabled in the dashboard for the driver.
• In case driver is aware that the ABS is not active, he/she can try to avoid going into such a situation. In case the driver has to go to such situation, he/she should not depend upon the ABS system and take control manually. 

h)how timing requirements at the vehicle level are met, i.e. how the fault tolerant time interval shall be met by defining a fault handling time interval; and

• FSR definitions should have time requirements like FTTI. 

i)avoidance or mitigation of a hazardous event due to improper arbitration of multiple control requests generated simultaneously by different functions.

• If we consider the below 2 Safety Goals
• “SG1: The ABS module shall prevent locking of the wheel.”.
• “SG3: The ABS module shall be able to detect malfunction which will prevent it from acting.”
• The FSR should be clear that in case SG3 is violated, then SG1 should not be attempted. Both of these should be independent functions and arbitration should be pre-decided.

ISO 26262-3:2017(E) – Clause 7.4.2.6:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

The FSR should also define requirements (if applicable) related to the Emergency Operations.

• The Emergency Operations define the actions that needs to be taken in case the safe state is not achieved within the FTTI.

Requirements related to Driver Actions:

ISO 26262-3:2017(E) – Clause 7.4.2.7:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

• If some assumptions are considered where the driver (or any other person) has to take some action to avoid violation of the safety goal, then these should be mentioned in the requirements.
• The FSR should also include these actions and control/methods available with the driver (or any other person).
• The various warning and degradation concepts can be covered here.

Properties Functional Safety Requirements (FSRs):

ISO 26262-3:2017(E) – Clause 7.4.2.4:
*** Please refer this clause from originally procured licensed copy of ISO26262 Part 3*** 

• The following properties are applicable to each FSR (if applicable).

Sample Functional Safety Requirements for Antilock Braking System (ABS) Item:

Notes:

#1 – Assuming the ABS is activated 15 times per second to avoid any lock situation. Hence the full cycle of Fault detection (Locking) and Fault Reaction (ABS activation) occurs approximately (1000msec/15 = 66.6 msec). That can be divided as Fault detection (Locking) – 30 msec and Fault Reaction (ABS activation) – 30 msec. So that (30 msec + 30 msec) < 66.6 msec.

#2 – These values may vary based upon OEM requirements and on road analysis.

#3 – The BCM is assumed to be main ECU which shall relay the failure status to Driver after receiving from ABS. (ABS -> BCM -> Driver Dash board). The appropriate choice of ECU shall be done by OEM.

#4 – It is assumed that the ABS failure LED on the dashboard shall be active within 100msec of ABS module failure detection.

FSR ID	FSR Description
FSR_1	The ABS module shall use the -      brake on/off activation signal -      wheel speed signal for engaging and disengaging the ABS functionality. The ABS should be activated only brake is pressed and if the speed is more than 15mph#2.
FSR_2	The ABS module shall receive the brake on/off activation signal.
FSR_3	The ABS module shall be able to detect the 4-wheel speed signal from the 4-wheel speed sensors.
FSR_4	The ABS module shall be able to detect the deceleration in any of the 4-wheels. It shall also be able to detect any imminent wheel lock up scenario.
FSR_5	In case of imminent wheel lock up scenario, then action shall be taken to prevent lock up.
FSR_6	The ABS module shall have mechanism to detect if any error is present in brake activation signal every time it is received.
FSR_7	The ABS module shall have mechanism to detect if any error is present in 4-wheel speed signal every time it is received.
FSR_8	The ABS module shall execute the diagnostics test sequence after ignition and determine any error present.
FSR_9	In case of any failure detected, the ABS module shall disengage the ABS and notify the BCM#3.
FSR_10	In case of any error detection arising of any of the failure, the ABS module shall shut down and shall not affect normal braking of the vehicle.

Abbreviations:

Acronym	Description
Mph	Miles per Hour
Msec	Milliseconds
FSR	Functional Safety Requirements
BCM	Body Control Module
ABS	Antilock Braking System
TSR	Technical Safety Requirements
TSC	Technical Safety Concepts
FTTI	Fault Tolerant Time Interval

(...Continued in Next Part)

ISO 26262 Part 3.5: Item Definition

ISO 26262 Part 3.5: Item Definition

What is an Item definition?

• The Item Definitions draws out the identification of a E/E unit or a part of it, on which ISO 26262 life cycle process needs to be carried out.

How to identify an Item?

• Reference of previously existing Item on which Functional Safety compliance needs to be applied
• A completely new concept that needs to be developed in accordance with Functional Safety compliance.
• During the course of ISO 26262 life cycle Item Definition may has to be changed while some system/sub systems needs to be added or removed.

Determining Requirements for the Item that shall be used throughout Functional Safety Life Cycle

• Once the Item has been determined, the requirements related to it shall be identified.
• This requirements are necessary to analyse the Item from the Functional Safety point of view to be adhered during the Safety life cycle.

How to define Boundary of an Item?

An E/E unit may not be always performing independently to achieve a desired functionality. It is further supported/affected by

• User/Driver of the vehicle
• Or other Mechanical units which the E/E unit (under study) controls/ monitors.
• Or Environment where the functionality is expected to operate.

The boundary of the Item shall be determined based upon

• The Elements of the Item
• the assumptions concerning the effects of the item's behavior on the vehicle;
• the functionality of the item under consideration required by other items and elements;
• the functionality of other items and elements required by the item under consideration;
• the allocation and distribution of functions among the involved systems and elements; and
• the operational scenarios which impact the functionality of the item.

Based upon the Item boundary further division into System, Sub Systems, Software (SW)/Hardware (HW)/Firmware (FW) Components/Sub Components are determined.

Example of an Item - Antilock Braking System

Here Antilock Braking System (ABS) is considered as a E/E unit on which the Functional Safety life cycle shall be executed.
This ABS unit which perform a functionality of preventing locking of the wheel consists of

• E/E system (ABS Control Unit, Sensing units, Pump Motor Control Unit, Valve/Solenoid Control Unit), 
• Mechanical System (Actual Brake pedals, Brake Calipers, Brake Pads, Rotor, Brake hose, Brake Shoe, Brake Drum) and 
• Hydraulic System (Master Cylinder, Accumulator, Reservoirs, Piston, Valves, Pump Motor)

Preliminary Architecture Diagram/Assumptions:

The Item Diagram forms the basis of the Preliminary Architecture Diagram on which future System/Sub Systems are identified.

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)