Naming Convention - pw-cdn.watercorporation.com.au

Digital Transformation Group Operational Technology

DESIGN STANDARD DS 40-02

Naming Convention

VERSION 1

REVISION 4

APRIL 2018

Design Standard No. DS 40-02

Naming Convention

Uncontrolled if Printed of 34

Ver 1Rev4

© Copyright Water Corporation 2001-2018

FOREWORD

Supervisory Control and Data Acquisition (SCADA) Design Standards are prepared to ensure that the Water

Corporation’s staff, consultants and contractors are informed as to the Water Corporation’s design standards

and recommended practices. Design standards are intended to promote uniformity so as to simplify design and

drafting practice and have as their ultimate objective the provision of safe and functional plant at minimum

whole of life cost.

The Water Corporation design standards and recommended practices described in this design standard have

evolved over a number of years as a result of design and field experience and these have been investigated and

documented.

Users are invited to forward submissions for continuous improvement to the Principal SCADA Engineer who

will consider these for incorporation into future revisions.

Manager, Operational Technology

This document is prepared without the assumption of a duty of care by the Water Corporation. The document is not

intended to be nor should it be relied on as a substitute for professional engineering design expertise or any other

professional advice.

It is the responsibility of the user to ensure they are using the current version of this document.

© Copyright – Water Corporation: This standard and software is copyright. With the exception of use permitted by the

Copyright Act 1968, no part may be reproduced without the written permission of the Water Corporation.


Naming Convention


Ver 1Rev4


DISCLAIMER

Water Corporation accepts no liability for any loss or damage that arises from anything in the

Standards/Specifications including any loss or damage that may arise due to the errors and omissions of any

person. Any person or entity which relies upon the Standards/Specifications from the Water Corporation

website does so that their own risk and without any right of recourse to the Water Corporation, including,

but not limited to, using the Standards/Specification for works other than for or on behalf of the Water

Corporation.

The Water Corporation shall not be responsible, nor liable, to any person or entity for any loss or damage

suffered as a consequence of the unlawful use of, or reference to, the Standards/Specifications, including but

not limited to the use of any part of the Standards/Specification without first obtaining prior express written

permission from the CEO of the Water Corporation.

Any interpretation of anything in the Standards/Specifications that deviates from specific Water Corporation

Project requirements must be referred to, and resolved by, reference to and for determination by the Water

Corporation’s project manager and/or designer for that particular Project.


Naming Convention


Ver 1Rev4


REVISION STATUS

The revision status of this standard is shown section by section below:

REVISION STATUS

SECT. VER./

REV.

DATE PAGES

REVISED

REVISION DESCRIPTION

(Section, Clause, Sub-Clause)

RVWD. APRV.

1 0/0 12.06.01 All New Version SFB AAK

1 0/1 17.09.01 All General revision SFB AAK

1 0/2 10.07.02 All Tag Definitions added SFB AAK

1 1/0 15.03.06 All Updated to reflect

standardisation; includes other

controller types

LNR AAK

1 1/1 30.01.09 6 Minor Corrections LNR JB

1 1/4 10.4.18 8-9 Updated for Operational

Technology. Removed Citect

references

JGB RP






controller types

LNR AAK

2 1/1 30.01.09 8, 9 & 10 Updated abbreviations and

Property Values and Property

Modifiers tables

LNR JB



references

JGB RP






controller types

LNR AAK

3 1/1 30.01.09 ALL Updated to reflect current

practice.

LNR JB



references.

JGB RP






controller types

LNR AAK


Naming Convention


Ver 1Rev4


REVISION STATUS

SECT. VER./

REV.

DATE PAGES

REVISED

REVISION DESCRIPTION

(Section, Clause, Sub-Clause)

RVWD. APRV.



references. Previous Sec 4

deleted. Sec5 renamed.

JGB RP






controller types

LNR AAK

5 1/1 30.01.09 ALL Updated to reflect current

practice.

LNR JB

5 1/2 15/2/12 5,6 Updated for regional

realignment

Peter

Taylor

JGB

5 1/3 1/5/13 Several Minor formatting change.

Minor typographical changes

Page number corrections

JGB JGB



references. Previous Sec 4

deleted. Sec6 renamed.

JGB RP


Naming Convention


Ver 1Rev4


DESIGN STANDARD DS 40-02 Naming Convention

CONTENTS Section Page

1 INTRODUCTION ........................................................................................................................ 8

1.1 Purpose ......................................................................................................................................... 8

1.2 Scope.............................................................................................................................................. 8

1.3 References ..................................................................................................................................... 8

1.4 Definitions ..................................................................................................................................... 8

2 STRUCTURED NAMING REQUIREMENTS ....................................................................... 10

2.1 Unique Name .............................................................................................................................. 10

2.2 Descriptive Naming .................................................................................................................... 10

2.3 Standard Lists ............................................................................................................................ 10

2.4 Openness ..................................................................................................................................... 10

2.5 Conformance to Systems ........................................................................................................... 10

2.6 Structured Descriptions ............................................................................................................ 11

2.7 Open System Compliant ............................................................................................................ 11

2.8 Positive Logic.............................................................................................................................. 11

2.9 Naming Abbreviations and Schedules ..................................................................................... 11 2.9.1 Abbreviations ............................................................................................................................... 11 2.9.2 Property Values ............................................................................................................................ 12 2.9.3 Property Modifiers ....................................................................................................................... 13

3 CLEARSCADA OBJECT NAMING CONVENTION ........................................................... 14

3.1 Format ......................................................................................................................................... 14

3.2 Process Object Naming ............................................................................................................. 14 3.2.1 Identifier Name Components ....................................................................................................... 14

3.3 Template Naming ....................................................................................................................... 21

3.4 Mimic Naming ............................................................................................................................ 22

3.5 Logic, Script and ODBC Query Naming ................................................................................. 23

3.6 Outstation/Scanner Naming...................................................................................................... 23

3.7 Trend Naming ............................................................................................................................ 24

3.8 Communication Naming ........................................................................................................... 24

3.9 Alarm Redirection Naming ....................................................................................................... 24

3.10 Schedule Naming ........................................................................................................................ 24

3.11 Archive Naming ......................................................................................................................... 25

3.12 Crystal Report Naming ............................................................................................................. 25

3.13 Forecast Naming ........................................................................................................................ 25


Naming Convention


Ver 1Rev4


3.14 Method Call Naming ................................................................................................................. 25

3.15 Random Generator Naming...................................................................................................... 25

3.16 Time Profile Naming ................................................................................................................. 26

3.17 Server Naming ............................................................................................................................ 26

4 LOCAL CONTROLLER NAMING CONVENTION............................................................. 27

4.1 Program Name Format ............................................................................................................. 27

4.2 SCADAPack RTUs .................................................................................................................... 27

4.3 Tag/Address Name Format ....................................................................................................... 28 4.3.1 Special Case Names ..................................................................................................................... 30 4.3.2 Naming Examples ........................................................................................................................ 31 4.3.2.1 General Tag Names ...................................................................................................................... 31 4.3.2.2 Special Case Names ..................................................................................................................... 32

5 CORPORATE SYSTEM NAMES ............................................................................................ 33


Naming Convention


Ver 1Rev4


1 INTRODUCTION

1.1 Purpose

This standard describes the formats, rules and conventions for the naming of data points, tags and

objects for SCADA, Control and related systems as well as the convention for assigning descriptions

to these items.

1.2 Scope

This standard applies to any SCADA, Control or related system containing data that can be named

and/or to which descriptions may be applied. This standard shall be used by any person involved in

designing or modifying names and descriptions on any SCADA, Control or related system.

1.3 References

DS24 - Electrical Drafting Standard

DS 40-06 - Software Change Control

DS 41-02 - Citect Configuration

DS 41-03 - ClearSCADA Configuration

DS 43-01 - DNP3 Polling

DS 80 - WCX CAD Standard

ANSI/ISA-5.1-2009 Instrumentation Symbols and Identification

1.4 Definitions

For the purpose of this standard, the following definitions shall apply:

Corporation Water Corporation (of Western Australia)

DNP3 Distributed Network Protocol. An open communications protocol

administered by the DNP User Group.

HMI Human Machine Interface (used to indicate the SCADA {or remote} operator

interface)

Local Controller Includes any device used to control assets. These will include devices such as

PLCs, RTUs and other controllers

MST Mode Sequence Table. A look-up table used as part of some Water

Corporation control strategies

OIP Operator Interface Panel. Used to indicate an operator interface located at

site. For the purpose of this standard it does not include touch panel type

operator screens.


Naming Convention


Ver 1Rev4


PLC Programmable Logic Controller

RTU Remote Terminal Unit

SOM Scheme Operating Matrix. A table representing scheme operating restrictions

which is used to control equipment.

Water Corporation

SOE

The Standard Operating Environment of Water Corporation workstations.

This encompasses a particular configuration of the operating system and

network settings.


Naming Convention


Ver 1Rev4


2 STRUCTURED NAMING REQUIREMENTS

All data in SCADA, Control and related systems must be named. For the purpose of this document

data has been classified into four (4) different types:

a) ClearSCADA Objects – Names of objects within the ClearSCADA Operator Interface shall

follow the ClearSCADA Object Naming Convention.

b) Local Controller Variables or Coils – Real world data to/from the Local Controller shall follow

the Local Controller Naming Convention.

c) Variables – Internal Data in the Operator Interface or Local Controller that is only ever used

within that system shall follow the Variable Naming Convention.

d) Special Case Names – Some internal data that is passed from the Local Controller to/from an

OIP is not suitable for the Naming Convention. In these situations a hybrid Tag/Variable

solution is followed.

The structured Naming Convention must meet the following requirements:

2.1 Unique Name

The Naming Convention creates a Name that is structured such that it can handle any situation,

whether it is creating a name for an instrument never used before or having many similar devices at

the same location. In any scenario, the Naming Convention is able to create a unique identification

tag.

2.2 Descriptive Naming

The nature, purpose and location of a device can be determined from the Name. This is limited to

identification of where and what, but does not attempt to fully ‘describe’ the device being named.

2.3 Standard Lists

The Naming Convention is built from a standard list or ‘schedules’. The name shall be broken into

sub-parts, and each sub-part will have a schedule listing of available choices.

2.4 Openness

If a Name has no correct choice from a standard list, then a new entry to the schedule can be created.

New entries to the schedule shall only be made when required and where the new entry adds value to

the Naming Convention. There shall be a ‘general’ entry on all schedules for use on unusual items

that are ‘one off’ or very infrequent.

2.5 Conformance to Systems

Names shall conform to the requirements of the systems to which they apply. Each system has

limitations on allowable Names. The limitation shall be applied to the Naming Convention. In

addition, bulk configuration methods that draw upon a good Naming structure shall be used.


Naming Convention


Ver 1Rev4


2.6 Structured Descriptions

All Names shall be assigned descriptions and these shall follow a meaningful structure. The

description system shall not attempt to rigorously document a complete system but rather form

guidelines to be adhered to. It is more important to have system consistency than unusable rigor.

Consistency includes the use of standard abbreviations and notation.

2.7 Open System Compliant

This Naming Convention has been designed to work on all SCADA and Control platforms currently

used in the Corporation. It would need to be tested for any new platforms (ie new Local Controller

programming languages) that are adopted by the Corporation.

2.8 Positive Logic

Names and Descriptions shall be ‘positive logic’, such that a digital logical ON state means the Name

and Description reads true. For example, a description of ‘valve fault’ shall mean that the valve has a

fault when the digital point is in the ON state and no fault when the digital point is in the OFF state.

2.9 Naming Abbreviations and Schedules

For consistency the following abbreviations and schedules shall be used in place of the full word(s).

2.9.1 Abbreviations

Abbreviation Item

Auto Automatic

Comms Communication

DB Deadband

EAS Excess Activated Sludge

FB Feedback

FS Float Switch

PS Pump Station

RAS Return Activated Sludge

RPT Report

SP Setpoint

TWS Town Water Supply

UPS Uninterruptable Power Supply

WAS Waste Activated Sludge

WC Water Conveyance

WS Water Supply

WT Water Treatment

WTP Water Treatment Plant

WW Waste Water


Naming Convention


Ver 1Rev4


WWC Waste Water Conveyance

WWT Waste Water Treatment

WWTP Waste Water Treatment Plant

2.9.2 Property Values

New properties required shall be added to this list. For one-off or unusual properties, the ZZZ

‘general’ object identifier may be used, but instances of this must be minimised.

Code Description

ACK Acknowledge

AUT Automatic

AVL Available

BAL Balance

BIA Bias

BLK Blocked

BWS Backwash

C Conductivity

CAL Calculate

CLP Clamp

CLS Close

CNV Converter trip

COM Communications

D Density

DBD Dead band

DER Derivative time

DEV Deviation

DSC Discrepancy

DTY Duty

E Voltage

EFF Efficiency

ENA Enable

EST Emergency stop

F Flow

FDE Fast decrease

FLT Fault/fail

FOL Follow

FUP Fast increase

HDC Hand control (physical)

HLD Hold

I Current

ILK Interlock

INH Inhibit

INS In service

INT Integral rate/time

IPT Input

J Power

K Time

Code Description

L Level

LNR Loop number

LOC Local

LRS Lower range setpoint

LDT Leak Detected

LTR Lookup Table Reference

M Moisture/humidity

MAN Manual

MCO Main Contactor

MST Minimum slew time

MTC Maintenance

NAV Not Available

OOS Out of service

ONL Online

OP Output

OPN Open

OVR Override

P Pressure/vacuum

PMN Permission

PPB Proportional band/gain

PV Process variable/value

RAT Ratio

RCX Receive

RDY Ready

REM Remote

RNG Running

RST Reset

RTR Requested to run

S Speed/frequency

SBY Standby

SDE Slow decrease

SEC Security

SEL Select

SMP Sample period

SPT Setpoint track

SRG Surge Diverter

STA Status

STP Stop


Naming Convention


Ver 1Rev4


Code Description

STR Start

SUP Slow increase

T Temperature

TOL Thermal Overload

TRQ Torque

TRX Transmission

TST Test

V Vibration

VOL Volume

W Weight/force

Z Position

ZZZ General

2.9.3 Property Modifiers

Where possible the property modifier shall be determined as per the table in ANSI/ISA-5.1-2009

standard section 4. Refer to DS24 Section 22 for additional details.

In addition the following modifiers may also be used:

Code Description Order

B Blocked or Disabled 3

E Added to tags that are mapped from one device to another without change 4

P Process Variable 1

Q Totaliser/Accumulator 1

R Real world input/output 4

S Setpoint 1


Naming Convention


Ver 1Rev4


3 ClearSCADA OBJECT NAMING CONVENTION

3.1 Format

It is essential that the object naming convention is followed, as many systems have been configured

with the convention in mind.

Object naming must be consistent. The best way of creating an object is to compare with previously

(correctly) implemented objects. Examples are included within this document.

Where numbers are used in the naming, thought shall be given to whether left padding of zeros is

required. Left padding with zeros is required up to the expected maximum number of significant

digits

3.2 Process Object Naming

Every object in the Operator Interface is described by an ‘identifier’. This identifier is required to

describe any data point in the Operator Interface to allow grouping and filtering by region, district,

scheme, facility, etc. The identifier can be used as the ‘directory’ structure required creating the SCX

database. In addition, some or all of the identifiers can be used as the ‘comment’ field required by the

PI data historian in order to provide an English language searchable point source identifier. In

general, the point description is the English language description of the site, abbreviated for ease of

referral at a glance.

When naming objects do not use symbols such as the forward slash. The ampersand symbol (&)

should be replace with the word “and”.

The makeup of the identifier is:

<Region>.<District>.{<Site>,<Plant>,<Scheme>}.{<Area>,<Process>,<Facility>}.{<Equi

pment>,<Object>}.<Module>.<Config>.{<Component>,<Attribute>}

Where:

“.” is the delimiter between each component of the identifier,

<xyz> is replaced with the appropriate name or value, and

{A, B, C} denotes any one of A, B or C.

3.2.1 Identifier Name Components

The following describes the components of the identifier. Each identifier can be omitted, have only

one instance (1) or may have two (2) instances as shown.

Component Information

Region Description The name of the Operating Region

Instances: 1 instance


Naming Convention


Ver 1Rev4


Allowable Values: GAR = Goldfields and Agricultural Region

GSR = Great Southern Region

Metro = Metropolitan Region

MWR = Mid West Region

NWR = North West Region

SWR – South West Region

District Description The name of the Operating District within the Region

Instances 1 instance


Naming Convention


Ver 1Rev4


Allowable Values GAR:

Agricultural East

Agricultural West

Goldfields

South Coastal

GSR:

LGS - Albany

UGS - Katanning

UGS - Narrogin

Metro:

WWT

Perth North

Perth South

Mandurah Murray

WT

Perth North

Perth South

Mandurah Murray

WWC

Perth North

Perth South

Mandurah Murray

WC

Perth North

Perth South

Mandurah Murray

MWR:

Gascoyne

Coastal Midlands

Geraldton

NWR:

East Pilbara

West Pilbara

East Kimberly

West Kimberly


Naming Convention


Ver 1Rev4


SWR:

Leeuwin

Warren Blackwood

Wellington

Site, Plant or

Scheme

Description This component refers to the name of the scheme,

treatment plant or logical system grouping

Instances 1 Instance

Allowable Values Examples include:

Beenyup

Port Hedland TWS

Port Hedland WW

Area,

Process or

Facility

Description This identifier component describes the specific

physical ‘area’ within the site, plant or scheme

Instances For flexibility this component may be omitted. Also,

this component may have two entries for complex areas


Town Sites.Port

Pretreatment

Yokine

No 1 TPS

Equipment Description This identifier component describes the specific asset in

question



Inlet

Bore 7_98

Control Zone

Module Description This identifier component describes the object module

used for the particular object function. Within SCX,

this component inherits all attributes from a predefined

template


Naming Convention


Ver 1Rev4


Instances 1 or 2 instances

Allowable Values Module Names, for example:

RTU

Zone Control (Direct and Mode Control)

Pump

PGC (Pump Group Controller)

Well

Tank

Valve

Flow

Config Description This identifier component describes the configuration

required for a particular object. This configuration can

define how the object operates, alarms, and/or is

displayed

Instances 0 or 1 Instances

Allowable Values Local RTU configuration points will have this identifier

component called:

~Local Config

SCX configuration points will have this identifier

component called:

~SCX Config

Attribute Description This identifier component describes the specific object

that is being monitored, controlled or which may be a

configuration point, set point or string description.

Essentially, it is the item which may be accessed or

changed by SCX.



Level differential

State

Level

Abbreviations are allowed as detailed in Section 2.9


Naming Convention


Ver 1Rev4


Examples:

Region District Site/ Plant/

Scheme

Area/ Process/

Facility

Equipment Module Config Attribute

1 2 1 2 1

Metro WWT Beenyup Pretreatment Inlet Bar

Screen

Level

differential

NWR East

Pilbara

Port

Hedland

TWS

Town Sites Port Lot 954

TPS

Radio RSSI

MWR Geraldton Kalbarri

TWS

No 1 TPS Unit Pump Starts Last

Hour

Metro WWC PN Swan Barrambie

Way

WWPS

Well Level

Metro WT Wanneroo Pinjar

Borefield

Bore 12 Misc Security

NWR West

Pilbara

West

Pilbara WS

- Yannery

Tank

Tank Level

NWR West

Pilbara

West

Pilbara WS

- Kangaroo

Hill TPS

Pump 1 ~Local

Config

Remote

control

NWR East

Pilbara

Port

Hedland

TWS

Yule River

Borefield

Yule

PS

Unit 1 Pump State

Considering the above, examples of full point description identifiers are shown below. Possible

values for the point descriptors are also listed.

“Metro.WWT.Beenyup.Pretreatment.Inlet.Bar.Screen.Level differential” = “1 High”

“NWR.East Pilbara.Port Hedland TWS.Yule River Borefield Bore 7_98.Pump.State” =

“Running”

“MWR.East District.Cue TWS. No 1 TPS.Unit 2.Starts Last Hour” = “22”

“Metro.WWC.PN.Swan Barrambie Way WWPS. Well.Level” = “6.25”

“Metro.WWT.Wanneroo.Pinjar Borefield.Bore 12.Misc.Security” = “Breached”

“NWR.West Pilbara.West Pilbara WS.Yannery Tank.Tank.Level” = “13.00”

The format of the site name shall be:

[Number] [Street Name] [Street Type] [Extra] SiteType


Naming Convention


Ver 1Rev4


Where:

Italics indicates that the element is a ‘variable’ that shall be replaced with the appropriate value.

[a] indicates a is an optional element. [Number], [Street Name] and [Street Type]

are optional for most site types. However, they are compulsory for WWPS sites.

The [Street Type] element is the type of street the site is located on and shall be abbreviated

according to Table A-1 below, with verbatim use of upper and lower case. If the thoroughfare type is

not on the table, it shall be typed in full (not abbreviated).

Type Abbr. Type Abbr.

Alley Ally Grove Gr

Arcade Arc Highway Hwy

Avenue Ave Junction Jnc

Boulevard Bvd Lane Lane

Bypass Bypa Link Link

Circuit Cct Mews Mews

Close Cl Parade Pde

Corner Crn Place Pl

Court Ct Ramble Rmbl

Crescent Cres Ridge Rdge

Cul-de-sac Cds Road Rd

Drive Dr Square Sq

Elbow El Street St

Esplanade Esp Terrace Tce

Green Grn

List of Street Type values, based on Australian Standard AS 4590.

[Extra] is to be used where additional identifying descriptions are required, such as relative

directions (N, S, E, W etc) or indications of unusual process functionality (eg Vacuum for WWPS

sites).

SiteType shall be selected from the following list:

Bore

Tank

Dam

Valve

TPS (Transfer Pump Station)

BPS (Booster Pump Station)

WWPS (Wastewater Pump Station)

Repeater

Flowmeter

Chlorination


Naming Convention


Ver 1Rev4


WTP (Water Treatment Plant)

WWTP (Wastewater Treatment Plant)

Chemical Dosing (multiple chemicals in the process)

UV

Where a site consists of multiple site types the site type is to be omitted from the site name and

included as the site sectors in the next level of the hierarchy.

For example:

12_85 Bore

Stanley St Tank

Genga TPS

No 1 Main Street WWPS

Repeater

3.3 Template Naming

Templates are located in one of the following groups, each of which is considered a “library” of

ClearSCADA templates:

1. ~Config_DNP –eNet

2. ~Config_Trio

3. ~ConfigWAWC

4. ~Config_OPC

5. ~Config_DNP

The templates in each library are further organized into separate groups. When creating or specifying

new templates, the group structure within each library shall be taken into account. For example if a

template is required within the DNP – eNet Library for a new type of pump, then this template should

reside within the group: ~Config_DNP3 – eNet.Templates.Modules.Drives.Pump.

The name of the ClearSCADA templates shall adopt the following format:

Type a nn <X>

Where the components of the name are:


Naming Convention


Ver 1Rev4



A Description An alpha character that represents the version of the template.

The first version of a template created should be designated

“A”.

When a change to this template is required, which will affect

the configuration of the existing instances of the template, ie

the changes cannot be easily rolled out to the existing

instances, then a new template must be created and designated

with the next alphabetic character.

Allowable Values: “A” to “Z:”

Nn Description A number which uniquely identifies the template.

Allowable Values: “01” to “99”

<X> Description The letter “X” in capitals is added to the end of a template that

has been superseded and no longer to be used.

In the above example, a new type of template is required, therefore the next unique number shall be

used to identify the template and since it is the first template of its type the alpha character is “A”.

Thus if the unique number identified for the template type is “03” the new template will be named -

“Type A03”.

The unique number shall be allocated as the next consecutive number unless the same functionality

already exists in one of the other libraries. If the same functionality (ie “type of asset”) exists in

another library then the number shall be the same as the number in the existing library. For example,

if you require to configure a new pump which has the standard faults, but no manual control in the

DNP_eNet library and a pump template exists in the OPC library, with the configuration that you

require, as “Type C03”, then you shall create a new template in the DNP_eNet library as “Type A03”

(ie it is the first revision in the library of a “Type 03” pump).

If the use of a template has been superseded, that is, instances of this template are no longer to be

created, then the names of the templates shall have a suffix of “X”. For example, if there should no

longer be any more instances created of Zone Control.Direct Control.Equipment.Group Type 01 (say

due to changes in control philosophy), then template is named: “Type 01 X”.:

3.4 Mimic Naming

There are four (4) types of mimics:

a) Image

b) Object

c) Popup

d) Overview


Naming Convention


Ver 1Rev4


All mimics names shall begin with one of these words. More words may be added after a hyphen (“-

“) to distinguish between two or more of the same type of mimic (eg. Overview – Geographical). For

details on Image, Object and Popups refer to DS 41-02 – SCX Configuration.

Where possible, the names of overview mimics will describe the process depicted on that mimic.

Where a larger than standard Overview mimic is required a Content mimic will be used. The naming

of the Content mimic shall be Overview – {Description} – Content, where Overview – {Description}

is the name of the mimic in which the Content mimic will be embedded.

3.5 Logic, Script and ODBC Query Naming

The following format shall be adopted:

Logic - <Description>

Script Library - <Description>

Query - <Description>

Where

<Description> is to be replaced by the appropriate text.

For example:

Logic – Calc Scheme Delivery

3.6 Outstation/Scanner Naming


<Manufacturer> - <Product Type>

Where

<Manufacturer> and <Product Type> are to be replaced by the appropriate text.

For example:

Serck Controls (or Schneider) – eNet

Serck Controls (or Schneider) – Compact 550

Koyo – DL405

Siemens – S7

The group containing the outstation/scanner object will be named to indicate what type of outstation

or scanner it is. For example:

RTU.Serck Controls – eNet

PLC.Koyo – DL405


Naming Convention


Ver 1Rev4


3.7 Trend Naming


Trend - <Description>

Where


For example:

Trend – Flows

Trend – Pump 1

3.8 Communication Naming


Channel - <Protocol> - <Connection Type> - <Description>

Outstation Set - <Protocol> - <Connection Type> - <Description>

Where

<Protocol> and <Description> are to be replaced by the appropriate text.

<Connection Type> = {Ethernet, PSTN, or Serial}

For example:

Channel – DNP3 – Ethernet – Port Hedland

Channel – Modbus – Serial – Pre Treatment

Outstation Set – DNP3 – PSTN – Port Hedland

3.9 Alarm Redirection Naming


Redirection - <Description>

Where


3.10 Schedule Naming


Schedule - <Description> - <Time Period>


Naming Convention


Ver 1Rev4


Where

<Description> is to be replaced by the appropriate text and

<Time Period> = {Daily, Shift, Weekly, or Monthly}

3.11 Archive Naming


Archive - <Description>

Where


3.12 Crystal Report Naming


Crystal Report - <Description> - <Time Period>

Where


<Time Period> = {Daily, Shift, Weekly, or Monthly}

3.13 Forecast Naming


Forecast - <Description>

Where


3.14 Method Call Naming


Method Call - <Description>

Where


3.15 Random Generator Naming

The following format Shall be adopted:

Random Generator - <Description>


Naming Convention


Ver 1Rev4


Where


3.16 Time Profile Naming


Time Profile - <Description>

Where


3.17 Server Naming


For site with a single server:

<Site Name>

For site with a multiple server:

<Site Name> - <Server Description>

Where

<Site Name> and <Server Description> are to be replaced by the appropriate text.

For example:

Australind WTP

JTWC – UWSS1

JTWC – Test


Naming Convention


Ver 1Rev4


4 LOCAL CONTROLLER NAMING CONVENTION

4.1 Program Name Format

4.2 SCADAPack RTUs

Naming of program files for RTUs shall comply with the following format:

RDSsTUuu

Naming of RTU Configuration files for RTUs shall comply with the following format:

RDSsTUuu_Ooooo

Where the following describes the components:


R Description The region in which the RTU resides

Allowable Values:

D Description The district in which the RTU resides

Allowable Values:

Ss Description The scheme in which the RTU resides

Allowable Values:

T Description The type of asset that the RTU is associated with


Naming Convention


Ver 1Rev4



Allowable Values: The following values shall be used:

B for bores

T for tanks

S for wastewater pump stations

W for water pump stations

C for chemical dosing facilities

R for repeater stations

F for flow meters

J for power

V for valves

P for water or wastewater treatment plants

E for reticulation

M for pressure monitoring

X for combination of assets

Uuu Description Users choice to help distinguish the site

Allowable Values:

Ooooo Description The DNP3 address of the RTU

4.3 Tag/Address Name Format

All addresses or tags within a local controller shall be named. The naming convention shall be

applied to real world or derived values. Tag names shall adhere to the convention below:

AaOoooo_Px<M>


Naming Convention


Ver 1Rev4


Where the following describes the components of the tag name.


AA Description The equipment type or instrument tag number to which the

data refers. This value may refer to groups of equipment or an

entire plant if appropriate.

Allowable Values: The Equipment Type is a two (2) character description of the

equipment type or instrument tag to which the data refers.

The values to be used for the Equipment Type should follow

the P & ID drawings. The allowable values are outlined in DS

80 WCX CAD (Equipment Type) and DS24 Electrical

Drafting Standard (Instrument Tag).

Ooooo Description The Equipment Number of the asset. This is typically the

equipment loop number as defined on the P & ID.

Allowable Values: Equipment numbers are 4 digits and are defined at asset

creation. Where a tag refers to a group of devices then the

Equipment Number shall be ‘0000’

P Description The Property describes the component of the equipment to

which the data refers. Properties can be 1 to 3 characters.

The Property may include an additional Property Modifier to

further describe the data.

Allowable Values: The allowable values for the Property Tag are as per the table

in Section 2.9

X Description The Instance is an optional number used to distinguish

between more than one occurrence of the Property Tag

Allowable Values: If used the values must start with “1”. Left padding with zeros

is not required, unless it is foreseen that 10, 100 or 1000 tags

are needed. The maximum number allowable is “9999”.

<M> Description This depicts the Modifier, which is an optional parameter(s)

used to distinguish duplicate data values, for example, data

points used for mapping data between devices and/or software

alarms.

Allowable Values: The allowable values for the Modifier are defined in Section

2.9


Naming Convention


Ver 1Rev4


4.3.1 Special Case Names

Special Case Names may be used within Local Controllers for global variables used to transfer

information between software modules. The naming format for use with Special Case Names is as

outlined below.

Typically a name will be up to three words concatenated together with each word starting with a

capital letter.

[<Location>]<Type><Word1>…<Wordx>

Where:


[<Location>] Description This is an optional component which depicts the location

of the data.

Allowable

Values:

The allowable values are:

m – for module based data

g – for global variables

local (ie location is left blank)

<Type> Description This depicts the data type

Allowable

Values:

The allowable values are:

c - constant

i- integer;

s - string;

b - boolean;

l - long;

r - real or floating point;

h - handle (index);

t -– timer

<Wordi>…<Wordx> Description A string that describes the functionality of the variable


Naming Convention


Ver 1Rev4


Allowable

Values:

Examples include:

Count

Name

Node

Initialised

Control

Pulse

4.3.2 Naming Examples

4.3.2.1 General Tag Names

Example P&ID

From the Example P&ID the following names can be defined:

DT09204_D1 Density transmitter DT9204 density

MX09206_REM1 Motor MX9206 in remote

FT09207_F1 Flow transmitter FT9207 flow rate

LT09205_L1 Tank TA9205 level

Other tagnames that may include:

MX09206_T0L1 Mixer MX 9206 thermal overload input

DT09204_D1AL Density transmitter DT9204 density low alarm

DT09204_D1ALL Density transmitter DT9204 density low low alarm

LT09205_L1AL Tank level low alarm

LT09205_L1AH Tank level high level

DIT

9204

DI

9204

DAL

9204

DALL

9204

LI

9205 LIT

9205

LAL

9205

LAH

9205

LAHH

9205

FIT

9207

FI

9207

FAL

9207

Mixer

Density

Transmitter

Flow

Meter M I

HS

9206

XL

9206

HS

9206 MX-9206

MX-9206

TA-9205

Level Indicator


Naming Convention


Ver 1Rev4


LT09205_L1AHH Tank level high high alarm

FT09207_F1AL Flow Transmitter FT9207 flow low alarm

MX09206_TOL1A Mixer MX9206 thermal overload alarm

4.3.2.2 Special Case Names

Examples of special case names:

icheckCount local based integer, used to check the value of a counter

hAlarmDevice local based handle, reference to an alarm device

sName local based string, name

msDevDesc[20] module based string, an array of 20 device descriptions

gsNodeName global based string describing the name of this node

gbInitialisedISA global based boolean used to flag the initialisation of “ISA”

giControlVolume global based integer, reading indicating controlling volume value

bOneHourPulse local based boolean pulse triggered every hour

gcPressAdd global based constant pointing to the SCADA data address of the pressure


Naming Convention


Ver 1Rev4


5 CORPORATE SYSTEM NAMES

Corporate systems such as the Data Historian shall use the same names as used in ClearSCADA for

data provided by the Integrated SCADA system.


Naming Convention


Ver 1Rev4


END OF DOCUMENT

Naming Convention - pw-cdn.watercorporation.com.au

Documents

Transcript of Naming Convention - pw-cdn.watercorporation.com.au