PDF generated on 21 Dec 2018DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

How To

Signal and plant system I&C Variable Naming Convention

Plant system instrumentation and control (I&C) design requires the application of a naming convention for signals for piping and instrumentation diagrams (P&ID) and electrical diagrams. In addition, a naming convention for plant system I&C variables is needed for user software engineering, CODAC functions concerning control, mimics and more generally, the human machine interface (HMI). This document presents a naming convention applicable for both I&C signals and variables.

Approval Process Name Action AffiliationAuthor Pimentel L. 07 Dec 2018:signed IO/DG/COO/SCOD/CSD/PCICo-AuthorsReviewers Petitpas P.

Stepanov D. 07 Dec 2018:recommended17 Dec 2018:recommended

IO/DG/COO/SCOD/CSD/PCIIO/DG/COO/SCOD/CSD/CDC

Approver Wallander A. 21 Dec 2018:approved IO/DG/COO/SCOD/CSDDocument Security: Internal Use

RO: Petitpas PierreRead Access LG: CODAC team, AD: ITER, AD: External Collaborators, AD: IO_Director-General, AD: EMAB, AD:

Auditors, AD: ITER Management Assessor, project administrator, RO, AD: OBS - Control System Division (CSD) - EXT, AD: OBS - CODAC Section (CDC) - EXT, AD: OBS - CODAC Section (CDC), LG: Cryogenic Section lin...

IDM UID

2UT8SHVERSION CREATED ON / VERSION / STATUS

07 Dec 2018 / 9.1 / Approved

EXTERNAL REFERENCE / VERSION

PDF generated on 21 Dec 2018DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

Change Log

Signal and plant system I&C Variable Naming Convention (2UT8SH)

Version Latest Status Issue Date Description of Change

v1.0 In Work 17 Aug 2009

v1.1 Signed 24 Aug 2009 Comments received on 24th of August taken in accountv1.2 Signed 25 Aug 2009 Comments from CODAC team taken in account. Version ready to be

reviewed by IOv1.3 Signed 25 Aug 2009 Comments from CODAC team taken in account. Version ready to be

reviewed by IOv1.4 Signed 26 Aug 2009 Version ready to be reviewed by IOv1.5 Signed 26 Aug 2009 Version ready to be reviewed by IOv2.0 Signed 17 Sep 2009 New version after IO reviewv2.1 Signed 18 Sep 2009 Update after last? CODAC team review. ready for final check by IO

IO comments pushed in https://user.iter.org/?uid=2W3A4Y&action=get_document

v2.2 Signed 02 Oct 2009 Final version without markup. No significative change with respect to previous one

v2.3 Approved 07 Oct 2009 Final version ready for approvalv3.0 Signed 28 Jan 2010 Official PCDH v5 review outcomes included

if(typeof editorarray == 'object'){ editorarray.push('ctl00_MasterPlaceHolder_DocumentView1_ctl01_ctl08_ver_description') }

v4.0 Signed 28 Jan 2010 PCDH v5 review includedv5.0 Signed 29 Jan 2010 Update after PCDH v5 reviewv5.1 Approved 29 Jan 2010 Update after PCDH v5.0 reviewv6.0 Signed 10 Sep 2010 Introduction of the FBS for variable namingv7.0 Signed 03 Jan 2011 New version to be reviewed in scope of PCDH v6.v7.1 Signed 03 Jan 2011 New version to be reviewed in scope of PCDH v6.v7.2 Signed 05 Jan 2011 J Poole reviewv7.3 Approved 08 Feb 2011 Version after PCDH v6 external reviewv7.4 Approved 10 Mar 2011 Minor changes on a reference doc version number and a figure not well

formatted in the pdf file.v8.0 Signed 08 Jan 2013 Update in scope of the PCDH v7 release. No major change only typos solved

plus CBS introducedv8.1 Approved 08 Jan 2013 Update in scope of the PCDH v7 release. No major change only typos solved

plus CBS introduced. One type fixed/ v8.0

if(typeof editorarray == 'object'){ editorarray.push('TabPlaceHolder_DocumentView1_ctl01_ctl00_ctl00_ctl16_ver_description') }

v9.0 Approved 02 Nov 2017 Significant maintenance revision to incorporate return on experience:- 1.3 requirements for document maintenance- 2.3 detailed description of how to use AAAA, RRRR and SSS codes- 2.4 support for 5 CBS levels and restrictions of CBS choice- 2.5 recommendations to follow for system specific variable naming conventions and reference to existing software specific naming

PDF generated on 21 Dec 2018DISCLAIMER : UNCONTROLLED WHEN PRINTED – PLEASE CHECK THE STATUS OF THE DOCUMENT IN IDM

conventions- 2.6 new section to describe how to name variables that have no associated physical signal- 2.7 new section to describe how to name variables associated with higher order information- New figures, references and acronyms to accompany new and revised text

v9.1 Approved 07 Dec 2018 Minor changes:- 2.5: Extension of the variable name limit name from 16 cars to 24 max; Correct inconsistency on the written instructions and figure description on how to compose variable name from a signal regarding padding zeros. (I JIRA ticket PBS43-127).- 2.8: Added section with the recommended variable description length and content.- Annex A: added table with the different platforms limitations on variable name and description lengths.-1.5; 2.3; 2.7: Updated all [RD8] ISA-5.1-1984 (R1992) document reference to ISA-5.1-2009- Added page numbering.

Records of revisions

Revision Date Description Modified Pages 0 25/08/2009 First draft -

1 30/07/2009 Version after CODAC review for PCDH v5 all

2 16/09/2009 First IO review all

3 07/10/2009 Version ready for approval by PDDG for PCDH v5

1

4 25/01/2010 Second IO review all

5 16/08/2010 Clarification of component, signal and PVs, Signal naming convention kept unchanged.Definition of a new PV naming

Section 2.1

Section 2.3

6 10/09/2010 CODAC internal review, see review formPV replaced by variable to keep generic

all

7.1 10/11/2010 Update after IO review all

7.2 05/01/2011 J Poole review all

7.3 08 Feb 2011 Version after PCDH v6 external review Cover page

8 01 Aug 2012 Update for PCDH v7: some typos fixed, CBS introduced, added reference documents in use for naming convention, procedure for naming signal introduced, upper case requirement for PS I&C interface variables

all

Page 2 of 17

9 21 September 2017

Significant maintenance revision to incorporate return on experience:

- 1.3 requirements for document maintenance

- 2.3 detailed description of how to use AAAA, RRRR and SSS codes

- 2.4 support for 5 CBS levels and restrictions of CBS choice

- 2.5 recommendations to follow for system specific variable naming conventions and reference to existing software specific naming conventions

- 2.6 new section to describe how to name variables that have no associated physical signal

- 2.7 new section to describe how to name variables associated with higher order information

- New figures, references and acronyms to accompany new and revised text

all

9.1 30/11/2018 - 2.5: Extension of the variable name limit name from 16 cars to 24 max; Correct inconsistency on the written instructions and figure description on how to compose variable name from a signal regarding padding zeros. (I JIRA ticket PBS43-127).- 2.8: Added section with the recommended variable description length and content.- Annex A: added table with the different platforms limitations on variable name and description lengths.-1.5; 2.3; 2.7: Updated all [RD8] ISA-5.1-1984 (R1992) document reference to ISA-5.1-2009- Added page numbering.

13,14,16,17

Page 3 of 17

TABLE of CONTENTS1. INTRODUCTION....................................................................................................................4

1.1. PCDH context...................................................................................................................41.2. Document scope................................................................................................................41.3. Document identifiers........................................................................................................51.4. Acronyms ..........................................................................................................................51.5. Reference documents .......................................................................................................6

2. NAMING CONVENTIONS....................................................................................................72.1. I&C components, Signals and Variables .......................................................................72.2. Component identifiers .....................................................................................................92.3. Signal identifiers.............................................................................................................102.4. Function identifiers ........................................................................................................132.5. Variable identifier ..........................................................................................................132.6. How to name variables that have no associated physical signal ................................152.7. How to name variables associated with higher order information ...........................152.8. Variables description field.............................................................................................162.9. Questions on applying the naming convention............................................................16

Annex A – Variable name length technical limitations ..............................................................17

Page 4 of 17

1. INTRODUCTION

1.1. PCDH contextThe Plant Control Design Handbook (PCDH) [RD1] defines methodology, standards,

specifications and interfaces applicable to ITER plant instrumentation & control (I&C) systems 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 I&C system life cycle and recaps

the main rules to be applied to the plant I&C systems 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.

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.

Figure 1: PCDH documents structure for version 7

1.2.Document scopeA naming convention has been set up and is already applicable for ITER components. The

plant I&C systems include components which must be named accordingly. In addition, because signals and variables of the plant I&C system cannot be identified by the component naming convention alone (a controller, sensor and actuator may be connected to several signals) the need arises for a convention tailored to signal and variables specificities. This document proposes a naming convention for signals linked to ITER components as well as for variables implemented by the plant system’s controllers.

Page 5 of 17

1.3.Document identifiersTable 1 provides the full list of document identifiers used in this document. The

recommendations raised in this document are guidelines; some are rules and in such a case they are identified by a star symbol. In this way it will be easier for the user to understand the requirements.

Table 1: Paragraph identifiers

RD Reference Document Rules referenced in core PCDH

1.4.AcronymsTable 2 shows the acronyms used in this document. This table includes relevant acronyms

which have been extracted from PCDH.Table 2: Acronyms

Acronym ItemCBS Control Breakdown StructureCODAC COntrol, Data Access and CommunicationI&C Instrumentation & ControlIDM ITER Document Management systemIEC International Electro-technical CommissionIED Intelligent Electronic DeviceIO ITER OrganizationIRIO Intelligent Reconfigurable Input/OutputISA Instrumentation Symbols and IdentificationLAC Local Air CoolerP&ID Process and Instrumentation DiagramPBS Plant Breakdown StructurePCDH Process Control Design HandbookPLC Programmable Logic ControllerRIO Remote Input/OutputRO Responsible OfficerSIC Safety Important ComponentSR Safety Relevant

Page 6 of 17

1.5.Reference documents[RD1] Plant Control Design Handbook (27LH2V)[RD2] ITER Numbering System for Components and Parts (28QDBS) [RD3] EDB: PBS Registry (https://user.iter.org/?uid=2FBMWF)[RD4] ITER Function Category and Type for ITER Numbering System (2FJMPY)[RD5] EDB: Function Category Designator (TTT) Registry

(https://user.iter.org/?uid=43WDW9) [RD6] EDB: Plant Component Registry (https://user.iter.org/?uid=65Y3RC)[RD7] PSP: AAAA Registry (https://psp.iter.org/PsProfile/page/psDesign/aaaa.faces)[RD8] ISA-5.1-2009[RD9] PSP: SS Registry (https://psp.iter.org/PsProfile/page/psDesign/ss.faces)[RD10] PSP: Signal Database (https://psp.iter.org/PsProfile/page/psDesign/psSignalDetails.faces)[RD11] ITER Control Breakdown Structure (CBS) (9TYFWC)[RD12] IRIO Library user's manual (RATM8Z)[RD13] PLC Software Engineering Handbook (3QPL4H)[RD14] CODAC Core System Migration Guide (7JCFUD)[RD15] IEC61850 Naming and Mapping Conventions for ITER Electrical Substation Automation

System (AHH8UR)[RD16] Guidelines for PIS configuration and integration (7LELG4)[RD17] Naming convention for safety I&C variables (SNFMR5)[RD18] 01_Diagnostics Plant I&C Design Process (SRS and SDS) with link to templates and

examples (JQLRRK)[RD19] 34.0I.PC - IOTS - 000004 : PLC control logic standardisation for PBS 34 (N3Y8M7)[RD20] System Health Monitoring Variables (35XFCY)[RD21] PCDH ROs (U8S7Z5)

Page 7 of 17

2. NAMING CONVENTIONS

2.1. I&C components, Signals and VariablesDefinitions:- A signal is analogue or binary state, configuration or command information that comes on a

physical medium from/to a plant system sensor or actuator to/from a control system signal interface or controller.

- I&C components include sensors, actuators, controllers, servers, any central CODAC equipment and the associated software for all this equipment.

- I&C cables may be signal cables, field-bus cables or network cables. They may be copper or optical fibre. A signal cable may carry either analogue or digital signals. An I&C component may generate or use one or many signals.

- Variables are digitized representations of signals or representations of properties related to or derived from signals. Once signals have been digitized in a signal interface, the I&C controllers work with variables. By extension a variable can be any representation of data used by I&C controllers.

- I&C functions manipulate controller variables and are implemented by controllers.All of the entities listed above need to be named. The ITER component naming convention

[RD2] applies for physical items: components and cables. This document discusses both signal naming (Section 2.3) and variable naming (Section 2.5).

I&C components and I&C signals:Figure 2 illustrates the components involved in a simple example of physical architecture

from the plant system sensors and actuators to the central CODAC system.

PS actuator

Signal cable

Signal cableFieldbus cable Network cable

Signal interface

Plant system I&C controller

Central CODAC

components

Plant system I&C

components

P

PS sensor

PSH

Figure 2: I&C physical architecture with I&C components

Page 8 of 17

From signals to controller variables:

Signal interface

P

Sensor/actuator

Signal

Signal conditioner

Signal/variable

Controller rack

Variable

Cubicle

Cable

Figure 3: Conversion of I&C signals to controller variables

In the model of conversion presented in Figure 3, the input/output boards of the controllers are acting as converters from signals to variables:

The common model of conversion is: one signal = one process data = one variable to carry the data.

Some I&C signals carry multiplexed data. In such a configuration the model becomes: one signal = several process data = several variables.

In this section, we make the distinction between “signals” and “variables,” and define the “signal interface” (the point where analogue signals are digitised) as the point at which a signal becomes a variable. A different naming convention is proposed for signals and variables. The convention for signals is:

Signal Name = Component Identifier : Signal IdentifierThe component identifier is based upon the plant breakdown structure (PBS) and the rules for

forming component names are reviewed in section 2.2 below. Rules for forming the signal identifier are reviewed in section 2.3.

By analogy, the convention for naming variables is: Variable Name = Function Identifier : Variable Identifier

The function identifier is based on the control breakdown structure (CBS) and the rules for forming function names are given in section 2.4. Rules for forming the variable identifier are given in section 2.5.

Page 9 of 17

2.2. Component identifiersA convention for uniquely identifying parts and components for ITER is defined in the ITER

Numbering System for Parts/Components, see [RD2]. This naming convention is applicable to any component of the plant I&C system.

This reference consists of three identifiers separated by the separator (hyphen “-“): - Plant Breakdown Structure (PBS) Identifier: PPPPPP; - Component functional category designator: TTT; - Sequential Number: NNNN.Therefore, the format of any ITER component name is:

PPPPPP-TTT-NNNN.

The PBS Identifier (PPPPPP) identifies the plant system PBS level 3 to which the component belongs to. See [RD3] for PBS registry.

The Function Category Designator (TTT) designates the type of component and belongs to the list of types defined in the ITER Function Category and Type, see [RD4] for TTT rules and [RD5] for TTT registry. The Sequential Number (NNNN) shall be allocated by IO so that the complete identifier

(PPPPPP-TTT-NNNN) is unique within the whole ITER plant.

PPPPPP identifiers - Cooling water plant system: 26- PHTS water loops: 26.PH- Divertor/limitor loop: 26.PH.DL

PPPPPP = 26PHDL- Component cooling water: 26.CC- CCWS1 water loop: 26.CC.C1

PPPPPP = 26CCC1

26PHDL-VC-0002

26PHDL-HX-0001

26PHDL-VC-0001 T

P

26PHDL-MT-001526CCC1-MP-0010

TTT identifiers- Heat exchanger: HX- Valve: VC- T sensor: MT- P sensor: MP

Figure 4: Illustration of component naming applied to plant system equipment involving components from different PBS

Page 10 of 17

2.3. Signal identifiersPlant I&C system design requires a naming convention for signals to be applied in P&ID,

and electrical diagrams etc. Any I&C signal name is made of two identifiers separated by a colon “:”. The first is the

identifier of the component producing the signal; the second is the identifier of the signal within the component.

The component naming convention, as defined in the previous section, applies to the component identifier.The signal identifier shall satisfy the following naming convention:

AAAA[RRRR]-SSS.

The signal identifier is made of three parts. - The first part AAAA identifies the sensor/actuator class using the ISA-5.1-2009 [RD8]

standard for instrumentation symbols and identification;- The PSP registry [RD7] contains a list of predefined standard ‘AAAA’ codes. - However for some signals, there might be requirement of new ‘AAAA’ codes

which are not available in [RD7]. In such scenarios a new ‘AAAA’ code can be derived using ISA-5.1 as specified in the PCDH [RD1], providing: New ‘AAAA’ codes must not conflict with existing codes in [RD7]. [RD7] must be updated to include any new AAAA codes.

- The second part RRRR is an optional alpha-numeric string of maximum 4 characters and used to identify several sensors/actuators of the same class within the component;

- If there are several signals with the same PPPPPP-TTT-NNNN:AAAA part, define RRRR to distinguish them;

- If RRRR begins with an alphabetic character then use “-“ (hyphen) as a separator;- When a component has multiple signals with the same AAAA code then RRRR

should be used to distinguish between them For example, valve position indicators with multiple contacts, open/close

actuators with multiple inputs and pressure transmitters that measure both differential and absolute values;

- RRRR should also be used when signal duplication is used to interface a signal to multiple plant controllers For example, when a sensor or valve is monitored or controllable by both

safety and interlock controllers, or safety/interlock and conventional controllers; or all three

Appropriate command priority should be applied in the actuators to ensure that safety is the top priority;

The following prefixes in the RRRR code are suggested when signal duplication is used:

C = Conventional (neither interlock nor safety) control I = Interlock SA = SIC-1 SB = SIC-2B

Page 11 of 17

SC = SIC-2C SR = SR-C SO = Occupational Safety If signals are duplicated between A and B trains then R3 could

indicate which train, e.g. SAA or SAB. This will ensure that variables also have unique names (note that the SSS

code is not used in variable names).

- The third part SSS is an alphabetic string of 3 characters introduced by a hyphen “-”. It is used to identify the signal type:

- S1 is determined by whether the signal is control (C), interlock (I) or safety (S);- S2 indicates if the signal is raw (R) or if it has been conditioned in some way (C);

Typically raw signals are those immediately issued from the plant component whereas conditioned signal have been changed in some way, typically changing the voltage or current to a different range from the raw signal;

E.g. the low level voltage signal from a whetstone bridge or thermocouple is a raw signal, but the output from the transmitter is conditioned and a standard range;

A measurement signal from the field should be defined as raw (R) only up until a signal conditioning device and defined as conditioned (C) after it is conditioned;

A command signal output from a controller should always be defined as raw (R). If the signal passes through a conditioner before it reaches an actuator then is becomes conditioned (C).

- S3 indicates if the signal follows the standard (C) voltage, current and pressure ranges defined in section 4.5.5 of the PCDH, or if the signal is different, e.g. lower (L) or higher (H).

Therefore the signal name format is as shown in Figure 5. Note that square brackets [ ] around RRRR denote this part is optional, do not put [ ] in the signal ID.

Identification Code

Identification Fields

Syntax

Expected Usage

PBS IdentifierFunction Category

Designator

Sequential Number

PPPPPP - TTT - NNNN :

Functional Reference

AAAA[RRRR]-SSS

Sensor Class

Several Sensors of Same

class

Signal Identifier

Signal TYpe

Figure 5 Signal Naming Format

Page 12 of 17

Figure 6 shows how signals for various sensors and plant equipment could be named. It shows typical process measurements for temperature, pressure and flow, with valve and pump control and feedback signals. In this example the signals for the flow switch, valve and pump speed feedback do not need to be conditioned. However other signals for the thermocouple, pressure sensor strain gauge and pump speed control must pass through a signal conditioner before they are useful. The AAAA part remains constant throughout the signal loop whilst the SSS part changes if the signal passes through an intermediate signal conditioner.

26PH

DL-M

FL-0

001:

FL-C

RC

26PH

DL-V

C-00

01:Z

O-C

RC26

PHDL

-VC-

0001

:ZC-

CRC

26PH

DL-V

C-00

01:Z

REF-

CRC

26PH

DL-V

C-00

01:Z

T-CR

C

T FP

26PHDL-PLC-0001 Control System

26PHDL-MTE-0001 Thermocouple

26PHDL-MWS-0001Strain Gauge 26PHDL-VC-0001

Regulating Valve

26PHDL-MFL-0001 Flow Switch

26PHDL-SCI-0001 Signal Conditioner

26PHDL-SCI-0002 Signal Conditioner

26PH

DL-M

TE-0

001:

TT-C

RC

26PH

DL-M

WR-

0001

:PT-

CRL

26PHDL-MTE-0001:TT-CCC

26PHDL-MWR-0001:PT-CCC

AAAA codes: FL: Flow – level low PT: pressure SREF: Speed set-point ST: Speed transmitter TT: Temperature ZC: Position closed ZO: Position open ZREF: Position set-point ZT: Position transmitter

SSS codes: CCC: Conventional conditioned standard signal CRC: Conventional raw standard signal CRL: Conventional raw low-level signal CCH: Conventional conditioned high-level signal

26PH

DL-P

L-00

01:S

REF-

CCH

26PHDL-PL-0001:SREF-CRC

26PHDL-MSC-0001 Speed Controller

26PHDL-PL-0001 Pump

26PH

DL-P

L-00

01:S

T-CR

C

Figure 6: Illustration of I&C signal naming.

Recommended procedure to name a signal:1. Determine the plant component which emits or consumes this signal. This gives the

PPPPPP-TTT-NNNN part;2. Consult the registry of AAAA codes, [RD7] , to select the right code; or propose a new

code, as described above;3. If you have several signals with the same PPPPPP-TTT-NNNN:AAAA part, define RRRR

to distinguish them;4. Determine if your signal is control (C), interlock (I) or safety (S). This gives the first letter

of the SSS field;

Page 13 of 17

5. Consult the registry of SS codes, [RD9] , to select the reminder of the SSS field; or propose a new code, as described above;

6. Verify that the complete identifier PPPPPP-TTT-NNNN:AAAA[RRRR]-SSS is not in use in the global signal registry [RD10].

2.4. Function identifiers

A Control Breakdown Structure (CBS) is defined for the whole ITER plant. See [RD11]. The plant system function identifier shall be based upon a Control Breakdown Structure (CBS)

and satisfy the following naming convention:- Within each hierarchical CBS level, a plant system function is identified by an alpha-

numeric string of maximum 4 characters: FFFF. This string identifier shall be unique within the CBS level concerned and all letters shall be in upper case.

- The full plant system function name consists of all required function identifiers separated by the separator (hyphen “-“).

- The function name must include at least one function identifier.- There is no maximum number of levels for the CBS, however to ensure legibility the

maximum number of function identifiers that may be included in a function name is 5.

Therefore the plant system function format is, for example:

- FFFF-FFFF-FFFF for a level 3 function- FFFF-FFFF-FFFF-FFFF-FFFF for a level 5 function.

CBS tree nodes “SYSM – System Monitoring” (level 3) and “HWCF – Hardware Configuration” (level 3) are reserved for software internal use. They are used to host process variables required for proper functioning of central I&C infrastructure. Plant I&C system engineers shall not use these functions for designating plant system process-specific variables. These nodes are assumed for every plant I&C system and are not shown in the rest of the document.

2.5. Variable identifierThe variable name format is: Function Identifier : Variable Identifier

The variable identifier is a free string of 24 characters maximum VV…VV, provided the full name including the function identifier is unique within the whole ITER plant.

- Only alphanumeric characters should be used, with “-“ (hyphen) permitted as a separator. Any alphabetic character used in names shall be in upper case.Therefore, the variable name format is:

FFFF-…….FFFF:VV…. VV

For variables directly reflecting data from I&C signals, it is recommended that the variable identifier VV….VV should satisfy the following naming convention:

- The variable Identifier is made of two parts separated by the separator (hyphen “-“):

Page 14 of 17

- The first part is the component identifier described in section 2.2, but without the PBS identifier PPPPPP.

- The second part is the signal identifier as mentioned in section 2.3, but without the SSS suffix for signal type.

Thus the complete variable identifier format would be:

TTTNNNN-AAAA[RRRR]

Figure 7 illustrates a possible CBS for the Cooling Water System (CWS) and an example of the conversion of signal names to variable names.

Figure 7: Example of variable naming using the CBS and the signal namesThere are many field devices which produce multiple variables from a single physical

measurement connection. These variables must also be named following the convention described above and a proposed method to do this is explained in section 2.6.

Plant controllers will produce lots of information that is calculated from the signal information received from the plant components but does not relate directly to physical signals. All variables that are used to represent this information should also be named following the variable naming convention and a proposed method for this is described in section 2.7.

Variable names should be used in all design documents and databases, as well as in all software source code where feasible. Additional rules may apply depending on the software in which the variables and signal names are referenced. These rules will be detailed in specific software engineering documents attached to core CODAC documents or to PCDH. For example, there are restrictions on variable names for software that interfaces the IRIO devices [RD12]; in

Page 15 of 17

PLC software [RD13][RD14]; in IEC 61850 devices [RD15]; in plant interlock systems [RD16] and plant safety systems [RD17].

2.6. How to name variables that have no associated physical signalThere are many field devices which produce multiple variables from a single physical

measurement connection. The variables often relate directly to physical characteristics of an object that can be calculated from the original measurement. For example, in electrical systems metering devices are often used to measure multiple electrical properties such as +/- kWh, +/- kVArh, kVAh, I, U, V, F, P, Q, S, PF, etc. The device calculates values for each of these properties and sends the information by fieldbus to a PLC which passes it on to CODAC.

Other examples are plant components with integrated controllers, such as protective relay intelligent electronic devices (IED), local air coolers (LAC) and many off-the-shelf pumps and motors.

In all these cases the information sent over fieldbus is data, it is not a signal. All the data relates directly to a physical object and could be measured by a dedicated physical signal, but for valid reasons the plant I&C design has taken a different approach. All this data within fieldbus connections should be named using the variable naming convention.

In many of these cases the physical measurement connection between the controller/sensor and the plant is not apparent to the user. In these cases it is not mandatory to assign signal names to the connections, however it is still recommended because it helps to produce the variable names using the following approach:

1. List all information that is transmitted by fieldbus (in both directions)2. If sensors/actuators are known then assign each piece of information to a sensor or actuator

a. Then assign a signal name to each sensor and actuator following the standard signal naming convention described in section 2.3

i. If a sensor or actuator already has a component ID use the TTT and NNNN of the component ID;

1. If not then use the TTT and NNNN of the overall field device that is connected to the fieldbus

ii. Choose AAAA codes as described in section 2.33. Generate virtual signal names for all remaining information which it is not possible to

assign to a sensor or actuator, again following section 2.3a. Use the TTT and NNNN of the field deviceb. Select an appropriate AAAA code as above

4. As described in section 2.5 generate variable names using the real and virtual signal names identified in steps 2 and 3.

2.7. How to name variables associated with higher order informationPlant controllers will produce lots of information that is calculated from the signal information

received from the plant components but does not relate directly to any physical connection. There will also be variables that are used as part of the controllers programme, such as control gains, calibration and states. In EPICS terminology these are known as “soft” variables. All variables that are used to represent this information should also be named following the variable naming convention.

Specific naming conventions have already been defined for diagnostics (PBS 55) [RD18] and cryogenics systems [RD19]. All names for health monitoring data of I&C controllers are already defined in CODAC core system documentation [RD20]. Approaches for interlock [RD16] and safety systems [RD17] have already been defined.

Page 16 of 17

In the absence of a defined convention for the names of higher order variables within a system, and where the information is in respect to specific characteristics of specific objects, it is recommended to follow the TTTNNNN-AAAA[RRRR] convention if feasible.

1. Identify a suitable TTT code for the object [RD5] about which the variable represents a property

a. If no suitable TTT code exists then choose a new code from ISA-5.1-2009 to represent this object

b. If ISA-5.1-2009 contains nothing suitable then define a new acronymc. Note that it is not necessary to make a formal TTT code but the chosen code must

be unique and recorded in I&C design documentation2. If there is more than one of these type of objects represented in this CBS node then use

NNNN to differentiate between them3. Identify a suitable AAAA code for the property which is represented by the variable

(section 2.3)a. If no suitable AAAA code exists then choose a new four-letter-acronym to

represent this propertyb. Note that it is not necessary to make a formal AAAA code but the chosen code

must be unique and recorded in I&C design documentation4. If there is more than one of these type of properties associated with this object then use

RRRR to differentiate between them

Any systems which do not follow TTTNNNN-AAAA[RRRR] must define their naming convention in an approved procedure on IDM and include it within the I&C design deliverables. This will provide a reference to all users of the system to help them find and use the variables. All proposed conventions must have a methodical structure that will allow software to reliably parse the variable name to determine what it represents.

2.8. Variables description fieldWhen the I&C controller / software platform has available a description or comment attribute

linked to the variable (see Table 3) it is recommended to use it do describe the basic information about the meaning of the variable.

In case there is no dedicated field for units in the platform, the description shall contain reference to the unit of the value in question if applicable. In this case the unit text shall be defined at the beginning of the description enclosed by the following fixed pattern #[unit], enabling automatic parsing by importing tools.

Example of a description text: #[bar] Pressure sensor measurement

The recommended maximum length for the total description content is 80 characters. However, since the EPICS limit for the description field is currently of 40 characters, all the basic information should be contained in the first 40 characters, allowing to truncate and import the text to EPICS without losing the most significant information.

2.9. Questions on applying the naming conventionTo ensure that the standards and recommendations described in this document are applied in a

consistent way and to provide adequate guidance to all plant I&C engineers all questions about naming conventions for I&C should be copied to the RO for this document, as defined in [RD21].

Page 17 of 17

Annex A – Variable name length technical limitationsTable 3. List of the variable and description length technical limitations per platform

Platform Possible local variable name length

Variable name length enforced

by SDD

Possible variable description

lengthPLC – Siemens Simatic Manager 6x[24]+24* 23 (FF): 24 (VV) 80

PLC – Siemens TIA Portal 7x127+24* 23 (FF): 24 (VV) No limit

3.14.1 ≤ EPICS v. ≤ 3.15.1 ( 1.0.0 ≤ CCS v. ≤ 5.0.0 )

27 (out of 60, imposed by

links usability)60 40

3.15.2 ≤ EPICS v. ≤ 3.15.4 ( 5.1.0 ≤ CCS v. ≤ 5.3.0 )

60(links limit increased

to 128)60 40

EPICS v. 3.15.5 ( 5.4.0 ≤ CCS v. ≤ 5.4.1 )

60(links limit increased

to 256)60 40

7.0.1 ≤ EPICS v. ( 6.0.0 ≤ CCS v. )

60(links unlimited) 60 40

SDD 100 60 300

CS Studio100 (BEAST and

BEAUTY, no limit on BOY)

60 40

PSP database FF(24):VV(24) 60 255

PSPS Editor No limit 60 No limit

SDN 100 60 80

DAN 100 60 80

UDA 100 60 100

OPC UA 4096** 60 No limit

OPC DA 255** - NA

WINCC OA 128** - 500 (alarm 80)

Matlab v > 6.5 63 - NA

NI Labview 255** - NA

* Levels of nested structs with 24 chars each + final variable name with 24 chars. ** Including server name