Persistency Safety Plan Formal Review Report

Persistency Safety Plan Formal Review		status: draft security: NO safety: ASIL_B
tags: persistency version: 2 realizes: wp__fdr_reports
doc__persistency_safety_plan_fdr		Generic Document

Purpose

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

Conduct As described in wf__p_formal_rv, the formal document review is performed by an “external” safety manager:

• reviewer: Alexander Schemmel (aschemmel-tech)

• scope: the module safety plan Persistency Safety Plan (doc__persistency_safety_plan) (version 2) including the feature safety work products list Persistency Safety WPs (doc__persistency_safety_wp) and the skill check Persistency Codeowners (doc__persistency_codeowners)

Checklist

See also doc_concept__wp_inspections for further information about reviews in general and inspection in particular.

Table 9 Safety Plan Checklist

Id	Safety plan activity	Compliant to ISO 26262?	Reference	Comment
1	Is the rationale for the safety work products tailoring included?	N/A	std_req__iso26262__management_6452	This is the first formal release of the module, so no impact analysis of re-used SW is needed. For following releases the component and feature modification requests affecting the SW release will be linked here (safety planning based on impact analysis as defined in the tailoring of the wp__platform_safety_plan).
2	Is impact analysis planned in case of re-use of SW (needed for every release following the first formal release)?	YES	std_req__iso26262__management_6452	The module safety plan adds to the wp__platform_safety_plan, whose tailoring defines that the safety planning for a change request on an existing feature is done based on an impact analysis. The module safety plan does not repeat this.
3	Does the safety plan define all needed activities for safety management (incl. formal document review and Safety Audit)?	YES	std_req__iso26262__management_6465 std_req__iso26262__management_6491 std_req__iso26262__management_64111	Planned are the formal document reviews (wp__fdr_reports) of the module safety plan, the module safety package and the module’s safety analyses and DFA. The safety audit (wp__audit_report) is planned on platform level in the wp__platform_safety_plan (performed by external experts); the module safety plan refers to the next S-CORE safety audit.
4	Does the safety plan define all needed activities for System and SW development, integration and verification?	NO	std_req__iso26262__management_6465	Component KVS: requirements, AoU, requirements inspection, architecture, architecture inspection, implementation, unit test, implementation inspection and component integration test are planned. Feature Persistency (Persistency Safety WPs (doc__persistency_safety_wp)): feature request, requirements, AoU, architecture, FMEA, DFA and the inspections are planned. Module: safety manual, user manual (wp__module_user_manual), module verification report and release note are planned. Finding: wp__verification_feat_int_test has no link to a work product (“<WP Link>”).
5	Does the safety plan define all needed activities for safety analysis and DFA?	YES	std_req__iso26262__management_6465	Planned are the feature FMEA and DFA (Persistency Safety WPs (doc__persistency_safety_wp)), the component FMEA and DFA and their formal document review (wp__fdr_reports).
6	Does the safety plan define all needed activities for supporting processes (incl. tool mgt)?	YES	std_req__iso26262__management_6465	The supporting processes (configuration, change, documentation, problem resolution and tool management) are planned on platform level in the wp__platform_safety_plan. The module uses the platform tools (Bazel, docs-as-code, GitHub) and adds no module specific tools.
7	Does the safety plan document a responsible for all activities?	YES	std_req__iso26262__management_6463	Safety Manager and Module Project Manager are named in the module roles. For each work product the Persistency Safety Plan (doc__persistency_safety_plan) states the link to the process (column “Link to process”), which defines the responsible role. The role holders are the CODEOWNERS, whose skills are checked in Persistency Codeowners (doc__persistency_codeowners).
8	If OSS software components is used, is it planned to be qualified?	NO	std_req__iso26262__management_6455	The Rust implementation uses the OSS crates tinyjson and adler32. Their classification (wp__sw_component_class) and qualification plan are open and documented as deviation in Deviations from Module Safety Plan. Replacement of adler32 is discussed in #413.
9	Is a safety manager and a project manager appointed for the project?	YES	std_req__iso26262__management_6461 std_req__iso26262__management_6462	Safety Manager: Volker Häussler, Module Project Manager (= Feature team lead): Uwe Maucher.
10	Is safety plan sufficiently linked to the project plan?	YES	std_req__iso26262__management_6464	The module safety plan links to the Persistency Feature Team Planning.
11	Is safety plan updated iteratively to show the progress?	YES	std_req__iso26262__management_6468	The safety plan is in version 2 and maintained via pull requests (history in the repository); the work product tables show the process status, the linked documents show the work product status.