Sage Journals: Discover world-class research

Abstract

Wireless networks are regarded as a promising candidate for condition monitoring systems of large-scale wind turbines due to the design flexibility, easy deployment, and reduced installation cost. This article investigates different data aggregation approaches of wireless-based architectures for the internal monitoring of a large-scale wind turbine. The main objective is to construct a wireless internal network inside the wind turbine nacelle, for collecting sensing data from different parts and transmitting the data to a remote control center through a wireless external network that serves the turbine towers of the wind farm. The proposed wireless network architectures consist of wireless sensor nodes, coordinator nodes, and a front-end device. The designs of the wireless-based architectures involve choices of physical components, sensor types, sampling rate, and data rate. Wi-Fi is a promising technology that is considered for the wind turbine internal network in this work. Through simulations, the network performance is evaluated with regard to end-to-end delay for different data aggregation approaches of wireless-based architectures.

Keywords

Wind turbine condition monitoring system wireless network Wi-Fi OPNET

Introduction

The installed capacity of wind energy is growing very fast compared with other sources of renewable energy.¹ This progress in the wind power industry has enabled wind turbines (WTs) to become more mature, with higher capacities, larger rotor diameters, and taller towers. However, recent studies have shown that as WTs become larger, the failure rate becomes higher, and thus, more maintenance is needed.² There are different condition monitoring solutions that are used for monitoring WTs such as supervisory control and data acquisition (SCADA), condition monitoring systems (CMS), and structure health monitoring (SHM). These solutions have been used for real-time monitoring and control of WTs in order to increase the availability, decrease downtime, and reduce operation and maintenance costs.³ The SCADA system is designed to provide data about the operating condition of WTs. It provides the average signal value of approximately 5–10 min from sensors such as temperature, vibration, power, and current. Compared to CMS, SCADA systems consider deploying small number of sensor nodes (SNs) with a lower sampling rate. Furthermore, SCADA does not collect all the necessary information for condition monitoring purposes.¹ The CMS is designed to provide data about the health of the WT with sampling rates in the kHz range. It consists of SNs and a data acquisition system. The main functions of CMS include data acquisition, data transmission, and data processing.⁴ There are different monitoring techniques used in WTs such as vibration analysis, acoustic analysis, ultrasonic testing, oil analysis, strain measurement, and thermography.² Regardless the technique used by WTs, the CMS capacity depends on number of SNs, types of sensors, and data processing techniques.

The communication network of a wind farm (WF) can be divided into two parts: the WT internal network and the WF external network. Both wired-based and wireless-based solutions may be considered for either the internal or external network. For a wired-based solution, Ferguson et al.⁵ and Swiszcz et al.⁶ carried out the design of a data acquisition and CMS for a WT internal network. The CMS was installed on an operating WT (Vestas V47). The CMS consists of two main units: the data acquisition unit in the nacelle and the data storage unit in the tower. Cables are used to connect between different sensor types and the data acquisition unit. The critical parameters monitored by the WT internal network were vibration, rotor speed, current, voltage, temperature, wind speed, wind direction, humidity, and pressure. In Goraj et al.,⁷ a communication network design for an offshore WF was given that had an Ethernet-based architecture. The authors described the design requirements and network topology for a large-scale WF (the Great Gabbard wind project) in the United Kingdom. In Park et al.,⁸ a novel CMS was developed and installed at the Yeongheung WF, South Korea, for three WTs supplied by different manufacturers. The communication network for the CMS also has an Ethernet-based architecture. The CMS has been installed in a WT nacelle and operated successfully.

For a wireless-based solution, Meng et al.⁹ presented the design of a wireless-based SCADA system for a WF. In Zheng et al.,¹⁰ the authors studied the feasibility of applying the broadband wireless technology using WiMAX (Worldwide Interoperability for Microwave Access) for monitoring WFs. The network topology is based on a wireless mesh configuration. The communication network consists of a communication controller at each WT, wireless mesh nodes in the WF, and a remote monitoring station at the control center. In Song et al.,¹¹ the authors designed a remote monitoring system for WTs, where the internal network consisted of a ZigBee-based wireless sensor network and was connected to the control center by a general packet radio services (GPRS) module. In Hsu and Wu,¹² the authors implemented a data transmission interface for remote monitoring and control of a small-scale WT based on ZigBee wireless sensor network. After long-term practical running, the system proved to be successful and stable. The deployment of ZigBee supports data rate up to 250 kbps and lower power consumption. Also, it supports different network topologies (star, ring, and mesh) which could provide coverage range of 10–100 m.¹³ In Kang et al.,¹⁴ we report that we have recently designed and implemented a condition monitoring and control system for a small-scale WT. It consists of data collection units, a control unit, and a coordinator. The data collection units are installed to collect sensing data from different sensors such as temperature, humidity, pressure, wind direction, wind speed, and vibration. ZigBee-based wireless is used to communicate between a coordinator and data collection units.

One of the recent developments in CMS for WTs is to design a smart, wireless, and energy-efficient sensor network where wired-based solutions cannot be installed.¹ Wireless technology could provide the vital solution to minimize deployment difficulties and cost and is more flexible than wired networks. In this work, Wi-Fi is a promising candidate considered for the WT internal network. The deployment of wireless local area network (WLAN) provides high-speed point-to-point and point-to-multipoint communication. Also, it offers easy installation, more flexibility, and less cost. The selection of Wi-Fi for a WT communication network is based on Nilsson.¹⁵ The author designed and implemented a lifetime monitoring system for a real WT, where the monitoring modules in the hub and the nacelle were connected through WLAN (IEEE 802.11b/g). The field tests of the prototype installation in the WT worked successfully despite of the harsh environment. Also, the prototype tests showed that the communication was stable and reliable.

The main contribution of this work is a design for wireless-based architectures for the internal condition monitoring of a large-scale WT that is based on the International Electrotechnical Commission (IEC) 61400-25-6 standard. The proposed network model consists of wireless SNs, coordinator nodes (CNs), and a front-end (FE) device. Appropriate choices for physical components, sensor types, sampling rate, and data rate have been considered in order to meet the requirements for aggregating sensing data wirelessly from a WT internal network. We conducted network modeling and simulation using OPNET Modeler.

Communication network for WT

IEC 61400-25 standard

A WF is composed of three main components: WTs, the electrical system, and the meteorological system. IEC 61400-25 is a standard for the monitoring and control of the WF. It is an extension of the IEC 61850 standard that used for communication networks in electric substations. According to the IEC 61400-25-6¹⁶ (logical node (LN) classes and Data classes for Condition Monitoring), WT condition monitoring is defined as the process of observing WT components or structures for a period of time to detect early signs of failures. There are different elements of WT condition monitoring involving vibration, oil debris, temperature, strain gauges, and acoustics. Figure 1 shows the scope of the IEC 61400-25-6 standard, which consists of two main parts: local condition monitoring and central condition monitoring. The local condition monitoring part is located in the WT, while central condition monitoring part is in the control center.

Figure 1.

Condition monitoring and control of WTs based on IEC 61400-25-6.

Conventional condition monitoring system of WT

The conventional local CMS inside a WT consists of SNs, a data acquisition unit, and a local computer. There are many SNs placed at different parts to measure the critical parameters such as temperature, vibration, wind speed, and wind direction. The SNs periodically generate monitoring data that are forwarded from data acquisition units to the wind turbine controller (WTC) for temporary storage. The CMS is located in the turbine nacelle and connected to the main WTC. The WTC is able to manage a variety of open and proprietary communication protocols such as Fieldbus and industrial Ethernet. In addition, the WTC exchanges control information for pitch control to change the blade angle and the yaw drivers based on wind direction and speed. Figure 2 shows the conventional wired-based communication network architecture for the CMS inside a WT. The WTC is located at the base of the tower, which is connected to an Ethernet switch for WF networking. Furthermore, it exchanges data between the WT and the control center.¹⁷

Figure 2.

Conventional wired-based communication network architecture for CMS inside WT.

We consider the IEC 61400-25 standard to define the WT LNs including WROT, WTEM, WGEN, WTRF, WNAC, WYAW, WTOW, and WMET, as given in Table 1. The SNs of a WT could be classified into different categories such as mechanical measurements (rotor speed, pitch angle, oil level, temperature, displacement, vibration, and torque); electrical measurements (voltage, current, power, power factor (PF), and frequency); meteorological data (wind speed, wind direction, temperature, humidity, and pressure); and status information. Table 2 shows the detailed types of data and attributes of the rotor. In this work, we define the sensor types and number of SNs for the WT based on the IEC 61400-25-2 standard.

Table 1.

Logical nodes of a wind turbine.

LN classes	Description
WROT	Wind turbine rotor information
WTRM	Wind turbine transmission information
WGEN	Wind turbine generator information
WCNV	Wind turbine converter information
WTRF	Wind turbine transformer information
WNAC	Wind turbine nacelle information
WYAW	Wind turbine yawing information
WTOW	Wind turbine tower information
WMET	Wind power plant meteorological information

LN: logical node.

Table 2.

Types of data and attributes of the rotor (WROT).

Data	Attribute name	Explanation
Analog information	RotSpd	Rotor speed at rotor side
	RotPos	Angular rotor position
	HubTmp	Temperature in the rotor hub
	PtHyPresBl	Pressure of hydraulic pitch system for blade
	PtAngValBl	Pitch angle for blade
Status information	RotSt	Status of rotor
	BlStBl	Status of blade
	PtCtlSt	Status of pitch control
Control information	BlkRot	Set rotor to blocked position
Control information	PtEmgChk	Check emergency pitch system

Proposed wireless-based architectures for WT

Wireless network architecture

The proposed wireless-based architecture for WF consists of two levels: WT internal network and WF external network, as shown in Figure 3. There are three main parts of a WT: nacelle, tower, and foundation. The CMS is located in the WT nacelle for collecting sensing data from different parts. The WT internal network consists of many SNs. The SNs are connected to different WT parts such as the gearbox, generator, and transformer. The internal network covers a small network size, where the main function of this level is local monitoring inside the WT. A wireless FE device is located in the nacelle for collecting and processing the WT monitoring data. Furthermore, it communicates with the control center through a wireless external network. The WT internal network could be implemented using conventional wired technology (Ethernet) or wireless technology (Wi-Fi, ZigBee, and Bluetooth).

Figure 3.

Proposed wireless-based communication network architecture for WF.

The main function of WF external network level is remote monitoring of the WF. It enables the control center to exchange monitoring data and control information remotely with WTs. The WF external network requires longer range communication between WTs and the control center, compared to the distances over which the internal network operates. The function of the control center is to store monitoring data which are categorized and stored in servers. In the proposed wireless-based solution, a base station is located at the control center. The base station enables the exchange of uplink monitoring data (from WTs to the control center) and downlink control data (from the control center to WTs). There are two types of data transmission for the WF external network, namely, direct transmission (single hop) and multi-hop transmission (multiple hops). In direct transmission configuration, WTs transmit data directly to the base station of the control center (point-to-multipoint topology). This configuration is suitable for WFs with a small number of WTs. However, with a large number of WTs, the link between WTs and the base station may become congested. In the multi-hop transmission configuration, WTs transmit data to the base station of the control center using multiple hops. In uplink and downlink, intermediate nodes called relay nodes are operated as aggregators and relays, which are used to connect WTs and the control center. The multi-hop transmission reduces the number of direct links from WTs to the base station and provides additional coverage compared to a single-hop transmission.¹⁰

Network model and data aggregation approach

Figure 4 shows a schematic diagram illustrating a WT as a cyber-physical system. It consists of two parts: the physical level and the network level. Based on the IEC 61400-25-6 standard, the WT physical level consists of nine LNs: rotor (WROT), transmission (WTRM), generator (WGEN), converter (WCNV), transformer (WTRF), nacelle (WNAC), yaw (WYAW), tower (WTOW), and meteorological (WMET), as shown in equation (1)

\begin{matrix} W T_{LN} = {WROT, WTRM, WGEN, WCNV, \\ WTRF, WNAC, WYAW, WTOW, WMET \end{matrix}}

(1)

Figure 4.

Schematic diagram illustrating WT as a cyber-physical system.

The network level comprises three different types of nodes: SNs, CNs, and an FE device. The main function of SN is sensing, while the function of CN is data aggregation from wireless SNs through single hop or multi-hops. The FE device aggregates data from CNs. Also, it communicates with the control center through a wireless external network. Each WT part is considered to be represented by an LN, as shown in Figure 4, whose nodes involve different types of SNs.

An SN SN_i can be identified by the physical location (LN), sensor type (S_T), and sensor identifier (S_ID) using equation (2)

S N_{i} = {LN, S_{T}, S_{ID}}

(2)

There are several types of SNs inside WT such as temperature (Tmp), speed (Spd), pressure (Pres), torque (Torq), voltage (V), current (A), and PF. The types of sensors S_T(SN_i) can be defined as in equation (3)

S_{T} (S N_{i}) \subseteq {Tmp, Spd, Pres, Torq, V, A, PF, \dots}

(3)

In order to identify SN_i, each sensor has a unique identifier (S_ID), where T is the total number of sensors, as given in equation (4)

S_{ID} (S N_{i}) = i i \in T

(4)

We define the sampling rate and number of channels in order to calculate the data size generated from each SN. The sample size is assumed 2 bytes (16 bits) based on Wijetunge et al.¹⁸ Data rate of the application layer can be calculated according to equation (5)

Data rate = 2 \times N_{c} \times f_{s}

(5)

where N_c and f_s represent the number of channels and sampling frequency, respectively.

We considered different configurations for aggregating sensing data wirelessly from the WT internal network. The four approaches for data aggregations inside the WT are those based on the physical components, the sensor types, the sampling frequency, and the data rate. Data aggregation aims to collect and forward sensing data from different SNs toward the FE device. The physical SNs are installed inside the WT. We used the concept of virtual nodes (VNs) to organize the physical SNs into multiple groups, as shown in Figure 5.

Figure 5.

Mapping of physical sensor devices to the logical network counterpart.

Case 1: data aggregation based on physical components

There are nine LNs representing nine parts of the WT based on the IEC 61400-25-6 standard. Each LN consists of one CN and many SNs. There is a direct communication between the SNs and the CN for collecting sensing data. In addition, there is a direct communication between the nine CNs and the FE unit, as shown in Figure 6.

Figure 6.

Data aggregation based on the physical components.

Case 2: data aggregation based on data rate

A WT consists of three LNs and one VN. The three LNs represent heavy data traffic inside WT, which are WGEN, WCNV, and WTRF. The VN represents the aggregation among six LNs with light data traffic, which are WROT, WTRM, WNAC, WYAW, WTOW, and WMET. Figure 7 shows the data aggregation based on the data rate, where there is a direct communication between the four CNs and the FE unit.

Figure 7.

Data aggregation based on the data rate.

Case 3: data aggregation based on sampling rate

The measurements are classified based on the sampling rate into eight VNs as follows: 1 Hz (temperature, power factor, humidity, oil level, and status); 3 Hz (speed, pitch angle, wind direction, and wind speed); 5 Hz (power); 10 Hz (displacement and frequency); 50 Hz (torque); 100 Hz (pressure); 200 Hz (vibration); and 2048 Hz (voltage and current). Also, there is a direct communication between the eight VNs and the FE unit, as shown in Figure 8.

Figure 8.

Data aggregation based on the sampling frequency.

Case 4: data aggregation based on sensor type

There are different types and number of SNs. The measurements are classified based on sensor types into 17 VNs as follows: temperature (16 SNs), speed (3 SNs), pressure (7 SNs), wind direction (3 SNs), wind speed (3 SNs), pitch angle (6 SNs), vibration (2 SNs), voltage (12 SNs), power (2 SNs), power factor (2 SNs), current (6 SNs), oil level (4 SNs), frequency (1 SN), displacement (2 SNs), torque (1 SN), humidity (3 SNs), and status information (29 SNs). In this case, there is a direct communication between the 17 VNs and the FE unit, as shown in Figure 9. Table 3 compares different data aggregation approaches for the WT internal network, and Table 4 shows the measurement requirements for different SNs inside the WT.

Figure 9.

Data aggregation based on the sensor type.

Table 3.

Different configurations of data aggregation for WT internal network.

Data	Data aggregation	LN	VN	SN	CN
Case 1	Physical level	9	–	102	9
Case 2	Data rate	3	1	102	4
Case 3	Sampling rate	–	8	102	8
Case 4	Sensor type	–	17	102	17

WT: wind turbine; LN: logical node; VN: virtual node; SN: sensor node; CN: coordinator node.

Table 4.

Measurement requirement for sensor data in WT.

Measurement	Data transmission (bytes/s)	Number of SNs	Total traffic (bytes/s)
Temperature	2	16	32
Speed	6	3	18
Pressure	200	7	1400
Pitch angle	6	6	36
Vibration	1200	2	2400
Voltage	12,288	12	147,456
Current	12,288	6	73,728
Power	10	2	20
Power factor	2	2	4
Humidity	2	3	6
Wind direction	6	3	18
Wind speed	6	3	18
Displacement	40	2	80
Oil level	2	4	8
Frequency	20	1	20
Torque	300	1	300
Status	2	29	58
Total		102	225,602

WT: wind turbine; SNs: sensor nodes.

From the practical point of view, data aggregation could be implemented by different wired/wireless technologies. Wired connections can be used to collect measurements from SNs and transmit the data to the FE unit. Also, wireless technology can be used to collect measurements from SNs using a wireless access point (AP). Given wired-based solution as an example, Ferguson et al.⁵ carried out the design of a data acquisition and CMS for a WT internal network where wired connections have been used to connect between different sensor types and the data acquisition unit. The parameters were divided into two groups based on the sampling rate: low speed (50 Hz) and high speed (20 kHz). The same concept has been used in Case 3 of our work for data aggregation based on the sampling rate.

Network modeling and simulation

Assumptions

A set of real WT dimensions was used to build our network model. The dimensions are related to an offshore WT (HQ 5500) prototype that was installed on Jeju Island (South Korea) in February 2014. The WT capacity is 5.5 MW, which is the biggest turbine size installed in South Korea. The hub height is 100 m and the rotor diameter is 140 m. The network configuration in OPNET considers a field of 200 m × 200 m. The tower height is 100 m, the nacelle dimension is 12 m × 4 m, and the rotor diameter is 140 m.¹⁹ Simulation assumptions are given in Table 5.

Table 5.

Simulation assumption.

Parameter	Value
Nacelle area	12 m × 4 m
Tower height	100 m
Technology	Wi-Fi
Wi-Fi data rate	54, 24, and 11 Mbps
Simulation time	10 min

IEC technical committee (TC 88) has published the standard IEC 61400-25, which comprises six parts. Part 4 (IEC 61400-25-4) presents the conceptual architecture of multiple mapping for the communication profile, as shown in Figure 10. Both physical and link layers are out the scope of the standard. The Transmission Control Protocol/Internet Protocol (TCP/IP) is the basic protocol supported by all mapping profiles.²⁰ Different communication network technologies (wired/wireless) could be considered. The focus of this research work is on IEEE 802.11 (Wi-Fi) using the OPNET simulation.

Figure 10.

Illustration of protocol stack: (a) communication profiles based on IEC 61400-25-4 and (b) protocol stack of FTP.

A WT is an autonomous system which can continue to work even if the communication link between the WT and the control center is not available. As explained in section “Communication network for WT,” each WT is equipped with a WTC that handles and stores data from SNs. Data packets are received at the WTC at different time intervals such as 100 ms, 1 s, and 10 s. The WTC processes the sensing data for internal control purposes and provides the data to the SCADA system. The measurements are cached and transmitted in bulk with a different frequency. The updated rate is at least once per second, and the maximum transfer rate is based on channel capacity and network technology.^21,22

The IEC 61400-25 standard does not provide any specific communication timing requirements for WT communication network. In this work, we considered the communication timing requirements for electric substation automation based on IEEE 1646 standard, as shown in Table 6.²³ The focus of this work is the WT internal network (between SNs and the WTC). The WF external network (the connection between the WT and the control center) is out of scope of this work.

Table 6.

Communication timing requirements for different applications based on IEEE 1646 standard.

Information type	Internal	External
Monitoring and control	16 ms	1 s
Protection	4 ms	8–12 ms
Operation and maintenance	1 ms	10 s

Figure 11 shows the internal structure of a wireless SN (wlan_wkstn_adv) used for Wi-Fi-based architectures. The application layer is concerned with SNs’ information such as message type, message size, and data interval. The File Transfer Protocol (FTP) is selected to transfer the data between SNs and the FE unit.

Figure 11.

OPNET model of a sensor node based on Wi-Fi.

Wi-Fi-based internal network for WT

Figure 12 shows the Wi-Fi-based architecture of the WT internal network using 102 SNs. Four different scenarios are configured for data aggregation. In OPNET, the network model is implemented using wireless workstations (wlan_wkstn_adv) and APs (wlan_ethernet_slip4_adv). Figure 13 shows the network configuration of Wi-Fi-based architecture for Case (1). The communication network is configured in an infrastructure mode which consists of nine basic service sets (BSSs). The FE unit is connected to nine APs using wired links (Fast Ethernet). The following metrics have been considered for the performance evaluation:

Server FTP Traffic received (bytes/s) represents the average bytes per second forwarded to all FTP applications by the transport layers in the server node.

End-to-end (ETE) delay is the amount of time (in seconds) for data to be delivered from source (SNs) to the destination (FE device) along the communication path.

Wireless local area network (LAN) delay (s) represents the ETE delay of all the packets received by the wireless LAN MACs of all WLAN nodes in the network and forwarded to the higher layer. This delay includes medium access delay at the source MAC, reception of all the fragments individually, and transfers of the frames via AP, if AP functionality is enabled.

Wireless LAN data dropped (bits/s) represents the total size of higher layer data packets (in bits/s) dropped by all the WLAN MACs in the network.

Figure 12.

Wi-Fi-based OPNET model of WT internal network (no aggregation—102 sensor nodes).

Figure 13.

Wi-Fi-based OPNET model of WT internal network for Case 1: nine LNs.

Traffic received results

The data traffic for the Wi-Fi-based network architecture for Cases 1 and 2 is given as examples, as shown in Tables 7 and 8, respectively. Each SN is assigned a basic service set identifier (BSS-ID) to transmit the traffic profile to the allocated AP. Both the SN and the AP are configured with the same BSS-ID to ensure that the sensor data from different logical/VNs do not interfere with each other. The simulation results showed that the received amount of traffic at the FE unit agrees with our calculation for all cases. The received traffic from different SNs such as current, displacement, frequency, and humidity is shown in Figure 14(a). The initial peak in the curves is due to network initialization (for approximately 12 s). When the network goes into the steady state, the received traffic is stable. The total traffic is approximately 225,602 bytes/s, as shown in Figure 14(b).

Table 7.

Data traffic for Wi-Fi-based architecture (Case 1).

	WT internal network	Number of SNs	BSS-ID	Total traffic (bytes/s)
Case 1 (nine LNs)	WROT	16	1	642
	WTRM	3	2	2828
	WGEN	7	3	73,764
	WCNV	6	4	74,060
	WYAW	2	5	220
	WTOW	12	6	8
	WNAC	6	7	112
	WTRF	2	8	73,740
	WMET	2	9	228
	Total	102		225,602

WT: wind turbine; SNs: sensor nodes; BSS-ID: basic service set identifier; LNs: logical node.

Table 8.

Data traffic for Wi-Fi-based architecture (Case 2).

	WT internal network	Number of SNs	BSS-ID	Total traffic (bytes/s)
Case 2 (three LNs, one VN)	WGEN	14	3	73,764
	WCNV	14	4	74,060
	WTRF	12	8	73,740
	Six LNs data	62	1	4038
	Total	102		225,602

WT: wind turbine; SNs: sensor nodes; BSS-ID: basic service set identifier; LNs: logical node; VN: virtual node.

Figure 14.

Amount of received traffic for Wi-Fi-based architecture: (a) individual SNs in Case 1 and (b) total traffic received in Case 1.

Delay results

The performance of WT internal network (without data aggregation) is evaluated in view of ETE delay in case of direct data transmission from SNs to the FE device. The SNs are modeled by wireless workstations, and the FE device is modeled by a wireless server. Figure 15 compares the wireless ETE delay of 102 SNs using different data rates of 54, 24, and 11 Mbps. As expected, the higher the data rate, the lower the ETE delay. At 11 Mbps, the maximum ETE delay is approximately 96.151 ms, while it is approximately 40.763 ms at 54 Mbps. At 24 Mbps, the maximum and average ETE delays are 49.409 and 46.621 ms, respectively. Table 9 lists the maximum and average ETE delays for different data rates.

Figure 15.

ETE delay of Wi-Fi-based architecture with 102 SNs (no aggregation).

Table 9.

ETE delay for different Wi-Fi-based architectures (no aggregation).

Wi-Fi-based internal network	Maximum	Average
11 Mbps	96.151 ms	92.425 ms
24 Mbps	49.409 ms	46.621 ms
54 Mbps	40.763 ms	38.590 ms

We configured four scenarios for different data aggregations using a data rate of 54 Mbps. The WT internal network comprises nine APs in Case 1, four APs in Case 2, eight APs in Case 3, and 17 APs in Case 4. Figure 16 shows the ETE delay for different Wi-Fi-based architectures. Case 1 achieves the lowest ETE delay compared with other scenarios. The maximum and average ETE delays of Case 1 are 14.834 and 13.694 ms, respectively. Case 3 achieves the highest ETE delay. The maximum and average ETE delays of Case 2 are 26.986 and 24.735 ms, respectively. Figure 17 shows the data dropped in bits per second for WLAN versus the simulation time. For the direct data transmission scenario, a higher data drop rate is due to buffer overflow compared to other aggregation scenarios. If large numbers of SNs are connected directly to an AP or the FE device, the problem of congestion, collisions, and buffer overflow will occur and delay will be increased. Table 10 lists the maximum and average ETE delays for different network configurations. Considering the communication timing requirements of monitoring and control given in Table 6, the network model of Case 1 satisfies the timing requirements with ETE delay of less than 16 ms. No data packets were dropped due to buffer overflow for Cases 1 and 4.

Figure 16.

ETE delay of Wi-Fi-based architecture for Cases 1, 2, 3, and 4.

Figure 17.

Data dropped due to buffer overflow of Wi-Fi-based architecture for Cases 1, 2, 3, and 4.

Table 10.

ETE delay for different Wi-Fi-based architectures (54 Mbps).

Wi-Fi-based internal network	Maximum	Average
Case 1 (9 LNs)	14.834 ms	13.694 ms
Case 2 (4 VNs)	26.986 ms	24.735 ms
Case 3 (8 VNs)	28.762 ms	26.854 ms
Case 4 (17 VNs)	19.558 ms	18.231 ms

The results in Figure 17 show a high data drop rate due to buffer overflow for the direct data transmission (no aggregation scenario) compared to other aggregation scenarios. When there is a buffer overflow, we would expect to see latency increase. In Cases 1 and 4, no data packets were dropped due to buffer overflow. This can be confirmed by comparing the simulation results of Figure 17 with the ETE latencies in Figure 16. Cases 2 and 3 have more data dropped due to buffer overflow which results in a high ETE delay.

Conclusion

In this article, we investigated the design, simulation, and evaluation of different data aggregation approaches of wireless-based architectures for a WT internal network. The proposed wireless network consists of SNs, CNs, and an FE device. Wi-Fi is a promising technology considered in this work. The maximum ETE delay was approximately 96.151 ms for a data rate of 11 Mbps and approximately 40.763 ms for a data rate of 54 Mbps. Four approaches have been considered for data aggregation inside the WT based on physical components, sensor types, sampling rate, and data rate. Case 1 achieves the lowest ETE delay compared with other data aggregation approaches. The maximum and average ETE delays of Case 1 are 14.834 and 13.694 ms, respectively. A significant reduction in ETE delay has been achieved using data aggregation approaches compared with direct wireless data transmission.

Footnotes

Academic Editor: Jose Ignacio Moreno

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the Brain Korea 21 PLUS and the National Research Foundation of Korea (NRF) grant funded by the Korea government (2010-0028509, 2014-055177). This research was also supported by “Research Base Construction Fund Support Program” funded by Chonbuk National University in 2016.

References

Takoutsing

Wamkeue

Ouhrouche

. Wind turbine condition monitoring: state-of-the-art review, new trends, and future challenges. Energies 2014; 7: 2595–2630.

García Márquez

Tobias

Pinar Pérez

. Condition monitoring of wind turbines: techniques and methods. Renew Energ 2012; 46: 169–178.

Singh

Coulter

Sayani

MAG

. Survey on communication architectures for wind energy integration with the smart grid. Int J Environ Stud 2013; 70: 765–776.

Smarsly

Kincho

Hartmann

. A cyber infrastructure for integrated monitoring and life-cycle management of wind turbines. In: 20th international workshop on intelligent computing, in Engineering 2013 (ICE13), European Group for Intelligent Computing in Engineering (EG-ICE), Vienna, Austria, 1–3 July 2013, vol. 6, no. 30, pp.1–10.

Ferguson

Catterson

Booth

. Designing wind turbine condition monitoring systems suitable for harsh environments. In: 2nd IET renewable power generation conference (RPG 2013), Beijing, China, 9–11 September 2013, vol. 51, pp.1–4. London: Institution of Engineering and Technology (IET).

Swiszcz

Cruden

Booth

. A data acquisition platform for the development of a wind turbine condition monitoring system. In: 2008 international conference on condition monitoring and diagnosis, Beijing, China, 21–24 April 2008, vol. 51, pp.1358–1361. New York: IEEE.

Goraj

Epassa

Midence

. Designing and deploying Ethernet networks for offshore wind power applications—a case study. In: 10th IET international conference on developments in power system protection (DPSP 2010). Managing the change, Manchester, 29 March–1 April 2010, vol. 51, p.84. London: Institution of Engineering and Technology (IET).

Park

Kim

Lee

JK.

Development of condition monitoring system with control functions for wind turbines. Proc World Acad Sci Eng Technol 2011; 81: 286–291.

Meng

Gong

. Design of SCADA system based on wireless communication for offshore wind farm. In: Qian

Cao

. (eds) Recent advances in computer science and information engineering. Berlin and Heidelberg: Springer, 2012, pp.347–352.

10.

Zheng

Wang

. Applications of WiMAX-based wireless mesh network in monitoring wind farms. Int J Network Virt Organ 2010; 7: 535–548.

11.

Song

Wang

. Remotely monitoring offshore wind turbines via ZigBee networks embedded with an advanced routing strategy. J Renew Sustain Energ 2013; 5: 013110.

12.

Hsu

C-L

W-B.

The practical design of constructing data transition interface with ZigBee WSN and RS-485 wired interface—example with small-scaled wind-power electricity generator system. J Softw 2008; 3: 49–56.

13.

Parikh

Kanabar

Sidhu

. Opportunities and challenges of wireless communication technologies for smart grid applications. In: 10th IEEE power and energy society general meeting, Minneapolis, MN, 25–29 July 2010, pp.1–7. New York: IEEE.

14.

Kang

K-Y

Ahmed

Kim

Y-C

. Implementation of condition monitoring and control system for small-scale wind turbines. In: IECON 2014—40th annual conference of the IEEE industrial electronics society, Dallas, TX, 29 October–1 November 2014, pp.2122–2127. New York: IEEE.

15.

Nilsson

Lifetime monitoring of wind turbines. Master Thesis, Department of Automatic Control, Lund University, Lund, 2005.

16.

IEC 61400-25-6:2010. Wind turbines—part 25-6: communications for monitoring and control of wind power plants—LN classes and data classes for condition monitoring.

17.

Pettener

. SCADA and communication networks for large scale offshore wind power systems. In: IET conference on renewable power generation, RPG, Edinburgh, 6–8 September 2011, pp.1–6. New York: IEEE.

18.

Wijetunge

Gunawardana

Liyanapathirana

. Wireless sensor networks for structure health monitoring: considerations for communication protocol design. In: 17th ICT international conference on telecommunication, Doha, Qatar, 4–7 April 2010, pp.694–699. New York: IEEE.

19.

HQ 5500. 5.5 MW offshore wind turbine. New Horizons Spring Magazine, 2014, pp.24–27, https://www.hceamericas.com/common/cms/images/html-images/Media%20Content/HHI%20Horizon%20-%20Spring%202014%20(web).pdf (accessed 1 April 2016).

20.

IEC 61400-25-4:2008. Wind turbines—part 25-4: communications for monitoring and control of wind power plants—mapping to communication profile.

21.

Johnsson

Svensson

Wind power communication—design and implementation of test environment for IEC61850/UCA2. Elforsk rapport 02:16, April 2002. Stockholm: Elforsk AB.

22.

ENERCON SCADA System. Product description, 2006, pp.1–25, http://planning.allerdale.gov.uk/portal/servlets/AttachmentShowServlet?ImageName=170578

23.

Khan

JY.

A comprehensive review of the application characteristics and traffic requirements of a smart grid communications network. Comput Netw 2013; 57: 825–845.

Wireless communication architectures based on data aggregation for internal monitoring of large-scale wind turbines