Co-simulation of physical processes

AU2025226579A1Pending Publication Date: 2026-08-06SIEMENS AG
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
AU · AU
Patent Type
Applications
Current Assignee / Owner
SIEMENS AG
Filing Date
2025-02-17
Publication Date
2026-08-06

AI Technical Summary

Technical Problem

Co-simulation methods in complex systems like energy networks face significant delays due to context switches caused by wait states during the exchange of computational results, especially when simulation models run on different processors, leading to increased latency.

Method used

Implementing an active wait state on shared memory areas between simulation processes on separate processor cores, allowing rapid exchange of calculation results without operating system context switches, using an active wait state that terminates when the result is available, and employing a shared memory area to query for the presence of results.

Benefits of technology

Reduces latency and improves simulation efficiency by enabling rapid result transfer between simulation processes, minimizing context switch delays and maintaining system responsiveness.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

The invention relates to a computer-implemented method for simulating interlinked physical processes, in which a first simulation process is operated on a first processor core, a second simulation process is operated on a second processor core which is different from the first process core, one of the simulation processes takes over a respective calculation result from the other simulation process at time intervals of at most 1 ms and for this purpose transitions into a waiting state which is brought to an end by the presence of the calculation result, wherein the waiting state used is an active waiting state in which a memory area shared between the simulation processes is regularly queried, and the value of which indicates the presence of the calculation result, wherein the regular querying prevents a context change by the operating system of the computer at least for a time period of greater than 1 ms.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Description

[0002] Co-simulation of physical processes

[0003] The invention relates to the co-simulation of physical processes, in particular of electrical energy networks.

[0004] 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.

[0005] 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.

[0006] 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.

[0007] Co-simulation is naturally performed on a computer system. During co-simulation, computational results are exchanged between the simulation models and the simulation programs that calculate the models. For this purpose, it is useful 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. For certain simulation models, it is possible for the exchange of computational results to occur at short time intervals, for example, between 10 ps and 100 ps 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 in order to avoid a comparatively time-consuming context switch, ie switching between processes by the operating system, between the simulation models.

[0008] 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.

[0009] 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.

[0010] This object is achieved by a method having the features specified in claim 1.

[0011] 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.

[0012] 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.

[0013] 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. This regular query prevents a context switch by the computer's operating system for at least a period of time greater than 1 ms. A simulation process is understood to be a computer program that simulates a model for 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 calculation results resulting from the simulation. The behavior can be temporal behavior, but can also simulate another 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 advantageously allows multiple calculation results to be transferred to the simulation process without the operating system having to perform a time-consuming context switch to another process, thereby slowing down the simulation. Furthermore, the invention relates to a computer program product that can be loaded directly into a programmable computer, comprising program code portions that, when the program is executed by a computer, cause the computer to execute the steps of a method according to the invention.

[0019] 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.

[0020] 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:

[0021] 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 ps, ​​in particular a maximum of 200 ps, ​​in particular a maximum of 100 ps. These time intervals are the duration of a respective calculation that the simulation process performs and, after which it waits for the calculation result from 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 is "WaitForSingleObject()" in a Windows API.

[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:

[0033] Figure 1 shows an example of a symmetric co-simulation for an electrical network,

[0034] Figure 2 shows a scheme for the co-simulation process with an active wait state for the exchange of calculation results,

[0035] Figure 3 shows a diagram of the active waiting state.

[0036] 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.

[0037] As shown in Figure 1, the two simulation processes determine, based on data not shown in Figure 1, values ​​for a respective voltage Uk(t) and u m (t) and a respective current flow ik(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.

[0038] Several such transmission lines can be simulated together, thereby simulating a larger network. For this purpose, more than two instances of the simulation software can run as simulation processes, for example, three or four or more. These more than two simulation processes then also exchange their calculation results with each other.

[0039] 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.

[0040] The schematic flow of the simulation as a whole is shown schematically in Figure 2 for the example of exactly two simulation processes.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] In step 106, a check is made to determine whether a timeout, i.e., a time overflow, has occurred. If so, the program switches to step 116. If no timeout has occurred, the status is synchronized with the other simulation process 10, 20 in step 107. In a subsequent step 108, a check is made to determine whether the other simulation process 10, 20 has timed out. If so, the program switches to step 109, setting its own status to timeout, and the program switches to step 116. Otherwise, the calculation results of the respective simulation process 10, 20 are written to the shared memory area 51 in step 110 so that they can be retrieved by the other simulation process 10, 20.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] Otherwise, in a step 115, the calculation results 70 of the other simulation process 10, 20 are read from the common memory area 51.

[0049] 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.

[0050] In step 117, a check is made to determine whether the last journal has been reached. This can be done based on a pre-planned number of journals or based on other criteria. If this is not the case, the program 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. The active wait state, which enables rapid communication between the simulation processes 10, 20 largely without context switching by the operating system, is schematically illustrated in Figure 3.

[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 shared counter variable 62 is incremented and compared with the value two. The shared counter variable 62 is shared between simulation processes 10 and 20 and must therefore be handled in such a way that no errors occur during write accesses due to near-simultaneous accesses by both simulation processes 10 and 20. To this end, the increment is performed as an atomic 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 decremented by one and compared with the value one in an inseparable action. 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. 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, where an operating system-specific wait state is entered. The process also proceeds to step 207 if, in step 203, the common counting variable 62 has at least the value one, which signals that both simulation processes 10, 20 provide a calculation result 70.

[0056] 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.

[0057] Reference symbol

[0058] 10, 20 Simulation process

[0059] 51 Shared memory area 60 Active wait state

[0060] 62 common counting variables

[0061] 70 Calculation result

[0062] 101... 118 steps of co-simulation

[0063] 202...207 steps of the active waiting state

Claims

Patent 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 wait state (60) for this purpose, which wait state is ended by the presence of the calculation result (70), characterized in that an active wait state (60) is used as the wait state (60), in which the area (51) in the memory is regularly polled by the simulation process (10, 20) in the wait state (60), and the value of which indicates the presence of the calculation result (70), wherein the regular polling prevents a context change by the operating system of the computer at least for a time period greater than 1 ms.

2. The 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. The 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 ps.

5. Method according to one of the preceding claims, wherein 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, wherein 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, wherein 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 incrementing 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 behavior of an electrical energy system, for example a three-phase electrical distribution network, is used as the linked physical processes.

13. The 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. The 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 control 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.