From 242be60b8503a83f64a4ae98a52417dd6bf59cbd Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Tue, 18 Nov 2025 08:01:45 +0100 Subject: [PATCH 1/7] Fixes https://github.com/eclipse-score/process_description/issues/60 - Fixed folder structure - Adapted roles in safety management - Added dedicated workflow for impact analysis of change requests --- .DS_Store | Bin 0 -> 6148 bytes .../process_areas/safety_management/index.rst | 107 +----------------- .../process_areas/safety_management/roles.rst | 82 -------------- .../safety_management_concept.rst | 91 +++++++++++++++ .../safety_management_getstrt.rst | 28 +++++ .../safety_management_roles.rst | 27 +++++ ...ows.rst => safety_management_workflow.rst} | 23 +++- ...rst => safety_management_workproducts.rst} | 4 +- process/roles/index.rst | 20 ++++ 9 files changed, 195 insertions(+), 187 deletions(-) create mode 100644 .DS_Store delete mode 100644 process/process_areas/safety_management/roles.rst create mode 100644 process/process_areas/safety_management/safety_management_concept.rst create mode 100644 process/process_areas/safety_management/safety_management_getstrt.rst create mode 100644 process/process_areas/safety_management/safety_management_roles.rst rename process/process_areas/safety_management/{workflows.rst => safety_management_workflow.rst} (80%) rename process/process_areas/safety_management/{workproducts.rst => safety_management_workproducts.rst} (99%) diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..cbf579b9b41a59a34296108fa2bf86266d5b9020 GIT binary patch literal 6148 zcmeHKI|>3Z5S>vG!N$@uSMUZw^aOhVMFbH^|vYm-cL}Uavl$#A*vwic9^)jMBIL WHL(qJI^s?T@@K$wp;3WfEARkPw-tr} literal 0 HcmV?d00001 diff --git a/process/process_areas/safety_management/index.rst b/process/process_areas/safety_management/index.rst index 0956806ba8..272e6e0cc8 100644 --- a/process/process_areas/safety_management/index.rst +++ b/process/process_areas/safety_management/index.rst @@ -17,107 +17,12 @@ Safety Management ================= -Concept -------- - -.. doc_concept:: Safety Management Concept - :id: doc_concept__safety_management_process - :status: valid - -In this section a concept for the safety management will be discussed. Inputs for this concepts are mainly the requirements of ISO26262 "Part 2: Management of functional safety" - -Inputs -^^^^^^ - -#. Stakeholders for the safety management work products? -#. Who needs which information? -#. Which safety plans do we have? -#. Which other work products of safety management are important? -#. What tooling do we need? - -Stakeholders -^^^^^^^^^^^^ - -#. :need:`Project Lead ` - - * planning of development for module and for platform projects - * status reporting of safety activities - -#. :need:`Safety Manager ` - - * he is the main responsible for the safety management work products (as in :doc:`workproducts`). - See also his role definition in :doc:`roles`. - -#. :need:`External Auditor ` - - * understand activities planning, processes definition and execution - -#. "Distributor" (external role) - - * use the platform in a safe way - * integrate the platform in his product (distribution) and safety case - * plan this integration (also in time) - * qualify the SW platform as part of his product - -Safety Plans -^^^^^^^^^^^^ - -This SW platform project defines two levels of planning: platform and module. There will be one safety plan on platform level and several safety plans on module level (one for each module). -This is how we organize our development teams and repositories. Each of these safety plan "creates" one SEooC. -The :need:`Platform Safety Plan ` exists only once and is part of the :need:`Platform Management Plan `. - -Safety Management Work Products -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Apart from the safety plans the main work products of safety management are (see also the link to workflows below): - -* :need:`Safety Manual ` - the safety manual defines the requirements for safe usage or integration of the SW platform (or its individual modules) -* :need:`Confirmation Reviews ` - on safety plan, safety package and safety analyses, according to ISO 26262 requirements -* :need:`Safety Package ` - the safety package does not contain the safety argumentation. By this the S-CORE project ensures it does not take over liability for the SW platform (or its individual modules). But it enables the distributors to integrate the SW platform (or its individual modules) in their safety package. - -Safety Management Tooling -^^^^^^^^^^^^^^^^^^^^^^^^^ - -For the safety planning and safety manual, sphinx-needs will be used for referencing. - -For the activities planning (who, when) we use github issues and monitor these in github projects. - -For the reporting (e.g. displaying the status of the work products) additional tooling is created (see :doc:`guidance/process_req`) - -Getting started ---------------- - -.. doc_getstrt:: Safety Management Get Started - :id: doc_getstrt__safety_management_process - :status: valid - - -In case you are appointed as a :need:`Safety Manager ` by the :need:`rl__project_lead` in the project: - -* Contact the :need:`Project Lead ` for your SEooC to establish planning and reporting (the TL should already have established a Github project for planning) -* Create your safety plan according to :need:`wf__cr_mt_safety_plan` -* Make familiar with your role description and the other workflows of safety management (see below) -* Make familiar with the development and supporting process descriptions in :ref:`process_description` plus the relevant sections of the :need:`Platform Management Plan ` - -Workflows ---------- - -.. toctree:: - :maxdepth: 1 - :glob: - - roles.rst - workproducts.rst - workflows.rst - -Guidance --------- - .. toctree:: :maxdepth: 1 - :glob: - - guidance/index.rst -.. needextend:: docname is not None and "process_areas/safety_management" in docname - :+tags: safety_mgt + safety_management_getstrt + safety_management_concept + guidance/index + safety_management_roles + safety_management_workflow + safety_management_workproducts diff --git a/process/process_areas/safety_management/roles.rst b/process/process_areas/safety_management/roles.rst deleted file mode 100644 index e8473d073c..0000000000 --- a/process/process_areas/safety_management/roles.rst +++ /dev/null @@ -1,82 +0,0 @@ -.. - # ******************************************************************************* - # Copyright (c) 2025 Contributors to the Eclipse Foundation - # - # See the NOTICE file(s) distributed with this work for additional - # information regarding copyright ownership. - # - # This program and the accompanying materials are made available under the - # terms of the Apache License Version 2.0 which is available at - # https://www.apache.org/licenses/LICENSE-2.0 - # - # SPDX-License-Identifier: Apache-2.0 - # ******************************************************************************* - -Roles ------ - -.. role:: Safety Manager - :id: rl__safety_manager - :status: valid - :contains: rl__committer - - The safety manager is responsible for making sure that ISO26262 is complied to in the project. He/She shall lead and monitor the safety relevant activities of the project. - - Required skills - - * Degree: Master's degree in electrical engineering/computer science/mathematics, or similar degree, or comparable work experience - * Solid understanding of functional safety management - * Knowledge in project management - * Deep understanding of quality criteria and the correlating methods and procedures to achieve and verify them - * Technical know-how of embedded systems - * Preferred training: Automotive Functional Safety Expert (AFSE) or similar - - Knowledge of standards - - * ISO 26262 - - Experience - - * 2 years of experience in the management of safety topics - * Experience in managing projects - * Experience in managing safety anomalies - - Responsibility - - * Creating the Safety Plan - * Functional Safety related project status reporting - * Creation and Monitoring of completeness of the safety case - * Reporting of safety anomalies - * Verify, that the preconditions for the "release for production", which are part of the release notes, are fulfilled, and the correctness, completeness and consistency of the release notes - * Coaching the project team w.r.t all questions related to functional safety - * Planning of safety audit - * Approval of OSS component classification and safety analyses (incl. DFA) - * Creating the safety manuals on platform and module level - * Checking that every person in his team has sufficient safety skills for his role - - Authority - - * Escalation of planning topics to the project manager defined in the safety plan - * Initiate the publication of a safety anomaly - * Recommend the Release of a SW platform or a module - * Refusing the approval of work products as defined in the workflows - * Refusing the approval of his team's role nomination (i.e. requesting that the role will be withdrawn) - - -.. role:: External Auditor - :id: rl__external_auditor - :status: valid - - Required skills, Knowledge of standards, Experience - - * External Auditor comes from organization specialized in safety audits and assessment, thus sufficient skill should be guaranteed by the sending organization. - * For performing the confirmation reviews also a safety manager from another (S-CORE) project can play the role of an external auditor, in this case the same skills apply as for the safety manager. - - Responsibility - - * Performing and reporting of safety audit - * Performing of confirmation reviews on safety plans, safety case and safety analysis (incl. DFA) - - Authority - - * Decision on the passing or failing of an audit diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst new file mode 100644 index 0000000000..1b3ac29ef1 --- /dev/null +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -0,0 +1,91 @@ +.. + # ******************************************************************************* + # Copyright (c) 2025 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Concept +------- + +.. doc_concept:: Safety Management Concept + :id: doc_concept__safety_management_process + :status: valid + +In this section a concept for the safety management will be discussed. +Inputs for this concepts are mainly the requirements of ISO26262 "Part 2: Management of functional safety". + +Key concept +^^^^^^^^^^^ +The Safety Management Plan should define the strategy to manage the identified safety activities +in an effective and repeatable way for the project life cycle. + +Inputs +^^^^^^ + +#. Stakeholders for the safety management work products? +#. Who needs which information? +#. Which safety plans do we have? +#. Which other work products of safety management are important? +#. What tooling do we need? + +Stakeholders +^^^^^^^^^^^^ + +#. :need:`Technical Lead ` + + * planning of development for module and for platform projects + * status reporting of safety activities + +#. :need:`Safety Manager ` + + * main responsible for the safety management work products + * role definition in :doc:`roles` + +#. :need:`External Auditor ` + + * understand activities planning, processes definition and execution + +#. "Distributor" (external role) + + * use the platform in a safe way + * integrate the platform in his product (distribution) and safety case + * plan this integration (also in time) + * qualify the SW platform as part of his product + +Safety Plans +^^^^^^^^^^^^ + +This SW platform project defines two levels of planning: platform and module. There will be one safety plan on platform level and several safety plans on module level (one for each module). +This is how we organize our development teams and repositories. Each of these safety plan "creates" one SEooC. +The Platform Safety Plan exists only once and is part of the Platform Management Plan of S-CORE. + +Safety Management Work Products +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Apart from the safety plans the main work products of safety management are: + +* :need:`Safety Manual ` - the safety manual defines the requirements for safe usage or integration of the SW platform (or its individual modules) +* :need:`Confirmation Reviews ` - on safety plan, safety package and safety analyses, according to ISO 26262 requirements +* :need:`Safety Package ` - the safety package does not contain the safety argumentation. By this the S-CORE project ensures it does not take over liability for the SW platform (or its individual modules). But it enables the distributors to integrate the SW platform (or its individual modules) in their safety package. + +Safety Management Tooling +^^^^^^^^^^^^^^^^^^^^^^^^^ + +For the safety planning and safety manual, `sphinx-needs `_ will be used for referencing. + +For the activities planning (who, when) we use `GitHub issues `_ and monitor these in GitHub projects. + +For the reporting (e.g. displaying the status of the work products) additional tooling is created. + +Guidance +^^^^^^^^ + +The safety management guideline can be found in the guidance section. diff --git a/process/process_areas/safety_management/safety_management_getstrt.rst b/process/process_areas/safety_management/safety_management_getstrt.rst new file mode 100644 index 0000000000..bfd259df56 --- /dev/null +++ b/process/process_areas/safety_management/safety_management_getstrt.rst @@ -0,0 +1,28 @@ +.. + # ******************************************************************************* + # Copyright (c) 2025 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Getting started +--------------- + +.. doc_getstrt:: Safety Management Get Started + :id: doc_getstrt__safety_management_process + :status: valid + + +In case you are appointed as a :need:`Safety Manager ` by the :need:`rl__project_lead` in the S-CORE project: + +* Contact the :need:`Technical Lead ` for your SEooC to establish planning and reporting (the TL should already have established a Github project for planning) +* Create your safety plan according to :need:`wf__cr_mt_safety_plan` +* Make familiar with your role description and the other workflows of safety management (see below) +* Make familiar with the development and supporting process descriptions in :ref:`process_description` plus the relevant sections of the :need:`wp__platform_mgmt` diff --git a/process/process_areas/safety_management/safety_management_roles.rst b/process/process_areas/safety_management/safety_management_roles.rst new file mode 100644 index 0000000000..74b37b04ff --- /dev/null +++ b/process/process_areas/safety_management/safety_management_roles.rst @@ -0,0 +1,27 @@ +.. + # ******************************************************************************* + # Copyright (c) 2025 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Roles +----- + +For safety management no additional roles need to be defined. + +Contributing Roles: + + * :need:`Safety Manager ` + * :need:`External Auditor ` + +A detailed overview of the responsibility for the steps of the requirement process is listed here: + +:ref:`workflow_requirements` diff --git a/process/process_areas/safety_management/workflows.rst b/process/process_areas/safety_management/safety_management_workflow.rst similarity index 80% rename from process/process_areas/safety_management/workflows.rst rename to process/process_areas/safety_management/safety_management_workflow.rst index df7447c0ad..452251ccb4 100644 --- a/process/process_areas/safety_management/workflows.rst +++ b/process/process_areas/safety_management/safety_management_workflow.rst @@ -12,8 +12,8 @@ # SPDX-License-Identifier: Apache-2.0 # ******************************************************************************* -Workflows ---------- +Workflow Safety Management +-------------------------- .. workflow:: Create/Maintain Safety Plan :id: wf__cr_mt_safety_plan @@ -113,3 +113,22 @@ Workflows | The Safety Manager is responsible for the monitoring of the safety activities against the safety plan. | The Safety Manager is responsible to verify, that the preconditions for the release, which are part of the release notes, are fulfilled. | The Safety Manager is responsible to verify the correctness, completeness and consistency of the release notes. + +.. workflow:: Impact Analysis of Change Request + :id: wf__impact_analysis_change_request + :status: valid + :responsible: rl__safety_manager + :approved_by: rl__technical_lead + :input: wp__platform_mgmt, wp__issue_track_system, wp__sw_component_class, wp__tailoring + :output: wp__issue_track_system + :contains: gd_temp__change_component_request, gd_temp__change_decision_record, gd_temp__change_impact_analysis + :has: doc_concept__safety_management_process + + | In accordance with ISO 26262-2:2018 section 5.2.2.3 d/e (Impact Analysis), the project implements a dedicated workflow for analyzing change requests. + | The Safety Manager is responsible for ensuring that each change request is analyzed for its impact on safety, as required by ISO 26262-2:2018. + | Impact analysis is performed at the element level (e.g., module or component) rather than the item (system) level, reflecting the modular architecture of the platform. This tailoring is documented in the safety plan and justified by the project structure and scope. + | The analysis includes: + | - Reviewing the change request and its context + | - Assessing the impact on affected elements, safety requirements, and work products + | - Documenting the rationale for decisions regarding acceptance, implementation, or rejection of the change + | The outcome is a change impact analysis report and a documented decision, which are reviewed and approved as part of the safety management process. diff --git a/process/process_areas/safety_management/workproducts.rst b/process/process_areas/safety_management/safety_management_workproducts.rst similarity index 99% rename from process/process_areas/safety_management/workproducts.rst rename to process/process_areas/safety_management/safety_management_workproducts.rst index 9fa6d9df3c..3c7c6dac95 100644 --- a/process/process_areas/safety_management/workproducts.rst +++ b/process/process_areas/safety_management/safety_management_workproducts.rst @@ -12,8 +12,8 @@ # SPDX-License-Identifier: Apache-2.0 # ******************************************************************************* -Work products -------------- +Workproducts Safety Management +------------------------------ .. workproduct:: Platform Safety Plan :id: wp__platform_safety_plan diff --git a/process/roles/index.rst b/process/roles/index.rst index c1b9e5382c..90914f7f74 100644 --- a/process/roles/index.rst +++ b/process/roles/index.rst @@ -64,6 +64,12 @@ Project Process roles The process community members are responsible for the definition of the process architecture of the project integrated management system and how they processes interact. The approval and release of the process is done by the safety, quality and security managers and the project leads (for the parts which affect them). +.. role:: External Auditor + :id: rl__external_auditor + :status: valid + + External auditing instance confirming the compliance to ISO26262 and the defined processes in S-CORE. The external auditor is not part of the project organization. + Project Development roles ------------------------- @@ -135,6 +141,20 @@ Project Feature teams The module team is responsible for all artifacts within the module SEooCs. Each module has only one responsible team but a team may also be responsible for several (small) modules. +.. role:: Safety Manager + :id: rl__safety_manager + :status: valid + :contains: rl__committer + + The safety manager is responsible for making sure that ISO26262 is complied to in the project. He/She shall lead and monitor the safety relevant activities of the feature development. + The safety manager is assigned and elected by a committee considering the project lead(s) + + Experience + + * 3+ years of proven experience in the management of safety topics + * Experience in managing projects + * Experience in managing safety anomalies + Project Roles list ------------------ From 89066a9beac595b8676dd3e8958cfa600b2d2276 Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Tue, 18 Nov 2025 22:42:15 +0100 Subject: [PATCH 2/7] Changes for https://github.com/eclipse-score/score/issues/1143 - [x] _Deviation_8: There is no role defined, which covers the Software Safety Analysis. The committer is intended to cover the Software Safety Analysis, but this is not part of the role description yet._ > Added workflow:: Perform Component Safety Analysis in safety_management_workflow.rst --- .DS_Store | Bin 6148 -> 8196 bytes .../safety_management_workflow.rst | 15 +++++++++++++++ 2 files changed, 15 insertions(+) diff --git a/.DS_Store b/.DS_Store index cbf579b9b41a59a34296108fa2bf86266d5b9020..918c53298f8a00be6c808bcb348af8ce8d7db910 100644 GIT binary patch literal 8196 zcmeHMTWl0n7(V~Bv}eSD=>;e-z|a*0DYC6aDHpTt7D7QNb_?CMlx22jgpt{qvNOAj zKxK`_Nbr(qGzKqE5^o7lUO;1_L8A|93|5Ts#am2_4<;Hf4`BSyoLOQQ`=Z7`oRggM zpWFYR`Tz5MXZFkzLZBF!!nFO7=iy~1lakYVrDWH$P$C0g)>F zy1&vX%PqwDM~SL**{RP1r>J<<)T^awN^&qcG%Ssz!;^Pu4lX$Sg^10Jh0#Z1nztZj~KGK+&r zZ?d7}kn7~UxNkQl%X!!6GtjJAFuKvWn>2BCX0x%vTM$o9Z&DX6z5a$(>pC}V+S)fR z*VQ*P&XA-bjIHgNx0yz6d(qUry@Q&YF>Kwm_Y4$F*GyYRzpZ7BI%pBa@!50c%E~-t zL3yZBg~}0{%%{!$dDFXNyrHgMmYS7oMEPa9Q^yC~;^=H8-5*h!l_iu8v;KI_z>;@M z%arA!tkHfK{op2|Qky8dV*fq_23K7v-9%+w+-_-U!{S}5rL|PvEDjX-cJR&_QjChp zjFZixlP>RzE9)XItL2Q|BEqt)v4v89f3csbtk+G? z$?<43E4NZQ$c%OBI@*!v%$=R+R}|bH(=M1u0^Cy01^FzcG!naxZ%(AVN0B%6l3(`& zEkCfpADpa>qhdAI<-3!+djGzg8tVqt|46U zBa$jlK^F1mwM(#BgAC%$mgTA{3rJkvY;98|xe96Np8?8^%drVTWAz$IlBb^pCK|yS9pXH)fXDyb_nb3Ksr#9HoC9M|trNL#(SfmFdI+ hS>h6VF#YEr0w(!k{`Y@_kG}u_ delta 130 zcmZp1XfcprU|?W$DortDU=RQ@Ie-{MGqg=C6q~50D9Q+A12Ir6hasgbxF|0tKQDb^ zq55QV@e3Op*03#R=im@z2I&AQ;sz3~K-{*m@H_Klei>a(koE&W%rM!8N1BHTVgblb KhRyLjGnfGbM;7w{ diff --git a/process/process_areas/safety_management/safety_management_workflow.rst b/process/process_areas/safety_management/safety_management_workflow.rst index 452251ccb4..a6b98be489 100644 --- a/process/process_areas/safety_management/safety_management_workflow.rst +++ b/process/process_areas/safety_management/safety_management_workflow.rst @@ -41,6 +41,20 @@ Workflow Safety Management | The Safety Manager shall approve the OSS component classification performed by an expert on this component. + .. workflow:: Perform Component Safety Analysis + :id: wf__perform_comp_safety_analysis + :status: valid + :responsible: rl__committer + :approved_by: rl__safety_manager + :input: wp__sw_component_class + :output: wp__component_safety_analysis + :contains: gd_guidl__component_safety_analysis, gd_temp__component_safety_analysis + :has: doc_concept__safety_management_process, doc_getstrt__safety_management_process + + | The committer is responsible for performing the safety analysis of the component after its classification. + | The safety analysis identifies and documents potential safety risks and mitigations for the component. + | The Safety Manager reviews and approves the analysis to ensure completeness and compliance with safety requirements. + .. workflow:: Create/Maintain Safety Package :id: wf__cr_mt_safety_package :status: valid @@ -132,3 +146,4 @@ Workflow Safety Management | - Assessing the impact on affected elements, safety requirements, and work products | - Documenting the rationale for decisions regarding acceptance, implementation, or rejection of the change | The outcome is a change impact analysis report and a documented decision, which are reviewed and approved as part of the safety management process. + From fb1d682a283991ca06f752a7a5d27c5ade033f0a Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Wed, 19 Nov 2025 14:39:04 +0100 Subject: [PATCH 3/7] https://github.com/eclipse-score/process_description/issues/60 Addressed the point: Are the standard requirements, work products complete, correct linked? --- .../guidance/architecture_guideline.rst | 2 +- .../guidance/architecture_process_reqs.rst | 2 +- .../change_management_workproducts.rst | 1 + .../change_management_feature_template.rst | 2 +- ...ge_management_impact_analysis_template.rst | 2 +- .../software_development_template.rst | 6 +- .../guidance/quality_plan_guideline.rst | 3 +- .../guidance/quality_plan_template.rst | 2 +- .../safety_analysis_workproducts.rst | 4 +- .../guidance/checklist_safety_package.rst | 2 +- .../guidance/checklist_safety_plan.rst | 2 +- .../guidance/guideline_safety_management.rst | 200 ++++++++++-------- .../guidance/template_module_safety_plan.rst | 2 +- .../guidance/template_safety_manual.rst | 2 +- .../safety_management_workflow.rst | 15 -- .../safety_management_workproducts.rst | 4 +- 16 files changed, 131 insertions(+), 120 deletions(-) diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst index 9593bd8698..3cc5c7d3ad 100644 --- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst +++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst @@ -20,7 +20,7 @@ Architecture Guideline .. gd_guidl:: Architectural Design :id: gd_guidl__arch_design :status: valid - :complies: std_req__isopas8926__44411, std_req__isopas8926__44412 + :complies: std_req__isopas8926__44411, std_req__isopas8926__44412, std_req__iso26262__software_745 The guideline focuses on the steps which need to be performed in order to create the architectural design. The concept behind those steps is described in the :need:`[[title]] ` diff --git a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst index f541dd776c..0f6c14675c 100644 --- a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst +++ b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst @@ -127,7 +127,7 @@ Attributes of Architectural Elements :id: gd_req__arch_attr_safety :status: valid :tags: manual_prio_1, attribute, mandatory - :complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425 + :complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425, std_req__iso26262__software_746 :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch Each architectural element shall have a automotive safety integrity level (ASIL) identifier: diff --git a/process/process_areas/change_management/change_management_workproducts.rst b/process/process_areas/change_management/change_management_workproducts.rst index e5bd9f807f..f8b51644e5 100644 --- a/process/process_areas/change_management/change_management_workproducts.rst +++ b/process/process_areas/change_management/change_management_workproducts.rst @@ -38,6 +38,7 @@ Work Products Change Management | Safety anomaly: Conditions that deviate from expectations and that can lead to harm. | The documentation of a change request shall contain the list of changed work products, | the details of the change and the planned date of deployment of the change. + | In case a anomaly cannot be closed it shall be escalated to the project manager. .. workproduct:: Feature Request :id: wp__feat_request diff --git a/process/process_areas/change_management/guidance/change_management_feature_template.rst b/process/process_areas/change_management/guidance/change_management_feature_template.rst index b2ffc089d4..195c80c6c8 100644 --- a/process/process_areas/change_management/guidance/change_management_feature_template.rst +++ b/process/process_areas/change_management/guidance/change_management_feature_template.rst @@ -20,6 +20,6 @@ Feature Template .. gd_temp:: Feature Request Template :id: gd_temp__change_feature_request :status: valid - :complies: std_req__aspice_40__SUP-10-BP1, std_req__aspice_40__SUP-10-BP2, std_req__aspice_40__SUP-10-BP3, std_req__aspice_40__SUP-10-BP5, std_req__aspice_40__iic-18-57, std_req__iso26262__support_8422, std_req__iso26262__support_8431, std_req__iso26262__support_8432 + :complies: std_req__aspice_40__SUP-10-BP1, std_req__aspice_40__SUP-10-BP2, std_req__aspice_40__SUP-10-BP3, std_req__aspice_40__SUP-10-BP5, std_req__aspice_40__iic-18-57, std_req__iso26262__support_8422, std_req__iso26262__support_8431, std_req__iso26262__support_8432, std_req__iso26262__management_6431 for the content see :need:`doc__feature_name` diff --git a/process/process_areas/change_management/guidance/change_management_impact_analysis_template.rst b/process/process_areas/change_management/guidance/change_management_impact_analysis_template.rst index 5810bdf6d3..008bed8bb6 100644 --- a/process/process_areas/change_management/guidance/change_management_impact_analysis_template.rst +++ b/process/process_areas/change_management/guidance/change_management_impact_analysis_template.rst @@ -20,7 +20,7 @@ Impact Analysis Template .. gd_temp:: Impact Analysis Template :id: gd_temp__change_impact_analysis :status: valid - :complies: std_req__aspice_40__SUP-10-BP2, std_req__aspice_40__iic-18-57, std_req__iso26262__support_8431, std_req__iso26262__support_8432, std_req__isopas8926__4462 + :complies: std_req__aspice_40__SUP-10-BP2, std_req__aspice_40__iic-18-57, std_req__iso26262__support_8431, std_req__iso26262__support_8432, std_req__isopas8926__4462, std_req__iso26262__management_644, std_req__iso26262__management_6452 Type of Change Request ---------------------- diff --git a/process/process_areas/implementation/guidance/software_development_template.rst b/process/process_areas/implementation/guidance/software_development_template.rst index 96f2397619..ecd2749e61 100644 --- a/process/process_areas/implementation/guidance/software_development_template.rst +++ b/process/process_areas/implementation/guidance/software_development_template.rst @@ -18,7 +18,7 @@ Software Development Plan Template .. gd_temp:: Software Development Plan Template :id: gd_temp__software_development_plan :status: draft - :complies: std_req__iso26262__software_541 + :complies: std_req__iso26262__software_541, std_req__iso26262__software_543 Purpose +++++++ @@ -26,8 +26,8 @@ Purpose The main purpose of the software development plan is to define several software development related conditions: * selection of design and programming language -* design guideline -* coding guideline (e.g. MISRA, can also include style guide or naming convention) +* design guideline (e.g. Enforcement of low complexity, Use of naming conventions, etc) +* coding guideline (e.g. MISRA, can also include style guide or naming convention; Furthermore the coding guideline should respect the usual topics like Use of language subsets, Use of style guides, etc.) * SW configuration guideline * development tools diff --git a/process/process_areas/quality_management/guidance/quality_plan_guideline.rst b/process/process_areas/quality_management/guidance/quality_plan_guideline.rst index 7e08bc0e52..de18fb8dd0 100644 --- a/process/process_areas/quality_management/guidance/quality_plan_guideline.rst +++ b/process/process_areas/quality_management/guidance/quality_plan_guideline.rst @@ -20,7 +20,8 @@ Guideline Quality Management Plan .. gd_guidl:: Quality Management Plan Definitions Guideline :id: gd_guidl__qlm_plan_definitions :status: valid - :complies: std_req__iso26262__management_5423, std_req__aspice_40__SUP-1-BP1, std_req__aspice_40__SUP-1-BP2, std_req__aspice_40__SUP-1-BP3, std_req__aspice_40__SUP-1-BP4, std_req__aspice_40__SUP-1-BP7, std_req__aspice_40__PIM-3-BP1, std_req__aspice_40__PIM-3-BP2, std_req__aspice_40__PIM-3-BP3, std_req__aspice_40__PIM-3-BP4, std_req__aspice_40__PIM-3-BP5, std_req__aspice_40__PIM-3-BP6, std_req__aspice_40__PIM-3-BP7, std_req__aspice_40__SUP-1-BP5, std_req__aspice_40__SUP-1-BP6, std_req__aspice_40__PIM-3-BP8 + :complies: std_req__iso26262__management_5423, std_req__aspice_40__SUP-1-BP1, std_req__aspice_40__SUP-1-BP2, std_req__aspice_40__SUP-1-BP3, std_req__aspice_40__SUP-1-BP4, std_req__aspice_40__SUP-1-BP7, std_req__aspice_40__PIM-3-BP1, std_req__aspice_40__PIM-3-BP2, std_req__aspice_40__PIM-3-BP3, std_req__aspice_40__PIM-3-BP4, std_req__aspice_40__PIM-3-BP5, std_req__aspice_40__PIM-3-BP6, std_req__aspice_40__PIM-3-BP7, std_req__aspice_40__SUP-1-BP5, std_req__aspice_40__SUP-1-BP6, std_req__aspice_40__PIM-3-BP8, std_req__iso26262__management_5451 + | **Overall quality management:** | diff --git a/process/process_areas/quality_management/guidance/quality_plan_template.rst b/process/process_areas/quality_management/guidance/quality_plan_template.rst index 9880e2e2d2..8a41b80e54 100644 --- a/process/process_areas/quality_management/guidance/quality_plan_template.rst +++ b/process/process_areas/quality_management/guidance/quality_plan_template.rst @@ -20,7 +20,7 @@ Template Quality Plan .. gd_temp:: Quality Management Plan Template :id: gd_temp__qlm_plan :status: valid - :complies: std_req__iso26262__management_5423, std_req__aspice_40__SUP-1-BP1, std_req__aspice_40__SUP-1-BP2, std_req__aspice_40__SUP-1-BP3, std_req__aspice_40__SUP-1-BP4, std_req__aspice_40__SUP-1-BP7, std_req__aspice_40__PIM-3-BP1, std_req__aspice_40__PIM-3-BP2, std_req__aspice_40__PIM-3-BP3, std_req__aspice_40__PIM-3-BP4, std_req__aspice_40__PIM-3-BP5, std_req__aspice_40__PIM-3-BP6, std_req__aspice_40__PIM-3-BP7 + :complies: std_req__iso26262__management_5423, std_req__aspice_40__SUP-1-BP1, std_req__aspice_40__SUP-1-BP2, std_req__aspice_40__SUP-1-BP3, std_req__aspice_40__SUP-1-BP4, std_req__aspice_40__SUP-1-BP7, std_req__aspice_40__PIM-3-BP1, std_req__aspice_40__PIM-3-BP2, std_req__aspice_40__PIM-3-BP3, std_req__aspice_40__PIM-3-BP4, std_req__aspice_40__PIM-3-BP5, std_req__aspice_40__PIM-3-BP6, std_req__aspice_40__PIM-3-BP7, std_req__iso26262__management_5451 :note: The quality management plan shall be continuously maintained during the project. Deviations to the platform plan should be documented here. diff --git a/process/process_areas/safety_analysis/safety_analysis_workproducts.rst b/process/process_areas/safety_analysis/safety_analysis_workproducts.rst index e53ceb1f6a..173729727a 100644 --- a/process/process_areas/safety_analysis/safety_analysis_workproducts.rst +++ b/process/process_areas/safety_analysis/safety_analysis_workproducts.rst @@ -45,7 +45,7 @@ Workproducts Safety Analysis .. workproduct:: Component FMEA :id: wp__sw_component_fmea :status: valid - :complies: std_wp__iso26262__analysis_751, std_wp__iso26262__analysis_851, std_wp__isopas8926__4524 + :complies: std_wp__iso26262__analysis_751, std_wp__iso26262__analysis_851, std_wp__isopas8926__4524, std_wp__iso26262__software_752 FMEA, verifies the component architecture (as part of SW Safety Concept) @@ -54,7 +54,7 @@ Workproducts Safety Analysis .. workproduct:: Component DFA :id: wp__sw_component_dfa :status: valid - :complies: std_wp__iso26262__analysis_751, std_wp__iso26262__software_753, std_wp__isopas8926__4524 + :complies: std_wp__iso26262__analysis_751, std_wp__iso26262__software_753, std_wp__isopas8926__4524, std_wp__iso26262__software_752 Dependent Failure Analysis on component/module level diff --git a/process/process_areas/safety_management/guidance/checklist_safety_package.rst b/process/process_areas/safety_management/guidance/checklist_safety_package.rst index 6fbf0dd55e..59ace9a138 100644 --- a/process/process_areas/safety_management/guidance/checklist_safety_package.rst +++ b/process/process_areas/safety_management/guidance/checklist_safety_package.rst @@ -18,6 +18,6 @@ Safety Package Formal Review Checklist .. gd_chklst:: Safety Package Formal Review Checklist :id: gd_chklst__safety_package :status: valid - :complies: std_req__iso26262__management_6491, std_req__iso26262__management_6492, std_req__iso26262__management_6493, std_req__iso26262__management_64101, std_req__iso26262__management_64102, std_req__iso26262__management_64103, std_req__iso26262__management_64104, std_req__iso26262__management_64105 + :complies: std_req__iso26262__management_5425, std_req__iso26262__management_6491, std_req__iso26262__management_6492, std_req__iso26262__management_6493, std_req__iso26262__management_64101, std_req__iso26262__management_64102, std_req__iso26262__management_64103, std_req__iso26262__management_64104, std_req__iso26262__management_64105 For the content see here: :need:`doc__module_name_safety_package_fdr` diff --git a/process/process_areas/safety_management/guidance/checklist_safety_plan.rst b/process/process_areas/safety_management/guidance/checklist_safety_plan.rst index d6edbfad91..ca1fa6b5ce 100644 --- a/process/process_areas/safety_management/guidance/checklist_safety_plan.rst +++ b/process/process_areas/safety_management/guidance/checklist_safety_plan.rst @@ -18,6 +18,6 @@ Safety Plan Formal Review Checklist .. gd_chklst:: Safety Plan Formal Review Checklist :id: gd_chklst__safety_plan :status: valid - :complies: std_req__iso26262__management_6491, std_req__iso26262__management_6492, std_req__iso26262__management_6493, std_req__iso26262__management_64101, std_req__iso26262__management_64102, std_req__iso26262__management_64103, std_req__iso26262__management_64104, std_req__iso26262__management_64105 + :complies: std_req__iso26262__management_5425, std_req__iso26262__management_6491, std_req__iso26262__management_6492, std_req__iso26262__management_6493, std_req__iso26262__management_64101, std_req__iso26262__management_64102, std_req__iso26262__management_64103, std_req__iso26262__management_64104, std_req__iso26262__management_64105, std_req__iso26262__management_5427, std_req__iso26262__management_6421, std_req__iso26262__management_6431, std_req__iso26262__management_6461, std_req__iso26262__management_6462, std_req__iso26262__management_6464, std_req__iso26262__management_64610, std_req__iso26262__management_64113 For the content see here: :need:`doc__module_name_safety_plan_fdr` diff --git a/process/process_areas/safety_management/guidance/guideline_safety_management.rst b/process/process_areas/safety_management/guidance/guideline_safety_management.rst index a7af6b0796..3eb49a9383 100644 --- a/process/process_areas/safety_management/guidance/guideline_safety_management.rst +++ b/process/process_areas/safety_management/guidance/guideline_safety_management.rst @@ -20,93 +20,119 @@ Safety Management Guideline .. gd_guidl:: Safety plan definitions :id: gd_guidl__saf_plan_definitions :status: valid - :complies: std_req__iso26262__management_6465, std_req__iso26262__management_6466, std_req__iso26262__management_6467, std_req__iso26262__management_6468, std_req__iso26262__management_6469 - - **Overall safety management:** - - Safety culture: - Safety culture is planned to grow in the SW platform. This shall be fostered by doing a lessons learned after each feature development completion, using the ISO 26262-2 Table B.1 as a questionnaire. - This lessons learned is the main input for process improvement managed by :need:`wp__process_impr_report` - As starting point for safety culture we define a Committer selection process to already have professionals with safety experience in the teams. - - Additionally the SW platform's processes are defined with experience of several companies already performing successful safe SW development. This also improves independence of reviews for the process definitions. - - Quality Management: - ASPICE standard is selected for quality management. Processes will always link to the :ref:`standard_iso26262` standard and to the :ref:`ASPICE PAM4 ` standard. - - Competence management: - The :need:`rl__safety_manager` on SW platform level is responsible to define a competence management for the whole platform. - Expectation is that the safety competence of the persons nominated for the roles is already given and only has to be checked. - The exception from this are the committers, for these no safety competence needs to be enforced. - So the module safety managers shall consult the :need:`module safety plan ` and perform accordingly in their module project. - - Communication: - Development teams are interdisciplinary, so the regular (sprint) planning and review meetings enable communication (as defined in in the project specific :need:`project management plan `). Another main communication means are the Pull Request reviews. - Also the standard Eclipse Foundation communication strategies are used (e.g. mailing lists) - - Safety anomalies: - As the SW platform organization does not have own vehicles in the field, it relies on feedback from OEMs and Distributors on bugs discovered in the field. The need for this feedback is part of each safety manual. - But also during development of change requests to existing features, bug reporting by the Open Source community or integration of existing SW components into new features may lead to the discovery of new safety anomalies. - Safety anomalies can also be deviations from the development process with impact on safety. - If these are known at the time of creation of a release they will be part of the :need:`wp__module_safety_package` or :need:`wp__platform_safety_package` for the SEooC. - Safety anomalies relevant for already delivered releases will be identified as such and communicated (as defined in Problem Resolution part of :need:`wp__platform_mgmt`) via the :need:`wp__issue_track_system` (which is also Open Source). - - **Tailoring safety activities:** - Main tailoring driver is that the SW platform is pure SW development and is provided as "SEooC" - this explains mainly the generic, platform wide tailoring. - Tailoring is done for the whole SW platform by defining only the relevant work products and an argumentation why the others are not needed in :ref:`standard_iso26262` and :need:`platform safety plan `. - But there may be also additional tailoring for each module SEooC development to restrict further the work products. This is documented in every :need:`wp__module_safety_plan`. Here the usage of already existing components is the main tailoring driver. - - **Planning safety activities:** - In the safety plan the nomination of the safety manager and the project manager is documented. - The planning of safety activities is done using issues in the :need:`wp__issue_track_system` as specified in the :need:`wp__platform_mgmt` - - It contains for each issue: - - * objective - as part of the issue description - * dependencies on other activities or information - by links to the respective issues - * responsible person for the activity - as issue assignee - * required resources for the activity - by selecting a team label (or "project") pointing to a team of committers dedicated to the issue resolution - * duration in time, including start and end point - by selecting a milestone - * UID of the resulting work products - stated in the issue title - - The planning of safety activities is divided into the - - * platform SEooC planning, dealing with all work products needed only once for the platform. This is included in :need:`wp__platform_safety_plan` - * module SEooC planning, dealing with all work products needed for each module development (initiated by a change request), included in :need:`wp__module_safety_plan`. This module safety planning also includes the planning of OSS component qualification based on :need:`gd_guidl__component_classification`. - - A template exists to guide this: :need:`gd_temp__module_safety_plan`. - - **Planning supporting processes:** - Supporting processes (Requirements Management, Configuration Management, Change Management, Documentation Management, Tool Management) are planned within the :need:`wp__platform_mgmt` - - **Planning integration and verification:** - Integration on the target hardware is not done in the scope of the SW platform project, but SW/SW integration up to the feature level is performed and its test results are part of the :need:`wp__verification_platform_ver_report`. - - The integration on the target hardware done by the distributor or OEM is supported by delivering a set of HW/SW integration tests which were already run successfully on a reference HW platform. - This is planned by the respective work products: - - * :need:`wp__verification_feat_int_test` - * :need:`wp__verification_platform_int_test` - - Verification planning is documented in :need:`wp__verification_plan` - - **Scheduling of confirmation reviews, audit and assessment:** - Scheduling is done in the same way as for all work products definition by issues. The respective work products are :need:`wp__fdr_reports` and :need:`wp__audit_report` - - **Planning of dependent failures and safety analyses:** - In cases where the components consist of sub-components there will be more than one architecture level. DFA and Safety analysis will then be done on these multiple levels. See the respective work products: - - * feature level: :need:`wp__feature_fmea` and :need:`wp__feature_dfa` - * component level: :need:`wp__sw_component_fmea` and :need:`wp__sw_component_dfa` - - **Provision of the confidence in the use of software tools:** - Tool Management planning is part of the :need:`wp__platform_mgmt`. The respective work product to be planned as an issue of the generic safety plan is the :need:`wp__tool_verification_report`, which contains tool evaluation and if applicable qualification of the SW platform toolchain. - Components developed in different programming languages will have different toolchains. They will be qualified once for the SW platform. - - **(OSS) Component qualification planning:** - Based on the component classification as described in :need:`gd_guidl__component_classification`, - the qualification of the component is planned as part of the :need:`gd_temp__module_safety_plan`. - The template contains guidance how to do this and to document in the "OSS (sub-)component Workproducts" list. + :complies: std_req__iso26262__management_5426, std_req__iso26262__management_6465, std_req__iso26262__management_6466, std_req__iso26262__management_6467, std_req__iso26262__management_6468, std_req__iso26262__management_6469, std_req__iso26262__management_6422, std_req__iso26262__management_6423, std_req__iso26262__management_6424, std_req__iso26262__management_6451, std_req__iso26262__management_6452, std_req__iso26262__management_6453, std_req__iso26262__management_6454, std_req__iso26262__management_6455, std_req__iso26262__management_6456, std_req__iso26262__management_6457, std_req__iso26262__management_6461, std_req__iso26262__management_6462, std_req__iso26262__management_6463, std_req__iso26262__management_64610, std_req__iso26262__management_6472, std_req__iso26262__management_6471, std_req__iso26262__management_64111, std_req__iso26262__management_64112, std_req__iso26262__management_64113, std_req__iso26262__management_64114, std_req__iso26262__management_64121, std_req__iso26262__management_64122, std_req__iso26262__management_64123, std_req__iso26262__management_64124, std_req__iso26262__management_64125, std_req__iso26262__management_64126, std_req__iso26262__management_64127, std_req__iso26262__management_64128, std_req__iso26262__management_6431, std_req__iso26262__management_6432, std_req__iso26262__management_6433, std_req__iso26262__management_6454, std_req__iso26262__management_64129, std_req__iso26262__management_641210, std_req__iso26262__management_641211, std_req__iso26262__management_641212, std_req__iso26262__management_641213, std_req__iso26262__software_747, std_req__iso26262__software_1046, std_req__iso26262__software_1144, std_req__iso26262__support_8441, std_req__iso26262__management_5424, std_req__iso26262__management_5427, std_req__iso26262__management_5432, std_req__iso26262__management_5441, std_req__iso26262__management_5424, std_req__iso26262__management_5427, std_req__iso26262__management_5461 + + + + + | **Overall safety management:** + | Safety culture: + | Safety culture is planned to grow in the SW platform. This shall be fostered by doing a lessons learned after each feature development completion, using the ISO 26262-2 Table B.1 as a questionnaire. + | This lessons learned is the main input for process improvement managed by :need:`wp__process_impr_report` + | As starting point for safety culture we define a Committer selection process to already have professionals with safety experience in the teams. + | + | Additionally the SW platform's processes are defined with experience of several companies already performing successful safe SW development. This also improves independence of reviews for the process definitions. + | + | Quality Management: + | ASPICE standard is selected for quality management. Processes will always link to the :ref:`standard_iso26262` standard and to the :ref:`ASPICE PAM4 ` standard. + | + | Competence management: + | The :need:`rl__safety_manager` on SW platform level is responsible to define a competence management for the whole platform. + | Expectation is that the safety competence of the persons nominated for the roles is already given and only has to be checked. + | The exception from this are the committers, for these no safety competence needs to be enforced. + | So the module safety managers shall consult the :need:`module safety plan ` and perform accordingly in their module project. + | + | Communication: + | Development teams are interdisciplinary, so the regular (sprint) planning and review meetings enable communication (as defined in in the project specific :need:`project management plan `). Another main communication means are the Pull Request reviews. + | Also the standard Eclipse Foundation communication strategies are used (e.g. mailing lists) + | + | Safety anomalies: + | As the SW platform organization does not have own vehicles in the field, it relies on feedback from OEMs and Distributors on bugs discovered in the field. The need for this feedback is part of each safety manual. + | But also during development of change requests to existing features, bug reporting by the Open Source community or integration of existing SW components into new features may lead to the discovery of new safety anomalies. + | Safety anomalies can also be deviations from the development process with impact on safety. + | If these are known at the time of creation of a release they will be part of the :need:`wp__module_safety_package` or :need:`wp__platform_safety_package` for the SEooC. + | Safety anomalies relevant for already delivered releases will be identified as such and communicated (as defined in Problem Resolution part of :need:`wp__platform_mgmt`) via the :need:`wp__issue_track_system` (which is also Open Source). + | + | **Tailoring Safety Activities** + | The main driver for tailoring safety activities in the software platform context is that the platform is developed purely as software and provided as a Safety Element out of Context (SEooC). This requires a generic, platform-wide approach to tailoring, ensuring that safety processes are both efficient and relevant. + | Before any tailoring is performed, an **impact analysis** must be conducted in accordance with ISO 26262. This analysis determines whether the item or component is a new development, a modification, or an existing item with a modified environment. The results of this analysis guide the extent and nature of any tailoring. + | If tailoring is necessary, it must be justified and documented. The rationale should demonstrate that the tailored approach is sufficient to achieve the required level of functional safety. Tailoring may be driven by several factors, including: + | - Proven-in-use arguments, + | - Qualification of software components, + | - Confidence in the use of software tools. + | In each case, the tailoring must follow the relevant guidance and requirements set out in ISO 26262, ensuring that all safety goals are met and that the integrity of the safety lifecycle is maintained. + | For the software platform as a whole, tailoring is typically achieved by clearly defining which work products are relevant and providing a reasoned argument for omitting others. This is documented in the platform safety plan and the standard ISO 26262 reference documentation. + | Where necessary, additional tailoring may be applied at the module or feature level, particularly for SEooC developments. In these cases, the main driver for tailoring is often the reuse of existing, qualified components. Such module-specific tailoring is documented in the respective feature safety plans. + | This approach ensures that safety activities are focused, efficient, and appropriate to the context of a reusable software platform, while maintaining compliance with the intent and requirements of ISO 26262. + | Tailoring is done for the whole SW platform by defining only the relevant work products and an argumentation why the others are not needed in :ref:`standard_iso26262` and :need:`platform safety plan `. + | When safety activities are tailored because an element is developed as a Safety Element out of Context (SEooC): + | a) The SEooC development must be based on a requirements specification that is derived from well-defined assumptions about its intended use and context, including all relevant external interfaces. + | b) These assumptions regarding intended use and context must be validated when the SEooC is integrated into its target application. + | This approach ensures that SEooC development remains compliant with ISO 26262 expectations. + | Such SEooC tailoring can happen for each module SEooC development to restrict further the work products. This is documented in every :need:`wp__module_safety_plan`. Here the usage of already existing components is the main tailoring driver. + + | Main tailoring driver is that the SW platform is pure SW development and is provided as "SEooC" - this explains mainly the generic, platform wide tailoring. + | Tailoring is done for the whole SW platform by defining only the relevant work products and an argumentation why the others are not needed in :ref:`standard_iso26262` and `REPLACE_doc__platform_safety_plan`. + | But there may be also additional tailoring for each module SEooC development to restrict further the work products. This is documented in every feature safety plan. Here the usage of already existing components is the main tailoring driver. + | + | **Planning safety activities:** + | In the safety plan the nomination of the safety manager and the project manager is documented. + | The planning of safety activities is done using issues in the :need:`wp__issue_track_system` as specified in the :need:`wp__platform_mgmt` + | It contains for each issue: + | + | * objective - as part of the issue description + | * dependencies on other activities or information - by links to the respective issues + | * responsible person for the activity - as issue assignee + | * required resources for the activity - by selecting a team label (or "project") pointing to a team of committers dedicated to the issue resolution + | * duration in time, including start and end point - by selecting a milestone + | * UID of the resulting work products - stated in the issue title + | + | The planning of safety activities is divided into the + | + | * platform SEooC planning, dealing with all work products needed only once for the platform. This is included in :need:`wp__platform_safety_plan` + | * module SEooC planning, dealing with all work products needed for each module development (initiated by a change request), included in :need:`wp__module_safety_plan`. This module safety planning also includes the planning of OSS component qualification based on :need:`gd_guidl__component_classification`. + | + | A template exists to guide this: :need:`gd_temp__module_safety_plan`. + | + | **Planning supporting processes:** + | Supporting processes (Requirements Management, Configuration Management, Change Management, Documentation Management, Tool Management) are planned within the :need:`wp__platform_mgmt` + | + | **Planning integration and verification:** + | Integration on the target hardware is not done in the scope of the SW platform project, but SW/SW integration up to the feature level is performed and its test results are part of the :need:`wp__verification_platform_ver_report`. + | + | The integration on the target hardware done by the distributor or OEM is supported by delivering a set of HW/SW integration tests which were already run successfully on a reference HW platform. + | This is planned by the respective work products: + | + | * :need:`wp__verification_feat_int_test` + | * :need:`wp__verification_platform_int_test` + | + | Verification planning is documented in :need:`wp__verification_plan` + | As part of the verification process for production releases, it shall be ensured that the embedded software contains all specified functions and properties, + | and only contains other unspecified functions if these do not impair compliance with the software safety requirements. + | Any unspecified functions, such as code for debugging or instrumentation, must either be deactivated or removed prior to release, unless their presence does not affect safety compliance. + | + | **Scheduling of confirmation reviews, audit and assessment:** + | Scheduling is done in the same way as for all work products definition by issues. The respective work products are :need:`wp__fdr_reports` and :need:`wp__audit_report` + | A person responsible for carrying out the functional safety audit shall be appointed as part of the scheduling process. This person has to have the required skillset and knowledge. + | The functional safety assessor may appoint one or more assistants to support the assessment. + | These assistants may not be fully independent from the developers of the relevant item, elements, or work products, but must possess at least a basic level of independence. + | The assessor is responsible for appraising the input from any assistants to ensure that the assessment remains objective and that an unbiased opinion is provided. + | The planning and follow-up of the audit or assessment shall also take into account the type of report to be issued—whether it is an acceptance, conditional acceptance (with required corrective actions and conditions for acceptance), or a rejection. + | Any conditions or corrective actions identified in the report must be addressed and tracked to completion as part of the safety management process. + | **Planning of dependent failures and safety analyses:** + | In cases where the components consist of sub-components there will be more than one architecture level. DFA and Safety analysis will then be done on these multiple levels. See the respective work products: + | + | * feature level: :need:`wp__feature_fmea` and :need:`wp__feature_dfa` + | * component level: :need:`wp__sw_component_fmea` and :need:`wp__sw_component_dfa` + | + | **Provision of the confidence in the use of software tools:** + | Tool Management planning is part of the :need:`wp__platform_mgmt`. The respective work product to be planned as an issue of the generic safety plan is the :need:`wp__tool_verification_report`, which contains tool evaluation and if applicable qualification of the SW platform toolchain. + | Components developed in different programming languages will have different toolchains. They will be qualified once for the SW platform. + | + | **(OSS) Component qualification planning:** + | Based on the component classification as described in :need:`gd_guidl__component_classification`, + | the qualification of the component is planned as part of the :need:`gd_temp__module_safety_plan`. + | The template contains guidance how to do this and to document in the "OSS (sub-)component Workproducts" list. .. gd_guidl:: Safety manual generation :id: gd_guidl__saf_man diff --git a/process/process_areas/safety_management/guidance/template_module_safety_plan.rst b/process/process_areas/safety_management/guidance/template_module_safety_plan.rst index c1a92cbc6e..c8dfc510ce 100644 --- a/process/process_areas/safety_management/guidance/template_module_safety_plan.rst +++ b/process/process_areas/safety_management/guidance/template_module_safety_plan.rst @@ -18,6 +18,6 @@ Module Safety Plan Template .. gd_temp:: Module Safety Plan Template :id: gd_temp__module_safety_plan :status: valid - :complies: std_req__iso26262__management_6465, std_req__iso26262__management_6466, std_req__iso26262__management_6467, std_req__iso26262__management_6468, std_req__iso26262__management_6469, std_req__isopas8926__44341, std_req__isopas8926__44342, std_req__isopas8926__44611, std_req__isopas8926__4463 + :complies: std_req__iso26262__management_5425, std_req__iso26262__management_5424, std_req__iso26262__management_6465, std_req__iso26262__management_6466, std_req__iso26262__management_6467, std_req__iso26262__management_6468, std_req__iso26262__management_6469, std_req__isopas8926__44341, std_req__isopas8926__44342, std_req__isopas8926__44611, std_req__isopas8926__4463, std_req__iso26262__management_5427, std_req__iso26262__management_6421 For the content see here: :need:`doc__module_name_safety_plan` diff --git a/process/process_areas/safety_management/guidance/template_safety_manual.rst b/process/process_areas/safety_management/guidance/template_safety_manual.rst index 18c8926ff5..1ce846a9f7 100644 --- a/process/process_areas/safety_management/guidance/template_safety_manual.rst +++ b/process/process_areas/safety_management/guidance/template_safety_manual.rst @@ -18,6 +18,6 @@ Safety Manual Template .. gd_temp:: Safety Manual Template :id: gd_temp__safety_manual :status: valid - :complies: std_req__iso26262__system_6411, std_req__iso26262__system_6412, std_req__iso26262__system_6413, std_req__iso26262__system_6414, std_req__iso26262__system_6421, std_req__iso26262__system_6422, std_req__iso26262__software_641, std_req__iso26262__software_642, std_req__iso26262__software_645, std_req__iso26262__support_12421 + :complies: std_req__iso26262__management_5425, std_req__iso26262__system_6411, std_req__iso26262__system_6412, std_req__iso26262__system_6413, std_req__iso26262__system_6414, std_req__iso26262__system_6421, std_req__iso26262__system_6422, std_req__iso26262__software_641, std_req__iso26262__software_642, std_req__iso26262__software_645, std_req__iso26262__support_12421 For the content see here: :need:`doc__module_name_safety_manual` diff --git a/process/process_areas/safety_management/safety_management_workflow.rst b/process/process_areas/safety_management/safety_management_workflow.rst index a6b98be489..452251ccb4 100644 --- a/process/process_areas/safety_management/safety_management_workflow.rst +++ b/process/process_areas/safety_management/safety_management_workflow.rst @@ -41,20 +41,6 @@ Workflow Safety Management | The Safety Manager shall approve the OSS component classification performed by an expert on this component. - .. workflow:: Perform Component Safety Analysis - :id: wf__perform_comp_safety_analysis - :status: valid - :responsible: rl__committer - :approved_by: rl__safety_manager - :input: wp__sw_component_class - :output: wp__component_safety_analysis - :contains: gd_guidl__component_safety_analysis, gd_temp__component_safety_analysis - :has: doc_concept__safety_management_process, doc_getstrt__safety_management_process - - | The committer is responsible for performing the safety analysis of the component after its classification. - | The safety analysis identifies and documents potential safety risks and mitigations for the component. - | The Safety Manager reviews and approves the analysis to ensure completeness and compliance with safety requirements. - .. workflow:: Create/Maintain Safety Package :id: wf__cr_mt_safety_package :status: valid @@ -146,4 +132,3 @@ Workflow Safety Management | - Assessing the impact on affected elements, safety requirements, and work products | - Documenting the rationale for decisions regarding acceptance, implementation, or rejection of the change | The outcome is a change impact analysis report and a documented decision, which are reviewed and approved as part of the safety management process. - diff --git a/process/process_areas/safety_management/safety_management_workproducts.rst b/process/process_areas/safety_management/safety_management_workproducts.rst index 3c7c6dac95..e3a7f3bf67 100644 --- a/process/process_areas/safety_management/safety_management_workproducts.rst +++ b/process/process_areas/safety_management/safety_management_workproducts.rst @@ -139,9 +139,7 @@ Workproducts Safety Management .. workproduct:: Tailoring Document Work Products :id: wp__tailoring_work_products :status: valid - :complies: std_wp__iso26262__management_651, std_wp__iso26262__management_751, std_wp__iso26262__system_652, std_wp__iso26262__system_653, std_wp__iso26262__system_654, std_wp__iso26262__system_655, std_wp__iso26262__system_656, std_wp__iso26262__system_657, std_wp__iso26262__system_751, std_wp__iso26262__system_752, std_wp__iso26262__system_851, std_wp__iso26262__system_852, std_wp__iso26262__software_652, std_wp__iso26262__software_1151, std_wp__iso26262__software_1152, std_wp__iso26262__software_app_c_52, std_wp__iso26262__software_app_c_54, std_wp__iso26262__software_app_c_57, std_wp__iso26262__support_551, std_wp__iso26262__support_552, std_wp__iso26262__support_553, std_wp__iso26262__support_554, std_wp__iso26262__support_555, std_wp__iso26262__support_1351, std_wp__iso26262__support_1352, std_wp__iso26262__support_1353, std_wp__iso26262__support_1451, std_wp__iso26262__support_1452, std_wp__iso26262__support_1551, std_wp__iso26262__support_1651, std_wp__iso26262__analysis_551, std_wp__iso26262__analysis_552, std_wp__isopas8926__4522 - - This work product "definition" links to all the work products which are not covered by the + :complies: std_wp__iso26262__management_651, std_wp__iso26262__management_751, std_wp__iso26262__system_652, std_wp__iso26262__system_653, std_wp__iso26262__system_654, std_wp__iso26262__system_655, std_wp__iso26262__system_656, std_wp__iso26262__system_657, std_wp__iso26262__system_751, std_wp__iso26262__system_752, std_wp__iso26262__system_851, std_wp__iso26262__system_852, std_wp__iso26262__software_652, std_wp__iso26262__software_1151, std_wp__iso26262__software_1152, std_wp__iso26262__software_app_c_52, std_wp__iso26262__software_app_c_54, std_wp__iso26262__software_app_c_57, std_wp__iso26262__support_551, std_wp__iso26262__support_552, std_wp__iso26262__support_553, std_wp__iso26262__support_554, std_wp__iso26262__support_555, std_wp__iso26262__support_1351, std_wp__iso26262__support_1352, std_wp__iso26262__support_1353, std_wp__iso26262__support_1451, std_wp__iso26262__support_1452, std_wp__iso26262__support_1551, std_wp__iso26262__support_1651, std_wp__iso26262__analysis_551, std_wp__iso26262__analysis_552, std_wp__isopas8926__4522 This work product "definition" links to all the work products which are not covered by the processes work products documented. Make sure these are tailored out in the safety plan for your project (documented in the PMP), to be able to demonstrate completeness as described in :need:`gd_guidl__saf_package`. It is not really a work product definition, From 033af319cf8485948e7d5d65bbf730f2e86331bf Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Wed, 19 Nov 2025 16:30:45 +0100 Subject: [PATCH 4/7] Final adpatations made to adress https://github.com/eclipse-score/process_description/issues/78 --- .../guidance/guideline_safety_management.rst | 14 ++++ .../safety_management_concept.rst | 2 +- .../safety_management_roles.rst | 68 +++++++++++++++++-- .../safety_management_workflow.rst | 13 ++++ .../safety_management_workproducts.rst | 20 +++++- process/roles/index.rst | 20 ------ 6 files changed, 109 insertions(+), 28 deletions(-) diff --git a/process/process_areas/safety_management/guidance/guideline_safety_management.rst b/process/process_areas/safety_management/guidance/guideline_safety_management.rst index 3eb49a9383..58bfb5ffaa 100644 --- a/process/process_areas/safety_management/guidance/guideline_safety_management.rst +++ b/process/process_areas/safety_management/guidance/guideline_safety_management.rst @@ -153,3 +153,17 @@ Safety Management Guideline | The safety package shall be generated progressively and automatically compiling the work products. | One of the checks to perform on the platform safety package is to check completeness of the | process compliance to standards, which can be seen from standard linkage charts in :ref:`external_standards`. + +.. gd_guidl:: Safety case creation and maintenance + :id: gd_guidl__saf_case + :status: valid + :complies: std_req__iso26262__management_6481, std_req__iso26262__management_6482 + + | **Safety Case Creation and Maintenance** + | A safety case shall be created and maintained for each item or element developed according to ISO 26262. + | The safety case provides the structured argument, supported by evidence, that functional safety has been achieved, in accordance with the safety plan. + | The safety case is developed progressively as work products are generated throughout the safety lifecycle. + | The safety manager is responsible for initiating, updating, and finalizing the safety case. + | Updates to the safety case are triggered by major lifecycle milestones, audits, or significant changes to the item or its context. + | The safety case references the safety package, which compiles the relevant work products as evidence for the safety argument. + | The safety case is reviewed and approved as part of the release process to demonstrate compliance with ISO 26262. diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst index 1b3ac29ef1..6306874288 100644 --- a/process/process_areas/safety_management/safety_management_concept.rst +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -39,7 +39,7 @@ Inputs Stakeholders ^^^^^^^^^^^^ -#. :need:`Technical Lead ` +#. :need:`Project Lead ` * planning of development for module and for platform projects * status reporting of safety activities diff --git a/process/process_areas/safety_management/safety_management_roles.rst b/process/process_areas/safety_management/safety_management_roles.rst index 74b37b04ff..ff3db17f7e 100644 --- a/process/process_areas/safety_management/safety_management_roles.rst +++ b/process/process_areas/safety_management/safety_management_roles.rst @@ -15,13 +15,69 @@ Roles ----- -For safety management no additional roles need to be defined. -Contributing Roles: +.. role:: Safety Manager + :id: rl__safety_manager + :status: valid + :contains: rl__committer - * :need:`Safety Manager ` - * :need:`External Auditor ` + The safety manager is responsible for making sure that ISO26262 is complied to in the project. He/She shall lead and monitor the safety relevant activities of the project. -A detailed overview of the responsibility for the steps of the requirement process is listed here: + Required skills -:ref:`workflow_requirements` + * Degree: Master's degree in electrical engineering/computer science/mathematics, or similar degree, or comparable work experience + * Solid understanding of functional safety management + * Knowledge in project management + * Deep understanding of quality criteria and the correlating methods and procedures to achieve and verify them + * Technical know-how of embedded systems + * Preferred training: Automotive Functional Safety Expert (AFSE) or similar + + Knowledge of standards + + * ISO 26262 + + Experience + + * 2 years of experience in the management of safety topics + * Experience in managing projects + * Experience in managing safety anomalies + + Responsibility + + * Creating the Safety Plan + * Functional Safety related project status reporting + * Creation and Monitoring of completeness of the safety case + * Reporting of safety anomalies + * Verify, that the preconditions for the "release for production", which are part of the release notes, are fulfilled, and the correctness, completeness and consistency of the release notes + * Coaching the project team w.r.t all questions related to functional safety + * Planning of safety audit + * Approval of OSS component classification and safety analyses (incl. DFA) + * Creating the safety manuals on platform and module level + * Checking that every person in his team has sufficient safety skills for his role + + Authority + + * Escalation of planning topics to the project manager defined in the safety plan + * Initiate the publication of a safety anomaly + * Recommend the Release of a SW platform or a module + * Refusing the approval of work products as defined in the workflows + * Refusing the approval of his team's role nomination (i.e. requesting that the role will be withdrawn) + + +.. role:: External Auditor + :id: rl__external_auditor + :status: valid + + Required skills, Knowledge of standards, Experience + + * External Auditor comes from organization specialized in safety audits and assessment, thus sufficient skill should be guaranteed by the sending organization. + * For performing the confirmation reviews also a safety manager from another (S-CORE) project can play the role of an external auditor, in this case the same skills apply as for the safety manager. + + Responsibility + + * Performing and reporting of safety audit + * Performing of confirmation reviews on safety plans, safety case and safety analysis (incl. DFA) + + Authority + + * Decision on the passing or failing of an audit diff --git a/process/process_areas/safety_management/safety_management_workflow.rst b/process/process_areas/safety_management/safety_management_workflow.rst index 452251ccb4..bf39ff5251 100644 --- a/process/process_areas/safety_management/safety_management_workflow.rst +++ b/process/process_areas/safety_management/safety_management_workflow.rst @@ -132,3 +132,16 @@ Workflow Safety Management | - Assessing the impact on affected elements, safety requirements, and work products | - Documenting the rationale for decisions regarding acceptance, implementation, or rejection of the change | The outcome is a change impact analysis report and a documented decision, which are reviewed and approved as part of the safety management process. + +.. workflow:: Create/Maintain Safety Case + :id: wf__cr_mt_safety_case + :status: valid + :responsible: rl__safety_manager + :approved_by: rl__project_lead + :input: wp__module_safety_package, wp__platform_safety_package + :output: wp__safety_case + :contains: gd_guidl__saf_case + :has: doc_concept__safety_management_process + + | The Safety Manager creates and maintains the safety case, compiling evidence from safety packages and other work products. + | The safety case provides the structured argument for functional safety compliance according to ISO 26262. diff --git a/process/process_areas/safety_management/safety_management_workproducts.rst b/process/process_areas/safety_management/safety_management_workproducts.rst index e3a7f3bf67..d2e89903eb 100644 --- a/process/process_areas/safety_management/safety_management_workproducts.rst +++ b/process/process_areas/safety_management/safety_management_workproducts.rst @@ -139,8 +139,26 @@ Workproducts Safety Management .. workproduct:: Tailoring Document Work Products :id: wp__tailoring_work_products :status: valid - :complies: std_wp__iso26262__management_651, std_wp__iso26262__management_751, std_wp__iso26262__system_652, std_wp__iso26262__system_653, std_wp__iso26262__system_654, std_wp__iso26262__system_655, std_wp__iso26262__system_656, std_wp__iso26262__system_657, std_wp__iso26262__system_751, std_wp__iso26262__system_752, std_wp__iso26262__system_851, std_wp__iso26262__system_852, std_wp__iso26262__software_652, std_wp__iso26262__software_1151, std_wp__iso26262__software_1152, std_wp__iso26262__software_app_c_52, std_wp__iso26262__software_app_c_54, std_wp__iso26262__software_app_c_57, std_wp__iso26262__support_551, std_wp__iso26262__support_552, std_wp__iso26262__support_553, std_wp__iso26262__support_554, std_wp__iso26262__support_555, std_wp__iso26262__support_1351, std_wp__iso26262__support_1352, std_wp__iso26262__support_1353, std_wp__iso26262__support_1451, std_wp__iso26262__support_1452, std_wp__iso26262__support_1551, std_wp__iso26262__support_1651, std_wp__iso26262__analysis_551, std_wp__iso26262__analysis_552, std_wp__isopas8926__4522 This work product "definition" links to all the work products which are not covered by the + :complies: std_wp__iso26262__management_651, std_wp__iso26262__management_751, std_wp__iso26262__system_652, std_wp__iso26262__system_653, std_wp__iso26262__system_654, std_wp__iso26262__system_655, std_wp__iso26262__system_656, std_wp__iso26262__system_657, std_wp__iso26262__system_751, std_wp__iso26262__system_752, std_wp__iso26262__system_851, std_wp__iso26262__system_852, std_wp__iso26262__software_652, std_wp__iso26262__software_1151, std_wp__iso26262__software_1152, std_wp__iso26262__software_app_c_52, std_wp__iso26262__software_app_c_54, std_wp__iso26262__software_app_c_57, std_wp__iso26262__support_551, std_wp__iso26262__support_552, std_wp__iso26262__support_553, std_wp__iso26262__support_554, std_wp__iso26262__support_555, std_wp__iso26262__support_1351, std_wp__iso26262__support_1352, std_wp__iso26262__support_1353, std_wp__iso26262__support_1451, std_wp__iso26262__support_1452, std_wp__iso26262__support_1551, std_wp__iso26262__support_1651, std_wp__iso26262__analysis_551, std_wp__iso26262__analysis_552, std_wp__isopas8926__4522 + + This work product "definition" links to all the work products which are not covered by the processes work products documented. Make sure these are tailored out in the safety plan for your project (documented in the PMP), to be able to demonstrate completeness as described in :need:`gd_guidl__saf_package`. It is not really a work product definition, but this is the best way to link to the tailored out standard work products. + +.. workproduct:: Safety Case + :id: wp__safety_case + :status: valid + :complies: std_wp__iso26262__management_654 + + The safety case provides the structured argument, supported by evidence, that functional safety has been achieved for the item or element, in accordance with the safety plan. + + The safety case: + * Compiles and references the relevant work products generated throughout the safety lifecycle to support the safety argument. + * Is developed progressively as work products become available, allowing for incremental release and assessment. + * In distributed developments, may combine the safety cases of customer and suppliers, referencing evidence from all parties and defining interfaces in a Development Interface Agreement (DIA). + * Supports safety planning by identifying intended safety arguments early, and supports progressive functional safety assessments as evidence accumulates. + + The safety case is a key deliverable to demonstrate compliance with ISO 26262 functional safety requirements. + The creation and maintenance of the safety case shall follow the process described in :need:`gd_guidl__saf_case`. diff --git a/process/roles/index.rst b/process/roles/index.rst index 90914f7f74..c1b9e5382c 100644 --- a/process/roles/index.rst +++ b/process/roles/index.rst @@ -64,12 +64,6 @@ Project Process roles The process community members are responsible for the definition of the process architecture of the project integrated management system and how they processes interact. The approval and release of the process is done by the safety, quality and security managers and the project leads (for the parts which affect them). -.. role:: External Auditor - :id: rl__external_auditor - :status: valid - - External auditing instance confirming the compliance to ISO26262 and the defined processes in S-CORE. The external auditor is not part of the project organization. - Project Development roles ------------------------- @@ -141,20 +135,6 @@ Project Feature teams The module team is responsible for all artifacts within the module SEooCs. Each module has only one responsible team but a team may also be responsible for several (small) modules. -.. role:: Safety Manager - :id: rl__safety_manager - :status: valid - :contains: rl__committer - - The safety manager is responsible for making sure that ISO26262 is complied to in the project. He/She shall lead and monitor the safety relevant activities of the feature development. - The safety manager is assigned and elected by a committee considering the project lead(s) - - Experience - - * 3+ years of proven experience in the management of safety topics - * Experience in managing projects - * Experience in managing safety anomalies - Project Roles list ------------------ From 84aa78b6f8afc7c2dad52a43dca805dca67bc41d Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Wed, 19 Nov 2025 16:50:24 +0100 Subject: [PATCH 5/7] Fixed build error: /home/runner/work/process_description/process_description/process/process_areas/safety_management/safety_management_concept.rst:50: WARNING: unknown document: 'roles' [ref.doc] --- .../safety_management/safety_management_concept.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst index 6306874288..db03bee5bb 100644 --- a/process/process_areas/safety_management/safety_management_concept.rst +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -39,7 +39,7 @@ Inputs Stakeholders ^^^^^^^^^^^^ -#. :need:`Project Lead ` +#. :need:`Technical Lead ` * planning of development for module and for platform projects * status reporting of safety activities @@ -47,7 +47,7 @@ Stakeholders #. :need:`Safety Manager ` * main responsible for the safety management work products - * role definition in :doc:`roles` + * role definition in :doc:`/process_areas/safety_management/safety_management_roles` #. :need:`External Auditor ` From 35bf3bc50cce757b8b2c765039276c39a2ca567e Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Tue, 25 Nov 2025 07:43:45 +0100 Subject: [PATCH 6/7] Fixed review findings --- .../module_name/docs/manual/safety_manual.rst | 2 +- .../safety_mgt/module_safety_plan_fdr.rst | 2 +- .../change_management_workproducts.rst | 2 +- .../change_management_feature_template.rst | 2 +- .../guidance/guideline_safety_management.rst | 57 +++++++------------ .../safety_management_concept.rst | 28 +++++---- .../safety_management_getstrt.rst | 21 +++++-- .../safety_management_roles.rst | 6 +- .../safety_management_workflow.rst | 17 +----- .../safety_management_workproducts.rst | 16 ------ process/standards/aspice_40/iic/iic-06.rst | 8 +-- 11 files changed, 65 insertions(+), 96 deletions(-) diff --git a/process/folder_templates/modules/module_name/docs/manual/safety_manual.rst b/process/folder_templates/modules/module_name/docs/manual/safety_manual.rst index c4b890722f..4675438131 100644 --- a/process/folder_templates/modules/module_name/docs/manual/safety_manual.rst +++ b/process/folder_templates/modules/module_name/docs/manual/safety_manual.rst @@ -66,7 +66,7 @@ List of AoUs expected from the environment the platform / module runs on: Assumptions on the User ^^^^^^^^^^^^^^^^^^^^^^^ -| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety case. +| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety package. | Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: . Assumptions from components to their users can be fulfilled in two ways: | 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform". | 2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature. diff --git a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst index bf6b2906b5..2df20c4383 100644 --- a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst +++ b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst @@ -58,7 +58,7 @@ The purpose of this safety plan formal review checklist is to report status of t - * - 3 - - Does the safety plan define all needed activities for safety management (incl. Confirmation review and Safety Audit)? + - Does the safety plan define all needed activities for safety management (incl. Formal document review and Safety Audit)? - [YES | NO ] - diff --git a/process/process_areas/change_management/change_management_workproducts.rst b/process/process_areas/change_management/change_management_workproducts.rst index f8b51644e5..f242a98cb1 100644 --- a/process/process_areas/change_management/change_management_workproducts.rst +++ b/process/process_areas/change_management/change_management_workproducts.rst @@ -38,7 +38,7 @@ Work Products Change Management | Safety anomaly: Conditions that deviate from expectations and that can lead to harm. | The documentation of a change request shall contain the list of changed work products, | the details of the change and the planned date of deployment of the change. - | In case a anomaly cannot be closed it shall be escalated to the project manager. + | In case a anomaly cannot be closed it shall be escalated to the :need:`Project Lead `. .. workproduct:: Feature Request :id: wp__feat_request diff --git a/process/process_areas/change_management/guidance/change_management_feature_template.rst b/process/process_areas/change_management/guidance/change_management_feature_template.rst index 195c80c6c8..635ab75d3b 100644 --- a/process/process_areas/change_management/guidance/change_management_feature_template.rst +++ b/process/process_areas/change_management/guidance/change_management_feature_template.rst @@ -20,6 +20,6 @@ Feature Template .. gd_temp:: Feature Request Template :id: gd_temp__change_feature_request :status: valid - :complies: std_req__aspice_40__SUP-10-BP1, std_req__aspice_40__SUP-10-BP2, std_req__aspice_40__SUP-10-BP3, std_req__aspice_40__SUP-10-BP5, std_req__aspice_40__iic-18-57, std_req__iso26262__support_8422, std_req__iso26262__support_8431, std_req__iso26262__support_8432, std_req__iso26262__management_6431 + :complies: std_req__aspice_40__SUP-10-BP1, std_req__aspice_40__SUP-10-BP2, std_req__aspice_40__SUP-10-BP3, std_req__aspice_40__SUP-10-BP5, std_req__aspice_40__iic-18-57, std_req__iso26262__support_8422, std_req__iso26262__support_8431, std_req__iso26262__support_8432, std_req__iso26262__management_644 for the content see :need:`doc__feature_name` diff --git a/process/process_areas/safety_management/guidance/guideline_safety_management.rst b/process/process_areas/safety_management/guidance/guideline_safety_management.rst index 58bfb5ffaa..61ae691083 100644 --- a/process/process_areas/safety_management/guidance/guideline_safety_management.rst +++ b/process/process_areas/safety_management/guidance/guideline_safety_management.rst @@ -54,26 +54,27 @@ Safety Management Guideline | Safety anomalies relevant for already delivered releases will be identified as such and communicated (as defined in Problem Resolution part of :need:`wp__platform_mgmt`) via the :need:`wp__issue_track_system` (which is also Open Source). | | **Tailoring Safety Activities** - | The main driver for tailoring safety activities in the software platform context is that the platform is developed purely as software and provided as a Safety Element out of Context (SEooC). This requires a generic, platform-wide approach to tailoring, ensuring that safety processes are both efficient and relevant. - | Before any tailoring is performed, an **impact analysis** must be conducted in accordance with ISO 26262. This analysis determines whether the item or component is a new development, a modification, or an existing item with a modified environment. The results of this analysis guide the extent and nature of any tailoring. - | If tailoring is necessary, it must be justified and documented. The rationale should demonstrate that the tailored approach is sufficient to achieve the required level of functional safety. Tailoring may be driven by several factors, including: - | - Proven-in-use arguments, + | The software platform is developed purely as software and provided as a Safety Element out of Context (SEooC). That is why only software relevant parts of :ref:`standard_iso26262` are used. + | This requires a generic, platform-wide approach to tailoring so that safety processes remain efficient, relevant, and compliant with the software relevant ISO 26262. + | Before any tailoring is performed, an **impact analysis** must be conducted in accordance with ISO 26262. This analysis is performed on element level, not on the item level as previously stated. + | This analysis determines whether the element is a new development, a modification, or an existing element with a modified environment. The results guide the extent and nature of any tailoring. + | + | If tailoring is necessary, it must be justified and documented. The rationale should demonstrate that the tailored approach is sufficient to achieve the required level of functional safety. Tailoring may be driven by factors such as: + | | - Qualification of software components, | - Confidence in the use of software tools. - | In each case, the tailoring must follow the relevant guidance and requirements set out in ISO 26262, ensuring that all safety goals are met and that the integrity of the safety lifecycle is maintained. - | For the software platform as a whole, tailoring is typically achieved by clearly defining which work products are relevant and providing a reasoned argument for omitting others. This is documented in the platform safety plan and the standard ISO 26262 reference documentation. - | Where necessary, additional tailoring may be applied at the module or feature level, particularly for SEooC developments. In these cases, the main driver for tailoring is often the reuse of existing, qualified components. Such module-specific tailoring is documented in the respective feature safety plans. - | This approach ensures that safety activities are focused, efficient, and appropriate to the context of a reusable software platform, while maintaining compliance with the intent and requirements of ISO 26262. - | Tailoring is done for the whole SW platform by defining only the relevant work products and an argumentation why the others are not needed in :ref:`standard_iso26262` and :need:`platform safety plan `. - | When safety activities are tailored because an element is developed as a Safety Element out of Context (SEooC): - | a) The SEooC development must be based on a requirements specification that is derived from well-defined assumptions about its intended use and context, including all relevant external interfaces. - | b) These assumptions regarding intended use and context must be validated when the SEooC is integrated into its target application. - | This approach ensures that SEooC development remains compliant with ISO 26262 expectations. - | Such SEooC tailoring can happen for each module SEooC development to restrict further the work products. This is documented in every :need:`wp__module_safety_plan`. Here the usage of already existing components is the main tailoring driver. - - | Main tailoring driver is that the SW platform is pure SW development and is provided as "SEooC" - this explains mainly the generic, platform wide tailoring. - | Tailoring is done for the whole SW platform by defining only the relevant work products and an argumentation why the others are not needed in :ref:`standard_iso26262` and `REPLACE_doc__platform_safety_plan`. - | But there may be also additional tailoring for each module SEooC development to restrict further the work products. This is documented in every feature safety plan. Here the usage of already existing components is the main tailoring driver. + | + | Note: Proven-in-use arguments are generally not applicable for a reusable SEooC platform intended for integration into various target applications and environments. + | + | For the software platform as a whole, tailoring is achieved by clearly defining which work products are relevant and providing a reasoned argument for omitting others. This is documented in the platform safety plan and the ISO 26262 reference documentation. + | + | Additional tailoring may apply at the module or feature level, particularly for SEooC developments where reuse of existing qualified components is the main driver. Such tailoring is documented in the respective module safety plans. + | + | When safety activities are tailored because an element is developed as SEooC: + | a) The SEooC development must be based on a requirements specification derived from well-defined assumptions about its intended use and context, including all relevant external interfaces. + | b) These assumptions must be validated when the SEooC is integrated into its target application. + | + | This approach ensures that safety activities are focused, efficient, and appropriate to the context of a reusable software platform, while maintaining compliance with ISO 26262 requirements and intent. | | **Planning safety activities:** | In the safety plan the nomination of the safety manager and the project manager is documented. @@ -107,14 +108,12 @@ Safety Management Guideline | * :need:`wp__verification_platform_int_test` | | Verification planning is documented in :need:`wp__verification_plan` - | As part of the verification process for production releases, it shall be ensured that the embedded software contains all specified functions and properties, - | and only contains other unspecified functions if these do not impair compliance with the software safety requirements. | Any unspecified functions, such as code for debugging or instrumentation, must either be deactivated or removed prior to release, unless their presence does not affect safety compliance. | - | **Scheduling of confirmation reviews, audit and assessment:** + | **Scheduling of formal document reviews, audit and assessment:** | Scheduling is done in the same way as for all work products definition by issues. The respective work products are :need:`wp__fdr_reports` and :need:`wp__audit_report` | A person responsible for carrying out the functional safety audit shall be appointed as part of the scheduling process. This person has to have the required skillset and knowledge. - | The functional safety assessor may appoint one or more assistants to support the assessment. + | The functional safety auditor may appoint one or more assistants to support the audit. | These assistants may not be fully independent from the developers of the relevant item, elements, or work products, but must possess at least a basic level of independence. | The assessor is responsible for appraising the input from any assistants to ensure that the assessment remains objective and that an unbiased opinion is provided. | The planning and follow-up of the audit or assessment shall also take into account the type of report to be issued—whether it is an acceptance, conditional acceptance (with required corrective actions and conditions for acceptance), or a rejection. @@ -153,17 +152,3 @@ Safety Management Guideline | The safety package shall be generated progressively and automatically compiling the work products. | One of the checks to perform on the platform safety package is to check completeness of the | process compliance to standards, which can be seen from standard linkage charts in :ref:`external_standards`. - -.. gd_guidl:: Safety case creation and maintenance - :id: gd_guidl__saf_case - :status: valid - :complies: std_req__iso26262__management_6481, std_req__iso26262__management_6482 - - | **Safety Case Creation and Maintenance** - | A safety case shall be created and maintained for each item or element developed according to ISO 26262. - | The safety case provides the structured argument, supported by evidence, that functional safety has been achieved, in accordance with the safety plan. - | The safety case is developed progressively as work products are generated throughout the safety lifecycle. - | The safety manager is responsible for initiating, updating, and finalizing the safety case. - | Updates to the safety case are triggered by major lifecycle milestones, audits, or significant changes to the item or its context. - | The safety case references the safety package, which compiles the relevant work products as evidence for the safety argument. - | The safety case is reviewed and approved as part of the release process to demonstrate compliance with ISO 26262. diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst index db03bee5bb..05d59c4529 100644 --- a/process/process_areas/safety_management/safety_management_concept.rst +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -24,8 +24,9 @@ Inputs for this concepts are mainly the requirements of ISO26262 "Part 2: Manage Key concept ^^^^^^^^^^^ -The Safety Management Plan should define the strategy to manage the identified safety activities -in an effective and repeatable way for the project life cycle. +The Safety Management Plan establishes a comprehensive strategy for managing all identified safety activities throughout the entire project life cycle. +It ensures that these activities are executed in a systematic, effective, and repeatable manner, providing clear guidance on responsibilities, processes, and control measures. +This approach supports risk mitigation, regulatory compliance, and continuous improvement, enabling the project team to maintain safety standards consistently from initiation to completion. Inputs ^^^^^^ @@ -39,24 +40,27 @@ Inputs Stakeholders ^^^^^^^^^^^^ -#. :need:`Technical Lead ` +#. :need:`Project Lead ` * planning of development for module and for platform projects - * status reporting of safety activities #. :need:`Safety Manager ` - * main responsible for the safety management work products + * main responsible to ensure ISO 26262 compliance in the project * role definition in :doc:`/process_areas/safety_management/safety_management_roles` + * status reporting of safety activities #. :need:`External Auditor ` - * understand activities planning, processes definition and execution + * Performs independent safety audits and formal document reviews (e.g., safety plans, safety packages, safety analyses). + * Verifies compliance with defined safety processes and standards. + * Reports audit results and decides on pass/fail status. + #. "Distributor" (external role) * use the platform in a safe way - * integrate the platform in his product (distribution) and safety case + * integrate the platform in his product (distribution) and safety pacakge * plan this integration (also in time) * qualify the SW platform as part of his product @@ -65,7 +69,7 @@ Safety Plans This SW platform project defines two levels of planning: platform and module. There will be one safety plan on platform level and several safety plans on module level (one for each module). This is how we organize our development teams and repositories. Each of these safety plan "creates" one SEooC. -The Platform Safety Plan exists only once and is part of the Platform Management Plan of S-CORE. +The Platform Safety Plan exists only once and is part of the Platform Management Plan. Safety Management Work Products ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -73,15 +77,15 @@ Safety Management Work Products Apart from the safety plans the main work products of safety management are: * :need:`Safety Manual ` - the safety manual defines the requirements for safe usage or integration of the SW platform (or its individual modules) -* :need:`Confirmation Reviews ` - on safety plan, safety package and safety analyses, according to ISO 26262 requirements -* :need:`Safety Package ` - the safety package does not contain the safety argumentation. By this the S-CORE project ensures it does not take over liability for the SW platform (or its individual modules). But it enables the distributors to integrate the SW platform (or its individual modules) in their safety package. +* :need:`Formal Document Review Reports ` - on safety plan, safety package and safety analyses, according to ISO 26262 requirements +* :need:`Safety Package ` - the safety package does not contain the safety argumentation. By this the project ensures it does not take over liability for the SW platform (or its individual modules). But it enables the distributors to integrate the SW platform (or its individual modules) in their safety package. Safety Management Tooling ^^^^^^^^^^^^^^^^^^^^^^^^^ -For the safety planning and safety manual, `sphinx-needs `_ will be used for referencing. +For the safety planning and safety manual a “Docs-as-Code” approach is used and within that approach Id will be used for referencing. -For the activities planning (who, when) we use `GitHub issues `_ and monitor these in GitHub projects. +For the activities planning (who, when) we use a task tracking stystem to create and manage issues, and monitor progress through a project managemnet dashboard. For the reporting (e.g. displaying the status of the work products) additional tooling is created. diff --git a/process/process_areas/safety_management/safety_management_getstrt.rst b/process/process_areas/safety_management/safety_management_getstrt.rst index bfd259df56..501ae2bd32 100644 --- a/process/process_areas/safety_management/safety_management_getstrt.rst +++ b/process/process_areas/safety_management/safety_management_getstrt.rst @@ -15,14 +15,23 @@ Getting started --------------- -.. doc_getstrt:: Safety Management Get Started +.. doc_getstrt:: Getting started on Safety Management :id: doc_getstrt__safety_management_process :status: valid +If you are appointed as a :need:`Safety Manager ` by the :need:`Project Lead ` in the project: -In case you are appointed as a :need:`Safety Manager ` by the :need:`rl__project_lead` in the S-CORE project: +* **Establish Planning and Reporting** + - Contact the :need:`Project Lead ` for your SEooC. + - Confirm that an Issue Tracking system is in place for planning and reporting. -* Contact the :need:`Technical Lead ` for your SEooC to establish planning and reporting (the TL should already have established a Github project for planning) -* Create your safety plan according to :need:`wf__cr_mt_safety_plan` -* Make familiar with your role description and the other workflows of safety management (see below) -* Make familiar with the development and supporting process descriptions in :ref:`process_description` plus the relevant sections of the :need:`wp__platform_mgmt` +* **Create Your Safety Plan** + - Follow the workflow described in :need:`wf__cr_mt_safety_plan`. + +* **Understand Your Role and Responsibilities** + - Review your role description in :doc:`/process_areas/safety_management/safety_management_roles`. + - Familiarize yourself with the Safety Management workflow in :doc:`/process_areas/safety_management/safety_management_workflow`. + +* **Explore Supporting Processes** + - Read the development and supporting process descriptions in :ref:`process_description`. + - Check relevant sections of :need:`wp__platform_mgmt`. diff --git a/process/process_areas/safety_management/safety_management_roles.rst b/process/process_areas/safety_management/safety_management_roles.rst index ff3db17f7e..a70b538c13 100644 --- a/process/process_areas/safety_management/safety_management_roles.rst +++ b/process/process_areas/safety_management/safety_management_roles.rst @@ -46,7 +46,7 @@ Roles * Creating the Safety Plan * Functional Safety related project status reporting - * Creation and Monitoring of completeness of the safety case + * Creation and Monitoring of completeness of the safety package * Reporting of safety anomalies * Verify, that the preconditions for the "release for production", which are part of the release notes, are fulfilled, and the correctness, completeness and consistency of the release notes * Coaching the project team w.r.t all questions related to functional safety @@ -71,12 +71,12 @@ Roles Required skills, Knowledge of standards, Experience * External Auditor comes from organization specialized in safety audits and assessment, thus sufficient skill should be guaranteed by the sending organization. - * For performing the confirmation reviews also a safety manager from another (S-CORE) project can play the role of an external auditor, in this case the same skills apply as for the safety manager. + * For performing the formal document reviews also a safety manager from another project can play the role of an external auditor, in this case the same skills apply as for the safety manager. Responsibility * Performing and reporting of safety audit - * Performing of confirmation reviews on safety plans, safety case and safety analysis (incl. DFA) + * Performing of formal document reviews on safety plans, safety pacakge and safety analysis (incl. DFA) Authority diff --git a/process/process_areas/safety_management/safety_management_workflow.rst b/process/process_areas/safety_management/safety_management_workflow.rst index bf39ff5251..0f56cb5653 100644 --- a/process/process_areas/safety_management/safety_management_workflow.rst +++ b/process/process_areas/safety_management/safety_management_workflow.rst @@ -51,7 +51,7 @@ Workflow Safety Management :contains: gd_guidl__saf_package, gd_temp__feature_safety_wp, gd_temp__module_safety_plan :has: doc_concept__safety_management_process, doc_getstrt__safety_management_process - | The Safety Manager in S-CORE is NOT responsible to provide the argument for the achievement of functional safety. + | The Safety Manager in the project is NOT responsible to provide the argument for the achievement of functional safety. | But the Safety Manager creates and maintains the safety package in the sense of a collection of safety related work products. | The generation and the maintainance of this draft safety package shall be automtated as much as possible. | It does not contain the final argumentation of the safety of the product. @@ -118,7 +118,7 @@ Workflow Safety Management :id: wf__impact_analysis_change_request :status: valid :responsible: rl__safety_manager - :approved_by: rl__technical_lead + :approved_by: rl__project_lead :input: wp__platform_mgmt, wp__issue_track_system, wp__sw_component_class, wp__tailoring :output: wp__issue_track_system :contains: gd_temp__change_component_request, gd_temp__change_decision_record, gd_temp__change_impact_analysis @@ -132,16 +132,3 @@ Workflow Safety Management | - Assessing the impact on affected elements, safety requirements, and work products | - Documenting the rationale for decisions regarding acceptance, implementation, or rejection of the change | The outcome is a change impact analysis report and a documented decision, which are reviewed and approved as part of the safety management process. - -.. workflow:: Create/Maintain Safety Case - :id: wf__cr_mt_safety_case - :status: valid - :responsible: rl__safety_manager - :approved_by: rl__project_lead - :input: wp__module_safety_package, wp__platform_safety_package - :output: wp__safety_case - :contains: gd_guidl__saf_case - :has: doc_concept__safety_management_process - - | The Safety Manager creates and maintains the safety case, compiling evidence from safety packages and other work products. - | The safety case provides the structured argument for functional safety compliance according to ISO 26262. diff --git a/process/process_areas/safety_management/safety_management_workproducts.rst b/process/process_areas/safety_management/safety_management_workproducts.rst index d2e89903eb..3c7c6dac95 100644 --- a/process/process_areas/safety_management/safety_management_workproducts.rst +++ b/process/process_areas/safety_management/safety_management_workproducts.rst @@ -146,19 +146,3 @@ Workproducts Safety Management for your project (documented in the PMP), to be able to demonstrate completeness as described in :need:`gd_guidl__saf_package`. It is not really a work product definition, but this is the best way to link to the tailored out standard work products. - -.. workproduct:: Safety Case - :id: wp__safety_case - :status: valid - :complies: std_wp__iso26262__management_654 - - The safety case provides the structured argument, supported by evidence, that functional safety has been achieved for the item or element, in accordance with the safety plan. - - The safety case: - * Compiles and references the relevant work products generated throughout the safety lifecycle to support the safety argument. - * Is developed progressively as work products become available, allowing for incremental release and assessment. - * In distributed developments, may combine the safety cases of customer and suppliers, referencing evidence from all parties and defining interfaces in a Development Interface Agreement (DIA). - * Supports safety planning by identifying intended safety arguments early, and supports progressive functional safety assessments as evidence accumulates. - - The safety case is a key deliverable to demonstrate compliance with ISO 26262 functional safety requirements. - The creation and maintenance of the safety case shall follow the process described in :need:`gd_guidl__saf_case`. diff --git a/process/standards/aspice_40/iic/iic-06.rst b/process/standards/aspice_40/iic/iic-06.rst index c581a4f6f7..b07119e4fc 100644 --- a/process/standards/aspice_40/iic/iic-06.rst +++ b/process/standards/aspice_40/iic/iic-06.rst @@ -58,7 +58,7 @@ - Description / confirmation of existing backup and recovery mechanisms - References to corresponding procedures or regulations - - -.. needextend:: "c.this_doc()" - :+tags: aspice40_iic06 + + +.. needextend:: "c.this_doc()" + :+tags: aspice40_iic06 From 84dd8175e9ba365be7ad1464be84072307d803a1 Mon Sep 17 00:00:00 2001 From: Kroehnd Date: Wed, 26 Nov 2025 11:06:31 +0100 Subject: [PATCH 7/7] Fixed review findings --- .DS_Store | Bin 8196 -> 8196 bytes .../safety_management_concept.rst | 13 ------------- .../safety_management_getstrt.rst | 8 ++++++++ .../safety_management_roles.rst | 6 +++++- .../safety_management_workproducts.rst | 4 ++-- 5 files changed, 15 insertions(+), 16 deletions(-) diff --git a/.DS_Store b/.DS_Store index 918c53298f8a00be6c808bcb348af8ce8d7db910..ff8bcb240832ec24f4aedd1bd75ba075a3dc1f8f 100644 GIT binary patch delta 21 ccmZp1XmQvuSAfIF*jz`!+{}FQQh|7W07}FLPyhe` delta 21 ccmZp1XmQvuSAfIR#6U;E!q8&#Qh|7W07{hxN&o-= diff --git a/process/process_areas/safety_management/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst index 05d59c4529..f0c1cfa779 100644 --- a/process/process_areas/safety_management/safety_management_concept.rst +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -56,14 +56,6 @@ Stakeholders * Verifies compliance with defined safety processes and standards. * Reports audit results and decides on pass/fail status. - -#. "Distributor" (external role) - - * use the platform in a safe way - * integrate the platform in his product (distribution) and safety pacakge - * plan this integration (also in time) - * qualify the SW platform as part of his product - Safety Plans ^^^^^^^^^^^^ @@ -88,8 +80,3 @@ For the safety planning and safety manual a “Docs-as-Code” approach is used For the activities planning (who, when) we use a task tracking stystem to create and manage issues, and monitor progress through a project managemnet dashboard. For the reporting (e.g. displaying the status of the work products) additional tooling is created. - -Guidance -^^^^^^^^ - -The safety management guideline can be found in the guidance section. diff --git a/process/process_areas/safety_management/safety_management_getstrt.rst b/process/process_areas/safety_management/safety_management_getstrt.rst index 501ae2bd32..60b8ab415e 100644 --- a/process/process_areas/safety_management/safety_management_getstrt.rst +++ b/process/process_areas/safety_management/safety_management_getstrt.rst @@ -35,3 +35,11 @@ If you are appointed as a :need:`Safety Manager ` by the :ne * **Explore Supporting Processes** - Read the development and supporting process descriptions in :ref:`process_description`. - Check relevant sections of :need:`wp__platform_mgmt`. + +* **This is a test** + - This is teste: :need:`rl__external_auditor:content` + +Show me: +.. needextract:: + :filter: id == 'rl__process_community' + :layout: clean diff --git a/process/process_areas/safety_management/safety_management_roles.rst b/process/process_areas/safety_management/safety_management_roles.rst index a70b538c13..80142e0293 100644 --- a/process/process_areas/safety_management/safety_management_roles.rst +++ b/process/process_areas/safety_management/safety_management_roles.rst @@ -22,6 +22,10 @@ Roles :contains: rl__committer The safety manager is responsible for making sure that ISO26262 is complied to in the project. He/She shall lead and monitor the safety relevant activities of the project. + This role is assigned through a transparent, meritocratic election process similar to committer elections. + Only existing committers are eligible. Nominations must include evidence of relevant contributions and safety expertise. + The election must be public, archived, and follow Eclipse Foundation principles of openness and neutrality. + The criteria for nomination and election must be documented and published on the project’s website. Required skills @@ -76,7 +80,7 @@ Roles Responsibility * Performing and reporting of safety audit - * Performing of formal document reviews on safety plans, safety pacakge and safety analysis (incl. DFA) + * Performing of formal document reviews on safety plans, safety package and safety analysis (incl. DFA) Authority diff --git a/process/process_areas/safety_management/safety_management_workproducts.rst b/process/process_areas/safety_management/safety_management_workproducts.rst index 3c7c6dac95..67fd81b884 100644 --- a/process/process_areas/safety_management/safety_management_workproducts.rst +++ b/process/process_areas/safety_management/safety_management_workproducts.rst @@ -12,8 +12,8 @@ # SPDX-License-Identifier: Apache-2.0 # ******************************************************************************* -Workproducts Safety Management ------------------------------- +Work Products Safety Management +------------------------------- .. workproduct:: Platform Safety Plan :id: wp__platform_safety_plan