codac architecture / design description documentstatic.iter.org/codac/pcdh7/folder...

18
PDF generated on 11 Oct 2017 DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM CODAC Architecture / Design Description Document The CODAC - Plant System Interface This document describes the software interface between CODAC and the plant system I&C and specifies how this interface must be implemented in the plant system I&C. Approval Process Name Action Affiliation Author Di Maio F. 05 Sep 2017:signed IO/DG/COO/SCOD/CSD/CDC Co-Authors Reviewers Park M. 11 Sep 2017:recommended IO/DG/COO/SCOD/CSD/CDC Approver Wallander A. 18 Sep 2017:approved IO/DG/COO/SCOD/CSD Document Security: Internal Use RO: Di Maio Franck Read Access AD: ITER, AD: External Collaborators, AD: IO_Director-General, AD: EMAB, AD: OBS - CODAC Section (CDC) - EXT, AD: OBS - Control System Division (CSD), AD: OBS - CODAC Section (CDC), AD: OBS - Plant Control and Instrumentation Section (PCI) - EXT, AD: Auditors, AD: ITER Management Assessor, project a... IDM UID 34V362 VERSION CREATED ON / VERSION / STATUS 05 Sep 2017 / 2.2 / Approved EXTERNAL REFERENCE / VERSION

Upload: tranhuong

Post on 25-Jun-2018

219 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

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

CODAC Architecture / Design Description Document

The CODAC - Plant System InterfaceThis document describes the software interface between CODAC and the plant system I&C and specifies how this interface must be implemented in the plant system I&C.

Approval Process Name Action AffiliationAuthor Di Maio F. 05 Sep 2017:signed IO/DG/COO/SCOD/CSD/CDCCo-AuthorsReviewers Park M. 11 Sep 2017:recommended IO/DG/COO/SCOD/CSD/CDCApprover Wallander A. 18 Sep 2017:approved IO/DG/COO/SCOD/CSD

Document Security: Internal UseRO: Di Maio Franck

Read Access AD: ITER, AD: External Collaborators, AD: IO_Director-General, AD: EMAB, AD: OBS - CODAC Section (CDC) - EXT, AD: OBS - Control System Division (CSD), AD: OBS - CODAC Section (CDC), AD: OBS - Plant Control and Instrumentation Section (PCI) - EXT, AD: Auditors, AD: ITER Management Assessor, project a...

IDM UID

34V362VERSION CREATED ON / VERSION / STATUS

05 Sep 2017 / 2.2 / Approved

EXTERNAL REFERENCE / VERSION

Page 2: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

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

Change Log

The CODAC - Plant System Interface (34V362)

Version Latest Status Issue Date Description of Change

v1.0 In Work 10 Dec 2009

v1.1 Signed 10 Dec 2009 New drfat after internal review. Still many open points.v1.2 Approved 28 Jan 2010 After I&C IPT review.

Chapter 2 stabilized.v1.3 Signed 07 Jan 2011 Version for review.v1.4 Signed 10 Jan 2011 Reuse OPSTATE and OPREQ as variable names, as in prvious version.

Final change before review.v2.0 Approved 10 Feb 2011 Version for PCDH 6.

Updated with the outcome of the review: correction of the COS table, addition of read commands, mention of log servers.

v2.1 Approved 30 Apr 2013 Updated for PCDH 7 + extensions from CODAC Core System v4- COS/PSOS completed- Addition on alarms and acrive interfaces (NJU)- System monitoring completed- Addition of SDN data- Simulation mode completed- Interface sheet chapter added

v2.2 Approved 05 Sep 2017 - Extend the CBS part in variable names (section 2.4)- Suppress the recommendation on deployment (previous section 2.5)- Reword external data statement (section 3.5)- Add DAN data (section 3.7)- Add Error and Trace logging (section 3.8)- Generalize simulation (section 4.2): many simulation variables, no more "SIM" sub-function.- New convention for Control mode with new variables (section 4.4)- More details on the scope of interface sheet (chapter 5)- Updated list of references for SDN, DAN and logs

-

Page 3: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 1 of 16

Table of Contents

1 INTRODUCTION...............................................................................................................21.1 PCDH CONTEXT ................................................................................................................21.2 SCOPE OF THE DOCUMENT..................................................................................................21.3 REFERENCES ......................................................................................................................31.4 ACRONYMS ........................................................................................................................3

2 PLANT SYSTEM I&C CONFIGURATION...................................................................52.1 PLANT SYSTEM I&C FUNCTION IDENTIFIER........................................................................52.2 PLANT SYSTEM I&C NAME.................................................................................................52.3 PLANT SYSTEM I&C SIGNALS NAME ..................................................................................52.4 PLANT SYSTEM I&C VARIABLE NAME ................................................................................62.5 PLANT SYSTEM I&C CONFIGURATION TOOLS .....................................................................6

3 PLANT SYSTEM I&C INTERFACE COMPONENTS.................................................73.1 EPICS VARIABLES.............................................................................................................7

3.1.1 Variable kind.............................................................................................................83.1.2 Values type ................................................................................................................8

3.2 COMMANDS .......................................................................................................................93.3 ALARMS INTERFACE ..........................................................................................................9

3.3.1 Limit Alarm .............................................................................................................103.3.2 State Alarm..............................................................................................................10

3.4 ARCHIVING INTERFACE....................................................................................................103.5 EXTERNAL DATA .............................................................................................................113.6 SDN DATA .......................................................................................................................113.7 DAN DATA ......................................................................................................................113.8 ERROR AND TRACE LOGGING ...........................................................................................12

4 STANDARD INTERFACE DATA .................................................................................134.1 OPERATING STATE AND OPERATING REQUEST ................................................................134.2 SYSTEM MONITORING FUNCTION......................................................................................144.3 SIMULATION ....................................................................................................................144.4 CONTROL MODE ..............................................................................................................14

5 INTERFACE SHEET.......................................................................................................16

Page 4: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 2 of 16

1 INTRODUCTION

1.1 PCDH contextThe Plant Control Design Handbook (PCDH) [RD1] defines methodology, standards, specifications and interfaces applicable to ITER Plant Systems Instrumentation & Control (I&C) system life cycle. I&C standards are essential for ITER to:

Integrate all plant systems into one integrated control system.

Maintain all plant systems after delivery acceptance.

Contain cost by economy of scale.PCDH comprises a core document which presents the plant system I&C life cycle and recaps the main rules to be applied to the plant system I&Cs for conventional controls, interlocks and safety controls. Some I&C topics will be explained in greater detail in dedicated documents associated with PCDH as presented in Figure 1. This document is one of them.

1.2 Scope of the documentThis document is a specification for the interface used to communicate with any ITER plant system from CODAC.Interlocks and safety are not covered, except for the interlock or safety information that is available in the conventional controllers of the plant systems.The interface described in this document is implemented in the plant systems controllers and in the PSH. The interface includes:

Any data of the plant system that can be accessed (set or retrieved) from CODAC.

The commands that the plant system can execute.

The alarms that are detected by the plant system and transmitted to CODAC.

The data that need to be received from CODAC.Although not detailed in this version, the interface will also include the data and events distributed with the Time Communication Network (TCN) and the Synchronous Data Network (SDN).The interface definition of each plant system shall include a mandatory part, common to all plant systems. A limited definition of this common interface is included in this version of the document.The interface specified in this document shall be fully defined in the plant system self-description using the IO supplied tools, such as the SDD tools that are distributed with the CODAC Core System software [RD2].

Page 5: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 3 of 16

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 for 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 (B7N2B7)

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)

Software engineering and QA for CODAC (2NRS2K)

Guidelines for I&C cubicle configurations (4H5DW6)

CWS case study specifications (35W299)

NUCLEAR PCDH (2YNEFU)

OCCUPATIONAL SAFETY CONTROLSGuidelines for PSS design (C99J7G)

Available and approved

Legend

This document

(XXXXXX) IDM ref.

The CODAC -PS Interface (34V362)

Figure 1 – Schema of PDCH documents

1.3 References[RD1] Plant Control Design Handbook (ITER_D_27LH2V)

[RD2] CODAC Core System Overview (ITER_D_34SDZ5)

[RD3] I&C signal and process variable naming convention (ITER_D_2UT8SH)

[RD4] CODAC glossary: (ITER_D_34QECT)

[RD5] EPICS Application developer’s guide: http://www.aps.anl.gov/epics/base/R3-14/11-docs/AppDevGuide.pdf

[RD6] Logging library - Software User Manual (QEK784)

[RD7] SDN - Software User Manual (B7SKFU)

[RD8] DAN User manual (Q6GULS)

[RD9] IS-45-XX-00X Template (UMJSJK)

1.4 Acronyms The following acronyms, defined in a separate CODAC glossary [RD4], are used:

API Application Programming Interface CBS Control Breakdown StructureDAN Data Archiving NetworkHMI Human Machine InterfaceI&C Instrumentation & ControlICD Interface Control DocumentIS Interface SheetPCS Plasma Control SystemPSH Plant System HostPON Plant Operation NetworkPV EPICS Process VariableSDD Self-description Data

Page 6: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 4 of 16

SDN Synchronous Databus NetworkTCN Time Communication Network

Page 7: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 5 of 16

2 Plant System I&c Configuration

As defined in the Plant Control Design Handbook [RD1], each plant system I&C consists of one and only one PSH and one or more plant system controller(s) interfacing to plant system components, actuators and sensors, via signal interfaces. Plant system controllers are either fast controllers or PLCs.With respect to CODAC, each plant system I&C is in charge of implementing a set of functions belonging to the ITER plant functional breakdown.This role of the plant system I&C is illustrated in Figure 2.

Plant System I&C

PSH

Controller

Controller

Componentsignalsignal

Componentsignalsignal

Implements

Function

Function- commands- variables

Function- commands- variables

Figure 2 – Plant system I&C functional role

Each plant system I&C shall provide the CODAC/Mini-CODAC systems (operator displays, supervision, scheduling system, alarms handling…) with a functional interface implemented by EPICS process variables (PVs).This interface is bound to the functions implemented by the plant system I&C and, for each function the interface is composed of a list of commands and variables.The CODAC interface is part of the plant system I&C configuration that also includes the definition of the signals and the configuration of the PSH and controllers.

2.1 Plant system I&C function identifierThe set of functions implemented by a plant system I&C shall be defined in the ITER Control Breakdown System (CBS).The ITER functional breakdown is a hierarchical structure. Each level is uniquely identified by an alpha numeric string of maximum 4 characters. A function name is composed with the name of each level separated by a dash (“-“).The set of functions implemented by a plant system I&C shall belong to the same level 2 function from the ITER CBS. As a result, all these functions shall share the same FFFF-FFFF pattern in their name that is built as: <CBS1>-<CBS2> where CBS1 and CBS2 are CBS identifiers at level 1 and level 2.

2.2 Plant system I&C nameConventionally, a plant system I&C is associated with a CBS level 2 function and shall be named accordingly: <CBS1>-<CBS2>.

2.3 Plant system I&C signals nameThe set of signals that a plant system I&C manages shall be defined using IO supplied tools.

Page 8: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 6 of 16

Within a plant system I&C, the signals are identified using their unique name, as defined in the Plant Control Design Handbook [RD1].Any signal managed by a plant system I&C is named with the identifier of the component to which the signal belongs and the identifier of the signal separated by a colon (“:”).The component identifier shall comply with the ITER component naming convention.The signal identifier shall comply with the signal naming convention, as defined in the document “I&C signal and process variable naming convention” [RD3].The signal name format, compliant with these rules is: PPPP-TTT-NNNN:AAAA[RRRR]-SSS

2.4 Plant system I&C variable nameThe variable names are composed of a function identifier and a variable identifier. A colon (:) is separating those two parts.The function identifier shall be a CBS node. For plant system I&C variables it shall belong to the CBS2 node of this plant system I&C. Variables may be associated to a CBS1 node in case they belong to such a level (control group) and are deployed on a CBS1 server. Variables can be associated with CBS nodes up to the 5th level.The variable identifier is a free string of 16 characters maximum VV…VV, provided the full name including the function identifier is unique within the whole ITER plant. Any alphabetic character used in names shall be in upper case. The variable name can be composed of many sequence of characters separated by a minus (-) character. The variable name format, compliant with these rules is: CBS1-CBS2[-CBS3[-CBS4[-CBS5]]]:VV1[-VV2[…]]

2.5 Plant system I&C configuration toolsThe Plant system I&C software and the CODAC interface shall be defined using IO supplied configuration tools. The main tool is the SDD editor that is supplied with the CODAC Core System distribution.A plant system I&C configuration data that shall be defined using the SDD editor is composed of:

The list of signals that are interfaced via the plant system I&C.

The list of functions that the plant system I&C implements and, for each function, the complete definition of the function interface (commands and variables).

The configuration of the controllers and PSH, including the configuration of the controllers’ I/O interfaces and the signal connections.

Page 9: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 7 of 16

3 Plant System I&C interface components

The interface components are:

- EPICS Process Variable (PV) implemented by EPICS processes and interfaced over the PON by means of the Channel Access (CA) protocol

- Variables exchanged over the Synchronous Databus Network (SDN)

- Data transmitted over the Archiving Network (DAN)

3.1 EPICS VariablesIn the interface definition of a plant system I&C, a distinction is made between the configuration of the plant system and its state.The configuration represents the set of internal values that is the input for the plant system I&C processing and that can only be modified by means of commands (dynamic configuration) or changes in a configuration data-base (static configuration).The state represents the set of internal values that reflect the current state of the system as maintained by the plant system I&C processing, according to the configuration and the input signals.

Operate

Controller

State

Equipment

Input Signals

Control Equipment

State Variables

Configuration

Output signals

StaticConfiguration

(Self-description)

Configuration Variables

Simple commands

Figure 3 - States and Configuration Data Flows

The interface with a system’s internal data is implemented by means of functional variables that can be read and, conditionally, written by CODAC, and by simple commands that trigger specific action in controllers. The complete state of a plant system shall be interfaced by means of a set of variables, qualified as state variables.The complete configuration of a plant system shall be interfaced by means of a set of variables, qualified as configuration variables.Each variable that belongs to a Plant System I&C interface shall be defined using the SDD editor and shall be deployed on one and only one controller or PSH.

Page 10: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 8 of 16

A configuration variable can be qualified as being or not static. If static, its value shall be specified in the variable definition (in SDD); if not, the value can be set by a “put” command (via Channel Access).By default, the value of a configuration variable is persistent, which means that the value is saved when changed and restored whenever the plant system I&C is restarted.Optionally, a state variable can be configured to be persistent. This should be restricted to cases in which an acquired value needs to be restored after a controller has been restarted,A state variable shall be assumed to be dynamic, in the sense that its value can change independently of commands received by the system or component.

3.1.1 Variable kindVariables differ with respect to the kind they belong to: A discrete variable can only have a defined set of values. Its definition includes the specification of

each value, consisting in a numeric code and an alphanumeric label. This applies to Boolean values and to enumerations.

A continuous variable has a continuous range of values that may be bound by limits. Its definition includes the data type, the units and may include limits for operation and alarms.

In addition, the value of a variable can be a string of characters and in that case its definition includes the maximum number of characters. The definition of a discrete variable shall include the exhaustive list of the supported values. The number of values is limited to a maximum of 16. Each value shall be defined with a numeric code, which is an unsigned 16 bit integer, and a character string whose length is limited to a maximum of 16 characters.The definition of a continuous variable shall include a data type and a unit. If required, design limits shall also be specified.The definition of a string variable shall include the maximum length of the string. This length cannot be greater than 40 characters.

3.1.2 Values typeThe supported types for values exchanged via variables are those supported by EPICS records and by channel access. These comprise:

Numeric data types, signed or unsigned integers (8 bits, 16 bits, 32 bits) and floats (32 bits and 64 bits)

Strings, as arrays of maximum 40 bytes,Scalar values are supported for all the listed data types. Arrays of numeric values and bytes are also supported.The following attributes are associated with any value received from a monitored variable via channel access:

A time stamp represented in UTC time with a resolution on one nanosecond. The actual precision depends on the time precision of the control unit.

A quality factor (STAT field in EPICS), that indicates, when not null, that the value is not available and that provides a coarse indication of the reason.

The elementary data types for a variable are those listed in Table 1 below, as supported by EPICS.

Page 11: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 9 of 16

Table 1 - Supported elementary data types for values

Symbol Description

INT8 8 bits signed integer

UINT8 8 bits unsigned integer

INT16 16 bits signed integer

UINT16 16 bits unsigned integer

INT32 32 bits signed integer

UINT32 32 bits unsigned integer

FLOAT32 32 bits float

FLOAT64 64 bits float

STRING Byte arrays with max length of 40.

The value data type for discrete variables cannot be configured. UINT16 is the only supported data type.

The value for a continuous variable can be a scalar of any of the elementary data types or a one dimension array of any numeric data type from this list. The implementation of a state variable shall allow the delivery of a time stamp attribute that shall be at least as accurate as the time precision of the control unit.

3.2 CommandsCommands sent to a plant system I&C are of three types:

Read the value of any variable (state or configuration) Example: caput TEST-MOT:POSCMD “Open”

Write a new value to a configuration variable. Example: caput TEST-MOT:POSCMD “Open”

Trigger an action in a controller via a simple command.Example: caput TEST-MOT:RESET 1Simple commands are also implemented by means of EPICS PVs and variables in PLCs. The value written must be 1, which signals and indicates a request that is pending for transmission to the PLC or for execution in a fast controller. Once the request has been transmitted or executed, the variable value is reset to 0.The value written to a configuration variable shall comply with value data type specified in the definition of the variable.The simple commands that the controllers implement shall be defined in plant system I&C interface. Only the name of the command needs to be specified and conventionally it should be a verb describing the action to be triggered.

3.3 Alarms InterfaceThe purpose of the alarm system is to provide information to the operators through a Mini-CODAC / CODAC system service for fault diagnosis and correction. A plant wide alarm handling policy will be put in place to handle the alarm situations and to undertake corrective action to allow normal and safe operation to continue.

Page 12: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 10 of 16

The plant system I&C shall maintain the status of all active alarms and shall transmit any change of this status (alarm raised, alarm cleared).The alarm shall carry information to the CODAC system to enable alarm reduction.The alarms shall be raised in accordance with the operating states. This is needed to properly qualify alarms which are not significant in a given situation.EPICS records generate alarms. The types of alarms fall into the following categories:

scan alarms,

read/write alarms,

limit alarms,

state alarms.

Some of these alarms are automatically managed by the EPICS device support - scan alarms and read/write alarms. The alarm severity is always set to INVALID for invalid data or no communication.

Limit alarms and state alarms are configured using SDD and are part of the Plant System Interface.

3.3.1 Limit AlarmAlarm limits are configured for analogue records (Analog Input [AI], Analog Output [AO], and Calculated PV [CALC]… records). There are two limits for above normal operating range – high-high [HIHI] and high [HIGH] and two limits for the below-limit operating range – low-low [LOLO] and low [LOW] so that a warning can be set off before the value goes into a dangerous condition.

Each of these limits may have an associated alarm severity: MAJOR, MINOR, NO_ALARM or INVALID. If the record's value drops below the low limit and an alarm severity of MAJOR was specified for that low limit, then a MAJOR alarm is triggered. When the severity of a limit is set to NO_ALARM, none will be generated.

Analogue records also contain a hysteresis field, which is used when determining limit violations. The hysteresis field is a dead band around the alarm limits and keeps a signal that is hovering at the limit from generating too many alarms.

3.3.2 State AlarmState alarms are configured for discrete values (Binary Input [BI], Binary Output [BO], Multi-Bit Binary Input [MBBI], Multi-Bit Binary Output [MBBO]…). In this case, a certain state can trigger an alarm with a given severity.

Discrete records also have a specific field (UNSV) used to specify the severity of an unknown state to NO_ALARM, MINOR or MAJOR. If set, the unknown state severity field triggers an alarm when the record support routine cannot find a matching value in the state value fields for VAL or when VAL is out of range.

The change of state severity field (COSV) triggers an alarm when the record's state changes, if set to MAJOR or MINOR. Thus, the operator can be informed when the record's alarm state has changed. If this field specifies NO_ALARM, then a change of state will not trigger a change of state alarm. If specified either MINOR or MAJOR, a change of state will trigger an alarm with the corresponding severity.

3.4 Archiving InterfaceUsing SDD, EPICS analogue records should include the definition of the thresholds and smoothing filter to reduce noise on the input signal. The objective is to define on the EPICS IOC level these necessary parameters to reduce the amount of processing negligible value changes:

Page 13: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 11 of 16

ADEL - Archive dead band: limits the values sent to the archive engine to changes beyond this threshold

SMOOTH - constant between 0 and 1 applied to the converted hardware signal, with 0 meaning no smoothing and 1 meaning ultimate smoothing.

Archiving can be enabled/disabled according to a specific variable defined as the “enabling” variable: whenever the value of this variable is above zero, sampling and archiving of a whole group will be enabled until the variable returns to zero or below. The enabling variable should be defined using SDD.

Then for each variable to be archived, the mode should be specified in SDD:

Archiving Monitor Mode: each value sent by the EPICS IOC is stored. With a perfectly configured data source with adequate thresholds that only pass significant changes to the archive engine; this mode is the recommended one. Important changes in value are written to the archive, while noise in the signal is suppressed to minimize wasted resources. The expected change frequency should be specified in SDD as it sizes the memory buffer allocated to the variable by the Archive Engine,

Archiving Monitor with Threshold Mode: each value received is compared by the Archive Engine to the previous one and stored only if the change is greater than the dead band. In this mode, the Archive Engine performs the dead band check in place of the EPICS IOC,

Archiving Scan Mode: the Archive Engine receives each update from the data source but only writes the most recent ones at periodic times. Mode created for PVs which do not have a good dead band configuration and where using monitored mode would add too many data to the archive

3.5 External DataThe data transmitted to the plant system I&C by CODAC from another plant system I&C shall be fully defined. Such data are identified in the plant system’s Interface Sheet (IS) as external data and is defined in the interface of the plant system implementing the variable.Any variable belonging to another system shall be specified and will be made available via a CODAC gateway.

3.6 SDN dataAny plant system I&C having an interface with the Plasma Control System (PCS), shall include in its interface definition the SDN data that it produces and/or consumes.The unit of data exchange over SDN is a topic. Each topic has a unique name. As for variables, topic names are prefixed with a CBS function: <CBS1>-<CBS2>[-<CBS3>]:<topic_name> Each SDN data producer shall provide the full definition of each SDN topic it publishes on SDN. This includes the structure of the data packets and the static metadata that all topic users share.Each SDN data consumer shall define the SDN topic it subscribes to.

3.7 DAN dataAny plant system I&C producing scientific data for archiving shall include in its interface definition, the archiving data it is producing.Each DAN data producer shall define the DAN variables it produces. DAN variables are named with the same naming convention, with a CBS function prefix, a column separator and an identifier.

Page 14: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 12 of 16

3.8 Error and Trace loggingThe log messages are handled by log servers that record all messages in files. Operators and experts shall be able to obtain from these log files the details of an abnormal behavior, for diagnostic purposes. The plant system I&C shall provide information on its normal and abnormal behavior by means of log messages, as defined in the Plant Control Design Handbook.Two Application Programming Interfaces (API) are provided for producing such messages. The code that is included in an EPICS module that can be used in a plain EPICS environment should use the error logging API that is part of EPICS and defined in the EPICS Application programmers guide [RD5].An ITER-standard library is included in the CODAC Core System distribution. It shall be used for any code produced for the ITER context. It is based on the Syslog system (RFC5424).In either case, the log information that shall be transmitted via the API is composed of

A log severity, which shall be specified when calling the API. The values depend on the API used. For ITER logs, these are the syslog’s severity values

A text of maximum 255 characters.A time stamp is automatically added by the supporting libraries into the log message.Error messages shall provide details of faults detected by a controller. However, the fault itself shall be signaled by means of a variable that maintains the state of the fault as active or not and that shall activate/deactivate the generation of an alarm.

Page 15: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 13 of 16

4 Standard Interface DataThe CODAC interface includes some standard variables that shall be implemented by each plant system I&C.

The IO supplied tools will enforce the presence of such variables and will provide the capacity to configure them. Except where explicitly mentioned, all these variables shall be implemented in the plant system I&C.

The current list is limited to the minimum set of variables supporting standard features defined in the Plant Control Design Handbook.

4.1 Operating State and Operating RequestIn each plant system I&C, the common operating state (COS), as defined in the Plant Control Design Handbook, is implemented by the following two COS variables:

A state variable named <CBS1>-<CBS2>:COS-OPSTATE, for returning the COS value to the supervision system.

A configuration variable named <CBS1>-<CBS2>:COS-OPREQ, for handling COS change requests from the supervision system.

These 2 variables belong to the CBS2 function and are deployed on the PSH.The values are the same for all plant system I&C. These are copied from PCDH in Table 2 below.

Table 2 – Values for COS variable

<CBS1>-<CBS2>:COS-OPSTATE1 Off2 NotReady3 Ready4 Initialising5 Initialised6 Executing7 PostChecks8 Terminating9 Aborting10 Absent11 Local12 Fault13 Safe

<CBS1>-<CBS2>:COS-OPREQ1 SwitchOff 2 SwitchOn3 gotoReady 4 Initialise5 gotoInitialised6 Execute7 PostCheck8 Terminate9 Abort1011 gotoLocal ?1213 gotoSafe ?

The values of the COS variables are fixed but updating the state and reacting to requests is specific to the plant system and should be implemented by specific variables:

- <CBS1>-<CBS2>:PSOS-OPSTATE: the current operating state

- <CBS1>-<CBS2>:PSOS-OPREQ: the requests the plant system I&C implementsFor each plant system I&C, two mapping tables shall be edited for the translation between the generic COS variables and the PSOS specific ones.

Page 16: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 14 of 16

4.2 System monitoring functionIn each plant system I&C, one level 3 function is standardized for the management and monitoring of the plant system I&C. This function is added into each plant system I&C by CODAC configuration tools with automatically generated variables. This function is named <CBS1>-<CBS2>-SYSMThe system monitoring function currently includes the following:

- Monitoring the resource of the control units, such as memory, CPU or network and triggering alarms when resource usage limits are crossed.

- Monitoring the health of the required software processes and triggering alarms on detection of abnormal behavior.

- Monitoring the communication status with PLCs

- Monitoring the cubicle conditions (temperature, door status …)

4.3 SimulationSimulation options: <CBS>:SIM-<option_name> are Boolean configuration variable (bo record) that control the activation of a simulation mode. Conventionally, these variables should be named with a “SIM” prefix. These configuration variables should be static variables in the case the simulation mode is activated by loading EPICS db files for simulation. In case some variables are exclusively controlling a simulation, it is recommended to associated those variables to a SIM sub-function.

4.4 Control ModeThe control mode, as defined in the Plant Control Design Handbook, is implemented by means of a a state variable named CONTMODE reflecting whether central or local control is active and two variables reflecting if local control is enabled by CODAC and requested by the plant system. The variables are defined in Table 3.When the control mode is Local, commands can be transmitted to the controllers but those controllers may ignore or reject them. In any case, read access to control configurations as well as monitoring of the state configuration shall not be discontinued in local control mode. Actions from local HMI, such as touch panels, should only be enabled in local control mode.

Table 3 - Control mode variables values

CONTMODE LOCAL-C LOCAL-S

0 Central 0 Local control inhibited 0 Local control released

1 Local 1 Local control permitted 1 Local control requested

The expected behavior is as follows:

1. The plant system shall indicate using the LOCAL-S variable its request for switching to local mode. This is triggered by an operator action.

2. CODAC shall grant permission for local mode using LOCAL-C variable. This is triggered by an operator action.

3. The plant system shall indicate using the CONTMODE variable that local mode is active. Any commands from CODAC are rejected or ignored.

4. The plant system shall release local mode using LOCAL-S variable. This is triggered by an operator action.

Page 17: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 15 of 16

5. CODAC shall take central control using LOCAL-C variable. This is triggered by an operator action.

6. The plant system shall indicate using CONTMODE variable that central mode is active. Any local commands are rejected or ignored.

Page 18: CODAC Architecture / Design Description Documentstatic.iter.org/codac/pcdh7/Folder 1/4-The_CODAC_-_Plant_System... · CODAC Architecture / Design Description Document ... Author Di

Page 16 of 16

5 Interface sheet

The CODAC – Plant System I&C interface set of data is made of the configuration data of the interface components as specified in chapter 3 and of the standard interface data as specified in the chapter 4.When the plant system I&C is manufactured, this data is produced using SDD tools and maintained in SDD databases. Beforehand, the interface definition is recorded in Interface Sheets (IS) that are part of the Interface Control Document with CODAC.To allow data transfer from the IS to the CODAC configuration databases used during design (PSP) and implementation (SDD), these IS should be provided as structured tables.The following data shall be defined in the plant system interface control document and associated IS:

- List of all the controllers

- List of all the variables The content of PBS45 Interface Sheet is defined in the template for these IS [RD9]