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

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion MODULE.bazel
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ bazel_dep(name = "rules_pkg", version = "1.1.0")
# Python version
#
###############################################################################
bazel_dep(name = "rules_python", version = "1.4.1")
bazel_dep(name = "rules_python", version = "1.8.3")

PYTHON_VERSION = "3.12"

Expand Down
25 changes: 25 additions & 0 deletions process/folder_templates/platform/docs/safety_mgt/index.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
..
# *******************************************************************************
# Copyright (c) 2026 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
# *******************************************************************************

Safety Management
Copy link
Contributor

Choose a reason for hiding this comment

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

if you introduce here a new folder, why not move also Safety Planning here Platform DFA, etc. align with Security, that we can have there also a subfolder, Verification Report can stay on top level as well Stakeholder Requirements

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I aligned with Module Directories

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please move the safety Plan template also in this folder?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes please (and delete the old folder "safety_planning")

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmhmhm... Platform safety plan template was embedded in the "index.rst" of the specific directory, something I needed some time to sort out. I removed directory there and created a new file here with the right name

#################

.. toctree::
:titlesonly:

platform_dfa
platform_safety_plan_fdr
platform_safety_package_fdr
platform_safety_analysis_fdr
platform_safety_plan
Copy link
Contributor

Choose a reason for hiding this comment

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

Please add here an index as for Safety_Mgt, otherwise it ins not in a subfolder and nove here also Safety Analysis Checklist

Copy link
Contributor

Choose a reason for hiding this comment

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

should also be in the "docs" folder like the others

Original file line number Diff line number Diff line change
Expand Up @@ -29,13 +29,6 @@ Platform DFA (Dependent Failure Analysis)

.. note:: Use the content of the document to describe e.g. why a fault model is not applicable for the diagram.

.. attention::
The above directive must be updated according to your Feature.

- Modify ``Your Feature Name`` to be your Feature Name
- Modify ``id`` to be your Feature Name in upper snake case preceded by ``doc__`` and succeeded by ``_dfa``
- Adjust ``status`` to be ``valid``
- Adjust ``safety`` and ``tags`` according to your needs

Dependent Failure Initiators
----------------------------
Expand All @@ -44,10 +37,10 @@ Dependent Failure Initiators

.. plat_saf_dfa:: <Title>
:violates: <Feature architecture>
:id: plat_saf_DFA__<Feature>__<Element descriptor>
:id: plat_saf_DFA__Platform__<Element descriptor>
:failure_id: <ID from DFA failure initiators :need:`gd_guidl__dfa_failure_initiators`>
:failure_effect: "description of failure effect of the failure initiator on the element"
:mitigated_by: <ID from Feature Requirement | ID from AoU Feature Requirement>
:mitigated_by: <ID from Stakeholder Requirement | ID from AoU Feature Requirement>
:mitigation_issue: <ID from Issue Tracker>
:sufficient: <yes|no>
:status: <valid|invalid>
Expand Down
Original file line number Diff line number Diff line change
@@ -1,99 +1,92 @@
..
# *******************************************************************************
# 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
# *******************************************************************************


Safety Analysis Checklist
=========================

.. document:: [Your Platform Name] Safety Analysis Checklist
:id: doc__platform_name_safety_analysis_fdr
:status: draft
:safety: ASIL_B
:security: YES
:realizes: wp__fdr_reports
:tags: template

.. attention::
The above directive must be updated according to your Platform.

- Modify ``Your Platform Name`` to be your Platform Name
- Modify ``id`` to be your Platform Name in lower snake case preceded by ``doc__`` and followed by ``_safety _analysis_fdr``
- Adjust ``status`` to be ``valid``
- Adjust ``safety``, ``security`` and ``tags`` according to your needs


**Purpose**
The purpose of this Safety Analysis (DFA and FMEA) checklist template is to collect the topics to be checked during verification of the Safety Analysis.

**Conduct**
As described in :need:`wf__p_formal_rv`, the formal document review is performed by an "external" safety manager:

- reviewer: <committer with safety manager skills explicitly named here>

**Checklist**

Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional to add in the remarks why it is passed or not passed. In case of "no" an issue link to the issue tracking system has to be added in the last column. See also :ref:`review_concept` for further information about reviews in general and inspection in particular.

.. list-table:: Safety Analysis Checklist
:header-rows: 1
:widths: 10,30,30,15,8,8

* - Review ID
- Acceptance Criteria
- Guidance
- Passed
- Remarks
- Issue link
* - REQ_01_01
- Is / are the attribute sufficient set correctly?
- The mitigations shall have a direct influence ont the violation by prevention, detection or mitigation to reduce the risk to an acceptable level.
- The mitigations are sufficient.
- <yes|no>
-
* - REQ_01_02
- Are the templates for DFA and/or FMEA used?
- See :ref:`dfa_templates` / :ref:`FMEA_templates` and also :ref:`process_requirements_safety_analysis`
- Templates are used to generate the DFA or / and FMEA.
- <yes|no>
-
* - REQ_01_03
- Were the failure initiators / fault models applied?
- See :need:`gd_guidl__dfa_failure_initiators` / :need:`gd_guidl__fault_models`
- The applicable items of the failure initiators / fault models are used to ensure a structured analysis. For all not applicable items an argument shall be given in the content of the document.
- <yes|no>
-
* - REQ_01_04
- Are the failure effects clearly and completely described?
- Use the generic failure effect descriptions and enlarge the description if it's applicable to the considered element.
- The effects of the failure is described completely. The effect can be recognized easily.
- <yes|no>
-
* - REQ_01_06
- Is the attribute "mitigated by" linked correct?
- Check if the correct failure effect is linked via "mitigated by".
- The "mitigated by" link is correct.
- <yes|no>
-
* - REQ_01_07
- Is the sufficiency of the "mitigated by" (prevention, detection or mitigation) described or can it be recognized easily?
- The sufficiency of the "mitigated by" is described in the content of the document. It can be recognized easily.
- The "mitigated by" shows clearly that a fault / failure can be mitigated by the linked requirement by prevention, detection or mitigation. It shall be described in the contend.
- <yes|no>
-
* - REQ_01_08
- Is the overall result of the Safety Analysis described in the report?
- It shall be shown in the report if the Safety Analysis are finished and if all artifacts are "valid" and "sufficient".
- The results of the Safety Analysis are described in the report. The report is available :need:`wp__verification_platform_ver_report`.
- <yes|no>
-
..
# *******************************************************************************
# Copyright (c) 2026 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
# *******************************************************************************


Platform Safety Analysis Checklist
==================================

.. document:: Platform Safety Analysis Checklist
:id: doc__platform_safety_analysis_fdr
:status: draft
:safety: ASIL_B
:security: YES
:realizes: wp__fdr_reports
:tags: template



**Purpose**
The purpose of this Safety Analysis (DFA and FMEA) checklist template is to collect the topics to be checked during verification of the Platform Safety Analysis.

**Conduct**
As described in :need:`wf__p_formal_rv`, the formal document review is performed by an "external" safety manager:

- reviewer: <committer with safety manager skills explicitly named here>

**Checklist**

Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional to add in the remarks why it is passed or not passed. In case of "no" an issue link to the issue tracking system has to be added in the last column. See also :ref:`review_concept` for further information about reviews in general and inspection in particular.

.. list-table:: Safety Analysis Checklist
:header-rows: 1
:widths: 10,30,30,15,8,8

* - Review ID
- Acceptance Criteria
- Guidance
- Passed
- Remarks
- Issue link
* - REQ_01_01
- Is / are the attribute sufficient set correctly?
- The mitigations shall have a direct influence ont the violation by prevention, detection or mitigation to reduce the risk to an acceptable level.
- The mitigations are sufficient.
- <yes|no>
-
* - REQ_01_02
- Are the templates for DFA and/or FMEA used?
- See :ref:`dfa_templates` / :ref:`FMEA_templates` and also :ref:`process_requirements_safety_analysis`
- Templates are used to generate the DFA or / and FMEA.
- <yes|no>
-
* - REQ_01_03
- Were the failure initiators / fault models applied?
- See :need:`gd_guidl__dfa_failure_initiators` / :need:`gd_guidl__fault_models`
- The applicable items of the failure initiators / fault models are used to ensure a structured analysis. For all not applicable items an argument shall be given in the content of the document.
- <yes|no>
-
* - REQ_01_04
- Are the failure effects clearly and completely described?
- Use the generic failure effect descriptions and enlarge the description if it's applicable to the considered element.
- The effects of the failure is described completely. The effect can be recognized easily.
- <yes|no>
-
* - REQ_01_06
- Is the attribute "mitigated by" linked correct?
- Check if the correct failure effect is linked via "mitigated by".
- The "mitigated by" link is correct.
- <yes|no>
-
* - REQ_01_07
- Is the sufficiency of the "mitigated by" (prevention, detection or mitigation) described or can it be recognized easily?
- The sufficiency of the "mitigated by" is described in the content of the document. It can be recognized easily.
- The "mitigated by" shows clearly that a fault / failure can be mitigated by the linked requirement by prevention, detection or mitigation. It shall be described in the contend.
- <yes|no>
-
* - REQ_01_08
- Is the overall result of the Safety Analysis described in the report?
- It shall be shown in the report if the Safety Analysis are finished and if all artifacts are "valid" and "sufficient".
- The results of the Safety Analysis are described in the report. The report is available :need:`wp__verification_platform_ver_report`.
- <yes|no>
-
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
..
# *******************************************************************************
# 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
# *******************************************************************************

Platform Safety Package Formal Review Report
============================================

.. note:: Document header

.. document:: Platform Safety Package Formal Review
:id: doc__platform_safety_package_fdr
:status: draft
:safety: ASIL_B
:security: NO
:realizes: wp__fdr_reports
:tags: template


**Purpose**

The purpose of this review checklist is to report status of the formal review for the platform safety package.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

**Conduct**
As described in :need:`wf__p_formal_rv`, the formal document review is performed by an "external" safety manager:

- reviewer: <committer with safety manager skills explicitly named here>

**Checklist**

.. list-table:: Safety Package Checklist
:header-rows: 1

* - Id
- Safety package activity
- Compliant to ISO 26262?
- Comment

* - 1
- Is a safety package provided which matches the safety plan (i.e. all planned work products referenced)?
- [YES | NO ]
- <Rationale for result>

* - 2
- Is the argument how functional safety is achieved, provided in the safety package, plausible and sufficient?
- NO
- The argument is intentionally not provided by the project.

* - 3
- Are the referenced work products available?
- [YES | NO ]
- <Rationale for result>

* - 4
- Are the referenced work products in released state, including the process safety audit?
- [YES | NO ]
- <Rationale for result>

* - 5
- If safety related deviations from the process or safety concept are documented, are these argued understandably?
- [YES | NO ]
- <Rationale for result>
Loading
Loading