Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions safety-analysis/telltale/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Telltale Safety Analysis

## Purpose and scope

This section of the repository hosts the OSEP working group's analysis of the Automotive Working Group's [Instrument Cluster use case](https://github.com/elisa-tech/wg-automotive/tree/master/Cluster_Display_Use_Case_v2).

There are two distinct parts to this:

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

Our focus is on the specific mechanism that verifies that the telltales are displayed correctly, and the roles and responsibilities that Linux has in supporting this. 'Displayed correctly' in this context means that the rendering of the telltale portions of the display have resulted in a specified result on the screen, within an specified timeframe.

Looking at [this diagram](https://raw.githubusercontent.com/elisa-tech/wg-automotive/master/Cluster_Display_Use_Case_v2/stpa/Telltale-control-structure-minimal.svg) from the Automotive WG:

* 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)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest insertion:

  • The question how the Display works with regards to ensuring/making observable that the telltale display, as well as the user notification about potential safety violations, actually performs as expected, is part of a follow-on iteration in the future, as well as another potential system/analysis boundary

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dakrbo. I've added an extra paragraph - does this capture your points?


The latter is an additional safety mechanism that has been proactively added in the system concept, but we may want to omit it for our initial stage of analysis, to better understand the context that may make it necessary, and explore other options.

The question of how the Display component might be involved in ensuring that the telltales are correctly displayed, or notifying the user in the even of lost or degraded safety functionality, is part of a future iteration of analysis, and belongs to another potential system/analysis boundary.
45 changes: 45 additions & 0 deletions safety-analysis/telltale/element-view.dot
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
digraph G {

node [shape=box width=1 height=0.5
fontname=arial fontsize=16
style=filled fillcolor=white]
graph [splines=ortho ranksep=0.8 newrank=true
nodesep=0.8 compound=true
fontname=arial fontsize=16]

subgraph cluster_cluster {
label="Instrument Cluster" style=rounded labeljust=l margin=15
init [label="Init process" width=3]
subgraph cluster_processes {
label="Other processes" fontsize=12
style=rounded penwidth=0.5
margin=10 bgcolor=lightgrey
receiver [label="Dashboard\nManager" width=3.5]
checker [label="Telltale\nChecking" penwidth=3]
other [label="Other GUI\nprocesses"]
render [label="GUI\nRendering" width=3]
}
os [label="Linux\nKernel" width=5]
}
can [label="Communications"]
display [label="Display"]

{rank=same; checker; render}

init -> os
init -> os [dir=back]
init -> os [dir=back style=dashed]
init -> receiver [lhead=cluster_processes]
init -> receiver [dir=back style=dashed lhead=cluster_processes]
receiver -> checker
receiver -> render
render -> os [ltail=cluster_processes]
render -> os [dir=back style=dashed ltail=cluster_processes]
other -> render
render -> checker
checker -> os
receiver -> os [dir=back style=dashed]
os -> can
os -> can [dir=back style=dashed]
os -> display
}
Binary file added safety-analysis/telltale/element-view.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
30 changes: 30 additions & 0 deletions safety-analysis/telltale/item-view.dot
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
digraph G {

node [shape=box width=1 height=0.5
fontname=arial fontsize=16
style=filled fillcolor=white]
graph [splines=ortho ranksep=0.5 newrank=true
nodesep=0.2 compound=true
fontname=arial fontsize=16]

driver [label="Driver of\n vehicle"]
subgraph cluster_vehicle {
label="Vehicle systems" style=rounded
source [label="Other\nSource"]
requester [label="Telltale\nSource"]
}
cluster [label="Instrument\nCluster" style=bold width=2.5]
display [label="Display" width=2]
watchdog [label="Watchdog"]
backlight [label="Display backlight"]

{rank=same; driver;source}
driver->display [dir=back style=dashed]
source -> cluster
requester -> cluster
cluster -> watchdog
cluster -> display
cluster -> display [dir=back style=dashed]
watchdog -> backlight
display -> backlight [dir=back style=dashed]
}
Binary file added safety-analysis/telltale/item-view.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.