Fusa_009_ Safety Related Software Design Approache...

Safety Related Software Design Approaches

Today,let us talk about Safety Related Software Design Approaches.

1-  Introduction

 For the automotive E/E systems, many of the functionalities andproperties of ECU software are not safety-related, but only a part of them.Only those software elements that contribute to the implementation of safetyrequirements are considered safety-related. To implement the safety relatedrequirements and non-safety related requirements, there are several kind of designoptions on the market.

• QM design

• Mixed ASIL design

• Maximum ASIL design

Following figure demonstrates the three types holding software elementswith and without safety related software.

For the QM design, it means that develop the complete ECU softwarein conformance with the “QM”assigned to all of the functions within the ECU. This design is used as thefunction design with non-safety related system, thus there will be no morediscussion on this design.

For the safety related design approaches, both design options (MixedASIL design and Maximum ASIL design) must be used to achieve the same goal: Toachieve the necessary integrity of the safety functions. The level of integrityexpresses the degree of trust you can have that a software will provide the statedfunctions and properties as demanded under specified conditions withinspecified time. The required integrity can be achieved in two approaches:

• Preventthat the software contains errors, which lead to a malfunctioning behavior.

• Addadditional technical measures that are able to detect and control such amalfunctioning behavior.

The two safety related design approaches and the benefits of each of them would bediscussed in the following sections.

2-  Mixed ASIL design

The definition: Develop a design in which such a mixed ASIL elements or functions cancoexist. This is a typical approach if the portion of safety-related functionalitiesis rather small or third party or QM software needs to be integrated. In ISO 26262,this design approach is just as coexistence design defined in ISO 26262. 

As shown in the picture (ECU -2,ECU-3 and ECU-4), in a “Mixed ASIL Design” ECU, the elementsdo not all have the same integrity based on their specific development goals orrequirements. If they are integrated into one software without furthermeasures, the integrity of the complete software cannot exceed that of theelement with the lowest integrity, like the weakest link of a chain.

A “Mixed ASIL Design”targets the development of software elements according to QM or a lower ASIL withoutjeopardizing the integrity of the entire software system, which may have ahigher ASIL. It may also enable the containment of errors in a partition.

 This concept requires a suitable software design on applicationlevel:

• The functional blocks must be coherent

• The unwanted interlinking between functional blocks (e. g. viaglobal variables) should be avoided.

• It also requires a safety mechanism realizing the freedom frominterference on hardware and software level which ensures that a softwareelement with a lower ASIL cannot interfere with a software element with ahigher ASIL. This mechanism must be able to either prevent that a malfunctionof one element leads to the malfunction of another element, or it must be ableto detect such interference and to mitigate the effects in time. This safetymechanism has to be developed according to the “MaximumASIL” of the software safety requirements realized on thisECU.

To perform this approach, the elements of SW with higher integritylevel shall be free from interference with the elements of SW with lower integrity.In this article, no further discussion on freedom from interference are addresseddue to time limited, I will prepare a new blog article to discuss how to befree from interference. 

To guide implement the software with mixed ASIL design, ISO 26262defined criteria for coexistence of the elements in Part 9 Clause 6. Thus, therequirements specified in it need be followed when using mixed ASIL design.

Comparisonwith the Maximum ASIL Design, The separation between “QMor lower ASIL” and “MaximumASIL” elements provides the following benefits:

• Development methods for “Maximum ASIL” only have to be applied for safety-related software elements(which includes the elements ensuring the freedom from interference). Thisallows the reuse of existing QM software (e. g. third-party software), as longas it is not safety-related.
• Propagation of failures between software elements of the sameASIL can be prevented or detected, although it is not mandated by Freedom from Interference.However this also supports the separation of safety-related parts with highavailability requirements from other parts in fail-operational architectures
• Some failures caused by hardware defects can also be preventedor detected (e. g. timing supervision will detect a faulty clock source). 
  

Onthe other hand, the following disadvantages have to be taken into account whenapplying the “Mixed ASIL Design”:

• The separation adds additional complexity to the softwaredesign. Especially in legacy software, safety-related and non-safety-relatedfunctional blocks are often tightly coupled, which requires additional effortfor a software architecture redesign.

• The safety mechanism to ensure “Freedomfrom interference” may result in a performance penaltyduring runtime (e. g. for reprogramming the MPU and context switching). Toreduce these penalties to a minimum, the interaction between the softwareelements that are separated by freedom from interference mechanisms needs to beas low as possible.

3-  Maximum ASIL design

The Definition:Develop the complete ECU software in conformance with the “Maximum ASIL” assigned to any of thesafety-related functions within the ECU. It is the typical approach if theportion of safety-related functionalities is rather large.

As shown in the picture (ECU -5), in a “MaximumASIL Design”, all elements have the same integritywhich is the highest integrity ASIL Y. When integrating such elements, inprinciple the complete software has the same integrity and does not require anexamination for Freedom from Interference. Nevertheless, the safety analysis atsoftware architectural level may reveal weaknesses which have to be addressed(e. g. by technical measures) in order to achieve confidence in “Functional Safety”.

The “Maximum ASIL Design”has its advantages in use cases where a high share of the software provides safety-relatedfunctionality. In this approach, both the safety-related and thenon-safety-related functions follow the development process of the highest ASILin the system. For the non-safety-related software elements, the coexistenceargumentation follows a process argumentation: if those software elements are developedin the same stringent way applying the same process methods as the safety relatedsoftware elements, the coexistence of the elements is possible without furthertechnical separation measures. The only difference between the non-safety-relatedand the safety-related software elements is then the necessary safety analysisfor the latter.

Compared to the “Mixed ASIL Design” this approach gives the following benefits:

• No additional complexity for development of a partitioningconcept.

• No performance penalty due to safety mechanisms ensuringFreedom from Interference.

• Improved quality also for the non-safety-related softwarecomponents, which leads to a higher availability of the system. On the otherhand the following disadvantages have to be considered:

• The development effort increases since all softwareelements have to be developed according to the highest ASIL. For thenon-safety-related part an additional safety requirement is then applied, whichrequires the non-interference (“silence”) with the safety-related part.

• As ASIL development does not mean that the softwareis error free, errors in these parts are not prevented to propagate by design.

• Inclusion of third-party software (e.g. “black-box” software) is moredifficult, as the development, process of these modules is often unknown orcannot be influenced.
  

4-  ISO 26262 Requirements

NO.	ISO 26262 Requirements ID or clause on  coexistence
1	ISO 26262 Part 4, 6.4.6.4
2	ISO 26262 Part 4, 7.4.1.4
3	ISO 26262 Part 4, 7.4.8
4	ISO 26262 Part 4, Clause 6

5-  Reference

[1]    ISO 26262-4：2018，Road vehicles - Functional safety - Part4 : Product development at the system level

[2]    ISO 26262-5：2018，Road vehicles - Functional safety - Part5 : Product development at the hardware level

[3]    ISO 26262-6：2018，Road vehicles - Functional safety - Part6 : Product development at the software level

[4]    ISO 26262-9：2018，Road vehicles - Functional safety - Part9 : Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses

[5]    Software for Safety-Related Automotive Systems

6-  About 功能安全沙龙

功能安全沙龙 is used as  an Wechart Public Account for the technical sharing platform on following topics :

• ISO-26262
  
• SOTIF/ ISO 21448
• Cyber-security/J3061 or ISO-21434
• Powertrain Control of PHEV and EV
• ADAS or ADS or AD vehicles