diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000..ff8bcb2408 Binary files /dev/null and b/.DS_Store differ 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/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..f242a98cb1 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 :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 b2ffc089d4..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 + :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/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..61ae691083 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,118 @@ 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 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. + | + | 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. + | 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` + | 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 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 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. + | 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/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/safety_management_concept.rst b/process/process_areas/safety_management/safety_management_concept.rst new file mode 100644 index 0000000000..f0c1cfa779 --- /dev/null +++ b/process/process_areas/safety_management/safety_management_concept.rst @@ -0,0 +1,82 @@ +.. + # ******************************************************************************* + # 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 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 +^^^^^^ + +#. 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 + +#. :need:`Safety Manager ` + + * 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 ` + + * 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. + +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. + +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:`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 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 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 new file mode 100644 index 0000000000..60b8ab415e --- /dev/null +++ b/process/process_areas/safety_management/safety_management_getstrt.rst @@ -0,0 +1,45 @@ +.. + # ******************************************************************************* + # 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:: 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: + +* **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. + +* **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`. + +* **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/roles.rst b/process/process_areas/safety_management/safety_management_roles.rst similarity index 78% rename from process/process_areas/safety_management/roles.rst rename to process/process_areas/safety_management/safety_management_roles.rst index e8473d073c..80142e0293 100644 --- a/process/process_areas/safety_management/roles.rst +++ b/process/process_areas/safety_management/safety_management_roles.rst @@ -15,12 +15,17 @@ 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. + 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 @@ -45,7 +50,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 @@ -70,12 +75,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 package and safety analysis (incl. DFA) Authority diff --git a/process/process_areas/safety_management/workflows.rst b/process/process_areas/safety_management/safety_management_workflow.rst similarity index 78% rename from process/process_areas/safety_management/workflows.rst rename to process/process_areas/safety_management/safety_management_workflow.rst index df7447c0ad..0f56cb5653 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 @@ -51,7 +51,7 @@ Workflows :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. @@ -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__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 + :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..67fd81b884 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 -------------- +Work Products Safety Management +------------------------------- .. workproduct:: Platform Safety Plan :id: wp__platform_safety_plan 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