ASIL-D

Are you developing a new product for automotive context? and you want to understand how to make it safe in accordance with ISO 26262? maybe you have already read many books or followed many online courses, but you find yourself as lost as your initial question?

Don´t worry, asild.de is here to help you! I have started this website exactly due to this major materials gap: every online or book material speaks of the process world of ISO 26262; but no one -yet- focused on the functional safety engineering part. this website is exactly for this purposed intended, so set it in your bookmarks, this is the first article and there are many to come!

let´s start with the basic high levels steps in this article and we will detail every step in a dedicated article

step 1: identify the functional use cases of your new “item”

maybe you are developing a new generation of vehicle wipers, or a brand new ADAS functionality, or a complete new integration ECU. every new item* (product or function) you are developing is first and foremost to be seen from the vehicle level perspective:

*we will go more into the formal definitions later on. but for now the focus is on the “doing”

what is the function on the vehicle level provided by your item? or the use case? depending on if your industry is french influenced (value analysis: functional analysis) or american/german influenced (sysml: use cases)

as an outcome of this step, you will identify the functionalities provided by your item e.g

• main customer functions (FC1)
  • provide and maintain clear forward visibility of the road and surrounding environment to the driver during precipitation, soiling, or other visual obstructions.

step 2: identify the item definition and boundaries

you have then to look into your vehicle level item definition. which elements are contributing to the fulfillment of this function?

here you may make a begineer´s mistake and think only the product you are developing in your company is the item (e.g the wiper control ECU). but no, here the focus is on vehicle level, even the parts you may not be responsible for as a Tier 1. the focus is on every contributor to the vehicle function your product is contributing to. that makes the vehicle item.

in our example, the wipers function FC1 requires the following elements within its item:

• Windshield
• Wiper blades unit (including mechanical parts )
• Wipers motors unit (including cables)
• Wipers electronic control unit (ECU including connectors)
• Wipers stalk switch (the thing you move with your hands to control the whipers in the steering column)
• 12V Battery (including cables, fuses, etc.)
• Washer System Components: These are vital for clearing the windshield of dirt and grime, which is just as critical for clear visibility as rain.
  • Washer Fluid Reservoir
  • Washer Pump
  • Washer Nozzles
  • Washer Hoses
• Rain Sensor: of course we want to develop an automatic wipers, this sensor is the primary input that activates the system. .

step 3: do a hazards and risks assessment

now that we have identified our vehicle level function (step 1) and the vehicle item realizing it (step 2)

our goal is to identify the hazards that might be cause by the function and there after identify the risks involved (leading to a safety integrity level) and the safety goal that the function must ensure with that safety integrity level to be used in a safe manner by the customer.

• step 3.1: list the failure modes clusters of the function
  • this step is rather easy, we can use a dictionary list of failure modes:
    • loss of functionality: no clearing of visibility while conditions* of clearing visibility are met
    • erroneous functionality: clearing of visibility is incomplete to the specification level
    • unintended functionality: clearing of visibility is started while not required

*conditions here are specified by your product manager/system engineer. if the conditions are not well specified this is another domain of sotif (safety of the intended functionality). in a functional safety analysis we assume a correct specification of the function conditions and we analyze a systematic or random fault leading to non-fulfillment of the specification

• step 3.2: analyze the driving situations
  • we list the different driving conditions for which the function will be used, misused or working under failure modes. I will make a seperate article for this, as it is an own topic that requires time to develop. but for simplicity we will look here into combination of 3 factors:
    • driving infrastructure:
      • Highway
      • Rural
      • City
    • driving weather
      • rain
      • sun
      • dirt
    • time:
      • day
      • night
  • the driving situation in our simplified case is always a combination of the 3 factors:
    • driving situation 1: Highway, rainy during the day
    • with the 3 factors we have a combinatory number of situations of 3*3*2 = 12 driving situations
• step 3.3: find the hazards
  • a failure of the function (step 3.1) in itself is not a hazard (danger seen by the driver or traffic participants), it is only how it is felt by the driver during a driving situation it comes a hazard
    • said differently, the failure mode of wipers not working while your car is parked, is not a hazard, it´s just a failure mode
  • we have for our function FC1, 3 failure modes identified, and 12 driving situations. with combinatory logic we have therefore 12*3 = 32 hazardous (or non-hazardous) situations
  • e.g
    • loss of functionality during driving situation 1, can lead to
      • Hazard 1: loss of visibility
      • unintended functionality in driving situation 2 (rural, night, dirty) can as well lead to:
        • Hazard 1: loss of visibility (if the dirt type spreads on the windshield due to dry wiping)
  • you notice here that the same hazard can come from different failure modes and driving situations. in fact, the same hazard can come from completely different items: for example a high beam functionality/item can cause loss of visibility to driving participants
  • it is actually a possibility for the whole industry to standardize the list of the vehicle hazards! and some companies do internally!
• step 3.4: evaluate controllability: what can a the driver or other road participants do to “control the hazard” to not go into a “hazardous situations”
  • in our example Hazard 1, loss of visibility, leads to multiple hazardous situations depending on the driving situation, but the most repeating one: is read end collision with the front vehicle (in case of driving situation 1 for example)
  • can the driver or other road participants control the hazard?
    • the only solution I can think of, and please comment if you have other means to react in this situation: is to control the hazard by other items in the vehicle: in this case driver can start braking + warning lights!
    • cautious: here you must NOT use the item itself as measure of controlling the hazard, otherwise you will have a circular logic. you will understand better in the step if the safety goal definition because the internal items measures are what we call the safety goals! and that is the output of the hazards and risks assessment
• step 3.5 evaluate the safety integrity level
  • we will not detail this step here as many books and courses already overexplain it
    • we will however in a seperate article add concrete evaluations with statistical approaches and using databases.
    • for now we will focus on simple explaination:
  • simple steps here are:
    • evaluate the exposure level: the likelyhood of being in that driving situation
      • from E0 very low to E4 very high, happens daily
    • evaluate the severity of the hazardous situations
      • from S0 no injury to S3 life threatning
      • very important here: severity is evaluated without controllability! to leave the 2 parameters independent! as the ASIL rating itself reduces by controllability
    • evaluate controllability of the hazard
      • from C0 simple controllable to C3 very difficult to uncontrollable
• step 3.6
  • for every combination of failure mode, driving situation, hazard and hazardous situation we will have the E, C and S parameter. and using ISO26262 table, we can identify the ASIL level from
    • N.A (not even in the table e.g S0, E0, C0)
    • QM
    • ASIL A
    • ASIL B
    • ASIL C
    • ASIL D
• step 3.7 identify the safety goal
  • this deserves an article on it´s own but the most important takes are. we have 5 possibilities of safety goals depending on what we want to do:
  • we can focus on
    • improving controllability to C0: in this case we try to define a concrete measure:
      • SG1variant1: driver shall be able to override the wipers via stalk switch control
      • this safety goal has the advantage of removing the safety criticality on multiple sub-parts of the item. and focusing all the safety development effort on the override part
      • the safety analysis then focuses on the contributing parts to the override
    • reducing the failure mode, of course in this case there as many safety goals as failure modes
      • SG1variant2: avoid unintended wipers activation
      • SG2 variant2: avoid loss of wipers
      • this safety goal then keeps the safety measures neutral and requires a top down safety analysis e.g fault tree analysis, to identify all possible parts that contribute to this failure mode
    • reducing exposure: we can simply not offer the functionality to the customer on certain driving conditions! of course then this has to be in consideration with SOTIF and legal/homologation requirements. in the case of wipers we can´t simply say: deactivate the wipers on highway. because it´s very likely against the legal requirements
    • reducing severity: we can try using external items to reduce severity. for this function its not a good example to elaborate this. maybe in an analysis of the braking functionality we can elaborate on this more

and last is the safe state: if you can´t even fullfill your safety goal, where to leave your system:

in this case it´s straight forward: activate the wipers with liquid and full functionality just in case as your safe state

with these steps we should end up with a list of safety goals each with an ASIL level (ASIL acronym already has level as its automotive safety integrity level, but its common in industry to use the expression ASIL level to differentiate between A, B, C and D)

the maximum ASIL level of all the SGs of the function is the target ASIL level for that item development.

in the next articles we will focus on the functional safety concepts, technical safety concepts, hardware developement, software developement with real concrete examples with focus on safety engineering and not repeating the process vocabulary.

stay tuned, bookmark this new website. and comment your wishes for next articles or feedback on this one.