Remote Technologies UK-WITS Protocol Project Jim Baker Water Corporation of WA

Remote Technologies

UK-WITS Protocol Project

Jim BakerWater Corporation of WA

Overview of the UK-WITS Telemetry Project:What is/ Who are WITS?The WITS Telemetry ProjectDiscussion

Page 3

Acknowledgements• UK-WITS team

– Barry Shephard - Grontmij– Martin Pritchard – Severn Trent Water– Ed Oborn – Grontmij

• DNP3 Technical Committee– Barry Shephard - Member– Andrew West - Chair

WITS Background• United Kingdom Water Industry Telemetry Standards Group.• Driver was for UK Water Management Organisations (UK-WMOs) to

control their destiny w.r. to telemetry• 11/7/2003 31 WMOs agree to establish WITS.• Intended to be open to UK vendors and utilities:

“Membership of the WITS Management Group is limited to members of the UK Water Management Organisations.”

“Companies outside the UK Water Management Organisations can be specific project members with the approval of the group.”

(from UK-WITS Group Membership document)

The UK-WITS Vision

” To harness the combined strengths of knowledge, skills and influence of the water industry, taking responsibility for the continuous improvement of telemetry technology and service, through shared developments on behalf of the UK Water Management Organisations ”

Page 7

Quote from July 2005 WITS presentation

• Telemetry in the Water Industry– Accepted as an essential business tool– Not just an alarm handling system– Key to delivering efficiencies– Drive to increase level of telemetry coverage– Lots of expectations in AMP4*– Selecting the right solution for monitoring will become more

difficult

*AMP4: 2004 periodic review for water industry. Guidance on environmental priorities by UK Environment Agency

WITS Management Team

• Malcolm Tyler - Grontmij• Simon Harrison – Anglian Water• Martin Pritchard – Severn Trent Water• Charles Williams - Grontmij• Russell Wheadon – Thames Water• Peter Vogan - United Utilities• Simon Poole - Dwr Cymru (Welsh Water)• Nick Williams - Severn Trent Water• Paul Sutton – Wessex Water• Paul Carter – Parsons Brinckerhoff• Ed Oborn - Grontmij• Barry Shephard – DNP3 TC/Grontmij

Founding Vendors

FerranttiFerranti

SeprolSeprol

DynamicLogicSerck

SerckDynamicLogic

The problem

6000 LegacyField

Devices

Master stations with proprietary protocols, can only buy from 1 vendor – high risk, high cost

SCADATelemetry

System

Proprietary protocol drivers

PSTN or GSM only

The solutionOld master station being replaced, offering new opportunities

Type 2Type 1Type 1 Type 2 Type 2Type 1Type 3

Type 4

PSTN, GPRS, ADSL, …

• Define a standard/common protocol for all water devices.• Vision:

“To evolve current technologies to a point where any

remote field device is able to communicate to any

telemetry system, facilitated through the use of a

defined set of communication standards/protocols”

UK-WITS first joint project...

Page 9

• Business & User Requirements– IT system integration & data usage across business– Need to cater for

• Small sites (single input) to large sites (000s I/O)• List of key functions

• The Need– Interoperability– Avoid vendor lock-in– Savings through increased competition– Improved system integration

Page 14

Project Background

• Procurement Issues– Customer specific solutions - increased cost– Locked in to specific vendors

• Opportunity & Willingness to Change– Availability of internationally recognised standards– Other industries standards adoption

• Electricity in UK & overseas• Australian water industry

– WITS group for UK water industry

Page 15

Project Background

• Constraints– Adequate functionality for all– Efficiency (where there is limited bandwidth)– Security– Enabler for future technology usage– Current Vendors– Need support from users & vendors– Need to support legacy & allow migration

Page 16

Project Background

• Improved device connectivity• Financial benefits• Reduced dependency on specific vendors• Future proofing & future IT compatibility• Assess costs & ease of adoption

Project Objectives

Page 17

Assess Options

Technical Analysis

Economic Approach

Recommendations

Implementation Plan

Preferred Option(s)

Page 19

Project Approach

1. Do nothing

2. Adopt an existing open standard protocol

3. Adopt an existing proprietary protocol

4. Develop a new standard protocol

$$$$

The Options

Page 18

Options Selection

Option 1: Do Nothing

Page 20

Options Selection

CompanyA

CompanyB

CompanyC

CompanyD

Range ofProprietary

&StandardProtocols

VendorA

VendorB

VendorC

VendorD

Page 21

Options Selection - “Do Nothing”

• Proprietary protocols development• Standard protocols development• Vendor driven• User driven• Lower initial cost• Low interoperability, pay per new interface• Limited competition - affects device price• Does it meet objectives?

Page 22

Options Selection - “Do Nothing”

Option 2: Standard Protocol

Page 23

Options Selection

20 ‘standards’

DNP 3IEC 60870IEC 61850ModbusUCA 2

Shortlist Selection

Page 24

Options Selection – Standard Protocol

• International standard developed from Westronic protocol in 1993 for electrical industry

• Owned by DNP3 user group, with Technical Committee advising on proposed changes

• Efficient, robust, scalable, supports TCP/IP• Widely used in water industry already• Needs extensions to achieve specific functionality, but some of

this has already been developed

DNP3 Overview

Page 25


• International standard developed from proprietary protocol in 1994 for electrical industry

• European user base• Robust, secure, scalable, supports TCP/IP• Poor bandwidth efficiency (LAN origin)• Some communication media limitations• Being superseded by newer standards (eg IEC 61850)

IEC 60870-5 Overview

Page 26


• International standard originating from another standard protocol (UCA2) recently for electrical industry

• Still under development providing complete data standard• Main drive from US electricity industry• Robust, secure, scalable, supports TCP/IP• Multi-layered protocol and structured around process / asset

architecture• Object orientated enabling automatic configuration

IEC 61850 Overview

Page 27


• Initially developed by Modicon in 1979• Three variants - RTU, ASCII, TCP• Latter is TCP/IP compatible• Widely known and used worldwide• Continuous communication only• Ideal for local I/O transfer• Limited functionality (does not meet many key requirements)

Modbus Overview

Page 28


• Based on IEEE standard; tailored to Electricity industry requirements

• Multi-layered protocol and structured around process / asset architecture

• Complicated protocol, developed before its time in the 1990’s• Has been superseded by IEC61850

UCA2 Overview

Page 29


100s of

ProprietaryProtocols

MMS1988

UCA 1991

UCA2 1999

IEC618502003

IEC60870-51994

DNP3 Serial1993

DNP3 Ethernet 2000

?

Standards Evolution

Page 30


Option 3: Proprietary Protocol

Page 31

Options Selection

List of Vendors

Bristol BabcockCSE Servelec/SeprolDynamic LogicLogicaCMGSerck Controls

Provide over 90% of UKWMO Telemetry Market Share

Shortlist Selection

Page 32

Options Selection – Proprietary Protocol

•Good rangeof functionality

•Flexible communications•Widely used in all

industry sectors

BSAP

D7000 Proteus

Seprol Medina

Overview

Page 33


• Wide usage in UKWMOs.• Proprietary protocols for each vendor/product• Protocol suitable for occasional data transfer (eg daily SMS),

very byte efficient to achieve this• Not designed for range of functionality & flexibility required for

telemetry systems• Technically straight forward to add a driver to system

Data Loggers

Page 34


• Functionally rich to suit most UKWMO requirements• Efficient, therefore suitable for low bandwidth• Secure due to bespoke nature, but would be vulnerable if in

public domain• Some development may be required for TCP/IP compatibility• Support most comms media's, some restrictions• More difficult to integrate into corporate IT• Commercial arrangements with vendors and associated

politics

SWOT Overview

Page 35


• A possible technical solution...• But some obstacles...

– Commercial arrangements with current protocol owner– Vendor willingness to implement a competitors protocol as

a standard– Risk of it still not being recognised as a true standard.

Summary, Risks & Issues

Page 36


Option 4: Creating a New Protocol

Page 37

Options Selection

200? 201?

Benefits Costs

Creating a NEW protocol

Page 38

Options Selection – New Protocol

• 1 Do Nothing– Propose this will not meet objectives but use as a

benchmark• 2 Existing Standard

– Will meet objectives, need to do further analysis on each short-listed standard

• 3 Proprietary Protocol– May meet objectives, but too many obstacles and risks

• 4 New Protocol– Deselected due to high cost and extended timescales

Summary of outcome

Page 40

Options Selection

√√

TECHNICAL EVALUATION OF EXISTING STANDARDS

Conducted by:

Richard Wells – Yorkshire Water

Bob Bartindale – Parsons Brinckerhoff

Page 43

TECHNICALASSESSMENT

Functional Requirements

Business Requirements

RECOMMENDATION Economic

Assessment

STRATEGICISSUES (SWOT)

TECHNICALCOMPATIBILITY

CommunicationsData / Info

IS/ITOperations

Efficiency

Security

Page 44

Technical Evaluation- Methodology

Define Devices

Telemetry / Data Management System

Device AIntelligent Instrument

Device B

Device C

Device D

Small Outstation

Modular Outstation

Data Logger

Etc.

(10 total)

Page 45

Technical Evaluation – Functional Compliance

Etc.

Remote Control

Prog. Download

Time Synch

Alarms

Etc.Device D

Device C

Device B

Device A

Define Device Requirements

Page 46


Protocol Standard Device A

Device B Device C

Device D

Etc.

DNP 3.0

IEC 60870

IEC 61850

Modbus

UCA 2.0

Analyse Options

Page 49

Technical Evaluation– Functional Compliance

Scoring Criterion: Function already supported by protocol standard

Protocol Score %

DNP 3.0 31 96.9%

IEC 60870 31 96.9%

IEC 61850 29 90.6%

Modbus 9 28.1%

UCA 2.0 28 87.5%

Page 50


Page 52

0

10

20

30

40

50

60

70

80

90

100

DNP3 IEC60870 IEC61850 Modbus UCA2

Efficiency %

Technical Evaluation Protocol Efficiency Score

Page 54

0

10

20

30

40

50

60

70

80

90

100

DNP3 IEC60870 IEC61850 Modbus UCA2

Security %

Technical Evaluation Protocol Security Score

Protocol % Rank

DNP 3.0 80% 1=

IEC 60870 40% 4

IEC 61850 80% 1=

Modbus 20% 5

UCA 2.0 60% 3

Page 56

Technical Evaluation SWOT Results

CommunicationsDoes this Option satisfy strategic

and tactical communications needs?Data and InformationDoes this Option satisfy strategic

and tactical needs for corporate data?IS/ITIs this Option compatible with current

and emerging IT standards?Plant OperationDoes this Option meet developing

plant & operational needs?

Page 57

Technical Evaluation Compatibility Tests

Protocol Score %

DNP 3.0 26 87%

IEC 60870 30 100%

IEC 61850 30 100%

Modbus 19 63%

UCA 2.0 30 100%

Page 58

Technical Evaluation Compatibility Results

Efficiency

TECHNICALASSESSMENT

Functional Requirements

Business Requirements

RECOMMENDATION Economic

Assessment

STRATEGICISSUES (SWOT)

TECHNICALCOMPATIBILITY

CommunicationsData / Info

IS/ITOperations

Security

25%

10%

30%

25%

10%

Page 60

Technical Evaluation - Methodology

Protocol Score Rank

DNP 3.0 79% 1

IEC 61850 78% 2

UCA 2.0 67% 3

IEC 60870 63% 4

Modbus 34% 5

Overall Technical Evaluation Scoring

Page 61

Technical Evaluation

Standards are available and proven

Functionality foundation available

Standards compatible with Business Objectives

Standards compatible with IT estate

Strong reasons for adopting industry standards

Summary of Technical Evaluation

Page 64

Technical Evaluation

DNP3 implementationDNP3 functionality used

– Data sets– Object Group 0– File transfer functions

• Incremental Configuration Download• Bulk Configuration Download• Data Logging

– XML device profile

Data Sets

Data Sets (AN2005-005)• Allows information about an item to be grouped together.• Can transfer all associated information in one object• RBE/Unsolicited/event classes• WITS defines 7 data sets

– Analog Alarm Reporting– Counter Alarm Reporting– Binary Events– Device Health Check– Call Back– Application Manager– Action Inhibit

Analog/Counter Alarm Reporting Data Set

Information Type Size Description

Point Object Group number

UINT 1 byte DNP3 Object Group number of type of data in alarm

Point Number UINT 2 byte Number of point in alarm

Point Value FLT 4 byte Value of point at which alarm was raised.

Point alarm condition

UINT 1 byte Alarm condition (High, High High, etc)

Point Quality UINT 1 byte DNP3 quality flags of point

Status Flags UINT 1 byte Reports the status of the WITS flags associated with the particular point

Binary Event Data SetElement No. Information Type Size Description

5 Point Object Group number


6 Point Number UINT 2 byte Number of point in alarm

7 Point Quality UINT 1 byte DNP3 quality flags of point

8 Status Flags UINT 1 byte Reports the status of the WITS flags associated with the particular point

Device Health Check Data SetElement

No.Type Size Description

5 BSTR 4 bytes 32 bit string defined within the WITS Device Profile. The following bit definitions are required:•Supply failure•Battery Low•I/O failure•Scheduled connection occurrance•Local user device attached•Log file nearly full•Log file has discarded some information•Close communications link•Configuration changed•Device off scan

6 BSTR 4 bytes 32 bit string defined by Field Device vendor. Definitions in device profile.

Call Back Data SetElement

No.Information Type Size Description

5 WITS Port Number

UINT 1 byte Port number on which to perform call back test (0-254, 255=any)

6 WITS connection VSTR 32 bytes Telephone number or IP address

7 Network Protocol UINT Network protocol (if any). Eg TCP, UDP, IPv4, IPv6

8 Network address VSTR 48 bytes Depends on protocol. Eg URL or IP address, port address.

Action Inhibit Data SetElement No. Information Type Size Description

5 Point Object Group number


6 Point Number UINT 2 byte Number of point in alarm

7 Action UINT 1 byte 0 = inhibit all actions

1 = inhibit events for data set, Log to log file instead. Inhibit connection request.

2 = Inhibit connection request

3 = remove action inhibit

8 Timeout UINT 4 bytes The timeout, in seconds, for the action inhibit. After the specified period has elapsed the action inhibit will be automatically removed by the Field Device.

Application Manager Data SetElement No. Type Size Description

5 UINT 2 bytes Application index number

6 VSTR 16 bytes Version of application or sub-component identifier as applicable

7 BSTR 1 byte Current status of application

Bit 0 = 1 if app is initialised

Bit 1 = 1 if app is running

Bit 2 = 1 if app is paused

Bit 3 = 1 if app has a problem

Bit 4 = 1 if app does not exist at this index

8 VSTR 32 bytes Details of problem if one exists

Application Manager Data SetElement No. Type Size Description

9 BSTR 1 byte Permitted control actions

Bit 0 = 1 if app can be initialised

Bit 1 = 1 if app can be started

Bit 2 = 1 if app can be stopped

Bit 3 = 1 if app can be paused

Bit 4 = 1 if app can be deleted

Bits 5-7 reserved

10 BSTR 1 byte Master station control request

Bit 1 = 1 Initialise app

Bit 2 = 1 Start app

Bit 3 = 1 Stop app

Bit 4 = 1 Pause app

Bit 5 = 1 Resume app

Bit 6 = Request information response

Bit 7 = Delete application

Object Group 0

Object Group 0• Used for holding general information (attributes) about a device• Variations point to specific attribute.• Indexes define Attribute Set• Index 0 is the default set and is mandatory• “WITS” is a registered namespace and is associated with the WITS

attribute set

Index 0 Mandatory WITS variations

Variation Read/Write Usage Type Description

240 Read/Write Mandatory UINT[2] Maximum transmit fragment size

241 Read/Write Mandatory UINT[2] Maximum receive fragment size

242 Read Mandatory VSTR[8]Device manufacturer’s software version

string (e.g. “3.39”, “b03.1”)

243 Read Mandatory VSTR[8]Device manufacturer’s hardware version

string (e.g. “1.23”)

WITS attribute variationsVariation Read/Write Usage Type Description

1 Read Mandatory UINT[4] WITS major version number

2 Read Mandatory UINT[4] WITS minor version number

3 Read Mandatory VSTR[16] Bulk Configuration version string

4-253 Read Ignored - Reserved for future use

254 Read Mandatory - Special variation for requesting return of all attributes

255 Read Mandatory - Special variation for requesting list of attributes

File Transfer Functions

Incremental Configuration Download

Incremental Configuration• Provides changes since last bulk config download• Cannot create or delete objects from field device• Downloads to pseudo directory• Requires activate request – if no errors• One record for each action

Record types0 Device On/Off scan

1 Connection detail

2 Scheduled connection

1000 Point On/Off scan

1001 Override point

1002 Analog Range/Scaling

1003 Analog limit

1004 Counter limit

1005 Point archive

1006 Binary states

1007 Limit profile

1008 Rate of Change

1009 DNP3 Object Flag Actions

1010 Minimum

1011 Maximum

1012 Mean

1013 Integral

1014 State counter

1015 State runtime

Record example – Point On/Off scanElement number


1 Record type UINT 2 bytes Unique record identifier (1000)

2 Byte count UINT 2 bytes Number of bytes remaining in this record (8)

3 Point type UINT 1 byte DNP3 point group

4 Point number UINT 2 bytes Point index

5 On/Off scan flag

UINT 1 byte 0=Off scan, 1=On scan

Record example – Scheduled ConnectionElement number


1 Record type UINT 2 bytes Unique record identifier (2)

2 Byte count UINT 2 bytes Number of bytes remaining in this record (8)

3 Start Time DNP3 Time

6 bytes Start Time

4 Repeat Interval

UINT 2 bytes Frequency of connection in hours


Bulk configuration Download

General

Vendor specific configuration

application

Master Station

FieldDevice

Bulk Config file and matching IC file

Full Config(BCF+ICF)Comms config or BCF Incremental Config file

Bulk Configuration Download• Used for initial configuration download

• Vendor specific file contents

• Impractical to impose a standard

• Must contain point database as a minimum


Data Log Files

Data logging• Transfer of historical data

• Defined filename format

• Defined File format

• AN2005-004

Filename format• “WITSLOG\D_A_GB__X_X”

• Log specifier “WITSLOG/”. File specifier

• Read type “D” = destructive

• Log type “A” = all (all log types requested: All, Time, Event)

• Point type “GB” = Global (all point types requested: )

• Point number = blank field for future use.

• Time from “X” = earliest entry in log

• Time to “X” = most recent entry

File format• Depends on file content

• Has file header:

• Followed by point/event information

Security (Authentication)• Authentication is required for critical functions, such as controls

and file transfers.

• Authentication is based on the use of secret keys that are shared between a Master Station and a Field Device.

Documents

Remote Technologies UK-WITS Protocol Project Jim Baker Water Corporation of WA