Telltale Safety Analysis

Analysis Results

Analysis results will be documented in the GitHub repo.

Journal

We will use this Wiki to keep a journal of our discussions, so that others can follow our progress. However, the goal is to distil and refine the results of these discussions into a structured and peer-reviewed documentation in the main repository.

08 June 2023

Scope definition

Two distinct parts:

• General instrument cluster / dashboard display (non-safety)
• Specific telltale notifications as part of this display

What are the safety mechanisms that we are concerned with?

• e.g. Specific mechanism that verifies that the telltales are displayed correctly
• 'Correctly' meaning that the rendering of the telltale portions of the display have resulted in the correct result on the screen

Looking at this diagram:

• The system boundary is an ECU running an operating system (involving Linux) that is responsible for executing the cluster display and associated processing
• The checking control and safety manager are the safety-relevant components that implement the safety mechanism
• The dashboard manager may also be safety relevant, because it provides the input data to the checking control
• The watchdog may be internal to the ECU or external (future design decision)
  • This is an additional safety mechanism that we have proactively added at this stage, but we may want to omit it at the initial stage of analysis

Does the type of telltale(s) that we are considering make a difference to our analysis?

• i.e. the ASIL determination
• By their nature, telltales tend to be lower ASIL, because there is an assumption that action from the driver needs to happen within a reasonably timeframe
• For a higher severity problem an additional warning mechanism would be required, but the telltale display may still play a part in the expected response
• For initial consideration, let’s think about a Check Engine warning.