790 likes | 1.2k Views
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
E N D
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 • 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)
” 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 ” The UK-WITS Vision 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
Ferrantti Seprol Ferranti Seprol Serck Dynamic Logic Dynamic Logic Serck The problem SCADA Telemetry System Master stations with proprietary protocols, can only buy from 1 vendor – high risk, high cost Proprietary protocol drivers 6000 Legacy Field Devices PSTN or GSM only
The solution Old master station being replaced, offering new opportunities PSTN, GPRS, ADSL, … Type 2 Type 1 Type 1 Type 3 Type 1 Type 2 Type 2 Type 4
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 (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 Objectives • Improved device connectivity • Financial benefits • Reduced dependency on specific vendors • Future proofing & future IT compatibility • Assess costs & ease of adoption Page 17
Assess Options Economic Approach Technical Analysis Recommendations Preferred Option(s) Implementation Plan Project Approach Page 19
Options Selection The Options • Do nothing • Adopt an existing open standard protocol • Adopt an existing proprietary protocol • Develop a new standard protocol $$$$ Page 18
Options Selection Option 1: Do Nothing Page 20
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
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
DNP 3 • IEC 60870 • IEC 61850 • Modbus • UCA 2 20 ‘standards’ Options Selection – Standard Protocol Shortlist Selection Page 24
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
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 (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
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 • 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 Proprietary Protocols 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
Options Selection Option 3: Proprietary Protocol Page 31
Bristol Babcock • CSE Servelec/Seprol • Dynamic Logic • LogicaCMG • Serck Controls List of Vendors Options Selection – Proprietary Protocol Shortlist Selection Provide over 90% of UKWMO Telemetry Market Share Page 32
Options Selection – Proprietary Protocol Overview BSAP • Good range • of functionality • Flexible communications • Widely used in all • industry sectors D7000 Proteus 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? 201? Benefits 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
Business Requirements Functional Requirements TECHNICAL COMPATIBILITY Communications Data / Info IS/IT Operations Efficiency TECHNICAL ASSESSMENT Security STRATEGIC ISSUES (SWOT) Economic Assessment RECOMMENDATION Technical Evaluation- Methodology Page 44
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
Device A Device B Device C Device D Etc. Alarms Time Synch Prog. Download Remote Control Etc. Technical Evaluation – Functional Compliance Define Device Requirements Page 46
Technical Evaluation– Functional Compliance Analyse Options Page 49
Technical Evaluation – Functional Compliance Scoring Criterion: Function already supported by protocol standard Page 50
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
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
Technical Evaluation Overall Technical Evaluation Scoring Page 61