Platform Safety Plan
|
status: draft
security:
safety: ASIL_B
|
||||
Safety management / Platform Safety Plan#
This document implements Platform Safety Plan (wp__platform_safety_plan).
Purpose#
The main purpose of the safety plan is to:
adhere to ISO 26262 where applicable for the project according to the defined tailoring
And:
to define and assign the roles and responsibilities regarding safety activities
to define the tailored safety activities, to provide the corresponding rationales for tailoring and to review the provided rationales
to plan the safety activities
to coordinate and track the progress of safety activities in accordance with the safety plan
to ensure a correct progression of the safety activities throughout the safety lifecycle
to plan to create a comprehensible safety case (collection of the safety related work products)
to judge whether the SW achieves functional safety process conformance (i.e. the functional safety audit, confirmation reviews)
Objectives and Scope#
Functional Safety Management Goals#
Adherence to the ISO 26262 according to the defined tailoring
in detail
to plan all functional safety related activities and work products
to monitor and facilitate all activities
to measure and report functional safety status based on well-defined metrics
Functional Safety Management Scope#
There is no deviation from the scope presented in the S-CORE project page . The platform and its components are developed, and integrated for an assumed technical system as Safety Element out of Context (SEooC). The development of the platform and its components follows the defined processes. Responsibilites for development, implementation, integration and verification are also defined int the processes.
Regarding the platform specifics:
the highest ASIL in the project is ASIL B
all safety activities from a procedural point of view are developed according to ASIL B
all safety related SW in the project is developed according to ISO 26262 ASIL B
The SW platform functionality consists of features, which are based on a set of requirements and are developed in parallel. These features are developed into SW components contained in “modules”, which are another set of SEooCs (initiated by a contribution request). A template exists to guide this: Module Safety Plan Template (gd_temp__module_safety_plan).
Tailoring#
Tailoring of safety activities:
The tailoring is divided into project wide and module specific rules.
Project wide tailoring is documented in this document - this is based on developement of a platform SEooC.
Module SEooC specific tailoring is documented in the module development Safety Plans - this may be based on SEooC specifics or because component qualification according to ISO 26262 part 8 clause 12 (or ISO PAS 8926) is selected.
In case of a change request on an existing feature (i.e. a contribution request), the subsequent safety planning will be done based on an impact analysis.
The following ISO 26262 defined safety work products are not relevant for the SCORE SW platform development:
Because these are in responsibility of the system integrator: management_11 (std_wp__iso26262__management_11), system_2 (std_wp__iso26262__system_2), system_3 (std_wp__iso26262__system_3), system_4 (std_wp__iso26262__system_4), system_5 (std_wp__iso26262__system_5), system_6 (std_wp__iso26262__system_6), system_7 (std_wp__iso26262__system_7), system_8 (std_wp__iso26262__system_8), system_9 (std_wp__iso26262__system_9), system_10 (std_wp__iso26262__system_10), system_11 (std_wp__iso26262__system_11)
Note that stakeholder requirements (system_1 (std_wp__iso26262__system_1)) are in scope of the project, to be able to cover System and HW related failures which are usually covered by SW (e.g. end to end protection for ECU external communication). But those are the “Assumed Technical Safety Requirements” of the SW platform SEooC and do not need to be tested by SEooC supplier. I.e. the system testing is out of scope. There will be HW/SW integration tests of feature requirements, as required by ISO 26262 part 6. These may be reused by the user on his HW platform also to cover his Technical Safety Requirements towards the SW platform. But this is the decision of the user.
Because there is no calibration used for the SCORE SW platform components, only configuration: software_19 (std_wp__iso26262__software_19), software_21 (std_wp__iso26262__software_21), software_24 (std_wp__iso26262__software_24)
Because distributed development is not how the project is organized. All contributors are seen as part of the project team. When used, OSS components are qualified and external SEooCs are integrated in the project scope: support_1 (std_wp__iso26262__support_1), support_2 (std_wp__iso26262__support_2), support_3 (std_wp__iso26262__support_3), support_4 (std_wp__iso26262__support_4), support_5 (std_wp__iso26262__support_5)
Because in the SCORE SW platform HW elements are out of scope: support_21 (std_wp__iso26262__support_21), support_22 (std_wp__iso26262__support_22), support_23 (std_wp__iso26262__support_23)
Because in the SCORE SW platform a proven in use argument will not be applied: support_24 (std_wp__iso26262__support_24), support_25 (std_wp__iso26262__support_25)
Because in the SCORE SW platform interfacing of out of scope of ISO 26262 applications is not planned: support_26 (std_wp__iso26262__support_26)
Because in the SCORE SW platform integration of safety-related systems not developed according to ISO 26262 is not planned: support_27 (std_wp__iso26262__support_27)
Because in the SCORE SW platform no ASIL decomposition is planned: analysis_1 (std_wp__iso26262__analysis_1), analysis_2 (std_wp__iso26262__analysis_2)
Because in the SCORE SW platform integration of safety-related systems not developed according to ISO 26262 is not planned: support_27 (std_wp__iso26262__support_27)
Because in the SCORE SW platform no ASIL decomposition is planned: analysis_1 (std_wp__iso26262__analysis_1), analysis_2 (std_wp__iso26262__analysis_2)
Approach#
Safety Culture#
The safety of the project S-CORE is inherent. It relies on the personal dedication and integrity of every person who is involved in the project. The safety thinking in the project allows a questioning attitude and fosters the taking of responsibility. Every participation, e.g. with the raise up of an improvement or by asking questions in the discussion section of GitHub is welcomed. The processes, guidelines and templates define the organizational framework. Adherence is verified by automated checks and manual inspections. All the aspects of ISO 26262 are directly implemented in the development process to ensure a proper communication and high understanding of functional safety. With continuous improvements, an integral aspect in all processes, we want to achieve excellence.
Functional Safety Management Organization#
It is the project strategy to qualify the platform or components of the platform to the appropriate international standards and directives. Therefore the project approach to facilitate a common culture regarding safety and security is part of our documentation. The project will be under the Eclipse Foundation and so the Eclipse Foundation Project Handbook: applies.
Eclipse Roles
Contributors can be everyone and we will not discourage the open source community from this. As the contributor cannot merge code (or any other work product) into the project’s codebase, the safety development competence of the contributor is irrelevant.
Committers play the main development role in the project, as only these are allowed to merge, so they are the ultimate responsibles for the project’s repository content.
The Eclipse Project Lead(s) has the ISO 26262 project manager role.
Project Roles
Roles are defined in every process and in a generic roles section. All those are matched to Eclipse roles. Project role assignment is done in every feature development Safety Plan.
Critical dependencies
The project has not implemented a quality management system yet. But it aims to be conform to ASPICE, as defined in the management system. Continuous improvement is part to all processes. Improvements are handled in the scope of Quality Management.
Risk
Organization and management system has not a mature level yet.
Skills
The main safety related project roles are the project manager and the safety manager and these also have to have the (Eclipse) committer role. As defined in Committer Training the committers are elected in a meritrocatic manner, meaning those have to show their skills and understanding of the project processes in several previous pull requests.
As each project can adopt additional criteria for the committers election, we define the following:
each committer has to prove his knowledge in functional safety SW development by
an absolved training in ISO 26262 (or equivalent standard, at least 16h of SW development specific training by a trusted training provider) OR
by attending the projects’s ISO 26262 SW development training (given by a safety team member)
Additionally the project repository is organized in “CODEOWNER” sections. These “CODEOWNERS” need to approve any pull request modifying a file in their area before it is merged.
In case of safety related “CODEOWNER” sections (e.g. a file containing feature requirements with an ASIL level) the persons having “CODEOWNER” rights need to have: * One year of professional practice of safety related SW development (or management) relevant for the section content
The successful checking of committers and CODEOWNERS skills is ensured by the safety manager and documented in the role assignment document. One important aspect to this is, that we ensure the identity of the committer by applying the GitHub digital signature mechanism.
Functional Safety Ressources#
A dedicated safety manager is elected by Project Lead (rl__project_lead) for all the S-CORE SEooCs development.
The safety manager, supported by the project manager (i.e. the Technical Lead (rl__technical_lead)), will ensure that safety activities are actively planned, developed, analyzed, verified and tested and managed throughout the life cycle of the project. As all the implementation of safety functions takes place within module development, there is a safety manager appointed in the module’s safety plan.
Resources and milestones are planned in Github Issues for all activities. There are issue templates for sagas (covering one feature development) and for epics (covering one development work product each). Resource and milestone planning is done as defined in the Project management plan
Tools
The whole development and thus all work products are located in Github. The development is automated as much as possible and follows the defined processes. Github issues are used as planning tool. The issue types and issue types workflows are described in the platform management plan. For safety relevant issues types a “safety” label is used.
Functional Safety Management Communication#
To exchange general information and to clarify general topics the following communication channels are used:
Regular (online) meetings, at least every two months.
E-Mails
Messager Services e.g., Slack, Microsoft Teams, Github Notifications
Ad hoc safety related meetings are set up for clarification topics.
Reporting
The safety management status is reported due the meeting defined in the platform management plan. The status report includes at least the defined Quality Criteria defined below in chapter TODO, LINK TO TEMPLATE
Escalation
Safety Manager (rl__safety_manager) to Technical Lead (rl__technical_lead)
Technical Lead (rl__technical_lead) to Project Lead (rl__project_lead)
Examples for valid escalation causes are:
Safety issues cannot be resolved on module level or with the available resources.
There are conflicting points-of-view between the project manager and the safety manager
Functional Safety Management Life Cycle#
The safety lifecycle of the S-CORE project is initiated at the project set-up and driven and maintained by the safety manager supported by the Process Community Member (rl__process_community). Note that the Eclipse Foundation also defines project phases. Eclipse definition is more about the process maturity for the whole project, if we are in Mature Phase, we latest will have the project lifecycle as defined in our process description. Nevertheless, Safety Development and even Safety Case release is independent from Mature and Incubation Phase as the completeness and appropriateness of the platform process and artefacts is determined by Safety Audit and not be Eclipse project reviews.
Functional Safety Requirements#
Requirement Engineering is defined in the process description. See Requirements Engineering
The application of ISO 26262 standards requirements is realized by defining process guidances and matching those to the ISO 26262 requirements (see Introduction).
Functional Safety Schedule#
The schedule is defined in section “Platform Safety Plan” below, but also within each module safety plan. See linked issues below and in Module Safety Plan Template (gd_temp__module_safety_plan).
Functional Safety Development#
The SW development is defined in the project-wide software development plan. See Software Development
Functional Safety Verification#
The platform management plan defines the Software Verification
Functional Safety Tool Management#
The platform management plan defines Tool Management
Functional Safety Work Products#
The work products relevant for a module development is defined within each module safety management plan. See Module Safety Plan Template (gd_temp__module_safety_plan). Generic project wide work products are defined below.
Functional Safety Quality Criteria#
The platform management plan defines Quality management
Platform Safety Plan#
Functional Safety Management SW Platform Work Products#
work product Id |
Link to process |
Process status |
Link to issue |
Link to WP |
WP status |
|---|---|---|---|---|---|
n/a (comes from outside the project) |
n/a |
n/a |
RELEASED |
||
n/a |
n/a |
n/a |
not open sourced |
to be shown to assessor |
|
Create/Maintain Platform Ma... (wf__cr_mt_platform_mngmt_plan) |
draft |
<Link to issue> |
?? |
||
?? |
n/a |
established |
|||
Create/Maintain Platform Ma... (wf__cr_mt_platform_mngmt_plan) |
draft |
<Link to issue> |
?? |
||
?? |
<automated> |
||||
?? |
<Link to issue> |
<Link to WP> |
<automated> |
||
?? |
<automated> |
||||
valid |
this document |
see above |
|||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
Confirmation Review Reports (wp__cmr_reports) (platform Safety Plan) |
valid |
<Link to issue> |
<Link to WP> |
<automated> |
|
Confirmation Review Reports (wp__cmr_reports) (platform Safety Case) |
valid |
<Link to issue> |
<Link to WP> |
<automated> |
|
Confirmation Review Reports (wp__cmr_reports) (feature’s Safety Analyses & DFA) |
Safety Analysis CMR tbd |
<automated> |
<Link to issue> |
<Link to WP> |
<automated> |
performed by external experts |
n/a |
<Link to issue> |
<Link to WP> |
<WP status (manual)> |
|
?? |
<Link to issue> |
<Link to WP> |
<automated> |
||
?? |
<Link to issue> |
<Link to WP> |
<automated> |
||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
?? |
<Link to issue> |
<Link to WP> |
<automated> |
||
Platform Verification Report (wp__platform_sw_verification_report) |
?? |
<Link to issue> |
<Link to WP> |
<automated> |
|
valid |
n/a (done already) |
See below status charts |
|||
valid |
<Link to issue> |
See below status charts |
|||
Create/Maintain Platform Ma... (wf__cr_mt_platform_mngmt_plan) |
draft |
<Link to issue> |
?? |
||
Create/Maintain Platform Ma... (wf__cr_mt_platform_mngmt_plan) |
draft |
<Link to issue> |
?? |
||
?? |
<Link to issue> |
<Link to WP> |
<automated> |
||
Tailoring Documents (wp__tailoring) (generic) |
valid |
ISO 26262 & Platform Safety Plan (doc__platform_safety_plan) |
valid |
Functional Safety Management Feature Specific Work Products#
See feature tree documents (created by using gd_temp__feature_safety_wp):
<link to document for every feature>
Functional Safety Work Products Status Charts#
Error
Matplotlib missing for needpie plot 'Stakeholder Requirements\nvalid, invalid'
Error
Matplotlib missing for needpie plot 'Toolchain Requirements\nvalid, invalid'
Title |
ID |
Status |
Complies |
|---|---|---|---|
Platform Safety Plan |
draft |