1 Introduction

1.1 Purpose of the Document

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].

1.3 Terms and Definitions

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 Applicable Documents

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

4.2.3 Roles and their Key Competencies

The specification of the roles and corresponding activities is done in safeCore Software Development Plan in the chapter Software Life Cycle Processes and Activities.

Every project member shall have an overview training of IEC61508.

This list is extended with required qualification of different roles:

4.2.4 SafeCore team Stakeholders and their Key competencies

The following table gives an overview of the SafeCore team stakeholders and their key competencies:

4.2.5 Trainings

Trainings of team members will be planned by PM during development phase of project. A detailed list of all trainings with participants is shown in .

4.2.6 Project supporting Stakeholder

4.2.6.1 Information-Security

Information security is done by the infoteam information security officer. The infoteam information security system is certified acording ISO27001.

4.2.6.2 IT-Management

The development toolchain runs for the safeCore project in a virtual environment. The safeCore project team is resposible for the virtual environment and the included tooling. IT-Management is responsible for the server on which the virtual environment is running, including a backup strategy.

4.2.6.3 Data Protection

Data protection is done from the data protection officer. In the safeCore project instead of the names of the project members no additional personal date are collected or processed so not specific data protection measurements has to be defined and controlled.

4.3 External Organizations

This section gives an overview of all external organizations participating in this project and a detailed description of the communication models used for different artifacts.

4.3.1 Communication model TKE - TCI

This subsection covers the communication model between customer TKE and TCI team with handling of all inputs and outputs.

4.3.1.1 Development Interface Agreement (DIA)

In addition to contract information for the "sub-project" safeCore the document DIA is established. It contains the overview of the MULTI project and the description and location of the "sub-project" safeCore.

Furthermore it includes a RASI-Chart of tasks and responsibilities belonging to safeCore project, the software life cycle and the safety life cycle.

The document is exchanged by infoteam PM, TKE Assessor or TKE PM via internet data storage BrainLoop. A versioning is made in the document by document name, history tab and on BrainLoop.

4.3.1.2 Customer Requirement Management

The High Level requirements from customer are stored in his DOORS system. They will be exported from DOORS and imported into Confluence and Jira. The import will be done after receiving the requirements.

TCI team development process will take place. As results of the development process a Traceability Record will be generated and exported for exchange with customer.

After exchange the Traceability Record as all artifacts will be reviewed and approved by ASS of customer. This overall workflow is shown in .

A more detailed explanation is given in safeCore Software Development Plan in chapter SoftwareRequirementProcess and in [RSTD].

4.3.1.3 Quality Assessment

Quality Assessments/Functional safety assessments will be split into Functional Safety Milestone Reviews adjusted to specific phases of the safety life cycle. Planning will be done in coordination with customer.

In forehand the safeCore Quality Report shall be prepared.

The results of the assessements shall be recorded in FSM Review Reports.

4.3.1.4 Milestones

The MULTI System will be realized in multiple steps with increasing number of components and features. Two steps are planned for the implementation of MULTI, called Gen1 and Gen2. The generation steps are chosen so that the next generation will deploy all components of the previous generation and add new. The Minimal Certification Approach (MCA) defines an implementation of MULTI Gen1 in order to achieve initial certification. Refer to safeCore Main Architecture Design Specification for details on the planned evolution of MULTI.

The overall project planning for MULTI TKE (Gen1) defines milestones called "Release Milestones" the dates and content of the release milestones are defined in the SoR.

For the safeCore project planning the following Release Milestones have to be considered:

• D-Release – Design Approval

• P1-Release

• P2-Release – Implementation Approval

• P3-Release

• P4.1-Release

• P5-Release

• P6-Release

• P7-Release

Note: -Hotfixes will be provided on Customer request with a supporting Change request for immediate resolutions. This will be supported by limited testing only, full coverage testing will be conducted in next major Release milestones only.

Hotfix is an urgent fix requested(by TKE) in the safeCore Software. Due to the urgent nature of the fix requested the software will be updated and tested in limited coverage and released through a hotfix baseline.

Depending upon the requirement availability and urgency in the timeline, the testing carried out in the hotfix will be limited and may not have a complete coverage for UIT and SNIT.

This hotfix will be verified on HIL bench by TKE HIL testing team.

In addition to the three Release Milestones three "Pre-Release Milestones" are defined by TKE. For the safeCore project planning the following four Pre-Releases are intermediate milestones for the P1-Release:

• PR1 - Proof of concept for LCU with Collision prevention

• PR2 - Exchanger

• PR3 - IOC

• PR4 - LCU

Update 20.04.2022: There are some safety functions defined in customer requirements are not mandatory for MULTI Gen1, therefore postponed to MULTI Gen2. MULTI Gen2 is not the scope of this project.

Update 08.07.2022: Functionality of MULTI Gen1 is changed to MCA (Minimal Certification Approach) scope, which are defined and reviewed by safeCore Release Plan and baseline of HLRQ specifications on 29.07.2022. Some developped components and features in Pre-Releases are not necessary for MCA scope, e.g. Exchanger. Impact analysis and feature complete are planned during P1 and P2 releases.

5 Responsibility between customer and TCI in safety life cycle

Responsibilities in safety life cycle split between customer and TCIis illustrated in following figure:

As shown in TCI is responsible for the software development in safety life cycle phases "9. E/E/PE system safety requirements specification" and "10. E/E/PE safety-related systems Realization". That means specifying the system safety requirements of the system (HW, SW) in the Main Architecture and Design Specification and the realization of the logical safety function on one or more PLCs.

6 System Overview

6.1 System boundary

This chapter gives an overview of the system boundary. Information about the project MULTI, part multiSAFE and safeCore is given.

6.1.1 Architecture

The position of project safeCore in the MULTI programm in defined in diagram .

6.1.2 Internal Sequences

Description of Internal Sequences is part of the system / sub-system safety plan prepared by TKE (DIA D00007289).

6.1.3 Samples

Description of Samples is part of the system / sub-system safety plan prepared by TKE (DIA D00007289).

6.1.4 System Requirements

Specification of System Requirements is prepared by TKE (DIA D00007289).

6.2 Safe Function and Safe State

Definition of Safe Function(s) and Safe State(s) is part of the specifications prepared by TKE for the Safety functions (DIA D00007289).

7 Hazard Analysis

7.1 Hazards

The Hazard analysis is prepared by TKE (DIA D00007289).

7.2 Identification of SIL

The definition of corresponding SIL is part of the specifications prepared by TKE for the Safety functions (DIA D00007289).

The highest SIL for a safety function will be SIL3 (see also [SOR] chapter 3.2).

7.3 Safety Requirements

Specification of Safety Requirements is prepared by TKE for the Safety functions (DIA D00007289).

7.4 Essential Safety Measures of Architecture

Specification of essential Safety Measures of the Architecture is prepared by TKE (DIA D00007289).

7.5 Software Development at component level

All workproducts and evidences as mentioned in Development Interface Agreement (DIA D00007289) related to safeCore software development and testing is prepared by TCI.

8 Appendix

8.1 Contents

8.2 History

{"enableNumbering":true}