Upload
others
View
44
Download
0
Embed Size (px)
Citation preview
PDF generated on 22 Dec 2017DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
Memorandum / Note
Guidelines for PIS configuration and integrationThis document explains the guidelines to be followed by the plant system designers for the configuration and integration of the PIS. The document is the first version of one of the PCDH Satellite Documents for the interlocks.
Approval Process Name Action AffiliationAuthor Soni J. 21 Dec 2017:signed IO/DG/COO/SCOD/CSD/PCICo-Authors Gaikwad Y.
Pedica R. 21 Dec 2017:signed21 Dec 2017:signed
TATA Consultancy Services France SA...IO/DG/COO/SCOD/CSD/PCI
Reviewers Ciusa G. Fernandez-hernando J. L.Liu Y. Petitpas P. Prieto diaz I.
21 Dec 2017:recommended21 Dec 2017:recommended21 Dec 2017:recommended21 Dec 2017:recommended21 Dec 2017:recommended
IO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/PCI
Approver Wallander A. 22 Dec 2017:approved IO/DG/COO/SCOD/CSDDocument Security: Internal Use
RO: Fernandez-hernando Juan luisRead Access LG: CODAC team, LG: Interlock Gang, AD: ITER, AD: Only-staff, AD: External Collaborators, AD:
IO_Director-General, AD: EMAB, AD: Auditors, AD: ITER Management Assessor, project administrator, RO, AD: OBS - Control System Division (CSD) - EXT, AD: OBS - CODAC Section (CDC) - EXT, AD: OBS - CODAC Sect...
IDM UID
7LELG4VERSION CREATED ON / VERSION / STATUS
21 Dec 2017 / 4.0 / Approved
EXTERNAL REFERENCE / VERSION
PDF generated on 22 Dec 2017DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
Change Log
Guidelines for PIS configuration and integration (7LELG4)
Version Latest Status Issue Date Description of Change
v0.0 In Work 06 Nov 2012
v1.0 Approved 24 Jan 2013 Version for PCDH v7v2.0 Approved 18 Dec 2014 Added naming convention, software and hardware configuration, integration
and management strategy.v3.0 Approved 25 Apr 2016 More detailed information added to the guideline:
PIS Naming convention (Software/ Hardware / Variables) Slow Architecture (Siemens tools / Single CPU configuration / Fully fault tolerant configuration) - Software/ Program Structure - PLC Core application - Safety related interface with CIS - CIS Supervision interface (WinCC OA) - Interface with CODAC Integration and Management
The attached PLC Software Template provides: Software Settings for - Organization Block (i.e. Interrupt Timings; PIP) - FB/FC/DB/SFB/SFC (Numbering, Naming etc.) - Continuous Function Charts (i.e. Compilation, Downloading) - Memory Bits, Clocks, Timers, Counters. Standard Blocks for - Health Monitoring System - Time Stamp Push Protocol (TSPP Protocol) - Operator Integrity Commands (Three Step Overrides Verification) - Communication on TCP/IP (S7 Protocol) - Communication for Fault Tolerant Systems - Voter Logic - Threshold Logic Hardware Settings for -CPU (i.e. Max scan cycle, IO Process, Clock) -Input / Output Card (Numbering, Redundancy etc.) -Channel Level (i.e. Safety Parameters) -Network Configuration Runtime Group Organization for -Standard Program -Safety Program
v4.0 Approved 21 Dec 2017 The document has following major updates:
The scope of this PCDH document is to provide the guidelines to be followed by the plant system I&C suppliers and plant system I & C RO , for the configuration and integration of Slow/ Fast PIS . The older version document’s write up was mainly about the Slow PIS PLC software development which is mainly useful for the Slow PIS software developer and further, most of contains are already part of another document that is PIS PLC template (SDTX28) .
Hence considering the scope the document and readers, it was completely rewritten.
In the document main focus is given on concepts and recommendations for
PDF generated on 22 Dec 2017DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM
configuration and integration of (Slow/Fast)PIS .
Following major topics are added/ updated in the document :
(1) Naming convention for Fast PIS (2) Configuration of Slow PIS - Hardware configuration - Software architectures and programing concepts (3) Configuration of Fast PIS - Hardware configuration - Software architectures and programing concepts (4) Management of PIS software
(5) Integration of slow and fast PIS - Recommendations for FAT - Recommendations for SAT
Guidelines for PIS Configuration and Integration (ITER_D_7LELG4)
Page 1 of 90
Table of Contents
1. Introduction ...................................................................................................................51.1 PCDH Context...........................................................................................................................................5
1.2 Document Scope ........................................................................................................................................5
1.3 Applicable Standards [AS].......................................................................................................................6
1.4 Related Documents [RD] ..........................................................................................................................6
1.5 Abbreviations and Acronyms ..................................................................................................................8
1.6 Definitions ..................................................................................................................................................9
1.7 Considerations.........................................................................................................................................10
1.8 Assumptions.............................................................................................................................................10
2. Principles......................................................................................................................112.1 Introduction.............................................................................................................................................11
2.2 Terminology.............................................................................................................................................12
3. Naming Convention for PIS .......................................................................................153.1 Naming convention for slow PIS............................................................................................................15
3.2 Naming convention for Fast PIS............................................................................................................15
3.2.1. Project and Hardware naming convention ..........................................................................................16
3.2.2. Variable naming convention.................................................................................................................17
4. Configuration of Slow PIS..........................................................................................234.1 Hardware configuration .........................................................................................................................23
4.2 Software Architecture and Programing concepts................................................................................24
4.2.1. Local interlock function implementation in Slow PIS ..........................................................................25
4.2.2. Part of Central interlock function implementation in slow PIS ...........................................................26
4.2.3. Concept of Override and Threshold value section ...............................................................................28
4.2.4. Concept of Reset ...................................................................................................................................33
4.2.5. Concept of Reintegration ......................................................................................................................34
4.2.6. Concept of Critical health monitoring..................................................................................................36
4.2.7. Concept of archiving and status Monitoring ........................................................................................38
4.2.8. Concept of conventional health monitoring and CODAC interface.....................................................40
5. Configuration of Fast PIS...........................................................................................42
Guidelines for PIS Configuration and Integration (ITER_D_7LELG4)
Page 2 of 90
5.1 Hardware configuration .........................................................................................................................42
5.1.1. Hardware Configuration using Fast PIS Template..............................................................................42
5.1.2. Hardware Configuration for New project ............................................................................................45
5.2 Software architecture and Programming concepts .............................................................................46
5.2.1. Concept of archiving and status Monitoring ........................................................................................50
6. Management of PIS software .....................................................................................526.1 Version Control .......................................................................................................................................52
6.2 Repository Management.........................................................................................................................53
6.3 Development Process ..............................................................................................................................53
6.3.1. Scope areas for PIS Software development ..........................................................................................54
6.3.2. Off-Site Development and Stand-Alone Test (Independently from IO) ................................................55
7. Integration ...................................................................................................................577.1 Recommendation for FAT of PIS ..........................................................................................................57
7.1.1. Plant System FAT Context ....................................................................................................................57
7.1.2. PIS FAT Objective ................................................................................................................................57
7.1.3. Recommendations about the methodology ...........................................................................................58
7.1.4. Recommendations about the FAT scope...............................................................................................60
7.1.5. Recommendations for performing the campaigns ................................................................................61
7.1.6. Recommendations for checking the interfaces .....................................................................................69
7.2 Multiproject Integration Procedure......................................................................................................72
7.2.1. First Connection of a New PIS (one or several PLCs) to the CIS........................................................73
7.2.2. Update of a PIS configuration..............................................................................................................74
7.3 Recommendation for SAT of PIS ..........................................................................................................78
7.3.1. On-Site Integration Context..................................................................................................................78
7.3.2. Plant System SAT Context ....................................................................................................................78
7.3.3. Recommendations / Requirements about the methodology ..................................................................79
7.3.4. Recommendations for on-site integration activities .............................................................................80
Guidelines for PIS Configuration and Integration (ITER_D_7LELG4)
Page 3 of 90
List of FiguresFigure 1: PCDH Documents Structure.....................................................................................................................5Figure 2: PIS Conceptual Software Architecture...................................................................................................24Figure 3: Typical slow local interlock protection function schema .......................................................................25Figure 4: Typical Event generation schema for central interlock function............................................................26Figure 5: Typical Action generation schema for central interlock function ..........................................................27Figure 6: Concept of Overrides..............................................................................................................................29Figure 7: Concept of threshold selection using HIOC protocol.............................................................................32Figure 8: Concept of RESET .................................................................................................................................34Figure 9: Concept of Reintegration........................................................................................................................36Figure 10: Concept of Critical health monitoring ..................................................................................................37Figure 11: Concept of archiving and status monitoring.........................................................................................39Figure 12: Conventional Health monitoring and CODAC.....................................................................................41Figure 13: Application of the naming convention .................................................................................................43Figure 14: Protection function’s number choice ....................................................................................................44Figure 15: Versioning of the bitfile........................................................................................................................44Figure 16: C API generator ....................................................................................................................................45Figure 17 : Fast PIS software architecture .............................................................................................................47Figure 18: FPGA Core application.........................................................................................................................48Figure 19: Status word structure ............................................................................................................................51Figure 20: Development Process Work Flow for slow PIS Applications..............................................................53Figure 21: Development Process Work Flow for Fast PIS Applications..............................................................54Figure 22: Off-Site Development...........................................................................................................................55Figure 23: Example of typical PIS FAT Test Environment...................................................................................65Figure 24: First Connection of New PIS with CIS.................................................................................................73Figure 25: Update PIS Configuration without affecting central functions ............................................................76Figure 26: Update of PIS affecting Central Functions...........................................................................................77Figure 27: Steps involved in onsite Integration .....................................................................................................80Figure 28: Steps involved in C4 Campaign ...........................................................................................................85
Guidelines for PIS Configuration and Integration (ITER_D_7LELG4)
Page 4 of 90
List of TablesTable 1: Abbreviations and Acronyms.........................................................................................................8Table 2: Fast PIS Hardware naming convention .........................................................................................16Table 3: Fast PIS variable naming convention ............................................................................................17Table 4 : Override type and associated signals naming convention ...............................................................30Table 5: Critical Health Monitoring Signal ................................................................................................37Table 6: Approved cRIO modules .............................................................................................................45Table 7: Status word data .........................................................................................................................50
Page 5 of 90
1. Introduction
1.1 PCDH Context
Standards, specifications and methodology as defined in [RD1] Plant Control Design Handbook (PCDH) (ITER_D_27LH2V) Plant Control Design Handbook (PCDH) (ITER_D_27LH2V)_Related Documents_[RD] and interfaces applicable to the whole life cycle of International Thermonuclear Experimental Reactor (ITER) plant system Instrumentation & Control (I&C) systems. I&C standards are essential for ITER to:1. Integrate all plant systems I&C into one Integrated Control System (ICS). 2. Maintain all plant systems I&C after delivery acceptance.3. Contain cost by economy of scale.PCDH comprises a of core document, which presents the plant system I&C life cycle and recaps the main rules to be applied to the plant system I&Cs for conventional controls, interlocks and safety controls. Some I&C topics are explained in detail in dedicated documents associated with PCDH as presented in Figure 1: PCDH Documents Structure. This document is one of them.
Core PCDH (27LH2V)Plant system control philosophyPlant system control Life CyclePlant system control specificationsCODAC interface specificationsInterlock I&C specificationSafety I&C specification
PCDH core and satellite documents: v7PS CONTROL DESIGN
Plant system I&C architecture (32GEBH)
Methodology for PS I&C specifications (353AZY)
CODAC Core System Overview (34SDZ5)INTERLOCK CONTROLS
Guidelines PIS design (3PZ2D2)
Guidelines for PIS integration & config. (7LELG4)
Management of local interlock functions (75ZVTY)
PIS Operation and Maintenance (7L9QXR)
I&C CONVENTIONSI&C Signal and variable naming (2UT8SH)
ITER CODAC Glossary (34QECT)
ITER CODAC Acronym list (2LT73V)
PS SELF DESCRIPTION DATASelf description schema documentation (34QXCP)
CATALOGUES for PS CONTROLSlow controllers products (333J63)
Fast controller products (345X28)
Cubicle products (35LXVZ)
Integration kit for PS I&C (C8X9AE)
PS CONTROL INTEGRATIONThe CODAC -PS Interface (34V362)
PS I&C integration plan (3VVU9W)
ITER alarm system management (3WCD7T)
ITER operator user interface (3XLESZ)
Guidelines for PON archiving (87N2B7)
PS Operating State management (AC2P4J)
Guidelines for Diagnostic data structure (354SJ3)PS CONTROL DEVELOPMENT
I&C signal interface (3299VT)
PLC software engineering handbook (3QPL4H)
Guidelines for fast controllers (333K4C)
CODAC software development environment (2NRS2K)
Guidelines for I&C cubicle configurations (4H5DW6)
CWS case study specifications (35W299)
NUCLEAR PCDH (2YNEFU)
OCCUPATIONAL SAFETY CONTROLSGuidelines for PSS design
Available and approvedExpected
Legend
This document
(XXXXXX) IDM ref.
Guidelines for PIS integration & config. (7LELG4)
Figure 1: PCDH Documents Structure
1.2 Document Scope
This document provides the guidelines to be followed by the plant system I&C suppliers for the configuration and integration of the part of the plant system I&C, which implements the investment protection functions and interfaces with the Central Interlock System (CIS).This document does not provide the guidelines for the design of the plant system I&C, which implements the investment protection functions and interfaces with the CIS.
Page 6 of 90
These are described in [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2).
1.3 Applicable Standards [AS]
[AS1]. IEC 61508 Functional safety of electrical/electronic/programmable electronic safety- related systems
[AS2]. IEC 61511 Functional safety – Safety instrumented systems for the process industry sector
1.4 Related Documents [RD]
[RD1]. Plant Control Design Handbook (PCDH) (ITER_D_27LH2V)[RD2]. Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2) [RD3]. Management of Local Interlock Functions (ITER_D_75ZVTY)[RD4]. PIS Operation and Maintenance (ITER_D_7L9QXR) [RD5]. Central Interlock System (PBS-46) - Design Description Document (DDD)
(QCH3GJ v2.2) [RD6]. Catalogue for I&C products – Slow controllers (ITER_D_333J63)[RD7]. PLC Software Engineering Handbook (ITER_D_3QPL4H)[RD8]. Interlock Control System – Overall Quality Plant (ITER_D_75GBSW)[RD9]. Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH)[RD10]. Plant System I&C Integration Plan (ITER_D_3VVU9W)[RD11]. ITER Operator User Interface (ITER_D_3XLESZ)[RD12]. ITER Alarm System Management (ITER_D_3WCD7T)[RD13]. Guidelines for PON Archiving (ITER_D_B7N2B7)[RD14]. ITER CODAC Subversion Guideline (ITER_D_A2GSXB)[RD15]. Core System Application Developer Manual (ITER_D_33T8LW)
[RD16]. CIS_V.0_WinCC_OA_Configuration_and_interfacing_with_PLC (ITER_D_PHK5CJ)
[RD17]. Implementation of High Integrity Operator Commands in the Interlock Control System (ITER_D_PKMDA8)
[RD18]. Standard PLC Software Structure (SPSS) User Manual (ITER_D_G4UMX5)[RD19]. ITER Control Breakdown Structure_ (CBS) (ITER_D_9TYFWC). [RD20]. CODAC Core System Overview (ITER_D_97W6Q9).[RD21]. CODAC Core System Installation Manual (ITER_D_33JNKW)[RD22]. Self-description data editor - User manual (ITER_D_32Z4W2)[RD23]. Standard PLC Template for Interlock Applications_ITER_D_SDTX28
Page 7 of 90
[RD24]. IEC 61508 Functional safety of electrical/electronic/programmable electronic safety related systems.
[RD25]. SIEMENS Manual: SIMATIC Industrial Software S7 F/FH Systems Configuring and Programming
[RD26]. "Fast PIS- WinCC OA Interface Module” User Manual (ITER D SVL3N9 )[RD27]. Review guidelines for Interlock Systems (PMUS5G v1.0)[RD28]. ITER On-Site Testing Strategy (ITER_D_44U2Y4)
Page 8 of 90
1.5 Abbreviations and Acronyms
The following table shows the abbreviations and acronyms used in this document. The relevant abbreviations or acronyms have been extracted from the complete list in PCDH.
Table 1: Abbreviations and Acronyms
Abbreviation or Acronym Expansion
CIN Central Interlock Network
CIS Central Interlock System
CP Communication Processor
CPU Central Processing Unit
CODAC Control, Data Access and Communication
EPICS Experimental Physics and Industrial Control System
ES Engineering Station
FH Fault Tolerant (Specifically used for Siemens System)
GOS Global Operating State
HIOC High Integrity Operator Commands
HMI Human Machine Interface
I&C Instrumentation & Control
ICS Interlock Control System
I/O Input / Output
IO ITER Organization
IOC Input Output Controller
PBS Plant Breakdown System
PCDH Plant Control Design Handbook
PIN Plant Interlock Network
Page 9 of 90
Abbreviation or Acronym Expansion
PIS Plant Interlock System
PLC Programmable Logic Controller
PON Plant Operation Network
PS Power Supply
PSCC Plant System Conventional Control
PSH Plant System Host
PSS-OS Plant Safety System- Occupational safety
PVN Private Network Identifier
SCADA Supervisory Control and Data Acquisition
WinCC OA Windows Control Center Open Architecture
1.6 Definitions
I/O ModuleBoard installed close to the Central Processing Unit (CPU) or connected to the CPU remotely in order to report/transmit signals from/to the field
Local NetworkCommunication network is considered as a Local Network when communication between Local racks, Remote racks from CPU or Communication Processor (CP) over network bus.
Central Network
Communication network is considered as a Central Network when central system communicating with rest of system / sub system over network bus. e.g. Control, Data Access and Communication (CODAC), Interlock, Occupational Safety
FBProfibus (any Field Bus) communication from controller (from PIS/CIS to remote I/O) is termed as FB in slow PIS PLC naming convention.
FNProfinet (any Field Net) communication from controller (from PIS/CIS to remote I/O) is termed as FN in slow PIS PLC naming convention.
Page 10 of 90
1.7 Considerations
As explained in the [RD3] Management of Local Interlock Functions (ITER_D_75ZVTY) document, safety is a term that should not be used when describing the interlock system. Nevertheless, this term will be used in the expression ‘safety-related’ as opposed to normal or standard. Moreover, as the Siemens PLC are divided into two parts (standard and safety), this term will also be used in the expressions ‘safety program’ and ‘safety data’ to distinguish the safety part of the interlock systems.
As explained in [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2), critical interlock data is used for performing the machine protection functions while the non-critical interlock data does not directly participate in the interlock functions (that is, reset, analog values etc.).
WinCC Open Architecture (WinCC OA) is the Supervisory Control and Data Acquisition (SCADA) solution selected for the Central Interlock Network (CIS). It is completely in the scope of PBS-46 (Central Interlock System). The developers of the PIS will follow the rules explained in the current document but no additional configuration will be required from the plant system developer. Justification on the selection of this solution can be found in ITER_D_ATSJJN Study of human Factors applied to the operation of the ITER interlocks.
1.8 Assumptions
The reader is well-versed with the conventions and standards [RD1] Plant Control Design Handbook (PCDH) (ITER_D_27LH2V) and [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2)
The reader is well-versed with the Plant System Instrumentation & Control (I&C) architecture and [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W)
The reader is well-versed with CODAC Core System overview [RD21] CODAC Core System Overview (ITER_D_97W6Q9).
Page 11 of 90
2. Principles
2.1 Introduction
The plant systems are the main parts of the ITER facility and will be delivered by the project members with their own control systems (Plant System I&Cs). The plant interlock systems are a part of plant system I&Cs, which implement the investment protection functions.As described in [RD2] Guidelines for the Design of the Plant Interlock System (PIS) (ITER_D_3PZ2D2) the plant interlock systems comprise two architectural types:
1. Slow PIS architecture based on PLCs2. Fast PIS architecture based on fast controllers
- It is important to standardize the configuration of the plant interlock systems in order to facilitate their integration, commissioning and maintenance. Due to the different technologies used in each architecture, different tools are needed to develop the software of each of them. However, the software structure and concepts will be kept the same as far as possible.
- As is explained in reference [RD4] PIS Operation and Maintenance (ITER_D_7L9QXR) , Operations on interlocks are allowed from both the CIS and the CODAC infrastructure. The standardization of the treatment of interlock data (that is, monitoring, logging and so on) at the CIS level is provided by PBS-46 (Central Interlock System) and at CODAC level is provided by each plant system. In order to achieve this, some guidelines in addition to the general CODAC guidelines have to be followed during the configuration of the CODAC interface.
- At the installation phase, each plant system is incorporated in ITER in one main step but the installation schedule of the plant systems covers many years. Therefore, some PIS involved in central interlock functions will be available years after others involved in the same central interlock functions. This requires specific means to minimize errors and the time taken during the integration and commissioning of the various PIS.
- As detailed in the Interlock Control System (ICS) Overall Quality Plan [RD8] Interlock Control System – Overall Quality Plant (ITER_D_75GBSW), the plant system reviews process must take into account and meet the requirements of IEC 61508 as far as possible. The system lifecycle will be clearly documented in order to facilitate future verification and modifications by ITER Organization
- For uniform development, seamless integration and easy maintenance of PIS, it is strongly recommended to follow the guidelines mentioned in this document during the configuration and integration of the PIS.
This document is mainly focused on the configuration and integration of two possible PIS architecture. First part is focused on the configuration of Slow and Fast PIS; and second part provides the guidelines for PIS FAT and SAT.
Page 12 of 90
2.2 Terminology
Central Interlock System (CIS) The Central Interlock System (CIS) together with CODAC and the Central Safety System (CSS), forms the ITER I&C Central Systems. The CIS is in charge of implementing the central protection functions via the Plant Interlock Systems (PIS) and, if required, some direct actuators. It also provides access to the local interlock data of the different plant Interlock Systems.
Plant Interlock Systems (PIS)The Plant Interlock Systems (PIS) are part of the plant systems I&C. Each PIS provides local protection by implementing the local interlock functions of the corresponding plant system. Also, most of the PIS participate in the central interlock functions coordinated by the CIS. All the sensors and actuators involved in machine protection in ITER are connected to at least one PIS in their plant system. The PIS constitutes the interface between the CIS and the plant systems.Only plant systems I&C participating in inter-plant interlocks or implementing local investment protection functions are integrated in the Interlock Control System (ICS) architecture.
Central Interlock Network (CIN)The Central Interlock Network (CIN) provides communication between the Plant Interlock Systems and the Central Interlock System for inter-plant systems investment protection functions. Only plant system’s I&C participating in inter-plant system investment protection functions, or performing local investment protection functions, are connected to the CIS via CIN.
Plant Interlock Network (PIN)The Plant Interlock Network (PIN) provides communication between the controllers involved in the investment protection functions inside same plant system over a network bus. For the plant systems with more than one PIS, the PIN will be used to inter connect them. The PIN in one Plant System shall not be shared with other Plant Systems.
Interlock Control System (ICS)The Interlock Control System (ICS) is in charge of the supervision and control of all the ITER components involved in the instrumented protection of the ITER plant systems. It comprises the Central Interlock System (CIS), the different Plant Interlock Systems (PIS) and its networks (CIN and PIN). The ICS does not include the sensors and actuators of the plant systems but controls them through PIS.
Page 13 of 90
Interlock EventThis is the plant system state or combination of states involving different plant systems that triggers an action of the corresponding PIS and/or the CIS.
Interlock Action These are measures or sequences of measures carried out by the CIS and/or the PIS to mitigate the risks following an interlock event. These protection actions are managed by the PIS when the measures are restricted to the plant system that generated the interlock event and by the CIS when different plant systems are involved.
Interlock FunctionThis is the logical description of the interlock actions following an interlock event. These functions are classified into two categories as explained in [RD2] , that is local interlock function and central interlock function.
Critical Interlock DataThere are interlock signals performing the machine protection functions transmitted via the CIN and PIN. They are divided into:
o Critical Automatic Data:
Data that is exchanged between CIS modules and PIS modules and is directly involved in the central interlock functions (events, actions) is called critical automatic data. This data is generated from logical / functional behaviour in controllers.
Following are the examples of critical automatic data:
- Interlock events (Boolean). Example: wrong plasma current.- Interlock actions (Boolean). Example: Disruption Mitigation System trigger.
o Critical Manual Data:-
- Data that is exchanged between CIS modules and PIS modules and directly involves manual actions/ triggering is called critical manual data. This data is generated from supervisory module and is transferred to controllers for performing further logic.
Critical manual data includes:
Override Interlock Configuration Data (Threshold Values etc.)
E.g. Manual operation commands. Example: Overrides.
Page 14 of 90
Non-Critical Interlock DataInformation treated by the PIS and the CIS which, although needed, does not directly participate in the interlock function. For instance, the reset (unlatch) of interlock functions, actuators and sensors, or the analog values of the temperature, pressure etc.For example, in case of cryogenics, temperature values are used to decide whether the magnets can be powered or not, these values are used in PIS to generate the interlock event. However, only the interlock event (critical data) signal is routed to the CIS via the CIN while the temperature values (non-critical data) are sent to CODAC via the PON network.
Page 15 of 90
3. Naming Convention for PIS
Naming convention of PIS is divided in mainly two parts according to architecture type:
3.1 Naming convention for slow PIS
In case of slow PIS, naming convention recommendation covers the following:
1) Project and Hardware naming convention in Step7 2) Block naming and numbering convention in Step 7 3) Variable naming convention
For more detail about the slow PIS naming convention please refer to [RD23].
3.2 Naming convention for Fast PIS
In case of fast PIS, naming convention is mainly recommended for the following: 1. Project and Hardware naming convention2. Variable naming convention
Page 16 of 90
3.2.1. Project and Hardware naming convention
Following Table 2 depicts Fast PIS Project and Hardware naming convention
Table 2: Fast PIS Hardware naming convention
Item Proposed Naming Convention Significance and Example
AAAA This signifies the CBS level 1 of the Controller.
BBBB This signifies the CBS level 2 of the Controller.
CCCCCParticularly CCCCC must make the difference between projects that will coexist in the same Plant System
Project Name AAAA_BBBB_CCCCC
Example CRYO_CA_ICU01PPPPPP Plant Breakdown Structure (PBS) IdentifierTTT Component functional category designator
NNNN Sequential number. It is also indicating the domain of the component.
Chassis/Host PC Name PPPPPP_TTT_NNNN
Example 460100_PFC _4000
Chassis ID Chassis ID where signal module is installed CR1 or CR2
Signal Module Identifier
Sequential number of Signal module with suffix of SM The slot position must match with the Signal module Identifier number
Type of Module Identifier Analog or Digital Input/output type.
CR1_SM01_DI
Input/Output Modules
Chassis ID_Signal module identifier _Type of Module identifier
Example CR2_SM03_AO
Page 17 of 90
3.2.2. Variable naming convention
Following Table 3 depicts Fast PIS Variable naming convention :
Table 3: Fast PIS variable naming convention
Significance and ExampleItem
target Proposed Naming Convention
KKK Chassis indicator, it indicates the Chassis where
the variable is generated.|CH1 Chassis 1 |CH2 Chassis 2
TTTNNNN_AAAA [RRRR]
The Variable identifier part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH).CR1_MT0001_TT0001
Labview Variable
KKK_TTTNNNN_AAAA[RRRR]
ExampleCR2_MT0001_TT0001
FFFF-FFFF-FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH).
KKK Indicator of the Chassis that receive the signals CH1 or CH2
TTTNNNN_AAAA[RRRR]
This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). MAG-MATF-INTF:CR1_ MT0001_TT
Var
iabl
es L
inke
d to
Sig
nal
CODAC PV FFFF-FFFF-FFFF:KKK_TTTNNNN_AAAA[RRRR]
Example MAG-MATF-INTF:CR2_ MT0001_TT
Page 18 of 90
FFFF_FFFF_FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH).
KKK Indicator of the Chassis that receive the signals CR1 or CR2
TTTNNNN_AAAA[RRRR]
This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). MAG_MATF_INTF_CR1_ MT0001_TT
WinCC OA Datapoint
FFFF_FFFF_FFFF_KKK_TTTNNNN_AAAA[RRRR]
Example
MAG_MATF_INTF_CR2_ MT0001_TTKKK Chassis indicator, it indicates the Chassis where
the variable is generated.CR1 Chassis 1 CR2 Chassis 2
VVVVVVVVV Free textual description used to explain the function of the variable.
Var
iabl
es C
ompu
ted
by
the
PIS
Labview Variable
KKKK_VVVVVVVVV_GGGH[RR]
GGG Maximum Three Character is the identifier of the variable. § MSK Mask§ THR Threshold§ FRC Force § CRT Critical § RAW Raw data § STS Status§ ACK Acknowledge
Page 19 of 90
H One character field used as optional attribute in case of Mask, Threshold and Force Variables.§ P Pulse § L Level § C Command§ S Status § R Reset
[RR] Sequential Number if required to discriminate signal with the same name CR1_CRYOOK_MSKP01Example CR2_CRYOOK_MSKP01
FFFF_FFFF_FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). With reference to the Control function identifier and Variable Identifier
KKK Chassis indicator , it indicates the Chassis where the variable is generated.CR1 Chassis 1 CR2 Chassis 2
VVVVVVVVV Suggested length nine characters the free textual description used to explain the function of the variable.
CODAC PV FFFF-FFFF-FFFF:KKK_VVVVVVVVV_GGGH[RR]
GGG Maximum Three Character is the identifier of the variable. § MSK Mask§ THR Threshold§ FRC Force § CRT Critical § RAW Raw data § STS Status
Page 20 of 90
§ 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
[RR] Sequential Number if required to discriminate signal with same name CRYO-CA-LIN1:CR1_CRYOOK_MSKP01Example CRYO-CA-LIN1:CR2_CRYOOK_MSKP01
FFFF_FFFF_FFFF This part shall be generated following the CODAC naming convention. [RD9] Signal and PS I&C Variable Naming Convention (ITER_D_2UT8SH). With reference to the Control function identifier and Variable Identifier
KKK Chassis indicator, it indicates the Chassis where the variable is generated.CR1 Chassis 1 CR2 Chassis 2
WinCC OA Datapoint
FFFF_FFFF_FFFF_KKK_VVVVVVVVV_GGGH[RR]
VVVVVVVVV Suggested length nine characters the free textual description used to explain the function of the variable.
Page 21 of 90
GGG Maximum Three Character is the identifier of the variable. § MSK Mask§ THR Threshold§ FRC Force § CRT Critical § RAW Raw data § STS Status§ ACK Acknowledge
H One character field used as optional attribute in case of Mask, Threshold and Force Variables.§ P Pulse § L Level § C Command§ S Status § R Reset
[RR] Sequential Number if required to discriminate signal with same name CRYO_CA_LIN1_CR1_CRYOOK_MSKP01Example
CRYO_CA_LIN1_CR1_CRYOOK_MSKP01TTTNNNN Component name following the CODAC
Naming ConventionHPC_COM Communication with Host PC statusCR_COM Communication with Partner Chassis StatusSM[N] Health Status of the ModuleN DSP_V[N] Discrepancy status of voter N
HltStatusVAr
ERR_F[N] FPGA error staus of Function N PCF1501_HPC_COMC
ritic
al H
ealth
Mon
itori
ng
Var
iabl
es
Labview Variables
TTTNNNN_HltStatusVAr
Example PCF1501_CR_COM
Page 22 of 90
PCF1501_SM1PCF1501_DSP_V1PCF1501_ERR_F1
FFFF CBS level 1 following CODAC conventionFFFF CBS level 2 following CODAC conventionFFFF fixed code ‘SYSM’ dedicated to system
monitoringHPC_COM Communication with Host PC statusCR_COM Communication with Partner Chassis StatusSM[N] Health Status of the ModuleN DSP_V[N] Discrepancy status of voter N
HltStatusVAr
ERR_F[N] FPGA error status of Function N MAG_PFCS_SYSM_PCF1501_HPC_COM
MAG_PFCS_SYSM_PCF1501_CR_COMMAG_PFCS_SYSM_PCF1501_SM1MAG_PFCS_SYSM_PCF1501_DSP_V1
WinCC OA Datapoint
FFFF_FFFF_FFFF_ TTTNNNN_HltStatusVar
Example
MAG_PFCS_SYSM_PCF1501_ERR_F1
Page 23 of 90
4. Configuration of Slow PIS
For standardising the slow PIS hardware configuration and software architecture throughout all the suppliers and help the PIS developers, the PBS 46 (CIS) team has developed the PIS PLC template. The PIS PLC templet is a pre-configured and ready to use PLC project. The main features of the PIS PLC template are:
- Two Generic templates for Standalone and Fully fault tolerant PIS configuration development.
- Pre-configuration of all the recommended hardware setting and network interfaces
- Generic naming of hardware components, functions and charts. Hence, easy to customised for any PIS.
- Modular software architecture
- Contain customised library : PIS_LIB, which have specially developed and tested safety function blocks and charts for its use in the PIS application
- Ready to use CFC charts and DB’s for implementation of CIS interface, CODAC interface, critical health monitoring, overrides etc.
The PIS PLC application is supported by the document [RD23]. The main features of the document are:
- Slow PIS project workflow mentioned in template for systematic and consistent development
- Well defined guidelines on ‘how to manage safety and standard PLC programming and communication’
- Optimum performance can be achieved through programing rules and f-runtime group rules described in template
For complete step by step guidelines of how to use PIS PLC template and configure the slow PIS, please refer [RD23]. Below sections only provides the overview on hardware configuration and software programing using the PIS PLC templates.
4.1 Hardware configuration
Recommendations of the hardware configuration are mainly focused on the recommended settings for the PIS PLC hardware configuration in Step 7. The recommendations are required to maintain the uniform PIS hardware configuration throughout the ITER project and seamless integration of PIS with CIS and CODAC. Please refer the [RD24] Standard PLC Template for Interlock Applications_ITER_D_SDTX28, for complete step by step guidelines for hardware configuration using the PIS PLC template.
Page 24 of 90
4.2 Software Architecture and Programing concepts
The recommended PIS software architecture is shown in Figure 2, it is strongly recommended to use the PIS PLC template project. In order to simplify the program organization, maintenance, debugging and commissioning, the architecture is structured in blocks/modules. The S7 program in the CPU module consists of fail-safe components (safety program) and non-fail-safe components (standard program).The blocks/modules directly involved in interlock functions (safety-related communications and logic) are in the PLC safety program whereas the other blocks/modules (standard communication or monitoring) can be in the standard program. Data exchanged between the user safety program and the user standard program in the F-CPU can be done using special F-Blocks for data conversion.The PLC safety program will consist of fail-safe blocks selected from an F-Library, interconnected using the CFC programming language. During the compilation, fault control measures are automatically added to the safety program and additional safety-related tests are performed.The PIS standard programs should be configured using the graphical languages of STEP-7 (CFC, LAD or FBD if necessary), SCL Language can be used in Standard program, whereas in safety program SCL Language shall be avoided. Usage of pointers is totally forbidden.
Figure 2: PIS Conceptual Software Architecture
Page 25 of 90
4.2.1. Local interlock function implementation in Slow PIS
Local interlock function is a machine’s protection function, where the interlock event and the interlock action(s) occur in the same plant system. The CIS does not play an active role in the protection function and it shall be only informed on the change of state of the plant system. Typical schema of implementation of the local interlock function in slow PIS is shown in Figure 3. Main steps of the local interlock functions implementation are:1) Reading the input through channel driver to detect the event 2) Apply voter logic (include channel diagnostic, if needed) to confirm the event 3) Apply Mask logic, if event is overridable 4) Apply the functional logic to generate the mitigation action command 5) Apply function disable logic, if function is overridable6) Apply Force logic if action is overridable 7) Apply the reset logic to latch/unlatch the action command8) Send the action output to the single/multiple output port (based on output voter logic)
through channel driver
Ready to Reset
Ready to Reset
Notification*
Voter Result
Event Masking
Command
Condition 1Condition 2 Condition 3
Event Protective Action
Function Reset
Event Masked
Notification
Input1Input2Input3
Action Forcing
Command
Action Forcing
Notification
SR
Function/action Activation Notification
Function Reset*
Function Disable
Function Disable
Notification
Voter Logic Solver
Local Function
Logic Action
* TO/FROM CODAC
2oo3
Figure 3: Typical slow local interlock protection function schema
Page 26 of 90
4.2.2. Part of Central interlock function implementation in slow PIS
The central interlock function is a machine’s protection function involving two or more plant systems. The interlock events are generated by the slow PIS and transmitted via the CIN to the CIS protection modules, which takes an interlock decision and dispatches the required interlock actions to the slow PIS of the other plant systems involved. Typical schema of PIS implementation of event and action, as part of a central interlock function, is shown in Figure 4 and Figure 5.
Condition 1Condition 2
EVENT
Ready to Reset
Ready to Reset
Notification*
Voter Results
Event Masking
Event
Event Reset
Event Masked Notification
Event Reset *
Input1Input2Input3
SR
TO CIS
EVENT
Condition 1Condition 2 Condition 3
2oo3
* TO/FROM CODAC
Voter Logic Solver
Figure 4: Typical Event generation schema for central interlock function
Page 27 of 90
ACTION
Action Forcing
Protective Action
command
SR
Action ActivatedNotification
Ready to Reset
Ready to Reset
Notification* Condition 1Condition 2 Condition 3
Function Reset* Function Reset Notification
Action ForcedNotification
FROM CIS
* TO/FROM CODAC
Figure 5: Typical Action generation schema for central interlock function
Function of Event detecting PIS: 1) Reading the input through channel driver to detect the event 2) Apply voter logic (include channel diagnostic, if needed) to confirm the event 3) Apply Mask logic, if event is overridable 4) Apply the reset logic to latch/unlatch the event 5) Send Event to the CIS Module through fail safe communication
Page 28 of 90
Coordination Function of CIS : 1) Based on event, the CIS takes an interlock decision and dispatches required interlock
actions to the slow PIS of different plant system through fail safe communication
Function of Action performing PIS: 1) Receive the action command from the CIS 2) Apply the Force Logic , if action is overridable 3) Apply the reset logic to latch/unlatch the action commands4) Send the action command to the single/multiple output port (based on output voter logic)
through channel driver
4.2.3. Concept of Override and Threshold value section
4.2.3.1. Concept of Override
Interlock functions are put in place to protect ITER from incorrect operation and other hazards. Therefore masking an interlock event, disabling an interlock function or forcing an interlock action should be avoided as much as possible. However, in some situations during commissioning and maintenance, it is necessary to operate certain systems outside their nominal conditions through application of override. These critical operator actions are only available from the CIS Desk, and only can be performed after the convenient administrative procedures have been correctly completed.
The main aspects of override implementation in slow PIS are as follows:
Override operation shall not be performed from the plant system or CODAC conventional screens. Operation shall be performed from the CIS operation desk.
These critical operations that present a potential hazard must be managed in a way that the operator is aware at all times of the operation execution.
It provides a method for assuring that the command sent from the operator has been correctly received and executed in the controller.
Override signals must send through communication bus that comply with the safety standards IEC 61508, IEC 61784-3 and IEC 61783-3 OR ensure that safety-bus frame must be passed completely unmodified from a safety sender to a safety receiver
Page 29 of 90
In ITER interlock system, s7 communication between PIS PLC and WinCC OA SCADA does not ensure the send/receive of unmodified bus frame. To comply with above requirements and implement override from WinCC-OA, the CIS team has developed High Integrity Operator command (HIOC) protocol. The HIOC protocol has three step validation processes which ensure the integrity of the transmitted message over S7 communication. The HIOC protocol and the concept of three step validation procedure are discussed in detail in [RD17].
The implementation of an override shall be configured using the PIS PLC template chart: "HIOC_BO” which includes two ready to use HIOC implementation blocks, whichare available on the PIS library “PIS_LIB”.
o Standard block: HIOC_STD ( S_OC_BO )o Safety block: HIOC_SFT ( F_OC_BO)
The standard program block (HIOC_STD) is in chargeof the SCADA communication whereas safety program block (HIOC_SFT) is checking the signal integrity.
Step by step procedure for Implementation of override in slow PIS along with ready to use HIOC blocks and charts are given in PIS PLC template [RD23]. The below section only provides the overview of the implementation of overrides through HIOC protocol.
A typical override implementation schema using PIS_LIB blocks is show in Figure 6.
Request ID, Command ID, Confirmation ID
SLOW PIS PLC
Data Conversion between Safety and Standard
HIOC_STD
FB 1023:S_OC_BO FB 1024: F_OC_BO
Critical signal BeforeOverride (XX-CRT)
Critical signal After Override (XX-CRTO)
Three Step Validation
CIS Desk (WinCC-OA Client)
Supervisiory Module(WinCC-OA Server)
CIS
SCADA_HIOCDB 1016
SAFETY PROGRAMSTANDARD PROGRAM
HIOC_SFT
F_Q_OVRC
F_CRTOF_OVRSF_CRT
Figure 6: Concept of Overrides
Page 30 of 90
As shown in Figure 6, the application of an override on a critical signal (event/action) shall be implemented by a logical “OR”operation of the critical signal before override (XX_CRT) and override command (F_Q_OVRC) from safety program block (HIOC_SFT). After the application of the override, the critical signal variable name suffix should be changed to CRTO from CRT, as per the PIS naming convection.
Data exchanged between Safety program block (HIOC_SFT) and standard program block (HIOC_STD) are already integrated in the PIS PLC template chart for HIOC.
Override command is sent from the CIS operator desk, and only applied after thePIS PLC validation through the HIOC protocol’s three step validation method. Only after successful validation in HIOC_SFT block, the override command (F_Q_OVRC) is available at output of HIOC_SFT block to apply the override on the critical signal. Notification of override command (F_OVERS), Status of critical signals before override (XX_CRT) and after override (XX_CRTO) shall be connected to the HIOC_SFT block. , standard program block HIOC_STD shall update these statuses in DB 1016 (SCADA_HIOC), after safety to standard data conversion.
The DB 1016 is used for storing the HIOC verification messages and statuses from the HIOC_STD block. In the DB 1016, statuses per override are integrated in a signal Double word signal “QDW”. For more details about QDW refer [RD23].
Data in DB 1016 (SCADA_HIOC) is then sent to the CIS desk (WinCC OA Client) from PIS PLC through Supervisor module (WinCC OA server). Figure 6, represents the detail flow of data exchange between CIS and PIS PLC.
In Table 4, example of override types and its associated signals and variable naming convention are given for reference from PBS 34. Similar variable naming convention for override shall be applied in the PIS software.
Table 4 : Override type and associated signals naming convention
Override type
Override command
Override status Critical signal before override
Critical signal after override
Event Mask CRYOSTART_ MSK
CRYOSTART _MSKS
CRYOSTART_CRT
CRYOSTART_CRTO
Action Force
XX_FRC XX_FRCS XX_CRT XX_CRTO
Function Disabled
XX_DSB XX_DSBS XX_CRT XX_CRTO
Page 31 of 90
Normally override for event and action is applied at PIS level. But for the some specific actions commands, which are sent from CIS to more than one PIS, in this case override is applied at the CIS level.
4.2.3.2. Threshold value section
Concept of threshold:In an interlock system threshold value is the event detection for analog value exceeding the allowed maximum/ minimum value. The Threshold value configuration is only available from the CIS Desk.In view point of threshold value modification risk from CIS, a design philosophy adopts two threshold levels.
1. Adjustable value: Threshold of an interlock function can be adjusted during normal operation according to a predefined list of values. These values defined during design and can be selected up to 16 values.
2. Not adjustable value: It is fixed on the basis of component specification, design condition and must be hard coded in PLC which is not allowed to adjust during normal operation. The value of this parameter is related to the maximum (or minimum) value allowed for this particular condition.
For implement adjustable threshold value, the following design principles should be followed
No interlock threshold management can be done from the plant system or CODAC services of conventional system.
No interlock threshold value can be manually defined by an operator from the CIS operation desk.
Any other change of a threshold value can only be done after strict authorisation and validation procedure, only in maintenance and commissioning period
Selection of adjustable threshold value is only done from CIS desk routed through supervisory module and must be implemented using HIOC threshold blocks, it will be included in the PIS PLC template
Concept of threshold value selection using HIOC protocol:
Page 32 of 90
Request ID, Command ID, Confirmation ID
Response
Data Conversion between Safety and Standard
HIOC_TH_STDHIOC_TH_SFT
Three Step Validation
Selected Threshold Value
Threshold Values for Selection
1 2 3 16
SCADA_HIOC_TH
CIS Desk (WinCC-OA Client)
Supervisiory Module(WinCC-OA Server)
CIS SLOW PIS PLC
STANDARD PROGRAM SAFETY PROGRAM
Figure 7: Concept of threshold selection using HIOC protocol
The Threshold selection is a critical operation; hence operation should be validated through HIOC protocol to comply the safety standards mentioned in override section.
Similar to the override implementation, the HIOC protocol for threshold selection contains standard program block HIOC_TH_STD and safety program block HIOC_TH_SFT. The PIS PLC template includes a chart where primary connection between these two ready to use blocks are interconnected.
Conceptual diagram of threshold value selection using HIOC protocol is shown in Figure 7. As per concept of threshold, the adjustable threshold values (up to 16) are hardcoded and assigned to the HIOC_TH_SFT block. The selection of these adjustable values is assigned to a sequential number from 1 to 16 and the sequential number is named as K. The K value selection in HIOC_TH_SFT block is done from the CIS desk through the CIS supervisor module and the threshold value (K value) is verified using three step validation process of HIOC protocol. After verification of K value in HIOC_TH_SFT block,the adjustable threshold value for the respective Kth selection is then send out from HIOC_TH_SFT block as selected threshold value.
HIOC_TH_STD block update the verification message and notification of threshold selection (K) and selected threshold value, in DB (SCADA_HIOC_TH), which will exchange data between CIS desk and PIS PLC through the CIS supervisor module (WinCC OA Server).
Page 33 of 90
4.2.4. Concept of Reset
After the activation of local interlock functions, reset is required before normal operation can continue. The reset can only be performed when the interlock event has been clearer, meaning that it is not a critical command. The reset command shall be performed from CODAC. With this approach, flexibility during the operation of ITER is maximized without compromising its integrity.To ensure that the integrity of the interlock functions will not be affected by this non-critical interface, the internal logic of the PIS PLC shall ensure that all the conditions required for a safe operation are met and the operator reset is the last step after a recovery from an interlock event.The following rules shall be observed for the RESET operation:1. Resets operation should not be permitted if the causes (risks) are still active.2. This operation should manually performed by the Plant System Expert, using the
CODAC services.3. The interface should be implemented via the PSH.4. The PSCC should not be involved in the reset of investment protection functions.5. The evaluation of the conditions for reset shall be performed without considering the
operator command status.6. The operator shall be aware of the status of the function at every moment.7. The operator shall be informed that the conditions to reset the function are met (ready to
reset status).8. Reset shall be pulse commands, so whatever the communication protocol of commands
between the systems is, it is necessary to react to the command on the positive edge and not on the status.
9. The following signals should be configured in the SDD tool to implement the function reset from CODAC, but not limited to:
1) Status signals for the function reseto Ready to Reseto critical event /action status
2) Command for function reseto Reset command
For implement the Reset operation it is recommended to use the customised function block FB 1011 (F_FN_RST), which is the part of PIS_LIB.
Page 34 of 90
The typical schema of local interlock function Reset operation, using FB 1011 is shown in Figure 8. The FB 1011 support evaluation of up to 16 safe conditions for Ready to Reset. If all the required conditions for Reset the interlock function are met, then ready to reset status (output of FB 1011) is set. After conversion from safety to standard data type, the Ready to Reset signal is updated in DB 100 (CodacStates) and sent to CODAC through PSH over PON connection. After receiving the Ready to Reset status at Plant system CODAC operation desk, operator can sent the Reset command, into DB 102 (CodacCommands) of PIS PLC, through PSH. In PIS PLC, after standard to safety data conversion, the Reset command is validated and executed in FB 1011 safety program. Event/Action statuses of the interlock function are continuously updated in DB 100 and sent to CODAC (not shown in Figure 8).
Data Conversion between Safety and Standard
CODACDesk
PSH Ready to Reset status
SLOW PIS PLC
COMMANDDB 102
STATUS DB 100
STANDARD PROGRAM SAFETY PROGRAM
CODAC
OP_CMD
Ready to Reset
FB 1011: F_FN_RST
Reset CMD
Cond 1
Cond 16
Cond 2
Function Reset
Figure 8: Concept of RESET
4.2.5. Concept of Reintegration
In the event of an error on a F-I/O (e.g. a channel fault), the F I/O (or the affected channel) switches to safe mode. In this state of “passivation”, substitute values are automatically replaced instead of the process values.After clearing the error that caused the passivation, the switchover from substitute values to process values shall occur only after a manual user acknowledgment in the safety program. Automatic acknowledgement is not recommended, the switchover is referred as “reintegration”.It is considered that the reintegration action should be performed from CODAC, without compromising its integrity.
Page 35 of 90
Rules 1, 2, 3, & 5 mentioned in concept of RESET are applicable for Reintegration implementation. Additional rules shall be observed for the channel driver Reintegration operation:1. The evaluation of reintegration request shall be performed at PIS level and it should be
without considering the reintegration command from CODAC services.2. The operator shall be informed when the error has been cleared to reintegrate the channel
driver module. 3. All the acknowledge request generated from the channel driver of all the configured
signal modules (F-AI/ F-DI/F-DO) should be logically combined with an “OR” gate and finally a single reintegration request signal will be generated. A single reintegration pulse command from CODAC shall reintegrate all the channel drivers of all configured signal modules.
4. Reintegration must be pulse command, so whatever the communication protocol of command between the systems is, it is necessary to react to the command on the positive edge and not on the status.
The typical schema of channel driver reintegration function is shown in Figure 9. In the Figure 9, error may occur in single or multiple channels during operation. Once error has been eliminated, the acknowledge request (ACK_REQ) status is set. The request (ACK_REQ) from all channel drivers is logically combine with an OR and the result is updated in DB 100 (CodacStates) and sent to CODAC through the PSH, over PON connection. After receiving the acknowledge request (ACK_REQ) status at Plant system CODAC, operator has to send reintegration command, into DB 102 (CodacCommands) of PIS PLC, through PSH. After standard to safety data conversion, the reintegration command is validated and executed in the safety program, on rising edge of pulse Command. In safety program, the reintegration command shall be connect to (ACK_REI) input in such way that a single reintegration command from CODAC shall reintegrate all the F/IO modules.
Page 36 of 90
Reintegration Command
Acknowledge Request
CODACDesk
PSH
CODAC
Data Conversion between Safety and Standard
SLOW PIS PLC
COMMANDDB 102
STATUS DB 100
STANDARD PROGRAM SAFETY PROGRAM
F-CH_DRIVER BLOCK
ACK_REI
ACK_REQ
ACK_REI
ACK_REQ
ACK_REI
ACK_REQ
ACK_REI
ACK_REQ
OR
Block Name * *
CH 1
CH 2
CH 3
CH n *
F-A
I/F
DI/
F D
O
* As per module type F AI/F DI/F DO channel number varies to 6 / 24 / 10
** Block name as per module name in hardware configuration
F-CH_DRIVER BLOCK
F-CH_DRIVER BLOCK
F-CH_DRIVER BLOCK
Figure 9: Concept of Reintegration
4.2.6. Concept of Critical health monitoring
Diagnostics of the components included in PIS PLC system that needs close and continues monitoring are termed as Critical health monitoring. Table 5 lists the signals are considered for critical heath monitoring of PIS PLC system:The critical health monitoring signals are monitor and archived in the CIS supervisor module. The main aspects of Critical Health Monitoring in the PIS PLC are as follows:
Program should be written in standard program in OB 34 , which execute and update the status every 200 msec.
Health monitoring shall be done without any initialization or intervention from CIS.For implement the critical health monitoring it is recommended to use customised function block FB 1036 (C_DIAG_CPU) and DB 1001 (SCADA_CHMD), which are the part of PIS_LIB.The typical schema of Critical Health Monitoring using FB 1036 is shown in Figure 10.In the standard program FB 1036 is executed cyclically every 200 msec and update the status of the defined critical signals in DB 1001 (SCADA_CHMD).
Page 37 of 90
Table 5: Critical Health Monitoring Signal
Sr. No. Description
1 CPU INTF (internal error)2 CPU EXTF (external error)3 CPU RUN4 CPU STOP5 CPU REDF (redundancy error)6 CPU MSTR (master)7 CPU DC24V8 CPU IF (interface failure)9 CPU UF (user failure)10 CPU MF (monitoring failure)11 CPU CF (communication
failure)12 CPU MAINT
From the DB 1001, status of critical health monitoring signals are receives in the CIS supervisor module (WinCC OA Server) through S7 communication and shown on CIS operator desk (WinCC OA Client).
Figure 10: Concept of Critical health monitoring
Page 38 of 90
4.2.7. Concept of archiving and status Monitoring
On the basis of critical and non-critical data defined in section 2.2 of this document, plant interlock system shall adopt two types of protocol for data archiving and status monitoring :
1. S7 protocol - for non-critical data2. TSPP protocol - for critical data
4.2.7.1. S7 protocol
S7 protocol is a Siemens proprietary protocol. It is used for PLC programming, exchanging data between PLCs and accessing PLC data from SCADA. It can be used for bidirectional communication. The following considerations shall be observed for archiving and monitoring through S-7 protocol:
1. Non critical data shall be archived and monitor through S7 protocol. 2. In S-7 protocol, WinCC-OA is the master, its pull data from the PIS PLC. Hence
no special configuration needed in PIS PLC. Only the DB’s shall be created for exchanging the data.
3. It is recommended to create the following exchange data blocks (DB’s) at PIS PLC side for non-critical data archiving and monitoring:
SCADA_STATE_100ms (DB 1004): for Boolean signals archiving at 100ms
SCADA_STATE_1s (DB 1005): for Analog signals archiving at 1s4. If PIS needs different archiving intervals, like 500ms or 300ms etc., then a new
data block (DB) with name SCADA_STATE_500ms or SCADA_STATE 300ms etc . shall be created.
Data continuously updated in exchange DB (DB 1004 and DB 1005) and as per archiving interval supervisor module (WinCC OA server) pulls the data, archives and update to CIS desk (WinCC-OA Client).Detail implementation is explained in PIS PLC template document [RD23].
4.2.7.2. TSPP protocol (Time Stamp Push Protocol)
TSPP (Time Stamp Push Protocol) is a protocol which send the data with time stamped at the source (PLC) in such a way that the CIS supervisor module will receive the time of change of the data with the precision of the PIS PLC cycle time. For this protocol, the PIS PLC will be pushing data to the CIS supervisor module (WinCC OA Server) which will decode the TSPP packets and archive the values and the timestamps.The main aspects of TSPP implementation in slow PIS PLC are:
Only critical data shall be sent to supervisor module through TSPP for arching and monitoring. Non-critical data should not be sent through the TSPP because it increases the load on the TSPP and affects the critical data archiving.
Page 39 of 90
It is also recommended not to use TSPP for archive the analog values.
Data sent over TSPP protocol is having first priority for archiving in CIS supervisor module, and then supervision on CIS desk
TSPP is also optimized, as the communication between CIS supervisor module and PIS PLC only occurs if there is change of state.
Additionally, TSPP data can be archived locally in the PLC during a short loss of communication (less than 30s) between PIS PLC and CIS Supervisor module (WinCCOA server) that prevent the loss of archiving. This short loss of communication may occurs due to switchover (for example Communication Processor or network failure) or the WinCC OA Server switchover (Between MSR and BSR)
Siemens S7 400 FH PLCs supports TSPP protocol by default; however additional PIS PLC blocks are developed to cater the slow PIS PLC design.
It supports a maximum Buffer Length = 32 KbytesIt is recommended to use DB 1002 (SCADA_STATE_TSPP) for Critical data exchange through TSPP. Detail implementation is explained in PIS PLC template document [RD23].
TSPP Protocol
S7 Protocol
CIS Desk (WinCC-OA Client)
Supervisiory Module(WinCC-OA Server)
CIS
Data through S7 Protocol
Data through TSPP Protocol
SCADA_STATE_100ms (DB 1004)
SCADA_STATE_1s (DB 1005)
SCADA_STATE_TSPP (DB 1002)
SLOW PIS PLC
STANDARD PROGRAM
Figure 11: Concept of archiving and status monitoring
Page 40 of 90
4.2.8. Concept of conventional health monitoring and CODAC interface
4.2.8.1. CODAC Interface
The CODAC (Control, Data Access and Communication) system is the central control system for the conventional plant control systems of ITER. CODAC is responsible for integrating all plant systems I&C and enabling operation of ITER as a single integrated facility, providing overall plant system coordination, supervision, alarm handling, data archiving and plant visualization (HMI).In interlock system each slow PIS shall be connected to its respective PSH through PON for interface with CODAC. The link between the PIS and PSH must be bidirectional in order to transmit non critical commands (reset and reintegration) from CODAC to the PIS via the PSH and to make non critical data available to the control room. The connection of the slow PIS to PON is also required to receive time synchronization through the Network Time Protocol (NTP) from PON.
Implementation of the slow PIS interface with CODAC is on the basis of SPSS library [RD18]. Step by step implementation of PIS PLC and CODAC interface in view point of interlock system is described in PIS PLC template document [RD23].The main aspects of interface between PIS PLC and CODAC are as follows:
Communication between CODAC and PIS shall be direct link between PIS to PON network using EPICS interface. Normally PSH is the EPICS interface provided by CODAC to each plant system.
The interface shall be a standard program in PIS PLC, if data is required in safety program then conversion to safety data from standard data shall be through Siemens safety library blocks.
The following types of signals shall be considered as interface data between PIS and CODAC and they shall be configured in the SDD tool, but not limited to:1) States variables (Status)
o Ready to Reseto Acknowledge request o Conventional Health monitoringo All critical event and action status o All Analog process values
2) Command variables o Reset Command o Reintegration Command
All the data exchanged through standard PLC program over PON, use the TCP connection where port 2001 used for command and port 2000 is for states variables.
Page 41 of 90
PIS PLC receives commands (DB 102) and sends status (DB 100) data to CODAC through PSH.
4.2.8.2. Conventional Health monitoring
Conventional health monitoring is considered non critical because they are supervised by the CODAC. See the definition of Non critical data in section 2.2. As explained in the concept of CODAC interface, conventional health monitoring of PIS PLC shall be passed to CODAC for supervision and monitoring purpose. For implementation of conventional health monitoring in PIS PLC, it is recommended to use PIS PLC template chart “PISxx_CODAC” and SPSS package provided in PIS PLC template. PIS developer do not need to write extra program, as SPSS library code will identify the conventional health monitoring signals and generate standard program through SCL and STL code.
Command
Status
TCP CONNECTION
TCP Connection-port 2001
TCP Connection-port 2000
CODACDesk
PSH
CODAC
COMMANDDB 102
STATUS DB 100
1. Reset command2. Reintegration command
1. Ready to Reset2. Acknowledge Req.3. Conventional Health monitoring4. All critical event and action status5. Analog process values
SLOW PIS PLC
STANDARD PROGRAM
Figure 12: Conventional Health monitoring and CODAC
Page 42 of 90
5. Configuration of Fast PIS
To standardise the configuration of a fast PIS hardware and software architecture for all suppliers and help the PIS developers, the PBS 46 (CIS) team has developed a set of standard PIS templates that can be used when setting up a Fast PIS.Due to the strong correlation in the fast architecture between the hardware configuration and the software one, it is suggested to use the templates only when the fast plant interlock system architecture exactly matches with the functionalities implemented in one of the templates provided by IO. In any other cases, these guidelines can be used for getting a general understanding of the subject, with the recommendation to contact the Interlock RO for support on the design of the fast plant interlock system. Main features of the Fast PIS templates are:
Modular software architecture
Preconfigured Host PC software module to perform the monitoring
Preconfigured FPGA projects, to implement the protection functions
5.1 Hardware configuration
Two scenarios can be considered for hardware configuration, these are:
5.1.1. Hardware Configuration using Fast PIS Template
When the hardware configuration of a project under development exactly matches with the hardware configuration adopted in a PIS template, the developer can configure the cRIOs using one of the following templates provided by IO.
- 3 AI and 2 DO 24 V, implementing protection functions based on a 2oo3 voting logic
- 3 DI 24 V and 2 DO 24 V, implementing protection functions based on a 2oo3 voting logic
- 3 DI TTL and 2 DO TTL, implementing protection functions based on a 2oo3 logic
- 3 AI and Event to CIS (Manchester Code) implementing protection functions based on a 2oo3 voting logic and transmitting the event to the CIS
- 3 DI 24 V and Manchester Coded TTL output signal, implementing protection functions based on a 2oo3 voting logic and transmitting the event to the CIS
- 3 DI TTL and Manchester Coded TTL output signal, implementing protection functions based on a 2oo3 voting logic and transmitting the event to the CIS
- Manchester Coded TTL input signal and 2 DO 24 V, receiving an action from the CIS
- Manchester Coded TTL input signal and 2 DO TTL, receiving an action from the CIS
Page 43 of 90
The Configuration of the Fast PIS requires 2 steps: - Configuration of the cRIO FPGAs - Configuration of the Host PC
In order to configure the cRIO FPGAs, the Developer shall download the desired template from SVN: https://svnpub.iter.org/codac/iter/codac/dev/units/m-cis-pisfc/tags/TO4 and apply some customization,In the LabVIEW’s project window of the selected template, the resources linked to the terminals of the modules, that act as input and output of the system, shall be renamed with aliases specific for the plant system, conforming to the naming convention..
Figure 13: Application of the naming convention
In case of a template with multiple protection functions deployable, the exact number of function to be performed in the specific plant system has to be chosen among the available ones, by selecting it from the drop down menu of the polymorphic sub-VI in the block diagram of the top-level VI.
Page 44 of 90
Figure 14: Protection function’s number choice
Before compiling the LabVIEW project, the deployment has to be properly versioned by imposing the right initial values to the array of U8 called “FPGAVIversion”; the documentation involving the Fast PIS shall keep track of the history of the program.
Figure 15: Versioning of the bitfile
It shall be remark that the bitfile generated by the NI compiling tools is not the one that shall be used to configure the Host PC; it shall be fed to the National Instruments’ C API generator, which generates a header file and .lvbitx file that shall be used when configuring the Host PC.
Page 45 of 90
Figure 16: C API generator
For configuring the Host PC, it is necessary to couple the interface module source files with the cRIOs composing the Fast-PIS architecture being used. This is done by entering the serial numbers of the chassis, as they’re returned by the lsrio.py function, in the “DeviceSerialNumber” field for the parameters of the calls to the function irio_initDriver , before compiling the C project. [RD26] The parameter “projectName” of the same function has to be filled in with the name of the bitfile produced by the C API generator, without the initial “NiFpga_”.
5.1.2. Hardware Configuration for New project
If the Fast PIS project under development doesn’t have the same functionalities of one of the templates provided, then a new project needs to be configured in collaboration with the IO CIS responsible officer; this has to be done taking into account that the selection of the input/output modules to be used in the CRIO Chassis is strongly dependant on the logic to be implemented. In Table 6 are listed the approved C-Series modules that can be installed in the cRIOs of a fast PIS and their possible usage.
Table 6: Approved cRIO modules
MODULE DESCRIPTIONNI 9205 32 Ch DI modules ±200 mV, ±1, ±5, and ±10 VNI 9264 16 Ch DO used as DI diagnostic module
8 Ch DI module TTL8 Ch DO module TTL NI 94018 Ch DO used as DI diagnostic module
Page 46 of 90
8 Ch DI used ad DO diagnostic module SPI interchassis communicationManchester transmitter (event)Manchester receiver(action)
NI 9477 32 Ch Digital sinking output module 5,12, 24, 48, 60 VNI 9426 32 Ch Sourcing DI module 30 VNI 9425 32 Ch Sinking DI module 12 V,24 VNI 9476 32 Ch Sourcing DO module 12 V,24 V
5.2 Software architecture and Programming concepts
The Fast PIS software architecture can be divided in two major blocks
The Host PC, in charge of implementing the interface between the cRIO FPGA and the Central Systems for monitoring and controlling purposes via HMI.
The cRIO FPGA core application, in charge of performing the interlock functions and communicating the Actions and Events to the central interlock system’s fast modules. ,
Data is exchanged between the cRIO FPGAs and the Host PC software layer through a FIFO queue over a DMA channel in the FPGA and through an exchange data buffer shared with the Host PC.
Page 47 of 90
Host PC
iRIO-OPC UA Interface
OPC UA SERVER
cRIO FPGA (Chassis 1)
IRIO
CORE APPLICATION
Central Interlock System SUPERVISOR MODULE
CODAC
Mxi
Sensors
Actuators
MC from CIS
MC to CIS
cRIO FPGA (Chassis 2)
CORE APPLICATIONMxi
Interchassis Communication
Figure 17 : Fast PIS software architecture
The main functional blocks of the Host PC’s Software architecture are the followings
OPC UA Server iRIO-OPC UA interface
The OPC UA Server
Implements an OPC UA server, based on the open source project called “Open 62541”
Allows multiples LAN connections from clients provided with a valid certificate and implements the communication with different levels of security.
Receives data from the iRIO-OPC UA interface and stores them in the OPC UA address space. The iRIO-OPC UA interface
- The cRIO FPGA generates periodically a “status word” that includes all the information which is meant to be monitored in each chassis; this status word is sent via DMA to the Host PC: the iRIO-OPC UA interface reads the status word from the data buffer (using the iRIO library) of the Host PC and permits the update of the related OPC UA nodes.
Page 48 of 90
In case that the Host PC is interfaced with the cRIO FPGA, in which one of the templates provided is deployed, the Host PC software implementation will be provided by IO and will require only a configuration by the PIS developer, as explained in [RD26]. In any other case, the Host PC shall be configured with the supervision of the IO’s CIS responsible officer. Note that the fast PIS architecture is composed of two cRIOs in a parallel configuration called “Double Decker”, hence the LabVIEW project to be deployed to each FPGA is the same.
The main functional blocks of the cRIO FPGA core are the following:
Inputs
Outputs
Manchester transmitter/receiver
Voter
Decision logic
SPI Interchassis Communication
The following Figure 18 depicts a block scheme representation of one of the possible implementation of a template.
Data/Diag ratio
Diagnostic Input
GenerationInput Reading
Input Diagnostic
Check Voter Voter
Diagnostic
Output Writing
Output Diagnostic
Chassis Diagnostic
SPI communicatio
n Slave
SPI Communicatio
n Master
Global Status
Manchester Receiver
Manchester Transmitter
From CIS
To CIS
To Next Iteration
From previous Iteration
EVENT
ACTION
To other Chassis From other chassis
Loop Iteration time
INPUT VOTER
OUTPUT
MC EC/DC
SPI
DECISION
Figure 18: FPGA Core application
Page 49 of 90
InputsThe blocks dealing with inputs are those in charge of reading the data from the sensors. In addition, for diagnostics purposes, one of these blocks generates data for the input modules so that it can be checked if the acquired data equals the generated one.A diagnostics module outputs some random test values to the input modules, delivering them to channels different from those used by the sensors. These values are then read back and compared. In addition the voter will also act as a diagnostic test for the actual input channels. If any sensor channel result is different from the others, the voter will detect the discrepancy. If both tests pass, then it will be assumed that the sensors and the input modules do not have any faults and can then be trusted.
VoterThe voter blocks perform the 2oo3 logic voter and the voter’s diagnostics. The diagnostics of the voter uses the data generated for the input diagnostics modules and compares the voting result with the expected output for this test data.When random test inputs are sent through the input modules, the input values will then be sent to the voter. The voter results are compared to see if they coincide with the random diagnostic test inputs. All diagnostic scans use the same voter as the actual safety function. If this test passes then it will be assumed that the voter is functioning free of faults and thus, it can be trusted.OutputsThe blocks dealing with outputs are in charge of generating the outputs for the actuators. In addition, for diagnostics purposes, these blocks generate additional outputs data in the diagnostics output channelsso that it can be checked if the generated data equals the expected data. If this test passes, it’s that the output modules are functioning free of faults and, thus, they can be trusted.
SPI Interchassis communication Communication messages are sent from one chassis to the other for very iteration of the main loop. Two SPI communications are established between the chassis, each of them performing the data transfer in one way.
Decision LogicThe decision logic blocks generate the output values for the next iteration.The Output values are elaborated as the results of the voting applied to the input and taking into account all information from sensors, diagnostics blocks and remote chassis (through SPI communication) to generate these values.
MC Transmitter This block generates the digital bit pattern in a digital output TTL channel. This communication will be done over a serial protocol (Manchester Code based) at a 10 Mbps bit rate. In this case, the data will be sent to the Central Interlock System (CIS).
MC Receiver This block receives the digital bit pattern in a digital input TTL channel and converts it to a 64-bit word. This communication will be done over a serial protocol (Manchester Code based). In
Page 50 of 90
this case, there are two MC Receivers in each chassis; one of them receives data from the Central Interlock System (CIS) and the other one receives data from the other chassis. The data received from the other chassis has to be checked in order to assure the coherence between the data received by both chassis from CIS.
5.2.1. Concept of archiving and status Monitoring
During every cycle of the main loop in the FPGA, the decision logic blocks generate the values that are going to be sent as output in the next iteration. These blocks take into account the information from sensors, diagnostics blocks and remote chassis (through the SPI communication) to generate these values. The information generated for all previous blocks in every iteration are packed into a “status word”, which is used for monitoring the status of each Chassis. A status word contains the information in Table 7 and its structure is portrayed in Figure 19.Note: the status word as described is valid only for the FPGA templates mentioned in Chapter 5, for any different template is it possible that the monitoring status word has a different configuration and needs to be configured with the collaboration with the IO PBS 46 RO. The Status word is exchanged via DMA with the Host PC and published on the OPC UA Server; this permits the subscription to the variables by any certified OPC UA client as the interlock and CODAC SCADA.
Table 7: Status word data
Legend Description
Consecutive Number Consecutive number of the word
PU Powering status CH Communication with Host PC statusCC Communication with remote chassis statusRP Power status of remote chassisI1 Diagnostic status of Input module 1
I2 Diagnostic status of Input module 2
I3 Diagnostic status of Input module 3
O1 Diagnostic status of Output module 1
O2 Diagnostic status of Output module 2TE Temperature alarm status
VOn Voter Output status of n-th protection functionVAn Voter Output alarm of n-th protection functionVDn Voter Diagnostic status of n-th protection functionCRC Cyclic redundancy check
Page 51 of 90
STATUS WORD0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Consecutive Number PU CH CC RP I1 I2 I3 O1 O2 TE VO116 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
VA1
VD1
VO2
VA2
VD2
VO3
VA3
VD3
VO4
VA4 VD4 VO5 VA5 VD5 VO6 VA6
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47VD6
VO7
VA7
VD7
VO8
VA8
VD8
VO9
VA9
VD9
VO10
VA10
VD10
VO11
VA11
VD11
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63CRC
Figure 19: Status word structure
Page 52 of 90
6. Management of PIS software
This section deals with recommendation for the Version Control for
- Slow/Fast PIS software management Repository Management for
- Software on SVN during various stages of integration PIS software Runtime application Development process
6.1 Version Control
Software version control is a cornerstone of the software development and QA process. In order to assure a correct version control management of the software and configuration files used in the development of the PIS, the following files shall be updated on ITER SVN repository:
Software developed or used by PIS (Fast and Slow). Plant system-specific software configuration files. PIS-CODAC interface configuration file.
The Repository is located on https://svnpub.iter.org/codac/iter/codac/icdev/unitsThe files contained into the repository, can be accessed using Tortoise SVN software, allowing to commit and checkout the files from SVN.In addition to the file version information, some additional information such as time of commitment, name of the author(s), the author’s annotation and so on is available on SVN. Every change of the software or the configuration files have to be managed in SVN. The SVN general guidelines are provided in [RD14] ITER CODAC Subversion Guideline (ITER_D_A2GSXB).Note: PIS I&C projects folder is the same for conventional and interlock project, the Interlock files will be stored inside specified folder related to interlock architecture. Following sections summarizes the methodology for organizing a repository for PIS related development.
Page 53 of 90
6.2 Repository Management
Some guidelines for PIS Repository Management are as follows:
Slow PIS STEP-7 projects will be stored in SVN unzipped. This avoids files manipulations before/after every SVN operation.
The last project stored in SVN and the project running on the PIS (Slow/Fast) must be the same (During FAT it is compulsory while during offsite development it is optional)
Every change into the software must be tracked and committed into SVN.
6.3 Development Process
Development process is the process of developing source code and generating the configuration file in order to make the program runnable and compatible with all the related software involved.
Figure 20: Development Process Work Flow for slow PIS Applications
Above Figure 20 shows the workflow for development process of slow PIS applications. There are four horizontals layers as follows:
SDD tool: Used to generate the configuration files for CODAC Interface with PIS.
STEP-7: Used to develop the Core Application of the slow PIS. WinCC OA: Used to implement the archiving and the monitoring of the PIS
- From Mini-CIS Desk during FAT- From CIS desk during SAT.
CODAC CORE SYSTEM: Used to implement the core application that permits the monitoring and archiving from the CODAC System.
Page 54 of 90
Several development tools are involved in the development of specifically Fast PIS runtime Application. These are as follows:
CSS
I&C CREATION COMPONENT CREATION-SIGNAL
CONTROLLER CREATION
CONFIGURATION AND STATES CREATION
EPICS CONFIGURATION
LabVIEW PROJECT
CREATION
WIN CC OA PROJECT
CREATION
CREATION OF BITFILE
DRIVER SETTINGS DATAPOINT CONFIGURATION
GRAPHIC SCREEN DEVELOPMENT
APPLICATION CREATION COMPILE GENERATE BOY SCREEN
HOST PC CHASSIS-WinCC OA INTERFACE
CONFIGURATION
SDD
LabVIEW
ECLIPSE
WINCC-OA
CODAC CORE SYSTEM
RUNTIME APPLICATION
Figure 21: Development Process Work Flow for Fast PIS Applications
Figure 21 shows the workflow for development process of Fast PIS applications. Several development tools are involved in the development of specifically Fast PIS runtime Application. These are as follows:
SDD tool : Used to generate the configuration files for CODAC Interface with PIS. LabVIEW : Used to develop the Core Application of the Fast PIS chassis Eclipse : Used to configure the interface between the Chassis and the WinCC OA for
data exchange. WinCC OA : Used to implement the archiving and the monitoring of the PIS
- From Mini-CIS Desk during FAT- From CIS desk during SAT
CODAC CORE SYSTEM: Used to implement the fast controller PC Host core application that permits the monitoring and archiving from the CODAC System.
6.3.1. Scope areas for PIS Software development
Following areas are in scope of PBS 46 CIS Teamo WinCC OA project creation, configuration and Interfacing with PIS.
Following areas are in scope of PS I&C ROo The development procedures related to SDD, STEP 7 and CODAC Core System,
Refer [RD23].
Page 55 of 90
o LabView core application and Eclipse project creation
6.3.2. Off-Site Development and Stand-Alone Test (Independently from IO)
Page 56 of 90
Figure 22: Off-Site Development
The following inputs are required before starting the first step of development process for slow/fast PIS:
PIS-CIS interface sheet PIS functions specification.
The PIS developer receives the specification from the PS I&C RO to start the development of functionality accordingly.When the Code is ready, it is compiled and downloaded into the PIS slow/fast controller; a temporary version is generated and saved into SVN repository. All the Local functions are tested with the hardware and software already implemented, the central functions are tested using the MINI-CIS that will provide the tools to simulate the behaviour of the central interlock architecture. For more detail about MIN-CIS refer 7.1.5.6If the entire tests are passed, the PIS developer will generate a local release of the PIS project and confirm the validity of the Version Tag saved in SVN.
Page 57 of 90
7. Integration
Each plant system is incorporated into ITER in one main step; however the installation schedule of the plant systems covers a long duration. This requires the implementation of specific means to minimize errors and the time taken during the integration and commissioning of the plat system I&C. The document [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W) describes the testing approach and methods and the organisational scheme for planning and performing the FAT and SAT for any ITER I&C system. In additional to this in order to achieve a good integration between the different plant interlock systems and the CIS, some specific guidelines are given in below section.
7.1 Recommendation for FAT of PIS
7.1.1. Plant System FAT Context
As explained in section 3.4.4 of [RD1] Plant Control Design Handbook (ITER_D_27LH2V), Plant System factory acceptance tests (FAT) are intended to check the conformity of the procured plant system to the approved design. Plant System I&C FAT is a part of the plant system FAT. All I&C components in the procurement shall be powered and tested during FAT. The FAT scenario for I&C will be adjusted depending on the configuration of I&C procurement with the policy to test as much as possible, as soon as possible. The guidelines for plant system integration [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W) provide further details on FAT scenarios applicable to plant system I&C. All the guidelines mention in [RD1] and [RD10] for the FAT of plant I& C system are applicable for the PIS. In addition to this following additional recommendation are given for PIS FAT.
7.1.2. PIS FAT Objective
The objective of the PIS FAT is to check the readiness of the PIS for installation which means:
- The PIS satisfies requirements set in [AS1] IEC 61511 have been satisfied.
- The PIS satisfies the requirements and recommendations applicable to interlock system set in [RD1] Plant Control Design Handbook (ITER_D_27LH2V) and its satellite documents.
- The PIS satisfies the requirements defined in the plant interlock requirement specifications.
- The PIS satisfies the requirements defined in the interface sheets.
- The PIS satisfies the manufacturers’ recommendations.
- The PIS documentation is up to date.
- The PIS satisfies all the interfaces with mini-CODAC and mini-CIS, wherever applicable.
Page 58 of 90
7.1.3. Recommendations about the methodology
Refer to the section 3.4.4 of [RD1] for general recommendation for I&C FAT methodology. In addition to it some additional recommendation about PIS FAT methodology are as follows:
- The mini-CODAC and mini-CIS are used for FAT and must be preconfigured before FAT campaign.
- PIS Supplier must provide necessary software tools and configuration files.
7.1.3.1. Pre-requisites
The PIS is considers ready for the FAT if the following criteria are met:
- The test plan is defined and agreed by all parties.
- The deliverable documents are stored in IDM.
- The hardware deliverables are available.
- The software deliverables are stored in the correct IO repository.
- The test environment and tools are ready.
- The supplier is ready to proceed.It is highly recommended to perform a pre-FAT, by PIS developer in order to detect and solve issues internally before starting the FAT. Indeed, performing a pre-FAT allows to save time considering that contrary to issues detected and solved during FAT, issues detected and solved during pre-FAT do not require formal issue management.
7.1.3.2. Test plan
The test plan shall include:
- A management plan (physical location, test personnel, etc.).
- The identification of the items to test (documents reference and version, hardware components, software version).
- The description of the test environment and tools. Detailed test procedures (test description, expected results) for each test.
7.1.3.3. Test report
Supplier shall submit PIS test report after completion of FAT. The results of the acceptance tests must be documented in the test report. The test report generally consists in a copy of the test plan with actual test results/comments.Following points shall be taken care during the filling of the Test Report:
Page 59 of 90
- If a test cannot be carried out, the reasons for the non-execution shall be explained in the comments reserved box in test report.
- If a test is successful, the test results box shall clearly indicate it and comments can be added in the comments reserved box in test report.
- If there is a failure during test, an issue sheet shall be opened (refer to section 7.1.3.4 ) and the test results shall be filled with the issue in test report.
- If the test environment and tools or the items to test are modified during the acceptance tests phase, the test report shall identify the versions for each test.
7.1.3.4. Issue management
As explained in section 6.1 “Issue management” of [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W), during the execution of tests, any deviation from the expected result shall be captured in a uniquely identified Problem Sheet. It shall record all the information related to the root cause investigation of the problem and all the remedial actions. Problem sheets shall be electronically typed in and at least archived into the IO problem tracking tools. The Problem Sheet shall record all the information related to the root cause investigation of the problem and all the remedial actions all along its lifecycle. Each non-conformance to the FAT should be recorded in the uniquely identified problem table.The Problem Sheet should be used generally for the following, but not limited to it :
- To describe the issue (system version, test procedure, test results, etc.)
- To analyse the issue (severity level, root cause, etc.)
- To propose remedial actions (specification modification, software modification, hardware modification, documentation update, etc.)
- To analyse the extent of impact (on software, hardware, documentation, etc.)
- To propose re-test procedures to validate that the issue is solved and that the modification has not adversely impacted other parts of the system
- To plan the modification and the validation (who, when, how, etc.)
- To implement the modification as planned.
- To validate the modification as planned.
Page 60 of 90
7.1.4. Recommendations about the FAT scope
7.1.4.1. Plant System FAT
The Plant System FAT should include the verification of all the requirements, functions (local, central etc.) and specifications involved in plant system I&C design.
7.1.4.2. Plant System I&C FAT
As explained in section 3.2 “Scope of FAT for I&C systems” of [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W), the FAT for I&C is split into four campaigns. A campaign is a set of scenarios targeting the same function or a specific category of tests (i.e. stress tests, performance tests).
C1. I&C documentationC2. I&C hardwareC3. I&C configuration data and softwareC4. I&C functional requirements
7.1.4.3. PIS FAT
In context of the PIS, the purpose of each campaign is extended as described in the following sections:1. C1 campaign: I&C documentation
The campaign aims at checking that:- All the PIS documentation required at this stage is available.- The PIS design satisfies the requirements set in [RD1] Plant Control Design
Handbook (ITER_D_27LH2V) and its satellite documents when applicable.- The PIS design satisfies the requirements set in the applicable PIS requirement
specifications.- The PIS design satisfies the requirements set in the applicable interface sheets.- The PIS design satisfies the manufacturer’s recommendations.- The PIS documentation is consistent.- The PIS documentation satisfies the PCDH and IEC 61508 requirements
applicable to the documents delivered in the scope of a procurement.2. C2 campaign: I&C hardware
The campaign aims at checking that:- The hardware deliverables satisfy manufacturer’s recommendations.- The hardware deliverables are in conformance with the PIS documentation.- Requirements (PCDH, IEC 61508, etc.) applicable to the hardware deliverables
are met.3. C3 campaign: I&C configuration data and software
The campaign aims at checking that:- The software deliverables satisfy manufacturers’ recommendations.- The software deliverables are in conformance with the PIS documentation.
Page 61 of 90
- Requirements (PCDH, IEC 61511, etc.) applicable to the software deliverables are met.
4. C4 campaign: I&C functional requirementsThe campaign aims at checking that the PIS (hardware + software) functional requirements are met (the PIS operates as required/defined).The policy is to test as much as possible as soon as possible, so the tests scenario shall be adjusted depending on the available interfacing components.The leading guideline of FAT tests scenario is to test I&C performance and functionality as much as reasonable achievable.The tests to be performed may include:
Functionality tests:
- Local interlock function test which include the interlock event and the interlock action(s) occur in the same plant system. These may include voter logic, force logic etc. For local functions information refers 4.2.1 .
- Central interlock function test which include machine’s protection function involving two or more plant systems. These may include sending event(s) and Receive action (s) from CIS, overrides etc. For central functions information refers 4.2.2.
- system diagnostics functions
- TSPP archiving functions
- Supervision function
Performance tests (response time, reliability, etc.)
Environmental tests (ambient air, EMC, life- and stress- testing, radiation, vibration, etc.)
Interface testing (Plant System Equipment interface, CIS Interface, CODAC interface etc.)
Testing in degraded and/or fault mode, exception testing
Maintenance and operating manuals/procedures tests
7.1.5. Recommendations for performing the campaigns
7.1.5.1. C1 campaign: I&C documentation
As explained in [RD10] Plant System I&C Integration Plan (ITER_D_3VVU9W) section 3.3 Performing FAT for I&C system, the campaign C1 does not require any attendance of the PS I&C RO at the FAT site since it may be performed remotely at IO using the deliverable documents. All document deliverables, as mentioned in [RD1] and [RD27] are expected to be reviewed.
Page 62 of 90
7.1.5.2. C2 campaign: I&C hardware
All hardware deliverables are expected to be checked. This campaign aims at verifying that all the hardware components are compliant with PIS bill of material (BOM). This campaign ends up with the equipment powering and electrical tests. PCDH rules for I&C deliverables management (section 3.4.1) are applicable to the hardware deliverables. It is also recommended to check the following:
- The hardware deliverables satisfy manufacturer’s recommendations
- The hardware deliverables are in conformance with the PIS documentation
- PIS Hardware is in conformance with PIS Manufacturing Description documentation and Interface Sheets.
- PIS I&C Spare parts with appropriate specifications of storage space and conditions are available
- Tools required for maintenance of any PIS I&C component with appropriate specifications of storage space and conditions are available
- Rules/requirements/recommendations applicable to hardware deliverables that were not checkable during C1 campaign (non-documented information) are satisfied.
- The hardware deliverables do not present any damage.
- The hardware deliverables have always been stored in appropriate conditions.
- The hardware deliverables have been checked (powered) and/or calibrated if required
7.1.5.3. C3 campaign: I&C configuration data and software
All software deliverables are expected to be checked. PCDH rules for I&C deliverables management (section 3.4.1) are applicable to the software deliverables.It is recommended to perform a PIS program code review in order to check that:
- The PIS program satisfies manufacturer’s recommendations.- The PIS program is in conformance with the PIS documentation (PIS Manufacturing
Description and Interface Sheets).- Rules/Requirements/Recommendations applicable to software deliverables that were not
checkable during C1 campaign (non-documented information) are satisfied.- Integration of all PIS programs with Mini-CIS program is mandatory.- Integration of PIS with mini CIS is required to check central functions that are in purview
of PIS during FAT.
- For the PIS involved in the implementation of central interlock functions, it is recommended that PBS 46 performs the integration procedure of the PIS program into the CIS multi-project and check it by compilation
Page 63 of 90
7.1.5.4. C4 campaign: I&C functional requirements
This campaign aims at checking that the PIS hardware and software operates as required/defined.It is recommended to:
Check the procedures for installation and commissioning.
Check that the hardware operates as required/defined.
Check that the software operates as required/defined.
Check the procedures for operation and maintenance of any I&C component.Note 1: Environmental (ambient air, EMC, life- and stress- testing, radiation, vibration, etc.) tests generally cannot be performed at supplier’s premises. So when considered, they are normally planned before the beginning of the FAT in specific laboratories. When available, the results of these tests are analyzed. The environmental test report shall allow validating the correct operation of the PIS in the environmental conditions expected at future PIS location in ITER site.
Note 2: Performance (response time, reliability, etc.) tests generally cannot be performed by experiences. So the reliability evaluations (based on analysis/calculations) are the sole performance results available. The reliability evaluation report shall allow validating the appropriate performances of the PIS. Considering the limits of the analysis techniques, margins between evaluation and requirements shall be high enough to get confidence in the conformance of the system with reliability requirements.
Note 3: In order to check that the software operates as required/defined, it may be considered to run the software on the hardware deliverables .It may be considered that part of the software testing activities are planned before the beginning of the FAT or during the code review recommended during C3 campaign. In this case, it is highly recommended to back-up each software version, to track modifications between all the versions and to record the test results with the identification of the tested version. The tests shall allow validating that the PIS operate as expected (in normal, degraded and fault modes) which means:
- As required according to the requirements specifications- As described in the PIS documentation
Note 4: Interface tests are highly recommended in order to discover interfacing issues as soon as possible. The leading guideline of FAT tests scenario is to test I&C performance and functionality as much as reasonable achievable. Whenever it is possible, it is considered to test interfaces with interfacing components or with identic copy of interfacing components. Whenever it is not possible, the tests shall allow validating the interface as much as possible with components as similar as possible to interfacing components.
Page 64 of 90
7.1.5.5. Items to Test:
The item to test is normally the PIS cubicle(s) with all I&C internal equipment and wiring. For part of the campaign, it may be the PIS PLC running with the application software.
Page 65 of 90
7.1.5.6. Test Environment:
PIS REMOTE IO
PIS SLOW CONTROLLERS
Mini CIS slowController
Mini-CIS Supervision Module
[WinCC OA]
Mini CODAC
OPERATOR STATION
PLANT INTERLOCK SYSTEM
Mini-CIS
AI 9
193
9401
MC
+ DM
S tr
igge
r94
01
9401
9401
9401
9401
Dia
g
9401
9401
94
01
9401
94
01
inte
rcha
ssis
PIS Engineering Workstation
AI 9
193
9401
MC
+ DM
S tr
igge
r94
01
9401
9401
9401
9401
Dia
g
9401
9401
94
01
9401
94
01
inte
rcha
ssis
AI 9
193
9401
MC
+ DM
S tr
igge
r94
01
9401
9401
9401
9401
Dia
g
9401
9401
94
01
9401
94
01
inte
rcha
ssis
Mini CIS fastController
MC
PIS FAST CONTROLLERS
CIN P
PON
AI 9
193
9401
MC
+ DM
S tr
igge
r94
01
9401
9401
9401
9401
Dia
g
9401
9401
94
01
9401
94
01
inte
rcha
ssis
AI 9
193
9401
MC
+ DM
S tr
igge
r94
01
9401
9401
9401
9401
Dia
g
9401
9401
94
01
9401
94
01
inte
rcha
ssis
Figure 23: Example of typical PIS FAT Test Environment
The FAT for PIS is managed in their real tests whose environment can be depicted from the conceptual perspectives. For performing FAT of PIS (slow and fast), mini-CIS shall be used for generating the CIS events and actions simultaneously.The FAT Test Environment shall include:
PIS system
PIS engineering station Which include Commercial Software packages: - Administration and Programming software for a Slow Controller: Siemens Step7,
F-Systems, CFC, F-Libraries, SCL etc.- Administration and Programming software for a Fast Controller: LabVIEW, IRIO
library
Page 66 of 90
Mini-CIS as a CIS substitutional tool
Mini-CODAC as a CODAC substitutional tool
Plant System Equipment (sensors, actuators, etc.) Substitution Tool
7.1.5.7. Test Tools:
1) Mini-CIS The CIS components are not available at supplier’s premises during the FAT. Hence for testing of the PIS interface with CIS protection modules and SCADA, concept of mini-CIS system has been introduces similar to mini-CODAC. The mini-CIS consists of an industrial computer and if needed Slow Controller/Fast controller acting as CIS protection module, where the hardware and the software components are designed to replace the main functionality of the CIS and perform the FAT/SAT of plant Interlock System.
Mini-CIS provide flowing functionality during FAT of the PIS o CIS protection module Substitution ToolIf a PIS implements part of central interlock functions, it’s requires an interface with the CIS protection (Slow/Fast) Modules. These CIS components are not available at suppliers’ premises for the FAT. Indeed, without its substitution tool, issues may appear, for example:
- Difficulty in checking interface.- Difficulty in checking Central functions.
For overcome above difficulties the Mini-CIS have a slow/fast controller which works as substitutional tool for CIS protection module and it’s used for checking the safety communication interface between CIS/PIS and also to check the implementation of the central interlock functions part in PIS .
o CIS SCADA Substitution ToolIt is one of the offerings of Mini- CIS during FAT, supervisory control and data acquisition of the PIS information is performed by the Mini-CIS acting as CIS SCADA Substitution tool. Indeed, without this substitution tool, issues may appear as below:
Page 67 of 90
- Difficulty to monitoring PIS variables.- Difficulty to reproduce manually the override command protocol.- Difficulty to check the TSPP timestamping and archiving functions.- Difficulty to validate the appropriate implementation of the S7-TSPP
interface.- Need to modify the program in order to allow the reception of commands
(For Example: By default the command variables are reset if the SCADA alive counter is stops)
For overcome above difficulties the Mini-CIS have an industrial computer with WinCC OA server which works as substitutional tool of CIS SCADA and it’s used for Supervision (monitoring) and archiving of following PIS data through S-7 protocol : I. Supervision data: All status (event, action etc.) of the functions and the PIS
hardware health status: CPU, CP, I/O modules, etc. This information is generated by the PIS and sent to the CIS.
II. Archiving data: All the critical events and actions of PIS are logged together with their own time stamp, which are assigned directly by the triggering PLC .
The requirement of mini-CIS will be provided by PIS I&C RO to PBS 46, as per the technical and functional requirements of the respective PIS. The min-CIS requirement should be provided minimum 4-6 months before FAT. The PBS 46 will configure the mini-CIS system and send the same to PIS I&C RO.
Mini-CIS Hardware ArchitectureThe mini-CIS hardware architecture is composed ofI. A Dual Xeon E5-2418L industrial computer as specified in [RD4], used as
main hardware component, with the following network interfacesa. Interface with CIN P networkb. Interface with CIN A network
II. If required Slow/Fast Controller acting as CIS Protection Modules, with the following network interfacea. Interface with CIN P networkb. MC Interface between Fast CIS and Fast PIS modules
Mini-CIS software architecture The following software are installed in the industrial computer
I. Red Hat Linux Operating System 6.4 or above.II. Siemens WinCC OA 3.13 server.
III. Siemens WinCC OA software is configured to be connected to the PIS slow controller/Fast controller.
IV. Min-CIS HMI developed in WinCC OA for the testing
Page 68 of 90
If required the min-CIS Slow/Fast controller is provided with developed necessary interface software
The FAT and SAT of a PIS including testing of all interfaces can be carried out using Mini-CIS.
There may be more than one mini-CIS available at IO to allow simultaneous FAT and SAT of different PIS, and they can be adapted for each particular case.
2) Mini-CODAC as CODAC substitution Tool Mini-CODAC is used to test the interfaces between each plant system (including PIS) and CODAC, so that after the plant systems FAT and SAT, the final integration is painless (acting as a plug-and-play module).Configuration of the PSH and Mini-CODAC – used as a local CODAC system – is a task ofthe plant system I&C supplierIn order to check the appropriate configuration of the PIS NTP synchronization, Mini-CODAC able to run NTP server services.
3) Plant System Equipment Substitution Tool
If some Plant System Equipment is not available, it is recommended to implement a Plant System Equipment Substitutional Tool to simulate the unavailable Plant System Equipment in order to facilitate the functionality tests.Depending on the amount and the type of I/O managed by the PIS and the complexity of the logical interconnection between them, two options are proposed:I. Test bench If a few I/O cannot be connected to real equipment and do not present a lot of logical interconnections, it may be considered to implement a small test bench with digital inputs connected to buttons and/or contact of relays, digital outputs connected to indicator and/or relays and analogue inputs connected to calibrator .
II. Plant System Equipment SimulatorsIf a lot of I/O cannot be connected to real equipment or present a lot of logical interconnections, it may be useful to implement a controller-based Plant System Equipment simulator.In any case, the Plant System Equipment Simulation Tools shall be ready, documented and checked before the beginning of the FAT activities. The documentations shall include the simulation tool hardware and internal logic description, connection to PIS I/O procedures, operator interface manual and the Simulation Tool test report.
4) Other Tools
- Multi-Channel Oscilloscope- Tester: multi-purpose- Safety Specification Tester ( Recommended : MI-2094: metrel)
Page 69 of 90
7.1.6. Recommendations for checking the interfaces
It is highly recommended to check the interfaces with the CIS as far as possible during the FAT.The following sections aim at mapping the main verification activities recommended for checking the interfaces with the CIS to the 4 - campaign Plant System I&C FAT organization model. The scope of these recommendations is limited to the verification of the appropriate implementation in the PIS, and is described in the next sections.
7.1.6.1. 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.
7.1.6.2. 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.)
7.1.6.3. C3 campaign: I&C configuration data and software
Page 70 of 90
- To check the CIN Plant System network switches configuration (e.g. IP address, time synchronization management etc.)
- To check the compatibility of the programming environment used by Plant System designers for programming of Slow/Fast PIS, with the programming environment installed on the CIS Engineering Workstation.
- To check the delivered software applications including the configuration of the Slow/Fast PIS regarding the CIS interface important details.
- To validate the CIS Multiproject integration compatibility by integrating into the CIS multiproject the delivered slow PIS software applications project
For Slow Controllers:To check the delivered software applications including the configuration of the PIS controller(s) regarding the CIS interface important details:
o Project data (e.g. name, properties, etc.), devices (e.g. type, name, etc.), networks (e.g. type, name, etc.)
o Network configuration (e.g. connection type, connection ID, etc.)o Hardware configuration (e.g. component properties, component name, etc.)o Standard program (e.g. data blocks, communication function blocks, etc.)o Safety program (e.g. data blocks, communication function blocks, etc.)
For Fast Controllers:Check the coherence of the delivered software package with the setup required for the specific PIS. More in detail:
LabVIEW FPGA project name has to reflect the setup of the F-PIS
Network configuration of the Host PC (e.g. connection type, connection ID, etc.)
Hardware configuration of cRIOs (e.g. type of modules installed, slot used, etc.)
IRIO calls in the Host PC’s program have to match the cRIOs serial numbers, bitfile and header file names
cRIOs’ bitfile and header file have to correspond to the LabVIEW FPGA project from which they were compiled.
7.1.6.4. 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 71 of 90
- To check that the CIN Plant System network switches functional requirements are met.
o PIS interface with PIS Engineering Workstation
- These verifications aim at checking the physical connections up to the CIN Plant System network switches, part of the interface configuration, and part of the IP Access protection configuration, the password protection configuration and the number of connection resources.
- These verifications should take place with the PIS Engineering Workstation at suppliers’ premises and with other workstations (if required) at IO site.
- Check the connection establishment via CIN-P wherever applicable.
o To check the NTP synchronization: NTP synchronization is through the PON. Normally mini-CODAC will be used for NTP server at supplier premises.
o To check the S7-IE connection: These verifications aim at checking part of the interface configuration, part of the IP Access protection configuration, the number of connection resources, the exchanged variables and the override protocol implementation. These verifications should take place with the min-CIS at suppliers’ premises and with the CIS SCADA Servers at IO site.
o To check the S7-TSPP connection if any: Checking part of the interface configuration, the communication configuration and the exchanged variables. These verifications should take place with a mini-CIS at suppliers’ premises and with the CIS SCADA Servers at IO site.
o PIS PLC interface with CIS PLC (safety-related communication) if any
- Checking the interface configuration, the safety-related communication configuration, the exchanged variables and the degraded/fault modes.
- These verifications should take place with the CIS PLC at IO site. If a PLC system available in min-CIS as CIS PLC Substitution Tool at suppliers’ premises, (part of) these verifications could also take place with the min-CIS
o To check the functional interface specificationsThe verifications described in above sections aim at checking the appropriate configuration of the interfaces according to the interface specifications. It is highly recommended to complement these verifications by others in order to validate the interface specifications. It may be considered
- Check the local Interlock functions or part of central interlock functions performed by the PIS, including the control and monitoring interfaces.
- Check the operation and maintenance procedures requiring the usage of the SCADA (e.g. function and system monitoring interfaces, reset procedures in case of function trip and in case of system failure, maintenance procedures requiring operator overrides).
Page 72 of 90
- Check all the mechanisms that are considered to be implemented in PIS PLC in order to improve the reliability of the operator overrides.
o To check the interface interactions in potential abnormal situationsIt is also highly recommended to check the following potential abnormal situations. These verifications should take place at supplier site with the mini-CIS platform.:
- Loss of communication with the CIS SCADA - Start-up of the CIN while the PIS and the CIS are already running.- Start-up of the PIS while the CIS is already running- Start-up of the CIS while the PIS is already running
For Fast Controllers:o Check the network connectivity of the Host PC to CINo Check the PIS cRIO interface with CIS cRIO, if present
- Test the Manchester coded communication between fast controllers. - This verification should take place with the CIS cRIO at IO site or with a mini-cis
cRIO at suppliers’ premises.
o Check the Host PC interface with PIS Engineering Workstationo Check the PTP synchronization of the Host PC through the TCNo Check the interface behaviour in potential abnormal situations
It is also highly recommended to check the following potential abnormal situations. These verifications should take place at supplier site with the mini-CIS platform.
- Loss of communication with the CIS SCADA - Start-up of the CIN while the F-PIS and the CIS are already running.- Start-up of the F-PIS while the CIS is already running- Start-up of the CIS while the F-PIS is already running
7.2 Multiproject Integration Procedure
In slow PIS case, a Step 7 Multi-project approach is adopted. Successful integration of the PIS project into CIS multi project is main step of integration. Following section describes how the Multi-project integration has been performed during SAT.
Page 73 of 90
7.2.1. First Connection of a New PIS (one or several PLCs) to the CIS
CIS Multiproject PIS Project removed from MiniCIS Multiproject WinCC OA Project
Import PIS project in CIS MultiProject
on CIS Workstation
Configure Communication Between PIS and CIS
(Using Netpro Configuration)
Configure Supervision data for WinCC OA
Compilation of CIS Multiproject is OK ? Update CIS Multiproject
CIS Multiproject Ready for SAT
NO
YES
Figure 24: First Connection of New PIS with CIS
Page 74 of 90
Above-mentioned flowchart describes first connection of a new Slow PIS to CIS.
The project administrator manages the Multiproject at the master database, defines
the structure of projects (locally, if required), controls distributed transactions for
external authors, then transfers the incoming projects to the Multiproject, adjusts
the cross-project data via the system functions ( file update synchronization ) and
executes necessary cross-project functions.
The IO CIS lead engineer start the integration importing the PIS local release into
the Multiproject, the shared communication are configured and the project
compiled and downloaded the into each PLC involved. A temporary version tag
of the software is generated and saved into SVN.
All the tests are performed and a new developing phase will start if a PIS or a CIS
functionality will fails. If all tests are passed the Multiproject and the PIS project
will be released and confirmed the SVN version tag. The saved Multiproject will
include also all the PLC source code and configuration managed with the
Multiproject.
7.2.2. Update of a PIS configuration
The update of PIS project is like a new development of it, so all the coding and test phases needs to be done; when the update and test are completed a new version of the PIS project will be released and saved. There are two possible cases for update of PIS configuration:
Update of a PIS configuration (hardware and/or software) not affecting central
functions/monitoring/and so on
Update of at PIS configuration (hardware and/or software) affecting central
functions/monitoring/and so on
7.2.2.1. Update of PIS Configuration (Hardware and/or Software) Without Affecting Central Functions/Monitoring
The development begins from the last Multiproject release for CIS and PIS.
Update the PIS project and perform the local function test , if passed all the test
release the update PIS project
Page 75 of 90
As the PIS update does not affect the central functionalities there is no need to
update the CIS configuration, all the previous settings in the CIS are still good for
the new PIS project.
WinCC OA configuration doesn’t need to be updated as the data exchanged with
the Supervisor Module are not changed.
Import the updated PIS project into CIS Multiporject and perform the tests.
A phase of testing is required in order to verify all the central and local
functionality.
If all test passed a new CIS Multiproject is released and the SVN version tag
confirmed.
Page 76 of 90
Figure 25: Update PIS Configuration without affecting central functions
Page 77 of 90
7.2.2.2. Update of PIS Configuration (Hardware and/or Software) Affecting Central Functions/Monitoring
Figure 26: Update of PIS affecting Central Functions
Page 78 of 90
When a PIS update affects the central functionality, a phase of redesign coding and testing is required.
If CIS project is affected by the PIS update then all the technical specification need
to be reviewed and updated. A new phase of coding and testing will start following
the new specification.
When the new CIS Project is developed and ready to integrate the PIS Project, the
IO CIS lead engineer start the integration import the updated PIS local release into
the Multiproject, configure the shared communication between them compile and
download the software into each PLC involved. A temporary version tag is
released.
The integration of the Multiproject with WinCC OA is done, and a Central testing
phase starts, if a PIS or a CIS functionality will fail a new update phase needs to be
done.
If the entire tests are passed, the Multiproject and the PIS project will be released
and the SVN version tag confirmed.
7.3 Recommendation for SAT of PIS
From the CENTRAL I&C perspective, the SAT objective is to check the readiness of the plant system I&C for integration with CENTRAL I&C systems and infrastructure and to check the readiness of the plant system I&C for integrated commissioning.
7.3.1. On-Site Integration Context
The On-site Integration consists in three main steps:
Installation phase
Acceptance phase
Integrated Commissioning phase
Refer to [RD28] ITER On-Site Testing Strategy (ITER_D_44U2Y4) and to [RD1] Plant Control Design Handbook (ITER_D_27LH2V) for additional explanations.
7.3.2. Plant System SAT Context
Page 79 of 90
As explained in section 3.4.6 of [RD1] Plant Control Design Handbook
(ITER_D_27LH2V), Plant System Site Acceptance Test (SAT) is intended to
check the conformity with IO requirements of the plant system procurement first
as stand-alone.
Plant System I&C SAT is a part of the plant system SAT. All I&C components in
the procurement shall be powered and tested during SAT. The guidelines for plant
system integration [RD10] Plant System I&C Integration Plan
(ITER_D_3VVU9W) provide further details on SAT of plant system I&C. In
section 3.4.6 of [RD1] Plant Control Design Handbook (ITER_D_27LH2V), for
process control and performance test purpose, the plant system shall be tested
under a scenario and acceptance criteria provided by the ITER plant system RO.
This scenario shall include the individual tests of every plant system I&C function
with the real process connected to the plant system I&C and the test of the plant
system as a complete autonomous system as close as possible.
Attention shall be paid to checking of the proper operation of the whole plant
system (no adverse interactions between the different components affecting each
other operation).
Interlock Functional Assessment must be carried out in order to test failure modes
and improve integration results.
7.3.3. Recommendations / Requirements about the methodology
Refer to [RD28] ITER On-Site Testing Strategy (ITER_D_44U2Y4), to the sections
3.4.5 and 3.4.6 of [RD1] Plant Control Design Handbook (ITER_D_27LH2V) and to
the Clauses of [AS2] IEC 61511-1 and IEC 61508 for general
recommendations/requirements.
Refer also to section 7.1.4 recommendations about the methodology for FAT.
Generally for each campaign, the beginning of the campaign during the SAT is first a
repeat of the corresponding campaign during the FAT.
Page 80 of 90
7.3.4. Recommendations for on-site integration activities
C1 campaign: I&C Documentation
Site Reception and Installation
C2 campaign: I&C Hardware
Electrical Safety Hazard Inspection
C3 campaign: I&C Configuration data and Software
Powering/Software Integration/ Connections to central I&C systems
C4 campaign: I&C Functional Requirement
Interlock function Assessment
System Acceptance
Onsite Integration Readiness
Page 81 of 90
Figure 27: Steps involved in onsite Integration
The scope of the on-site integration activities is normally the whole Plant System. The scope of this document being limited to I&C systems dedicated to the PIS, this section provides details only about the PIS related on-site integration activities.
7.3.4.1. On-site integration readiness
It is recommended to check that:
- FAT issues are solved
- The deliverables documents are stored in IDM
- The hardware deliverables are ready for shipping
- The software deliverables are stored in the correct IO repository
- IO Site is ready for reception (Buildings RFE as identified in Figure 4 of [RD28] ITER On-Site Testing Strategy (ITER_D_44U2Y4): Building, CIS, SSEN, etc. ready)
7.3.4.2. C1 campaign: I&C documentation
For performing this campaign during SAT of PIS, please Refer 7.1.5.1
7.3.4.3. Site Reception and Installation
Site Delivery Components (cubicles, cables, field devices, etc.). List of delivered components
Site Reception Check the compliance of the components with the list of delivered components. Damage checking by visual inspection
Site Installation Components are installed at appropriate locations:- Cubicles are installed at their final place.- Sensitive equipment packed separately is properly remounted.- Field devices are installed at their final place.- Spare and maintenance tools are installed at their final storage
location.
Internal Cabling/Wiring
Cabling/Wiring between the Plant System components.
External Cabling/Wiring
Cabling/Wiring with interfacing components- Interfaces with PBS.43 (power supply – earth)Pre-requisites:- Lock and tag of the appropriate circuit breakers- Power supply cables are installed
Page 82 of 90
- Earth connection points are installed
Installation Procedure:- Get the authorization to proceed- Connect the power supply cables and the earth.- Request for cabling inspection.- Get the cabling acceptance.- Lock and tag the main switch disconnectors- Get the authorization to test the interface.- Test the interface (e.g. check the voltage before and after the
circuit breaker)- Switch on the circuit breaker, check the voltage before and
after the circuit breaker, check the voltage before and after the main switch disconnector, etc.)
Interfaces with PBS.46 (CIS)Pre-requisites:- CNP are installed- Deactivation of the appropriate ports of the network switches
located in Network hutchInstallation Procedure:- Get the authorization to proceed- Connect the optic fiber cable in the CNP- Request for cabling inspection- Get the cabling acceptanceInterfaces with others if any
7.3.4.4. C2 campaign: I&C hardware
It is recommended to check that:
All the installation issues are solved.
The hardware deliverables are installed at appropriate location.
The hardware deliverables do not present any damage.
The hardware deliverables satisfy manufacturers’ recommendations.
The hardware deliverables are in conformance with the documentation:
- PIS Hardware is in conformance with PIS Manufacturing Description documentation (e.g. PIS cubicles hardware configuration diagrams including cubicle layout, cubicle internal wiring diagram, terminals description, cables list and material list),
- PIS On-site installation plan (e.g. cabling documents for all the PIS cubicles connections),
Page 83 of 90
- PIS operation and maintenance document (e.g. Schematic diagrams of the full signal path from the sensors/actuators to the I/O boards of the PIS including powering and conditioning, with identification of test point for fault analysis or calibration and identification of the terminal blocks).
- PIS I&C Spare parts are in conformance with appropriate specifications of storage space and conditions.
- Tools required for maintenance of any PIS I&C component are in conformance with PIS Operation and maintenance document
Rules/requirements/recommendations applicable to hardware deliverables that were not checkable during C1 campaign (non-documented information) are satisfied
7.3.4.5. Electrical Safety Hazard Inspection
Carry out an electrical hazard safety inspection to get the authorization to power the PIS.
7.3.4.6. C3 campaign: I&C configuration data and software
For performing this campaign during SAT of PIS, please refer 7.1.5.3.
7.3.4.7. Powering / Software integration / Connection to central I&C system
Powering Pre-requisites:- Administrative authorizations.- No worker on the installation.- Lock and tag of the actuators power circuit.- For slow PIS PLC CPU in STOP- In case of Fast PIS cRIO chassis should be OFF. ,
Procedure:- Check that all the circuit breakers and all the power
supplies are off- Check the voltage before and after the main switch
disconnector.- Switch on the main switch disconnector.- Check the voltage before and after the main switch
disconnector.- Check that the corresponding green power light is on
etc.Note: If the lock and tag of the actuators power circuit, do not guarantee the avoidance of any unexpected automatic action, which could potentially damage the plant system, take appropriate measures.
Page 84 of 90
Field devices configuration Field devices calibration/configuration if necessary and tests.
Network switches configuration
Procedures:- Download the network switches configuration - Check the on-line network switches configuration.
For Slow PIS:
PLC Hardware configuration
Procedures:- Reset the CPU- Download the hardware configuration- Check the on-line configuration
Note: At this level, the check list shall validate that the PLC can be connected to the CINwithout any damage
- Check all the inputs from the sensors up to the input modules (cabling, logic, sensors installation, etc.)
- Check all the outputs from the output modules up to the end of the control circuit (cabling, logic, etc.)
Note: If the lock and tag of the actuators power circuit, do not guarantee the avoidance of any potential damage to the plant system when manually activating some outputs, take appropriate measures.
Network connection Activate the appropriate ports of the network switches located in Network hutch
PLC Software downloading Download the software with the PBS.46 CIS Engineering Workstation:
- Download the hardware configuration.- Download the S7 program.- Check if the downloading was successful.
Note: If the lock and tag of the actuators power circuit do not guarantee the avoidance of any unexpected automatic action which could potentially damage the plant system, take appropriate measures (e.g. put the CPU in STOP)
- Put the CPU in RUN if required- Check the system state
Note: If the lock and tag of the actuators power circuit do not guarantee the avoidance of any unexpected automatic action which could potentially damage the plant system, take appropriate measures before switching the CPU to RUN mode.
For Fast PIS
Network connection Activate the appropriate ports of the network switches located in Network hutch
Page 85 of 90
Fast PIS Software downloading
Download the software with the PBS.46 CIS Engineering Workstation .Download the configuration project on the Host PCExecute the script that runs the program which download the bitfile to the chassis
- Check if the downloading was successful.- Check the system state
7.3.4.8. C4 campaign: I&C functional requirements
Figure 28: Steps involved in C4 Campaign
1. C4 campaign: I&C functional requirements readinessA Plant system is normally ready for the functional tests if the following criteria are met:
- Installation and commissioning issues are solved- All the Plant System components are operational
Page 86 of 90
- The PIS is ready- The test operator is ready to proceed- Administrative authorizations are obtained
For organizational reasons, it may be considered to repeat the tests performed during the FAT C4 campaign: I&C functional tests at the beginning of the SAT C4 campaign: I&C functional requirements, in order to check the Plant System components separately as much as possible before the overall Plant system functional tests. In case of the resolution of FAT, installation and commissioning issues have required a lot of modifications, this intermediate phase is highly recommended.
2. To check the state of the Plant SystemFor Slow PIS
Field Devices To check that the field devices are in appropriate state
PIS Controllers - To check that the modules are ok (e.g. power supply, interface modules, signal modules).
- To check that the CPU is/are running.- To check that the inputs are consistent with field devices.- To check that the field devices are consistent with the outputs.- To check the ability to monitor the system with the CIS
Engineering Workstation Via CIN-P 1 and CIN-P 2 - To check that communication links are established / interfacing
components are reachable.I. S7-IE interface with SCADA Server in MSR and BSR via
CIN-P1II. S7-IE interface with SCADA Server in MSR and BSR via
CIN-P2III. S7-TSPP interface with SCADA Server S7-IE interface
with SCADA Server in MSR and BSR via CIN-P1IV. S7-TSPP interface with SCADA Server S7-IE interface
with SCADA Server in MSR and BSR via CIN-P2V. NTP synchronization with CODAC
VI. Fail-safe communication interface with CIS protection module PLC via CIN – P1 and CIN – P2 ( if PIS participates in CIS functions )
- To check the performance of the slow PIS I. To check the maximum cycle time and its maximum
allowed valueII. To check the standard program execution time, its
maximum allowed value and the alarm in case of over valueIII. To check the safety program execution time, its maximum
allowed value and the alarm in case of over value
Page 87 of 90
For Fast PIS
Field Devices To check that the field devices are in appropriate state
PIS Controllers - To check that the modules are ok (e.g. power supply, diagnostic modules, signal modules).
- To check that the both cRIO chassis are running.- To check that the inputs are consistent with field devices.- To check that the outputs are consistent with the field devices.- To check the ability to access the system with the CIS
Engineering Workstation Via CIN-P 1 and CIN-P 2 - To check that communication links are established and
interfacing components are reachable.I. Host PC interface with SCADA Server in MSR and BSR
via CIN-P1II. Host PC interface with SCADA Server in MSR and BSR
via CIN-P2III. PTP synchronization with CODACIV. Manchester communication interface with CIS fast
protection module PLC via fiber optics links ( if PIS participates in CIS functions )
3. To check the functions implemented by hardwired logic ( if any)In ICS some special interlock functions are implemented using BLIB and DLIBS hardwire architectures. Functions implemented by these hardwire logic need to be checked.
4. To check the functions implemented by the controllers
Interlock Function test :
To check the local and part of central interlock functions (if any) (including its monitoring):- To check all the event cases (combinations of input
depending of the voter)- To check all the action cases (combinations of output
depending on the voter)- To check the reset procedure- To check the operation/maintenance procedure (e.g. requiring
overrides)System monitoring functions:
For Slow PIS :- To check the safety program signature monitoring- To check the safety mode state monitoring
Page 88 of 90
- To check the PLC date/time monitoring
For Fast PIS :- To check the HOST PC date/time monitoring
5. To check the degraded / fault modesFor Slow PIS
Field devices To check the Field Devices degraded/fault modes
PIS Cubicle To check the fault mode: loss of signal power supply
Slow PIS controller(s)
- To check the degraded mode: loss of signal power supply Class II-IP
- To check the degraded mode: loss of signal power supply Class IV
- To check the fault mode: loss of both signal power supply- To check the degraded/fault mode: loss of signal modules- To check the degraded/fault mode: loss of interface modules- To check the degraded/fault mode: loss of fieldbus- To check the degraded mode: loss of CPU power supply Class
II-IP- To check the degraded mode: loss of CPU power supply Class
IV- To check the degraded/fault mode: loss of both CPU power
supply- To check the degraded/fault mode CPU in STOP- To check the alarm: battery failure- To check the alarm: back-up voltage failure- To check the degraded mode: loss of network connection to
CIN-P 1- To check the degraded mode: loss of network connection to
CIN-P 2- To check the degraded/fault mode: loss of both connections to
CIN - To check the CPU state monitoring
(RUN/STOP/STARTUP/UPDATE/etc. and Master/slave (if Fully fault tolerant PIS )
In case of Fully fault tolerant PIS: - To check the degraded mode: synchronization failure leading to
slave CPU in STOP- To check the fault mode: synchronization failure leading to two
Master CPU in RUN
Page 89 of 90
Power Distribution - Check the fault mode: loss of power distribution to the plant interlock system cubical(s)
- Class II-IP power supply (switch off the main switch disconnector).
- To check the error-free recovery (switch on the main switch disconnector).
- Class IV power supply (switch off the main switch disconnector).
- To check the error-free recovery (switch on the main switch disconnector).
PIS interfacing components
- To check the degraded mode: loss of CIS SM server in MSR- To check the degraded mode: loss of CIS SM Server in BSR- To check the fault mode: loss of both SM Servers- To check the degraded mode: loss of CIS protection module in
MSR (if required)- To check the degraded mode: loss of CIS protection module in
BSR (if required)- To check the fault mode: loss of both CIS protection module ( if
required)- To check the degraded mode: loss of CIN-P 1- To check the degraded mode: loss of CIN-P 2- To check the fault mode: loss of both CIN branches
For Fast PIS
Field devices Tests are same as Slow PIS
PIS Cubicle Tests are same as Slow PIS
Fast PIS controller (s)
- To check the degrade mode: loss of cRIO Chassis 1 or 2 power supply Class II-IP
- To check the degraded mode: loss of cRIO Chassis 1 or 2 power supply Class IV
- To check the fault mode: loss of both power supply (Class II-IP and IV) of cRIO Chassis 1 or 2
- To check the degrade mode: loss of Host PC power supply Class II-IP
- To check the degraded mode: loss of Host PC power supply Class IV
- To check the fault mode: loss of both power supply (Class II-IP and IV) of Host PC
- To check the degraded mode if cRIO Chassis 1 or 2 are back to “initialization state”
- To check the fault mode cRIO if Chassis 1 and 2 are back to “initialization state”
- To check the degraded mode: loss of network connection to CIN-P 1
Page 90 of 90
- To check the degraded mode: loss of network connection to CIN-P 2
- To check the degraded mode: loss of both connections to CIN-P
- To check the degraded mode: interchassis synchronization failure between two cRIO Chassis
- To check the degraded/fault mode: loss of modules detection
Power Distribution Tests are same as Slow PIS
PIS interfacing components
Tests are same as Slow PIS
6. To check the operator/maintenance procedures To check operation and Periodic tests procedures (if not checked during the C2 hardware campaign or during the verification of the functions) and calibration procedure (if not checked during field devices configuration).
7. To check the performancesIn the performance test of PIS (slow/fast) Immunity to typical environmental conditions, response time, spurious trip rate, accuracy, etc. are tested As explained in section 3.2.6 and Figure 1 of [RD26] ITER On-Site Testing Strategy (ITER_D_44U2Y4), acceptance phase may be split in two phases:
- Provisional acceptance phase and- Final acceptance phase.
This typically allows addressing part of the performance tests (e.g. spurious trip rate) during the final acceptance phase even if performance tests such as response time measurements must be addressed as much as possible during the provisional acceptance phase.
7.3.4.9. Functional Assessment
It is recommended to organize a interlock functional assessment (if possible, undertaken by an independent organization).The assessment team shall confirm that:- The risk assessment has been carried out as per [RD3] .- The recommendations arising from the FMEA (or HAZOP or STPA) have been
properly implemented- All the means of risk reductions are designed, constructed and installed in accordance
with the interlock system requirement specification- The validation plan is appropriate and the validation activities have been completed- The operating and maintenance procedures are in place