Safety Plan#

Note

Document header

[Your Module Name] Safety Plan
status: draft
security: NO
safety: ASIL_B
tags: template

Attention

The above directive must be updated according to your Module.

  • Modify Your Module Name to be your Module Name

  • Modify id to be your Module Name in upper snake case preceded by doc_ and succeeded by safety_plan

  • Adjust status to be valid

  • Adjust safety and tags according to your needs

note:

The module safety plan shall be continuously maintained during the project. Deviations to the module safety plan should be documented here

Functional Safety Management Context#

This Safety Plan adds to the project’s wp__platform_safety_plan all the module development relevant work products needed for ISO 26262 conformity.

Functional Safety Management Scope#

This Safety Plan’s scope is a SW module of the SW platform <link to module documentation in platform/modules/<modulename>/index.rst>. The module consists of one or more SW components and will be qualified as a SEooC.

Functional Safety Management Roles#

Table 9 Module roles#

Role

Assignee

Safety Manager

<link to Module’s Safety Manager assignment or name>

Module Project Manager

<link to Module’s Project Manager assignment or name>

Tailoring#

Additional to the tailoring in the SW platform project as defined in the project’s wp__platform_safety_plan we define here the additional tailoring on module level.

  • Excluded for this module are additionally the following work products (and their related requirements):

    • <work product/requirement> - <Argumentation why it is not needed or replaced by another work product or activity.>

Functional Safety Module Work products#

One set of work products for the module and one set for each component of the module:

Module Work products List#

Component <name> Work products List#

Table 11 Component <name> Work products#

Work product Id

Link to process

Process status

Link to WP

wp__requirements_comp

gd_temp__req_comp_req

valid

[Your Component Name] Requi... (doc__mod_temp_component_name_requirements)

wp__requirements_comp_aou

gd_temp__req_aou_req

valid

[Your Component Name] Requi... (doc__mod_temp_component_name_requirements)

wp__requirements_inspect

gd_chklst__req_inspection

valid

[Your Component Name] Requi... (doc__mod_temp_component_name_req_inspection)

wp__component_arch

gd_temp__arch_comp

valid

[Your Component Name] Archi... (doc__mod_temp_component_name_architecture)

wp__sw_arch_verification

gd_chklst__arch_inspection_checklist

valid

[Your Component Name] Archi... (doc__mod_temp_component_name_arc_inspection)

wp__sw_component_fmea

gd_temp__comp_saf_fmea

valid

[Your Component Name] FMEA (doc__mod_temp_component_name_fmea)

wp__sw_component_dfa

gd_temp__comp_saf_dfa

valid

[Your Component Name] DFA (doc__mod_temp_component_name_dfa)

wp__sw_implementation

gd_guidl__implementation

valid

[Your Component Name] Detai... (doc__mod_temp_component_name_detailed_design) & <Link to code>

wp__verification_sw_unit_test

gd_guidl__verification_guide

valid

<Link to WP>

wp__sw_implementation_inspection

gd_chklst__impl_inspection_checklist

valid

[Your Component Name] Imple... (doc__mod_temp_component_name_impl_inspection)

wp__verification_comp_int_test

gd_guidl__verification_guide

valid

<Link to WP>

wp__sw_component_class

gd_guidl__component_classification

valid

[Your Component Name] Compo... (doc__mod_temp_component_name_comp_class)

Note: In case the component is a new development, wp__sw_component_class shall be removed from the above list (and also from the folders). In case an OSS element is used in the module, part 6 has to be filled out.

OSS (sub-)component qualification plan#

For the selected OSS component the following work products will be implemented (and why):

If the OSS element is classified as
  • component, then the below table shall match the above, adding the reasoning for tailoring of work products according to the OSS component classification.

  • lower level component, then no work products additional to the component’s will be planned and activities below are part of the component’s issues.

Table 12 OSS (sub-)component <name> Work products#

Work product Id

Link to process

Reasoning for tailoring

wp__requirements_comp

gd_temp__req_comp_req

Always needed (for Q and QR classification) and also improves process Id 2

wp__requirements_comp_aou

gd_temp__req_aou_req

Always needed (for Q and QR classification) and also improves process Id 5

wp__requirements_inspect

gd_chklst__req_inspection

<Reasoning for tailoring>

wf__cr_mt_comparch

gd_temp__arch_comp

<Reasoning for tailoring, needed for example in case of deficits in process Id 3&4 and complexity Ids 1&4>

wp__sw_component_fmea

gd_temp__comp_saf_fmea

<Reasoning for tailoring, could help arguing too high cyclomatic complexity covered by safety mechanisms>

wp__sw_arch_verification

gd_chklst__arch_inspection_checklist

<Reasoning for tailoring, needed if also wf__cr_mt_comparch is required>

wp__sw_implementation

n/a

Tailored - If source code is modified, this is not a OSS qualification any more.

wp__verification_sw_unit_test

gd_guidl__verification_guide

<Reasoning for tailoring, can improve deficits in process Id 6 and complexity Id 3>

wp__sw_implementation_inspection

gd_chklst__impl_inspection_checklist

<Reasoning for tailoring, can improve deficits in process Id 6 and complexity Id 2>

wp__verification_comp_int_test

gd_guidl__verification_guide

Always needed (for Q and QR classification)

wp__sw_component_class

gd_guidl__component_classification

Always needed as basis for tailoring.

Module Safety Package#

To create the safety package (according to gd_guidl__saf_package) the following documents and work products status have to go to “valid” (after the relevant verification were performed).

Module Documents Status#

For all the work product documents the status can be seen by following the “Link to WP”. A summary of the status is also documented in the project’s documentation management plan.

See <add here the section reference to the documentation management plan>

Component Documents Status#

For all the work product documents the status can be seen by following the “Link to WP”. A summary of the status is also documented in the project’s documentation management plan.

See <add here the section reference to the documentation management plan>

Component Requirements Status#

No needs passed the filters

Component AoU Status#

No needs passed the filters

Component Architecture Status#

No needs passed the filters

Deviations from Module Safety Plan#

The following deviations from the module safety plan are present in the module safety package. These are deviations from planned processes execution and/or workproduct results, safety anomalies in the sense of known bugs in the software are reported in the release notes.

<Describe here the deviations, whether they have an impact on module’s safety functions, how these can be mitigated or argued and if and when a resolution is planned.>