Remote Technologies UK-WITS Protocol Project Jim Baker Water

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

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

Acknowledgements • UK-WITS team – Barry Shephard - Grontmij – Martin Pritchard – Severn Trent Water – Ed Oborn – Grontmij • DNP 3 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 AMP 4* – Selecting the right solution for monitoring will become more difficult *AMP 4: 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 – DNP 3 TC/Grontmij

Founding Vendors

The problem SCADA Telemetry System Proprietary protocol drivers Master stations with proprietary protocols, can only buy from 1 vendor – high risk, high cost 6000 Legacy Field Devices PSTN or GSM only Dynamic Serck Logic Ferrantti Ferranti Seprol Dynamic Serck Logic

The solution Old master station being replaced, offering new opportunities PSTN, GPRS, ADSL, … Type 11 Type 22 Type 31 Type 42

UK-WITS first joint project. . . • 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” Page 9

Project Background • Business & User Requirements – IT system integration & data usage across business – Need to cater for • Small sites (single input) to large sites (000 s 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 Objectives • • • Improved device connectivity Financial benefits Reduced dependency on specific vendors Future proofing & future IT compatibility Assess costs & ease of adoption Page 17

Project Approach Assess Options Preferred Option(s) Technical Analysis Economic Approach Recommendations Implementation Plan Page 19

Options Selection The Options 2. Do nothing Adopt an existing open standard protocol 3. Adopt an existing proprietary protocol 4. Develop a new standard protocol 1. $$$$ Page 18

Options Selection Option 1: Do Nothing Page 20

Options Selection - “Do Nothing” Vendor A Company B Company C Company D Range of Proprietary & Standard Protocols Vendor B Vendor C Vendor D 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 Option 2: Standard Protocol Page 23

Options Selection – Standard Protocol Shortlist Selection 20 ‘standards’ DNP 3 IEC 60870 IEC 61850 Modbus UCA 2 Page 24

Options Selection – Standard Protocol DNP 3 Overview • International standard developed from Westronic protocol in 1993 for electrical industry • Owned by DNP 3 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 Page 25

Options Selection – Standard Protocol IEC 60870 -5 Overview • 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) Page 26

Options Selection – Standard Protocol IEC 61850 Overview • International standard originating from another standard protocol (UCA 2) 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 Page 27

Options Selection – Standard Protocol Modbus Overview • • 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) Page 28

Options Selection – Standard Protocol UCA 2 Overview • 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 IEC 61850 Page 29

Options Selection – Standard Protocol Standards Evolution MMS 1988 UCA 1991 UCA 2 1999 IEC 61850 2003 100 s of Proprietary Protocols IEC 60870 -5 1994 DNP 3 Serial 1993 ? DNP 3 Ethernet 2000 Page 30

Options Selection Option 3: Proprietary Protocol Page 31

Options Selection – Proprietary Protocol Shortlist Selection List of Vendors Bristol Babcock CSE Servelec/Seprol Dynamic Logica. CMG Serck Controls Provide over 90% of UKWMO Telemetry Market Share Page 32

Options Selection – Proprietary Protocol Overview BSAP D 7000 Proteus • Good range of functionality • Flexible communications • Widely used in all industry sectors Seprol Medina Page 33

Options Selection – Proprietary Protocol Data Loggers • 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 Page 34

Options Selection – Proprietary Protocol SWOT Overview • 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 Page 35

Options Selection – Proprietary Protocol Summary, Risks & Issues • 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. Page 36

Options Selection Option 4: Creating a New Protocol Page 37

Options Selection – New Protocol Creating a NEW protocol 200? Benefits 201? Costs Page 38

Options Selection Summary of outcome √ • 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 Page 40

TECHNICAL EVALUATION OF EXISTING STANDARDS Conducted by: Richard Wells – Yorkshire Water Bob Bartindale – Parsons Brinckerhoff Page 43

Technical Evaluation- Methodology Business Requirements TECHNICAL COMPATIBILITY Communications Data / Info IS/IT Operations Functional Requirements Efficiency TECHNICAL ASSESSMENT STRATEGIC ISSUES (SWOT) Economic Assessment Security RECOMMENDATION Page 44

Technical Evaluation – Functional Compliance Define Devices Device A Intelligent Instrument Data Logger Small Outstation Device B Device C Device D Modular Outstation Etc. (10 total) Telemetry / Data Management System Page 45

Technical Evaluation – Functional Compliance Define Device Requirements Device A Alarms Device D Etc. Prog. Download Device C Time Synch Device B Remote Control Etc. Page 46

Technical Evaluation– Functional Compliance Analyse Options Protocol Standard DNP 3. 0 Device A Device B Device C IEC 60870 IEC 61850 Etc. Modbus UCA 2. 0 Device D 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

Technical Evaluation Protocol Efficiency Score Page 52

Technical Evaluation Protocol Security Score Page 54

Technical Evaluation SWOT Results 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 Compatibility Tests Communications Does this Option satisfy strategic Data and Information and tactical communications needs? Does this Option satisfy strategic IS/IT and tactical needs for corporate data? Is this Option compatible with current and emerging. Plant Operation IT standards? Does this Option meet developing plant & operational needs? Page 57

Technical Evaluation Compatibility Results 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 - Methodology Business Requirements TECHNICAL COMPATIBILITY Communications Data / Info 25% IS/IT Operations Functional Requirements 25% Efficiency 10% TECHNICAL ASSESSMENT STRATEGIC 30% ISSUES (SWOT) Economic Assessment Security 10% RECOMMENDATION Page 60

Technical Evaluation Overall Technical Evaluation Scoring Protocol Score Rank DNP 3. 0 79% 1 IEC 61850 78% 2 UCA 2. 0 67% 3 IEC 60870 63% 4 Modbus 34% 5 Page 61

Technical Evaluation Summary of 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 Page 64

DNP 3 implementation DNP 3 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 (AN 2005 -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 DNP 3 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, etc) Point Quality UINT 1 byte DNP 3 quality flags of point Status Flags UINT 1 byte Reports the status of the WITS flags associated with the particular point

Binary Event Data Set Element No. Information Type Size Description 5 Point Object Group number UINT 1 byte DNP 3 Object Group number of type of data in alarm 6 Point Number UINT 2 byte Number of point in alarm 7 Point Quality UINT 1 byte DNP 3 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 Set Element 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 Set Element No. Information Type Size 5 WITS Port Number UINT 1 byte 6 WITS connection VSTR 32 bytes 7 Network Protocol UINT 8 Network address VSTR Description Port number on which to perform call back test (0 -254, 255=any) Telephone number or IP address Network protocol (if any). Eg TCP, UDP, IPv 4, IPv 6 48 bytes Depends on protocol. Eg URL or IP address, port address.

Action Inhibit Data Set Element No. Information Type Size Description 5 Point Object Group number UINT 1 byte DNP 3 Object Group number of type of data in alarm 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 Set Element 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 8 VSTR 32 bytes 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 Details of problem if one exists

Application Manager Data Set Element 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”, “b 03. 1”) 243 Read Mandatory VSTR[8] Device manufacturer’s hardware version string (e. g. “ 1. 23”)

WITS attribute variations Variation 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 types 0 Device On/Off scan 1007 Limit profile 1 Connection detail 1008 Rate of Change 2 Scheduled connection 1009 DNP 3 Object Flag Actions 1000 Point On/Off scan 1010 Minimum 1001 Override point 1011 Maximum 1002 Analog Range/Scaling 1012 Mean 1003 Analog limit 1013 Integral 1004 Counter limit 1014 State counter 1005 Point archive 1015 State runtime 1006 Binary states

Record example – Point On/Off scan Element number Information Type Size Description 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 DNP 3 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 Connection Element number Information Type Size Description 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 DNP 3 Time 6 bytes Start Time 4 Repeat Interval UINT 2 bytes Frequency of connection in hours

File Transfer Functions Bulk configuration Download

General Vendor specific configuration application Bulk Config file and matching IC file Full Config (BCF+ICF) Comms config or BCF Field Device Master Station 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

File Transfer Functions Data Log Files

Data logging • • Transfer of historical data Defined filename format Defined File format AN 2005 -004

Filename format • • “WITSLOGD_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.