GB2616058A - Computer-Implemented Methods of Executable workflow Generation - Google Patents

Abstract

The invention lies in the field of “Multi-disciplinary Analysis and Optimisation” which concerns the integration of multiple sub-models to model a larger system. There is provided a computer-implemented method of generating an executable workflow. The method generates a workflow which generates a graph with three nodes: a first node corresponding to an output global variable desired by a user; a second node corresponding to a model which produces said output; and a third node corresponding to the input for the model. The first input is determined to be assigned to a first scope with the output, or to a second scope different to the first scope. By assigning an input or output variable to the proper scope, a variable corresponding to some physical entity is used consistently by the various sub-models which act on it, resulting in a more accurate model. The correct use of scope can avoid undesirable “loops” in which two sub-models pass each other the same data through a closed loop of the graph. This is alleged to make the assembly of the workflow more efficient, and the create workflows which are in themselves more efficient to execute

Description

Computer-Implemented Methods of Executable Workflow Generation Technical Field The present application relates to computer-implemented methods of generating executable workflows in the field of "multi-disciplinary analysis and optimisation" (MDAO), which concerns combining analysis tools of different engineering domains together to perform more useful analyses.

MDAO, in the broadest sense, relates to the combination of analyses in different domains to solve and/or optimise technical solutions to problems which involve multiple computer models which span different disciplines. For example, in the field of electric vehicles, an optimised vehicle design may be reliant on a number of significant components which may be modelled for different physical processes. In an electric vehicle, the choice and design of battery will influence other vehicle parameters such as weight and size. The cooling requirements of the choice and design of battery may also affect the weight, size and energy consumption of a cooling system. In turn, the size and weight of the battery and cooling system may affect the overall size and weight of the vehicle which will affect vehicle characteristics such as handling and top speed. In order to optimise or design for a particular vehicle characteristic, such as a desired top speed, many different computer models simulating the various physical conditions of electrical, thermal, mechanical, and fluid dynamic systems within the vehicle may need to be updated. These various models may rely on a multitude of inputs which are common across the models and some inputs which are unique. Arranging the multitude of models and ensuring that common parameters are defined sensibly so that an overall simulation may be more effectively run is a non-trivial exercise even at a small scale. When the number of models and parameters ends up in the hundreds or thousands, the problem of preparing an effective global simulation is even more difficult to achieve. What is needed is an improved method of generating an executable workflow for a global simulation which can be effectively run where multiple models and parameters are involved.

Summary

Aspects of the present invention are set out by the claims.

Aspects of the present disclosure provide a computer-implemented method of generating an executable workflow, comprising: a. receiving a request for a first global variable to be output from a first scope of a workflow graph; b. defining the first global variable as a first node in the workflow graph; c. selecting a first model from a model repository, wherein the first model produces the first global variable as an output after the first model has received at least a first input; d. defining the selected first model as a second node in the workflow graph, wherein the second node is connected to the first node via a directed edge, and wherein the second node is assigned to the first scope; e. determining, either: i. that the first input be assigned to the first scope, or ii. that the first input be assigned to a second scope different from the first scope; f. defining the first input as a third node in the workflow graph, wherein the third node is connected to the second node via a directed edge; and g. generating an executable workflow based on the workflow graph. Whilst the method is generally described in the context of single inputs, single outputs, or at least a first input for example, the skilled person will appreciate that the method is applicable and scalable to models, sub-models, workflow graphs, and sub-graphs which may include a plurality of inputs and/or a plurality of outputs. It will be appreciated that models and sub-models may vary in complexity from those which provide a single output in response to a single input, to complex models which produce a plurality of outputs or large amounts of data and/or require large amounts of data to define the input.

Advantageously, the computer-implemented method may produce an executable workflow based on models which are available in a model repository. By determining the scope of the first input and generating an executable workflow based on the resultant workflow graph, models may be effectively defined to avoid conflicts or other problems which may result in slow running or inaccurate workflows. Determination of the scope to which the first input may be assigned effectively allows the problem to be solved by the workflow to be segmented so that a workflow which solves the problem and is also executable on a computing device may be found. The computer-implemented method may be effective for small problems which only require one or few models or sub-models. However, the method is scalable to larger problems which may require a plurality of models and/or sub-models (for example, tens, hundreds, or thousands of models and/or sub-models).

The computer-implemented method may further comprise: receiving a request for a second global variable; selecting a second model from the model repository, wherein the second model produces the first input to the first model as a first output after the second model has received the second global variable as an input, and wherein selecting the second model comprises determining that the second model produces the first output which is consistent with the first input; defining the selected second model as a fourth node in the workflow graph, wherein the fourth node is connected to the third node via a directed edge; defining the second global variable as a fifth node in the workflow graph, wherein the fifth node is connected to the fourth node via a directed edge.

Optionally, defining the first global variable as a first node in the workflow graph comprises determining that the first global variable already exists in the first scope and defining the preexisting first global variable as the first node in the workflow graph.

Advantageously, the computer-implemented method may prevent duplication of the first global variable within a single scope of the workflow graph. In this way, the first global variable will only take on one value. Should the first global variable be defined as multiple nodes in a single scope of the workflow graph, the first global variable may take on multiple different values. If multiple values within a single scope are given to the first global variable, this may result in failure of the executed workflow. For example, in the case where the first global variable is gearbox losses, and two nodes within a single scope define the gearbox losses, should the value for gearbox losses differ between the two nodes, then any models taking the gearbox losses as an input may be operating using conflicting data.

The computer-implemented method may further comprise: iterating a. tot. multiple times; tracking the models that have been selected between iterations; and tracking the scopes that have been assigned between iterations. Advantageously, by iterating the steps multiple times and tracking the models that have been selected between iterations, the method will be capable of finding a workflow graph which is executable. The method allows for previously used models or models which have been assigned the wrong scope to be discarded or assigned to another scope which is more likely to provide an executable workflow.

Optionally, determining that the first input be assigned to a second scope different from the first scope comprises determining that the workflow graph includes a cycle.

Optionally, determining that the first input be assigned to a second scope different from the first scope comprises determining that the first global variable and the second global variable are not connected by a path through the workflow graph.

The computer-implemented method may further comprise determining whether there is a complete path of directed edges in the workflow graph between the first global variable and the second global variable, and if no complete path can be determined, determining that the first variable be assigned to a new scope. Advantageously, by assigning the first global variable to a new scope, the method may allow for a workflow graph to be defined which is executable. That is, a workflow graph in which there is a complete path of directed edges between the first global variable and the second global variable.

Optionally, the first model is a sub-model comprising: a third model which produces the first global variable as an output after the third model has received a second input; and a fourth model which produces the second input as an output after the fourth model has received the first input. Further optionally, one or more of the first model, second model, third model, and 5 fourth model are sub-models comprising a plurality of models connected as nodes in a sub-graph. Advantageously, sub-models, combinations of other models and/or sub-graphs comprising multiple sub-models and/or models may form part of the current workflow graph. Useful sub-models or sub-graphs may make up a portion of the model repository so that they can be reused in other workflow graphs. By making these sub-models or sub-graphs available 10 in the model repository, the method may settle upon an executable workflow more efficiently.

Optionally, the request is a user-request generated at a user device. Advantageously, the computer-implemented method may provide an executable workflow which solves a user-defined problem. For example, the user may define an output they wish to see at a user terminal, and the computer-implemented method will provide an executable workflow which provides the desired output based on one or more inputs and using the models which are available in the model repository. Should there be no model available in the model repository to provide the user with an executable workflow, the method may further comprise indicating at the user terminal that the required model is not available.

Optionally, the request is a sub-model request for a third scope of the workflow graph, wherein the third scope is different from the first scope and the second scope. Advantageously, the computer-implemented method may interact with other instances of the same method. In this way, nested computation of workflow generation may allow for a complex chain of sub-models to be defined. For example, the method may be provide an executable workflow graph which can be used as part of another workflow graph.

The computer-implemented method may further comprise determining whether there are any cycles in the workflow graph, and repeating the method with an alternative selected for any of 30 the models included the workflow graph for which an alternative is available and for which the alternative has not already been attempted.

The computer-implemented method may further comprise determining that there is an input to the first model for which no models in the model repository produce an output, and repeating 35 the method with an alternative selected first model from the model repository.

Optionally, the executable workflow comprises a plurality of pointers configured to cause one or more computing devices to execute the first model and the second model in order according to the workflow graph. Advantageously, the models in the model repository do not all need to be located or executable in one physical location. Some models may require specialised computing devices or may be limited to operating on a particular device under software licence agreements. In this way, the executable workflow may result in a list of executable instructions to be executed on a single computing device to run the workflow, or the computing device may cause one or more of the models of the executable workflow to be executed on other computing devices to provide the required outputs.

The model repository may comprise computer simulated models of physical processes. 10 Optionally, the computer simulated models are configured to simulate one or more of the mechanical, electrical, fluid dynamic, thermal, and/or chemical characteristics of one or more components of a vehicle.

Optionally, the vehicle is one of an electric car, an electric van, or an electric bus.

In an aspect of the disclosure, there is provided a computer-implemented method of simulating a physical system comprising: receiving an executable workflow generated according to any aspect described herein, and executing the executable workflow on one or more computing system or on a distributed computing system.

Brief Description of the Drawings

Figure 1 is a flowchart of a process according to an embodiment of the disclosure, 25 Figure 2 is a first iteration of a workflow graph; Figure 3 is a workflow graph updated from the workflow graph of figure 2; Figure 4 is a workflow graph updated from the workflow graph of figure 3; Figure 5 is a workflow graph updated from the workflow graph of figure 4; Figure 6 is a diagram of a computing system and model repository according to the disclosure.

Detailed Description

As shown in Figure 1, there is provided a computer-implemented method of generating an executable workflow. The method comprises receiving 101 a request for a first global variable to 40 be output from a first scope of a workflow graph.

A global variable corresponds to any piece of data (defined by a user or otherwise) that could be shared between models. In one example, the global variable may be a global variable which is of interest from a user, and the request is a user-request generated at a user device. A user may define a problem to be solved, or a global variable which is desired to be optimised. For example, a user might define that they wish the top speed of a vehicle to be at least 155 mph. In that case, the first global variable may be the top speed of the vehicle, and the workflow graph may be defined to optimise various vehicle parameters to meet the top speed requirement.

Alternatively, the user may define the problem to be solved as to provide an optimal gear ratio for a particular vehicle. In that case, the first global variable may be the gear ratio of the gearbox.

In another example, the request for the global variable may be in the form of a request of a sub-10 model for a different scope of the workflow graph. In the process of generating the workflow, a sub-model may require an input of the global variable from a different scope of the workflow graph. For example, a driving force model may request the input of a variable of gearbox losses.

The method further comprises defining 102 the first global variable as a first node in the workflow graph. Defining the first global variable in the workflow graph may make the first global variable available in the workflow graph to be connected to other nodes such that an executable workflow may be generated.

The method further comprises selecting 103 a first model from a model repository, wherein the first model produces the first global variable as an output after the first model has received at least a first input. The model repository may comprise a list of models which are available to be executed as part of the executable workflow. For example, the model repository may include a plurality of models relating to various physical simulations of a product, such as an electric vehicle. Models in the model repository may include but are not limited to battery charge models, battery heat models, tyre models, gearbox models, motor power models, driving force models, aerodynamic models, top speed models, and acceleration models.

The models may be further defined by their required inputs and outputs. For example, a driving force model may provide an output of the driving force experienced by an electric vehicle. In order to calculate the driving force output, the driving force model may require inputs of the speed of the vehicle, gearbox losses in the gearbox of the vehicle, and the diameter of the tyres of the vehicle.

Selecting the first model from the model repository may include selecting the first model based on the requirement of the first global variable as an output. The model repository may include only one model which produces the first global variable as an output, in which case that model may be selected. Alternatively, the model repository may include a plurality of models which each produce the first global variable as an output, in which case one of the plurality of models which produce the first global variable as an output may be selected from the plurality of models. Where there are a plurality of models which each produce the first global variable as an output, the method may include selecting a first one of the plurality of models. Alternatively, if in a previous iteration of the method one model of the plurality of models has already been selected, the method may include selecting a model from the plurality of models which is different from the model which has already been selected, but which also produces the first global variable as an output. In this way, when the method is iterated, the workflow may be updated or adjusted to include different models from the model repository which may also provide the first global variable as an output. This may be useful where, for example, there are a plurality of models which all provide the same first global variable as an output but which may require a different array of inputs to calculate the output. In this way, an optimised workflow may be generated by exploring alternative arrangements of a workflow graph.

When the first model has been selected from the model repository the selected first model may 15 be defined 104 as a second node in the workflow graph. Since the selected first model produces the first global variable as an output, the second node may be connected to the first node via a directed edge. In this way, the workflow graph represents the workflow of executing the model to produce the first global variable as an output.

The method further comprises assigning the second node to the first scope of the workflow graph. A scope within a workflow graph may be defined as a self-contained arrangement of nodes which contain a subset of the functionality of the entire workflow graph. For example, an outer scope of the workflow graph may contain all nodes within the workflow graph. A first scope may be defined within the outer scope which contain a subset of nodes of the workflow graph.

The subset of nodes in the first scope may be an arrangement of nodes which produce an output required for a model located in the outer scope of the workflow. Further scopes may defined within the first scope which contain a subset of nodes of the first scope of the workflow graph. For example, further scopes may include a subset of nodes which contain a sub-model which produces a required input to the first scope.

The method further comprises determining 105 either i. that the first input be assigned to the first scope, or ii. that the first input be assigned to a second scope different from the first scope.

The first input may be determined to be assigned to the first scope if there is currently no reason to assign the first input to a different scope. For example, in a first iteration of the method or while the workflow graph is still being built, there may be nothing which would require the first input to be assigned to a different scope. However, it may be determined that the first input be assigned to a second scope different from the first scope. For example, it may be determined that the workflow graph includes a cycle. In building the workflow graph it may arise that two or more nodes would continuously feed inputs to each other in a continuous loop. In a simplified example, one model may take power as an input and produce resistance as an output, a second model may take resistance as an input and produce power as an output. Whilst either of these models may be useful within a workflow graph, it would not be useful to have the first model provide resistance to the second model and for the second model to then provide power to the first model in a loop. This cycle may be essentially broken by determining that one input should be assigned to a different scope. This is a simplified example, whereas cycles in a workflow graph may exist which span many different nodes and include a plurality of inputs and outputs in between. Nevertheless, the cycle may be avoided by assigning the first input to a second scope.

The first input is defined 106 as a third node in the workflow graph, and the third node is connected to the second node via a directed edge. In this way, the first node the second node, 15 and the third node are interconnected and a path between the nodes is completed. Following this completion an executable workflow may be generated 107 based on the workflow graph.

In another example, after determining whether there are any cycles in the workflow graph, the method may be repeated 110 with an alternative model selected for any of the models already present in the workflow graph. In this example, the method is iteratively repeated 110 until there are no more cycles in the workflow graph. In general terms, the method may be iteratively repeated 110 until none of the criteria are met for attempting alternative models or scopes. The method may include determining whether there are any alternative models available in the model repository which have not already been used in an attempt to produce a valid workflow graph.

In another example, the method may determine that the first input be assigned to a second scope different from the first scope because no complete path in the workflow exists. In particular, the method may comprise determining whether there is a complete a path of directed edges in the workflow graph exists between the first global variable and the second global variable, and if no complete path can be determined, determining that the first variable be assigned to a new scope.

The method may comprise determining that there is an input to the first model for which no models in the model repository produce an output. In such a case an alternative model may be selected from the model repository and the method repeated such that a valid workflow graph is produced.

The method may further comprise receiving a request for a second global variable. The second global variable may be a second variable of interest to a user and therefore defined by the user. Alternatively, the second global variable may be a variable which is required to provide the inputs to the first model, another model, or a submodel in the workflow graph. A second model from the model repository may be selected based on the second model producing the first input to the first model as a first output after the second model has received the second global variable as an input. The second model may therefore provide a path between the second global variable and the first model. Selecting the second model may be done based on a determination that the second model produces the first output which is consistent with the first input. The first output may be consistent with the first input in that they are values which represent the same characteristic of the modelled system. For example, where the first input is gear ratio, the second model may be selected based on determining that it is a model of the model repository which produces gear ratio as an output. Since the first input is consistent with the first output, passing the first output of the second model to the first model as an input is a valid workflow path. The selected second model may be defined as a fourth node in the workflow graph and the fourth node may be connected to the third node via a directed edge. This provides a defined path in the workflow graph between the nodes which represents that path of information between the selected first and second models. Further, the second global variable may be defined as a fifth node in the workflow graph, and the fifth node connected to the fourth node via a directed edge completing the path of the workflow graph.

Where it is determined that the first global variable and the second global variable are not connected by any path through the workflow graph, the first input may be assigned to a second scope different from the first scope comprises. In this way, the workflow graph may, in a further iteration of the method, provide a path between the first global variable and the second global variable.

The method of defining the first global variable as a first node in the workflow graph may further comprise determining that the first global variable already exists in the first scope and defining the pre-existing first global variable as the first node in the workflow graph. Where this is the case, the method prevents duplicated global variables from existing in the workflow graph and ensures that the global variable is assigned to an appropriate scope within the workflow graph.

The method described herein may be iterated multiple times. Over the multiple iterations the 35 workflow graph may be updated to refine the operation of the executable workflow and/or to develop the workflow graph to include new or different models and submodels. Each iteration, new models may be selected to replace or supplement the models which are already part of the workflow graph. Once a complete workflow graph has been defined, an executable workflow may be generated 107 based on the workflow graph.

Iteration 110 of the method is shown by the broken line arrow in figure 1, which indicates the 5 processes in the method which may be repeated prior to the final generation of an executable workflow based on the workflow graph.

When the method (101, 102, 103, 104, 105, 106) is iterated, models which have been selected are tracked between iterations. For example, if a first model is used in a workflow graph defined in a first iteration, the method includes recording that the first model has already been selected. Based on this tracking information, models which have already been selected in a first iteration but which did not result in a valid workflow graph may be discounted from selection in subsequent iterations. Similarly, scopes which have already been assigned in one iteration may be tracked between iterations so that unsuccessful or non-optimal scope definitions may be discounted from being defined in subsequent iterations. By tracking or monitoring the models and scopes which have already been assigned across iterations of the method, this forces the algorithm to eventually converge. Thus, it is possible to explore a variety of different choices of model and scope structure which will result in an optimised executable workflow.

Models of the model repository may be a single model (e.g. a model designed by a user to simulate airflow around an electric car) or they may be sub-models comprising two or more other models connected as nodes in a sub-graph. Sub-graphs may comprise a plurality of models and/or sub-models connected as nodes in a sub-graph which can be combined with one or more other models, sub-models, and/or sub-graphs to create a workflow graph. Sub-graphs may be defined and stored in the model repository when their functionality is determined to be useful in defining other workflow graphs. For example, the first model may be a sub-model which comprises a third model and a fourth model. The third model may produce the first global variable as an output after receiving the output of the fourth model as an input, and the fourth model may generated its output after it has received the first input as an input. In other words, the first model may be a submodel including a chain or collection of other models. Furthermore, each submodel may comprise other submodels and/or models in combination. When a submodel scope is defined, the submodel may be submitted to the model repository so that it may be selected in future iterations or for use in other workflow graphs. It will be understood by the skilled person that any of the models described herein may be a single model or may be a submodel defined as a chain or collection of other models and/or submodels in combination.

It will be further understood that the method may be performed in respect of defining an appropriate submodel within another scope of a workflow graph. For example, the request may be a sub-model request for a third scope of the workflow graph, wherein the third scope is different from the first scope and the second scope. In this way, the method may either produce a workflow graph for the purposes of satisfying user requirements, or the method may produce a submodel to be used within the scope of another workflow graph. Thus, the user may define a high-level problem to be solved which relies on very few global variables and the method may determine the complex structure of different models and submodels, and how they should fit together to most effectively compute a solution.

Worked Example

Turning to figures 2 to 5, a worked example of a method according to the disclosure will now be described.

Figure 2 shows an intermediate workflow graph. An outer scope is defined by the requirements of a user to provide an optimal gear ratio. The optimal gear ratio is provided as an output node connected via a directed edge to a gear optimiser model which accepts as inputs, the bounds of gear ratios, a top speed, and acceleration. The gear optimiser model may run the models in the optimiser submodel scope multiple times providing a gear ratio as an output until the solution converges to an optimal gear ratio value. The outer scope of the workflow graph therefore comprises the input of the bounds of the gear ratio, the gear optimiser model, the optimal gear ratio as an output, and an optimiser submodel scope. The optimiser submodel scope is determined as a submodel scope which accepts the input of a gear ratio and provides an output of a top speed and an output of an acceleration.

The optimiser submodel scope is defined by a top speed model, an acceleration model, a top speed submodel, and an acceleration submodel. The top speed model requires driving force as an input and provides an output of the speed. The acceleration model also accepts driving force as an input and provides an output of the speed. The top speed submodel scope includes an input of speed, gearbox losses, tyre diameter, and produces an output of the driving force. The acceleration submodel scope also includes an input of speed, gearbox losses, tyre diameter and produces an output of the driving force. In the instance of the workflow graph shown in figure 2, gearbox data is provided as a node which provides the gearbox losses as an input to the driving force model.

Turning to figure 3, it is determined in the method that there is no complete path where the gear optimiser provides the gear ratio to update the top speed and the acceleration to optimise the gear ratio. In other words, the gear ratio node as shown in figure 2 is unconnected. Since there is no complete path, the gearbox data in the top speed submodel scope and in the acceleration submodel scope are replaced with a gearbox model. The gearbox model also provides gearbox losses as an output, but accepts gear ratio as an input to calculate the gearbox losses. In a first instance, a node for gear ratio is assigned to the top speed submodel scope which is connected via a directed edge to the gearbox model assigned to the top speed submodel scope. A second node for gear ratio is assigned to the acceleration submodel scope which is connected via a directed edge to the gearbox model assigned to the acceleration submodel scope.

According to the method, it is determined that the gearbox model assigned to the top speed submodel scope and the gearbox model assigned to the acceleration submodel scope may be assigned to a different scope. In particular, the method may determine that the gearbox model of the top speed submodel scope and the gearbox model of the acceleration submodel scope may be assigned to the optimiser submodel scope. Further, since the two gearbox models now assigned to the optimiser submodel scope are duplicates, they may be replaced with a single node of the gearbox model within the optimiser submodel scope. The gearbox losses node of the top speed submodel scope and the gearbox losses node of the acceleration submodel scope are also determined to be duplicates and non-variant within the top speed submodel scope or within the acceleration submodel scope. The gearbox losses node of the top speed submodel scope and the gearbox losses node of the acceleration submodel scope are therefore assigned to the optimiser submodel scope and replace with a single gearbox losses node connected to the driving force model of the top speed submodel scope via a first directed edge and to the driving force model of the acceleration submodel scope via a second directed edge. The resulting assignment of scope is shown in figure 4.

In addition, figure 4 shows that the tyre diameter which is constant through each iteration of the top speed submodel scope and the acceleration submodel scope may be assigned to the optimiser submodel scope. Since the tyre diameter supplied to the top speed submodel scope and the acceleration submodel scope are identical, the two tyre diameter nodes are replaced with a single tyre diameter node connected to the driving force model of the top speed submodel scope by a first connected edge and to the driving force model of the acceleration submodel scope by a second connected edge.

A variable can only have a single instance within a given scope. Were there to be more than one instance of a variable within a given scope, this could result in the variable taking two different values at one time. In this example diagrams, speed exists in both the top speed and acceleration submodel scopes, meaning the top speed model can give a value of speed different to that given by the acceleration submodel. From figures 3-4, the variable "gearbox losses" is moved into the optimiser submodel scope, meaning it can only take a single value that is used in both the top speed and acceleration submodel scopes Turning to figure 5, the method determines that the tyre diameter node is a value which is not determined by any other nodes in the workflow. Furthermore, the tyre diameter is not determined by any models available in the model repository. Since the tyre diameter is therefore an input value (similar to how the gear ratio bounds are an input value to be set by a user), the tyre diameter node is assigned to the outer scope of the workflow graph.

It will be understood that the specific example described in relation to figure 2 to 5 is a simplified example which only includes a few assignments of nodes to different scopes based on whether there are missing paths, duplicated nodes or invariant nodes, as well as a small total number of models and scopes. Once a submodel scope has been defined within the workflow graph, the submodel scope may be duplicated to be included within another scope of the workflow. For example, once the top speed submodel scope has been determined, the submodel scope may be duplicated for the acceleration submodel scope to provide the same functionality to the acceleration model as is provided to the top speed model. Further, once a submodel scope has been defined, the submodel may be included in the model repository to be utilised in further workflow graphs.

Once the workflow graph has been fully defined, as shown in figure 5, an executable workflow is generated. The executable workflow may include a list of executable instructions to be executed on one or more computer processors. The list of executable instructions may include a list of the models to be run on the one or more computer processors and instructions to pass the requisite variables from one model to the next according to the workflow graph. For example, the executable instructions generated from the workflow graph shown in figure 5 may include instructions to iterate the gear optimiser model, passing the gear ratio global variable to the gearbox model. The instructions may further include an instruction to pass the gearbox losses from the gearbox model to the driving force models which are iterated to obtain a top speed and an acceleration of the electric vehicle which are then passed to the gear optimiser.

The executable instructions may include location data which indicates where each model may be run. For example, a driving force model may be more effectively executed on one computing system comprising hardware which is specifically adapted to run a driving force model (e.g. including a large number of processing cores), whereas the gear optimiser model may be effectively run on a user terminal which can directly accept the gear ratio bounds from the user input and display the results on a monitor. The location data may indicate that a model may be run on a particular computing system because the software required, or the licence required to run the software is only installed on that particular computing system.

Where the executable workflow is executed on a plurality of different computing systems, the executable instructions may include instructions to pass the output from one model run by a first computing system to a second computing system where a second model will be executed.

The executable instructions may include the models to be executed and/or the executable instructions may comprise a plurality of pointers, wherein the pointers are configured to cause one or more computing devices to execute the first model and the second model in order according to the workflow graph. For example, the executable instructions may comprise the actual instructions to cause a computing device to execute the desired model, or they may comprise commands which can be transmitted to another computing device as a request for that computing device to execute the appropriate model.

Models referred to in this specification may comprise computer-simulated models of physical processes which can be stored or detailed in the model repository. For example, when a model of the aerodynamics of an electric vehicle is created either by a user or automatically generated, the model or a description of the characteristics (e.g. inputs, outputs, restrictions) of the model may be stored in the model repository. Other computer-simulated models of physical processes may include but are not limited to battery models, electric motor models, tyre models, vehicle handling models, thermal models, crash test models, and sound/vibration models. More generally, the computer simulated models may be any models configured to simulate one or more of the mechanical, electrical, fluid dynamic, thermal, and/or chemical characteristics of one or more components of a vehicle.

The vehicle may be any one of a car, van, bus, aircraft, watercraft, or an electric car, an electric van, or an electric bus, electric aircraft, or electric watercraft. Each model in the model repository may be generally applicable to any vehicle or may be specific to one or more categories and/or vehicles. For example, one model of the model repository may be a general aerodynamic model for any ground based vehicle which may accept the vehicle dimensions as an input, whereas another model of the model repository may be an aerodynamic model specific to a particular vehicle and does not require the vehicle dimensions as an input.

The skilled person will appreciate that a method of simulating a physical system may comprise receiving an executable workflow generated according to the present disclosure, and executing the executable workflow on one or more computing system or on a distributed computing 35 system.

The methods described herein provide improvements in that a more efficiently executable workflow for modelling physical processes may be created and ultimately executed on one or more computing systems. The methods are more effective at producing a valid workflow requiring less computing resources to generate a workflow. This is even more apparent for complex workflows which may include hundreds or thousands of nodes and models available in the model repository. The methods also produce an executable workflow which is more efficient to run on one or more computing systems. The resultant executable workflow will be one which does not include, for example, cycles, dead ends, or repeated calculation of the same global variables. The methods will also produce an executable workflow which produces more technically accurate results. For example, in a workflow where the same variable is generated by multiple models, multiple values for that variable may result. This does not make physical sense, since a single variable may only take a single value. The present methods ensure that conflicting values for single variables do not occur within a single workflow graph.

Once the executable workflow has been executed by the one or more computing devices, the results may be a more accurate physical representation of the optimised parameters for a vehicle or for an electric vehicle. This disclosure incorporates a method of manufacturing the vehicle or electric vehicle according to the optimised parameters determined by executing the executable workflow on the one or more computing devices. This disclosure also incorporates an improved vehicle or electric vehicle manufactured in accordance with the optimised parameters determined by executing the executable workflow on the one or more computing devices.

Figure 6 shows an exemplary computing environment 600 which may be used to perform the methods described herein. The computing environment 600 may include at least a first computing system 601. The computing system 601 comprises a processor 602 and memory 603 configured to perform computing operations. The processor 602 may communicate with external devices or peripherals such as monitors, networks, and other computing systems via an I/O interface. The computing system 601 is configured to communicate with a model repository 610 via the I/O interface. The model repository 610 may be physically located within the computing system 601, on an external computing system, connected via a network, or distributed across a plurality of computing systems. The computing system 601 may further be configured to communicate with computing system 620 which is also in communication with model repository 610. Computing system 620 may be capable of running computer models of the model repository 610 and may update the model repository 610 with models and/or submodels which are available to be executed on computing system 620. Computing system 601 may also be configured to communicate with computing system 630. Computing system 630 may be configured to execute one or more models of model repository 610, but the model repository 610 is maintained by communication with computing system 601. In this way, computing system 601 may be used to generate an executable workflow which may be executed across computing environment 600 or on any sub-division of computing environment 600. For example, computing system 601 may generate an executable workflow which may be executed on computing system 620 and on computing system 601, or on computing system 620 and computing system 630. Computing system 601 and computing system 620 may add or replace models and submodels of the model repository 610 as they are created or modified.

It will be understood that various modifications and changes to the specific examples described herein may be made without departing from the scope of the appended claims. The skilled person will recognise that methods may include additional steps or steps carried out in a different order whilst still producing the technical effects described. The invention is that which is defined by the appended claims.

Claims (1)

1. Claims 1. A computer-implemented method of generating an executable workflow, comprising: a. receiving a request for a first global variable to be output from a first scope of a workflow graph; b. defining the first global variable as a first node in the workflow graph; c. selecting a first model from a model repository, wherein the first model produces 10 the first global variable as an output after the first model has received at least a first input; d. defining the selected first model as a second node in the workflow graph, wherein the second node is connected to the first node via a directed edge, and wherein the second node is assigned to the first scope; e. determining, either: i. that the first input be assigned to the first scope, or U. that the first input be assigned to a second scope different from the first scope; f. defining the first input as a third node in the workflow graph, wherein the third node is connected to the second node via a directed edge; and g. generating an executable workflow based on the workflow graph. 20 2. The computer-implemented method of claim 1, further comprising: receiving a request for a second global variable; selecting a second model from the model repository, wherein the second model produces the first input to the first model as a first output after the second model has received the second global variable as an input, and wherein selecting the second model comprises determining that the second model produces the first output which is consistent with the first input; defining the selected second model as a fourth node in the workflow graph, wherein the fourth node is connected to the third node via a directed edge; defining the second global variable as a fifth node in the workflow graph, wherein the fifth node is connected to the fourth node via a directed edge.3. The computer-implemented method of claim 1 or claim 2, wherein defining the first global variable as a first node in the workflow graph comprises determining that the first global variable 35 already exists in the first scope and defining the pre-existing first global variable as the first node in the workflow graph.4. The computer-implemented method of any preceding claim, the method further comprising: iterating a. to f. multiple times; tracking the models that have been selected between iterations; and tracking the scopes that have been assigned between iterations.5. The computer-implemented method of any preceding claim, wherein determining that the 5 first input be assigned to a second scope different from the first scope comprises determining that the workflow graph includes a cycle.6. The computer-implemented method of claim 2, or claims 3 or 4 when dependent on claim 2, wherein determining that the first input be assigned to a second scope different from the first 10 scope comprises determining that the first global variable and the second global variable are not connected by a path through the workflow graph.7. The computer-implemented method of any preceding claim, further comprising: determining whether there is a complete path of directed edges in the workflow graph 15 between the first global variable and the second global variable, and if no complete path can be determined, determining that the first variable be assigned to a new scope.8. The computer-implemented method of any preceding claim, wherein the first model is a sub-model comprising: a third model which produces the first global variable as an output after the third model has received a second input; a fourth model which produces the second input as an output after the fourth model has received the first input.9. The computer-implemented method of claim 8, wherein one or more of the first model, second model, third model, and fourth model are sub-models comprising a plurality of models connected as nodes in a sub-graph.10. The computer-implemented method of any preceding claim, wherein the request is a user-30 request generated at a user device.11. The computer-implemented method of any one of claims 1 to 9, wherein the request is a sub-model request for a third scope of the workflow graph, wherein the third scope is different from the first scope and the second scope.12. The computer-implemented method of any preceding claim, further comprising: determining whether there are any cycles in the workflow graph, and repeating the method with an alternative selected for any of the models included the workflow graph for which an alternative is available and for which the alternative has not already been attempted.13. The computer-implemented method of any preceding claim, further comprising: determining that there is an input to the first model for which no models in the model repository produce an output, and repeating the method with an alternative selected first model from the model repository.14. The computer-implemented method of any preceding claim, wherein the executable workflow comprises a plurality of pointers configured to cause one or more computing devices to execute the first model and the second model in order according to the workflow graph.15. The computer-implemented method of any preceding claim, wherein the model repository 15 comprises computer simulated models of physical processes.16. The computer-implemented method of claim 15, wherein the computer simulated models are configured to simulate one or more of the mechanical, electrical, fluid dynamic, thermal, and/or chemical characteristics of one or more components of a vehicle.17. A computer-implemented method of simulating a physical system comprising: receiving an executable workflow generated according to any preceding claim, and executing the executable workflow on one or more computing system or on a distributed computing system.