guidelines for pis configuration and integrationstatic.iter.org/codac/pcdh7/folder...

PDF generated on 22 Dec 2017DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

Memorandum / Note

Guidelines for PIS configuration and integrationThis document explains the guidelines to be followed by the plant system designers for the configuration and integration of the PIS. The document is the first version of one of the PCDH Satellite Documents for the interlocks.

Approval Process Name Action AffiliationAuthor Soni J. 21 Dec 2017:signed IO/DG/COO/SCOD/CSD/PCICo-Authors Gaikwad Y.

Pedica R. 21 Dec 2017:signed21 Dec 2017:signed

TATA Consultancy Services France SA...IO/DG/COO/SCOD/CSD/PCI

Reviewers Ciusa G. Fernandez-hernando J. L.Liu Y. Petitpas P. Prieto diaz I.

21 Dec 2017:recommended21 Dec 2017:recommended21 Dec 2017:recommended21 Dec 2017:recommended21 Dec 2017:recommended

IO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCI

Approver Wallander A. 22 Dec 2017:approved IO/DG/COO/SCOD/CSDDocument Security: Internal Use

RO: Fernandez-hernando Juan luisRead Access LG: CODAC team, LG: Interlock Gang, AD: ITER, AD: Only-staff, AD: External Collaborators, AD:

IO_Director-General, AD: EMAB, AD: Auditors, AD: ITER Management Assessor, project administrator, RO, AD: OBS - Control System Division (CSD) - EXT, AD: OBS - CODAC Section (CDC) - EXT, AD: OBS - CODAC Sect...

IDM UID

7LELG4VERSION CREATED ON / VERSION / STATUS

21 Dec 2017 / 4.0 / Approved

EXTERNAL REFERENCE / VERSION


Change Log

Guidelines for PIS configuration and integration (7LELG4)

Version Latest Status Issue Date Description of Change

v0.0 In Work 06 Nov 2012

v1.0 Approved 24 Jan 2013 Version for PCDH v7v2.0 Approved 18 Dec 2014 Added naming convention, software and hardware configuration, integration

and management strategy.v3.0 Approved 25 Apr 2016 More detailed information added to the guideline:

PIS Naming convention (Software/ Hardware / Variables) Slow Architecture (Siemens tools / Single CPU configuration / Fully fault tolerant configuration) - Software/ Program Structure - PLC Core application - Safety related interface with CIS - CIS Supervision interface (WinCC OA) - Interface with CODAC Integration and Management

The attached PLC Software Template provides: Software Settings for - Organization Block (i.e. Interrupt Timings; PIP) - FB/FC/DB/SFB/SFC (Numbering, Naming etc.) - Continuous Function Charts (i.e. Compilation, Downloading) - Memory Bits, Clocks, Timers, Counters. Standard Blocks for - Health Monitoring System - Time Stamp Push Protocol (TSPP Protocol) - Operator Integrity Commands (Three Step Overrides Verification) - Communication on TCP/IP (S7 Protocol) - Communication for Fault Tolerant Systems - Voter Logic - Threshold Logic Hardware Settings for -CPU (i.e. Max scan cycle, IO Process, Clock) -Input / Output Card (Numbering, Redundancy etc.) -Channel Level (i.e. Safety Parameters) -Network Configuration Runtime Group Organization for -Standard Program -Safety Program

v4.0 Approved 21 Dec 2017 The document has following major updates:

The scope of this PCDH document is to provide the guidelines to be followed by the plant system I&C suppliers and plant system I & C RO , for the configuration and integration of Slow/ Fast PIS . The older version document’s write up was mainly about the Slow PIS PLC software development which is mainly useful for the Slow PIS software developer and further, most of contains are already part of another document that is PIS PLC template (SDTX28) .

Hence considering the scope the document and readers, it was completely rewritten.

In the document main focus is given on concepts and recommendations for


configuration and integration of (Slow/Fast)PIS .

Following major topics are added/ updated in the document :

(1) Naming convention for Fast PIS (2) Configuration of Slow PIS - Hardware configuration - Software architectures and programing concepts (3) Configuration of Fast PIS - Hardware configuration - Software architectures and programing concepts (4) Management of PIS software

(5) Integration of slow and fast PIS - Recommendations for FAT - Recommendations for SAT

Guidelines for PIS Configuration and Integration (ITER_D_7LELG4)

Page 1 of 90

Table of Contents

1. Introduction ...................................................................................................................51.1 PCDH Context...........................................................................................................................................5

1.2 Document Scope ........................................................................................................................................5

1.3 Applicable Standards [AS].......................................................................................................................6

1.4 Related Documents [RD] ..........................................................................................................................6

1.5 Abbreviations and Acronyms ..................................................................................................................8

1.6 Definitions ..................................................................................................................................................9

1.7 Considerations.........................................................................................................................................10

1.8 Assumptions.............................................................................................................................................10

2. Principles......................................................................................................................112.1 Introduction.............................................................................................................................................11

2.2 Terminology.............................................................................................................................................12

3. Naming Convention for PIS .......................................................................................153.1 Naming convention for slow PIS............................................................................................................15

3.2 Naming convention for Fast PIS............................................................................................................15

3.2.1. Project and Hardware naming convention ..........................................................................................16

3.2.2. Variable naming convention.................................................................................................................17

4. Configuration of Slow PIS..........................................................................................234.1 Hardware configuration .........................................................................................................................23

4.2 Software Architecture and Programing concepts................................................................................24

4.2.1. Local interlock function implementation in Slow PIS ..........................................................................25

4.2.2. Part of Central interlock function implementation in slow PIS ...........................................................26

4.2.3. Concept of Override and Threshold value section ...............................................................................28

4.2.4. Concept of Reset ...................................................................................................................................33

4.2.5. Concept of Reintegration ......................................................................................................................34

4.2.6. Concept of Critical health monitoring..................................................................................................36

4.2.7. Concept of archiving and status Monitoring ........................................................................................38

4.2.8. Concept of conventional health monitoring and CODAC interface.....................................................40

5. Configuration of Fast PIS...........................................................................................42


Page 2 of 90

5.1 Hardware configuration .........................................................................................................................42

5.1.1. Hardware Configuration using Fast PIS Template..............................................................................42

5.1.2. Hardware Configuration for New project ............................................................................................45

5.2 Software architecture and Programming concepts .............................................................................46

5.2.1. Concept of archiving and status Monitoring ........................................................................................50

6. Management of PIS software .....................................................................................526.1 Version Control .......................................................................................................................................52

6.2 Repository Management.........................................................................................................................53

6.3 Development Process ..............................................................................................................................53

6.3.1. Scope areas for PIS Software development ..........................................................................................54

6.3.2. Off-Site Development and Stand-Alone Test (Independently from IO) ................................................55

7. Integration ...................................................................................................................577.1 Recommendation for FAT of PIS ..........................................................................................................57

7.1.1. Plant System FAT Context ....................................................................................................................57

7.1.2. PIS FAT Objective ................................................................................................................................57

7.1.3. Recommendations about the methodology ...........................................................................................58

7.1.4. Recommendations about the FAT scope...............................................................................................60

7.1.5. Recommendations for performing the campaigns ................................................................................61

7.1.6. Recommendations for checking the interfaces .....................................................................................69

7.2 Multiproject Integration Procedure......................................................................................................72

7.2.1. First Connection of a New PIS (one or several PLCs) to the CIS........................................................73

7.2.2. Update of a PIS configuration..............................................................................................................74

7.3 Recommendation for SAT of PIS ..........................................................................................................78

7.3.1. On-Site Integration Context..................................................................................................................78

7.3.2. Plant System SAT Context ....................................................................................................................78

7.3.3. Recommendations / Requirements about the methodology ..................................................................79

7.3.4. Recommendations for on-site integration activities .............................................................................80


Page 3 of 90

List of FiguresFigure 1: PCDH Documents Structure.....................................................................................................................5Figure 2: PIS Conceptual Software Architecture...................................................................................................24Figure 3: Typical slow local interlock protection function schema .......................................................................25Figure 4: Typical Event generation schema for central interlock function............................................................26Figure 5: Typical Action generation schema for central interlock function ..........................................................27Figure 6: Concept of Overrides..............................................................................................................................29Figure 7: Concept of threshold selection using HIOC protocol.............................................................................32Figure 8: Concept of RESET .................................................................................................................................34Figure 9: Concept of Reintegration........................................................................................................................36Figure 10: Concept of Critical health monitoring ..................................................................................................37Figure 11: Concept of archiving and status monitoring.........................................................................................39Figure 12: Conventional Health monitoring and CODAC.....................................................................................41Figure 13: Application of the naming convention .................................................................................................43Figure 14: Protection function’s number choice ....................................................................................................44Figure 15: Versioning of the bitfile........................................................................................................................44Figure 16: C API generator ....................................................................................................................................45Figure 17 : Fast PIS software architecture .............................................................................................................47Figure 18: FPGA Core application.........................................................................................................................48Figure 19: Status word structure ............................................................................................................................51Figure 20: Development Process Work Flow for slow PIS Applications..............................................................53Figure 21: Development Process Work Flow for Fast PIS Applications..............................................................54Figure 22: Off-Site Development...........................................................................................................................55Figure 23: Example of typical PIS FAT Test Environment...................................................................................65Figure 24: First Connection of New PIS with CIS.................................................................................................73Figure 25: Update PIS Configuration without affecting central functions ............................................................76Figure 26: Update of PIS affecting Central Functions...........................................................................................77Figure 27: Steps involved in onsite Integration .....................................................................................................80Figure 28: Steps involved in C4 Campaign ...........................................................................................................85


Page 4 of 90

List of TablesTable 1: Abbreviations and Acronyms.........................................................................................................8Table 2: Fast PIS Hardware naming convention .........................................................................................16Table 3: Fast PIS variable naming convention ............................................................................................17Table 4 : Override type and associated signals naming convention ...............................................................30Table 5: Critical Health Monitoring Signal ................................................................................................37Table 6: Approved cRIO modules .............................................................................................................45Table 7: Status word data .........................................................................................................................50

of 90

1. Introduction

1.1 PCDH Context

Standards, specifications and methodology as defined in [RD1] Plant Control Design Handbook (PCDH) (ITER_D_27LH2V) Plant Control Design Handbook (PCDH) (ITER_D_27LH2V)_Related Documents_[RD] and interfaces applicable to the whole life cycle of International Thermonuclear Experimental Reactor (ITER) plant system Instrumentation & Control (I&C) systems. I&C standards are essential for ITER to:1. Integrate all plant systems I&C into one Integrated Control System (ICS). 2. Maintain all plant systems I&C after delivery acceptance.3. Contain cost by economy of scale.PCDH comprises a of 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 detail in dedicated documents associated with PCDH as presented in Figure 1: PCDH Documents Structure. This document is one of them.

Core PCDH (27LH2V)Plant system control philosophyPlant system control Life CyclePlant system control specificationsCODAC interface specificationsInterlock I&C specificationSafety I&C specification

PCDH core and satellite documents: v7PS CONTROL DESIGN

Plant system I&C architecture (32GEBH)

Methodology for PS I&C specifications (353AZY)

CODAC Core System Overview (34SDZ5)INTERLOCK CONTROLS

Guidelines PIS design (3PZ2D2)

Guidelines for PIS integration & config. (7LELG4)

Management of local interlock functions (75ZVTY)

PIS Operation and Maintenance (7L9QXR)

I&C CONVENTIONSI&C Signal and variable naming (2UT8SH)

ITER CODAC Glossary (34QECT)

ITER CODAC Acronym list (2LT73V)

PS SELF DESCRIPTION DATASelf description schema documentation (34QXCP)

CATALOGUES for PS CONTROLSlow controllers products (333J63)

Fast controller products (345X28)

Cubicle products (35LXVZ)

Integration kit for PS I&C (C8X9AE)

PS CONTROL INTEGRATIONThe CODAC -PS Interface (34V362)

PS I&C integration plan (3VVU9W)

ITER alarm system management (3WCD7T)

ITER operator user interface (3XLESZ)

Guidelines for PON archiving (87N2B7)

PS Operating State management (AC2P4J)

Guidelines for Diagnostic data structure (354SJ3)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)

NUCLEAR PCDH (2YNEFU)

OCCUPATIONAL SAFETY CONTROLSGuidelines for PSS design

Available and approvedExpected

Legend

This document

(XXXXXX) IDM ref.

Guidelines for PIS integration & config. (7LELG4)

Figure 1: PCDH Documents Structure

1.2 Document Scope

This document provides the guidelines to be followed by the plant system I&C suppliers for the configuration and integration of the part of the plant system I&C, which implements the investment protection functions and interfaces with the Central Interlock System (CIS).This document does not provide the guidelines for the design of the plant system I&C, which implements the investment protection functions and interfaces with the CIS.

of 90

These are described in [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2).

1.3 Applicable Standards [AS]

[AS1]. IEC 61508 Functional safety of electrical/electronic/programmable electronic safety- related systems

[AS2]. IEC 61511 Functional safety – Safety instrumented systems for the process industry sector

1.4 Related Documents [RD]

[RD1]. Plant Control Design Handbook (PCDH) (ITER_D_27LH2V)[RD2]. Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2) [RD3]. Management of Local Interlock Functions (ITER_D_75ZVTY)[RD4]. PIS Operation and Maintenance (ITER_D_7L9QXR) [RD5]. Central Interlock System (PBS-46) - Design Description Document (DDD)

(QCH3GJ v2.2) [RD6]. Catalogue for I&C products – Slow controllers (ITER_D_333J63)[RD7]. PLC Software Engineering Handbook (ITER_D_3QPL4H)[RD8]. Interlock Control System – Overall Quality Plant (ITER_D_75GBSW)[RD9]. Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH)[RD10]. Plant System I&C Integration Plan (ITER_D_3VVU9W)[RD11]. ITER Operator User Interface (ITER_D_3XLESZ)[RD12]. ITER Alarm System Management (ITER_D_3WCD7T)[RD13]. Guidelines for PON Archiving (ITER_D_B7N2B7)[RD14]. ITER CODAC Subversion Guideline (ITER_D_A2GSXB)[RD15]. Core System Application Developer Manual (ITER_D_33T8LW)

[RD16]. CIS_V.0_WinCC_OA_Configuration_and_interfacing_with_PLC (ITER_D_PHK5CJ)

[RD17]. Implementation of High Integrity Operator Commands in the Interlock Control System (ITER_D_PKMDA8)

[RD18]. Standard PLC Software Structure (SPSS) User Manual (ITER_D_G4UMX5)[RD19]. ITER Control Breakdown Structure_ (CBS) (ITER_D_9TYFWC). [RD20]. CODAC Core System Overview (ITER_D_97W6Q9).[RD21]. CODAC Core System Installation Manual (ITER_D_33JNKW)[RD22]. Self-description data editor - User manual (ITER_D_32Z4W2)[RD23]. Standard PLC Template for Interlock Applications_ITER_D_SDTX28

https://user.iter.org/default.aspx?uid=27LH2V



https://user.iter.org/default.aspx?uid=3PZ2D2

https://user.iter.org/default.aspx?uid=75ZVTY

https://user.iter.org/default.aspx?uid=7L9QXR

https://user.iter.org/?uid=QCH3GJ

https://user.iter.org/?uid=QCH3GJ

https://user.iter.org/default.aspx?uid=333J63

https://user.iter.org/default.aspx?uid=3QPL4H

https://user.iter.org/default.aspx?uid=75GBSW

https://user.iter.org/default.aspx?uid=2UT8SH

https://user.iter.org/default.aspx?uid=3VVU9W

https://user.iter.org/default.aspx?uid=3XLESZ

https://user.iter.org/default.aspx?uid=3WCD7T

https://user.iter.org/default.aspx?uid=B7N2B7

https://user.iter.org/default.aspx?uid=A2GSXB

https://user.iter.org/default.aspx?uid=33T8LW

https://user.iter.org/default.aspx?uid=PHK5CJ

https://user.iter.org/default.aspx?uid=PHK5CJ

https://user.iter.org/default.aspx?uid=PKMDA8

https://user.iter.org/default.aspx?uid=PKMDA8

https://user.iter.org/default.aspx?uid=G4UMX5

https://user.iter.org/default.aspx?uid=97W6Q9

https://user.iter.org/default.aspx?uid=33JNKW

of 90

[RD24]. IEC 61508 Functional safety of electrical/electronic/programmable electronic safety related systems.

[RD25]. SIEMENS Manual: SIMATIC Industrial Software S7 F/FH Systems Configuring and Programming

[RD26]. "Fast PIS- WinCC OA Interface Module” User Manual (ITER D SVL3N9 )[RD27]. Review guidelines for Interlock Systems (PMUS5G v1.0)[RD28]. ITER On-Site Testing Strategy (ITER_D_44U2Y4)

http://www.geocities.jp/matchmoinfo/Infoyard/FunctionalSafety_IEC_2003.pdf

http://www.geocities.jp/matchmoinfo/Infoyard/FunctionalSafety_IEC_2003.pdf

https://support.industry.siemens.com/cs/document/2201072/simatic-industrial-software-s7-f-fh-system-configuration-and-programming?dti=0&lc=en-WW

https://support.industry.siemens.com/cs/document/2201072/simatic-industrial-software-s7-f-fh-system-configuration-and-programming?dti=0&lc=en-WW

https://user.iter.org/?uid=SVL3N9

https://user.iter.org/?uid=PMUS5G

https://user.iter.org/default.aspx?uid=44U2Y4

of 90

1.5 Abbreviations and Acronyms

The following table shows the abbreviations and acronyms used in this document. The relevant abbreviations or acronyms have been extracted from the complete list in PCDH.

Table 1: Abbreviations and Acronyms

Abbreviation or Acronym Expansion

CIN Central Interlock Network

CIS Central Interlock System

CP Communication Processor

CPU Central Processing Unit

CODAC Control, Data Access and Communication

EPICS Experimental Physics and Industrial Control System

ES Engineering Station

FH Fault Tolerant (Specifically used for Siemens System)

GOS Global Operating State

HIOC High Integrity Operator Commands

HMI Human Machine Interface

I&C Instrumentation & Control

ICS Interlock Control System

I/O Input / Output

IO ITER Organization

IOC Input Output Controller

PBS Plant Breakdown System

PCDH Plant Control Design Handbook

PIN Plant Interlock Network

of 90

Abbreviation or Acronym Expansion

PIS Plant Interlock System

PLC Programmable Logic Controller

PON Plant Operation Network

PS Power Supply

PSCC Plant System Conventional Control

PSH Plant System Host

PSS-OS Plant Safety System- Occupational safety

PVN Private Network Identifier

SCADA Supervisory Control and Data Acquisition

WinCC OA Windows Control Center Open Architecture

1.6 Definitions

I/O ModuleBoard installed close to the Central Processing Unit (CPU) or connected to the CPU remotely in order to report/transmit signals from/to the field

Local NetworkCommunication network is considered as a Local Network when communication between Local racks, Remote racks from CPU or Communication Processor (CP) over network bus.

Central Network

Communication network is considered as a Central Network when central system communicating with rest of system / sub system over network bus. e.g. Control, Data Access and Communication (CODAC), Interlock, Occupational Safety

FBProfibus (any Field Bus) communication from controller (from PIS/CIS to remote I/O) is termed as FB in slow PIS PLC naming convention.

FNProfinet (any Field Net) communication from controller (from PIS/CIS to remote I/O) is termed as FN in slow PIS PLC naming convention.

of 90

1.7 Considerations

As explained in the [RD3] Management of Local Interlock Functions (ITER_D_75ZVTY) document, safety is a term that should not be used when describing the interlock system. Nevertheless, this term will be used in the expression ‘safety-related’ as opposed to normal or standard. Moreover, as the Siemens PLC are divided into two parts (standard and safety), this term will also be used in the expressions ‘safety program’ and ‘safety data’ to distinguish the safety part of the interlock systems.

As explained in [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2), critical interlock data is used for performing the machine protection functions while the non-critical interlock data does not directly participate in the interlock functions (that is, reset, analog values etc.).

WinCC Open Architecture (WinCC OA) is the Supervisory Control and Data Acquisition (SCADA) solution selected for the Central Interlock Network (CIS). It is completely in the scope of PBS-46 (Central Interlock System). The developers of the PIS will follow the rules explained in the current document but no additional configuration will be required from the plant system developer. Justification on the selection of this solution can be found in ITER_D_ATSJJN Study of human Factors applied to the operation of the ITER interlocks.

1.8 Assumptions

The reader is well-versed with the conventions and standards [RD1] Plant Control Design Handbook (PCDH) (ITER_D_27LH2V) and [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2)

The reader is well-versed with the Plant System Instrumentation & Control (I&C) architecture and [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W)

The reader is well-versed with CODAC Core System overview [RD21] CODAC Core System Overview (ITER_D_97W6Q9).

https://user.iter.org/default.aspx?uid=ATSJJN

https://user.iter.org/default.aspx?uid=ATSJJN

of 90

2. Principles

2.1 Introduction

The plant systems are the main parts of the ITER facility and will be delivered by the project members with their own control systems (Plant System I&Cs). The plant interlock systems are a part of plant system I&Cs, which implement the investment protection functions.As described in [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2) the plant interlock systems comprise two architectural types:

1. Slow PIS architecture based on PLCs2. Fast PIS architecture based on fast controllers

- It is important to standardize the configuration of the plant interlock systems in order to facilitate their integration, commissioning and maintenance. Due to the different technologies used in each architecture, different tools are needed to develop the software of each of them. However, the software structure and concepts will be kept the same as far as possible.

- As is explained in reference [RD4] PIS Operation and Maintenance (ITER_D_7L9QXR) , Operations on interlocks are allowed from both the CIS and the CODAC infrastructure. The standardization of the treatment of interlock data (that is, monitoring, logging and so on) at the CIS level is provided by PBS-46 (Central Interlock System) and at CODAC level is provided by each plant system. In order to achieve this, some guidelines in addition to the general CODAC guidelines have to be followed during the configuration of the CODAC interface.

- At the installation phase, each plant system is incorporated in ITER in one main step but the installation schedule of the plant systems covers many years. Therefore, some PIS involved in central interlock functions will be available years after others involved in the same central interlock functions. This requires specific means to minimize errors and the time taken during the integration and commissioning of the various PIS.

- As detailed in the Interlock Control System (ICS) Overall Quality Plan [RD8] Interlock Control System – Overall Quality Plant (ITER_D_75GBSW), the plant system reviews process must take into account and meet the requirements of IEC 61508 as far as possible. The system lifecycle will be clearly documented in order to facilitate future verification and modifications by ITER Organization

- For uniform development, seamless integration and easy maintenance of PIS, it is strongly recommended to follow the guidelines mentioned in this document during the configuration and integration of the PIS.

This document is mainly focused on the configuration and integration of two possible PIS architecture. First part is focused on the configuration of Slow and Fast PIS; and second part provides the guidelines for PIS FAT and SAT.

of 90

2.2 Terminology

Central Interlock System (CIS) The Central Interlock System (CIS) together with CODAC and the Central Safety System (CSS), forms the ITER I&C Central Systems. The CIS is in charge of implementing the central protection functions via the Plant Interlock Systems (PIS) and, if required, some direct actuators. It also provides access to the local interlock data of the different plant Interlock Systems.

Plant Interlock Systems (PIS)The Plant Interlock Systems (PIS) are part of the plant systems I&C. Each PIS provides local protection by implementing the local interlock functions of the corresponding plant system. Also, most of the PIS participate in the central interlock functions coordinated by the CIS. All the sensors and actuators involved in machine protection in ITER are connected to at least one PIS in their plant system. The PIS constitutes the interface between the CIS and the plant systems.Only plant systems I&C participating in inter-plant interlocks or implementing local investment protection functions are integrated in the Interlock Control System (ICS) architecture.

Central Interlock Network (CIN)The Central Interlock Network (CIN) provides communication between the Plant Interlock Systems and the Central Interlock System for inter-plant systems investment protection functions. Only plant system’s I&C participating in inter-plant system investment protection functions, or performing local investment protection functions, are connected to the CIS via CIN.

Plant Interlock Network (PIN)The Plant Interlock Network (PIN) provides communication between the controllers involved in the investment protection functions inside same plant system over a network bus. For the plant systems with more than one PIS, the PIN will be used to inter connect them. The PIN in one Plant System shall not be shared with other Plant Systems.

Interlock Control System (ICS)The Interlock Control System (ICS) is in charge of the supervision and control of all the ITER components involved in the instrumented protection of the ITER plant systems. It comprises the Central Interlock System (CIS), the different Plant Interlock Systems (PIS) and its networks (CIN and PIN). The ICS does not include the sensors and actuators of the plant systems but controls them through PIS.

of 90

Interlock EventThis is the plant system state or combination of states involving different plant systems that triggers an action of the corresponding PIS and/or the CIS.

Interlock Action These are measures or sequences of measures carried out by the CIS and/or the PIS to mitigate the risks following an interlock event. These protection actions are managed by the PIS when the measures are restricted to the plant system that generated the interlock event and by the CIS when different plant systems are involved.

Interlock FunctionThis is the logical description of the interlock actions following an interlock event. These functions are classified into two categories as explained in [RD2] , that is local interlock function and central interlock function.

Critical Interlock DataThere are interlock signals performing the machine protection functions transmitted via the CIN and PIN. They are divided into:

o Critical Automatic Data:

Data that is exchanged between CIS modules and PIS modules and is directly involved in the central interlock functions (events, actions) is called critical automatic data. This data is generated from logical / functional behaviour in controllers.

Following are the examples of critical automatic data:

- Interlock events (Boolean). Example: wrong plasma current.- Interlock actions (Boolean). Example: Disruption Mitigation System trigger.

o Critical Manual Data:-

- Data that is exchanged between CIS modules and PIS modules and directly involves manual actions/ triggering is called critical manual data. This data is generated from supervisory module and is transferred to controllers for performing further logic.

Critical manual data includes:

Override Interlock Configuration Data (Threshold Values etc.)

E.g. Manual operation commands. Example: Overrides.

of 90

Non-Critical Interlock DataInformation treated by the PIS and the CIS which, although needed, does not directly participate in the interlock function. For instance, the reset (unlatch) of interlock functions, actuators and sensors, or the analog values of the temperature, pressure etc.For example, in case of cryogenics, temperature values are used to decide whether the magnets can be powered or not, these values are used in PIS to generate the interlock event. However, only the interlock event (critical data) signal is routed to the CIS via the CIN while the temperature values (non-critical data) are sent to CODAC via the PON network.

of 90

3. Naming Convention for PIS

Naming convention of PIS is divided in mainly two parts according to architecture type:

3.1 Naming convention for slow PIS

In case of slow PIS, naming convention recommendation covers the following:

1) Project and Hardware naming convention in Step7 2) Block naming and numbering convention in Step 7 3) Variable naming convention

For more detail about the slow PIS naming convention please refer to [RD23].

3.2 Naming convention for Fast PIS

In case of fast PIS, naming convention is mainly recommended for the following: 1. Project and Hardware naming convention2. Variable naming convention

of 90

3.2.1. Project and Hardware naming convention

Following Table 2 depicts Fast PIS Project and Hardware naming convention

Table 2: Fast PIS Hardware naming convention

Item Proposed Naming Convention Significance and Example

AAAA This signifies the CBS level 1 of the Controller.

BBBB This signifies the CBS level 2 of the Controller.

CCCCCParticularly CCCCC must make the difference between projects that will coexist in the same Plant System

Project Name AAAA_BBBB_CCCCC

Example CRYO_CA_ICU01PPPPPP Plant Breakdown Structure (PBS) IdentifierTTT Component functional category designator

NNNN Sequential number. It is also indicating the domain of the component.

Chassis/Host PC Name PPPPPP_TTT_NNNN

Example 460100_PFC _4000

Chassis ID Chassis ID where signal module is installed CR1 or CR2

Signal Module Identifier

Sequential number of Signal module with suffix of SM The slot position must match with the Signal module Identifier number

Type of Module Identifier Analog or Digital Input/output type.

CR1_SM01_DI

Input/Output Modules

Chassis ID_Signal module identifier _Type of Module identifier

Example CR2_SM03_AO

of 90

3.2.2. Variable naming convention

Following Table 3 depicts Fast PIS Variable naming convention :

Table 3: Fast PIS variable naming convention

Significance and ExampleItem

target Proposed Naming Convention

KKK Chassis indicator, it indicates the Chassis where

the variable is generated.|CH1 Chassis 1 |CH2 Chassis 2

TTTNNNN_AAAA [RRRR]

The Variable identifier part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH).CR1_MT0001_TT0001

Labview Variable

KKK_TTTNNNN_AAAA[RRRR]

ExampleCR2_MT0001_TT0001

FFFF-FFFF-FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH).

KKK Indicator of the Chassis that receive the signals CH1 or CH2

TTTNNNN_AAAA[RRRR]

This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). MAG-MATF-INTF:CR1_ MT0001_TT

Var

iabl

es L

inke

d to

Sig

nal

CODAC PV FFFF-FFFF-FFFF:KKK_TTTNNNN_AAAA[RRRR]

Example MAG-MATF-INTF:CR2_ MT0001_TT

of 90

FFFF_FFFF_FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH).

KKK Indicator of the Chassis that receive the signals CR1 or CR2

TTTNNNN_AAAA[RRRR]

This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). MAG_MATF_INTF_CR1_ MT0001_TT

WinCC OA Datapoint

FFFF_FFFF_FFFF_KKK_TTTNNNN_AAAA[RRRR]

Example

MAG_MATF_INTF_CR2_ MT0001_TTKKK Chassis indicator, it indicates the Chassis where

the variable is generated.CR1 Chassis 1 CR2 Chassis 2

VVVVVVVVV Free textual description used to explain the function of the variable.

Var

iabl

es C

ompu

ted

by

the

PIS

Labview Variable

KKKK_VVVVVVVVV_GGGH[RR]

GGG Maximum Three Character is the identifier of the variable. § MSK Mask§ THR Threshold§ FRC Force § CRT Critical § RAW Raw data § STS Status§ ACK Acknowledge

of 90

H One character field used as optional attribute in case of Mask, Threshold and Force Variables.§ P Pulse § L Level § C Command§ S Status § R Reset

[RR] Sequential Number if required to discriminate signal with the same name CR1_CRYOOK_MSKP01Example CR2_CRYOOK_MSKP01

FFFF_FFFF_FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). With reference to the Control function identifier and Variable Identifier

KKK Chassis indicator , it indicates the Chassis where the variable is generated.CR1 Chassis 1 CR2 Chassis 2

VVVVVVVVV Suggested length nine characters the free textual description used to explain the function of the variable.

CODAC PV FFFF-FFFF-FFFF:KKK_VVVVVVVVV_GGGH[RR]

GGG Maximum Three Character is the identifier of the variable. § MSK Mask§ THR Threshold§ FRC Force § CRT Critical § RAW Raw data § STS Status

of 90

§ ACK Acknowledge


[RR] Sequential Number if required to discriminate signal with same name CRYO-CA-LIN1:CR1_CRYOOK_MSKP01Example CRYO-CA-LIN1:CR2_CRYOOK_MSKP01

FFFF_FFFF_FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). With reference to the Control function identifier and Variable Identifier

KKK Chassis indicator, it indicates the Chassis where the variable is generated.CR1 Chassis 1 CR2 Chassis 2

WinCC OA Datapoint

FFFF_FFFF_FFFF_KKK_VVVVVVVVV_GGGH[RR]

VVVVVVVVV Suggested length nine characters the free textual description used to explain the function of the variable.

of 90

GGG Maximum Three Character is the identifier of the variable. § MSK Mask§ THR Threshold§ FRC Force § CRT Critical § RAW Raw data § STS Status§ ACK Acknowledge


[RR] Sequential Number if required to discriminate signal with same name CRYO_CA_LIN1_CR1_CRYOOK_MSKP01Example

CRYO_CA_LIN1_CR1_CRYOOK_MSKP01TTTNNNN Component name following the CODAC

Naming ConventionHPC_COM Communication with Host PC statusCR_COM Communication with Partner Chassis StatusSM[N] Health Status of the ModuleN DSP_V[N] Discrepancy status of voter N

HltStatusVAr

ERR_F[N] FPGA error staus of Function N PCF1501_HPC_COMC

ritic

al H

ealth

Mon

itori

ng

Var

iabl

es

Labview Variables

TTTNNNN_HltStatusVAr

Example PCF1501_CR_COM

of 90

PCF1501_SM1PCF1501_DSP_V1PCF1501_ERR_F1

FFFF CBS level 1 following CODAC conventionFFFF CBS level 2 following CODAC conventionFFFF fixed code ‘SYSM’ dedicated to system

monitoringHPC_COM Communication with Host PC statusCR_COM Communication with Partner Chassis StatusSM[N] Health Status of the ModuleN DSP_V[N] Discrepancy status of voter N

HltStatusVAr

ERR_F[N] FPGA error status of Function N MAG_PFCS_SYSM_PCF1501_HPC_COM

MAG_PFCS_SYSM_PCF1501_CR_COMMAG_PFCS_SYSM_PCF1501_SM1MAG_PFCS_SYSM_PCF1501_DSP_V1

WinCC OA Datapoint

FFFF_FFFF_FFFF_ TTTNNNN_HltStatusVar

Example

MAG_PFCS_SYSM_PCF1501_ERR_F1

of 90

4. Configuration of Slow PIS

For standardising the slow PIS hardware configuration and software architecture throughout all the suppliers and help the PIS developers, the PBS 46 (CIS) team has developed the PIS PLC template. The PIS PLC templet is a pre-configured and ready to use PLC project. The main features of the PIS PLC template are:

- Two Generic templates for Standalone and Fully fault tolerant PIS configuration development.

- Pre-configuration of all the recommended hardware setting and network interfaces

- Generic naming of hardware components, functions and charts. Hence, easy to customised for any PIS.

- Modular software architecture

- Contain customised library : PIS_LIB, which have specially developed and tested safety function blocks and charts for its use in the PIS application

- Ready to use CFC charts and DB’s for implementation of CIS interface, CODAC interface, critical health monitoring, overrides etc.

The PIS PLC application is supported by the document [RD23]. The main features of the document are:

- Slow PIS project workflow mentioned in template for systematic and consistent development

- Well defined guidelines on ‘how to manage safety and standard PLC programming and communication’

- Optimum performance can be achieved through programing rules and f-runtime group rules described in template

For complete step by step guidelines of how to use PIS PLC template and configure the slow PIS, please refer [RD23]. Below sections only provides the overview on hardware configuration and software programing using the PIS PLC templates.

4.1 Hardware configuration

Recommendations of the hardware configuration are mainly focused on the recommended settings for the PIS PLC hardware configuration in Step 7. The recommendations are required to maintain the uniform PIS hardware configuration throughout the ITER project and seamless integration of PIS with CIS and CODAC. Please refer the [RD24] Standard PLC Template for Interlock Applications_ITER_D_SDTX28, for complete step by step guidelines for hardware configuration using the PIS PLC template.

of 90

4.2 Software Architecture and Programing concepts

The recommended PIS software architecture is shown in Figure 2, it is strongly recommended to use the PIS PLC template project. In order to simplify the program organization, maintenance, debugging and commissioning, the architecture is structured in blocks/modules. The S7 program in the CPU module consists of fail-safe components (safety program) and non-fail-safe components (standard program).The blocks/modules directly involved in interlock functions (safety-related communications and logic) are in the PLC safety program whereas the other blocks/modules (standard communication or monitoring) can be in the standard program. Data exchanged between the user safety program and the user standard program in the F-CPU can be done using special F-Blocks for data conversion.The PLC safety program will consist of fail-safe blocks selected from an F-Library, interconnected using the CFC programming language. During the compilation, fault control measures are automatically added to the safety program and additional safety-related tests are performed.The PIS standard programs should be configured using the graphical languages of STEP-7 (CFC, LAD or FBD if necessary), SCL Language can be used in Standard program, whereas in safety program SCL Language shall be avoided. Usage of pointers is totally forbidden.

Figure 2: PIS Conceptual Software Architecture

of 90

4.2.1. Local interlock function implementation in Slow PIS

Local interlock function is a machine’s protection function, where the interlock event and the interlock action(s) occur in the same plant system. The CIS does not play an active role in the protection function and it shall be only informed on the change of state of the plant system. Typical schema of implementation of the local interlock function in slow PIS is shown in Figure 3. Main steps of the local interlock functions implementation are:1) Reading the input through channel driver to detect the event 2) Apply voter logic (include channel diagnostic, if needed) to confirm the event 3) Apply Mask logic, if event is overridable 4) Apply the functional logic to generate the mitigation action command 5) Apply function disable logic, if function is overridable6) Apply Force logic if action is overridable 7) Apply the reset logic to latch/unlatch the action command8) Send the action output to the single/multiple output port (based on output voter logic)

through channel driver

Ready to Reset

Ready to Reset

Notification*

Voter Result

Event Masking

Command

Condition 1Condition 2 Condition 3

Event Protective Action

Function Reset

Event Masked

Notification

Input1Input2Input3

Action Forcing

Command

Action Forcing

Notification

SR

Function/action Activation Notification

Function Reset*

Function Disable

Function Disable

Notification

Voter Logic Solver

Local Function

Logic Action

* TO/FROM CODAC

2oo3

Figure 3: Typical slow local interlock protection function schema

of 90

4.2.2. Part of Central interlock function implementation in slow PIS

The central interlock function is a machine’s protection function involving two or more plant systems. The interlock events are generated by the slow PIS and transmitted via the CIN to the CIS protection modules, which takes an interlock decision and dispatches the required interlock actions to the slow PIS of the other plant systems involved. Typical schema of PIS implementation of event and action, as part of a central interlock function, is shown in Figure 4 and Figure 5.

Condition 1Condition 2

EVENT

Ready to Reset

Ready to Reset

Notification*

Voter Results

Event Masking

Event

Event Reset

Event Masked Notification

Event Reset *

Input1Input2Input3

SR

TO CIS

EVENT

Condition 1Condition 2 Condition 3

2oo3

* TO/FROM CODAC

Voter Logic Solver

Figure 4: Typical Event generation schema for central interlock function

of 90

ACTION

Action Forcing

Protective Action

command

SR

Action ActivatedNotification

Ready to Reset

Ready to Reset

Notification* Condition 1Condition 2 Condition 3

Function Reset* Function Reset Notification

Action ForcedNotification

FROM CIS

* TO/FROM CODAC

Figure 5: Typical Action generation schema for central interlock function

Function of Event detecting PIS: 1) Reading the input through channel driver to detect the event 2) Apply voter logic (include channel diagnostic, if needed) to confirm the event 3) Apply Mask logic, if event is overridable 4) Apply the reset logic to latch/unlatch the event 5) Send Event to the CIS Module through fail safe communication

of 90

Coordination Function of CIS : 1) Based on event, the CIS takes an interlock decision and dispatches required interlock

actions to the slow PIS of different plant system through fail safe communication

Function of Action performing PIS: 1) Receive the action command from the CIS 2) Apply the Force Logic , if action is overridable 3) Apply the reset logic to latch/unlatch the action commands4) Send the action command to the single/multiple output port (based on output voter logic)

through channel driver

4.2.3. Concept of Override and Threshold value section

4.2.3.1. Concept of Override

Interlock functions are put in place to protect ITER from incorrect operation and other hazards. Therefore masking an interlock event, disabling an interlock function or forcing an interlock action should be avoided as much as possible. However, in some situations during commissioning and maintenance, it is necessary to operate certain systems outside their nominal conditions through application of override. These critical operator actions are only available from the CIS Desk, and only can be performed after the convenient administrative procedures have been correctly completed.

The main aspects of override implementation in slow PIS are as follows:

Override operation shall not be performed from the plant system or CODAC conventional screens. Operation shall be performed from the CIS operation desk.

These critical operations that present a potential hazard must be managed in a way that the operator is aware at all times of the operation execution.

It provides a method for assuring that the command sent from the operator has been correctly received and executed in the controller.

Override signals must send through communication bus that comply with the safety standards IEC 61508, IEC 61784-3 and IEC 61783-3 OR ensure that safety-bus frame must be passed completely unmodified from a safety sender to a safety receiver

of 90

In ITER interlock system, s7 communication between PIS PLC and WinCC OA SCADA does not ensure the send/receive of unmodified bus frame. To comply with above requirements and implement override from WinCC-OA, the CIS team has developed High Integrity Operator command (HIOC) protocol. The HIOC protocol has three step validation processes which ensure the integrity of the transmitted message over S7 communication. The HIOC protocol and the concept of three step validation procedure are discussed in detail in [RD17].

The implementation of an override shall be configured using the PIS PLC template chart: "HIOC_BO” which includes two ready to use HIOC implementation blocks, whichare available on the PIS library “PIS_LIB”.

o Standard block: HIOC_STD ( S_OC_BO )o Safety block: HIOC_SFT ( F_OC_BO)

The standard program block (HIOC_STD) is in chargeof the SCADA communication whereas safety program block (HIOC_SFT) is checking the signal integrity.

Step by step procedure for Implementation of override in slow PIS along with ready to use HIOC blocks and charts are given in PIS PLC template [RD23]. The below section only provides the overview of the implementation of overrides through HIOC protocol.

A typical override implementation schema using PIS_LIB blocks is show in Figure 6.

Request ID, Command ID, Confirmation ID

SLOW PIS PLC

Data Conversion between Safety and Standard

HIOC_STD

FB 1023:S_OC_BO FB 1024: F_OC_BO

Critical signal BeforeOverride (XX-CRT)

Critical signal After Override (XX-CRTO)

Three Step Validation

CIS Desk (WinCC-OA Client)

Supervisiory Module(WinCC-OA Server)

CIS

SCADA_HIOCDB 1016

SAFETY PROGRAMSTANDARD PROGRAM

HIOC_SFT

F_Q_OVRC

F_CRTOF_OVRSF_CRT

Figure 6: Concept of Overrides

of 90

As shown in Figure 6, the application of an override on a critical signal (event/action) shall be implemented by a logical “OR”operation of the critical signal before override (XX_CRT) and override command (F_Q_OVRC) from safety program block (HIOC_SFT). After the application of the override, the critical signal variable name suffix should be changed to CRTO from CRT, as per the PIS naming convection.

Data exchanged between Safety program block (HIOC_SFT) and standard program block (HIOC_STD) are already integrated in the PIS PLC template chart for HIOC.

Override command is sent from the CIS operator desk, and only applied after thePIS PLC validation through the HIOC protocol’s three step validation method. Only after successful validation in HIOC_SFT block, the override command (F_Q_OVRC) is available at output of HIOC_SFT block to apply the override on the critical signal. Notification of override command (F_OVERS), Status of critical signals before override (XX_CRT) and after override (XX_CRTO) shall be connected to the HIOC_SFT block. , standard program block HIOC_STD shall update these statuses in DB 1016 (SCADA_HIOC), after safety to standard data conversion.

The DB 1016 is used for storing the HIOC verification messages and statuses from the HIOC_STD block. In the DB 1016, statuses per override are integrated in a signal Double word signal “QDW”. For more details about QDW refer [RD23].

Data in DB 1016 (SCADA_HIOC) is then sent to the CIS desk (WinCC OA Client) from PIS PLC through Supervisor module (WinCC OA server). Figure 6, represents the detail flow of data exchange between CIS and PIS PLC.

In Table 4, example of override types and its associated signals and variable naming convention are given for reference from PBS 34. Similar variable naming convention for override shall be applied in the PIS software.

Table 4 : Override type and associated signals naming convention

Override type

Override command

Override status Critical signal before override

Critical signal after override

Event Mask CRYOSTART_ MSK

CRYOSTART _MSKS

CRYOSTART_CRT

CRYOSTART_CRTO

Action Force

XX_FRC XX_FRCS XX_CRT XX_CRTO

Function Disabled

XX_DSB XX_DSBS XX_CRT XX_CRTO

of 90

Normally override for event and action is applied at PIS level. But for the some specific actions commands, which are sent from CIS to more than one PIS, in this case override is applied at the CIS level.

4.2.3.2. Threshold value section

Concept of threshold:In an interlock system threshold value is the event detection for analog value exceeding the allowed maximum/ minimum value. The Threshold value configuration is only available from the CIS Desk.In view point of threshold value modification risk from CIS, a design philosophy adopts two threshold levels.

1. Adjustable value: Threshold of an interlock function can be adjusted during normal operation according to a predefined list of values. These values defined during design and can be selected up to 16 values.

2. Not adjustable value: It is fixed on the basis of component specification, design condition and must be hard coded in PLC which is not allowed to adjust during normal operation. The value of this parameter is related to the maximum (or minimum) value allowed for this particular condition.

For implement adjustable threshold value, the following design principles should be followed

No interlock threshold management can be done from the plant system or CODAC services of conventional system.

No interlock threshold value can be manually defined by an operator from the CIS operation desk.

Any other change of a threshold value can only be done after strict authorisation and validation procedure, only in maintenance and commissioning period

Selection of adjustable threshold value is only done from CIS desk routed through supervisory module and must be implemented using HIOC threshold blocks, it will be included in the PIS PLC template

Concept of threshold value selection using HIOC protocol:

of 90

Request ID, Command ID, Confirmation ID

Response


HIOC_TH_STDHIOC_TH_SFT

Three Step Validation

Selected Threshold Value

Threshold Values for Selection

1 2 3 16

SCADA_HIOC_TH



CIS SLOW PIS PLC

STANDARD PROGRAM SAFETY PROGRAM

Figure 7: Concept of threshold selection using HIOC protocol

The Threshold selection is a critical operation; hence operation should be validated through HIOC protocol to comply the safety standards mentioned in override section.

Similar to the override implementation, the HIOC protocol for threshold selection contains standard program block HIOC_TH_STD and safety program block HIOC_TH_SFT. The PIS PLC template includes a chart where primary connection between these two ready to use blocks are interconnected.

Conceptual diagram of threshold value selection using HIOC protocol is shown in Figure 7. As per concept of threshold, the adjustable threshold values (up to 16) are hardcoded and assigned to the HIOC_TH_SFT block. The selection of these adjustable values is assigned to a sequential number from 1 to 16 and the sequential number is named as K. The K value selection in HIOC_TH_SFT block is done from the CIS desk through the CIS supervisor module and the threshold value (K value) is verified using three step validation process of HIOC protocol. After verification of K value in HIOC_TH_SFT block,the adjustable threshold value for the respective Kth selection is then send out from HIOC_TH_SFT block as selected threshold value.

HIOC_TH_STD block update the verification message and notification of threshold selection (K) and selected threshold value, in DB (SCADA_HIOC_TH), which will exchange data between CIS desk and PIS PLC through the CIS supervisor module (WinCC OA Server).

of 90

4.2.4. Concept of Reset

After the activation of local interlock functions, reset is required before normal operation can continue. The reset can only be performed when the interlock event has been clearer, meaning that it is not a critical command. The reset command shall be performed from CODAC. With this approach, flexibility during the operation of ITER is maximized without compromising its integrity.To ensure that the integrity of the interlock functions will not be affected by this non-critical interface, the internal logic of the PIS PLC shall ensure that all the conditions required for a safe operation are met and the operator reset is the last step after a recovery from an interlock event.The following rules shall be observed for the RESET operation:1. Resets operation should not be permitted if the causes (risks) are still active.2. This operation should manually performed by the Plant System Expert, using the

CODAC services.3. The interface should be implemented via the PSH.4. The PSCC should not be involved in the reset of investment protection functions.5. The evaluation of the conditions for reset shall be performed without considering the

operator command status.6. The operator shall be aware of the status of the function at every moment.7. The operator shall be informed that the conditions to reset the function are met (ready to

reset status).8. Reset shall be pulse commands, so whatever the communication protocol of commands

between the systems is, it is necessary to react to the command on the positive edge and not on the status.

9. The following signals should be configured in the SDD tool to implement the function reset from CODAC, but not limited to:

1) Status signals for the function reseto Ready to Reseto critical event /action status

2) Command for function reseto Reset command

For implement the Reset operation it is recommended to use the customised function block FB 1011 (F_FN_RST), which is the part of PIS_LIB.

of 90

The typical schema of local interlock function Reset operation, using FB 1011 is shown in Figure 8. The FB 1011 support evaluation of up to 16 safe conditions for Ready to Reset. If all the required conditions for Reset the interlock function are met, then ready to reset status (output of FB 1011) is set. After conversion from safety to standard data type, the Ready to Reset signal is updated in DB 100 (CodacStates) and sent to CODAC through PSH over PON connection. After receiving the Ready to Reset status at Plant system CODAC operation desk, operator can sent the Reset command, into DB 102 (CodacCommands) of PIS PLC, through PSH. In PIS PLC, after standard to safety data conversion, the Reset command is validated and executed in FB 1011 safety program. Event/Action statuses of the interlock function are continuously updated in DB 100 and sent to CODAC (not shown in Figure 8).


CODACDesk

PSH Ready to Reset status

SLOW PIS PLC

COMMANDDB 102

STATUS DB 100


CODAC

OP_CMD

Ready to Reset

FB 1011: F_FN_RST

Reset CMD

Cond 1

Cond 16

Cond 2

Function Reset

Figure 8: Concept of RESET

4.2.5. Concept of Reintegration

In the event of an error on a F-I/O (e.g. a channel fault), the F I/O (or the affected channel) switches to safe mode. In this state of “passivation”, substitute values are automatically replaced instead of the process values.After clearing the error that caused the passivation, the switchover from substitute values to process values shall occur only after a manual user acknowledgment in the safety program. Automatic acknowledgement is not recommended, the switchover is referred as “reintegration”.It is considered that the reintegration action should be performed from CODAC, without compromising its integrity.

of 90

Rules 1, 2, 3, & 5 mentioned in concept of RESET are applicable for Reintegration implementation. Additional rules shall be observed for the channel driver Reintegration operation:1. The evaluation of reintegration request shall be performed at PIS level and it should be

without considering the reintegration command from CODAC services.2. The operator shall be informed when the error has been cleared to reintegrate the channel

driver module. 3. All the acknowledge request generated from the channel driver of all the configured

signal modules (F-AI/ F-DI/F-DO) should be logically combined with an “OR” gate and finally a single reintegration request signal will be generated. A single reintegration pulse command from CODAC shall reintegrate all the channel drivers of all configured signal modules.

4. Reintegration must be pulse command, so whatever the communication protocol of command between the systems is, it is necessary to react to the command on the positive edge and not on the status.

The typical schema of channel driver reintegration function is shown in Figure 9. In the Figure 9, error may occur in single or multiple channels during operation. Once error has been eliminated, the acknowledge request (ACK_REQ) status is set. The request (ACK_REQ) from all channel drivers is logically combine with an OR and the result is updated in DB 100 (CodacStates) and sent to CODAC through the PSH, over PON connection. After receiving the acknowledge request (ACK_REQ) status at Plant system CODAC, operator has to send reintegration command, into DB 102 (CodacCommands) of PIS PLC, through PSH. After standard to safety data conversion, the reintegration command is validated and executed in the safety program, on rising edge of pulse Command. In safety program, the reintegration command shall be connect to (ACK_REI) input in such way that a single reintegration command from CODAC shall reintegrate all the F/IO modules.

of 90

Reintegration Command

Acknowledge Request

CODACDesk

PSH

CODAC


SLOW PIS PLC

COMMANDDB 102

STATUS DB 100


F-CH_DRIVER BLOCK

ACK_REI

ACK_REQ

ACK_REI

ACK_REQ

ACK_REI

ACK_REQ

ACK_REI

ACK_REQ

OR

Block Name * *

CH 1

CH 2

CH 3

CH n *

F-A

I/F

DI/

F D

O

* As per module type F AI/F DI/F DO channel number varies to 6 / 24 / 10

** Block name as per module name in hardware configuration

F-CH_DRIVER BLOCK

F-CH_DRIVER BLOCK

F-CH_DRIVER BLOCK

Figure 9: Concept of Reintegration

4.2.6. Concept of Critical health monitoring

Diagnostics of the components included in PIS PLC system that needs close and continues monitoring are termed as Critical health monitoring. Table 5 lists the signals are considered for critical heath monitoring of PIS PLC system:The critical health monitoring signals are monitor and archived in the CIS supervisor module. The main aspects of Critical Health Monitoring in the PIS PLC are as follows:

Program should be written in standard program in OB 34 , which execute and update the status every 200 msec.

Health monitoring shall be done without any initialization or intervention from CIS.For implement the critical health monitoring it is recommended to use customised function block FB 1036 (C_DIAG_CPU) and DB 1001 (SCADA_CHMD), which are the part of PIS_LIB.The typical schema of Critical Health Monitoring using FB 1036 is shown in Figure 10.In the standard program FB 1036 is executed cyclically every 200 msec and update the status of the defined critical signals in DB 1001 (SCADA_CHMD).

of 90

Table 5: Critical Health Monitoring Signal

Sr. No. Description

1 CPU INTF (internal error)2 CPU EXTF (external error)3 CPU RUN4 CPU STOP5 CPU REDF (redundancy error)6 CPU MSTR (master)7 CPU DC24V8 CPU IF (interface failure)9 CPU UF (user failure)10 CPU MF (monitoring failure)11 CPU CF (communication

failure)12 CPU MAINT

From the DB 1001, status of critical health monitoring signals are receives in the CIS supervisor module (WinCC OA Server) through S7 communication and shown on CIS operator desk (WinCC OA Client).

Figure 10: Concept of Critical health monitoring

of 90

4.2.7. Concept of archiving and status Monitoring

On the basis of critical and non-critical data defined in section 2.2 of this document, plant interlock system shall adopt two types of protocol for data archiving and status monitoring :

1. S7 protocol - for non-critical data2. TSPP protocol - for critical data

4.2.7.1. S7 protocol

S7 protocol is a Siemens proprietary protocol. It is used for PLC programming, exchanging data between PLCs and accessing PLC data from SCADA. It can be used for bidirectional communication. The following considerations shall be observed for archiving and monitoring through S-7 protocol:

1. Non critical data shall be archived and monitor through S7 protocol. 2. In S-7 protocol, WinCC-OA is the master, its pull data from the PIS PLC. Hence

no special configuration needed in PIS PLC. Only the DB’s shall be created for exchanging the data.

3. It is recommended to create the following exchange data blocks (DB’s) at PIS PLC side for non-critical data archiving and monitoring:

SCADA_STATE_100ms (DB 1004): for Boolean signals archiving at 100ms

SCADA_STATE_1s (DB 1005): for Analog signals archiving at 1s4. If PIS needs different archiving intervals, like 500ms or 300ms etc., then a new

data block (DB) with name SCADA_STATE_500ms or SCADA_STATE 300ms etc . shall be created.

Data continuously updated in exchange DB (DB 1004 and DB 1005) and as per archiving interval supervisor module (WinCC OA server) pulls the data, archives and update to CIS desk (WinCC-OA Client).Detail implementation is explained in PIS PLC template document [RD23].

4.2.7.2. TSPP protocol (Time Stamp Push Protocol)

TSPP (Time Stamp Push Protocol) is a protocol which send the data with time stamped at the source (PLC) in such a way that the CIS supervisor module will receive the time of change of the data with the precision of the PIS PLC cycle time. For this protocol, the PIS PLC will be pushing data to the CIS supervisor module (WinCC OA Server) which will decode the TSPP packets and archive the values and the timestamps.The main aspects of TSPP implementation in slow PIS PLC are:

Only critical data shall be sent to supervisor module through TSPP for arching and monitoring. Non-critical data should not be sent through the TSPP because it increases the load on the TSPP and affects the critical data archiving.

of 90

It is also recommended not to use TSPP for archive the analog values.

Data sent over TSPP protocol is having first priority for archiving in CIS supervisor module, and then supervision on CIS desk

TSPP is also optimized, as the communication between CIS supervisor module and PIS PLC only occurs if there is change of state.

Additionally, TSPP data can be archived locally in the PLC during a short loss of communication (less than 30s) between PIS PLC and CIS Supervisor module (WinCCOA server) that prevent the loss of archiving. This short loss of communication may occurs due to switchover (for example Communication Processor or network failure) or the WinCC OA Server switchover (Between MSR and BSR)

Siemens S7 400 FH PLCs supports TSPP protocol by default; however additional PIS PLC blocks are developed to cater the slow PIS PLC design.

It supports a maximum Buffer Length = 32 KbytesIt is recommended to use DB 1002 (SCADA_STATE_TSPP) for Critical data exchange through TSPP. Detail implementation is explained in PIS PLC template document [RD23].

TSPP Protocol

S7 Protocol



CIS

Data through S7 Protocol

Data through TSPP Protocol

SCADA_STATE_100ms (DB 1004)

SCADA_STATE_1s (DB 1005)

SCADA_STATE_TSPP (DB 1002)

SLOW PIS PLC

STANDARD PROGRAM

Figure 11: Concept of archiving and status monitoring

of 90

4.2.8. Concept of conventional health monitoring and CODAC interface

4.2.8.1. CODAC Interface

The CODAC (Control, Data Access and Communication) system is the central control system for the conventional plant control systems of ITER. CODAC is responsible for integrating all plant systems I&C and enabling operation of ITER as a single integrated facility, providing overall plant system coordination, supervision, alarm handling, data archiving and plant visualization (HMI).In interlock system each slow PIS shall be connected to its respective PSH through PON for interface with CODAC. The link between the PIS and PSH must be bidirectional in order to transmit non critical commands (reset and reintegration) from CODAC to the PIS via the PSH and to make non critical data available to the control room. The connection of the slow PIS to PON is also required to receive time synchronization through the Network Time Protocol (NTP) from PON.

Implementation of the slow PIS interface with CODAC is on the basis of SPSS library [RD18]. Step by step implementation of PIS PLC and CODAC interface in view point of interlock system is described in PIS PLC template document [RD23].The main aspects of interface between PIS PLC and CODAC are as follows:

Communication between CODAC and PIS shall be direct link between PIS to PON network using EPICS interface. Normally PSH is the EPICS interface provided by CODAC to each plant system.

The interface shall be a standard program in PIS PLC, if data is required in safety program then conversion to safety data from standard data shall be through Siemens safety library blocks.

The following types of signals shall be considered as interface data between PIS and CODAC and they shall be configured in the SDD tool, but not limited to:1) States variables (Status)

o Ready to Reseto Acknowledge request o Conventional Health monitoringo All critical event and action status o All Analog process values

2) Command variables o Reset Command o Reintegration Command

All the data exchanged through standard PLC program over PON, use the TCP connection where port 2001 used for command and port 2000 is for states variables.

of 90

PIS PLC receives commands (DB 102) and sends status (DB 100) data to CODAC through PSH.

4.2.8.2. Conventional Health monitoring

Conventional health monitoring is considered non critical because they are supervised by the CODAC. See the definition of Non critical data in section 2.2. As explained in the concept of CODAC interface, conventional health monitoring of PIS PLC shall be passed to CODAC for supervision and monitoring purpose. For implementation of conventional health monitoring in PIS PLC, it is recommended to use PIS PLC template chart “PISxx_CODAC” and SPSS package provided in PIS PLC template. PIS developer do not need to write extra program, as SPSS library code will identify the conventional health monitoring signals and generate standard program through SCL and STL code.

Command

Status

TCP CONNECTION

TCP Connection-port 2001

TCP Connection-port 2000

CODACDesk

PSH

CODAC

COMMANDDB 102

STATUS DB 100

1. Reset command2. Reintegration command

1. Ready to Reset2. Acknowledge Req.3. Conventional Health monitoring4. All critical event and action status5. Analog process values

SLOW PIS PLC

STANDARD PROGRAM

Figure 12: Conventional Health monitoring and CODAC

of 90

5. Configuration of Fast PIS

To standardise the configuration of a fast PIS hardware and software architecture for all suppliers and help the PIS developers, the PBS 46 (CIS) team has developed a set of standard PIS templates that can be used when setting up a Fast PIS.Due to the strong correlation in the fast architecture between the hardware configuration and the software one, it is suggested to use the templates only when the fast plant interlock system architecture exactly matches with the functionalities implemented in one of the templates provided by IO. In any other cases, these guidelines can be used for getting a general understanding of the subject, with the recommendation to contact the Interlock RO for support on the design of the fast plant interlock system. Main features of the Fast PIS templates are:

Modular software architecture

Preconfigured Host PC software module to perform the monitoring

Preconfigured FPGA projects, to implement the protection functions

5.1 Hardware configuration

Two scenarios can be considered for hardware configuration, these are:

5.1.1. Hardware Configuration using Fast PIS Template

When the hardware configuration of a project under development exactly matches with the hardware configuration adopted in a PIS template, the developer can configure the cRIOs using one of the following templates provided by IO.

- 3 AI and 2 DO 24 V, implementing protection functions based on a 2oo3 voting logic

- 3 DI 24 V and 2 DO 24 V, implementing protection functions based on a 2oo3 voting logic

- 3 DI TTL and 2 DO TTL, implementing protection functions based on a 2oo3 logic

- 3 AI and Event to CIS (Manchester Code) implementing protection functions based on a 2oo3 voting logic and transmitting the event to the CIS

- 3 DI 24 V and Manchester Coded TTL output signal, implementing protection functions based on a 2oo3 voting logic and transmitting the event to the CIS

- 3 DI TTL and Manchester Coded TTL output signal, implementing protection functions based on a 2oo3 voting logic and transmitting the event to the CIS

- Manchester Coded TTL input signal and 2 DO 24 V, receiving an action from the CIS

- Manchester Coded TTL input signal and 2 DO TTL, receiving an action from the CIS

of 90

The Configuration of the Fast PIS requires 2 steps: - Configuration of the cRIO FPGAs - Configuration of the Host PC

In order to configure the cRIO FPGAs, the Developer shall download the desired template from SVN: https://svnpub.iter.org/codac/iter/codac/dev/units/m-cis-pisfc/tags/TO4 and apply some customization,In the LabVIEW’s project window of the selected template, the resources linked to the terminals of the modules, that act as input and output of the system, shall be renamed with aliases specific for the plant system, conforming to the naming convention..

Figure 13: Application of the naming convention

In case of a template with multiple protection functions deployable, the exact number of function to be performed in the specific plant system has to be chosen among the available ones, by selecting it from the drop down menu of the polymorphic sub-VI in the block diagram of the top-level VI.

of 90

Figure 14: Protection function’s number choice

Before compiling the LabVIEW project, the deployment has to be properly versioned by imposing the right initial values to the array of U8 called “FPGAVIversion”; the documentation involving the Fast PIS shall keep track of the history of the program.

Figure 15: Versioning of the bitfile

It shall be remark that the bitfile generated by the NI compiling tools is not the one that shall be used to configure the Host PC; it shall be fed to the National Instruments’ C API generator, which generates a header file and .lvbitx file that shall be used when configuring the Host PC.

of 90

Figure 16: C API generator

For configuring the Host PC, it is necessary to couple the interface module source files with the cRIOs composing the Fast-PIS architecture being used. This is done by entering the serial numbers of the chassis, as they’re returned by the lsrio.py function, in the “DeviceSerialNumber” field for the parameters of the calls to the function irio_initDriver , before compiling the C project. [RD26] The parameter “projectName” of the same function has to be filled in with the name of the bitfile produced by the C API generator, without the initial “NiFpga_”.

5.1.2. Hardware Configuration for New project

If the Fast PIS project under development doesn’t have the same functionalities of one of the templates provided, then a new project needs to be configured in collaboration with the IO CIS responsible officer; this has to be done taking into account that the selection of the input/output modules to be used in the CRIO Chassis is strongly dependant on the logic to be implemented. In Table 6 are listed the approved C-Series modules that can be installed in the cRIOs of a fast PIS and their possible usage.

Table 6: Approved cRIO modules

MODULE DESCRIPTIONNI 9205 32 Ch DI modules ±200 mV, ±1, ±5, and ±10 VNI 9264 16 Ch DO used as DI diagnostic module

8 Ch DI module TTL8 Ch DO module TTL NI 94018 Ch DO used as DI diagnostic module

of 90

8 Ch DI used ad DO diagnostic module SPI interchassis communicationManchester transmitter (event)Manchester receiver(action)

NI 9477 32 Ch Digital sinking output module 5,12, 24, 48, 60 VNI 9426 32 Ch Sourcing DI module 30 VNI 9425 32 Ch Sinking DI module 12 V,24 VNI 9476 32 Ch Sourcing DO module 12 V,24 V

5.2 Software architecture and Programming concepts

The Fast PIS software architecture can be divided in two major blocks

The Host PC, in charge of implementing the interface between the cRIO FPGA and the Central Systems for monitoring and controlling purposes via HMI.

The cRIO FPGA core application, in charge of performing the interlock functions and communicating the Actions and Events to the central interlock system’s fast modules. ,

Data is exchanged between the cRIO FPGAs and the Host PC software layer through a FIFO queue over a DMA channel in the FPGA and through an exchange data buffer shared with the Host PC.

of 90

Host PC

iRIO-OPC UA Interface

OPC UA SERVER

cRIO FPGA (Chassis 1)

IRIO

CORE APPLICATION

Central Interlock System SUPERVISOR MODULE

CODAC

Mxi

Sensors

Actuators

MC from CIS

MC to CIS

cRIO FPGA (Chassis 2)

CORE APPLICATIONMxi

Interchassis Communication

Figure 17 : Fast PIS software architecture

The main functional blocks of the Host PC’s Software architecture are the followings

OPC UA Server iRIO-OPC UA interface

The OPC UA Server

Implements an OPC UA server, based on the open source project called “Open 62541”

Allows multiples LAN connections from clients provided with a valid certificate and implements the communication with different levels of security.

Receives data from the iRIO-OPC UA interface and stores them in the OPC UA address space. The iRIO-OPC UA interface

- The cRIO FPGA generates periodically a “status word” that includes all the information which is meant to be monitored in each chassis; this status word is sent via DMA to the Host PC: the iRIO-OPC UA interface reads the status word from the data buffer (using the iRIO library) of the Host PC and permits the update of the related OPC UA nodes.

of 90

In case that the Host PC is interfaced with the cRIO FPGA, in which one of the templates provided is deployed, the Host PC software implementation will be provided by IO and will require only a configuration by the PIS developer, as explained in [RD26]. In any other case, the Host PC shall be configured with the supervision of the IO’s CIS responsible officer. Note that the fast PIS architecture is composed of two cRIOs in a parallel configuration called “Double Decker”, hence the LabVIEW project to be deployed to each FPGA is the same.

The main functional blocks of the cRIO FPGA core are the following:

Inputs

Outputs

Manchester transmitter/receiver

Voter

Decision logic

SPI Interchassis Communication

The following Figure 18 depicts a block scheme representation of one of the possible implementation of a template.

Data/Diag ratio

Diagnostic Input

GenerationInput Reading

Input Diagnostic

Check Voter Voter

Diagnostic

Output Writing

Output Diagnostic

Chassis Diagnostic

SPI communicatio

n Slave

SPI Communicatio

n Master

Global Status

Manchester Receiver

Manchester Transmitter

From CIS

To CIS

To Next Iteration

From previous Iteration

EVENT

ACTION

To other Chassis From other chassis

Loop Iteration time

INPUT VOTER

OUTPUT

MC EC/DC

SPI

DECISION

Figure 18: FPGA Core application

of 90

InputsThe blocks dealing with inputs are those in charge of reading the data from the sensors. In addition, for diagnostics purposes, one of these blocks generates data for the input modules so that it can be checked if the acquired data equals the generated one.A diagnostics module outputs some random test values to the input modules, delivering them to channels different from those used by the sensors. These values are then read back and compared. In addition the voter will also act as a diagnostic test for the actual input channels. If any sensor channel result is different from the others, the voter will detect the discrepancy. If both tests pass, then it will be assumed that the sensors and the input modules do not have any faults and can then be trusted.

VoterThe voter blocks perform the 2oo3 logic voter and the voter’s diagnostics. The diagnostics of the voter uses the data generated for the input diagnostics modules and compares the voting result with the expected output for this test data.When random test inputs are sent through the input modules, the input values will then be sent to the voter. The voter results are compared to see if they coincide with the random diagnostic test inputs. All diagnostic scans use the same voter as the actual safety function. If this test passes then it will be assumed that the voter is functioning free of faults and thus, it can be trusted.OutputsThe blocks dealing with outputs are in charge of generating the outputs for the actuators. In addition, for diagnostics purposes, these blocks generate additional outputs data in the diagnostics output channelsso that it can be checked if the generated data equals the expected data. If this test passes, it’s that the output modules are functioning free of faults and, thus, they can be trusted.

SPI Interchassis communication Communication messages are sent from one chassis to the other for very iteration of the main loop. Two SPI communications are established between the chassis, each of them performing the data transfer in one way.

Decision LogicThe decision logic blocks generate the output values for the next iteration.The Output values are elaborated as the results of the voting applied to the input and taking into account all information from sensors, diagnostics blocks and remote chassis (through SPI communication) to generate these values.

MC Transmitter This block generates the digital bit pattern in a digital output TTL channel. This communication will be done over a serial protocol (Manchester Code based) at a 10 Mbps bit rate. In this case, the data will be sent to the Central Interlock System (CIS).

MC Receiver This block receives the digital bit pattern in a digital input TTL channel and converts it to a 64-bit word. This communication will be done over a serial protocol (Manchester Code based). In

of 90

this case, there are two MC Receivers in each chassis; one of them receives data from the Central Interlock System (CIS) and the other one receives data from the other chassis. The data received from the other chassis has to be checked in order to assure the coherence between the data received by both chassis from CIS.

5.2.1. Concept of archiving and status Monitoring

During every cycle of the main loop in the FPGA, the decision logic blocks generate the values that are going to be sent as output in the next iteration. These blocks take into account the information from sensors, diagnostics blocks and remote chassis (through the SPI communication) to generate these values. The information generated for all previous blocks in every iteration are packed into a “status word”, which is used for monitoring the status of each Chassis. A status word contains the information in Table 7 and its structure is portrayed in Figure 19.Note: the status word as described is valid only for the FPGA templates mentioned in Chapter 5, for any different template is it possible that the monitoring status word has a different configuration and needs to be configured with the collaboration with the IO PBS 46 RO. The Status word is exchanged via DMA with the Host PC and published on the OPC UA Server; this permits the subscription to the variables by any certified OPC UA client as the interlock and CODAC SCADA.

Table 7: Status word data

Legend Description

Consecutive Number Consecutive number of the word

PU Powering status CH Communication with Host PC statusCC Communication with remote chassis statusRP Power status of remote chassisI1 Diagnostic status of Input module 1

I2 Diagnostic status of Input module 2

I3 Diagnostic status of Input module 3

O1 Diagnostic status of Output module 1

O2 Diagnostic status of Output module 2TE Temperature alarm status

VOn Voter Output status of n-th protection functionVAn Voter Output alarm of n-th protection functionVDn Voter Diagnostic status of n-th protection functionCRC Cyclic redundancy check

of 90

STATUS WORD0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Consecutive Number PU CH CC RP I1 I2 I3 O1 O2 TE VO116 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

VA1

VD1

VO2

VA2

VD2

VO3

VA3

VD3

VO4

VA4 VD4 VO5 VA5 VD5 VO6 VA6

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47VD6

VO7

VA7

VD7

VO8

VA8

VD8

VO9

VA9

VD9

VO10

VA10

VD10

VO11

VA11

VD11

48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63CRC

Figure 19: Status word structure

of 90

6. Management of PIS software

This section deals with recommendation for the Version Control for

- Slow/Fast PIS software management Repository Management for

- Software on SVN during various stages of integration PIS software Runtime application Development process

6.1 Version Control

Software version control is a cornerstone of the software development and QA process. In order to assure a correct version control management of the software and configuration files used in the development of the PIS, the following files shall be updated on ITER SVN repository:

Software developed or used by PIS (Fast and Slow). Plant system-specific software configuration files. PIS-CODAC interface configuration file.

The Repository is located on https://svnpub.iter.org/codac/iter/codac/icdev/unitsThe files contained into the repository, can be accessed using Tortoise SVN software, allowing to commit and checkout the files from SVN.In addition to the file version information, some additional information such as time of commitment, name of the author(s), the author’s annotation and so on is available on SVN. Every change of the software or the configuration files have to be managed in SVN. The SVN general guidelines are provided in [RD14] ITER CODAC Subversion Guideline (ITER_D_A2GSXB).Note: PIS I&C projects folder is the same for conventional and interlock project, the Interlock files will be stored inside specified folder related to interlock architecture. Following sections summarizes the methodology for organizing a repository for PIS related development.

https://svnpub.iter.org/codac/iter/codac/icdev/units

of 90

6.2 Repository Management

Some guidelines for PIS Repository Management are as follows:

Slow PIS STEP-7 projects will be stored in SVN unzipped. This avoids files manipulations before/after every SVN operation.

The last project stored in SVN and the project running on the PIS (Slow/Fast) must be the same (During FAT it is compulsory while during offsite development it is optional)

Every change into the software must be tracked and committed into SVN.

6.3 Development Process

Development process is the process of developing source code and generating the configuration file in order to make the program runnable and compatible with all the related software involved.

Figure 20: Development Process Work Flow for slow PIS Applications

Above Figure 20 shows the workflow for development process of slow PIS applications. There are four horizontals layers as follows:

SDD tool: Used to generate the configuration files for CODAC Interface with PIS.

STEP-7: Used to develop the Core Application of the slow PIS. WinCC OA: Used to implement the archiving and the monitoring of the PIS

- From Mini-CIS Desk during FAT- From CIS desk during SAT.

CODAC CORE SYSTEM: Used to implement the core application that permits the monitoring and archiving from the CODAC System.

of 90

Several development tools are involved in the development of specifically Fast PIS runtime Application. These are as follows:

CSS

I&C CREATION COMPONENT CREATION-SIGNAL

CONTROLLER CREATION

CONFIGURATION AND STATES CREATION

EPICS CONFIGURATION

LabVIEW PROJECT

CREATION

WIN CC OA PROJECT

CREATION

CREATION OF BITFILE

DRIVER SETTINGS DATAPOINT CONFIGURATION

GRAPHIC SCREEN DEVELOPMENT

APPLICATION CREATION COMPILE GENERATE BOY SCREEN

HOST PC CHASSIS-WinCC OA INTERFACE

CONFIGURATION

SDD

LabVIEW

ECLIPSE

WINCC-OA

CODAC CORE SYSTEM

RUNTIME APPLICATION

Figure 21: Development Process Work Flow for Fast PIS Applications

Figure 21 shows the workflow for development process of Fast PIS applications. Several development tools are involved in the development of specifically Fast PIS runtime Application. These are as follows:

SDD tool : Used to generate the configuration files for CODAC Interface with PIS. LabVIEW : Used to develop the Core Application of the Fast PIS chassis Eclipse : Used to configure the interface between the Chassis and the WinCC OA for

data exchange. WinCC OA : Used to implement the archiving and the monitoring of the PIS

- From Mini-CIS Desk during FAT- From CIS desk during SAT

CODAC CORE SYSTEM: Used to implement the fast controller PC Host core application that permits the monitoring and archiving from the CODAC System.

6.3.1. Scope areas for PIS Software development

Following areas are in scope of PBS 46 CIS Teamo WinCC OA project creation, configuration and Interfacing with PIS.

Following areas are in scope of PS I&C ROo The development procedures related to SDD, STEP 7 and CODAC Core System,

Refer [RD23].

of 90

o LabView core application and Eclipse project creation

6.3.2. Off-Site Development and Stand-Alone Test (Independently from IO)

of 90

Figure 22: Off-Site Development

The following inputs are required before starting the first step of development process for slow/fast PIS:

PIS-CIS interface sheet PIS functions specification.

The PIS developer receives the specification from the PS I&C RO to start the development of functionality accordingly.When the Code is ready, it is compiled and downloaded into the PIS slow/fast controller; a temporary version is generated and saved into SVN repository. All the Local functions are tested with the hardware and software already implemented, the central functions are tested using the MINI-CIS that will provide the tools to simulate the behaviour of the central interlock architecture. For more detail about MIN-CIS refer 7.1.5.6If the entire tests are passed, the PIS developer will generate a local release of the PIS project and confirm the validity of the Version Tag saved in SVN.

of 90

7. Integration

Each plant system is incorporated into ITER in one main step; however the installation schedule of the plant systems covers a long duration. This requires the implementation of specific means to minimize errors and the time taken during the integration and commissioning of the plat system I&C. The document [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W) describes the testing approach and methods and the organisational scheme for planning and performing the FAT and SAT for any ITER I&C system. In additional to this in order to achieve a good integration between the different plant interlock systems and the CIS, some specific guidelines are given in below section.

7.1 Recommendation for FAT of PIS

7.1.1. Plant System FAT Context

As explained in section 3.4.4 of [RD1] Plant Control Design Handbook (ITER_D_27LH2V), Plant System factory acceptance tests (FAT) are intended to check the conformity of the procured plant system to the approved design. Plant System I&C FAT is a part of the plant system FAT. All I&C components in the procurement shall be powered and tested during FAT. The FAT scenario for I&C will be adjusted depending on the configuration of I&C procurement with the policy to test as much as possible, as soon as possible. The guidelines for plant system integration [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W) provide further details on FAT scenarios applicable to plant system I&C. All the guidelines mention in [RD1] and [RD10] for the FAT of plant I& C system are applicable for the PIS. In addition to this following additional recommendation are given for PIS FAT.

7.1.2. PIS FAT Objective

The objective of the PIS FAT is to check the readiness of the PIS for installation which means:

- The PIS satisfies requirements set in [AS1] IEC 61511 have been satisfied.

- The PIS satisfies the requirements and recommendations applicable to interlock system set in [RD1] Plant Control Design Handbook (ITER_D_27LH2V) and its satellite documents.

- The PIS satisfies the requirements defined in the plant interlock requirement specifications.

- The PIS satisfies the requirements defined in the interface sheets.

- The PIS satisfies the manufacturers’ recommendations.

- The PIS documentation is up to date.

- The PIS satisfies all the interfaces with mini-CODAC and mini-CIS, wherever applicable.

of 90

7.1.3. Recommendations about the methodology

Refer to the section 3.4.4 of [RD1] for general recommendation for I&C FAT methodology. In addition to it some additional recommendation about PIS FAT methodology are as follows:

- The mini-CODAC and mini-CIS are used for FAT and must be preconfigured before FAT campaign.

- PIS Supplier must provide necessary software tools and configuration files.

7.1.3.1. Pre-requisites

The PIS is considers ready for the FAT if the following criteria are met:

- The test plan is defined and agreed by all parties.

- The deliverable documents are stored in IDM.

- The hardware deliverables are available.

- The software deliverables are stored in the correct IO repository.

- The test environment and tools are ready.

- The supplier is ready to proceed.It is highly recommended to perform a pre-FAT, by PIS developer in order to detect and solve issues internally before starting the FAT. Indeed, performing a pre-FAT allows to save time considering that contrary to issues detected and solved during FAT, issues detected and solved during pre-FAT do not require formal issue management.

7.1.3.2. Test plan

The test plan shall include:

- A management plan (physical location, test personnel, etc.).

- The identification of the items to test (documents reference and version, hardware components, software version).

- The description of the test environment and tools. Detailed test procedures (test description, expected results) for each test.

7.1.3.3. Test report

Supplier shall submit PIS test report after completion of FAT. The results of the acceptance tests must be documented in the test report. The test report generally consists in a copy of the test plan with actual test results/comments.Following points shall be taken care during the filling of the Test Report:

of 90

- If a test cannot be carried out, the reasons for the non-execution shall be explained in the comments reserved box in test report.

- If a test is successful, the test results box shall clearly indicate it and comments can be added in the comments reserved box in test report.

- If there is a failure during test, an issue sheet shall be opened (refer to section 7.1.3.4 ) and the test results shall be filled with the issue in test report.

- If the test environment and tools or the items to test are modified during the acceptance tests phase, the test report shall identify the versions for each test.

7.1.3.4. Issue management

As explained in section 6.1 “Issue management” of [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W), during the execution of tests, any deviation from the expected result shall be captured in a uniquely identified Problem Sheet. It shall record all the information related to the root cause investigation of the problem and all the remedial actions. Problem sheets shall be electronically typed in and at least archived into the IO problem tracking tools. The Problem Sheet shall record all the information related to the root cause investigation of the problem and all the remedial actions all along its lifecycle. Each non-conformance to the FAT should be recorded in the uniquely identified problem table.The Problem Sheet should be used generally for the following, but not limited to it :

- To describe the issue (system version, test procedure, test results, etc.)

- To analyse the issue (severity level, root cause, etc.)

- To propose remedial actions (specification modification, software modification, hardware modification, documentation update, etc.)

- To analyse the extent of impact (on software, hardware, documentation, etc.)

- To propose re-test procedures to validate that the issue is solved and that the modification has not adversely impacted other parts of the system

- To plan the modification and the validation (who, when, how, etc.)

- To implement the modification as planned.

- To validate the modification as planned.

of 90

7.1.4. Recommendations about the FAT scope

7.1.4.1. Plant System FAT

The Plant System FAT should include the verification of all the requirements, functions (local, central etc.) and specifications involved in plant system I&C design.

7.1.4.2. Plant System I&C FAT

As explained in section 3.2 “Scope of FAT for I&C systems” of [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W), the FAT for I&C is split into four campaigns. A campaign is a set of scenarios targeting the same function or a specific category of tests (i.e. stress tests, performance tests).

C1. I&C documentationC2. I&C hardwareC3. I&C configuration data and softwareC4. I&C functional requirements

7.1.4.3. PIS FAT

In context of the PIS, the purpose of each campaign is extended as described in the following sections:1. C1 campaign: I&C documentation

The campaign aims at checking that:- All the PIS documentation required at this stage is available.- The PIS design satisfies the requirements set in [RD1] Plant Control Design

Handbook (ITER_D_27LH2V) and its satellite documents when applicable.- The PIS design satisfies the requirements set in the applicable PIS requirement

specifications.- The PIS design satisfies the requirements set in the applicable interface sheets.- The PIS design satisfies the manufacturer’s recommendations.- The PIS documentation is consistent.- The PIS documentation satisfies the PCDH and IEC 61508 requirements

applicable to the documents delivered in the scope of a procurement.2. C2 campaign: I&C hardware

The campaign aims at checking that:- The hardware deliverables satisfy manufacturer’s recommendations.- The hardware deliverables are in conformance with the PIS documentation.- Requirements (PCDH, IEC 61508, etc.) applicable to the hardware deliverables

are met.3. C3 campaign: I&C configuration data and software

The campaign aims at checking that:- The software deliverables satisfy manufacturers’ recommendations.- The software deliverables are in conformance with the PIS documentation.

of 90

- Requirements (PCDH, IEC 61511, etc.) applicable to the software deliverables are met.

4. C4 campaign: I&C functional requirementsThe campaign aims at checking that the PIS (hardware + software) functional requirements are met (the PIS operates as required/defined).The policy is to test as much as possible as soon as possible, so the tests scenario shall be adjusted depending on the available interfacing components.The leading guideline of FAT tests scenario is to test I&C performance and functionality as much as reasonable achievable.The tests to be performed may include:

Functionality tests:

- Local interlock function test which include the interlock event and the interlock action(s) occur in the same plant system. These may include voter logic, force logic etc. For local functions information refers 4.2.1 .

- Central interlock function test which include machine’s protection function involving two or more plant systems. These may include sending event(s) and Receive action (s) from CIS, overrides etc. For central functions information refers 4.2.2.

- system diagnostics functions

- TSPP archiving functions

- Supervision function

Performance tests (response time, reliability, etc.)

Environmental tests (ambient air, EMC, life- and stress- testing, radiation, vibration, etc.)

Interface testing (Plant System Equipment interface, CIS Interface, CODAC interface etc.)

Testing in degraded and/or fault mode, exception testing

Maintenance and operating manuals/procedures tests

7.1.5. Recommendations for performing the campaigns

7.1.5.1. C1 campaign: I&C documentation

As explained in [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W) section 3.3 Performing FAT for I&C system, the campaign C1 does not require any attendance of the PS I&C RO at the FAT site since it may be performed remotely at IO using the deliverable documents. All document deliverables, as mentioned in [RD1] and [RD27] are expected to be reviewed.

of 90

7.1.5.2. C2 campaign: I&C hardware

All hardware deliverables are expected to be checked. This campaign aims at verifying that all the hardware components are compliant with PIS bill of material (BOM). This campaign ends up with the equipment powering and electrical tests. PCDH rules for I&C deliverables management (section 3.4.1) are applicable to the hardware deliverables. It is also recommended to check the following:

- The hardware deliverables satisfy manufacturer’s recommendations

- The hardware deliverables are in conformance with the PIS documentation

- PIS Hardware is in conformance with PIS Manufacturing Description documentation and Interface Sheets.

- PIS I&C Spare parts with appropriate specifications of storage space and conditions are available

- Tools required for maintenance of any PIS I&C component with appropriate specifications of storage space and conditions are available

- Rules/requirements/recommendations applicable to hardware deliverables that were not checkable during C1 campaign (non-documented information) are satisfied.

- The hardware deliverables do not present any damage.

- The hardware deliverables have always been stored in appropriate conditions.

- The hardware deliverables have been checked (powered) and/or calibrated if required

7.1.5.3. C3 campaign: I&C configuration data and software

All software deliverables are expected to be checked. PCDH rules for I&C deliverables management (section 3.4.1) are applicable to the software deliverables.It is recommended to perform a PIS program code review in order to check that:

- The PIS program satisfies manufacturer’s recommendations.- The PIS program is in conformance with the PIS documentation (PIS Manufacturing

Description and Interface Sheets).- Rules/Requirements/Recommendations applicable to software deliverables that were not

checkable during C1 campaign (non-documented information) are satisfied.- Integration of all PIS programs with Mini-CIS program is mandatory.- Integration of PIS with mini CIS is required to check central functions that are in purview

of PIS during FAT.

- For the PIS involved in the implementation of central interlock functions, it is recommended that PBS 46 performs the integration procedure of the PIS program into the CIS multi-project and check it by compilation

of 90

7.1.5.4. C4 campaign: I&C functional requirements

This campaign aims at checking that the PIS hardware and software operates as required/defined.It is recommended to:

Check the procedures for installation and commissioning.

Check that the hardware operates as required/defined.

Check that the software operates as required/defined.

Check the procedures for operation and maintenance of any I&C component.Note 1: Environmental (ambient air, EMC, life- and stress- testing, radiation, vibration, etc.) tests generally cannot be performed at supplier’s premises. So when considered, they are normally planned before the beginning of the FAT in specific laboratories. When available, the results of these tests are analyzed. The environmental test report shall allow validating the correct operation of the PIS in the environmental conditions expected at future PIS location in ITER site.

Note 2: Performance (response time, reliability, etc.) tests generally cannot be performed by experiences. So the reliability evaluations (based on analysis/calculations) are the sole performance results available. The reliability evaluation report shall allow validating the appropriate performances of the PIS. Considering the limits of the analysis techniques, margins between evaluation and requirements shall be high enough to get confidence in the conformance of the system with reliability requirements.

Note 3: In order to check that the software operates as required/defined, it may be considered to run the software on the hardware deliverables .It may be considered that part of the software testing activities are planned before the beginning of the FAT or during the code review recommended during C3 campaign. In this case, it is highly recommended to back-up each software version, to track modifications between all the versions and to record the test results with the identification of the tested version. The tests shall allow validating that the PIS operate as expected (in normal, degraded and fault modes) which means:

- As required according to the requirements specifications- As described in the PIS documentation

Note 4: Interface tests are highly recommended in order to discover interfacing issues as soon as possible. The leading guideline of FAT tests scenario is to test I&C performance and functionality as much as reasonable achievable. Whenever it is possible, it is considered to test interfaces with interfacing components or with identic copy of interfacing components. Whenever it is not possible, the tests shall allow validating the interface as much as possible with components as similar as possible to interfacing components.

of 90

7.1.5.5. Items to Test:

The item to test is normally the PIS cubicle(s) with all I&C internal equipment and wiring. For part of the campaign, it may be the PIS PLC running with the application software.

of 90

7.1.5.6. Test Environment:

PIS REMOTE IO

PIS SLOW CONTROLLERS

Mini CIS slowController

Mini-CIS Supervision Module

[WinCC OA]

Mini CODAC

OPERATOR STATION

PLANT INTERLOCK SYSTEM

Mini-CIS

AI 9

193

9401

MC

+ DM

S tr

igge

r94

01

9401

9401

9401

9401

Dia

g

9401

9401

94

01

9401

94

01

inte

rcha

ssis

PIS Engineering Workstation

AI 9

193

9401

MC

+ DM

S tr

igge

r94

01

9401

9401

9401

9401

Dia

g

9401

9401

94

01

9401

94

01

inte

rcha

ssis

AI 9

193

9401

MC

+ DM

S tr

igge

r94

01

9401

9401

9401

9401

Dia

g

9401

9401

94

01

9401

94

01

inte

rcha

ssis

Mini CIS fastController

MC

PIS FAST CONTROLLERS

CIN P

PON

AI 9

193

9401

MC

+ DM

S tr

igge

r94

01

9401

9401

9401

9401

Dia

g

9401

9401

94

01

9401

94

01

inte

rcha

ssis

AI 9

193

9401

MC

+ DM

S tr

igge

r94

01

9401

9401

9401

9401

Dia

g

9401

9401

94

01

9401

94

01

inte

rcha

ssis

Figure 23: Example of typical PIS FAT Test Environment

The FAT for PIS is managed in their real tests whose environment can be depicted from the conceptual perspectives. For performing FAT of PIS (slow and fast), mini-CIS shall be used for generating the CIS events and actions simultaneously.The FAT Test Environment shall include:

PIS system

PIS engineering station Which include Commercial Software packages: - Administration and Programming software for a Slow Controller: Siemens Step7,

F-Systems, CFC, F-Libraries, SCL etc.- Administration and Programming software for a Fast Controller: LabVIEW, IRIO

library

of 90

Mini-CIS as a CIS substitutional tool

Mini-CODAC as a CODAC substitutional tool

Plant System Equipment (sensors, actuators, etc.) Substitution Tool

7.1.5.7. Test Tools:

1) Mini-CIS The CIS components are not available at supplier’s premises during the FAT. Hence for testing of the PIS interface with CIS protection modules and SCADA, concept of mini-CIS system has been introduces similar to mini-CODAC. The mini-CIS consists of an industrial computer and if needed Slow Controller/Fast controller acting as CIS protection module, where the hardware and the software components are designed to replace the main functionality of the CIS and perform the FAT/SAT of plant Interlock System.

Mini-CIS provide flowing functionality during FAT of the PIS o CIS protection module Substitution ToolIf a PIS implements part of central interlock functions, it’s requires an interface with the CIS protection (Slow/Fast) Modules. These CIS components are not available at suppliers’ premises for the FAT. Indeed, without its substitution tool, issues may appear, for example:

- Difficulty in checking interface.- Difficulty in checking Central functions.

For overcome above difficulties the Mini-CIS have a slow/fast controller which works as substitutional tool for CIS protection module and it’s used for checking the safety communication interface between CIS/PIS and also to check the implementation of the central interlock functions part in PIS .

o CIS SCADA Substitution ToolIt is one of the offerings of Mini- CIS during FAT, supervisory control and data acquisition of the PIS information is performed by the Mini-CIS acting as CIS SCADA Substitution tool. Indeed, without this substitution tool, issues may appear as below:

of 90

- Difficulty to monitoring PIS variables.- Difficulty to reproduce manually the override command protocol.- Difficulty to check the TSPP timestamping and archiving functions.- Difficulty to validate the appropriate implementation of the S7-TSPP

interface.- Need to modify the program in order to allow the reception of commands

(For Example: By default the command variables are reset if the SCADA alive counter is stops)

For overcome above difficulties the Mini-CIS have an industrial computer with WinCC OA server which works as substitutional tool of CIS SCADA and it’s used for Supervision (monitoring) and archiving of following PIS data through S-7 protocol : I. Supervision data: All status (event, action etc.) of the functions and the PIS

hardware health status: CPU, CP, I/O modules, etc. This information is generated by the PIS and sent to the CIS.

II. Archiving data: All the critical events and actions of PIS are logged together with their own time stamp, which are assigned directly by the triggering PLC .

The requirement of mini-CIS will be provided by PIS I&C RO to PBS 46, as per the technical and functional requirements of the respective PIS. The min-CIS requirement should be provided minimum 4-6 months before FAT. The PBS 46 will configure the mini-CIS system and send the same to PIS I&C RO.

Mini-CIS Hardware ArchitectureThe mini-CIS hardware architecture is composed ofI. A Dual Xeon E5-2418L industrial computer as specified in [RD4], used as

main hardware component, with the following network interfacesa. Interface with CIN P networkb. Interface with CIN A network

II. If required Slow/Fast Controller acting as CIS Protection Modules, with the following network interfacea. Interface with CIN P networkb. MC Interface between Fast CIS and Fast PIS modules

Mini-CIS software architecture The following software are installed in the industrial computer

I. Red Hat Linux Operating System 6.4 or above.II. Siemens WinCC OA 3.13 server.

III. Siemens WinCC OA software is configured to be connected to the PIS slow controller/Fast controller.

IV. Min-CIS HMI developed in WinCC OA for the testing

of 90

If required the min-CIS Slow/Fast controller is provided with developed necessary interface software

The FAT and SAT of a PIS including testing of all interfaces can be carried out using Mini-CIS.

There may be more than one mini-CIS available at IO to allow simultaneous FAT and SAT of different PIS, and they can be adapted for each particular case.

2) Mini-CODAC as CODAC substitution Tool Mini-CODAC is used to test the interfaces between each plant system (including PIS) and CODAC, so that after the plant systems FAT and SAT, the final integration is painless (acting as a plug-and-play module).Configuration of the PSH and Mini-CODAC – used as a local CODAC system – is a task ofthe plant system I&C supplierIn order to check the appropriate configuration of the PIS NTP synchronization, Mini-CODAC able to run NTP server services.

3) Plant System Equipment Substitution Tool

If some Plant System Equipment is not available, it is recommended to implement a Plant System Equipment Substitutional Tool to simulate the unavailable Plant System Equipment in order to facilitate the functionality tests.Depending on the amount and the type of I/O managed by the PIS and the complexity of the logical interconnection between them, two options are proposed:I. Test bench If a few I/O cannot be connected to real equipment and do not present a lot of logical interconnections, it may be considered to implement a small test bench with digital inputs connected to buttons and/or contact of relays, digital outputs connected to indicator and/or relays and analogue inputs connected to calibrator .

II. Plant System Equipment SimulatorsIf a lot of I/O cannot be connected to real equipment or present a lot of logical interconnections, it may be useful to implement a controller-based Plant System Equipment simulator.In any case, the Plant System Equipment Simulation Tools shall be ready, documented and checked before the beginning of the FAT activities. The documentations shall include the simulation tool hardware and internal logic description, connection to PIS I/O procedures, operator interface manual and the Simulation Tool test report.

4) Other Tools

- Multi-Channel Oscilloscope- Tester: multi-purpose- Safety Specification Tester ( Recommended : MI-2094: metrel)

of 90

7.1.6. Recommendations for checking the interfaces

It is highly recommended to check the interfaces with the CIS as far as possible during the FAT.The following sections aim at mapping the main verification activities recommended for checking the interfaces with the CIS to the 4 - campaign Plant System I&C FAT organization model. The scope of these recommendations is limited to the verification of the appropriate implementation in the PIS, and is described in the next sections.


To check the PIS Manufacturing Description for the following in view point of interface:

- To check the identification of the interfaces with the CIS in diagrams representing the PIS hardware architecture and its physical connections and functional interfaces with other I&C systems

- To check the components selected in the List of components- To check the list of data at CIS interface- To check the identification/description of the physical interface with the CIN in hardware

configuration of PIS cubicles showing all the cubicle interfaces (with Central I&C infrastructure, buildings, power supply, HVAC, etc.)

- To check the description of the interfaces with the CIS configuration in the description of the software.

- To check the identification/description of cables in the List of cables included in the cubicle hardware configuration diagrams.

To check the PIS On-site installation plan in view point of interface:

- To check the description of the physical interface with the CIN in cabling diagrams.- To check the procedure to install and connect the PIS to CNP.


- To check the cables between Plant Interlock Cubicles and Central I&C Network infrastructure (e.g. state, reference, connector type, length, etc.)

- To check the Plant System CIN switches (e.g. state, reference, installation inside the cubicle, labelling, etc.)

- To check the Slow/Fast PIS controllers connections to Plant System CIN switches (e.g. cables, cabling inside the cubicle, labelling, etc.)

- To check the Slow/Fast PIS and more precisely their interfaces with the CIS (e.g. state, reference, installation inside the rack/cubicle, etc.)


of 90

- To check the CIN Plant System network switches configuration (e.g. IP address, time synchronization management etc.)

- To check the compatibility of the programming environment used by Plant System designers for programming of Slow/Fast PIS, with the programming environment installed on the CIS Engineering Workstation.

- To check the delivered software applications including the configuration of the Slow/Fast PIS regarding the CIS interface important details.

- To validate the CIS Multiproject integration compatibility by integrating into the CIS multiproject the delivered slow PIS software applications project

For Slow Controllers:To check the delivered software applications including the configuration of the PIS controller(s) regarding the CIS interface important details:

o Project data (e.g. name, properties, etc.), devices (e.g. type, name, etc.), networks (e.g. type, name, etc.)

o Network configuration (e.g. connection type, connection ID, etc.)o Hardware configuration (e.g. component properties, component name, etc.)o Standard program (e.g. data blocks, communication function blocks, etc.)o Safety program (e.g. data blocks, communication function blocks, etc.)

For Fast Controllers:Check the coherence of the delivered software package with the setup required for the specific PIS. More in detail:

LabVIEW FPGA project name has to reflect the setup of the F-PIS

Network configuration of the Host PC (e.g. connection type, connection ID, etc.)

Hardware configuration of cRIOs (e.g. type of modules installed, slot used, etc.)

IRIO calls in the Host PC’s program have to match the cRIOs serial numbers, bitfile and header file names

cRIOs’ bitfile and header file have to correspond to the LabVIEW FPGA project from which they were compiled.


To check the following test from the PIS interface point of view:

For Slow Controllers:o CIN Plant System network switches configuration

of 90

- To check that the CIN Plant System network switches functional requirements are met.

o PIS interface with PIS Engineering Workstation

- These verifications aim at checking the physical connections up to the CIN Plant System network switches, part of the interface configuration, and part of the IP Access protection configuration, the password protection configuration and the number of connection resources.

- These verifications should take place with the PIS Engineering Workstation at suppliers’ premises and with other workstations (if required) at IO site.

- Check the connection establishment via CIN-P wherever applicable.

o To check the NTP synchronization: NTP synchronization is through the PON. Normally mini-CODAC will be used for NTP server at supplier premises.

o To check the S7-IE connection: These verifications aim at checking part of the interface configuration, part of the IP Access protection configuration, the number of connection resources, the exchanged variables and the override protocol implementation. These verifications should take place with the min-CIS at suppliers’ premises and with the CIS SCADA Servers at IO site.

o To check the S7-TSPP connection if any: Checking part of the interface configuration, the communication configuration and the exchanged variables. These verifications should take place with a mini-CIS at suppliers’ premises and with the CIS SCADA Servers at IO site.

o PIS PLC interface with CIS PLC (safety-related communication) if any

- Checking the interface configuration, the safety-related communication configuration, the exchanged variables and the degraded/fault modes.

- These verifications should take place with the CIS PLC at IO site. If a PLC system available in min-CIS as CIS PLC Substitution Tool at suppliers’ premises, (part of) these verifications could also take place with the min-CIS

o To check the functional interface specificationsThe verifications described in above sections aim at checking the appropriate configuration of the interfaces according to the interface specifications. It is highly recommended to complement these verifications by others in order to validate the interface specifications. It may be considered

- Check the local Interlock functions or part of central interlock functions performed by the PIS, including the control and monitoring interfaces.

- Check the operation and maintenance procedures requiring the usage of the SCADA (e.g. function and system monitoring interfaces, reset procedures in case of function trip and in case of system failure, maintenance procedures requiring operator overrides).

of 90

- Check all the mechanisms that are considered to be implemented in PIS PLC in order to improve the reliability of the operator overrides.

o To check the interface interactions in potential abnormal situationsIt is also highly recommended to check the following potential abnormal situations. These verifications should take place at supplier site with the mini-CIS platform.:

- Loss of communication with the CIS SCADA - Start-up of the CIN while the PIS and the CIS are already running.- Start-up of the PIS while the CIS is already running- Start-up of the CIS while the PIS is already running

For Fast Controllers:o Check the network connectivity of the Host PC to CINo Check the PIS cRIO interface with CIS cRIO, if present

- Test the Manchester coded communication between fast controllers. - This verification should take place with the CIS cRIO at IO site or with a mini-cis

cRIO at suppliers’ premises.

o Check the Host PC interface with PIS Engineering Workstationo Check the PTP synchronization of the Host PC through the TCNo Check the interface behaviour in potential abnormal situations

It is also highly recommended to check the following potential abnormal situations. These verifications should take place at supplier site with the mini-CIS platform.

- Loss of communication with the CIS SCADA - Start-up of the CIN while the F-PIS and the CIS are already running.- Start-up of the F-PIS while the CIS is already running- Start-up of the CIS while the F-PIS is already running

7.2 Multiproject Integration Procedure

In slow PIS case, a Step 7 Multi-project approach is adopted. Successful integration of the PIS project into CIS multi project is main step of integration. Following section describes how the Multi-project integration has been performed during SAT.

of 90

7.2.1. First Connection of a New PIS (one or several PLCs) to the CIS

CIS Multiproject PIS Project removed from MiniCIS Multiproject WinCC OA Project

Import PIS project in CIS MultiProject

on CIS Workstation

Configure Communication Between PIS and CIS

(Using Netpro Configuration)

Configure Supervision data for WinCC OA

Compilation of CIS Multiproject is OK ? Update CIS Multiproject

CIS Multiproject Ready for SAT

NO

YES

Figure 24: First Connection of New PIS with CIS

of 90

Above-mentioned flowchart describes first connection of a new Slow PIS to CIS.

The project administrator manages the Multiproject at the master database, defines

the structure of projects (locally, if required), controls distributed transactions for

external authors, then transfers the incoming projects to the Multiproject, adjusts

the cross-project data via the system functions ( file update synchronization ) and

executes necessary cross-project functions.

The IO CIS lead engineer start the integration importing the PIS local release into

the Multiproject, the shared communication are configured and the project

compiled and downloaded the into each PLC involved. A temporary version tag

of the software is generated and saved into SVN.

All the tests are performed and a new developing phase will start if a PIS or a CIS

functionality will fails. If all tests are passed the Multiproject and the PIS project

will be released and confirmed the SVN version tag. The saved Multiproject will

include also all the PLC source code and configuration managed with the

Multiproject.

7.2.2. Update of a PIS configuration

The update of PIS project is like a new development of it, so all the coding and test phases needs to be done; when the update and test are completed a new version of the PIS project will be released and saved. There are two possible cases for update of PIS configuration:

Update of a PIS configuration (hardware and/or software) not affecting central

functions/monitoring/and so on

Update of at PIS configuration (hardware and/or software) affecting central

functions/monitoring/and so on

7.2.2.1. Update of PIS Configuration (Hardware and/or Software) Without Affecting Central Functions/Monitoring

The development begins from the last Multiproject release for CIS and PIS.

Update the PIS project and perform the local function test , if passed all the test

release the update PIS project

of 90

As the PIS update does not affect the central functionalities there is no need to

update the CIS configuration, all the previous settings in the CIS are still good for

the new PIS project.

WinCC OA configuration doesn’t need to be updated as the data exchanged with

the Supervisor Module are not changed.

Import the updated PIS project into CIS Multiporject and perform the tests.

A phase of testing is required in order to verify all the central and local

functionality.

If all test passed a new CIS Multiproject is released and the SVN version tag

confirmed.

of 90

Figure 25: Update PIS Configuration without affecting central functions

of 90

7.2.2.2. Update of PIS Configuration (Hardware and/or Software) Affecting Central Functions/Monitoring

Figure 26: Update of PIS affecting Central Functions

of 90

When a PIS update affects the central functionality, a phase of redesign coding and testing is required.

If CIS project is affected by the PIS update then all the technical specification need

to be reviewed and updated. A new phase of coding and testing will start following

the new specification.

When the new CIS Project is developed and ready to integrate the PIS Project, the

IO CIS lead engineer start the integration import the updated PIS local release into

the Multiproject, configure the shared communication between them compile and

download the software into each PLC involved. A temporary version tag is

released.

The integration of the Multiproject with WinCC OA is done, and a Central testing

phase starts, if a PIS or a CIS functionality will fail a new update phase needs to be

done.

If the entire tests are passed, the Multiproject and the PIS project will be released

and the SVN version tag confirmed.

7.3 Recommendation for SAT of PIS

From the CENTRAL I&C perspective, the SAT objective is to check the readiness of the plant system I&C for integration with CENTRAL I&C systems and infrastructure and to check the readiness of the plant system I&C for integrated commissioning.

7.3.1. On-Site Integration Context

The On-site Integration consists in three main steps:

Installation phase

Acceptance phase

Integrated Commissioning phase

Refer to [RD28] ITER On-Site Testing Strategy (ITER_D_44U2Y4) and to [RD1] Plant Control Design Handbook (ITER_D_27LH2V) for additional explanations.

7.3.2. Plant System SAT Context

of 90

As explained in section 3.4.6 of [RD1] Plant Control Design Handbook

(ITER_D_27LH2V), Plant System Site Acceptance Test (SAT) is intended to

check the conformity with IO requirements of the plant system procurement first

as stand-alone.

Plant System I&C SAT is a part of the plant system SAT. All I&C components in

the procurement shall be powered and tested during SAT. The guidelines for plant

system integration [RD10] Plant System I&C Integration Plan

(ITER_D_3VVU9W) provide further details on SAT of plant system I&C. In

section 3.4.6 of [RD1] Plant Control Design Handbook (ITER_D_27LH2V), for

process control and performance test purpose, the plant system shall be tested

under a scenario and acceptance criteria provided by the ITER plant system RO.

This scenario shall include the individual tests of every plant system I&C function

with the real process connected to the plant system I&C and the test of the plant

system as a complete autonomous system as close as possible.

Attention shall be paid to checking of the proper operation of the whole plant

system (no adverse interactions between the different components affecting each

other operation).

Interlock Functional Assessment must be carried out in order to test failure modes

and improve integration results.

7.3.3. Recommendations / Requirements about the methodology

Refer to [RD28] ITER On-Site Testing Strategy (ITER_D_44U2Y4), to the sections

3.4.5 and 3.4.6 of [RD1] Plant Control Design Handbook (ITER_D_27LH2V) and to

the Clauses of [AS2] IEC 61511-1 and IEC 61508 for general

recommendations/requirements.

Refer also to section 7.1.4 recommendations about the methodology for FAT.

Generally for each campaign, the beginning of the campaign during the SAT is first a

repeat of the corresponding campaign during the FAT.

of 90

7.3.4. Recommendations for on-site integration activities

C1 campaign: I&C Documentation

Site Reception and Installation

C2 campaign: I&C Hardware

Electrical Safety Hazard Inspection

C3 campaign: I&C Configuration data and Software

Powering/Software Integration/ Connections to central I&C systems

C4 campaign: I&C Functional Requirement

Interlock function Assessment

System Acceptance

Onsite Integration Readiness

of 90

Figure 27: Steps involved in onsite Integration

The scope of the on-site integration activities is normally the whole Plant System. The scope of this document being limited to I&C systems dedicated to the PIS, this section provides details only about the PIS related on-site integration activities.

7.3.4.1. On-site integration readiness

It is recommended to check that:

- FAT issues are solved

- The deliverables documents are stored in IDM

- The hardware deliverables are ready for shipping

- The software deliverables are stored in the correct IO repository

- IO Site is ready for reception (Buildings RFE as identified in Figure 4 of [RD28] ITER On-Site Testing Strategy (ITER_D_44U2Y4): Building, CIS, SSEN, etc. ready)


For performing this campaign during SAT of PIS, please Refer 7.1.5.1

7.3.4.3. Site Reception and Installation

Site Delivery Components (cubicles, cables, field devices, etc.). List of delivered components

Site Reception Check the compliance of the components with the list of delivered components. Damage checking by visual inspection

Site Installation Components are installed at appropriate locations:- Cubicles are installed at their final place.- Sensitive equipment packed separately is properly remounted.- Field devices are installed at their final place.- Spare and maintenance tools are installed at their final storage

location.

Internal Cabling/Wiring

Cabling/Wiring between the Plant System components.

External Cabling/Wiring

Cabling/Wiring with interfacing components- Interfaces with PBS.43 (power supply – earth)Pre-requisites:- Lock and tag of the appropriate circuit breakers- Power supply cables are installed

of 90

- Earth connection points are installed

Installation Procedure:- Get the authorization to proceed- Connect the power supply cables and the earth.- Request for cabling inspection.- Get the cabling acceptance.- Lock and tag the main switch disconnectors- Get the authorization to test the interface.- Test the interface (e.g. check the voltage before and after the

circuit breaker)- Switch on the circuit breaker, check the voltage before and

after the circuit breaker, check the voltage before and after the main switch disconnector, etc.)

Interfaces with PBS.46 (CIS)Pre-requisites:- CNP are installed- Deactivation of the appropriate ports of the network switches

located in Network hutchInstallation Procedure:- Get the authorization to proceed- Connect the optic fiber cable in the CNP- Request for cabling inspection- Get the cabling acceptanceInterfaces with others if any


It is recommended to check that:

All the installation issues are solved.

The hardware deliverables are installed at appropriate location.

The hardware deliverables do not present any damage.

The hardware deliverables satisfy manufacturers’ recommendations.

The hardware deliverables are in conformance with the documentation:

- PIS Hardware is in conformance with PIS Manufacturing Description documentation (e.g. PIS cubicles hardware configuration diagrams including cubicle layout, cubicle internal wiring diagram, terminals description, cables list and material list),

- PIS On-site installation plan (e.g. cabling documents for all the PIS cubicles connections),

of 90

- PIS operation and maintenance document (e.g. Schematic diagrams of the full signal path from the sensors/actuators to the I/O boards of the PIS including powering and conditioning, with identification of test point for fault analysis or calibration and identification of the terminal blocks).

- PIS I&C Spare parts are in conformance with appropriate specifications of storage space and conditions.

- Tools required for maintenance of any PIS I&C component are in conformance with PIS Operation and maintenance document

Rules/requirements/recommendations applicable to hardware deliverables that were not checkable during C1 campaign (non-documented information) are satisfied

7.3.4.5. Electrical Safety Hazard Inspection

Carry out an electrical hazard safety inspection to get the authorization to power the PIS.


For performing this campaign during SAT of PIS, please refer 7.1.5.3.

7.3.4.7. Powering / Software integration / Connection to central I&C system

Powering Pre-requisites:- Administrative authorizations.- No worker on the installation.- Lock and tag of the actuators power circuit.- For slow PIS PLC CPU in STOP- In case of Fast PIS cRIO chassis should be OFF. ,

Procedure:- Check that all the circuit breakers and all the power

supplies are off- Check the voltage before and after the main switch

disconnector.- Switch on the main switch disconnector.- Check the voltage before and after the main switch

disconnector.- Check that the corresponding green power light is on

etc.Note: If the lock and tag of the actuators power circuit, do not guarantee the avoidance of any unexpected automatic action, which could potentially damage the plant system, take appropriate measures.

of 90

Field devices configuration Field devices calibration/configuration if necessary and tests.

Network switches configuration

Procedures:- Download the network switches configuration - Check the on-line network switches configuration.

For Slow PIS:

PLC Hardware configuration

Procedures:- Reset the CPU- Download the hardware configuration- Check the on-line configuration

Note: At this level, the check list shall validate that the PLC can be connected to the CINwithout any damage

- Check all the inputs from the sensors up to the input modules (cabling, logic, sensors installation, etc.)

- Check all the outputs from the output modules up to the end of the control circuit (cabling, logic, etc.)

Note: If the lock and tag of the actuators power circuit, do not guarantee the avoidance of any potential damage to the plant system when manually activating some outputs, take appropriate measures.

Network connection Activate the appropriate ports of the network switches located in Network hutch

PLC Software downloading Download the software with the PBS.46 CIS Engineering Workstation:

- Download the hardware configuration.- Download the S7 program.- Check if the downloading was successful.

Note: If the lock and tag of the actuators power circuit do not guarantee the avoidance of any unexpected automatic action which could potentially damage the plant system, take appropriate measures (e.g. put the CPU in STOP)

- Put the CPU in RUN if required- Check the system state

Note: If the lock and tag of the actuators power circuit do not guarantee the avoidance of any unexpected automatic action which could potentially damage the plant system, take appropriate measures before switching the CPU to RUN mode.

For Fast PIS

Network connection Activate the appropriate ports of the network switches located in Network hutch

of 90

Fast PIS Software downloading

Download the software with the PBS.46 CIS Engineering Workstation .Download the configuration project on the Host PCExecute the script that runs the program which download the bitfile to the chassis

- Check if the downloading was successful.- Check the system state


Figure 28: Steps involved in C4 Campaign

1. C4 campaign: I&C functional requirements readinessA Plant system is normally ready for the functional tests if the following criteria are met:

- Installation and commissioning issues are solved- All the Plant System components are operational

of 90

- The PIS is ready- The test operator is ready to proceed- Administrative authorizations are obtained

For organizational reasons, it may be considered to repeat the tests performed during the FAT C4 campaign: I&C functional tests at the beginning of the SAT C4 campaign: I&C functional requirements, in order to check the Plant System components separately as much as possible before the overall Plant system functional tests. In case of the resolution of FAT, installation and commissioning issues have required a lot of modifications, this intermediate phase is highly recommended.

2. To check the state of the Plant SystemFor Slow PIS

Field Devices To check that the field devices are in appropriate state

PIS Controllers - To check that the modules are ok (e.g. power supply, interface modules, signal modules).

- To check that the CPU is/are running.- To check that the inputs are consistent with field devices.- To check that the field devices are consistent with the outputs.- To check the ability to monitor the system with the CIS

Engineering Workstation Via CIN-P 1 and CIN-P 2 - To check that communication links are established / interfacing

components are reachable.I. S7-IE interface with SCADA Server in MSR and BSR via

CIN-P1II. S7-IE interface with SCADA Server in MSR and BSR via

CIN-P2III. S7-TSPP interface with SCADA Server S7-IE interface

with SCADA Server in MSR and BSR via CIN-P1IV. S7-TSPP interface with SCADA Server S7-IE interface

with SCADA Server in MSR and BSR via CIN-P2V. NTP synchronization with CODAC

VI. Fail-safe communication interface with CIS protection module PLC via CIN – P1 and CIN – P2 ( if PIS participates in CIS functions )

- To check the performance of the slow PIS I. To check the maximum cycle time and its maximum

allowed valueII. To check the standard program execution time, its

maximum allowed value and the alarm in case of over valueIII. To check the safety program execution time, its maximum

allowed value and the alarm in case of over value

of 90

For Fast PIS

Field Devices To check that the field devices are in appropriate state

PIS Controllers - To check that the modules are ok (e.g. power supply, diagnostic modules, signal modules).

- To check that the both cRIO chassis are running.- To check that the inputs are consistent with field devices.- To check that the outputs are consistent with the field devices.- To check the ability to access the system with the CIS

Engineering Workstation Via CIN-P 1 and CIN-P 2 - To check that communication links are established and

interfacing components are reachable.I. Host PC interface with SCADA Server in MSR and BSR

via CIN-P1II. Host PC interface with SCADA Server in MSR and BSR

via CIN-P2III. PTP synchronization with CODACIV. Manchester communication interface with CIS fast

protection module PLC via fiber optics links ( if PIS participates in CIS functions )

3. To check the functions implemented by hardwired logic ( if any)In ICS some special interlock functions are implemented using BLIB and DLIBS hardwire architectures. Functions implemented by these hardwire logic need to be checked.

4. To check the functions implemented by the controllers

Interlock Function test :

To check the local and part of central interlock functions (if any) (including its monitoring):- To check all the event cases (combinations of input

depending of the voter)- To check all the action cases (combinations of output

depending on the voter)- To check the reset procedure- To check the operation/maintenance procedure (e.g. requiring

overrides)System monitoring functions:

For Slow PIS :- To check the safety program signature monitoring- To check the safety mode state monitoring

of 90

- To check the PLC date/time monitoring

For Fast PIS :- To check the HOST PC date/time monitoring

5. To check the degraded / fault modesFor Slow PIS

Field devices To check the Field Devices degraded/fault modes

PIS Cubicle To check the fault mode: loss of signal power supply

Slow PIS controller(s)

- To check the degraded mode: loss of signal power supply Class II-IP

- To check the degraded mode: loss of signal power supply Class IV

- To check the fault mode: loss of both signal power supply- To check the degraded/fault mode: loss of signal modules- To check the degraded/fault mode: loss of interface modules- To check the degraded/fault mode: loss of fieldbus- To check the degraded mode: loss of CPU power supply Class

II-IP- To check the degraded mode: loss of CPU power supply Class

IV- To check the degraded/fault mode: loss of both CPU power

supply- To check the degraded/fault mode CPU in STOP- To check the alarm: battery failure- To check the alarm: back-up voltage failure- To check the degraded mode: loss of network connection to

CIN-P 1- To check the degraded mode: loss of network connection to

CIN-P 2- To check the degraded/fault mode: loss of both connections to

CIN - To check the CPU state monitoring

(RUN/STOP/STARTUP/UPDATE/etc. and Master/slave (if Fully fault tolerant PIS )

In case of Fully fault tolerant PIS: - To check the degraded mode: synchronization failure leading to

slave CPU in STOP- To check the fault mode: synchronization failure leading to two

Master CPU in RUN

of 90

Power Distribution - Check the fault mode: loss of power distribution to the plant interlock system cubical(s)

- Class II-IP power supply (switch off the main switch disconnector).

- To check the error-free recovery (switch on the main switch disconnector).

- Class IV power supply (switch off the main switch disconnector).

- To check the error-free recovery (switch on the main switch disconnector).

PIS interfacing components

- To check the degraded mode: loss of CIS SM server in MSR- To check the degraded mode: loss of CIS SM Server in BSR- To check the fault mode: loss of both SM Servers- To check the degraded mode: loss of CIS protection module in

MSR (if required)- To check the degraded mode: loss of CIS protection module in

BSR (if required)- To check the fault mode: loss of both CIS protection module ( if

required)- To check the degraded mode: loss of CIN-P 1- To check the degraded mode: loss of CIN-P 2- To check the fault mode: loss of both CIN branches

For Fast PIS

Field devices Tests are same as Slow PIS

PIS Cubicle Tests are same as Slow PIS

Fast PIS controller (s)

- To check the degrade mode: loss of cRIO Chassis 1 or 2 power supply Class II-IP

- To check the degraded mode: loss of cRIO Chassis 1 or 2 power supply Class IV

- To check the fault mode: loss of both power supply (Class II-IP and IV) of cRIO Chassis 1 or 2

- To check the degrade mode: loss of Host PC power supply Class II-IP

- To check the degraded mode: loss of Host PC power supply Class IV

- To check the fault mode: loss of both power supply (Class II-IP and IV) of Host PC

- To check the degraded mode if cRIO Chassis 1 or 2 are back to “initialization state”

- To check the fault mode cRIO if Chassis 1 and 2 are back to “initialization state”

- To check the degraded mode: loss of network connection to CIN-P 1

of 90

- To check the degraded mode: loss of network connection to CIN-P 2

- To check the degraded mode: loss of both connections to CIN-P

- To check the degraded mode: interchassis synchronization failure between two cRIO Chassis

- To check the degraded/fault mode: loss of modules detection

Power Distribution Tests are same as Slow PIS

PIS interfacing components

Tests are same as Slow PIS

6. To check the operator/maintenance procedures To check operation and Periodic tests procedures (if not checked during the C2 hardware campaign or during the verification of the functions) and calibration procedure (if not checked during field devices configuration).

7. To check the performancesIn the performance test of PIS (slow/fast) Immunity to typical environmental conditions, response time, spurious trip rate, accuracy, etc. are tested As explained in section 3.2.6 and Figure 1 of [RD26] ITER On-Site Testing Strategy (ITER_D_44U2Y4), acceptance phase may be split in two phases:

- Provisional acceptance phase and- Final acceptance phase.

This typically allows addressing part of the performance tests (e.g. spurious trip rate) during the final acceptance phase even if performance tests such as response time measurements must be addressed as much as possible during the provisional acceptance phase.

7.3.4.9. Functional Assessment

It is recommended to organize a interlock functional assessment (if possible, undertaken by an independent organization).The assessment team shall confirm that:- The risk assessment has been carried out as per [RD3] .- The recommendations arising from the FMEA (or HAZOP or STPA) have been

properly implemented- All the means of risk reductions are designed, constructed and installed in accordance

with the interlock system requirement specification- The validation plan is appropriate and the validation activities have been completed- The operating and maintenance procedures are in place