COMMUNICATION IN SMART WATER NETWORKS

Workgroup Interoperability, London April 2016 Who We Are

. Michal Koenig (Co-Chair), Qualcomm . Nicolas Foret, Schneider Electric . Stuart Combellack, Technolog . Jonathan Coome, Syrinix . Quintilia Lopez, INDRA . Salil M Kharkar & Elkin Hernandez, DC Water . Amin Rasekh, Sensus . Andreas Hauser (Chair) & Eley Querner, TUV SUD Motivation

. Proprietary systems . Vendor deadlock . Technology deadlock . Interface Incompatibility . Inefficiency due to wrong technology/protocols . Instability, Inconsistency, Business interruption . No confidence, no comparison . Excessive Piloting - No best practices – No scalable solutions – No standards . Reduced market acceptance Wireless Sensor Zigbee (IEEE 802.15.4) MiWi (IEEE 802.15.4) 6LoWpan (IEEE 802.15.4) Wireless Hart (IEEE 802.15.4) ISA 100 (IEEE 802.15.4) SimpliciTI (IEEE 802.15.4) KNX EnOcean Dash7 WISA ANT, ANT+ WiMax ONE-NET Z-Wave Insteon Buetooth WiFi NFC RuBee S-net Mission and Project Scope

. Foster the deployment and acceptance of smart water applications  seamless and interoperable communication and operation  generally accepted communication protocols . SWAN Work Group Interoperability Project: 1. current state of generally applied communication protocols in smart water networks applications 2. Define communication-related requirements of the involved components What is Interoperability?

. Interoperability refers to the capability of units of a smart water system to exchange and use information and services with one another and interfaced external units to enable an effective, secure system operation with little or no need for manual intervention. . The three types of interoperability, i.e., technical, semantic, and process interoperability, ensure effective exchange of data, common understanding of the data exchanged, and coordination of different work processes. Methodology

Sensor Measure continuously acoustic signals, pressure, flow or other data at a single point of a pipe network. RTU Able to read data from local sensor and actuator sending it to SCADA periodically. Additionally, it can provide local control of pumps and valves. Data Read data from sensor (flow, pressure, etc.), logger stores them at regular intervals, and transmits it to the SCADA system. SCADA Receives and aggregates data from multiple installations to monitor and control the network in near/real time. It may store historical data for later viewing. Analyti Analysis of data. cs/ Big data: Able to process massive and Server heterogeneous data. It can process structured and non structured information. The List

Requirements Application Transport Data Link Presentation Network Physical Session 3 Layer Approach: Sensor - Data logger Fault tolerant; command transmission (bidirectional SPI communication); standard interface: 4-20 mA, counter Dry contacts, pulse, 4- 20mA, 0-10V, RS232, inputs, or serial link (modbus,….); low power consumption • Application Layer RS482, M-Bus Data logger - SCADA GSM/GPRS coverage; secure communication, resilient to DNP3 TCP, TCP/UDP, DNP3, GSM RF, • failure, some applications require diversity, interoperability DNP3, IP Radio, LORA, SIGFOX Network Layer IPv6, IP SCADA – Web services tend to be proprietary interfaces but can have OPC DA, JSON, RDF, IPv6, IPv4 Server/Analytics automatic discovery; secure communication, security, OWL, RESTful web • Physical Layer services backfill, redundancy, interoperability SOAP, WSDL, XML, CSV, ODBC, OGC, SensorML, WaterML2.0, OpenMI Data logger – Secure data exchange; fault tolerant; command IPv6, IPv4 GSM RF, LORA, Server/Analytics transmission (bidirectional communication); network (ADSL, SIGFOX 3G, Wifi, etc.); SCADA - RTU Backfilling capable data exchange (SCADA backfill its Modbus, DNP3 TCP, TCP/UDP, GSM RF historical database, following loss with RTU), secure DNP3, IPv6, IPv4 communication, resilient to failure, some applications require diversity RTU – Valve Sensors data integration Modbus 6LoWPAN 4-20mA

Sensor - RTU Fault tolerant, secure, wired and wireless, bidirectional Modbus Dry contacts, pulse, 4- 20mA, 0-10V,

GIS – Analytics Secure data exchange, usability IPv6, IPv4

Sensor - PLC Fault tolerant, secure, wired, bidirectional Profibus, ModBUS RS485

Sensor - Server MQTT, XMPP 6LoWPAN Mapping into IoT World

R. Gil, "Wireless connectivity for the - One size does not fit all," 2014. IP Convergence

IPv6

6LoWPAN Take Aways

. Currently, many different communication protocols in smart water applications are used, which makes an interoperable and seamless exchange of data impossible. . Mainly caused by the addition of new smart applications on top of existing/proprietary network management systems, which are designed from an automation/vertical integration point of view. . However, the rapid development of the Internet of Things and Data Analytics suggests also horizontal integration with again different requirements in terms of range and throughput, power consumption and topology. . There is not the protocol that meets all the different requirements in smart water network applications. However, it can be stated that protocols for most of the communication channels are converging towards IP based protocols. . In any case, the shake-up in the communication space forces utilities and technology vendors to continuously observe this trend and to adapt accordingly. . Consequently, migration will play a key part for an interoperable, efficient and reliable smart water network for the near future. Outlook

. White Paper to be published end of April . Re-Focus Work Group “Interoperability” with the goal to . Stop excessive piloting and start piloting scalable, replicable and interoperable solution . Establish best practice use case . Define requirements for smart applications rather than technologies and pave the way for all innovators THANK YOU FOR YOUR ATTENTION

Workgroup Interoperability, London April 2016