Remote%20Technologies

1
Remote Technologies UK-WITS Protocol Project Jim
Baker Water Corporation of WA
2
Overview of the UK-WITS Telemetry Project What
is/ Who are WITS? The WITS Telemetry
Project Discussion
Page 3
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

4
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)

5
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
6
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

7
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

8
Founding Vendors
9
The problem
SCADA Telemetry System
Master stations with proprietary protocols, can
only buy from 1 vendor high risk, high cost
6000 Legacy Field Devices
Proprietary protocol drivers
PSTN or GSM only
10
The solution
Old master station being replaced, offering new
opportunities
PSTN, GPRS, ADSL,
Type 2
Type 1
Type 1
Type 1
Type 2
Type 3
Type 2
Type 4
11
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
12
Project Background

• 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
13
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
14
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
15
Project Objectives

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

Page 17
16
Project Approach
Page 19
17
Options Selection
The Options

1. Do nothing
2. Adopt an existing open standard protocol
3. Adopt an existing proprietary protocol
4. Develop a new standard protocol

Page 18
18
Option 1 Do Nothing
Options Selection
Page 20
19
Options Selection - Do Nothing
Range of Proprietary Standard Protocols
Vendor A
Company A

Vendor B
Company B
Vendor C
Company C
Vendor D
Company D
Page 21
20
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
21
Option 2 Standard Protocol
Options Selection
Page 23
22
Options Selection Standard Protocol
Shortlist Selection
Page 24
23
Options Selection Standard Protocol
DNP3 Overview

• 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

Page 25
24
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
25
Options Selection Standard Protocol
IEC 61850 Overview

• 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

Page 27
26
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
27
Options Selection Standard Protocol
UCA2 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 1990s
• Has been superseded by IEC61850

Page 29
28
Options Selection Standard Protocol
Standards Evolution
MMS 1988
UCA 1991
UCA2 1999
IEC61850 2003
IEC60870-5 1994
?
DNP3 Serial 1993
DNP3 Ethernet 2000
Page 30
29
Option 3 Proprietary Protocol
Options Selection
Page 31
30
Options Selection Proprietary Protocol
Shortlist Selection
Provide over 90 of UKWMO Telemetry Market Share
Page 32
31
Options Selection Proprietary Protocol
Overview
BSAP

• Good range
• of functionality
• Flexible communications
• Widely used in all
• industry sectors

D7000
Proteus
Seprol
Medina
Page 33
32
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
33
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
34
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
35
Option 4 Creating a New Protocol
Options Selection
Page 37
36
Options Selection New Protocol
Creating a NEW protocol
200?
201?
Benefits
Costs
Page 38
37
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 39
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

v
Page 40
39
TECHNICAL EVALUATION OF EXISTING STANDARDS

• Conducted by
• Richard Wells Yorkshire Water
• Bob Bartindale Parsons Brinckerhoff

Page 43
40
Technical Evaluation- Methodology

Page 44
41
Technical Evaluation Functional Compliance
Define Devices
Device A
Intelligent Instrument
Device B
Data Logger
Device C
Small Outstation
Device D
Modular Outstation
Etc. (10 total)
Telemetry / Data Management System
Page 45
42
Technical Evaluation Functional Compliance
Define Device Requirements
Page 46
43
Technical Evaluation Functional Compliance
Analyse Options
Protocol Standard Device A Device B Device C Device D Etc.
DNP 3.0 ? ? ?
IEC 60870 ?
IEC 61850 ? ?
Modbus ? ?
UCA 2.0 ? ? ?
Page 49
44
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
45
Technical Evaluation Protocol Efficiency Score
Page 52
46
Technical Evaluation Protocol Security Score
Page 54
47
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
48
Technical Evaluation Compatibility Tests
Communications Does this Option satisfy
strategic and tactical communications needs?
Data and Information Does this Option satisfy
strategic and tactical needs for corporate data?
IS/IT Is this Option compatible with current and
emerging IT standards?
Plant Operation Does this Option meet developing
plant operational needs?
Page 57
49
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
50
Technical Evaluation - Methodology
Business Requirements
Functional Requirements
25
TECHNICAL COMPATIBILITY Communications Data /
Info IS/IT Operations
Efficiency
10
TECHNICAL ASSESSMENT
25
Security
10
STRATEGIC ISSUES (SWOT)
30
Economic Assessment
RECOMMENDATION
Page 60
51
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
52
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
53
DNP3 implementation

• DNP3 functionality used
• Data sets
• Object Group 0
• File transfer functions
• Incremental Configuration Download
• Bulk Configuration Download
• Data Logging
• XML device profile

54
Data Sets
55
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

56
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
57
Binary Event Data Set
Element No. Information Type Size Description
5 Point Object Group number UINT 1 byte DNP3 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 DNP3 quality flags of point
8 Status Flags UINT 1 byte Reports the status of the WITS flags associated with the particular point
58
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.
59
Call Back Data Set
Element No. Information Type Size Description
5 WITS Port Number UINT 1 byte Port number on which to perform call back test (0-254, 255any)
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.
60
Action Inhibit Data Set
Element No. Information Type Size Description
5 Point Object Group number UINT 1 byte DNP3 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.
61
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 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
62
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
63
Object Group 0
64
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

65
Index 0 Mandatory WITS variations
Variation Read/Write Usage Type Description
240 Read/Write Mandatory UINT2 Maximum transmit fragment size
241 Read/Write Mandatory UINT2 Maximum receive fragment size
242 Read Mandatory VSTR8 Device manufacturers software version string (e.g. 3.39, b03.1)
243 Read Mandatory VSTR8 Device manufacturers hardware version string (e.g. 1.23)
66
WITS attribute variations
Variation Read/Write Usage Type Description
1 Read Mandatory UINT4 WITS major version number
2 Read Mandatory UINT4 WITS minor version number
3 Read Mandatory VSTR16 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
67
File Transfer Functions

• Incremental Configuration Download

68
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

69
Record types
0 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
70
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 DNP3 point group
4 Point number UINT 2 bytes Point index
5 On/Off scan flag UINT 1 byte 0Off scan, 1On scan
71
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 DNP3 Time 6 bytes Start Time
4 Repeat Interval UINT 2 bytes Frequency of connection in hours
72
File Transfer Functions

• Bulk configuration Download

73
General
Vendor specific configuration application
Master Station
Bulk Config file and matching IC file
Full Config (BCFICF)
Comms config or BCF
Incremental Config file
Field Device
74
Bulk Configuration Download

• Used for initial configuration download
• Vendor specific file contents
• Impractical to impose a standard
• Must contain point database as a minimum

75
File Transfer Functions

• Data Log Files

76
Data logging

• Transfer of historical data
• Defined filename format
• Defined File format
• AN2005-004

77
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

78
File format

• Depends on file content
• Has file header
• Followed by point/event information

79
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.