Guidelines for PSS-OS design
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).
Author
CoAuthor
Reviewers
Approver
Read Access
Approval Process
Action
Affiliation
21-Dec-2012:signed
IO/DG/DIP/CHD/CSD/PCI
21-Dec-2012:signed
IO/DG/DIP/CHD/CSD/PCI
03-Jan-2013:signed
IO/DG/DIP/CHD/CSD/PCI
21-Dec-2012:signed
IO/DG/DIP/CHD/CSD
07-Jan-2013:signed
IO/DG/DIP/CHD/CSD/CDC
10-Jan-2013:recommended
IO/DG/DIP/CHD/CSD/PCI
09-Jan-2013:recommended
IO/DG/DIP/CHD/CSD/PCI
14-Jan-2013:recommended
IO/DG/DIP/CHD/CSD
09-Jan-2013:recommended
IO/DG/DIP/CHD/CSD/PCI
14-Jan-2013:approved
IO/DG/DIP
Document Security: level 1 (IO unclassified)
RO: Fourneron Jean-Marc
RO, project administrator, LG: PBS48 EXT, AD: ITER, AD: External Collaborators, AD: Section - CODAC,
AD: Section - Plant Control and Instrumentation
Name
Fourneron J.- M.
Badin R.
Delannoy N.
Pernin J.- M.
Petitpas P.
Yonekawa I.
Journeaux J.- Y.
Wallander A.
Fernandez Robles C.
Bak J.- S.
PDF generated on 14-Jan-2013
DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
Change Log
Title (Uid)
Versio
n
Latest Status
Issue Date
Description of Change
Creation of the document
Guidelines for PSS-OS
design (C99J7G_v1_0)
v1.0
Approved
21 Dec
2012
Guidelines for PSS-OS
design (C99J7G_v0_0)
v0.0
In Work
07 Nov
2012
PDF generated on 14-Jan-2013
DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
Guidelines for PSS-OS design
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
BCR
BSR
CDR
CFC
CSN
CSS
CIS
CODAC
CPU
EEE
E/E/PE
FAT
FDR
HFT
HIRA
HMI
HO
I&C
IEC
IO
I/O
IOC
LAS
MCR
MRR
MSR
OHS
OS
PBS
PCDH
PDR
PFD
PFH
Item
Backup Control Room (building 24)
Backup Server Room (building 24)
Conceptual Design review
Continuous Function Charts
Central Safety Network
Central Safety System
Central Interlock System
Control, Data Access and Communication
Central Processing Unit
Electronic, Electrical and Electromechanical
Electrical / Electronic / Programmable Electronic
Factory Acceptance Tests
Final Design Review
Hardware Fault Tolerant
Hazard Identification and Risk Assessment
Human-Machine Interface
Hand Over
Instrumentation & Control
International Electrotechnical Commission
ITER Organization
Input / Output
Input Output Controller
Local Access Safety
Main Control Room (building 71)
Manufacturing Readiness Review
Main Server Room (building 71)
Occupational Health and Safety
Occupational Safety
Plant Breakdown System
Plant Control Design Handbook
Preliminary Design Review
Probability of Failure on Demand
Probability of Failure per Hour
Page 6 of 95
PLC
PR
PS
PSCC
PSH
PSN
PSS
QC
RFE
RO
SAT
SCADA
SCS
SIL
SNP
SPSS
SQS
SRD
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
Safety Integrity Level
Safety Network Panel
Standard PLC Software Structure
Safety, Quality and Security Department
System Requirements Document
For a complete list of ITER
abbreviations refer to [RD11],
ITER
Abbreviations
[ITER_D_2MU6W5].
1.3 References
1.3.1 Reference
documents
[RD1].
Project
Requirements
(PR)
[ITER_D_27ZRW8 ]
[RD2].
Plant
Control
Design
Handbook
(PCDH)
[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].
[RS2].
IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related
systems.
IEC 61511: Functional safety- safety instrumented systems for the process industry sector.
1.3.3 Hardware Reference documents
[RD12].
[RD13].
[RD14].
[RD15].
[RD16].
[RD17].
[RD18].
[RD19].
[RD20].
ITER Catalogue for I&C products – Cubicle [ITER_D_35LXVZ]
ITER Catalogue for I&C products – Slow Controllers [ITER_D_333J63]
Guidelines for I&C Cubicle configurations [ITER_D_476HUG]
I&C Cubicle Monitoring System – Hardware Specifications [ITER_D_7KK29M]
I&C Cubicle Monitoring System – Functional Specifications [ITER_D_7A45LE]
I&C Cubicle Internal Configuration [ITER_D_4H5DW6]
Electrical design Handbook (EDH) [ITER_D_2F7HD2]
IO cable catalogue [ITER_D_355QX2]
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
OCCUPATIONAL SAFETY CONTROLS
Guidelines for PSS-OS design
NUCLEAR PCDH (2YNEFU)
CATALOGUES for PS CONTROL
Slow controllers products (333J63)
Fast controller products (345X28)
Cubicle products (35LXVZ)
Integration kit for PS I&C
PS CONTROL DESIGN
Plant system I&C architecture (32GEBH)
Methodology for PS I&C specifications (353AZY)
CODAC Core System Overview (34SDZ5)
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)
Figure 1.1: PCDH documents structure
Page 8 of 95
I&C CONVENTIONS
I&C Signal and variable naming (2UT8SH)
ITER CODAC Glossary (34QECT)
ITER CODAC Acronym list (2LT73V)
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.
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
responsibility
PBS.48 scope of
responsibility
PS I&C TROs
joined
responsibility
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
PCDH for OS I&C
PSS-OS guidelines
PBS.48 RO
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
Interface Sheets
PBS.xx/PBS.48
for OS I&C
PBS.xx
procurements
PBS.xx RO
Figure 2.1: OS I&C Specification
Page 9 of 95
PBS.48
Procurement
PBS.48 RO
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 PSSOS, 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
Safety Critical
Hardwired
HMI
CSS
OS
-OS
Sc
Sco
op
pe
e
CSS-OS
Terminal
Server-room
CSS-OS
Engineering
Workstation
CSS-OS
Maintenance
Terminal
CSS-OS
Safety PLC
CSS-OS
Servers
SCS
OS
-OS
Sc
Sco
op
pe
e
CSN-OS
PSS-OS
Safety PLC
PSSOS
OS
Sc
Scop
eop
Plant systems
e
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
CSS-OS
Safety
PLC
CSN-OS
Plant System
PSS-OS
Safety
PLC
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 CSSOS 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
Not used for this case
Monitoring
Coordination System
Risk detecting
System
Event or action transmission
Reset
Risk eliminating
System
Action
Event
Sensor
Actuator
Plant System
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.
Central System
Critical Monitoring
System
Safety Monitoring
System
Not used for this case
Reset
Monitoring
Monitoring
Monitoring
Coordination System
Action transmission
Event transmission
Risk detecting
System
Risk eliminating
System
Action
Event
Sensor
Actuator
Plant System X
Plant System Y
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.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.
Central System
Critical Monitoring
System
Critical Monitoring
Safety Monitoring
System
Monitoring
Critical Control
Monitoring
Event transmission
Reset
Monitoring
Coordination System
Action transmission
Risk detecting
System
Risk eliminating
System
Action
Event
Sensor
Actuator
Plant System X
Plant System Y
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.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.
CSS-OS
Critical Monitoring
System
Safety Monitoring
System
Monitoring
Critical Monitoring
Reset
Monitoring
Coordination System
CSS-N
Event transmission
Risk detecting
System
Event
Sensor
PBS69
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.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.
Central System
Critical Monitoring
System
Safety Monitoring
System
Monitoring
Critical Monitoring
Monitoring
Reset
Coordination System
Event transmission
Risk detecting
System
Event
Sensor
PBS69
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.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
PSS-OS 1
Event
Logic solver
Subsystem
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
SIL2 Local OS
Function
+
PSS-OS SIL2
Architecture
SIL3 Local OS
Function
PSS-OS SIL3
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
PSS-OS 1
CSS-OS
PSS-OS 2
Logic solver
Logic solver
Logic solver
Subsystem
Subsystem
Subsystem
Action
Subsystem
Central calculation
Plant System 1 integrity area example
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
SIL2 Local Part of
OS central
Function
+
PSS-OS SIL2
Architecture
SIL3 Local Part of
OS central
Function
PSS-OS SIL3
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
PFH2
PFH1
PSS-OS 1
Logic
solver
Event
Subsystem1
Subsystem2
SIL 2 CLAIM
PFH1 + PFH2 + PFH3 < 10-6
Plant System 1 integrity area example
Figure 2.13: Local Function mechanisms
Page 23 of 95
PFH3
Action
Subsystem3
Example 2: Central OS function in high demand mode
PFH2
PFH3
PFH4
Event
PSS-OS 1
Logic
solver
CSS-OS
Logic
solver
PSS-OS 2
Logic
solver
Action
Subsystem1
Subsystem2
Subsystem3
Subsystem4
Subsystem5
PFH1
PFH5
SIL 2 CLAIM
PFH1 + PFH2 + PFH3 + PFH4 + PFH5 < 10-6
Plant System 1 integrity area example
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.

1 out of 2 architecture (1oo2):
‘’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 corresponds to HFT=1.

2 out of 2 architecture (2oo2):
‘’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 corresponds to HFT=0.

2 out of 3 architecture (2oo3):
‘’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).
This architecture corresponds to HFT=1.
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.
Hazardous event
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
Fault Not Managed
Fault Managed
Activation Point
Actuator
time
Process Reacts
Time to React
Action Taken
Sensor
detection
time
Fault Detected
Fault Occurs
Process Safety Time
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
CSS-OS
Terminal
Server-room
SIEMENS
CSS-OS
Engineering
Maintenance
Workstation
Terminal
CSS-OS
Safety PLC
CSS-OS
Server
PLC IOC
CSN-OS
Plant systems
PSSx-OS
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.
Standard Availability
PLC Configuration
1 Objective
2 I/O Concepts
3 Architectures
Integrated I/O
Remote I/O
S7 Distributed
System
S7 Distributed
System
S7 F/FH
System
S7 300F CPU
S7 300F CPU
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
CSS-OS
Server PLC
IOC
CSN – OS1
CSN – OS2
PSS-OS
SIMATIC S7
SIMATIC S7
CPU 300F
CPU 315F
2 PN/DP
2 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
CSS-OS
Server PLC
IOC
CSS-OS
Safety PLC
CSN – OS1
CSN – OS2
PSS-OS
SIMATIC S7
S7
SIMATIC
300F -2PN/DP
PN/DP
CPU 315F-2
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.
General requirements for this architecture are:






A single CPU,
A single CPU station (rack),
A single field network,
A minimum of one remote I/O station,
Associated safety I/O modules,
A redundant connection with the redundant occupational safety acquisition networks.
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 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.
The characteristics of the selected hardware components are described in chapter 7. The characteristics of the
associated software tools are described in chapter 8.
Safety I/O modules
Figure 4.5: SIMATIC ET200M remote I/O station equipped with Safety I/O modules
Page 35 of 95
CSN – OS1
CSN – OS2
PSS-OS
SIMATICS7
S7
SIMATIC
CPU
300F
-2
PN/DP
CPU 315F-2 PN/DP
PSN – OS
PROFIBUS
SIMATIC S7
ET 200M
To other
Remote I/O
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.
General requirements for this architecture are:






A single CPU,
A single CPU station (rack),
A non-redundant field network,
A minimum of one remote I/O station,
Associated safety I/O modules,
A redundant connection with the redundant occupational safety acquisition networks.
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.
Detailed application for this architecture:




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 S7300 Safety I/O modules.
The characteristics of the selected hardware components are described in chapter 7. The characteristics of the
associated software tools are described in chapter 8.
Figure 4.7: SIMATIC S7-400 station mainly equipped with S7-400 5H CPU
CSN – OS1
CSN – OS2
PSS-OS
SIMATIC S7
CPU 400 5H-2 PN/DP
PSN – OS
PROFIBUS
SIMATIC S7
ET 200M
To other
Remote I/O
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).
General requirements for this architecture are:






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,
Associated safety I/O modules,
A redundant connection with the redundant occupational safety acquisition networks.
Detailed application for this architecture:




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).
The characteristics of the selected hardware components are described in chapter 7. The characteristics of the
associated software tools are described in chapter 8.
Page 38 of 95
CSN – OS1
CSN – OS2
REDUNDANT
SIMATIC S7
SIMATIC S7
CPU 400-5H
CPU 400-5H
PSN – OS1
PSS-OS
PSN – OS2
PROFIBUS
PROFIBUS
SIMATIC S7
ET 200M
REDUNDANT
SIMATIC S7
ET 200M
To other
Remote I/O
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
PSS-OS 1
PLC
Plant Safety System 1
Concentrator or Master
PSS-OS 2
PLC
PSN-OS
PROFIBUS DP
Plant Safety System 2
PSS-OS 3
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
Plant Safety System 1
Plant Safety System 2
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
SIGNAL VALID
(unsafe condition)
SAFETY
ACTIVATED
SIGNAL VALID
(safe condition)
SAFETY NOT
ACTIVATED
SIGNAL INVALID
(open circuit)
SAFETY
ACTIVATED
20,007 mA
Case 3
x mA
Case 2
3,9995 mA
Case 1
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
Conventional Control and Investment Protection Systems
Safety,
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 CSNOS 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
PSS-OS
Rack 0
PSa
PSb
CPU
C
P
a
C
P
b
Bus 0 Profinet
Bus 1 Profinet
Bus 0 Profibus
Sensor a
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
BACK-UP SWITCH
MAIN SWITCH
RJ45
RJ45
PSS-OS
Rack 0
PS0a
PS0b
CPU
0
PSS-OS
Rack 1
C
P
0
Sync
10m
Sync
10m
PS1a
PS1b
CPU
1
C
P
1
Bus 0 Profibus
Sync
10m
Sync
10m
FO (2m)
FO (2m)
DP
Bus 1 Profibus
Bus 0 Profinet
DP
Bus 1 Profinet
Sensor a
Actuator a
PSS-OS Periphery
Rack 2
DP
DP
IM0a
IM1a
DIa
DI
DOa
DO
DO
DO
AI
Sensor b
Actuator b
PSS-OS Periphery
Rack 3
DP
DP
IM0b
IM1b
DIb
DI
DOb
DO
DO
DO
AI
Sensor c
Actuator c
DP
DP
IM0c
IM1c
DIc
DI
DOc
DO
AI
PSS-OS Periphery
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,
Complies with safety requirements to SIL3 in accordance with IEC 61508,
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




Complies with safety requirements to SIL3 in accordance with IEC 61508,
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.





Complies with safety requirements to SIL3 in accordance with IEC 61508,
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
PSa
Class II-IP - 230Vac
PSb
DI
DI
DO
DO
AI
AI
Redundancy
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
PSa
PSb
DP
DP
IM0a
IM1a
DP
DP
IM0b
IM1b
DI
DI
DO
DO
AI
AI
DI
DI
DO
DO
AI
AI
Redundancy
1
Class II-IP - 230Vac
Redundant PS – 24Vdc
Class IV - 230Vac
Redundancy
2
Redundant PS – 24Vdc
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 CSSOS 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 CSSOS. 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 CSSOS. 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
normal
degraded
degraded
normal
tripped
TO
degraded
normal
tripped
tripped
normal
CONDITION
One of the component of the safety function becomes unavailable.
If all the components of the safety function become available
If an event or a major failure occurs
If an event or a major failure occurs
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
Alarming
Supervision display
/ monitoring
CSS-OS terminal
PSS logic treatment
Archiving
CSS-OS terminal
Operator action /
command
Archiving
OUTPUTS
INPUTS
Standard function
Function Ready to Reset
Reset command
31
Maintenance Set
32
Maintenance Reset
33
38
Function State
(Normal OR Degraded OR Tripped) 35
Function overrided
Function
37
Function in maintenance mode
36
Memorized state of each function input (x7) 34
Digital input state
X 4 DI
15
Digital input invalidity
14
Override Enable
17
Override Disable
18
Engineering value of the analog input
7
8
9
4 x safety thresholds value
3
4
5
X 3 AI
2
Analog input invalidity
Override Enable
Override Disable
Digital output state
X 3 DO
Output invalidity
Override Value
Override Mode
Override Number
29
Override Validation
30
1
4 x safety thresholds reached 6
Override
11
12
13
22
19
20
21
Override number
24
Override activation
26
Override desactivation
27
Override number + 10000
Window override validity
25
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
Alarming
Supervision display
/ monitoring
Archiving
PSS logic treatment
Archiving
CSS-OS terminal
Operator action /
command
CSS-OS terminal
OUTPUTS
INPUTS
Emergency Button
Emergency Button state
X4
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
MIS
MIE
OB1 User Program
Legend :
Outputs actualization
MIE
Inputs actualization
OB1 User Program
PCC
OBxx
T1
OBxx
T0
MIS
MIE
OB1 User Program
PCC
CYCLIC
PERIODIC
MIS
MIE
PCC
OBxx
Time
T3
Tasks
MIS
OB1
User program treatment
OBxx Periodic interuption
PCC
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 miniCSS-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 3rd 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
BACK-UP SWITCH
RJ45
Sensor a
Sensor b
RJ45
Actuator a
Actuator b
CPU
PSS-OS
Rack 0
C
P
a
C
P
b
DIa
DIb
DOa
DOb
DP
Bus 0 Profinet
Bus 1 Profinet
Figure A1.1: Architecture 1 Schema
Page 80 of 95
AI
AI
Architecture 2 – Standard availability architecture with Distributed IO configuration
Order No.
Designation
Quantity
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
6ES7326-1BK02-0AB0
Digital input 24DI 24V DC; diagnose fail-safe
2
6ES7326-2BF10-0AB0
Digital output 10DO DC 24V/2A PP; diagnose fail-safe
2
6ES7336-4GE00-0AB0
Analog input 6AI 15 bit; diagnostics fail-safe
2
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
6GK7343-1GX30-0XE0
CP 343-1 Advanced Industrial Ethernet S7-300
2
Table A1.2: Architecture 2 List of logic component
PBS.X Cubicle
MAIN SWITCH
BACK-UP SWITCH
RJ45
RJ45
PSS-OS
Rack 0
CPU
C
P
a
C
P
b
Sensor a
DP
Sensor b
Actuator a
Actuator b
DP
PSS-OS Periphery
Rack 1
IM0a
DIa
DIb
Bus 0 Profinet
Bus 1 Profinet
Bus 0 Profibus
Figure A1.2: Architecture 2 Schema
Page 81 of 95
DOa
DOb
AI
AI
Architecture 3 – Specific Standard availability architecture
Order No.
Designation
Quantity
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
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
6ES7392-1BJ00-0AA0
20-pin front connector with spring terminals
1
6ES7392-1BM01-0AA0
Front connector 40-pole with Cage Clamp terminals
2
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
6GK7443-1GX20-0XE0
CP 443-1 Advanced Industrial Ethernet S7-400
2
Table A1.3: Architecture 3 List of logic component
PBS.X Cubicle
MAIN SWITCH
BACK-UP SWITCH
RJ45
RJ45
PSS-OS
Rack 0
PSa
PSb
CPU
C
P
a
C
P
b
Sensor a
DP
Sensor b
Actuator a
Actuator b
DP
PSS-OS Periphery
Rack 1
IM0a
DIa
DIb
Bus 0 Profinet
Bus 1 Profinet
Bus 0 Profibus
Figure A1.3: Architecture 3 Schema
Page 82 of 95
DOa
DOb
AI
AI
Architecture 4 – High availability architecture with Distributed IO configuration
Order No.
Designation
Quantity
6ES7153-2BA02-0XB0
IM 153-2 High Feature for ET200M PROFIBUS DP
6
6ES7195-1GA00-0XA0
DIN rail for active bus modules 482mm (19")
3
6ES7195-7HB00-0XA0
Active bus module for 2 modules 40mm wide
3
6ES7195-7HC00-0XA0
Active bus module or 1 module 80 mm wide
3
6ES7195-7HD10-0XA0
Active bus module IM/IM for 2 IM153-2 High Feature
3
6ES7326-1BK02-0AB0
Digital input 24DI 24V DC; diagnose fail-safe
3
6ES7326-2BF10-0AB0
Digital output 10DO DC 24V/2A PP; diagnose fail-safe
3
6ES7336-4GE00-0AB0
Analog input 6AI 15 bit; diagnostics fail-safe
3
6ES7392-1BJ00-0AA0
20-pin front connector with spring terminals
3
6ES7392-1BM01-0AA0
Front connector 40-pole with Cage Clamp terminals
6
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
6GK7443-1GX20-0XE0
CP 443-1 Advanced Industrial Ethernet S7-400
2
Table A1.4: Architecture 4 List of logic component
Page 83 of 95
PBS.X Cubicle
BACK-UP SWITCH
MAIN SWITCH
RJ45
RJ45
PSS-OS
Rack 0
PS0a
PS0b
CPU
0
PSS-OS
Rack 1
C
P
0
Sync
10m
Sync
10m
PS1a
PS1b
CPU
1
C
P
1
Bus 0 Profibus
Sync
10m
Sync
10m
FO (2m)
FO (2m)
DP
Bus 1 Profibus
Bus 0 Profinet
DP
Bus 1 Profinet
Sensor a
Actuator a
PSS-OS Periphery
Rack 2
DP
DP
IM0a
IM1a
DIa
DI
DOa
DO
Sensor b
Actuator b
PSS-OS Periphery
Rack 3
DP
DP
IM0b
IM1b
DIb
DI
DOb
DO
DO
DO
AI
Sensor c
Actuator c
DP
DP
IM0c
IM1c
DIc
DI
DOc
DO
AI
PSS-OS Periphery
Rack 4
Figure A1.4: Architecture 4 Schema
Page 84 of 95
DO
DO
AI
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
Analog input 1 - High High safety threshold
reached
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI1-TS-SLLreach
Analog input 1 - Safety threshold SL reached
Analog input 1 - Low low saferty threshold
reached
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-ENGvalue
Analog input 2 - Engineering value
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI2-TM-SHvalue
Analog input 2 - High safety threshold value
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI2-TM-SHHvalue
Analog input 2 - High High safety threshold value
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
Analog input 2 - High High safety threshold
reached
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI2-TS-SLLreach
Analog input 2 - Safety threshold SL reached
Analog input 2 - Low low saferty threshold
reached
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
XXXX-YYYY-SF:IFnn-AI3-TM-ENGvalue
Analog input 3 - Engineering value
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI3-TM-SHvalue
Analog input 3 - High safety threshold value
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI3-TM-SHHvalue
Analog input 3 - High High safety threshold value
XXXX-YYYY-SF
XXXX-YYYY-SF:IFnn-AI1-TS-SHHreach
XXXX-YYYY-SF:IFnn-AI1-TS-SLreach
XXXX-YYYY-SF:IFnn-AI2-TS-SHHreach
XXXX-YYYY-SF:IFnn-AI2-TS-SLreach
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
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.
1
XXXX-YYYY-SF:IFnn-AI1-TM-ENGvalue
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.
XXXX-YYYY-SF:IFnn-AI1-TS-SHreach
6
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
7
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 alarm can be overridden.
This variable might be used to generate the very high level alarm.
XXXX-YYYY-SF:IFnn-AI1-TS-SLreach
8
9
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 alarm can be overridden.
This variable might be used to generate the low level alarm.
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 alarm can be overridden.
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.
XXXX-YYYY-SF:IFnn-AI1-TS-INVALIDITY
11
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.
XXXX-YYYY-SF:IFnn-AI1-TS-OVRenab
12
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).
XXXX-YYYY-SF:IFnn-AI1-TS-OVRdisab
13
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).
XXXX-YYYY-SF:IFnn-DI1-TS-INVALIDITY
14
15
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.
An alarm might be raised when this signal becomes true.
XXXX-YYYY-SF:IFnn-DI1-TS-STATE
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.
This setting is used as a maintenance reference parameter filled from the PLC database to be
displayed in the OS-supervision.
XXXX-YYYY-SF:IFnn-DI1-TS-OVRenab
17
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
This variable is combined with the other one (….TS-OVRdisab).
XXXX-YYYY-SF:IFnn-DI1-TS-OVRdisab
18
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.
This variable is combined with the other one (….TS-OVRdisab).
XXXX-YYYY-SF:IFnn-DO1-TS-INVALIDITY
19
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.
An alarm might be raised when this signal becomes true.
XXXX-YYYY-SF:IFnn-DO1-TS-OVRvalue
20
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.
XXXX-YYYY-SF:IFnn-DO1-TS-OVRmode
21
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.
This setting is used as a maintenance reference parameter filled from the PLC database to be
displayed in the OS-supervision.
XXXX-YYYY-SF:IFnn-OVR-TM-NUM
24
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<=[TM_OVER_number] <= 4999.
- for an override removal operation, 5000<=[TM_OVER_number] <= 9999.
This value is displayed in the OS-supervision override popup window (available for a maintenance
login).
Page 88 of 95
XXXX-YYYY-SF:IFnn-OVR-TM-NUM10000
25
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.
XXXX-YYYY-SF:IFnn-OVR-TS-ACTIV
26
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.
XXXX-YYYY-SF:IFnn-OVR-TS-WIN
28
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.
XXXX-YYYY-SF:IFnn-OVR-TC-VALID
30
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.
XXXX-YYYY-SF:IFnn-SAF-TC-MAINTreset
31
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.
XXXX-YYYY-SF:IFnn-SAF-TC-MAINTset
32
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.
XXXX-YYYY-SF:IFnn-SAF-TC-RESET
33
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.
XXXX-YYYY-SF:IFnn-SAF-TM-INPUTstate
34
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
bit1
bit2
bit3
bit4
memorized state of function DI1
memorized state of function DI2
memorized state of function DI3
memorized state of function DI4
AI 1 threshold reached
bit5
AI 2 threshold reached
bit6
AI 3 threshold reached
bit7
AI 4 threshold reached
bit8
bit9
bit10
bit11
bit12
bit13
bit14
bit15
spare
spare
spare
spare
spare
spare
spare
spare
True=Input 1 is tripped ; False=Input 1 is not tripped
True=Input 2 is tripped ; False=Input 2 is not tripped
True=Input 3 is tripped ; False=Input 3 is not tripped
True=Input 4 is tripped ; False=Input 4 is not tripped
True= A threshold on AI 1 is reached ; False = no threshold
AI 1 is reached
True= A threshold on AI 2 is reached ; False = no threshold
AI 2 is reached
True= A threshold on AI 3 is reached ; False = no threshold
AI 3 is reached
True= A threshold on AI 4 is reached ; False = no threshold
AI 4 is reached
XXXX-YYYY-SF:IFnn-SAF-TM-STATE
35
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
XXXX-YYYY-SF:IFnn-SAF-TS-MAINT
36
37
This is the maintenance alarm of the safety function managed by the Boolean commands […SAFTC-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
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
on
on
on
on
A dedicated alarm is set in the OS-supervision.
38
XXXX-YYYY-SF:IFnn-SAF-TS-RESETrdy
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.
This setting is used as a maintenance reference parameter filled from the PLC database to be
displayed in the OS-supervision.
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
DI 2
DI 3
DO 1
Infrared barrier #1
Infrared barrier #2
Infrared barrier #3
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
Function
Connection used
31
32
33
38
DI 1
15
14
17
18
DI 2
15
14
17
18
DI 3
15
14
17
18
DO 1
22
19
20
21
Override
29
30
24
26
35
27
25
37
36
34
28
Interface Function detail:
- PLC name: 99-ABCPLC-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.
Caution: The following list is a partial variable table.
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
AI 1 value
Safety threshold 1
S
LOGIC TEST
<= ; >=
A
≥1
AI 1 invalidity
Latched
Trip
Override
mode
SEL
&
0
NOT
Override
value
SEL
R
AI n value
Safety threshold n
1
OUTPUT 1
TRUE
Latched
Trip
FALSE
S
LOGIC TEST
<= ; >=
≥1
&
AI n invalidity
Override
mode
SEL
LOGIC TRIP
(OR)
NOT
0
MATRIX
SAFETY
MANAGEMENT
R
Latched
Trip
Override
value
SEL
1
OUTPUT 2
TRUE
FALSE
S
DI 1 trip
B
≥1
DI 1 invalidity
&
NOT
Override
mode
SEL
0
R
S
DI n trip
≥1
&
NOT
Override number
override
TRUE
FALSE
DI n invalidity
Override validation
Override
value
SEL
Latched
Trip
Override enable
DI : [...TS-OVRenab]
Override disable
DO : [...TS-OVRmode]
A
B
Figure A3.1: Functional representation schema
Page 94 of 95
1
OUTPUT 3
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.
Caution: The following list is a partial variable table.
VARIABLE NAME
DESCRIPTION
FUNCTION NAME
XXXX-YYYY-SF-EBnn-DI1-TS-INVALIDITY
XXXX-YYYY-SF-EBnn-DI1-TS-STATE
XXXX-YYYY-SF-EBnn-DI1-TAGNAME
XXXX-YYYY-SF-EBnn-DI2-TS-INVALIDITY
XXXX-YYYY-SF-EBnn-DI2-TS-STATE
XXXX-YYYY-SF-EBnn-DI2-TAGNAME
XXXX-YYYY-SF-EBnn-DI3-TS-INVALIDITY
XXXX-YYYY-SF-EBnn-DI3-TS-STATE
XXXX-YYYY-SF-EBnn-DI3-TAGNAME
XXXX-YYYY-SF-EBnn-DI4-TS-INVALIDITY
XXXX-YYYY-SF-EBnn-DI4-TS-STATE
XXXX-YYYY-SF-EBnn-DI4-TAGNAME
Digital input 1 - Invalidity
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
XXXX-YYYY-SF
Digital input 1 - State
Digital input 1 - Name
Digital input 2 - Invalidity
Digital input 2 - State
Digital input 2 - Name
Digital input 3 - Invalidity
Digital input 3 - State
Digital input 3 - Name
Digital input 4 - Invalidity
Digital input 4 - State
Digital input 4 - Name
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.
XXXX-YYYY-SF:EBnn-DIx-TS-INPUTinvalid
1
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.
XXXX-YYYY-SF:EBnn-DIx-TS-INPUTstate
2
3
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.
XXXX-YYYY-SF:EBnn-DIx-TAGNAME
This is the digital input tagname.
Page 95 of 95
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising