Computer-implemented method for providing artifacts for a simulation of a real device

Abstract

The invention relates to a computer-implemented method for providing artifacts (4) for the simulation of a real device, wherein a database (3) and a logic module (2) are provided, wherein the logic module (2) is connected to the database (3) for data transmission and the artifacts (4) have different classes (6), the classes (6) and the input artifacts of those classes (6) with back-references are described in a metamodel (8), the artifacts (4) within a class are instances (10), wherein each instance (10) has a version (12) of the instance (10), comprising the following method steps: accessing the database (3) with the logic module (2), checking one of the instances (10) with the logic module (2) to determine whether a change has been made to the instance (10), if no change has been made to the instance (10) or no further version (14) has been generated: providing the instance (10) for the simulation, if the change to the instance (10) has been made or a further version (14) has been generated: updating the metadata, and repeating step S2 and subsequently step S3a or S3b until a predetermined number of instances (10) have been checked. In this way, a computer-implemented method for providing artifacts for the simulation of a real device with improved traceability is provided.

Description

[0001] Computer-implemented method for

[0002] Providing artifacts for a simulation of a real device

[0003] The invention relates to a computer-implemented method for providing artifacts for simulating a real device, wherein a database and a logic module are provided, the logic module is connected to the database for data transmission, and the artifacts have different classes.

[0004] Simulation applications for performing complex simulations of a real device typically comprise a multitude of artifacts in different classes. Artifacts in general can be virtual elements such as (source) code or scripts that are required to execute the simulation of the real device. These elements, in turn, can be edited and updated using an editor. Simulation applications in hardware-in-the-loop (EHL) and software-in-the-loop (SIL) simulations require different artifacts in different classes. These artifacts are interconnected across classes and have relationships between them. The relations can, for example, be variables and parameters that are manipulated and / or created in the respective artifacts. For example, an artifact that provides results can depend on an artifact that defines the conditions required to calculate the results.If a change is made to an artifact, it may be necessary to adapt the related artifacts. During the development process of such a simulation application, artifacts are created that are deployed at various development stages of the simulation application and are themselves subject to numerous changes. The larger the simulation and the more artifacts and version changes of the artifacts have occurred, or the more new artifacts have been added during the simulation development process, the more difficult it becomes to run the simulation with an up-to-date and consistent set of corresponding artifacts that deliver consistent results.

[0005] The ability to understand the relationships between artifacts is also referred to as traceability. Traceability can be achieved, for example, by modifying artifacts to include information that lists related artifacts as additional content. However, this modification complicates the development process and is not very flexible. One type of traceability is requirement traceability. In requirement traceability, all aspects of the development process are linked to the underlying requirements. Requirements traceability therefore aims at the connection between different artifacts and their relationships. However, especially for sensitive applications such as the simulation of a real device, it is essential that the results obtained from the simulations are highly reliable and consistent.However, requirements traceability primarily aims at including all relations of the artifacts and generally ensuring feasibility, without meeting the requirements of data and result consistency necessary in simulation applications.

[0006] Based on this, the object of the invention is to provide a computer-implemented method for providing artifacts for simulating a real device with improved traceability.

[0007] This problem is solved by the subject matter of patent claim 1. Preferred developments can be found in the subclaims.

[0008] According to the invention, a computer-implemented method for providing artifacts for simulating a real device is provided, wherein a database and a logic module are provided, the logic module is connected to the database for data transmission, and the artifacts have different classes, the artifacts are stored in the database and are interdependent across classes, within a class the dependency of each artifact is given in the form of identical backreferences within the class to at least one input artifact and / or identical forward references within the class to at least one output artifact of further classes, the classes as well as the classes of the input artifacts of those classes are described with backreferences in a metamodel, the artifacts within a class are instances, wherein each instance has at least one version of the instance provided with a version number, the version number of the version,a storage location of the version, a storage location of the input artifact determined with the metamodel and a relationship between the input artifact and the version determined with the metamodel are metadata that are assigned to the respective instance with the logic module, and with a change of an instance, an instance modified according to the change is created in the form of a further version of the instance in the class, comprising the following method steps:,

[0009] 51) Accessing the database with the logic module,

[0010] 52) Checking one of the instances with the logic module to see if a change has been made to the instance,

[0011] S3a) if no change has been made to the instance or no further version has been created: making the instance available for simulation,

[0012] S3b) if the change to the instance has been made or a further version has been created: updating the metadata, whereby the updating of the metadata includes updating the version number and the storage location of the further version and updating the storage location of the input artifact of the further version as well as the relationship between the further version and the input artifact, and

[0013] S4) Repeating step S2 and subsequently step S3a or S3b until a predetermined number of instances have been checked.

[0014] The metamodel and database are deployed once and then checked and updated so that a simulation with appropriate instances can be provided.

[0015] According to the invention, the instances are verified via data traceability. Consistent simulation results are generated because the method according to the invention ensures that, by updating the metadata and verifying with the logic module, only those instances are provided for the simulation that correspond to one another and with which consistent results can therefore be expected.

[0016] The method is preferably executed on a single computer, a system comprising a network of computers, a computing cluster, in a cloud, or distributed across a cloud and a computing cluster. Artifact classes include, for example, simulation models, configuration files, communication matrices, application software, etc. Across all classes, artifacts exist that are assigned to the respective classes. Within a class, multiple artifacts can exist; some classes can be empty for a specific simulation, etc. The artifacts themselves are dependent on other artifacts of other classes through backreferences and / or forward references.

[0017] All artifacts within a class are instances. Therefore, in this context, we will refer to artifacts across classes, while within a class we will refer to instances. In the simulation model class, instances are, for example, a simulation model of a control unit or a simulation model of a motor vehicle engine. Each of these instances has at least one version of the instance, each with a version number. The versions multiply as the instance changes. In other words, with every change to an instance, a new version of the instance is created, so that there is one more version of the instance. Every change to an instance results in another version of the instance in the class that takes the changes into account. This additional version of the instance therefore has its own version number and its own storage location.This makes it possible to keep all versions of the instances so that the development process of the instance can be traced.

[0018] Some instances will therefore contain only backreferences, some will contain only forward references, and others will contain both backreferences and forward references. These backreferences and forward references are class-independent. This means that, depending on the type of reference, there are input artifacts and / or output artifacts for the referenced instance, which refer to specific artifacts in the referenced classes, the instances corresponding to the instance. Because the storage location of the input artifact and the relationship between the input artifact and the version are now stored directly in the metadata, the logic module is able to directly and quickly access an instance corresponding to the instance in the form of the input artifact. Since the references are identical throughout the entire class, they also apply to the versions of the instance.Specifically, this means that a version of the ECU instance exists within the Simulation Models class. The Simulation Model class has a reference back to a Configuration Files class. The Configuration Files class therefore has an input artifact of the ECU instance. The configuration files for the ECU thus correspond to the input artifact of the version of the ECU instance of the Simulation Model class.

[0019] A forward reference, or a forward reference in a programming language, refers to the situation where the artifact is used as an input artifact. The opposite of a forward reference is a backward reference.

[0020] In this case, relation means a dependency between the version and the input artifacts and / or output artifacts, which refer, for example, to certain variables and / or data that must be passed between the instances.

[0021] When the instance is checked, the metadata for the instance is also checked. The metadata can be stored on the data storage or another storage device. However, the metadata can also be closely linked to the respective instance (data container on the instance). The metadata belongs to the instance, so that more effective checking can take place between versions of the instance. Due to the centralized assignment of metadata to the instances, the metadata can be retrieved more quickly and changes to the instances can be identified more quickly, whereby different versions of an instance can also be assigned different metadata. In principle, it can also be provided that the computer-implemented method according to the invention provides artifacts for the simulation of a system consisting of several devices.

[0022] In principle, it is possible for various elements to be described in the metamodel. However, according to a preferred development of the invention, it is provided that, starting from at least one version, the input artifacts of the respective classes are described in an input artifact chain with references to all interdependent input artifacts, the storage locations of the input artifacts of the input artifact chain and the relationship between the version and the input artifacts of the version are assigned to the logic module as additional metadata of the instance, and in step S3b, the storage locations of the input artifacts of the input artifact chain of the further version and the relationships between the input artifacts of the input artifact chain are additionally updated. As mentioned at the beginning, not every version of the instance necessarily has an input artifact.In the metamodel, all input artifacts are now described in an input artifact chain, starting from at least one version of the instance that has a reference to the input artifact. This means that the input artifact chain extends through all instances in the respective classes that are connected to each other via references, up to a first, original input artifact. Describing the input artifact chain enables faster and more efficient access to the input artifacts that are connected to the version via references.

[0023] In this context, according to a preferred development of the invention, a dependency of each version is given in the form of back references to at least one input version and / or forward references to at least one output version of further classes, the input version has a version number corresponding to the version number of the version, wherein in the metamodel the input versions of those versions are additionally described in classes with back references, wherein the metadata are the version number of the version, the storage location of the version (12), the corresponding version number of the input version, a storage location of the input version and a relation between the input version and the version,and in step S3b, instead, when updating the metadata, the version number and the storage location of the further version are updated, and the corresponding version number and the storage location of the input version of the further version and the relationship between the further version and the input version are updated.

[0024] The version has input versions and / or output versions. If the input artifacts and / or the output artifacts refer to specific instances in the referenced classes, the input versions and / or the output versions refer directly to versions corresponding to the version. These corresponding versions have the version number corresponding to the version number of the version in the referenced class. This provides instances with corresponding versions for the simulation. In this case, corresponding versions can be versions that preferably have identical version numbers or correspond to the current versions of the respective instances.

[0025] According to a particularly preferred development of the invention, it is provided that, starting from at least one version and based on the input artifact chain, the input versions of all interdependent input versions are described in an input version chain with corresponding version numbers in the metamodel, the storage locations of the input versions of the input version chain and the relationship between the version and the input versions are assigned as additional metadata to the instance with the logic module, and in step S3b, the storage locations of the input versions of the input version chain of the further version and the relationships between the input versions of the input version chain are additionally updated. Analogous to the input artifact chain, all input versions in an input version chain are described in the metamodel of at least one version of the instance that has a reference to the input version.This means that the input version chain extends through all corresponding versions of the instances in the respective classes, which are linked to each other via respective references, up to a first, original input version. Forming the input version chain enables the logic module, based on the metamodel, particularly fast and efficient access to the respective corresponding versions of the instances and their metadata in the referenced classes.

[0026] In principle, the input artifacts can be checked in various ways. However, according to a preferred development of the invention, the computer-implemented method comprises the following additional step: once the change to the instance has been made or the further version has been generated: checking with the logic module whether a change has been made to one of the input artifacts of the further version containing the input versions of the input version chain. Using this transitive property, the versions in the input artifacts corresponding to the version are also checked for changes and compatibility.

[0027] In principle, all input artifacts of the version can always be checked. However, according to a preferred embodiment of the invention, the check in step S2a is performed on a user-selectable portion of the input artifacts of the input version chain of the further version. If the user in question already knows which input artifacts are most likely to be affected by the change to the instance or the creation of the further version, the check can be significantly limited and thus accelerated in this way.

[0028] According to a preferred development of the invention, the computer-implemented method comprises the following further step: once the change to the instance has been made or the further version has been created: determining the initial version, which is dependent on the further version, based on the metamodel. The version has a version number that corresponds to the version number of the initial version. Because all back references of all classes are known in the metamodel, the forward references are also known conversely. The forward references follow indirectly from the metamodel and therefore do not also have to be established in the metamodel. The bijective property, which results from the knowledge of the initial version, makes it possible to check the initial version immediately after the change to the instance is detected.

[0029] According to a preferred development of the invention, it is further provided that in the metamodel, starting from at least one version and based on the input version chain, the output versions of all mutually dependent output versions are described in an output version chain with corresponding version numbers, the storage locations of the output versions of the output version chain and the relationship between the version and the output versions are assigned as additional metadata to the instance with the logic module and in step S3b the storage locations of the output versions of the output version chain of the further version and the relationships between the input versions of the input version chain are additionally updated, comprising the following further step: if the change to the instance has been made orThe next version was created: Use the logic module to check whether a change has been made to one of the next version's output artifacts containing the source versions of the source version chain. Creating an output version chain improves the retrieval of forward references from the metamodel using the logic module. Starting from the version, all forward and / or backward references of the version can be checked together with the input version chain.

[0030] Various measures can be taken to identify non-corresponding versions or when non-corresponding versions have been identified. However, according to a preferred development of the invention, the computer-implemented method comprises the following further steps: when the change to the instance has been made or the further version has been created: checking whether the input versions of the input version chain have version numbers corresponding to the version number of the further version, and if the input versions do not have version numbers corresponding to the version number of the further version: issuing a message. By checking the input versions of the input version chain for version numbers corresponding to the version number of the further version, non-corresponding versions with non-corresponding version numbers can be identified immediately.According to the invention, the user is then notified of this incompatibility when the message is output, for the sake of data traceability. Checking the input versions can be done by checking the corresponding data in the metamodel, since this is constantly updated according to the invention. This eliminates the need to check the specific instances; only the metadata for the linked artifacts needs to be checked.

[0031] In this context, the method according to a preferred development of the invention comprises the following further steps: if the change to the instance has been made or the further version has been created which does not have the version number corresponding to the version number of the input version: updating the metadata and in step S4 instead: repeating step S2 and subsequently one of the steps S3a, S3b or S3c until a predetermined number of instances have been checked. The updating of the metadata is carried out automatically if it was determined during the check that the further version was not created based on a corresponding version. According to a preferred development of the invention, it is provided that in step S2 the checking takes place automatically after a change or following a user input.In this case, it is possible to specify which instances are to be checked for each check. In this context, according to a further preferred development of the invention, it is particularly preferred that, in step S2, the checking of the instances takes place at predetermined, constant time intervals. The duration of the time intervals can be adjustable for this purpose, so that the checking of the instances can be carried out with increased flexibility.

[0032] The invention further relates to a non-volatile, computer-readable storage medium having instructions stored thereon which, when executed on a processor, effect a method according to one of the preceding claims.

[0033] The invention is described in more detail below with reference to the drawings using preferred embodiments.

[0034] The drawings show

[0035] Fig. 1 shows an arrangement for providing artifacts for simulating a real device according to a preferred embodiment of the invention and

[0036] Fig. 2 shows a flowchart for a computer-implemented method for

[0037] Providing artifacts for simulating a real device according to a preferred embodiment of the invention.

[0038] Fig. 1 shows an arrangement for providing artifacts 4 for simulating a real device. On a computing cluster 1, a logic module 2 is connected to a database 3 for data transfer. Artifacts 4 are stored in various classes 6 next to a metamodel 8 on the database 3, or in other locations that the logic module 2 can access but that are not located in the same memory as the metamodel 8. The logic module 2 can access the metamodel 8. The artifacts 4 are interdependent across classes in the form of backreferences to at least one input artifact and / or forward references to at least one output artifact. The artifacts 4 within a class 6 always have identical dependencies related to the classes 6. The artifacts 4 within the class 6 are instances 10.Each instance 10 has at least one version 12 of instance 10 provided with a version number, so that a dependency of each version 12 exists in the form of back references to at least one input version from another class 6 and / or forward references to at least one output version from another class 6. The input version and the output version have a version number corresponding to the version number of version 12 if the simulation is to deliver consistent results. If instance 10 is changed, an instance 10 modified according to the change is generated in the form of another version 14 of instance 10 in class 6.

[0039] Metamodel 8 describes all classes as well as the input artifacts of those classes 6 with backreferences. In addition, metamodel 8 describes all input artifacts in an input artifact chain for each version 12 that has a backreference to an input artifact.

[0040] Based on the input artifact chain, the metamodel 8 describes the input versions of all interdependent input versions in an input version chain with corresponding version numbers, starting from at least one version 12.

[0041] With the logic module 2, the respective instance 10 is assigned the version number of version 12, a storage location of version 12, the corresponding version number of the input version, a storage location of the input version, a relation between the input version and version 12, the storage locations of the input versions of the input version chain and the relation between version 12 and the input versions as metadata.

[0042] Fig. 2 shows a flowchart for the computer-implemented method according to a preferred embodiment of the invention. This method comprises steps S1 to S4. In a first step S1, the database is accessed using the logic module 2. In a second step S2, one of the instances 10 is checked using the logic module 2 to determine whether a change has been made to the instance 10.

[0043] Provided that the change to instance 10 has been made or the further version 14 has been created, in a further step S2a, the logic module 2 additionally checks whether a change has been made to one of the input artifacts of the further version 14 containing the input versions of the input version chain. In parallel, under the same condition, in step S2b, the output version that depends on the further version 14 is determined using the metamodel 8. The version number for the further version 14 is then updated in the metadata for the output version. Under the same condition, in parallel to steps S2a and S2b, in step S2c, it is checked whether the input versions of the input version chain have the version numbers corresponding to the version number of the further version 14.In step S2d, a message is then issued to a user if the input versions do not have the version numbers corresponding to the version number of the further version.

[0044] In the third step, the instances 10 are made available for the simulation in step S3a if no changes have been made to instance 10 or no further version 14 has been created. If, however, the changes have been made to instance 10 or a further version 14 has been created, the metadata is updated in step S3b. When the metadata is updated, the version number and storage location of the further version 14 are updated, as are the corresponding version number and storage location of the input version of the further version 14 and the relationship between the further version 14 and the input version. In addition, the storage locations of the input versions of the input version chain of the further version 14 and the relationships between the input versions of the input version chain are updated.Finally, in step S4, the steps from step S2 are repeated until the instances required for the simulation have been checked and provided. List of reference symbols.

[0045] 1 computing cluster

[0046] 2 Logic module 3 Data memory

[0047] 4 Artifact

[0048] 6th grade

[0049] 8 Metamodel

[0050] 10 Instance 12 Version

[0051] 14 more versions

Claims

Patent claims 1. A computer-implemented method for providing artifacts (4) for simulating a real device, wherein a database (3) and a logic module (2) are provided, wherein the logic module (2) is connected to the database (3) for data transmission and the artifacts (4) have different classes (6), the artifacts (4) are stored in the database (3) and are interdependent across classes, within a class (6), the dependency of each artifact (4) is given in the form of identical backreferences within the class (6) to at least one input artifact and / or identical forward references within the class to at least one output artifact of further classes (6), the classes (6) and the input artifacts of those classes (6) are described with backreferences in a metamodel (8), the artifacts (4) are instances (10) within a class,wherein each instance (10) has at least one version (12) of the instance (10) provided with a version number, the version number of the version (12), a storage location of the version (12), a storage location of the input artifact determined with the metamodel (8) and a relation between the input artifact and the version (12) determined with the metamodel (8) are metadata that are assigned to the respective instance (10) with the logic module (2), and with a change of an instance (10), an instance modified according to the change is generated in the form of a further version (14) of the instance (10) in the class (6), comprising the following method steps: 51) Accessing the database (3) with the logic module (2), 52) Checking one of the instances (10) with the logic module (2) to see whether a change has been made to the instance (10), S3a) if no change has been made to the instance (10) or no further version (14) has been created: making the instance (10) available for the simulation, S3b) if the change to the instance (10) has been made or a further version (14) has been created: updating the metadata, wherein the updating of the metadata includes updating the version number and the storage location of the further version (14) and updating the storage location of the input artifact of the further Version (14) and the relation between the further version (14) and the input artifact, and S4) Repeating step S2 and subsequently step S3a or S3b until a predetermined number of instances (10) have been checked.

2. Computer-implemented method according to claim 1, wherein in the metamodel (8) starting from at least one version (10) the input artifacts of those classes (6) are described with references of all interdependent input artifacts in an input artifact chain, the storage locations of the input artifacts of the input artifact chain and the relationship between the version (12) and the input artifacts of the version (12) are assigned as additional metadata to the instance (10) with the logic module (2), and in step S3b the storage locations of the input artifacts of the input artifact chain of the further version (14) and the relations of the input artifacts of the input artifact chain to one another are additionally updated.

3. Computer-implemented method according to claim 2, wherein a dependency of each version (12) is given in the form of back references to at least one input version and / or forward references to at least one output version of further classes (6), the input version has a version number corresponding to the version number of the version (12), wherein in the metamodel (8) the input versions of those versions (10) in classes (6) are additionally described with back references, wherein the metadata (8) are the version number of the version (12), the storage location of the version (12), the corresponding version number of the input version, a storage location of the input version and a relation between the input version and the version (12),and in step S3b, instead, when updating the metadata, the version number and the storage location of the further version (14) are updated and the corresponding version number and the storage location of the input version of the further version (14) and the relationship between the further version (14) and the input version are updated.

4. Computer-implemented method according to claim 3, wherein in the metamodel (8), starting from at least one version (12) and based on the input artifact chain, the input versions of all interdependent input versions are described in an input version chain with corresponding version numbers, the storage locations of the input versions of the input version chain and the relationship between the version (12) and the input versions are assigned as additional metadata to the instance (10) with the logic module (12), and in step S3b, the storage locations of the input versions of the input version chain of the further version (14) and the relationships between the input versions of the input version chain are additionally updated.

5. A computer-implemented method according to claim 4, comprising the following further step: S2a) if the change to the instance (10) has been made or the further version (14) has been created: Checking with the logic module (2) whether a change has been made in one of the input artifacts of the further version (14) containing the input versions of the input version chain.

6. Computer-implemented method according to claim 5, wherein the checking in step S2a is performed on a part of the input artifacts of the input version chain of the further version (14) that can be selected by a user.

7. A computer-implemented method according to any one of claims 3 to 6, comprising the following further step: S2b) when the change to the instance (10) has been made or the further version (14) has been created: Determining the initial version, which is dependent on the further version (14), using the metamodel (8).

8. Computer-implemented method according to one of claims 3 to 7, comprising the following further steps: S2c) if the change to the instance (10) has been made or the further version (14) has been created: Check whether the input versions of the input version chain have the version numbers corresponding to the version number of the further version (14), and S2d) if the input versions do not have the version number corresponding to the version number of the further version (14): issuing a message.

9. A computer-implemented method according to any one of claims 3 to 8, comprising the following further step: S3c) if the change to the instance (10) has been made or the further version (14) has been created which does not have the version number corresponding to the version number of the input version: updating the metadata and in step S4 instead: S4) Repeating step S2 and subsequently one of steps S3a, S3b or S3c until a predetermined number of instances (10) have been checked.

10. Computer-implemented method according to one of the preceding claims, wherein in step S2 the checking is carried out automatically after a change or upon input from the user.

11. Computer-implemented method according to one of the preceding claims, wherein in step S2 the checking of the instances (10) takes place at predetermined constant time intervals.

12. A non-transitory, computer-readable storage medium having instructions stored thereon which, when executed on a processor, effect a method according to any one of the preceding claims.

Images