idnits 2.17.1 draft-vilajosana-detnet-windfarm-usecase-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 165 has weird spacing: '... | Data rate ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 7, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Sie13' is mentioned on line 365, but not defined == Missing Reference: 'Kri03' is mentioned on line 369, but not defined == Missing Reference: 'Spe09' is mentioned on line 373, but not defined == Missing Reference: 'Pet11' is mentioned on line 381, but not defined == Missing Reference: 'Ahm14' is mentioned on line 377, but not defined == Missing Reference: 'IEEE1646' is mentioned on line 360, but not defined == Missing Reference: 'IEC61400' is mentioned on line 356, but not defined == Missing Reference: 'IEC104' is mentioned on line 385, but not defined == Missing Reference: 'OPCXML' is mentioned on line 389, but not defined == Missing Reference: 'MODBUS' is mentioned on line 392, but not defined Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Detnet X. Vilajosana, Ed. 3 Internet-Draft Worldsensing 4 Intended status: Informational T. Mahmoodi 5 Expires: January 8, 2017 King's College London 6 S. Spirou 7 Intracom Telecom 8 P. Vizarreta 9 Technical University of Munich, TUM 10 July 7, 2016 12 Wind Park requirements for Detnet 13 draft-vilajosana-detnet-windfarm-usecase-00 15 Abstract 17 This document analyses the use case requirements for deterministic 18 flows in a wind park network. It inlcudes the intra-domain and 19 inter-domain requirements. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 8, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Use Case description . . . . . . . . . . . . . . . . . . . . 3 58 4. Traffic Demand . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Intra-Domain network considerations . . . . . . . . . . . . . 6 60 6. Inter-Domain network considerations . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 8. Wind Park Networks Future . . . . . . . . . . . . . . . . . . 8 63 9. Wind Park Network Wish List . . . . . . . . . . . . . . . . . 9 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 11.2. External Informative References . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The wind power industry has been selected as a representative example 73 of industrial networks with strict performance, security, and 74 reliability requirements. A Wind Park network is part of a 75 Supervisory Control and Data Acquisition (SCADA) system that 76 regulates power production from each wind turbine and from the entire 77 park. The SCADA system extends beyond the Wind Park, over the 78 Internet, to a remote control centre. Moreover, this network 79 interconnects sensors and actuators and a hierarchy of purpose-built 80 controllers and repositories via domain-specific protocols (e.g., IEC 81 1041, MODBUS2) in a static and secure topology. In this document the 82 Intra domain requirements, referring to the network consiserations in 83 terms of latency, jitter, delay tolerance, within the same 84 administrative domain will be presented. Analogously, and as Wind 85 Parks are connected to remote Control Centers the requirements and 86 considerations for the Inter domain reliability, jitter, latency and 87 delay tolerance will be outlined. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 3. Use Case description 97 In a Wind Park, the wind turbines represent a complex system of 98 sensors, actuators and an internal controller, located offshore or in 99 remote locations that communicate with a central control or master 100 SCADA station over reliable communication network. Wind turbines are 101 grouped in radials to maximize the energy production. The size of 102 the wind park varies significantly; having the biggest offshore wind 103 parks up to 200 wind turbines. Depending on the size of the park, 104 there might be an additional substation located close to turbines to 105 facilitate power transportation to the utility grid with minimum 106 losses [Sie13], [Kri03]. On another side, local control center 107 combines several functionalities necessary for control and management 108 of the wind park. SCADA comprise power plant control function to 109 synchronize and coordinate operation of the wind turbines in the 110 park, network management system (NMS) for network configuration, 111 performance and fault monitoring and different servers to collect and 112 store the metering data and status information from sensors, as well 113 as gateway to the other control centers and Internet [Spe09], 114 [Pet11]. The communication system between field devices and SCADA 115 has to be reliable to facilitate control and management of the wind 116 park. Wind power plant control and monitoring system have stringent 117 latency requirements, and reconfiguration of the network in the case 118 of a failure has to be done quickly. The most common way to improve 119 reliability is to connect wind turbines in a ring in order to provide 120 resistance to single link or node failure. Additionally, backup 121 microwave links can be built to improve the overall system 122 availability. 124 Figure 1: Wind turbine control network 126 | 127 | 128 | +-----------------+ 129 | | +----+ | 130 | | |WTRM| WGEN | 131 WROT x==|===| | | 132 | | +----+ WCNV| 133 | |WNAC | 134 | +---+---WYAW---+--+ 135 | | | 136 | | | +----+ 137 |WTRF | |WMET| 138 | | | | 139 Wind Turbine | +--+-+ 140 Controller | | 141 WTUR | | | 142 WREP | | | 143 WSLG | | | 144 WALG | WTOW | | 146 4. Traffic Demand 148 Figure 1 presents the subsystems that operate a wind turbine. This 149 subsystems include the rotor (WROT) control, the nacelle control 150 (WNAC), the transmission control (WTRM), the generator (WGEN), the 151 yaw controller of the tower head (WYAW), the in-turbine power 152 converter (WCNV), the in-tower power transformer (WTRF) and an 153 external meteorological station providing real time information to 154 the controllers of the tower (WMET). Traffic characteristics 155 relevant for the network planning and dimensioning process in a wind 156 turbine scenario are listed below. The values in this section are 157 based mainly on the relevant references [Ahm14] [Spe09]. Each 158 logical node (Figure 1) is a part of the metering network and 159 produces analogue measurements and status information that must 160 comply with different specifications in terms of data rate. 162 Table 2: Wind turbine data rate constraints 164 +----------+----------+----------+------------+----------+-------------+ 165 |Subsystem |# Sensors | # Analog | Data rate | # Status | Data rate | 166 | | | Samples |(bytes/sec) | Samples | (bytes/sec) | 167 +----------+----------+----------+------------+----------+-------------+ 168 | WROT | 14 | 9 | 642 | 5 | 10 | 169 | WTRM | 18 | 10 | 2828 | 8 | 16 | 170 | WGEN | 14 | 12 | 73764 | 2 | 4 | 171 | WCNV | 14 | 12 | 74060 | 2 | 4 | 172 | WTRF | 12 | 5 | 73740 | 2 | 4 | 173 | WNAC | 12 | 9 | 112 | 3 | 6 | 174 | WYAW | 7 | 8 | 220 | 4 | 8 | 175 | WTOW | 4 | 1 | 8 | 3 | 6 | 176 | WMET | 7 | 7 | 228 | - | - | 177 +----------+----------+----------+------------+----------+-------------+ 178 | Total | 102 | 73 | 225544 | 29 | 58 | 179 +----------+----------+----------+------------+----------+-------------+ 181 Quality of Service (QoS) requirements of different services are 182 presented in the Table 2. The requirements are defined by IEEE 1646 183 standard [IEEE1646] and IEC 61400 standard [IEC61400]. 185 Table 3: Wind turbine Reliability and Latency constraints 187 +-----------+----------+-------------+-----------------+ 188 | Service | Latency | Reliability |Packet Loss Rate | 189 +-----------+----------+-------------+-----------------+ 190 | Analogue | | | | 191 | measure | 16 ms | 99.99% | < 10-6 | 192 +-----------+----------+-------------+-----------------+ 193 | Status | | | | 194 |information| 16 ms | 99.99% | < 10-6 | 195 +-----------+----------+-------------+-----------------+ 196 |Protection | | | | 197 | traffic | 4 ms | 100.00% | < 10-9 | 198 +-----------+----------+-------------+-----------------+ 199 | Reporting | | | | 200 |and logging| 1 s | 99.99% | < 10-6 | 201 +-----------+----------+-------------+-----------------+ 202 | Video | | | no specific | 203 | surveill. | 1 s | 99.00% | requirement | 204 +-----------+----------+-------------+-----------------+ 205 | Internet | | | no specific | 206 |connection | 60 min | 99.00% | requirement | 207 +-----------+----------+-------------+-----------------+ 208 | Control | | | | 209 | traffic | 16 ms | 100.00% | < 10-9 | 210 +-----------+----------+-------------+-----------------+ 211 | Data | | | | 212 | polling | 16 ms | 99.99% | < 10-6 | 213 +-----------+----------+-------------+-----------------+ 215 5. Intra-Domain network considerations 217 A Wind turbine is composed of a large set of subsystems (sensors, 218 actuators) that require time critical operation. The time- 219 criticallity of different actions is shwon in Table 3. These 220 subsystems are connected to an intra-domain network used to monitor 221 and control the operation of the turbine and connect it to the SCADA 222 subsystems. The different components are inter-connected using fiber 223 optics, industrial buses, industrial ethernet, EtherCat or a 224 combination of them. Industrial signaling and control protocols such 225 as Modbus, Profibus, Profinet and EtherCat are used directly on top 226 of the L2 or encapsulated over TCP/IP. 228 The Data collected from sensors or condition monitoring systems is 229 multiplexed into fiber cables for transmission to the base of the 230 tower and to remote control centers. The turbine controller 231 continuously monitors the condition of the wind turbine and collects 232 statistics on its operation. As the name implies, the controller 233 also manages a large number of switches, hydraulic pumps, valves, and 234 motors within the wind turbine. 236 There is usually a controller both at the bottom of the tower and in 237 the nacelle. The communication between these two controllers usually 238 takes place using fiber optics instead of copper links. Sometimes, a 239 third controller is installed in the hub of the rotor and manages the 240 pitch of the blades. That unit usually communicates with the nacelle 241 unit using serial communications. 243 6. Inter-Domain network considerations 245 As mentioned in the introduction, a remote control center that 246 belongs to a grid operator, regulates the power output, enables 247 remote actuation and monitors the health of one or more Wind Parks in 248 tandem. It connects to the local control center in a Wind Park over 249 the Internet (Figure 2), via firewalls at both ends. The AS path 250 between the local control center and the Wind Park typically involves 251 several ISPs at different tiers. For example, a remote control 252 center in Denmark can regulate a Wind Park in Greece over the normal, 253 public AS path between the two locations. 255 The remote control center is part of the SCADA system, setting the 256 desired power output to the Wind Park and reading off the result once 257 the new power output level has been set. Traffic between the remote 258 control center and the Wind Park typically consists of protocols like 259 IEC 104 [IEC104], OPC XML-DA [OPCXML], Modbus [MODBUS], and SNMP 260 [RFC3411]. Usually, QoS requirements are not strict, so no SLAs or 261 service provisioning mechanisms (e.g., VPN) are employed. Traffic 262 flow across the domains is best effort. In case of events like 263 equipment failure, tolerance for alarm delay is in the order of 264 minutes, due to redundant systems already in place. 266 +--------------+ 267 | | 268 | | 269 | Wind Park #1 +----+ 270 | | | XXXXXX 271 | | | X XXXXXXXX +----------------+ 272 +--------------+ | XXXX X XXXXX | | 273 +---+ XXX | Remote Control | 274 XXX Internet +---------+ Center | 275 +----+X XXX | | 276 +--------------+ | XXXXXXX XX | | 277 | | | XX XXXXXXX +----------------+ 278 | | | XXXXX 279 | Wind Park #2 +----+ 280 | | 281 | | 282 +--------------+ 284 7. Security Considerations 286 On top of the classical requirements for protection of control 287 signaling, it must be noted that Wind Farm networks operate on 288 critical infrastructures with heterogeneous devices and networks. 289 This includes heterogeneous L2 technologies that must be secured in a 290 per link model. Control and signaling occur at the transport layer 291 and therefore end to end security mechanism must be installed. 293 8. Wind Park Networks Future 295 In the future we expect cloud-based SCADA systems controlling, 296 storing and monitoring the critical and non-critical subsystems of 297 the windfarm. We foresee an increase in the number of sensing 298 devices and technologies, combining wireless and wired capillars. We 299 foresee heterogeneous L2 technologies, homogenized by common IPv6 300 frameworks such as those developed by 6TiSCH, 6lo, LPWAN and 6MAN. 301 We expect windfarm networks to be operated by standardized and common 302 management planes, enabling the orchestration of the different 303 building blocks and underlaying technologies and being able to 304 Internet-connect enabling service gurantees and remote operation with 305 quality of service. Therefore protocols for network management, flow 306 control, increased reliability and security are mandatory in order to 307 improve the operation of critical infrastructures, including in this 308 case Wind Farms. 310 9. Wind Park Network Wish List 312 The community would like to see a set of protocols that enable the 313 inter-domain and the intra-domain operation of a wind park 314 infrastructure satisfying the timing, security, availability and QoS 315 constraints described above, such that the resulting converged 316 network can replace the heterogeneous, sometimes propieatary field 317 networks. Ideally this connectivity should extend to the open 318 Internet. This would imply an architecture that can guarantee 320 Low communication delays from <4 ms to 1000ms in the inter-domain 321 network 323 Low communication delays from <150 ms to 5000 ms in the intra- 324 domain network 326 Low jitter (< 1 ms) 328 Tight feedback intervals (4ms - 10ms) in the intra-domain 330 High network availability (up to 99.9999% ) 332 10. Acknowledgements 334 This requirements have been extracted from the study of Wind Farms 335 conducted within the 5GPPP Virtuwind Project. The project is funded 336 by tge European Union's Horizon 2020 research and innovation 337 programme under grant agreement No 671648 (VirtuWind). 339 11. References 341 11.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 349 Architecture for Describing Simple Network Management 350 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 351 DOI 10.17487/RFC3411, December 2002, 352 . 354 11.2. External Informative References 356 [IEC61400] 357 "International standard 61400-25: Communications for 358 monitoring and control of wind power plants", June 2013. 360 [IEEE1646] 361 "Communication Delivery Time Performance Requirements for 362 Electric Power Substation Automation", IEEE Standard 363 1646-2004 , Apr 2004. 365 [Sie13] "Creating the most from wind, retrieved from siemens.com/ 366 wind-equipment", ACM International Conference on Mobile 367 Computing and Networking (MobiCom) , June 2013. 369 [Kri03] Kristoffersen, J. and P. Christiansen, "Horns Rev Offshore 370 Wind Farm: Its Main Controller and Remote Control 371 System.", Wind Engineering, p. 351-360. , June 2003. 373 [Spe09] Sperotto, A., Sadre, R., Vliet, F., and A. Pras, "A First 374 Look into SCADA Network Traffic", IP Operations and 375 Management, p. 518-521. , June 2009. 377 [Ahm14] Ahmed, M. and R. Kim, "Communication network architectures 378 for smart-wind power farms", Energies, p. 3900-3921. , 379 June 2014. 381 [Pet11] Pettener, A., "SCADA and communication networks for large 382 scale offshore wind power systems", EIET Conference on 383 Renewable Power Generation. , June 2011. 385 [IEC104] International Electrotechnical Commission, "International 386 Standard IEC 60870-5-104: Network access for IEC 387 60870-5-101 using standard transport profiles", June 2006. 389 [OPCXML] OPC Foundation, "OPC XML-Data Access Specification", Dec 390 2004. 392 [MODBUS] Modbus Organization, Inc., "MODBUS Application Protocol 393 Specification", Apr 2012. 395 Authors' Addresses 396 Xavier Vilajosana (editor) 397 Worldsensing 398 483 Arago 399 Barcelona, Catalonia 08013 400 Spain 402 Phone: +34 (646) 633 681 403 Email: xvilajosana@worldsensing.com 405 Toktam Mahmoodi 406 King's College London 407 Strand, London WC2R 2LS 408 London, London WC2R 2LS 409 UK 411 Email: toktam.mahmoodi@kcl.ac.uk 413 Spiros Spirou 414 Intracom Telecom 415 19.7 km Markopoulou Ave. 416 Peania, Attiki 19002 417 Greece 419 Email: spis@intracom-telecom.com 421 Petra Vizarreta 422 Technical University of Munich, TUM 423 Maxvorstadt, Arcisstrasse 21 424 Munich, Germany 80333 425 GE 427 Email: petra.vizarreta@lkn.ei.tum.de