Efficient Safety Automotive System Design through Validation during the Early Design Phases

Dr.-Ing.Olena Ivanova

（ITK-Engineering GmbH,Stuttgart 70565,Germany）

【Abstract】Efficiency of the system design approach could be increased through the system design validation,respecting safety objectives and system dynamics during the early concept phases.Therefore,a formal safety system design criteria applicable to the system behavior models and safety critical constraints is represented.An efficient safety system design approach,which respects formal safety system design criteria,is shown as well.The safety critical constraints are defined in terms of hazard or fault tolerance domains for observable on the vehicle or system level states.For system behavioral models selected item validation methods are shown.Mathematical models as part of the system behavior models respect system dynamics,which are not explicitly considered in ISO 26262.In this work,it is also illustrated how to apply the proposed safety system design approach for a simple system.A formal safety design criteria helps to prevent conservative design restrictions,surely prevent safety hazards for system with complex dynamics and reduce coordination efforts by the distributed development but require some tools for automated safety system validation because of the possible system dynamic complexity.

Key words:ISO 26262,Safety system design,Fault tolerance domain,System dynamics,Model in the Loop（MiL）

1 Introduction

Safety isoneof thekey issuesof futureautomobile development.

With thetrend of increasingtechnological complexity,software content and mechatronic implementation,there are increasing risksfromsystematic failures and random hardwarefailures.ISO 26262 includesguidancetoavoid these risks by providing appropriate requirements and processes.

Figure 1 showsthe safety activities during the whole product lifecycle,includingtheconcept phase,product development and the phase after release for production.Each number near the activity notation referencesthe volume-number in Reference[1].The application field of Reference[1]issafety-related systemscomprised of electrical,electronic and software components.The remainingsystemsarenotated as“other technologies”or“external measures”,depending on the itemscope （see 1*and 3*in Figure1）.Theassumptionsregardingitem controllability by the driver using the hazard and risk analysis shall be checked by the safety product validation,as shown by No.4-9 in Figure 1.

Figure 1. Safety lifecycle

This study concentrateson the system design and validation of theconcept phase,becauseefficient system design during this phase saves the most effort and costs.

Themain objectiveof theitemdefinition（see 3-5 in Figure 1）is to describe the system,its dependencies and interaction with theenvironment and other items,see Reference[1],volume 3,§5.Itemdefinition includes the functional concept,operational and environmental constrains,and interactional interfaces with other items and the environment,its elements and so on.

ISO 26262 specifies no formal validation methods for the itemdefinition.

By theinitiation of thesafety lifecycle（see 3-6 in Figure 1）,a distinction can be made between a new item development and amodification of theexistingitem,specifying the responsibilities and work products for the development and production processes.

The objective of the hazard analysis and risk assessment（see3-7 in Figure1）istoidentify and to categorize the hazards where malfunctions in the itemcan trigger and toformulatethesafety goalsrelated tothe prevention or mitigation of the hazardous events.Through Reference[1],volume 3,§7,the hazard analysis and risk assessment arebased on theitemdefinition.Thehazard is defined in terms of conditions or behavior that can be observed at thevehiclelevel.

In Reference[2],[3]and[4],hazard definition is achieved by definition of thefault set（specified in the natural language and based on the item definition）,which referstothedrivingsituation fromstandardized safety catalogs.This type of hazard definition has several disadvantages:

a.Hazard definition strongly depends on the item definition and this in turn depends on the preliminary systemdesign.Thus,thehazard isspecified in such away that it cannot be easily reused for other systemdesigns or itsredesign.

b.A correctness of the hazard definition strongly dependson thecorrectnessof theitemdefinition and there is no formalized way to validate the itemdefinition without ageneral hazard definition methodology.

The objective of the functional safety concept（see 3-8 in Figure1）istoderivethefunctional safety requirementsfromthe safety goals.

Thisincludes:

a.Fault detection and fault mitigation for the preliminary itemarchitecture.

b.Systemtransition tothesafestate.

c.Fault tolerance mechanism.

d.Driver warningconcept.

2 Hazard Definition

The hazardsare classified through their controllability by thedriver,theoccurrenceprobability of therelevant driving situation and the caused injury severity during the hazard and risk assessment.Further development efforts and safety system design depend on this classification.However,such classification for new product featurescould havesomeuncertainties.Possibleuncertaintiesinvolve assumptions regarding controllability by the driver,which aredifficult tobevalidated at thebeginningof the development process.

Themain requirement dueto Reference[1]for hazard definition is definition in terms of the conditions or behavior that can beobserved at thevehiclelevel,see Reference[1],volume 3,§5.

In thisstudy,thesafety relevant hazardsaredefined through a hazard tolerance domain Dnh,which consistsof the elements xv,for which hold xv∈Rnhand v（xv,t）＜0:

where Rnhis a vector space necessary for the unique and completeconditionsor behavior definition that can be observed on the vehicle level;xvis a state vector,with behavior definition that can be observed on the vehicle level aselements;v（xv,t）＜0 isa vector function,which defines the condition and behavior on the vehicle level,which could lead tothesafety relevant hazard.

In most cases,the definition of the safety goals means toprevent exceedingthehazard tolerancedomain Dnh.Systemstates,which bring the systeminto the hazard tolerancedomain arenotated assafeone[1],and requireno further prevention or control measures.

Such ahazard tolerancedomain definition Formula（1）formalizes the hazard and safety goal definition,which prevents misunderstanding by the distributed development,formalizes safety analysis and allows us to systemize and even automate some steps in the system design and validation.

Conclusion 1:for an item-independent hazard definition,astandardized catalogwith xvstatesand hazard tolerance domain definition see Formula （1）,shall be provided for all automotive Original Equipment Manufacturers.

Asmentioned above,thehazard tolerancedomain may have some uncertainties due to driver model assumption.Such uncertaintiesarenot within thescopeof this article,so here we assume a conservative driver model.Thereby,a hazard tolerance domain is considered asa certain domain.

The further design of the functional safety concept is based on thehazard toleranceregion Formula （1）and item definition.

3 Item Definition

Therequirementsregardingitemdefinition are explicitly described in Reference[1],volume 3,§5 and includedefinition of theitemelements,their functionality,interfaces and functional design constraints.In this chapter,formalized itemdefinition and validation methods for the early development’s phases with respect to the safety objectivesareprovided.

3.1 Item Interface Definition and Validation

First,anecessary iteminterfacewith other items,the environment and driver should be specified.The safety relevant system inputsand outputs,see Figure 1,represent a state vector xv=[]tThrough vector composition by thehazard tolerancedomain definition in Formula （1）.

Thesysteminput fromtheenvironment env=[env1env2]Tcould not be detected through the item interfaceunlike,but strongly influencesystemoutput statesvalues.

Therefore,env shall be explicitly specified by the itemdefinition and respected by thefurther systemdesign.The non-safety system inputs and outputsnot influence the values of the safety relevant systemstates xv.Through such adefinition,the systemdynamic for the safety states xvis decoupled from the xfsystemdynamic.

Conclusion 2:if the safety relevant item interfacesnot represent a state vector xvfor conditions or behavior definition on the vehicle level,then the item definition isnot appropriatefor thehazard prevention.

3.2 Submodules and Internal Item State Definition and Validation

The internal interfaces between item elements and itemsubmodulesarealsodefined by theitemdefinition.Here safetyrelevant system states,non-safety relevant system statesand iteminternal control inputs u=[u1u2]Tare differed.

All safety relevant states xsby thesafety item definition aredecoupled fromtherest of thesystemstates.

A Functional Safety Concept（FSC）for a particular itemdefinition is designed.To validate the FSC,hazard tolerance domain Dnhin the vector space Rsis transformed tointernal itemstates xs（see Figure2）:

where the hazard tolerance domain Dsincludes all reachable xsvalues,which are estimated through the transformation function vs（xv,t,env）,which exists for all xv

Figure2.Itemdefinition

The condition?xv（ ）Dnhmeans the existence of the condition and behavior on the vehiclelevel xv,which guarantees for the system statesno exceeding fromthe hazard tolerancedomain Dnh:

Thereby,ahazard tolerancedomain Dsfor theinternal

where s（xs,t,u）will be referenced as a hazard function.

Such a domain transformation specifiesan additional criterion for thepreliminary itemdesign validation.

Conclusion 3:if the inverse transformation function sv?vs-1tothevector space Rnvwith vehiclebehavior states xv.

does not exist or leadsto the exit fromthe initial hazard tolerance domain Dnh:

see Figure 3,then Item—Definition or preliminary system design isnot appropriate for the hazard prevention.

Figure 3. Inversetransformation of hazard tolerance domain

3.3 Reachability Domain for Internal Item States and Its Validation

The reachability domain Dsdfor the internal item states xsisrestricted duetothesystemdynamicsand the itemoperational mode.The common effects,which influence the systemdynamics,are:communication（send/receive）frequency between several control units （SUs）,requirement execution time on some control units,and systemtransition process （for sensors,actuator and soon）.

The systemdynamics depend on the final system design,thereforefor theconcept phase,simply an assumption regarding systemdynamics could be considered.In the Reference[1],thereareno requirements or instruction to respect the systemdynamics by theitem/systemdesign.

The reachability domain restriction due to the system dynamics

is respected in the feasibility domain

where the control inputs fu（xs,t）depend on the system design decision,f（xs,t,u,env）describesthesystemdynamics and g（xs,t,u,env）describes algebraic dependencies by the systemdynamic definition.

Some basic requirements for the safety critical item dynamicsmodellingin Formula （6）areasfollows:the model in Formula （6）shall guaranty that all possible hazardscould bedetected （Req 1）;faulty hazard detection through the modelling error shall satisfy the system performance requirements （Req 2）.

Therefore,lets specify ideal systemmodel

The requirements for safety critical itemdynamics modellingcould bedefined as

and

whereacceptablemodellingerror

As soon as systemdynamic is modeled,a new method is proposed to respect the systemdynamics by the safety concept validation.Thiswill prevent detection of safety relevant concept faults only by the final product validation.Thisconsequently reduces the development costs and effort.

The reachability domain restriction due to the operation mode is respected in domain OP for the attainableinitial conditions xs（0）,control and environment inputs u and env:

where xs（0）-,u,-env-are lover bounds and xs（0）,+u+,env+aretheupper boundsof referenced states.

The feasibility domain ML and choice of the operation modedefinethereachability domain Dsdfor the internal itemstates:

Such a formal reachability domain definition specifies afurther criterion for theitemdesign validation.

Conclusion 4:if the reachability domain for the internal itemstates Dsdexceedsthehazard tolerance domain for the internal itemstates Ds,see Figure 4,Dsd?Ds,then the systemdynamicsand/or itemoperation mode does not satisfy the safety requirements.

Figure 4. Reachability domain for the internal itemstates

Thesystemdesign modification could changethe reachability domain for the internal item states.To prevent safety concept faultsby thedesign modification,a continuoussystemvalidation due to the defined above conclusionsshall beimplemented.Therefore,an item functional model,validation scenariosand validation routine shall be defined.

An examplefor safety relevant design modification is state values feasibility check before propagation.In this case,thesystemreaction timeincreases,and consequently,the feasibility domain and reachability domain for internal itemstates change.Therefore,a design validation via conclusion 4 isessential.

Conclusion 5:the reachability domain definition for theinternal itemstatescount asan assumption until the final systemdesign decision,implementation and validation.Thereachability domain Dsdassumption is validated via conclusions 3 and 4 by any relevant system design modification.

3.4 Sensors,Interfacesand Execution Module Accuracy by Item Definition

Theinterfacesand execution moduleaccuracy strongly influence the value of the itemstates and consequently increasethereachability domain D?sdof thefeasibility domain for the item～ sates increases with respect～to item states accuracy ML?ML and real～ operation mode OP divergesfromideal operational OP ? OP.

By itemstatesaccuracy model consideration,a definition and validation of reachability domain D?sdare morecomplicated and advanced toolsand methodsare used.

Nowadays,most componentsand systemsin the automotive sector already have accuracy modelsfor the input and output states:established error models（offsets,scale error,nonlinearities,drift and so on）or tolerance interval for theupper and lower statevaluesor covariance matrices for the systemmodules with Kalman filters or probability valuesfor the systemstate or further signal qualifiers （e.g.,imageunderstandingsystems）.

For these systems,which internal state estimation accuracy vary duringthedrive （e.g.,cognitivesystems）,a functional safety concept with adaptive reachability domain control shall beimplemented.Other ways,such as a functional safety concept unnecessarily restrictsthe systemdesign and isinappropriatetoguaranty safety objectives.

Nowadays,in ISO 26262,therearenosafety requirements,which respect item states accuracy by the systemdesign.The hard definition of the fault tolerance time for each safety mechanism（see ISO 26262,volume 4,§6.4.2.3）also restricts the possibility to design an adaptive safety mechanismor reachability domain control.

4 System Fault Definition

Asdefined in Reference[1],an FSCincludes safety systemfault definition,itsdetection,mitigation and tolerance mechanism.A safety fault definition is done on the basis of the safety analysis results.

By systemsafety analysis,afault in each systemstate xs,control input u and possiblefault combination are considered.

The methodology of automatized safety system analysisisnot described in Reference[1]for theearly development phasebut theautomatized fault injection in the AUTOSARmodel isalready researched as an important systemvalidation methodology.In Reference[5],fault modelsfor each safety relevant fault areadded as extension modulestothefinal sourcecodewithout its manual change.The necessity of formal fault model definition is discussed in Reference[5]but in practice,fault modelsin natural languagewereused.Here,in contrast to Reference[5],replacing the mathematical model of sub-items or sub-modules due to the mathematical model of thissub-systemwith afault is proposed.

Due to such validation,the administration efforts for SWmodulesand fault modulesescalatebut thetraceability and the systematic of the safety analysis will be improved.

Hence,amathematical model for thesystemwith a fault will be provided:

wheredepending on thefailureallocation,afunctional dependency ge1（xs,u,t）or a system dynamic fe1（xs,t,u,env）will bechanged or escape.A reachability domain for a“systemwith a fault”can be defined as follows:

Conclusion 6:If the reachability domain for the systemwith afault doesnot exit thehazard tolerance domain for theinternal itemstates,then the specified systemfailureisnot safety relevant and requires no special through ISO 26262 specified process and additional safety measures,other waysa safety mechanism for thisfault or fault combination isrequired or anew definition of theoperational modeisrequired or the functional systemdesign shall be changed.

As in Reference[1],a fault tolerance time shall be specified if applicablefor thefunctional safety concept design.In the hazard tolerance domain definitionexplicitly specified,soin thiscaseafault tolerancetimeis applicableand shall bedefined.In thisstep,welosesome generality of thefault tolerancedomain definition dueto conservativechoiceof thehazard function s★（xs,u） with constant fault tolerance time （tend-t0）:

Thus,thegeneral definition of thefault tolerancetime ftt （if fault tolerancedomain isalready defined）always leadstothelossof performanceand over engineeringin most cases.

A good example of how such a design can lead to over engineering is the relation between acceptable system error and fault tolerance time.The smaller the systemerror,the higher the fault tolerance time could be.So,a constant definition of the fault tolerance time is a strong restriction.

5 Example

The implementation of the above defined system design and formal validation methods will be shown here for a simple example.The safety critical item dynamics modellingisin thescopeof thefurther research,therefore herean initial systemwith simply systemdynamicswas chosen asan example.Hence,thefulfillment of the modellingrequirements（Req 1） and （Req 2） could be excluded in this context.

Some systemmodule shall switch a lamp on demand,if it is required through the systeminput∈{0 ;1}.Here the statesand system control input u are scaler values,see vector space dimension for Dnhdomain.

The definition of the fault tolerance domain could be done based on the following requirement:“The required state of the lamp shall be safety implemented with fault tolerance time interval.”

Because of the system simplicity,the transformation of the fault tolerance domain Dnhin the vector space Rscould be easily done:

On thisstep,thereisnosafety mechanism implemented and hence systemdynamics are neglected.For theoperation modeholds:

So,the hazard tolerance domain for the internal item statescan beobtained asfollows:

The reachability domain for the internal itemstates is

where index （1）indicates that the reachability domain holds for the first systemdesign iteration.The reachability domain shall bereevaluated for each systemdesign modification.In contrast to the reachability domain,the hazard tolerancedomain Dnhshall not bechanged.

For the systemwithout internal fault the validation criteria Dsd?Ds,could be easily verified.

In thecaseof theinternal systemfault（e.g.,burned LED）,the systemdynamicswill be changed xs=0.

For such asystem,conclusion 4 could not be validated and thefollowingholds:.

Because LEDis allocated at the end of the functional chain,thisfault can not beprevented,but todetect it and warn thedriver with additional systemoutputcan be

For such asystem,ahazard tolerancedomain shall be fit to the new systemoutput:

hazard could occur just in thecasethat LEDisburned,and the driver isnot informed.

Thetransformation function vs（2）

leads to the new hazard tolerance domain definition for internal item states:

For such asystemdesign,thesystemdynamicsfor internal states will be also changed:

For the （2）-nd systemdesign iteration,conclusion 4 is fulfilled:

For thereachability domain of the“systemwith a fault”in our case holds:

Thefulfillment of theconditionsdependson thedefinition of theoperation modeand in general for thespecifiedthiscannot beensured.

For somespecial drivingsituation,when warning lamp must blink （on-off change of the systeminput）with frequency f2,see the Figure5,thefollowinginequality could not beguaranteed:

Figure5. Systemstates for the submodule with afault

Thus,when u frequency f2does not fulfil the condition

thesafety relevant fault（e.g.,burning LED）could not be detected.

Helpful in thiscasecould betherestriction of the changingratefor thecontrol input uin:

by theoperation modedefinition.

where tn-tn-m＜t*1holds.

6 Conclusion

It has been shown how important the formal definition of the hazard tolerance domain and the systemdesign validation regardingitssafety objectiveseven for asimple system.

A completefault treecould bedefined automatically through the specified internal item statesand control inputs.

Here,the advantagesof the modular design could be used and themathematical model just for related functional module with a fault is updated.The final computation of thereachability domain for thecompleteitemand its validation could be done automatically.

By any change of the system design and further systemdesign refinement,reevaluation of the reachability domain and its validation shall be done automatically,which contributestotheautomatization of thechange management.