Memorandum / Note. Approval Process Name Action Affiliation Author Soni J. 21 Dec 2017:signed IO/DG/COO/SCOD/CSD/PCI Co-Authors Gaikwad Y.

Transcription

1 IDM UID 7LELG4 VERSION CREATED ON / VERSION / STATUS 21 Dec 2017 / 4.0 / Approved EXTERNAL REFERENCE / VERSION Memorandum / Note Guidelines for PIS configuration and integration This 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 Affiliation Author Soni J. 21 Dec 2017:signed IO/DG/COO/SCOD/CSD/PCI Co-Authors Gaikwad Y. 21 Dec 2017:signed TATA Consultancy Services France SA... Pedica R. Reviewers Ciusa G. Fernandez-hernando J. L. Liu Y. Petitpas P. Prieto diaz I. 21 Dec 2017:signed 21 Dec 2017:recommended 21 Dec 2017:recommended 21 Dec 2017:recommended 21 Dec 2017:recommended 21 Dec 2017:recommended IO/DG/COO/SCOD/CSD/PCI IO/DG/COO/SCOD/CSD/PCI IO/DG/COO/SCOD/CSD/PCI IO/DG/COO/SCOD/CSD/PCI IO/DG/COO/SCOD/CSD/PCI IO/DG/COO/SCOD/CSD/PCI Approver Wallander A. 22 Dec 2017:approved IO/DG/COO/SCOD/CSD Document Security: Internal Use RO: Fernandez-hernando Juan luis Read 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... PDF generated on 22 Dec 2017 DISCLAIMER : UNCONTROLLED WHEN PRINTED PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

2 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 v7 v2.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 PDF generated on 22 Dec 2017 DISCLAIMER : UNCONTROLLED WHEN PRINTED PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

3 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 PDF generated on 22 Dec 2017 DISCLAIMER : UNCONTROLLED WHEN PRINTED PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

4 Guidelines for PIS Configuration and Integration (ITER_D_7LELG4) Table of Contents 1. Introduction PCDH Context Document Scope Applicable Standards [AS] Related Documents [RD] Abbreviations and Acronyms Definitions Considerations Assumptions Principles Introduction Terminology Naming Convention for PIS Naming convention for slow PIS Naming convention for Fast PIS Project and Hardware naming convention Variable naming convention Configuration of Slow PIS Hardware configuration Software Architecture and Programing concepts Local interlock function implementation in Slow PIS Part of Central interlock function implementation in slow PIS Concept of Override and Threshold value section Concept of Reset Concept of Reintegration Concept of Critical health monitoring Concept of archiving and status Monitoring Concept of conventional health monitoring and CODAC interface Configuration of Fast PIS...42 Page 1 of 90

5 Guidelines for PIS Configuration and Integration (ITER_D_7LELG4) 5.1 Hardware configuration Hardware Configuration using Fast PIS Template Hardware Configuration for New project Software architecture and Programming concepts Concept of archiving and status Monitoring Management of PIS software Version Control Repository Management Development Process Scope areas for PIS Software development Off-Site Development and Stand-Alone Test (Independently from IO) Integration Recommendation for FAT of PIS Plant System FAT Context PIS FAT Objective Recommendations about the methodology Recommendations about the FAT scope Recommendations for performing the campaigns Recommendations for checking the interfaces Multiproject Integration Procedure First Connection of a New PIS (one or several PLCs) to the CIS Update of a PIS configuration Recommendation for SAT of PIS On-Site Integration Context Plant System SAT Context Recommendations / Requirements about the methodology Recommendations for on-site integration activities...80 Page 2 of 90

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

7 Guidelines for PIS Configuration and Integration (ITER_D_7LELG4) List of Tables Table 1: Abbreviations and Acronyms...8 Table 2: Fast PIS Hardware naming convention...16 Table 3: Fast PIS variable naming convention...17 Table 4 : Override type and associated signals naming convention...30 Table 5: Critical Health Monitoring Signal...37 Table 6: Approved crio modules...45 Table 7: Status word data...50 Page 4 of 90

8 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. PCDH core and satellite documents: v7 PS CONTROL DESIGN INTERLOCK CONTROLS Guidelines PIS design (3PZ2D2) Guidelines for PIS integration & config. (7LELG4) Management of local interlock functions (75ZVTY) PIS Operation and Maintenance (7L9QXR) Plant system I&C architecture (32GEBH) Methodology for PS I&C specifications (353AZY) CODAC Core System Overview (34SDZ5) I&C CONVENTIONS I&C Signal and variable naming (2UT8SH) ITER CODAC Glossary (34QECT) ITER CODAC Acronym list (2LT73V) OCCUPATIONAL SAFETY CONTROLS Guidelines for PSS design NUCLEAR PCDH (2YNEFU) CATALOGUES for PS CONTROL Slow controllers products (333J63) Fast controller products (345X28) Cubicle products (35LXVZ) Integration kit for PS I&C (C8X9AE) Core PCDH (27LH2V) Plant system control philosophy Plant system control Life Cycle Plant system control specifications CODAC interface specifications Interlock I&C specification Safety I&C specification PS CONTROL DEVELOPMENT I&C signal interface (3299VT) PLC software engineering handbook (3QPL4H) Guidelines for fast controllers (333K4C) CODAC software development environment (2NRS2K) Guidelines for I&C cubicle configurations (4H5DW6) CWS case study specifications (35W299) PS SELF DESCRIPTION DATA Self description schema documentation (34QXCP) PS CONTROL INTEGRATION The CODAC -PS Interface (34V362) PS I&C integration plan (3VVU9W) ITER alarm system management (3WCD7T) ITER operator user interface (3XLESZ) Guidelines for PON archiving (87N2B7) PS Operating State management (AC2P4J) Guidelines for Diagnostic data structure (354SJ3) Legend This document Available and approved Expected (XXXXXX) IDM ref. 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. Page 5 of 90

9 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 Functional safety of electrical/electronic/programmable electronic safety- related systems [AS2]. IEC Functional safety Safety instrumented systems for the process industry sector 1.4 Related Documents [RD] [RD1]. [RD2]. [RD3]. [RD4]. [RD5]. [RD6]. [RD7]. [RD8]. [RD9]. [RD10]. [RD11]. [RD12]. [RD13]. [RD14]. [RD15]. [RD16]. [RD17]. [RD18]. [RD19]. [RD20]. [RD21]. [RD22]. [RD23]. Plant Control Design Handbook (PCDH) (ITER_D_27LH2V) Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2) Management of Local Interlock Functions (ITER_D_75ZVTY) PIS Operation and Maintenance (ITER_D_7L9QXR) Central Interlock System (PBS-46) - Design Description Document (DDD) (QCH3GJ v2.2) Catalogue for I&C products Slow controllers (ITER_D_333J63) PLC Software Engineering Handbook (ITER_D_3QPL4H) Interlock Control System Overall Quality Plant (ITER_D_75GBSW) Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH) Plant System I&C Integration Plan (ITER_D_3VVU9W) ITER Operator User Interface (ITER_D_3XLESZ) ITER Alarm System Management (ITER_D_3WCD7T) Guidelines for PON Archiving (ITER_D_B7N2B7) ITER CODAC Subversion Guideline (ITER_D_A2GSXB) Core System Application Developer Manual (ITER_D_33T8LW) CIS_V.0_WinCC_OA_Configuration_and_interfacing_with_PLC (ITER_D_PHK5CJ) Implementation of High Integrity Operator Commands in the Interlock Control System (ITER_D_PKMDA8) Standard PLC Software Structure (SPSS) User Manual (ITER_D_G4UMX5) ITER Control Breakdown Structure_ (CBS) (ITER_D_9TYFWC). CODAC Core System Overview (ITER_D_97W6Q9). CODAC Core System Installation Manual (ITER_D_33JNKW) Self-description data editor - User manual (ITER_D_32Z4W2) Standard PLC Template for Interlock Applications_ITER_D_SDTX28 Page 6 of 90

10 [RD24]. IEC 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) Page 7 of 90

11 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 CIN CIS CP CPU CODAC EPICS ES FH GOS HIOC HMI I&C ICS I/O IO IOC PBS PCDH PIN Expansion Central Interlock Network Central Interlock System Communication Processor Central Processing Unit Control, Data Access and Communication Experimental Physics and Industrial Control System Engineering Station Fault Tolerant (Specifically used for Siemens System) Global Operating State High Integrity Operator Commands Human Machine Interface Instrumentation & Control Interlock Control System Input / Output ITER Organization Input Output Controller Plant Breakdown System Plant Control Design Handbook Plant Interlock Network Page 8 of 90

12 Abbreviation or Acronym Expansion PIS PLC PON PS PSCC PSH PSS-OS PVN SCADA WinCC OA Plant Interlock System Programmable Logic Controller Plant Operation Network Power Supply Plant System Conventional Control Plant System Host Plant Safety System- Occupational safety Private Network Identifier Supervisory Control and Data Acquisition Windows Control Center Open Architecture 1.6 Definitions I/O Module Local Network Central Network FB FN Board installed close to the Central Processing Unit (CPU) or connected to the CPU remotely in order to report/transmit signals from/to the field Communication network is considered as a Local Network when communication between Local racks, Remote racks from CPU or Communication Processor (CP) over network bus. 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 Profibus (any Field Bus) communication from controller (from PIS/CIS to remote I/O) is termed as FB in slow PIS PLC naming convention. Profinet (any Field Net) communication from controller (from PIS/CIS to remote I/O) is termed as FN in slow PIS PLC naming convention. Page 9 of 90

13 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 safetyrelated 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). Page 10 of 90

14 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 PLCs 2. 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 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. Page 11 of 90

15 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. Page 12 of 90

16 Interlock Event This 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 Function This 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 Data There 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. Page 13 of 90

17 Non-Critical Interlock Data Information 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. Page 14 of 90

18 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 convention 2. Variable naming convention Page 15 of 90

19 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 Project Name Chassis/Host PC Name Input/Output Modules AAAA_BBBB_CCCCC PPPPPP_TTT_NNNN Chassis ID_Signal module identifier _Type of Module identifier AAAA This signifies the CBS level 1 of the Controller. BBBB This signifies the CBS level 2 of the Controller. Particularly CCCCC must make the CCCCC difference between projects that will coexist in the same Plant System Example CRYO_CA_ICU01 PPPPPP Plant Breakdown Structure (PBS) Identifier TTT Component functional category designator NNNN Sequential number. It is also indicating the domain of the component. Example _PFC _4000 Chassis ID Chassis ID where signal module is installed CR1 or CR2 Sequential number of Signal module with Signal Module suffix of SM The slot position must match Identifier with the Signal module Identifier number Type of Module Identifier Analog or Digital Input/output type. Example CR1_SM01_DI CR2_SM03_AO Page 16 of 90

20 Variable naming convention Following Table 3 depicts Fast PIS Variable naming convention : Ite m target Proposed Naming Convention Table 3: Fast PIS variable naming convention Significance and Example Variables Linked to Signal Labview Variable CODAC PV KKK_TTTNNNN_AAAA [RRRR] FFFF-FFFF- FFFF:KKK_TTTNNNN_AAA A[RRRR] KKK TTTNNNN_AAAA [RRRR] Example FFFF-FFFF-FFFF KKK TTTNNNN_AAAA[ RRRR] Example Chassis indicator, it indicates the Chassis where the variable is generated. CH1 Chassis 1 CH2 Chassis 2 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 CR2_MT0001_TT0001 This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). Indicator of the Chassis that receive the signals CH1 or CH2 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 MAG-MATF-INTF:CR2_ MT0001_TT Page 17 of 90

21 WinCC OA Datapoint FFFF_FFFF_FFFF_KKK_TTT NNNN_AAAA[RRRR] FFFF_FFFF_FFFF KKK TTTNNNN_AAAA[ RRRR] Example This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). Indicator of the Chassis that receive the signals CR1 or CR2 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 Variables Computed by the PIS Labview Variable KKKK_VVVVVVVVV_GGG H[RR] MAG_MATF_INTF_CR2_ MT0001_TT KKK 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. 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 Page 18 of 90

22 CODAC PV FFFF-FFFF- FFFF:KKK_VVVVVVVVV_G GGH[RR] H [RR] Example FFFF_FFFF_FFFF KKK VVVVVVVVV GGG 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 Sequential Number if required to discriminate signal with the same name CR1_CRYOOK_MSKP01 CR2_CRYOOK_MSKP01 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 Chassis indicator, it indicates the Chassis where the variable is generated. CR1 Chassis 1 CR2 Chassis 2 Suggested length nine characters the free textual description used to explain the function of the variable. Maximum Three Character is the identifier of the variable. MSK Mask THR Threshold FRC Force CRT Critical RAW Raw data STS Status Page 19 of 90

23 ACK Acknowledge 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 WinCC OA Datapoint FFFF_FFFF_FFFF_KKK_VVV VVVVVV_GGGH[RR] [RR] Example FFFF_FFFF_FFFF KKK VVVVVVVVV Sequential Number if required to discriminate signal with same name CRYO-CA-LIN1:CR1_CRYOOK_MSKP01 CRYO-CA-LIN1:CR2_CRYOOK_MSKP01 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 Chassis indicator, it indicates the Chassis where the variable is generated. CR1 Chassis 1 CR2 Chassis 2 Suggested length nine characters the free textual description used to explain the function of the variable. Page 20 of 90

24 GGG H Maximum Three Character is the identifier of the variable. MSK Mask THR Threshold FRC Force CRT Critical RAW Raw data STS Status ACK Acknowledge 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] Example Sequential Number if required to discriminate signal with same name CRYO_CA_LIN1_CR1_CRYOOK_MSKP01 Critical Health Monitoring Variables Labview Variables TTTNNNN_HltStatusVAr TTTNNNN HltStatusVAr Example CRYO_CA_LIN1_CR1_CRYOOK_MSKP01 Component name following the CODAC Naming Convention HPC_COM Communication with Host PC status CR_COM Communication with Partner Chassis Status SM[N] Health Status of the ModuleN DSP_V[N] Discrepancy status of voter N ERR_F[N] FPGA error staus of Function N PCF1501_HPC_COM PCF1501_CR_COM Page 21 of 90

25 WinCC OA Datapoint FFFF_FFFF_FFFF_ TTTNNNN_HltStatusVar FFFF FFFF FFFF HltStatusVAr Example PCF1501_SM1 PCF1501_DSP_V1 PCF1501_ERR_F1 CBS level 1 following CODAC convention CBS level 2 following CODAC convention fixed code SYSM dedicated to system monitoring HPC_COM Communication with Host PC status CR_COM Communication with Partner Chassis Status SM[N] Health Status of the ModuleN DSP_V[N] Discrepancy status of voter N ERR_F[N] FPGA error status of Function N MAG_PFCS_SYSM_PCF1501_HPC_COM MAG_PFCS_SYSM_PCF1501_CR_COM MAG_PFCS_SYSM_PCF1501_SM1 MAG_PFCS_SYSM_PCF1501_DSP_V1 MAG_PFCS_SYSM_PCF1501_ERR_F1 Page 22 of 90

26 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. Page 23 of 90

27 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 Page 24 of 90

28 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 overridable 6) Apply Force logic if action is overridable 7) Apply the reset logic to latch/unlatch the action command 8) Send the action output to the single/multiple output port (based on output voter logic) through channel driver Event Masking Command Event Masked Notification Function Disable Function Disable Notification Action Forcing Command Action Forcing Notification Function/action Activation Notification Voter Logic Solver Input1 Input2 Input3 2oo3 Voter Result Event Local Function Logic Action S R Protective Action Function Reset Condition 1 Condition 2 Condition 3 Ready to Reset Ready to Reset Notification* Function Reset* * TO/FROM CODAC Figure 3: Typical slow local interlock protection function schema Page 25 of 90

29 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. EVENT Event Masking Event Masked Notification EVENT Voter Logic Solver TO CIS Input1 Input2 Input3 2oo3 Voter Results Event S R Condition 1 Condition 2 Condition 1 Condition 2 Condition 3 Ready to Reset Notification* Ready to Reset Event Reset Event Reset * * TO/FROM CODAC Figure 4: Typical Event generation schema for central interlock function Page 26 of 90

30 ACTION FROM CIS Action Forcing Action Forced Notification Action Activated Notification Condition 1 Condition 2 Condition 3 Ready to Reset Notification* Ready to Reset S R Protective Action command Function Reset* Function Reset Notification * 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 Page 27 of 90

31 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 commands 4) Send the action command to the single/multiple output port (based on output voter logic) through channel driver Concept of Override and Threshold value section 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 and IEC OR ensure that safety-bus frame must be passed completely unmodified from a safety sender to a safety receiver Page 28 of 90

32 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. CIS CIS Desk (WinCC-OA Client) STANDARD PROGRAM FB 1023:S_OC_BO SLOW PIS PLC SAFETY PROGRAM FB 1024: F_OC_BO F_Q_OVRC HIOC_STD HIOC_SFT Three Step Validation Request ID, Command ID, Confirmation ID F_CRT F_OVRS F_CRTO Critical signal After Override (XX-CRTO) Supervisiory Module (WinCC-OA Server) SCADA_HIOC DB 1016 Critical signal Before Override (XX-CRT) Data Conversion between Safety and Standard Figure 6: Concept of Overrides Page 29 of 90

33 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 Function Disabled XX_FRC XX_FRCS XX_CRT XX_CRTO XX_DSB XX_DSBS XX_CRT XX_CRTO Page 30 of 90

34 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 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: Page 31 of 90

35 CIS STANDARD PROGRAM SLOW PIS PLC SAFETY PROGRAM CIS Desk (WinCC-OA Client) Three Step Validation HIOC_TH_STD HIOC_TH_SFT Selected Threshold Value Request ID, Command ID, Confirmation ID Response Threshold Values for Selection Supervisiory Module (WinCC-OA Server) SCADA_HIOC_TH Data Conversion between Safety and Standard 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 K th 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). Page 32 of 90

36 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 reset o o Ready to Reset critical event /action status 2) Command for function reset o 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. Page 33 of 90

37 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). CODAC SLOW PIS PLC CODAC Desk STANDARD PROGRAM SAFETY PROGRAM FB 1011: F_FN_RST OP_CMD Cond 1 Cond 2 COMMAND DB 102 Ready to Reset Reset CMD Cond 16 PSH Ready to Reset status STATUS DB 100 Function Reset Data Conversion between Safety and Standard Figure 8: Concept of RESET 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. Page 34 of 90

38 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. Page 35 of 90

39 CODAC SLOW PIS PLC STANDARD PROGRAM SAFETY PROGRAM CODAC Desk F-CH_DRIVER BLOCK ACK_REI CH 1 ACK_REQ Reintegration Command COMMAND DB 102 Block Name * * OR F-CH_DRIVER BLOCK ACK_REI CH 2 ACK_REQ F-CH_DRIVER BLOCK ACK_REI CH 3 ACK_REQ F-AI/F DI/F DO PSH Acknowledge Request STATUS DB 100 F-CH_DRIVER BLOCK ACK_REI CH n * ACK_REQ Data Conversion between Safety and Standard * 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 Figure 9: Concept of Reintegration 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). Page 36 of 90

40 Table 5: Critical Health Monitoring Signal Sr. No. Description 1 CPU INTF (internal error) 2 CPU EXTF (external error) 3 CPU RUN 4 CPU STOP 5 CPU REDF (redundancy error) 6 CPU MSTR (master) 7 CPU DC24V 8 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 Page 37 of 90

41 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 : S7 protocol 1. S7 protocol - for non-critical data 2. TSPP protocol - for critical data 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 1s 4. 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] 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. Page 38 of 90

42 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 Kbytes It 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]. CIS SLOW PIS PLC CIS Desk (WinCC-OA Client) STANDARD PROGRAM SCADA_STATE_100ms (DB 1004) Data through S7 Protocol S7 Protocol SCADA_STATE_1s (DB 1005) Supervisiory Module (WinCC-OA Server) TSPP Protocol Data through TSPP Protocol SCADA_STATE_TSPP (DB 1002) Figure 11: Concept of archiving and status monitoring Page 39 of 90

43 Concept of conventional health monitoring and CODAC interface 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 o o o o Ready to Reset Acknowledge request Conventional Health monitoring All critical event and action status All Analog process values 2) Command variables o o Reset Command 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. Page 40 of 90

44 PIS PLC receives commands (DB 102) and sends status (DB 100) data to CODAC through PSH 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. CODAC SLOW PIS PLC STANDARD PROGRAM CODAC Desk PSH TCP CONNECTION Command TCP Connection-port 2001 Status TCP Connection-port 2000 COMMAND DB 102 STATUS DB Reset command 2. Reintegration command 1. Ready to Reset 2. Acknowledge Req. 3. Conventional Health monitoring 4. All critical event and action status 5. Analog process values Figure 12: Conventional Health monitoring and CODAC Page 41 of 90

45 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: 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 Page 42 of 90

46 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: 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. Page 43 of 90

47 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. Page 44 of 90

48 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_ 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 DESCRIPTION NI Ch DI modules ±200 mv, ±1, ±5, and ±10 V NI Ch DO used as DI diagnostic module 8 Ch DI module TTL NI Ch DO module TTL 8 Ch DO used as DI diagnostic module Page 45 of 90

49 NI 9477 NI 9426 NI 9425 NI Ch DI used ad DO diagnostic module SPI interchassis communication Manchester transmitter (event) Manchester receiver(action) 32 Ch Digital sinking output module 5,12, 24, 48, 60 V 32 Ch Sourcing DI module 30 V 32 Ch Sinking DI module 12 V,24 V 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. Page 46 of 90

50 Central Interlock System SUPERVISOR MODULE Host PC crio FPGA (Chassis 1) Sensors OPC UA SERVER Mxi CORE APPLICATION CODAC Actuators IRIO irio-opc UA Interface crio FPGA (Chassis 2) Interchassis Communication MC from CIS Mxi CORE APPLICATION MC to CIS 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 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. Page 47 of 90

51 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. Loop Iteration time INPUT VOTER Diagnostic Input Generation Input Reading Input Diagnostic Check Voter Voter Diagnostic From previous Iteration Data/ Diag ratio Output Writing Output Diagnostic OUTPUT Chassis Diagnostic Global Status To Next Iteration From CIS Manchester Receiver EVENT ACTION Manchester Transmitter MC EC/DC DECISION To CIS SPI Communicatio n Master To other Chassis SPI From other chassis SPI communicatio n Slave Figure 18: FPGA Core application Page 48 of 90

52 Inputs The 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. Voter The 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. Outputs The 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 channels so 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 Logic The 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 Page 49 of 90

53 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 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. Legend Consecutive Number Table 7: Status word data Description Consecutive number of the word PU Powering status CH Communication with Host PC status CC Communication with remote chassis status RP Power status of remote chassis I1 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 2 TE Temperature alarm status VOn Voter Output status of n-th protection function VAn Voter Output alarm of n-th protection function VDn Voter Diagnostic status of n-th protection function CRC Cyclic redundancy check Page 50 of 90

54 STATUS WORD Consecutive Number PU CH CC RP I1 I2 I3 O1 O2 TE VO VA VD VO VA VD VO VA VD VO VA VD4 VO5 VA5 VD5 VO6 VA VD 6 VO 7 VA 7 VD 7 VO 8 VA 8 VD 8 VO 9 VA 9 VD 9 VO1 0 VA1 0 VD1 0 VO1 1 VA1 1 VD CRC Figure 19: Status word structure Page 51 of 90

55 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 The 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. Page 52 of 90

56 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. Page 53 of 90

57 Several development tools are involved in the development of specifically Fast PIS runtime Application. These are as follows: SDD I&C CREATION COMPONENT CREATION- SIGNAL CONTROLLER CREATION CONFIGURATION AND STATES CREATION EPICS CONFIGURATION LabVIEW LabVIEW PROJECT CREATION CREATION OF BITFILE ECLIPSE HOST PC CHASSIS- WinCC OA INTERFACE CONFIGURATION RUNTIME APPLICATION WINCC-OA WIN CC OA PROJECT CREATION DRIVER SETTINGS DATAPOINT CONFIGURATION GRAPHIC SCREEN DEVELOPMENT CSS CODAC CORE SYSTEM APPLICATION CREATION COMPILE GENERATE BOY SCREEN 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 Scope areas for PIS Software development Following areas are in scope of PBS 46 CIS Team o WinCC OA project creation, configuration and Interfacing with PIS. Following areas are in scope of PS I&C RO o The development procedures related to SDD, STEP 7 and CODAC Core System, Refer [RD23]. Page 54 of 90

58 o LabView core application and Eclipse project creation Off-Site Development and Stand-Alone Test (Independently from IO) Page 55 of 90

59 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 If 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. Page 56 of 90

60 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 Plant System FAT Context As explained in section 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 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 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. Page 57 of 90

61 Recommendations about the methodology Refer to the section 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 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 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 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: Page 58 of 90

62 - 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 ) 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 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. Page 59 of 90

63 Recommendations about the FAT scope 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 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 documentation C2. I&C hardware C3. I&C configuration data and software C4. I&C functional requirements 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 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. Page 60 of 90

64 - Requirements (PCDH, IEC 61511, etc.) applicable to the software deliverables are met. 4. C4 campaign: I&C functional requirements The 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 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 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 Recommendations for performing the campaigns 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. Page 61 of 90

65 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 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 Page 62 of 90

66 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. Page 63 of 90

67 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. Page 64 of 90

68 Test Environment: Mini-CIS Mini-CIS Supervision Module [WinCC OA] OPERATOR STATION Mini CIS slow Controller Mini CIS fast Controller Mini CODAC PIS Engineering Workstation PIS SLOW CONTROLLERS AI MC + DMS trigger Diag interchassis AI MC + DMS trigger Diag interchassis AI MC + DMS trigger Diag interchassis PON CIN P MC PIS FAST CONTROLLERS PIS REMOTE IO PLANT INTERLOCK SYSTEM 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 Page 65 of 90

69 Mini-CIS as a CIS substitutional tool Mini-CODAC as a CODAC substitutional tool Plant System Equipment (sensors, actuators, etc.) Substitution Tool 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 Tool If 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 Tool It 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: Page 66 of 90

70 - 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 Architecture The mini-cis hardware architecture is composed of I. A Dual Xeon E5-2418L industrial computer as specified in [RD4], used as main hardware component, with the following network interfaces a. Interface with CIN P network b. Interface with CIN A network II. If required Slow/Fast Controller acting as CIS Protection Modules, with the following network interface a. Interface with CIN P network b. 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 Page 67 of 90

71 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 supplier In 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 Simulators If 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) Page 68 of 90

72 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 C1 campaign: I&C documentation 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 C2 campaign: I&C hardware - 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.) C3 campaign: I&C configuration data and software Page 69 of 90

73 - 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 o o o o Project data (e.g. name, properties, etc.), devices (e.g. type, name, etc.), networks (e.g. type, name, etc.) Network configuration (e.g. connection type, connection ID, etc.) Hardware configuration (e.g. component properties, component name, etc.) Standard program (e.g. data blocks, communication function blocks, etc.) 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 C4 campaign: I&C functional requirements To check the following test from the PIS interface point of view: For Slow Controllers: o CIN Plant System network switches configuration Page 70 of 90

74 o - To check that the CIN Plant System network switches functional requirements are met. 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 o o o o To check the NTP synchronization: NTP synchronization is through the PON. Normally mini-codac will be used for NTP server at supplier premises. 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. 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. 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 To check the functional interface specifications The 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). Page 71 of 90

75 - 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 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 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 o Check the network connectivity of the Host PC to CIN 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 Workstation o Check the PTP synchronization of the Host PC through the TCN o 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. Page 72 of 90

76 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) Compilation of CIS Multiproject is OK? NO Update CIS Multiproject YES Configure Supervision data for WinCC OA CIS Multiproject Ready for SAT Figure 24: First Connection of New PIS with CIS Page 73 of 90