CODAC Architecture / Design Description Document

Transcription

1 IDM UID 34V362 VERSION CREATED ON / VERSION / STATUS 05 Sep 2017 / 2.2 / Approved EXTERNAL REFERENCE / VERSION 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... PDF generated on 11 Oct 2017 DISCLAIMER : UNCONTROLLED WHEN PRINTED PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

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

3 Table of Contents 1 INTRODUCTION PCDH CONTEXT SCOPE OF THE DOCUMENT REFERENCES ACRONYMS PLANT SYSTEM I&C CONFIGURATION PLANT SYSTEM I&C FUNCTION IDENTIFIER PLANT SYSTEM I&C NAME PLANT SYSTEM I&C SIGNALS NAME PLANT SYSTEM I&C VARIABLE NAME PLANT SYSTEM I&C CONFIGURATION TOOLS PLANT SYSTEM I&C INTERFACE COMPONENTS EPICS VARIABLES Variable kind Values type COMMANDS ALARMS INTERFACE Limit Alarm State Alarm ARCHIVING INTERFACE EXTERNAL DATA SDN DATA DAN DATA ERROR AND TRACE LOGGING STANDARD INTERFACE DATA OPERATING STATE AND OPERATING REQUEST SYSTEM MONITORING FUNCTION SIMULATION CONTROL MODE INTERFACE SHEET...16 Page 1 of 16

4 1.1 PCDH context 1 INTRODUCTION The 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 document This 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 selfdescription using the IO supplied tools, such as the SDD tools that are distributed with the CODAC Core System software [RD2]. Page 2 of 16

5 PCDH core and satellite documents: v7 PS CONTROL DESIGN INTERLOCK CONTROLS Guidelines for PIS design (3PZ2D2) Guidelines for PIS integration & config. (7LELG4) Management of local interlock functions (75ZVTY) PIS Operation and Maintenance (7L9QXR) Plant system I&C architecture (32GEBH) Methodology for PS I&C specifications (353AZY) CODAC Core System Overview (34SDZ5) I&C CONVENTIONS I&C Signal and variable naming (2UT8SH) ITER CODAC Glossary (34QECT) ITER CODAC Acronym list (2LT73V) OCCUPATIONAL SAFETY CONTROLS Guidelines for PSS design (C99J7G) NUCLEAR PCDH (2YNEFU) CATALOGUES for PS CONTROL Slow controllers products (333J63) Fast controller products (345X28) Cubicle products (35LXVZ) Integration kit for PS I&C (C8X9AE) Core PCDH (27LH2V) Plant system control philosophy Plant system control Life Cycle Plant system control specifications CODAC interface specifications Interlock I&C specification Safety I&C specification PS CONTROL DEVELOPMENT I&C signal interface (3299VT) PLC software engineering handbook (3QPL4H) Guidelines for fast controllers (333K4C) Software engineering and QA for CODAC (2NRS2K) Guidelines for I&C cubicle configurations (4H5DW6) CWS case study specifications (35W299) PS SELF DESCRIPTION DATA Self description schema documentation (34QXCP) PS CONTROL INTEGRATION The CODAC -PS Interface (34V362) PS I&C integration plan (3VVU9W) ITER alarm system management (3WCD7T) ITER operator user interface (3XLESZ) Guidelines for PON archiving (B7N2B7) PS Operating State management (AC2P4J) Guidelines for Diagnostic data structure (354SJ3) Legend This document Available and approved (XXXXXX) IDM ref. Figure 1 Schema of PDCH documents 1.3 References [RD1] [RD2] [RD3] [RD4] Plant Control Design Handbook (ITER_D_27LH2V) CODAC Core System Overview (ITER_D_34SDZ5) I&C signal and process variable naming convention (ITER_D_2UT8SH) CODAC glossary: (ITER_D_34QECT) [RD5] EPICS Application developer s guide: docs/appdevguide.pdf [RD6] [RD7] [RD8] [RD9] Logging library - Software User Manual (QEK784) SDN - Software User Manual (B7SKFU) DAN User manual (Q6GULS) 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 Structure DAN Data Archiving Network HMI Human Machine Interface I&C Instrumentation & Control ICD Interface Control Document IS Interface Sheet PCS Plasma Control System PSH Plant System Host PON Plant Operation Network PV EPICS Process Variable SDD Self-description Data Page 3 of 16

6 SDN TCN Synchronous Databus Network Time Communication Network Page 4 of 16

7 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. Function Plant System I&C Function - commands - variables Function - commands - variables Implements PSH Controller Controller signal signal signal signal Component Component 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 identifier The 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 Plant system I&C name Conventionally, 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 name The set of signals that a plant system I&C manages shall be defined using IO supplied tools. Page 5 of 16

8 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 name The 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 5 th 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 tools The 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 6 of 16

9 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 Variables In 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 Variables State Simple commands Control Equipment Configuration Variables Configuration Static Configuration (Self-description) Output signals Input Signals Equipment 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 7 of 16

10 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 Variable kind Variables 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 Values type The 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 8 of 16

11 Table 1 - Supported elementary data types for values Symbol INT8 UINT8 INT16 UINT16 INT32 UINT32 FLOAT32 FLOAT64 Description 8 bits signed integer 8 bits unsigned integer 16 bits signed integer 16 bits unsigned integer 32 bits signed integer 32 bits unsigned integer 32 bits float 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 Commands Commands 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 1 Simple 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 Interface The 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 9 of 16

12 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 Limit Alarm Alarm 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 State Alarm State 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 Interface Using 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 10 of 16

13 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 Data The 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 data Any 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 data Any 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 11 of 16

14 3.8 Error and Trace logging The 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 12 of 16

15 4 Standard Interface Data The 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 Request In 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. <CBS1>-<CBS2>:COS-OPSTATE 1 Off 2 NotReady 3 Ready 4 Initialising 5 Initialised 6 Executing 7 PostChecks 8 Terminating 9 Aborting 10 Absent 11 Local 12 Fault 13 Safe Table 2 Values for COS variable <CBS1>-<CBS2>:COS-OPREQ 1 SwitchOff 2 SwitchOn 3 gotoready 4 Initialise 5 gotoinitialised 6 Execute 7 PostCheck 8 Terminate 9 Abort gotolocal? 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 implements For 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 13 of 16

16 4.2 System monitoring function In 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>-SYSM The 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 Simulation Simulation 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 Mode The 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 14 of 16

17 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 15 of 16

18 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] Page 16 of 16