METHOD, SYSTEM AND APPARATUS FOR ACCESSING AND MANAGING A PLURALITY OF WIND TURBINES VIA A NETWORK

CROSS REFERENCE TO RELATED APPLICATIONS

[001] This application claims priority from U.S. Provisional Patent Application No.

61/806,321 filed March 28, 2013 and Canadian Patent Application No. 2,810,823 filed on March 28, 2013, both of which are entitled METHOD, SYSTEM AND APPARATUS FOR ACCESSING AND MANAGING A PLURALITY OF WF D TURBINES VIA A NETWORK

and are hereby incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

Field of Invention

[002] The subject matter herein relates generally to accessing and managing wind turbines and more particularly to a method, system and apparatus for accessing and managing a plurality of wind turbines via a network.

Description of Related Art

[003] Wind turbines can be used individually or in groups to provide a clean source of power for individuals, communities, businesses and organizations. A range of different wind turbines are available on the market, ranging from smaller wind turbines of about 300W up to much larger wind turbines of about 7.5MW or larger. There is increasing interest for wind turbines generally on the smaller side of the scale, to allow for a wider range of availability and uses. Smaller wind turbines afford a generally easier and broader base of implementation, but also result in a more dispersed and widespread installation base, made up of a more diverse set of owners, operators, maintainers, dealers and other entities involved. Accordingly, in such an environment, there is a need for an improved form of networked communication in connection with multiple wind turbines, to enhance the way in which such wind turbines are accessed, managed and maintained.

SUMMARY OF THE INVENTION

[004] In accordance with one aspect of the invention, there is provided a method and system of monitoring and controlling a plurality of wind turbines via a network. Different levels of access and control are permitted with respect to the plurality of wind turbines for a variety of users amongst a variety of user groups. This provides a mechanism for managing what actions users are able to perform and what information they are able to see and manipulate in association the plurality of wind turbines. With this aspect wind turbines are organized and managed according to a plurality of access and control groups, with each of the access and control groups providing for a configurable level of access and control over one or more of the wind turbines associated with the applicable access and control group. Each access and control group corresponds to at least one wind turbine connected to the network. In various embodiments one or more access and control groups may comprise tens or hundreds of wind turbines or more. In addition, users are assigned user profiles through which users may be assigned to one or more of the access and control groups. When a user profile is assigned to an access and control group, it is also assigned one or more levels of access and control to all wind turbines associated with such access and control group. In various embodiments a user profile may be assigned a configurable level of access and control directly to one or more wind turbines.

5] In various embodiments, the plurality of wind turbines are assigned to a plurality of access and control groups via a first computer server, which includes assigning a first set of wind turbines to a first turbine group and a second set of wind turbines to a second turbine group. The first turbine group comprises associations with one or more wind turbines different from the wind turbines associated with the second turbine group. A plurality of user groups are associated with the plurality of access and control groups according to a plurality of user profiles managed via the first computer server, wherein each user within each plurality of user groups is assigned a user profile permitting a configurable level of access and control to one or more of the plurality of wind turbines. In various embodiments this includes: associating a first group of users with the first turbine group; associating a second group of users with the second turbine group; associating a third group of users with all or select subsets of both the first and second turbine groups; and associating a first subset of users from amongst the first group of users with a different level of access and control to one or more of the first set of wind turbines as compared to a second subset of users from amongst the first group of users associated with the first turbine group. With this aspect, a plurality of client device requests associated with the plurality of wind turbines may be received by the computer server from a plurality of client devices. For each of the plurality of client device requests, the server determines what level of access and control over wind turbine resources is associated with the applicable client device request based on which of the plurality of user profiles is associated with each of the plurality of client device requests. A select level of access and control to one or more of the plurality of wind turbines is provided to an applicable client device based upon and configured to an applicable user profile selected from the plurality of user profiles and associated with the applicable client device.

[006] In various embodiments, this access and control aspect may comprise retrieving and transmitting to the applicable client device user-centric data and instructions responsive to a corresponding client device request selected from the plurality of client device requests, wherein the user-centric data and instructions are configured to cause the applicable client device to display on a user interface only features of one or more of the plurality of wind turbines that are associated with the user-identified level of access and control available to the applicable user profile.

[007] In various embodiments, a custom interface is provided for a plurality of wind turbines in networked communication with a computer server system. This allows for different user interfaces and user experiences to be presented to client devices based on which wind turbine fleet a user profile and/or a wind turbine is associated with. In such cases, a first set of user interfaces may be available to one or more of a first plurality of users or user groups associated with a first wind turbine fleet, and a second set of user interfaces may be available to one or more of a second plurality of users or user groups associated with a second wind turbine fleet different from the first wind turbine fleet. In various embodiments the first wind turbine fleet comprises a first plurality of wind turbine groups, with each such group comprising one or more wind turbines different from the other groups in the first plurality of wind turbine groups. In various embodiments, the second wind turbine fleet comprises a second plurality of wind turbine groups, with each such group comprising one or more wind turbines different from the other groups in the second plurality of wind turbine groups.

[008] In another aspect of the invention, there is provided a method and system of caching wind turbine-related data on client devices for access and/or display to a user via a graphical user interface such as, for example, a web browser. In various embodiments, the pieces of wind turbine-related data that may be accessed and/or displayed via the graphical user interface may be in the tens or hundreds of pieces, and which may need to be refreshed or updated at regular or irregular time intervals to reflect changes in the state, operating condition, settings and/or parameters of a corresponding wind turbine. [009] In accordance with this aspect, a client-side cache is used to store visual data and other information related to a plurality of settings and parameters for a wind turbine that a particular client device is connected to and/or from which the client device is receiving information via a computer server. A consolidated request is formed by aggregating wind turbine-related data. Pieces of data of the same type that are needed by multiple screens are consolidated into a single request for the same type of data. The client-side cache may filter out requests for wind turbine- related data that is already known to the client-side session on the client device and which is not as yet stale or due for a refresh.

[0010] In various embodiments the client-side caching method makes use of software-based widgets and widget controllers available on or to the client device to aggregate data at certain time intervals so that client device requests for wind-turbine related data can be made to the computer server as consolidated requests. In various embodiments, a consolidated request is formed by aggregating wind turbine-related data across a plurality of screens or pages available to a user via the web browser or other graphical user interface.

[0011] In various embodiments, when a client device request is initiated seeking wind turbine- related data for one or more wind turbines, a software refresh component on the client device generates an aggregated list of variables identified as being in need of refreshed data. The refresh component may check with the client-side cache to filter out any variables in the list concerning pieces of data that are already known to the client-side cache and which are not as yet stale or due for a refresh. If after this filtering process there remain one or more variables in the aggregated list of variables, the refresh component initiates sending the client device request to the computer server, which retrieves and returns to the client device the necessary pieces of wind turbine-related data from a server-side cache if available and not stale or from the applicable wind turbine. Otherwise, the refresh component proceeds to a data refresh stage in which the information presented on the screens available through the graphical user interface displayed on the client device are refreshed locally based on the wind turbine-related data stored in the client-side cache.

[0012] In another aspect, there is provided a method and system of exchanging data and control signals with at least a portion of a wind turbine network comprising a plurality of wind turbines. With this aspect operational data is transferred from a plurality of wind turbines to an information management server operative to manage access and control over the plurality of wind turbines and then stored in a database in operative communication with the information management server. Transfer of the operational data from the plurality of wind turbines to the information management server occurs via a virtual private network ("VPN") connection created by a VPN concentrator server to operatively connect a plurality of client devices with the plurality of wind turbines via the information management server. In various embodiments, a separate VPN connection is established with the information management server for each wind turbine that the information management server is in communication with. Once a VPN connection is established by the VPN concentrator server, part or all of the operational data for a wind turbine may be transferred from the wind turbine to the information management server, where the data may be stored, cached and/or forwarded on to one or more client devices for display thereon in response to specific client device requests from those one or more client devices. In various arrangements, instructions from one or more client devices to control or change one or more features of a wind turbine can be communicated to the applicable wind turbine via a VPN connection established with that wind turbine by the VPN concentrator server.

[0013] In another aspect there is provided a range of various caching features to support accessing and managing a plurality of wind turbines via a network.

[0014] Another aspect provides a system for managing a plurality of wind turbines, each wind turbine having a local controller. The system comprises an authorization data store for storing permission data for the plurality of wind turbines. The permission data comprises, for each wind turbine, one or more authorized user profiles, each authorized user profile associated with an authorization level for that wind turbine. The system further comprises a central server system in communication with the local controllers of the wind turbines through a private network. The central server system is configured to receive a plurality of wind turbine access requests from a plurality of client devices through a public network, each wind turbine access request including a user profile and an indication specifying one or more particular wind turbines of the plurality of wind turbines. For each wind turbine access request, the central server system is configured to query the authorization data store with the user profile to determine an authorization level for each of the one or more particular wind turbines for the user profile, and provide the client device with a level of access to the one or more particular wind turbines specified in the wind turbine access request based on the determined authorization levels.

[0015] Another aspect provides a method for managing a plurality of wind turbines, each wind turbine having a local controller. The method comprises storing permission data for the plurality of wind turbines in an authorization data store accessible to a central server system, the permission data comprising, for each wind turbine, one or more authorized user profiles, each authorized user profile associated with an authorization level for that wind turbine, receiving, at the central server system, a plurality of wind turbine access requests from a plurality of client devices through a public network, each wind turbine access request including a user profile and an indication specifying one or more particular wind turbines of the plurality of wind turbines, and, for each wind turbine access request, querying the authorization data store with the user profile to determine an authorization level for each of the one or more particular wind turbines for the user profile, and providing the client device with a level of access to the one or more particular wind turbines specified in the wind turbine access request based on the determined authorization levels through a private network between the central server system and the local controllers.

[0016] Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In drawings which illustrate aspects, features and embodiments of the invention,

[0018] Figure 1 is a block diagram of a system for accessing and managing a plurality of wind turbines via a network in accordance with a first embodiment;

[0019] Figure 2 is a block diagram of an illustrative computer server in accordance with the first embodiment;

[0020] Figure 3 is a block diagram of an illustrative client device in accordance with the first embodiment;

[0021] Figures 4A to 4C are block diagrams illustrating tables for use in accordance with the first embodiment;

[0022] Figures 5A to 5C are block diagrams each illustrating a set of associations in accordance with the first embodiment;

[0023] Figure 6 is a block diagram illustrating a resulting set of permissions (filtered and unfiltered) managed in accordance with the first embodiment;

[0024] Figure 7 is a flowchart of an exemplary method for managing access and control over a plurality of wind turbines in accordance with the first embodiment; [0025] Figure 8 is another flowchart of an exemplary method of managing access and control over a plurality of wind turbines in accordance with the first embodiment;

[0026] Figure 9 is another flowchart of an exemplary method of managing access and control over a plurality of wind turbines in accordance with the first embodiment;

[0027] Figures 10A to 10G are diagrams illustrating exemplary user screens in accordance with the some embodiments;

[0028] Figures 1 1 A to 1 1 E are diagrams illustrating exemplary user screens displayed via a mobile device in accordance with the some embodiments;

[0029] Figure 12 is a block diagram of a system for accessing and managing a plurality of wind turbines via a network in accordance with another embodiment;

[0030] Figure 13 is a block diagram illustrating components of a client-side caching method in accordance with some embodiments;

[0031] Figure 14 is a flowchart of an exemplary method of one aspect of client-side caching in accordance with some embodiments;

[0032] Figure 15 is a flowchart of an exemplary method of another aspect of client-side caching in accordance with some embodiments;

[0033] Figure 16 is a flowchart of an exemplary method of another aspect of client-side caching in accordance with some embodiments;

[0034] Figure 17 is a flowchart of an exemplary method of another aspect of client-side caching in accordance with some embodiments;

[0035] Figure 18 is a diagram illustrating an exemplary user screen in accordance with the some embodiments;

[0036] Figure 19 is a diagram illustrating in a table a variety of widget features available from the user screen shown in Figure 18 in accordance with the some embodiments;

[0037] Figure 20 is a detailed view of a server system operable to implement various aspects of the present invention in some embodiments;

[0038] Figure 21 is a high level schematic view of a network system architecture and illustrating information flows between elements of the system as used in some embodiments;

[0039] Figure 22 is a schematic view of a VPN concentrator configuration for directing traffic flows between elements of the system in some embodiments;

[0040] Figure 23 depicts a flowchart illustrating a load balancer monitoring routine used in some embodiments; [0041] Figures 24A and 24B depict a flowchart illustrating an I/O request and read request handling routine implemented in some embodiments;

[0042] Figure 25 depicts a flowchart illustrating a write request handling routine implemented by the system in some embodiments.

DETAILED DESCRIPTION

[0043] Aspects and features of the invention will now be described with reference to illustrative embodiments and figures.

[0044] System Overview

[0045] Referring to Figure 1 , a system for supporting access to and management of a plurality of wind turbines via a network in accordance with a first embodiment is shown generally at 100 (also referred to herein as a wind turbine management system). The system 100 includes a computer server system 102 operative to communicate with a plurality of wind turbines 104, 105, 106, 107, 108 and 109 via network 1 10, and a plurality of cl ient devices 1 14, 1 16, 1 1 8 and 120 via network 1 12. The computer server system 102 comprises one or more computer servers 138 operative to support various tasks as described herein in connection with the management of communications with and control over the plurality of wind turbines. In some embodiments there is provided at least a first computer server and a second computer server. In other embodiments, a single computer server is used that is configured to support multiple software server entities programmed to provide the various tasks described herein.

[0046] In the first embodiment, network 1 10 is a private network such as a virtual private network, and network 1 12 is a public network such as the Internet. In various embodiments the computer server system 102 communicates with wind turbines (such as 104, 105, 106, 107, 108 and 109) over the private network 1 10 via a wired network connection or a plurality of network connections, some wired and some wireless. In various embodiments the computer server system 102 communicates with remote client devices (such as 1 14, 1 16, 1 1 8 and 120) over public network 1 12 via a wired network connection or a plurality of network connections, some wired and some wireless.

[0047] Referring to Figure 2, each computer server 138 includes one or more processors for executing instructions, memory for storing instructions and data, and an input/output interface (I/O) to provide the computer server a mechanism for interfacing with various devices. Each computer server is configurable to perform the applicable operations described herein by programming the applicable one or more processors. A processor may include one or more processing units. Memory is used to embody one or more computer programs or sets of computer-readable instructions for use with the processor. Memory may include random access memory (RAM), one or more storage devices, one or more computer readable media, or a combination thereof. The I/O interface includes a network interface such as a network interface card having an input/output for connection to the one or more networks, such as networks 1 12 and 1 14, and through which communications are conducted with wind turbines and client devices.

[0048] In the first embodiment, client device 1 14 is a laptop computer, client device 1 1 6 is a personal computer, client device 1 18 is a smartphone and client device 120 is a tablet such as an iPad. However, client devices 1 14, 1 16, 1 18 and 120 may be any form of personal computing device capable of connecting a user to a network including a workstation, a personal computer, a MacBook™, a Chromebook™, a tablet, a web book, a smartphone, a personal digital assistant, an internet set top box, personal video recorder ("PVR") or gaming system in communication with a television or display device, or any other computing device capable of connecting a user to a network and providing the user with a graphical user interface (such as, for example, a web browser or web enabled application) with which to send and receive data and instructions. Other such devices which may provide such an interface for a user may include a web-enabled wall or table or a web-enabled watch.

[0049] Referring to Figures 1 and 3, an illustrative embodiment of client device 1 14 is shown.

Other client devices, including client devices 1 16, 1 1 8 and 120, may be generally similar to client device 1 14. In the first embodiment, the first client device 1 14 includes a processor 1 14A, memory 1 14B, an input/output interface (I/O) 1 14C and a display 1 14D. The I/O interface includes a network interface such as a network interface card having an input/output for connection to the one or more networks, including network 1 12, and through which communications are conducted with the computer server system 102. In some embodiments the network interface enables a wired connection to network 1 12 but in other embodiments, the network interface may enable a wireless connection such as, by way of example, a Wi-Fi™, WiMax or cellular connection. Computer-readable instructions for directing the processor to carry out various functions are stored in the memory, which may include program memory.

[0050] In the first embodiment, client device 1 14 is configured to provide a user, via the computer server system 102, with a certain level of access to a wind turbine, certain wind turbine-related data associated with that wind turbine or both, based on a user profile associated with that user and stored and managed by the computer server system 102.

[0051] Referring to Figure 1 , wind turbines 104, 105, 106, 107, 108 and 109 each include one or more wind turbine controllers, such as controllers 104B, 105B, 106B, 107B, 108B and 109B, operative to communicate with the computer server system 102 and to communicate with sensors 104C, 105C, 106C, 1 07C, 108C and 109C on the applicable wind turbines. In response to instructions from the computer server system 102 or optional ly an authorized client device, controllers 104B, 105B, 106B, 107B, 108B and 109B are operative to change and control a plurality of settings and parameters that manage and control the state and operating condition of the applicable wind turbines. Sensors 104C, 105C, 106C, 107C, 108C and 109C are operative to detect one or more wind turbine state and operating conditions at various time intervals dependent on the one or more conditions being monitored by a particular sensor according to its sensor function. In various embodiments, each of wind turbines 104, 105, 106, 107, 108 and 109 include a large array of sensors for detecting hundreds of various conditions and states associated with the applicable wind turbines and controllers 104B, 105B, 106B, 107B, 108B and 109B are operative to monitor those various conditions and states and to control and change the state and condition of an applicable wind turbine according to one or more of the hundreds of conditions and states monitored.

[0052] Wind turbine-related data collected by the system 102 from the wind turbines may be stored and managed locally or remotely via a database or database system 1 34.

[0053] Access and Control Features

[0054] In the first embodiment there is provided a method of monitoring and controlling a plurality of wind turbines via a network wherein the plurality of wind turbines are represented by wind turbines 104, 105, 106, 107, 108 and 109 and the network is represented by networks 1 10 and 1 12. Different levels of access and control are permitted by the computer server system 102 with respect to the plurality of wind turbines for a variety of users amongst a variety of user groups. This provides a mechanism for managing what actions users are able to perform and what information they are able to see and manipulate in association the plurality of wind turbines.

[0055] With this method wind turbines are organized and managed by the computer server system 102 according to a plurality of access and control groups, with each of the access and control groups providing for a configurable level of access and control over one or more of the wind turbines associated with the applicable access and control group. In general, the computer server system 102 acts as an information management server or information management system which may be configured to provide different levels of access and control over individual wind turbines, over groups of wind turbines and over subgroups of such groups. Each access and control group corresponds to at least one wind turbine connected to system 102 via network 1 10 and in various embodiments one or more access and control groups may comprise tens or hundreds of wind turbines or more. In addition, users are assigned user profiles within the system 102, and through those user profiles may be assigned to one or more of the access and control groups. When a user profile is assigned to an access and control group, it is also assigned one or more levels of access and control to all wind turbines associated with such access and control group. The system 102 also supports the assignment of a user profi le directly to one or more wind turbines, in which case the user profile is assigned a configurable level of access and control to those one or more wind turbines to which the user profile is directly assigned. Data related to the various levels of access and control is also referred to herein as authorization data. This authorization data is stored and managed via a database or database system 136, which is in communication with and/or part of the computer server system 102.

[0056] Figures 4A to 4C provide, by way of example, illustrative tables that may be used in the first embodiment, wherein there are six wind turbines 160 (104, 105, 106, 107, 108 and 109 from Figure 1) accessible via system 102, four access and control groups 162 (Figure 4B - first, second, third and fourth turbine groups Gl , G2, G3 and G4) and six configurable levels of access and control 164 permitted amongst wind turbines that may be assigned to user profiles. In some embodiments only four or five configurable levels of access and control are provided. In other embodiments more than six configurable levels of access and control may be provided.

[0057] For the example shown, the six configurable levels of access and control 164 provide certain users with different levels of permitted access and control over a configurable number of wind turbines depending on the corresponding user profiles of those users as shown in Figure 4C. In this exemplary arrangement, the scope of authorization to access and/or control wind turbines, user profiles and permissions available to each six configurable levels of access and control are summarized in Table 1 below. Guest Monitor basic operational data related to a wind turbine; cannot control or make changes to the wind turbine; no permission control over groups or other user profiles

Observer Monitor detailed operational data related to a wind turbine; cannot control or make changes to the wind turbine; no permission control over groups or other user profiles

Operator Monitor detailed operational data related to a wind turbine; can stop/start turbine and acknowledge shutdowns or resume operation after transient faults, optionally may not make any other changes to the wind turbine or otherwise control wind turbine; optionally cannot make changes to any or select settings or parameters; no permission control over groups or other user profiles

Maintenance Same features as Operator plus the following additional features:

Can change maintenance functions and statistics for any wind turbines in a group (e.g. grid frequency expected by the turbine, the point at which the turbine shuts down due to high wind speeds; may also reset statistics, e.g. the number of times the turbine has connected to the grid or the number of times the brakes have been applied)

Admin (Tier 2) Has all the features of Maintenance, plus the fol lowing additional features:

Can access and control individual wind turbines in a group associated with this Admin;

Can change settings and parameters associated with the wind turbines in the associated group

Controls permissions on wind turbines up to and including Operator level

Controls permissions for the associated group up to and including Maintenance level

Admin (Tier 1) Full access to and control of wind turbines and user permissions across all access and control groups associated with this Admin

Table 1 [0058] A select user profile assigned a Guest level of permission for a select wind turbine in a select access and control group is authorized to monitor basic operational data generated by the select wind turbine (e.g. turbine identifier or ID, turbine operating status (generating/freewheeling/waiting for wind/shut down), turbine rotor RPM, wind speed, power being generated, energy produced, active fault conditions and various other wind turbine-related data), but cannot control or make changes to the configuration of the select wind turbine or its operation. An Observer level of permission for the select wind turbine provides the select user profile with all of the access and control permitted a Guest level of permission and additionally makes available further operational data which may be related, for example, to current grid operating conditions (voltage, frequency), current temperatures (inside the nacelle, outside the nacelle, generator, and gearbox oil), and/or statistics (occurrences of grid faults and excessive current shutdowns, number of times the brakes have been applied, number of times the turbine has connected to the grid). An Operator level of permission for the select wind turbine provides the select user profile with all of the access and control permitted an Observer level of permission and additionally permits a user with the authorized user profile to stop or start the select wind turbine and/or acknowledge shutdowns thereof via the system 102.

[0059] A Maintenance level of permission for the select wind turbine may provide the select user profile with all of the access and control permitted an Operator level of permission and may additionally permit a user with the select Maintenance level user profile to change maintenance- related functions and statistics (e.g. reset the number of braking events logged once the brake pads have been changed; change shutdown setpoints related to wind speed and temperature). An Admin (Tier Two) level of permission provides the select user profile with all of the access and control permitted a Maintenance level of permission and additionally permits a user with the Admin (Tier Two) level user profile to control which user profiles are permitted Guest, Observer or Operator level access and control (each a subordinate level of permission) to one or more particular wind turbines within the access and control group for which that user profile has an Admin (Tier Two) level of permission. This includes user profiles that were created outside of or independent of the access and control group over which the Admin (Tier Two) level user profile has administrative control (the "Admin (Tier Two) domain"). In various embodiments, the Admin (Tier Two) level user profile is also provided with the ability to create, modify and/or delete links associating all wind turbines within the same Admin (Tier Two) domain to any user profile having a level of permission of Guest, Observer, Operator or Maintenance. In some embodiments, specific user profiles assigned a level of permission by an Admin (Tier One) level user profile in association with one or more wind turbines within one or more access and control groups may be locked to prevent that level of permission for any such specific user profiles from being modified by an Admin (Tier Two) level user profile. In various embodiments, additional levels of Admin tiers may be provided.

[0060] In various embodiments wind turbines are grouped according to this method in order to provide a dealer-level group access and control over a subset of wind turbines for which only a select dealer is responsible for at a dealer level of operations. This is done by assigning a dealer with an Admin (Tier Two) level user profile associated with all wind turbines within the group of wind turbines for which the dealer is responsible. This has the advantage of enabling wind turbines across a wide range of owners, users and locations to be organized in a dealer-centric arrangement, so that wind turbines accessible via the system 102 can be managed and maintained according to dealers and their fleets of wind turbines.

[0061] Referring to Figures 1 , 5A and 7, there is shown in operation the method 200 of providing for multi-level access and control across a variety of different wind turbine groups and a plurality of different user groups via system 102. A plurality of wind turbines are assigned at block 202 by the system 102 to a plurality of access and control groups 170 via a first computer server (e.g. 138). As part of this block 202, a first set of wind turbines may be assigned to a first turbine group (Gl ) and a second set of wind turbines may be assigned to a second turbine group (G2), wherein the first turbine group comprises associations with one or more wind turbines different from the wind turbines associated with the second turbine group. In the example shown in connection with Figures 5A to 5C, further assignments are optionally provided for including a third set of wind turbines (in this case one turbine) which is assigned to a third turbine group (G3) and a fourth set of turbines which is assigned to a fourth turbine group (G4). At block 204 a plurality of user groups are associated via the system 1 02 with the plurality of access and control groups according to a plurality of user profiles managed via the first computer server 138, wherein each user within each plurality of user groups is assigned a user profile permitting a configurable level of access and control to one or more of the plurality of wind turbines. In connection with block 204, a first group of users is associated with the first turbine group, a second group of users is associated with the second turbine group and a third group of users may be associated with all or select subsets of both the first and second turbine groups. In addition, a first subset of users from amongst the first group of users is associated at block 204 with a different level of access and control to one or more of the first set of wind turbines as compared to a second subset of users from amongst the first group of users associated with the first turbine group. In various embodiments, when using four, five, six or more levels of access and control, many different users within a group of users (such as the first group of users) will have different levels of access and control assigned to their user profiles in connection with one or more wind turbines.

[0062] At block 206 the system 102 receives via the first computer server 138 a plurality of client device requests associated with the plurality of wind turbines from the plurality of client devices at varying time intervals. The system 102 determines a user-specific level of access and control over wind turbine resources for each of the plurality of client device requests based on which of the plurality of user profiles is associated with the plurality of client device requests. In various embodiments, wind turbine resources may include data and instructions for monitoring and controlling the wind turbine including turning a wind turbine on, shutting the wind turbine down, and monitoring and adjusting settings and parameters related to the operation of the wind turbine.

[0063] For each of the plurality of client devices associated with the client device requests, the system 102 provides at block 208 a select level of access and control to one or more of the plurality of wind turbines based upon and configured to an applicable user profile selected from the plurality of user profiles and associated with an applicable client device selected from the plurality of client devices. This may include at block 208 retrieving and transmitting to the applicable client device user-centric data and instructions responsive to a corresponding client device request selected from the plurality of client device requests. The user-centric data and instructions are configured to cause the applicable client device to display on a user interface only features of one or more of the plurality of wind turbines that are associated with the user- identified level of access and control available to the applicable user profile.

[0064] The use of a plurality of access and control groups in conjunction with various levels of access and control associated with user profiles are illustrated by way of example in Figures 5B, 5C and 6. In the example shown 172, 174, (a) Lindsay is a typical dealer and accordingly has the Admin (Tier Two) level of access and control assigned to her user profile for all wind turbines in the first turbine group; (b) Bob is a typical wind turbine owner, having the Observer level of access and control to only his wind turbine; (c) Sam is a special, multi-access user; he acts as maintenance staff for the first turbine group and therefore has been assigned the Maintenance level of level of access and control to his user profile for the first turbine group; he also has been contracted to keep watch over the wind turbine fleet of the second turbine group, and in this capacity he has been assigned the more limited Observer level of access and control to the second turbine group. In addition, in the example shown Sam has been given special permission to attempt to fix a problem identified with one wind turbine (T2) within the second turbine group, and for this purpose his user profile has been assigned the Operator level of access and control to the one wind turbine (T2) so that he can perform basic operations (e.g. start/stop) on the applicable wind turbine in an effort to see if he can fix the operation of that wind turbine. Sam can also clear transient faults; i.e. acknowledge that a grid fault condition occurred and start the applicable wind turbine if the grid fault condition has since resolved itself.

[0065] In addition to the list of users set out above, in the example shown 172, 174 in Figures 5B and 5C: (d) Peter is a maintenance worker with Maintenance level access and control to the second turbine group; (e) Paul is a user with Operator level authorization over wind turbines in the third turbine group (G3); (f) Mary is an executive with a company that owns a fleet of wind turbines making up the fourth turbine group (G4); George is a consultant assisting Mary's company and who has been provided with Observer level authorization to wind turbines in the fourth turbine group; and James is a maintenance worker who has been provided with Maintenance level authorization to wind turbines in each of the third and fourth turbine groups (G3, G4).

[0066] Referring to Figures 8 and 9, in various embodiments user profiles may be linked or associated 218 with a select level of access and control to one or more wind turbines by a wind turbine dealer or representative having an Admin (Tier Two) level user profile. In this example, the dealer accesses 220 through the system 102 a list of turbines accessible to the dealer under that dealer's Admin (Tier Two) level user profile from a client device. From the l ist of turbines, the dealer selects 222 a wind turbine and accesses a permissions list associated with the selected wind turbine. The permissions list for the selected wind turbine is retrieved 224 by the system 102 and a list of user profiles is displayed on the client device identifying which users have a level of access and control to the selected wind turbine and their respective level of access and control. The dealer may then request, via the system 102, the addition 226 of a new link associating the selected wind turbine to a user profile having a certain level of access and control or the removal 228 of one or more links between the selected wind turbine and existing user profiles that already have access and control to the selected wind turbine. A dealer may also cancel 229 an existing invitation to add a link associating a user profile with a wind turbine at a certain level of access and control. These requests are then processed via the computer server system 102. Where a new link to a user profile is to be added to the wind turbine, an email address associated with that user profile is retrieved 230 and an email invite is then sent 232 to that email address for acceptance so that the additional of the new link between the selected wind turbine and the applicable user profile can be confirmed 234. In some embodiments, when the user with the email address receives and opens the email invite, a link generated by the system 102 appears which, when clicked or otherwise activated 236, checks to see if the associated user profile is available 238 and if so, logs in 240 to the system 102 using that user profile to confirm that the user profile then has a new level of access and control over the selected wind turbine. If the associated user profile is not available 238 the user is prompted to create an account 241 for the associated user profi le. As illustrated in Figure 6, in various embodiments when a user is provided with both a higher level and lower level of access and control to a wind turbine group, the user authorization can be filtered according to the higher level of access and control available to that user where such higher level incorporates the range of access and control of the lower level authorization.

[0067] In various embodiments, user profiles may also be linked in a similar way by an Admin (Tier One) level user profile. In other embodiments, the level of access and control that may be permitted for user profiles by an Admin (Tier One) level user profile may be blocked in whole or in part so that the Admin (Tier Two) level user profile has more autonomous or semi- autonomous control over the applicable access and control group and the wind turbines associated therewith.

[0068] An exemplary set of user screens that may be displayed on a client device are shown for illustration purposes in Figures 10A, 10B, I OC, 10D, 10E, 10F and 1 0G.

[0069] User screens 242, 244 and 246 shown in Figures 1 0A, 1 0B and I OC represent illustrative forms of control screens for which authorized users having an appropriate level of access and control associated with an applicable wind turbine (in this example identified as "My Turbine") may view and control various control features associated with the applicable wind turbine and may change various settings and parameters related to the applicable wind turbine. For example, from these control screens, the applicable wind turbine may be started or shutdown (242A), the wind turbine configuration may be set (242B), a maintenance mode for the wind turbine may be activated (242C), various email configuration information may be set (244A), dealer VPN settings may be established (244B) and/or various temperature thresholds (246 A) may be set that may be associated with automatically shutting down the wind turbine and/or setting off alarms that may be communicated to one or more users via the system 1 02.

[0070] User screens 248 and 250 shown in Figures 1 0D and 10E represent illustrative forms of monitoring screens for which authorized users having an appropriate level of access and control associated with an applicable wind turbine may view various features associated with the applicable wind turbine, including its state, settings and condition. For example, from these monitoring screens, an authorized user may view energy production and consumption data (248A), data related to the turbine speed (248B), data related to wind conditions at the wind turbine site (248C), data related to power conditions (248D), data (250A) related to the temperature (of components of the wind turbine and/or the outside air), the availability of the wind turbine and/or a yaw system for the wind turbine, and/or data (250B) related to the braking system for the wind turbine, contractor cycles and/or shutdowns.

[0071] User screen 252 shown in Figure 10F represents an illustrative form of basic user screen by which authorized users may view basic information (252A, 252B) related to the power production and wind speed associated with the wind turbine, along with other general data relating to the state and operation of the wind turbine (252C).

[0072] User screen 254 shown in Figure 10G represents an illustrative form of administrative screen for which authorized users having an appropriate Admin level of access and control associated with a plurality of wind turbines may select and deselect (254A) one or more wind turbine groups so as to have easy access to the wind turbines related to the selected wind turbine groups in a list view (254C). With user screen 254 an authorized user may also select and deselect (254B) a variety of wind turbine states, which may be used to filter out which wind turbines from the groups selected in 254A are displayed in the list view 254C.

[0073] The users screens shown in the foregoing figures are meant to be displayed on a client device having a display footprint sufficient to allow a user to easily read the information displayed, for example via a personal computer, a laptop or a tablet. Smaller devices, such as smartphones and some small tablet-like devices, provide less visual area on which a graphical user interface may be displayed making it potentially challenging or impractical to display user screens formatted for a larger format display area.

[0074] Referring to Figure 1 1 A, 1 I B, 1 1 C, 1 I D and 1 I E, there are shown an exemplary set of user screens (256, 258, 260, 262, 264) associated with accessing and controlling information related to and features of one or more wind turbines, wherein the user screens are configured to be displayed on a small format client device such as a smartphone.

[0075] User screen 256 shown in Figure 1 1A represents an illustrative form of administrative screen for which an authorized user may view and have access to a plurality of wind turbines displayed in a list view (256A) for easy navigation. In this example, summary operational data relating to each wind turbine in the list may also be displayed in an overview format as illustrated.

[0076] User screen 258 represents an illustrative form of control screen displayed on a mobile client device for which authorized users having an appropriate level of access and control associated with an applicable wind turbine may view and control various control features associated with the applicable wind turbine and may change various settings and parameters related to the applicable wind turbine. In the example shown, the control screen is configured 258A to allow for control over starting and stopping a wind turbine and enabling a maintenance mode.

[0077] User screen 260 represents an illustrative form of screen displayed on the mobile client device with which an authorized user may monitor various operational data and conditions associated with an applicable wind turbine. In the example shown, the screen 260 displayed is configured 260A to present energy-related data as well as data related to wind conditions, turbine speed and turbine power. The exemplary screen 260 also displays an active alert 260B to the user indicating that there is an alarm condition on the applicable wind turbine, If the user selects the active alert notification 260B displayed, the user may be presented with more detailed notification information relating to the alarm condition. In various embodiments this notification information 262A may be displayed on an alarm screen 262 such as illustrated in Figure 1 ID, which by way of example identifies a yaw control problem with the applicable wind turbine.

[0078] User screen 264 represents an illustrative form of control screen displayed on the mobile client device through which an authorized user may view 264A yaw drive-related information for a wind turbine and control 264B the yaw drive for that wind turbine.

[0079] Referring to Figure 12, in yet other embodiments the system 282 (similar to system 102 in Figure 1 ) can be configured to support segregated access and control of a plurality of different and unrelated wind turbine fleets. For example, the system 282 can be configured to support a segregated level of access and control over two or more segregated and distinct wind turbine fleets which may comprise a first plurality of turbine groups and a second plurality of turbine groups, wherein the first plurality of turbine groups comprises at least two distinct wind turbine groups each associated with one or more wind turbines, and wherein the second plurality of turbine groups comprises at least two other distinct wind turbine groups each associated with one or more other wind turbines.

[0080] In the configuration shown in Figure 12, two separate private networks (290A and 290B) are managed by the computer server system 282 to communicate separately with the two different pluralities of turbine groups. In various embodiments two separate sets of databases are maintained via the system 282 for the respective pluralities of turbine groups. For the example shown for instance, a wind turbine-related data database 286A and an authorization database 286B are maintained for the first plural ity of turbine groups separately from a wind turbine-related data database 288A and an authorization database 288B that are maintained for the second plurality of turbine groups. Alternatively, instead of providing separate databases 286A, 286B, 288A, 288B, authorization and wind turbine-related data for the first and second pluralities of turbine groups could be stored in separate portions of the same database. Authorized users of one of the wind turbine fleets may be permitted access and/or control over applicable wind turbines within an applicable one of the segregated wind turbine fleets via system 282.

[0081] In a segregated access and control configuration, at least two Admin (Tier One) level user profiles are provided for, including a first Admin (Tier One) level user profile assigned to the first plurality of turbine groups and a second Admin (Tier One) level user profile assigned to the second plurality of turbine groups. In this case, the first Admin (Tier One) level user profile has top level access and control to only those wind turbines within the first plurality of turbine groups, and may only receive limited (if any) access and control to one or more wind turbines within the second plurality of turbine groups with the permission of the second Admin (Tier One) level user profile. Similarly, in this case the second Admin (Tier One) level user profile has top level access and control to only those wind turbines within the second plurality of turbine groups, and may only receive limited (if any) access and control to one or more wind turbines within the first plurality of turbine groups with the permission of the first Admin (Tier One) level user profile. Under this arrangement the system 102 supports, for example, the concurrent yet segmented access to and management of competing or different suppl iers of wind turbines, having optionally different types of wind turbines and corresponding operating conditions, with access and control over wind turbines organized according to different lines of dealers within each supplier group.

[0082] Segregated access and control allows the system 1 02 to support co-branding or rebranding of the system 102 so that the user interfaces and user experiences including the levels of access and control available to be assigned, can differ between separate fleets of wind turbines and/or between separate suppliers of wind turbines and their respective dealer groups.

In such arrangements, user interfaces can be configured to provide different combinations of display elements and levels of access and control as compared between the respective wind turbine fleets.

[0083] Additional Aspects and Features

[0084] The wind turbine management system 100 above can comprise a variety of aspects and features to further enhance functionality and flexibility for a multitude of users over access and control of a plurality of wind turbines, in addition to and/or apart from the various aspects and features described above. Furthermore, as with the aspects and features described above with reference to the earlier embodiments, each of the following aspects and features individually provides a beneficial enhancement and is a separate embodiment of the invention. These additional aspects and features are described below.

[0085] Custom User Interface Features

[0086] In various embodiments, a custom interface is provided for a plurality of wind turbines in networked communication with the computer server system 102. This allows for different user interfaces and user experiences to be presented to client devices based on which wind turbine fleet a user profile and/or a wind turbine is associated with. In such cases, a first set of user interfaces may be available to one or more of a first plurality of users or user groups associated with a first wind turbine fleet, and a second set of user interfaces may be available to one or more of a second plurality of users or user groups associated with a second wind turbine fleet different from the first wind turbine fleet. In various embodiments the first wind turbine fleet comprises a first plurality of wind turbine groups, with each such group comprising one or more wind turbines different from the other groups in the first plurality of wind turbine groups. In various embodiments, the second wind turbine fleet comprises a second plurality of wind turbine groups, with each such group comprising one or more wind turbines different from the other groups in the second plurality of wind turbine groups. [0087] In various embodiments, the system 102 can be used to cause the first set of user interfaces to provide a first set of authorized users with a set of features and functionality, including levels of access and control, configured to one or more groups of wind turbines within the first wind turbine fleet, and which may be further configured to a display format and level of access and control customized to one or more dealers and/or suppliers of wind turbines within the first wind turbine fleet. The system 102 can also be used to cause the second set of user interfaces to provide a second set of authorized users with a second set of features and functionality, including levels of access and control, configured to one or more groups of wind turbines within the second wind turbine fleet, and which may be further configured to a display format and level of access and control customized to one or more dealers and/or suppliers of wind turbines within the second wind turbine fleet.

[0088] In various embodiments, the system 102 can be adapted to provide a plurality of interface servers comprising a first interface server configured to support the management of access and control of the first wind turbine fleet through the first set of user interfaces and a second interface server configured to support the management of access and control of the second wind turbine fleet through the second set of user interfaces, with each of the plurality of interface servers having a respective unique network address for communication with the respective wind turbine fleet and/or with users of the respective wind turbine fleet. In operation, the system 102 may be configured to handle wind turbine resource requests forwarded from any of the plurality of interface servers and may furthermore process such wind turbine resource requests and provide custom access and control over one or more wind turbines within the wind turbine fleet for which an applicable one of the plurality of interface servers is configured to support.

[0089] For example, the computer server system 102, acting as a central server, may receive a resource request from one of the plurality of interface servers in communication with the central server, with the resource request including an originating network address associated with the interface server from which the resource request originated, wherein the interface server is associated with user interfaces configured for users of and/or wind turbines making up the first wind turbine fleet. In response to the resource request, the system 102 may be configured to identify a set of user interface instructions for a custom user interface selected from the first set of user interfaces and associated with the originating network address. Once identified, the set of user interface instructions may be transferred by the system 102 to a client device in communication with one or more wind turbines within the first wind turbine fleet, to enable the client device to display a custom graphical user interface based on the corresponding set of user interface instructions and to provide via that graphical user interface a custom level of access and control over the one or more wind turbines within the first wind turbine fleet, which custom level of access and control is adapted to the type and configuration of wind turbines making up the first wind turbine fleet. The system 102 may also receive a second resource request from another one of the plurality of interface servers (e.g. a second interface server), with the resource request including a second originating network address associated with the second interface server from which the second resource request originated, wherein the second interface server is associated with user interfaces configured for users of and/or wind turbines making up the second wind turbine fleet. In response to the second resource request, the system 102 may be configured to identify a second set of user interface instructions for a second custom user interface selected from the second set of user interfaces and associated with the second originating network address. Once identified, the second set of user interface instructions may be transferred by the system 102 to a second client device in communication with one or more wind turbines within the second wind turbine fleet, to enable the second client device to display a second custom graphical user interface based on the corresponding second set of user interface instructions and to provide via that graphical user interface a second custom level of access and control over the one or more wind turbines within the second wind turbine fleet, which second custom level of access and control is adapted to the type and configuration of wind turbines making up the second wind turbine fleet.

90] In various embodiments a custom interface or set of interfaces associated with a first wind turbine fleet may be identified or specified on a server in communication with the system 102 by a port to which client device requests are made, allowing for a custom form of user interface to be displayed for authorized users having access to one or more wind turbines in the first wind turbine fleet. In this arrangement, different portals or sites with different user interfaces and corresponding user experiences may be supported, wherein different IP addresses are associated with corresponding portals or sites so that the server may manage communications between client devices associated with one site and a set of wind turbines from the first turbine fleet separately from communications between client devices related to a second site and another set of wind turbines from a second wind turbine fleet. In this way, a first custom user interface may be displayed to users associated with the first wind turbine fleet, which interface is different from a second custom user interface that may be displayed to users associated with the second wind turbine fleet.

[0091] Client-Side Caching and Widget-Related Display Features

[0092] Referring to Figure 1 , it will be noted that within system 1 00 users monitor and control one or more wind turbines through graphical user interface ("GUI"), such as through a web browser, displayed on respective client devices. In various embodiments, the GUI is configured on a client device to make one or more screens available to a user through which the user can interact with one or more wind turbines via system 102 or, where authorized, directly with one or more wind turbines via network connection. Some users have limited levels of access and control to wind turbines (e.g. Guest or Observer levels of users) while other users by contrast have broader levels of access and control (e.g. Operator, Maintenance and Admin levels). However, in various cases, users of many or all types will have access of a variety of wind turbine-related data through a plurality of user screens accessible through and displayed via their web browsers on applicable client devices. The range of wind turbine-related data that may be presented to a user via one or more user screens on a web browser can be significant, and easily amount to tens or hundreds of pieces of wind turbine-related data or more. Furthermore, various forms of data can be very time sensitive whereas other forms of data may be less time sensitive or not time sensitive at all. While a web browser could be configured to make a multitude of client device requests from time to time to the system 102 for each individual piece of wind- related data associated with a wind turbine, this would result in a multitude of requests for the same information being made to the computer server system 102 which would occur multiple times and often many, many times. The problem becomes even more burdensome for the computer server system 102 and inefficient when one considers that the computer server system 102 could be hit with a multitude of such requests for redundant information again and again from many, most or all of the wind turbines connected to the computer server system 102.

[0093] Referring to Figure 13, the operation of the computer server system 102 can be enhanced through the implementation of a method 300 of caching wind turbine-related data on client devices. In accordance this feature, a client-side cache is used to store visual data and other information related to a multitude of settings and parameters for a wind turbine that a particular client device is connected to and/or from which the client device is receiving information via the computer server system 102. In various embodiments the caching method 300 makes use of software-based widgets 302 and widget controllers 304 available on or to the client device to aggregate data at certain time intervals so that client device requests for wind-turbine related data can be made to the system 102 as consolidated requests. In various embodiments the time interval may be about every 2 seconds. Alternatively, the time interval may be configurable and/or may be set for a shorter or longer time interval depending on how relatively real-time a refreshed version of the wind turbine-related data is to be presented to a user via a client device.

[0094] For the purposes of this client-side caching feature, a widget is a graphical display tool that is used to display via a web browser or other GU I certain information on the screen of the client device. Software controllers 304 are a data processing and calculation tool, configured to, through the client device, process various forms of wind turbine-related data and produce data that is presentable to a user on the user screen via widgets or to prepare data entered by widgets to be written to the turbine (e.g. removing extraneous commas from numbers). By way of example only, a software controller may take the fact that the power meter for a wind turbine is reading 800 kW and a flag saying power meter is invalid to then set power read to "— " for display. Software controllers can also populate flags used by widgets. For instance, a flag saying that someone has indicated that they are maintaining an applicable wind turbine can be aggregated into a flag saying the Turbine Start button should be disabled.

[0095] In various embodiments of method 300, a consolidated request is formed by aggregating wind turbine-related data across the currently visible screen or page and for historic widgets whether or not the screen for those historic widgets is currently displayed on the client device. Pieces of data of the same type that are needed by multiple screens are consolidated into a single request for the same type of data. The client-side cache 306 may also filter out requests for wind turbine-related data that is already known to the client-side session on the client device and which is not as yet stale or due for a refresh.

[0096] In this way, all of the requests for refreshed data needed by one or more of the user screens can be consolidated and sent to the computer server system 102 as a consolidated request, resulting in the system 102 receiving fewer but larger requests. Processing such consolidated requests is more efficient and on a relative basis results in a reduced burden on the system 102.

[0097] Referring to Figures 1 , 13 and 14, a widget refresh component 308 running on a client device finds, at predetermined intervals, all visible widgets 320 and all historic widgets 322 (i.e. widgets that don't exist on the screen or page that is currently open and displayed on the client device but that rely on trended data to remain current - for example graphs) available on a client device (e.g. 1 14) in association with the current user profile for the user logged into the system 102 through the client device. In various embodiments the widget refresh component 308 is a JavaScript or other programming script operating in cooperation with web browser of the client device. In various embodiments the widgets associated with a user profile are based on the level of access and control available to the current user profile. In the current example, the predetermined intervals are about every 2 seconds, although longer or shorter intervals may be used. The visible widgets and historic widgets are aggregated 324 in a list, and then for each such widget in the aggregated list the widget refresh component 308 checks 326 to see if that widget specifies any variables in need of data from one or more wind turbines. If the answer at 326 is NO, processing proceeds to 330, If the answer at 326 is YES, then the refresh component 308 appends 328 the variables identified at 326 to a list of variables to be refreshed before proceeding to 330. At 330 the refresh component 308 checks to see if the current widget being processed requires one or more widget controllers (304), and if the answer is YES each of the widget controllers are checked 332 for variables in need of data to be refreshed. Any such variables found at 332 are appended 334 to the list of variables to be refreshed. Once all controllers associated with the current widget under review have been checked for variables in this manner, the widget refresh component 308 proceeds to the next widget to check at 326, and processing continues in this way until all widgets in the aggregated list of widgets have been processed.

[0098] In various embodiments, whenever a user initiates a client device request through the client device for wind turbine-related data, the widget refresh component 308 may be invoked to generate an aggregated list of widgets from which to generate an aggregated list of variables in need of refreshed data, in the manner described above, if the client device request is initiated between the predetermined interval (e.g. in less than 2 seconds from when the interval last occurred). In other embodiments, the client device request may not trigger the processing described above, and instead the widget refresh component 308 will rely upon the last aggregated list of variables identified as being in need of refreshed data as was last generated by the refresh component 308 at the rollover of the last predetermined interval.

[0099] Once a client device request is initiated seeking wind turbine-related data from the computer server system 102 and the widget refresh component 308 has generated or retrieved (as the case may be) an aggregated list of variables identified as being in need of refreshed data, the refresh component 308 may check 336 with the client-side cache 306 to filter out any of the variables in the list concerning one or more pieces of data that are already known to the client- side cache 306 and which are not as yet stale or due for a refresh. If after this filtering process 336 there remain one or more variables in the aggregated list of variables, the widget refresh component 3 10 initiates sending 338 the client device request to the computer server system 102, which retrieves and returns to the client device the necessary pieces of wind turbine-related data from a server-side cache if available and not stale or from the applicable wind turbine. Otherwise, the refresh component 310 proceeds to a data refresh stage 380 (Figure 17) in which the information presented on the screens available through the web browser are refreshed locally based on the wind turbine-related data stored in the client-side cache 306. In various embodiments, this includes having widgets are refreshed locally based on the wind turbine- related data stored in the client-side cache 306.

[00100] Referring to Figure 16, the computer server system 102 receives and processes 340 client device requests for refreshed data such as the one described above. Such client requests include a payload identifying a consolidated list of variables for which refreshed data is needed. In various embodiments, the system 102 checks 342 to see if an applicable client device request has been made by an authorized user before al lowing the request to be processed. For each client device request that is processed, the system 102 may check 344 each variable in the consolidated list of variables to see if that variable has fresh data currently available from a server-side cache to which the system 102 may be in communication, and if it does, then that fresh data is retrieved from the server-side cache and appended 346 to a list of fresh data to be returned to the client device from which the client device request originated. Any of the variables in the consolidated list of variables that does not have fresh data currently available from the server-side cache is appended 348 to a list of variables to be updated (also referred to as a "refresh update list") through a server-initiated request 362 to be made by the computer server system 102 to the applicable wind turbine. Where a server-side cache is used in this manner, the refresh update list is generated until all variables in the consolidated list of variables from the client device request have been processed 350. Where a server-side cache is not used in this manner, the refresh update list may represent the consolidated list of variables.

[00101] If the refresh update list is not empty 352 then the system 1 02 checks 354 to see if there is an outstanding request to the applicable wind turbine in need of processing, and if the answer is NO, and there are no other requests already waiting 358 to write to the applicable wind turbine, then the refresh update list is cleared (approved) 360 by the system 1 02 to be the next request to be sent to the applicable wind turbine for processing 362. For example, in some embodiments a flag may be set at 360 indicating that a read request should proceed to be sent to the applicable wind turbine to retrieve the data associated with the refresh update list. On the other hand, if the system 102 determines that there is at least one outstanding request to the wind turbine at 354 or there is a write request to the applicable wind turbine that is pending at 358, then the system initiates a delay before approving the refresh update list as the next request to be sent to the applicable wind turbine. This provides an opportunity for read requests and write requests that are already outstanding to be processed before a request is sent to the applicable wind turbine to update the current refresh update list. In various embodiments the delay introduced at 356 may be a random delay, while in other embodiments the delay may be a predetermined time period sufficient to provide enough of a delay that notionally a certain number of outstanding read requests and/or write requests can be processed by the applicable wind turbine.

[00102] When a request for data for the refresh update list is sent to the applicable wind turbine, the request is processed and each variable in the list is populated 368 with the corresponding fresh data retrieved from the wind turbine and the resulting refreshed data is appended to a list to be returned to the system 102. Once this refresh process is complete, the refreshed data collected is sent 370 to the computer server system 102 and the wind turbine is released from handling the current refresh request and is allowed to handle new requests from the server (whether read or write requests) or in some embodiments from direct client device requests made by users with sufficient authorization to make such direct requests according to their user profile (e.g. an Admin (Tier One) level user profile).

[00103] Referring to Figure 17, the widget refresh process 380 on the client device is shown.

When the computer server system 102 responds 381 to the client device request with refreshed data collected from the wind turbine, the refreshed data received by the client device is populated 382 by the widget refresh component 308 in the client-side cache 306 for quick retrieval. When the refresh process 380 is initiated 384 the wind turbine-related data stored in the client-side cache 306 is collected, including both existing, unrefreshed data that was already in the cache 306 and the refreshed data that was received from the server system 102 to populate or repopulate applicable portions of the cache 306. As part of the refresh process 380 the widget refresh component 308 finds all visible widgets 385 and all historic widgets 386 available on the client device in association with the current user profile for the user logged into the system 102 through that client device. The visible widgets and historic widgets are aggregated 387 in a list, and then for each such widget in the aggregated list the widget refresh component 308 checks 388 to see if that widget requires one or more widget controllers (304). If the answer is YES then each of the widget controllers are checked 389 to see if they require further widget controllers and if the answer is YES then the process sorts 390 through the applicable widget controllers until process-independent widget controllers are processed first. Once the widget controllers associated with a widget are sorted in this way, then for each such widget controller the variables containing the refresh data needed by the applicable widget controller are passed 391 to that widget controller and the widget controller is refreshed 392. This process repeats 393 for each widget controller that an applicable widget requires, until all such widget controllers are refreshed with applicable wind turbine-related data. Once the applicable wind turbine-related data is processed by such widget controllers, the processed data is then passed 394 to the applicable widget 302 by the widget refresh component 308. This process repeats 396 for each widget that needs to be processed with updated/refreshed wind turbine-related data.

[00104] For illustration purposes, Figure 18 shows an exemplary control screen displayed to a user on a client device via a web browser, which screen has been marked with references identifying a variety of widgets that provide graphical features in association with the exemplary control screen. In conjunction with this example, Figure 19 shows an enumerated table identifying the function or role of the various widgets displayed on the control screen in Figure 18.

[00105] Logging Features

[00106] In various embodiments information that was read from or written to any of the wind turbines accessible within the system 100 is logged for later review, tracking and maintenance activities. In various circumstances, users with a Maintenance level of access and control may also view such logged information, including the user profiles involved in initiating the read and/or write activities on the wind turbines. The information may be logged by the computer server system 102 using database 134 or 136, the applicable wind turbine(s) or both. In various embodiments, the computer server system 102 may aggregate and store information about network usage including information with respect to page views, user location, user activities over time and the like.

[00107] Server System Architecture Features [00108] Figure 20 illustrates an example of a server system architecture 400 that may be used in some embodiments of the invention to implement various aspects of the invention. It wi ll be appreciated that the server system depicted in Figure 20 is shown in simplified form, without showing the entire operating environment, and omitting certain supporting elements that will be described below in connection with Figure 21 including a content distribution network (CDN) for unrestricted media, a restricted media store for storing private data, an authorization database and/or a turbine data database, for example.

[00109] In embodiments such as the one shown in Figure 20, the server system 102 may include a backend server 490, at least one load balancing server 402, 403 and a plurality of front-end servers 410, 412, 414. The server system 102 may further include a VPN server 460. The aforesaid servers may be dedicated hardware servers or servers implemented by software, for example, virtual servers, interconnected by a dedicated or shared network. In some embodiments, one or more of the aforesaid servers may be consolidated onto a single physical piece of server hardware.

[00110] In general, each server is in communication with at least one memory storing computer readable instructions operable to direct a processor to perform the functionality of the respective server, as described herein. When used in a server, a processor may include one or more processing units and may comprise a microprocessor or another suitable processor circuit. For other devices, a processor may include, for example, a processor circuit, a microprocessor, a microcontroller, a programmable logic controller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), and/or a circuit operable to perform the functionality described herein. The memory may include RAM, DRAM, flash memory, a network accessible database, and/or one or more optical or hard disk drives, for example. The processor is operable to read the instructions from the memory, to read or write data values to and from the at least one memory, and to conduct I/O operations to I/O ports of the server. The I/O ports may include physical or virtual ports for connecting a keyboard, a display, memory or other storage device, and/or for providing a network connection for the server, for example.

[00111] Figure 21 gives a high-level schematic view of a number of the information flows that may be present in one exemplary system architecture used in some embodiments. Figure 21 shows the server system 102 in its operating environment 500, which may include, for example, a plurality of client devices such as desktop or laptop computers, or mobile Internet devices such as smart phones. The client devices are operable to make requests to read turbine system data from the front-end nodes 502 (e.g., front end servers 410 and 412), and to exercise control over the turbine systems 104, 106, 108 by issuing control commands to the turbine systems or writing values to control registers of individual turbines, for example. Client devices 1 14, 1 16 in such an embodiment have direct access to at least one load balancer 402, 403 and a content distribution network (CDN) for quickly distributing static content such as generic CSS, JavaScript, and image files.

[00112] If a client device 1 14 is making an initial request for service, the front-end nodes 410 will communicate with the client device and the authorization database 136 to authenticate the client device and determine whether the client device is permitted to access the system 400. In some embodiments, the front-end server nodes 1 14 will cause a login and password webpage to be displayed on the client device, or will redirect the client device to an authentication server capable of accepting login credentials. If the user of the client device enters a valid login identifier and password, the client device is thereafter permitted to have at least some of its read and write requests handled in accordance with the set of permissions (or level of authorization) associated with the client identifier. The authorization database may associate each client identifier, directly or indirectly, with various sets of permissions (e.g., authorization levels) specifying which turbine systems 104, 106, 108 are visible or accessible to the client, the turbine-specific data or control features that are visible or accessible to the client, and the nature and extent of the operations (e.g., read-only, or read and write access) that are permissible for the client, for each respective turbine system.

[00113] Read and write requests from client devices are initially passed to a load balancer device 402, which decides which one of a plurality of front-end server nodes will handle the request. The load balancer 402 distributes service requests among the front-end server nodes according to predetermined algorithm, for example, a round robin distribution of requests to respective front-end nodes, or alternatively, may rely on information received regarding the level of load being experienced by the front-end nodes, to determine a least used or least loaded front-end node available to handle the request. In some systems, there may be a plurality of load balancers 402, 403 in order to provide customized display functionality to the client devices.

[00114] The front-end server nodes are configured to determine which load balancer device 402, 403 is making a service request, Based on this information, the front-end server nodes are operable to decide which set of display elements should be presented to the client device. The selected set of display elements is associated with a respective visual theme. In effect, the load balancer 402 is operable to decide which visual theme, selected from a plurality of visual themes, should be presented to the client device for display via a graphical user interface (GUI). For example, front-end servers 410, 412, 414 may present a first set of display elements representing a first visual theme to a client device which was authenticated by a server at a first network address, whereas the same front-end servers 410, 412, 414 may present a second set of display elements, presenting a distinct second visual theme to the client device if the client device was authenticated by a server at a second network address. The front-end nodes may identify the originating load balancer 402 for the request by an identifier sent from the load balancer 402, for example, a port identifier uniquely identifying each load balancer 402.

[00115] By sending a read request to the load balancer 402, a client device may request from the server system a webpage including display elements optional ly based on a combination of unrestricted media (unprotected information) and restricted media (proprietary or protected information). Examples of unrestricted media include certain images, JavaScript code, and cascading stylesheets (CSS). Unrestricted media files are often generic therefore they require no protection from unauthorized access; in addition, they are typically static in nature and therefore should be loaded as quickly as possible. In some embodiments, a content distribution network (CDN) is used to distribute the unrestricted media as quickly as possible to client devices, wherein the CDN may comprise a plurality of servers distributed geographically. In various embodiments, client devices can directly request unrestricted media files from the content distribution network without any further authentication or authorization. The provision of dedicated CDN servers for retrieving and providing static content to client devices allows this task to be offloaded from specialized web servers in the web server system (e.g., intermediate dynamic-content web server or web servers, such as a dynamic content web server or web servers that are running in association with the turbine system) to free up the processing power and bandwidth of those other servers for more necessary tasks.

[00116] On the other hand, some information requested on the webpage needs to be protected from unauthorized access, for example, because it is customized or proprietary (e.g., photographs of a particular turbine) and/or because it takes significant computing resources to produce (e.g., dynamic data such as aggregated historical data). Consequently, requests for restricted media are handled by the front-end server nodes, which act as the server for restricted media files and provide them to the client device if the client devices are authorized. Client devices are typically unable to directly access restricted media. [00117] The front-end servers 410, 412, 414 also are configured to retrieve any parameters read from any the plurality of turbine systems and to log or store them in at least one database of turbine-related data such as the database 1 34. The front-end servers communicate with turbines through the VPN concentrator 464, which may have read and write access to an entire fleet of turbines (e.g., 104, 106, 108). Referring back to Figure 20, these and other components of the system will now be described in greater detail.

[00118] Load Balancer 402

[00119] The load balancer 402 is operable to communicate over a public network 1 12 in Figure 1 such as the Internet to a plurality of client devices 1 14, 1 16, 1 1 8 and to respond to requests made from the client devices. The load balancer 402 may include a load-balancing process 404 for apportioning incoming client requests among the plurality of front-end servers 410, 412, 414 in a manner that optimally uses computing resources available in view of the operational state of each front-end server. The load balancer 402 may further include a monitor process 406 for monitoring the health of the front-end servers. In some embodiments, the load balancer 402 may send control packets to the front-end servers 410, 412, 414, and wait for a response.

[00120] In response to detecting that at least one front-end server 41 0 is not operational or is in an improper operational state, the load balancer 402 may remove the unhealthy front-end server from its rotation until the problem has been resolved (e.g., by the back-end server 490 rebooting or restarting certain processes on the unhealthy front-end server or following manual intervention such as power cycling). In other words, service requests from client devices are no longer forwarded to the unhealthy front-end server 410 while it is removed from the load balancer's rotation list. The load balancer 402 continues to poll the front-end server 410 until it detects that the health of the front-end server 410 has been restored and that its operational status is satisfactory, whereupon the load balancer 402 will put the front-end server back into rotation to receive and service further client device requests.

[00121] Figure 23 provides an example of an algorithm that could be used by a monitor process 406 running on the load balancer 402, as shown generally at 600. In this embodiment, the monitor 406 initiates a health check of the front end server 410 every T seconds (e.g., T=10 or another suitable value), as shown at 602. The method involves initiating an HTTP request to the front end server node at issue (604) and waiting for the server response (606). If no response is received after a predetermined time period (e.g., 10 seconds) or a response is returned indicating that the front end node is unhealthy, then the monitor increments a variable representing a count of fails (608). The variable is checked to see whether it exceeds a predetermined threshold (610). If not, then the monitor 406 will proceed to initiate another health check request in due course (602). However, if it is determined at block 610 that the front end server 410 has failed too many times, then the front end server 410 is removed from the load balancer rotation (612). As a further option, at block 606, the monitor 406 may receive a response indicating that the front end server being queried is in fact healthy, in which case, the monitor 406 marks the front- end server as being healthy by setting the variable representing the consecutive number of failed health checks to zero (614). If the node was out of rotation (616), it is placed back into rotation (618). Subsequent health checks 602 will then be conducted in due course (602). In one embodiment, the load balancer 402 attempts twice to connect to the front-end server 410 with an HTTP request, however, if there is no response within a predetermined period of time (e.g., 10 seconds), the load balancer assumes that the front-end server has malfunctioned and marks its records accordingly. These records are exposed to the backend server 490 to allow the backend server to undertake healing actions when a front-end node has failed.

[00122] In some embodiments, as will be described below in detail, the front-end servers 410, 412, 414 may be configured to maintain a VPN connection to the VPN server 460. In such a scenario, in addition to confirming that the front-end server 410, 412, 414 is operational and that all necessary processes (e.g., Web server and reverse proxy 420, a dynamic content web server 430, etc.) are running correctly, the monitor 406 of the load balancer 400 may in addition be configured to poll each front-end server regarding whether that front-end server has a val id VPN connection to the VPN server 460. If the monitor 406 finds that a particular front-end server does not have a valid VPN connection, it marks that front-end server as being in an unhealthy state and removes it from rotation, such that the unhealthy front-end server is no longer forwarded service requests from client devices until its VPN connection is restored.

[00123] The server system 102 may include more than one load balancer. For example, first and second load balancers 402, 403 may be configured to serve first and second sets of client computers associated with different respective turbine networks, and may be tailored to provide different functionality and different visual features (e.g., custom logos and display pages) to the different turbine networks. For example, at least one server in the system 400, such as the load balancer 402 or front end server 410 may detect the identity of the client computer that is making a request and thus infer the target turbine network that it is attempting to access. Alternatively, at least one server in the system 400, such as the load balancer 402 or front end server 410, may provide different functionality and different visual features to client devices making requests based on the types of wind turbines to which the requests relate. For example, a first functionality and first set visual features may be served to a client device making a request relating to a first type of wind turbine, and a second functionality and second set visual features may be served to a client device making a request relating to a second type of wind turbine. Alternatively, an authentication server which accepts and verifies login credentials (e.g., a login identifier and password) from a client device may be configured to assign the client device, for future transactions, to a particular load balancer associated with a particular turbine network associated with those login credentials. In some embodiments, the turbine network may be identified by the address of the login or authentication server that is accessed by the client computer.

[00124] Once the system has identified which turbine network is being accessed, the client device is configured to communicate with the load balancer 402, 403 associated with the target turbine network. The load balancer is configured to connect to a port of the front-end servers 410, 412, 414 corresponding to the target turbine network to provide functionality, including custom displays and controls, associated with the target turbine network to the client device throughout the session. In other words, the front-end server 410 may provide different functionality and/or a different set of display elements or "skins" to the client device depending on which port the load balancer 402 uses to connect to the front-end server, wherein the functionality or display elements are appropriate to the turbine network being accessed by the client device.

[00125] Front-end Server 410

[00126] Referring to Figure 20, the front-end server 410 in some embodiments may include a Web server and reverse proxy 420, a web server for generating dynamic content (i.e., a dynamic content web server) such as a web server gateway interface (WSGI) server 430, a storage module 440, a process control system or supervisor 450, as well as other supportive processes 452.

[00127] The Web server 420 may include a server process such as NGI X operable to maintain a plurality of proxy connections with client devices over a public network 1 12 such as the Internet. The Web server 420 acts as gatekeeper and passes on only relevant client requests to the Web server 430. The Web server 420 may be configured to automatically provide static elements to client devices 1 14, 1 16 by itself or in conjunction with a content distribution network (CDN 504 in Figure 21 ), in order to offload such functionality from the Web server 430 and the turbines 104, 106, 108. The turbine systems, in particular, stand to benefit from the diminished amount of processing and bandwidth necessary to transmit purely data over the VPN tunnels, as opposed to say, data combined with display elements, since the processing power of their respective processors (e.g., PLC 472) and the bandwidth of their respective network connections (474) may be quite constrained. In a worst case scenario, overloading a turbine system with excessive computational or data traffic requests could cause the turbine system to crash, which could lead to negative consequences for the control and operation of the turbine as a whole, possibly even causing physical damage.

[00128] The accessibility of the Web server 420 to client devices 1 14, 1 16 communicating over the public network 1 12 either through the load balancer 402, or in some embodiments, directly from the client devices 1 14, 1 16, is in stark contrast to the non-accessibility of the Web server 430, and thus the Web server 420 is configured to act as a gatekeeper of connections with clients to provide increased security for the private Web server 430.

[00129] The Web server 430 may be configured to generate dynamic content that is relatively time-consuming to produce and/or requires access to restricted media (508 in Figure 21 ) available only to authorized clients. In one embodiment, the Web server 430 may include a Python interpreter such as a GUnicorn process in support of a Django configuration framework, however, it will be appreciated that other frameworks can be utilized to implement the functionality described herein.

[00130] The front-end server 410 also includes a process control system (e.g., supervisor) 450 operable to start all the processes that are configured to run on the front-end server 410 (e.g., NGINX, GUnicorn, Redis, and in some embodiments, an IKE daemon).

[00131] In the illustrated embodiment, the front-end servers 410, 412, 414 may have unlimited access to read/write all parameters to all turbine systems (e.g., 104, 106, 108) on the network, or only a subset of the read/write parameters may be exposed to the front-end servers. While only a single front-end server may be used in some embodiments, providing a plurality of front-end servers 410, 412, 414 enables the handling of greater network loads with lower latency and/or increased reliability due to fai lsafe mechanisms.

[00132] In some embodiments, the front-end server 410 may create and maintain a VPN connection to the VPN server 460, including the VPN concentrator 464. In one embodiment, the VPN connections may be implemented by a background IKE daemon 452 which forms IKE connection (IKEC) processes as necessary to create VPN tunnels. Such an embodiment may also include a VPN monitor process 452 for monitoring the status of the VPN connection to the VPN concentrator 464. In some embodiments, the front-end server 410 may use a script or process 452 to implement healing functions. For example, in embodiments where the front-end server 410 maintains a VPN connection to the VPN server 460, the front-end server 410 can periodically ping the VPN concentrator 464 to see if it is available. If it is not available, then the front-end server 410 may be configured to kill and restart all processes associated with the VPN connection to re-establish a valid VPN tunnel to the VPN server 460. However, if the VPN monitor process 452 has malfunctioned, intervention of the backend server 492 will be needed to restart the relevant processes on the front-end server 410 to re-establish the VPN connection.

[00133] VPN Server 460

[00134] The VPN server 460 may include proxy and VPN concentrator functionality that may be implemented with either software or dedicated hardware or other hardware. For example, the VPN concentrator 464 may be a software-based concentrator such as Charon-based strongSwan running on a programmable server, or alternatively, the VPN concentrator 464 may be a feature of a hardware-based VPN server 460.

[00135] In some embodiments, the VPN concentrator 464 is configured to act as a master to conduct packet forwarding to the turbine systems (e.g., 104, 106, 108), which act as slaves. The ability to create a plurality of VPN tunnels or connections to the turbines is advantageous in situations where the turbines being monitored and controlled are distributed geographically such that it becomes necessary to piggyback turbine communications over existing public networks (especially if some of the turbines are located in remote areas).

[00136] Special VPN Connections

[00137] Referring to Figures 20 and 22, in some embodiments, the system 400 may be configured to allow client devices 524 belonging to system management staff and client devices located at the system management office (534, 536) to connect to the private network 468 remotely, to provide special access to the turbines in ways that are not permitted by the front end server 410 (e.g., via code debuggers). For example, the client devices 524 and 534 may connect over a public network to the Web server and reverse proxy 462 through a custom external access point 480 providing a hook for such client devices to exercise custom control functions and to access additional data from the turbine systems 104, 106, and 108. In particular, such a custom access point 480 allows the connecting client devices to avoid reading cached data from the front-end server cache 440, but rather, to receive up-to-date raw turbine data on demand. A further level of external access may be provided through an advanced external VPN access point 482, which provides a hook directly into the VPN concentrator 464. The VPN access point 482 requires that the client device be configured to use the VPN connections made available by the VPN concentrator 464. Advantageously, this method of connection is not limited by the subset of data and control features exposed by the Web server and reverse proxy 462, and thus the client device may have hundreds of additional data items and control functions available to them that otherwise would not be available if they connected to the turbine via the VPN server 460 or the front-end server ("FES") 410. For example, a connection made through the access point 482 may use a protocol native to the turbine system with which communication is being established, which may provide more powerful functional ity than conventional HTTP requests made from a client device.

[00138] Secure Connection between FES and VPNC

[00139] If the server system 102 is implemented over a distributed geographic area or utilizes shared computing resources such as cloud computing, this may create concerns regarding the integrity and security of communications between certain server system components, for example, communications between the front-end server 410 and the VPN server 460. Accordingly, the VPN concentrator 464 may have an authenticated, secure channel to the front- end servers 410, 412, 414. In some embodiments, the VPN concentrator 464 maintains at least one VPN tunnel to the front-end server nodes 410, 412, 414. In other embodiments, a different type of secure connection may be established between the front-end servers 410, 412, 414 and their VPN concentrator 464. For example, an authenticated HTTPS reverse proxy connection 454 using SSL encryption between the front-end servers 410, 412, 414 and the VPN concentrator 464 obviates the need to maintain a VPN tunnel between these entities. In still other embodiments, however, where the front-end servers 410, 412, 414 and VPN concentrator 464 have a dedicated (unshared) connection impervious to eavesdropping, the front-end servers 410, 412, 414 may communicate with the VPN concentrator 464 without any security measures such as authentication or encryption.

[00140] Figure 22 also illustrates the HTTPS proxy connection between the front-end nodes 502 and the VPN concentrator 464, shown generally at 526.

[00141] Backend Server [00142] The backend server 490 may include a storage module 440 for storing data, a monitor module 492 for monitoring the operational status and health of the front-end servers 410, 412, 414, and a healing module 494 for automatic healing of unhealthy front-end server nodes. The monitoring module 490 and healing module 494 may be implemented by respective processes running on the back-end server 490 or may be both consolidated into a single process 492, 494. In some embodiments, the monitor and healing process 492, 494 may be configured to monitor the health of the front-end node servers 410, 412, 414 to provide healing functionality thereto if the health of a front-end server node deteriorates. In this case, the monitoring and healing process 492, 494 may be configured to automatically restart certain processes on the front-end servers 410, 412, 414 that have crashed to return an unhealthy front-end server 410 to a desired operational state (e.g., one in which failed VPN tunnels are re-established by the front-end server). For example, the backend server 490 may use remote access to reconfigure and restore the front-end server to the desired operational status by rebooting or restarting any malfunctioning processes, such as the Web server and reverse proxy 420, the dynamic content webserver (e.g., a WSGI web server) 430, the storage module 440, etc., and/or the VPN communication processes (e.g., IKE Daemon and IKE connectors 452, if present). The backend server 490 may also optionally include other processes to support the functionality of the server system 102, for example, asynchronous tasks such as the nightly or on-demand parsing of turbine data.

[00143] Periodically or at predetermined times, the back-end server 490 may poll each load balancer 402, 403 to determine whether the load balancer has discovered that certain front-end servers 410, 412, 414 associated with the load balancer are unhealthy. In particular, the monitor and healing process 492, 494 may be configured to monitor the load balancer 402 to determine if the load balancer has marked any of the front-end servers 410, 412, 414 as having an unhealthy operational state. A front-end server is considered unhealthy if the front-end server is inoperative, or if a critical piece of software on the front-end server (such as the Web servers 420, 430) is not responsive to service requests, or in some embodiments, if the front-end server 410 lacks a mandatory VPN connection to the VPN server 460.

[00144] In response to detecting that the load balancer 402 has marked a particular front-end server as being in an unhealthy operational state or even as being inoperative, the back-end server 490 attempts to cause the front-end server in question to be rebooted or restarts certain processes on the front-end server for which a malfunction has been indicated by the load balancer 402. For example, if a web server (420 or 430) running on the front-end server is not working correctly, the process or processes associated with that web server can be restarted. In some embodiments, where the front-end server 410 has lost a VPN tunnel, the back-end server 490 causes the appropriate processes (e.g., IKE Daemon 452) on the front-end server 410 to re- establish and maintain the lost VPN tunnel, by using remote access into the front-end server to restart these processes. In some embodiments, the back-end server 490 may pol l each front-end server directly to determine its state of health (e.g., by sending status requests to the public Web server and reverse proxy 420), rather than relying on the monitoring done by the load balancer 402.

[00145] The storage module 440 of the backend server 490 may include a database management system (DBMS) and/or a key-value store. A process running on the back-end server 490, for example, Redis, may implement the key value store 440. The DBMS or key-value store 440 can be used to store temporary variables, turbine data and control parameters, and in some embodiments, may be used to implement a master cache that is ultimately distributed to and replicated in each of the front-end servers 410, 412, 414.

[00146] Secure Connection Between FES and VPNC

[00147] In one embodiment, the load balancer 402 and the front-end servers 410, 412, 414 cooperate to ensure that a secure VPN tunnel is maintained to the VPN concentrator 464. If it is detected that the VPN tunnel between the front-end server 41 0 and the VPN server 460 has failed, a self-healing process is initiated to restore the VPN connection. From time to time, the front-end servers 410, 412, 414 are configured to check whether the VPN tunnel is up and running. The load balancer 402 includes a health monitor process which pings the front-end servers 410, 412, 414 periodically to request a report as to whether the front-end server has an active VPN tunnel to the VPN concentrator 464.

[00148] In this embodiment, the front-end server is tasked with maintaining persistent VPN connections to the VPN server and concentrator, however, this task necessitates that the front- end server be configured to heal failed VPN connections, for example, by restarting VPN-related processes. For example, a VPN connection could fail if the underlying public network over which the VPN tunnel is unreliable. In addition, it may be necessary to re-key the VPN tunnel connection from time to time, which may mean that a particular VPN connection maintained by the front-end server is forced to go down until a new key is generated and the VPN tunnel is reconnected based on the new key. The rekeying process could take some time during which the front-end server would not be able to connect to the turbines. However, maintaining such VPN connections in the front-end servers requires memory and processing power to be diverted from the other functions of these servers.

[00149] An Alternative Secure Connection between FES and VPNC

[00150] In an alternative embodiment, a secure connection is maintained between the front-end server 410 and the VPN server 460 and concentrator 464, not in the form of a persistent or static VPN tunnel maintained by the front-end server, but rather, in the form of a secure connection that is dynamically created on-demand for each transaction. In some embodiments, an HTTPS request 454 encrypted with SSL is sent from the front-end server 410 to the reverse proxy process 462 running on the VPN server 460. In such embodiments, the secure connection is less affected by unreliable public networks as a secure tunnel is created on demand for each HTTPS request 454 but need not be maintained for subsequent requests or transactions. In some embodiments, some processes 466 on the reverse proxy 462 on the VPN server 460 may implement another level of caching of data, in addition to the level of caching provided in the front end 410 and back end 440 servers, as described herein.

[00151] In some embodiments, the front-end server 410 may be operable to store, retrieve and/or to calculate the network address of the VPN concentrator 464, the network address of the target turbine system 104, and/or the network address of a particular target variable or control register on the turbine system 104. One or more of the aforesaid network addresses may include an IP address. In a reverse proxy server context, these network addresses may be concatenated together to form a hierarchical system network address (e.g., in the form of a uniform resource identifier or URL) for the particular data or control register of the turbine system 104, as follows:

[00152] HTTPS://address of vpnc/address of turbine/address of register.

[00153] Once the HTTPS request using secure socket layer encryption is received by the Web server and reverse proxy 462 running on the VPN server 460, the reverse proxy 462 forwards the request to an appropriate port on the VPN concentrator 464 in the form of an HTTP request. Assuming that the connection between the reverse proxy 462 and the VPN concentrator 464 is a dedicated connection or otherwise is considered secure, it may not be necessary to use SSL encryption for the latter request, which may take the form of the following network address (i.e., uniform resource identifier):

[00154] HTTP://address_of_turbine/address_of_register. [00155] The HTTP request is passed through the appropriate VPN tunnel 470 and over the private network 468 to a corresponding router and VPN endpoint 474, 478 or 484, where it is passed to an internal HTTP server of the turbine (e.g., 476, 482, or 486) for handling and response.

[00156] In alternative embodiments, the reverse proxy server 462 may be replaced with a different kind of proxy server, for example, a forward proxy server. In the latter case, the first part of the system network addresses unnecessary (i.e., the address of the VPN concentrator), however, the front-end server will then have to be configured to communicate with the forward proxy server.

[00157] It will be appreciated that different turbine systems may implement the HTTP server in a different manner, as illustrated in Figure 20. Turbine 104 includes a programmable logic controller (PLC) 472 for controlling the operation of the turbine and also for responding to network communication requests. The PLC 472 thus includes a built-in web server 476. In a different embodiment, illustrated in a second turbine 106, the HTTP server may be a distinct Web server 482 internetworked with the PLC 480 and a router/VPN device 478 over a local area network (LAN) of the turbine system 106. In yet another embodiment, shown in a third turbine 108, the turbine may include a programmable control server 486 configured with software instructions capable of directing a processor of the server to provide the functionality of a router and VPN endpoint 484 (e.g., a routing and VPN process), as well as Web server functionality (e.g., a web server process).

[00158] In some embodiments, the front-end server 410 is able to make HTTP-based read and write requests by simply invoking a particular HTTP-based uniform resource identifier appended with parameters specifying the nature of the operation desired (e.g., the parameter or parameters to be read or written), and this HTTP-based request is passed through the VPN server 460 and a VPN-protected private network 468 to the appropriate turbine 104, where it is handled by the internal HTTP server 476. The internal HTTP server 476, 482 or 486 causes an associated processor, PLC (e.g., 472) or the server 486 itself to read or write the specified parameters to a memory store associated with the turbine. The memory store may be internal to the PLC 472 or server 486, or it may be an external or internetworked database system.

[00159] In the case of a read request, the turbine's internal HTTP server 476 may respond with a message enclosing the requested parameters if they are available. If the requested parameters are not available, invalid, or forbidden, the server 476 may respond instead with an appropriate error message or status code (e.g., in some embodiments, error code 403 if the URI is forbidden, error code 404 if the URI is not found, error code 500 if there is a server error, and error code 502 if there is a bad gateway error). Other status codes may indicate other information as to whether the operation was successful and if any problem was detected. Such error and status codes are returned to the front-end server 41 0 via the corresponding VPN tunnel 470.

[00160] In the examples given above, connections between the front-end server 410 and the turbine 104 are implemented by requests using the HTTP protocol, however, it will be appreciated that other networking protocols may be adapted to run over a VPN connection 470 to facilitate communication between the front-end servers 410, 412, 414 with respective VPN endpoints in a plurality of remote turbines 104, 106 and 108. The front-end servers, in turn, are configured to provide the read turbine parameters and/or the returned error or status codes of the request to the requesting client devices.

[00161] Dead Peer Detection

[00162] In some embodiments, there is provided a method of detecting a dead or malfunctioning peer device over a secure VPN connection. The method involves, after each predetermined interval (e.g., every 30 seconds), sending a packet over the VPN connection to a target network device with which the VPN connection should be maintained. The network device is given a certain period of time (e.g., 10 seconds) to respond to the request to confirm that it is fully operational. In some embodiments, the VPN concentrator 400 sends periodic packet requests to VPN endpoints 474, 478, 484 located at individual turbine systems (e.g. 104, 106, 108), to query whether the associated turbine systems are up and running and are able to communicate over their respective VPN tunnels 470. Alternatively, or in addition, the VPN endpoints 474, 470, and 484 at the remote turbine systems 104, 106, and 108, may send a periodic response request packet over a VPN tunnel 472 to the VPN server 460 to request that the server 460 respond to confirm that it is operational and able to communicate over its corresponding VPN tunnel. If a VPN endpoint 474, 478, or 484 of the turbine systems receives no response to the response request packet within a certain amount of time (e.g., 10 seconds), the VPN endpoint in question may kill the VPN tunnel and may try to initiate a connection to the VPN endpoint on the other side (i.e., VPN concentrator 464) to establish a new persistent VPN connection. In this manner, the VPN tunnels 470 can be automatically maintained and healed to dynamically form a private network 1 10, 468 notwithstanding the fact that, in some embodiments, the VPN-protected communications are being supported by or carried on an underlying public network 1 12 such as the Internet.

[00163] Turbine Communications

[00164] In the illustrated embodiment, for security reasons, individual turbines cannot initiate communication with a front-end server or any other turbine; they can only respond to communication initiated by the front-end servers 410, 412, 414. The turbines cannot communicate to any device on the other side of the VPN tunnel 470 except the VPN concentrator 464. While the routing tables may be set up under the assumption that everything on the same subnet is on the same network, the various turbine systems 104, 106, 108 are typically placed on different subnets, plus there is a need to engage in port forwarding to establish communication with the turbine systems. These communication limitations may be enforced using subnet security and port forwarding.

[00165] The VPN concentrator 464 is configurable to enforce a predetermined set of traffic rules for data in the server system. Figure 22 provides an example of how the VPN concentrator 464 can be configured to police the traffic flows between a plurality of sources and the plurality of destinations in some embodiments of the invention. In the embodiment of Figure 22, the front- end server nodes 502, the mobile workstation 524, and the system management office 534 are only permitted by the VPN concentrator 464 to communicate with one or more turbine systems 530, however, they are not permitted to otherwise communicate with each other through the VPN concentrator 464. In this manner, the VPN concentrator 464 creates dedicated VPN tunnels from the remote turbine systems to the front-end server nodes 502, mobile workstations 524, and the system management office 534.

[00166] It wi ll be appreciated that, if the front-end server nodes 502 implement data caching, then the mobile workstation 524 and system management office 534 will be able to obtain more fresh data (i.e., raw data) that is not subject to the limitations of the cache on the front-end nodes 502. In addition, the mobile workstation 524 and the system management office 534 potentially can be configured to use a different protocol than that used to make read and write requests by the front-end nodes (e.g., the HTTP protocol).

[00167] As will be seen from Figure 22, client devices owned by the turbine owner 522 may have a direct (local) interface 532 to the turbine system, for example a wired LAN or a wireless connection thereto. For example, a web server module of the turbine system may be configured to respond to local requests for access in accordance with a set of permissions associated with the owner of the turbine. Alternatively, the turbine system may have integral hardware input elements (e.g., a keypad or keyboard) and output elements (e.g., an LCD display) providing a human-machine interface (HM1) for the owner.

[00168] Miscellaneous Features

[00169] The above-mentioned server architecture helps the front-end servers 410, 412, 414 pull data from turbines 104, 106, 108 when required, as quickly and reliably as possible, while offloading a great deal of the processing and data bandwidth from the computing resources of the turbines. Due the combination of authorization features, shielding by gateway webservers, and VPN features, secure communication between the turbines and the server takes place over a private network, for example, a plurality of virtual private network (VPN) connections or tunnels between the VPN server/concentrator 460 and respective VPN endpoints in the remote turbine systems.

[00170] In such a server architecture, it is unnecessary for the client devices to maintain a persistent VPN tunnel to turbine systems of interest, because all VPN tunnels are established and maintained by a central server system, which acts as an intermediary between the turbine systems and the client devices. Advantageously, this approach reduces or obviates the need to provide a custom configuration for each client device (e.g., it is unnecessary to configure VPN client software on the client device). Client devices already have preinstalled browser software capable of making HTTP requests.

[00171] Furthermore, the server system 102 can be configured to provide an arbitrary subset of the functionality that would otherwise be available if the client devices connected to the turbine systems directly. In various embodiments, from a security perspective, it may be beneficial to not expose certain data and control functionality present on the turbine system to the casual user, but only to provide the specific read and/or write functionality that is needed for each user. Similarly, it is beneficial to be able to change the permissions associated with a particular user in the server system without having to be concerned about which client device the user is using or may use in the future. If an authorized user begins to use a new client device (e.g., a smartphone) or temporarily resorts to using a borrowed client device (e.g., an internet-enabled computer at a public library), the new or borrowed client device will be capable of providing any of functionality user had with his or her old client device.

[00172] The server system can be configured to provide certain authorized users with the ability to establish new accounts for new users and to authorize them to communicate with a particular set of turbines in accordance with a particular set of permissions. For example, a dealer could be authorized to add or remove employees from a list of accounts authorized to access a particular group of turbines being maintained by the dealer. The nature of the access available to each employee can be tailored to each individual employee's level of trust and competence.

[00173] Co-location of the front-end nodes with the VPN server 460 at a single data centre can greatly decrease the latency of communication between the front-end server with the VPN server 460, compared to locating them in separate data centres. In some embodiments, the VPN concentrator 464 may be implemented as a software process on a general-purpose server, whereas in other embodiments, the VPN concentrator 464 may be a dedicated hardware device, or a managed network of VPN devices.

[00174] Reducing Demands Made on the Turbine System

[00175] The computing resources of a turbine system are often shared between its control and communication functions, thus it not desirable to overload the turbine system with requests that require significant computational resources and/or that generate significant network traffic. Overloading a turbine system may result in the control system of the turbine system failing which could lead to a loss of the turbine's computing and communication functions and perhaps even loss of control over the operation of the turbine itself. In addition, turbine I/O operations are often very slow, and it would be desirable to avoid them, while still satisfying the demands of client devices for real-time (or nearly real-time) data.

[00176] In a network architecture such as the one depicted in Figures 1 and 20, there is a possibility that multiple cl ient devices will try to access a turbine system such as 104 almost simultaneously. For example, the user of the system may use multiple computing devices at different locations (e.g., at home and at work, and may also carry a mobile workstation or smart phone) all of which could be used to try to retrieve turbine data from one or more turbine systems. In addition, a single client device may be operable to issue multiple read or write requests to the turbine depending on the data and control interface presented to the client device by the front-end server 410. In some embodiments, the interface is presented as a series of webpages with one or more active tabs or sub-pages, each of which has a plurality of dynamic data elements that rely on data from the turbine systems to remain up-to-date. Each of the webpages that are open may make requests to obtain real-time (or nearly real-time) data from the turbine systems, which further increases the potential of overtaxing a particular turbine system's computational and communication resources, as mentioned above. [00177] In some embodiments, the turbine systems may be protected from being overextended computationally or in terms of I/O or traffic bandwidth by configuring the server system 102 to allow no more than N turbine system transactions to be pending at any given time. In a conservative system, N=l , such that only one read or write transaction can be processed by the turbine system at one time. Read or write transactions which are received while a request is already active are forced to wait for completion of the currently active transaction. This approach helps to avoid overloading the turbine's computing resources (such as the turbine's programmable logic controller 472 or control server 486), reduces the number of I/O operations, and reduces the network traffic bandwidth needed for communications with the turbine system.

[00178] As another optional level of protection of the turbine system, in some embodiments, a very large read (or write) request for a turbine system may be broken up into multiple smaller pieces, both to improve the latency of response and also to limit the amount of processing that needs to be done by the turbine system to handle the request. An upper bound on the number of parameters that can be retrieved at one time may be set, for example, at 15 data items. For example, in some embodiments a large request for the turbine system to read 40 turbine parameters may be broken up into two individual reads of 15 parameters each, followed by a third read request that retrieves 10 parameters.

[00179] In some embodiments, a caching mechanism may be implemented either in the server system 102 or at the client device (or at both) in order to both reduce latency and to avoid unnecessarily requesting turbine data from turbine systems which has recently been retrieved. Items in the cache system may be configured to expire automatically when they become stale or are rendered invalid or uncertain due to a certain event, such as a successful write of certain control parameters to the turbine system. Turbine data parameters may be kept in the caching system for shorter or longer periods of time depending on how important they are and how reliable they are over a given period of time. For example, turbine status information and long averages such as wind speed can be usefully kept in the cache for about 5 minutes in some embodiments, whereas instantaneous parameters such as instantaneous wind speed or instantaneous power produced grow stale quickly and thus would be kept in the cache for only about 2 seconds in some embodiments. Other parameters may be kept in the cache for still different periods of time. Certain parameters, such as the turbine status, become invalid or uncertain if a certain kind of parameter is written, for example, a stop turbine command is issued, whereupon such affected parameters should be flushed from the cache. Certain exemplary embodiment of a caching system will now be described with reference to Figures 25 and 26.

[00180] When an I/O request from a client device is received at the server system 102, the server system 102 begins an I/O request handling routine, shown generally at 620. At block 622, the server system 102 receives a read or write request from a client device. At block 624, the server system 102 queries an authentication database (such as database 136 shown in Figure 1 ) to determine whether or not the client device is authorized to make such a request. If the client device is not authorized to make the request, then the request is rejected (626). On the other hand, if the client is authorized to make the request, the process moves to block 628, which, depending on whether the request is a read or write request, causes the server system 402 either to initiate a write request handling routine (630), or to initiate a read request handling routine as shown at block 632 and following.

[00181] Read Caching

[00182] At block 632, the server system 1 02, and in particular, the front-end server 410, examines its cache to see whether or not each parameter requested can be located as already present in the cache. For example, the cache may be implemented by the storage module 440 as a key-value store, thus the front-end server 410 searches the store to find out if there is a key- value pair present for each of the turbine parameters that are being read. If all of the requested parameters are located in the cache, block 634 allows processing to move to block 636. In block 636, all of the request parameters are read from the cache and are returned to the client device without conducting any read operations to the target turbine system. As will be appreciated, this results in an enormous increase in response time and decreases the amount of I/O, network bandwidth, and processing that is needed at the turbine systems. In addition, this allows the user of the client device to benefit from serendipitous reading and writing activities to the same turbine by other entities, for example, other client devices that may be unaffiliated with the user.

[00183] However, the result at block 634 may be that not all of the parameters are located in the cache. For example, some of the turbine parameters were never read and placed into cache by earlier operations by this (or another) user, or if they were, those values have since become stale or invalid and were flushed from the cache. If at least some of the parameters requested are not available in the cache system, the server system 1 02 begins to take steps to initiate communications with the turbine to read the missing parameters from the target turbine, as indicated in block 640. [00184] As described above, the server system 102 may enforce limitations on the ability of different client devices to access a particular turbine resource by limiting the number of active requests at one time. In this embodiment, the maximum number of active requests that can be made simultaneously to a turbine is one, however, in other embodiments, the system 400 may allow two or more concurrent requests to be active. At block 642, if the systems of text that there is another active request of this turbine, then the requesting thread must wait for the active request to complete, as indicated by block 644. If there is no active request to this turbine, or if the previous active request has completed, the algorithm proceeds to block 646. If there is a write pending (as may be determined by checking a write active flag in some embodiments) then the process proceeds to wait and returns to block 642. If there is no write pending, the system sets the active request flag for this turbine to true (648). If the number of parameters requested exceeds a predetermined threshold number (650), then the request is broken up into pieces, and several read requests are carried out to obtain all the missing parameters, as shown in blocks 652 and 654.

[00185] At block 656, the return data from the turbine system is evaluated. If at least some of the parameters were not found or the turbine system failed to respond, then the operation was not successful, and the active request flag is cleared (658), after which all known parameters are returned to the user (670). However, if the data returned from the turbine system indicates that all requested parameters were returned, then the system populates the cache with the newly read parameters (674), inserts a log record of read parameters into DataDB (676, 1 34), where the log entry may include, e.g., an entry 678 which includes turbine, ID, timestamp, a key-value pair 680 and, in some embodiments, other values). The active request flag for this turbine is cleared (682), and all the parameters (i.e., the ones returned from the cache, if any, and the parameters just read from the turbine system) are all returned to the client device (684).

[00186] Write Caching

[00187] Referring to Figure 25, a caching method is disclosed for write requests for use in some embodiments of the invention. The method involves initiating communication with the turbine to write a parameter (702), and setting a write pending flag to allow other processes or threads to know that a write operation is desired by this particular thread or process (704). If there is another active request to this turbine (706), then this write request is paused until the active request is finished, whereupon the active request flag is set (709) and there is an attempt to write the parameter to the target turbine (708). If the write failed (712), the write pending flag is cleared (714), the active request flag is cleared (715), and the system returns a write failure indication to the client (716) because the write failed (718). If the write was successful, then the system 400 populates the master cache 420 with the value that was successfully written (step 720), it invalidates any associated cache values that were (or could have been) affected by the written value, i.e., values in the cache that were rendered invalid or uncertain due to the successful write (722), and logs the successful write in a database (724). This may involve putting an entry 726 into a data DB database 134, including a turbine identifier, a timestamp, a key, the value written, and a user identifier representing the user who performed the write operation. After this, the active request flag is cleared (727), the write pending flag is cleared (728), and the system 400 returns a confirmation to the client device that the write succeeded (730, 732).

[00188] Read or write threads which are waiting for the availability of a shared resource may attempt to access the shared resource after a random back-off period. In an alternative embodiment, read requests and write requests can be put into respective read and write request queues, such that read requests are serviced in the order of their receipt (e.g., as indicated by a timestamp associated with the read request), except in cases where a write request is pending. If there are any entries in the write queue pending, they must take priority as soon as it is possible to write to the turbine, since writes have the potential to affect the values currently stored in the cache of the server system 102 as well as the values that will need to be returned in response to future read requests.

[00189] In embodiments where the read and write commands are invoked from processes or threads that are not synchronous with respect to each other, the active request flag and the write pending flags (e.g., referenced in blocks 706 and 728 of Figure 25) may be synchronized to avoid race conditions created by the order of execution of the processes or threads whi le trying to access the shared resource. It will be appreciated that various methods of synchronization (e.g., waiting on mutexes and semaphores) are available and can be applied to avoid race conditions between asynchronous processes and threads. In embodiments where the read and write requests are serviced in round-robin fashion or as part of synchronous queues, such synchronization methods may not be needed. Also, it will be appreciated that, in alternative embodiments, the cache could be implemented with a shared memory structure, rather than replicating the cache from the master cache 440 on the backend server 490 to the respective caches 440 on each of the front-end servers 410. [00190] Advantageously, in such embodiments of the system 400, communication with turbines tends to be minimized and the speed of interaction with users is enhanced due to the provision of a secure, yet remotely-accessible, cloud-based caching method for turbine data and control information at the central server system 102. The backend server 490 includes a master cache implemented in the storage module 440 as a key-value store. The master cache is periodically replicated across all front-end server nodes 410, 412, 414 such that eventually the same cache is distributed to all front-end servers. While this embodiment involves synchronizing caches based on a programmable time interval, in other embodiments, the front-end and back-end caches may be synchronized based on certain predefined system event (e.g., a successful write). In addition, cache values may be stored in a high speed system memory of the server system such as RAM or flash drives to increase the speed of reading values.

[00191] Storing data in the cloud incurs costs that increase with the amount of data being stored, therefore the present method serves to reduce the amount of data being stored while focusing on the most useful data. Because parameters are stored for different lengths of times, determined on a per-parameter basis, and certain cached values may be invalidated in response to a write which affects those cached values, this in effect prunes the data being stored to prioritize the storage of fresh, valid, and in-demand data while discarding stale, invalid or otherwise unnecessary data. In cases where turbines are located in remote locations and use expensive or unreliable data transmission facilities (e.g., satellite uplinks), such methods and architecture can reduce data transmission costs and increase the availability of data to end-users despite any data transmission problems.

[00192] When a new client device comes online or a pre-existing client device comes online after a long absence from contact with the system 400, it is capable to cause a large spike in service requests to the turbine in the absence of protective methods such as those described above. For example, the client device may almost simultaneously launch a plurality of data screens, each with a plurality of turbine data display elements, such that the total number of data items required numbers in the thousands. If a substantial number of these data items are available in the cache, the user will receive useful data very quickly and the system wil l minimize wear and tear on turbine systems to the extent possible.

[00193] It will be appreciated that any of the programmable or software-implemented functionality described herein may be stored in a tangible medium (e.g., magnetic media, optical discs, flash memory, RAM, etc.) as instructions for directing a processor to carry out any of the various methods of the invention. It will also be appreciated that such instructions may be capable of being transferred (e.g., over digital or computer networks) in the form of communication signals.

[00194] The foregoing illustrative embodiments have been presented in the context of wind turbines and turbines. In various alternative embodiments the methods and systems described herein may be used to access and manage other forms of distributed energy generating systems that are connected to a network.

[00195] While specific embodiments of the invention have been described and illustrated, such embodiments should be considered illustrative of the invention only and not as limiting the invention as construed in accordance with the accompanying claims.

[00196] It should be appreciated that the embodiments disclosed herein are not necessarily mutually exclusive such that features of one embodiment may be combined with those of another embodiment to form further embodiments falling within the scope of these claims. It should also be appreciated that various other possible combinations and permutations of the internal and external components described herein may form still further embodiments falling within the scope of these claims.