├── .gitignore ├── documentation ├── Example_requirements.png └── qemu.md ├── Cluster_Display_Use_Case_v2 ├── Item_Defintion │ ├── Papyrus_Model │ │ ├── Cluster_demo_en_US.properties │ │ ├── Cluster_demo │ │ │ ├── icons │ │ │ │ ├── Class.gif │ │ │ │ ├── Model.gif │ │ │ │ ├── Package.gif │ │ │ │ ├── Profile.gif │ │ │ │ ├── Diagram_Profile.gif │ │ │ │ ├── Diagram_Requirement.gif │ │ │ │ ├── Diagram_InternalBlock.gif │ │ │ │ ├── Diagram_SysML_Package.gif │ │ │ │ ├── Diagram_BlockDefinition.gif │ │ │ │ ├── Diagram_SysML_Activity.gif │ │ │ │ ├── Diagram_SysML_Sequence.gif │ │ │ │ └── Diagram_SysML_StateMachine.gif │ │ │ ├── resources │ │ │ │ ├── js │ │ │ │ │ ├── hyperlink.js │ │ │ │ │ ├── script.js │ │ │ │ │ ├── split.min.js │ │ │ │ │ └── simpletreemenu.js │ │ │ │ └── css │ │ │ │ │ └── simpletree.css │ │ │ ├── index.html │ │ │ ├── Cluster_demo │ │ │ │ ├── Blocks │ │ │ │ │ └── NominalFunction.SVG │ │ │ │ └── NewSysML1.6RequirementDiagram.SVG │ │ │ └── SysML │ │ │ │ ├── ConstraintBlocks │ │ │ │ └── ConstraintBlocks.SVG │ │ │ │ └── Allocations │ │ │ │ └── Allocations.SVG │ │ ├── .project │ │ ├── Cluster_demo.di │ │ ├── Style_Sheet.css │ │ └── Cluster_demo_de_DE.properties │ ├── Operational_states.puml │ ├── Block_diagram_nominal.puml │ ├── Sequence_diagram_safety.puml │ ├── Block_diagram_with_safety.puml │ ├── Sequence_diagram_nominal.puml │ └── Item_Definition.md └── stpa │ ├── system-context.dot.png │ ├── cluster-control-structure.dot.png │ ├── ucas.md │ ├── system-context.dot │ ├── telltale2.md │ ├── README.md │ ├── purpose.md │ ├── cluster-control-structure.dot │ ├── structure.md │ ├── telltale.yml │ └── telltale.md ├── Initialy_discussed_system_scope ├── images │ ├── tsc-schematic.png │ ├── tsc-diagnostics-tft.png │ ├── tsc-normal-operation.png │ ├── tsc-diagnostics-communication.png │ ├── tsc-diagnostics-image-generator.png │ └── image-display.md └── telltale.md ├── AGL_cluster_demo_use_case ├── Safety-analysis │ ├── Safety_analysis.xlsx │ ├── Diagrams_onlineview.md │ ├── Determine_Safety_status.puml │ └── Safety_demo_analysis.puml ├── Telltale_concept_files │ ├── Block_Diagram.png │ └── Sequence_Diagram.png ├── Architecture │ ├── Arch_naiv_message_based.puml │ ├── Sequence-Diagram │ │ ├── Sequence_diagram.md │ │ └── Sequence_diagram.puml │ ├── Arch_demo.puml │ ├── Arch_demo_mockup.puml │ └── Diagrams_onlineview.md ├── Item Defintion │ ├── Block_diagram_demo.puml │ ├── Block_diagram.puml │ └── Item Definition.md ├── readme.md └── Concept.md ├── AGL-cluster-demo-documentation ├── Main_onlineview.md ├── Arch_naiv.puml └── Main.puml ├── index.html ├── Docker_container ├── elisa.dockerfile └── Readme.md ├── README.md └── LICENSE /.gitignore: -------------------------------------------------------------------------------- 1 | *.metadata/ 2 | -------------------------------------------------------------------------------- /documentation/Example_requirements.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/documentation/Example_requirements.png -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo_en_US.properties: -------------------------------------------------------------------------------- 1 | #Thu Jul 15 09:23:25 CEST 2021 2 | _label_Connector8=Target Rendering State 3 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/system-context.dot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/stpa/system-context.dot.png -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/images/tsc-schematic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Initialy_discussed_system_scope/images/tsc-schematic.png -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Safety-analysis/Safety_analysis.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/AGL_cluster_demo_use_case/Safety-analysis/Safety_analysis.xlsx -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/images/tsc-diagnostics-tft.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Initialy_discussed_system_scope/images/tsc-diagnostics-tft.png -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/images/tsc-normal-operation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Initialy_discussed_system_scope/images/tsc-normal-operation.png -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Telltale_concept_files/Block_Diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/AGL_cluster_demo_use_case/Telltale_concept_files/Block_Diagram.png -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/cluster-control-structure.dot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/stpa/cluster-control-structure.dot.png -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Telltale_concept_files/Sequence_Diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/AGL_cluster_demo_use_case/Telltale_concept_files/Sequence_Diagram.png -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/images/tsc-diagnostics-communication.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Initialy_discussed_system_scope/images/tsc-diagnostics-communication.png -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/images/tsc-diagnostics-image-generator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Initialy_discussed_system_scope/images/tsc-diagnostics-image-generator.png -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Class.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Class.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Model.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Model.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Package.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Package.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Profile.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Profile.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_Profile.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_Profile.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_Requirement.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_Requirement.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_InternalBlock.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_InternalBlock.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_Package.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_Package.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_BlockDefinition.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_BlockDefinition.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_Activity.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_Activity.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_Sequence.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_Sequence.gif -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_StateMachine.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/elisa-tech/wg-automotive/HEAD/Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/icons/Diagram_SysML_StateMachine.gif -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Architecture/Arch_naiv_message_based.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | [Watchdog] 3 | package "Linux"{ 4 | [Safety signal source] -- [QT App] : periodically get Image 5 | [Safety signal source] --> [Safety App] : Message 6 | [Safety App] -->[Watchdog] : Pet 7 | } 8 | @enduml -------------------------------------------------------------------------------- /AGL-cluster-demo-documentation/Main_onlineview.md: -------------------------------------------------------------------------------- 1 | # Github display of the Cluster display app control flow 2 | 3 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL-cluster-demo-documentation/Main.puml) 4 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Architecture/Sequence-Diagram/Sequence_diagram.md: -------------------------------------------------------------------------------- 1 | # Sequence Diagram 2 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL_cluster_demo_use_case/Architecture/Sequence-Diagram/Sequence_diagram.puml) 3 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/.project: -------------------------------------------------------------------------------- 1 | 2 | 3 | Playground 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo.di: -------------------------------------------------------------------------------- 1 | 2 | 3 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Architecture/Arch_demo.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | [Watchdog] 3 | package "Linux"{ 4 | [Safety signal source] --> [QT App] : Montitor QT App, alternatively external checker HW 5 | [Safety signal source] .> [Safety App] : cyclic Message thumbs up/down 6 | [Safety App] ..>[Watchdog] : Pet 7 | } 8 | [Watchdog] --> [Backlight] : kill line 9 | @enduml -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Table of contents 6 | 7 | 8 | Models 9 |

10 | Instrument Cluster Use case v2 11 |

12 | 13 | 14 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Architecture/Arch_demo_mockup.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | [Watchdog] 3 | package "Linux"{ 4 | [Safety signal source] --> [QT App] : Trigger corruption 5 | [Safety signal source] .> [Safety App] : cyclic Message thumbs up/down 6 | [Safety App] ..>[Watchdog] : Pet 7 | [Safety App] -->[QT App] : Trigger Display of Warning Message 8 | } 9 | [Watchdog] --> [Backlight] : kill line 10 | @enduml -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/resources/js/hyperlink.js: -------------------------------------------------------------------------------- 1 | // Eclipse Public License Copyright (c) 2017 CEA LIST 2 | // use to interpret Papyrus hyperlinks 3 | 4 | function displayMessage (evt) { changeDiagram(evt.data);} 5 | if (window.addEventListener) { 6 | window.addEventListener("message", displayMessage, false); 7 | }else { 8 | window.attachEvent("onmessage", displayMessage); 9 | } -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Style_Sheet.css: -------------------------------------------------------------------------------- 1 | Association { 2 | fontName:"Segoe UI"; 3 | routing:Rectilinear; 4 | lineColor:#000000 5 | } 6 | 7 | Association.Association { 8 | fontName:"Segoe UI"; 9 | routing:Rectilinear; 10 | lineColor:#000000 11 | } 12 | 13 | Association.Connector_style { 14 | fontName:"Segoe UI"; 15 | routing:Rectilinear; 16 | lineColor:#000000 17 | } 18 | 19 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Item Defintion/Block_diagram_demo.puml: -------------------------------------------------------------------------------- 1 | ' Functional perspective Cluster Demo application 2 | @startuml 3 | package "Instrument Cluster" { 4 | [Watchdog] 5 | package "Cluster Controller" { 6 | [QT-Application] 7 | [Safety-Signal-source] 8 | [Safety-App] 9 | } 10 | } 11 | 12 | [Safety-Signal-source] --> [Safety-App] 13 | 14 | [Safety-App] --> [Watchdog] : pet 15 | 16 | [Safety-App] --> [QT-Application] : Corruption trigger 17 | @enduml 18 | 19 | 20 | -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/images/image-display.md: -------------------------------------------------------------------------------- 1 | # Normal Operation 2 | ![tsc-normal-operation](tsc-normal-operation.png) 3 | 4 | # Diagnostics Communication 5 | ![tsc-diagnostics-communication](tsc-diagnostics-communication.png) 6 | 7 | # Diagnostics Image Generator 8 | ![tsc-diagnostics-image-generator](tsc-diagnostics-image-generator.png) 9 | 10 | # Diagnostics TFT 11 | ![tsc-diagnostics-tft](tsc-diagnostics-tft.png) 12 | # Schematic 13 | ![tsc-schematic](tsc-schematic.png) 14 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/ucas.md: -------------------------------------------------------------------------------- 1 | # Identify Unsafe Control Actions 2 | 3 | ## Definitions 4 | > An Unsafe Control Action (UCA) is a control action that, in a particular 5 | context and worst-case environment, will lead to a hazard. 6 | 7 | ## Unsafe Control Actions 8 | 9 | **Note**: This is a work in progress and is not yet complete 10 | 11 | UCAs Have been documented for the following components: 12 | 13 | * [Request Handler](telltale.md#unsafe-control-action-summary-1) 14 | * [Telltale Checking](telltale.md#unsafe-control-action-summary-3) 15 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo_de_DE.properties: -------------------------------------------------------------------------------- 1 | #Thu Jul 15 09:23:25 CEST 2021 2 | _label_Rendered\ Bitmap=Rendered Bitmap 3 | _label_Connector8=Target Rendering State 4 | _label_Connector7=Read Configuration Data 5 | _label_Cluster_demo__Blocks__Cluster\ Display\ System__Interaction_nominal_function__ActionExecutionSpecification3=Handle request 6 | _label_Connector5=Post Processed Image\: Scaling, alpha and color correction etc 7 | _label_Connector11=Polling 8 | _label_InteractionOperand0__Render\ Frame=Render Frame 9 | _label_Connector13=Post Processed Image\: Scaling, alpha and color correction etc 10 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Operational_states.puml: -------------------------------------------------------------------------------- 1 | ' Functional perspective Cluster Demo application 2 | @startuml 3 | 'skinparam linetype polyline 4 | ' skinparam linetype ortho 5 | skinparam componentStyle rectangle 6 | 7 | [Startup] as S_startup 8 | [Normal Operation] as S_normal 9 | '[Degraded Operation] as S_degraded 10 | [Safe State] as S_safe_state 11 | 12 | S_startup --> S_safe_state 13 | S_startup --> S_normal 14 | 15 | 'S_normal --> S_degraded 16 | S_normal --> S_safe_state 17 | 18 | 'S_degraded --> S_normal 19 | 'S_degraded --> S_safe_state 20 | 21 | S_safe_state ..> S_startup : Reset 22 | 23 | 24 | @enduml 25 | 26 | -------------------------------------------------------------------------------- /AGL-cluster-demo-documentation/Arch_naiv.puml: -------------------------------------------------------------------------------- 1 | ' Functional perspective 2 | @startuml 3 | [Telltale Requester] 4 | [Request handling] 5 | [Image generation] 6 | [Image Display] 7 | [Telltale checking] 8 | [Telltale Requester] --> [Request handling] 9 | [Request handling] --> [Image generation] 10 | [Request handling] --> [Telltale checking] 11 | [Framebuffer] --> [Image Display] 12 | [Image generation] --> [Framebuffer] 13 | [Framebuffer] --> [Telltale checking] 14 | 15 | package "Linux"{ 16 | [Safety signal source] .. [QT App] : periodically get Image 17 | [Safety signal source] --> [Safety App] : Message 18 | [Safety App] ..>[Watchdog] : Pet 19 | } 20 | [Watchdog] --> [Backlight] : kill line 21 | @enduml -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Safety-analysis/Diagrams_onlineview.md: -------------------------------------------------------------------------------- 1 | # Activity Diagrams 2 | ## Assumption 3 | Assuming the HW to be free of faults, only spatial and temporal interference remain as sources for faults in the execution of the Safety signal source and the Safety app. 4 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL_cluster_demo_use_case/Safety-analysis/Safety_demo_analysis.puml) 5 | ## Variant with external signal source 6 | Assuming an external signal source, we get the following abstract schematic: 7 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL_cluster_demo_use_case/Safety-analysis/Determine_Safety_status.puml) 8 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Safety-analysis/Determine_Safety_status.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 3 | box "SOC" 4 | participant "HW, GPIO etc" order 11 5 | participant "Kernel, drivers, etc" order 12 6 | participant "Safety signal source" order 20 7 | end box 8 | participant "External signal source" order 10 9 | 10 | activate "External signal source" 11 | "External signal source" -> "HW, GPIO etc": Periodic message 12 | "HW, GPIO etc" -> "Kernel, drivers, etc" 13 | "Kernel, drivers, etc" -> "Safety signal source" 14 | activate "Safety signal source" 15 | "Safety signal source" -> "Safety signal source": Check E2E 16 | Alt E2E pass 17 | "Safety signal source" -> "Safety signal source": Decision logic 18 | "Safety signal source" ->]: Send message to Safety App 19 | else E2E miss 20 | end 21 | 22 | @enduml -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Architecture/Diagrams_onlineview.md: -------------------------------------------------------------------------------- 1 | # Suggested Architecture 2 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL_cluster_demo_use_case/Architecture/Arch_demo.puml) 3 | # Suggested Architecture for the mockup/demonstration 4 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL_cluster_demo_use_case/Architecture/Arch_demo_mockup.puml) 5 | # Naive message based Architecture 6 | Massive Safety flaw, messages getting lost can't be detected 7 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/master/AGL_cluster_demo_use_case/Architecture/Arch_naiv_message_based.puml) 8 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Item Defintion/Block_diagram.puml: -------------------------------------------------------------------------------- 1 | ' Functional and SW architecture perspective Cluster Demo application 2 | @startuml 3 | [Telltale Requester] 4 | package "Instrument Cluster" { 5 | together { 6 | [Display] 7 | [Backlight] 8 | } 9 | [Watchdog] 10 | package "Cluster Controller" { 11 | [Request handling] 12 | [QT-Application] 13 | [Safety-Signal-source] 14 | [Safety-App] 15 | } 16 | } 17 | 18 | [Telltale Requester] --> [Request handling] : Telltale Request 19 | [Request handling] --> [QT-Application] 20 | [Request handling] --> [Safety-Signal-source] 21 | 22 | [QT-Application] --> [Display] : Image_out 23 | [Safety-Signal-source] --> [Safety-App] 24 | [Display] --> [Safety-Signal-source] : Image_in 25 | 26 | [Safety-App] --> [Watchdog] : pet 27 | [Watchdog] --> [Backlight] : kill line 28 | [Display] -- [Backlight] 29 | @enduml 30 | 31 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/system-context.dot: -------------------------------------------------------------------------------- 1 | digraph G { 2 | 3 | node [shape=box width=1 height=0.5 fontname=arial fontsize=16 style=filled fillcolor=white] 4 | graph [splines=ortho ranksep=1 nodesep=0.2 fontname=arial fontsize=16 compound=true] 5 | 6 | driver [label="Driver of\n vehicle"] 7 | source [label="Source of State\n Info (non-safety)"] 8 | requester [label="Telltale\nRequester"] 9 | cluster [label="System including\n Instrument Cluster" width=4] 10 | display [label="Display" width=3.5] 11 | watchdog [label="External\nWatchdog"] 12 | backlight [label="Display backlight"] 13 | driver->display [dir=back style=dashed] 14 | source -> cluster 15 | requester -> cluster 16 | cluster -> watchdog 17 | cluster -> display 18 | cluster -> display [dir=back style=dashed] 19 | watchdog -> backlight 20 | display -> backlight [dir=back style=dashed] 21 | } 22 | -------------------------------------------------------------------------------- /AGL-cluster-demo-documentation/Main.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | start 3 | :Setup, QT setup, AGL shell, canvas, command-line parser etc; 4 | if (both command-line options set?) then (yes) 5 | :More Setup; 6 | partition read_config() { 7 | :Read config file; 8 | :Set global variable "runAnimation" accordingly; 9 | } 10 | :Setup QT context properties, including "runAnimation"; 11 | else (no) 12 | endif 13 | partition app.exec() { 14 | :Run QT Application; 15 | fork 16 | if (runAnimation) then (true) 17 | :Change Telltale Status values \n by executing animation sequence \n as defined in App/ValueSource.qml; 18 | else (false) 19 | : Change Telltale status values \n according to messages from the SignalComposer; 20 | endif 21 | fork again 22 | :Refresh display according to \n the Telltale status values; 23 | end fork 24 | } 25 | end 26 | @enduml -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/resources/js/script.js: -------------------------------------------------------------------------------- 1 | // Eclipse Public License Copyright (c) 2017 CEA LIST 2 | 3 | 4 | var changeDiagram = function(value) { 5 | document.getElementById("diagram").data = value; 6 | }; 7 | 8 | 9 | var displayJson = function(value) { 10 | var res = ""; 11 | if (value){ 12 | res = res +"" 17 | if (value.additionalInformations.iconpath){ 18 | res = res + ""; 19 | } 20 | if (value.additionalInformations.diagramPath) { 21 | res = res + ""+ value.text+""; 22 | }else { 23 | res = res + value.text; 24 | } 25 | 26 | if (value.childs && value.childs.length > 0){ 27 | res = res + "" 32 | } 33 | return res+""; 34 | } 35 | return "novalue"; 36 | }; -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/telltale2.md: -------------------------------------------------------------------------------- 1 | # Telltale Control and Data Flow 2 | 3 | Work-in-progress control and data flow diagrams for the Telltale Use Case 4 | 5 | In both diagrams: 6 | 7 | * Blue boxes represent data structures exchanged by controllers 8 | * Dashed lines represent data flow 9 | * The orange box is an external hardware watchdog 10 | 11 | ## Control and data flow with framebuffer checking 12 | 13 | ![Flow with framebuffer check](Telltale-control-structure.svg) 14 | 15 | In this design, a telltale checking algorithm is implemented using Linux, which extracts a rendered image of the display from the framebuffer and searches for the required telltales. 16 | 17 | The hardware watchdog implements the eGas model. 18 | 19 | ## Control and data flow without checking 20 | 21 | ![Flow with framebuffer check](Telltale-control-structure-minimal.svg) 22 | 23 | In this simplified design, the telltale checking is implemented by the display, which means that Linux has a minimal responsibility as part of the safety mechanism. 24 | 25 | The hardware watchdog is a simple model. 26 | 27 | TODO: Define responsibilities for Checking Control and Safety Manager 28 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Safety-analysis/Safety_demo_analysis.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 'skinparam wrapWidth 200 3 | box "Linux" 4 | participant "Safety-Signal-source" order 10 5 | participant "Safety-App" order 20 6 | end box 7 | participant "Watchdog" order 30 8 | participant "Backlight" order 40 9 | 10 | activate "Safety-Signal-source" 11 | activate "Watchdog" 12 | "Safety-Signal-source" -> "Safety-Signal-source": Determine Safety status 13 | note left of "Safety-Signal-source":FM-001: Spatial Interference \n-> Status determination wrong 14 | "Safety-Signal-source" -> "Safety-App": Send cyclic Safety status Message 15 | note left of "Safety-Signal-source":FM-002: Spatial Interference \n-> Message corrupted 16 | note left of "Safety-Signal-source":FM-003: Temporal Interference \n-> Message too early/late/missing 17 | deactivate "Safety-Signal-source" 18 | activate "Safety-App" 19 | "Safety-App" -> "Safety-App": Check E2E 20 | note left of "Safety-App":FM-004: Spatial Interference \n-> E2E check false negative 21 | alt E2E check passes 22 | "Safety-App" -> "Safety-App": Check Safety Signal 23 | note left of "Safety-App":FM-005: Spatial Interference \n-> Safety signal check corrupted 24 | alt Safety signal OK 25 | "Safety-App" -> "Watchdog": Pet watchdog 26 | note left of "Safety-App":FM-006: Spatial Interference \n-> Message corrupted 27 | note left of "Safety-App":FM-007: Temporal Interference \n-> Message too early/late/missing 28 | "Watchdog" -> "Watchdog": watchdog check 29 | else Safety signal NOK 30 | "Watchdog" -> "Watchdog": watchdog check 31 | "Watchdog" -> "Backlight": kill Backlight 32 | end 33 | else E2E miss 34 | "Watchdog" -> "Watchdog": watchdog check 35 | "Watchdog" -> "Backlight": kill Backlight 36 | end 37 | @enduml -------------------------------------------------------------------------------- /Docker_container/elisa.dockerfile: -------------------------------------------------------------------------------- 1 | FROM debian:buster-slim 2 | 3 | ARG DEBIAN_FRONTEND=noninteractive 4 | RUN set -x && apt-get update && apt-get upgrade -y \ 5 | && apt-get install -y curl python \ 6 | gawk wget git-core diffstat unzip texinfo gcc-multilib \ 7 | build-essential chrpath socat libsdl1.2-dev xterm \ 8 | cpio file locales lz4 zstd procps libtinfo5 9 | 10 | RUN echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen && locale-gen en_US.UTF-8 11 | RUN echo "#!/bin/bash\n\nif [ ! -d /src/home ]; then\n\tmkdir /src/home\nfi\n\n/bin/bash" > /bin/start.sh 12 | RUN chmod a+x /bin/start.sh 13 | RUN echo "#!/bin/bash \n\n\ 14 | if [ ! -e \$HOME/.gitconfig ]; then\n\ 15 | echo \"Please enter your name:\"\n\ 16 | read name\n\ 17 | echo \"Thanks \${name}. Please enter your email:\"\n\ 18 | read email\n\ 19 | git config --global user.email \"\$email\"\n\ 20 | git config --global user.name \"\$name\"\n\ 21 | fi\n\ 22 | ln=\`cat \$HOME/.bashrc | grep AGL_TOP | wc -l\`\n\ 23 | if [ \$ln -eq 0 ]; then\n\ 24 | echo 'export AGL_TOP=\$HOME/AGL' >> \$HOME/.bashrc\n\ 25 | fi\n\ 26 | if [ ! -f \$HOME/bin/repo ]; then\n\ 27 | mkdir -p \$HOME/bin\n\ 28 | export PATH=\$HOME/bin:\$PATH\n\ 29 | echo 'export PATH=\$HOME/bin:\$PATH' >> \$HOME/.bashrc\n\ 30 | curl https://storage.googleapis.com/git-repo-downloads/repo > \$HOME/bin/repo\n\ 31 | chmod a+x \$HOME/bin/repo\n\ 32 | fi\n\ 33 | export AGL_TOP=\$HOME/AGL\n\ 34 | if [ ! -d \$AGL_TOP/needlefish ]; then\n\ 35 | mkdir -p \$AGL_TOP/needlefish\n\ 36 | cd \$AGL_TOP/needlefish\n\ 37 | repo init -b needlefish -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo\n\ 38 | repo sync\n\ 39 | git clone https://github.com/elisa-tech/meta-elisa.git\n\ 40 | fi" > /bin/setup_elisa.sh 41 | RUN chmod a+x /bin/setup_elisa.sh && update-alternatives --install /usr/bin/python python /usr/bin/python3.7m 3 42 | 43 | ARG UNAME=elisa 44 | ARG UID=1000 45 | ARG GID=1000 46 | RUN groupadd -g $GID -o $UNAME 47 | RUN useradd -M -u $UID -g $GID -o -s /bin/bash -d /src/home $UNAME 48 | USER $UNAME 49 | CMD /bin/start.sh 50 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Architecture/Sequence-Diagram/Sequence_diagram.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 'skinparam wrapWidth 200 3 | participant "Telltale-requester" 4 | 5 | box "Cluster Controller" 6 | participant "Request handling" order 5 7 | participant "Safety-Signal-source" order 10 8 | participant "QT-Application" order 15 9 | participant "Safety-App" order 20 10 | end box 11 | participant "Watchdog" order 30 12 | participant "Display" order 35 13 | participant "Backlight" order 40 14 | 15 | 16 | activate "Display" 17 | activate "Telltale-requester" 18 | activate "Request handling" 19 | activate "Watchdog" 20 | "Telltale-requester" -> "Request handling" : Telltale request 21 | activate "Safety-Signal-source" 22 | "Request handling" -> "Safety-Signal-source": Telltale request 23 | deactivate "Telltale-requester" 24 | 25 | "Request handling" -> "QT-Application" : Telltale request 26 | activate "QT-Application" 27 | "QT-Application" -> "QT-Application" : Render Image 28 | 29 | "QT-Application" -> "Display": Image_out 30 | deactivate "QT-Application" 31 | "Display" -> "Safety-Signal-source" : Image_in 32 | "Safety-Signal-source" -> "Safety-Signal-source" : Check E2E 33 | 34 | deactivate "Request handling" 35 | "Safety-Signal-source" -> "Safety-Signal-source": Determine Safety status 36 | alt E2E miss or Safety status false 37 | "Safety-Signal-source" -> "Safety-App": Send cyclic Safety status Message requesting safe state 38 | else 39 | "Safety-Signal-source" -> "Safety-App": Send cyclic Safety status Message 40 | end 41 | deactivate "Safety-Signal-source" 42 | activate "Safety-App" 43 | "Safety-App" -> "Safety-App": Check E2E 44 | alt E2E check passes 45 | "Safety-App" -> "Safety-App": Check Safety Signal 46 | alt Safety signal OK 47 | "Safety-App" -> "Watchdog": Pet watchdog 48 | "Watchdog" -> "Watchdog": watchdog check 49 | else Safety signal NOK 50 | "Watchdog" -> "Watchdog": watchdog check 51 | "Watchdog" -> "Backlight": kill Backlight 52 | end 53 | else E2E miss 54 | "Watchdog" -> "Watchdog": watchdog check 55 | "Watchdog" -> "Backlight": kill Backlight 56 | end 57 | @enduml -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/resources/css/simpletree.css: -------------------------------------------------------------------------------- 1 | /* IE 11 hack to avoid overflow */ 2 | @media all and (-ms-high-contrast:none) 3 | { 4 | *::-ms-backdrop, object { height: 80% } / IE11 */ 5 | } 6 | 7 | .diagram-explorer-div{ 8 | float:left; 9 | width: 20%; 10 | } 11 | 12 | .diagram-div{ 13 | float:right; 14 | width: 80%; 15 | } 16 | 17 | .html-editor{ 18 | width: 100%; 19 | } 20 | 21 | ul { 22 | list-style-type: none; 23 | margin: 0; 24 | } 25 | 26 | li { 27 | list-style-type: none; 28 | white-space: nowrap; 29 | } 30 | 31 | .diagram-explorer ul{ /*CSS for Simple Tree Menu*/ 32 | margin: 0; 33 | padding: 0; 34 | } 35 | 36 | .diagram-explorer li{ /*Style for LI elements in general (excludes an LI that contains sub lists)*/ 37 | background: white url(../icons/list.gif) no-repeat left center; 38 | list-style-type: none; 39 | padding-left: 22px; 40 | margin-bottom: 3px; 41 | } 42 | 43 | .diagram-explorer li.submenu{ /* Style for LI that contains sub lists (other ULs). */ 44 | background: white url(../icons/closed.gif) no-repeat left 1px; 45 | cursor: hand !important; 46 | cursor: pointer !important; 47 | } 48 | 49 | 50 | .diagram-explorer li.submenu ul{ /*Style for ULs that are children of LIs (submenu) */ 51 | display: none; /*Hide them by default. Don't delete. */ 52 | } 53 | 54 | .diagram-explorer .submenu ul li{ /*Style for LIs of ULs that are children of LIs (submenu) */ 55 | cursor: default; 56 | } 57 | 58 | 59 | .api { 60 | height: 750px; 61 | border: 1px solid #ddd; 62 | border-radius: 4px; 63 | } 64 | 65 | .split p { 66 | padding: 5px; 67 | } 68 | 69 | .split { 70 | -webkit-box-sizing: border-box; 71 | -moz-box-sizing: border-box; 72 | box-sizing: border-box; 73 | 74 | overflow-y: auto; 75 | overflow-x: hidden; 76 | } 77 | 78 | .gutter { 79 | background-color: #eee; 80 | background-repeat: no-repeat; 81 | background-position: 50%; 82 | } 83 | 84 | .split.split-horizontal, .gutter.gutter-horizontal { 85 | height: 100%; 86 | float: left; 87 | } 88 | 89 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/README.md: -------------------------------------------------------------------------------- 1 | # Cluster Display Use Case - STPA results 2 | 3 | This folder contains the results of applying STPA for the Telltale function of 4 | the Cluster Display use case. 5 | 6 | The analysis is divided into the following sections, based on the stages in the 7 | [STPA Handbook](https://psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf) 8 | 9 | * [Define the purpose of analysis](purpose.md) 10 | * [Model the control structure](structure.md) 11 | * [Identify unsafe control actions](ucas.md) 12 | * Identify loss scenarios 13 | 14 | The results of the STPA are recorded in YAML in [telltale.yml](telltale.yml); 15 | a formatted [markdown version](telltale.md) of the results is rendered using 16 | [stpatools](https://gitlab.com/CodethinkLabs/stpatools) (see below). 17 | 18 | ## Notes 19 | 20 | ### Diagrams 21 | 22 | Control structure diagrams are created using Graphviz; both the source files 23 | (*.dot) and the rendered PNGs are stored in git. 24 | 25 | To render a PNG version of a diagram, you will need to do the following: 26 | 27 | 1) Install [Graphviz](https://graphviz.gitlab.io/download/) 28 | 29 | 2) Run the following command: 30 | ``` 31 | dot -Tpng -O INPUT_FILENAME 32 | ``` 33 | where INPUT_FILENAME is the diagram file (e.g. cluster-control-structure.dot). 34 | 35 | Note that the -O option automatically generates an output filename by appending 36 | .png to the input filename. Use -o*OUTPUT_FILENAME* to specify a different 37 | output filename. 38 | 39 | To output in SVG use -Tsvg instead of -Tpng. 40 | 41 | ### STPA results 42 | 43 | STPA results are recorded in `telltale.yml` using the format described in 44 | [stpatools](https://gitlab.com/CodethinkLabs/stpatools/-/blob/main/doc/FORMAT.md). 45 | 46 | 1) Install [yammlint](https://yamllint.readthedocs.io/en/stable/) 47 | 48 | 2) Install stpatools, use pip3: 49 | ``` 50 | pip3 install git+https://gitlab.com/CodethinkLabs/stpatools 51 | ``` 52 | 53 | 3) To validate the results, use the following commands: 54 | ``` 55 | yamllint -d relaxed telltale.yml 56 | stpa-validate telltale.yml 57 | ``` 58 | 59 | 4) To render in markdown, use the following command: 60 | ``` 61 | stpa-render -o telltale.md telltale.yml 62 | ``` 63 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/readme.md: -------------------------------------------------------------------------------- 1 | # Freeplane and Safety Plugin 2 | The Safety concept map has been created with the mindmap tool freeplane https://www.freeplane.org/wiki/index.php/Home 3 | It's also recommended to install the Safety Concept addon https://github.com/Jochen-Kall/Safety_concept_tool to ensure correct display of the Safety properties and easier modification of the map. It is not strictly necessary just to view the map though. 4 | 5 | # How to identify changed Requirements in a Safety Concept Mindmap 6 | 7 | The .mm file format is .xml based, and every node has a hidden Property "MODIFIED" encoding the date and time of the last modification. 8 | This means that any change in a node implies a change of the "MODIFIED" Property allowing us to extract the IDs of changed requirements using git, which can easily be done with a little bit of bash juggling: 9 | 10 | ## Obtaining the changed lines with git 11 | The following produces the patch series between two revisions of the file with only changed lines and saves it to the Intermediate.txt file instead to a serieos of patch files: 12 | 13 | ```git format-patch .. -U0 --stdout Telltale_concept.mm > Intermediate.txt``` 14 | 15 | ## Extracting the IDs of changed nodes 16 | We now can use grep to find the IDs of changed requirements: 17 | 18 | ```grep -E "ID=\"ID_.{,12}\"" --only-matching Intermediate.txt > Intermediate2.txt``` 19 | 20 | ## Getting rid of doubles 21 | This contains every ID several times, thus to get rid of doubles: 22 | 23 | ```uniq Intermediate2.txt ``` 24 | 25 | ## Piping it all together 26 | Now for the finale, getting rid of the intermediate files and pipe from one step to the next instead 27 | 28 | ```git format-patch .. -U0 --stdout Telltale_concept.mm | grep -E "ID=\"ID_.{,12}\"" --only-matching | uniq``` 29 | 30 | ## Merging and workmode 31 | Since the file format plays nicely with Git, to some extend at least, merging is feasible, so feel free to work on the mindmap and create a pull request. If it turns out it is not, for instance when in each branch the mindmap gets reordered, we can use the method above to perform complex merges by hand, if necessary. 32 | 33 | For safety analysis purpose, the procedure above should make it streight forward to keep the analysis synchronized when moving on to a newer revision of the mindmap. 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/purpose.md: -------------------------------------------------------------------------------- 1 | # Define the purpose of analysis 2 | 3 | ## Goals 4 | 5 | > What kinds of losses will the analysis aim to prevent? Will STPA be applied 6 | only to traditional safety goals like preventing loss of human life or will it 7 | be applied more broadly to security, privacy, performance, and other system 8 | properties? What is the system to be analyzed and what is the system boundary? 9 | 10 | ## System boundary 11 | 12 | ### Definitions 13 | > A system is a set of components that act together as a whole to achieve some 14 | common goal, objective, or end. A system may contain subsystems and may also be 15 | part of a larger system 16 | > A system is an abstraction conceived by the analyst. A decision must be made 17 | about what is included in the system and what the system boundary is. With 18 | respect to engineering, the most useful way to define the system boundary for 19 | analysis purposes is to include the parts of the system over which the system 20 | designers have some control. 21 | 22 | ![Control Structure Diagram for system context](system-context.dot.png) 23 | 24 | ## Notes 25 | 26 | * For next level down, include another application (e,g, IVI) running on the 27 | same system as the Instrument Cluster 28 | - This may have a second display and other peripheral components 29 | 30 | ### Questions 31 | 32 | * What are the telltale requesters? 33 | - These would help us to characterise the possible vehicle-level hazards 34 | * Is there an IVI running on the same SoC as the Cluster? 35 | - Is a Hypervisor involved in the system? 36 | * Are there any other external controllers? 37 | 38 | ## Losses 39 | 40 | ### Definitions 41 | > A loss involves something of value to stakeholders. Losses may include a loss 42 | of human life or human injury, property damage, environmental pollution, loss 43 | of mission, loss of reputation, loss or leak of sensitive information, or any 44 | other loss that is unacceptable to the stakeholders. 45 | 46 | See [Losses](telltale.md#losses). 47 | 48 | ## Notes 49 | 50 | * L-2 and L-3 are included for context, but are not strictly safety-relevant 51 | 52 | ## System Level Hazards 53 | 54 | ### Definitions 55 | 56 | > A hazard is a system state or set of conditions that, together with a 57 | particular set of worst-case environmental conditions, will lead to a loss. 58 | 59 | See [Hazards](telltale.md#hazards) 60 | 61 | ## System-level Constraints 62 | 63 | ### Definitions 64 | 65 | > A system-level constraint specifies system conditions or behaviors that need 66 | to be satisfied to prevent hazards (and ultimately prevent losses) 67 | 68 | See [System Constraints](telltale.md#system-constraints) 69 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/cluster-control-structure.dot: -------------------------------------------------------------------------------- 1 | digraph G { 2 | 3 | node [shape=box width=1 height=0.5 fontname=arial fontsize=16 style=filled fillcolor=white] 4 | graph [splines=ortho ranksep=1 nodesep=0.2 fontname=arial fontsize=16 compound=true] 5 | 6 | vehicle [label="Vehicle" width=5 fillcolor=gray] 7 | cluster [label="Cluster App" width=3] 8 | rank=same{ 9 | requester [label="Telltale requester" width=3 fillcolor=gray] 10 | watchdog [label="Watchdog" width=5 fillcolor=gray] 11 | } 12 | handler [label="Request Handler" width=3] 13 | render_OM [label="Object Model (e.g. QT)" width=3 fillcolor=lightblue] 14 | render [label="Rendering (e.g. QT)" width=4] 15 | dControl [label="Display Controller" width=6.5 fillcolor=gray] 16 | rank=same { 17 | framebuffer [label="Framebuffer" width=2 fillcolor=lightblue] 18 | readbackinterface [label="Readbackinterface" width=2] 19 | } 20 | returnbuffer [label="Returnbuffer" width=3 fillcolor=lightblue] 21 | display [label="Display" width=7 fillcolor=gray] 22 | check [label="Telltale checking" width=4] 23 | 24 | vehicle -> cluster [taillabel="\r\r\r Provide \rvehicle state \r(CAN bus?) \r"] 25 | vehicle -> requester [taillabel="\rProvide Hazard State \r(CAN bus?) \r"] 26 | requester -> handler [taillabel="\rSet telltale status \r(CAN bus?) \r"] 27 | cluster -> render_OM [taillabel="\rUpdate state \r(IPC?) \r"] 28 | cluster -> dControl [taillabel="\r Display \rcontroller \r configuration \r"] 29 | handler -> check [taillabel="\rSet required \rtelltales \r"] 30 | handler -> render_OM [taillabel="\rUpdate telltales \r(IPC?) \r"] 31 | dControl -> display [taillabel="\rProvide \rimage buffer(s) \r"] 32 | render -> dControl [taillabel="\rSet \rbase \raddress \r" weight=2] 33 | render -> framebuffer [taillabel="\rProvide \rimage \rbuffer(s) \r"] 34 | 35 | watchdog -> check [taillabel="\rChallenge \r" style=dashed color=red] 36 | watchdog -> check [dir=back headlabel="\rResponse \r\r"] 37 | watchdog -> check [dir=back headlabel="\rPet \r\r"] 38 | watchdog -> display [taillabel="\rTurn \roff \rbacklight \r"] 39 | framebuffer -> dControl [dir=back taillabel="\r Initate \rDMA \r Transfer \r"] 40 | framebuffer -> dControl [taillabel="\r Frame \r Data \r" style=dashed color=red] 41 | 42 | render_OM -> render [taillabel="\rObject data " style=dashed color=red] 43 | render_OM -> render [dir=back headlabel="\rRead \r\r" ] 44 | check -> returnbuffer [taillabel="\rRead \r"] 45 | check -> returnbuffer [dir=back headlabel="\rImage \rData \r\r" color=red style=dashed] 46 | returnbuffer -> readbackinterface [dir=back headlabel="\rWrite \r" color=red style=dashed] 47 | framebuffer -> readbackinterface [dir=back headlabel="\nRead \n"] 48 | 49 | } 50 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Item Defintion/Item Definition.md: -------------------------------------------------------------------------------- 1 | # Scope 2 | This document describes the assumptions and predefinitions of the ELISA Automtotive workgroup AGL cluster demo use case, and defines terms and identifiers to be used in the rest of the documents. 3 | 4 | This Use case serves several purposes 5 | * Proof of concept of a Safety critical system with non trivial Linux involvement for an automotive use case 6 | * Producing a basis for analysis in the Architecture Workgroup 7 | * Pioneering OSS tooling and collaboration processes for safety work 8 | * Creating an demo application within AGL 9 | * Producing reuseable safety concept building blocks for a generic design pattern 10 | 11 | What this use case is not 12 | * Complete 13 | * entirely realistic 14 | * The safety goals are formulated too strictly, leaving no room for debouncing for instance 15 | * Simplification of the fault handling, a real cluster display would have a degraded mode of operation with simplified graphics instead of shutting off the backlight directly 16 | * directly useable for a real safety project 17 | 18 | ## Description 19 | In general, the Cluster display shows the instruments behind the drivers wheel, including but not limited to speedometer, fuel level, Direction indicator, and telltales. 20 | The display of telltales in particular is safety critical, since telltales are a vital part of the warning and degradation concept of various items in typical car designs. 21 | 22 | ## Hardware 23 | In this use case, to the end of getting something running, no specific Hardware is considered. 24 | The demo runs on a X86-64 target within QEMU [todo: check] with an emulated HW watchdog [currently softdog, will be changed soon] 25 | 26 | ## System Behaviour 27 | ### Block Diagram 28 | The idealized version we base our concept work on, thus is not fully reflected in the implementation of our demo. 29 | Our concept work uses the following block diagram 30 | [todo add Block_diagram.puml] 31 | whereas the part implemented (to some extend) in the demo is 32 | [todo add Block_diagram_demo.puml] 33 | 34 | ## Safety Goals and Safe State 35 | No hara (hazard analysis and risc assessment) was performed for the system. Instead we assume the following safety goals as given: 36 | ### Safety Goal 1 37 | While requested, the system shall display the driver warning within 200 ms or transition to the safe state within 200 ms. 38 | ### Safety Goal 2 39 | The system shall transition to the safe state within 100ms of the display showing an unrequested telltale for longer than 100 ms 40 | ### Safe State 41 | The system wide Safe state is defined as display backlight switched off / black screen. 42 | 43 | ## Interfaces 44 | We only describe the interfacese for the idealized version, the demo version does not have any after all. 45 | 46 | ### Telltale request 47 | ### Watchdog petting 48 | ### Image data forward path 49 | ### Image data backward path 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Block_diagram_nominal.puml: -------------------------------------------------------------------------------- 1 | ' Functional perspective Cluster Demo application 2 | @startuml 3 | skinparam linetype polyline 4 | skinparam linetype ortho 5 | skinparam componentStyle rectangle 6 | [Telltale Requester] as TT_requester 7 | [Non Safety \nInstrument cluster \nstate sources] as other_inputs 8 | 9 | together { 10 | [Display] as AE_Display 11 | [Backlight] as AE_Backlight 12 | } 13 | ' [Power Source] 14 | '[Watchdog] 15 | package "SOC" { 16 | [Request handling /\nDisplay State arbitration] as AE_Request_handling 17 | 18 | package "Rendering (HW/SW)" as pkg_Rendering { 19 | [QM Plane Rendering] as AE_Rendering 20 | '[Safety Plane Rendering] 21 | [Plane Storage] as AE_Plane_Storage #Aqua 22 | } 23 | 24 | package "Autonomous Merge Pipeline 60Hz (HW)" as pkg_DC #grey { 25 | [Plane Blending] as AE_Plane_Blending 26 | [HW Display Interface] as AE_HW_Display_interface 27 | [Configuration Data] as AE_Merge_Pipeline_Configuration_Data #Aqua 28 | } 29 | 30 | 31 | [Initialization] as AE_Initialization 32 | 33 | } 34 | 35 | package "Logical constraint" #green { 36 | [Synchronization] as Synchronization 37 | } 38 | 39 | 'pkg_Rendering -[#blue,bold,dotted]- pkg_DC : Synchronization 40 | 41 | 42 | note top of Synchronization : Rendering and Merging \npipeline need to be synchronized 43 | 44 | [Synchronization] .[dotted,#blue]. pkg_DC 45 | [Synchronization] .[dotted,#blue]. pkg_Rendering 46 | '"Autonomous Merge Pipeline 60Hz (HW)" -- "Rendering (HW/SW)" 47 | 48 | 49 | ' schauen ob wir Synchronisierung visualisiert bekommen 50 | ' package symbole ausblenden 51 | ' Schauen ob wir relative anordnung 52 | 53 | 'Power source 54 | '[Power Source] -[#blue]- SOC 55 | '[Power Source] -[#blue]- [Display] 56 | '[Power Source] -[#blue]- [Watchdog] 57 | '[Power Source] -[#blue]- AE_Backlight 58 | 59 | ' Autonomous Plane blender 60 | AE_Plane_Blending ..> AE_Plane_Storage : Polling 61 | AE_Plane_Blending --> AE_HW_Display_interface : Post Processed Image: \n Scaling, alpha and color correction etc 62 | AE_HW_Display_interface --> AE_Display: Bit Stream 63 | AE_Merge_Pipeline_Configuration_Data .. AE_Plane_Blending 64 | 65 | ' Request handling 66 | other_inputs --> AE_Request_handling : "Non safety display inputs \n (car speed for speedometer, rpm, etc)" 67 | TT_requester -left-> AE_Request_handling : Telltale Request 68 | 69 | AE_Request_handling --> AE_Rendering: Target Rendering State 70 | '[Request handling] --> [Safety Plane Rendering] 71 | '[Request handling] --> [Telltale checking] 72 | 73 | 'Rendering 74 | AE_Rendering --> AE_Plane_Storage: Rendered Bitmap 75 | '[Safety Plane Rendering] --> AE_Plane_Storage 76 | 77 | 'Safety checking 78 | '[HDMI Interface] --> [HDMI Decoding] 79 | '[HDMI Decoding] --> [Telltale checking] 80 | '[Telltale checking] --> [Watchdog] : pet 81 | '[Telltale checking] --> [Calibration Data] 82 | 83 | 'Watchdog 84 | '[Watchdog] --> AE_Backlight : kill line 85 | AE_Display -- AE_Backlight 86 | 87 | AE_Initialization -- AE_Merge_Pipeline_Configuration_Data 88 | @enduml 89 | 90 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/structure.md: -------------------------------------------------------------------------------- 1 | # Model the control structure 2 | 3 | ## Control Structure 4 | 5 | ![Control Structure diagram for Cluster](cluster-control-structure.dot.png) 6 | 7 | ## Notes 8 | 9 | Key 10 | * Grey boxes are controllers that are external to the system (SoC) 11 | - Provide context for input/output across system boundary 12 | * Blue boxes represent controllers that manage data 13 | - These act as 'gateways' between cooperating control hierarchies 14 | * Black arrows represent control actions 15 | * Red dashed arrows represent feedback 16 | 17 | Cluster App 18 | - Receives vehicle state information (via the CAN bus?) 19 | - Updates the display state of vehicle state indicators in teh Object Model 20 | - Configures the Display Controller 21 | 22 | Rendering (Qt) 23 | - Qt framework components are responsible for managing display rendering 24 | - Renders the display to image buffer(s) based on the Object Model 25 | - Updates image buffer(s) in the Framebuffer 26 | - Provides image buffer address to Display Controller (via kernel) 27 | 28 | Framebuffer and Display controller 29 | - Hardware / firmware components in SoC 30 | - Composes image and renders it on the display 31 | 32 | Request Handler 33 | - Receives cyclical messages from various Telltale requesters (E2E protected) 34 | - Missing or corrupted request messages are assumed to request the Telltale in 35 | question 36 | - Underlying Assumption: Telltales are always designed to be safety relevant 37 | in the "activation direction" (if in doubt, show the telltale) 38 | - Arbitrates Telltale requests by logical "or" (in case the same Telltale can be 39 | requested by several requesters). 40 | - Sets the corresponding Telltale-related Rendering States in the Object Model 41 | (once per cycle) 42 | - Triggers Telltale checking for the arbitrated Set of active Telltales (once 43 | per cycle) 44 | 45 | Telltale Checking 46 | - Manages a list of requested telltales (activation status) 47 | - Periodically checks the Displayed image against the set of requested Telltales 48 | - If one or more requested Telltales are not present, or an unrequested Telltale 49 | is present in the displayed Image, Telltale checking does not pet the watchdog 50 | - Otherwise, pets the Watchdog 51 | - Responds to periodic challenges from the Watchdog 52 | 53 | Display 54 | - Provides rendered image data to Telltale checking via Readbackinterface and 55 | Returnbuffer 56 | - How does the kernel facilitate this? 57 | 58 | Watchdog 59 | - Sends periodic challenge to Telltale checking 60 | - If correct response is not received, turns off backlight 61 | - Manages a timer 62 | - Resets the timer when a Pet message is received 63 | - If the timer expires, turns off backlight 64 | 65 | ## Questions 66 | 67 | - Why does the Request Handler communicate with the Telltale Checking by IPC? 68 | - Does telltale requester need to know the vehicle state in order to detect a 69 | hazardous condition? 70 | - Does the Vehicle set the state or do the Cluster App and the Telltale 71 | Requester get it? 72 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Sequence_diagram_safety.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 'skinparam wrapWidth 200 3 | participant "Telltale-requester" as TR #Aqua 4 | 5 | box "Cluster Controller" 6 | participant "Request handling" as Request_handling order 5 7 | participant "QM Plane Rendering" as Rendering_QM order 10 8 | participant "Safety Plane Rendering" as Rendering_Safety order 13 9 | participant "Plane Storage" as Plane_storage order 15 10 | 11 | end box 12 | box "Merge Pipeline" 13 | 'participant "Configuration Data" as Configuration_data order 35 14 | participant "Plane Blending" as Plane_blending order 35 15 | participant "HW Display Interface" as Display_Interface order 40 16 | end box 17 | 18 | box "Safety checking" 19 | participant "Image Decoding" as Decoding order 45 20 | participant "Telltale checking" as Telltale_checking order 50 21 | end box 22 | 23 | participant "Display" as Display order 55 #Aqua 24 | 'participant "Backlight" as Backlight order 40 25 | participant "Watchdog" as WD order 60 26 | 27 | activate TR 28 | TR -> Request_handling : Telltale Request 29 | deactivate TR 30 | 31 | activate Request_handling 32 | Request_handling -> Rendering_QM : Telltale status to render 33 | activate Rendering_QM 34 | Request_handling -> Rendering_Safety : Telltale status to render 35 | activate Rendering_Safety 36 | 37 | Rendering_QM -> Rendering_QM : Rendering 38 | Rendering_QM -> Plane_storage : Writing Frame 39 | activate Plane_storage 40 | 41 | Rendering_Safety -> Plane_storage : Writing Frame 42 | activate Plane_storage 43 | Plane_storage -> Rendering_Safety 44 | deactivate Plane_storage 45 | note right : concurrent writing to plane storage, need to discuss if that is an issue, and how to mitigate if it is. 46 | deactivate Rendering_Safety 47 | 48 | ' Polling while frame is written 49 | Plane_blending --> Plane_storage : Polling Data 50 | note right: "Situation bad synchronization between writing from \n QM rendering, Safety rendering and Polling" 51 | activate Plane_storage 52 | activate Plane_blending 53 | Plane_storage --> Plane_blending 54 | deactivate Plane_storage 55 | Plane_storage --> Rendering_QM 56 | deactivate Rendering_QM 57 | deactivate Plane_storage 58 | 59 | Plane_blending -> Plane_blending 60 | Plane_blending -> Display_Interface 61 | activate Display_Interface 62 | deactivate Plane_blending 63 | deactivate Plane_storage 64 | 65 | Display_Interface-> Display 66 | activate Display 67 | deactivate Display 68 | Display_Interface -> Decoding 69 | deactivate Display_Interface 70 | activate Decoding 71 | activate Telltale_checking 72 | Request_handling -> Telltale_checking 73 | deactivate Request_handling 74 | note right: Timing relevant between Request handling, Rendering and Data polling. \n Need to discuss how that happens, some frame counter for instance. \n Also dovetails with debouncing 75 | Decoding -> Telltale_checking 76 | deactivate Decoding 77 | ' Telltale checking stuff 78 | alt Requested Telltale visible 79 | Telltale_checking -> WD : Pet 80 | activate WD 81 | deactivate WD 82 | else Requested Telltale not visible 83 | alt Debouncing 84 | Telltale_checking -> WD : Pet 85 | activate WD 86 | deactivate WD 87 | else No more debouncing 88 | end 89 | end 90 | 91 | @enduml -------------------------------------------------------------------------------- /documentation/qemu.md: -------------------------------------------------------------------------------- 1 | # qemu call of cluster-demo 2 | 3 | The qemu image as generated by following the instructions from [meta-elisa](https://github.com/elisa-tech/meta-elisa/blob/master/README.md) is called with `qemu-system-x86_64` along with the following parameters: 4 | 5 | needed | option | parameter | meaning 6 | :---|:---|:---|:--- 7 | optional | -snapshot | |Temporary snapshot: write all changes to temporary files instead of hard drive image. | 8 | needed |-device | virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02| 9 | mandatory |-watchdog | i6300esb | 10 | |mandatory|-netdev | user,id=net0,hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23 11 | ||-netdev user| | Use the user mode network stack which requires no administrator privilege to run 12 | ||-netdev id| net0 | ID of the network device 13 | ||-netdev hostfwd|hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23 | Redirect incoming TCP connections to the host port 2222/2323 to the guest IP address on guest 22/23 guestport. 14 | mandatory |-drive | file=./build/tmp/deploy/images/qemux86-64/agl-cluster-demo-platform-qemux86-64.ext4,if=virtio,format=raw | 15 | ||-drive file| This option defines which disk image to use with this drive. If the filename contains comma, you must double it (for instance, "file=my,,file" to use file "my,file"). 16 | ||-drive if | virtio | This option defines on which type on interface the drive is connected. Available types are: ide, scsi, sd, mtd, floppy, pflash, virtio. 17 | ||-drive format | raw | Specify which disk format will be used rather than detecting the format. Specified as format=raw to avoid interpreting an untrusted format header. 18 | ?|-show-cursor || add a mouse cursor to the demo 19 | ?|-usb ||Enable the USB driver (will be the default soon) 20 | ?|-device usb-tablet | Question: Should this become "-usbdevice tablet"? 21 | ? Do we need a virtio random number generator |-device virtio-rng-pci | 22 | ? mandatory |-vga | virtio | Select type of VGA card to emulate 23 | not needed|-soundhw | hda 24 | ? | -machine | q35 | Modern chipset (PCIe, AHCI, ...) adding ",accel=kvm" adds hardware virtualization acceleration 25 | ? |-cpu | kvm64 | Specify a processor architecture to emulate 26 | ? |-cpu | qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt | 27 | ||-enable-kvm | Enable KVM full virtualization support. This option is only available if KVM support is enabled when compiling. 28 | mandatory |-m | 4096 | Set virtual RAM size to 4096 megabytes 29 | optional for now | -smp | 4 | Simulate an SMP system with 4 CPUs 30 | duplicate ||-m | 2048 | Set virtual RAM size to 2048 megabytes 31 | useful | -serial mon:stdio | Redirect the virtual serial port to host character device. The default device is "vc" in graphical mode and "stdio" in non graphical mode. 32 | useful | -serial | null | Redirect the virtual serial port to host character device 33 | mandatory | -kernel | ./build/tmp/deploy/images/qemux86-64/bzImage | Use bzImage as kernel image. The kernel can be either a Linux kernel or in multiboot format. 34 | mandatory | -append | 'root=/dev/vda rw console=ttyS0 mem=4096M ip=dhcp oprofile.timer=1 console=ttyS0,115200n8 quiet ' | Use as kernel command line 35 | 36 | 37 | Information extracted from: 38 | - https://linux.die.net/man/1/qemu-kvm 39 | - https://wiki.qemu.org/Features/VirtIORNG -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Block_diagram_with_safety.puml: -------------------------------------------------------------------------------- 1 | ' Functional perspective Cluster Demo application 2 | @startuml 3 | skinparam linetype polyline 4 | skinparam linetype ortho 5 | skinparam componentStyle rectangle 6 | [Telltale Requester] as TT_requester 7 | [Non Safety \nInstrument cluster \nstate sources] as other_inputs 8 | 9 | together { 10 | [Display] as AE_Display 11 | [Backlight] as AE_Backlight 12 | } 13 | ' [Power Source] 14 | '[Watchdog] 15 | package "SOC" { 16 | [Request handling /\nDisplay State arbitration] as AE_Request_handling 17 | 18 | package "Rendering (HW/SW)" as pkg_Rendering { 19 | [QM Plane Rendering] as AE_Rendering 20 | '[Safety Plane Rendering] 21 | [Plane Storage] as AE_Plane_Storage #Aqua 22 | } 23 | 24 | package "Autonomous Merge Pipeline 60Hz (HW)" as pkg_DC #grey { 25 | [Plane Blending] as AE_Plane_Blending 26 | [HW Display Interface] as AE_HW_Display_interface 27 | [Configuration Data] as AE_Merge_Pipeline_Configuration_Data #Aqua 28 | } 29 | 30 | package "Safety checking 15Hz (HW/SW)" as pkg_Safety_checking { 31 | [Telltale checking] 32 | [Safety Monitor] as AE_Safety_Monitor 33 | [Image Decoding] as image_decoding 34 | } 35 | 36 | [Initialization] as Initialization 37 | 38 | 39 | } 40 | 41 | package "Logical constraint" #green { 42 | [Synchronization] as Synchronization 43 | } 44 | 45 | 'pkg_Rendering -[#blue,bold,dotted]- pkg_DC : Synchronization 46 | 47 | 48 | note top of Synchronization : Rendering and Merging \npipeline need to be synchronized 49 | 50 | [Synchronization] .[dotted,#blue]. pkg_DC 51 | [Synchronization] .[dotted,#blue]. pkg_Rendering 52 | '"Autonomous Merge Pipeline 60Hz (HW)" -- "Rendering (HW/SW)" 53 | 54 | 55 | ' schauen ob wir Synchronisierung visualisiert bekommen 56 | ' package symbole ausblenden 57 | ' Schauen ob wir relative anordnung 58 | 59 | 'Power source 60 | '[Power Source] -[#blue]- SOC 61 | '[Power Source] -[#blue]- [Display] 62 | '[Power Source] -[#blue]- [Watchdog] 63 | '[Power Source] -[#blue]- AE_Backlight 64 | 65 | ' Autonomous Plane blender 66 | AE_Plane_Blending ..> AE_Plane_Storage : Polling 67 | AE_Plane_Blending --> AE_HW_Display_interface : Post Processed Image: \n Scaling, alpha and color correction etc 68 | AE_HW_Display_interface --> AE_Display: Bit Stream 69 | 'AE_Merge_Pipeline_Configuration_Data .. AE_Plane_Blending 70 | 71 | ' Request handling 72 | other_inputs --> AE_Request_handling : "Non safety display inputs \n (car speed for speedometer, rpm, etc)" 73 | TT_requester -left-> AE_Request_handling : Telltale Request 74 | 75 | 76 | AE_Request_handling --> AE_Rendering: Target Rendering State 77 | '[Request handling] --> [Safety Plane Rendering] 78 | '[Request handling] --> [Telltale checking] 79 | 80 | 'Rendering 81 | AE_Rendering --> AE_Plane_Storage: Rendered Bitmap 82 | '[Safety Plane Rendering] --> AE_Plane_Storage 83 | 84 | 'Safety checking 85 | AE_HW_Display_interface --> image_decoding 86 | AE_Request_handling --> [Telltale checking]: Requested Telltale Information 87 | image_decoding --> [Telltale checking] 88 | [Telltale checking] -> AE_Safety_Monitor 89 | AE_Safety_Monitor --> [Watchdog] : pet 90 | 91 | 'Watchdog 92 | [Watchdog] --> AE_Backlight : kill line 93 | AE_Display -- AE_Backlight 94 | 95 | Initialization -- AE_Merge_Pipeline_Configuration_Data 96 | @enduml 97 | 98 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Sequence_diagram_nominal.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 'skinparam wrapWidth 200 3 | participant "Telltale-requester" as TR 4 | 5 | box "Cluster Controller" 6 | participant "Request handling" as Request_handling order 5 7 | participant "QM Plane Rendering" as Rendering_QM order 10 8 | participant "Plane Storage" as Plane_storage order 15 9 | end box 10 | box "Merge Pipeline" 11 | 'participant "Configuration Data" as Configuration_data order 35 12 | participant "Plane Blending" as Plane_blending order 35 13 | participant "HW Display Interface" as Display_Interface order 35 14 | end box 15 | 16 | participant "Display" as Display order 35 17 | 'participant "Backlight" as Backlight order 40 18 | 19 | activate TR 20 | TR -> Request_handling : Telltale Request 21 | deactivate TR 22 | 23 | activate Request_handling 24 | Request_handling -> Rendering_QM : Telltale status to render 25 | deactivate Request_handling 26 | 27 | activate Rendering_QM 28 | Rendering_QM -> Rendering_QM : Rendering 29 | Rendering_QM -> Plane_storage : Writing Frame 30 | 31 | activate Plane_storage 32 | 33 | ' Polling while frame is written 34 | Plane_blending --> Plane_storage : Polling Data 35 | note right: "Situation bad synchronization" 36 | activate Plane_storage 37 | activate Plane_blending 38 | Plane_storage --> Plane_blending 39 | deactivate Plane_storage 40 | Plane_storage --> Rendering_QM 41 | deactivate Rendering_QM 42 | deactivate Plane_storage 43 | 44 | Plane_blending -> Plane_blending 45 | Plane_blending -> Display_Interface 46 | deactivate Plane_blending 47 | deactivate Plane_storage 48 | Display_Interface-> Display 49 | 50 | Plane_blending --> Plane_storage : Polling Data 51 | note right: "Situation good synchronization" 52 | activate Plane_storage 53 | Plane_storage --> Plane_blending 54 | deactivate Plane_storage 55 | 56 | activate Plane_blending 57 | Plane_blending -> Plane_blending 58 | Plane_blending -> Display_Interface 59 | deactivate Plane_blending 60 | 61 | Display_Interface-> Display 62 | 63 | 64 | 65 | 66 | ' activate "Display" 67 | ' activate "Telltale-requester" 68 | ' activate "Request handling" 69 | ' activate "Watchdog" 70 | ' "Telltale-requester" -> "Request handling" : Telltale request 71 | ' activate "Safety-Signal-source" 72 | ' "Request handling" -> "Safety-Signal-source": Telltale request 73 | ' deactivate "Telltale-requester" 74 | 75 | ' "Request handling" -> "QT-Application" : Telltale request 76 | ' activate "QT-Application" 77 | ' "QT-Application" -> "QT-Application" : Render Image 78 | 79 | ' "QT-Application" -> "Display": Image_out 80 | ' deactivate "QT-Application" 81 | ' "Display" -> "Safety-Signal-source" : Image_in 82 | ' "Safety-Signal-source" -> "Safety-Signal-source" : Check E2E 83 | 84 | ' deactivate "Request handling" 85 | ' "Safety-Signal-source" -> "Safety-Signal-source": Determine Safety status 86 | ' alt E2E miss or Safety status false 87 | ' "Safety-Signal-source" -> "Safety-App": Send cyclic Safety status Message requesting safe state 88 | ' else 89 | ' "Safety-Signal-source" -> "Safety-App": Send cyclic Safety status Message 90 | ' end 91 | ' deactivate "Safety-Signal-source" 92 | ' activate "Safety-App" 93 | ' "Safety-App" -> "Safety-App": Check E2E 94 | ' alt E2E check passes 95 | ' "Safety-App" -> "Safety-App": Check Safety Signal 96 | ' alt Safety signal OK 97 | ' "Safety-App" -> "Watchdog": Pet watchdog 98 | ' "Watchdog" -> "Watchdog": watchdog check 99 | ' else Safety signal NOK 100 | ' "Watchdog" -> "Watchdog": watchdog check 101 | ' "Watchdog" -> "Backlight": kill Backlight 102 | ' end 103 | ' else E2E miss 104 | ' "Watchdog" -> "Watchdog": watchdog check 105 | ' "Watchdog" -> "Backlight": kill Backlight 106 | ' end 107 | @enduml -------------------------------------------------------------------------------- /Docker_container/Readme.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | The ELISA Automotive WG docker container bundles everything needed to build the telltale example use case. 3 | This eliminates problems arising from individual build systems by design and helps us with troubleshooting in case of problems. 4 | The Container also contains a premade script taking care of the setup steps. 5 | # Prerequisites and Installation 6 | Install Docker: 7 | -------------- 8 | 9 | Install docker from your distro or you can follow instructions at https://docs.docker.com/engine/install/ 10 | 11 | As a post installation step, following the instructions at [Manage Docker as a non-root user](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user), enables building and running Docker as non-root user. 12 | 13 | 14 | Build the docker image after installing docker: 15 | ---------------------------------------------- 16 | 17 | $ docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) -t elisa -f elisa.dockerfile . 18 | 19 | **Note**: 20 | There is a '.' at the end of the command which is required. 21 | 22 | # Initial Setup and running the ELISA container 23 | Initial compulsory step before setup: Create your working directory and give it a home folder: 24 | ------------------------- 25 | 26 | $ mkdir -p elisa/home 27 | $ cd elisa 28 | $ docker run -it --rm -v $PWD:/src --workdir /src elisa 29 | 30 | After the above commands you should be inside the docker container in a folder named '/src'. 31 | 32 | For setup you can either use the easy way or the expert way. 33 | 34 | Setup step (the easy way): 35 | ------------------------- 36 | 37 | $ setup_elisa.sh 38 | $ cd home/AGL/needlefish/ 39 | 40 | The above command will ask you to enter your name and email and then will configure everything and will also clone the required source code at elisa/home/AGL/needlefish folder. 41 | 42 | 43 | Setup step (the expert way): 44 | --------------------------- 45 | 46 | From AGL: 47 | 48 | $ export AGL_TOP=$HOME/AGL 49 | $ echo 'export AGL_TOP=$HOME/AGL' >> $HOME/.bashrc 50 | $ mkdir -p $AGL_TOP 51 | $ mkdir -p $HOME/bin 52 | $ export PATH=$HOME/bin:$PATH 53 | $ echo 'export PATH=$HOME/bin:$PATH' >> $HOME/.bashrc 54 | $ curl https://storage.googleapis.com/git-repo-downloads/repo > $HOME/bin/repo 55 | $ chmod a+x $HOME/bin/repo 56 | $ cd $AGL_TOP 57 | $ mkdir needlefish 58 | $ cd needlefish 59 | 60 | The next two commands (Setting your name and email adress for use by GIT) are not documented in AGL but needed before 'repo' can be used. 61 | 62 | $ git config --global user.email "you@example.com" 63 | $ git config --global user.name "Your Name" 64 | 65 | Replace the above examples with your actual email and name. 66 | 67 | Last two commands from AGL: 68 | -------------------------- 69 | 70 | $ repo init -b needlefish -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo 71 | $ repo sync 72 | 73 | Instructions from Elisa: 74 | ----------------------- 75 | 76 | $ git clone https://github.com/elisa-tech/meta-elisa.git 77 | 78 | # Building and Rebuilding 79 | 80 | Steps to build: 81 | -------------- 82 | 83 | $ source meta-agl/scripts/aglsetup.sh -f elisa-cluster-demo 84 | $ bitbake elisa-cluster-demo-platform 85 | 86 | You will be still inside the container untill you give the command 'exit'. 87 | 88 | **NOTE**: 89 | 90 | Everything that was cloned or built inside docker will also be available from the host under the folder elisa/home. 91 | After the first run, if you want to build again then most of the above steps are not needed. 92 | Only the following should be sufficient. 93 | 94 | $ cd elisa 95 | $ docker run -it --rm -v $PWD:/src --workdir /src elisa 96 | $ cd $AGL_TOP/needlefish 97 | $ source meta-agl/scripts/aglsetup.sh -f elisa-cluster-demo 98 | $ bitbake elisa-cluster-demo-platform 99 | $ exit 100 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/resources/js/split.min.js: -------------------------------------------------------------------------------- 1 | /*! Split.js - v1.3.5 */ 2 | !function(e,t){"object"==typeof exports&&"undefined"!=typeof module?module.exports=t():"function"==typeof define&&define.amd?define(t):e.Split=t()}(this,function(){"use strict";var e=window,t=e.document,n="addEventListener",i="removeEventListener",r="getBoundingClientRect",s=function(){return!1},o=e.attachEvent&&!e[n],a=["","-webkit-","-moz-","-o-"].filter(function(e){var n=t.createElement("div");return n.style.cssText="width:"+e+"calc(9px)",!!n.style.length}).shift()+"calc",l=function(e){return"string"==typeof e||e instanceof String?t.querySelector(e):e};return function(u,c){function z(e,t,n){var i=A(y,t,n);Object.keys(i).forEach(function(t){return e.style[t]=i[t]})}function h(e,t){var n=B(y,t);Object.keys(n).forEach(function(t){return e.style[t]=n[t]})}function f(e){var t=E[this.a],n=E[this.b],i=t.size+n.size;t.size=e/this.size*i,n.size=i-e/this.size*i,z(t.element,t.size,this.aGutterSize),z(n.element,n.size,this.bGutterSize)}function m(e){var t;this.dragging&&((t="touches"in e?e.touches[0][b]-this.start:e[b]-this.start)<=E[this.a].minSize+M+this.aGutterSize?t=E[this.a].minSize+this.aGutterSize:t>=this.size-(E[this.b].minSize+M+this.bGutterSize)&&(t=this.size-(E[this.b].minSize+this.bGutterSize)),f.call(this,t),c.onDrag&&c.onDrag())}function g(){var e=E[this.a].element,t=E[this.b].element;this.size=e[r]()[y]+t[r]()[y]+this.aGutterSize+this.bGutterSize,this.start=e[r]()[G]}function d(){var t=this,n=E[t.a].element,r=E[t.b].element;t.dragging&&c.onDragEnd&&c.onDragEnd(),t.dragging=!1,e[i]("mouseup",t.stop),e[i]("touchend",t.stop),e[i]("touchcancel",t.stop),t.parent[i]("mousemove",t.move),t.parent[i]("touchmove",t.move),delete t.stop,delete t.move,n[i]("selectstart",s),n[i]("dragstart",s),r[i]("selectstart",s),r[i]("dragstart",s),n.style.userSelect="",n.style.webkitUserSelect="",n.style.MozUserSelect="",n.style.pointerEvents="",r.style.userSelect="",r.style.webkitUserSelect="",r.style.MozUserSelect="",r.style.pointerEvents="",t.gutter.style.cursor="",t.parent.style.cursor=""}function S(t){var i=this,r=E[i.a].element,o=E[i.b].element;!i.dragging&&c.onDragStart&&c.onDragStart(),t.preventDefault(),i.dragging=!0,i.move=m.bind(i),i.stop=d.bind(i),e[n]("mouseup",i.stop),e[n]("touchend",i.stop),e[n]("touchcancel",i.stop),i.parent[n]("mousemove",i.move),i.parent[n]("touchmove",i.move),r[n]("selectstart",s),r[n]("dragstart",s),o[n]("selectstart",s),o[n]("dragstart",s),r.style.userSelect="none",r.style.webkitUserSelect="none",r.style.MozUserSelect="none",r.style.pointerEvents="none",o.style.userSelect="none",o.style.webkitUserSelect="none",o.style.MozUserSelect="none",o.style.pointerEvents="none",i.gutter.style.cursor=j,i.parent.style.cursor=j,g.call(i)}function v(e){e.forEach(function(t,n){if(n>0){var i=F[n-1],r=E[i.a],s=E[i.b];r.size=e[n-1],s.size=t,z(r.element,r.size,i.aGutterSize),z(s.element,s.size,i.bGutterSize)}})}function p(){F.forEach(function(e){e.parent.removeChild(e.gutter),E[e.a].element.style[y]="",E[e.b].element.style[y]=""})}void 0===c&&(c={});var y,b,G,E,w=l(u[0]).parentNode,D=e.getComputedStyle(w).flexDirection,U=c.sizes||u.map(function(){return 100/u.length}),k=void 0!==c.minSize?c.minSize:100,x=Array.isArray(k)?k:u.map(function(){return k}),L=void 0!==c.gutterSize?c.gutterSize:10,M=void 0!==c.snapOffset?c.snapOffset:30,O=c.direction||"horizontal",j=c.cursor||("horizontal"===O?"ew-resize":"ns-resize"),C=c.gutter||function(e,n){var i=t.createElement("div");return i.className="gutter gutter-"+n,i},A=c.elementStyle||function(e,t,n){var i={};return"string"==typeof t||t instanceof String?i[e]=t:i[e]=o?t+"%":a+"("+t+"% - "+n+"px)",i},B=c.gutterStyle||function(e,t){return n={},n[e]=t+"px",n;var n};"horizontal"===O?(y="width","clientWidth",b="clientX",G="left","paddingLeft"):"vertical"===O&&(y="height","clientHeight",b="clientY",G="top","paddingTop");var F=[];return E=u.map(function(e,t){var i,s={element:l(e),size:U[t],minSize:x[t]};if(t>0&&(i={a:t-1,b:t,dragging:!1,isFirst:1===t,isLast:t===u.length-1,direction:O,parent:w},i.aGutterSize=L,i.bGutterSize=L,i.isFirst&&(i.aGutterSize=L/2),i.isLast&&(i.bGutterSize=L/2),"row-reverse"===D||"column-reverse"===D)){var a=i.a;i.a=i.b,i.b=a}if(!o&&t>0){var c=C(t,O);h(c,L),c[n]("mousedown",S.bind(i)),c[n]("touchstart",S.bind(i)),w.insertBefore(c,s.element),i.gutter=c}0===t||t===u.length-1?z(s.element,s.size,L/2):z(s.element,s.size,L);var f=s.element[r]()[y];return f0&&F.push(i),s}),o?{setSizes:v,destroy:p}:{setSizes:v,getSizes:function(){return E.map(function(e){return e.size})},collapse:function(e){if(e===F.length){var t=F[e-1];g.call(t),o||f.call(t,t.size-t.bGutterSize)}else{var n=F[e];g.call(n),o||f.call(n,n.aGutterSize)}},destroy:p}}}); 3 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/telltale.yml: -------------------------------------------------------------------------------- 1 | Losses: 2 | - Identifier: L-1 3 | Text: Loss of life or injury to people (not limited to vehicle occupants) 4 | - Identifier: L-2 5 | Text: Loss of or damage to vehicle 6 | - Identifier: L-3 7 | Text: Loss of or damage to objects outside the vehicle 8 | 9 | Hazards: 10 | - Identifier: H-1 11 | Text: > 12 | Driver is not informed about a system condition, leading to a collision 13 | or other harmful event 14 | Losses: [L-1, L-2, L-3] 15 | - Identifier: H-2 16 | Text: > 17 | Driver is distracted by the display, leading to a collision or other 18 | harmful event 19 | Losses: [L-1, L-2, L-3] 20 | - Identifier: H-3 21 | Text: > 22 | Driver becomes desensitized to a warning because it is incorrectly 23 | repeated, leading to a collision or other harmful event 24 | Losses: [L-1, L-2, L-3] 25 | - Identifier: H-4 26 | Text: > 27 | Content on display compromises the driver (e.g. flickering image triggers 28 | epileptic fit), leading to a collision or other harmful event 29 | Losses: [L-1, L-2, L-3] 30 | 31 | Constraints: 32 | - Identifier: C-1 33 | Text: > 34 | Warning of a potentially harmful system condition must be visible and 35 | noticeable by the driver 36 | Hazards: [H-1] 37 | - Identifier: C-2 38 | Text: > 39 | Display content must not impede the driver in performing the driving task 40 | Hazards: [H-2, H-4] 41 | - Identifier: C-3 42 | Text: > 43 | Erroneous, ambiguous or contradictory information relating to potentially 44 | harmful system conditions must not be persistently displayed 45 | Hazards: [H-3] 46 | 47 | Components: 48 | 49 | - Identifier: RH 50 | Text: Request Handler 51 | 52 | Control Actions: 53 | - Identifier: RH-Set 54 | Text: Set Required Telltales 55 | Target: TC 56 | 57 | Unsafe Control Actions: 58 | 59 | - Identifier: RH-UCA-01 60 | Text: > 61 | RH provides Set Required Telltales when the status of the indicated 62 | telltale has not changed or the wrong telltale is indicated 63 | Reason: Providing 64 | Hazards: [H-1] 65 | 66 | - Identifier: RH-UCA-02 67 | Text: > 68 | RH does not provide Set Required Telltales when the status of a 69 | telltale has changed 70 | Reason: Not Providing 71 | Hazards: [H-1] 72 | 73 | - Identifier: RH-UCA-03 74 | Text: > 75 | RH provides Set Required Telltales after an unacceptably long delay 76 | Reason: Timing 77 | Hazards: [H-1] 78 | 79 | - Identifier: RH-UCA-04 80 | Text: > 81 | RH provides Set Required Telltales during or after a TC check cycle 82 | Reason: Timing 83 | Hazards: [H-1] 84 | 85 | - Identifier: TC 86 | Text: Telltale Checking 87 | 88 | Control Actions: 89 | - Identifier: TC-Read 90 | Text: Read image data from buffer 91 | Target: RB 92 | 93 | Unsafe Control Actions: 94 | 95 | - Identifier: TC-UCA-01 96 | Text: > 97 | TC provides Read when incorrect image data relating to required 98 | Telltales is stored by RB 99 | Reason: Providing 100 | Hazards: [H-1] 101 | 102 | - Identifier: TC-UCA-02 103 | Text: > 104 | TC does not provide Read when new image data is available in RB 105 | Reason: Not Providing 106 | Hazards: [H-1] 107 | 108 | - Identifier: TC-UCA-03 109 | Text: > 110 | TC provides Read when image data in RB is out of date 111 | Reason: Timing 112 | Hazards: [H-1] 113 | 114 | - Identifier: TC-Pet 115 | Text: Pet watchdog 116 | Target: WD 117 | 118 | Unsafe Control Actions: 119 | 120 | - Identifier: TC-UCA-04 121 | Text: > 122 | TC provides Pet when when telltales are not correctly displayed 123 | Reason: Providing 124 | Hazards: [H-1] 125 | 126 | - Identifier: TC-Response 127 | Text: Respond to challenge from Watchdog 128 | Target: WD 129 | 130 | Unsafe Control Actions: 131 | 132 | - Identifier: TC-UCA-05 133 | Text: > 134 | TC provides Response when telltales are not correctly displayed 135 | Reason: Providing 136 | Hazards: [H-1] 137 | 138 | # Rejected the following UCAs becaus ethey do not lead to Hazards 139 | # - TC does not provide Response when telltales are correctly displayed 140 | # - TC provides Response too late when telltales are correctly displayed 141 | 142 | - Identifier: RB 143 | Text: Return Buffer 144 | 145 | Feedback: 146 | - Identifier: RB-FB-Image-Data 147 | Text: Image Data from Readback Interface 148 | Target: TC 149 | 150 | - Identifier: RI 151 | Text: Readback Interface 152 | 153 | Feedback: 154 | - Identifier: RI-FB-Displayed-Image 155 | Text: Image Data from Display 156 | Target: RB 157 | 158 | - Identifier: WD 159 | Text: Watchdog 160 | 161 | Feedback: 162 | - Identifier: WD-FB-Challenge 163 | Text: Challenge to ensure Telltale Checking is still functioning 164 | Target: TC 165 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/stpa/telltale.md: -------------------------------------------------------------------------------- 1 | # Losses 2 | 3 | ## L-1 4 | 5 | Loss of life or injury to people (not limited to vehicle occupants) 6 | 7 | ## L-2 8 | 9 | Loss of or damage to vehicle 10 | 11 | ## L-3 12 | 13 | Loss of or damage to objects outside the vehicle 14 | 15 | 16 | # Hazards 17 | 18 | ## H-1 19 | 20 | Driver is not informed about a system condition, leading to a collision or other harmful event 21 | 22 | 23 | Possible losses: [L-1](#l-1), [L-2](#l-2), [L-3](#l-3) 24 | 25 | ## H-2 26 | 27 | Driver is distracted by the display, leading to a collision or other harmful event 28 | 29 | 30 | Possible losses: [L-1](#l-1), [L-2](#l-2), [L-3](#l-3) 31 | 32 | ## H-3 33 | 34 | Driver becomes desensitized to a warning because it is incorrectly repeated, leading to a collision or other harmful event 35 | 36 | 37 | Possible losses: [L-1](#l-1), [L-2](#l-2), [L-3](#l-3) 38 | 39 | ## H-4 40 | 41 | Content on display compromises the driver (e.g. flickering image triggers epileptic fit), leading to a collision or other harmful event 42 | 43 | 44 | Possible losses: [L-1](#l-1), [L-2](#l-2), [L-3](#l-3) 45 | 46 | 47 | # System Constraints 48 | 49 | | Constraint | Description | 50 | | ---- | ---- | 51 | | C-1 | Warning of a potentially harmful system condition must be visible and noticeable by the driver | 52 | | C-2 | Display content must not impede the driver in performing the driving task | 53 | | C-3 | Erroneous, ambiguous or contradictory information relating to potentially harmful system conditions must not be persistently displayed | 54 | 55 | # Component responsibilities 56 | 57 | | ID | Component | Constraints | Description | 58 | | ---- | ---- | ---- | ---- | 59 | 60 | # RB 61 | 62 | Return Buffer 63 | 64 | ## Unsafe Control Action Summary 65 | 66 | | Control Action | Providing | Not Providing | Timing | Duration | 67 | | ---- | ---- | ---- | ---- | ---- | 68 | 69 | ## Feedback 70 | 71 | ### RB-FB-Image-Data 72 | 73 | Image Data from Readback Interface 74 | 75 | **Target:** [TC](#tc) 76 | 77 | # RH 78 | 79 | Request Handler 80 | 81 | ## Unsafe Control Action Summary 82 | 83 | | Control Action | Providing | Not Providing | Timing | Duration | 84 | | ---- | ---- | ---- | ---- | ---- | 85 | | [RH-Set](#rh-set) | [RH-UCA-01](#rh-uca-01) | [RH-UCA-02](#rh-uca-02) | [RH-UCA-03](#rh-uca-03), [RH-UCA-04](#rh-uca-04) | | 86 | 87 | ## Control Actions 88 | 89 | ### RH-Set 90 | 91 | Set Required Telltales 92 | 93 | **Target:** [TC](#tc) 94 | 95 | #### Unsafe Control Actions 96 | 97 | ##### RH-UCA-01 98 | 99 | RH provides Set Required Telltales when the status of the indicated telltale has not changed or the wrong telltale is indicated 100 | 101 | **Reason:** Providing 102 | 103 | **Possible Hazards:** [H-1](#h-1) 104 | 105 | ##### RH-UCA-02 106 | 107 | RH does not provide Set Required Telltales when the status of a telltale has changed 108 | 109 | **Reason:** Not Providing 110 | 111 | **Possible Hazards:** [H-1](#h-1) 112 | 113 | ##### RH-UCA-03 114 | 115 | RH provides Set Required Telltales after an unacceptably long delay 116 | 117 | **Reason:** Timing 118 | 119 | **Possible Hazards:** [H-1](#h-1) 120 | 121 | ##### RH-UCA-04 122 | 123 | RH provides Set Required Telltales during or after a TC check cycle 124 | 125 | **Reason:** Timing 126 | 127 | **Possible Hazards:** [H-1](#h-1) 128 | 129 | # RI 130 | 131 | Readback Interface 132 | 133 | ## Unsafe Control Action Summary 134 | 135 | | Control Action | Providing | Not Providing | Timing | Duration | 136 | | ---- | ---- | ---- | ---- | ---- | 137 | 138 | ## Feedback 139 | 140 | ### RI-FB-Displayed-Image 141 | 142 | Image Data from Display 143 | 144 | **Target:** [RB](#rb) 145 | 146 | # TC 147 | 148 | Telltale Checking 149 | 150 | ## Unsafe Control Action Summary 151 | 152 | | Control Action | Providing | Not Providing | Timing | Duration | 153 | | ---- | ---- | ---- | ---- | ---- | 154 | | [TC-Pet](#tc-pet) | [TC-UCA-04](#tc-uca-04) | | | | 155 | | [TC-Read](#tc-read) | [TC-UCA-01](#tc-uca-01) | [TC-UCA-02](#tc-uca-02) | [TC-UCA-03](#tc-uca-03) | | 156 | | [TC-Response](#tc-response) | [TC-UCA-05](#tc-uca-05) | | | | 157 | 158 | ## Control Actions 159 | 160 | ### TC-Pet 161 | 162 | Pet watchdog 163 | 164 | **Target:** [WD](#wd) 165 | 166 | #### Unsafe Control Actions 167 | 168 | ##### TC-UCA-04 169 | 170 | TC provides Pet when when telltales are not correctly displayed 171 | 172 | **Reason:** Providing 173 | 174 | **Possible Hazards:** [H-1](#h-1) 175 | 176 | ### TC-Read 177 | 178 | Read image data from buffer 179 | 180 | **Target:** [RB](#rb) 181 | 182 | #### Unsafe Control Actions 183 | 184 | ##### TC-UCA-01 185 | 186 | TC provides Read when incorrect image data relating to required Telltales is stored by RB 187 | 188 | **Reason:** Providing 189 | 190 | **Possible Hazards:** [H-1](#h-1) 191 | 192 | ##### TC-UCA-02 193 | 194 | TC does not provide Read when new image data is available in RB 195 | 196 | **Reason:** Not Providing 197 | 198 | **Possible Hazards:** [H-1](#h-1) 199 | 200 | ##### TC-UCA-03 201 | 202 | TC provides Read when image data in RB is out of date 203 | 204 | **Reason:** Timing 205 | 206 | **Possible Hazards:** [H-1](#h-1) 207 | 208 | ### TC-Response 209 | 210 | Respond to challenge from Watchdog 211 | 212 | **Target:** [WD](#wd) 213 | 214 | #### Unsafe Control Actions 215 | 216 | ##### TC-UCA-05 217 | 218 | TC provides Response when telltales are not correctly displayed 219 | 220 | **Reason:** Providing 221 | 222 | **Possible Hazards:** [H-1](#h-1) 223 | 224 | # WD 225 | 226 | Watchdog 227 | 228 | ## Unsafe Control Action Summary 229 | 230 | | Control Action | Providing | Not Providing | Timing | Duration | 231 | | ---- | ---- | ---- | ---- | ---- | 232 | 233 | ## Feedback 234 | 235 | ### WD-FB-Challenge 236 | 237 | Challenge to ensure Telltale Checking is still functioning 238 | 239 | **Target:** [TC](#tc) 240 | 241 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 |
10 |

My diagram-explorer tree.

11 |
12 |
13 | 14 | Your browser does not support SVG 15 | 16 |
17 |
18 | 19 | 24 | 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/resources/js/simpletreemenu.js: -------------------------------------------------------------------------------- 1 | /*********************************************** 2 | * Dynamic Countdown script- � Dynamic Drive (http://www.dynamicdrive.com) 3 | * This notice MUST stay intact for legal use 4 | * Visit http://www.dynamicdrive.com/ for this script and 100s more. 5 | ***********************************************/ 6 | 7 | var persisteduls=new Object() 8 | var ddtreemenu=new Object() 9 | 10 | //ddtreemenu.closefolder="icons/closed.gif" //set image path to "closed" folder image 11 | //ddtreemenu.openfolder="icons/open.gif" //set image path to "open" folder image 12 | 13 | //////////No need to edit beyond here/////////////////////////// 14 | 15 | ddtreemenu.createTree=function(treeid, enablepersist, persistdays){ 16 | var ultags=document.getElementById(treeid).getElementsByTagName("ul") 17 | if (typeof persisteduls[treeid]=="undefined") 18 | persisteduls[treeid]=(enablepersist==true && ddtreemenu.getCookie(treeid)!="")? ddtreemenu.getCookie(treeid).split(",") : "" 19 | for (var i=0; i 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | Interaction14 79 | 80 | 81 | 82 | 83 | 84 | request Handlin... 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | rendering : Rendering 93 | 94 | 95 | 96 | 97 | 98 | 99 | asdf 100 | 101 | 102 | 103 | 104 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Item_Definition.md: -------------------------------------------------------------------------------- 1 | # Scope 2 | This document describes the assumptions and predefinitions of the ELISA Automotive workgroup cluster demo use case, and defines terms and identifiers to be used in the rest of the documents. 3 | 4 | - [Scope](#scope) 5 | - [Description](#description) 6 | - [Assumptions](#assumptions) 7 | - [Hardware](#hardware) 8 | - [System Behaviour](#system-behaviour) 9 | - [Operational states](#operational-states) 10 | - [State and state change diagram](#state-and-state-change-diagram) 11 | - [Block Diagram nominal function](#block-diagram-nominal-function) 12 | - [Block Diagram Including Safety Checking](#block-diagram-including-safety-checking) 13 | - [Block description](#block-description) 14 | - [Sequence diagrams nominal function during state normal Operation](#sequence-diagrams-nominal-function-during-state-normal-operation) 15 | - [Sequece diagram including telltacle checking during normale Operation](#sequece-diagram-including-telltacle-checking-during-normale-operation) 16 | - [Safety Goals and Safe State](#safety-goals-and-safe-state) 17 | - [Safety Goal 1](#safety-goal-1) 18 | - [Safety Goal 2](#safety-goal-2) 19 | - [Safe State](#safe-state) 20 | - [Interfaces](#interfaces) 21 | - [Telltale request](#telltale-request) 22 | - [Watchdog petting](#watchdog-petting) 23 | - [Image out](#image-out) 24 | - [Safety Concept](#safety-concept) 25 | - [Safety Goal 1](#safety-goal-1-1) 26 | - [Safety Goal 2](#safety-goal-2-1) 27 | 28 | ## Description 29 | In general, the Cluster Display shows the instruments behind the drivers wheel, including but not limited to speedometer, fuel level, Direction indicator, and telltales. 30 | The display of telltales in particular is safety critical, since telltales are a vital part of the warning and degradation concept of various items in typical car designs. 31 | ## Assumptions 32 | * We assume the Display displays image data fed into it with ASIL B integrity, i.e. we do not consider display monitoring of any sort, a backwards path from the Display etc. 33 | * The HW video interface is kept variable in this design at this point. 34 | * We assume the system is reliably supplied with energy. 35 | * We do not consider a degradation state, it can always be added at a later stage. A degradation state would only complicate the system without giving us additional insights. 36 | * We do not consider a specific "off" state since the black display coincides with the safe state. 37 | * We do not consider a windown/shutdown state, it can be added at a later stage withoutout much changes to the system as it is. A windown state would complicate the system without analytical benefit, same as the degradation state. 38 | * We assume monolithic rendering of one all in one plane, opposed to several planes. That does limit the opportunities for telltale checking to checks after the merging pipeline, but is in line with the QT based AGL cluster demo. 39 | * Rationale: The more sophisticated model including several rendering planes might be necessary at some point to achieve sufficient diagnostic coverage, depending on the HW metrics of the Telltale checker element, since checking on rendering plane level allows to pinpoint the source of a malfunction with higher precision. 40 | * Non Monolithic rendering also is prerequisite for a potential degradation mode, should we at some point extend the use case to include it (see above) 41 | * From a safety design perspective, we do not assume that the more complex multi plane variant gives us any additional insights. 42 | * [todo, done, recheck once more] Formulate design with two components, one checking HW or SW and one monitor in SW, to keep it a Linux use case 43 | * We separate the telltale checking functionally to the monitoring/reaction, this enables us to transition from a HW based checker to SW based checker without having to rework the concept completely. 44 | * There are diferent types of tell tales indicating different information i.e. battery level or engine temperature which may have different ASIL level assigned. We limit our analysis to the worst case, seen as ASIL-B. 45 | * [todo, confirm formulation] We assume, that the cyclical message coming in contains the already arbitrated requestet telltale status for all safety relevant telltales. 46 | 47 | ## Hardware 48 | In this use case, to the end of getting something running, no specific Hardware is considered. 49 | The demo runs on a X86-64 target within QEMU with an emulated HW watchdog ("I6300esb") 50 | 51 | ## System Behaviour 52 | ### Operational states 53 | The system operates in three states 54 | * Startup 55 | * No safety assertions 56 | * Image output suppressed 57 | * Transition to normal Operation once everything is in order 58 | * Normal Operation 59 | * Safe state 60 | * Black screen 61 | #### State and state change diagram 62 | ![Alt text](Cluster Display State diagram) 63 | 64 | 65 | ### Block Diagram nominal function 66 | Nominal function absent of safety mechanisms. 67 | 68 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/Cluster_display_v2/Cluster_Display_Use_Case_v2/Item_Defintion/Block_diagram_nominal.puml) 69 | 70 | ![Alt text](test) 71 | 72 | 73 | 74 | [todo] sanity check allocation to AGL cluster demo parts possible? 75 | ### Block Diagram Including Safety Checking 76 | Block diagram including safety mechanisms 77 | 78 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/Cluster_display_v2/Cluster_Display_Use_Case_v2/Item_Defintion/Block_diagram_with_safety.puml) 79 | 80 | Plantuml gets into more and more trouble here to find an acceptable diagram layout... 81 | -> papyrus, but it doesn't let me draw boxes like that 82 | [todo] reflect checker being in HW or SW 83 | 84 | [todo] assumption checking is triggered, hw checker provides an answer -> HW spec still under NDA. 85 | 86 | Plane storage as NUMA 87 | dedicated graphics memory allocation typically 88 | Region blocked for GPU memory 89 | dedicated memory hardware would be very expensive 90 | maybe chip level protection mechanisms (HW) 91 | All SOCs have there specialties, should typically be there. 92 | 93 | clarifying watchdog and Display can be HW / SW 94 | could be WD interface and Display interface 95 | 96 | potentially as subcomponents of our Safety Monitor block 97 | 98 | 99 | ### Block description 100 | [todo] Not accurate anymore, this needs to be aligned with the Papyrus model. 101 | * Telltale requester 102 | * ID: TT_requester 103 | * Description: Source of safety relevant telltale requests. Sends cyclically an E2E protected request indicating whether the telltale shall be displayed or not. 104 | * Display 105 | * ID: AE_Display 106 | * Displays the image data delivered through the HW Display interface. 107 | * The Display of the image data is provided with sufficient Safety Integrity level, see assumption 108 | * Backlight 109 | * ID: AE_Backlight 110 | * Illuminates the Display, Backlight off by means of kill line is used to transition the safe state. 111 | * Request handling/Display State arbitration 112 | * ID: AE_Request_handling 113 | * Function block receiving Telltale requests as well as non safety relevant Information to be displayed in the cluster display. Function block determines the state of the instruments to be rendered and sends that information to the Renderer. 114 | * QM Plane Rendering 115 | * ID: AE_Rendering 116 | * Rendering of the image, either by CPU rasterizer or GPU. Rendered Plane is stored in Plane storage. 117 | * Plane Storage 118 | * ID: AE_Plane_Storage 119 | * Storage for rendered Plane. 120 | * Configuration Data 121 | * ID: AE_Merge_Pipeline_Configuration_Data 122 | * Configuration data of the merger, things like alpha/color correction upscaling etc 123 | * Plane Blending 124 | * ID: AE_Plane_Blending 125 | * Plane blending in HW, image postprocessing, color correction etc 126 | * HW Display Interface 127 | * ID: AE_HW_Display_interface 128 | * Physical HW display interface 129 | 130 | ### Sequence diagrams nominal function during state normal Operation 131 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/Cluster_display_v2/Cluster_Display_Use_Case_v2/Item_Defintion/Sequence_diagram_nominal.puml) 132 | 133 | [Todo] Reflect changes in the Block diagrams 134 | [Todo] Replace with Papyrus model sequence charts, these are no longer accurate! 135 | 136 | ### Sequece diagram including telltacle checking during normale Operation 137 | ![system](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/Jochen-Kall/wg-automotive/Cluster_display_v2/Cluster_Display_Use_Case_v2/Item_Defintion/Sequence_diagram_safety.puml) 138 | 139 | [Todo] Reflect changes in the Block diagrams 140 | [Todo] Replace with Papyrus model sequence charts, these are no longer accurate! 141 | 142 | 143 | ## Safety Goals and Safe State 144 | No hara (hazard analysis and risc assessment) was performed for the system. Instead we assume the following safety goals as given: 145 | ### Safety Goal 1 146 | 147 | While a safety relevant telltale is requested, the system shall display the telltale to human perception within within 200ms 148 | * Info: Timing is debateable, could be relaxed if necessary, does not impact the safety concept (much) 149 | * Info: The safe state of the system cluster display is the black screen. 150 | * Info: "to human perception" means, the periods during which the system does not display the telltale are shorter, than what humans can discern (tbd ms) 151 | * Info: A telltale is considered requested, as soon as telltale request message is received 152 | * Info: The message delay between telltale requester and the system cluster display is out of scope and not considered in this safety concept 153 | * Info: We assume, that the telltale requester sends a request message cyclically and E2E protected, on missing or corrupted messages the cluster display assumes all safety telltales to be requested. [todo] debate, debouncing? 154 | ### Safety Goal 2 155 | 156 | tbd 157 | 158 | ### Safe State 159 | The system wide Safe state is defined as display backlight switched off / black screen. 160 | 161 | ## Interfaces 162 | 163 | ### Telltale request 164 | * The Telltale request is sent cyclically every 200 ms 165 | * The Telltale request contains the information which telltales to show 166 | * The Telltale request is E2E protected 167 | 168 | ### Watchdog petting 169 | * For now we assume a windows watchdog that has to be triggered every x ms 170 | * If necessary, we change the design to an intelligent watchdog, if we need more sophistication, such as control flow monitoring 171 | * If the watchdog is not triggered, it resets the µP and switches off the backlight 172 | * This can be extended to a more realistic design where a not displayed telltale does not directly causes the safe state, but rather switches the system to using a backup image generated by the CPU instead of by the relatively error prone HW graphics pipeline. 173 | * We can extend this to a more realistic design including a reset counter in the µP as opportunity to look into persistent storage 174 | ### Image out 175 | * The Image data is transferred through the HW Display Interface to the Display with a frequency of 60Hz 176 | * We assume the protocol to have E2E protection, and the Display to react to faulty image data by going black (-> Safe state) 177 | 178 | # Safety Concept 179 | ## Safety Goal 1 180 | ## Safety Goal 2 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | -------------------------------------------------------------------------------- /Initialy_discussed_system_scope/telltale.md: -------------------------------------------------------------------------------- 1 | # System definition 2 | The item telltale handles displaying safety relevant warning signs called "telltales" to the driver on the instrument cluster display, in case requested by other systems of the car. 3 | 4 | The requesting system is modelled as a generic controller connected via a bus i.e. CAN. 5 | 6 | Further inputs (involved systems) are the ignition and the battery. While the ignition is off, the display remains black. 7 | 8 | The connection to the Battery is necessary to safely deal with low charge levels that could cause erratic display function. 9 | 10 | Cyclic communication will be necessary, otherwise switch on/off commands can be missed. 11 | 12 | ## Inputs 13 | 1. Telltale request 14 | 1. Battery state 15 | 1. Ignition state 16 | 17 | ## Outputs 18 | None? 19 | 20 | ## Safe States 21 | The safe state of the system is defined by the screen switched off/black. The system is allowed to transition out of the safe state, after Ignition change. 22 | 23 | _[Further point to discuss, could also be allowed to recover if certain underlying transient faults are no more, i.e. corrupted communication between requester and cluster controller]_ 24 | 25 | ## Schematic 26 | [add diagram from google doc](https://docs.google.com/document/d/1GQ9FwFEJz9hLjhK_xTEi2DVBmgU2DBnX/edit#heading=h.wcfczcs05qi2) 27 | 28 | ## Assumptions 29 | It is assumed that the HW of the cluster controller has to be systematically capable in the sense that it either performs correctly or switches itself off, which results in the display not receiving image data and the kill line being pulled down. This implies existence of a window watchdog to ensure there is no temporal misbehaviour. 30 | 31 | Besides the safety relevant telltale functionality, unrelated QM software runs on the cluster controller. 32 | 33 | It is assumed that the High level Safety requirements have ASIL B assigned, since that is the integrity level, typically required for instrument clusters in commercial vehicles. 34 | 35 | ## High level Safety requirements 36 | ### HLSR_1 ASIL B 37 | While the ignition is on and while the System shall display the driver warning within 200 ms or transition to the safe state within 200 ms. 38 | 39 | Information: “while ” means that, if the telltale request persists/is repeated, the system has to continue to display the telltale. 40 | 41 | Need to discuss if Ignition=on is necessary here, if the system is probably not running in the first place while IG=off. 42 | 43 | Information: In Haraki-sans design, the condition is not safety relevant, we leave it in for now, but general consensus is that it is probably not necessary. 44 | 45 | ### HLSR_2 ASIL B 46 | The system shall transition into the safe state within 100ms, if an unmotivated telltale is shown. 47 | 48 | Information: The timing is derived from the temporal resolution of the human eye, flickering shorter than 100ms is not perceived. 49 | 50 | ### HLSR_3 ASIL B 51 | The system shall inform the telltale requester of the status of the telltale (displayed/safe state). 52 | 53 | Information: We cover this requirement mainly to broaden the solution space of projects. 54 | 55 | 56 | # Functional Safety Concept 57 | ## HLSR_1 ASIL B 58 | * [ASIL B] The Telltale requester shall send a request cyclically detailing whether a telltale is needed to be shown or not. 59 | * [ASIL B] The communication between telltale requester and cluster controller shall be E2E protected against data corruption and message loss. 60 | * [ASIL B] The Instrument cluster displays the requested telltale within the timing constraints or transitions to the safe state. 61 | * [ASIL B] The instrument cluster transitions to the safe state if communication is missing, corrupted, or out of order. 62 | * [ASIL B] The chain between Telltale request sent and display/safe state shall be less than 200ms. 63 | 64 | ## HLSR_2 ASIL B 65 | * [ASIL B] The Instrument cluster shall monitor the display and detect display of unrequested tell tales. 66 | * [ASIL B] The instrument cluster shall transition to the safe state within 100ms of showing an unrequested tell tale. 67 | 68 | ## HLSR_3 ASIL B 69 | * [ASIL B] The cluster controller shall send a status message to the telltale requester (displayed/safe state). 70 | * [ASIL B] The chain between telltale request sent and status message received back shall be less than **x ms**. 71 | 72 | 73 | # Technical Safety Concept **_[DRAFT]_** 74 | At this point we have to decide how the system shall be designed between Cluster controller and display. 75 | 76 | Mainly two variants exist: 77 | 1. A safety display that displays is present with the required integrity, diagnoses itself and transitions to black on its own if it diagnoses an internal problem or if the image stream is compromised or not available. 78 | 1. QM Display with a readback path to the Controller is present, and a switch off line allowing the controller to diagnose the Display and transition to the safe state by pulling down the switch off line (e.g. killing the power supply of the backlight), if the requested telltale is not shown within the time threshold). 79 | 80 | Below a draft of more likely scenario 2.) is illustrated 81 | 82 | ## Schematic 83 | [add diagram from google doc](https://docs.google.com/document/d/1GQ9FwFEJz9hLjhK_xTEi2DVBmgU2DBnX/edit#heading=h.aff2dnyejgrd) 84 | 85 | ## HLSR_1 86 | * [ASIL B] The shall send the telltale request containing the information to show or not every 100 ms. 87 | * [ASIL B] The Ignition shall send the Ignition status every 100ms. 88 | * [ASIL B] The Battery shall send the battery status every 100ms. 89 | * [ASIL B] The communication between /Ignition / Battery shall be E2E protected (CRC and message counter). 90 | * [ASIL B] If the Cluster controller does not receive a new telltale request after 100 ms, it shall transition to the safe state by pulling down the kill pin. 91 | * [ASIL B] The Instrument cluster shall check CRC and message counter of incoming messages. 92 | * [ASIL B] If the Cluster controller receives the telltale request too late, corrupted or out of order/ skipped message counter, it shall transition to the safe state by pulling down the kill pin. 93 | * [ASIL B] If the Ignition is off, the Cluster controller shall transition to the safe state by pulling down the kill pin. 94 | * [ASIL B] If the battery charge level is below , the Cluster controller shall transition to the safe state by pulling down the kill pin. 95 | * [ASIL B] The Cluster controller shall embed the telltale into the display stream every 100 ms. 96 | * [QM] The Display shall show the display stream content. 97 | * [QM] The Display shall provide back the image displayed to the Cluster controller within a maximal delay of x ms 98 | * [ASIL B] The Cluster Controller shall transition the System into safe state within x ms by pulling down the kill pin, if the read back image data comes too late or does not coincide with the requested telltale. 99 | * [ASIL B] The Cluster Controller shall pull down the kill pin, in case of an internal fault (-> see assumption). 100 | * [ASIL B] The watchdog shall pull down the kill pin forcing the Display to black, if the Cluster controller fails to trigger it in time. 101 | ** Details not relevant here, this just makes sure the typical clock related failure modes that can’t be diagnosed within the controller are covered. 102 | 103 | ### Conclusions 104 | * With that Design, the immediate focus would lie on correctness of execution and spatial freedom from interference between the safety functionality and the rest. 105 | * Temporal misbehaviour which can’t be ruled out in a modern platform as well as temporal interference is covered by the watchdog and does not have to be addressed. 106 | * Incorrect execution needs to be addressed. 107 | * Spatial freedom from interference needs to be addressed i.e. making sure non safety or different safety functionality does not impede correctness of execution in the safety functionality. 108 | 109 | ## HLSR_2 110 | _[to be addressed]_ 111 | 112 | ## HLSR_3 113 | _[to be addressed]_ 114 | 115 | 116 | # Technical Safety Concept based on Haraki-sans design 117 | Concept draft based on presentation from Haraki-sans slides on the AGL cluster architecture. 118 | 119 | ## Schematic 120 | ![tsc-schematic](images/tsc-schematic.png) 121 | 122 | ## HLSR_1 [ASIL B] 123 | ### Normal Operation 124 | ![tsc-schematic](images/tsc-schematic.png) 125 | 126 | * [ASIL B] The shall send the telltale request containing the information to show or not every 100 ms. 127 | * [ASIL B] The Ignition shall send the Ignition status every 100ms. 128 | * [ASIL B] The Battery shall send the battery status every 100ms. 129 | * [QM] The Cluster controller shall provide the telltale request status to the Image generator every **x ms**. 130 | * [QM] The Image generator shall embed the requested telltales into the the Image. 131 | * [ASIL B] The Image generator shall send back the Image CRC to the Cluster Controller. 132 | * [Assumption] The CRC is taken at the very end of the Image pipeline, or the Image generator functionality after the CRC is taken is of the required Safety Integrity (ASIL B) . 133 | * [ASIL B] The Image generator shall send the Image to be displayed to the Display IC. 134 | * [ASIL B] While the Display IC does not receive a degradation command, it shall pass through the Image data from the Image generator to the TFT. 135 | 136 | 137 | ### Diagnostics Image generator 138 | ![tsc-diagnostics-image-generator](images/tsc-diagnostics-image-generator.png) 139 | 140 | * [ASIL B] The Cluster Controller shall check the Telltale CRC from the Image generator against the expected CRC according to the telltale request. 141 | * [ASIL B] If the Telltale CRC from the Image generator is not as expected, the Cluster controller shall pass on the Telltale information to the Display IC and command degradation. 142 | * [ASIL B] While the Display IC receives a degradation command, it shall ignore the output of the Image generator and generate the Image itself instead. 143 | 144 | ### Diagnostics TFT 145 | ![tsc-diagnostics-tft](images/tsc-diagnostics-tft.png) 146 | 147 | * [QM] The TFT shall provide self diagnostics results to the Display IC. 148 | * [QM] The TFT shall provide the image shown to the Display IC. 149 | * [ASIL B] The Display IC shall monitor the Image shown by the TFT against the Image it sent. 150 | * [ASIL B] The Display IC shall send a safe state request to the cluster controller if Image requested and Image sent does not match, or any TFT fault is detected. 151 | * [ASIL B] The Cluster controller shall pull down the Backlight kill line, if the Display controller requests transition to the safe state. 152 | 153 | ### Diagnostics Communication 154 | ![tsc-diagnostics-communication](images/tsc-diagnostics-communication.png) 155 | 156 | * [ASIL B] The communication between /Ignition / Battery shall be E2E protected (CRC and message counter). 157 | * [ASIL B] If the Cluster controller does not receive a new telltale request after 100 ms, it shall transition to the safe state by pulling down the Backlight kill pin. 158 | * [ASIL B] The Instrument cluster shall check CRC and message counter of incoming messages. 159 | * [ASIL B] If the Cluster controller receives the telltale request too late, corrupted or out of order/ skipped message counter, it shall transition to the safe state by pulling down the Backlight kill pin. 160 | 161 | 162 | ### Temporal protection 163 | Since we have a temporal aspect in the high level safety requirements, a window watchdog is required to protect against malfunctioning of the clock/frequency generator of the controller. 164 | 165 | * [ASIL B] The watchdog shall pull down the kill pin forcing the Display to black, if the Cluster controller fails to trigger it in time. 166 | ** Details not relevant here, this just makes sure the typical clock related failure modes that can’t be diagnosed within the controller are covered. 167 | 168 | ## HLSR_2 [ASIL B] 169 | HLSR_2 is mostly covered by the HSLR_1 concept. Once telltales have been requested from the image generator, showing not requested telltales is covered by the HSLR_1 concept. Additional requirement therefore: 170 | 171 | * [ASIL B] The cluster controller shall only request a telltale insertion from the image generator, if it receives a valid telltale request for that telltale. 172 | 173 | ## HLSR_3 [ASIL B] 174 | _[to be addressed]_ 175 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ELISA Automotive WG 2 | 3 | > [!Caution] 4 | > The Automotive WG is currently paused and **looking for a new Working Group Lead**! 5 | > 6 | > Currently, Automotive activities are handled within the [ELISA Systems WG](https://github.com/elisa-tech/wg-systems/wiki) 7 | 8 | ## Mission statement 9 | The automotive workgroup discusses the conditions and prerequisites the automotive sector needs to integrate Linux into a safety critical system. 10 | 11 | We focus on actual use cases from the Automotive domain to derive the technical requirements to the kernel as a basis for investigation within the Safety Architecture Workgroup and to serve as a blueprint for actual projects in the future. 12 | 13 | This repository contains agreed upon and peer reviewed material for this work group, see [process description below](#contribution-workflow) 14 | 15 | ## Use case 16 | Currently, the Automotive work group focuses on the tell tale use case, i.e. warning symbols in the intstrument cluster of a vehicle, typically rated with ASIL B. 17 | ## Getting in Contact, Getting Involved 18 | ### Mailing list, Calendar etc 19 | Subscribe to our mailing list: 20 | https://lists.elisa.tech/g/automotive 21 | 22 | ### Meetings 23 | 24 | No explicit Automotive meeting is currently conducted until a new host aka working group lead is found. 25 | 26 | Join the [Systems WG](https://lists.elisa.tech/g/systems) meetings instead. They are scheduled weekly on Mondays alternating with Tuesdays every other week. 27 | 28 | See the public ELISA calendar to find the next meeting: https://elisa.tech/community/meetings/ 29 | 30 | _Note: Use Chrome*ium engine in case the calendar is not properly rendered when following the link_ 31 | 32 | ### Newcomer Onboarding Checklist 33 | We welcome newcomer. If you don't find your way forward, most likely it is on the WG to improve documentation. 34 | 35 | If you are interested in becoming the the new Working Group Lead drop a mail on the [ELISA devel mailing list](https://lists.elisa.tech/g/main) 36 | 37 | Other than that, here is a checklist to get you started: 38 | * Sign up for [mailinglist and calendar](#mailing-list-calendar-etc) 39 | * Get to know the [contribution process](#contribution-workflow) 40 | * Check out this repository and explore, [Repo overview](#elisa-automotive-wg---navigation-and-file-locations) 41 | * [Developers] check out the meta-elisa repository to learn how to set up a build environment, build and run the [demo](#first-iteration-of-the-use-case) 42 | 43 | 44 | # Contribution workflow 45 | The automotive working group uses the following github based workflow as base for contributions. 46 | ## Prerequisites 47 | * Git 48 | * Github account 49 | ## Workflow 50 | * If you did not fork and clone yet 51 | * Fork the upstream repo and clone your fork to get a local working copy, details see [click](#initial-setup---forking-and-cloning) 52 | * If you already forked the repository and cloned your fork 53 | * Make sure to start your work on the most recent version of the upstream master branch, for details see [click](#syncing-your-fork-and-local-working-copy-with-the-upstream-repository) 54 | * Create a feature branch based on "master/main" to start your work on [click](#creating-a-feature-branch) 55 | * [Optional for non code repositories] If you suspect the files you intend to work on are being worked on by other members of the group as well, or you want to discuss your planned work beforehand, create an Github issue, see [click](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue). 56 | If you did create an issue, it is best practice to reference the issue in your commit messages. 57 | * Commit changes and push them to your fork see [click](#committing-and-pushing) 58 | * Getting your completed work back into the main repository, aka Pull Requests 59 | * Make sure your feature branch is still based on the most recent master in the upstream repository, see [click](#rebasing-a-feature-branch) 60 | * Make sure all your commits are signed off 61 | * If they are not, github will notify you of failed DCO checks and provide instructions how to sign off afterwards, does not always get it right though. 62 | * Make sure you pushed all commits of your feature branch to your fork on github 63 | * Create a cross fork pull request from your feature branch to elisa-tech/wg-automotive:master on Github 64 | * Important! Do not continue to push revisions to the feature branch, unless you want the changes to become part of the pull request, the moment you push revisions to github, the pull request will be amended automatically! 65 | * You might be asked to rebase your feature branch again, this can become necessary if a pull request is merged in the meantime that has conflicting changes with your feature branch (See [click](#rebasing-a-feature-branch)). 66 | * Review Process 67 | * The pull request is visible and open for comments and discussion on Github. 68 | * Review is considered done if no more unresolved findings/comments remain, no checks fail and 2 group members approved the change. 69 | * Merge ready pull requests are put on the next Workgroup synccall agenda for discussion, if consensus is found, the pull request is merged by an maintainer. 70 | 71 | # Git Newbie section 72 | This section serves as reference for members new to GIT, to be read on demand. 73 | All the GIT black belts out there can stop reading at this point in good concience. 74 | 75 | ## Intital Setup - Git etc 76 | For this workflow, having Git installed and configured is essential. 77 | 78 | Linux users install the git package, Windows users grab git for Windows [click](https://git-scm.com/downloads). 79 | 80 | Both groups need to provide Name and email adress to git: 81 | ``` 82 | git config --global user.email "you@example.com" 83 | git config --global user.name "Your Name" 84 | ``` 85 | 86 | Depending on your preferences and love/tolerance of the commande line, you might also want to get a graphical GIT interface such as 87 | * Tortoise git (Windows) 88 | * Gitkraten 89 | ## Github Workflow in a nut shell 90 | ![Github Workflow](documentation/Github_workflow.svg) 91 | ## Initial Setup - Forking and Cloning 92 | * Fork elisa-tech/wg-automotive within Github [Instructions](https://docs.github.com/en/get-started/quickstart/fork-a-repo) 93 | * Clone the fork [Instructions](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository) 94 | ## Creating a feature branch 95 | With your fork of the repository cloned, proceed to create a feature branch, push it up to github and make your branch track the newly created feature branch. 96 | Make sure to base your feature branch the most recent commit, i.e. sync your fork befor you start your work [click](#syncing-your-fork-and-local-working-copy-with-the-upstream-repository) 97 | 98 | Short example using command line git in the top level folder to fetch the latest revision and create a new branch by the name of "my_feature": 99 | Assuming your fork is on par with the upstream repository, fetch origin to get the revisions to your local clone 100 | ``` 101 | git fetch origin 102 | ``` 103 | Create your feature branch based of origin/master: note the flag --no-track to avoid tracking origin/master, since we are constructing a new feature branch. 104 | ``` 105 | git checkout -b my_feature --no-track origin/master 106 | ``` 107 | Push the new branch to your fork on github and make your branch track it: 108 | ``` 109 | git push -u origin my_feature 110 | ``` 111 | 112 | ## Committing and pushing 113 | * Commit your changes within your local copy using either command line git or a graphical interface (tortoise git, gitkraken etc) 114 | * Quality check your commits 115 | * Sign off your commits using the --signoff flag when using command line git, or the according setting of your GIT Gui, see [click](#signing-off-and-dco) 116 | * Provide a short concise commit message describing the changes 117 | * Reference the github issue you are working on, if applicable with the hashtag syntax #<<"issue number">> in your commit message and pull request message [click](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) This will link your commits/pull request to the issue and make it visible in the github interface 118 | * Push regularly to your Github fork to have a backup of your work 119 | ``` 120 | git push origin 121 | ``` 122 | 123 | ## Signing off and DCO 124 | Using the --signoff flag when committing conveniently adds the signoff line to your commit message 125 | ``` 126 | Signed-off-by: <> 127 | ``` 128 | What if I forgot? 129 | Github will complain when you create a pull request, having signed commits is required! 130 | How to fix it then? 131 | Signing off on the last 3 commits for instance is done by rebasing the current branch on an earlier commit: 132 | ``` 133 | git rebase HEAD~3 --signoff 134 | ``` 135 | Keep in mind, since this changes the history of the repo, if you already pushed, pushing again to overwrite the changelog requires using the --force flag! 136 | 137 | 138 | ## Syncing Your fork and local working copy with the upstream repository 139 | Before starting your work, you need to make sure the files you start out with are up to date to avoid having to fix that afterwards. 140 | This workflow involves three relevant destinations 141 | * The original upstream repository [on Github servers] elisa-tech/wg-automotive 142 | * Your fork of the repo [on Github servers] 143 | * The clone of your fork on your local machine. 144 | 145 | To ensure your files are up to date, your fork needs to be syncronized with the upstream repository to pick up any changes merged since the last time you synced your fork. This sync can be done in the github browser interface with just one click, provided your master branch has no conflicts with the master branch of the upsream repository. To ensure this property, its best to never commit to the master branch of your fork at all. 146 | Github description: 147 | https://docs.github.com/en/github/collaborating-with-pull-requests/working-with-forks/syncing-a-fork#syncing-a-fork-from-the-web-ui 148 | 149 | With your fork syncronized with the upstream repository, we have to make sure any new commits picked up from the upstream repository are propagated to your local clone. 150 | Assuming you refrain from committing to your master branch, the changes can be pulled and fast forwarded: 151 | Command line GIT example with a shell opened in the directory of your local checked out copy: 152 | ``` 153 | git fetch origin 154 | git checkout master 155 | git pull origin --ff-only 156 | ``` 157 | The flag --ff-only restricts the pull operation to fast forward merges, this operation will fail if the current revision in your local copy is not a direct ancestor of the upstream revisions to be pulled, i.e. if you by mistake committed to your local master branch. 158 | For a detailled explanation why that would be highly undesirable even if the merge has no conflicts see [click](https://blog.sffc.xyz/post/185195398930/why-you-should-use-git-pull-ff-only-git-is-a) 159 | 160 | After these two steps, the master branch of all three repositories are synced up, you can inspect the latest revision in the master branch and you are prepared to base a feature branch on synced up master branch. 161 | 162 | ## Rebasing a Feature Branch 163 | While you worked on your feature branch, other pull request might have been merged into the master branch of the upstream repository. 164 | Since could lead to conflicts when merging your branch, you need to make sure that your feature branch is based on the current revision, not the one you started your work with. 165 | This we accomplish by a two step process 166 | * Syncing up your local master with the upstream master, see [click](#syncing-your-fork-and-local-working-copy-with-the-upstream-repository) 167 | * Rebasing your feature branch on master, i.e. GIT will find the bifurcation at which your branch split off master, and reapply all commits in your branch since then to the current master, which results in your branch being "rebased" on the current master instead. 168 | 169 | Command line git example: 170 | ``` 171 | git fetch origin 172 | git checkout my_feature_branch 173 | git rebase origin/master 174 | ``` 175 | 176 | In case of conflicts, rebase will interrupt the process, give you a chance to resolve the conflict and continue. 177 | For a detailled description of the process and commands involved, see [click](https://git-scm.com/docs/git-rebase) 178 | 179 | Now your feature branch is based on the most recent master branch and can be merged without conflicts. 180 | Pushing your rebased feature branch to your github fork requires the use of the -force flag, since rebasing changes the commit history already present in your fork. 181 | 182 | ``` 183 | git push origin -force 184 | ``` 185 | 186 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/Cluster_demo/NewSysML1.6RequirementDiagram.SVG: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | «Requirement» 106 | 107 | Requirement22 108 | id=ID_asdfsdaf 109 | text=Ein abgeleitetes Requirement 110 | 111 | 112 | 113 | 114 | 115 | 116 | «Requirement» 117 | 118 | nocheins 119 | id=ID_wasauchimmer 120 | text=Ein abgeleitetes Requirement 121 | 122 | 123 | 124 | 125 | «Block» 126 | 127 | Display 128 | 129 | 130 | DeriveReqt24 131 | «abstraction, DeriveReqt» 132 | 133 | 134 | 135 | Satisfy14 136 | «abstraction, Satisfy» 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/SysML/ConstraintBlocks/ConstraintBlocks.SVG: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | «Stereotype» 85 | ConstraintBlock 86 | 87 | 88 | 89 | 90 | + getParameters(): Property 91 | 92 | 93 | 94 | «Metaclass» 95 | Class 96 | 97 | 98 | «Stereotype» 99 | Block 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used. Binding connectors, as defined in Chapter 8: Blocks, are used to bind each parameter of the constraint block to a property in the surrounding context. All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks. 115 | 116 | 117 | 118 | 119 | A Class classifies a set of objects and specifies the features that characterize the structure and behavior of those objects. A Class may have an internal structure and Ports. 120 | 121 | 122 | 123 | A Block is a modular unit that describes the structure of a system or element. It may include both structural and behavioral features, such as properties and operations, that represent the state of the system and behavior that the system may exhibit. Some of these properties may hold parts of a system, which can also be described by blocks. A block may include a structure of connectors between its properties to indicate how its parts or other properties relate to one another. SysML blocks provide a general-purpose capability to describe the architecture of a system. They provide the ability to represent a system hierarchy, in which a system at one level is composed of systems at a more basic level. They can describe not only the connectivity relationships between the systems at any level, but also quantitative values or other information about a system. SysML does not restrict the kind of system or system element that may be described by a block. Any reusable form of description that may be applied to a system or a set of system characteristics may be described by a block. Such reusable descriptions, for example, may be applied to purely conceptual aspects of a system design, such as relationships that hold between parts or properties of a system. Connectors owned by SysML blocks may be used to define relationships between parts or other properties of the same containing block. The type of a connector or its connected ends may specify the semantic interpretation of a specific connector. 124 | 125 | 126 | 127 | -------------------------------------------------------------------------------- /AGL_cluster_demo_use_case/Concept.md: -------------------------------------------------------------------------------- 1 | # Safety concept 2 | ## Safety goal: while requested, the system shall display the driver warning within 200 ms or transition to the safe state within 200 ms. 3 |
Unfold Safety Goal

4 | 5 | * [ID_1502911625] [Information] Information: “while ” means that, if the telltale request persists/is repeated, the system has to continue to display the telltale. 6 | * [ID_1052985289] [Information] The 200 ms include the time needed for the request to reach the Cluster demo. This is considered in the frequency of the cyclic communication. 7 | * [ID_1780168904] [FSR] [ASIL B] The Telltale requester shall send a request cyclically controlling whether a telltale is needed to be shown or not. 8 | * [ID_736988533] [TSR] [ASIL B] The Telltale requester shall send the telltale request message every 200 ms 9 | * [ID_529767340] [TSR] [ASIL B] The Telltale request message shall contain a boolean "telltale_request" = 0 if the telltale is not requested and 1 if the telltale is requested 10 | * [ID_950923064] [TSR] [ASIL B] The Telltale request message shall be E2E protected with E2E Protocol xxx 11 | * [ID_1340201467] [Information] We don't specify this in all detail here, Message counter and CRC is needed 12 | * [ID_883554261] [FSR] [ASIL B] All inputs from outside the system, the cluster controller uses to determine whether a requested telltale is shown shall be E2E protected against data corruption out of order transmission and message loss 13 | * [ID_1807969240] [TSR] [ASIL B] The Cluster controller shall monitor messages from the Telltale requester 14 | * [ID_199781775] [TSR] [ASIL B] The Cluster controller shall check the telltale request message for E2E miss 15 | * [ID_1822634618] [Information] We don't specify this in all detail here, Message counter and CRC is needed 16 | * [ID_1213070481] [TSR] [ASIL B] If the cluster controller determines an E2E miss in the tell tale request message, the cluster controller shall transition the system into the safe state 17 | * [ID_1404407311] [TSR] [ASIL B] The Cluster controler shall check all additional inputs from outside the system, the Cluster controller needs to decide whether a requested telltale is displayed for E2E miss 18 | * [ID_114212614] [SW] [ASIL B] The Safety-Signal-Source shall check the additional inputs for E2E misses 19 | * [ID_1017729133] [Information] This refers not only to the telltale request messages from the telltale requester, but also all further inputs the safety-signal source needs to decide whether the requested telltale is displayed or not, e.g. input from a HW checker element, or Image data flowing back from the display 20 | * [ID_1264174165] [TSR] [ASIL B] If the cluster controller determines an E2E miss in an additional input needed for telltale verification, the cluster controller shall transition the system into the safe state 21 | * [ID_1488369061] [SW] [ASIL B] On E2E miss of any input to Safety-signal-source, Safety-signal-source shall request "Safe state" from the safety-app 22 | * [ID_1579674255] [FSR] [ASIL B] The Instrument cluster shall display the requested telltale or transition to the safe state 23 | * [ID_1284231708] [Information] We implement this by splitting into a QM path rendering the Display and a Safety path checking whether the requested telltale is shown or not 24 | * [ID_205232490] [TSR] [QM[B]] The Instrument Cluster shall render the cluster display image within 70ms of the instrument Cluster receiving the message 25 | * [ID_499334358] [SW] [QM[B]] The QT app shall render the image within 70ms of the cluster controller receiving the message 26 | * [ID_874940663] [TSR] [ASIL B] The Instrument Cluster shall determine, whether the requested telltale is displayed 27 | * [ID_994205752] [Information] Safety-signal source part of the control flow 28 | * [ID_745377459] [SW] [ASIL B] The safety-signal-source shall determine, whether the requested telltale is shown 29 | * [ID_1088404633] [SW] [ASIL B] If the requested telltale is not shown, the Safety-signal-source shall request "Safe state" from the safety app. 30 | * [ID_382560048] [SW] [QM[B]] The safety-signal source shall cyclically send the safety status message to the safety app 31 | * [ID_70275415] [SW] [ASIL B] Communication from the Safety signal source to the Safety App shall be E2E protected 32 | * [ID_1259502493] [Information] We don't specify this in all detail here, Message counter and CRC is needed 33 | * [ID_1639133793] [SW] [ASIL B] The results of the Safety signal source workload shall deterministically depend on the inputs 34 | * [ID_220738134] [Information] This implies freedom from spatial interference between the safety-signal-source / safety app and the rest of the (Operating) system, if taken at face value. The formulation is deliberate, the Architecture Workgroup is analysing all potential ways such interference could happen, we then revisit this requirement to refine it regarding safety mechanisms on the application level handling the determined interference scenarios, where possible to avoid putting undue burden on the kernel. 35 | * [ID_1937203672] [Information] Hardware faults are out of scope, see assumptions 36 | * [ID_991487171] [Information] Temporal interference is not relevant here, since the watchdog transitions the system into the safe state, if execution takes too long. 37 | * [ID_1791854442] [TSR] [ASIL B] If the requested telltale is not displayed, the instrument cluster shall transition the system to the safe state by not triggering the external watchdog 38 | * [ID_538932640] [Information] Safety App portion of the Control Flow 39 | * [ID_563434302] [SW] [ASIL B] The Safety App shall check the Communication from Safety Signal Source for E2E misses 40 | * [ID_1726916053] [SW] [ASIL B] The Safety App shall pet the external watchdog, if and only if the cyclic message from the safety signal source passes the E2E check and does not request "safe state" 41 | * [ID_971824356] [SW] [ASIL B] The results of the Safety-app workload shall deterministically depend on the inputs 42 | * [ID_1459030927] [Information] This implies freedom from spatial interference between the safety-signal-source / safety app and the rest of the (Operating) system, if taken at face value. The formulation is deliberate, the Architecture Workgroup is analysing all potential ways such interference could happen, we then revisit this requirement to refine it regarding safety mechanisms on the application level handling the determined interference scenarios, where possible to avoid putting undue burden on the kernel. 43 | * [ID_722885474] [Information] Hardware faults are out of scope, see assumptions 44 | * [ID_560329904] [Information] Temporal interference is not relevant here, since the watchdog transitions the system into the safe state, if execution takes too long. 45 | * [ID_998490846] [TSR] [ASIL B] If the watchdog is not triggered within 200ms, it shall transition the system to the safet state 46 | * [ID_1409122909] [Information] Watchdog part of the control flow 47 | * [ID_1337523371] [Information] Timing allocation considerations: 48 | The timings for rendering and telltale verification are not safety relevant, since the watchdog transitions to the system to the safe state, if the chain takes too long. 49 | * [ID_865269483] [Information] Signal sending including rendering by QT app: 100ms. We assume the time delay between the requester sending the message, and the cluster demo receiving it is less than 30ms, leaving 70ms for the rendering 50 | * [ID_1226012594] [Information] Display check inklusive WD trigger: 50ms 51 | * [ID_322365118] [Information] Watchdog logic inclusive backlight killing: 50ms 52 | * [ID_1266688002] [SW] [ASIL B] The watchdog shall disable the backlight of the Cluster Display within 50ms, if it is not triggered within 150ms. 53 | * [ID_922972509] [FSR] [ASIL B] The chain between Telltale request sent and display/safe state shall be less than 200ms. 54 | * [ID_1197920546] [Information] Timing allocation considerations: 55 | The timings for rendering and telltale verification are not safety relevant, since the watchdog transitions to the system to the safe state, if the chain takes too long. 56 | * [ID_1916288361] [Information] Signal sending including rendering by QT app: 100ms. We assume the time delay between the requester sending the message, and the cluster demo receiving it is less than 30ms, leaving 70ms for the rendering 57 | * [ID_980166321] [Information] Display check inklusive WD trigger: 50ms 58 | * [ID_450743490] [Information] Watchdog logic inclusive backlight killing: 50ms 59 | * [ID_190273872] [TSR] [ASIL B] The Telltale request message shall be sent every 200 ms 60 | * [ID_571758931] [TSR] [QM[B]] The Instrument Cluster shall render the cluster display image within 70ms of the instrument Cluster receiving the message 61 | * [ID_207710874] [SW] [QM[B]] The QT app shall render the image within 70ms of the cluster controller receiving the message 62 | * [ID_1787478473] [TSR] [QM[B]] Verification of telltale shown shall be performed within 50ms 63 | * [ID_1679094583] [TSR] [ASIL B] If the watchdog is not triggered within 200ms, it shall transition the system to the safet state 64 | * [ID_866134195] [Information] Watchdog part of the control flow 65 | * [ID_329269881] [Information] Timing allocation considerations: 66 | The timings for rendering and telltale verification are not safety relevant, since the watchdog transitions to the system to the safe state, if the chain takes too long. 67 | * [ID_678436710] [Information] Signal sending including rendering by QT app: 100ms. We assume the time delay between the requester sending the message, and the cluster demo receiving it is less than 30ms, leaving 70ms for the rendering 68 | * [ID_589807630] [Information] Display check inklusive WD trigger: 50ms 69 | * [ID_27256903] [Information] Watchdog logic inclusive backlight killing: 50ms 70 | * [ID_91008504] [SW] [ASIL B] The watchdog shall disable the backlight of the Cluster Display within 50ms, if it is not triggered within 150ms. 71 |

72 | 73 | ## Safety goal: The system shall transition to the safe state within 100ms of the display showing an unrequested telltale for longer than 100 ms 74 |
Unfold Safety Goal

75 | 76 | * [ID_575915779] [Information] We need to discuss this, this might not work with the frequency of 200ms we have in SZ1, it will if we relax it a little bit to around 120ms, see 77 | * [ID_1024133711] [FSR] [ASIL B] The Telltale requester shall send a request cyclically controlling whether a telltale is needed to be shown or not. 78 | * [ID_793329888] [TSR] [ASIL B] The Telltale requester shall send the telltale request message every 200 ms 79 | * [ID_1442215130] [TSR] [ASIL B] The Telltale request message shall contain a boolean "telltale_request" = 0 if the telltale is not requested and 1 if the telltale is requested 80 | * [ID_9487660] [TSR] [ASIL B] The Telltale request message shall be E2E protected with E2E Protocol xxx 81 | * [ID_83965615] [Information] We don't specify this in all detail here, Message counter and CRC is needed 82 | * [ID_1726434528] [FSR] [ASIL B] All inputs from outside the system, the cluster controller uses to determine whether a requested telltale is shown shall be E2E protected against data corruption out of order transmission and message loss 83 | * [ID_691030811] [TSR] [ASIL B] The Cluster controller shall monitor messages from the Telltale requester 84 | * [ID_1451767216] [TSR] [ASIL B] The Cluster controller shall check the telltale request message for E2E miss 85 | * [ID_324867201] [Information] We don't specify this in all detail here, Message counter and CRC is needed 86 | * [ID_29229427] [TSR] [ASIL B] If the cluster controller determines an E2E miss in the tell tale request message, the cluster controller shall transition the system into the safe state 87 | * [ID_1988413123] [TSR] [ASIL B] The Cluster controler shall check all additional inputs from outside the system, the Cluster controller needs to decide whether a requested telltale is displayed for E2E miss 88 | * [ID_571517104] [SW] [ASIL B] The Safety-Signal-Source shall check the additional inputs for E2E misses 89 | * [ID_224260376] [Information] This refers not only to the telltale request messages from the telltale requester, but also all further inputs the safety-signal source needs to decide whether the requested telltale is displayed or not, e.g. input from a HW checker element, or Image data flowing back from the display 90 | * [ID_1568256292] [TSR] [ASIL B] If the cluster controller determines an E2E miss in an additional input needed for telltale verification, the cluster controller shall transition the system into the safe state 91 | * [ID_1562874415] [SW] [ASIL B] On E2E miss of any input to Safety-signal-source, Safety-signal-source shall request "Safe state" from the safety-app 92 | * [ID_1967724661] [FSR] [ASIL B] The instrument cluster shall transition to the safe state within 50ms, if an unrequested telltale is displayed for more than 100 ms 93 | * [ID_464783880] [Information] We implement this by splitting into a QM path rendering the Display and a Safety path checking whether the requested telltale is shown or not 94 | * [ID_1234093641] [TSR] [QM[B]] The Instrument Cluster shall render the cluster display image within 70ms of the instrument Cluster receiving the message 95 | * [ID_1721681830] [SW] [QM[B]] The QT app shall render the image within 70ms of the cluster controller receiving the message 96 | * [ID_142142357] [TSR] [ASIL B] All Inputs the Cluster controller needs to decide whether a un requested telltale is displayed shall be E2E protected 97 | * [ID_1824391227] [TSR] [ASIL B] The Instrument Cluster shall determine, if a not requested telltale is displayed for more than 100ms 98 | * [ID_1623141656] [TSR] [ASIL B] If a unrequested telltale is shown for more than 100ms the instrument cluster shall transition the system to the safe state by not triggering the external watchdog 99 | * [ID_1771819379] [FSR] [ASIL B] The chain between Telltale request sent and display/safe state shall be less than 200ms. 100 | * [ID_1372264395] [Information] Timing allocation considerations: 101 | The timings for rendering and telltale verification are not safety relevant, since the watchdog transitions to the system to the safe state, if the chain takes too long. 102 | * [ID_851857056] [Information] Signal sending including rendering by QT app: 100ms. We assume the time delay between the requester sending the message, and the cluster demo receiving it is less than 30ms, leaving 70ms for the rendering 103 | * [ID_60352073] [Information] Display check inklusive WD trigger: 50ms 104 | * [ID_1148423018] [Information] Watchdog logic inclusive backlight killing: 50ms 105 | * [ID_1374235407] [TSR] [ASIL B] The Telltale request message shall be sent every 200 ms 106 | * [ID_66701131] [TSR] [QM[B]] The Instrument Cluster shall render the cluster display image within 70ms of the instrument Cluster receiving the message 107 | * [ID_139490740] [SW] [QM[B]] The QT app shall render the image within 70ms of the cluster controller receiving the message 108 | * [ID_1797976261] [TSR] [QM[B]] Verification of telltale shown shall be performed within 50ms 109 | * [ID_666005204] [TSR] [ASIL B] If the watchdog is not triggered within 200ms, it shall transition the system to the safet state 110 | * [ID_1120681616] [Information] Watchdog part of the control flow 111 | * [ID_150284297] [Information] Timing allocation considerations: 112 | The timings for rendering and telltale verification are not safety relevant, since the watchdog transitions to the system to the safe state, if the chain takes too long. 113 | * [ID_149104298] [Information] Signal sending including rendering by QT app: 100ms. We assume the time delay between the requester sending the message, and the cluster demo receiving it is less than 30ms, leaving 70ms for the rendering 114 | * [ID_530521654] [Information] Display check inklusive WD trigger: 50ms 115 | * [ID_1019504250] [Information] Watchdog logic inclusive backlight killing: 50ms 116 | * [ID_10230674] [SW] [ASIL B] The watchdog shall disable the backlight of the Cluster Display within 50ms, if it is not triggered within 150ms. 117 |

118 | -------------------------------------------------------------------------------- /Cluster_Display_Use_Case_v2/Item_Defintion/Papyrus_Model/Cluster_demo/SysML/Allocations/Allocations.SVG: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | «Stereotype» 132 | Allocate 133 | 134 | 135 | 136 | 137 | + getAllocatedFrom( in ref: NamedElement, in result: NamedElement) 138 | 139 | 140 | + getAllocatedTo( in ref: NamedElement, in result: NamedElement) 141 | 142 | 143 | 144 | 145 | «Stereotype» 146 | AllocateActivityPartition 147 | 148 | 149 | 150 | 151 | «Metaclass» 152 | ActivityPartition 153 | 154 | 155 | «Metaclass» 156 | Abstraction 157 | 158 | 159 | «Stereotype» 160 | DirectedRelationshipPropertyPath 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | Allocate is a dependency based on UML::abstraction. It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level. Allocate is used for assessing user model consistency and directing future design activity. It is expected that an «allocate» relationship between model elements is a precursor to a more concrete relationship between the elements, their properties, operations, attributes, or sub-classes. 179 | 180 | 181 | 182 | 183 | 184 | AllocateActivityPartition is used to depict an «allocate» relationship on an Activity diagram. The AllocateActivityPartition is a standard UML2::ActivityPartition, with modified constraints as stated in the paragraph below. 185 | 186 | 187 | An ActivityPartition is a kind of ActivityGroup for identifying ActivityNodes that have some characteristic in common. 188 | 189 | 190 | An Abstraction is a Relationship that relates two Elements or sets of Elements that represent the same concept at different levels of abstraction or from different viewpoints. 191 | 192 | 193 | 194 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Attribution-ShareAlike 4.0 International Creative Commons 2 | Corporation ("Creative Commons") is not a law firm and does not provide legal 3 | services or legal advice. Distribution of Creative Commons public licenses 4 | does not create a lawyer-client or other relationship. Creative Commons makes 5 | its licenses and related information available on an "as-is" basis. Creative 6 | Commons gives no warranties regarding its licenses, any material licensed 7 | under their terms and conditions, or any related information. Creative Commons 8 | disclaims all liability for damages resulting from their use to the fullest 9 | extent possible. 10 | 11 | Using Creative Commons Public Licenses 12 | 13 | Creative Commons public licenses provide a standard set of terms and conditions 14 | that creators and other rights holders may use to share original works of 15 | authorship and other material subject to copyright and certain other rights 16 | specified in the public license below. The following considerations are for 17 | informational purposes only, are not exhaustive, and do not form part of our 18 | licenses. 19 | 20 | Considerations for licensors: Our public licenses are intended for use by 21 | those authorized to give the public permission to use material in ways otherwise 22 | restricted by copyright and certain other rights. Our licenses are irrevocable. 23 | Licensors should read and understand the terms and conditions of the license 24 | they choose before applying it. Licensors should also secure all rights necessary 25 | before applying our licenses so that the public can reuse the material as 26 | expected. Licensors should clearly mark any material not subject to the license. 27 | This includes other CC-licensed material, or material used under an exception 28 | or limitation to copyright. More considerations for licensors : wiki.creativecommons.org/Considerations_for_licensors 29 | 30 | Considerations for the public: By using one of our public licenses, a licensor 31 | grants the public permission to use the licensed material under specified 32 | terms and conditions. If the licensor's permission is not necessary for any 33 | reason–for example, because of any applicable exception or limitation to copyright–then 34 | that use is not regulated by the license. Our licenses grant only permissions 35 | under copyright and certain other rights that a licensor has authority to 36 | grant. Use of the licensed material may still be restricted for other reasons, 37 | including because others have copyright or other rights in the material. A 38 | licensor may make special requests, such as asking that all changes be marked 39 | or described. 40 | 41 | Although not required by our licenses, you are encouraged to respect those 42 | requests where reasonable. More considerations for the public : wiki.creativecommons.org/Considerations_for_licensees 43 | 44 | Creative Commons Attribution-ShareAlike 4.0 International Public License 45 | 46 | By exercising the Licensed Rights (defined below), You accept and agree to 47 | be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 48 | 4.0 International Public License ("Public License"). To the extent this Public 49 | License may be interpreted as a contract, You are granted the Licensed Rights 50 | in consideration of Your acceptance of these terms and conditions, and the 51 | Licensor grants You such rights in consideration of benefits the Licensor 52 | receives from making the Licensed Material available under these terms and 53 | conditions. 54 | 55 | Section 1 – Definitions. 56 | 57 | a. Adapted Material means material subject to Copyright and Similar Rights 58 | that is derived from or based upon the Licensed Material and in which the 59 | Licensed Material is translated, altered, arranged, transformed, or otherwise 60 | modified in a manner requiring permission under the Copyright and Similar 61 | Rights held by the Licensor. For purposes of this Public License, where the 62 | Licensed Material is a musical work, performance, or sound recording, Adapted 63 | Material is always produced where the Licensed Material is synched in timed 64 | relation with a moving image. 65 | 66 | b. Adapter's License means the license You apply to Your Copyright and Similar 67 | Rights in Your contributions to Adapted Material in accordance with the terms 68 | and conditions of this Public License. 69 | 70 | c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, 71 | approved by Creative Commons as essentially the equivalent of this Public 72 | License. 73 | 74 | d. Copyright and Similar Rights means copyright and/or similar rights closely 75 | related to copyright including, without limitation, performance, broadcast, 76 | sound recording, and Sui Generis Database Rights, without regard to how the 77 | rights are labeled or categorized. For purposes of this Public License, the 78 | rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 79 | 80 | e. Effective Technological Measures means those measures that, in the absence 81 | of proper authority, may not be circumvented under laws fulfilling obligations 82 | under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, 83 | and/or similar international agreements. 84 | 85 | f. Exceptions and Limitations means fair use, fair dealing, and/or any other 86 | exception or limitation to Copyright and Similar Rights that applies to Your 87 | use of the Licensed Material. 88 | 89 | g. License Elements means the license attributes listed in the name of a Creative 90 | Commons Public License. The License Elements of this Public License are Attribution 91 | and ShareAlike. 92 | 93 | h. Licensed Material means the artistic or literary work, database, or other 94 | material to which the Licensor applied this Public License. 95 | 96 | i. Licensed Rights means the rights granted to You subject to the terms and 97 | conditions of this Public License, which are limited to all Copyright and 98 | Similar Rights that apply to Your use of the Licensed Material and that the 99 | Licensor has authority to license. 100 | 101 | j. Licensor means the individual(s) or entity(ies) granting rights under this 102 | Public License. 103 | 104 | k. Share means to provide material to the public by any means or process that 105 | requires permission under the Licensed Rights, such as reproduction, public 106 | display, public performance, distribution, dissemination, communication, or 107 | importation, and to make material available to the public including in ways 108 | that members of the public may access the material from a place and at a time 109 | individually chosen by them. 110 | 111 | l. Sui Generis Database Rights means rights other than copyright resulting 112 | from Directive 96/9/EC of the European Parliament and of the Council of 11 113 | March 1996 on the legal protection of databases, as amended and/or succeeded, 114 | as well as other essentially equivalent rights anywhere in the world. 115 | 116 | m. You means the individual or entity exercising the Licensed Rights under 117 | this Public License. Your has a corresponding meaning. 118 | 119 | Section 2 – Scope. 120 | 121 | a. License grant. 122 | 123 | 1. Subject to the terms and conditions of this Public License, the Licensor 124 | hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, 125 | irrevocable license to exercise the Licensed Rights in the Licensed Material 126 | to: 127 | 128 | A. reproduce and Share the Licensed Material, in whole or in part; and 129 | 130 | B. produce, reproduce, and Share Adapted Material. 131 | 132 | 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions 133 | and Limitations apply to Your use, this Public License does not apply, and 134 | You do not need to comply with its terms and conditions. 135 | 136 | 3. Term. The term of this Public License is specified in Section 6(a). 137 | 138 | 4. Media and formats; technical modifications allowed. The Licensor authorizes 139 | You to exercise the Licensed Rights in all media and formats whether now known 140 | or hereafter created, and to make technical modifications necessary to do 141 | so. The Licensor waives and/or agrees not to assert any right or authority 142 | to forbid You from making technical modifications necessary to exercise the 143 | Licensed Rights, including technical modifications necessary to circumvent 144 | Effective Technological Measures. For purposes of this Public License, simply 145 | making modifications authorized by this Section 2(a)(4) never produces Adapted 146 | Material. 147 | 148 | 5. Downstream recipients. 149 | 150 | A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed 151 | Material automatically receives an offer from the Licensor to exercise the 152 | Licensed Rights under the terms and conditions of this Public License. 153 | 154 | B. Additional offer from the Licensor – Adapted Material. Every recipient 155 | of Adapted Material from You automatically receives an offer from the Licensor 156 | to exercise the Licensed Rights in the Adapted Material under the conditions 157 | of the Adapter's License You apply. 158 | 159 | C. No downstream restrictions. You may not offer or impose any additional 160 | or different terms or conditions on, or apply any Effective Technological 161 | Measures to, the Licensed Material if doing so restricts exercise of the Licensed 162 | Rights by any recipient of the Licensed Material. 163 | 164 | 6. No endorsement. Nothing in this Public License constitutes or may be construed 165 | as permission to assert or imply that You are, or that Your use of the Licensed 166 | Material is, connected with, or sponsored, endorsed, or granted official status 167 | by, the Licensor or others designated to receive attribution as provided in 168 | Section 3(a)(1)(A)(i). 169 | 170 | b. Other rights. 171 | 172 | 1. Moral rights, such as the right of integrity, are not licensed under this 173 | Public License, nor are publicity, privacy, and/or other similar personality 174 | rights; however, to the extent possible, the Licensor waives and/or agrees 175 | not to assert any such rights held by the Licensor to the limited extent necessary 176 | to allow You to exercise the Licensed Rights, but not otherwise. 177 | 178 | 2. Patent and trademark rights are not licensed under this Public License. 179 | 180 | 3. To the extent possible, the Licensor waives any right to collect royalties 181 | from You for the exercise of the Licensed Rights, whether directly or through 182 | a collecting society under any voluntary or waivable statutory or compulsory 183 | licensing scheme. In all other cases the Licensor expressly reserves any right 184 | to collect such royalties. 185 | 186 | Section 3 – License Conditions. 187 | 188 | Your exercise of the Licensed Rights is expressly made subject to the following 189 | conditions. 190 | 191 | a. Attribution. 192 | 193 | 1. If You Share the Licensed Material (including in modified form), You must: 194 | 195 | A. retain the following if it is supplied by the Licensor with the Licensed 196 | Material: 197 | 198 | i. identification of the creator(s) of the Licensed Material and any others 199 | designated to receive attribution, in any reasonable manner requested by the 200 | Licensor (including by pseudonym if designated); 201 | 202 | ii. a copyright notice; 203 | 204 | iii. a notice that refers to this Public License; 205 | 206 | iv. a notice that refers to the disclaimer of warranties; 207 | 208 | v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 209 | 210 | B. indicate if You modified the Licensed Material and retain an indication 211 | of any previous modifications; and 212 | 213 | C. indicate the Licensed Material is licensed under this Public License, and 214 | include the text of, or the URI or hyperlink to, this Public License. 215 | 216 | 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner 217 | based on the medium, means, and context in which You Share the Licensed Material. 218 | For example, it may be reasonable to satisfy the conditions by providing a 219 | URI or hyperlink to a resource that includes the required information. 220 | 221 | 3. If requested by the Licensor, You must remove any of the information required 222 | by Section 3(a)(1)(A) to the extent reasonably practicable. 223 | 224 | b. ShareAlike.In addition to the conditions in Section 3(a), if You Share 225 | Adapted Material You produce, the following conditions also apply. 226 | 227 | 1. The Adapter's License You apply must be a Creative Commons license with 228 | the same License Elements, this version or later, or a BY-SA Compatible License. 229 | 230 | 2. You must include the text of, or the URI or hyperlink to, the Adapter's 231 | License You apply. You may satisfy this condition in any reasonable manner 232 | based on the medium, means, and context in which You Share Adapted Material. 233 | 234 | 3. You may not offer or impose any additional or different terms or conditions 235 | on, or apply any Effective Technological Measures to, Adapted Material that 236 | restrict exercise of the rights granted under the Adapter's License You apply. 237 | 238 | Section 4 – Sui Generis Database Rights. 239 | 240 | Where the Licensed Rights include Sui Generis Database Rights that apply to 241 | Your use of the Licensed Material: 242 | 243 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, 244 | reuse, reproduce, and Share all or a substantial portion of the contents of 245 | the database; 246 | 247 | b. if You include all or a substantial portion of the database contents in 248 | a database in which You have Sui Generis Database Rights, then the database 249 | in which You have Sui Generis Database Rights (but not its individual contents) 250 | is Adapted Material, including for purposes of Section 3(b); and 251 | 252 | c. You must comply with the conditions in Section 3(a) if You Share all or 253 | a substantial portion of the contents of the database. 254 | 255 | For the avoidance of doubt, this Section 4 supplements and does not replace 256 | Your obligations under this Public License where the Licensed Rights include 257 | other Copyright and Similar Rights. 258 | 259 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 260 | 261 | a. Unless otherwise separately undertaken by the Licensor, to the extent possible, 262 | the Licensor offers the Licensed Material as-is and as-available, and makes 263 | no representations or warranties of any kind concerning the Licensed Material, 264 | whether express, implied, statutory, or other. This includes, without limitation, 265 | warranties of title, merchantability, fitness for a particular purpose, non-infringement, 266 | absence of latent or other defects, accuracy, or the presence or absence of 267 | errors, whether or not known or discoverable. Where disclaimers of warranties 268 | are not allowed in full or in part, this disclaimer may not apply to You. 269 | 270 | b. To the extent possible, in no event will the Licensor be liable to You 271 | on any legal theory (including, without limitation, negligence) or otherwise 272 | for any direct, special, indirect, incidental, consequential, punitive, exemplary, 273 | or other losses, costs, expenses, or damages arising out of this Public License 274 | or use of the Licensed Material, even if the Licensor has been advised of 275 | the possibility of such losses, costs, expenses, or damages. Where a limitation 276 | of liability is not allowed in full or in part, this limitation may not apply 277 | to You. 278 | 279 | c. The disclaimer of warranties and limitation of liability provided above 280 | shall be interpreted in a manner that, to the extent possible, most closely 281 | approximates an absolute disclaimer and waiver of all liability. 282 | 283 | Section 6 – Term and Termination. 284 | 285 | a. This Public License applies for the term of the Copyright and Similar Rights 286 | licensed here. However, if You fail to comply with this Public License, then 287 | Your rights under this Public License terminate automatically. 288 | 289 | b. Where Your right to use the Licensed Material has terminated under Section 290 | 6(a), it reinstates: 291 | 292 | 1. automatically as of the date the violation is cured, provided it is cured 293 | within 30 days of Your discovery of the violation; or 294 | 295 | 2. upon express reinstatement by the Licensor. 296 | 297 | c. For the avoidance of doubt, this Section 6(b) does not affect any right 298 | the Licensor may have to seek remedies for Your violations of this Public 299 | License. 300 | 301 | d. For the avoidance of doubt, the Licensor may also offer the Licensed Material 302 | under separate terms or conditions or stop distributing the Licensed Material 303 | at any time; however, doing so will not terminate this Public License. 304 | 305 | e. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 306 | 307 | Section 7 – Other Terms and Conditions. 308 | 309 | a. The Licensor shall not be bound by any additional or different terms or 310 | conditions communicated by You unless expressly agreed. 311 | 312 | b. Any arrangements, understandings, or agreements regarding the Licensed 313 | Material not stated herein are separate from and independent of the terms 314 | and conditions of this Public License. 315 | 316 | Section 8 – Interpretation. 317 | 318 | a. For the avoidance of doubt, this Public License does not, and shall not 319 | be interpreted to, reduce, limit, restrict, or impose conditions on any use 320 | of the Licensed Material that could lawfully be made without permission under 321 | this Public License. 322 | 323 | b. To the extent possible, if any provision of this Public License is deemed 324 | unenforceable, it shall be automatically reformed to the minimum extent necessary 325 | to make it enforceable. If the provision cannot be reformed, it shall be severed 326 | from this Public License without affecting the enforceability of the remaining 327 | terms and conditions. 328 | 329 | c. No term or condition of this Public License will be waived and no failure 330 | to comply consented to unless expressly agreed to by the Licensor. 331 | 332 | d. Nothing in this Public License constitutes or may be interpreted as a limitation 333 | upon, or waiver of, any privileges and immunities that apply to the Licensor 334 | or You, including from the legal processes of any jurisdiction or authority. 335 | 336 | Creative Commons is not a party to its public licenses. Notwithstanding, Creative 337 | Commons may elect to apply one of its public licenses to material it publishes 338 | and in those instances will be considered the "Licensor." The text of the 339 | Creative Commons public licenses is dedicated to the public domain under the 340 | CC0 Public Domain Dedication. Except for the limited purpose of indicating 341 | that material is shared under a Creative Commons public license or as otherwise 342 | permitted by the Creative Commons policies published at creativecommons.org/policies, 343 | Creative Commons does not authorize the use of the trademark "Creative Commons" 344 | or any other trademark or logo of Creative Commons without its prior written 345 | consent including, without limitation, in connection with any unauthorized 346 | modifications to any of its public licenses or any other arrangements, understandings, 347 | or agreements concerning use of licensed material. For the avoidance of doubt, 348 | this paragraph does not form part of the public licenses. 349 | 350 | Creative Commons may be contacted at creativecommons.org. 351 | --------------------------------------------------------------------------------