The Functional Safety Mirror

Dec 7th, 2019, Issue no.13, ISO 26262-4, Technical Safety Concept (TSC)

This series is dedicated for the absolute functional safety beginners, system engineers or software engineers or anyone wants to know about automotive functional safety ISO 26262 standard from ZERO

Introduction

This article describes the safety mechanisms specs that should be included in the technical safety concept document. In the last article, we talked about the TSR's specs and the first specs of the safety mechanisms. We will talk about safety mechanisms that address the transition to safe state and latent faults. We also, will talk about the types of self-test.

Safety Mechanisms

According to ISO 26262-4, clause 6.4.2.2:

For each safety mechanism that enables an item to achieve or maintain a safe state, the following shall be specified:

a) the transition between states;

this means that you have to define set of requirement upon the transition from the drive-train state/ normal operating mode to the safe state.

// REQ_01: De-energize the steering assist motor before the transition to the safe state ID01
// REQ_02: blah blah        

These requirements could be specified in a separate state or in the state machine of the Safe Sate prior of the real execution of the safe state.

b) the fault handling time interval "FHTI" w.r.t the timing requirements assigned from the appropriate architectural level; and

// REQ_01: De-energize the steering assist motor before the transition to the safe state ID01 in max time 100 ms.        

FHTI = FDTI + FRTI;

FDTI: Fault Detection Time Interval; time-span from the occurrence of a fault to its detection

FRTI: Fault Reaction Time Interval; time-span from the detection of a fault to reaching a safe state or to reaching emergency operation

where, FHTI < FTTI, that being said, that we have to detect and react to the fault in 100 ms because the FTTI is 150 ms.

N.B, We have traced the FTTI = 150 ms from the functional safety requirements at the Functional Safety Concept. The FTTI is a specification for the ITEM while the FHTI is a specification for the safety mechanism

In the above figure, the FHTI shall be considered for the safety mechanism according to the system architecture: design A or design B. It is design dependent, if you select the design B, the time interval of detection of the sensor fault to reaction of this fault by de-energizing the actuator, see REQ_01, shall be increased by the transmission and processing time of the communication network and the gateway.

c) the emergency operation tolerance time interval "EOTTI", if the safe state of the item cannot be reached within the FTTI.

This specification is to provide emergency operation to be executed if the safe state cannot be reached within the FTTI. Look at scenario no.3 in the following figure:

The emergency operation is an operating mode defined as part of the warning and degradation strategy. Emergency operation is initiated prior to the end of the FTTI and is maintained until the safe state is reached prior to the end of the emergency operation tolerance time interval. That being said, there is a new parameter that shall be defined: EOTTI.

6.4.2.3 This requirement applies to ASILs (A), (B), C, and D. If applicable, safety mechanisms shall be specified to prevent faults from being latent.

For example, there is a faulty resistor in the brake system but this fault is latent because the brake has not engaged yet. But what is latent? let's check the following flowchart that demonstrates the failure modes classification, from ISO 26262-5 annex B:

Latent faults are multiple-point faults whose presence are not detected by a safety mechanism nor perceived by the driver within the?multiple-point fault detection interval (MPFDI)

NOTE 1 Only random hardware faults which are multiple-point faults have the potential to be latent.

EXAMPLE Self-tests are safety mechanisms which verify the status of components during the different operation modes (e.g. power-up, power-down, during operation or in an additional self-test mode) to detect multiple-point faults. Valve, relay or lamp function tests that take place during power up routines are examples of self-tests.

Therefore, there are three types of self-test:

Offline self-test

Vehicle start-up – test as much as possible within the vehicle start-up time constraints

Online self-test

Vehicle Shutdown or diagnostic testing – maximum test coverage, no time constraints when vehicle powered down

Periodic self-test

Diagnostic testing during the operating mode of the vehicle or in additional self-test mode during the normal operation

The fault will not be detected until the item is used. That being said, until the task periodicity comes into execution. Therefore, there is a need to make periodic self-test for some critical ASIL-D items. The primary goal is to guarantee high self-test quality without affecting the deadline requirements of normal hard real-time tasks with appropriate selection of the periodicity of the self-test tasks.

Hypothetically, how can we design an appropriate periodic self-test time for an item?

Suppose we have Time Triggered Architecture, TTA.

Task 1 & Task 2 have highest frequency, while another event driven task(ASILD) is low likely to occur in comparison with T1 &T2, from HARA it might has exposure E4. Therefore, we we can assign Task no.5 for its periodic self-test, which is executed once on the major cycle.

Why didn't you make periodic self test for T1 & T2?

Because both tasks' periods are short and inside their routine, plausibility checks are performed before firing their outputs

The microcontrollers with ASIL rated have on chip HW mechanisms for Built-In Self-Test.?Executing a full BIST at start-up will exceed the needs of many users. Online testing is mainly intended for a full BIST of the MCU, typically performed prior to shutdown of the ECU, when execution time is not as critical, see the following BIST block diagram:

The BIST can test the logic of the computing & the memory and this coverage can be full or limited according to the configuration of the self test control unit of the microcontroller.

Logic BIST: ALU, safety core, checker core,and peripherals

Memory BIST: test instruction memory and data memory of safety core, Cache, DMA and system RAM.

What if there is no a safety mechanism to cover your certain peripheral?

You have to implement your STL? Self-Test Library

The BIST is used to detect the latent fault of the system platform (microcontroller). This is different from testing Item elements. For example, if you have a modem in your item and you want to test it:

// Functional self-test pseudo code for GPS

__const flash uint8 TestCmd[] = "AT\r\0";

__const flash uint8 LogMsgs[2][7] = { "OK","NOT OK"};

 uint8 respBuf[10]={0};

Void RunSelfTest(void)
{
 
  Send_AT_Command(TestCmd, respBuf, strlen(respBuff)); 

  if(respBuf[0] == 'O' && respBuf[1] == 'K')  
  {
  
   LOG(LogMsgs[0][7]); // Modem is OK
  }
  
  else 
  {
   LOG(LogMsgs[1][7]); // Modem is not OK
  }
   
  
  //...        

Conclusion

We have seen how to specify a safety mechanism for safe state transition, fault handling time and emergency operation interval. In addition, we have seen how to specify safety mechanisms to address the latent faults. We demonstrate different types of self-test types to detect latent faults.

We are still in technical safety concept.

If you have insights in this subject, you can share with us and enrich the content!

Stay tuned!

References:

• Wikipedia
• ISO 26262:2018
• NXP application note for MPC5777M?
• Google images