The safety plan defines all organizational measures for the safeCore project in compliance to IEC 61508. The safety plan is valid for all safeCore project members.

The project safeCore is part of the project multiSAFE. The project multiSAFE takes care about safety on system level including the safety concept. The responsibility for project safeCore is defined in the [DIA]. 
System Overview and Hazard Analysis is in the responsibility of TKE, which is the input for the project safeCore. The chapters are part of this safety plan to ensure that safety concept aspects are covered.

1.2. Scope of the Document

This document applies to the complete safety life-cycle for the safeCore project, according to [IEC61508].

For a list of project wide definitions of term, refer to [GLOSS].

1.4. Imperative Terms

Use of the words 'shall', 'must', 'will' and 'may' within the products of this standard shall be as follows:

• The word 'shall' in a text expresses a mandatory requirement of the specification. Departure from
  such a requirement is not permissible without formal agreement between the relevant parties (e.g.
  System Design and the Software Team).
  
  

• The word 'should' in a text expresses a recommendation or advice on implementing such a
  requirement of the related specification. System Design expects such a requirement or advice to be
  followed unless good reasons are stated for not doing so.
  
  

• The word 'must' in a text is used for legislative or regulatory requirements (e.g. health and safety) with
  which both the System Design and the Software Design shall comply. It is not used to express a
  requirement of the specification.

• The word 'will' in a text expresses a provision or service by System Design or an intention by System
  Design in connection with a requirement of the specification. The Software team may rely on such
  provisions, service or intention.

• The word 'may' in a text expresses a permissible practice or action. It does not express a requirement
  of the specification.

• The word 'is' in a text does not express a requirement of the specification.

2.1. Certification Standards

2.2. Project Documents

2.3. Software Development Standards

2.4. Project Plans

2.5. Referenced Documents

3. Process Specification

The safety software development is in the responsibility of safeCore.

An overview of processes is described or referred in the following chapters.

3.1. Software Life Cycle Processes

The design and verification process shall follow the V-Model. The detailed description of software life cycle processes and activities is documented in safeCore Software Development Plan in chapter Software Life Cycle Processes and Activities.

3.2. Team Change Impact on  Software Life Cycle Processes

The project has experienced a change in the software development team, which could potentially impact the safety plan. The impacts that have been identified include changes to the safety requirements, delays in the schedule, loss of institutional knowledge, risk of errors or omissions

To mitigate these impacts, the following steps will be taken:

• Training on the safety requirements will be provided to the new team

• A comprehensive knowledge transfer process will be conducted to ensure that TCI team has all the necessary information and knowledge about the project

• The progress of the new team will be closely monitored, and guidance and support will be provided as needed

• The safety plan will be reviewed and updated regularly to ensure that it remains compliant with the safety requirements and addresses any issues that arise as a result of the team change

3.3. Software Development Environment and Tools

Tools which are used during the development process shall be documented and qualified by its requirements. The detailed description is documented in chapter Software Development Environment and chapter Tool Qualification in safeCore Software Development Plan.

3.4. Change Management Process

3.4.1. Objectives

Change management process is a central process. The purpose of change management process is to manage change requests so that approved changes will be controlled, ensuring the project remains on schedule, within budget and provides the agreed deliverables.

The primary objectives of change management are to:

• ensure the functional safety for the safeCore project is maintained to the specified level;

• ensure that the technical requirements, necessary for the overall operation, maintenance and repair are specified and provided to those responsible for the future operation and maintenance for the safeCore project by

  • manage each change request from initiation through to closure;

  • process change requests based upon direction from the appropriate authority;

  • communicate the impact of changes to appropriate personnel; and

  • allow small changes to be managed with a minimum of overhead.

Change Requests shall be applied for process topics as well as for technical topics.

The Change Management Process is the mechanism used to initiate, record, assess, approve and resolve project changes. Project changes are needed when it is deemed necessary to change the scope, time or cost of one or more previously approved project deliverables. Most changes will affect the budget and/or schedule of the project.

3.4.2. Change Management Documents

The following documentation is used to monitor and/or control changes to the project:

• The ‘Change Request Form’ is used to identify and describe a proposed change to the project.

• The ‘CID Log’ (Change, Issues, Decision) is the log where all requests for changes are registered and tracked through to resolution.

The issue tracking tool JIRA is used for document any Change Requests. There is a issue type 'Change Request' (CR) defined where identification and description of every single instance is guaranteed.

3.4.3. Responsibility

The following will play a role in the request, review, tracking and approval of a change request:

3.4.3.1. Change Manager

The Change Manager receives, logs, monitors and controls the progress of all changes within the project. The Project Managers are responsible for:

• Identifying the requirement to make a change to the project

• Documenting the requirement by completing a CR

• Categorizing and prioritizing all CRs

• Submitting the CR to safeCore Change Control Board (CCB) for review.

• Reporting and communicating all decisions made by safeCore CCB

• Close the CRs issue when completed

3.4.3.2. safeCore Change Control Board (CCB)

safeCore CCB is the Steering Committee or other authorized body who is the principal authority for all CRs forwarded by the Change Manager. safeCore CCB is responsible for:

• Reviewing all CRs forwarded by the Change Manager

• Considering all supporting documentation

• Approving / rejecting each CR based on its relevant merits and when necessary escalating to the executive steering committee.

• Resolving change conflicts (where 2 or more changes overlap)

3.4.4. Inputs

Inputs for the change management process are:

1. Change requests

2. Process description (this chapter in this document)

3. Customer Requirements (Document safeCore High Level Requirement Proxy)

4. Associated Jira requirement issues

5. Artifacts defined in Architecture and Design Process

6. Artifacts defined in Implementation Process

7. Artifacts defined in Verification Process

8. Process description safeCore Requirement Management Process

3.4.5. Activities

1. For each change request an associated Jira change request issue has to be created.

2. Document all decisions to be made during the change management process

   1. approve / reject change requests based on the to be prepared impact analysis

   2. discuss about change request in case of contradiction with the requirements.

3. Document all related Artifacts.

Note: safeCore requirement management process is related to change management process.

Note: safeCore change management process involves the safeCore change control board (CCB). CCB acts as a steering committee.

3.4.6. Outputs

Outputs of the change management process are:

1. Decision or tasks for the changes.

2. Associated Jira change request issue status.

3.4.7. Transition Criteria

Process Entry

1. All inputs for the change management process are prepared.

Process Exit

1. All outputs of the change management process are prepared.

2. All change request issue status are in a final state in Jira.

3.5. Project documentation management

Project documents with history, version number and document state are stored in Confluence. The procedure of the review process is described in [SVVP]. 

Naming conventions of documents and layout of the document space in Confluence are listed in [MDL].

The following figure gives a short overview of the layout structure for main artifacts:

The confluence multiSAFE Development page is split into two main sub-pages:

• safeCore Life Cycle Documents: Contains all documents planned according to Master Document List and delivered by Configuration Index Document.

• Project Supporting and Guidance: Contains support documents, like HowTo articles for use of tools, descriptions of server installation etc.

Requirements are stored in Confluence. Links for traceability and state are done in Jira.

3.6. Decommissioning / Disposal

At safeCore project end a final transfer of the following project data to TKE is planned:

• created project artifacts and their history

• description of the toolchain, toolchain classification and qualification, manuals, plans and their history

• configured tools of the development toolchain

4. Project Organization

4.1. Structure of the Project

The structure of the project safeCore is shown in 

Because of the safeCore project being embedded as "sub-project" in the multiSAFE project, the customer is responsible for overall certification. 

Therefore all artifacts created during safeCore SW life cycle will be approved by the Assessor from the customer.

4.2. Roles and project team members

4.2.1. Team members experience

4.2.2. Team