references: io/cfe/12/7512/fmr plc (spss) iter …...references: io/cfe/12/7512/fmr engineering...

References: IO/CFE/12/7512/FMR

Engineering support in the Standard PLC Software Structure (SPSS) Development.

（標準 PLCソフトウエア構造(SPSS)開発への技術支援）

締め切り 7月 3日(火)12時現地時間、7月 3日（火）19時日本時間

（応募書類は ITER機構へ直接提出）

概要：

ITER機構では、標準 PLCソフトウエア構造(the Standard PLC Software Structure ：以下 SPSS

と記す)開発の支援を頂く技術者を、ITER 参加極の企業・機関等から募集しています。応募

を希望される企業・機関等は、所定の期限までに応募書類を直接 ITER機構の下記担当までご

提出下さい。

○ 主な作業内容

・ワークフロー分析：ワークフローと使用例（ユースケース）の定義化。アプリケーショ

ンの開発者が SPSS を使用する異なる状況を規定する作業。例：初期開発、PLCコアアプ

リケーションのメンテナンス、SPSSのメンテナンス、インターフェースの修正

・冗長化アーキテクチャーの対応：現在ある SPSSを改善し冗長化（二重化、三重化）アー

キテクチャに対応できるようにする。EPICSドライバの開発も含まれる。

・ CODACインターフェース拡張作業： CODACインターフェースの SPSSの改善。データフロ

ーの差別化。例：スタティック・コンフィグレーション、揮発性コンフィグレーション、

生データ、PLCモニタリングデータ、タイムスタンピング精度等。

・高速コントローラ・インターフェース：高速コントローラインターフェースのサポート

○主な経験

・電子/コンピュータ科学/電気力学系の大学卒業か同等の学位があり、少なくとも８年間以

上の PLCの経験を有する。

・プログラミング言語である構造化テキストのプログラミング言語の使用経験を有す他。

○作業場所

・ITER機構（仏カダラッシュ）。

○契約期間

・2年。

○その他

・本契約者は、ITER機構(IO)のタスク責任者の指示のもとインクリメント・アジャイルアプ

ローチといった短い開発サイクル（1，2週間）での作業を行う。コンプリートテスト・シミ

ュレーション・インフラストラクチャはカダッシュの ITERサイトで実施する。報告書の作成

などサブタスクについては契約の範囲内であればオフサイトでも実施可能。本契約者は ITER

機構宛て、月例プログレス・レポートに添付されたタイムシートをもとに毎月請求書を提出

する。支払いは月例プログレスレポートの受理(承認)を持って行われる。

・契約者は、本業務の遂行にあたり、利害の対立が生じないようにすること。

・契約者は、ITERプロジェクトにおいて契約を得ようとしている企業と関係を有しないこと。

・契約者は、本業務を通じて得た情報に対して秘密保持が義務づけられる。

・ITER機構が面接（電話、ビデオ会議など）を行うことがある。

・ITER機構の規定にしたがい、日当の上限は 500ユーロ。

○提出書類

・履歴書(CV)

・日当提案書

・誓約書

○応募書類提出先

・ITER機構の下記担当者宛に電子メールにて送付

[email protected]

○応募書類提出期限

・2012年 7月 3日(火) 12：00(CET)現地時間、7月 3日（火）19時日本時間

mailto:[email protected]

PDF generated on 15-Jun-2012DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

Memorandum / Note

SPSS Technical Specification

The Standard PLC Software Structure is the backbone of all PLCs deployed on the ITER Project. This document is describing the functionnalities that the SPSS should support, the context and the scope of application.

Approval Process Name Action AffiliationAuthor Evrard B. 13-Jun-2012:signed IO/DG/DIP/CHD/CSD/PCICoAuthorReviewers Moynier F. 14-Jun-2012:recommended IO/DG/ADM/DGA/PCDApprover Yonekawa I. 15-Jun-2012:approved IO/DG/DIP/CHD/CSD/PCI

Document Security: level 1 (IO unclassified)RO: Evrard Bruno

Read Access LG: PLC group, LG: CODAC team, AD: ITER, AD: External Collaborators, AD: Section - Plant Control and Instrumentation, project administrator, RO

IDM UID

6SRGGZVERSION CREATED ON / VERSION / STATUS

13 Jun 2012 / 1.3/ Approved

EXTERNAL REFERENCE


Change LogTitle (Uid) Version Latest Status Issue Date Description of Change

SPSS Technical Specification (6SRGGZ_v1_3)

v1.3 Approved 13 Jun 2012 - Removed reference to Profile Description. Has been moved to SPSS Service Contract Specification.


v1.2 Signed 30 May 2012

Answered to comments. Addition of a chapter: Technical Profile Description.


v1.1 Approved 23 Apr 2012

Minor Modifications: integration of reviewer comments.


v1.0 Approved 17 Feb 2012

SPSS Technical Specification Page 1 of 25

Table of Contents

Table of Contents ........................................................................................................................1Table of Figures...........................................................................................................................21 Introduction.........................................................................................................................3

1.1 Purpose of document ..................................................................................................31.2 Scope.............................................................................................................................31.3 Acronyms.....................................................................................................................31.4 Definitions....................................................................................................................31.5 Reference Documents .................................................................................................4

2 Technical Context ...............................................................................................................53 Generic Requirements of PLC Applications at ITER.....................................................74 Conceptual Architecture of a PLC application................................................................8

4.1 PLC Core Application ................................................................................................94.2 CODAC Interface .....................................................................................................10

4.2.1 Configuration Variables..........................................................................................114.2.2 State Variables ........................................................................................................114.2.3 Simple Commands ..................................................................................................114.2.4 Collaborative Data ..................................................................................................114.2.5 Data Types ..............................................................................................................124.2.6 Redundant Architectures.........................................................................................13

4.3 Hardware Interface ..................................................................................................144.3.1 General Description ................................................................................................144.3.2 Interface Switch ......................................................................................................154.3.3 Filtering...................................................................................................................164.3.4 Engineering Limits..................................................................................................164.3.5 FBS Wrapper ..........................................................................................................164.3.6 Adaptation...............................................................................................................164.3.7 Forcing ....................................................................................................................174.3.8 SIL PLCs.................................................................................................................17

4.4 PLC Interface ............................................................................................................174.5 Fast Controller Interface..........................................................................................184.6 System Monitoring....................................................................................................18

5 Standard PLC Software Structure (SPSS) .....................................................................205.1 Description.................................................................................................................205.2 CODAC Interface in the SPSS.................................................................................21

6 Future Development .........................................................................................................24


Table of FiguresFigure 1: CODAC Architecture ________________________________________________5Figure 2: PLC Conceptual Architecture__________________________________________8Figure 3: PLC Core Application Environment_____________________________________9Figure 4: Simple Example of CODAC HMI ______________________________________10Figure 5: Collaborative Data _________________________________________________12Figure 6: Hardware Inputs/Outputs Interface Block Diagram _______________________14Figure 7 : Main Cycle Loop Standard Structure __________________________________20Figure 8 : CODAC Interface Standard Structure__________________________________21Figure 9 : Warm Restart Block Standard Structure ________________________________21Figure 10:UDTs and DBs organisation and dependencies for the Control Function

“CWS-DHLT-WFC”. ___________________________________________22Figure 11:UDTs and DBs organisation and dependencies for TCP connexion

parameters. ___________________________________________________23


1 Introduction

1.1 Purpose of document

The SPSS is a Software package that will be deployed on every PLC in the ITER project. This document gives a conceptual description of the Standard PLC Software Structure (SPSS). It lists what the SPSS is expected to do, and what is it covering. This document will be used as base of negotiation for a contract for the development of the SPSS.

1.2 Scope

The SPSS covers: The PLC deployed as Conventional Controllers. The redundant PLCs deployed as conventional Controllers, PIS and PSS for

occupational Safety, up to a SIL3, and Nuclear Safety SIC2-C Controllers.

The SPSS doesn’t cover Fast Controllers, Nuclear Safety Controllers of categories SIC2-B and SIC1

1.3 Acronyms

CFC Continuous Flow ChartCOS Common Operating StateDB Data BlockFB Function BlockFBD Functional Block DiagramCBS Control Breakdown StructureCOTS Component Off-The-ShelfFC Function ChartI/Q Inputs/OutputsLAD Ladder DiagramPBS Plant Breakdown StructurePCDH Plant Control Design HandbookPIS Plant Interlock systemPLC Programmable Logic ControllerPSH Plant System HostPSS Plant Safety SystemSDD Self-Description DataSFB System Function BlockSFC System Function ChartSIC2-C Safety Important Component Level 2 – IEC61226 Category “C”SSPS Standard Software PLC StructureUDT User Data Type

1.4 Definitions


PLC Application All software developed in a PLC PLC Core Application All software or control blocks implementing the control

functions. All that is not implemented in the peripheral blocksShared DB variable Generic term used for any variable in a PLCProcess Variable Generic term used for a variable in the EPICS environment.Plant System I&C Programmer

Person responsible for programming CODAC, PLC or fast controller applications.

Peripheral Blocks PLC software blocks implementing the interfaces and healthmonitoring.

Configuration Set of all configuration variables for a PLC.Configuration Variable An EPICS PV transmitted to the PLC through a shared DB

variable. States Set of all PLC shared DB variables transmitted to CODAC. State Variable A PLC shared DB variable transmitted to CODAC through an

EPICS PV. Standard Control Block Interface

In and Out parameters of a FC or a FB for a control block deployed in the PLC core application

Control Function Function achieved by a controller in the context of a functional analysis.

Control Block FC of FB in the context of a Siemens Step 7 application, or any other controller.

1.5 Reference Documents

[RD 1] “I&C Signal and Process Variable Naming Convention”, ftp://ftp.iter.org//permanent_files/io_in_cad/com/www/codac/pcdh/SD01_v2_3.pdf

[RD 6] “Plant System I&C Architecture”, ftp://ftp.iter.org//permanent_files/io_in_cad/com/www/codac/pcdh/SD03_v7_4.pdf

ftp://ftp.iter.org/permanent_files/io_in_cad/com/www/codac/pcdh/SD01_v2_3.pdf

ftp://ftp.iter.org/permanent_files/io_in_cad/com/www/codac/pcdh/SD03_v7_4.pdf


2 Technical Context

CODACTerminal

CODAC Server

Channel AccessGateway

PlantSystem

Host

Actuators and Sensors

CODAC Server

CODAC servicesand applications

CODAC Server

CODAC services

CODACTerminalCentral supervision, monitoring and data handling

FastController

CODAC Server

Applications

CODAC Server

Archiving

CentralInterlockSystem

CentralSafety

System

CODAC CISInterface

CODAC CSSInterface

Plant System I&C

ITER Control Group

Safety Controller

SignalInterface

Interlock Controller

SignalInterface

SignalInterface

SignalInterface

SafetyDesk

TCN

CODAC HPCPlasmaControl

TCN

Human Machine Interface

Rest of the worldPON

PON

CIN CSN

FastController

COTSIntelligent

Device

RemoteI/O

RemoteI/O

SlowController

SlowController

TCN

AVN

AVN

DAN

DAN

LegendPON = Plant Operation Network DAN = Data Archive NetworkTCN = Time Communication Network CIN = Central Interlock NetworkSDN = Synchronous Databus Network CSN = Central Safety NetworkAVN = Audio Video Network

CINDAN

SDN

InterlockDesk

Figure 1: CODAC Architecture

The architecture of plant system I&C is defined in [RD 6]. The PLCs will communicate with CODAC through the PSH. The PSH is a standard computer running EPICS. Its configuration will be generated for each plant system I&C. The communication with Step7 PLCs will be done through TCP/IP socket communication. The general structure of the frames has already been settled.

The PSH will implement a State Machine called the COS which has to be synchronized with the State of the PLC.

PLCs inside a plant system may have functional interfaces with other PLCs, fast controllers and COTS intelligent devices. These interfaces will be supported by the PON.

In Figure 1, the “Slow Controllers”, the “Interlock Controller” and the “Safety Controller” can be implemented with PLCs. Slow Controllers can be conventional or redundant PLCs for higher availability. Interlock and Occupational Safety Controllers can be SIL1 to SIL3 PLCs. SIC2-C Safety controllers can be SIL3 controllers.


The Interlocks and Safety Controllers are separated from the conventional control, in strict compliance with IEC61508. Meanwhile, they could be connected to the CODAC, for monitoring purposes.


3 Generic Requirements of PLC Applications at ITER

- Flexibility.

o During integration and commissioning, all interfaces may be not available. The application should allow some signals to be forced, or the partial simulation of the missing interface.

- Maintainability

o Sufficient system information should be provided.

o The PLC application should be modular so that modifications have only local impact.

o The design of the application should take into account at least one major Hardware Upgrade. The underlying requirement is code portability.

- Ability to be tested.

o Unit testing of PLC Control Blocks should be easy.

o Control systems software should be tested independently from the system. The idea is to test the control system when it is connected to a simulator rather than the system. The plant system designer has to define beforehand which controllers have to be tested together.

- Readability

o Every information transformation in the data flow should be easy to track.


4 Conceptual Architecture of a PLC application.

7

3

PLC

CODAC interface

Hardware Outputs/Inputs Interface

4

PLC Interface

Plant Systems Equipment

Simulator

CODAC Core System

11

13 Fast Controller

Interface(s)6 Fast

Controller(s)

PLC(s)

2

1

7

System Monitoring

8

10

9 12

PLC Core Application

5

1

Figure 2: PLC Conceptual Architecture

The principle is to have a common architecture for applications inside all the PLCs deployed on the project. Depending on the particular PLC application, all the blocks may not be present. For example:

A “Master Controller”, in an I&C architecture (see [RD 6]) will not have any hardware Input/Output interface but will have a lot of interfaces with other PLCs in the plant system.

Fast controller interfaces will probably be very rare and may use the CODAC interface, as Fast Controllers are running EPICS and are consequently connected to Channel Access.

We expect that the internal structure of all blocks will be standard for all PLCs deployed on the project. Only the volume and structure of the data computed in these blocks will be different. In the future, we expect that these blocks will be generated automatically, using the configuration database as input. Meanwhile, we already know that in some cases it will be


difficult to have exactly the same structure. It will be developed in the following chapters. For conventional Controllers, The CODAC interface (“2”on Figure 2) will be fully generated by the SDD package.

In the document, Blocks 2, 3, 4, 5, 7 of Figure 2 are called the “Peripheral Blocks”, in the sense that these blocks embeds “peripheral” features. In opposition to the “PLC Core Application”, embedding the Central Logic.

4.1 PLC Core Application

The PLC core application (“1”on Figure 2) is the place where the control logic, GRAFCETS, state charts and regulation loops of the process will be implemented. Only process programming should be found here. The PLC core application will implement the control functions. Its functionality will be affected by all the interfaces on Figure 2. All programming or treatment not directly involving the process is performed in the peripheral blocks (interfaces, system monitoring).

CODAC Interface


Configuration Variables

Simple Commands

Collaborative Datas

State Variables

Hardware Outputs/Inputs interface

Outputs Inputs

ControllerInterface(s)

PLC

Figure 3: PLC Core Application Environment

The PLC core application will use the configuration variables (see Figure 3) transmitted by the CODAC interface as the main inputs from operation. Some configuration variable examples:

- ON/OFF state requests- OPEN/CLOSE state requests,- HIGH VACUUM/ROUGHING/VENTING request, - Current setpoint, - Temperature setpoint- …


Hardware inputs and outputs (See Figure 3) are in engineering format. The PLC core application is insensitive to the fact that these values may be coming from real equipment or are simulated or forced. The PLC core application will compute the CODAC configuration variables and the hardware inputs and generate the outputs in order to reach the configuration requested. The state variables report the effective state of the process. The main principle is that it is always possible to have an easy comparison in CODAC between the state (configuration) of the process that was requested and the actual state. A simple example of what a CODAC HMI for a simple device is given in Figure 4.

Power SupplyPower Supply

ON

0.0095.00Amps

Fuse OK

Water Cooling NOK

Temperature OK

Interlocks

24 VDC OK

Power OK

Configuration State

Amps

OFF

Power SupplyPower Supply

ON

95.0095.00Amps

Fuse OK

Water Cooling NOK

Temperature OK

Interlocks

24 VDC OK

Power OK

Configuration State

Amps

ON

Easy Comparaison of Configuration and State

Easy Comparaison of Configuration and State

Normal Operation Off - Normal Operation

Figure 4: Simple Example of CODAC HMI

Collaborative data (See Figure 3) are state variables produced by other plant systems and transmitted by CODAC core system. Transverse wired links between plant systems are strictly forbidden. Transmission of information between plant systems will use the collaborative data link. The interfaces with other controllers in same plant system I&C also have an impact on the processing and this aspect will be developed in § 4.4 and § 4.5.

4.2 CODAC Interface

The main function of the CODAC interface (“2”in Figure 2 ) is to manage the PLC side of the communication with CODAC, which is developed in an EPICS environment. The CODAC side of the communication is managed by a specific driver in the PSH .This communication decomposes in 4 categories, as represented in Figure 3:

- Configuration variables- State variables- Simple commands


- Collaborative data

4.2.1 Configuration Variables

The main use of configuration variables is described in § 4.1. In Figure 2 the link “8” shows another use of these variables: giving configuration to the hardware I/O interface. Mainly, it will provide conversion of parameters from physical to engineering units, forcing values and inhibits, it will also affect the simulation mode. It is described in § 4.3

4.2.2 State Variables

The state variables are used to transmit the state of the process:- Directly from the hardware I/O interface (“6”in Figure 2 ). This direct link is necessary

as the CODAC core applications use these variables without requiring computing in the PLC core application. It is important to note here that these variables are in engineering units, and they can also be forced or simulated.

- From the computed variables issued by the PLC core application (“7”in Figure 2 ). - From the system monitoring (“9”in Figure 2 ).

4.2.3 Simple Commands

Simple commands are variables set to “TRUE” during one cycle in the PLC. These simple commands are used in the cases where it is not necessary to memorize the action related to this command, as is the case for configuration variables. Typical examples are “Reset” of some devices. Reset is not a stable configuration, it is a transient command.

4.2.4 Collaborative Data

Collaborative data are state variables transmitted between plant system I&Cs. A strong requirement of the PCDH is that no transverse physical link is allowed between plant system I&Cs. Any such link must be in the form of a software link between 2 PLCs from 2 different plant system I&Cs. This collaborative data will be state variables with the specific classification of “Collaborative Data”. Note, that if several controllers have to share the same information (e.g. a temperature, or a pressure) it is important that this information has exactly the same origin.


Figure 5: Collaborative DataInterlock and Safety Controllers will not use this channel to communicate between them. They will always transmit their information through a Central Controller (CSS, CIS). It is strictly not recommended to use this channel to influence the behaviour of Safety and Interlock Controllers.

4.2.5 Data Types

In the following Table you can find the type association between Step 7 and EPICS performed in the CODAC Interface:

STEP 7 EPICSStates Variable Configuration,

Collaborative DataPV Type Data Type PV Type Data Type

BOOLEAN AI Int or short. 0x00 if FALSE0x01 if TRUE

AO Int or short. 0x00 if FALSE0x01 if TRUE

REAL AI Float 32 bits AO Float 32 bitsINT AI Short (signed) AO Short (signed)DINT AI Int (32 bits) (signed) AO Int (32 bits) (signed)WORD AI Unsigned short,

hexadecimal representation

AO Unsigned short, hexadecimal representation

DWORD AI Unsigned int (32bits), hexadecimal representation

AO Unsigned int (32bits), hexadecimal representation

TBD MBBI MBBO


For Simple Commands, it is a BOOLEAN variable on Step 7 Side. On EPICS Side, it is a bit that is set to “0x1” during 300msec. During these 300msecs, it is transmitted to the PLC. In the PLC, this bit has to be set to “TRUE” during one cycle of the PLC program.

4.2.6 Redundant Architectures

For High Availability, Interlock and Safety Controllers, redundant Architectures will be deployed. The CODAC Interface will take this feature into account.


4.3 Hardware Interface

4.3.1 General Description

FilteringLow-pass Anti-Rebounce

Codac Interface

Plant System Plant System Simulator

“Forcing” “Forcing”

Configuration

Digital

States


CBS Wrapper CBS Wrapper

Hardware Outputs interface

Analog

Engineering Limits

Analog Digital

AdaptationScaling Standardiza-tion AdaptationScaling Standardiza-

tion

Interface SwitchTCP/IPET200M

Interface SwitchTCP/IPET200M

Wiring TCP Socket

PLC

CODAC

Har

dwar

e In

puts

inte

rf ac e

Har

dwar

e O

u tpu

ts In

ter fa

ce

Figure 6: Hardware Inputs/Outputs Interface Block Diagram

The hardware interface is divided in two parts: the input interface and the output interface. Almost the same functions are present in both parts but they are processed in the opposite


order. The following process flow description of a wired input coming from a plant system explains the working of this interface:

- The signal is wired between the plant system and the input board of the PLC, or it comes from a Simulator, via a TCP/IP Connection. The layer “Interface Switch” selects the source of the data. It this same layer, the data are wrapped in a DB. Example, if data comes from wired inputs, then “I0.0” is copied to “DB1.DBX0.0”. All the data can afterwards manipulated with one single DB.

- The signal goes through a filtering layer. For Booleans, it is an anti-rebounce, for analog values, it is a low pass filter, suppressing the noise.

- The shared DB variable issued is transmitted to an “FBS Wrapper”, where the variable is copied from a component naming convention (“PPPPPP-TTT-NNNN:AAAASSSS”) to an CBS Level 3 convention (CBS-L3.variable). See [RD 1]. Another shared DB variable is issued.

- The signal goes through an “adaptation layer”. Depending of the nature of the signal, the processing is different:

o Numerical variable: “Scaling”. The signal is transformed to an engineering value according to a linear regression, or a look up table, etc…

o Boolean variable: “Standardization” here the Boolean value can be negated or not, depending on the logic the developer wants to use in the core application. For example, in order to have fail-safe logic, the status of a device could be notified by a “0V” signal, which is more convenient for encoding a “TRUE”.

- The variable goes through a “Forcing” layer, where its value can be forced by the user for commissioning or maintenance purposes. The variable is issued by the hardware input interface.

- The variable is systematically transmitted to the “States Variables” transmission mechanism of the CODAC Interface and can be used by the PLC core application.

For outputs, the processing is almost the same, except that there is no “Filtering Layer”, and that there is an additional “Engineering Limits” layer, preventing the writing of fanciful values.

For Interlock and Safety Controllers, the Hardware Inputs/Outputs interface will probably be reduced to something very simple, of might even be completely skipped. This is a description of a complex interface, while all what relates safety should remains simple.

The following paragraphs give a more detailed description of every layer.

4.3.2 Interface Switch

This layer has several functions: Inputs/Outputs will be wrapping in Shared DBs to directly use Siemens data block

addressing area (shared DB variables) at the lowest level. This has 2 advantages: - It is possible to place the information in systems and subsystems hierarchically.- All the variables can be handled with just one simple block.


Complex interfaces like FM453 positioning modules and CP441 serial communications modules will also be implemented in this layer.

There is a link between this layer and the health monitoring function. All the variables issued by the wrapper will be transmitted to the health monitoring system. The health monitoring system transmits these variables to the CODAC interface. The purpose is to have CODAC raw values available on a system screen for debugging purposes.

Connecting a process simulator to the controller gives the following possibilities:- Validation of the software without being connected to the process- During integration and commissioning, modification of the software and be able to test

these modifications on a different platform, before loading on the real control unit.The interface switch simply switches the origin of the signal variables between the real process and simulator. Whatever the simulator is, the interface will be a data block.The control of the interface switch will be a CODAC configuration variable (Figure 2 – “10”). This command has to have some security associated with it in the sense that it cannot be used during operation.

4.3.3 Filtering

4.3.3.1 Anti-Rebounce

This layer is used for digital signals. Extremely useful for detectors in order to have a clear transition. The time should be definable for each signal.

4.3.3.2 Low-Pass Filtering

Tis layer is used for analog values in order to remove noise.

4.3.4 Engineering Limits

For numerical outputs, it is necessary to set limits reflecting the limit of the actuator or of the physical process expressed in engineering format. If these limits are exceeded, the PLC output may be erroneous.The limits will be set by configuration variables.

4.3.5 FBS Wrapper

This block simply transfers the signal variables presented in a PBS naming convention (PPPPPP-TTT-NNN:AAAASSSS) to anCBS naming convention (CBS-L3.variable).

4.3.6 Adaptation

4.3.6.1 Standardization

The idea here is to standardize the code in the PLC core application as much as possible. The same type of devices should always be controlled with the same PLC function. In reality, the same type of devices will sometimes be wired with different logic. For example, a valve: the limit switches of some valves will be wired with positive logic (24VDC – position reached)


and some with negative logic (0VDC – position reached) whilst control of the valve is identical. The function of this standardization block would be to process the negation required for all discrete signals, in order to present a standard signal interface for the different types of devices to the PLC core application.All the negation parameters will be provided by CODAC configuration variables.

4.3.6.2 Scaling

Conversion from 16 bits integer to physical unit will be required for most of the numerical signal variables. This conversion can be linear, quadratic or of superior orders. It can also be a look-up table. All the conversion parameters will be provided by CODAC configuration variables.

4.3.7 Forcing

During integration, commissioning and sometimes during maintenance, it is normal that engineers will want to force some signal variables to a specific value, because the related signal is not connected, missing, is not operational or has failed. It is better to take this fact into account in the software design, so that this “irregular” (and possibly dangerous) behaviour will be controlled. The aim is to avoid dangerous “temporary-permanent” practices like forcing a signal with PLC hardcoded modifications, hardwired modifications, strapping of relays etc. This forcing layer has to be developed and in particular:

- some signals cannot be forced at any time because this could be destructive.- The control unit (or the all I&C) may not be able to reach an operational state as long as

signal variables are forced.- Inhibiting this forcing feature.

All permanent and runtime parameters will be provided by CODAC configuration variables.

4.3.8 SIL PLCs

With SIL PLCs, the organization of Inputs and outputs can become quite complex. You can have redundancies of signals, of acquisition chains, Votes 1oo2, 2oo3, etc…. Making the Hardware Interface much more complex if you want to reach the abstraction level described in this chapter.

4.4 PLC Interface

This interface addresses communications between: PLCs of a same plant system I&C, A Plant Safety or an Interlock Controller and its Central Controller,

for the case where a functional interface is required. The Siemens protocol to be used has to be defined. From a conceptual point of view, one can consider 3 different cases:

- A master/slave link where the master PLC is sending commands (Boolean or numerical) to a slave PLC


- A point-to-point link where 2 PLCs are exchanging states. This state transmission can be I/O of another PLC.

- A multipoint communication where a PLC is publishing states to a group of PLCs.

In a master/slave architecture, the master coordinator sends orders to the slaves. A communication paradigm has to be defined for these orders.

Each case will be implemented with the most appropriate Siemens technology.

4.5 Fast Controller Interface

This interface addresses communications between a PLC and a fast controller. 3 cases are considered:

- A master/slave link where the PLC is sending orders (Boolean or numerical) to a fast controller.

- A master/slave link where the fast controller is sending orders (Boolean or numerical) to a PLC.

- A point-to-point link where a Fast controller and a PLC are exchanging states.

In a master/slave architecture, the master will send orders to the slaves. A communication paradigm has to be defined for these orders.

4.6 System Monitoring

A task will be dedicated to PLC system monitoring: the following parameters will be monitored:

Operating Mode: RUN/STOP Memory:

o Load memory assigned: 0..100%o Work memory assigned: 0..100%o Retentive: 0..100%

Scan cycles:o Shortesto Longesto Averageo Standard deviation

CPU Time: Date and hour Communication

o Configuredo Max numbers of connections availableo Number of connections used

I/Os:o 24VDC Statuseso Board statuseso Raw value of each signal


Alive counter. Total Time Counter.

For redundant Architectures, monitored information will be specific and the volume to will be much bigger


5 Standard PLC Software Structure (SPSS)The principle of the SPSS is to have an identical software skeleton for all PLC application on the Project. The issue is the maintenance of the application and its adaptation to the specific needs of the experiment. Application developers should find more or less the same structure whatever the controller they connect. An SPSS already exists. Regarding all the features described in § 4, only a limited CODAC Interface has been embedded in the actual SPSS.

5.1 Description

The root structure of the control blocks in the PLC will be the same in every PLC deployed at ITER. The diagrams below describe this root standard structure.

CYCL_EXC (OB1)

// Core Applications// Example : “WFC”

“Process” (FC200)

// TBD.

“InputProcessing” (FC101")

// TBD.

“OutputProcessing” (FC102)

// Reset of All Simple Commands Received from CODAC

“ResetDB” (FC116)

// Pre-operationnal functions

“InputsProcessing”

“CodacInterface”

“Process”

// Operationnal functions

“OutputsProcessing”

“ResetDB”

// Post operationnal functions

// Communication Management with the CODAC

“CodacInterface”(FC100)

Figure 7 : Main Cycle Loop Standard Structure


“CodacChannel”,”iCondacchannel1"

// States and Configuration Variables

“CodacChannel”,”iCondacchannel2"

// Simple Commands

“CodacInterface”(FC100)

“CodacChannel”(FB110)

"CodacSetTcpEndPointx"

“T_CONN”

“T_SEND”

“T_RECV”

// TCP Connection Control

“PulseGenerator”,”iCodacPace"

“CodacTimeStamp”,”iCodacTimeStamp"

// Read the System Time“READ_CLCK”

// Generation of a pulse every 50msecs

“PulseGenerator”(FB100)

Figure 8 : CODAC Interface Standard Structure

WARM_START (OB100)

“CodacConnectionInit”// Initialization of TCP Communication port at Startup

“CodacConnectionInit”(FC115)

Figure 9 : Warm Restart Block Standard Structure

This standard structure is actually developed and maintained by ITER. It has to be imported in any application before developing or setting up the peripheral blocks and the core application.

5.2 CODAC Interface in the SPSS

In the actual SPSS, the CODAC Interface is supported. In Figure 8, the fixed application part of the CODAC interface is described. Globally it is managing the Legacy Communication Blocks of Siemens: “T_CON”, T_SEND”,” T_RECV”. The only missing part is the data to be transmitted, their location, the length, etc…In Figure 10 the Blocks represent the Shared DBs to be transmitted to the CODAC: The Blocks in light blue are part of the SPSS. It is the fixed part of the DBs: the UDT

defining the Headers/Footers. The Blocks in dark Blue are the Blocks specific to the application. The application

Developers use a tool called the SDD-Editor to generate them. In the example of the figures, it is a Water Cooling Function.

In Figure 11, the Blocks represent the Shared DBs, with the TCP parameters of the communication.


The Blocks in light blue are part of the SPSS. It is the DBs and the UDTs defining the Ports, Connections IDs etc..

The Block in dark Blue is the Block specific to the application. The application Developers use the SDD-Editor to generate them. This Block define the Length of the Block to be transmitted.

“cWBS” (UDT)

+ CWFC : BOOL;+ HSRQ : BOOL ;+ PT2SP : BOOL;+ LFSP : REAL;+ HFSP : REAL;...

“sWFC” (UDT)

+ PL1_CY : BOOL;+ PL1_YT: BOOL;+ VC8_FVY: BOOL;+ MP2_PT: BOOL;+ MF1_FT: BOOl;+ PL1_SY: REAL;+ STOPWFC: BOOL;+ LFST: BOOL;+ HFST: BOOL;...

CodacConf (DB101)

+ WBS : “cWBS”...

CodacStates (DB100)

+ Header : CodacStatesHeader+ WFC : “sWFC”+ …+ AliveCounter: INT+ TimeStamp: DATE_AND_TIME + Footer : CodacStatesFooter

“CodacStatesHeader” (UDT)

+ FixedPattern=0x02F08000 : DINT + Length: INT+ InterfaceVersion: String[40]

“Footer” (UDT)

+ FixedPattern=0xFD0F7FFF : DINT

“cmWBS” (UDT)

+ INIT : BYTE;+RESET : BYTE;+ ACK : BYTE;...

CodacCmd (DB102)

+ WBS : “cmWBS”+ ...

“s<FBSL[2,3,4]>” (UDT)

“cm<FBSL[2,3,4]>” (UDT)

c<FBSL[2,3,4]>” (UDT)

1

n

1

n

n

n

n

n

Figure 10:UDTs and DBs organisation and dependencies for the Control Function “CWS-DHLT-WFC”.


CodacConnections (DB103)

+ Channel1 : “_CodacConnection”;+ Channel2 : “_CodacConnection”;

“_CodacConnection” (UDT)

+ CONN_ID : INT;+ DEV_ID : BYTE;+ PORT : INT;+ INIT_COM : BOOL;+ SEND_DB : BYTE;+ RECV_DB : BYTE;

2

CodacChannels (DB104)

+ Channel1 : “_CodacChannel”;+ Channel2 : “_CodacChannel”;

“_CodacChannel” (UDT)

+ SEND_LEN : INT;+ RECV_LEN : INT;

n

Figure 11:UDTs and DBs organisation and dependencies for TCP connexion parameters.


6 Future DevelopmentThe ultimate target is to have the SPSS supporting all features of the Peripheral Blocks described in the Conceptual Architecture:

Codac Interfaceo It should support redundant architectureso It should be customizable for the Interface to be choosen: CP or CPU.

System Monitoring, System Monitoring for Redundant Architectures PLC interface. All cases should be considered: Conventional to Conventional,

Conventional to Redundant. Redundant to Redundant. Fast Controller Interface, with Conventional and Redundant. Hardware interface:

o For Conventional Controllers: For “Functional Boards”: Positioning, Counting, Fast I/Os For Specific Communication Boards: RS232, RS485, Modbus, Modbus

TCP.o For Redundant Architectures

In a high Availability Context In a Safety or Interlock Context (IEC61508)

The actual SPSS is developed with conventional languages. It should be possible to start from a CFC application.


Call for Expert Documents

SPSS Service Contract Specification

Description of the service required for the development of the Standard PLC Software Structure.

Approval Process Name Action AffiliationAuthor Evrard B. 13-Jun-2012:signed IO/DG/DIP/CHD/CSD/PCICoAuthorReviewers Moynier F. 14-Jun-2012:recommended IO/DG/ADM/DGA/PCDApprover Yonekawa I. 15-Jun-2012:approved IO/DG/DIP/CHD/CSD/PCI

Document Security: level 1 (IO unclassified)RO: Evrard Bruno

Read Access LG: PLC group, LG: CODAC team, AD: ITER, AD: External Collaborators, AD: Section - Plant Control and Instrumentation, project administrator, RO

IDM UID

9PGTR2VERSION CREATED ON / VERSION / STATUS

13 Jun 2012 / 1.0/ Approved

EXTERNAL REFERENCE

of 5

Table of Contents

1 INTRODUCTION..................................................................................................................................2

2 BACKGROUND AND OBJECTIVES ..................................................................................................2

3 TECHNICAL SPECIFICATION............................................................................................................2

4 WORK DESCRIPTION ........................................................................................................................2

5 PROFILE DESCRIPTION ....................................................................................................................3

6 ESTIMATED DURATION.....................................................................................................................3

7 EVALUATION CRITERIA....................................................................................................................3

8 WORK MONITORING AND MEETING SCHEDULE...........................................................................3

9 QUALITY ASSURANCE REQUIREMENTS........................................................................................4

10 PAYMENT SCHEDULE.......................................................................................................................4

11 REFERENCES, TERMINOLOGY AND ACRONYMS .........................................................................4

11.1 Acronyms .......................................................................................................................................411.2 References......................................................................................................................................5

of 5

1 INTRODUCTIONThis document describes the technical requirements for the settlement of a service contract for the development of a Standard PLC Software Structure. The SPSS is a Software package that will be deployed on every PLC in the ITER project. This contract consists of the service of one development engineer for 2 years. The required profile is described in the following chapters. Each bidder has to provide sufficient technical information about the involved engineer.

2 BACKGROUND AND OBJECTIVESITER is a fusion research facility in construction in Cadarache, France. One of the major ideas of the project is to have all subsystems built by the 7 countries participating to the experiment. This organization increases technical risks during the integration and commissioning phases.

In order to mitigate this risk, the Control Systems Division took several anticipating measures:

Publication of a PCDH, gathering a collection of standards to be applied by all providers.

Development of the CCS. The CCS is a software toolkit to be used by providers to develop their Control system.

As specified in the PCDH, only one line of products will be used for PLCs. The SPSS is one step further. The main purpose of SPSS is to enforce standardization in PLC Software Development. All common functions like numerical scaling, numerical values limiting, should be developed exactly in the same way on all PLCs of the project.

3 TECHNICAL SPECIFICATIONSee document “SPSS Technical Specification”.

IDM location: ITER_D_6SRGGZ

4 WORK DESCRIPTIONThe purpose of this contract is the development of the SPSS. The work will be broken down in several Tasks. Each tasks will be described in details by the ITER TRO. The contractor will evaluate the workload of every Task transmit it to the TRO before the Tasks begins.Here is a non-exhaustive list of the Task Orders foreseen:

ID Short Name Description1 Workflow Analysis Definition of Workflow and use cases. We need to define the different contexts

in which the application developer will use this SPSS: initial Development, maintenance on the PLC Core application, Maintenance on the SPSS, modification of one interface.

2 Redundant Architecture.

Improvement of the existing basic SPSS to support redundant architectures. This includes the development of an EPICS driver.

3 SPSS in CFC Port of actual SPSS on CFC language.4 SPSS Development Development of a SPSS with CODAC interface, Hardware Interface and

System Monitoring.5 CODAC Interface

ExtensionImprovement of Interface with CODAC, : differentiation of the data flows: static configuration, volatile Configuration, raw data, PLC monitoring data, accurate

https://user.iter.org/?uid=6SRGGZ

of 5

Time-Stamping.6 Fast Controllers

InterfaceSupport of Fast Controller Interface (with EPICS part).

7 … …

5 PROFILE DESCRIPTIONThe bidding companies should be able to provide one human resource with the following qualifications or experience: Education:

– Degree at least equivalent to 4 years of study after the High School Diploma, in the Electronic/Computer Science/Electro mechanics field or other relevant discipline.

Technical experience:– At least 8 years of experience with PLCs.– Experience with Structured Text programming language.– Experience with at least one of the following PLC Open Communications: FETCH/WRITE,

SEND/RECEIVE, Open TCP, ISO-on-TCP, LibNoDave, Modbus TCP.– Experience with Object Oriented Development Technologies: UML modeling, Java, C++,

Python, Maven.– Experience with data management technologies: XML, XSLT, W3C Schema– Experience with software engineering methods and tools;– Experience in development of code generation tools.– Experience with Linux and Open Source technologies.– Experience with Control Systems in a Large Scientific Experiment is an asset.– Experience in the following fields would be beneficial:

EPICS; Siemens s7-400FH range of products.; Subversion, CVS or Git.

Social skills:– Ability to work effectively in a multi-cultural environment;– Ability to work in a team and to promote team work.

Language requirements: – Fluent in English (written and spoken).

Computer and IT skills:– Comfortable with the following Microsoft Office Tools: Outlook, Word, Excel, SharePoint, Visio.

6 ESTIMATED DURATIONThis Service Contract will last for 2 years. The work is expected to be performed in close collaboration with the ITER TRO. It will be based on short development cycles (1-2 weeks) with an incremental and agile approach. A complete testing and simulation infrastructure is available in the ITER premises in Cadarache.The engineered provided will work mainly on site in the ITER premises of Cadarache.Some subtasks like documentation for example can be realized off-site. But it will be always in agreement with the ITER Technical Responsible Officer and it will be agreed during the Task definition.

7 EVALUATION CRITERIAThe selection will be done taking into account the following criteria: Human Ressource Expertise CV(s) 70% Price 30%’’

of 5

8 WORK MONITORING AND MEETING SCHEDULEFor each Task, there will be a

- Kick-off meeting where the ITER Technical Responsible Officer will describe the Task. It will be the opportunity for the engineer to asks questions and expose how he will proceed.

- Development meetings, not less than every 2 weeks. Not more than every 2 days. During these meetings, it is expected to have something to demonstrate in case it is about coding. These meetings are not only follow-up meetings. The contracting engineer and the ITER Technical RO will

o Detect and correct issues that may cause delays;o Review the completed and planned activities and asses the progress made;o Permit fast and consensual resolution of unexpected problems;o Clarify doubts and prevent misinterpretations of the specifications

- A final demonstration at the end of the Task.

A monthly report will be provided by the contractor. This report will include at least but not only: Worked hours The work executed for the on-going task(s). The work to be executed in the next month. The problems encountered, if any.

9 QUALITY ASSURANCE REQUIREMENTS For Software Developments, the Contractor will provide a development plan for each Task order. The Development will be organized in short iteration: 2 weeks maximum. Each Task order will be broken down in several iterations. Each Task order will begin with the definition of a preliminary version of the User Manual for the application that will be developed,Each iteration will follow the following cycle:

- Requirement Definition- Architecture definition- Coding-Unit Testing- Integration Testing- Validation

Each step will be verified. The final version of the User Manual will be provided at the end of the Task Order.The documentation associated to each step will be stored in a dedicated wiki or a SharePoint site on the ITER intranet.

10PAYMENT SCHEDULEThe Contractor shall supply monthly invoices to ITER IO based on the time sheets documented in the monthly progress reports. Invoices shall be supplied only after the progress report has been approved by IO.

11REFERENCES, TERMINOLOGY AND ACRONYMS

11.1Acronyms

CODAC Control, Data Access and Communication

of 5

CCS CODAC Core SystemCFC Continuous Flow ChartEPICS Experimental Physics and Industrial Control System RO Responsible OfficerTRO Technical Responsible OfficerUML Unified Modeling LanguageXML eXtended Markup LanguageXSLT EXtensible Stylesheet LanguageW3C World Wide Web ConsortiumTCP Transport Control ProtocolISO International Standardization Organization PLC Programmable Logic Controller

11.2References

PCDH Plant Control Design Handbook, ftp://ftp.iter.org//permanent_files/io_in_cad/com/www/codac/pcdh/PCDH_v6_1.pdf

CCS CODAC Core System, http://www.iter.org/org/team/chd/cid/codac/coresystemEPICS Experimental Physics and Industrial Control System http://www.aps.anl.gov/epics/

ftp://ftp.iter.org/permanent_files/io_in_cad/com/www/codac/pcdh/PCDH_v6_1.pdf

http://www.iter.org/org/team/chd/cid/codac/coresystem

http://www.aps.anl.gov/epics/

of 2

ITER Organization Call for Expertise IO/12/CFE/7512/FMR

Services of an Expert Engineer to provide support in the Standard PLC

Software Structure (SPSS) development

CURRICULUM VITAE

(max 5 pages)

Family name:

First names:

Date of birth:

Nationality:

Civil status:

Education:

Institution (Date from - Date to)

Degree(s) or Diploma(s) obtained:

Language skills: Indicate competence on a scale of 1 to 5 (1 - excellent; 5 - basic)

Language Reading Speaking Writing

Membership of professional bodies:

Other skills: (e.g. Computer literacy, etc.)

Present position:

Years within the firm:

Key qualifications: (Relevant to the project)

Specific international experience:

Country Date from - Date to

of 2

Professional experience (Relevant to the project)

Date from – Date to Location Company & reference person

Position Description

Other relevant information (e.g., Publications)




FINANCIAL PROPOSAL

Name of Expert:

NB :

- ON/SITE means the services are to be supplied at the ITER site in Cadarache, France.

- OFF/SITE means the services can be supplied from the contactors office/ site.

- Daily fee rates are calculated on the basis of days actually worked.

- For the purposes hereof, the daily rates are based on eight (8) working hours.

- Daily fee rates must include all expenses that are necessary to deliver the services including

travel, accommodation, daily subsistence allowances and any other conceivable expenses.

However, the contractor shall indicate in their financial proposal a separate budget line to

cover all the expert’s costs to carry out these missions.

Date

Signature

Duration Description Daily rate in € incl all Costs.

Total On Site Off Site

Year 1

(220 days) expert

Year 2

( 220 days) expert

TOTAL

STATEMENT OF EXCLUSIVITY AND AVAILABILITY




I, the undersigned, hereby declare that I agree to take part in the above-mentioned Call for

Expertise.

I further declare that I am able and willing to work

o for the period(s) foreseen in the Technical Specification attached to the above

referenced Call for Expertise for the position for which my CV has been proposed and

o within the execution period of the specific contract which is scheduled to run from

September 2012 for 24 months

I confirm that I am not engaged in another contract financed by the ITER Organization

whereby I would be in a position for which my services are required during the above periods.

I confirm that will not charge ITER for the same working day under more than one contract.

Furthermore, should this offer be accepted, I am fully aware that if I am not available at the

expected start date of my services for reasons other than ill-health or force majeure, I may be

subject to exclusion from other tender procedures and contracts funded by the ITER

Organization and that the notification of award of specific contract may be rendered null and

void.

Name

Signature

Date

Confidentiality Commitment




I, the undersigned, hereby declare that I agree to undertake the tasks assigned to me under the above mentioned contract. I undertake to perform my duties honestly and fairly. My contribution to the activities in which I will be involved will be objective and will fully respect the principles of fairness and impartiality. I undertake to hold in trust and confidence any ITER Project related information or documents. I undertake to use them only for the purposes of executing the tasks assigned to me and not to disclose them to any third party, including my employer. I will endeavour to avoid any conflict of interest situation, either direct or indirect. Should any such situation arise, I will promptly inform the relevant Responsible Officer. I undertake neither to assist nor be directly involved with any other bids or proposals in association with other external entity’s seeking to obtain contracts under the ITER project. I understand that I will be held personally responsible for maintaining the confidentiality of any documents or electronic files received and for returning, erasing or destroying all confidential documents or files upon completing the tasks, unless otherwise instructed. On conclusion of my assignment I will remain obligated to preserve the confidentiality for a period of 5 years.

Name:

Signature:

Date:

of 11

ITER ORGANIZATION SERVICE CONTRACT GENERAL CONDITIONS (version 2009)

ARTICLE II.1 – PERFORMANCE OF THE CONTRACT II.1.1. The Contractor shall perform the Contract to the highest professional standards. The Contractor shall

have sole responsibility for complying with all legal obligations incumbent on him, notably those resulting from employment, tax and social legislation.

II.1.2. The Contractor shall have sole responsibility for taking the necessary steps to obtain any permits, visas,

copyrights or licenses required for performance of the Contract under the laws and regulations in force at the place(s) where the tasks assigned to him are to be executed. In particular, the Contractor is responsible to obtain any export licenses, and such licenses shall be obtained within delivery period and are included in the contract price.

II.1.3. Without prejudice to Article II.3 any reference made to the Contractor’s staff in the Contract shall relate exclusively to individuals involved in the performance of the Contract.

II.1.4. The Contractor must ensure that any staff performing the Contract has the professional qualifications

and experience required for the execution of the tasks assigned to him. II.1.5. The Contractor shall neither represent the ITER Organization nor behave in any way that would give

such an impression. The Contractor shall inform third parties that he does not belong to the ITER Organization.

II.1.6. The Contractor shall have sole responsibility for the staff who executes the tasks assigned to him.

The Contractor shall make provision for the following employment or service relationships with his staff:

• staff executing the tasks assigned to the Contractor may not be given orders directly by the ITER Organization;

• the ITER Organization may not under any circumstances be considered to be the staff's employer and the said staff shall undertake not to invoke in respect of the ITER Organization any right arising from the contractual relationship between the ITER Organization and the Contractor.

II.1.7. In the event of disruption resulting from the action of a member of the Contractor's staff working on ITER Organization premises or in the event of the expertise of a member of the Contractor's staff failing to correspond to the profile required by the Contract, the Contractor shall replace him without delay. The ITER Organization shall have the right to request the replacement of any such member of staff, stating its reasons for so doing. Replacement staff must have the necessary qualifications and be capable of performing the Contract under the same contractual conditions. The Contractor shall be responsible for any delay in the execution of the tasks assigned to him resulting from the replacement of staff in accordance with this Article.

of 11

II.1.8. Should any unforeseen event, action or omission directly or indirectly hamper execution of the tasks, either partially or totally, the Contractor shall immediately and on his own initiative record it and report it to the ITER Organization. The report shall include a description of the problem and an indication of the date on which it started and of the remedial action taken by the Contractor to ensure full compliance with his obligations under the Contract. In such event the Contractor shall give priority to solving the problem rather than determining liability.

II.1.9. Should the Contractor fail to perform his obligations under the Contract in accordance with the

provisions laid down therein, the ITER Organization may - without prejudice to its right to terminate the Contract - reduce payments in proportion to the scale of the failure

ARTICLE II.1a – REPLACEMENT OF PERSONNEL

II.1a.1 The Contractor shall not make changes to the agreed expert personnel without the prior written

approval of ITER Organization. The Contractor must on its own initiative propose a replacement in the following cases:

a) In the event of death, in the event of illness or in the event of accident of expert personnel. b) If it becomes necessary to replace expert personnel for any other reasons beyond the Contractor’s

control (e.g. resignation, etc.). II.1a.2 Moreover, in the course of performance, and on the basis of a written and justified request, ITER

Organization can ask for a replacement if it considers that the expert personnel are inefficient or does not perform its duties under the Contract.

II.1a.3 Where expert personnel are to be replaced, the replacement must possess at least equivalent

qualifications and experience. Where the Contractor is unable to provide a replacement with equivalent qualifications and/or experience, ITER Organization may either decide to terminate the Contract, if the proper performance of it is jeopardized, or, if it considers that this is not the case, accept the replacement, provided that the rates of the latter are renegotiated to reflect the appropriate qualifications and/or experience.

II.1a.4 Additional costs incurred by the replacement are the responsibility of the Contractor. ITER

Organization makes no payment for the period when the expert to be replaced is absent. The replacement of any expert, whose name is listed in Annex II of the Contract, must be proposed by the Contractor within fifteen (15) calendar days from the first day of the expert’s absence.

ARTICLE II.2 – LIABILITY II.2.1. The ITER Organization shall not be liable for damage sustained by the Contractor in performance of

the Contract except in the event of willful misconduct or gross negligence on the part of the ITER Organization.

II.2.2. The Contractor shall be liable for any loss or damage caused by himself in performance of the

Contract, including in the event of subcontracting under Article II.13. The ITER Organization shall not be liable for any act or default on the part of the Contractor in performance of the Contract.

of 11

II.2.3. The Contractor shall provide compensation in the event of any action, claim or proceeding brought against the ITER Organization by a third party as a result of damage caused by the Contractor in performance of the Contract.

II.2.4. In the event of any action brought by a third party against the ITER Organization in connection with

performance of the Contract, the Contractor shall assist the ITER Organization. Expenditure incurred by the Contractor to this end may be borne by the ITER Organization.

II.2.5 The Contractor shall respect and abide by all relevant laws and regulations in force in location where

the services are performed and shall ensure that his personnel, experts and subcontractors’ personnel also respect and abide by all such laws and regulations. The Contractor shall indemnify the ITER Organization against claims and proceedings arising from any infringement by the Contractor, his personnel, experts and subcontractors’ of such laws and regulations.

ARTICLE II.3 - CONFLICT OF INTERESTS

II.3.1. The Contractor shall take all necessary measures to prevent any situation that could compromise the

impartial and objective performance of the Contract. Such conflict of interests could arise in particular as a result of economic interest, political or national affinity, family or any other relevant connection or shared interest. Any conflict of interests which could arise during performance of the Contract must be notified to the ITER Organization in writing without delay. In the event of such conflict, the Contractor shall immediately take all necessary steps to resolve it.

The ITER Organization reserves the right to verify that such measures are adequate and may require additional measures to be taken, if necessary, within a time limit which it shall set. The Contractor shall ensure that his staff, board and directors are not placed in a situation which could give rise to conflict of interests. Without prejudice to Article II.1 the Contractor shall replace, immediately and without compensation from the ITER Organization, any member of his staff exposed to such a situation.

II.3.2. The Contractor declares:

• that he has not made and will not make any offer of any type whatsoever from which an advantage can be derived under the Contract,

• that he has not granted and will not grant, has not sought and will not seek, has not attempted and will not attempt to obtain, and has not accepted and will not accept, any advantage, financial or in kind, to or from any party whatsoever, where such advantage constitutes an illegal practice or involves corruption, either directly or indirectly, inasmuch as it is an incentive or reward relating to performance of the Contract.

II.3.3. The Contractor shall pass on all the relevant obligations in writing to his staff, board, and directors as

well as to third parties involved in performance of the Contract. A copy of the instructions given and the undertakings made in this respect shall be sent to the ITER Organization should it so request.

ARTICLE II.4 – PAYMENT

At the end of each of the periods indicated in Annex II, the Contractor shall submit to the ITER Organization a formal request for payment accompanied by the following documents:

of 11

� a (technical) report in accordance with the instructions laid down in Annex I; � the relevant invoices indicating the reference number of the Contract to which they refer.

If the report is a condition for payment, on receipt the ITER Organization shall have such a period of time agreed upon the parties in which:

� to approve it, with or without comments or reservations

� to suspend such period and request additional information; or

� to reject it and request a new report.

If the ITER Organization does not react within this period, the report shall be deemed to have been approved. Approval of the report does not imply recognition either of its regularity or of the authenticity, completeness or correctness of the declarations or information enclosed.

Where the ITER Organization requests a new report because the one previously submitted has been rejected, this shall be submitted within two weeks. The new report shall likewise be subject to the above provisions.

ARTICLE II.5 – GENERAL PROVISIONS CONCERNING PAYMENTS

II.5.1. Payments shall be deemed to have been made on the date on which the ITER Organization's account

is debited. II.5.2. The payment periods referred to in Article I.4 may be suspended by the ITER Organization at any time

if it informs the Contractor that his payment request is not admissible, either because the amount is not due or because the necessary supporting documents have not been properly produced. In case of doubt on the eligibility of the expenditure indicated in the payment request, the ITER Organization may suspend the time limit for payment for the purpose of further verification, including an on-the-spot check, in order to ascertain, prior to payment, that the expenditure is eligible.

The ITER Organization shall notify the Contractor accordingly by registered letter with acknowledgment of receipt or equivalent. Suspension shall take effect from the date of dispatch of the letter. The remainder of the period referred to in Article I.4 shall begin to run again once the suspension has been lifted.

II.5.3. In the event of late payment, excepting the provisions of Article II.5.2 above, the Contractor may claim interest within two months of receiving the payment. Interest shall be calculated at the rate applied by the European Central Bank to its most recent main refinancing operations (“the reference rate”) plus 1.5 percentage points (“the margin”). The reference rate in force on the first day of the month in which the payment is due shall apply. Such interest rate is published in the C series of the Official Journal of the European Union. Interest shall be payable for the period elapsing from the calendar day following expiry of the time limit for payment up to the day of payment. Suspension of payment by the ITER Organization may not be deemed to constitute late payment.

ARTICLE II.6 – RECOVERY II.6.1. If total payments made exceed the amount actually due under the Contract or if recovery is justified in

accordance with the terms of the Contract, the Contractor shall reimburse the appropriate amount in

of 11

Euro or other currency indicated in the contract on receipt of the debit note, in the manner and within the time limits set by the ITER Organization.

II.6.2. In the event of failure to pay by the deadline specified in the request for reimbursement, the sum due shall bear interest at the rate indicated in Article II.5.3. Interest shall be payable from the calendar day following the due date up to the calendar day on which the debt is repaid in full.

II.6.3. The ITER Organization may, after informing the Contractor, recover amounts established as certain,

of a fixed amount and due by offsetting, in cases where the Contractor also has a claim on the ITER Organization that is certain, of a fixed amount and due. The ITER Organization may also claim against a bank guarantee, where provided for by the Contractor.

ARTICLE II.7 – PROPERTY OF THE ITER ORGANIZATION AND PROPERTY OF THE

CONTRACTOR II.7.1 Where for the purpose of the Contract the ITER Organization provides to the Contractor access to

drawings, files, technical data, computer programs, source codes, and any other item of property, the ITER Organization remains the sole owner of any item provided.

II.7.2 These items may only be used by the Contractor for the purposes of the Contract. The distribution,

reproduction or use by a third party without prior written approval by the ITER Organization is strictly forbidden.

II.7.3 All property of the Contractor while at the ITER Organization premises shall be at risk of the

Contractor and the ITER Organization shall accept no liability for any loss or damage to that property or caused by that property except where any such loss or damage was caused only by willful misconduct or gross negligence of any employee of the ITER Organization acting in the course of his employment. The ITER Organization shall accept liability only to the extent to which such loss or damage is so caused or contributed to.

ARTICLE II.8 – OWNERSHIP OF THE RESULTS - INTELLECTUAL AND INDUSTRIAL PROPERTY

Any results or rights thereon, including copyright and other intellectual or industrial property rights, obtained in performance of the Contract, shall be owned solely by the ITER Organization, which may use, publish, assign or transfer them as it sees fit, without geographical or other limitation, except where industrial or intellectual property rights exist prior to the Contract being entered into. The ownership of background intellectual property will not change unless otherwise agreed by the ITER Organization and the Contractor.

of 11

ARTICLE II.9 – CONFIDENTIALITY

II.9.1. The Contractor undertakes to treat in the strictest confidence and not make use of or divulge to third

parties any information or documents which are linked to performance of the Contract. The Contractor shall continue to be bound by this undertaking after completion of the tasks.

II.9.2. The Contractor shall obtain from each member of his staff, board and directors an undertaking that

they will respect the confidentiality of any information which is linked, directly or indirectly, to execution of the tasks and that they will not divulge to third parties or use for their own benefit or that of any third party any document or information not available publicly, even after completion of the tasks.

ARTICLE II.10 - USE, DISTRIBUTION AND PUBLICATION OF INFORMATION

II.10.1.The Contractor shall authorise the ITER Organization to process, use, distribute and publish, for whatever purpose, by whatever means and on whatever medium, any data contained in or relating to the Contract, in particular the identity of the Contractor, the subject matter, the duration, the amount paid and the reports.

II.10.2.Unless otherwise provided by the Special Conditions, the ITER Organization shall not be required to

distribute or publish documents or information supplied in performance of the Contract. If it decides not to publish the documents or information supplied, the Contractor may not have them distributed or published elsewhere without prior written authorisation from the ITER Organization.

II.10.3.Any distribution or publication of information relating to the Contract by the Contractor shall require

prior written authorisation from the ITER Organization. It shall state that the opinions expressed are those of the Contractor only and do not represent the ITER Organization's official position.

II.10.4.The use of information obtained by the Contractor in the course of the Contract for purposes other

than its performance shall be forbidden, unless the ITER Organization has specifically given prior written authorisation to the contrary.

ARTICLE II. 11 – TAXATION II.11.1.The Contractor shall have sole responsibility for compliance with the tax laws which apply to him.

Failure to comply shall make the relevant invoices invalid. II.11.2.The Contractor recognises that the ITER Organization is, as a rule, exempt from all taxes and duties,

including value added tax (VAT). II.11.3.The Contractor shall accordingly complete the necessary formalities with the relevant authorities to

ensure that the goods and services required for performance of the Contract are exempt from taxes and duties, including VAT. This applies in particular to VAT invoiced in France.

II.11.4 Only if the direct exemption of taxes and duties at the source is legally not possible, the Contractor

shall invoice them.

of 11

II.11.5.In cases of Article II.11.4 above, invoices presented by the Contractor shall indicate his place of taxation for VAT purposes and shall specify separately the amounts not including VAT and the amounts including VAT.

ARTICLE II.12 – FORCE MAJEURE II.12.1.Force majeure shall mean any unforeseeable and exceptional situation or event beyond the control of

the contracting parties which prevents either of them from performing any of their obligations under the Contract, was not due to error or negligence on their part or on the part of a subcontractor, and could not have been avoided by the exercise of due diligence. Defects in equipment or material or delays in making it available, labour disputes, strikes or financial problems cannot be invoked as force majeure unless they stem directly from a relevant case of force majeure.

II.12.2.Without prejudice to the provisions of Article II.1.8, if either contracting party is faced with force

majeure, it shall notify the other party without delay by registered letter with acknowledgment of receipt or equivalent, stating the nature, likely duration and foreseeable effects.

II.12.3.Neither contracting party shall be held in breach of its contractual obligations if it has been prevented

from performing them by force majeure. Where the Contractor is unable to perform his contractual obligations owing to force majeure, he shall have the right to remuneration only for tasks actually executed.

II.12.4.The contracting parties shall take the necessary measures to reduce damage to a minimum. ARTICLE II.13 – SUBCONTRACTING II.13.1.The Contractor shall not subcontract without prior written authorisation from the ITER Organization

nor cause the Contract to be performed in fact by third parties. II.13.2.Even where the ITER Organization authorises the Contractor to subcontract to third parties, he shall

none the less remain bound by his obligations to the ITER Organization under the Contract and shall bear exclusive liability for proper performance of the Contract.

II.13.3.The Contractor shall make sure that the subcontract does not affect rights and guarantees to which the

ITER Organization is entitled by virtue of the Contract. ARTICLE II.14 – ASSIGNMENT II.14.1.The Contractor shall not assign the rights and obligations arising from the Contract, in whole or in

part, without prior written authorization from the ITER Organization. II.14.2.In the absence of the authorization referred to in 1 above, or in the event of failure to observe the

terms thereof, assignment by the Contractor shall not be enforceable against and shall have no effect on the ITER Organization.

of 11

ARTICLE II.15 – TERMINATION BY THE ITER ORGANIZATION

II.15.1.The ITER Organization may terminate the Contract in the following circumstances:

(a) where the Contractor is being wound up, is having his affairs administered by the courts, has entered into an arrangement with creditors, has suspended business activities, is the subject of proceedings concerning those matters, or is in any analogous situation arising from a similar procedure provided for in national legislation or regulations;

(b) where the Contractor has been convicted of an offence concerning his professional conduct by a

judgment which has the force of res judicata; (c) where the Contractor has been guilty of grave professional misconduct proven by any means which the

ITER Organization can justify; (d) where the Contractor has not fulfilled obligations relating to the payment of social security

contributions or the payment of taxes in accordance with the legal provisions of the country in which he is established or with those of the country applicable to the Contract or those of the country where the Contract is to be performed;

(e) where the ITER Organization seriously suspects the Contractor of fraud, corruption, involvement in a

criminal organisation or any other illegal activity detrimental to the ITER Organization’s financial interest;

(f) where the Contractor is in breach of his obligations under Article II.3; (g) where the Contractor was guilty of misrepresentation in supplying the information required by the

ITER Organization as a condition of participation in the Contract procedure or failed to supply this information;

(h) where a change in the Contractor’s legal, financial, technical or organisational situation could, in the

ITER Organization’s opinion, have a significant effect on the performance of the Contract; (i) where the Contractor is unable, through his own fault, to obtain any permit or licence required for

performance of the Contract; (j) where the Contractor fails to fulfil its contractual obligations, after receiving formal notice in writing to

comply, specifying the nature of the alleged failure, and after being given the opportunity to remedy the failure within a reasonable period following receipt of the formal notice, remains in serious breach of his contractual obligations.

II.15.2.In case of force majeure, notified in accordance with Article II.12, either contracting party may terminate the Contract, where performance thereof cannot be ensured for a period corresponding to at least to one fifth of the period laid down in Article I.2.3.

II.15.3.Prior to termination under point c), e), f), g), h) or i), the Contractor shall be given the opportunity to

submit his observations in writing and communication with ITER Organization..

of 11

Termination shall take effect on the date on which a registered letter with acknowledgment of receipt terminating the Contract is received by the Contractor, or on any other date indicated in the letter of termination.

II.15.4.Consequences of termination:

In the event of the ITER Organization terminating the Contract in accordance with this Article and without prejudice to any other measures provided for in the Contract, the Contractor shall waive any claim for consequential damages, including any loss of anticipated profits for uncompleted work. On receipt of the letter terminating the Contract, the Contractor shall take all appropriate measures to minimise costs, prevent damage, and cancel or reduce his commitments. He shall draw up the documents required by the Contract for the tasks executed up to the date on which termination takes effect, within a period not exceeding sixty days from that date.

The ITER Organization may claim compensation for any damage suffered and recover any sums paid to the Contractor under the Contract.

On termination the ITER Organization may engage any other contractor to complete the services. The ITER Organization shall be entitled to claim from the Contractor extra costs incurred in making good and completing the services, without prejudice to any other rights or guarantees it has under the Contract.

ARTICLE II.16 – TERMINATION BY NOTICE

The ITER Organization may, of its own volition and without being required to pay compensation, terminate the Contract by serving a 15 days formal prior notice. Should the ITER Organization terminate the Contract, the Contractor shall only be entitled to payment corresponding to the services delivered and objectively justified irrevocable commitments entered into before the termination date.. On receipt of the letter terminating the Contract, the Contractor shall take all appropriate measures to minimise costs, prevent damage, and cancel or reduce his commitments. He shall draw up technical and financial reports for services rendered and irrevocable commitments up to the date on which termination takes effect, within a period not exceeding sixty days from that date.

ARTICLE II.17 – SUBSTANTIAL ERRORS, IRREGULARITIES AND FRAUD ATTRIBUTABLE TO THE CONTRACTOR

Where, after the award of the Contract, the award procedure or the performance of the Contract prove to have been subject to substantial errors, irregularities or fraud, and where such errors, irregularities or fraud are attributable to the Contractor, the ITER Organization may refuse to make payments, may recover amounts already paid or may terminate all the contracts concluded with the Contractor, in proportion to the seriousness of the errors, irregularities of fraud.

of 11

ARTICLE II.18 – JOINT AND SEVERAL LIABILITY IN CASE OF JOINT VENTURES/

CONSORTIA ETC.)

When the Contractor is a joint venture or consortium, all partners of such an undertaking agree hereby to ITER Organization that they shall exercise and will continue to exercise, in the performance of the Services and their other duties, obligations and liabilities pursuant to this Contract, all such reasonable skill, care and diligence as may be expected of a properly qualified and competent company experienced in carrying out work of a similar size, scope and complexity to the services, and the other duties, obligations and liabilities of the Contractor pursuant to this Contract in respect of the Services, and shall be jointly and severally liable to ITER Organization for any failure.

ARTICLE II.19 – INSURANCES

The Contractor shall take out insurance against risks and damage relating to performance of the Contract as required in the Contract and those required by the relevant applicable legislation. He shall also take out supplementary insurance as reasonably required by standard practice in the industry. A copy of all the relevant insurance contracts shall be sent to ITER Organization should it so request.

ARTICLE II.20 – LIQUIDATED DAMAGES

Should the Contractor fail to perform his obligations under the Contract within the time limits set by the Contract, then, without prejudice to the Contractor's actual or potential liability incurred in relation to the Contract or to the ITER Organization's right to terminate the Contract, the ITER Organization may decide to impose liquidated damages of a percentage of the amount specified in Article I.3.1 per calendar day of delay. This percentage will be specified in the Special Conditions. If the percentage is not specified then this article does not apply unless otherwise agreed by the parties.

The Contractor may submit arguments against this decision within thirty days of notification by registered letter with acknowledgement of receipt or equivalent. In the absence of reaction on his part or of written withdrawal by the ITER Organization within thirty days of the receipt of such arguments, the decision imposing the liquidated damages shall become enforceable. The ITER Organization and the Contractor expressly acknowledge and agree that any sums payable under this Article are in the nature of liquidated damages and not penalties, and represent a reasonable estimate of fair compensation for the losses that may be reasonably anticipated from such failure to perform obligations.

ARTICLE II.21 – AMENDMENTS

Any amendment to the Contract shall be the subject of a written agreement concluded by the contracting parties. An oral agreement shall not be binding on the contracting parties.

of 11

ARTICLE II.22 – SUSPENSION OF THE CONTRACT Without prejudice to the ITER Organization's right to terminate the Contract, the ITER Organization may at any time and for any reason suspend execution of the tasks under the Contract or any part thereof. Suspension shall take effect on the day the Contractor receives notification by registered letter with acknowledgment of receipt or equivalent, or at a later date where the notification so provides. The ITER Organization may within sixty (60) calendar days following suspension give notice to the Contractor to resume the work suspended or terminate the Contract following Article II.16 procedure. If the suspension under this Article II.22 is cancelled or the period of the notification or any extension thereof expires, the Contractor shall resume work. The ITER Organization will make an equitable adjustment in the delivery schedule or contract price, or both, and the Contract shall be modified, in writing, accordingly if 1) the suspension results in an increase in the time required for, or in the Contractor’s cost properly allocable to the performance of any part of the Contract; and 2) the Contractor asserts its right to the adjustment within thirty (30) days after receiving it.

ARTICLE II.23 – GOVERNING LAW AND SETTLEMENT OF DISPUTES

II.23.1 The ITER Organization is governed by the international agreement (“ITER Agreement”) and its annexes establishing the ITER Organization. The applicable law for contract interpretation is French law.

II.23.2 In the event of any dispute arising out of or in connection with the present Contract, the Parties agree

to submit the matter to settlement proceedings under the International Chamber of Commerce in Paris dispute settlement mediation ADR Rules. If the dispute has not been settled pursuant to the said Rules within 45 days following the filing of a Request for ADR or within such other period as the Parties may agree in writing, such dispute shall be finally settled under the Rules of Arbitration of the International Chamber of Commerce in Paris by one or more arbitrators appointed in accordance with the said Rules of Arbitration.

II.23.3 The arbitration proceedings in English shall take place in Paris, unless otherwise agreed by the parties.

***