Co-simulation of physical processes
The active wait state on separate processor cores for co-simulation processes addresses latency issues by allowing rapid result exchange without context changes, enhancing the efficiency and accuracy of complex system analysis.
Patent Information
- Application Number
- DE102024201657
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-02-22
- Publication Date
- 2025-08-28
AI Technical Summary
Co-simulation methods in complex systems, particularly energy grids, face significant delays due to context changes caused by operating systems when waiting for calculation results, leading to increased latency and inefficiencies.
Implementing an active wait state on separate processor cores for simulation processes, allowing periodic queries of a shared memory area to exchange calculation results without context changes by the operating system, reducing latency through parallel operation.
This approach significantly reduces latency and enhances the efficiency of co-simulation by enabling rapid exchange of computation results between simulation processes, preventing delays and improving the accuracy and speed of system analysis.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
[0001] The invention relates to the co-simulation of physical processes, in particular of electrical energy networks.
[0002] Co-simulation is an innovative approach for analyzing and optimizing complex systems. In co-simulation, several different simulation algorithms and / or engines are linked together to obtain a comprehensive understanding of the system. By combining different simulation methods, the advantages of individual models can be utilized while also compensating for their limitations. This enables a more realistic and precise analysis of complex systems, such as transportation systems, energy grids, or production processes.
[0003] Especially in energy networks, co-simulation can be used to address the fact that modern energy networks are increasingly shaped by the behavior of power converters, which serve, for example, as connection points for renewable energy generators.
[0004] Rotating machines, which store energy through the large inertial mass of their rotors, are increasingly being eliminated. The directly connected generators establish the connection to the power grid. The high amounts of stored energy reduce the interaction frequency of equipment, i.e., interaction with longer time constants in the range of seconds or minutes. The elimination of the machines reduces the time constants, necessitating new analysis methods, such as a coupled EMT+RMS analysis.
[0005] Naturally, co-simulation is performed on a computer system. During co-simulation, computational results are exchanged between the simulation models and the simulation programs that calculate them. For this purpose, it is advisable for a simulation model waiting for a computational result to signal a wait state to the operating system via functions specified by the operating system. This wait state is then terminated when the other simulation model provides the computational result.
[0006] For certain simulation models, it is possible for the exchange of computational results to occur at short time intervals, for example, between 10 µs and 100 µs, and in any case less than 1 ms. In this case, it is very advantageous if the simulation models of the co-simulation run on different processors or different processor cores to avoid a comparatively time-consuming context switch (i.e., switching between processes by the operating system) between the simulation models.
[0007] If the simulation models actually run in parallel in the manner described (i.e., not just seemingly parallel due to context switching), then the disadvantage is that the wait state assumed while waiting for a calculation result typically leads to a context switch by the operating system. Since such a context switch causes a time loss due to the shifting of memory contents that is on the order of the aforementioned time intervals, it disadvantageously leads to significant delays in the co-simulation.
[0008] It is an object of the invention to provide an improved method for co-simulation which reduces or avoids the disadvantage mentioned at the outset, thus in particular ensuring lower latencies with rapid exchange of calculation results.
[0009] This object is achieved by a method having the features specified in claim 1.
[0010] In the computer-implemented method according to the invention for simulating chained physical processes, a first simulation process is operated on a first processor core and a second simulation process is operated on a second processor core different from the first.
[0011] One of the simulation processes receives a calculation result from the other simulation process at intervals of no more than 1 ms. To do so, it enters a wait state that terminates when the calculation result is available.
[0012] An active wait state is used as the wait state, in which a memory area shared between the simulation processes is regularly queried, and whose value indicates the presence of the calculation result, whereby the regular query prevents a context switch by the computer's operating system for at least a period of time greater than 1 ms.
[0013] A simulation process is defined as a computer program that recreates a model of a physical system and calculates its behavior, with a set of input data representing an initial state. The behavior, in turn, is specified by the computational results obtained during the simulation. This behavior can be temporal, but can also replicate some other form of the effect of the input data.
[0014] Processor cores are familiar from modern CPUs, each capable of executing a set of machine instructions independently and, in principle, independently of other cores. The processor cores are conveniently part of a single CPU (Central Processing Unit).
[0015] The calculation result is understood as a respective set of data, i.e., one or more numbers resulting from the calculation steps of a particular simulation process. The wait state is a state in which no further calculations are performed for the simulation model. The memory is preferably the computer's RAM. It can also be part of a CPU's internal cache.
[0016] RAM (Random Access Memory) is a component of a computer that temporarily stores data that the processor can quickly access. It is volatile memory, meaning it loses its information when the computer is turned off. However, reading and writing operations in RAM are significantly faster than with any non-volatile memory.
[0017] The CPU cache is a small memory area that is directly part of the CPU. Access to it is even faster than access to RAM, so the CPU cache is used to temporarily store frequently used data and instructions, thus accelerating processing.
[0018] Compared to simply switching to a wait state specified by the operating system, this has the advantage that the simulation process can transfer calculation results multiple times without the operating system having to perform a time-consuming context switch to another process, thereby slowing down the simulation.
[0019] Furthermore, the invention relates to a computer program product which can be loaded directly into a programmable computer, comprising program code parts which, when the program is executed by a computer, cause the computer to carry out the steps of a method according to the invention.
[0020] A computer program product may, for example, be provided or delivered on a storage medium such as a memory card, USB stick, CD-ROM, DVD, a non-transitory storage medium or in the form of a downloadable file from a server in a network.
[0021] Advantageous embodiments of the invention emerge from the dependent claims. The embodiment of the independent claims can be combined with the features of one of the subclaims or, preferably, with those of several subclaims. Accordingly, the following additional features can be provided: The first and second simulation processes can be simulation models implemented differently from each other. In other words, they can be completely different software, particularly with different source code. It is also possible that the source code itself is not available, meaning that software products are used that cannot be modified or changed. The simulation processes can therefore be different software products.
[0022] Alternatively, the simulation processes can be based on the same source code; in other words, they can be the same software. This can be usefully run as the first and second simulation processes in separate processes or in separate threads within a single process. In any case, it is useful for the two simulation processes to have access to a shared memory area.
[0023] A computer with a multi-core processor is ideally used to run the simulation processes. This allows for truly parallel operation of threads or processes on at least two of its cores, thus enabling, in principle, the very rapid exchange of simulation results between the simulation processes.
[0024] The time intervals at which one of the simulation processes accepts a respective calculation result from the other simulation process can be a maximum of 500 µs, in particular a maximum of 200 µs, in particular a maximum of 100 µs. These time intervals are the duration of a respective calculation that the simulation process performs, after which it waits for the calculation result of the other simulation process. These time intervals are not fixed but result from the calculations required for a given simulation step.
[0025] The shared memory area can be a variable shared by both simulation processes, such as a counter. This can advantageously be alternately incremented and decremented from the active wait state.
[0026] It is useful for the two simulation processes to mutually adopt a calculation result from the other simulation process. In other words, the two simulation processes exchange their calculation results and use them as input values for a subsequent simulation step.
[0027] The active wait state is preferentially assumed by both simulation processes when waiting for the calculation result of the other simulation process.
[0028] Preferably, the active wait state is terminated after a maximum duration is reached. This prevents the active wait state from preventing a context switch by the operating system for an excessively long time, thus causing the computer to lock up (freeze). The maximum duration can be triggered, for example, by querying a timeout. Reaching the maximum duration is preferably determined by incrementing a counter and comparing it with a threshold. This advantageously eliminates the need to retrieve system information such as the time, but rather merely requires the entirely internal manipulation of memory information.
[0029] Ending the active wait state can be achieved by transitioning to a wait state provided by the operating system. One such wait state in a Windows API is "WaitForSingleObject()."
[0030] The behavior of an electrical energy system, such as a three-phase electrical distribution grid, can be used as interlinked physical processes. In this case, voltage and current measurements from the energy system can be used as input values for co-simulation. The final simulation result, in the form of the final calculation results from the simulation processes, can be used to control the electrical energy system. For example, co-simulation can be used to determine whether the energy system is in a critical state—for example, if the voltage value leaves a permissible range—and to activate or deactivate control power based on this.
[0031] In addition to using exactly two simulation processes, three or more simulation processes can also be used.
[0032] The invention is described and explained in more detail below with reference to the exemplary embodiments shown in the figures. They show: Fig. 1 an example of a symmetric co-simulation for an electrical network, Fig. 2 a scheme for the co-simulation process with an active wait state for the exchange of calculation results, Fig. 3 a scheme for the process of the active waiting state.
[0033] Fig. Figure 1 shows a simplified scheme for a symmetric co-simulation in a physical system, in this case an electrical power system. Specifically, a high-voltage transmission line is being modeled. The term "symmetric" here means that the two coupled simulation processes use the same model and the same simulation software. Commercial software such as PSCAD can be used for this. The simulation software used runs in parallel using separate processes or threads.
[0034] As in Fig. 1, the two simulation processes determine based on data stored in Fig. 1 are not shown, in fixed discrete time steps values for a respective voltage u k (t) and u m (t) and a respective current flow i k (t) and i m(t) as calculation results at each end of the transmission line. After completion of a calculation step, these calculation results are exchanged between the two simulation processes to enable the calculation of the next time step.
[0035] Several such transmission lines can be simulated together, simulating a larger network. This can be done by running more than two instances of the simulation software as simulation processes, for example, three or four or more.
[0036] These more than two simulation processes then also exchange their calculation results with each other.
[0037] Alternative designs use asymmetric co-simulation. The term "asymmetric" here means that the two coupled simulation processes simulate different models and use different simulation software for this purpose. The simulation software used runs in parallel as separate processes or threads.
[0038] The schematic flow of the simulation as a whole is for the example of exactly two simulation processes in Fig. 2 is shown schematically.
[0039] A first simulation process 10 is started in a first step 101. In a second step 102, a shared memory area 51 is initialized, as are the required variables. Then, in a third step 103, the system enters a wait state, waiting for a second simulation process to start. This occurs in a fourth step 104, i.e., the second simulation process 20 is also started. This can be done manually or automatically, depending on the specific software used.
[0040] In a fifth step 105, the second simulation process 20 establishes a connection to the shared memory area 51, thereby connecting the two simulation processes 10, 20. Depending on the specific design of the software, the shared memory area 51 may already be present intrinsically, for example, if the two simulation processes 10, 20 run as threads of one and the same software. In other designs, for example, with two different commercial software solutions, the shared memory area 51 is enabled by special functions of the operating system.
[0041] After establishing the connection in the fifth step 105, both simulation processes 10, 20 enter a similar coupled sequence, which is represented by the following steps.
[0042] In step 106, a check is made to determine whether a timeout, i.e., a time overflow, has occurred. If so, the program proceeds to step 116. If no timeout has occurred, the status is synchronized with the other simulation process 10, 20 in step 107.
[0043] In a subsequent step 108, a check is made to determine whether the other simulation process 10, 20 has experienced a timeout. If so, the own status is set to timeout in a step 109 and the process switches to step 116. Otherwise, in a step 110, the calculation results of the respective simulation process 10, 20 are written to the shared memory area 51 so that they can be retrieved by the other simulation process 10, 20.
[0044] In a step 111, a signal is then set which ends an active wait state 60 of the other simulation process 10, 20 and signals that calculation results are available and a further simulation step can be carried out.
[0045] In a step 112, the system enters an active wait state 60. This active wait state is terminated by the signal from step 111 from the other simulation process 10, 20. In other words, the active wait state 60 lasts until the signal from the other simulation process 10, 20 is set.
[0046] Once the active wait state 60 has ended, a check is performed in step 113 to determine whether the other simulation process 10, 20 has timed out. If this is the case, the own status is set to timeout in step 114, and the process switches to step 116.
[0047] Otherwise, in a step 115, the calculation results 70 of the other simulation process 10, 20 are read from the common memory area 51.
[0048] In step 116, a further simulation step is performed, ie, the available input values, including the calculation results 70 from the other simulation process 10, 20, are used to continue the simulation. In this process, new calculation results 70 are generated.
[0049] In step 117, a check is performed to determine whether the last time step has been reached. This can be done based on a pre-planned number of time steps or based on other criteria. If this is not the case, the loop returns to step 106, thus closing the loop. Otherwise, in step 118, the results are saved, the shared memory area 51 is released, and other cleanup work is performed, before the simulation is terminated.
[0050] The active wait state, which enables fast communication between the simulation processes 10, 20 largely without context switching by the operating system, is in Fig. 3 shown schematically.
[0051] After the active wait state 60 is started, an iteration counter 61 is set to 0 in a step 201. The iteration counter 61 belongs solely to a respective active wait state 60 and is therefore not shared between the simulation processes 10 and 20. The iteration counter 61 serves to define a maximum duration of the active wait state 60.
[0052] This is followed by a step 202, in which, in an atomic action, a common counter variable 62 is incremented and a comparison is made with the value 2. The common counter variable 62 is shared between the simulation processes 10 and 20 and must therefore be handled in such a way that write accesses do not result in errors due to near-simultaneous accesses by both simulation processes 10 and 20. To do this, the increment is performed as an inseparable action, in which the reading from memory to a register, the addition of 1, and the writing back are performed under a lock of the shared counter variable 62, thus preventing concurrent access by other threads or processes.
[0053] The combined comparison with the value two determines whether both parallel simulation processes 10, 20 are in the active wait state at the same time, since in a subsequent step 203 the common counter variable 62 is decremented again. The value two can therefore only be reached if both simulation processes 10, 20 are in the active wait state 60.
[0054] If the value is actually two (or more), then the system goes directly to step 204, which ends the active wait state because both calculation results 70 are available and the simulation can be continued.
[0055] Otherwise, the active wait state 60 continues with step 203. In this case, the common counter variable 62 is again decremented by one in an inseparable action and a comparison is made with the value one. If the value of the common counter variable 62 is not at least one, the iteration counter 61 is incremented, i.e., increased by one, in step 205. The program then returns to step 202.
[0056] Additionally, in step 206, the iteration counter 61 is compared with a threshold value. If the threshold value, which may be 100,000, for example, is exceeded, the program proceeds to step 207, in which an operating system-specific wait state is entered. The program also proceeds to step 207 if, in step 203, the common counter variable 62 has at least the value one, thereby signaling that both simulation processes 10, 20 are providing a calculation result 70.
[0057] As a result, the raising and lowering of the wait state ensures that the operating system does not prematurely terminate the active wait state by switching context, thus causing a significant delay for the next simulation step. At the same time, it ensures that a direct response is made to the availability of a calculation result 70 from both simulation processes 10, 20. Finally, it also ensures that the active wait state is terminated after a maximum duration has elapsed and that the system transitions to an operating system-specific wait state, which also allows a context switch to prevent prolonged blocking. Reference symbol 10, 20 Simulation process 51 Shared memory area 60 Active Waiting State 62 common counting variables 70 Calculation result 101...118 steps of co-simulation 202...207 steps of the active waiting state
Claims
[1] Computer-implemented method for simulating chained physical processes in which - a first simulation process (10) is operated on a first processor core, - a second simulation process (20) is operated on a second processor core different from the first, - the two simulation processes (10, 20) have access to an area (51) in the computer memory shared between the simulation processes, - one of the simulation processes (10, 20) takes over a respective calculation result (70) from the other simulation process (10, 20) at time intervals of at most 1 ms and goes into a waiting state (60) which is terminated by the availability of the calculation result (70), characterized bythat an active wait state (60) is used as the wait state (60), in which the area (51) in the memory is regularly queried by the simulation process (10, 20) in the wait state (60), and whose value indicates the presence of the calculation result (70), wherein the regular query prevents a context change by the operating system of the computer for at least a time period greater than 1 ms. [2] Method according to claim 1, wherein the first and second simulation processes (10, 20) are simulation models implemented differently from one another, in particular with different source code. [3] A method according to claim 1 or 2, wherein a computer with a multi-core processor is used. [4] Method according to one of the preceding claims, in which the time intervals are at most 100 µs. [5] Method according to one of the preceding claims, in which the shared memory area (51) corresponds to a variable (62) shared by both simulation processes (10, 20). [6] Method according to one of the preceding claims, in which the variable (62) is a counter which is alternately increased and decreased by the active wait state (60). [7] Method according to one of the preceding claims, in which the two simulation processes (10, 20) mutually adopt a calculation result (70) from the respective other simulation process (10, 20). [8] Method according to one of the preceding claims, in which the active waiting state (60) is assumed by both simulation processes (10, 20) when waiting for the calculation result (70) of the respective other simulation process (10, 20). [9] Method according to one of the preceding claims, in which the active waiting state (60) is terminated after reaching a maximum duration. [10] Method according to one of the preceding claims, in which the reaching of the maximum duration is determined by counting up a counter and comparing it with a threshold value. [11] Method according to one of the preceding claims, wherein the termination of the active wait state (60) is effected by a transition to a wait state provided by the operating system. [12] Method according to one of the preceding claims, in which the behaviour of an electrical energy system, for example a three-phase electrical distribution network, is used as the linked physical processes. [13] Method according to claim 12, wherein voltage and current measured values from the energy system are used as input values for the co-simulation. [14] Method according to claim 12 or 13, wherein a final result of the simulation in the form of final calculation results of the simulation processes (10, 20) is used to carry out a control of the electrical energy system. [15] A computer program product which can be loaded directly into a programmable computer, comprising program code parts which are suitable for carrying out the steps of the method according to any one of the preceding claims.