Guidelines for PSS-OS design - Iter

IDM UID 

C99J7G 

VERSION CREATED ON / VERSION / STATUS 

21 Dec 2012 / 1.0/ Approved 

EXTERNAL REFERENCE 

Memorandum / Note 

Guidelines for PSS-OS design 

This document provides the guidelines to be followed by the plant system I&C designers for 

the development of the part the Plant System I&C which implements the occupational safety 

protection functions and interfacing with the Central SafetySystems for Occupational Safety 

(CSS-OS). 

Approval Process 

Name Action Affiliation 

Author Fourneron J.- M. 21-Dec-2012:signed IO/DG/DIP/CHD/CSD/PCI 

CoAuthor Badin R. 

Delannoy N. 

Pernin J.- M. 

Petitpas P. 

Reviewers Yonekawa I. 

Journeaux J.- Y. 

Wallander A. 

Fernandez Robles C. 

21-Dec-2012:signed 

03-Jan-2013:signed 

21-Dec-2012:signed 

07-Jan-2013:signed 

10-Jan-2013:recommended 




Approver Bak J.- S. 14-Jan-2013:approved IO/DG/DIP 

Document Security: level 1 (IO unclassified) 

RO: Fourneron Jean-Marc 

Read Access 

IO/DG/DIP/CHD/CSD/PCI 


IO/DG/DIP/CHD/CSD 

IO/DG/DIP/CHD/CSD/CDC 



IO/DG/DIP/CHD/CSD 


RO, project administrator, LG: PBS48 EXT, AD: ITER, AD: External Collaborators, AD: Section - CODAC, 

AD: Section - Plant Control and Instrumentation 

PDF generated on 14-Jan-2013 

DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

Title (Uid) 

Versio 

n 

Change Log 

Latest Status Issue Date Description of Change 

Guidelines for PSS-OS 

design (C99J7G_v1_0) 

Guidelines for PSS-OS 

design (C99J7G_v0_0) 

v1.0 Approved 21 Dec 

2012 

v0.0 In Work 07 Nov 

2012 

Creation of the document 

PDF generated on 14-Jan-2013 

DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM


Table of Contents 

1 INTRODUCTION...............................................................................................................5 

1.1 SCOPE ................................................................................................................................6 

1.2 ACRONYMS ........................................................................................................................6 

1.3 REFERENCES ......................................................................................................................7 

1.3.1 Reference documents.................................................................................................7 

1.3.2 Applicable standards ................................................................................................7 

1.3.3 Hardware Reference documents ...............................................................................7 

1.3.4 Software Reference documents .................................................................................8 

1.4 PCDH CONTEXT ................................................................................................................8 

2 PRINCIPLES ......................................................................................................................9 

2.1 ROLES AND RESPONSIBILITIES............................................................................................9 

2.1.1 OHS HIRA process .................................................................................................10 

2.2 RELATION BETWEEN PSS-OS GUIDELINES AND IEC 61508 ............................................10 

2.3 ENVIRONMENTAL QUALIFICATION ...................................................................................10 

2.4 TERMINOLOGY.................................................................................................................10 

2.4.1 SCS-OS....................................................................................................................11 

2.4.2 PSS-OS....................................................................................................................11 

2.4.3 CSS-OS....................................................................................................................12 

2.4.4 PSN-OS ...................................................................................................................12 

2.4.5 CSN-OS ...................................................................................................................13 

2.4.6 Safety Function .......................................................................................................13 

2.4.7 Occupational Safety I&C Function.........................................................................13 

2.4.8 Occupational Safety Event......................................................................................14 

2.4.9 Occupational Safety Action.....................................................................................14 

2.4.10 Non-critical monitoring system...............................................................................14 

2.4.11 Critical monitoring system......................................................................................14 

2.5 OS FUNCTION SCOPE ........................................................................................................14 

2.5.1 Local OS function – Automatic activation ..............................................................15 

2.5.2 Central OS function – Automatic activation...........................................................16 

2.5.3 Central OS function – Manual activation...............................................................16 

2.5.4 Emergency buttons..................................................................................................17 

2.5.5 Local Access Safety functions (LAS).......................................................................19 

2.6 OS FUNCTION INTEGRITY .................................................................................................20 

2.6.1 Distinction between CSS-OS integrity, Plant System integrity and Occupational 

Safety function integrity ......................................................................................................20 

2.6.1.1 OS Local function case ...................................................................................20 

Page 1 of 95

2.6.1.2 OS Central Function case................................................................................21 

2.6.2 Design requirements to achieve a SIL level............................................................22 

2.6.2.1 Quantitative requirements...............................................................................23 

2.6.2.2 Architectural requirements..............................................................................24 

2.6.2.3 Voting concept ................................................................................................25 

2.6.3 OS function response time ......................................................................................25 

3 SCS-OS INTRODUCTION..............................................................................................27 

3.1 OS HMIS .........................................................................................................................27 

3.1.1 CSS-OS Operational Components ..........................................................................28 

3.1.1.1 Safety Critical Hardwired HMI.......................................................................29 

3.1.1.2 OS SCADA.....................................................................................................29 

3.1.2 CSS-OS Maintenance Components.........................................................................29 

3.1.2.1 CSS-OS Maintenance Terminals ....................................................................30 

3.1.2.2 CSS-OS Expert Stations .................................................................................30 

4 PSS-OS ARCHITECTURE .............................................................................................31 

4.1 PSS-OS STANDARD AVAILABILITY ARCHITECTURES .......................................................32 

4.1.1 Integrated I/O configuration...................................................................................32 

4.1.2 Remote I/O configuration .......................................................................................34 

4.1.3 Specific remote I/O configuration...........................................................................36 

4.2 PSS-OS HIGH AVAILABILITY ARCHITECTURE..................................................................38 

4.3 SPECIFIC PSS-OS INTER-EXCHANGES ..............................................................................39 

4.4 HARDWIRED ARCHITECTURE............................................................................................41 

5 SENSORS AND ACTUATORS.......................................................................................42 

5.1 IEC 61508 REQUIREMENTS AND CONCEPTS .....................................................................42 

5.1.1 Proven in use components ......................................................................................42 

5.1.2 Diversified components...........................................................................................42 

5.1.3 Fail-safe components ..............................................................................................42 

5.1.3.1 Definition ........................................................................................................42 

5.1.3.2 Principles.........................................................................................................43 

5.1.3.3 Energized to trip & de-energized to trip concepts ..........................................43 

5.1.3.4 Signal monitoring............................................................................................43 

5.1.3.5 Conclusion ......................................................................................................44 

5.1.4 Sensors and actuators connection to Safety Modules.............................................45 

5.2 SHARING OF SENSOR OR ACTUATOR BETWEEN OCCUPATIONAL SAFETY, CONVENTIONAL 

CONTROL AND INVESTMENT PROTECTION SYSTEMS................................................................45 

5.2.1 Sharing of Sensor....................................................................................................45 

5.2.2 Sharing of actuator .................................................................................................45 

6 NETWORKS .....................................................................................................................46 

6.1 CONNECTION BETWEEN PSS-OS AND CSS-OS................................................................46 

6.2 CONNECTION BETWEEN PSS-OS AND THE I/O MODULES.................................................47 

Page 2 of 95

6.3 CONNECTION BETWEEN DIFFERENT PSS-OS IN THE SAME PLANT SYSTEM.......................49 

6.4 CONNECTION BETWEEN DIFFERENT PSS-OS IN DIFFERENT PLANT SYSTEMS....................50 

7 HARDWARE ....................................................................................................................51 

7.1 PSS-OS PLC ...................................................................................................................51 

7.2 PSS-OS CUBICLES ...........................................................................................................52 

7.2.1 Cubicle Monitoring.................................................................................................52 

7.3 PSS-OS SWITCH ..............................................................................................................53 

7.3.1 Conceptual principles .............................................................................................53 

7.3.2 Switch Specifications ..............................................................................................53 

7.4 PSS-OS SIGNAL CABLING ................................................................................................54 

7.4.1 PSN-OS Network.....................................................................................................54 

7.4.2 Sensor / actuator .....................................................................................................54 

7.5 PSS-OS POWERING..........................................................................................................54 

7.5.1 Conceptual principles .............................................................................................54 

7.5.2 CPU racks...............................................................................................................55 

7.5.3 Peripheral racks......................................................................................................57 

7.5.4 Network products ....................................................................................................58 

7.5.5 Cubicle Power distribution .....................................................................................58 

8 SOFTWARE TOOLS AND REQUIREMENTS ...........................................................59 

8.1 SIEMENS TOOLS ............................................................................................................59 

8.2 CODAC TOOLS................................................................................................................59 

8.2.1 Self-description Data Toolkit (SDD) ......................................................................60 

8.2.2 Control System Studio.............................................................................................60 

8.2.2.1 Operator Interface (BOY) ...............................................................................60 

8.2.2.2 Alarm Interface (BEAST)...............................................................................60 

8.2.2.3 Engineering Archives (BEAUTY)..................................................................60 

9 SOFTWARE INTERFACES AND FUNCTIONAL REQUIREMENTS ...................61 

9.1 OS FUNCTIONAL MONITORING INTERFACE......................................................................61 

9.1.1 OS Common Concepts ............................................................................................62 

9.1.1.1 OS Function State and Status..........................................................................62 

9.1.1.2 OS Function Reset ..........................................................................................63 

9.1.1.3 Override ..........................................................................................................63 

9.1.1.4 Time stamping ................................................................................................63 

9.1.1.5 Alarm Management.........................................................................................64 

9.1.1.6 Naming convention.........................................................................................64 

9.1.2 Occupational Safety Standard ................................................................................64 

9.1.2.1 OS Standard Function .....................................................................................64 

9.1.2.2 OS Standard Emergency Button Monitoring..................................................67 

9.1.2.3 OS Specific Function ......................................................................................69 

9.2 OS INTERFACE BETWEEN PSS-OS PLC AND CSS-OS PLC.............................................70 

9.3 OS HARDWARE MONITORING INTERFACE .......................................................................70 

Page 3 of 95

9.4 PSS-OS SOFTWARE STRUCTURE ......................................................................................70 

9.4.1 SPSS Architecture and data exchanges ..................................................................71 

9.4.2 Safety application....................................................................................................71 

9.5 DELIVERABLES RELATED TO THE CSS-OS CONFIGURATIONS ..........................................72 

10 DEVELOPMENT AND INTEGRATION......................................................................73 

11 INSTALLATION..............................................................................................................74 

12 TESTING AND ACCEPTANCE TESTS.......................................................................75 

12.1 ENTRY CRITERIA ..............................................................................................................75 

12.2 ACCEPTANCE PROCESS.....................................................................................................75 

12.3 ACCEPTANCE CRITERIA....................................................................................................75 

12.4 FAT .................................................................................................................................76 

12.5 SAT .................................................................................................................................76 

13 STANDARDS COMPLIANCE AND CERTIFICATION REQUIREMENTS ..........78 

14 PERIODIC TESTS PRINCIPLE ....................................................................................79 

APPENDIX 1 – DETAILED LOGIC HARDWARE LISTS ................................................80 

APPENDIX 2 – VARIABLE TABLE FOR OS STANDARD FUNCTION ........................85 

APPENDIX 3 – FUNCTIONAL REPRESENTATION OF OS STANDARD FUNCTION 

94 

APPENDIX 4 – VARIABLE TABLE FOR OS STANDARD EMERGENCY BUTTON 

MONITORING .........................................................................................................................95 

Page 4 of 95

1 Introduction 

Occupational safety (OS) is a cross-disciplinary area concerned with protecting the safety, health and welfare of 

people engaged in work or employment. The goal of all occupational safety and health programs is to foster a safe 

work environment. 

In the ITER project, safety concerns are divided into: 

• Nuclear safety risks related to internal and external exposure to ionizing radiation and releases of 

radioactive material, 

• Occupational safety risks, covering all non-nuclear risks. 

Occupational safety risks may include: 

• Work in confined spaces, 

• Proximity to heavy duty equipment, 

• Elevated loads, 

• Pressure build-up in circuits, 

• High temperature, 

• Cryogenic risks, 

• Electrical risks, 

• Magnetic risks, 

• Oxygen depletion, 

• … 

Two types of protection can be found for OS risks: 

 

 

Internal protections implemented within system design. These are inherent protections embedded in the 

component, assembly or system itself and which do not involve I&C Systems (e.g. safety relief valves, 

cages, locking system....), 

I&C protections, which are instrumented functions which protect and warn personnel against possible 

immediate risks due to machine or systems failure, malfunctioning or normal hazardous operation (e.g. 

oxygen monitoring, leak detection……). 

The Safety Control System for Occupational Safety (SCS-OS) provides an I&C safety system for the entire ITER 

plant for the protection of people and the environment, covering occupational safety issues related to non-nuclear 

risks. 

This SCS-OS contains a central part, the Central Safety System (CSS-OS) linked to local parts, the Plant Safety 

Systems (PSS-OS), by a Central Safety Network (CSN-OS). A plant safety system for OS is an I&C safety system 

of a plant system which implements occupational safety functions. 

The following elements are not included in the safety I&C system for occupational safety: 

• Fire detection and protection systems, as these are independent systems delivered by PBS.62 and 63 

(Buildings), 

• Radiation protection system, as it is an independent system delivered by PBS.64 (Radiological and 

Environmental Monitoring), 

• Access control system, which provides access to controlled zones where it is necessary to control on 

site movement and to ensure that only properly authorized people have access, as it is an independent 

system delivered by PBS.69 (Access Control and Security Systems), 

• Fences, management of access to dangerous areas with a captive key system, administrative procedures, 

training of operators… as these are not electrical/electronic/programmable safety-related systems (not 

safety instrumentation and control systems), 

• I&C functions that have no specific Safety Integrity Level (SIL according to IEC 61508) requirements, 

as these systems can be implemented with conventional I&C, 

• Nuclear Safety Control System, 

• Interlock Control System, which is devoted to investment protection. 

Page 5 of 95

To implement this architecture all OS actors (PSS-OS and CSS-OS) will incorporate interface management 

(hardware and software) described in this document. 

1.1 Scope 

This document provides the guidelines to be followed by the plant system I&C designers for the development of 

the PSS-OS which implements the occupational safety protection functions and interfaces to the Central Safety 

Systems for Occupational Safety (CSS-OS). 

1.2 Acronyms 

Acronym 

Item 

BCR Backup Control Room (building 24) 

BSR Backup Server Room (building 24) 

CDR Conceptual Design review 

CFC Continuous Function Charts 

CSN Central Safety Network 

CSS Central Safety System 

CIS Central Interlock System 

CODAC Control, Data Access and Communication 

CPU Central Processing Unit 

EEE Electronic, Electrical and Electromechanical 

E/E/PE Electrical / Electronic / Programmable Electronic 

FAT Factory Acceptance Tests 

FDR Final Design Review 

HFT Hardware Fault Tolerant 

HIRA Hazard Identification and Risk Assessment 

HMI Human-Machine Interface 

HO Hand Over 

I&C Instrumentation & Control 

IEC International Electrotechnical Commission 

IO ITER Organization 

I/O Input / Output 

IOC Input Output Controller 

LAS Local Access Safety 

MCR Main Control Room (building 71) 

MRR Manufacturing Readiness Review 

MSR Main Server Room (building 71) 

OHS Occupational Health and Safety 

OS Occupational Safety 

PBS Plant Breakdown System 

PCDH Plant Control Design Handbook 

PDR Preliminary Design Review 

PFD Probability of Failure on Demand 

PFH Probability of Failure per Hour 

Page 6 of 95

PLC 

PR 

PS 

PSCC 

PSH 

PSN 

PSS 

QC 

RFE 

RO 

SAT 

SCADA 

SCS 

Programmable Logic Controller 

Project Requirements (ITER) 

Plant System 

Plant System Conventional Control 

Plant System Host 

Plant Safety Network 

Plant Safety System 

Quality Control 

Ready For Equipment 

Responsible Officer 

Site Acceptance Tests 

Supervisory Control And Data Acquisition 

Safety Control System 

For a complete list of ITER 

abbreviations refer to [RD11], 

ITER 

Abbreviations 

[ITER_D_2MU6W5]. 

1.3 References 

1.3.1 Reference 

documents 

SIL Safety Integrity Level 

[RD1]. Project 

SNP Safety Network Panel 

Requirements 

(PR) 

SPSS Standard PLC Software Structure 

[ITER_D_27ZRW8 ] 

[RD2]. Plant Control 

SQS Safety, Quality and Security Department 

Design Handbook (PCDH) 

SRD System Requirements Document 

[ITER_D_27LH2V] 

[RD3]. SRD-48 

(Central Safety System) from DOORS [ITER_D_2EBF97] 

[RD4]. CSS-OS SRD Complements about functional requirements [ITER_D_9GJ9G9] 

[RD5]. C-DDD Access Safety [ITER_D_3ESV5P] 

[RD6]. ITER Policy on EEE in Tokamak complex [ITER_D_6ZV6S3] 

[RD7]. Guidance for EEE in Tokamak complex [ITER_D_7NPFMA] 

[RD8]. Occupational Health and Safety Management Plan [ITER_D_6LCG7B] 

[RD9]. Procedure for Occupational Health and Safety Hazard Identification and Assessment 

[ITER_D_AJLQRF] 

[RD10]. Integration Scheme and procedure for Plant System I&C [ITER_D_3VVU9W] 

[RD11]. ITER Abbreviations [ITER_D_2MU6W5] 

1.3.2 Applicable standards 

[RS1]. IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related 

systems. 

[RS2]. IEC 61511: Functional safety- safety instrumented systems for the process industry sector. 

1.3.3 Hardware Reference documents 

[RD12]. ITER Catalogue for I&C products – Cubicle [ITER_D_35LXVZ] 

[RD13]. ITER Catalogue for I&C products – Slow Controllers [ITER_D_333J63] 

[RD14]. Guidelines for I&C Cubicle configurations [ITER_D_476HUG] 

[RD15]. I&C Cubicle Monitoring System – Hardware Specifications [ITER_D_7KK29M] 

[RD16]. I&C Cubicle Monitoring System – Functional Specifications [ITER_D_7A45LE] 

[RD17]. I&C Cubicle Internal Configuration [ITER_D_4H5DW6] 

[RD18]. Electrical design Handbook (EDH) [ITER_D_2F7HD2] 

[RD19]. IO cable catalogue [ITER_D_355QX2] 

[RD20]. EDH Part 4: Earthing [ITER_D_2ELREB] 

1.3.4 Software Reference documents 

[RD21]. 

PLC Software Engineering Handbook [ITER_D_3QPL4H] 

Page 7 of 95

[RD22]. 

[RD23]. 

[RD24]. 

CODAC Core System Overview [ITER_D_34SDZ5] 

Philosophy of ITER Alarm System Management [ITER_D_3WCD7T] 

SIEMENS S7 Safety Engineering System Manual [SIEMENS_A5E00109529-06] 

1.4 PCDH context 

The [RD2], Plant Control Design Handbook (PCDH), defines methodology, standards, specifications and 

interfaces applicable to the whole life cycle of ITER plant systems Instrumentation & Control (I&C) Systems. 

I&C standards are essential for ITER to: 

• Integrate all plant systems into one integrated control system, 

• Maintain all plant systems after delivery acceptance, 

• Contain cost by economy of scale. 

PCDH comprises a core document which presents the plant system I&C life cycle and recaps the main rules to be 

applied to the plant system I&Cs for conventional controls, interlocks and safety controls. Some I&C topics are 

explained in greater detail in dedicated documents associated with PCDH [RD2]. This document is one of them. 

PCDH core and satellite documents: v7 

INTERLOCK CONTROLS 

Guidelines PIS design (3PZ2D2) 

Guidelines for PIS integration & config. 

Management of local interlock functions 

PIS Operation and Maintenance 

PS CONTROL DESIGN 

Plant system I&C architecture (32GEBH) 

Methodology for PS I&C specifications (353AZY) 

CODAC Core System Overview (34SDZ5) 

I&C CONVENTIONS 

I&C Signal and variable naming (2UT8SH) 

ITER CODAC Glossary (34QECT) 

ITER CODAC Acronym list (2LT73V) 

OCCUPATIONAL SAFETY CONTROLS 


NUCLEAR PCDH (2YNEFU) 

CATALOGUES for PS CONTROL 

Slow controllers products (333J63) 

Fast controller products (345X28) 

Cubicle products (35LXVZ) 

Integration kit for PS I&C 

Core PCDH (27LH2V) 

Plant system control philosophy 

Plant system control Life Cycle 

Plant system control specifications 

CODAC interface specifications 

Interlock I&C specification 

Safety I&C specification 

PS CONTROL DEVELOPMENT 

I&C signal interface (3299VT) 

PLC software engineering handbook (3QPL4H) 

Guidelines for fast controllers (333K4C) 

CODAC software development environment (2NRS2K) 

Guidelines for I&C cubicle configurations (4H5DW6) 

CWS case study specifications (35W299) 

PS SELF DESCRIPTION DATA 

Self description schema documentation (34QXCP) 

PS CONTROL INTEGRATION 

The CODAC -PS Interface (34V362) 

PS I&C integration plan (3VVU9W) 

ITER alarm system management (3WCD7T) 

ITER operator user interface (3XLESZ) 

Guidelines for PON archiving 

PS Operating State management (AC2P4J) 

Guidelines for Diagnostic data structure (354SJ3) 

Legend 

This document 

Available and approved 

Expected 

(XXXXXX) IDM ref. 

Figure 1.1: PCDH documents structure 

Page 8 of 95

2 Principles 

This chapter describes the common environment for all occupational safety actors. 

The first sections introduce the roles and responsibilities of each actor, IEC standards and the ITER environment 

qualification principle. The next section explains the specific terminology used in this document. Another section 

defines the various occupational safety function types necessary to cover all the OS needs. The last section 

highlights some of the important IEC concepts which have to be followed. 

2.1 Roles and responsibilities 

In the ITER plant system procurement model, the occupational safety issues will be identified by the designers of 

the plant systems (either in IO or in the Domestic Agencies). 

Therefore, the approach is bottom-up. Those in charge of the design and procurement of plant systems should 

identify occupational safety issues and try to mitigate them by using internal protections as far as possible (refer to 

chapter 1 - Introduction). If the remaining risk is still higher than the targeted acceptable risk, entities in charge of 

the design and procurement of plant systems should consider using Instrumentation and Control (I&C) functions 

as additional means to reduce the risk. 

 

 

 

Reference list of 

Hazards 

Policies for main 

categories of risks 

(regulations, standard, 

overall strategy for 

prevention, mitigation, 

technological 

choices…) 

OHS Hazard and 

Identification 

procedure 

SQS scope of 

responsibility 

PS RO scope of 


PBS.48 scope of 


PS I&C TROs 

joined 


OHS HIRA process 

for a Plant System 

RO: PS RO with 

support of SQS, 

Operation, CHD/CS, 

BSI, QA 

PS OHS HIRA 

Approved by PS 

directorate Head 

Includes preventive and 

reactive risk mitigating 

measures and detection 

requirements. 

I&C part feeds PCDH “I8” 

document 

OS I&C function 

specification with SIL 

allocation 

RO: PS TRO 

With support of SQS, CHD/ 

CSD, AOP, BSI 

OS I&C functional 

specifications 

Approved by PS RO 

“D1” for OS function 

PCDH for OS I&C 

PSS-OS guidelines 

PBS.48 RO 

Interface Sheets 

PBS.xx/PBS.48 

for OS I&C 

PBS.xx 

procurements 

PBS.xx RO 

PBS.48 

Procurement 

PBS.48 RO 

Figure 2.1: OS I&C Specification 

Page 9 of 95

The design and implementation of the PSS-OS fall under the responsibility of the IO or Domestic Agency 

responsible officer for the corresponding plant system. 

The design and implementation of the CSS-OS and CSN-OS fall under the responsibility of the PBS48 (CSS) 

responsible officer at IO. 

2.1.1 OHS HIRA process 

The controls for occupational health and safety (OHS) risks and hazards are identified by thorough and 

comprehensive hazard identification and risk assessment process (OHS HIRA). This will be formally documented 

and approved and take into account the potential severity of injuries and illnesses as a result of unwanted events 

during construction and operation of the ITER plant and systems. 

Once these controls have been identified, the residual risk will be re-assessed to evaluate the adequacy of the 

controls applied. 

OHS HIRA is part of the OHS management work cycle as described in [RD8], Occupational Health and Safety 

Management Plan [ITER_D_6LCG7B]. 

The plant systems designers must refer to the [RD9], OHS HIRA procedure document [ITER_D_AJLQRF] to set 

up everything required to identify the OS risks related to the design of plant systems. 

Note: OHS HIRA is an iterative process which needs continuous review. 

This plant system HIRA process delivers the requirements for the OS I&C functions. 

2.2 Relation between PSS-OS Guidelines and IEC 61508 

These guidelines highlight important requirements and define specific ITER design features concerning 

integration, interfaces with the central system for occupational safety and overall operation, but they are not a 

substitute for the IEC standards for the requirements for SIL certification which must still be met. It is the 

responsibility of the plant system supplier to organize a safety assessment of the PSS-OS by a third party, and to 

demonstrate by this mean the compliance to the IEC 61508. 

2.3 Environmental qualification 

ITER plant systems will contain a large quantity of electronic, electrical, and electromechanical (EEE) 

components. Many of them will be, by necessity, located in the radiation and magnetic fields in the TOKAMAK 

Complex and can be negatively affected by these environmental conditions. 

This is the reason why ITER plant electronic, electrical and electro-mechanical systems, and among them the PSS- 

OS, must comply with the requirements for operating within the TOKAMAK Complex. 

Refer to [RD6], ITER Policy on EEE in the Tokamak Complex [ITER_D_6ZX6S3] and [RD7], Guidance for EEE 

in Tokamak Complex [ITER_D_7NPFMA] for more details. 

2.4 Terminology 

This section introduces the basic concepts of OS to be taken into account by the plant systems. 

Page 10 of 95

2.4.1 SCS-OS 

The Safety Control System for Occupational Safety (SCS-OS) provides an I&C safety system for the entire ITER 

plant for the protection of people and the environment regarding occupational safety issues related to non-nuclear 

risks. 

This SCS-OS contains a central part, the Central Safety System (CSS-OS) linked to local parts, the Plant Safety 

Systems (PSS-OS), by a Central Safety Network (CSN-OS). A plant safety system for OS is an I&C safety system 

of a plant system containing occupational safety functions. 

Control-room 

CSS 

-OS 

Sco 

pe op 

e 

Server-room 

CSS-OS 

Engineering 

Workstation 


Maintenance 

Terminal 

Safety Critical 

Hardwired 

HMI 


Safety PLC 


Servers 


Terminal 

SCS 

-OS 

Sco 

pe op 

e 

PSS- OS 

OS 

Sc 

Scop 

eop 

e 

PSS-OS 

Safety PLC 

Plant systems 

CSN-OS 

Figure 2.2: SCS-OS Overview and scope of the document 

Caution: the redundancy in the Control Room and the Server Room is not represented in figure 2.2. 

2.4.2 PSS-OS 

The Plant Safety Systems for Occupational Safety (PSS-OS) are part of the plant systems I&C. 

Every plant system that requires an I&C function with a SIL allocation above SIL1 (refer to IEC 61508 [RS1]and 

OHS HIRA procedure [RD9] must have a PSS-OS to reduce the OS risks it generates. 

Caution: the passive protections ensured by the system design (safety relief valves, cages, locking system…..) are 

unrelated to the I&C system and are therefore out of the scope of this document. 

The PSS-OS performs the OS I&C functions, by means of sensors, PLCs and actuators. 

Page 11 of 95

Each PSS-OS provides local protection by implementing the local occupational safety functions of the 

corresponding plant system. A PSS-OS may also participate in the central safety functions coordinated by the 

CSS-OS. 

It is the responsibility of the plant system responsible officer to supply, implement and operate: 

- Sensors and actuators involved in OS I&C functions, 

- PSS-OS PLC, including a standard interface with CSS-OS through CSN-OS. 

The PSS-OS is independent (in terms of hardware components & associated software) of the system that manages 

the nuclear safety I&C functions of the plant system. 

The PSS-OS is also independent (in terms of hardware components & associated software) of all the others I&C 

systems of the plant system (conventional and interlock systems). 

2.4.3 CSS-OS 

The Central Safety System for Occupational Safety is the central part of the SCS-OS, which integrates functions 

to coordinate the locally distributed plant I&C systems. It retrieves/manages data from the distributed systems to 

activate protections in order to remove or reduce hazardous conditions which have been detected. It does this 

either automatically, or by a manual operator command from the operator’s safety desks located in the control 

rooms. 

At the central level, the Central Safety System for Occupational Safety (CSS-OS, managed by PBS.48) is 

responsible for providing: 

- CSS-OS PLCs which host safety applications for coordinating the plant systems, 

- Human machine interfaces for the supervisory features of all the OS I&C functions that have to be 

reported in control rooms: monitoring, control, diagnostic, maintenance and archiving, 

- A dedicated redundant network (CSN-OS, refer to section 2.3.5) to enable communication between all 

the OS systems, 

- Engineering workstations, 

- Hardwired panels to manage central functions with manual activation and to display information that 

requires a high reliability. 

The CSS-OS is implanted in the server-rooms and control-rooms of buildings 71 and 24. The CSS-OS is beyond 

the scope of this document. 

The CSS-OS is independent from the system that manages nuclear safety functions. 

Notes: 

- PBS.48 (CSS) also implements central systems for nuclear safety. The design of this system is detailed in 

a dedicated document. 

- The Central Safety Systems together with CODAC and the Central Interlock System (CIS) form the 

ITER I&C Central Systems. 

2.4.4 PSN-OS 

The Plant Safety Network for Occupational Safety (PSN-OS) is the OS field network. 

It provides communication between the components involved in the OS functions inside one plant system. The 

PSN-OS connects the PSS-OS PLC in a plant system to the sensors and actuators in the same plant system when 

distributed I/O stations are used. 

The PSN-OS will also connect PSS-OS PLCs together when there is more than one in a plant system. 

The PSN-OS in one plant system will not be shared with other plant systems. 

Page 12 of 95

Server room 


Safety 

PLC 



Safety 

PLC 

Plant System 

PSN-OS 

Remote I/O 

station 

T 

To other remote I/O Station 

T: transmitter 

Figure 2.3: PSN-OS Network 

2.4.5 CSN-OS 

The Central Safety Network for Occupational Safety is the OS network. 

It provides communication between the plant safety systems and the Central Safety System for inter-plant system 

OS protection and monitoring functions via a redundant industrial Ethernet network. 

The CSN-OS is composed of two redundant networks and is independent of the network that manages the nuclear 

safety functions. 

The supply of the CSN-OS beyond the scope of the plant systems. 

The plant system providers are responsible for the PSS-OS connection to these redundant networks. 

2.4.6 Safety Function 

Safety function definition from IEC 61508 Part 3: 

‘’Function to be implemented by an E/E/PE safety-related system, other technology safety-related system or 

external risk reduction facilities, which is intended to achieve or maintain a safe state for the EUC, in respect of a 

specific hazardous event’’ 

‘’Electrical / electronic / programmable electronic (E/E/PE): based on electrical (E) and/or electronic (E) 

and/or programmable electronic (PE) technology’’ 

‘’Equipment under control (EUC): equipment, machinery, apparatus or plant used for manufacturing, process, 

transportation, medical or other activities’’ 

2.4.7 Occupational Safety I&C Function 

This is a safety I&C function that addresses a specific occupational safety hazard. 

Page 13 of 95

2.4.8 Occupational Safety Event 

This is the plant system state or combination of states involving one or several different plant systems that could 

potentially result in injuries and illnesses to people, and that triggers an action of the corresponding PSS-OS 

and/or the CSS-OS. 

The plant system state is usually determined through sensors. 

2.4.9 Occupational Safety Action 

These are measures or sequences of measures carried out by the PSS-OS and/or the CSS-OS to mitigate the risks 

following an occupational safety event. These protection actions are managed by the PSS-OS when the measures 

are restricted to the plant system which detected the event and by the CSS-OS when various plant systems are 

involved. 

2.4.10 Non-critical monitoring system 

The non-critical monitoring system, which is mainly composed of computerized HMIs, monitors occupational 

safety functions. These computerized HMIs are located in the control and the server rooms depending on the 

associated user activities. 

This system does not contribute to the SIL classified safety I&C functions. 

2.4.11 Critical monitoring system 

The critical monitoring system is a component of the CSS-OS monitoring system which has the ability to 

contribute to the SIL2 or SIL3 classified occupational safety I&C functions, unlike the non-critical monitoring 

system through CSS-OS terminals (which can only be accredited up to SIL1). Physically, this system will be 

implemented as two redundant hardwired panels, one in the Main Control Room for the safety operators, and the 

other in the Back-Up Control Room. 

These components monitor and also control some specific critical OS functions. 

2.5 OS function scope 

Given the organizational division of ITER and in order to meet the safety requirements, the functional 

requirements address two different needs: 

- Each plant system must have the means to detect and reduce its own OS risks locally, 

- If different plant systems are involved in the same OS function, a central system must coordinate the 

locally distributed safety systems. 

Two categories of occupational safety functions are defined: 

- “Requiring human intervention” type: high occupational risks that require a human response. The alarms 

and information related to these functions are displayed on a very reliable hardwired HMI (in the CSS- 

OS scope) because they trigger an action by the operator and consequently the safety action. 

- “Automatic” type: in this case, the risk is controlled by the SCS-OS without any human intervention. 

These functions are monitored from a computerized HMI, with detailed diagnostic performance. 

Apart from a minimal number of specific cases, the occupational risk functions are automatic functions. 

From these requirements and to cover all future OS functions, CSS has defined OS function types. These 

types should cover the complete needs of PSS-OS. The following sections describe these OS function types. 

Page 14 of 95

2.5.1 Local OS function – Automatic activation 

As a consequence of the identification process of safety functions described in [RD8], the Occupational Health 

and Safety Management Plan [ITER_D_6LCG7B] and of the type of occupational risks, the majority of 

occupational safety I&C functions will be completely implemented at a plant system level. Hence, most OS 

functions will be local functions. 

The plant system has the means of detecting its OS risk (it has its own sensors) and of reducing it (its own 

actuators) thereby performing an automatic safety protection or mitigation action to control the risk. 

Therefore, throughout their its cycle the plant system is fully responsible for the safety level of its own 

occupational safety I&C functions as defined in the applicable standards [RS1] and [RS2]. 

The central I&C system for occupational safety does not play an active role in the safety function. It is in charge 

of non-critical actions such as the reset of functions and it is informed about changes of state of the plant system. 

These OS I&C functions are called “local” safety functions. 

Central System 

Critical Monitoring 

System 

Safety Monitoring 

System 

Not used for this case 


Monitoring 

Coordination System 

Reset 

Risk detecting 

System 

Event or action transmission 

Risk eliminating 

System 

Event 

Action 

Plant System 

Sensor 

Actuator 

Safety critical component (contributes to the SIL classified safety I&C functions) 

Safety monitoring component (does not contribute to the SIL classified safety I&C functions) 

Figure 2.4: Local function mechanisms 

Note: the risk detecting system and the risk eliminating system can be in the same PLC. 

The majority of the occupational safety I&C functions will be fully implemented in one plant system. Given this 

local function concept, a specific OS standard has been developed by CSS in order to define the monitoring 

interface between the PSS-OS and the CSS-OS (refer to section 9.1.2.1 for more details) 

Page 15 of 95

2.5.2 Central OS function – Automatic activation 

Some OS I&C functions may concern two or more plant systems. 

In this case, the occupational safety events are detected by the plant system(s) and transmitted to the central OS 

I&C system which takes a safety decision and dispatches the required safety actions to the other plant system(s) 

involved. 

The plant systems providing part of the function must achieve the required safety level defined by the relevant 

standards [RS1] and [RS2]. 

The central system is also responsible of the supervisory features that do not require a safety level. 

These OS I&C functions are called “central” safety functions. 



System 


System 


Monitoring 

Monitoring 


Event transmission 

Reset 

Action transmission 

Monitoring 


System 


System 

Event 

Action 

Sensor 

Plant System X 

Actuator 

Plant System Y 



Figure 2.5: Central function mechanisms 

2.5.3 Central OS function – Manual activation 

Some safety functions require an operator to take a safety decision to trigger a safety action. 

In this case, the occupational safety events are detected by the plant system(s) and transmitted to the central OS 

I&C system which alerts the safety operator through a very reliable HMI. This HMI allows commands to be 

executed on the central system which in turn dispatches the required safety actions to the plant system(s). 

Page 16 of 95

The central system contributes to the safety integrity level of these functions. The plant systems providing part of 

the function must be accredited at the required safety integrity level defined by the relevant standards ([RS1] and 

[RS2]). 

The central system is responsible for the critical monitoring and critical control of the functions which require a 

safety level and for non-critical supervisory features that do not require a safety integrity level. 



System 


System 

Monitoring 



Monitoring 

Critical Control 


Reset 

Action transmission 

Monitoring 


System 


System 

Event 

Action 

Sensor 

Plant System X 

Actuator 

Plant System Y 



Figure 2.6: Central function mechanisms - requiring operator intervention 

Note: the risk eliminating system can be included in the same plant system as the risk detecting system. 

2.5.4 Emergency buttons 

Emergency stop buttons and call buttons will be installed throughout the ITER facilities and will be managed by 

the SCS-OS. 

Multisystem Emergency Stop Buttons: These are generally installed on the walls, at the room entrance or 

in strategic areas and are dedicated to personal safety. They will trigger the safety systems that put the 

associated systems in a safe state. PBS.69 “Access Control & Security Systems” will install these buttons 

and provide their status to the Central I&C system for occupational safety. The latter will distribute the 

stop command detected by PBS.69 to each plant system affected. The principles are the same as for the 

central function mechanisms (refer to Figure 2.5). 

Page 17 of 95

General Electrical Power Emergency Stop Buttons: These are generally installed on the walls, at the room 

entrance or in strategic areas (building level for example) and are dedicated to shut-off the electricity in 

specific area(s) for safe intervention by the fire brigade. PBS.43 “Steady State Electrical Power Supply 

Networks” will have to detect the activation of the button, to provide this information to the Central I&C 

system for occupational safety and to shut-off the electricity. The Central I&C system for occupational 

safety will only be responsible of the supervisory features. The principles are the same as for the local 

function mechanisms (refer to Figure 2.4). 

Emergency Call & Stop Buttons in the TOKAMAK Building: These alert the control room and stop and 

prevent on-going plasma operations (for example in the case of someone trapped in the building during a 

countdown). PBS.69 “Access Control & Security Systems” will install these buttons and provide their 

status to the Central I&C system for occupational safety. The Central I&C system for occupational safety 

may transmit the status of these buttons to the Central I&C System for nuclear safety (CSS-N) to stop or 

prevent on-going hazardous operations in the Tokamak Building. The Central I&C system for 

occupational safety is also responsible for alerting the control room staff through a highly reliable and 

available system. 



System 


System 


Monitoring 

Reset 

Monitoring 



CSS-N 


System 

Event 

Sensor 

PBS69 



Figure 2.7: Emergency call & stop button in TOKAMAK building mechanisms 

Emergency Call Buttons in other buildings: Unlike the emergency call & stop buttons in the Tokamak 

Building which put the system in safe state and simultaneously alert the control room, emergency call 

buttons only alert control room to trigger an emergency intervention. These buttons will be installed by 

PBS.69 “Access Control & Security Systems” which will provide the Central I&C system for 

Page 18 of 95

occupational safety with the status of these emergency call buttons. The Central I&C system for 

occupational safety will be responsible for reporting this emergency to the control rooms with a highly 

reliable and available system. 



System 


System 

Monitoring 


Reset 

Monitoring 




System 

Event 

Sensor 

PBS69 



Figure 2.8: Emergency call button in other building mechanisms 

Note: Plant System Emergency Stop devices or emergency switch off devices: These are generally installed in 

front of doors to electrical board systems or near electrical motors. They stop the process when a problem is 

detected by an operator (e.g. smoke or strange sound). The emergency stop devices or emergency switch off 

devices (under the responsibility of the plant system concerned) will be monitored by their conventional control 

system only and the status reported to the CODAC system. In parallel, operators can actuate the nearest 

emergency call button. 

Given these emergency button concepts, CSS has developed a specific OS standard to define the monitoring 

interface between the PSS-OS and the CSS-OS (refer to section 9.1.2.2 for more details). 

2.5.5 Local Access Safety functions (LAS) 

As described in [RD5], the Conceptual System Design Description of Access Safety System [ITER_D_3ESV5P], 

the SCS-OS is responsible for implementing the access safety functions concerning occupational safety risks. 

Local access safety functions (LAS) to protect people from non-nuclear risks in case of intrusion will be 

implemented to stop plant system equipment on the opening of a door and to remove the source of risks or to ban 

access to an area if a risk is detected. 

Page 19 of 95

The plant system will be responsible for detecting the risk and for removing it, stopping the equipment or banning 

access to the area. 

Therefore, as is the case for local occupational safety functions, the plant system will be responsible for the safety 

level of its own access safety I&C functions and systems. 

The Central I&C system for occupational safety will only be responsible for the supervisory features that do not 

require a safety level. 

The principles are the same as for local function mechanisms (refer to Figure 2.4). 

2.6 OS function integrity 

The safety functions of the SCS-OS have to fulfill the requirements of the IEC 61508 standard [RS1] and 

the IEC 61511 standard [RS2] throughout the life cycle of safety functions. 

IEC 61508 and IEC 61511 define four discrete Safety Integrity Levels (from 1 to 4). Each level corresponds to a 

probability range for the failure of a safety function. The higher the Safety Integrity Level of the safety-related 

systems, the lower the probability that they will not perform the requested safety function. 

This section highlights some of the key concepts of I&C safety standards. However, the Plant System 

designer has to refer to the standards themselves for the exhaustive list of the requirements to achieve the 

targeted SIL level. 

2.6.1 Distinction between CSS-OS integrity, Plant System integrity and 

Occupational Safety function integrity 

There are two steps in order to design Plant System integrity: 

1. The first is the separate design of each OS function (local function) or part of OS functions (central 

function) inside the Plant System. The SIL defined for each OS function and the associated IEC 

requirements are the main inputs for this step. 

2. The second step is the global design of the PSS-OS according to all of the OS function safety integrity 

levels (local function) and all parts of the OS function (central function) implemented in the PSS-OS. 

These steps and the associated local and central function requirements are developed below. 

2.6.1.1 OS Local function case 

First step: the separate design 

For occupational safety local functions, the level to be allocated is based on a calculation which only concerns the 

PSS-OS PLC, the sensors & associated signal conditioning (event) and the actuators (action). 

Page 20 of 95

Event 

Subsystem 

PSS-OS 1 

Logic solver 

Subsystem 

Action 

Subsystem 

Local calculation 

Plant System 1 integrity area example 

Figure 2.9: Local Calculation 

The designer of the Plant System will take all IEC requirements for each OS function into account to obtain the 

relevant SIL level (refer to section 2.6.2). 

Second step: the global design 

According to the following IEC 61508 requirements, the PSS-OS will be designed with the highest SIL of the 

functions deployed. 

From IEC 61508 Part 1 Section 7.6.2.10: 

‘’For an E/E/PE safety-related system that implements safety functions of different safety integrity levels, unless it 

can be shown there is sufficient independence of implementation between these particular safety functions, those 

parts of the safety-related hardware and software where there is insufficient independence of implementation shall 

be treated as belonging to the safety function with the highest safety integrity level. Therefore, the requirements 

applicable to the highest relevant safety integrity level shall apply to all those parts’’ 

Example: 

SIL2 Local OS 

Function 

PSS-OS SIL2 

Architecture 


Function 

+ 


Function 


Architecture 

Figure 2.10: Local Function synthesis principle 

2.6.1.2 OS Central Function case 

First step: the separate design 

For the OS central functions, the level allocated is based on a calculation concerning all the associated safety 

components: the CSS-OS PLC, the various PSS-OS PLC involved and the associated sensors and actuators. 

Page 21 of 95

In the following figure, a PSS-OS (PSS-OS 1) integrates part of an occupational safety central function. 

Event 

Subsystem 


Logic solver 

Subsystem 


Logic solver 

Subsystem 


Logic solver 

Subsystem 

Action 

Subsystem 

Central calculation 


Figure 2.11: Central Calculation 

For the central OS functions, the PSS-OS is one of several actors concerned with the SIL allocations. The designer 

of the Plant System will take all IEC requirements in account for each local part of the OS functions to achieve the 

relevant SIL level (refer to section 2.6.2) 

The set of subsystem calculations will demonstrate the overall SIL level of the complete OS function. 

Second step: the global design 

According to the following IEC 61508 requirements, the PSS-OS will be designed with the highest SIL of the 

functions deployed. 

Example: 

SIL2 Local Part of 

OS central 

Function 


Architecture 



Function 

+ 



Function 


Architecture 

Figure 2.12: Central Function synthesis mechanisms 

2.6.2 Design requirements to achieve a SIL level 

For each safety function, there are three main types of requirements that have to be met in order to achieve a given 

SIL: 

 

 

 

A quantitative requirement, expressed as a probability of failure on demand (PFD) or alternatively as the 

probability of a dangerous failure per hour (PFH), 

An architectural requirement, expressed in terms of constraints on the subsystems performing the safety 

function, 

Requirements concerning which techniques and measures should be used to avoid and control systematic 

faults. 

Page 22 of 95

2.6.2.1 Quantitative requirements 

According to IEC 61508 and IEC 61511, the safety integrity requirements for each safety function should be 

specified in terms of either: 

 

 

The average probability of a dangerous failure on demand of the safety function, for a low demand mode 

of operation (PFD), 

The average frequency of a dangerous failure of the safety function, for a continuous or high demand 

mode of operation (PFH or λ). 

It should be noted that the SIL requirement applies to a complete function, i.e. the field sensor (event), the logic 

solver and the final element (action). It is therefore incorrect to refer to any individual item or equipment having a 

safety integrity level. A separate component can be certified for a particular SIL application, but such a certificate 

constitutes only part of the verification effort, since the required failure probability from IEC 61508 Tables must 

be verified for the complete function. 

Example 1: Local OS function in high demand mode 

PFH1 PFH2 PFH3 

Event 

Subsystem1 


Logic 

solver 

Subsystem2 

Action 

Subsystem3 

SIL 2 CLAIM 

PFH1 + PFH2 + PFH3 < 10 -6 


Figure 2.13: Local Function mechanisms 

Page 23 of 95

Example 2: Central OS function in high demand mode 

PFH1 

PFH2 

PFH3 

PFH4 

PFH5 

Event 


Logic 

solver 


Logic 

solver 


Logic 

solver 

Action 

Subsystem1 Subsystem2 Subsystem3 Subsystem4 

Subsystem5 

SIL 2 CLAIM 

PFH1 + PFH2 + PFH3 + PFH4 + PFH5 < 10 -6 


Figure 2.14: Central Function mechanisms 

The Plant System 1 designer will take care of the whole subsystems for the first example whereas he will only 

take care of two subsystems (event & PSS-OS 1 logic solver) for the second example. 

2.6.2.2 Architectural requirements 

Following the same philosophy as for the quantitative requirements, functions must be broken down into 

subsystems or blocks: event (sensor & signal converting), logic solver (PLC) and action (final element). 

For safety instrumented functions, each subsystem or block will have a minimum hardware fault tolerance (HFT). 

From IEC 61508 Part 4 Section 3.6.3: 

‘’Fault tolerance: it is the ability of a functional unit to continue to perform a required function in the presence of 

faults or errors’’. 

From IEC 61508 Part 2 Section 7.4.4.1.1: 

‘’A hardware fault tolerance of N means that N+1 is the minimum number of faults that could cause a loss of the 

safety function’’. 

There are 3 possibilities for the HFT value: 

 

 

 

HFT=0, Single-channel use. A single fault may cause a loss of safety. 

HFT=1, redundant version. At least two hardware faults have to occur at the same time to cause a loss of 

safety. 

HFT=2, dual redundancy version. At least three hardware faults have to occur at the same time to cause a 

loss of safety. 

Refer to [RS1], IEC 61508 standard part 2 section 7.4.4 for more detail about architectural requirements. 

Page 24 of 95

2.6.2.3 Voting concept 

The voting logic (MooN) is one of the main concepts directly associated with the quantitative requirements. It 

allows the architecture of each subsystem to be specified. 

MooN: ‘’Safety instrumented system, or part thereof, made up of “N” independent channels, which are so 

connected, that “M” channels are sufficient to perform the safety instrumented function’’(From IEC 61511 Part 1 

Section 3.2.45). 

 

 

 

 

1 out of 1 architecture (1oo1): 

‘’This architecture consists of a single channel, where any dangerous failure leads to a failure of the 

safety function when a demand arises’’ (From IEC 61508 Part 6 Section B2.2.1). 

This architecture corresponds to HFT=0. 


‘’This architecture consists of two channels connected in parallel, such that either channel can process 

the safety function. Thus there would have to be a dangerous failure in both channels before a safety 

function failed on demand. It is assumed that any diagnostic testing would only report the faults found 

and would not change any output states or change the output voting’’(From IEC 61508 Part 6 Section 

B2.2.2). 



‘’This architecture consists of two channels connected in parallel so that both channels need to demand 

the safety function before it can take place. It is assumed that any diagnostic testing would only report the 

faults found and would not change any output states or change the output voting’’ (From IEC 61508 Part 

6 Section B2.2.3). 



‘’This architecture consists of three channels connected in parallel with a majority voting arrangement 

for the output signals, such that the output state is not changed if only one channel gives a different result 

which disagrees with the other two channels. 

It is assumed that any diagnostic testing would only report the faults found and would not change any 

output states or change the output voting’’ (From IEC 61508 Part 6 Section B2.2.5). 


2.6.3 OS function response time 

One impact that the choice of architecture has is on the OS function response time. The safety system must be 

capable of detecting the hazardous event and responding in time to mitigate its consequences, which means for 

example, for local functions involving only one controller, performing the following actions: 

1. Sense the out-of-control condition, 

2. Digital filtering of input signal, 

3. Input process scan time, 

4. PLC program scan time, 

5. Any trip delay timers set to remove process noise must time out, 

6. Output process scan time, 

7. Digital filtering of output signal, 

8. Fully actuate the output device. 

If several PLCs are involved in the OS function (central functions or local functions involving several PLCs), the 

communication time and PLC program scan time of each PLC must be added. 

Page 25 of 95

How much time the safety system has to respond depends on the dynamics of the process and the conditions 

initiating its actions. The available process safety time for any given safeguard starts when it is necessary to take 

action and ends at the point where the event can no longer be prevented. 

The process safety time is defined as the time period between a failure occurring in the process or the basic 

process control system (with the potential to cause a hazardous event) and the occurrence of the hazardous event if 

the safety instrumented function is not performed. 

Process Limit 

Hazardous event 

Fault Not Managed 

Fault Managed 

Activation Point 

Process Safety Time 

Fault Occurs 

Sensor 

detection 

time 

Fault Detected 

Time to React 

Action Taken 

Actuator 

time 

Process Reacts 

Cushion 

Figure 2.15: Time to respond to abnormal situations 

The time to react is data defined for each OS function. It determines the techniques to use for the implementation 

of the function. The time to react is the time elapsed between the risk occurrence and the mitigation request (when 

action is requested). 

In the case of a central function, this time constraint has to be shared between the different parts of the function 

(the different PSS-OS and the CSS-OS). 

Page 26 of 95

3 SCS-OS Introduction 

The SCS-OS is formed by the OS Central Safety System and the different plant safety systems for occupational 

safety of each plant system. 

The OS Central Safety System (CSS-OS) is linked to local parts, the Plant Safety Systems (PSS-OS), by a 

redundant Central Safety Network (CSN-OS). 

To meet all OS requirements, the CSS-OS System is composed of a safety logic system (to coordinate OS central 

functions) and a SCADA system (to supervise all local and central OS functions). 

The following sections focus on the different OS human machine interfaces designed to be used by the various OS 

actors. 

Note: The elements are described here mainly for information purposes, as the PSS-OS designer will finally build 

the interface with those components, even if in some cases it is an indirect interface. 

The different software tools associated with each component are developed in chapter 8 – Software. 

3.1 OS HMIs 

There are four dedicated human machine interfaces for the occupational safety System: 

- CSS-OS operating terminals, 

- Safety critical hardwired HMI, 

- CSS-OS maintenance terminals, 

- SIEMENS engineering workstation. 

Page 27 of 95

Control-room 

Safety Critical 

Hardwired HMI 


Terminal 

Server-room 

SIEMENS 

Engineering 

Workstation 


Maintenance 

Terminal 


Safety PLC 


Server 

PLC IOC 

PSSx-OS 

Plant systems 


Safety critical component 

Safety monitoring component 

Figure 3.1: OS HMIs and associated components 

Caution: the redundancy in the Control Room and the Server Room is not represented in figure 3.1. 

The figure above focuses on the different human machine interfaces (the other CSS-OS components are not 

represented). 

The routine access to the various PSS-OS is done from the control and server rooms using the SCS-OS 

infrastructure. The PSS-OS will mainly connect to two interfacing components: the CSS-OS Safety PLC 

associated with the safety critical hardwired HMI and the CSS-OS server PLC IOC. 

Note: The CSS-OS Server PLC IOC developed by PBS45 (CODAC), responds to the needs for PLC integration (it 

derives from the PSH of PBS45). 

3.1.1 CSS-OS Operational Components 

There are two types of operational component: 

The Safety Critical Hardwired HMI, 

The OS SCADA. 

Page 28 of 95

3.1.1.1 Safety Critical Hardwired HMI 

When the monitoring (or control) impacts on the triggering of safety actions and also requires a safety level (SIL), 

a very reliable (hardwired) supervisory device will be designed. 

It may be required for “not fully automatic” high occupational risks that require a human response (i.e. command) 

to trigger the safety function, or to display critical occupational safety function alarms or states. 

The redundant safety critical hardwired HMIs are located in the control rooms and are connected to the CSS-OS 

Safety PLC through specific redundant remote I/O stations. 

Note: This component only concerns a very few occupational safety parameters. 

3.1.1.2 OS SCADA 

The OS SCADA is done through the CSS-OS terminals located in the control rooms. They support the 

monitoring (and control) and have no impact on the actuation of an OS function. Support is via: 

 

 

 

OS process views (Global and detailed) (in CSS-OS scope), 

Alarm list views (in CSS-OS scope), 

Archived data list views (in CSS-OS scope). 

The main feature for an OS function is the reset command. The OS reset commands are sent by authorised 

operators from the CSS-OS operating terminals using the detail views. These commands are needed for OS 

operation but cannot modify the critical machine protection configuration of the PSS-OS. They are transmitted via 

the redundant CSN-OS. 

Note: The CSS-OS terminal technology is a dedicated CODAC Core System and the interface to the PSS-OS is 

through the CSS-OS Server PLC IOC. 

The CODAC Core System distribution includes the tools to build the EPICS software that is necessary for 

integrating PLCs into the CODAC infrastructure. 

The communications between the CSS-OS Server and the S7 PLCs are based on an existing EPICS driver (SLS 

s7plc) that has been extended by IO. 

These communications are implemented by means of exchanges of variables between the CSS-OS server and the 

PLCs. 

From the operator interface requirements of IEC 61511-1: 

“The SIS status information that is critical to maintaining the SIL shall be available as part of the operator 

interface. This information may include: 

 

 

 

 

 

 

 

 

where the process is in its sequence; 

indication that SIS protective action has occurred; 

indication that a protective function is bypassed; 

indication that automatic action(s) such as degradation of voting and/or fault handling has occurred; 

status of sensors and final elements; 

the loss of energy where that energy loss impacts safety; 

the results of diagnostics; 

failure of environmental conditioning equipment which is necessary to support the SIS” 

3.1.2 CSS-OS Maintenance Components 

There are two types of maintenance component: 

The CSS-OS maintenance terminals, 

The CSS-OS expert stations. 

Page 29 of 95

3.1.2.1 CSS-OS Maintenance Terminals 

Through the specific CSS-OS terminals located in the server rooms, SCS-OS displays the detailed state of the 

occupational safety system to the maintenance team via: 

 

 

 

 

Slow controller hardware diagnostic supervision views (in PSS-OS and CSS-OS scope), 

Cubicle hardware diagnostic supervision views (in PSS-OS and CSS-OS scope), 

Network component hardware diagnostic supervision views (in CSS-OS scope), 

Inter-systems communication diagnostic supervision views (in CSS-OS scope). 

The CSS-OS maintenance terminals also allow override operations without disturbing the Control Room 

Operator during maintenance phases. 

Note: The CSS-OS terminal technology is a dedicated CODAC Core System and the interface to the PSS-OS is 

through the CSS-OS Server PLC IOC. 

3.1.2.2 CSS-OS Expert Stations 

An engineering workstation is necessary for changing PLC application configuration and online monitoring. This 

station contains the off-line version of the application running inside all PLC of CSS-OS and PSS-OS. 

The redundant SIEMENS engineering workstation is directly connected to CSN-OS and exchanges data with 

CSS-OS PLC and PSS-OS PLC through the SIEMENS proprietary protocol. 

Page 30 of 95

4 PSS-OS Architecture 

Each plant system will have its own PSS-OS architecture designed taking into account the following: 

Functional requirements, 

Safety integrity level and availability of each OS function, 

Type of the OS function (local or central), 

IEC 61508 & IEC 61511 requirements, 

ITER catalogues. 

All actors of the ITER I&C System (PSS-OS and CSS-OS for Occupational Safety) will use [RD13], the ITER 

Catalogue for Slow Controller [ITER_D_333J63]. 

This ITER Slow Controller Catalogue is composed of a selected from the SIEMENS products. 

Among these SIEMENS products, two specific fail-safe systems are available for integrating safety engineering 

into SIMATIC S7 automation systems: 

 

 

The S7 Distributed safety System, 

The S7 F/FH System. 

Each system has specific hardware components and software tools associated with it: 

 

 

The first system (S7 Distributed safety System) will be used by the PSS-OS to build standard availability 

architectures (for SIL2 and SIL3 OS functions), 

The second system (S7 F/FH System) will be used by the PSS-OS to build high availability architectures 

(only for specific OS functions). 

Note 1: Some hardware components are common between the 2 SIMATIC S7 systems (principally, remote I/O 

station and safety I/O modules). 

Note 2: No SIL4 occupational safety functions have been identified yet. 

The functional requirements may require an: 

Interface with the CSS-OS SCADA, 

Interface with the CSS-OS Safety PLC (for central OS functions). 

Before describing the different PSS-OS architectures, it is necessary to list the main architectural requirements: 

1. Unless it is strictly necessary, only one PSS-OS logic architecture should be implemented per plant 

system. However, more than one architecture may be found inside the same plant system when it hosts 

different PSS-OS (it may be necessary to implement safety functions in several PSS-OS due to 

application size and complexity, or distribution throughout the site). 

2. Ideally one plant system contains only one plant safety system which is solely responsible within the 

plant system for the local and central safety function. The PSS controls and monitors the occupational 

safety sensors and actuators via the plant safety networks and it constitutes the interface to the CSS-OS 

via the central safety networks. 

3. Whenever possible, only one PSS-OS in the plant system is connected to the CSS-OS via the CSN-OS. 

This master PSS-OS of the plant system is the single access point to CSN/CSS. 

4. Each field network must be totally independent (no link between two occupational safety field networks 

or other field networks (from CODAC System or Interlock System)). 

Page 31 of 95

4.1 PSS-OS standard availability architectures 

The PSS-OS standard availability architectures demonstrate the occupational safety architecture needs when 

standard availability is required. 

These architectures are designed to satisfy safety class requirement (Safety Integrity Level) from SIL2 to SIL3 in 

accordance with IEC 61508. 

The standard availability architectures use components selected from the S7 Distributed Safety System catalogue 

and the S7 F/FH System catalogue available on [RD13], ITER Catalogue for slow controllers [ITER_D_333J63]. 

From one availability objective and two I/O configuration concepts, come three architectures. These three 

architectures using both S7 Safety Systems are proposed for the PSS-OS to cover most needs. 

1 Objective 

Standard Availability 

PLC Configuration 

2 I/O Concepts 

Integrated I/O 

Remote I/O 

3 Architectures 

S7 Distributed 

System 

S7 300F CPU 

S7 Distributed 

System 

S7 300F CPU 

S7 F/FH 

System 

S7 400H CPU 

Figure 4.1: Standard Availability Architecture definition 

4.1.1 Integrated I/O configuration 

This architecture will be used for the PSS-OS hardware configuration which only has a few I/O and is located near 

the PSS-OS cubicle. 

This is a basic and compact architecture without field network and remote stations. 

General requirements for this architecture are: 

 

 

 

 

A single CPU, 

A single rack, 

Associated safety I/O modules, 

A redundant connection with the redundant occupational safety acquisition networks. 

Only one rack (station) is necessary for the single CPU and the associated modules (power modules, network 

modules and I/O modules). 

The safety I/O modules are operated as centralized modules in the single rack. 

In order to connect the PSS-OS to the CSS-OS, the single CPU is connected to the redundant CSN-OS acquisition 

network. 

Detailed application for this architecture: 

 

 

A single SIMATIC S7-300F-2PN/DP Central Processing Unit (CPU), TÜV approved to SIL3, 

A single SIMATIC S7-300 rack equipped with the associated SIMATIC S7-300 Safety I/O modules. 

Page 32 of 95

The characteristics of the selected hardware components are described in chapter 7. The characteristics of the 

associated software tools are described in chapter 8. 

CPU 

Safety I/O modules 

Figure 4.2: SIMATIC S7-300 rack mainly equipped with S7-300F CPU and S7 Safety I/O modules 

I&C Architecture 


Server PLC 

IOC 

CSN – OS1 



SIMATIC S7 

SIMATIC S7 

CPU 300F 

CPU 315F 

2 PN/DP 

PN/DP 

SENSOR 

ACTUATOR 

Figure 4.3: integrated I/O configuration example for an OS local function 

Page 33 of 95

Note: In a local function case, the PSS-OS configuration has only one interface with the CSS-OS (CSS-OS 

SCADA through the CSS-OS Server PLC IOC). 

I&C Architecture 


Server PLC 

IOC 


Safety PLC 




SIMATIC S7 

CPU 315F-2 300F -2 PN/DP 

SENSOR 

Figure 4.4: integrated I/O configuration example for an OS central function 

Note: In a central function case, the PSS-OS configuration has two interfaces with the CSS-OS (CSS-OS SCADA 

and CSS-OS Safety PLC). 

4.1.2 Remote I/O configuration 

This architecture will be used for the PSS-OS hardware configuration when there are decentralized needs or a 

large number of I/O. 

This is a standard but is not a compact architecture like the integrated I/O configuration described above. 

Unlike to the integrated I/O configuration, the remote I/O configuration is an architecture with a field network and 

remote station(s). 

Page 34 of 95

This architecture has two types of station (or rack), S7-300 station and S7 remote I/O station. 

The single CPU and the associated modules (power modules, network modules) are located in the S7-300 station 

(identical to the integrated configuration). The safety I/O modules are located in one of the two types of station 

(S7-300 station and S7 remote I/O station) according to the plant system needs. 

In order to link the PSS-OS to the CSS-OS, the single CPU is connected to the redundant CSN-OS acquisition 

network. 


A single CPU, 

A single CPU station (rack), 

A single field network, 

A minimum of one remote I/O station, 




 

 

 

 

 

A single SIMATIC S7-300F-2PN/DP Central Processing Unit (CPU), TÜV approved to SIL3, 

A single SIMATIC S7-300 station (rack), 

A single ProfiBus / ProfiSafe field network, 

A minimum of one SIMATIC ET200M remote I/O station, 

Associated SIMATIC S7-300 Safety I/O modules. 



Safety I/O modules 

Figure 4.5: SIMATIC ET200M remote I/O station equipped with Safety I/O modules 

Page 35 of 95



SIMATIC 

SIMATIC 

S7 

S7 

CPU 

CPU 

315F-2 

300F -2 

PN/DP 

PN/DP 


PSN – OS 

PROFIBUS 

To other 

Remote I/O 

SIMATIC S7 

ET 200M 

Figure 4.6: remote I/O configuration principle 

4.1.3 Specific remote I/O configuration 

In the case of particular PSS-OS needs, the remote I/O configuration can be improved by using a powerful CPU 

from the S7 F/FH SIMATIC Safety System instead of the standard SIMATIC S7-300F-2PN/DP CPU from the S7 

Distributed Safety System. 

The choice between the two remote I/O configurations has to be made according to the process requirements (size 

for example). 

The main difference between configurations is the CPU model, which have different CPU technologies and 

different software for the safety management. 

The main parameters which have to be taken into account for the definition of the PSS-OS PLC: 

- The quantity of hardware inputs / outputs , 

- The PLC control unit speed. 

This specific architecture should be used when the system to be controlled requires more than 200 inputs/outputs 

or when fast CPU execution is required. 


A single CPU, 

A single CPU station (rack), 

A non-redundant field network, 

A minimum of one remote I/O station, 



Page 36 of 95

Caution: Unlike the next configuration, the S7-300 safety I/O modules are only located in the remote I/O station. 

The safety I/O modules are not compatible with the S7-400 station. 


A single SIMATIC S7-400-5H Central Processing Unit (CPU), TÜV approved to SIL3, 

A single SIMATIC S7-400 station (rack), 

A non-redundant ProfiBus / ProfiSafe field network, 

A minimum of one SIMATIC ET200M remote I/O station equipped with the associated SIMATIC S7- 

300 Safety I/O modules. 



Figure 4.7: SIMATIC S7-400 station mainly equipped with S7-400 5H CPU 



SIMATIC S7 

CPU 400 5H-2 PN/DP 


PSN – OS 

PROFIBUS 

To other 

Remote I/O 

SIMATIC S7 

ET 200M 

Figure 4.8: specific standard availability configuration principle 

Page 37 of 95

4.2 PSS-OS High availability architecture 

The PSS-OS high availability architecture demonstrates the occupational safety SIL3 architecture needs when 

high availability is required. 

A philosophy of redundancy is applied to all components (CPU, field network, remote I/O station and associated 

safety I/O modules). 

The high availability architecture uses components selected from the S7 F/FH System catalogue available from 

[RD13], the ITER Catalogue for slow controllers [ITER_D_333J63] (CPU and associated CPU station). 


 

 

 

 

 

 

Two redundant CPUs, 

A minimum of one CPU station (rack), 

A minimum of two redundant remote I/O stations (1oo2 evaluation case), 

Two redundant field networks, 




Two redundant SIMATIC S7-400-5H CPU, TÜV approved to SIL3, 

A minimum of one SIMATIC S7-400 station (rack), 

Two redundant ProfiBus / ProfiSafe field networks, 

A minimum of two redundant SIMATIC ET200M remote I/O stations equipped with associated S7-300 

Safety I/O modules (1oo2 evaluation case). 

Each redundant CPU is connected to only one redundant CSN-OS network (CSN-OS 1 or CSN-OS 2). 

Both CPUs are connected redundantly to all safety I/O modules via the redundant field networks (each remote I/O 

station is linked to the two redundant field networks). 



Page 38 of 95



SIMATIC S7 

CPU 400-5H 

REDUNDANT 

SIMATIC S7 

CPU 400-5H 


PSN – OS1 

PROFIBUS 

PSN – OS2 

PROFIBUS 

SIMATIC S7 

ET 200M 

To other 

Remote I/O 

REDUNDANT 

SIMATIC S7 

ET 200M 

Figure 4.9: redundant I/O configuration principle 

Figure 4.9 represents an architecture associated with an OS function with a 1oo2 sensor evaluation and a 1oo1 

actuator evaluation. 

Note: A third remote I/O station will be added in the case of a 2oo3 evaluation (sensor or actuator). 

There are two possibilities for the redundant CPUs layout. The first option (figure 4.9) has each CPU located in 

separate stations and also in a specific cubicle. The second option has the two redundant CPUs located in only one 

cubicle and in the same station. 

4.3 Specific PSS-OS inter-exchanges 

The PSS-OS exchanges with PSS-OS from other plant systems are performed exclusively through the CSS-OS. 

Each PSS-OS is connected to the CSS-OS via the CSN-OS (industrial Ethernet) for all occupational safety 

functions (local or central). 

In some special cases, one plant system may host more than one PSS-OS. This is the case for plant systems with 

I&C procured by different Domestic Agencies or formed by components geographically separated over the site. 

In these cases, there are two possibilities: 

The OS functions are shared among the different PSS-OS PLC via the PSN-OS network, 

The OS functions are shared among the different PSS-OS PLC via the CSN-OS network. 

Page 39 of 95

First case: 

In order to have only one connection point with the CSN-OS networks, one PLC is declared as concentrator (or 

master) to manage the communications with the CSS-OS. 

Connection point 

CSS-OS and others PSS-OS 

CSN-OS Backup 

CSN-OS Main 


PLC 

Plant Safety System 1 

Concentrator or Master 


PLC 

PSN-OS 

PROFIBUS DP 



PLC 

Plant Safety System n 

Figure 4.10: PSN-OS exchange principle 

Page 40 of 95

Second case: 

CSS-OS and others PSS-OS 

Industrial Ethernet 

CSN-OS Backup 

CSN-OS Main 

PSS-OS 1 PSS-OS 2 

PLC 

PLC 



Figure 4.11: CSN-OS exchange principle 

4.4 Hardwired architecture 

Up to SIL3 requirements, Safety PLC solutions are generally less complex than large hardwired systems. They 

provide more flexibility, diagnostic and troubleshooting features and the easiest communications through the 

network architecture. 

In spite of these general statements and for some specific cases, OS functions can be implemented using a 

hardwired architecture if there are particular requirements that make it more appropriate. 

These situations have to be discussed within IO on a case by case basis. 

Page 41 of 95

5 Sensors and actuators 

Each Plant System must follow various IEC 61508 requirements in order to select each sensor and actuator. The 

first section of this chapter presents the IEC 61508 requirements to be followed. 

The second part of this chapter concerns the sharing of sensors and actuators, if required, between the different 

I&C Central Systems (CODAC, Interlock or Safety). 

5.1 IEC 61508 requirements and concepts 

Instrumentation using sensors and actuators poses considerable safety responsibilities. 

Suitably qualified sensors and actuators are necessary to achieve the safety integrity level of the OS functions. 

The following requirements and concepts should be taken into account for sensor design and for final control 

element architecture: 

Quantitative requirements (probability of failure, refer to section 2.3.2.1), 

Qualitative requirements (hardware fault tolerance, refer to section 2.3.2.2), 

“Proven in use” concept, 

Diversity concept, 

Fail-safe concept. 

The following sections describe the last 3 items. 

5.1.1 Proven in use components 

If a sensor or actuator which has not already been certified is identified, then the Plant System designer may turn 

to “proven in use” components. 

From IEC 61511 Part2 Section 11.5.3.1: 

“There are very few field devices (sensors and valves) that are designed per IEC 61508-2 and IEC 61508-3. Users 

and designers will therefore have to depend more heavily on using field devices that have been “proven-in-use””. 

Refer to [RS2], IEC 61511 standard parts 1 & 2 section 11.5.3.1 for more details about Proven in use concepts and 

requirements. 

5.1.2 Diversified components 

To limit common mode of failure, whenever possible, the choice of redundant instruments should be diversified 

(use of different technologies or different manufacturers). 

5.1.3 Fail-safe components 

5.1.3.1 Definition 

In the event of a failure, a fail-safe component or system will automatically switch to a safe state. 

In particular: 

 

 

In the case of a fail-safe sensor failure, the system will automatically switch to a safe state thanks to 

health monitoring of the signal used. 

In the case of failure of a de-energized to trip actuator, the system will automatically switch to a safe state 

in case of loss of power supply or loss of signal thanks to the safe position of the actuator. 

Page 42 of 95

5.1.3.2 Principles 

Apart from some specific cases, the design of Plant System must use fail-safe principles to initiate safety actions. 

This means that the safe position of an actuator is reached when the power to that actuator is switched off. So, in 

the event of power failure, all PLC outputs (actuators commands) will go to the de-energized condition therefore 

putting the actuators in the safe position. When the power is restored all outputs must remain de-energized until 

appropriate resets. 

Specific inputs/outputs that are energized-to-trip (not fail-safe) will have health monitoring on the line (supervised 

digital input and supervised digital output). 

5.1.3.3 Energized to trip & de-energized to trip concepts 

A safety system is typically designed as normally energized (de-energize-to-trip) so that it is fail-safe. 

If there is loss of power or loss of connectivity between system components then the I&C System will respond by 

a tripping action. This result in higher safety integrity, but it can also result in more spurious trips of the process. 

Figure 5.1: De-energized to trip principle 

In some cases, a spurious trip can have dangerous results. For example, initiating a water deluge system inside a 

building can cause damage to equipment and can be hazardous to personnel. Chemical fire suppression can be 

dangerous to personnel, and false alarms degrade the willingness to respond by plant personnel. Energized to trip 

systems can help address this type of situation. 

In an Energized to trip design, the safety loop has to be energized in order to initiate a trip of the safety system. 

This means that failures such as loss of power or loss of connectivity between components have to be managed by 

adequate diagnostics to detect the failures. In an energized to trip design, line monitoring is essential to detect 

open-loops and short circuit failures in wiring between logic solver I/O and field devices. 

Figure 5.2: Energized to trip principle 

5.1.3.4 Signal monitoring 

From field devices of IEC 61511 Part1: 

”Energizing to trip discrete input/output circuits shall apply a method to ensure circuit and power supply 

integrity”. 

Page 43 of 95

5.1.3.4.1 Definition 

The signal monitoring consists of continuously checking the validity of the signal. 

First of all, it is important to differentiate between a contact normally opened and an opened contact due to a fault 

such as an open loop. In the same way, it is important to make the difference between a closed contact and a short 

circuit. 

Indeed, when the safety function is solicited, the signal must work and has to be sent to the safety system. 

The signal monitoring allows a maintenance action to be launched when a signal is not valid. In this way the 

signal can be repaired and the I&C system will be fully operational again. 

5.1.3.4.2 Application 

mA 

Case 4 

SIGNAL INVALID 

(short circuit) 

SAFETY 

ACTIVATED 

20,007 mA 

Case 3 

SIGNAL VALID 

(unsafe condition) 

SAFETY 

ACTIVATED 

x mA 

Case 2 

SIGNAL VALID 

(safe condition) 

SAFETY NOT 

ACTIVATED 

3,9995 mA 

Case 1 

SIGNAL INVALID 

(open circuit) 

SAFETY 

ACTIVATED 

0 mA 

Figure 5.3: Fail-safe principle 

Example with an analogue sensor: 

The first objective for this analogue sensor, checking a process variable, is to switch from safe condition to unsafe 

condition according to the x mA threshold monitoring. 

The second objective for this sensor is to switch from signal valid to signal invalid through the monitoring of the 

signal validity values (3.9995 mA and 20.007 mA). In this condition, the signal monitoring checks for the invalid 

areas (case 1 and case 4): 

Case 1: if the loop is opened, the system will receive 0mA. 

Case 2 and 3: if the transmitter is online and OK, the system will receive a value between 4 and 20mA. 

Case 4: if the transmitter is in short circuit, the system will receive over 20mA. 

Surveillance of invalid areas facilitates automatic switching to a safe state. 

5.1.3.5 Conclusion 

Fail-safe principles must be taken into account during sensor and actuator design for Plant System. 

Wherever there is a choice, analogue signals should be used in preference to digital on/off states. 

The energized to trip concept should only be used if the de-energized to trip concept is not applicable, or if 

spurious actuation can cause damage to equipment and can be hazardous to personnel. 

Page 44 of 95

For energized-to-trip sensors, line health monitoring must be used. 

5.1.4 Sensors and actuators connection to Safety Modules 

In standard availability architecture, redundant sensors and actuators can be connected to different safety modules 

on the same remote I/O station. If the amount of I/O requires additional peripheral racks, then the redundant I/O 

must be connected to different racks. 

In high availability architecture, redundant sensors and actuators must be connected to different remote I/O 

stations. In case of 2oo4 voting, the redundant components can be distributed over 3 racks. 

5.2 Sharing of sensor or actuator between Occupational Safety, 

Conventional Control and Investment Protection Systems 

5.2.1 Sharing of Sensor 

If a sensor has to be shared between Occupational Safety System and Interlock System or between Occupational 

Safety System and Conventional control System, the preferred solution is to duplicate it (together with its 

redundancy) and to totally separate the systems, linking one to the PSS-OS and the other to the PIS or the PSCC. 

If the sensor cannot be duplicated, specific solutions should be studied case by case. 

5.2.2 Sharing of actuator 

If an actuator has to be shared between Occupational Safety System and Interlock System or between 

Occupational Safety System and Conventional control System, the preferred solution is to duplicate it (together 

with its redundancy) and to totally separate the systems, linking one to the PSS-OS and the other to the PIS or the 

PSCC. 

When the actuator cannot be duplicated two solutions are proposed: 

 

Solution 1: As PSS-OS is the most critical system, it takes control of the actuator, sharing its commands 

via the CSS-OS / CODAC interface (non-secured) or the CSS-OS / CIS interface (secured). The 

command priority of the actuator is managed in the most critical system (PSS-OS). The priority 

management is based on relay technology in the actuator power cubicle. 

 

Solution 2: The actuator is shared but the command is performed separately by each system. The actuator 

respects the fail-safe principle, any system commanding the actuator in safe position has priority. 

Example: A valve can be finely regulated by conventional control but can also be reliably set in two 

single states (open-closed) by the safety system (the regulation loop controlled by the conventional 

system is opened by a safety relay controlled by the safety system: when the loop is opened, the valve 

goes to a safe position). 

Page 45 of 95

6 Networks 

6.1 Connection between PSS-OS and CSS-OS 

The PSS-OS is linked to CSS-OS through the CSN-OS Network. 

The PSS-OS will be connected to both the Main and Backup CSN-OS Networks through the closest CSN-OS 

Network Panel hosting CSN-OS. The link between PSS-OS Network Cubicle and CSS-OS Network Panel should 

use fibre-optic cables as follows: two optical strands for CSN-OS Main Network and two optical strands for CSN- 

OS Backup Network. 

The CSN-OS Network Panel, commonly called Safety Network Panel (SNP), is a passive wall-mounted patch 

panel which is the physical termination point for the CSN-OS Network. The CSN-OS Network Panels are 

installed at strategic locations close to the plant system I&C cubicles concerned by OS. 

A typical network panel layout is shown on the Figure below. 

Figure 6.1: PBS48.OS Network Panel 

The PSS-OS owner (RO) is in charge of connecting the PSS-OS Network to the CSN-OS Network, as described in 

the Interface Sheets between PBS.48 and the PBS of the PSS. 

The CSN-OS Network is based on two protocols which ensure communication: 

 

 

To connect PSS-OS Safety PLCs to the CSS-OS Safety PLC – SIMATIC S7 connection on Industrial 

Ethernet support, 

To connect PSS-OS PLCs (conventional and safety) to the CSS-OS SCADA – Open IE on Industrial 

Ethernet. 

Page 46 of 95

Figure 6.2: PSS-OS scope 

Note 1: Refer to chapter 7 – Hardware about OS network components requirements. 

Note 2: Due to high magnetic fields and radiation levels, no safety I&C Logic control cubicles will be installed 

inside the Tokamak Building (B11). 

Refer to [RD6], the ITER_Policy_on_EEE_in_Tokamak_complex_ITER_D_6ZX6S3 and [RD7], 

Guidance_for_EEE_in_Tokamak_Complex_ITER_D_7NPFMA documents for more details. 

6.2 Connection between PSS-OS and the I/O modules 

The connection between the PSS-OS and its remote periphery is part of the PSN-OS. 

The SIMATIC fail-safe signal modules will be operated in the SIMATIC ET200M distributed I/O system. Safety 

communication between the safety program in the F-CPU and the fail-safe I/O modules takes place via the 

standard ProfiBus DP with ProfiSafe safety profile. 

Page 47 of 95

PBS.X Cubicle 

MAIN SWITCH 

BACK-UP SWITCH 

RJ45 

RJ45 


Rack 0 

PSa PSb CPU C 

P 

a 

C 

P 

b 

Sensor a 

Bus 0 Profinet 


Bus 0 Profibus 

DP 

Sensor b 

Actuator a 

Actuator b 

DP 

PSS-OS Periphery 

Rack 1 

IM0a DIa DIb DOa DOb AI 

AI 

Figure 6.3: Connection between PSS-OS and an I/O 

In the case of architecture with high availability, the ProfiBus network must be redundant: each redundant CPU is 

connected to all the peripheral racks using two interface modules per rack as shown on the figure below: 

Page 48 of 95

PBS.X Cubicle 

MAIN SWITCH 


RJ45 

RJ45 


Rack 0 

PS0a PS0b CPU 

0 

C 

P 

0 


Rack 1 

PS1a PS1b CPU 

1 

C 

P 

1 

Sync 

10m 

Sync 

10m 

DP 

FO (2m) 

FO (2m) 

Sync 

10m 

Sync 

10m 

DP 





Sensor a 

Actuator a 


Rack 2 

DP 

DP 

IM0a IM1a DIa DI DOa DO DO DO AI 

Sensor b 

Actuator b 

DP 

DP 


Rack 3 

IM0b IM1b DIb 

DI DOb DO DO DO AI 

Sensor c 

Actuator c 

DP 

DP 

IM0c IM1c DIc 

DI DOc DO AI 


Rack 4 

Figure 6.4: Connection between PSS-OS and Multiples I/O 

In the case of a long distance for the ProfiBus I/O bus, it is possible to use optical link modules. 

6.3 Connection between different PSS-OS in the same plant system 

Some specific cases may require a direct interconnection between different PSS-OS in the same plant system 

without contribution from the CSS-OS. This has to be considered as a deviation from the principles and the ITER 

Organization has to approve it. This interconnection is a part of the PSN-OS. 

The number of PSS-OS inside the same plant system should be kept as low as possible and it can only increase 

when justified, for example by geographical or operational reasons. 

Page 49 of 95

The connection from PSS-OS to the PSS-OS connected to the CSS-OS, inside the same plant system, is dedicated 

for the exchange of critical safety data. 

The link between several PSS-OS in the same plant can be hardwired or computerized and can also be single or 

redundant to satisfy availability requirements. In the case of SIL-3 functions, this connection should be redundant. 

An example of connection between different PSS-OS in the same plant system is shown in section 4.3 Specific 

PSS-OS inter-exchanges. 

6.4 Connection between different PSS-OS in different plant systems 

The direct connection between plant safety systems for occupational safety belonging to different plant systems is, 

in principle, not allowed. This has to be considered as a deviation from the principles and the ITER Organization 

has to approve it. These exceptions can be made for performance or integrity reasons. 

An example of connection between different PSS-OS in different plant systems is shown in section 4.3 Specific 

PSS-OS inter-exchanges. 

Page 50 of 95

7 Hardware 

This chapter presents: 

 

 

A description of the hardware involved in the architectures described in chapter 4 – PSS-OS 

Architectures and chapter 6 - Networks. 

The technical requirements applicable to these hardware components. 

The logic components used in the PSS-OS architectures must come from the [RD13], ITER Catalogue for I&C 

Products – Siemens S7 PLC catalogue [ITER_D_333J63]. 

7.1 PSS-OS PLC 

Two fail-safe systems are available for integrating safety engineering into SIMATIC S7 automation systems: 

 

 

The S7 Distributed safety System, 

The S7 F/FH System. 

Each system has specific hardware components and software tools associated with it. The main characteristics of 

the components selected for occupational safety needs are described below. 

Refer to section 8.1 – SIEMENS tools for more details about the associated software tools. 

S7-300F-2PN/DP CPU 

Derived from the S7 Distributed Safety System, 

Failsafe automation system for plants with increased safety requirements, 

Complies with safety requirements to SIL3 in accordance with IEC 61508, 

Based on S7-300, 

ET200M distributed I/O stations with safety-related modules can be connected, 

Communication to EPICS SCADA front-ends via Industrial Ethernet 100 Mbits/s, 

Safety-related communication to remote I/O station via ProfiBus DP with ProfiSafe profile. 

S7-400-5H CPU 

Derived from the S7 F/FH System, 

Failsafe automation system for plants with increased safety requirements, 


Fault tolerant through redundant design, 

ET200M distributed I/O stations with safety-related modules can be connected. 

Communication to EPICS SCADA front-ends via Industrial Ethernet 100 Mbits/s, 

Safety-relevant communication to remote I/O station via ProfiBus DP with ProfiSafe profile. 

If the Plant System requires a standard availability architecture, S7-300F-2PN/DP CPU with distributed 

safety software should be used. 

If the Plant System requires a specific standard availability architecture or a high availability architecture, 

S7-400-5H CPU with F-system software should be used. 

If the Plant System monitors/controls more than 200 inputs/outputs, S7-400-5H CPU with F-system can be 

used. 

Page 51 of 95

S7 ET200M remote I/O 


Safety-relevant communication to CPU via Redundant ProfiBus DP with ProfiSafe profile, 

Safety modules compatibility, 

Standard modules compatibility for non-safety-related applications. 

S7 Safety Modules 

Compared to the standard modules of the S7-300 module family, the fail-safe signal modules differ in terms of 

their internal dual-channel structure. The two integrated processors monitor each other, automatically test the I/O 

circuits and force the fail-safe signal module into safe state when a fault/error has been detected. The F-CPU 

communicates with the fail-safe signal module by means of the safety-oriented ProfiSafe bus profile. 


Support applications for S7-300 system (centrally in S7-300 station and distributed in ET200M 

station) and for S7-400 system (distributed in ET200M station), 

Digital Input module, 

Analogue Input module, 

Digital Output module. 

Refer to [RD13], the ITER Catalogue for I&C products – Slow Controllers [ITER_D_333J63] for more details 

about these components and about complementary components like the power and communication modules. 

Refer to appendix 1 for complete and detailed lists of hardware component for each architecture proposed in 

chapter 4 – PSS-OS architectures. 

7.2 PSS-OS cubicles 

I&C Cubicles are standardized and specified in: 

- [RD12], ITER catalogue for I&C products – Cubicles [ITER_D_35LXVZ], 

- [RD14], Guidelines for I&C Cubicle Configurations [ITER_D_476HUG], 

- [RD2], Plant Control Design Handbook [ITER_D_27LH2V]. 

The components belonging to the PSS-OS are hosted in dedicated PSS-OS cubicles which must not be shared with 

conventional control or plant interlock systems. 

All electrical components (power supplies, circuit breakers…) have to be fully accessible and easily removable in 

order to be replaced even if the cubicle is still powered (use of DIN rail is preferred). 

For maintenance purposes, cubicles should be installed as far as possible from the sources of disturbances of 

Building 11 and in areas which are accessible during plasma operation. 

7.2.1 Cubicle Monitoring 

The standard I&C cubicle for ITER includes a monitoring system. Its final hardware configuration will depend on 

the specific cubicle form factor. This system will be provided by the PSS-OS. 

The PSS-OS cubicle configuration must comply with the design specifications for hardware integration of the 

monitoring system in I&C cubicle specified in [RD17], the I&C cubicle internal configuration 

[ITER_D_4H5DW6]. 

Occupational Safety particular design point: 

Each PSS-OS cubicle monitoring system should be connected to the CSS-OS via the CSN-OS as opposed to the 

PON network of the CODAC system. 

Page 52 of 95

7.3 PSS-OS Switch 

The connection between the PSS-OS and the CSN-OS is made through the PSS-OS switch to the closest Safety 

Network Panel (SNP). 

The plant system must provide the redundant fibre-optic connection up to the SNP (two optical strands singlemode 

for CSN-OS Main Network and two optical strands single-mode for CSN-OS Backup Network). These 

connections will include spare strands for maintenance or future growth of the system. 

The PSS-OS owner (RO) is in charge of connecting the PSS-OS to the CSN-OS Networks, as described in the 

Interface sheets between PBS.48 and the PBS of the PSS-OS. 

7.3.1 Conceptual principles 

The CSN-OS networks are a single-mode fibre-optic interface and are capable of transmit all PSS-OS information, 

such as safety communication and monitoring data under the Ethernet communication protocol. 

It will also be in charge of converting data from the fibre-optic interface to the copper hardware interface. 

Inside each cubicle, two switches are dedicated to one CSN network (one switch per CSN) to manage several 

functionalities, like safety communication management, diagnostics… 

Figure 7.1: Power supply redundancy principle 

7.3.2 Switch Specifications 

The characteristics required are: 

- Managed switch, 

- One Single-mode fibre-optic interface port, 

- A minimum of 3 RJ45 interface ports, 

- 24Vcc power supply redundancy management, 

- Security management (filtering by IP and MAC), 

- SNMP management, 

- Ethernet profile. 

The network equipment must be chosen from the ITER Catalogue of I&C products for Networks products. 

Page 53 of 95

7.4 PSS-OS signal cabling 

When signal redundancy is required, the redundant cables should be kept as separate as possible but they may be 

routed through the same cable tray. 

7.4.1 PSN-OS Network 

The connection between the PSS-OS and its remote periphery is part of the PSN-OS. 

In the case of a long distance for the ProfiBus I/O bus, it is possible to use optical link modules. 

The communication cables may be routed together with the conventional control cables. 

7.4.2 Sensor / actuator 

It is recommended that sensor / actuators signals are connected to the SIMATIC I/O modules through terminal 

blocks. It is advisable to install an external protective circuit in order to provide sufficient surge strength to an 

ET200M with fail-safe signal modules. It is recommended that the Marshalling Terminal Assembly referenced in 

the Catalogue for I&C products – Slow controllers is used. It is possible to use ABB/ENTRELEC or PHOENIX 

CONTACT equipment as recommended in the Guidelines for I&C cubicles configuration if these equipment are 

certified IEC 61508 and enable the reliability requirements to be fulfilled. 

The cables should be selected from the [RD19], the IO Cable Catalogue [ITER_D_355QX2]. 

The PSS-OS signal cabling must be compliant with: 

[RD2], Plant Control Design Handbook [ITER_D_27LH2V], 

[RD17], I&C cubicle internal configuration [ITER_D_4H5DW6], 

[RD14], Guidelines for I&C Cubicle Configurations [ITER_D_476HUG]. 

7.5 PSS-OS powering 

7.5.1 Conceptual principles 

The powering of PSS-OS cubicles must be compliant with the Electrical Design Handbook, in particular, Guide A: 

Electrical Installations for SSEN Systems [ITER_D_2EB9VT]. 

The following rules apply: 

- All PSS-OS cubicles and components must be redundantly powered, 

- The redundant powering cables must be kept as separate as possible although sharing of the same cable 

tray is permitted, 

- The mounting rail must be bonded to ground, 

- Circuit breakers must at least permit the independent power on/off of each train, each architecture and its 

periphery independently. 

- The power supplies should be monitored so that a failure of one power supply can be reported and 

repaired so that the system will not stay too long without redundancy. 

The PSS-OS cubicles are powered by two independent sources: 

Class II-IP power supply: an uninterruptible with backup by battery set of 1 hour autonomy and by a 

diesel generator available for 24 hours, 

Class IV-OL power supply: an alternative power supply in the event of class II-IP inverter failure or 

fault in the class II-IP power feeder. 

Page 54 of 95

The 24Vdc will be generated locally by redundant power supply modules using the Class II-IP or Class IV-OL 

sources. It is recommended that the power supplies for the digital I/O and the analogue inputs are separated. 

If PSS-OS equipment needs additional voltages, they should be obtained by transforming the existing voltages 

using appropriate components, which will be compliant with the SIL requirements of the function. This additional 

powering must be redundant. 

7.5.2 CPU racks 

Two families of SIMATIC CPU are used for the PSS-OS architectures and therefore there are two types of 

SIMATIC rack: the S7-300 rack and the S7-400 rack. Only the second one can be equipped with redundant power 

supplies. The solution for the S7-300 rack is to use two external non-redundant power supplies and one add-on 

module. Using diodes, the add-on module disconnects two parallel basic power devices. Failure of a single power 

supply no longer compromises the safe and uninterrupted supply of 24 volt power. 

Figure 7.2: CPU 300F Power supply redundancy principle 

Each S7-400 rack must be powered by two redundant power supply modules. The first power supply module 

should be powered by a class II-IP power supply and the second one by a class IV-OL power supply. Each power 

supply module must have two backup batteries in its battery compartment as shown on the schema below: 

Page 55 of 95

Figure 7.3: CPU 400H Power supply redundancy principle 

In the case of a redundant architecture of CPUs (high availability architecture), the same principle as above will 

apply: each CPU rack must be powered by two redundant power supply modules powered by two independent 

sources: Class IV OL and class II IP. Each power supply module must also have two sets of backup batteries in its 

battery compartment. The principle is shown on the figure below: 

Figure 7.4: Redundant CPU 400H Power supply redundancy principle 

The power supply equipment must be chosen from the [RD13], ITER Catalogue for I&C products – Slow 

Controller [ITER_D_333J63]. 

Page 56 of 95

7.5.3 Peripheral racks 

Like for the S7-300 rack, there is no dedicated redundant power module available for the SIMATIC remote I/O 

selected for the PSS-OS need (S7 ET200M). This is why the solution is identical to that for the S7-300 rack, using 

two external non-redundant power supplies and one add-on module (refer to section 7.5.2 for more details). 

PS II-IP 

PS IV-OL 

Figure 7.5: Add-on module principle 

The figure below describes the powering concept for a peripheral rack: 

DP 

IM DI DI DO DO AI AI 

PSa PSb Redundancy 

Class II-IP - 230Vac 

Redundant PS – 24Vdc 

Class IV - 230Vac 

Figure 7.6: Remote I/O Power supply redundancy principle 

In the case of a redundant architecture with multiple peripheral racks the principle stays the same: each peripheral 

rack will be powered by two power supply modules: 230Vac powered by the independent Class IV OL and class 

II IP sources, and one redundant module. 

The figure below describes the powering concept for multiple peripheral racks: 

Page 57 of 95

DP 

DP 

IM0a 

IM1a DI DI DO DO AI AI 

PSa 

PSb 

Redundancy 

1 

Class II-IP - 230Vac 

Class IV - 230Vac 


DP 

DP 

IM0b 

IM1b DI DI DO DO AI AI 

Redundancy 

2 


Figure 7.7: Remote I/Os Power supply redundancy principle 

Note: It is recommended that the power supplies for the digital I/O and the analogue inputs are separated. 

7.5.4 Network products 

Each network product (switches, electronic devices…) involved in PSN-OS or in CSN-OS should be powered by 

both of the independent sources, Class IV OL and Class II IP, as shown on the figure below: 

Figure 7.8: Switches Power supply redundancy principle 

7.5.5 Cubicle Power distribution 

Refer to the [RD14], Guidelines for I&C Cubicle Configuration [ITER_D_476HUG] for the PSS-OS application. 

Page 58 of 95

8 Software tools and requirements 

This chapter presents all the software to be used by the PSS-OS and the requirements associated with the OS 

environment. 

The PLC software, in the form of the SIEMENS tools is necessary to configure, develop and manage the 

occupational safety programmable logic controller (PLC) environment. 

The HMI software, in the form of the CODAC tools is used to develop and manage the occupational safety 

SCADA environment. 

8.1 SIEMENS tools 

The two fail-safe systems available in SIMATIC S7 automation systems (S7 Distributed Safety and S7 F/FH) 

should be evaluated according to the hardware architecture developed and the relevant availability level. 

The list of SIEMENS tools to be considered is: 

- SIMATIC STEP7 professional software, 

- SIMATIC STEP7 Optional package S7 Distributed Safety, which is only used to engineer the hardware 

and configure the occupational safety functions for architectures requiring standard availability. OS 

functions are configured in F-LAD or F-FBD languages, 

- SIMATIC STEP7 Optional package S7 F Systems, which is used to engineer the hardware and configure 

the occupational safety functions for certain architectures requiring standard availability and 

architectures which require high availability. It expands the S7-400H controller for OS functions by 

providing pre-configured blocks, certified by the German Technical Inspectorate (TÜV) according to SIL 

3 IEC 61508. OS functions are configured in Continuous Function Charts (CFC) with certified function 

blocks. 

8.2 CODAC tools 

The CSS-OS SCADA will be a dedicated SCADA using the CODAC Core System technology and associated 

configuration tools. It will provide the following set of central services: 

 

 

 

 

 

Operator interface engine, 

Alarms service, 

Data archiving service, 

Error and trace logging service, 

I&C configuration database. 

The CODAC Core System is a software package distributed by the IO CODAC Section for the development of the 

plant system I&C. It provides the plant system I&C developers with the environment required to develop and test 

the software in a way that complies with the ITER requirements. 

This software package includes: 

 

 

 

Self-Description Data Toolkit (database tool), 

Control System Studio (HMI, alarm and archiving tool), 

PLC and Fast Controllers support (interface tool). 

Note 1: The description of elements below is mainly for information, refer to [RD22], the CODAC Core System 

Overview [ITER_D_34SDZ5] for more details. 

Note 2: Delivery of the PSS-OS may require delivering CODAC configuration files, to be used on the mini CSS- 

OS for the first levels of testing. 

Page 59 of 95

8.2.1 Self-description Data Toolkit (SDD) 

The Core System includes a tool developed in-house – the Self-Describing Data (SDD) Toolkit – which allows the 

plant system I&C designers to define their plant system PVs, along with their settings and information about the 

configuration of these PVs. SDD supports configuration of all of CODAC Core, its applications, its operator 

displays and its interfaces in a self-consistent way. In particular, it is the tool for the configuration of plant system 

I&Cs. 

8.2.2 Control System Studio 

8.2.2.1 Operator Interface (BOY) 

BOY is a component of the Control System Studio toolkit. The BOY runtime environment connects to the control 

system, displays the operator interface (OPI), animates graphical widgets according to EPICS PV value, alarm 

status/severity and connection status, shows PV’s range and the definition of alarm limits and allows the operator 

to interact with the process by providing input data. 

This tool is required for the operator interface related to the OS I&C functions. 

8.2.2.2 Alarm Interface (BEAST) 

BEAST is a component of the Control System Studio toolkit. The BEAST distributed alarm system consists of: 

An alarm server that monitors alarm triggers in the control system and notifies appropriate stakeholders, 

The graphical user interface for viewing current alarms as a table or hierarchical tree, showing 

guidance, executing commands, opening dedicated displays and acknowledging raised alarms, 

A relational database for configuration and logging, 

Web reports to analyse the number and frequency of alarms. 

Configuration files are required for alarms related to the OS I&C functions. 

8.2.2.3 Engineering Archives (BEAUTY) 

BEAUTY is a component of the Control System Studio toolkit. The BEAUTY distributed archive system consists 

of: 

An archive engine that monitors EPICS PVs to be archived in the control system, 

The graphical user interface for displaying live and historic data in a plot, making some computations, 

adding annotations to the plot and exporting samples to different file formats such as Excel spread 

sheets or Matlab, 

A relational database for configuration and archiving of the samples. 

Configuration files are required for archiving associated with the OS I&C functions. 

Page 60 of 95

9 Software Interfaces and Functional Requirements 

In order to develop a homogeneous and efficient overall OS I&C system, it has been decided to standardize the 

control and monitoring parameters of the OS I&C functions, and the interface between the PSS-OS and the CSS- 

OS. This standardization will be highly beneficial from the Human Factors point of view and for the integration of 

the system. 

SCS-OS design had to take this into consideration and facilitate the integration of new OS I&C functions into the 

system as far as possible and at the same time, maintain the certification of the complete system. This means: 

• Minimizing the configuration errors related to new functions, 

• Reducing the impact of new functions on the previously installed certified functions, 

• Minimizing the non-regression tests required after the integration of new functions. 

To realize this objective, IO has standardized the OS functions concepts (states and status functions, monitored 

information, reset, override, messaging…) and the standard interface between an OS I&C function and the CSS- 

OS. It especially applies to the local OS functions. Most occupational safety functions should be functions which 

only need the CSS-OS for supervisory features and no safety processes. Moreover, occupational safety functions 

are similar enough to enable the standardization of the interface between the PSS-OS and the CSS-OS. 

When an OS I&C function can be standardized in this way, it is called a “Standard OS I&C function”. The main 

associated information and controls of the function are: 

• Inputs, 

• Outputs, 

• State of the function, 

• Override status, 

• Maintenance status, 

• Reset command, 

• Override commands. 

Only a very few occupational safety functions should require a highly reliable and available HMI or require the 

coordination of different plant systems. For central functions, functions that require display of information on the 

reliable hardwired HMI, or functions that would not adapt to the predefined standards, a more flexible 

configuration can be considered, but it should be the exception. In this case, the interface between the PSS-OS and 

the CSS-OS will be tailored to the specific needs and will be defined directly between the PSS-OS designers and 

the CSS-OS. However, all the concepts from standard functions that would be still applicable should be used: 

The interface which manages the link between a PSS-OS safety PLC and the CSS-OS SCADA (CODAC Core 

System technology) is detailed in section 9.1. This section defines the concepts applicable to all the OS I&C 

functions, and then those specifically related to Standard OS I&C function. It is an EPICS interface. 

The second interface which manages the link between the PSS-OS and CSS-OS safety PLCs (when relevant for a 

specific OS I&C function) is introduced in section 9.2. It is a SIMATIC Safety PLC interface. 

The last interface which manages the link about OS Hardware Monitoring between the PSS-OS and the CSS-OS 

SCADA is introduced in section 9.3. It is also an EPICS interface. 

9.1 OS Functional Monitoring Interface 

It is necessary to predefine some standards to manage most of the monitoring interfaces between PSS-OS safety 

PLC and the CSS-OS SCADA. The most frequent PSS-OS needs will be the local functions and emergency button 

monitoring. As far as possible, these standard interfaces should be implemented in each PSS-OS involved in an 

occupational safety function. 

Page 61 of 95

In this way, IO has standardized firstly the common OS functional concepts (states and status functions, monitored 

information, reset, override…) and secondly two OS standard EPICS interfaces. 

9.1.1 OS Common Concepts 

9.1.1.1 OS Function State and Status 

The safety logic between the inputs and the outputs will be specific to each OS I&C function, but the state of the 

function will always be synthesized by an overall status as defined below: 

 

 

 

Tripped state: 

The safety function is activated, associated safety actuators are maintained in the fail-safe position. 

Tripped condition: safety event or major failure that triggers the actuation of the safety function (fail safe 

design). 

Normal state: 

The safety function is not activated, associated safety actuators are activated in the normal position, there 

are no conditions related to the “degraded state”. 

Degraded state: 

The safety function is not activated, associated safety actuators are activated in the normal position, but a 

component of the safety function is unavailable (one sensor of a 2oo3 logic is tripped, degraded output 

configuration…). 

SEVERITY 

Normal 

A 

B 

Degraded 

D 

E 

C 

Tripped 

REFERENCE 

A 

B 

C 

D 

E 

FROM TO CONDITION 

normal degraded One of the component of the safety function becomes unavailable. 

degraded normal If all the components of the safety function become available 

degraded tripped If an event or a major failure occurs 

normal tripped If an event or a major failure occurs 

tripped normal If the operator resets AND the safety function is available 

Figure 9.2: Function States principle 

The function will also have two additional statuses associated that will be controlled by the operator from the 

CSS-OS: 

 

Override status, 

Page 62 of 95

Maintenance status. 

The override status will be set as soon as at least one input or output of the function is overridden. The overrides 

are used to disable inputs or outputs from a safety related system for maintenance activities (prevention or repair), 

to avoid trips caused by spurious signals or logic tests. 

An override can equally be applied to the inputs or outputs of the function. This may also be described as an 

inhibit or a forcing command. Strictly speaking, an ‘inhibit’ prevents something happening whereas an ‘override’ 

applies a forced state, but these two words tend to be used interchangeably. In this document, override will be 

used. 

However, the status indications of inhibited inputs and outputs stay active to provide as much information as 

possible to the operator. 

The maintenance status will be used by the operator to highlight a function that is under maintenance or during 

commissioning. This status is like a virtual flag set up by the operator on the control room’s displays as a reminder 

of this specific condition. 

This maintenance status however, has no influence on the behaviour of the safety functions, which are still 

computed. 

9.1.1.2 OS Function Reset 

Once triggered, the status of the safety function must be latched and the safety actuators must be activated to the 

safe position and remain there even if the safety event that triggered the function disappears. 

The reset command, usable from the CSS-OS SCADA, will allow all the latched safety actuators commands that 

were activated to the “Trip” state to be reset. 

The reset command will also reset all values latched during the triggering of the function (latched inputs value for 

example). 

Important requirement: The safety logic of the function must be designed so that the function’s reset command 

can only be effective if the inputs are in such a state that there is no safety event. 

9.1.1.3 Override 

By default, an override is not programmed. The override program has to be implemented as a safety program. An 

override should be programmed only if the function requires it. 

Inputs and outputs of the OS I&C function can only be overridden by maintenance operators from CSS-OS 

maintenance terminals. 

This action is performed through the function’s override controls. 

Note: A specific robust protocol guarantees that no override command can be accidentally set (human error and/or 

system failure). This protocol implemented for the data exchanges between PLC and OS SCADA ensures the 

quality of the commands. 

Caution: Override controls for an input or an output should only be implemented when demonstrated as necessary 

for the operation. 

9.1.1.4 Time stamping 

The PSS-OS PLC has to be synchronized with a unique time reference to provide correct logging of the sequence 

of events for fault analysis. 

Time synchronization of SCS-OS is done from an external clock. 

As S7 Siemens PLC accepts NTP synchronization, an NTP server is used for synchronizing all occupational safety 

SCS. 

Page 63 of 95

The goal of the time stamping function is to provide an accurate sequence of events in the archiving system for 

accident/incident analysis and accurate timing when a function activation/bypass is delayed in another I&C 

system. 

The main aim of this function is that the communication time between PLC does not affect the timestamp of 

events. For this reason, event time stamping should be performed as close as possible to the acquisition device. 

When an event happens in PSS-OS, the time stamping is done inside this PSS-OS PLC and this event is 

transmitted to CSS-OS, with this original timestamp information. 

The time reference for timestamps is the “ITER time” (=UTC time). 

9.1.1.5 Alarm Management 

Design: 

The alarm design integrates the recommendations described in the [RD23], Philosophy of ITER Alarm System 

Management document [ITER_D_3WCD7T]. 

Development tool: 

The software tool used to design the alarms is BEAST. It is a distributed alarm system consisting of alarm servers 

that monitor alarms from the EPICS IOC processes via channel access. It has a user interface for viewing the 

current alarms as well as acknowledging alarms and browsing the alarm history. 

An alarm is characterized by several specificities like: 

- Its family (Alarm, Default), 

- Its colour, 

- Its acknowledgement. 

Alarm behaviour: 

The following text is a description of a typical alarm’s behaviour: 

 

 

After a variable goes above its range, a related time-stamped alarm is set in the OS-supervision. 

This alarm is displayed in the alarm table until it has been acknowledged by an operator and whilst the 

fault is still present in the PLC. So, both conditions are required to reset the alarm. 

After an operator acknowledgement the alarm will change colour, but if the fault is still present the 

message will still remain. 

In that case, the disappearance of the fault is expected to automatically erase the alarm message. 

So the alarm variables in SDD should be configured to, “latch” and “annunciate” in order to: 

- Announce when a new alarm rises, 

- Enable the operator to acknowledge the alarm. 

Note: All alarms configured in the SDD should be also programmed in the PLC. 

9.1.1.6 Naming convention 

Refer to [RD2], Plant Control Design Handbook to the complete naming rules. 

9.1.2 Occupational Safety Standard 

9.1.2.1 OS Standard Function 

In order to cope with a large scope of future OS functions (most OS functions are likely to be local functions), an 

OS standard function was defined. Associated to this OS standard function, the whole interfaces with CSS-OS 

SCADA have been fixed. 

Page 64 of 95

Refer to section 2.5.1 for more details about OS local functions. 

The main information and controls associated with an OS function are: 

Inputs, 

Outputs, 

State of the function, 

Override status, 

Maintenance status, 

Reset command, 

Override commands. 

The maximum numbers of inputs and outputs of this OS standard I&C function are fixed. They have been 

designed to accommodate the majority of needs. If a specific function needs only a subset of these inputs and 

outputs, then they will be “disabled” by setting them to a specific “disabled” value. 

The standard function has: 

 

 

Inputs: 

o Zero to a maximum of four digital inputs available, to address the different logic combination 

(from 1oo1 to 2oo4) or different process thresholds to monitor, 

o Zero to a maximum of three analogue inputs available, to address the different logic 

combination (from 1oo1 to 2oo3), or different process values to monitor. 

Outputs: 

o Maximum three digital outputs available to control up to 3 safety actuators. 

If a function needs more inputs or outputs, it will be implemented as a specific function (see section 9.1.2.3). 

9.1.2.1.1 Detailed representation 

To implement the above concepts, the interface between the PSS-OS Safety PLC and the CSS-OS SCADA can be 

represented as shown below: 

Page 65 of 95

INPUTS 

OUTPUTS 

CSS-OS terminal 

Archiving 

Operator action / 

command 

PSS logic treatment 

Supervision display 

/ monitoring 


Archiving 

Alarming 

Standard function 

Reset command 

Maintenance Set 

Maintenance Reset 

31 

32 

33 

Function 

Function Ready to Reset 

Function State 

(Normal OR Degraded OR Tripped) 

Function overrided 

Function in maintenance mode 

38 

35 

37 

36 

Memorized state of each function input (x7) 34 

X 4 DI 

Digital input state 

Digital input invalidity 

Override Enable 

Override Disable 

15 

14 

17 

18 

X 3 AI 

Engineering value of the analog input 1 

4 x safety thresholds reached 

4 x safety thresholds value 

6 

2 

7 

3 

8 

4 

9 

5 

Analog input invalidity 11 

Override Enable 

12 

Override Disable 

13 

X 3 DO 

Digital output state 

Output invalidity 

Override Value 

Override Mode 

22 

19 

20 

21 

Override number 

24 

Override activation 

26 

Override Number 

Override Validation 

29 

30 

Override 

Override desactivation 

Override number + 10000 

27 

25 

Window override validity 

28 

Figure 9.3: OS Standard Function interface schema 

Inputs: The Left part of the figure lists the controls going from the CSS-OS terminal to the PSS-OS Safety PLC 

(red colour): 

 

 

The reset command, 

The override commands, 

Page 66 of 95

The maintenance commands. 

PSS-OS Safety PLC: The central part presents the PSS-OS Safety PLC, containing the: 

- Function data, 

- 4 Digital Inputs, 

- 3 Digital Outputs, 

- 3 Analog Inputs, 

- Override data. 

Outputs: The right part lists the exchanges between the PSS-OS Safety PLC and the CSS-OS SCADA System 

functions (monitoring, archiving and alarming) for each element of the standard function (black colour). 

Note: the numbers in green associated with each variable in the figure above, allow the link to be made with the 

details of each variable in appendix 2. 

9.1.2.1.2 SDD Translation 

The interface between the PSS-OS Safety PLC and the CSS-OS SCADA will be configured with the SDD tool 

(SDD editor software), defining all interface information. Some of the information will be specific to the function, 

while others are fixed by this standard. 

The specific information should be completed by the PSS-OS. 

Refer to section 8.2.1 for more details about the SDD tool. 

The result is three tables which can be exported from the SDD compilation. They are: 

A) Variable table, 

B) Control unit table, 

C) I/O modules table. 

A) Variable table 

This standard function contains 90 variables. A sample of a typical variable list exported can be found in 

ITER_D_DTXZMB - OS Standard SDD Template. 

Refer to appendix 2 for more details about variable table of the OS standard function typical. 

B) Control units table 

This table contains the complementary data concerning the control units (PLC, CSS-OS Server PLC 

IOC). 

The PSS-OS designer will be responsible for filling the table such as the control unit name and also the 

other information in the control units table. 

The information required will be provided by IO. 

C) I/O modules table 

This table concerns the I/O modules and is specific to the PSS-OS application. 

9.1.2.2 OS Standard Emergency Button Monitoring 

Unlike the first standard which is a standard function, the Standard Emergency button monitoring is only an 

standard event. This case arises from the large number of emergency button events which have to be implemented 

by the PSS-OS. 

Refer to section 2.5.4 for more details about OS emergency buttons. 

This event takes into account two different cases which can be encountered by the PSS-OS: 

Page 67 of 95

- Low integrity emergency button monitoring: PSS-OS will inform the CSS-OS terminal through the 

CSN about the emergency button and the display on the CSS-OS SCADA is sufficient from the safety 

point of view. 

- High integrity emergency button monitoring: In addition to what happens in the low integrity case, the 

detection of the button has to trigger a SIL 2 or SIL 3 safety action coordinated by the CSS-OS, or to be 

displayed on the safety critical display. 

Note: Plant system emergency stop devices or emergency switch off devices: Generally installed on the front 

doors to the system electrical boards or near electrical motors, these are specifically to stop the process when a 

problem is detected by an operator (e.g.: smoke or strange sound). The emergency stop devices or emergency 

switch off devices (under responsibility of the plant system concerned) will be only monitored by their 

conventional control and then reported to the CODAC system. In parallel, operators can actuate the nearest 

emergency call button. 

If it is decided that a specific plant system emergency stop device or an emergency switch off device, which 

performs the shutdown of a machine in the same plant system, has to be monitored by the CSS-OS, then it will be 

considered as a “standard OS I&C function” and addressed as described in section 9.1.2.1. 

The typical case has: 

 

Inputs: 

o 

Zero to a maximum of four digital inputs available, 

CSS-OS supervision 

PSS x 

Figure 9.4: Emergency button interface principle 

9.1.2.2.1 Detailed representation 

To implement the above concepts, the interface between the PSS-OS Safety PLC and the CSS-OS SCADA can be 

represented as shown below: 

Page 68 of 95

INPUTS 

OUTPUTS 


Archiving 

Operator action / 

command 

PSS logic treatment 

Supervision display 

/ monitoring 


Archiving 

Alarming 

Emergency Button 

X 4 

Emergency Button state 

Emergency Button invalidity 

Figure 9.5: Standard Emergency Button Monitoring Interface Schema 

Inputs: The Left part of the figure lists the controls going from the CSS-OS terminal to the PSS-OS Safety PLC 

(red colour): 

No configuration variable for this typical case. 

PSS-OS Safety PLC: The central part presents the PSS-OS Safety PLC containing: 

 

4 Digital Inputs. 

Outputs: The right part lists the exchanges between the PSS-OS Safety PLC and the CSS-OS SCADA System 

functions (monitoring, archiving and alarming) for each element of the standard function (black colour). 

 

 

Emergency Button State: the PSS-OS sends the Emergency Button state to the CSS-OS SCADA, 

Emergency Button Invalidity: is the health monitoring signal of the Emergency Button. 

Refer to appendix 4 for more details about the associated SDD translation. 

9.1.2.3 OS Specific Function 

It should be possible to implement most OS functions as standard OS I&C functions, however some will need 

“custom” treatment: 

- The central safety functions need SIL certified communications between the PSS-OS and the CSS-OS 

PLC to trigger safety actions of other plant systems, 

- Some functions require a highly reliable and available HMI which cannot be computerized, 

- Some functions have inputs and outputs that do not fit in the standard OS function, 

- Some complex functions could necessitate adaptation of the HMI to describe the function, 

- … 

In this case, the interface between the PSS-OS and the CSS-OS will be tailored to the needs and discussed directly 

between the PSS-OS and the CSS-OS designers. 

Page 69 of 95

However, all the concepts from standard functions that would be still applicable should be used: 

Definition of the states of the function, 

Standard information for inputs and outputs, 

Override and maintenance status, 

Latch and reset policy, 

Overrides concepts and policy, 

Naming convention. 

9.2 OS Interface between PSS-OS PLC and CSS-OS PLC 

The PSS-OS designer will develop the PLC Software with one of the following SIEMENS software packages 

according to the hardware configuration selected for the PSS-OS: 

 

 

S7 Distributed Safety in case of S7-300F CPU used, 

S7 F/FH System in case of S7-400H CPU used. 

Caution: For the OS central function cases, the PSS-OS PLC software will be interfaced to the CSS-OS PLC 

software (develop with S7 F/FH System). 

The PSS-OS designer should refer to the PLC supplier documents in order to take into account all mechanisms 

concerning safety communication via Industrial Ethernet protocol through the S7 connections. 

9.3 OS Hardware Monitoring Interface 

The only kind of alarm about system health that should appear on the CSS-OS SCADA on the safety operator’s 

desk should be a synthesized alarm. 

All detailed system monitoring should appear in the dedicated CSS-OS maintenance terminals and should be as 

detailed as possible. 

There are two kinds of health monitoring: 

- Cubicle monitoring (temperature, doors…), 

- System monitoring (PLC memory, communication rates…). 

Note: These values are transmitted to the CSS-OS SCADA through standard SDD templates which are still under 

study. 

Refer to the documents listed here for more details: 

- [RD2], Plant Control Design Handbook [ITER_D_27LH2V] paragraph 4.4.1, 

- [RD16], Functional specification of I&C cubicle monitoring [ITER_D_7A45LE]. 

9.4 PSS-OS software structure 

In this section, the program structure is introduced as a typical scheme of a Standard PLC Software Structure 

(SPSS) to be deployed on the ITER Project for the conventional PLC. This specific SPSS shows the links between 

the PSS-OS data and the CSS-OS SCADA SDD. 

Refer to [RD21], PLC Software Engineering Handbook [ITER_D_3QPL4H] for more details about the SPSS. 

Page 70 of 95

9.4.1 SPSS Architecture and data exchanges 

The figure below shows a typical SPSS program architecture, with: 

- CSS-OS SCADA interface for OS I&C functions, 

- Override modules (included in the functions). 

Figure 9.6: Software Structure principle 

The PLC core application is specific to the requirements of each plant system, whereas the rest of the SPSS 

program (input processing, CSS-OS SCADA interface, output processing, reset DB) is common to all plant 

systems. 

9.4.2 Safety application 

The safety application is not represented in the figure, because there are two cases which depend on the CPU 

technology (S7-300F or a S7-400H): 

- If the SPSS CPU is a SIEMENS 300F (distributed safety), then the safety program is in the main call, 

- If the SPSS CPU is a SIEMENS 400F or 400FH (F-Systems), then the safety program is called in a 

periodic call. 

A main call program is executed cyclically by the PLC core, whereas the periodic call program is periodically 

executed, it is called an “interruption”. 

Interruptions have priority, in order to respect the interruption call periods, the main program in a PLC cycle can 

be stopped until the interruption has completed executing. 

Page 71 of 95

CYCLIC 

Tasks 

MIS 

MIE 

OB1 User Program 

PCC 

MIS 

MIE 


PCC 

MIS 

MIE 


PCC 

PERIODIC 

OBxx 

OBxx 

OBxx 

Time 

T0 

T1 

T3 

MIS 

MIE 

OB1 

OBxx 

PCC 

Legend : 

Outputs actualization 

Inputs actualization 

User program treatment 

Periodic interuption 

Cycle control 

Figure 9.7: Safety Program principle 

The PSS-OS designer should refer to the PLC supplier documents in order to take into account all safety 

application mechanisms. 

9.5 Deliverables related to the CSS-OS configurations 

IO or a Domestic Agency is in charge of providing all of the modules and functions required to manage the OS 

function. The PSS-OS PLC and the associated mini CSS-OS are mainly concerned. 

Some devices, such as the PLC core application, have to be treated from the PSS-OS point of view. 

Note that the SPSS (which is the standard program implemented by ITER to integrate the user PLC core 

application) is provided by ITER. 

Some devices have to be treated from the mini CSS-OS point of view, such as: 

- SDD, 

- EPICS IOCs, 

- BOY screens. 

The SDD will also provide the alarm configuration (BEAST). 

Otherwise, the PSS-OS database is issued from the SDD compilation and has to be imported to the PSS-OS 

application software. 

Standard SDD for the PSS-OS functions, such as “standard function interface” and “emergency button interface” 

are available to download from IDM. 

The BOY screens related to the PSS-OS safety logic representation (ex: matrix…) will not be implemented by the 

plant systems, but will be automatically generated by an ITER routine executed from the CODAC Core system. 

Page 72 of 95

10 Development and Integration 

To further facilitate future integration and to ensure that there is a common plant I&C hardware and software 

infrastructure, PBS48 will, in addition to setting standards, provide plant system designers with three specific 

common hardware components: a basic communication infrastructure, a plant system host and “mini CSS-OS”. 

Mini CSS-OS – Each plant system I&C will also be provided with the software with CODAC Core System 

version Mini CSS-OS which includes the tools for accessing plant system data, operator displays, archiving, alarm 

handling, CSS-OS Server PLC IOC. Also provided will be the necessary software development tools, including 

the Self-Describing Database Editor. Future versions of Mini CSS-OS will support testing of plant system I&C 

and CSS interfaces as well as generic test engines to be used for FAT and SAT. 

Communications Infrastructure – Each plant system I&C will also be provided with the basic communications 

infrastructure, a standard switch, to ensure connectivity between mini CSS-OS and the various components – 

CSS-OS PLC IOC, and PLCs – of the plant system I&C itself. Use of this switch will facilitate future connection 

to the CSS-OS SCADA data network at the ITER site. 

Integrating with CSS-OS SCADA: 

After the SAT with mini CSS-OS, the PBS48 team will be responsible for the connection of the plant system I&C 

to CSS-OS SCADA itself. All SAT tests will be repeated, this time using ITER control room and server facilities. 

To the extent possible (increasingly for systems delivered later) these tests will be performed in a network loading 

environment which is as close as possible to future operating conditions. 

List of documents to be supplied by each PSS-OS to the PBS48: 

Hazard and risk analysis, 

Occupational safety function allocation, 

Database exchange list, 

Application software, 

Acceptance testing documents. 

Page 73 of 95

11 Installation 

The PSS-OS components will be installed in PSS-OS cubicles. 

For the installation of the PSS-OS cubicles, the following rules must be applied: 

- The PSS-OS cubicles must be compliant with [RD12], the ITER catalogue for I&C products – 

Cubicles [ITER_D_35LXVZ], 

- The space reservation and allocation of the components inside of the PSS-OS cubicle must be 

compliant with [RD14], the Guidelines for I&C Cubicle Configurations [ITER_D_476HUG] and 

[RD17], the I&C cubicle internal configuration [ITER_D_4H5DW6], 

- The handling and installation of the floor standing PSS-OS cubicles must be compliant with [RD14], 

the Guidelines for I&C Cubicle Configurations [ITER_D_476HUG] and [RD17], I&C cubicle 

internal configuration [ITER_D_4H5DW6] (§ Cubicle installation), 

- The requirements for earthing and electromagnetic compatibility and the cable entries (on top or on 

bottom) described in the Electrical Hand Book [RD18], EDH Part 1: Introduction 

[ITER_D_2F7HD2] and in [RD20], EDH Part 4: Earthing [ITER_D_2ELREB], EMC and Lightning 

Protection are applicable to the PSS-OS cubicles, 

- The specific requirements for Siemens hardware installation (e.g. cable section for backplane 

connexion, etc.) should be taken into account and respected, 

- The PSS-OS cubicle design and installation must meet the requirements for seismic class SC2. 

Page 74 of 95

12 Testing and Acceptance tests 

The testing and acceptance tests are important tasks and they are an integral part of the ITER model of integration. 

These tests are intended to check the conformity of the deliverables with the requirements specified by ITER. 

In the process defined by the ITER model of integration, two major acceptance tests are defined: FAT (Factory 

Acceptance Tests) carried out at the supplier’s premises during the manufacturing phase and the SAT (Site 

Acceptance Tests) covering the all plant systems installed on the site during the integration phase. 

Figure 12.1: Integration principle 

12.1 Entry criteria 

The entry criteria for the acceptance test given in [RD10], the Integration scheme and procedure for plant system 

I&C [ITER_D_3VVU9W] is applicable for the PSS-OS acceptance tests. 

This document gives a list of the pre-requisites which must be met in order to start the acceptance tests (FAT or 

SAT). A particular pre-requisite for PSS-OS test is the installation of the Mini CSS-OS tool (very similar to the 

Mini-CODAC) + Safety-OS PLC which will represent the CSS-OS safety PLC in order to perform SIL functions. 

12.2 Acceptance process 

The acceptance process described in [RD10], the Integration scheme and procedure for plant system I&C 

[ITER_D_3VVU9W] is applicable for the PSS-OS acceptance tests. 

In accordance with [RD2], the PCDH - Plant Control Design Handbook [ITER_D_27LH2V], the results of the 

execution of the FAT and SAT plans are recorded in a FAT (PCDH D50) or SAT (PCDH D65) report. Their 

classification and treatment should comply with the requirements for test campaign part passed, severity level 

value and live cycle state. 

12.3 Acceptance criteria 

The acceptance criteria with a list of requirement details, especially for the different validations taking into 

account parameters like execution rate, severity level, etc. described in [RD10], the Integration scheme and 

procedure for plant system I&C [ITER_D_3VVU9W] is applicable for the PSS-OS acceptance tests. 

Page 75 of 95

12.4 FAT 

The Plant System I&C Factory Acceptance Test (FAT) is a test which checks the conformity of the plant system 

I&C with IO requirements and mainly with the PCDH requirements, in order to ensure that the plant system I&C 

unit is integrable before starting the SAT. 

The unit for PS I&C FAT is the PSS-OS cubicle with its embedded hardware and software. 

Before starting the FAT the supplier must carry out a pre-FAT to detect and solve the manufacturing 

issues. 

The scope of the FAT should be adjusted according to the procurement configuration and will cover the following 

areas: 

Mechanical and electrical configuration of the PSS-OS cubicles 

PLC’s hardware and software 

Plant system configuration 

Plant system I&C functions 

Performance 

Documentation 

During the FAT, the interfaces to the plant (instrumentation and actuators) are disconnected or simulated by test 

equipment. The functional test will be performed with the mini-CSS-OS tool + safety PLC which will represent 

the CSS-OS safety PLC in order to perform SIL functions. The environmental conditions are those of the 

supplier’s factory. 

For checking compliance of the procurement with the remaining PCDH requirements and to optimize the duration 

of the FAT, the PCDH proposes to split I&C FAT into several campaigns. 

For further information about the FAT campaigns, their scope and scenarios consult the [RD2], PCDH - Plant 

Control Design Handbook [ITER_D_27LH2V] and [RD10], the Integration scheme and procedure for plant 

system I&C [ITER_D_3VVU9W]. 

12.5 SAT 

The Site Acceptance Test (SAT) is a test which checks the conformity of the whole set of plant system I&C 

delivered after their shipment to Cadarache. It checks conformity with IO requirements and mainly with the 

PCDH requirements, in order to ensure that the PSS-OS are ready to go ahead to the next step in life-cycle of the 

ITER model of integration: the integrated commissioning. 

The SAT will also be performed on what was not covered for any reason by the FAT. 

In accordance with [RD10], the Integration scheme and procedure for plant system I&C [ITER_D_3VVU9W] the 

SAT is organised into 3 sequential steps: 

- Component tests: the unit to test is the PSS-OS Cubicle (physical interfaces test). These tests are 

performed under the supplier’s responsibility with the support of ITER IO CSD for the PBS48.OS 

interface. 

- System tests: the unit to test is the PSS-OS System (functional tests). These tests are performed with 

mini-CSS-OS tool + safety PLC which will represent the CSS-OS safety PLC in order to perform 

SIL functions. These tests are performed under the supplier’s responsibility with the support of ITER IO 

CSD for the PBS48.OS. 

- System connection to PBS48.OS: the unit to test is the PSS-OS System (functional tests). The mini- 

CSS-OS tool + safety PLC used in the previous step are functionally disconnected from the PSS-OS 

system. The PBS48.OS servers are updated with the plant system configuration, alarm and archive data 

from the mini-CSS-OS tool and safety PLC used during the system tests. The system connection test to 

PBS48.OS is performed under ITER IO CSD responsibility. 

Page 76 of 95

In accordance with [RD2], the PCDH - Plant Control Design Handbook [ITER_D_27LH2V], any deviation from 

the expected result during the execution of tests must be captured in a uniquely identified issue sheet. This will 

record all of the information related to the investigation of the root cause of the issue and all of the remedial 

actions. In these cases the PCDH rules in the “Deviation policy” section should be applied. 

Page 77 of 95

13 Standards compliance and certification requirements 

This paragraph defines the methodology for certification of all occupational safety functions. 

The certification strategy of this system is based on IEC 61508. 

The plant system suppliers have to deliver a SIL certified system that meets the safety requirements as described 

in the IEC 61508. The plant system supplier has to arrange for this certification to be delivered by a third party. 

The justification for risk management of random and systematic failures is divided into four steps: 

- Step 1: Identifying what the required safety functions are. Hazard analysis and definition of safety 

functions, 

- Step 2: Assessment of the risk-reduction required by the safety function. This will involve a Safety 

Integrity Level (SIL) Assessment. The SIL is determined for each safety function according to the 

estimated frequency of the risk associated and the severity of its consequences. A Safety Integrity Level 

(SIL) applies to an end-to-end safety function of the safety-related system, not just to a component or part 

of the system, 

- Step 3: Ensuring the safety function performs to the design, including under conditions of incorrect 

operator input and failure modes. This will involve having the design and lifecycle managed by qualified 

and competent engineers carrying out processes to a recognised functional safety standard, 

- Step 4: Demonstration of achievement of the SIL level allocated. 

To ensure the objectivity of the study, an independent organization must carry out the SIL demonstration. If the 

Plant System supplier is highly skilled in risk assessment and SIL I&C implementation, then the demonstration 

could, with adequate justification, be carried out by an independent department. 

Page 78 of 95

14 Periodic tests principle 

The ITER experimental process is not continuous 24 hours / day, 365 days / year. Some periods are specifically 

dedicated to maintenance: 

- 2 or 3 operational shifts of 8 hours per day for plasma pulse operations, 

- When not used for full operations, the 3 rd quiet shift may be used for testing, wall conditioning, heating 

commissioning or for short term maintenance. 

- Typically, after 12 operational days there will be 2-4 short term maintenance days. 

Moreover, after each experimental campaign, there will be a planned long term maintenance period of typically 8 

months. 

The inherent availability objective integrates the scheduled downtime for routine maintenance during 3 days each 

week during experimental campaign (3.5 months), and 40% of the potential operation time (5 months), 

corresponding to the unscheduled downtimes for corrective maintenance to repair faults. 

This means that during a 2 year experimental campaign, 16.5 (8+3.5+5) months will be used for 

preventive/corrective maintenance & upgrades as compared with 7.5 months available for plasma 

operation/research programme. 

The SCS-OS (PSS-OS and CSS-OS) shall operate in continue to protect people and environment knowing that 

maintenance period are sometimes more critical than operational period (OS functions are generally linked to 

people presence). 

The process to perform the periodic tests that are required to maintain the SIL level of the PSS-OS functions has 

to be considered at the design stage. In order to limit the complexity of the OS I&C function or the need of 

overrides, it is generally easier to perform the periodic tests when the system protected by the function is stopped, 

which can happen in many cases during the Long Term Maintenance phase. When it is not possible or suitable, the 

requirements of the OS I&C functions have to take into account provisions for performing the tests during the 

PSS-OS operation (additional redundancies, specific overrides…). 

Page 79 of 95

APPENDIX 1 – Detailed logic hardware lists 

Architecture 1 – Standard availability architecture with Integrated IO configuration 

Order No. Designation Quantity 

6ES7317-2FK14-0AB0 Central processing unit CPU317F-2 PN/DP 1 

6ES7326-1BK02-0AB0 Digital input 24DI 24V DC; diagnose fail-safe 1 

6ES7326-2BF10-0AB0 Digital output 10DO DC 24V/2A PP; diagnose fail-safe 1 

6ES7336-4GE00-0AB0 Analog input 6AI 15 bit; diagnostics fail-safe 1 

6ES7390-1AJ30-0AA0 Mounting rail 830 mm 1 

6ES7392-1AJ00-0AA0 Front connector 20-pole with screw contact 1 

6ES7392-1AM00-0AA0 Front connector 40-pole with screw contact 1 

6ES7392-1BM01-0AA0 Front connector 40-pole with Cage Clamp terminals 1 

6ES7953-8LL31-0AA0 Micro Memory Card for IM151 CPU and S7-300C 2MB 1 

6GK7343-1GX30-0XE0 CP 343-1 Advanced Industrial Ethernet S7-300 2 

Table A1.1: Architecture 1 List of logic component 

PBS.X Cubicle 

MAIN SWITCH 


Sensor a 

RJ45 

Sensor b 

RJ45 

Actuator a 

Actuator b 

CPU 

C 

P 

a 

C 

P 

b 


Rack 0 DIa DOa AI 

DIb 

DOb 

AI 

DP 



Figure A1.1: Architecture 1 Schema 

Page 80 of 95

Architecture 2 – Standard availability architecture with Distributed IO configuration 


6ES7153-2BA02-0XB0 IM 153-2 High Feature for ET200M PROFIBUS DP 1 

6ES7195-1GA00-0XA0 DIN rail for active bus modules 482mm (19") 1 

6ES7195-7HA00-0XA0 Active bus module for PS and IM 153 1 

6ES7195-7HB00-0XA0 Active bus module for 2 modules 40mm wide 1 

6ES7195-7HC00-0XA0 Active bus module or 1 module 80 mm wide 1 

6ES7315-2FJ14-0AB0 Central processing unit CPU315F-2 PN/DP 1 




6ES7390-1AF30-0AA0 Mounting rail 530 mm 1 

6ES7392-1AJ00-0AA0 Front connector 20-pole with screw contact 2 

6ES7392-1AM00-0AA0 Front connector 40-pole with screw contact 4 

6ES7953-8LL31-0AA0 Micro Memory Card for IM151 CPU and S7-300C 2MB 1 



PBS.X Cubicle 

MAIN SWITCH 



Rack 0 

CPU 

RJ45 

C 

P 

a 

C 

P 

b 

RJ45 

Sensor a 

DP 

Sensor b 

Actuator a 

Actuator b 

DP 


Rack 1 


AI 





Page 81 of 95

Architecture 3 – Specific Standard availability architecture 




6ES7195-7HA00-0XA0 Active bus module for PS and IM 153 1 






6ES7392-1BJ00-0AA0 20-pin front connector with spring terminals 1 


6ES7400-1JA11-0AA0 UR2 Central/Expansion Unit; 9 Slots K-Bus ALU 1 

6ES7407-0KR02-0AA0 Power supply PS407 10A; AC 120/230V-> DC5V/24V redundant 2 

6ES7414-5HM06-0AB0 S7-CPU 414-5H; 2x2MB main memory; 1 MPI/DP 1 DP 1 

6ES7952-1AM00-0AA0 RAM Memory Card long; 4 MB 1 

6ES7960-1AA04-5KA0 Fiber optic cable for synch module 10m 1 

6ES7960-1AA06-0XA0 Sync. Module for Patch Cable up to 10 m 1 



PBS.X Cubicle 

MAIN SWITCH 


RJ45 

RJ45 


Rack 0 

PSa PSb CPU C 

P 

a 

C 

P 

b 

Sensor a 

DP 

Sensor b 

Actuator a 

Actuator b 

DP 


Rack 1 


AI 





Page 82 of 95

Architecture 4 – High availability architecture with Distributed IO configuration 






6ES7195-7HD10-0XA0 Active bus module IM/IM for 2 IM153-2 High Feature 3 




6ES7392-1BJ00-0AA0 20-pin front connector with spring terminals 3 


6ES7400-1JA01-0AA0 UR2 central controller/expansion unit; 9 slots K bus 2 

6ES7407-0KR02-0AA0 Power supply PS407 10A; AC 120/230V-> DC5V/24V redundant 4 

6ES7414-5HM06-0AB0 S7-CPU 414-5H; 2x2MB main memory; 1 MPI/DP 1 DP 2 

6ES7952-1AS00-0AA0 RAM Memory Card long; 16 MB 2 

6ES7953-8LM20-0AA0 Micro Memory Card for IM151 CPU and S7-300C 4MB 3 

6ES7960-1AA04-5KA0 Fiber optic cable for synch module 10m 2 

6ES7960-1AB06-0XA0 Synch. Module for Installation Cable up to 10km 4 



Page 83 of 95

PBS.X Cubicle 

MAIN SWITCH 


RJ45 

RJ45 


Rack 0 

PS0a PS0b CPU 

0 

C 

P 

0 


Rack 1 

PS1a PS1b CPU 

1 

C 

P 

1 

Sync 

10m 

Sync 

10m 

DP 

FO (2m) 

FO (2m) 

Sync 

10m 

Sync 

10m 

DP 





Sensor a 

Actuator a 


Rack 2 

DP 

DP 

IM0a IM1a DIa DI DOa DO DO DO AI 

Sensor b 

Actuator b 

DP 

DP 


Rack 3 

IM0b IM1b DIb 

DI DOb DO DO DO AI 

Sensor c 

Actuator c 

DP 

DP 

IM0c IM1c DIc 

DI DOc DO AI 


Rack 4 


Page 84 of 95

APPENDIX 2 – Variable Table for OS Standard Function 

The appendix comprises the detailed list of all variable associated with the OS standard function and one 

associated case study. 

The colour code indicates which boxes are pre-defined and which boxes may be completed. 

Pre-defined 

Has to be completed (specific) 

Caution: The following list is a partial variable table. 

VARIABLE NAME 

DESCRIPTION 

FUNCTION 

NAME 

XXXX-YYYY-SF:IFnn-AI1-TM-ENGvalue Analog input 1 - Engineering value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TM-SHvalue Analog input 1 - High safety threshold value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TM-SHHvalue Analog input 1 - High High safety threshold value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TM-SLvalue Analog input 1 - Low safety threshold value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TM-SLLvalue Analog input 1 - Low safety threshold value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TS-SHreach Analog input 1 - High safety threshold reached XXXX-YYYY-SF 

Analog input 1 - High High safety threshold 

XXXX-YYYY-SF:IFnn-AI1-TS-SHHreach reached 

XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TS-SLreach Analog input 1 - Safety threshold SL reached XXXX-YYYY-SF 

Analog input 1 - Low low saferty threshold 

XXXX-YYYY-SF:IFnn-AI1-TS-SLLreach reached 

XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TAGNAME Analog input 1 - Tagname XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TS-INVALIDITY Analog input 1 - Invalidity XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TS-OVRenab Analog input 1 - Override enabled XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI1-TS-OVRdisab Analog input 1 - Override disabled XXXX-YYYY-SF 




XXXX-YYYY-SF:IFnn-AI2-TM-SLvalue Analog input 2 - Low safety threshold value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TM-SLLvalue Analog input 2 - Low safety threshold value XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TS-SHreach Analog input 2 - High safety threshold reached XXXX-YYYY-SF 

Analog input 2 - High High safety threshold 

XXXX-YYYY-SF:IFnn-AI2-TS-SHHreach reached 

XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TS-SLreach Analog input 2 - Safety threshold SL reached XXXX-YYYY-SF 

Analog input 2 - Low low saferty threshold 

XXXX-YYYY-SF:IFnn-AI2-TS-SLLreach reached 

XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TAGNAME Analog input 2 - Tagname XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TS-INVALIDITY Analog input 2 - Invalidity XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TS-OVRenab Analog input 2 - Override enabled XXXX-YYYY-SF 

XXXX-YYYY-SF:IFnn-AI2-TS-OVRdisab Analog input 2 - Override disabled XXXX-YYYY-SF 




Table A2.1: Partial Variable Table of OS Standard Function 

After download of the OS standard function variable list from IDM, the PSS-OS Designer will replace the bold 

characters located in the green columns by the correct values, in compliance with the rules above. 

Page 85 of 95

More details for each type of variable: 

The usage of the interface function variables is detailed in the tables below. 

Some variables are multiple, but only one kind of variable is described below. 

XXXX-YYYY-SF:IFnn-AI1-TM-ENGvalue 

1 This is the analogue transmitter value scaled by the PLC to an engineering value. 

This value can be displayed in the CSS-OS supervision 

XXXX-YYYY-SF:IFnn-AI1-TM-SHvalue 

2 This is the analogue transmitter high level switch value in engineering units. 

This level is used by the PLC to raise the high level alarm. 

This value is the high level alarm set point. 

XXXX-YYYY-SF:IFnn-AI1-TM-SHHvalue 

3 This is the analogue transmitter very high level switch value in engineering units. 

This level is used by the PLC to raise the very high level alarm. 

This value is the very high level alarm set point. 

XXXX-YYYY-SF:IFnn-AI1-TM-SLvalue 

4 This is the analogue transmitter low level switch value in engineering units. 

This level is used by the PLC to raise the low level alarm. 

This value is the low level alarm set point. 

XXXX-YYYY-SF:IFnn-AI1-TM-SLLvalue 

5 This is the analogue transmitter very low level switch value in engineering units. 

This level is used by the PLC to raise the very low level alarm. 

This value is the very low level alarm set point. 

6 

7 

XXXX-YYYY-SF:IFnn-AI1-TS-SHreach 

This is the analogue transmitter high level switch signal. 

If the transmitter value (measured) becomes greater than or equal to the high level, then the PLC will 

raise an alarm. 

This alarm can be overridden. 

This variable might be used to generate the high level alarm. 

XXXX-YYYY-SF:IFnn-AI1-TS-SHHreach 

This is the analogue transmitter very high level switch signal. 

If the transmitter value (measured) becomes greater than or equal to the very high level, then the PLC 

will raise an alarm. 


This variable might be used to generate the very high level alarm. 

8 

XXXX-YYYY-SF:IFnn-AI1-TS-SLreach 

This is the analogue transmitter low level switch signal. 

If the transmitter value (measure) becomes lower than or equal to the low level, then the PLC will 

raise an alarm. 


This variable might be used to generate the low level alarm. 

9 XXXX-YYYY-SF:IFnn-AI1-TS-SLLreach 

Page 86 of 95

This is the analogue transmitter very low level switch signal. 

If the transmitter value (measure) becomes lower than or equal to the very low level, then the PLC 

will raise an alarm. 


This variable might be used to generate the very low level alarm. 

XXXX-YYYY-SF:IFnn-AI1-TAGNAME 

10 This is the analogue transmitter name. 

This setting is used as a maintenance reference parameter filled from the PLC database to be 

displayed in the OS-supervision. 

11 

XXXX-YYYY-SF:IFnn-AI1-TS-INVALIDITY 

This is a binary indication of the analogue transmitter signal’s health. 

If the PLC measurement becomes out of range, then the transmitter invalid status will be indicated. 

Generally, either the transmitter wire is disconnected (open loop) or a short-circuit has been detected. 

An alarm might be raised when this signal becomes true. 

12 

XXXX-YYYY-SF:IFnn-AI1-TS-OVRenab 

This is a binary indication of the analogue transmitter override status. 

If this binary signal becomes true, then it means that an override has been set for this transmitter. The 

transmitter override has effect on its four levels (HH, H, L, LL). 

This variable is combined with the other one (….TS-OVRdisab). 

13 

XXXX-YYYY-SF:IFnn-AI1-TS-OVRdisab 

This is a binary indication of the analogue transmitter override status. 

If this binary signal becomes true, then it means that an override has been removed for this 

transmitter. 

The transmitter override has effect on its four levels (HH, H, L, LL). 

This variable is combined with the other one (….TS-OVRenab). 

14 

XXXX-YYYY-SF:IFnn-DI1-TS-INVALIDITY 

This is a binary indication of the digital input signal’s health. 

For a safety signal (digital input), a monitoring line looks for either a short circuit or an open loop. 

If the PLC detects one of the two failures, then the digital input invalid status will be indicated. 


XXXX-YYYY-SF:IFnn-DI1-TS-STATE 

15 This is a binary indication of the digital input state (is the digital input true or false). 

This variable is equal to the digital input hardware value. 

XXXX-YYYY-SF:IFnn-DI1-TAGNAME 

16 This is the digital input name. 



17 

XXXX-YYYY-SF:IFnn-DI1-TS-OVRenab 

This is a binary indication of the digital input override status which is quite useful for the 

maintenance team. 

If this binary signal becomes true, then it means an override has been set for this digital input. 

An override status disables the trip on its trip value, and also when its invalid status is raised. 

Page 87 of 95


18 

XXXX-YYYY-SF:IFnn-DI1-TS-OVRdisab 

This is a binary indication of the digital input override status which is quite useful for the 

maintenance team. 

If this binary signal becomes true, then it means an override has been removed for this digital input. 

An override status disables the trip on its trip value, and also when its invalid status is raised. 


19 

XXXX-YYYY-SF:IFnn-DO1-TS-INVALIDITY 

This is a binary indication of the digital output signal’s health. 

For a safety signal (digital output), a monitoring line looks for either a short-circuit or an open loop. 

If the PLC detects one of the two failures, then the digital output invalid status will be indicated. 


20 

XXXX-YYYY-SF:IFnn-DO1-TS-OVRvalue 

This is the binary feedback of the digital output override value which is applied when the override 

mode is enabled. 

If this binary feedback becomes true, then it means that the digital output is set to “true”, so the 

override mode is set to enable. 

The logic is detailed in the logic diagram. 

21 

XXXX-YYYY-SF:IFnn-DO1-TS-OVRmode 

This is a binary indicator which is a feedback about the override mode. 

The override logic sets the override binary command, to select the override mode. 

If the override mode is set to “true”, then the digital output will be equal to the override value. 

This signal [..TS-OVR mode] is specific for the Digital Output override mode management. 

XXXX-YYYY-SF:IFnn-DO1-TS-STATE 

22 This is a binary indication of the digital output state (is the digital output true or false). 

The state includes the override management. 

This variable is equal to the digital output hardware value. 

XXXX-YYYY-SF:IFnn-DO1-TAGNAME 

23 This is the digital output name. 



24 

XXXX-YYYY-SF:IFnn-OVR-TM-NUM 

This is the override number feedback. It takes the value of the active override. 

The standard override function is designed to manage 5000 overrides per function. 

So, this variable can take a value between 0 to 9999 : 

- for an override setting operation, 0

25 

XXXX-YYYY-SF:IFnn-OVR-TM-NUM10000 

This variable is not useful for the operator, but is a protocol requirement. 

The communication protocol between OS-supervision and CSS is qualified as robust thanks to 

handshake management: after the CSS-supervision has transmitted the required override number to 

the PLC, the PLC responds to the OS-supervision with the received override number added to 10000. 

Then, the supervision compares the override number sent and the override number received. 

When there is a positive match between the transmitted and received values, it permits the 

supervision to enable the digital override operator command. 

26 

XXXX-YYYY-SF:IFnn-OVR-TS-ACTIV 

This is a Boolean feedback indicator that informs the DCS about what the PLC has understood (set or 

remove the bypass). 

This value can be used to indicate in the OS-supervision that at least one override is set for the 

function. 

XXXX-YYYY-SF:IFnn-OVR-TS-DESACTIV 

27 This is a Boolean feedback indicator that informs the DCS about what the PLC has understood (set or 

remove the bypass). 

This value can be used to indicate in the OS-supervision that no override is set for the function. 

28 

XXXX-YYYY-SF:IFnn-OVR-TS-WIN 

This variable is not useful for the operator. 

This is an OS-supervision requirement used to manage the override popup window for the function. 

According to the protocol between OS-supervision and CSS, after a successful override number 

comparison, the operator may confirm the override request before a 30 seconds timeout. If the 

timeout expires, then the request is cancelled and the popup disappears automatically. 

This variable is managed by the PLC, and is used to control the appearance of the popup. 

XXXX-YYYY-SF:IFnn-OVR-TR-NUM 

29 This variable is not useful for the operator, but is a protocol requirement. 

According to the protocol between OS-supervision and CSS, this variable corresponds to the one 

which is set by the operator and transmitted to the PLC for an override setting or removing request. 

30 

XXXX-YYYY-SF:IFnn-OVR-TC-VALID 

This is the Boolean variable used by a maintenance operator to validate an override command before 

the timeout expiration. 

This variable is connected to the “validation” button located in the override popup. 

The override becomes effective only after that validation. 

31 

XXXX-YYYY-SF:IFnn-SAF-TC-MAINTreset 

A maintenance operation might be signalled to the OS-supervision. An alarm (for a safety function) 

can be managed by a maintenance operator (a password is required). 

Once the maintenance operation is finished, this alarm can be removed by clicking a dedicated button 

“Maintenance mode” located in the matrix. 

This variable is linked to this button. 

32 

XXXX-YYYY-SF:IFnn-SAF-TC-MAINTset 

A maintenance operation might be signalled to the OS-supervision. An alarm (for a safety function) 

can be managed by a maintenance operator (a password is required). 

When the maintenance operation starts, this alarm can be set by clicking a dedicated button 

“Maintenance mode” located in the matrix. 

Page 89 of 95

This variable is linked to this button. 

33 

XXXX-YYYY-SF:IFnn-SAF-TC-RESET 

A safety function has a reset command that enables the safety function after a trip. 

This variable is linked to the safety function “reset button” located in the matrix. 

There is one reset command per safety function that resets all of the latched trips which have 

disappeared. 

34 

XXXX-YYYY-SF:IFnn-SAF-TM-INPUTstate 

This variable can have 16 possible states (maximum). 

The combination of the 16 states (array of 16 bool) makes the variable value. 

Each state is dedicated to a variable which represents the safety function inputs (trip condition). 

This will be used to display the OS-supervision alarms according to the safety function specification 

(number of inputs, outputs…). 

More details for this variable: 

INPUTstate INT bit0 memorized state of function DI1 True=Input 1 is tripped ; False=Input 1 is not tripped 

bit1 memorized state of function DI2 True=Input 2 is tripped ; False=Input 2 is not tripped 



bit4 AI 1 threshold reached True= A threshold on AI 1 is reached ; False = no threshold on 

AI 1 is reached 







bit8 spare 

bit9 spare 

bit10 spare 

bit11 spare 

bit12 spare 

bit13 spare 

bit14 spare 

bit15 spare 

35 

XXXX-YYYY-SF:IFnn-SAF-TM-STATE 

This is the safety function state given by the PLC. 

The variable format is an integer. 

There are three possible values : 

0: abnormal / unknown 

1: normal 

2: degraded 

3: tripped 

36 

XXXX-YYYY-SF:IFnn-SAF-TS-MAINT 

This is the maintenance alarm of the safety function managed by the Boolean commands […SAF- 

TC-MAINTset] and […SAF-TC-MAINTreset]. 

Normally, it is used to warn the OS-supervision operator that a maintenance operation on the safety 

function is in progress. 

It has no effect on the process, but only generates a time-stamped alarm on the OS-supervision. 

XXXX-YYYY-SF:IFnn-SAF-TS-OVER 

37 This is a binary indicator of the safety function override enabling. 

This signal is true when at least one override is set on the safety function. 

Page 90 of 95

A dedicated alarm is set in the OS-supervision. 

XXXX-YYYY-SF:IFnn-SAF-TS-RESETrdy 

38 When the all condition trips are false, a Boolean variable indicates the safety function is “ready to 

reset”. This means that if an operator clicks the “reset button”, the safety function will be reset. 

XXXX-YYYY-SF:IFnn-SAF-TAGNAME 

39 This is the safety function name. 



Case study 

To illustrate the concepts above, a small case study of the implementation of a standard OS I&C function is 

presented. 

In this case study, three infrared barriers protect personnel from the process area. In the case of an intrusion, one 

of the three infrared barriers will be cut which will immediately alert the supervision and automatically stop the 

process located in the safety area. 

Figure A2.1: Case Study schema 

Page 91 of 95

The PSS-OS Safety PLC manages three digital inputs (infrared barriers) to control one digital output (process 

shut-down command). 

DI 1 Infrared barrier #1 



DO 1 Process shut-down command 

According to the above Input & Output of the case study, the PSS-OS designer will select the following variables 

from the OS standard function typical: 

Interface 

Connection used 

Function 31 32 33 38 35 37 36 34 

DI 1 15 14 17 18 

DI 2 15 14 17 18 

DI 3 15 14 17 18 

DO 1 22 19 20 21 

Interface Function detail: 

Override 29 30 24 26 27 25 28 

- PLC name: 99-ABC- 

PLC-001, 

- PSH name: PSH000, 

- Plant system: 99-Example System Name (ABC), 

- Plant system I&Cs: DEFG. 

The function identified as the interface function #7 is a safety function (SF) called “control zone”. 

The xml file containing the variable list corresponding to the case study specifications is shown in the table below. 


Page 92 of 95

Table A2.2: Partial Variable Table of Case Study 

Page 93 of 95

APPENDIX 3 – Functional representation of OS Standard 

function 

reset 

R 

Latched 

Trip 

AI 1 value 

Safety threshold 1 

AI 1 invalidity 

LOGIC TEST 

= 

NOT 

A 

≥1 

& 

S 

Override 

value 

SEL 

Override 

mode 

SEL 

0 

1 

OUTPUT 1 

R 

Latched 

Trip 

TRUE 

FALSE 

AI n value 

Safety threshold n 

LOGIC TEST 

= 

≥1 

& 

S 

AI n invalidity 

NOT 

LOGIC TRIP 

(OR) 

Override 

mode 

SEL 

R 

Latched 

Trip 

MATRIX 

SAFETY 

MANAGEMENT 

TRUE 

Override 

value 

SEL 

0 

1 

OUTPUT 2 

FALSE 

DI 1 trip 

DI 1 invalidity 

B 

≥1 

& 

S 

NOT 

Override 

mode 

SEL 

R 

Latched 

Trip 

Override 

value 

SEL 

0 

1 

OUTPUT 3 

DI n trip 

DI n invalidity 

≥1 

& 

S 

TRUE 

FALSE 

NOT 

Override number 

Override validation 

override 

Override enable 

Override disable 

DI : [...TS-OVRenab] 

DO : [...TS-OVRmode] 

A 

B 

Figure A3.1: Functional representation schema 

Page 94 of 95

APPENDIX 4 – Variable Table for OS Standard Emergency 

Button monitoring 

The appendix comprises the detailed list of all variable associated with the OS Standard Emergency Button 

monitoring. 

As described above, the function can monitor a maximum of 4 buttons. 


VARIABLE NAME DESCRIPTION FUNCTION NAME 

XXXX-YYYY-SF-EBnn-DI1-TS-INVALIDITY Digital input 1 - Invalidity XXXX-YYYY-SF 

XXXX-YYYY-SF-EBnn-DI1-TS-STATE Digital input 1 - State XXXX-YYYY-SF 

XXXX-YYYY-SF-EBnn-DI1-TAGNAME Digital input 1 - Name XXXX-YYYY-SF 










Table A4.1: Partial Variable Table of OS Standard Emergency Button Monitoring 

More details for each type of variable: 

The usage of the interface function variables is detailed in the tables below. 

Some variables are multiple, but only one kind of variable is described below. 

1 

XXXX-YYYY-SF:EBnn-DIx-TS-INPUTinvalid 

This is the PSS digital hardware safety input health signal (push button). If true, the variable means 

the input signal is unavailable (either because of a short-circuit or open-loop detection). 

This will normally raise the trip command of the CSS. 

This raises an alarm in the CSS-OS supervision and also in the hardware critical panel in the high 

integrity case. 

2 

XXXX-YYYY-SF:EBnn-DIx-TS-INPUTstate 

This variable is a Boolean. 

It is the process value of the emergency push button wired in the PSS and transmitted to the CSS to 

achieve the safety trip command or not. 

This raises an alarm in the CSS-OS supervision and also in the hardware critical panel in the high 

integrity case. 

3 

XXXX-YYYY-SF:EBnn-DIx-TAGNAME 

This is the digital input tagname. 

Page 95 of 95

Guidelines for PSS-OS design - Iter

Create successful ePaper yourself

Delete template?

Save as template?