diff --git a/Autosar_Requirements/Autosar_requirements.mm b/Autosar_Requirements/Autosar_requirements.mm new file mode 100644 index 0000000..72c1f45 --- /dev/null +++ b/Autosar_Requirements/Autosar_requirements.mm @@ -0,0 +1,2221 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ [RS_Main_00010] +

+ + + + + + + + + +

+ AUTOSAR shall ensure correct computation, execution and execution order of +

+

+ multiple applications with mixed criticality. +

+ + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall provide safe initialization of hardware +

+

+ and software components +

+ + + + + + + + + +

+  Execution Management shall inherit at least the highest safety integrity level +

+

+ from any process that is running on the platform. +

+ + + + + + + + + + +

+ State Management shall inherit at least the highest safety integrity level from +

+

+ any Process that is managed by it. +

+ + + + + + + + + +

+ In case of software update/install of a safety relevant software, Update and +

+

+ Configuration Management shall verify the update/installation by checking the +

+

+ integrity of the updated or newly installed software. +

+ + + + + + + + + + + +

+  The AUTOSAR Adaptive Platform shall provide safe shutdown and termination +

+

+ of application and services. +

+ + + + + + + + + +

+  Platform Health Management shall ensure that the State Management is +

+

+ functioning, and triggers a watchdog reset in case it fails. +

+ + + + + + + + + + +

+ Platform Health Management shall ensure that the Execution Management is +

+

+ functioning, and triggers a watchdog reset in case it fails. +

+ + + + + + + + + + +

+  Platform Health Management shall monitor the control +

+

+ flow of safety relevant applications and services. ⌈ +

+ + + + + + + + + + + + + +

+ Platform Health Management shall notify State Management in case an +

+

+ AUTOSAR Adaptive Platform functional cluster, application or service other +

+

+ than Execution Management and State Management fails. +

+ + + + + + + + + + +

+ Execution Management shall support fully deterministic execution (time +

+

+ determinism and data determinism) so that higher ASIL levels can be achieved +

+

+ even when using parallel processing. +

+ + + + + + + + + + + + + +

+ State Management shall coordinate recovery actions. +

+ + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall provide safe resource management for +

+

+ the AUTOSAR Adaptive Platform functional-clusters, applications and services. +

+ + + + + + + + + +

+ The OS shall support a mechanism that prevents starvation of applications or +

+

+ processes on the basis of CPU usage (under the respect of available +

+

+ resources). +

+ + + + + + + + + + + + + + +

+ The Operating System shall provide mechanisms to configure resource +

+

+ budgeting in terms of CPU time for each process or group of processes. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [SWS_OSI_02002] + + + + + + + + + + + + + + + + + + cpu.cfs_period_us + + + + + + + + + + + + + cpu.cfs_quota_us + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+  The OS shall support resource reservation for memory in the interval +

+

+ [min,max]. If max is not specified it shall be considered as unlimited. +

+ + + + + + + + + + + [RS_OSI_00201] + + + + + + + + + + +

+ The Operating System shall provide mechanisms to configure memory +

+

+ budgeting for each process or for groups of processes +

+ + + + + + + + + + + + + + + + + + + + [SWS_OSI_02001] + + + + + + + + + + + + + + + + + + + + + + memory.memsw.limit_in_bytes memory.limit_in_bytes + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Operating System shall ensure that only allowed memory accesses are made. +

+ + + + + + + + + + + [RS_OSI_00206] + + + + + + + + + + +

+ The Operating System shall provide mechanisms to let multiple processes +

+

+ run isolated from each other. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+  The AUTOSAR Adaptive Platform shall provide dependable scheduling of +

+

+ AUTOSAR Adaptive Platform functional-clusters, applications and services. +

+ + + + + + + + + + + + + + + + + +

+  The AUTOSAR Adaptive Platform shall provide safe program execution. +

+ + + + + + + + + +

+ Platform Health Management shall inherit at least the highest safety integrity +

+

+ level from any Process that is running on the platform. +

+ + + + + + + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall detect the program execution time +

+

+ violation. +

+ + + + + + + + + + +

+ Platform Health Management shall monitor the execution frequency of safety +

+

+ relevant applications and services. +

+ + + + + + + + + +

+ Platform Health Management shall monitor that the duration between the +

+

+ checkpoints of safety relevant applications and services are within the minimum +

+

+ and maximum configured time limits. +

+ + + + + + + + + + + + + + + + + + + + + How is the OS flag to be understood? We understood it as requirements that do require something from the OS to be fulfilled, but if that interpretation is correct, then some requirements miss the flag, i.e. [RS_SAF_10037]  + + + + + + + + + + + + + + + + + +  [RS_SAF_10030] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ AUTOSAR shall ensure correct configuration during the entire life cycle of the +

+

+ platform. +

+ + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall provide safe verification mechanisms of +

+

+ platform functional-clusters, applications, services and their respective +

+

+ configuration data. +

+ + + + + + + + + + + + + + + + + + + + + + + +

+ AUTOSAR Adaptive Platform should provide mechanisms to switch back to the +

+

+ latest working configuration +

+ + + + + + + + +

+ Update and Configuration Management shall verify the integrity of the new +

+

+ configuration and ensure that a well known configuration can be used in case +

+

+ the verification fails. +

+ + + + + + + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall prevent unintended alteration of data. +

+ + + + + + + + + +

+ Persistency shall add integrity information to the persistent data if such a +

+

+ mechanism does not already exist in the operating system +

+ + + + + + + + + + +

+ Persistency shall check the integrity of persistent data when reading it if this is +

+

+ not already done by the operating system. +

+ + + + + + + + + + +

+ Communication Management shall provide mechanisms for detection of errors +

+

+ during the exchange of information among software components, by +

+

+ considering all faults listed in the ISO standard (ISO 26262:6-2018 D.2.4). +

+ + + + + + + + + + +

+ Communication Management shall, based on individual safety concepts, allow +

+

+ integrators to select and configure the set of safety mechanisms to detect +

+

+ communication faults. +

+ + + + + + + + + + + + + + + + + + +

+ AUTOSAR shall ensure correct update and upgrade of multiple platform and +

+

+ non-platform applications with mixed criticality. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall ensure that the safety relevant software +

+

+ is updated/upgraded in a state that cannot cause a hazardous situation +

+ + + + + + + + +

+ Update and Configuration Management (UCM) shall orchestrate the recovery +

+

+ to a safe operating mode in case of failed update process of a safety relevant +

+

+ software. +

+ + + + + + + + + +

+ If the verification of the update/installation of a safety relevant software fails, +

+

+ Update and Configuration Management shall ensure that a transition from +

+

+ non-hazardous state to a potentially hazardous state is not made unless the +

+

+ safety feature is available +

+ + + + + + + + + + + +

+ AUTOSAR shall ensure correct exchange (transmission and reception) of +

+

+ information. +

+ + + + + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall provide an interface for an application +

+

+ or service to allow safe communication. +

+ + + + + + + + + + + + + + + + + + + + + +

+ AUTOSAR shall detect faults and failures while processing data, +

+

+ communicating with other systems or system elements. +

+ + + + + + + + + + + + + + +

+ [RS_Main_00011] +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Full time and data determinism is needed on system level, but not necessarily on OS level. We should discuss to what exactly the OS needs to provide to make fulfillment of these requirements possible + + + + + + + + + + + + +

+ Additional Excerpt from AUTOSAR_EXP_PlatformDesign.pdf: +

+ + + + + + + + + + + + + + + + This looks very much like static RT µc thinking, time slices and sufficient ressources to finish the task in time. With a preemtive OS like Linux this can not be guaranteed by design of the OS We should debate adapting the requirements to better fit a preemptive OS, Execution management in tandem with external watchdogs could ensure a temporal upper bound or drive a safe state. Just because one can construct a corner case that delays execution on a a Linux based system indefinitely, does not mean it happens a lot. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ [RS_Main_00012] +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ [RS_Main_00030] +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ [RS_Main_00150] +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ The AUTOSAR Adaptive Platform shall provide safe transition of states in an +

+

+ application/service life cycle. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ AUTOSAR_SWS_OperatingSystemInterface.pdf +

+ + + + + + + + + + + + +

+ AUTOSAR_RS_OperatingSystemInterface.pdf +

+ + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Autosar_Requirements/Autosar_requirements_files/png_103443134580751252.png b/Autosar_Requirements/Autosar_requirements_files/png_103443134580751252.png new file mode 100644 index 0000000..603ad23 Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_103443134580751252.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_1422049677413748365.png b/Autosar_Requirements/Autosar_requirements_files/png_1422049677413748365.png new file mode 100644 index 0000000..ed2a477 Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_1422049677413748365.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_1583795526270649214.png b/Autosar_Requirements/Autosar_requirements_files/png_1583795526270649214.png new file mode 100644 index 0000000..e69c9bc Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_1583795526270649214.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_2134582951924925129.png b/Autosar_Requirements/Autosar_requirements_files/png_2134582951924925129.png new file mode 100644 index 0000000..51ea8c0 Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_2134582951924925129.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_458992244045570839.png b/Autosar_Requirements/Autosar_requirements_files/png_458992244045570839.png new file mode 100644 index 0000000..ee5dc6a Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_458992244045570839.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_4615176338401799785.png b/Autosar_Requirements/Autosar_requirements_files/png_4615176338401799785.png new file mode 100644 index 0000000..579b9b6 Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_4615176338401799785.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_7281299709021076975.png b/Autosar_Requirements/Autosar_requirements_files/png_7281299709021076975.png new file mode 100644 index 0000000..61f6cb0 Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_7281299709021076975.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_771748757874593714.png b/Autosar_Requirements/Autosar_requirements_files/png_771748757874593714.png new file mode 100644 index 0000000..b115cba Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_771748757874593714.png differ diff --git a/Autosar_Requirements/Autosar_requirements_files/png_9010377296742589771.png b/Autosar_Requirements/Autosar_requirements_files/png_9010377296742589771.png new file mode 100644 index 0000000..cca058f Binary files /dev/null and b/Autosar_Requirements/Autosar_requirements_files/png_9010377296742589771.png differ diff --git a/Autosar_Requirements/Notes.md b/Autosar_Requirements/Notes.md new file mode 100644 index 0000000..75bc84e --- /dev/null +++ b/Autosar_Requirements/Notes.md @@ -0,0 +1,52 @@ +# Autosar Requirements to OS - Analysis and Feedback +The Automotive WG considers Requirements the Autosar consortion poses on the underlying Operating system. +## Findings +The following points came up so far: +### General question regarding the OS flag +How is the OS flag to be understood? We understood it as requirements that do require something from the OS to be fulfilled, but if that interpretation is correct, then some requirements miss the flag, i.e. [RS_SAF_10037] +Followup question, some requirements with the OS flag do not have any children that carry the flag as well, i.e. [RS_SAF_10030] or [RS_SAF_10005], [RS_SAF_10002] +### AUTOSAR_RS_Safety.pdf +#### RS_SAF_00001, RS_SAF_21202 +Full time and data determinism is needed on system level, but not necessarily on OS level. We should discuss to what exactly the OS needs to provide to make fulfillment of these requirements possible. +### [RS_SAF_10028] +The requirements and its children, is the interpretation correct, that fully deterministic execution is ensured by execution management without OS involvement, as long as sufficient computing ressources are availlable? We need to discuss the ressources requirement, this argument is not that easy for a preemptive OS +#### [RS_SAF_21202] + Execution Management shall support fully deterministic + execution (time determinism and data determinism) so that higher ASIL levels + can be achieved even when using parallel processing. + +Additional Excerpt from AUTOSAR_EXP_PlatformDesign.pdf: + + Deterministic execution provides a mechanism such that a calculation using a given + input data set always produces a consistent output within a bounded time. Execution Management distinguishes between time and data determinism. The former states that the output is always produced by the deadline whereas the latter refers to generating the same output from the same input data set and internal state. + The support provided by Execution Management focuses on data determinism as it assumes time determinism has handled by the provision of sufficient resources. + +This looks very much like static RT µc thinking, time slices and sufficient ressources to finish the task in time. +With a preemtive OS like Linux this can not be guaranteed by design of the OS +We should debate adapting the requirements to better fit a preemptive OS, Execution management in tandem with external watchdogs could ensure a temporal upper bound or drive a safe state. +Just because one can construct a corner case that delays execution on a a Linux based system indefinitely, does not mean it happens a lot. + +#### [RS_SAF_10037] + The requirement should be flagged as OS related, see children requirements referring to OS measures + When taken out of context of it's parent requirement, the requirement looks more encompassing than it actually is. + +### AUTOSAR_RS_OperatingSystemInterface.pdf +No issues found, Requirements described in the document can in principle be fulfilled by a Linux kernel +### Autosar_SWS_Operating_Interface.pdf +#### SWS_OSI_02000 +Where does the number of ressource groups (8) come from? +### [SWS_OSI_01014] +Multi-Process Creation Capability Restriction : seccomp functionality can do the job +### [SWS_OSI_02001] Memory ResourceGroups +we can use cgroups or setrlimit, example cgroups: +``` + memory.memsw.limit_in_bytes + memory.limit_in_bytes +``` +#### [SWS_OSI_02002] CPU ResourceGroups +Can be done using cgroups : +``` + cpu.cfs_period_us + cpu.cfs_quota_us +``` + diff --git a/README.md b/README.md index 2d94b0c..c1c199b 100644 --- a/README.md +++ b/README.md @@ -1,43 +1,43 @@ -# ELISA Automotive WG - Navigation and file locations -## Mailing list, Calendar etc -https://lists.elisa.tech/g/automotive -## Meeting Minutes -https://docs.google.com/document/d/1qgEkB6HBjq0ojoTSmI_E18BZco3lORK1ZZDrBH1YQo0/edit#heading=h.b7qah2h40uzb -## Google drive workgroup folder -https://drive.google.com/drive/folders/1FCEzywCMfk3wY6lxBoMYjfQ_DQ44S5YS -## Repo Orientation regarding the Telltale Usecase -### Original considerations of the Use Case can be found in the folder -Initialy_discussed_system_scope -### The First iteration of the use case that the meta-elisa demo is based on can be found in -AGL_cluster_demo_use_case -* Item definition -* Safety Concept/Requirements -Our Implementation on top of the AGL Cluster demo is split in two repositories: - -The meta layer: (also includes build and running instructions) - -https://github.com/elisa-tech/meta-elisa - -The actual sourcecode repository: - -https://github.com/elisa-tech/wg-automotive-safety-app - -### The second iteration of the use case including Eclipse Papyrus based SysML models can be found in -Cluster_Display_Use_Case_v2 -* Item definition [WIP] -* SysML models [WIP] - -The models are also visible via github page deployment as online viewer at: - -https://elisa-tech.github.io/wg-automotive/ - -The html export might not always be up to date with the models, generation is not automated (yet) -## Tooling -### Requirements -Requirements are stored and handled as Freeplane Mindmap with Functional Safety Addon -* https://www.freeplane.org/wiki/index.php/Home -* https://github.com/Jochen-Kall/Safety_concept_tool -### SysML modeling -SysML models are done with Eclipse Papyrus with SysML v1.6 Plugin -* https://www.eclipse.org/papyrus/ -* https://marketplace.eclipse.org/content/papyrus-sysml-16 +# ELISA Automotive WG - Navigation and file locations +## Mailing list, Calendar etc +https://lists.elisa.tech/g/automotive +## Meeting Minutes +https://docs.google.com/document/d/1qgEkB6HBjq0ojoTSmI_E18BZco3lORK1ZZDrBH1YQo0/edit#heading=h.b7qah2h40uzb +## Google drive workgroup folder +https://drive.google.com/drive/folders/1FCEzywCMfk3wY6lxBoMYjfQ_DQ44S5YS +## Repo Orientation regarding the Telltale Usecase +### Original considerations of the Use Case can be found in the folder +Initialy_discussed_system_scope +### The First iteration of the use case that the meta-elisa demo is based on can be found in +AGL_cluster_demo_use_case +* Item definition +* Safety Concept/Requirements +Our Implementation on top of the AGL Cluster demo is split in two repositories: + +The meta layer: (also includes build and running instructions) + +https://github.com/elisa-tech/meta-elisa + +The actual sourcecode repository: + +https://github.com/elisa-tech/wg-automotive-safety-app + +### The second iteration of the use case including Eclipse Papyrus based SysML models can be found in +Cluster_Display_Use_Case_v2 +* Item definition [WIP] +* SysML models [WIP] + +The models are also visible via github page deployment as online viewer at: + +https://elisa-tech.github.io/wg-automotive/ + +The html export might not always be up to date with the models, generation is not automated (yet) +## Tooling +### Requirements +Requirements are stored and handled as Freeplane Mindmap with Functional Safety Addon +* https://www.freeplane.org/wiki/index.php/Home +* https://github.com/Jochen-Kall/Safety_concept_tool +### SysML modeling +SysML models are done with Eclipse Papyrus with SysML v1.6 Plugin +* https://www.eclipse.org/papyrus/ +* https://marketplace.eclipse.org/content/papyrus-sysml-16