[rst89]

Before reading this thread, just remember to do this simple exercise in controlled environment

1. Take your car on an empty stretch of road, mostly closed to vehicular traffic
2. Drive at sedate speed of 20kmph and just turn off your ignition and try to open door slightly.
3. Does your steering column gets locked?

If yes, then you are in deep trouble at high speed. Your OEM has not given you a functionally safe product to you. Generally one of the goals of functional safety in cars is that you should be able to manoeuvre the car in case ignition gets shut off abruptly.

Now we move on to main topic of functional safety in cars. This thread is based on my professional experience.

1. What is functional safety in cars?

Generally, aerospace has strict functional safety guidelines with triple redundancy existing in some systems. The development of a single aerospace component takes significant amount of time.

Functional safety in cars are governed by industrial standard named as ISO26262.
ISO26262 is derived from IEC61508 which was used for all Electrical/Electronic/Programmable Electronic Safety-related Systems in all kinds of industry. A need arose to formulate a standard for automotive industry as the number of Electronic control units went on increasing in cars and special standards were required for cars.

The first official version of ISO26262 was released in 2011. So if you all wondering that your cars are safely designed from E/E as per standards, then you stand to be corrected. Many OEM still use legacy systems in your cars and most of OEM are now incorporating ISO26262 from 2011 and it has been focus of E/E systems for all OEM's. ISO26262 is applied throughput the entire life cycle of the product.

ISO26262 deals with electrical and electronic systems(E/E) of cars which weigh less than 3.5 tons and are going for series production.

ISO26262 doesn't deal with mechanical aspects of a car.
ISO26262 tries to prevent unreasonable risk caused by malfunctioning of E/E systems.

Wikipedia has good description of ISO26262. The link is ISO26262.
There are total 10 parts under ISO26262.
What I will try to do is give you simple description of ISO26262 instead of going into each part of ISO26262 and how a product is developed for an OEM.

The key steps for development are as follows:

1. First an OEM defines an "Item". Item is used to refer to system or array of systems which achieves a fixed functionality in a car on which you will apply ISO26262 through the product development life cycle. Array of systems can be easily understood by following example. A Battery management systems(BMS) includes a battery management controller, Battery junction box and Cell monitoring control modules. ISO26262 will be applied to all of the modules in case of BMS.

2. Next hazard and risk analysis(HARA) is done on the product. HARA is important as it identifies what happens when an E/E item malfunctions. What is severity when the item malfunctions, the exposure to the occupant using the item and is it really controllable when the actual malfunction happens. Depending upon a table, we determine the safety integrity level for the item. HARA is done by an OEM unless a platform is getting developed by a Tier one OEM supplier.

I will give two simple examples of HARA is done on item
a) Suppose you are driving a car and your headlight stop working.
The three factors that determine are severity of the event, probability of occurrence of the event and control ability of the event.
The speed at which you are driving determines the severity of malfunctioning of headlight. So headlights failing at above 40 km/hr is given more severity level which determine safety integrity level of the headlights.
In case of probability, this event is given medium probability in case of driving in tunnels, wet roads or overtaking.
Next, is the vehicle controllable if the event occurs? Yes, it is normally controllable as driver is is normally able to bring the vehicle to stop in case of failure at medium or high speeds without departing lane in an uncontrolled manner. In the same way, in case of failure, he will break in emergency which will activate ABS.

b) Consider an item named as air suspension in cars. Now HARA done for sedans fitted with air suspension systems is different for air suspension systems fitted in SUV's. Why? Consider air suspension systems malfunctions, then chances of rollover in SUV increases compared to sedans and hence the control ability is affected while doing HARA.

The final outcome of HARA is safety goal is assigned to each hazardous event and it is associated with safety integrity level assigned to the event. The safety integrity level(SIL) in abbreviated as ASIL where A stands for automotive.

There are various levels of ASIL named ASIL A, ASIL B, ASIL C and ASIL D. ASIL D is highest level assigned to each event depending on HARA.

3. Next what are safety goals associated with an item.
Lets consider a simple item "Electronic steering column lock" (ESCL). ESCL drives a bolt into steering column based upon inputs received from the car. So basic functionality of ESCL is to lock and unlock the steering column.
What can be hazardous event for ESCL?

ESCL getting locked when car is in motion

All our safety goals should be geared to prevent ESCL getting locked when in motion. Safety goal is achieved by designing your system in such a way that it prevents the hazard.

4. Functional Safety Concept (FSC)

Functional safety concept is simple, if a hazard is reported, how should you item react to achieve the safety goal.
So when a hazard happens we should go to a safe state within some tolerant time. Now safe state can differ from item to item. In case of air suspension systems, safe state can be as simple to stop leveling of cars using air springs within some time.
The other objective is to allocate safety requirements to architectural elements, in our case the Electronic control unit (ECU).
FSC is generally done at OEM level and validated by vehicle integration and testing at OEM.
How you define the architecture is important at this phase. Should you use a distributed concept or non distributed concept to achieve safety goal is decided here?
A distributed concept is one ECU acts as slave of other ECU and power supply is cut off by master ECU.
A non distributed concept is the ECU makes decision himself to achieve the safety goal.

Now how me modify our architecture to achieve safety goal associated with Electronic steering column lock(ESCL) will be shown below in few representational diagrams.
The main safety goal of ESCL is no locking while driving.
The below diagrams may not be technically correct but will just give you an idea how concept is developed.

ESCL is made of a motor which drives a bolt in steering lock. The micro controller drives a switch which controls the motor. Below diagram shows the architecture of ESCL.



But what happens if my switch malfunctions while driving! I violate the safety goal. So lets place another switch in the architecture



Now what happens, if my micro controller fails. Add one more micro controller which will control the switch independently with same set of inputs.



So we derived a dual channel architecture to achieve the safety goal in FSC phase. We also derive the functional safety requirements here that needs to be fulfilled by the supplier.

5. Technical safety concept (TSC)
TSC achieves all goals of FSC but it includes how you incorporate it in your system.
The safety mechanism for each safety goal shall be specified in accordance to functional safety requirements. It is also related to detection, indication and control of faults in the system itself and faults in external devices interacting with the system. It has measures that enable system to achieve a safe state and gives details of degradation concept. It also provides the measures which prevent the fault from being latent.

6. V model of SW development:
ISO26262 follows V cycle of software development.
A you see in below figure, the various parts in ISO26262 follow the red path of development.


Source: ISO26262 release documents

I hope I have given you all an introduction to functional safety in cars.

I would be glad to connect with any automotive software professionals on this forum who can add more insights to this thread.

[GTO]

Thread moved from the Assembly Line to the Tech Section. Thanks for sharing!

[SPIKE ARRESTOR]

Originally Posted by rst89

What can be hazardous event for ESCL?

ESCL getting locked when car is in motion

All our safety goals should be geared to prevent ESCL getting locked when in motion. Safety goal is achieved by designing your system in such a way that it prevents the hazard.

Hi rst89,

Thanks for creating this thread.

For the ESCL what ASIL is allocated?

Also, for a malfunctioning microcontroller, is there no other way to make the system failsafe? Is this how it is implemented in the car?

Spike

[rst89]

Originally Posted by SPIKE ARRESTOR

Hi rst89,

Thanks for creating this thread.

For the ESCL what ASIL is allocated?

Also, for a malfunctioning microcontroller, is there no other way to make the system failsafe? Is this how it is implemented in the car?

Spike

Deducing ASIL for any product involves lot of process. If two individuals sit to derive the ASIL of a feature, then both may get different ASIL based upon their interpretation of severity, exposure and controllability of the feature. So a broad consensus is required for the same.

As far as I remember, ESCL has rating of ASIL level D.
Yes, if a micro fails, then you can't drive the car and you have to replace the board.

[SPIKE ARRESTOR]

Originally Posted by rst89

Deducing ASIL for any product involves lot of process. If two individuals sit to derive the ASIL of a feature, then both may get different ASIL based upon their interpretation of severity, exposure and controllability of the feature. So a broad consensus is required for the same.

Agree about the consensus part, but for every derived ASIL rating, there should be a rationale provided for choosing a different S, E, C.

As far as I remember, ESCL has rating of ASIL level D.

Quite high IMO.

Yes, if a micro fails, then you can't drive the car and you have to replace the board.

Is there a safe state allotted?

I find it quite strange, that two micro-controllers are used separately to control 2 switches in a ESCL system, are these multi core? Is there a watchdog implemented?

Would be interested to know the reason for such an implementation.

Spike

[rst89]

Originally Posted by SPIKE ARRESTOR

Agree about the consensus part, but for every derived ASIL rating, there should be a rationale provided for choosing a different S, E, C.



Quite high IMO.



Is there a safe state allotted?

I find it quite strange, that two micro-controllers are used separately to control 2 switches in a ESCL system, are these multi core? Is there a watchdog implemented?

Would be interested to know the reason for such an implementation.

Spike

Yup there is rationale for every Severity, exposure and controllability.

The two micro example was demonstration of a robust design. Very few of them might be using two micros in their board, reason: Cost.

Now may OEMs have their own strategy based upon ASIL level they have derived based upon safety assessment level. All use a Watchdog, the implementation differs. And hardly anyone uses multicore in automotive except ADAS guys even though the micro supports it.

[SPIKE ARRESTOR]

Originally Posted by rst89

All use a Watchdog, the implementation differs. And hardly anyone uses multicore in automotive except ADAS guys even though the micro supports it.

If all use a watchdog, the second microcontroller in the above example is unnecessarily redundant.

Spike