ORC stack-system control

10570782 · 2020-02-25

Assignee

Inventors

Cpc classification

International classification

Abstract

The invention relates to a method for controlling ORC stacks with a total number n.sub.tot of individually operable ORC modules, said method comprising the following steps: determining the running time remaining until the next servicing time for each operable ORC module respectively; determining a target number n.sub.soll of ORC modules to be operated; comparing said target number n.sub.soll to an actual number n.sub.ist of currently operated ORC modules; when n.sub.soll>n.sub.ist, connecting a number n.sub.solln.sub.ist of ORC modules that corresponds to the difference between the target number and the actual number, where the ORC modules with the longest remaining running times of the ORC modules currently not being operated are connected; and/or when n.sub.soll<n.sub.ist, disconnecting a number n.sub.istn.sub.soll of ORC modules that corresponds to the difference between the actual number and the target number, where the ORC modules with the shortest remaining running times of the ORC modules currently being operated are disconnected; and/or when n.sub.soll=n.sub.ist, connecting the ORC module with the longest remaining running time t.sub.1 of the ORC modules not currently being operated, and disconnecting the ORC module with the shortest remaining running time t.sub.2 of the ORC modules currently being operated, if t.sub.1>t.sub.2.

Claims

1. A method for controlling an Organic Rankine Cycle (ORC) stack with a total number n.sub.tot of individually operable ORC modules, the method comprising the steps of: determining the respective running time remaining until the next servicing time for each operable ORC module, wherein the respective running time remaining until the next servicing time is determined for one or more of the ORC modules based at least on a load and an operating time; determining a target number n.sub.soll of ORC modules to be operated; comparing said target number n.sub.soll to an actual number n.sub.ist of currently operated ORC modules; wherein, in a case that n.sub.soll>n.sub.ist, connecting a number n.sub.soll n.sub.ist of ORC modules that corresponds to the difference between the target number and the actual number, wherein the ORC modules with the longest remaining running times of ORC modules currently not being operated are connected; and wherein, in a case that n.sub.soll<n.sub.ist, disconnecting a number n.sub.istn.sub.soll of ORC modules that corresponds to the difference between the actual number and the target number, wherein the ORC modules with the shortest remaining running times of ORC modules currently being operated are disconnected.

2. The method according to claim 1 comprising the further step of: re-performing the steps of claim 1 after a predetermined update period.

3. The method according to claim 1, wherein determining the running time remaining until the next servicing comprises determining the shortest running time for each operable ORC module from a plurality of running times remaining until the servicing times for various services for the respective ORC module.

4. The method according to claim 3, further comprising the step of: determining a variable that determines at least one selected from the group of a heat flow or a mass flow of a heat-conveying fluid in the ORC stack, wherein determining the target number of ORC modules to be operated is done in dependence of the variable determining the heat flow.

5. The method according to claim 4, comprising the further step of: re-determining the input heat flow after a predetermined waiting period after last determining the input heat flow has lapsed, and if a change of the input heat flow is determined beyond a tolerance range for the change, re-performing the method of claim 4 including all the steps in the respective dependent claims.

6. The method according to claim 4, wherein determining the target number of ORC modules to be operated further comprises determining a respective heat flow to be supplied within an operating range for each ORC module with respect to the heat flow supplied.

7. The method according to claim 5, wherein determining the target number of ORC modules to be operated further comprises determining a respective heat flow to be supplied within an operating range for each ORC module with respect to the heat flow supplied.

8. The method according to claim 6, wherein determining the heat flow to be supplied is effected within the operating range while taking into account the changes of the remaining running times resulting therefrom.

9. The method according to claim 7, wherein determining the heat flow to be supplied is effected within the operating range while taking into account the changes of the remaining running times resulting therefrom.

10. The method according to claim 1, further comprising the step of: determining a variable that determines at least one selected from the group of a heat flow or a mass flow of a heat-conveying fluid in the ORC stack, wherein determining the target number of ORC modules to be operated is done in dependence of the variable determining the heat flow.

11. The method according to claim 10, comprising the further step of: re-determining the input heat flow after a predetermined waiting period after last determining the input heat flow has lapsed, and if a change of the input heat flow is determined beyond a tolerance range for the change, re-performing the method of claim 10.

12. The method according to claim 10, wherein determining the target number of ORC modules to be operated further comprises determining a respective heat flow to be supplied within an operating range for each ORC module with respect to the heat flow supplied.

13. The method according to claim 12, wherein the operating range is defined for each ORC module by a heat flow range in an output curve or an efficiency curve indicating the relationship between electric power and electric efficiency in dependence of the heat flow supplied, wherein a heat flow range is defined by a minimum and a maximum heat flow.

14. The method according to claim 13, wherein the respective heat flow to be supplied is determined for one or more ORC modules to be operated such that the largest possible electrical power or the highest possible electrical efficiency results.

15. The method according to claim 13, wherein determining the heat flow to be supplied for each ORC module comprises maximizing overall electrical efficiency of the ORC stack.

16. The method according to claim 12, wherein determining the heat flow to be supplied is effected within the operating range while taking into account the changes of the remaining running times resulting therefrom.

17. The method according to claim 16, wherein the heat flow to be supplied is determined such that a shift of a servicing time by a desired period results, resulting in shortening or lengthening the respective remaining running time.

18. The method according to claim 1, wherein, in a case that n.sub.soll=n.sub.ist, and after a minimum running time of the ORC modules, the method comprises the further step of connecting the ORC module with a longest remaining running time t.sub.1 of ORC modules not currently being operated, and disconnecting the ORC module with a shortest remaining running time t.sub.2 of ORC modules currently being operated, if t.sub.1>t.sub.2.

19. The method according to claim 1, wherein the respective servicing times for the operable ORC modules are servicing times for similar services.

20. An ORC stack with a total number n.sub.tot of individually operable ORC modules, wherein the ORC stack comprises a control unit for performing the method according to claim 1.

21. A computer program product for controlling an Organic Rankine Cycle (ORC) stack with a total number n.sub.tot of individually operable ORC modules, the computer program product comprising: a non-transitory computer readable medium comprising code configured to: determine the respective running time remaining until the next servicing time for each operable ORC module, wherein the respective running time remaining until the next servicing time is determined for one or more of the ORC modules based at least on a load and an operating time; determine a target number n.sub.soll of ORC modules to be operated; compare said target number n.sub.soll to an actual number n.sub.ist of currently operated ORC modules; wherein, in a case that n.sub.soll>n.sub.ist, connect a number n.sub.solln.sub.ist of ORC modules that corresponds to the difference between the target number and the actual number, wherein the ORC modules with the longest remaining running times of ORC modules currently not being operated are connected; and wherein, in a case that n.sub.soll<n.sub.ist, disconnect a number n.sub.istn.sub.soll of ORC modules that corresponds to the difference between the actual number and the target number, wherein the ORC modules with the shortest remaining running times of ORC modules currently being operated are disconnected.

22. The computer program product according to claim 21, wherein in a case that n.sub.soll=n.sub.ist, and after a minimum running time of the ORC modules, the code is further configured to connect the ORC module with a longest remaining running time t.sub.1 of ORC modules not currently being operated, and disconnect the ORC module with a shortest remaining running time t.sub.2 of ORC modules currently being operated, if t.sub.1>t.sub.2.

Description

FIGURES

(1) FIG. 1A,B show distributions of operating times of ORC modules in an ORC stack.

(2) FIG. 2 shows a flow diagram for a controller according to an embodiment of the present invention.

(3) FIGS. 3A,B show the efficiency curve in dependence of the heat flow supplied.

(4) FIG. 4 shows the temporal course of service parameters.

EMBODIMENTS

(5) Depending on the available (waste) heat output, ORC modules 1 and 2 in FIG. 1A are used for the base load and continue operation completely over the time interval specified. ORC modules 3-5, in contrast, are required only in part. This results in a highly heterogeneous distribution of operating times in accordance with the prescribed servicing intervals and servicing times. The objective, however, is homogenization of the servicing intervals and servicing times as shown in FIG. 1B. As this sketch indicates, this requires that the individual ORC modules are operated in a coordinated manner with a varying number of operating ORC modules. The fundamental question is, therefore, how process control can synchronize the servicing intervals in that it connects and disconnects the ORC modules such that the maximum number of ORC modules can be serviced during scheduled servicing. Furthermore, process control is by synchronization of the servicing intervals to ensure that no components are during servicing work replaced prior to having reached their service life, which has previously been explained by a discontinuation of otherwise necessary additional servicing work.

(6) To record the remaining running times for different types of servicing, a respective so-called service parameter is defined in this embodiment which results in a steadily growing value in connection with the running time remaining until the next servicing. This is illustrated in FIG. 4 by way of example for three service parameters WP1, WP2 and WP3 in dependence of time t. The point in time to is a current time of observation in which a decision is made about ORC modules to be connected or disconnected. Each service parameter is there associated with a respective remaining running time t.sub.WP1, t.sub.WP2 and t.sub.WP3, until the next servicing. Determining the remaining running time can be e.g. extrapolated from the recent course of the service parameter or determined by way of a self-learning logic. Alternatively, the service parameter can vice versa also be concluded from the remaining running time. For example, a fixed linear relationship exists for annually fixed servicing between WP and t.sub.WP. The types of services in an ORC module can be divided into service parameters (WP) as follows: a) calendar-based WPe.g. leakage test (at least annually) b) operating hour-based WPe.g. fan on the frequency converter (as it runs as soon as the ORC module is in operation) c) full load operating hour-based WP (e.g. fan on condenser (it runs depending on the load) d) condition-based WP (e.g. fouled heat exchangers (waste gas heat exchanger or condenser).

(7) The service parameters are based on stored or self-learning functions/algorithms. Servicing has to be done when the service parameter is greater than or equal to 1, where ideally servicing should be done exactly at WP=1. Slight exceeding the service parameter will generally be possible, however, the system then operates outside the values specified. A service parameter establishes a relationship between the running times remaining until servicing is due, where WP=0 in the event of a service just having been performed. The service parameter therefore maps the remaining running time to the interval [0; 1], where exceeding the scheduled servicing time is associated with values WP>1. For a service parameter based purely on operating time, summation of the running time since the last service is there to be performed. With servicing independent of the operating hours (for example, annually), the service parameter increases linearly from the last service until the next service from 0 to 1.

(8) FIG. 2 illustrates the process of decision making as to which ORC modules are to be put into operation or disconnected, respectively. 1.sup.st step: determining the sequence of the ORC modules to be serviced next. In this step, a table with all available, i.e. operational or currently operating ORC modules ORC.sub.i is created, sorted according to its smallest t.sub.i. ORC modules which are not operational, e.g. due to a defect or due to servicing work taking place, are not included in the table. t.sub.i denotes the time interval from the current point in time until the next service to be performed which is determined by reaching value 1 for the respective service parameter WP having the greatest value. This value is determined for each WP of every ORC module (by extrapolating the graphs of the individual WP based e.g. on the curve change in the past or other values such as season, sulfur content in biogas/waste gas, etc.). With a stack of ORC modules, various service parameters can lead to servicing, e.g. the service parameter of the feed pump can in one ORC module be reached, in another one, however, it can be the service parameters of a fan, etc. The WP with the highest value is determined for every ORC module. The remaining running times t.sub.i are derived therefrom, on the basis of which a table for increasing remaining running times is then created. The service parameter canas described abovebe located in a fixed time interval due to statutory requirements, can be defined by operating or full load operating hours, or also the condition of the component. Once the table has been updated, the running variable t=0 is set. 2.sup.nd step: determining heat flow. Here, the heat flow {dot over (Q)}.sub.(Ab)Wrme is determined as the input parameter, this can be done determined in different ways, e.g. by direct measurement using a heat meter or indirectly by determination from parameters and model equations of the components of the ORC. 3.sup.rd step: determining n.sub.soll. Based on a characteristic curve for partial load behavior of an ORC modulesee line in FIG. 3Aa range (design range) depending on the heat supplied in individual ORC modules is defined (x-axis, Q.sub.lim,min to Q.sub.lim,max) in which the ORC module is to be operated. The partial load behavior of an ORC module can be determined experimentally by running various performance variables, but can with sufficient knowledge of the individual components of the working medium and of the interconnection also be calculated theoretically.

(9) The exemplary curve illustrated in FIG. 3A is an adjusted compensation function based on measured values. It is apparent that the maximum efficiency is given at a slightly lower heat output than full load (=100% heat output, rated power, design point). This is for the reason that specifically more area is available under partial load for heat transfer in the evaporator and the condenser. In particular, efficient heat dissipation with low auxiliary power requirement and a lower condensation pressure results for the condenser from this factual oversizing which leads to better gross efficiency. Both together are largely responsible for the increasing efficiency in the partial load range. The decrease in efficiency to the left of the maximum is due to the decrease of the mass flow and the fresh vapor temperature, which is reflected in worse expansion engines and poorer thermal efficiencies.

(10) Also possible is operating the ORC in overload (based on the design point) as long as the component specifications are observed (for example, maximum rotational speed or maximum electrical output). Overload operation leads to an increase in gross output, but also results in an increase in internal consumption, which overcompensates the increase in gross output. Maximum efficiency is thus formed. The decrease in efficiency at overload operation e.g. when using an air condenser with a controlled condenser fan, results predominantly from the disproportionately increasing internal current consumption of the condenser fan.

(11) Defining the design range can be dependent on several factors (for example, dynamics of the heat source, number of ORC modules per stack, also exterior temperature). The design range can for any application therefore be previously defined or determined by a self-learning algorithm or individually once or also continuously adapted.

(12) The control scheme presently presented thereby enables output-optimized operation of ORC stacks because all the individual systems can be operated at an optimized application point. FIG. 3B shows two different operating points for a constant total heat input into the stack ({dot over (Q)}.sub.(Ab)Wrme). They result from a differing number of ORC modules in operation. The relationship applies for this example: n.sub.soll,1>n.sub.soll,nenn. The ORC stack process control allows for both operating cases because it is in both cases ensured that the ORC modules are operated with efficiency in the design range. As shown in FIG. 3B, higher-level stack control enables optimization of the output of the individual systems due to the fact that the efficiency of the individual systems at partial load behavior (90%=Soll, 1) is better than at the design point of the individual ORC modules (100%=Soll,nenn).

(13) As long as the number is within the limits of the design range, this value of n.sub.soll is permitted by the process control. But how many ORC modules are actually in operation can beyond that depend on further factors. The efficiency advantage by one or more ORC modules additional commissioned may not be canceled or surpassed by additionally incurred servicing costs, either by depleting operating time until reaching an operating hour-base WP, a full load operating hour-based WP, or the further increase of a condition-based WP, which the control presently ensures. 4.sup.th step: determining the number of ORC modules running. In this step, the controller compares the number of required ORC modules (n.sub.soll) for optimal power generation of the available waste heat power ({dot over (Q)}.sub.(Ab)Wrme) with the number of ORC modules currently in operation (n.sub.ist).
1.sup.st Case: n.sub.ist=n.sub.soll

(14) In the event that n.sub.ist=n.sub.soll the ORC modules running remain in operation. If after a defined minimum running time t.sub.lim the output has not changed, then the table of service parameters is checked for its being up-to-date and respective ORC modules on connected or disconnected. It is thereby prevented that some ORC modules arrive at servicing times too quickly and are therefore no longer available. If ORC modules must be disconnected, then that ORC module with the lowest t.sub.i (table ranking 1) is first disconnected and possibly others (according to sequence in the table). If ORC modules are to be connected, then those ORC modules which are not in operation but operational having the highest t.sub.i are to be connected.

(15) 2.sup.nd Case: n.sub.soll<n.sub.ist.

(16) If fewer ORC modules are to be in operation than is currently the case, then ORC modules must be disconnected. For this purpose a running variable i=1 is set. If the termination criterion n.sub.ist=n.sub.soll is now not yet given, then ORC modules are continually disconnected, starting with the largest service parameters, i.e. with the shortest running time remaining until servicing. This is achieved by increasing the running variable i by 1.

(17) 3.sup.rd Case: n.sub.soll>n.sub.ist

(18) If fewer ORC modules are to be in operation than is currently the case, then ORC modules must be connected. For this purpose a control variable i=i(t.sub.i=max) is set, i.e., that i is used which corresponds to the ORC module with the lowest service parameter. That i canbut does not necessarily need tocorrespond to the number of ORC modules. As longs as the termination criterion n.sub.ist=n.sub.soll is not yet given, then ORC modules are continually connected, starting with the lowest service parameter, i.e. with the longest running time remaining until servicing, and the running variable is reduced by 1.

(19) The embodiments illustrated are only by way of example and the full scope of the present invention is defined by the claims.