Software upgrade for wind turbine control system
By selecting nodes in the distributed control system of the wind turbine to receive and analyze upgrade requests and perform software upgrades in the allowed operating state, the fault problem caused by interdependence between nodes during the software upgrade of the wind turbine is solved, and the software upgrade of the wind turbine under normal operation is realized, ensuring the safety and reliability of the system.
Patent Information
- Application Number
- CN202380074158.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-10-19
- Filing Date
- 2023-10-13
- Publication Date
- 2025-05-30
AI Technical Summary
In the distributed control system of wind turbines, due to the interdependence between nodes and different operating examples of different nodes during the software upgrade, functional failures, unnecessary downtime and equipment wear are caused, and the prior art requires the turbine to be shut down to perform the upgrade, resulting in unavailable safety functions.
When the wind turbine is in an operating state, the query process is performed to ask other nodes to analyze whether the upgrade request can be permitted, and perform the software upgrade in the allowed operating state.
It realizes software upgrades in the normal operation of the wind turbine, avoids unnecessary downtime and equipment wear, and ensures the safety and reliability of the system.
Smart Images

Figure CN120077362A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a computer-implemented method for performing a software upgrade of a control system of a wind turbine; a control system of a wind turbine configured to perform the method; and a computer program product. Background Art
[0002] In a distributed control system in a wind turbine, there are multiple processors connected by some network and / or fieldbus. In systems that require functional safety, such as wind turbines, special hardware and software designed to handle safety-related functions are included in a set of processor nodes. Additionally, there may be other elements, such as network switches and other auxiliary elements, which are also necessary for the interconnection of the processor nodes. All these processor nodes, together with these additional elements, provide the overall control of the wind turbine.
[0003] Upgrading the software on such a distributed control system is a challenging task.
[0004] Interdependencies between functions running on different processor nodes can lead to functional failures. When devices and actuators suddenly stop, this results in unnecessary downtime and wear of the equipment, and can be particularly problematic for safety-related systems because their functions are similarly interrupted, which may potentially lead to unsafe states or force the safety system to be more rigid to compensate for these states, resulting in more costs and complexity.
[0005] If an upgrade to one or more of these processor nodes is performed while the processor nodes are operational, failures may occur. The loss of one processor node may cause an error on another node that it depends on. A typical characteristic of such a distributed control system is also that the processor nodes operate in very different paradigms. For example, a condition monitoring system from a third party operates in a different way from a standard PLC used for controlling operations, or even more so compared to a processor node that handles functional safety with severe constraints on its operation. This poses a challenge in coordinating states between the nodes.
[0006] Auxiliary elements that include software, such as network switches, intelligent sensors, and actuators, similarly need to be updated. These elements can also cause interruptions to functions distributed over multiple nodes and have additional complexity in that, outside of uploading new software to such devices, wind turbine developers may not have access to the software or firmware interfaces.
[0007] A known solution to this problem is to shut down everything in the turbine to enable the upgrade. This has the disadvantage that safety or other critical functions are unavailable (when this is not strictly necessary and there is a risk of damaging wind turbine components). Summary of the Invention
[0008] A first aspect of the present invention provides a computer-implemented method for performing a software upgrade of a control system of a wind turbine, the control system being a distributed control system including a network of nodes, the method comprising the steps of: when the wind turbine is in an operating state:
[0009] a) receiving and reading an upgrade request at a selected node of the distributed control system;
[0010] b) in response to reading the upgrade request in step a), performing a query process by the selected node to interrogate one or more of the other nodes of the distributed control system;
[0011] c) at the selected node, receiving an input from the query process of step b);
[0012] d) at the selected node, analyzing the input from step c) to determine whether the upgrade request can be permitted;
[0013] e) granting permission by the selected node based on the analysis of step d); and
[0014] f) in response to granting the permission in step e), determining an operating state during which the upgrade can be allowed, and
[0015] g) if the operating state is in an allowed state, performing the upgrade request by upgrading at least one of the nodes with new software.
[0016] If the wind turbine is in an operating state in which the upgrade does not place the wind turbine at risk during the upgrade process, upgrading the software of one or more nodes is generally allowed. The operating state during which the upgrade can be allowed may be when the wind turbine is not operating under one of a plurality of operating states in which the turbine may be at risk. Such non-allowed operating states include, but are not limited to, an operating state with high power output, an operating state that depends on the function of the node to be upgraded or on nodes that depend on the function of the node to be upgraded, a sensor indicating a special environmental or system condition (such as an acceleration sensor indicating high vibration movement of a component, a wind speed sensor indicating high wind speed or turbulence, a rotational speed sensor indicating high or varying rotor speed) signal.
[0017] Optionally, step a) includes reading configuration data; and performing step b) and / or step f) based on the configuration data.
[0018] Optionally, the configuration data determines which nodes are interrogated in step b); and / or the configuration data determines which nodes are upgraded in step g); and / or the configuration data determines the order in which nodes are upgraded in step g); and / or the configuration data determines which nodes are upgraded in parallel in step g).
[0019] Optionally, the configuration data is part of the upgrade request received in step a), or the configuration data is read from a memory in response to the upgrade request received in step a).
[0020] Optionally, the method further comprises: as a result of the analysis in step d), changing the operating state of the wind turbine; and delaying the execution of step f) until the operating state of the wind turbine has changed.
[0021] Changing the operating state of the wind turbine may be a result of determining in step f) that the operating state is not in an allowed state. When the operating state of the wind turbine has changed to an allowed operating state, at least one of the nodes is upgraded with new software.
[0022] Optionally, at least one critical function of the wind turbine continues to operate during the change of the operating state.
[0023] Optionally, the change of the operating state causes the power generated by the wind turbine to decrease.
[0024] Optionally, at least one of the nodes interrogated in step b) cannot perform any internal analysis.
[0025] Optionally, multiple nodes are upgraded in parallel in step g).
[0026] Optionally, the input received in step c) or the analysis in step d) identifies multiple nodes that can be upgraded in parallel; and the identified nodes are upgraded in parallel in step g).
[0027] Optionally, the update request identifies multiple nodes; a first subset of the nodes identified by the update request is upgraded in parallel in step g); and a second subset of the nodes identified by the update request is not upgraded in step g).
[0028] Optionally, the input received in step c) or the analysis in step d) identifies a first subset of nodes.
[0029] Optionally, the input received in step c) indicates the wind conditions and / or the power generated by the wind turbine.
[0030] Optionally, each node upgraded in step g) is identified by the update request received in step a).
[0031] Optionally, a plurality of nodes are identified by the update request; and in step g), not all nodes identified by the update request are upgraded.
[0032] Optionally, in step g), not all nodes of the network are upgraded.
[0033] Optionally, each node upgraded in step g) is also queried in step b).
[0034] Optionally, at least one node queried in step b) is not upgraded in step g).
[0035] Optionally, the method further comprises: before step a), forwarding the upgrade request to a selected node serving as a first upgrade arbiter; and after a timeout expires without receiving a response from the first upgrade arbiter, resending the upgrade request to another node of the distributed control system, the another node serving as a second upgrade arbiter, wherein the second upgrade arbiter receives the upgrade request in step a) and then performs steps b)-e).
[0036] Optionally, the method further comprises selecting a second upgrade arbiter from a plurality of additional upgrade arbiters. The plurality of additional upgrade arbiters are selected from the nodes of the distributed control system.
[0037] Optionally, the upgrade request is a first upgrade request, and the method further comprises:
[0038] a1) receiving a second upgrade request at a selected node of the distributed control system;
[0039] b1) in response to receiving the second upgrade request in step a1), performing, by the selected node, a query process to query one or more of the nodes of the distributed control system;
[0040] c1) at the selected node, receiving an input from the query process of step b1);
[0041] d1) at the selected node, analyzing the input from step c1) to determine whether the second upgrade request can be permitted;
[0042] e1) denying permission by the selected node based on the analysis of step d1); and
[0043] f1) in response to the denial in step e1), aborting the upgrade process associated with the second upgrade request.
[0044] Another aspect of the present invention provides a computer program product comprising software code which, when executed on a data processing system, is adapted to perform a software upgrade of a control system of a wind turbine, the computer program product being adapted to perform the method of the first aspect.
[0045] Another aspect of the present invention provides a control system for a wind turbine configured to perform the method of the first aspect.
[0046] Optionally, the control system includes: a network of nodes; an upgrade arbiter configured to perform steps a)-e) of the method; and a software upgrade server configured to perform step g) of the method. BRIEF DESCRIPTION OF THE DRAWINGS
[0047] Embodiments of the present invention will now be described with reference to the drawings, in which:
[0048] Figure 1 a wind turbine is shown;
[0049] Figure 2 a control system of the wind turbine is shown;
[0050] Figure 3 other elements of the control system are shown; and
[0051] Figure 4 a computer-implemented method for performing a software upgrade of the control system is shown. DETAILED DESCRIPTION
[0052] Figure 1 A wind turbine 1 is shown including a nacelle 3 mounted on a tower 2. A rotor 4, 5 is rotatably mounted to the nacelle 3. The rotor includes a hub 4 and blades 5 extending from the hub. In this example, the rotor includes three blades 5, but the number of blades can vary. The nacelle 3 can rotate about a vertical yaw axis to change its yaw angle.
[0053] The wind turbine 1 can be included in a collection of other wind turbines belonging to a wind power plant (also referred to as a wind farm or wind power park), which serve as power generation plants connected to the power grid via transmission lines. The power grid generally consists of a network of power generation stations, transmission circuits, and substations coupled by a network of transmission lines that transmit power to loads in the form of end users.
[0054] Figure 2 An embodiment of the control system 200 together with the elements of the wind turbine 1 is schematically illustrated. The rotor is mechanically connected to a generator 7 via a gearbox 9 (in direct drive systems and other systems, the gearbox may not be present). The power generated by the generator 7 is injected into the power grid 204 via an electrical converter 205. The generator 7 and the converter 205 can be based on a full-scale converter (FSC) architecture or a doubly-fed induction generator (DFIG) architecture, but other types can be used.
[0055] The control system 200 includes a plurality of components, the plurality of components including at least one main controller 220 having a processor and a memory such that the processor is capable of performing computational tasks based on instructions stored in the memory. Generally, the main controller 220 ensures that the wind turbine generates the requested power output level during operation. This is achieved by adjusting the pitch angle of the blades and / or the power extraction of the converter 205. To this end, the control system 200 includes a pitch system and a power system, the pitch system including a pitch controller 207 using a pitch reference signal 208, and the power system including a power controller 209 using a power reference signal 206. The rotor blades 5 can be pitched by a pitching mechanism. The rotor includes an individual pitch system capable of pitching the rotor blades 5 individually, and a common pitch system for simultaneously adjusting the pitch angles of all the rotor blades. The control system 200 or elements of the control system 200 can be placed in a plant controller (not shown) such that the turbine can be operated based on externally provided instructions.
[0056] Figure 3 Other elements of the control system 200 are illustrated, including various elements configured to perform a software upgrade of the control system 200.
[0057] The control system 200 is a distributed control system of a network including nodes 10a - 10j. Each of the nodes 10a - 10h can include software that needs to be updated (optionally periodically). The software can be executable software, or configuration data, or any other type of software.
[0058] The nodes include processor / controller nodes 10a - 10e that perform processing or control functions. As an example, each of the processor / controller nodes 10a - 10e can be: a processor; a controller (e.g., controlling the lubrication of the gearbox 9, or controlling the hydraulic pump of the pitch controller 207); a safety node (i.e., a node that handles functional safety); switchgear (e.g., a circuit breaker or switch fuse device for protecting the electrical equipment inside the wind turbine in the event of a fault condition); an embedded processor on a printed circuit board; or an independent programmable logic controller.
[0059] The nodes 10f and 10g are auxiliary devices. As an example, each of the nodes 10f, 10g can be a network switch (necessary for the interconnectivity of other nodes); a sensor (e.g., sensing the speed of the rotor 5, the condition of the gearbox 9, the wind speed, the movement of the tower 2, the movement of the nacelle 3, or the power output to the power grid 204); or an actuator (e.g., a blade pitching actuator).
[0060] Node 10h is the primary upgrade arbiter, and nodes 10i and 10j are secondary upgrade arbiters. In this example, there are only two secondary upgrade arbiters 10i and 10j, but there can be more than two. Upgrade arbiters are nodes of a distributed control system, and they usually also perform other functions, such as control functions. Upgrade arbiters are selected nodes of a distributed control system, usually pre-selected and assigned to the arbiter task through pre-stored functions (i.e., programming code that performs the arbiter task).
[0061] The control system 200 also includes a software upgrade server 11.
[0062] The upgrade arbiters 10h-j are nodes configured to grant or deny requests to execute software upgrades from the software upgrade server 11. The upgrade arbiters 10h-j query the nodes of the system to determine whether the request can be permitted.
[0063] The software upgrade server 11 and the upgrade arbiters 10h-10j are configured to perform a software upgrade of the control system 200 through Figure 4 the computer-implemented method steps shown. More specifically, the software upgrade server 11 and the upgrade arbiters 10h-10j include a computer program product that includes software code adapted to perform a software upgrade when executed on a data processing system, and the computer program product is adapted to perform Figure 4 the method shown.
[0064] The computer program product can be provided on a computer-readable storage medium or can be downloaded from a communication network. The computer program product can include instructions to cause a data processing system (e.g., in the form of a controller) to execute the instructions when the instructions are loaded onto the data processing system.
[0065] Figure 4 The first step a) of the method shown includes receiving and reading an upgrade request at the software upgrade server 11 at selected nodes of the distributed control system. The upgrade request is indicated by 13 in Figure 3 and can come from a user (e.g., a service person), from an automated process remote from the wind turbine, or from a node of the control system 200. As an example, the upgrade request 13 can request upgrades of nodes 10a, 10c, 10d, 10g.
[0066] The data in the upgrade request 3 can be read by the software upgrade server 11 to identify the nodes to be upgraded. Optionally, the upgrade request 3 can also include a configuration file that contains configuration data about the nodes to be upgraded. Alternatively, the software upgrade server 11 can include a local memory that contains configuration data of all nodes of the network.
[0067] Configuration data can explain the order in which nodes are to be upgraded and which nodes can be upgraded in parallel. Relevant additional information (such as upgrade order and timing) can also be included as required.
[0068] Figure 4 The following steps include: b) in response to reading an upgrade request in step a), performing a query process by the selected node, in which one or more of the nodes are interrogated; c) at the selected node, receiving the input from the query process of step b); d) at the selected node, analyzing the input from step c) to determine whether the upgrade request can be permitted; e) granting permission by the selected node based on the analysis of step d); and f) in response to granting permission in step e), determining the operating state during which the upgrade can be allowed, and g) if the operating state is in an allowed state, executing the upgrade request by upgrading at least one of the nodes with new software. The new software can be executable software, or configuration data, or any other type of software.
[0069] If the operating state is not in an allowed state, change the operating state to an allowed state and execute the upgrade request by upgrading at least one of the nodes with new software.
[0070] The software upgrade server 11 can request permission for a first set of upgrades that can be executed in parallel from the selected node acting as the main upgrade arbiter 10h. In response, the main upgrade arbiter 10h performs the query process of step b), receives the input from the query process in step c), and analyzes the input in step d) to determine whether the requested first set of upgrades is permitted in the current situation of the wind turbine.
[0071] Step b) interrogates one or more of the nodes 10a - 10g, and step d) determines the suitability of the nodes specified in the upgrade request to be upgraded, for example, by a logical check or other analysis.
[0072] For example, in very high wind conditions, it may be unsafe to upgrade the turbine software due to the risk of blade damage during the process. Additionally, assuming this is permitted, it may take some time to take constructive actions to put the turbine's system and the entire turbine itself in an appropriate state to perform the update.
[0073] At least one of the nodes interrogated in step b) can be a "non - intelligent" node that cannot perform any internal analysis. In this case, the main upgrade arbiter 10h assumes the role of verifying whether the "non - intelligent" node can be updated.
[0074] Upgrade request 13 may specify nodes 10a, 10c, 10d, 10g. The query process of step b) may include querying all or some of nodes 10a, 10c, 10d, 10h. Optionally, the query process of step b) may include querying other nodes not specified in the upgrade request (such as node 10b or auxiliary device 10f).
[0075] Based on the analysis of step d), the main upgrade arbiter 10h responds to the software upgrade server 11 with a decision. As an example, the decision may indicate whether the requested first set of upgrades can be performed immediately, whether some time is required to achieve the required state before allowing the upgrade, or whether the upgrade is not currently allowed for some reason.
[0076] In the case where the analysis of step d) indicates that the upgrade can be performed, the main upgrade arbiter 10h may respond to the software upgrade server 11 with a decision that permission is granted at step e). The software upgrade server 11 then performs the necessary upgrades in step g). The software upgrade server 11 waits until these are completed and then proceeds to the next set of upgrades that can be performed in parallel, restarting from the query process of step b).
[0077] The analysis of step d) may indicate that the upgrade cannot be performed while the wind turbine is in its current operating state, i.e., the wind turbine is not in an operating state that allows the upgrade. For example, the input received in step c) may indicate high wind conditions and / or high rotor speed, and / or high power generated by the wind turbine, making it impossible to perform the upgrade. Alternatively, the input received in step c) may indicate that redundant nodes of the control system must be activated, or that some functions are stopped or placed in a special state before the upgrade becomes possible.
[0078] In one embodiment, the main upgrade arbiter 10h may instruct the main controller 220 to change the operating state of the wind turbine, such as changing the rotor speed or activating redundant nodes. Once the operating state of the wind turbine has changed sufficiently (e.g., the rotor speed has dropped below a threshold, functions have stopped or been placed in a special state, or redundant nodes have started operating), the main upgrade arbiter 10h then grants permission at step e). In this embodiment, the operating state is changed to an allowed state.
[0079] In another embodiment, the main upgrade arbiter 10h may grant permission at step e), but the permission is conditional upon the operating state of the wind turbine being sufficiently changed before the software upgrade is executed. In this embodiment, the software upgrade server 11 may instruct the main controller 220 to change the operating state of the wind turbine, such as changing the rotor speed, stopping a function, placing a function in a special state, or activating redundant nodes. Once the operating state of the wind turbine has been sufficiently changed (e.g., the rotor speed has dropped below a threshold, a function has stopped, or redundant nodes have started operating), the software upgrade server 11 performs the upgrade in step g).
[0080] In both embodiments, the execution of step g) is delayed until the operating state of the wind turbine has changed. The change in the operating state of the wind turbine may be specific to only a certain part of the turbine, while the remainder of the wind turbine operates as described above.
[0081] The change in the operating state may cause the power generated by the wind turbine and supplied to the power grid 204 to decrease. Optionally, the wind turbine continues to supply power to the power grid 204 during the execution of the upgrade request in step g).
[0082] Generally, at least one critical function of the wind turbine continues to operate during the change in the operating state and during the upgrade process in step g). That is, the wind turbine may not be completely shut down to perform the upgrade.
[0083] In the case where the analysis in step d) indicates that the upgrade cannot be performed, the main upgrade arbiter 10h may respond to the software upgrade server 11 with a decision to deny permission at step g). The software upgrade server 11 may abort the upgrade at this stage and report relevant information to the user or record it appropriately.
[0084] The main upgrade arbiter 10h may specify one or more reasons for subsequent diagnosis by a person in the denial at step g). Optionally, if it takes some time to achieve a state that allows the upgrade, the main upgrade arbiter 10h may continue to update the software upgrade server 11 regarding the expected remaining time and indicate whether the preparation process has been completed ahead of time, thus allowing time to be saved during the upgrade.
[0085] In the case where a specified timeout elapses without a response from the main upgrade arbiter 10h, the software upgrade server 11 may select one of the secondary upgrade arbiters 10i, 10j in step h), and then resend the request to the selected secondary upgrade arbiter, which starts the process again at step b). Alternatively, in the case where a specified timeout elapses without a response from the main upgrade arbiter 10h, the software upgrade server 11 may perform some default action, which is typically to continue the upgrade to avoid deadlock or abort the upgrade while investigating the problem.
[0086] As described above, configuration data can be provided. The configuration data can be part of the upgrade request 13 received in step a), or the configuration data can be read from the memory in response to the upgrade request received in step a).
[0087] As an example, the configuration data can identify which nodes are to be upgraded in step g); and / or the order in which the nodes are upgraded in step g); and / or which nodes can be upgraded in parallel in step g). Step a) can include reading the configuration data; and the upgrade request in step g) can be executed based on the configuration data (for example, the nodes can be upgraded in a specified order in step g).
[0088] Optionally, some of the nodes to be upgraded are interdependent and can be upgraded in parallel. An example of interdependence is between a switchgear node and other nodes, where the other nodes are possible sources of high-voltage induced fires in a wind turbine. Another example of interdependence is between a safety node and other nodes monitored by the safety node to ensure safety. During normal operation, the safety node obtains inputs from other nodes, so shutting down the safety node requires shutting down other nodes.
[0089] In one embodiment, the configuration data can indicate which nodes can be upgraded in parallel. For example, the upgrade request 13 can specify nodes 10a, 10c, 10d, 10g, and the configuration data can indicate that a first subset of nodes (for example, nodes 10c and 10d) are interdependent and can be upgraded in parallel. In this case, only the first subset of nodes can be queried in the first iteration of steps b)-d), and upgraded in parallel in the first iteration of step g). At least in the first iteration of step g), a second subset of nodes (for example, nodes 10d and 10g) are not upgraded.
[0090] In an alternative embodiment, instead of configuration data indicating which nodes can be upgraded in parallel, the input received in step c) or the analysis step d) can identify a first subset of nodes (for example, nodes 10c and 10d) that can be upgraded in parallel. In this example, the output of the analysis step d) can be a permission to upgrade the first subset of nodes in parallel, and a rejection of upgrading a second subset of nodes (for example, nodes 10a and 10g) at least at the current time. Then, the interdependent nodes 10c and 10d indicated in the permission are upgraded in parallel in the first iteration of step g).
[0091] The software upgrade server 11 can wait until the upgrade of nodes 10c and 10d is completed, and then proceed to the next set of upgrades that can be executed in parallel (for example, nodes 10a and 10g), restarting from the query process in step b).
[0092] Typically, each node upgraded in each iteration of step g) is identified by the update request 13 received in step a).
[0093] Optionally, multiple nodes may be associated with the update request 13; and not all nodes associated with the update request are upgraded in a single iteration of step g). For example, nodes 10a, 10c, 10d, and 10g may be associated with the update request, but only nodes 10c and 10d are upgraded in the first iteration of step g).
[0094] Optionally, in step g), not all nodes of the network are upgraded.
[0095] Optionally, each node upgraded in step g) is also queried in step b).
[0096] Optionally, at least one node queried in step b) is not upgraded in step g).
[0097] Optionally, the upgrade arbitrators 10h - 10j themselves may include internal nodes updated in step g).
[0098] The selection of the arbitrators 10h - 10j may be configurable and may change not only between turbine versions but also based on information about the current state of the turbine. For example, if part of the control system or its network degrades, an alternative group of arbitrators may be selected.
[0099] The process may be repeated for a second upgrade request received in repeated step a). Figure 4 In this case, the other steps of the method are performed for the second upgrade request.
[0100] As an example, Figure 4 the repetition of the process may include:
[0101] a1) Receiving the second upgrade request at a selected node of the distributed control system;
[0102] b1) In response to receiving the second upgrade request in step a1), performing a query process by the selected node to query one or more of the nodes of the distributed control system;
[0103] c1) At the selected node, receiving the input from the query process of step b1);
[0104] d1) At the selected node, analyzing the input from step c1) to determine whether the second upgrade request can be permitted;
[0105] e1) The selected node refuses to permit based on the analysis of step d1); and
[0106] f1) In response to the rejection in step e1), abort the upgrade process associated with the second upgrade request.
[0107] First example
[0108] A first example of the process will now be described. Figure 4 of the process.
[0109] The arbiter 10h receives an upgrade request and interrogates sensor nodes (e.g., rotor speed sensors and / or power output sensors) indicating that the wind turbine is operating at a high level. The arbiter 10h analyzes the sensor data and does not give permission to perform the upgrade until the wind turbine is no longer operating at a high level. The main upgrade arbiter 10h may put the wind turbine into a safe state before granting permission in step e). In this example, the arbiter 10h has a direct connection to the sensors. In other examples, the arbiter 10h may only have an indirect connection to the sensors via other nodes. In this example, the other nodes may perform a certain amount of analysis to arrive at an answer. Thus, the analysis step d) may only be partially performed within the arbiter 10h, i.e., it may be distributed around the nodes of the control system.
[0110] Second example
[0111] A second example of the process will now be described. Figure 4 of the process.
[0112] The arbiter 10f receives an upgrade request and interrogates the tower movement sensor and the nacelle movement sensor. These indicate a large amount of movement because there is a storm. The arbiter 10h does not give permission to perform the upgrade until the storm has stopped.
[0113] Third example
[0114] A third example of the process will now be described. Figure 4 of the process.
[0115] The arbiter 10h receives an upgrade request for the hydraulic pump control node. This node has an interdependence with the blade pitch actuator, i.e., when the hydraulic pump control node is shut down, the blade pitch actuator cannot operate. Therefore, certain proactive actions may be required before permission is granted in step e).
[0116] Although the invention has been described above with reference to one or more preferred embodiments, it should be understood that various changes or modifications can be made without departing from the scope of the invention as defined in the appended claims.
Claims
1. A computer-implemented method for performing a software upgrade of a control system of a wind turbine, the control system being a distributed control system comprising a network of nodes, the method comprises the following steps: When the wind turbine is in an operating state: a) Receive and read an upgrade request at a selected node of the distributed control system; b) In response to reading the upgrade request in step a), perform a query process by the selected node to interrogate one or more of the other nodes of the distributed control system; c) At the selected node, receive the input from the query process of step b); d) At the selected node, analyze the input from step c) to determine whether the upgrade request can be permitted; e) Grant permission by the selected node based on the analysis of step d); and f) In response to granting the permission in step e), determine the operating state during which the upgrade can be allowed, and g) If the operating state is in an allowed state, execute the upgrade request by upgrading at least one of the nodes with new software.
2. The method according to claim 1, wherein, step a) comprises reading configuration data; and wherein steps b) and / or step f) are performed based on the configuration data.
3. The method according to claim 2, wherein: the configuration data determines which nodes to interrogate in step b); and / or the configuration data determines which nodes are upgraded in step g); and / or the configuration data determines the order in which the nodes are upgraded in step g); and / or the configuration data determines which nodes are upgraded in parallel in step g).
4. The method according to claim 2 or 3, wherein, the configuration data is part of the upgrade request received in step a), or the configuration data is read from a memory in response to receiving the upgrade request in step a).
5. The method according to any one of the preceding claims, further comprises: As a result of the analysis of step d), change the operating state of the wind turbine; and delay the execution of step f) until the operating state of the wind turbine has changed.
6. The method according to claim 5, wherein, at least one critical function of the wind turbine continues to operate during the change of the operating state.
7. The method according to claim 5 or 6, wherein, the change of the operating state causes the power generated by the wind turbine to decrease.
8. The method according to any one of the preceding claims, wherein, at least one of the nodes interrogated in step b) cannot perform any internal analysis.
9. The method according to any one of the preceding claims, wherein, a plurality of the nodes are identified by the update request; a first subset of the nodes identified by the update request is upgraded in parallel in step g); and a second subset of the nodes identified by the update request is not upgraded in step g).
10. The method according to any one of the preceding claims, wherein, the input received in step c) or the analysis of step d) identifies the first subset of the nodes.
11. The method according to any one of the preceding claims, further comprises: before step a), forwarding the upgrade request to a first upgrade arbiter; and after a timeout expires without receiving a response from the first upgrade arbiter, resending the upgrade request to a second upgrade arbiter, wherein the second upgrade arbiter receives the upgrade request in step a) and then performs steps b)-e).
12. The method according to claim 11, further comprising selecting the second upgrade arbiter from a plurality of additional upgrade arbiters.
13. A computer program product comprising software code which, when executed on a data processing system, is adapted to perform a software upgrade of a control system of a wind turbine, the computer program product being adapted to perform the method according to any one of the preceding claims.
14. A control system of a wind turbine, the control system being configured to perform the method according to any one of claims 1 to 12.
15. The control system according to claim 14, which comprises: a network of nodes; an upgrade arbiter configured to perform steps a)-e) of the method; and a software upgrade server configured to perform step g) of the method.