Method and systems for designing drive systems

Description

[0001] Description

[0002] Methods and systems for designing drive systems

[0003] Regardless of the grammatical gender of a particular term, persons with male, female or other gender identities are included.

[0004] The present disclosure relates to a computer-aided method and a system for designing at least one drive system which directly influences a control system and thus controls, in particular regulates, a process (in this case - controlled system), wherein the drive system and the control system together form an overall system.

[0005] Furthermore, the present disclosure relates to a computing device comprising an engineering platform configured to execute or orchestrate the aforementioned method.

[0006] Furthermore, the present disclosure relates to a computer program comprising instructions which, when executed by the aforementioned computing device, cause the latter to carry out the aforementioned method.

[0007] Furthermore, the present disclosure relates to a machine-readable medium comprising such a computer program.

[0008] The design of a drive system or its subsystem (object, such as a converter, motor, etc.) can be very complex. The goal is usually optimization based on selected criteria (cost, performance, especially the response time of a controlled variable, energy consumption, space requirements, etc.). This includes both the selection of the right components and the selection of the right combination.

[0009] Before a system can be automated or built, it must be designed. This involves selecting appropriate system components for the task to be solved by the automation system—i.e., a system that includes automation components. This includes the design of the drive systems for the system components.

[0010] The design depends on a specific application scenario such as support for commissioning, support for diagnosis, support for training measures, etc.

[0011] Typically, this optimization is based on static data, i.e. catalog or nameplate data, etc., which are not updated and do not depend on the operating behavior of the drive system and / or the dynamics in the application scenario. A particular disadvantage is that optimization based on (dynamic) system properties is not possible. A known example is a design with only one optimization criterion (size or price). In this case, the design cannot be automated, or can only be automated incompletely, because the validation of the design only takes place with the actual device or is left to the imagination and experience of the user.

[0012] Calculation results obtained using digital twins of the drive systems that can be integrated into simulation tools can also be used for the design.

[0013] A digital twin of a drive system is essentially a virtual representation of the actual drive system and can preferably be designed to be real-time capable, for example if it is updated in real time using data obtained from sensors and other data sources. This digital twin can be based on a variety of data sources, such as operating data, design drawings and models, maintenance histories, and other information collected over the life of the drive system. The digital twin can enable a variety of functions, such as monitoring, simulating, and predicting the performance and condition of the drive system. It can also serve as a digital model for optimizing maintenance processes and improving performance.In addition, it can also help reduce downtime and maintenance costs by detecting potential problems early and recommending appropriate actions. It can also be used to improve drive system efficiency by identifying and suggesting optimal operating conditions and monitoring performance over time.

[0014] In addition, a digital twin of the drive system can provide a powerful way to optimize the performance and efficiency of the drive system while reducing maintenance costs.

[0015] In the context of the present disclosure, the digital twin of a drive system is understood to be a simulation model of the drive system, which can be in the form of an FMU model (FMU = Functional Mock-up Unit) - e.g. as an . fmu file, with which at least one selected partial aspect of the behavior of the drive system can be simulated.

[0016] Such FMUs can be linked together via so-called Functional Mock-up Interfaces, or FMIs for short (see https: / / fmi-standard.org / ). FMI is a standard interface for the exchange of model-based simulations between different simulation tools and environments. FMUs comply with the FMI standard but can, in principle, be connected via other interfaces or integrated into other environments.

[0017] FMI defines a standardized data format for model-based simulations based on XML and binary files. It enables the exchange of model components and their connections between different simulation environments and tools. It enables the creation of complex systems from different components and models that can be embedded in different simulation environments and tools.

[0018] In particular, EMI supports dynamic (time-based) models based on various mathematical descriptions, such as differential equations, state machines, event-driven systems, and more. Interfaces can also be defined in EMI that enable data exchange between model components and their control by the simulation environment.

[0019] Today, design using digital twins is largely carried out singularly. This means, for example, that the linking of various tools and the digital twins, or the digital twins themselves if multiple drive systems are to be designed, is done manually. For example, a snapshot of the load behavior for a drive system (control unit with the electric rotating machine) can be the main input variable for the design. The user must manually evaluate several of these snapshots separately in the design tool and determine the optimal design themselves.

[0020] Even in more complex systems that may include multiple drive systems, the user must manually evaluate the individual systems (for example, for the design of a feed-in for a multi-axis system or parallel connection of feed-ins and the interactions of the network-side filter modules).

[0021] The present disclosure is therefore based on the object of providing methods and systems for the design of drive systems, which are faster and easier to handle than the existing design methods and systems and at the same time provide more accurate design results. This object is achieved with a computer-aided method mentioned above for designing at least one drive system, i.e., for determining parameters of the real drive system, wherein

[0022] Sl : a configurable digital twin of the drive system - a drive twin - and a predefined configurable model of the control system - a system model - are provided,

[0023] S2 : the drive twin is linked to the system model to form an executable digital twin of the overall system - an overall twin - whereby the drive twin is parameterized during linking, which defines a start parameter set of the drive twin,

[0024] S3 : the overall twin is executed to simulate the behavior of the entire system and thereby obtain simulation results,

[0025] S4 : the drive system of the overall system is designed according to the start parameter set,

[0026] S5 : the simulation results are compared with the behavior of the overall system,

[0027] S 6 : if the behavior of the overall system deviates from the simulation results, at least the drive twin is optimized with regard to a predetermined optimization goal by varying one or more parameters from the start parameter set ( 110 ) related to the predetermined optimization goal in order to minimize the deviation of the behavior of the overall system ( 103 ) from the simulation results ( 113 ), whereby an optimized parameter set of the drive twin is obtained,

[0028] S7: The drive system of the entire system is designed according to the optimized parameter set. In this process, an optimized drive system is defined / created for the control system.

[0029] An executable digital image of the drive system that describes its behavior, i.e., its digital twin represents a simulation that is parameterized with the same parameters as the real system.

[0030] Thus, the term “parameter” can be a software and hardware property.

[0031] In other words, everything that can be adjusted in a model (drive twin, overall twin) is a parameter. In a real drive, "parameter" can refer to a specific piece of data from the control software. Thus, the optimized parameter set can be available in the form of an (optimized) configuration file for the drive software and / or a suggestion for using a more optimal motor, and can be used accordingly in the real drive system.

[0032] From the simulation point of view, these are both - pro ect file for the drive software and description of the parameters of an optimal motor - parameters.

[0033] The drive system directly influences the control system. This also includes cases in which the drive system acts as a "disturber" of the control system. This can be the case in particular with mains interference (conducted EMC). This must be assessed according to various standards and guidelines (e.g. DIN 61000-4-7). In such a case, the procedure described here can be used to demonstrate conformity to such standards. In this context, the drive system, for example the converter, interferes with the mains, and it must be demonstrated that certain interference levels are maintained in order to accept the side effect of the drive system's influence on the mains.

[0034] The linking of the drive twin with the plant model can be done, for example, in a design, simulation or engineering tool.

[0035] After the linking, a simulation of a controlled operation can basically take place (drive system controls the process), in which the drive system, for example, influences the temperature of an environment or is operated in U / f operation.

[0036] Once linked, the drive twin can exchange data with the system model and, for example, act as a control loop. This allows controlled operation to be simulated.

[0037] In one embodiment, it may be provided that multiple drive systems are designed, whereby several drive twins can be linked to each other and / or to the system model. It may be provided that different drive systems should control and, in particular, regulate different processes, whereby the processes can influence each other.

[0038] In summary, the overall twin can comprise a plurality of drive twins and route models that are linked to each other in a specific manner defined by the application scenario.

[0039] Preferably, a drive system is designed as an electronic control unit, for example as a converter, in particular as a frequency converter.

[0040] In one embodiment, it can be provided that the drive system additionally comprises an electric rotary machine, preferably an electric motor, for example a synchronous motor (due to higher dynamics) or asynchronous motor.

[0041] In particular, it can be provided that the electronic control unit is coupled to the electric rotary machine in order to supply it with current and voltage with certain predeterminable characteristics (amplitude, frequency, etc.). Such drive systems (electronic control unit and electric rotary machine) are well known in the field of automation technology and are used, for example, to set mechanical devices in an automation system in motion. For this purpose, the drive systems can drive the axes of a machine tool or a robot arm, pumps (hydraulic drive), conveyor belts, etc., which is why they are often also referred to as "drives."

[0042] In other words, drive trains have a wide range of uses. A non-exhaustive list of applications includes motion control; electromechanical drive systems in machine tools; machine tool drives; DC motor applications on the intermediate circuit; battery management; grid-side applications, for example, to ensure the correct design of line filters; and much more. The electronic control unit, such as the converter, can then be controlled, regulated, or act as an interfering factor in these processes. A corresponding optimum can be simulated in each of these scenarios using the Digital Twin, and an optimal control strategy or minimal interference, etc., can be determined.

[0043] The starting point of the design (first rough design, first design stage), which leads to the determination of the start parameter set, can be an environment model (programmable logic controller (PLC), application (mechanics), supply network, other drives, DC rail / DC application, cooling medium...) in a time-based simulation language (optionally integrated in the design tool) in order to enable a simulation-based problem description. Which parts are specifically located in the environment model and which in the object of the drive system to be designed can be left open. For example, the PLC can also be located in the drive twin and stored at various abstraction levels (e.g. as fuzzy logic...).

[0044] In one embodiment, steps S3 to S7 can be repeated at least once. The optimized parameter set is used as the initial or starting parameter set for each repetition – the next or second design stage. In particular, a mathematical optimization method can be used for the design if it is represented as an optimization problem of a multidimensional function.

[0045] In one embodiment, it may be provided that optimization is carried out with regard to different optimization objectives at different repetitions (in different design stages).

[0046] At each repetition, it may be useful to simulate the drive twin and, preferably, the simulation models with the same or a more detailed environment model and check them against definable quality criteria. This may be necessary depending on the target criteria.

[0047] In addition, during the iterative design process described here, there may be suggestions for modifying the surrounding model in order to achieve better performance with regard to the optimization criteria of the overall twin (e.g., a recommendation to change the load or travel profile, etc.). For this purpose, it may be useful to define which parameters of the surrounding model are subject to tolerances.

[0048] In one embodiment, it can be provided that the drive twin is configurable with regard to its level of detail and / or the system model is configurable with regard to its level of detail, wherein the level of detail of the drive twin and / or the system model is changed immediately before or during the optimization, wherein preferably the number and / or type of connection points and / or sampling rates are adjustable.

[0049] The level of detail of a model refers to the amount and accuracy of information incorporated into the model. A highly detailed model contains a large amount of information that is specific and detailed, while a slightly detailed model contains only basic information.

[0050] A model with a higher level of detail is typically more complex and accurate because it incorporates more specific variables and factors. However, a higher level of detail can also result in greater computational complexity and potentially make the model more difficult to understand and interpret.

[0051] The level of detail depends fundamentally on the application of the model and what information is relevant to the specific problem. In some cases, a slightly detailed model may be sufficient, while in other cases a higher level of detail is necessary to obtain accurate results.

[0052] In this case, it may be necessary to adapt the level of detail of the drive twin and / or the plant model to each design level. This can mean either a more in-depth analysis (if more detail is required) or a more generalization of sub-aspects (if details are not important).

[0053] For example, it may be planned to increase the level of detail of the plant model (before or during optimization) by adding additional information (e.g., details on mass distribution in the drive train, loss resistances in the lines, flow channels in the cooling system, etc.). This results in a refinement of the plant model. The information required and thus the amount of additional information may depend on the previous design stage.

[0054] It can be useful if the drive twin is configurable with regard to its level of detail and the route model with regard to its level of detail, and during optimization the level of detail of the drive twin is adapted to the level of detail of the route model or vice versa.

[0055] In one embodiment, it can be provided that the drive twin comprises several parameterizable, interconnectable, coordinated or compatible simulation models.

[0056] It may also be provided that the level of detail can be adjusted for each simulation model, e.g. in the corresponding domains.

[0057] In this case, "coordinated or compatible" means, among other things, that when these simulation models are linked, certain values ​​are pre-assigned. In this case, the threshold values ​​may change, or certain parameters may have different tolerance limits.

[0058] In one embodiment, it may be provided that different simulation models are assigned to different simulation domains.

[0059] In one embodiment, it may be provided that each simulation model is a stationary (time-independent) or dynamic (time-based) simulation model.

[0060] In one embodiment, the simulation model can be a thermal simulation model, an electrical simulation model, a mechanical simulation model, a magnetic model, an acoustic model, an information technology model, for example an information electromagnetic model or a control technology model, or a combination thereof. In particular, the simulation model can be designed as a combination of an information electromagnetic model and a closed current control loop. The selection of the appropriate drive twin or the appropriate simulation models, e.g., during the rough design can be made on the basis of the interfaces and the known information. This selection can be made on the basis of a knowledge base of existing designs under similar boundary conditions (with an indication of the degree of fulfillment) (for example using generative neural networks).

[0061] It can be planned that several variants of the drive twin are investigated ( e . g . in parallel ). In doing so, different motor variants, converter sizes, SW options, etc . can be investigated which satisfy the specified boundary conditions defined by the plant model. The variation can be controlled using known methods of global nonlinear optimization with constraints ( e . g . nature-analogous methods (evolutionary, swarm-based algorithms) ). For example, by varying a starting design ( different starting parameter sets ) and applying a genetic algorithm in several steps, a new starting design ( optimized starting parameter set ) can be found, with which it can be proceeded to the next level of detail ( design level ).In other words, this design can be carried out up to a termination criterion (e.g., the drive selection does not change any further) in order to cover various scenarios of the surrounding system. The determined, optimized start parameter set can then be transferred to the drive twin, creating a drive twin with a higher level of detail. Several of these higher-level-of-detail DTs can also exist, running in parallel (e.g., different simulation domains) or serially (e.g., with ever-increasing levels of detail).

[0062] In one embodiment, it can be provided that the control path additionally has at least one feedback.

[0063] Open loop control is a type of control without feedback. Feedback in control engineering refers to the process of feeding back a portion of a system's output signal to modify the input signal and thus regulate the system's behavior. Specifically, this means that the system's output signal (e.g., the speed of a motor) is compared with a setpoint specified by the user or by the system itself. If there is a deviation between the output signal and the setpoint, an error is detected, and a correction signal is generated and applied to the system's input signal. The result is a control loop that continuously adjusts the system's behavior to achieve and maintain the setpoint.

[0064] In one embodiment, it may be provided that the simulation results include information about an interaction behavior of the drive twin with the plant model.

[0065] In other words, the simulation of the entire twin results in information about the interaction behavior of the drive twin with the environment model (plant model). This information can include, for example, a drive load profile, the effect of different multi-axis operations on one or parallel feeds, and the surrounding system.

[0066] This information or the interaction behavior can serve as a basis for the subsequent design steps.

[0067] It can be provided that the design process, for example at each design stage, provides feedback on how far the drive twin can still be refined.

[0068] The aforementioned simulation (of the entire twin or its parts) can be performed on external resources, e.g., on a cloud platform. This advantageously allows variants to be calculated in parallel without increasing the time required. In summary, the disclosed method utilizes different levels of detail of drive twins to offer a solution to a given problem with regard to predefined optimization criteria. The design process via variant creation can also be integrated into an iterative detailing of the model.

[0069] The invention is explained in more detail below using exemplary embodiments. In the following:

[0070] FIG 1 a system for designing a drive system,

[0071] FIG 2 shows a flow chart of a method for designing a

[0072] drive system, and

[0073] FIG 3 possible embodiment of the optimization step of FIG 2 .

[0074] The reference symbols used in the figures are intended solely to improve readability and are not to be interpreted as limiting. The same reference symbols in different figures designate essentially the same elements or objects.

[0075] FIG. 1 shows a (not yet designed) drive system 100, which is intended to become part of an automation system (not shown here) (after design). The drive system 100 can be designed as an electronic control unit 100a, for example, a converter, in particular a frequency converter.

[0076] In addition, the drive system 100 may additionally comprise an electric rotary machine 100b, preferably an electric motor, for example an asynchronous motor.

[0077] The electronic control unit can be connected to the electric rotating machine in order to supply it with current and voltage with certain adjustable characteristics (amplitude, frequency, etc.) and thus, for example, to reduce or increase its torque to the required level in order to meet the requirements of the application.

[0078] Such drive systems can, for example, drive the axes of a machine tool or a robot arm, pumps (hydraulic drive), conveyor belts, etc., which is why they are often referred to as "drives" or "drive trains".

[0079] The drive system 100 directly influences a (real) predetermined process 101. In control engineering, a process is often used as a synonym for the term control system.

[0080] The application can, for example, support commissioning, support diagnosis, support training measures, etc.

[0081] The direct influence of the drive system 100 on the process 101 is indicated by an arrow 102.

[0082] Together, the drive system 100 and the process 101 form an overall system 103.

[0083] Additionally or optionally, the process 101 may have a feedback 104. A control system (control path) with a feedback is called a closed-loop control (control path or control loop).

[0084] For example, digital twins can be used to gain knowledge about the requirements placed on the drive system 100 by the process 101 before the automation system is put into operation.

[0085] In the present case, a digital twin of the drive system 100—a drive twin 105—and a model of the control system 101—the system model 106—are provided. These are preferably implemented, for example, as separate software modules that can be linked to one another, for example, via EMI (Functional Mock-Up Interface).

[0086] A link can be established, for example, in a configuration / parameterization tool or a design tool or an engineering tool 107 of an engineering platform. The link creates a digital twin of the entire system 103—the overall twin 108.

[0087] The link is not a purely application-related connection, but rather enables a data exchange 109 between the models, i.e., between the drive twin 105 and the system model 106.

[0088] The drive twin 105 can be selected, for example, based on the interfaces and known information regarding the specific application. This selection can be made from a knowledge base of existing designs under similar constraints (with an indication of the degree of fulfillment), for example, using generative neural networks.

[0089] The aim of the design is to find a drive system 100 suitable for the process 101 .

[0090] The system model 106 is specified by the application or by the process 101. The system model 106 can describe one or more of the following applications: PLC, application (e.g., mechanics), supply network, other drives, DC rail, cooling medium, and many more.

[0091] Preferably, the plant model 106 is available in a time-based simulation language (optionally integrated in the design tool 107) to enable a simulation-based problem description. Both the working twin 105 and the plant model 106 are configurable.

[0092] The drive twin 105 can comprise a plurality of parameterizable, interconnectable, and coordinated simulation models 105a, 105b, 105c, 105d, 105e, wherein different simulation models 105a to 105e are preferably assigned to different simulation domains. The drive twin 105 can therefore comprise, for example, one or more of the following models 105a to 105e: thermal simulation model, electrical simulation model, mechanical simulation model, information technology model (for simulating control, logic, data pre- / post-processing, etc.), a magnetic model, an acoustic model. In particular, the simulation model can be designed as a combination of the information electromagnetic model and a closed current control loop.

[0093] In this context, "coordinateable" primarily means that when different simulation models are linked together, certain values ​​of the parameters of the simulation models 105a to 105e are coordinated with each other and pre-assigned accordingly. Compared to the unlinked simulation models 105a to 105e, this may mean, for example, that certain parameters have different threshold values ​​and / or tolerance limits.

[0094] Each simulation model 105a to 105e can be implemented as a static (time-independent) or as a dynamic simulation model, which enables a time-based simulation. This can, for example, allow for the consideration of speed control behavior or network harmonics.

[0095] The selection of the appropriate simulation models 105a to 105e can be made, like the selection of the drive twin 105 described above, based on the interfaces and the known information about the process 101 or the plant model 106. This selection can be made on a knowledge base of existing designs under the same or similar boundary conditions (preferably with an indication of the degree of fulfillment), for example with the aid of generative neural networks.

[0096] Furthermore, the drive twin 105 can be configured with regard to its level of detail. This means, for example, that each simulation model 105a to 105e comprised by the drive twin 105 can also be configured in detail. For example, the number and / or type of connection points and / or the sampling rates can be adjustable.

[0097] In addition, the route model 106 can also be configurable with regard to its level of detail.

[0098] In other words, the drive twin 105 and / or the system model 106 can be designed in such a way that their refinement or coarsening can be carried out at any time.

[0099] In particular, the level of detail of the drive twin 105 and the level of detail of the system model 106 or vice versa can be adapted.

[0100] In summary, during linking, the drive twin 105 is first parameterized. One or more simulation models 105a to 105e matching the system model can be selected in the drive twin 105. This defines a start parameter set 110 for the drive twin 105. The start parameter set 110 can be used directly to design the drive system 100. In other words, the first linking can be used to perform an initial "rough design" of the drive 100.

[0101] A possible initial parameterization can, for example, result from automatic controller settings (and, if necessary, with targeted additional inputs) (e.g., one-button tuning).

[0102] In other words, the focus in the first step of the rough design should be on the realization of the desired function of the application scenario, but not on the limitations of the potential solution portfolio.

[0103] In this case, one or more low-level-of-detail models 105a to 105e (generic digital twins) can be selected from the drive twin 105 and parameterized to the extent known from the drive system 100.

[0104] With the (now parameterized) overall twin 108, a simulation of the entire system 103 is possible. A simulation, in which the influence 102 of the drive system 100 on the process 101 and preferably also the feedback 104 are simulated (arrows 111, 112), is carried out, and simulation results 113 are thereby obtained. One or more closed control loops 112 can be simulated. The simulation results 113 can be present, for example, in the form of a load curve or multiple load curves for actual load over time.

[0105] In this case, several variants can be investigated (for example in parallel) thanks to the selectability and / or configurability of the drive twin 105 and its simulation models 105a to 105e. For this purpose, for example, motor variants, converter sizes, and (company) software options can be varied provided they satisfy the specified boundary conditions anchored in the specified process 101 or plant model 106. The variation can be controlled using known methods of global nonlinear optimization with constraints (for example, nature-analogous methods (evolutionary, swarm-based algorithms)). For example, by varying the initial or rough design and applying a genetic algorithm in several steps, a new initial design can be found, which can be used to proceed to the next level of detail.

[0106] The simulation of the drive twin 105 (or its parts 105a to 105e) or of the entire twin 108 can be performed internally, i.e., within the automation system, or on external resources, e.g., using a cloud infrastructure. Advantageously, variants can be calculated in parallel without increasing the time required.

[0107] The simulation results 113 may include information about the interaction behavior of the drive twin 105 with the plant model 106. These may include at least one of: the drive's load profile; the effect of different multi-axis operations on one or parallel feeds and the surrounding system, etc.

[0108] This interaction behavior can form the basis for the subsequent design steps (see below).

[0109] Alternatively or additionally, the interaction behavior can be used to investigate the effect of the change in the system model 106 on the drive twin 105, i.e. on its parameterization.

[0110] In other words, a low-level simulation (rough design) of the overall twin 108 can be initiated and executed up to a certain termination criterion, for example, until the drive selection (the parameterization of the drive twin 105) no longer changes. This covers various scenarios of the surrounding system 106. In this case, it is not necessary to restrict oneself to a worst-case scenario which, in turn, depends on empirical values, but rather to deliberately keep the solution space open. The parameterization achieved in this way can be used as a start parameter set 110, for example, to re-parameterize the drive twin 105. Subsequently or parallel to the simulation, the behavior of the overall system 103 is also investigated, with the drive system 100 of the overall system 103 having been designed according to the start parameter set 110. Real (experimental) data 114 on the behavior of the overall system 103 is collected.

[0111] The simulation results 113 are compared 115 with the data 114 that characterize the behavior of the overall system 103.

[0112] As a rule, the behavior of the overall system 103 during the first rough design deviates from the behavior of the overall twin 108, so that the simulation results 113 do not agree with the measured values ​​114.

[0113] At this point, the total twin 108 can be calibrated to the real measured values ​​114 in order to ensure the necessary error compensation.

[0114] In a first step, for example, it is achieved that the overall twin 108 behaves sufficiently consistently with the overall system 103, i.e. that the simulation results 113 from the simulation of the overall twin 108 lie, for example, within defined limits and / or meet criteria. This can be achieved by means of a mathematical optimization method in which one or more parameters from the start parameter set 110 are varied. It is understood that varying the parameters from the start parameter set 110 influences the simulation results. During optimization, a search is carried out for those changed, optimized parameters for which the deviation of the simulation results 113 from the behavior of the overall system 103 is the smallest or the simulation results lie, for example, within defined limits and / or meet certain criteria.A conventional optimization method can be used for this, such as Ansys optiSLang, MATLAB's Optimization Toolbox, or Simcenter HEEDS. Typically, the uncertainty of the model increases from the drive controller to the plant model. In other words, the software parameters and controller topology are identical, the configuration and component data of the drive system 100 are known (although they may contain tolerances or be from a third-party manufacturer), but the controlled system 101 has the highest uncertainties. This means that the focus of the system to be calibrated is on the parts of the system that are "furthest away" from the drive system 100.

[0115] However, the deviation can provide insight into which aspects of the overall twin 108 and in particular of the drive twin 103 require optimization.

[0116] The drive twin 105 can therefore be optimized with regard to a predetermined optimization goal 116 by varying those parameters from the start parameter set 110 of the drive twin 105 which are related to the optimization goal 116, and then examining the effect of the variation of the parameters on the simulation results 113 obtained from the simulation of the overall twin 108. In doing so, an optimum, preferably a minimum, can be sought under the condition that the simulation results 113 from the simulation of the overall twin 108 lie within defined limits and / or meet certain criteria. This results in an optimized parameter set 117 of the drive twin 105 which can be used to design the drive system 100. One of many examples of the relationships between parameters and optimization goals is, for example, the power (of the converter) and the costs.

[0117] The optimization can be carried out with regard to various optimization criteria or weighted individual criteria, such as: • Costs,

[0118] • Control accuracy,

[0119] • Control quality

[0120] • Performance, especially in terms of throughput, adjustment time of a controlled variable,

[0121] • Energy consumption,

[0122] • Consequences for the peripherals (available interfaces for auxiliary variables (e.g. cooling or voltage levels)),

[0123] • Space consumption, especially cumulative space consumption,

[0124] • Year of publication,

[0125] • prospective lifespan,

[0126] • prospective maintenance intensity,

[0127] • EMC class,

[0128] • other standard classes,

[0129] • etc .

[0130] These criteria can also be combined and assigned (different) weightings.

[0131] The result could be, for example, a detailed BOM (Bill of Materials) or the pre-commissioned project for transfer to the real drive system 100.

[0132] Immediately before or during optimization, the level of detail of the drive twin 105 and / or the system model 106 can be changed.

[0133] For example, the level of detail of the drive twin 105 or the simulation models 105a to 105e can be selected automatically based on the environment model 106.

[0134] In particular, a refinement (if more details are required) or a coarsening (if certain details are not important at the time) of the drive twin 105 and / or the system model 106 is possible. In this case, an optimization of certain components of the drive twin 105, for example the converter model and / or the model of the electric rotating machine and its operation, can be carried out in order to better adapt the drive twin 105 to the system model 106.

[0135] Furthermore, it may be useful to enrich the system model 106 (before or during optimization) with additional information 118 (for example, details on the mass distribution in the drive train, loss resistances in the lines, flow channels in the cooling system, etc.) or to refine it with the additional information 118. Furthermore, a calibrated model, for example, using field data, or a model from component suppliers can be considered as additional information here.

[0136] The optimized parameter set 117 is then used to design the drive system 100. This results in an optimized or optimally designed drive system 100 for the control system 101.

[0137] The optimized parameter set 117 (or a copy thereof) can also be saved for later use during operation. The optimized parameter set 117 can, for example, be transferred to the drive twin 105 or to another digital twin for later use, for example, during operation.

[0138] In other words, a drive system 100 is now available at the next design stage. When the optimized parameters 117 are transferred to the drive twin 105 or to another digital twin, a higher-level-of-detail digital twin is obtained, which can, if necessary, parameterize the drive system 100 during (automated) commissioning. Several of these higher-level-of-detail digital twins can also be created, which can be used simultaneously / side by side (e.g., as different simulation domains) or can build on one another serially (e.g., with an ever-increasing level of detail).

[0139] The aforementioned steps—simulation, testing, optimization, and transferring optimization results to the drive system 100—can be repeated as often as desired (see S70 in FIG. 2). The optimized parameter set from the previous design stage is used as the initial parameter set.

[0140] In addition, the optimization objective can be redefined for each iteration. Furthermore, the level of detail of the drive twin 105 and / or the plant model 106 can be changed or adjusted. This allows optimization to be performed with respect to different optimization objectives at different iterations. The information required for the drive twin 105 and / or the plant model 106 can depend on the previous design level.

[0141] At each repetition, it may be useful to simulate the drive twin 105 and preferably the simulation models 105a to 105e with the same or a more detailed environment model 106 and check them against definable quality criteria. This may be necessary depending on the target criteria.

[0142] Based on the results from the repetition, the design cycle can be further refined iteratively until an appropriate termination criterion is available.

[0143] In addition, the result of the simulation with the overall twin 108 can provide information on changing the environmental model 106 in order to achieve better quality with regard to the optimization criteria of the overall twin 108 (e.g., recommending a change to the load profile, the properties of the travel profile, or similar). For this purpose, it can be useful to define which parameters of the surrounding model are subject to tolerances (probablistic design / stochastic approach Sören). With the iterative approach to evaluating alternative variants of a system, a sensitivity analysis can also be performed, the results of which can also be used to make trade-off assessments on the requirements side. This can be used to define an improved offer in the portfolio. E.g., "If the tolerance for the value 'x' can be reduced, then the energy consumption will decrease by 'y' - is this an option in the portfolio?"

[0144] FIG. 2 shows a flowchart of a design method for a drive system, for example, for the drive system 100. In this respect, FIG. 2 can be viewed as a summary of the steps already described in connection with FIG. 1.

[0145] In a step S 1, a configurable digital twin of the drive system 100 - the drive twin 105 - and a configurable model of the control system 101 - the system model 106 - are provided.

[0146] In a step S2, the drive twin 105 is linked to the system model 106 to form an executable digital twin of the overall system 103—the overall twin 108. Linking means that the twins can exchange data. During linking, the drive twin 105 is parameterized. After parameterization, a start parameter set 110 of the drive twin 105 is available, which can serve as the first rough design of the drive system 100.

[0147] In a step S3, the behavior of the overall system 103 is simulated by executing the overall twin 108. This generates simulation results 113.

[0148] The following steps describe a verification of the simulation results, which can be carried out iteratively until the desired result is achieved. Several design stages (iterations) may be necessary to arrive at the desired result. "The desired result" is usually implemented as a predeterminable termination criterion. If the criterion is met at a design stage, the simulation results available at this stage are considered verified. The corresponding parameter set can be used to design the drive system 100.

[0149] Thus, in a step S4, the drive system 100 of the overall system 103 is first designed according to the start parameter set 110 - the rough design is carried out.

[0150] In a step S5, the simulation results 113 are compared with the behavior of the overall system 103.

[0151] In a step S 6 , it is first checked whether the behavior of the overall system 103 deviates from the simulation results 113 , which is usually often the case during the first rough design .

[0152] If no deviation is detected, the start parameter set 110 is already considered verified and can be used to design the drive system 100 - step S 60 . In this case, the design ends after the start parameter set 110 has been adopted - step S 61 .

[0153] If a deviation is detected, it can be analyzed to determine where optimization is needed. For example, it can be investigated whether there is a specific domain (electrical, thermal, mechanical) where the simulation does not match the experimental data 114, or whether there are other selected parameters of the drive 100 that contribute to suboptimal control of the process 101.

[0154] In any case, the drive twin 105 is optimized with respect to an optimization goal, whereby the optimization goal can be determined and defined based on the analysis of the deviation. It may be expedient to change the level of detail of the drive twin 105 and / or the system model 106 in order to obtain better optimization results.

[0155] For example, the following substeps are possible (see FIG. 3). In step S6a, for example, only the level of detail of the drive twin 105 is changed, without changing the level of detail of the system model 106. Conversely, in step S6b, for example, only the level of detail of the system model 106 is changed, without changing the level of detail of the drive twin 105. It is also conceivable that the level of detail of both the drive twin 105 and the system model 106 is changed.

[0156] The change can be a refinement or a coarsening of the aspects of the corresponding models.

[0157] For example, the number and / or type of connection points and / or sampling rates of the models can be changed.

[0158] Furthermore, changing a model, e.g., the drive twin 105, may also make it necessary to adapt the system model 106. In this case, the level of detail of the system model 106 is adapted to the level of detail of the drive twin 105 - step S6c.

[0159] The reverse case is also conceivable, in which - as in step S6d - the level of detail of the drive twin 105 is adapted to the level of detail of the route model 106.

[0160] Within the scope of this optimization S6, preferably S6a, S6b, S6c, or S6d, an optimized parameter set 117 is generated for the drive twin 105 (see FIG. 3), with which the drive system 100 can be designed. In a step S7, the drive system 100 of the overall system 103 is designed according to the optimized parameter set 117. This creates an optimized drive system 100 for the control path 101.

[0161] Now, the optimized parameter set 117 can also be verified. For this purpose, the aforementioned steps are repeated starting with step S3 - S70, whereby the drive twin 105 is parameterized with the optimized parameter set 117 and not with the start parameter set 110 for simulation purposes.

[0162] The configuration or parameterization tool 107 can be stored in a computing device (not shown here) and executed by it. The computing device can be configured, for example, as a system of computers communicating with each other, e.g., as a cloud infrastructure.

[0163] The computing device comprises an engineering platform. The engineering platform can comprise and execute a configuration or parameterization tool 107. In this case, the engineering platform comprises a corresponding solver for executing the aforementioned models.

[0164] The aforementioned models and in particular the overall twin 108 can also be executed as a co-simulation in the computing device. This means that the models are not executed by the engineering platform and are not designed as part of the engineering platform. In this case, inter-process communication takes place between the engineering platform and, for example, the overall twin 108 or a part of the overall twin 108, e.g. the drive twin 105 or plant model 106. During this inter-process communication, the engineering platform executes a sub-process which supplies one or more of the aforementioned models (e.g. the overall twin 108, the drive twin 105, the plant model 106, etc.) with the information required for the simulation and preferably orchestrates the simulation.The engineering platform does not contain a solver responsible for processing the corresponding model(s). In particular, the solver can run on a remote computer, e.g., in the cloud.

[0165] The purpose of this description is merely to provide illustrative examples and to indicate further advantages and special features of this invention. Thus, it cannot be interpreted as a limitation of the field of application of the invention or of the patent rights claimed in the claims. In particular, the features disclosed in connection with the methods described herein can be usefully used to further develop the systems described herein, and vice versa.

Claims

Patent claims 1. Computer-aided method for designing at least one drive system (100) which directly influences (102) a control path (101), wherein the drive system (100) and the control path (101) together form an overall system (103), wherein (51) a configurable digital twin of the drive system (100) - a drive twin (105) - and a predetermined configurable model of the control system (101) - a system model (106) - are provided, (52) the drive twin (105) is linked to the system model (106) to form an executable digital twin of the overall system (103) - an overall twin (108), wherein the drive twin (105) is parameterized during the linking, whereby a start parameter set (110) of the drive twin (105) is determined, (53) the overall twin (108) is executed to simulate the behavior of the overall system (103) and thereby obtain simulation results (113), (54) the drive system (100) of the overall system (103) is designed according to the start parameter set (110), (55) the simulation results (113) are compared with the behavior of the overall system (103), (56) if the behavior of the overall system (103) deviates from the simulation results (113), at least the drive twin (105) is optimized with respect to a predetermined optimization goal by varying one or more parameters from the start parameter set (110) related to the predetermined optimization goal in order to minimize the deviation of the behavior of the overall system (103) from the simulation results (113), whereby an optimized parameter set (117) of the drive twin (105) is obtained, (57) the drive system (100) of the overall system (103) is designed according to the optimized parameter set (117).

2. The method according to claim 1, wherein steps S3 to S7 are repeated at least once (S70).

3. The method according to claim 2, wherein optimization is carried out with regard to different optimization objectives in different repetitions.

4. The method according to claim 1 to 3, wherein the drive twin (105) is / are configurable with regard to its level of detail and / or the route model (106) is / are configurable with regard to its level of detail, wherein the level of detail of the drive twin (105) and / or the route model (106) is changed during the optimization (S6a, S6b).

5. The method according to claim 4, wherein the number and / or type of connection points and / or sampling rates of the drive twin (105) and / or the route model (106).

6. The method according to claim 4 or 5, wherein the drive twin (105) is configurable with regard to its level of detail and the route model (106) is configurable with regard to its level of detail, and wherein during the optimization the level of detail of the drive twin (105) is adapted to the level of detail of the route model (106) or vice versa (S6c, S6d).

7. The method according to one of claims 1 to 6, wherein the drive twin (105) comprises a plurality of parameterizable, interconnectable, and mutually tunable simulation models (105a to 105e).

8. The method according to claim 7, wherein different simulation models (105a to 105e) are assigned to different simulation domains.

9. The method according to claim 7 or 8, wherein each simulation model (105a to 105e) is a stationary or dynamic simulation model.

10. The method according to claim 9, wherein the simulation model (105a to 105e) is a thermal simulation model, an electrical simulation model, a mechanical simulation model, a magnetic model, an acoustic model, an information technology model, for example an information electromagnetic model or a control technology model or a combination thereof.

11. Method according to one of claims 1 to 10, wherein the control path (101) additionally has at least one feedback (104).

12. The method according to any one of claims 1 to 11, wherein the simulation results (113) comprise information about an interaction behavior of the drive twin (105) with the system model (106).

13. Computing device comprising an engineering platform configured to execute or orchestrate a method according to any one of claims 1 to 12.

14. A computer program comprising instructions which, when executed by a computing device according to claim 13, cause the computing device to carry out a method according to any one of claims 1 to 12.

15. A machine-readable medium comprising a computer program according to claim 14.

Images