Platform Safety Plan
|
status: draft
security: NO
safety: ASIL_B
|
||||
Safety management / 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. Responsibilities 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 change request). A template exists to guide this: 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 development 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 change 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 S-CORE SW platform development:
Because these are in responsibility of the system integrator: std_wp__iso26262__management_751, std_wp__iso26262__system_652, std_wp__iso26262__system_653, std_wp__iso26262__system_654, std_wp__iso26262__system_655, std_wp__iso26262__system_656, std_wp__iso26262__system_657, std_wp__iso26262__system_751, std_wp__iso26262__system_752, std_wp__iso26262__system_851, std_wp__iso26262__system_852
Note that stakeholder requirements (std_wp__iso26262__system_651) are in scope of the project, to be able to address System and HW related failures which are typically mitigated by SW (e.g. end-to-end protection for ECU external communication). However, these are considered “Assumed Technical Safety Requirements” of the SW platform SEooC and do not require testing by the SEooC supplier. Thus, system-level testing is out of scope. S-CORE will implement platform tests of stakeholder requirements for demonstration purposes, but these are not intended to provide complete coverage of the stakeholder requirements. There will be SW integration tests of feature requirements as specified in ISO 26262 part 6-10. These tests may be reused by users on their HW platform to address Technical Safety Requirements for the SW platform. Whether these are sufficient to cover the TSRs must be analyzed and decided by the user. 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. Note that S-CORE will implement Platform Integration Test of stakeholder requirements for demonstration, but these are not intended to be completely covering the stakeholder requirements. There will be SW integration tests of feature requirements, as required by ISO 26262 part 6-10. These may be reused by the users on their HW platform to cover Technical Safety Requirements towards the SW platform. But if these are sufficiently also covering the TSRs must be analyzed and decided by the user.
Also tailored out is the SW testing on the target, as the S-CORE project can only test on reference HW (part of SW integration testing). So these are not relevant: std_wp__iso26262__software_1151, std_wp__iso26262__software_1152
Because there is no calibration used for the S-CORE SW platform components, only configuration: std_wp__iso26262__software_app_c_52, std_wp__iso26262__software_app_c_54, std_wp__iso26262__software_app_c_57
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: std_wp__iso26262__support_551, std_wp__iso26262__support_552, std_wp__iso26262__support_553, std_wp__iso26262__support_554, std_wp__iso26262__support_555
Because in the S-CORE SW platform HW elements are out of scope: std_wp__iso26262__support_1351, std_wp__iso26262__support_1352, std_wp__iso26262__support_1353
Because in the S-CORE SW platform a proven in use argument will not be applied: std_wp__iso26262__support_1451, std_wp__iso26262__support_1452
Because in the S-CORE SW platform interfacing of out of scope of ISO 26262 applications is not planned: std_wp__iso26262__support_1551
Because in the S-CORE SW platform integration of safety-related systems not developed according to ISO 26262 is not planned: std_wp__iso26262__support_1651
Because in the S-CORE SW platform no ASIL decomposition is planned: std_wp__iso26262__analysis_551, std_wp__iso26262__analysis_552
Because HSI is coming from HW (and systems) engineering which are not part of S-CORE and the standard only asks for refinement during SW development. As the input is missing, there is nothing to refine. Expectations towards the HW/Environment are covered by AoUs. Additionally S-CORE only provides reference HW integration, so every user of the platform would have to redo the effort anyway: std_wp__iso26262__software_652
Because the SW platform is not an safety item but an element: std_wp__iso26262__management_651, hence impact analysis of the item level is tailored out
But also some activities based on requirements defining what has to be done to create a workproduct which is in scope of the S-CORE platform are tailored:
Because those are not relevant for ASIL_B: std_req__iso26262__system_6423, std_req__iso26262__system_6424, std_req__iso26262__system_6425
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.
Cybersecurity Interface#
Cybersecurity is a critical aspect of the overall safety culture and is recognized as an essential element in the development and operation of the S-CORE platform. While functional safety and cybersecurity have distinct objectives, their interaction is managed through coordinated processes and shared responsibilities.
The project acknowledges the need to address cybersecurity risks that may impact safety. To this end, the following measures are implemented:
Regular collaboration between the safety and cybersecurity teams to identify and assess potential cyber threats that could affect safety functions.
Integration of cybersecurity considerations into safety analyses, including risk assessments, to ensure that cyber risks are systematically evaluated.
Alignment of safety and cybersecurity requirements in the development lifecycle, with traceability between stakeholder safety requirements and relevant cybersecurity controls.
Participation in cross-functional reviews and audits to ensure that both safety and cybersecurity requirements are met and that any conflicts are resolved.
Continuous monitoring of emerging cybersecurity threats and updating the security plan accordingly; update the safety plan only if safety-related impacts are identified.
The project is committed to further strengthening the interface between safety and cybersecurity, and will regularly review and update its processes to reflect best practices and regulatory requirements. This approach ensures that cybersecurity is not treated in isolation, but as an integral part of the platform’s safety culture and management system. The security management aspects are defined in the Security management / Platform Security Plan.
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 responsible 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 meritocratic 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 Resources#
A dedicated safety manager is elected for all the S-CORE SEooCs development - see Platform Safety Manager (doc__platform_safety_manager).
The safety manager, supported by the project manager (rl__project_lead) or the assigned Feature team leads, 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 responsible safety manager documented 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 month.
E-Mails
Messenger 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 in the Project Lead Circle Meeting which is defined in Project Management Plan (doc__project_mgt_plan). The status report is based on safety plans work product lists (see below) and verification reports on platform and module level:
Escalation
rl__safety_manager to rl__project_lead (in the Project Lead Circle)
The Project Lead Circle is the ultimate decision instance within the S-CORE project. But as in every Eclipse project the rules and committee decisions of Eclipse have to be followed.
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 module project manager (= Feature team lead) and any safety manager
Safety anomalies detected by the safety manager are not accepted by the module project 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 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 artifacts is determined by Safety Audit and not be Eclipse project reviews. The S-CORE project implements a reduced ISO 26262 safety lifecycle, covering only those phases relevant to software SEooC development. All omitted phases (e.g., HARA, system/hardware development, calibration, proven-in-use) are justified and documented in the Tailoring section. All safety activities, planning, and evidence generation are tracked via the Platform Safety Plan, Module Safety Plans, and associated GitHub Issues. This approach ensures compliance with ISO 26262 for software SEooC, while avoiding unnecessary activities not applicable to the S-CORE context.
Functional Safety Requirements#
Requirement Engineering is defined in the process description. See Project Management Plan (doc__project_mgt_plan).
The application of ISO 26262 standards requirements is realized by defining process guidances and matching those to the ISO 26262 requirements (see e.g. for example gd_req__safety_doc_status).
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 gd_temp__module_safety_plan.
Functional Safety Development#
The SW development is defined in the project-wide software development plan. See Software Development Plan
Functional Safety Verification#
The platform management plan defines the Software verification
Functional Safety Tool Management#
The platform management plan defines Tool Management/ Tool Management Plan
Functional Safety Work Products#
The work products relevant for a module development is defined within each module safety management plan. See 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 Quality Management Plan
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 |
|
valid |
not started |
||||
draft |
n/a |
established |
|||
valid |
draft |
||||
valid |
<automated> |
||||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
valid |
<automated> |
||||
valid |
this document |
see above |
|||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
wp__fdr_reports (platform Safety Plan) |
valid |
<Link to issue> |
<Link to WP> |
<automated> |
|
wp__fdr_reports (platform Safety Package) |
valid |
<Link to issue> |
<Link to WP> |
<automated> |
|
wp__fdr_reports (feature’s Safety Analyses & DFA) |
Safety Analysis FDR tbd |
<automated> |
<Link to issue> |
<Link to WP> |
<automated> |
performed by external experts |
n/a |
<Link to WP> |
intermediate |
||
<Link to process> |
<Process status> |
<Link to issue> |
<Link to WP> |
<automated> |
|
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
valid |
n/a (done already) |
<automated> |
|||
valid |
valid |
||||
valid |
draft |
||||
valid |
<Link to issue> |
<Link to WP> |
<automated> |
||
wp__tailoring (generic) |
valid |
std_req__iso26262__management_5421 & Platform Safety Plan (doc__platform_safety_plan) |
valid |
Note: list of features for v0.5 according to S-CORE Roadmap and S-CORE Releases