WO2024022819A1 - Techniken zum validieren oder verifizieren von closed-loop-testplattformen - Google Patents

Techniken zum validieren oder verifizieren von closed-loop-testplattformen Download PDF

Info

Publication number
WO2024022819A1
WO2024022819A1 PCT/EP2023/069333 EP2023069333W WO2024022819A1 WO 2024022819 A1 WO2024022819 A1 WO 2024022819A1 EP 2023069333 W EP2023069333 W EP 2023069333W WO 2024022819 A1 WO2024022819 A1 WO 2024022819A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
closed
test platform
loop test
input data
Prior art date
Application number
PCT/EP2023/069333
Other languages
English (en)
French (fr)
Inventor
Joachim SOHNS
Patrick Weber
Philipp Glaser
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2024022819A1 publication Critical patent/WO2024022819A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B13/00—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion
    • G05B13/02—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric
    • G05B13/0265—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric the criterion being a learning criterion

Definitions

  • test platforms in the verification and validation of new systems (e.g. systems for autonomous or assisted driving) has enormous potential and can help shorten the validation process.
  • simulation-supported test platforms is almost indispensable, especially when releasing autonomous driving functions from level 3 (according to SAE definition).
  • the term “verification” refers to a comparison of the behavior and/or configuration of a system with a given specification. Verification is usually carried out using test cases that are derived from the requirements. As part of the validation, it is checked whether the system meets all the required security objectives and has all the necessary quality properties. Validation goes beyond verification. Among other things, validation also checks the completeness of the requirements and the validity of assumptions made. When “testing” is used in the context of this disclosure, this means checking quality requirements, security goals and other requirements for the system.
  • the scope of a test program in the field can be significantly reduced or such a test program can even be avoided completely (e.g. test drives with the system to be tested). Additionally or alternatively, the scope and/or quality of a test program can be increased without increasing the use of resources. This can, for example, help reduce potential risks from rare events.
  • During test drives it can be difficult to test the reaction of the system under test to rare events. To one To observe a large number of certain rare events in the test drives, for example, a prohibitive amount of test kilometers may be necessary.
  • rare events can be easily generated using a suitably chosen scenario.
  • a fundamental challenge is the replication of an environment of the system to be tested or of the system to be tested itself in the virtual environment (e.g. a simulation of the input signals of a system for a system of a vehicle).
  • an input signal from the real environment of the system is always replaced by a simulated and/or synthesized input signal.
  • the synthesized input signal can also have been generated based on real data (e.g. fault injection based on real fault images).
  • the question here is whether relevant features or properties of the real environments are changed or not represented. Both the absence of relevant features and their changes can result in a system being tested not being adequately tested during virtual validation or verification. This can significantly influence the functionality and even the operational reliability of the system being tested.
  • a closed-loop test platform a system under test is fed with input data (also referred to as “input signals” in the present disclosure).
  • output data also referred to as “output signals” in this disclosure
  • the behavior of a system under test can be tested if the system reacts to its environment (and feedback loops arise).
  • a first general aspect of the present disclosure relates to a method for training a machine learning module to validate or verify a closed-loop test platform for validating or verifying a system.
  • the method includes providing a plurality of data sets from two or more closed-loop test platforms, including at least one reference test platform. Each data set contains input data and associated output data of a system under test in a respective closed-loop test platform.
  • the method further includes determining similarity of portions of the input data for pairs of the plurality of data sets. Each pair of data sets contains a data set from a reference test platform.
  • the method further comprises determining similarities of sections of the output data associated with the sections of input data and training a machine learning module to estimate the similarity of input data and output data of a data set of a closed-loop test platform to be validated or verified and the data sets of the plurality of data sets of the at least one reference test platform as a function of input data and / or output data of the data set of the closed-loop test platform to be validated or verified using the certain similarities to a machine learning module for validating or verifying a closed-loop test platform.
  • a second general aspect of the present disclosure relates to methods for validating or verifying a closed-loop test platform for testing a system.
  • the method includes receiving a data set from a closed-loop test platform for testing a system, feeding at least a portion of the data set from the closed-loop test platform into a machine learning module for validating or verifying a closed-loop test platform.
  • the machine learning module is based on an estimate of the similarity of input data and output data of a data set of a closed-loop test platform to be validated or verified and data sets of at least one reference test platform as a function of input data and / or output data of the data set of the one to be validated or trained on a closed-loop test platform to be verified.
  • the method further comprises outputting one or more estimates of the similarity of input data and output data of a data set of a closed-loop test platform to be validated or verified.
  • a third general aspect of the present disclosure relates to a computing unit configured to carry out the methods according to the first or second general aspects.
  • the techniques according to the first through third general aspects of the present disclosure may, in some cases, have one or more of the following advantages.
  • validation or verification can be carried out at the level of an (overall system) even in situations in which the system to be tested and/or its environment is/are complex and, for example, by means of a plurality (possibly one large number) of (sub-) models have to be represented simulatively.
  • the different (sub-) models are validated or verified separately. This can be time-consuming.
  • the validation or verification can only be done in an open loop, which, as described above, may not allow a reliable statement to be made about the behavior of the system in the field (i.e. in a closed loop).
  • the use of similarities in the input data and output data of the (entire) system to assess the The validity of a closed-loop test platform makes it possible, for example, to detect whether certain system behavior occurs certain operating scenarios can be adequately mapped and thus tested.
  • the data sets used from the reference test platforms can represent adequate validations or verifications.
  • an estimate by the machine learning module regarding the similarity of the input data and output data to the data sets of the reference test platforms can in some cases enable a reliable statement to be made as to whether the behavior of a system is adequate on a closed-loop test platform to be validated or verified tests.
  • the techniques of the present disclosure can be applied in some cases even if the data from different test platforms differ (e.g. not exactly the same operating scenarios were simulated/run or not all relevant conditions were recreated in the simulation).
  • data from an endurance run can also be used (e.g. data recorded in systems in the field). This can reduce the effort required to validate or verify test platforms in some cases, as a broader range of data is available for validation or verification (e.g. data previously collected after changes in test protocols can be reused or data that is not even part of a test protocol). tests were collected). Test platforms from different manufacturers can also be compared (easier) in some situations.
  • the use of a machine learning module that is trained to estimate the similarity of input data and output data of a data set from a closed-loop test platform to be validated or verified and data sets from reference test platforms can also ensure reliable validation or verification in the enable the above-mentioned cases.
  • the techniques of the present disclosure may reduce the effort to perform validation or verification (e.g., simulation) in some cases.
  • the input and output data are compared in sections, with only a part of the input and output data being taken into account depending on the operating scenario being examined.
  • the sections can be represented compactly using techniques to reduce their dimensionality. Both can make both the training and the application of the machine learning modules more efficient (e.g. in terms of storage space and/or computing effort).
  • the techniques of the present disclosure can be used to identify operational scenarios or parameter ranges for which a closed-loop test platform has not yet been adequately validated or verified. If data occurs in the data set of the closed-loop test platform to which no suitable date for the reference test platform can be assigned, this is an indication that further data is being collected for validation for the closed-loop test platform or submodels contained therein must.
  • a “closed-loop test platform” (loosely translated in German as “test platform with feedback”) is any system that forms a test environment for a system under test, whereby the system under test is fed with input data and also output data from the system under test are fed back into the test environment (and can influence it).
  • the closed-loop test platform forms a feedback loop (and is therefore suitable for validating or verifying systems or functions of systems in which feedback plays a role in system behavior - which applies to a large number of systems ).
  • a “closed-loop test platform” a distinction is made between the system to be tested (in the present disclosure, unless explicitly described otherwise, a part of the closed-loop test platform) and the environment of the system to be tested.
  • a closed-loop test platform can simulate both the system being validated or verified and its environment.
  • a real system to be validated or verified may be inserted into the closed-loop test platform (the term "real” is used here in contrast to the term "simulated 1 - the real system is later in this Form also in use, a simulated system replicates a real system; a real environment is the environment in the field or in the application).
  • the system under test can take any form imaginable.
  • the system to be tested can be a hardware system, a software system or a system with hardware and software components.
  • a system to be tested in the field or on a test stand is also a closed-loop test platform (e.g. a test vehicle that contains a system to be tested - the test environment here can be a real environment of the system to be tested in the application case).
  • “Input data” refers to all data that is transmitted to the system to be tested in a closed-loop test platform (e.g. to simulate an environment of the system to be tested or from a real environment of the system to be tested).
  • the input data may include data simulated or synthesized using models or otherwise, and/or real data (which may be captured/generated in real time or retrieved from a database and/or may be modified by one or more processing steps).
  • the input data may include real data that is manipulated in some way.
  • the input data may include time records.
  • the input signals can also have any other format imaginable.
  • Output data refers to all data that is output in the closed-loop test platform from the system to be tested or that is recorded or derived regarding the system to be tested (e.g. by an agent who monitors behavior of the system to be tested ). The output data can be at least partially fed back into the environment of the closed-loop test platform and/or made available for monitoring purposes.
  • the terms “environment” or “test environment” refer to the context in which a system to be tested is embedded (ie in the intended use case).
  • the environment can generate the input data of the system under test.
  • the output data of the system under test can (at least partially) have an impact on the environment.
  • the environment can contain further systems (e.g. further systems to which the system to be tested is connected in use) and/or objects of an environment in which the system to be tested is in the
  • the environment (or the system under test) defines one or more interfaces through which data is transferred from the environment to the system (or vice versa).
  • the environment is simulated. Accordingly, the environment can be simulated in such a way that the data transferred to the system in the application case is reproduced in such a way that the functionality of the system can be tested.
  • a “system” can be any device or group of devices designed for a specific purpose, e.g. one or more regulation, control, communication and/or monitoring tasks.
  • a system can be a component of a higher-level (further) system.
  • a system can be software.
  • a system may be a hardware component (in some examples, with associated software).
  • a system can be an embedded system.
  • the system may be a vehicle or a module for a vehicle (e.g., for an automobile).
  • the system may be a robot or a module for a robot.
  • the system may be an industrial plant or machine or a module for an industrial plant or machine. .
  • the system may be a tool or a module for a tool.
  • a “machine learning module,” according to the present disclosure, is any hardware and/or software module that is trainable for a task using machine learning.
  • the machine learning module has parameters that are changed as part of training with a training data set in such a way that desired output data is generated in response to certain input data.
  • the machine learning module trained in this way also processes unknown input data (ie those that are not included in the training data set) in a desired manner.
  • a machine learning module may include one or more artificial neural networks, but is not limited to this topology.
  • a machine learning module can be implemented in any suitable manner.
  • a machine learning module can be a software module (ie the functionality is defined in software that can be executed on a non-specific computing unit).
  • the machine learning module may be a hardware module (ie, the functionality of the machine learning module is in hardware Are defined).
  • the functionality of the machine learning module can be defined in software and in hardware.
  • a “vehicle” as used in the present disclosure is any device for transporting passengers (including drivers) and/or goods.
  • a vehicle can be at least partially autonomous or assisted.
  • a vehicle can be a motor vehicle, but also any other land vehicle.
  • Floating, diving and/or flying devices can also be vehicles according to the present disclosure.
  • FIG. 1 shows a flowchart of a method for training a machine learning module to validate or verify a closed-loop test platform for testing a system in accordance with the present disclosure.
  • Figure 2 schematically illustrates the training methods of the present disclosure.
  • FIG. 3 schematically illustrates an example method for training a machine learning module of the present disclosure.
  • Fig. 4 shows schematically a closed-loop test platform.
  • FIG. 5 shows a flowchart of a method for validating or verifying a closed-loop test platform for testing a system in accordance with the present disclosure.
  • FIG. 6 schematically illustrates an example method for validating or verifying a closed-loop test platform of the present disclosure.
  • FIG. 7 shows an example output of a method for validating or verifying a closed-loop test platform of the present disclosure.
  • FIG. 8 shows another example edition of a method for validating or verifying a closed-loop test platform of the present disclosure.
  • FIG. 1 shows a flowchart of a method 100 for training a machine learning module to validate or verify a closed-loop test platform for testing a system in accordance with the present disclosure.
  • Figure 2 schematically illustrates the training methods of the present disclosure.
  • the method for training a machine learning module to validate or verify a closed-loop test platform for validating or verifying a system includes providing 101 a plurality of data sets 11 - 14 from two or more closed-loop test platforms 20, 22.
  • the closed-loop test platform is at least one reference test platform 22 (in the present disclosure the term “reference test platform” is used as an abbreviation for the term “reference closed-loop test platform”).
  • the reference test platform 22 or its data sets 13, 14 are used as reference points for estimations of the similarities during training.
  • the machine learning module is trained to estimate the input and output data of the closed-loop test platforms to be validated or verified as similar to the input and output data of the reference test platform(s) 22.
  • Reference test platform(s) may, in some examples, be closed-loop test platforms that have already been validated or verified or are otherwise confident that they have adequately tested the system under test.
  • Each data set 11 - 14 contains input data and associated output data of a system being tested in a respective closed-loop test platform 20, 22 (not broken down in FIGS. 1 and 2). Providing may include any operation that makes the plurality of records 11-14 available for subsequent processing.
  • a data set 11 - 14 can include any data that arises when operating the closed-loop test platform with the system under test.
  • a data set 11 - 14 may include data that occurs in a specific time interval when operating the closed-loop test platform with the system under test.
  • a system in the field is also a closed-loop test platform according to the present disclosure. Therefore, a data set 11 - 14 can also include data generated during operation of the system in the application and/or in the field (even if the system may not be tested in a narrower sense in this case).
  • a data set 11 - 14 may include data for one or more test runs of a closed-loop test platform with the system under test.
  • a test run can relate to a specific operating scenario of the system to be tested and/or a specific operating situation (e.g. an operating state) of the system to be tested (e.g. the test run can replicate the operating scenario or the operating situation).
  • the input data and output data can be data that arose during the specific operating scenario and/or the specific operating situation of the test run in question (more on this below).
  • a data set can also be recorded without replicating a specific operating scenario of the system to be tested and/or a specific operating situation of the system to be tested.
  • the data set 11 - 14 data may arise from a continuous run of a closed-loop test platform with the system to be tested.
  • an operating scenario or an operating situation can be any constellation or any condition that occurs in the operation of the system to be tested (e.g. characterized by certain values of operating parameters of the system to be tested or of parameters of its environment).
  • an operating scenario or an operating situation may concern certain environmental conditions or environmental configurations of the system (e.g. a trip in certain environmental conditions or environmental configurations).
  • an operational scenario or situation may include a violation of security objectives.
  • an operating scenario or an operating situation can create a critical condition of the system under test or an error condition of the system under test.
  • the input data can include all data that is fed to the system to be tested during operation of the corresponding closed-loop test platform.
  • the input data can be structured and/or formatted differently.
  • the input data includes those signals that the system under test obtains from the environment during operation (e.g. during a specific test run or a continuous run) (e.g. sensor signals or output signals from other systems that are upstream of the system under test and/or with the communicate with the system to be tested). These signals are also referred to as input signals in the present disclosure.
  • the input data may at least partially comprise one or more time records (as shown in FIG. 2).
  • the time records can represent one or more parameters or quantities over time (i.e., be one-dimensional or multi-dimensional). Time records can also depict the temporal progression of complex data structures (e.g. object lists or images).
  • the output data can include all data that is output by the system to be tested as part of the operation of the corresponding closed-loop test platform (e.g. during a specific test run or a continuous run). In some examples, this output data may include data that is fed back into the closed-loop test platform (e.g. as part of a test run or in a continuous run). Additionally or alternatively, the output data can include data that is recorded for the purpose of monitoring the system to be tested (eg that characterizes a behavior of the system to be tested). The output data is also referred to as output signals in the present disclosure. Like the input data, the output data can be structured and/or formatted differently depending on the closed-loop test platform and/or system to be tested and/or type of operation (e.g.
  • the output data may at least partially include one or more time records.
  • the time records can represent one or more parameters or quantities over time (ie, be one-dimensional or multi-dimensional).
  • Output data can be associated with the input data if they occur in the same operation (e.g. during a specific test run or a continuous run) in a temporal connection with the input data (e.g. essentially at the same time or with an upper-limited time offset).
  • the associated output data is the data that the system outputs or that is recorded when the system is monitored when it processes certain input data (e.g. as part of a test run or in a continuous run).
  • both the input data and the output data are processed (e.g. filtered or further processed into another format). It is therefore not necessary (but possible) that the input and/or output data are processed in the form in which they arise in the closed-loop test platform.
  • the input and/or output data is derived from the data as it occurs in the closed-loop test platform.
  • the input data and/or output data includes all data that is generated in the closed-loop test platform (e.g. as part of a test run or in a continuous run). In other examples, the input data and/or the output data are only a selection of the data that arise in the closed-loop test platform (e.g. as part of a test run or in a continuous run).
  • the method may also include generating one or more of the plurality of data sets 11 - 14 (e.g., by performing a corresponding test run using the closed-loop test platform 20, 22). Alternatively or additionally, one or more of the plurality of data records 11 - 14 may already be present.
  • the method further includes determining 102 the similarity of sections 31 - 38 of the input data for pairs of the plurality of data sets 11 - 14.
  • Each pair of test data sets contains a data set 13, 14 of a reference test platform 22 (and correspondingly a second data set 11, 12 of a further closed-loop test platform 20).
  • Aspects of how the similarities are determined are described below. In other words, for example, a similarity to a second section 35 of a second data set 13 (a reference test platform 22) is determined for a first section 31 of a first data set 11.
  • This procedure can then be repeated for further (first) and further (second) sections (e.g. more than 100, more than 1000 or more than 100,000 sections). Additionally or alternatively, sections of different pairs of data sets can be compared.
  • a section is a part of the input data and/or a part of a data element of the input data (i.e., less than the complete input data and/or less than a complete data element of the input data). If a data element of the input data (or the entire input data) is (are) a time record, a section can in turn be a time record of shorter duration than the entire time record (i.e., a temporal section of the time record).
  • a length of one of the time periods may be fixed within a predetermined (fixed or variable) duration (which may depend on the type of system and/or operation being tested).
  • the predetermined duration may be shorter than 2 minutes (e.g. shorter than 30 seconds or shorter than 15 seconds). Additionally or alternatively, the predetermined duration may be longer than 2 seconds (e.g. longer than 5 seconds). These durations may be of particular interest for systems used in vehicles.
  • a section may mark a portion of the input data and/or a portion of a date of the input data (e.g., a portion of an image of a series of image data or a portion of an object list) according to a criterion other than time.
  • the method includes decomposing the input data or a date of the input data into multiple sections 31 - 38 (as shown in FIG. 2 using the time records).
  • the sections can be disjoint (i.e., have no common data points) or overlap.
  • the identification of similar sections described above can be performed for each of the sections.
  • the method may include determining similar portions 31 - 38 of input data for pairs of the plurality of data sets 11 - 14 (where each pair of test data sets includes a data set 13, 14 of a reference test platform 22).
  • the similarities are determined only for the similar sections identified. In other words will For example, for a first section 35 of a first data set (eg a test data set 13, 14 of a reference test platform 22), a similar second section 31 of a second data set 11, 12 is determined (and, if necessary, a similarity is determined). This procedure can then be repeated for further (first) and further (second) sections.
  • identifying similar sections may be performed for multiple (e.g., all) pairs of the plurality of records. For a given (first) section, several similar (second) sections can also be identified (and the corresponding similarities determined). Of course, it is also possible that no similar other section can be found for a particular section.
  • the techniques of the present disclosure may also include finding pairs of portions of input data for training a machine learning module to validate or verify a closed-loop test platform (i.e., the pairs used to determine 102 similarities of the input data ).
  • the discovery may include the above decomposition of the input data and/or identifying similar sections.
  • Finding pairs of portions of input data may include comparing a plurality of different possible combinations of data pairs (ie, two sets of data) from the plurality of data sets and selecting one or more of the different combinations of data pairs according to a predetermined criterion.
  • the possible combinations can be created by varying different parameters. For example, the length of the sections can be chosen differently. Additionally or alternatively, the sections of a pair can be offset from one another at different times. In one example, the sections of the records of a pair can be folded (optionally additionally using a variable length of the sections). In any case, a similarity can be determined for each of the possible combinations (e.g. by means of those described in the present disclosure Techniques) and combinations with the greatest similarity and/or a similarity that exceeds a certain level are selected.
  • the sections of the input data can be broken down into smaller and smaller units (e.g. time sections).
  • a first variable e.g. a first operating parameter
  • a section can be identified from the input data in which a specific criterion is met (e.g. approximate stationarity or similar criterion).
  • a second variable e.g. a second operating parameter
  • this procedure can be repeated for one or more additional sizes.
  • the method further includes determining 103 similarities 50 of portions of the output data associated with portions of input data 31-38 (ie, portions for which similarities are determined and/or determined) (not shown in FIG. 2). For each pair of sections of the input data 31 - 38, a similarity of the associated sections of the output data is thus determined.
  • the similarity metrics that can be used are described below (different similarity metrics can be used to compare the sections of the input data and to compare the sections of the output data).
  • the sections of the output data can be designed like the sections of the input data.
  • a section may in turn be a time record of shorter duration than the entire time record (ie, a temporal section of the time record).
  • a length of one of the time segments may be fixed within a predetermined (fixed or variable) duration (which may depend on the type of system being tested and/or the test run).
  • the predetermined duration can - as for the sections of the input data - be shorter than 2 minute (e.g. shorter than 30 seconds or shorter than 15 seconds). Additionally or alternatively, the predetermined duration may be longer than 2 seconds (eg longer than 5 seconds).
  • the durations of the output data portions may be different than the durations of the input data portions.
  • portions of the output data and/or input data are selected to contain data relating to one or more predetermined operating situations and/or operating scenarios of the system in the respective closed-loop test platform.
  • the one or more predetermined operating situations and/or operating scenarios may be critical operating situations and/or operating scenarios of the system (e.g., critical to the functionality or operational security of the system).
  • the criticality can be determined according to a predetermined criticality criterion.
  • the predetermined criticality criterion can be designed differently depending on the type of system to be tested.
  • a criticality criterion may be that an operating situation of the system or a state of its environment has one or more predetermined characteristics (e.g., a specific error has occurred, a specific event (e.g., a specific anomaly) has occurred in the system or its environment , the input signals and/or the output signals of the system meet one or more predetermined conditions).
  • critical operating situations and/or operating scenarios of the system can be critical driving situations and/or driving scenarios. These may include one or more of driving under special environmental conditions (e.g. lighting or weather conditions), critical objects or events in the system's environment (missing or incorrect lane markings, hidden objects, sharp curves), or certain driving maneuvers (e.g. driving above a certain speed). .
  • critical driving situations and/or driving scenarios may include one or more critical driving situations and/or driving scenarios described as “triggering events” in the ISO/PAS 21448:2019 standard are.
  • the method also includes training 104 of a machine learning module to estimate the similarity of input data and output data of a data set of a closed-loop test platform to be validated or verified and the data sets 13, 14 of the plurality of data sets of the at least one reference -Test platform 22 as a function of input data and / or output data of the data set of the closed-loop test platform to be validated or verified using the certain similarities 50 to generate a machine learning module for validating or verifying a closed-loop test platform .
  • the goal of the training is for the machine learning module to estimate how similar a test data set (and thus the closed-loop test platform that generates it) is to the one or more data sets 13, 14 used for training a reference test platform 22.
  • This estimation result can be used to validate or verify the closed-loop test platform (and/or the system contained therein). If, for example, the data sets 13, 14 of the at least one reference test platform 22 adequately validate or verify the operating behavior of the system to be tested, it can be estimated whether a closed-loop test platform to be validated or verified has a similar behavior in relation to the input data and The initial data shows data sets 13, 14. If this is the case, it can be assumed that the closed-loop test platform to be validated or verified also adequately validates or verifies the operating behavior of the system under test.
  • FIG. 3 schematically illustrates an example method for training a machine learning module 62 of the present disclosure.
  • the machine learning module can 62 at least part of the output data and / or the input data 61 for the data sets that are not generated with the at least one reference platform (in Fig. 3 the (first) closed-loop test platform 20), obtained as an input variable and generating the estimate of the similarity of the input data and output data as an output variable.
  • the determined similarities 50 are used as ground truth (ie the expected output size of the machine learning module).
  • a similarity determined using a specific similarity metric can be used directly or processed. For example, one can Similarity can be normalized and/or scaled.
  • a similarity can be divided into two or more classes (e.g. binary into the classes “similar” or “dissimilar”).
  • the machine learning module can 62 can therefore be trained to estimate the similarities 50 of the input data and output data based on the at least part of the output data and/or the input data 61.
  • the training can be carried out using any suitable training method for machine learning modules.
  • a loss function ie, a difference between the real similarities and the output of the machine learning module 62
  • can be gradually reduced by adjusting the parameters of the machine learning module eg, by using a backpropagation algorithm and/or a gradient descent algorithm).
  • the machine learning module 62 receives only a portion of the output data and/or input data as inputs.
  • the machine learning module 62 may thus be trained (and eventually be) to estimate the similarity of input data and output data based on a smaller and/or different portion of the output data and/or input data of a data set of a system under test to be estimated than was used for determining the similarities as part of the training of the machine learning module 62 (e.g. a further selection of input data and output data is used for determining the similarities as part of the training of the machine learning module 62 used).
  • the machine learning module 62 may be trained (and as a result trained) to estimate similarities between input data and output data based on only a portion of the output data of a system under test in a closed-loop testing platform. In other examples, the machine learning module 62 may be trained (and as a result trained) to estimate similarities between input data and output data based on only a portion of the input data of a system under test in a closed-loop testing platform.
  • the portion of the input data and/or output data 61 may include information that represents an operating scenario of a system contained in the closed-loop test platform or a system contained in the closed-loop test platform 20, 22 that is captured or simulated with the respective closed-loop test platforms 20, 22 recorded or simulated Characterize the operating situation of a system contained in the closed-loop test platform.
  • a portion of the input data may characterize an operational scenario or situation (eg, a time record during the operational scenario or situation). This section may be an input to the machine learning module 62 in the application (for which the machine learning module 62 estimates the similarities 50).
  • a portion of the output data may characterize an operational scenario or an operational situation (eg, a time record during the operational scenario or the operational situation).
  • This section may also be an input to the machine learning module 62 in the application (for which the machine learning module 62 estimates the similarities).
  • the machine learning module 62 may have any suitable structure to be trained to estimate the similarities of the input data and output data.
  • the machine learning module 62 may include an artificial neural network (e.g., a deep neural network and/or a convolutional neural network).
  • the machine learning module 62 may be configured to estimate a first similarity for the input data and a second similarity for the output data (e.g., a similarity of the input data and associated output data of the closed-loop test platform to be validated or verified and the corresponding data the at least one reference test platform).
  • the similarities can be classified by the machine learning module 62 (ie the machine learning module 62 outputs the similarity for a data set of a closed-loop test platform to be validated or verified in two or more classes, for example binary in the classes “similar” or “dissimilar”).
  • the machine learning module can also output a probabilistic classification into multiple similarity classes. In these examples, the machine learning module 62 is a classifier.
  • the machine learning module 62 may output a measure or other measure of similarity (eg, from 0% to 100%). In these examples, the machine learning module 62 is a regressor. In any case, the output of the machine learning module 62 can be used to determine whether a data set for a closed-loop test platform adequately tests a system under test (ie, in a similar manner to the at least one reference test platform). As described above, similarities will be determined for both the input data portions and the output data portions. In some examples, these determinations may be conducted in one of the following ways.
  • determining the similarities of the portions of the input data may include determining a distance of a first portion of the input data of a first data set of the respective pair to the input data of a second portion of the second data set of the pair.
  • a distance between the first section of the input data of a first data set of the respective pair and the second section of the input data of the second data set of the pair is calculated using a suitable distance metric.
  • a larger distance means a smaller similarity (and vice versa).
  • the distance metric may be chosen based on the type of input data being compared.
  • Example distance metrics include a Euclidean distance, a Manhattan distance, or a higher vector norm distance (for one- or multi-dimensional sections of input data spanning a Euclidean space).
  • distance metrics are a Hamming distance or a Levenshtein distance (e.g. for strings).
  • the distance metric may include a distance metric for distributions (e.g., distance metrics for probability distributions, e.g., an earth mover's distance, EMD, or a Wassertstein distance - e.g., for point clouds detected by a radar or LIDAR).
  • the portions of the input data can be directly compared to the appropriate distance measure.
  • the sections may go through one or more pre-processing stages. For example, determining the similarities may include compressing the individual sections and comparing the compressed sections of input data. In some examples, compressing the individual sections may include creating a datum characteristic of the respective section with lower dimensionality than the original section. Additionally or alternatively, compressing the individual sections may include performing one or more methods for dimensionality reduction of the individual sections (e.g. selecting the one or more most important principal components in a principal component analysis, omitting least Significant bits etc.).
  • a portion of a scalar or vector time record may be represented by a single scalar or vector datum (ie, the time dimension is omitted). Additionally or alternatively, a vector datum may be represented by a lower dimension vector datum or a scalar datum (a vector has at least two entries in the present disclosure). Compression and/or dimensionality reduction can be helpful, as input data in many closed-loop test platforms can be high-dimensional.
  • the portions of the input data may be standardized or otherwise unified.
  • sections of input data with different formats (e.g. length or dimensionality) and/or different value ranges can be compared.
  • the compression and/or dimensionality reduction methods described above may also be used in some examples to unify the portions of the input data.
  • sections (of different lengths or dimensions) can each be represented by a scalar.
  • determining the similarities of the sections of the output data may include determining a distance of a first section of the output data of a first data set of the respective pair from a second section of the second data set of the pair.
  • a distance between the first section of the output data of a first data set of the respective pair and the second section of the input data of the second data set of the pair is calculated using a suitable distance metric.
  • a larger distance means a smaller similarity (and vice versa).
  • the other techniques described above can also be used for the output data.
  • the closed-loop test platforms whose data is used to train the machine learning module 62 take various forms. 4 shows schematically a closed-loop test platform 75.
  • the closed-loop test platform 75 may include a system under test 71 and an environment 70 of the system under test.
  • the environment 70 supplies input data 73 to the system 71 to be tested.
  • the input data 73 can be generated simulatively or synthesized in another way (e.g. the environment 70 is recreated by a simulation).
  • the input data 73 may be real data from the environment of the system under test 71 (e.g. in a test stand or during operation of the system under test 71 in the field - in these examples, the environment 70 may be at least partially the real environment of the system or include a hardware replication of these).
  • input data 73 may include real data that is modified by means of one or more processing steps (e.g. error injection based on real error images).
  • Output data 74 of the system 71 to be tested can in turn be fed back into the environment 70 (and generate new input data 73 there), etc.
  • a closed-loop test platform 75 may be a software-in-the-loop test platform.
  • the system 71 under test is software (i.e. the system is formed by software).
  • the software can be part of a higher-level system (e.g. a component that contains the software and in which the software performs a predetermined function).
  • the input data 73 and the output data 74 are supplied or tapped via a software interface.
  • the software is executed during a test run or in continuous operation (on a suitable computing unit) in order to simulate operation in the application.
  • the environment 71 can be simulated and/or using real systems.
  • a closed-loop test platform 75 may be a model-in-the-loop test platform.
  • the system 71 to be tested is a model of another system (eg a model of a system that is ultimately to be used in an application).
  • the technical system can again be software (i.e. software, which models the further system).
  • the input data 73 and the output data 74 are supplied or tapped via a software interface (the input data being adapted to the respective model).
  • the model is executed during a test run or in continuous operation (on a suitable computing unit) to simulate operation in the application.
  • the environment 71 can be simulated and/or using real systems.
  • a closed-loop test platform 75 may be a hardware-in-the-loop platform.
  • the system 71 under test is a hardware component (which itself may also contain software).
  • the system under test can be a hardware component specific to an application.
  • the input data 73 and the output data 74 can be supplied/queried via existing interfaces of the hardware component.
  • the environment 71 can be simulated and/or using real systems.
  • a closed-loop test platform 75 may include the system under test 71 in the field or on a test stand.
  • the system 71 under test can be a hardware component (which in turn may also contain software) or a software component.
  • the system to be tested can be a hardware component or software component intended for an application.
  • the input data 73 and the output data 74 can be supplied/queried via existing interfaces of the hardware component or software interfaces.
  • the environment 71 is a real environment of the system in the field or on a test stand.
  • the machine learning module 62 is trained using a plurality of data sets, each generated with different closed-loop test platforms 75.
  • the closed-loop test platforms described above can be combined in any way.
  • any type of closed-loop test platform 75 described above may be a reference test platform.
  • the at least one reference test platform may include a closed-loop test platform 75 of a first type and the other(s) Closed loop test platform(s) include a closed loop test platform 75 of a second type.
  • the at least one reference test platform can include a closed-loop test platform 75, which includes the system to be tested 71 in the field or on a test stand.
  • the reference test platform may contain the real system under test. This can ensure the quality of the data sets from the reference test platform (since, for example, problems can be reduced by simulating the system and/or its environment).
  • the at least one reference test platform can also include another of the above-mentioned closed-loop test platforms 75 (e.g. a closed-loop test platform in which the environment and/or the system to be tested are simulated with greater effort than in other closed-loop test platforms to be validated or verified and/or a closed-loop test platform whose behavior has already been validated or verified).
  • the techniques of the present disclosure can be used for any systems being tested in closed-loop test platforms.
  • the system under test is a vehicle or a module for a vehicle (e.g., for an automobile).
  • the system can be configured for installation in the vehicle itself and/or for communication with the vehicle (e.g. in a backend or an infrastructure component that provides functionality for the vehicle.
  • the system can have a Provide functionality for the assisted or autonomous driving of a vehicle.
  • FIG. 5 shows a flowchart of a method for validating or verifying a closed-loop test platform for testing a system in accordance with the present disclosure.
  • Figure 6 schematically illustrates an exemplary method for validating or verifying a closed-loop test platform 81 of the present disclosure.
  • the method includes receiving 501 a data set 61 a, 61 b of a closed-loop test platform 81 for testing a system.
  • the aim of the method is to validate or verify the data set 61a, 61b or the closed-loop test platform 81 with which the data set 61a, 61b was generated.
  • the data set 61a, 61b can be constructed in the same way as the data sets described above in relation to the training of the machine learning module (e.g. the data set contains input data and associated output data as explained above).
  • the data set may include only input data or only output data (e.g., only selected input data or output data).
  • the techniques of the present disclosure can be used for any systems being tested in closed-loop test platforms.
  • the system under test is a vehicle or a module for a vehicle (e.g., for an automobile).
  • the system can be configured for installation in the vehicle itself and/or for communication with the vehicle (e.g. in a backend or an infrastructure component that provides functionality for the vehicle.
  • the system can have a Provide functionality for the assisted or autonomous driving of a vehicle.
  • the method further includes feeding 502 at least part of the data set 61a, 61b of the closed-loop test platform 81 into a machine learning module 83 for validating or verifying a closed-loop test platform.
  • the portion of the test data set 61a, 61b may include input data and/or output data that contains information that represents an operating scenario of a system or a system contained in the closed-loop test platform 81, recorded or simulated with the closed-loop test platform 81 characterize the operating situation recorded or simulated with the closed-loop test platform en 81 of a system contained in the closed-loop test platform 81.
  • the portion of input data may characterize an operational scenario or situation (e.g., a time record during the operational scenario or situation).
  • the machine learning module 83 is based on an estimate of the similarity of input data and output data of a data set of a closed-loop test platform to be validated or verified and data sets of at least one reference test platform as a function of input data and / or output data of the data set of the one to be validated or to be verified closed-loop test platform trained using the specific similarities.
  • the method also includes outputting 503 one or more estimates 40a, 40b of the similarity of input data and output data of a data set 61a, 61b of the closed-loop test platform for testing a system 81 (i.e. the closed-loop test platform to be validated or verified ) and the data sets of the at least one reference test platform with the machine learning module 83.
  • a first similarity can be output for the input data and a second similarity for the output data.
  • the estimates 40a, 40b can take various forms, as described above. For example, binary information can be output as to whether the input data and the output data are similar to the data sets used for training or not. Alternatively (or additionally), a key figure or other parameter for similarity can be output.
  • the closed-loop test platform 81 for testing a system is a closed-loop simulation platform, i.e., the environment of the system under test, the system under test, or both are created using a simulation.
  • input data that is supplied to the system to be tested in the closed-loop test platform can be generated by means of a simulation (e.g. by simulating other systems that supply the system to be tested with input data, an environment of the system to be tested , or both).
  • the output data of the system to be tested can be at least partially fed back into the simulation.
  • the method includes outputting multiple estimates of the similarity of input data and output data of the closed-loop test platform data set 61, 61 b for testing a system 81 (ie, the closed-loop test platform to be validated or verified) and the data sets of the at least one reference test platform with the machine learning module 83.
  • the multiple estimates can be estimates of similarity for be different values of operating parameters of the system being tested and/or different operating scenarios or operating situations. Based on this information, it can be recognized whether a closed-loop test platform 81 to be validated or verified adequately tests certain areas (or not).
  • the estimates of the similarities 40a, 40b can be output in any suitable manner.
  • the one or more similarity estimates 40a, 40b estimates will be output in a graphical user interface.
  • the estimates may also be output via other interfaces (in human- or machine-readable form).
  • FIG. 7 shows an example output of a method for validating or verifying a closed-loop test platform of the present disclosure.
  • 8 shows another exemplary edition of a method for validating or verifying a closed-loop test platform of the present disclosure.
  • the estimates may be determined and reported for different points or regions of a parameter space.
  • 7 and 8 show an example of a two-dimensional parameter space (with a first axis 96 that plots a first parameter and a second axis 97 that plots a second parameter).
  • the parameter space can have more than two dimensions.
  • estimates may be issued for two or more operating scenarios and/or operating situations of the system.
  • areas 90 can now be identified in the parameter space in which the closed-loop test platform to be validated or verified delivers adequate results (e.g. input and output data are similar to the input and output data of the reference test platforms under a predetermined similarity criterion) and other areas 91 in which the closed-loop test platform to be validated or verified does not provide adequate results (e.g. input and output data are not similar to the input and output data of the Reference test platforms under a predetermined similarity criterion).
  • the assessment can be done automatically and issued to a user (e.g. via a graphical user interface). In other examples, instead of a binary ranking C, similar or dissimilar, a probabilistic ranking may be made and/or a value for a similarity metric may be output.
  • a (first) estimate 94 of the similarity of the input data and a (second) estimate 95 of the similarity of the output data can be output for each point.
  • data points 92 or parameter ranges can be identified for which data sets for reference test platforms are available.
  • one or more additional steps may be taken (which in some examples may be automated).
  • data sets (e.g. for certain test runs of a closed-loop test platform to be validated or verified) for which no data from a reference test platform (e.g. the system to be tested in the field) are available can be checked for reliability.
  • the trained machine learning module can also make a reliable estimate for these data sets as to whether the data from the closed-loop test platform to be validated or verified has sufficient similarity to the expected data.
  • coverage of a parameter space by the closed-loop test platform to be validated or verified and/or the at least one reference test platform can be determined based on the one or more estimates 40a, 40b. For example, areas can be identified for which data from the reference test platform is not yet available. Additional data may be requested and/or collected for these areas. For example, for the closed-loop test platform to be validated or verified and/or the at least one reference test platform, data can be requested and/or collected in which certain operating situations or operating scenarios are dealt with (e.g if there are no similar sections of the closed-loop test platform to be validated or verified to sections in the reference test platform data sets, or vice versa)
  • targeted new data sets can be requested (and generated) for the closed-loop test platform to be validated or verified in order to increase similarity to the data sets of the reference test platform (e.g. by fuzzing the input data).
  • the system to be tested contained therein can be released and further used (e.g. in a product or in a downstream stage of a development process).
  • the present disclosure also includes deploying the system included in the closed-loop test platform.
  • the methods of the present disclosure may be automated (e.g., computer-implemented) in some examples.
  • the present disclosure also relates to a computing unit designed to carry out the methods according to the present disclosure.
  • the computing unit can take any suitable form in terms of its hardware or software (e.g. a stand-alone computing unit or a distributed computing unit, e.g. a computing unit in a cloud).
  • the present disclosure also relates to a computer program that contains instructions that, when executed on a computing device, cause the computing device to carry out the steps of the methods of the present disclosure.
  • the present disclosure also relates to a computer program product or signal that includes the computer programs of the present disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Ein allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems. Das Verfahren umfasst Bereitstellen einer Mehrzahl von Datensätzen von zwei oder mehr Closed-Loop- Testplattformen, darunter mindestens eine Referenz-Testplattform. Jeder Daten- satz enthält Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplattform. Das Verfahren umfasst weiter Bestimmen von Ähnlichkeit von Abschnitten der Eingangsdaten für Paare der Mehrzahl von Datensätzen. Jedes Paar von Testdatensätzen enthält einen Datensatz einer Referenz-Testplattform. Das Verfahren umfasst weiterhin Be- stimmen von Ähnlichkeiten von Abschnitten der Ausgangsdaten, die den Ab- schnitten von Eingangsdaten zugehörig sind und Trainieren eines Maschinen- Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Aus- gangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizie- renden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkei- ten, um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen.

Description

Beschreibung
Titel
TECHNIKEN ZUM VALIDIEREN ODER VERIFIZIEREN VON CLOSED-LOOP- TESTPLATTFORMEN
Stand der Technik
Der Einsatz von virtuellen Testplattformen bei der Verifikation und Validierung von neuen Systemen (z.B. Systemen zum autonomen oder assistierten Fahren) hat enormes Potential und kann zur Verkürzung, des Validierungsprozesses beitragen. Insbesondere bei der Freigabe von autonomen Fahrfunktionen ab Level 3 (nach SAE-Definition) ist der Einsatz simulationsgestützter Testplattformen beinahe unverzichtbar. Der Begriff „Verifikation“ bezeichnet einen Vergleich des Verhaltens und/oder der Konfiguration eines Systems mit einer vorgegebenen Spezifikation. Üblicherweise erfolgt die Verifikation anhand von Testfällen, die von den Anforderungen ^Requirements“) abgeleitet werden. Im Rahmen der Validierung wird überprüft, ob das System alle erforderlichen Sicherheitsziele erfüllt und alle nötigen Qualitätseigenschaften besitzt. Die Validierung geht über die Verifikation hinaus. Unter anderem werden bei der Validierung auch die Vollständigkeit der Anforderungen sowie die Gültigkeit von getroffenen Annahmen überprüft. Wenn im Rahmen der vorliegenden Offenbarung von „testen“ gesprochen wird, so ist damit die Überprüfung von Qualitätsanforderungen, Sicherheitszielen und weiteren Anforderungen an das System gemeint.
Durch eine virtuelle Validierung oder Verifizierung kann beispielsweise ein Umfang eines Testprogramms im Feld erheblich reduziert oder ein solches Testprogramm sogar vollständig vermieden werden (z.B. Testfahrten mit dem zu testenden System). Zusätzlich oder alternativ kann der Umfang und/oder eine Qualität eines Testprogramms erhöht werden, ohne dass dabei der Einsatz an Ressourcen steigt. Das kann beispielsweise dazu beitragen, potentielle Risiken durch seltene Ereignisse zu reduzieren. So kann bei Testfahren eine Testung der Reaktion des zu testenden Systems auf seltene Ereignisse schwierig sein. Um eine Mehrzahl bestimmter seltener Ereignisse in den Testfahrten zu beobachten, kann zum Beispiel eine prohibitive Menge an Testkilometern notwendig sein. In einer virtuellen Validierung oder Verifizierung können seltene Ereignisse durch ein passend gewähltes Szenario einfach erzeugt werden.
Die virtuelle Validierung oder Verifizierung bringt aber auch neue Probleme mit sich. Eine fundamentale Herausforderung stellt die Nachbildung einer Umgebung des zu testenden Systems oder auch des zu testenden Systems selbst in der virtuellen Umgebung dar (z.B. eine Simulation der Eingangssignale eines Systems für ein System eines Fahrzeugs). Dabei werden im Rahmen einer Modellbildung der Umgebung oder der Auswahl von Umgebungsdaten stets ein Eingangssignal der realen Umgebung des Systems durch ein simuliertes und/oder synthetisiertes Eingangssignal ersetzt. Das synthetisierte Eingangssignal kann auch auf Grundlage realer Daten erzeugt worden sein (z.B. Fehlerinjektion auf Basis realer Fehlerbilder). Hier stellt sich die Frage, ob relevante Merkmale oder Eigenschaften der realen Umgebungen verändert oder nicht dargestellt werden. Sowohl das Fehlen von relevanten Merkmalen als auch deren Veränderung kann dazu führen, dass ein zu testendes System im Rahmen der virtuellen Validierung oder Verifizierung nicht adäquat getestet wird. Das kann die Funktionalität und sogar die Betriebssicherheit des so getesteten Systems maßgeblich beeinflussen.
Diese Gefahr ist in besonderem Maße für „Closed-Loop-Testplattformen“ zur virtuellen Validierung oder Verifizierung ein Thema. In einer Closed-Loop-Testplatt- form wird ein zu testendes System mit Eingangsdaten (in der vorliegenden Offenbarung auch als „Eingangssignale“ bezeichnet) beschickt. Zudem werden Ausgangsdaten (in der vorliegenden Offenbarung auch als „Ausgangssignale“ bezeichnet) des zu testenden Systems zurückgespeist, um die Aktionen des zu testenden Systems in die Testumgebung zurückzuführen. Basierend darauf können dann die Eingangssignale angepasst werden, usw. Mittels Closed-Loop-Test- plattformen kann damit das Verhalten eines zu testenden Systems getestet werden, wenn das System auf seine Umgebung zurückwirkt (und Rückkoppelschleifen entstehen). Für „Closed-Loop-Testplattformen“ sind die oben genannten Probleme in manchen Fällen noch kritischer, da in vielen Situationen komplexe Systeme mittels verschiedener Modelle abgebildet werden müssen, um z.B. die Eingangssignale eines zu testenden Systems zu bilden (und dessen Ausgangssignale zu prozessieren). Mit steigender Komplexität der Closed-Loop-Testplatt- formen steigt im Allgemeinen auch das Risiko, dass ein zu testendes System im Rahmen der virtuellen Validierung oder Verifizierung nicht adäquat getestet wird (z.B., weil gewisse Ereignisse in der Umgebung nicht oder nicht richtig simuliert werden). Zum Beispiel muss in einer Closed-Loop-Testplattform mit simulativer Nachbildung der Umgebung eines Systems das Auftreten in einer bestimmten Situation erwarteter Reaktionen des Systems nicht immer heißen, dass ein valider Test des Systems bezüglich der bestimmten Situation durchgeführt wurde. So kann es vorkommen, dass die simulative Nachbildung der Umgebung einen anderen Auslöser für die erwartete Reaktion enthält als in der realen Umgebung.
Um die Gefahr einer unzureichenden virtuellen Validierung oder Verifizierung und den damit einhergehenden Folgen (z.B. für die Betriebssicherheit des zu testenden Systems) zu reduzieren, sind daher wiederum Maßnahmen zur Validierung oder Verifizierung von Closed-Loop-Testplattformen notwendig. Die Techniken der vorliegenden Offenbarung nehmen sich dieser Aufgabe an.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zur Validierung oder Verifizierung eines Systems. Das Verfahren umfasst Bereitstellen einer Mehrzahl von Datensätzen von zwei oder mehr Closed-Loop-Testplattformen, darunter mindestens eine Referenz- Testplattform. Jeder Datensatz enthält Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplatt- form. Das Verfahren umfasst weiter Bestimmen von Ähnlichkeit von Abschnitten der Eingangsdaten für Paare der Mehrzahl von Datensätzen. Jedes Paar von Datensätzen enthält einen Datensatz einer Referenz-Testplattform. Das Verfahren umfasst weiterhin Bestimmen von Ähnlichkeiten von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten zugehörig sind und Trainieren eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten, um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen. Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems. Das Verfahren umfasst Empfangen eines Datensatzes einer Closed-Loop-Testplattform zum Testen eines Systems, Einspeisen zumindest eines Teils des Datensatzes der Closed-Loop-Testplattform in ein Maschinen-Lern- Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform. Das Maschinen-Lern-Modul ist auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen von mindestens einer Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplatt- form trainiert. Das Verfahren umfasst weiter Ausgeben einer oder mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplatt- form.
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft eine Recheneinheit, die dazu ausgelegt ist, die Verfahren gemäß der ersten oder zweiten allgemeinen Aspekte auszuführen.
Die Techniken gemäß der ersten bis dritten allgemeinen Aspekte der vorliegenden Offenbarung können in manchen Fällen einen oder mehrere der folgenden Vorteile haben.
Erstens kann mittels der Techniken der vorliegenden Offenbarung in manchen Fällen eine Validierung oder Verifizierung auf der Ebene eines (Gesamtsystems auch in Situationen erfolgen, in denen das zu testende System und/oder seine Umgebung komplex ist/sind und bspw. mittels einer Mehrzahl (möglicherweise einer großen Zahl) von (Unter-) Modellen simulativ dargestellt werden müssen. In manchen Ansätzen des Stands der Technik werden die verschiedenen (Unter-)Modelle separat validiert oder verifiziert. Das kann aufwändig sein. Zudem kann in manchen Fällen die Validierung oder Verifizierung nur in einem O- pen-Loop erfolgen, was wie oben beschrieben unter Umständen keine zuverlässige Aussage zum Verhalten des Systems im Feld (also in einem Closed-Loop) zulässt. Die Verwendung von Ähnlichkeiten der Eingangsdaten und Ausgangsdaten des (Gesamt-) Systems zur Beurteilung der Validität einer Closed-Loop-Test- plattform ermöglicht z.B. die Erkennung, ob bestimmte Verhalten des Systems in bestimmten Betriebsszenarien ausreichend abgebildet und somit getestet werden. Die verwendeten Datensätze der Referenz-Testplattformen können adäquate Validierungen oder Verifizierungen repräsentieren. Damit kann eine Schätzung des Maschinen-Lern-Moduls bezüglich einer Ähnlichkeit der Eingangsdaten und Ausgangsdaten zu den Datensätzen der Referenz-Testplattformen in manchen Fällen eine belastbare Aussage darüber ermöglichen, ob einen zu validierende oder zu verifizierende Closed-Loop-Testplattform das Verhalten eines Systems adäquat testet. Insbesondere kann geschätzt werden, ob die zu validierende oder zu verifizierende Closed-Loop-Testplattform relevante Eingangsdaten testet und diese zu erwarteten Ausgangsdaten des zu testenden Systems führen. In manchen Techniken des Stands der Technik wird lediglich überprüft, ob z.B. bestimmte kritische Betriebssituationen in den Ausgangsdaten des zu testenden Systems vorkommen. Dann kann es jedoch passieren, dass bspw. in einer Closed-Loop-Testplattform, die eine Umgebung eines zu testenden Systems simuliert, ganz andere Eingangsdaten als im Feld zu den kritischen Betriebssituationen in den Ausgangsdaten des zu testenden Systems führen. Auch das kann bedeuten, dass die Closed-Loop-Testplattform gewisse Verhalten des zu testenden Systems nicht adäquat validiert oder verifiziert.
Zweitens lassen sich die Techniken der vorliegenden Offenbarung in manchen Fällen auch dann anwenden, wenn die Daten verschiedener Testplattformen sich unterscheiden (z.B. nicht exakt gleiche Betriebsszenarien simuliert/ gefahren wurden oder nicht alle relevanten Bedingungen in der Simulation nachgestellt wurden). Beispielsweise können auch Daten eines Dauerlaufs verwendet werden (z.B. Daten, die in Systemen im Feld aufgenommen wurden). Das kann den Aufwand zur Validierung oder Verifizierung von Testplattformen in manchen Fällen verringern, da ein breiteres Spektrum an Daten zur Validierung oder Verifizierung zur Verfügung steht (z.B. können nach Änderungen in Testprotokollen vorher erhobene Daten weiterverwendet werden oder auch Daten, die gar nicht im Rahmen eines Tests erhoben wurden). Auch können Testplattformen verschiedener Hersteller in manchen Situationen (einfacher) verglichen werden. Der Einsatz eines Maschinen-Lern-Moduls, das auf die Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen von Referenz- Testplattformen trainiert ist, kann eine zuverlässige Validierung oder Verifizierung auch in den oben genannten Fällen ermöglichen. Drittens können die Techniken der vorliegenden Offenbarung den Aufwand zur Durchführung der Validierung oder Verifizierung (z.B. einer Simulation) in manchen Fällen verringern. Die Eingangs- und Ausgangsdaten werden abschnittsweise verglichen, wobei nur ein Teil der Eingangs- und Ausgangsdaten je nach untersuchtem Betriebsszenario in Betracht gezogen wird. Zudem können die Abschnitte in manchen Fällen mittels Techniken zur Reduktion ihrer Dimensionalität kompakt dargestellt werden. Beides kann sowohl das Training als auch die Anwendung der Maschinen-Lern-Module effizienter (z.B. in Bezug auf Speicherplatz und/oder Rechenaufwand) gestalten.
Viertens können die Techniken der vorliegenden Offenbarung verwendet werden, um Betriebsszenarios oder Parameterbereiche zu identifizieren, für welche eine Closed-Loop-Testplattform noch nicht hinreichend validiert oder verifiziert wurde. Treten in dem Datensatz der Closed-Loop-Testplattform Daten auf, denen kein geeignetes Datum der Referenz-Testplattform zugeordnet werden kann, so ist dies ein Hinweis darauf, dass für die Closed-Loop-Testplattform oder darin enthaltene Teilmodelle weitere Daten zur Validierung erhoben werden müssen.
Einige Begriffe werden in der vorliegenden Offenbarung wie folgt benutzt:
Eine „Closed-Loop-Testplattform“ (auf Deutsch frei übersetzt als „Testplattform mit Rückkopplung“) ist jedes System, das eine Testumgebung für ein zu testendes System bildet, wobei das zu testende System mit Eingangsdaten beschickt wird und zudem Ausgangsdaten des zu testenden Systems in die Testumgebung zurückgespeist werden (und diese beeinflussen können). In anderen Worten bildet die „Closed-Loop-Testplattform“ eine Rückkoppel-Schleife (und eignet sich daher für die Validierung oder Verifizierung von Systemen oder Funktionen von Systemen, in denen Rückkopplungen im Systemverhalten eine Rolle spielen - was auf eine große Anzahl von Systemen zutrifft). In einer „Closed-Loop-Test- plattform“ wird zwischen dem zu testenden System (in der vorliegenden Offenbarung, so nicht explizit anders beschrieben, ein Teil der Closed-Loop-Testplatt- form) und der Umgebung des zu testenden Systems unterschieden. In manchen Fällen kann eine Closed-Loop-Testplattform sowohl das zu validierende oder zu verifizierende System als auch seine Umgebung simulieren. In anderen Beispielen kann ein reales zu validierendes oder zu verifizierendes System in die Closed-Loop-Testplattform eingefügt werden (der Begriff „real“ wird hier im Gegensatz zu dem Begriff „simuliert1 benutzt - das reale System ist später in dieser Form auch im Einsatz, ein simuliertes System bildet ein reales System nach; eine reale Umgebung ist die Umgebung im Feld oder in der Anwendung). Das zu testende System kann jede erdenkliche Form annehmen. Z.B. kann das zu testende System ein Hardware-System, ein Software-System oder ein System mit Hardware- und Software- Komponenten sein. In der vorliegenden Offenbarung ist auch ein zu testendes System im Feld oder auf einem Teststand eine Closed-Loop- Testplattform (z.B. ein Testfahrzeug, dass ein zu testendes System enthält - die Testumgebung kann hier eine reale Umgebung des zu testenden Systems im Anwendungsfall sein).
Als „Eingangsdaten“ werden alle Daten bezeichnet, die in einer Closed-Loop- Testplattform an das zu testende System übermittelt werden (z.B. um eine Umgebung des zu testenden Systems nachzubilden oder aus einer realen Umgebung des zu testenden Systems). Die Eingangsdaten können mittels Modellen oder anderweitig simulierte oder synthetisierte Daten und/oder reale Daten umfassen (die in Echtzeit aufgenommen/erzeugt oder aus einer Datenbank abgerufen werden können und/oder mittels einer oder mehrerer Bearbeitungsschritte verändert sein können). Zum Beispiel können die Eingangsdaten reale Daten umfassen, die in einer gewissen Weise manipuliert sind. In manchen Fällen können die Eingangsdaten Zeitschriebe umfassen. Die Eingangssignale können aber auch jedes erdenkliche andere Format haben.
Als „Ausgangsdaten“ werden alle Daten bezeichnet, die in der Closed-Loop-Test- plattform aus dem zu testenden System ausgegeben werden oder bezüglich des zu testenden Systems erfasst oder abgeleitet werden (z.B. von einem Agenten, der ein Verhalten des zu testenden Systems überwacht). Die Ausgangsdaten können zumindest teilweise wieder in die Umgebung der Closed-Loop-Testplatt- form zurückgespeist werden und/oder zu Überwachungszwecken bereitgestellt werden.
Die Begriffe „Umgebung“ oder „Testumgebung“ bezeichnen den Kontext, in den ein zu testendes System eingebettet ist (d.h. im avisierten Anwendungsfall). Die Umgebung kann die Eingangsdaten des zu testenden Systems erzeugen. Zudem können die Ausgangsdaten des zu testenden Systems (zumindest teilweise) auf die Umgebung zurückwirken. Die Umgebung kann weitere Systeme (z.B. weitere Systeme, mit denen das zu testende System im Einsatz verbunden ist) enthalten und/oder Objekte eines Umfelds, in dem das zu testende System in dem avisierten Anwendungsfall operiert Die Umgebung (bzw. das zu testende System) definiert eine oder mehrere Schnittstellen, über die Daten von der Umgebung an das System übertragen werden (oder andersherum). In manchen Closed-Loop-Testplattform wird die Umgebung simuliert. Dementsprechend kann die Umgebung simulativ so nachgebildet sein, dass die an das System im Anwendungsfall übergebenen Daten so nachgebildet werden, dass eine Funktionalität des Systems getestet werden kann.
Ein „System“ kann jede Vorrichtung oder Gruppe von Vorrichtungen sein, die für einen bestimmten Zweck ausgelegt ist, z.B. eine oder mehrere Regel-, Steuer-, Kommunikations- und/oder Überwachungsaufgaben. Ein System kann eine Komponente eines übergeordneten (weiteren) Systems sein. Ein System kann eine Software sein. In anderen Beispielen kann ein System eine Hardware-Komponente sein (in manchen Beispielen mit zugehöriger Software). Zum Beispiel kann ein System ein embedded System (auf Deutsch „eingebettetes System“) sein. In manchen Beispielen kann das System ein Fahrzeug oder ein Modul für ein Fahrzeug (z.B. für ein Kraftfahrzeug) sein. In anderen Beispielen kann das System ein Roboter oder ein Modul für einen Roboter sein. In wieder anderen Beispielen kann das System eine Industrieanlage oder -maschine oder ein Modul für eine Industrieanlage oder -maschine sein. . In wieder anderen Beispielen kann das System ein Werkzeug oder ein Modul für ein Werkzeug sein.
Ein „Maschinen-Lern-Modul“ ist gemäß der vorliegenden Offenbarung jedes Hardware- und/oder Softwaremodul, das mittels maschinellen Lernens für eine Aufgabe trainierbar/trainiert ist. Das Maschinen-Lern-Modul weist dazu Parameter auf, die im Rahmen eines Trainings mit einem Trainings-Datensatz so verändert werden, dass in Antwort auf bestimmte Eingangsdaten gewünschte Ausgangsdaten erzeugt werden. Im günstigen Fall prozessiert das so trainierte Ma- schinen-Lern-Modul auch unbekannte Eingangsdaten (d.h. solche, die nicht in den Trainings-Datensatz enthalten sind) in einer gewünschten Weise. Ein Ma- schinen-Lern-Modul kann ein oder mehrere künstliche neuronale Netzwerke umfassen, ist aber nicht auf diese Topologie beschränkt. Ein Maschinen-Lern-Modul kann in jeder geeigneten Weise implementiert sein. Zum Beispiel kann ein Ma- schinen-Lern-Modul ein Software- Modul sein (d.h. die Funktionalität ist in Software definiert, die auf einer unspezifischen Recheneinheit ausgeführt werden kann). In anderen Beispielen kann das Maschinen-Lern-Modul eine Hardware- Modul sein (d.h., die Funktionalität des Maschinen-Lern-Moduls ist in Hardware definiert). In wieder anderen Beispielen kann die Funktionalität des Maschinen- Lern-Moduls in Software und in Hardware definiert sein.
Ein „Fahrzeug“ ist in der vorliegenden Offenbarung jede Vorrichtung zum Transport von Passagieren (einschließlich Fahrern) und/oder Gütern. Ein Fahrzeug kann zumindest teilweise autonom oder assistiert sein. Ein Fahrzeug kann ein Kraftfahrzeug, aber auch jedes andere Landfahrzeug sein. Auch schwimmende, tauchende und/oder fliegende Vorrichtungen können Fahrzeuge gemäß der vorliegenden Offenbarung sein.
Kurzbeschreibung der Figuren
Fig. 1 zeigt ein Flussdiagramm eines Verfahrens zum Training eines Maschi- nen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop- Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung.
Fig. 2 illustriert schematisch die Verfahren zum Training der vorliegenden Offenbarung.
Fig. 3 illustriert schematisch ein beispielhaftes Verfahren zum Training eines Maschinen-Lern-Moduls der vorliegenden Offenbarung.
Fig. 4 zeigt schematisch eine Closed-Loop-Testplattform.
Fig. 5 zeigt ein Flussdiagramm eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung.
Fig. 6 illustriert schematisch ein beispielhaftes Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
Fig. 7 zeigt eine beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
Fig. 8 zeigt eine weitere beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform der vorliegenden Offenbarung.
Detaillierte Beschreibung Zunächst werden in Bezug auf Fig. 1 bis Fig. 4 die Techniken zum Trainieren eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop- Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung erläutert. Im Folgenden werden anhand Fig. 5 bis Fig. 8 die Techniken zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung diskutiert (d.h., die Anwendung des trainierten Maschinen-Lern-Moduls).
Fig. 1 zeigt ein Flussdiagramm eines Verfahrens 100 zum Training eines Maschi- nen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplatt- form zum Testen eines Systems gemäß der vorliegenden Offenbarung. Fig. 2 illustriert schematisch die Verfahren zum Training der vorliegenden Offenbarung.
Das Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zur Validierung oder Verifizierung eines Systems umfasst Bereitstellen 101 einer Mehrzahl von Datensätzen 11 - 14 von zwei oder mehr Closed-Loop-Testplattformen 20, 22. Unter den Closed- Loop -Testplattform en ist mindestens eine Referenz-Testplattform 22 (in der vorliegenden Offenbarung wird der Begriff „Referenz-Testplattform“ als Abkürzung für den Begriff „Referenz-Closed-Loop-Testplattform“ verwendet). Die Referenz- Testplattform 22 bzw. deren Datensätze 13, 14 werden im Rahmen des Trainings als Bezugspunkte für Schätzungen der Ähnlichkeiten verwendet. In anderen Worten wird/ist das Maschinen-Lern-Modul darauf trainiert, zu schätzen wir ähnlich die Eingangs- und Ausgangsdaten der zu validierenden oder zu verifizierenden Closed-Loop-Testplattformen den Eingangs- und Ausgangsdaten der Referenz-Testplattform (en) 22 sind. Referenz-Testplattform (en) können in manchen Beispielen Closed-Loop-Testplattformen, die bereits validiert oder verifiziert wurden oder für die aus sonstigen Gründen ein Vertrauen besteht, dass sie das zu testende System adäquat getestet haben.
Jeder Datensatz 11 - 14 enthält Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Testplattform 20, 22 (nicht in Fig. 1 und Fig. 2 aufgeschlüsselt). Das Bereitstellen kann jedwede Operation umfassen, mit der die Mehrzahl von Datensätzen 11 -14 für die nachfolgende Verarbeitung zugänglich gemacht werden. Ein Datensatz 11 -14 kann jedwede Daten umfassen, die beim Betrieb der Closed-Loop-Testplattform mit dem zu testenden System anfallen. Zum Beispiel kann ein Datensatz 11 -14 Daten umfassen, die in einem bestimmten Zeitintervall beim Betrieb der Closed-Loop-Testplattform mit dem zu testenden System anfallen. Wie bereits erwähnt ist auch ein System im Feld eine Closed-Loop-Testplatt- form gemäß der vorliegenden Offenbarung. Daher kann ein Datensatz 11 -14 auch Daten, die beim Betrieb des Systems in der Anwendung und/oder im Feld anfallen, umfassen (auch wenn das System in diesem Fall nicht in einem engeren Sinne getestet werden mag).
Ein Datensatz 11 -14 kann Daten für einen oder mehrere Testläufe einer Closed- Loop -Testplattform mit dem zu testenden System umfassen. Ein Testlauf kann dabei in manchen Beispielen ein bestimmtes Betriebsszenario des zu testenden Systems und/oder eine bestimmte Betriebssituation (z.B. ein Betriebszustand) des zu testenden Systems betreffen (z.B. kann der Testlauf das Betriebsszenario oder die Betriebssituation nachbilden). Die Eingangsdaten und Ausgangsdaten können in diesem Fall Daten sein, die während des bestimmten Betriebsszenarios und/oder der bestimmten Betriebssituation des betreffenden Testlaufs angefallen sind (dazu unten mehr). In anderen Beispielen kann ein Datensatz aber auch aufgenommen werden, ohne dass ein bestimmtes Betriebsszenario des zu testenden Systems und/oder eine bestimmte Betriebssituation des zu testenden Systems nachgebildet werden. Zum Beispiel kann der Datensatz 11 -14 Daten aus einem Dauerlauf einer Closed-Loop-Testplattform mit dem zu testenden System anfallen.
Ein Betriebsszenario oder eine Betriebssituation kann in der vorliegenden Offenbarung jede im Betrieb des zu testenden Systems auftretende Konstellation oder jeder im Betrieb des zu testenden Systems auftretende Zustand sein (bspw. gekennzeichnet durch bestimmte Werte von Betriebsparametern des zu testenden Systems oder von Parametern seiner Umgebung). Zum Beispiel kann ein Betriebsszenario oder eine Betriebssituation bestimmte Umgebungsbedingungen bzw. Umgebungs-Konfigurationen des Systems betreffen (z.B. eine Fahrt in bestimmten Umgebungsbedingungen bzw. Umgebungs-Konfigurationen). Zusätzlich oder alternativ kann ein Betriebsszenario oder eine Betriebssituation eine Verletzung von Sicherheitszielen umfassen. Weiter zusätzlich oder alternativ kann ein Betriebsszenario oder eine Betriebssituation einen kritischen Zustand des zu testenden Systems oder einen Fehlerzustand des zu testenden Systems betreffen.
Die Eingangsdaten können alle Daten umfassen, die im Betrieb der entsprechenden Closed-Loop-Testplattform dem zu testenden System zugeführt werden. Je nach Closed-Loop-Testplattform und/oder zu testenden System und/oder Art des Betriebs (z.B. ein bestimmter Testlauf oder eine Dauerlauf) können die Eingangsdaten verschieden aufgebaut und/oder formatiert sein. In manchen Beispielen umfassen die Eingangsdaten diejenigen Signale, die das zu testende System im Betrieb (z.B. während eines bestimmtes Testlaufs oder eines Dauerlaufs) aus der Umgebung bezieht (z.B. Sensorsignale oder Ausgangssignale anderer Systeme, die dem zu testenden System vorgelagert sind und/oder mit dem zu testenden System kommunizieren). Diese Signale werden in der vorliegenden Offenbarung auch als Eingangssignale bezeichnet. In manchen Beispielen können die Eingangsdaten zumindest teilweise einen oder mehrere Zeitschriebe umfassen (wie in Fig. 2 gezeigt). Die Zeitschriebe können einen oder mehrere Parameter oder Größen über der Zeit abbilden (d.h., eindimensional oder mehrdimensional sein). Zeitschriebe können auch den zeitlichen Verlauf von komplexen Datenstrukturen abbilden (z.B. Objektlisten oder Bilder).
Die Ausgangsdaten können alle Daten umfassen, die im Rahmen des Betriebs der entsprechenden Closed-Loop-Testplattform (z.B. während eines bestimmtes Testlaufs oder eines Dauerlaufs) von dem zu testenden System ausgegeben werden. Diese Ausgangsdaten können in manchen Beispielen Daten umfassen, die in die Closed-Loop-Testplattform zurückgespeist werden (z.B. im Rahmen eines Testlaufes oder im Dauerlauf). Zusätzlich oder alternativ können die Ausgangsdaten Daten umfassen, die zum Zwecke der Überwachung des zu testenden Systems aufgenommen werden (z.B. die ein Verhalten des zu testenden Systems charakterisieren). Die Ausgangsdaten werden in der vorliegenden Offenbarung auch als Ausgangssignale bezeichnet. Wie auch die Eingangsdaten können die Ausgangsdaten je nach Closed-Loop-Testplattform und/oder zu testenden System und/oder Art des Betriebs (z.B. ein bestimmter Testlauf oder eine Dauerlauf) verschieden aufgebaut und/oder formatiert sein. In manchen Beispielen können die Ausgangsdaten zumindest teilweise einen oder mehrere Zeitschriebe umfassen. Die Zeitschriebe können einen oder mehrere Parameter oder Größen über der Zeit abbilden (d.h., eindimensional oder mehrdimensional sein). Ausgangsdaten können den Eingangsdaten zugehörig sein, wenn sie im gleichen Betrieb (z.B. während eines bestimmtes Testlaufs oder eines Dauerlaufs) in zeitlichem Zusammenhang mit den Eingangsdaten anfallen (z.B. im Wesentlichen gleichzeitig oder mit einem nach oben begrenzten zeitlichen Versatz). In anderen Worten sind die zugehörigen Ausgangsdaten die Daten, die das System ausgibt oder die bei der Überwachung des Systems aufgenommen werden, wenn es bestimmte Eingangsdaten verarbeitet (z.B. im Rahmen eines Testlaufes oder im Dauerlauf).
Sowohl die Eingangsdaten als auch die Ausgangsdaten sind in manchen Beispielen verarbeitet (z.B. gefiltert oder in ein anderes Format weiterverarbeitet). Es ist also nicht notwendig (aber möglich), dass die Eingangs- und/oder Ausgangsdaten in der Form verarbeitet werden, in der sie in der Closed-Loop-Test- plattform anfallen. In anderen Beispielen werden die Eingangs- und/oder Ausgangsdaten aus den Daten abgeleitet, in der sie in der Closed-Loop-Testplatt- form anfallen. In manchen Beispielen umfassen die Eingangsdaten und/oder Ausgangsdaten sämtliche Daten, die in der Closed-Loop-Testplattform anfallen (z.B. im Rahmen eines Testlaufes oder im Dauerlauf). In anderen Beispielen sind die Eingangsdaten und/oder die Ausgangsdaten nur eine Auswahl der Daten, die in der Closed-Loop-Testplattform anfallen (z.B. im Rahmen eines Testlaufes oder im Dauerlauf).
In manchen Beispielen kann das Verfahren auch das Erzeugen einer oder mehrerer der Mehrzahl von Datensätzen 11 -14 umfassen (z.B. durch das Durchführen eines entsprechenden Testlaufs mittels der Closed-Loop-Testplattform 20, 22). Alternativ oder zusätzlich können einer oder mehrerer der Mehrzahl von Datensätzen 11 -14 bereits vorliegen.
Das Verfahren umfasst zudem Bestimmen 102 der Ähnlichkeit von Abschnitten 31 -38 der Eingangsdaten für Paare der Mehrzahl von Datensätzen 11 -14. Jedes Paar von Testdatensätzen enthält einen -Datensatz 13, 14 einer Referenz-Testplattform 22 (und dementsprechend einen zweiten Datensatz 11 , 12 einer weiteren Closed-Loop-Testplattform 20). Aspekte zur Art der Ermittlung der Ähnlichkeiten (z.B. einsetzbare Ähnlichkeitsmetriken) werden weiter unten beschrieben. In anderen Worten wird z.B. für einen ersten Abschnitt 31 eines ersten Datensatzes 11 eine Ähnlichkeit mit einem zweiten Abschnitt 35 eines zweiten Datensatzes 13 (einer Referenz-Testplattform 22) bestimmt. Dieses Vorgehen kann dann für weiter (erste) und weitere (zweite) Abschnitte (z.B. mehr als 100, mehr als 1000 oder mehr als 100.000 Abschnitte) wiederholt werden. Zusätzlich oder alternativ können Abschnitte verschiedener Paare von Datensätzen verglichen werden.
Ein Abschnitt ist dabei ein Teil der Eingangsdaten und/oder ein Teil eines Daten- Elements der Eingangsdaten (d.h., weniger als die kompletten Eingangsdaten und/oder weniger als ein komplettes Daten-Element der Eingangsdaten). Wenn ein Daten-Element der Eingangsdaten (oder die gesamten Eingangsdaten) ein Zeitschrieb ist (sind), kann ein Abschnitt wiederum ein Zeitschrieb kürzerer Dauer als der gesamte Zeitschrieb sein (d.h., ein zeitlicher Abschnitt des Zeitschriebs). In manchen Beispielen kann eine Länge eines der zeitlichen Abschnitte innerhalb einer vorbestimmten (festen oder variablen) Dauer festgelegt sein (die von der Art des zu testenden Systems und/oder des Betriebs abhängen kann). Die vorbestimmte Dauer kann kürzer als 2 Minuten sein (z.B. kürzer als 30 Sekunden oder kürzer als 15 Sekunden). Zusätzlich oder alternativ kann die vorbestimmte Dauer länger als 2 Sekunden sein (z.B. länger als 5 Sekunden). Diese Dauern können insbesondere für Systeme, die in Fahrzeugen eingesetzt werden, von Interesse sein.
In anderen Beispielen kann ein Abschnitt gemäß einem anderen Kriterium als der Zeit einen Teil der Eingangsdaten und/oder einen Teil eines Datums der Eingangsdaten auszeichnen (z.B., ein Ausschnitt eines Bildes einer Serie von Bilddaten oder ein Ausschnitt einer Objektliste).
In manchen Beispielen umfasst das Verfahren Zerlegen der Eingangsdaten oder eines Datums der Eingangsdaten in mehrere Abschnitte 31 -38 (wie in Fig. 2 anhand der Zeitschriebe gezeigt). Die Abschnitte können disjunkt sein (d.h., keine gemeinsamen Datenpunkte aufweisen) oder überlappen. Das oben beschriebene Ermitteln der ähnlichen Abschnitte kann für jeden der Abschnitte durchgeführt werden.
In manchen Beispielen kann das Verfahren Ermitteln von ähnlichen Abschnitten 31 - 38 von Eingangsdaten für Paare der Mehrzahl von Datensätzen 11 -14 umfassen (wobei jedes Paar von Testdatensätzen einen Datensatz 13, 14 einer Referenz-Testplattform 22 umfasst). In manchen Beispielen werden die Ähnlichkeiten nur für die ermittelten ähnlichen Abschnitte bestimmt. In anderen Worten wird z.B. für einen ersten Abschnitt35 eines ersten Datensatzes (z.B. ein Testdaten- Satz 13, 14 einer Referenz-Testplattform 22) ein ähnlicher zweiter Abschnitt 31 eines zweiten Datensatzes 11 , 12 ermittelt (und ggf. eine Ähnlichkeit bestimmt). Dieses Vorgehen kann dann für weiter (erste) und weitere (zweite) Abschnitte wiederholt werden. Wenn die Mehrzahl von Datensätzen mehr als zwei Datensätze enthält, kann das Ermitteln von ähnlichen Abschnitten (und ggf. das Bestimmen von Ähnlichkeiten) für mehrere (z.B. alle) Paare der Mehrzahl von Datensätzen durchgeführt werden. Für einen bestimmten (ersten) Abschnitt können auch mehrere ähnliche (zweite) Abschnitte ermittelt werden (und die entsprechenden Ähnlichkeiten bestimmt werden). Natürlich ist es auch möglich, dass für einen bestimmten Abschnitt auch kein ähnlicher anderer Abschnitt gefunden werden kann.
In manchen Beispielen können die Techniken der vorliegenden Offenbarung auch das Auffinden von Paaren von Abschnitten von Eingangsdaten zum Training eines Maschinen-Lernmoduls zur Validierung oder Verifizierung einer Closed-Loop-Testplattform umfassen (d.h. die Paare, die zum Bestimmen 102 von Ähnlichkeiten der Eingangsdaten verwendet werden). In anderen Worten kann zunächst in der Mehrzahl von Datensätzen nach Abschnitten von Eingangsdaten gesucht werden, die miteinander gepaart werden und deren Ähnlichkeit im Weiteren wie beschrieben bestimmt wird. Das Auffinden kann das vorstehende Zerlegen der Eingangsdaten und/oder das Ermitteln von ähnlichen Abschnitten umfassen.
Das Auffinden von Paaren von Abschnitten von Eingangsdaten kann Vergleichen mehrerer unterschiedlicher möglicher Kombinationen von Datenpaaren (d.h. zwei Datenätzen) aus der Mehrzahl von Datensätzen und Auswählen einer oder mehrere der unterschiedlichen Kombinationen von Datenpaaren gemäß einem vorbestimmten Kriterium umfassen. Die möglichen Kombinationen können durch Variationen verschiedener Parameter erzeugt werden. Zum Beispiel kann eine Länge der Abschnitte unterschiedlich gewählt werden. Zusätzlich oder alternativ können die Abschnitte eines Paares unterschiedlich zeitlich versetzt zueinander sein. In einem Beispiel können die Abschnitte der Datensätze eines Paares gefaltet werden (optional zusätzlich unter Benutzung einer variablen Länge der Abschnitte). In jedem Fall kann für die möglichen Kombinationen jeweils eine Ähnlichkeit bestimmt werden (z.B. mittels der in der vorliegenden Offenbarung beschriebenen Techniken) und Kombinationen mit der größten Ähnlichkeit und/oder einer Ähnlichkeit, die ein bestimmtes Maß übersteigt, ausgewählt werden.
Zusätzlich oder alternativ können in manchen Beispielen zum Auswählen der Paare die Abschnitte der Eingangsdaten in immer kleinere Einheiten zerlegt werden (z.B. Zeitabschnitte). Zunächst kann für eine erste Größe (z.B. ein erster Betriebsparameter) ein Abschnitt aus den Eingangsdaten identifiziert werden, in dem ein bestimmtes Kriterium erfüllt ist (beispielsweise annähernde Stationarität oder ähnliches Kriterium). Für den betreffenden Abschnitt wird eine zweite Größe (z.B. ein zweiter Betriebsparameter) betrachtet und der Abschnitt in kleinere Teile zerlegt, in denen jeweils wieder ein bestimmtes Kriterium für die zweite Größe erfüllt ist. In manchen Beispielen kann dieses Procedere für eine oder mehrere weitere Größen wiederholt werden. Dann liegt eine Mehrzahl von kürzeren Abschnitten (als der ursprüngliche Abschnitt) vor, in denen für alle behandelten Größen (erste Größe, zweite Größe usw.) jeweils bestimmte Kriterien erfüllen. Diese Abschnitte können sowohl in den Eingangsdaten der Datensätzen der mindestens einen Referenz-Testplattform als auch in den weiteren Datensätzen ermittelt werden und zu den Paaren zusammengestellt werden, deren Ähnlichkeiten wie in der vorliegenden Offenbarung beschrieben bestimmt wird.
Das Verfahren umfasst zudem Bestimmen 103 von Ähnlichkeiten 50 von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten 31 - 38 (d.h. den Abschnitten, für die Ähnlichkeiten bestimmt werden und/oder die ermittelt wurden) zugehörig sind (nicht in Fig. 2 gezeigt). Für jedes Paar von Abschnitten der Eingangsdaten 31 -38 wird somit eine Ähnlichkeit der zugehörigen Abschnitte der Ausgangsdaten bestimmt. Wiederum werden die verwendbaren Ähn- lichkeitsmetriken weiter unten beschreiben (für den Vergleich der Abschnitte der Eingangsdaten und den Vergleich der Abschnitte der Ausgangsdaten können unterschiedliche Ähnlichkeitsmetriken eingesetzt werden). Die Abschnitte der Ausgangsdaten können wie die Abschnitte der Eingangsdaten ausgestaltet sein. Z.B. können, wenn ein Datum der Ausgangsdaten (oder die gesamten Ausgangsdaten) ein Zeitschrieb ist, ein Abschnitt wiederum ein Zeitschrieb kürzerer Dauer als der gesamte Zeitschrieb sein (d.h., ein zeitlicher Abschnitt des Zeitschriebs). In manchen Beispielen kann eine Länge eines der zeitlichen Abschnitte innerhalb einer vorbestimmten (festen oder variablen) Dauer festgelegt sein (die von der Art des zu testenden Systems und/oder des Testlaufs abhängen kann). Die vorbestimmte Dauer kann - wie für die Abschnitte der Eingangsdaten - kürzer als 2 Minute sein (z.B. kürzer als 30 Sekunden oder kürzer als 15 Sekunden). Zusätzlich oder alternativ kann die vorbestimmte Dauer länger als 2 Sekunden sein (z.B. länger als 5 Sekunden). In manchen Beispielen können die Dauern der Abschnitte der Ausgangsdaten unterschiedlich sein von den Dauern der Abschnitte der Eingangsdaten.
In manchen Beispielen sind Abschnitte der Ausgangsdaten und/oder Eingangsdaten ausgewählt, um Daten zu einer oder mehrere vorbestimmter Betriebssituationen und/oder Betriebsszenarios des Systems in der jeweiligen Closed-Loop- Testplattform zu enthalten.
Zum Beispiel können die ein oder mehreren vorbestimmten Betriebssituationen und/oder Betriebsszenarios kritische Betriebssituationen und/oder Betriebsszenarios des Systems sein (z.B. kritisch für die Funktionalität oder Betriebssicherheit des Systems). Die Kritikalität kann nach einem vorbestimmten Kritikalitätskri- terium bestimmt das. Das vorbestimmte Kritikalitätskriterium kann je nach Art des zu testenden Systems unterschiedlich ausgestaltet sein. In manchen Beispielen kann ein Kritikalitätskriterium sein, dass eine Betriebssituation des Systems oder ein Zustand seiner Umgebung ein oder mehrere vorbestimmte Charakteristika aufweist (z.B. ein bestimmter Fehler ist aufgetreten, ein bestimmtes Ereignis (bspw. eine bestimmte Anomalie) ist in dem System oder seiner Umgebung aufgetreten, die Eingangssignale und/oder die Ausgangssignale des Systems erfüllen eine oder mehrere vorbestimmte Bedingungen).
Zum Beispiel können kritische Betriebssituationen und/oder Betriebsszenarios des Systems im Falle eines Systems für ein Fahrzeug kritische Fahrsituationen und/oder Fahrszenarios sein. Diese können eines oder mehrere umfassen von Fahren unter besonderen Umgebungsbedingen (z.B. Lichtverhältnisse oder Wetterbedingungen), kritische Objekte oder Ereignisse in der Umgebung des Systems (fehlende oder falsche Fahrspurmarkierungen, verdeckte Objekte, scharfe Kurven) oder bestimmte Fahrmanöver (z.B. Fahren über einer bestimmten Geschwindigkeit). In manchen Beispielen können kritische Fahrsituationen und/oder Fahrszenarios ein oder mehrere kritische Fahrsituationen und/oder Fahrszenarios umfassen, die im Standard ISO/PAS 21448:2019 (Englischer Titel „Road vehicles — Safety of the intended functionality“) als “Triggering Events” beschrieben sind. Das Verfahren umfasst zudem Trainieren 104 eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Test- plattform und der Datensätze 13, 14 der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform 22 als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten 50, um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed- Loop -Testplattform zu erzeugen. In anderen Worten ist das Ziel des Trainings, dass das Maschinen-Lern-Modul schätzt, wie ähnlich ein Testdaten-Satz (und damit die diesen erzeugende Closed-Loop-Testplattform) der für das Training verwendeten ein oder mehreren Datensätzen 13, 14 der mindestens einen Referenz-Testplattform 22 ist.
Dieses Schätzergebnis kann zum Validieren oder Verifizieren Closed-Loop-Test- plattform (und/oder des darin enthaltenen Systems) verwendet werden. Wenn z.B. die Datensätze 13, 14 der mindestens einen Referenz-Testplattform 22 das Betriebsverhalten des zu testenden Systems adäquat validieren oder verifizieren, kann geschätzt werden, ob eine zu validierende oder zu verifizierende Closed- Loop -Testplattform ein ähnliches Verhalten in Bezug auf die Eingangsdaten und Ausgangsdaten zeigt wir die Datensätze 13, 14. Ist das der Fall, kann davon ausgegangen werden, dass auch die zu validierende oder zu verifizierende Closed- Loop -Testplattform das Betriebsverhalten des zu testenden Systems adäquat validiert oder verifiziert.
Weiter Aspekte des Trainings des Maschinen-Lern-Moduls werden nun in Bezug auf Fig. 3 erläutert. Fig. 3 illustriert schematisch ein beispielhaftes Verfahren zum Training eines Maschinen-Lern-Moduls 62 der vorliegenden Offenbarung. Das Maschinen-Lern-Modul kann 62 zumindest einen Teil der Ausgangsdaten und/oder der Eingangsdaten 61 für die Datensätze, die nicht mit der mindestens einen Referenz- Plattform erzeugt sind (in Fig. 3 die (erste) Closed-Loop-Test- plattform 20), als Eingangsgröße erhalten und die Schätzung der Ähnlichkeit der der Eingangsdaten und Ausgangsdaten als Ausgangsgröße erzeugen. Im Rahmen des Trainings werden die bestimmten Ähnlichkeiten 50 als Ground Truth (d.h. die erwartete Ausgabegröße des Maschinen-Lern-Moduls) verwendet. Dabei kann eine mittels einer bestimmten Ähnlichkeitsmetrik ermittelte Ähnlichkeit direkt verwendet oder aber prozessiert werden. Zum Beispiel kann eine Ähnlichkeit normiert und/oder skaliert werden. In anderen Beispielen kann eine Ähnlichkeit in zwei oder mehr Klassen eingeteilt werden (z.B. binär in die Klassen „ähnlich“ oder „unähnlich“). Das Maschinen-Lern-Modul kann 62 kann also darauf trainiert werden, basierend auf dem zumindest einen Teil der Ausgabedaten und/oder der Eingabedaten 61 die Ähnlichkeiten 50 der Eingabedaten und Ausgabedaten zu schätzen. Das Training kann mittels jeder geeigneten Trainingsmethode für Maschinen-Lern-Module durchgeführt werden. Zum Beispiel kann eine Verlustfunktion (d.h., ein Unterschied zwischen den realen Ähnlichkeiten und der Ausgabe des Maschinen-Lern-Moduls 62) durch Anpassung der Parameter des Maschinen-Lern-Moduls schrittweise reduziert werden (z.B. durch Verwendung eines Backpropagation-Algorithmus und/oder eines Gradienten-Abstiegs-Algo- rithmus).
In manchen Beispielen erhält das Maschinen-Lern-Modul 62 nur einen Teil der Ausgabedaten und/oder Eingabedaten als Eingangsgrößen. In diesem Fall kann das Maschinen-Lern-Modul 62 somit darauf trainiert werden (und schließlich sein), eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten basierend auf einem kleineren und/oder anderen Teil der Ausgabedaten und/oder Eingabedaten eines Datensatzes eines zu testenden Systems zu schätzen, als für die Bestimmung der Ähnlichkeiten im Rahmen des Trainings des Ma- schinen-Lern-Moduls 62 verwendet wurde (z.B. eine weitere Auswahl an Eingangsdaten und Ausgangsdaten wird für die Bestimmung der Ähnlichkeiten im Rahmen des Trainings des Maschinen-Lern-Moduls 62 verwendet). Zum Beispiel kann das Maschinen-Lern-Modul 62 darauf trainiert werden (und als Ergebnis dann trainiert sein), basierend auf nur einem Teil der Ausgangsdaten eines zu testenden Systems in einer Closed-Loop-Testplattform Ähnlichkeiten zwischen Eingangsdaten und Ausgangsdaten zu schätzen. In anderen Beispielen kann das Maschinen-Lern-Modul 62 darauf trainiert werden (und als Ergebnis dann trainiert sein), basierend auf nur einem Teil der Eingangsdaten eines zu testenden Systems in einer Closed-Loop-Testplattform Ähnlichkeiten zwischen Eingangsdaten und Ausgangsdaten zu schätzen.
Zusätzlich oder alternativ kann in manchen Beispielen der Teil der Eingangsdaten und/oder Ausgangsdaten 61 Informationen umfassen, die ein mit der jeweiligen Closed-Loop-Testplattformen 20, 22 erfasstes oder simuliertes Betriebsszenario eines in der Closed-Loop-Testplattform enthaltenen Systems oder eine mit der jeweiligen Closed-Loop-Testplattformen 20, 22 erfasste oder simulierte Betriebssituation eines in der Closed-Loop-Testplattform enthaltenen Systems charakterisieren. Zum Beispiel kann ein Abschnitt der Eingangsdaten ein Betriebsszenario oder eine Betriebssituation charakterisieren (z.B. ein Zeitschrieb während des Betriebsszenarios oder der Betriebssituation). Dieser Abschnitt kann eine Eingangsgröße des Maschinen-Lern-Moduls 62 im Anwendungsfall sein (für die das des Maschinen-Lern-Modul 62 die Ähnlichkeiten 50 schätzt). Zusätzlich oder alternativ kann ein Abschnitt der Ausgangsdaten ein Betriebsszenario oder eine Betriebssituation charakterisieren (z.B. ein Zeitschrieb während des Betriebsszenarios oder der Betriebssituation). Dieser Abschnitt kann ebenfalls eine Eingangsgröße des Maschinen-Lern-Moduls 62 im Anwendungsfall sein (für die das des Maschinen-Lern-Modul 62 die Ähnlichkeiten schätzt).
Das Maschinen-Lern-Modul 62 kann jede geeignete Struktur aufweisen, um auf die Schätzung der Ähnlichkeiten der Eingangsdaten und Ausgangsdaten trainiert werden zu können. In manchen Fällen kann das Maschinen-Lern-Modul 62 ein künstliches neuronales Netz enthalten (z.B. ein tiefes neuronales Netz und/oder ein faltendes neuronales Netz).
Das Maschinen-Lern-Modul 62 kann ausgelegt sein, eine erste Ähnlichkeit für die Eingangsdaten und eine zweite Ähnlichkeit für die Ausgangsdaten zu schätzen (z.B. eine Ähnlichkeit der Eingangsdaten und zugehörigen Ausgangsdaten der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und den entsprechenden Daten der mindestens einen Referenz-Testplattform). Die Ähnlichkeiten können von dem Maschinen-Lern-Modul 62 klassifiziert werden (d.h. das Maschinen-Lern-Modul 62 gibt die Ähnlichkeit für einen Datensatz einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattforme in zwei oder mehreren Klassen aus, z.B. binär in den Klassen „ähnlich“ oder „unähnlich“). Das Ma- schinen-Lern-Modul kann auch eine probabilistische Einstufung in mehrere Klassen der Ähnlichkeit ausgeben. In diesen Beispielen ist das Maschinen-Lern-Mo- dul 62 ein Klassifikator. In anderen Beispielen kann das Maschinen-Lern-Modul 62 eine Kennzahl oder andere Kenngröße für die Ähnlichkeit ausgeben (z.B. von 0% bis 100%). In diesen Beispielen ist das Maschinen-Lern-Modul 62 ein Regressor. In jedem Fall kann anhand der Ausgabe des Maschinen-Lern-Moduls 62 erkannt werden, ob ein Datensatz für eine Closed-Loop-Testplattform ein zu testendes System adäquat testet (d.h. in einer ähnlichen Weise wie die mindestens eine Referenz-Testplattform). Wie vorstehend beschrieben, wird sowohl für die Abschnitte der Eingangsdaten als auch für die Abschnitte der Ausgangsdaten Ähnlichkeiten bestimmt werden. Diese Ermittlungen können in manchen Beispielen in einer der folgenden Weisen durchgeführt werden.
In manchen Beispielen kann die Bestimmung der Ähnlichkeiten der Abschnitte der Eingangsdaten Bestimmen eines Abstandes eines ersten Abschnitts der Eingangsdaten eines ersten Datensatzes des jeweiligen Paares mit den Eingangsdaten eines zweiten Abschnitts des zweiten Datensatzes des Paares umfassen. In anderen Worten wird mittels einer geeigneten Abstandsmetrik ein Abstand zwischen dem ersten Abschnitt der Eingangsdaten eines ersten Datensatzes des jeweiligen Paares und dem zweiten Abschnitt der Eingangsdaten des zweiten Datensatzes des Paares berechnet. Ein größerer Abstand bedeutet eine kleinere Ähnlichkeit (und umgekehrt). Die Abstandmetrik kann basierend auf dem Typ der verglichenen Eingangsdaten gewählt sein. Beispielhafte Abstandsmetriken umfassen einen euklidischen Abstand, einen Manhattan-Abstand oder einen Abstand einer höheren Vektornorm (für ein- oder mehrdimensionale Abschnitte von Eingangsdaten, die einen euklidischen Raum aufspannen). Andere Beispiele für Abstandsmetriken sind ein Hamming-Abstand oder eine Levenshtein Distanz (z.B. für Zeichenketten). In anderen Beispielen kann die Abstandsmetrik eine Abstandmetrik für Verteilungen umfassen (z.B. Abstandsmetriken für Wahrscheinlichkeitsverteilungen, bspw. eine earth mover's distance, EMD, oder ein Wassert- stein-Abstand - z.B. für Punktwolken, die von einem Radar oder LIDAR detektiert werden).
In manchen Beispielen können die Abschnitte der Eingangsdaten direkt mit dem geeigneten Abstandsmaß verglichen werden. In anderen Beispielen können die Abschnitte einen oder mehrere Vorverarbeitungsstufen durchlaufen. Zum Beispiel kann das Bestimmen der Ähnlichkeiten Komprimieren der einzelnen Abschnitte und Vergleichen der komprimierten Abschnitte von Eingangsdaten umfassen. In manchen Beispielen kann das Komprimieren der einzelnen Abschnitte das Erzeugen eines für den jeweiligen Abschnitt charakteristischen Datums mit geringer Dimensionalität als der ursprüngliche Abschnitt umfassen. Zusätzlich oder alternativ kann das Komprimieren der einzelnen Abschnitte eine Durchführung eines oder mehrerer Verfahren zur Dimensionalitätsreduktion der einzelnen Abschnitte umfassen (z.B. Auswahl von den ein oder mehr wichtigsten Hauptkomponenten in einer Hauptkomponentenanalyse, weglassen von Least Significant Bits usw.). In manchen Beispielen kann ein Abschnitt eines skalaren oder vektoriellen Zeitschriebs durch ein einzelnes skalares oder vektorielles Datum repräsentiert werden (d.h., die Zeitdimension fällt weg). Zusätzlich oder alternativ kann ein vektorielles Datum durch ein vektorielles Datum niedrigerer Dimension oder ein skalares Datum repräsentiert werden (ein Vektor hat in der vorliegenden Offenbarung mindestens zwei Einträge). Eine Kompression und/oder Dimensionalitätsreduktion kann hilfreich sein, da gerade Eingangsdaten in vielen Closed-Loop-Testplattformen hochdimensional sein können.
Zusätzlich oder alternativ können die Abschnitte der Eingangsdaten normiert oder in anderer Weise vereinheitlich werden. In dieser Weise können Abschnitte von Eingangsdaten mit verschiedenen Formaten (z.B. Länge oder Dimensionali- tät) und/oder unterschiedlichen Wertebereichen verglichen werden. Die oben beschriebenen Verfahren zur Kompression und/oder Dimensionalitätsreduktion können ebenfalls in manchen Beispielen verwendet werden, um die die Abschnitte der Eingangsdaten zu vereinheitlichen. Z.B. können (verschieden lange oder dimensionale) Abschnitte jeweils durch ein Skalar repräsentiert werden. Diese Techniken können die Vergleichbarkeit von Abschnitten von Eingangsdaten verschiedener Closed-Loop-Testplattformen verbessert werden.
In den vorhergehenden Abschnitten wurden Verarbeitungsaspekte (insbesondere bezüglich der Bestimmung der Ähnlichkeiten) hauptsächlich für die Abschnitte der Eingangsdaten beschrieben. Die Techniken können jedoch ebenfalls oder alternativ für die Abschnitte der Ausgangsdaten angewandt werden. Zum Beispiel kann die Bestimmung der Ähnlichkeiten der Abschnitte der Ausgangsdaten Bestimmen eines Abstandes eines ersten Abschnitts der Ausgangsdaten eines ersten Datensatzes des jeweiligen Paares von einem zweiten Abschnitt des zweiten Datensatzes des Paares umfassen. In anderen Worten wird mittels einer geeigneten Abstandsmetrik ein Abstand zwischen dem ersten Abschnitt der Ausgangsdaten eines ersten Datensatzes des jeweiligen Paares und dem zweiten Abschnitt der Eingangsdaten des zweiten Datensatzes des Paares berechnet. Ein größerer Abstand bedeutet eine kleinere Ähnlichkeit (und umgekehrt). Die weiteren oben beschriebenen Techniken können für die Ausgangsdaten ebenfalls eingesetzt werden. Die Closed-Loop-Testplattformen, deren Daten zum Trainieren des Maschinen- Lern-Moduls 62 verwendet werden, verschiedene Formen annehmen. Fig. 4 zeigt schematisch eine Closed-Loop-Testplattform 75.
Wie bereits beschrieben, kann die Closed-Loop-Testplattform 75 ein zu testendes System 71 und eine Umgebung 70 des zu testenden Systems umfassen. Die Umgebung 70 führt dem zu testenden System 71 Eingangsdaten 73 zu. Die Eingangsdaten 73 können simulativ erzeugt werden oder in anderer Weise synthetisiert werden (z.B. die Umgebung 70 wird durch eine Simulation nachgebildet). In anderen Beispielen können die Eingangsdaten 73 reale Daten aus der Umgebung des zu testenden Systems 71 sein (z.B. in einem Teststand oder während des Betriebs des zu testenden Systems 71 im Feld - in diesen Beispielen kann die Umgebung 70 zumindest teilweise die reale Umgebung des Systems oder eine Nachbildung derer durch Hardware umfassen). In wieder anderen Beispielen können Eingangsdaten 73 reale Daten umfassen, die mittels einer oder mehrerer Bearbeitungsschritte verändert sind (z.B. Fehlerinjektion auf Basis realer Fehlerbilder). Ausgangsdaten 74 des zu testenden Systems 71 können wiederum in die Umgebung 70 zurückgeführt werden (und dort neue Eingangsdaten 73 erzeugen), usw.
In manchen Beispielen kann eine Closed-Loop-Testplattform 75 eine Software- in-the-Loop-Testplattform sein. In diesem Fall ist das zu testende System 71 eine Software (d.h. das System wird durch eine Software gebildet). Die Software kann dabei in der Anwendung Teil eines übergeordneten Systems sein (z.B. einer Komponente, die die Software enthält und in der die Software eine vorbestimmte Funktion ausführt). In einer Software-in-the-Loop-Testplattform werden die Eingangsdaten 73 und die Ausgangsdaten 74 über eine Software-Schnittstelle zugeführt bzw. abgegriffen. Die Software wird während eines Testlaufs oder im Dauerlauf ausgeführt (auf einer geeigneten Recheneinheit), um den Betrieb in der Anwendung nachzustellen. Die Umgebung 71 kann simulativ nachgestellt werden und/oder durch reale Systeme.
In manchen Beispielen kann eine Closed-Loop-Testplattform 75 eine Model-in- the- Loop -Testplattform sein. In diesem Fall ist das zu testende System 71 ein Modell eines weiteren Systems sein (z.B. ein Modell eines Systems, das letztendlich in die einer Anwendung zum Einsatz kommen soll). In diesen Beispielen kann das technische System wiederum eine Software sein (d.h. eine Software, die das weitere System modelliert). In diesen Model-in-the-Loop-Testplattformen werden die Eingangsdaten 73 und die Ausgangsdaten 74 über eine Software- Schnittstelle zugeführt bzw. abgegriffen (wobei die Eingangsdaten an das jeweilige Modell angepasst sein). Das Modell wird während eines Testlaufs oder im Dauerlauf ausgeführt (auf einer geeigneten Recheneinheit), um den Betrieb in der Anwendung nachzustellen. Die Umgebung 71 kann simulativ nachgestellt werden und/oder durch reale Systeme.
In wieder anderen Beispielen kann eine Closed-Loop-Testplattform 75 eine Hard- ware-in-the-Loop-Plattform sein. In diesem Fall ist das zu testende System 71 eine Hardware- Komponente (die ihrerseits auch Software enthalten kann). Beispielsweise kann das zu testende System eine für eine Anwendung bestimmte Hardware-Komponente sein. In einer Hardware-in-the-Loop-Testplattform können die Eingangsdaten 73 und die Ausgangsdaten 74 über existierende Schnittstellen der Hardware- Komponente zugeführt/ abgefragt werden. Die Umgebung 71 kann simulativ nachgestellt werden und/oder durch reale Systeme.
In wieder anderen Beispielen kann eine Closed-Loop-Testplattform 75 das zu testende System 71 im Feld oder auf einem Teststand umfassen. In diesem Fall ist kann das zu testende System 71 eine Hardware- Komponente (die ihrerseits auch Software enthalten kann) oder eine Software- Komponente sein. Beispielsweise kann das zu testende System eine für eine Anwendung bestimmte Hardware-Komponente oder Software- Komponente sein. Wiederum können die Eingangsdaten 73 und die Ausgangsdaten 74 über existierende Schnittstellen der Hardware-Komponente oder Software-Schnittstellen zugeführt / abgefragt fragen. Die Umgebung 71 ist in diesen Beispielen eine reale Umgebung des Systems im Feld oder auf einem Teststand.
Wie oben beschrieben wird das Maschinen-Lern-Modul 62 mittels einer Mehrzahl von Datensätzen trainiert, die jeweils mit unterschiedlichen Closed-Loop-Test- plattformen 75 erzeugt sind. Dabei können die vorstehend beschriebenen Closed-Loop-Testplattformen in beliebiger Weise kombiniert werden. Insbesondere kann jeder Typ der vorstehend beschriebenen Closed-Loop-Testplattformen 75 eine Referenz-Testplattform sein.
In manchen Beispielen kann die mindestens eine Referenz-Testplattform eine Closed-Loop-Testplattform 75 eines ersten Typs enthalten und die andere(n) Closed-Loop-Testplattform(en) eine Closed-Loop-Testplattform 75 eines zweiten Typs enthalten.
Zusätzlich oder alternativ kann die mindestens eine Referenz-Testplattform eine Closed-Loop-Testplattform 75 umfassen, die das zu testende System 71 im Feld oder auf einem Teststand umfasst. In anderen Worten kann die Referenz-Testplattform das reale zu testende System enthalten. Das kann eine Qualität der Datensätze der Referenz-Testplattform sicherstellen (da z.B. Probleme durch simu- latives Nachbilden des Systems und/oder seiner Umgebung reduziert werden können). Alternativ oderzusätzlich kann die mindestens eine Referenz-Testplattform aber auch eine andere der oben genannten Closed-Loop-Testplattformen 75 umfassen (z.B. eine Closed-Loop-Testplattform, in der die Umgebung und/oder das zu testende System mit einem höheren Aufwand simulative nachgestellt werden als in anderen zu validierenden oder zu verifizierenden Closed- Loop -Testplattform en und/oder eine Closed-Loop-Testplattform, deren Verhalten bereits validiert oder verifiziert wurde).
Wie weiter oben erklärt, können die Techniken der vorliegenden Offenbarung für jedwede Systeme, die in Closed-Loop-Testplattformen getestet werden, eingesetzt werden. In manchen Beispielen ist das zu testende System ein Fahrzeug oder ein Modul für ein Fahrzeug (z.B. für ein Kraftfahrzeug). Das System kann dabei zum Einbau in das Fahrzeug selbst konfiguriert sein und/oder zur Kommunikation mit dem Fahrzeug (z.B. in einem Backend oder einer Infrastruktur-Komponente, das/die eine Funktionalität für das Fahrzeug zur Verfügung stellt. In manchen Beispielen kann das System eine Funktionalität für das assistierte oder autonome Fahren eines Fahrzeugs bereitstellen.
Im Zusammenhang mit Fig. 1 bis Fig. 4 wurden im Wesentliche Aspekte des Trainierens eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems beschrieben. In den folgenden Abschnitten werden Anwendungen einer trainierten Maschinen-Lern-Mo- duls zum Validieren oder Verifizieren einer Closed- Loop-Testplattform zum Testen eines Systems genauer diskutiert.
Fig. 5 zeigt ein Flussdiagramm eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zum Testen eines Systems gemäß der vorliegenden Offenbarung. Fig. 6 illustriert schematisch ein beispielhaftes Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplattform 81 der vorliegenden Offenbarung.
Das Verfahren umfasst Empfangen 501 eines Datensatzes 61 a, 61 b einer Closed-Loop-Testplattform 81 zum Testen eines Systems. Ziel des Verfahrens ist eine Validierung oder Verifizierung des Datensatzes 61 a, 61 b bzw. der Closed- Loop -Testplattform 81 , mit der der Datensatz 61 a, 61 b erzeugt wurde. Der Datensatz 61 a, 61 b kann ebenso aufgebaut sein, wie die oben in Bezug auf das Training des Maschinen-Lern-Moduls beschriebenen Datensätze (z.B. der Datensatz enthält Eingangsdaten und zugehörige Ausgangsdaten wir oben erläutert). In manchen Beispielen kann der Datensatz nur Eingangsdaten oder nur Ausgangsdaten umfassen (z.B. nur ausgewählte Eingangsdaten oder Ausgangsdaten).
Wie weiter oben erklärt, können die Techniken der vorliegenden Offenbarung für jedwede Systeme, die in Closed-Loop-Testplattformen getestet werden, eingesetzt werden. In manchen Beispielen ist das zu testende System ein Fahrzeug oder ein Modul für ein Fahrzeug (z.B. für ein Kraftfahrzeug). Das System kann dabei zum Einbau in das Fahrzeug selbst konfiguriert sein und/oder zur Kommunikation mit dem Fahrzeug (z.B. in einem Backend oder einer Infrastruktur-Komponente, das/die eine Funktionalität für das Fahrzeug zur Verfügung stellt. In manchen Beispielen kann das System eine Funktionalität für das assistierte oder autonome Fahren eines Fahrzeugs bereitstellen.
Das Verfahren umfasst weiterhin Einspeisen 502 zumindest eines Teils des Datensatzes 61 a, 61 b der Closed-Loop-Testplattform 81 in ein Maschinen-Lern-Mo- dul 83 zum Validieren oder Verifizieren einer Closed-Loop-Testplattform. Zum Beispiel kann der Teil des Testdatensatzes 61 a, 61 b Eingangsdaten und/oder Ausgangsdaten umfassen, die Informationen enthalten, die ein mit der Closed- Loop -Testplattform 81 erfasstes oder simuliertes Betriebsszenario eines in der Closed-Loop-Testplattform 81 enthaltenen Systems oder eine mit der Closed- Loop -Testplattform en 81 erfasste oder simulierte Betriebssituation eines in der Closed-Loop-Testplattform 81 enthaltenen Systems charakterisieren. Zum Beispiel kann der Teil der Eingangsdaten ein Betriebsszenario oder eine Betriebssituation charakterisieren (z.B. ein Zeitschrieb während des Betriebsszenarios oder der Betriebssituation). Das Maschinen-Lern-Modul 83 ist auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen mindestens einer Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop- Testplattform unter Verwendung der bestimmten Ähnlichkeiten trainiert.
Das Verfahren umfasst zudem Ausgeben 503 einer oder mehrerer Schätzungen 40a, 40b der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes 61 a, 61 b der Closed-Loop-Testplattform zum Testen eines Systems 81 (d.h. der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform) und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen- Lern-Modul 83. In manchen Beispielen kann eine erste Ähnlichkeit für die Eingangsdaten und eine zweite Ähnlichkeit für die Ausgangsdaten ausgeben werden. Die Schätzungen 40a, 40b können, wie oben beschrieben, verschiedene Formen annehmen. Zum Beispiel kann eine binäre Information ausgegeben werden, ob die Eingangsdaten und die Ausgangdaten den zum Training verwendeten Datensätzen ähnlich sind, oder nicht. Alternativ (oder zusätzlich) kann eine Kennzahl oder andere Kenngröße für die Ähnlichkeit ausgeben werden.
In manchen Beispielen ist die Closed-Loop-Testplattform 81 zum Testen eines Systems eine Closed-Loop-Simulationsplattform, d.h., das Umfeld des zu testenden Systems, das zu testende System, oder beide werden mittels einer Simulation erzeugt. Zum Beispiel können Eingangsdaten, die in der Closed-Loop-Test- plattform dem zu testenden System zugeführt werden, mittels einer Simulation erzeugt werden (z.B. durch eine Simulation anderer Systeme, die das zu testende System mit Eingangsdaten versorgen, einem Umfeld des zu testenden Systems, oder beiden). Zusätzlich oder alternativ können die Ausgangsdaten des zu testenden Systems zumindest teilweise in die Simulation zurückgespeist werden.
In manchen Beispielen umfasst das Verfahren Ausgeben mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten des Datensatzes 61 , 61 b der Closed-Loop-Testplattform zum Testen eines Systems 81 (d.h. der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform) und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul 83. Die mehreren Schätzungen können Schätzungen der Ähnlichkeit für verschiedene Werte von Betriebsparameter des getesteten Systems und/oder verschiedenen Betriebsszenarien oder Betriebsituationen sein. Basierend auf diesen Informationen kann erkannt werden, ob eine zu validierende oder zu verifizierende Closed-Loop-Testplattform 81 bestimmte Bereiche adäquat testet (oder nicht).
Die Schätzungen der Ähnlichkeiten 40a, 40b können in jeder geeigneten Weise ausgegeben werden. In manchen Beispielen werden die einen oder mehreren Schätzungen der Ähnlichkeiten 40a, 40b Schätzungen in einer graphischen Benutzeroberfläche ausgegeben werden. In anderen Beispielen können die Schätzungen auch über andere Schnittstellen ausgegeben werden (in menschen- oder maschinelesbarer Form).
In Bezug auf Fig. 7 oder Fig. 8 werden nun weitere Aspekte der ausgebbaren Schätzungen der Ähnlichkeiten besprochen. Fig. 7 zeigt eine beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop-Test- plattform der vorliegenden Offenbarung. Fig. 8 zeigt eine weitere beispielhafte Ausgabe eines Verfahrens zum Validieren oder Verifizieren einer Closed-Loop- Testplattform der vorliegenden Offenbarung.
In manchen Beispielen können die Schätzungen für verschiedene Punkte oder Bereiche eines Parameterraums ermittelt und ausgegeben werden. Fig. 7 und Fig. 8 zeigen beispielhaft einen zweidimensionalen Parameterraum (mit einer ersten Achse 96, die einen ersten Parameter aufträgt und einer zweiten Achse 97, die einen zweiten Parameter aufträgt). In anderen Beispielen kann der Parameterraum mehr als zwei Dimensionen haben. In wieder anderen Beispielen können Schätzungen für zwei oder mehr Betriebsszenarien und/oder Betriebssituationen des Systems ausgegeben werden.
Anhand der Schätzungen der Ähnlichkeiten können nun Bereiche 90 in dem Parameterraum ausgemacht werden, in denen die zu validierende oder zu verifizierende Closed-Loop-Testplattform adäquate Ergebnisse liefert (z.B. Eingangsund Ausgangsdaten sind ähnlich zu den Eingangs- und Ausgangsdaten der Referenz-Testplattformen unter einem vorbestimmten Ähnlichkeitskriterium) und andere Bereiche 91 , in denen die zu validierende oder zu verifizierende Closed- Loop -Testplattform keine adäquaten Ergebnisse liefert (z.B. Eingangs- und Ausgangsdaten sind nicht ähnlich zu den Eingangs- und Ausgangsdaten der Referenz-Testplattformen unter einem vorbestimmten Ähnlichkeitskriterium). Die Beurteilung kann automatisch erfolgen und an einen Nutzer ausgegeben werden (z.B. über eine graphische Benutzeroberfläche). In anderen Beispielen kann statt einer binären Einstufung C, ähnlich“ oder „unähnlich“) eine probabilistische Einstufung erfolgen und/oder ein Wert für einen Ähnlichkeitsmetrik ausgeben werden.
Fig. 8 zeigt eine Ausgabe (z.B. über eine graphische Benutzeroberfläche), in der für eine Mehrzahl von Punkten eines Parameterraums Schätzungen der Ähnlichkeiten ausgeben werden. Für jeden Punkt kann jeweils eine (erste) Schätzung 94 der Ähnlichkeit der Eingangsdaten und eine (zweite) Schätzung 95 der Ähnlichkeit der Ausgangsdaten ausgegeben werden. Zusätzlich können Datenpunkte 92 oder Parameterbereiche kenntlich gemacht werden, für die Datensätze für Referenz-Testplattformen vorliegen.
Basierend auf der Ausgabe der Ähnlichkeiten können ein oder mehrere weitere Schritte vorgenommen werden (die in manchen Beispielen automatisiert ausgeführt werden können).
In manchen Beispielen können insbesondere Datensätze (z.B. für bestimmte Testläufe einer zu validierenden oder zu verifizierenden Closed-Loop-Testplatt- form), für die keine Daten einer Referenz-Testplattform (z.B. dem zu testenden System im Feld) vorliegen, auf Zuverlässigkeit geprüft werden. Das trainierte Ma- schinen-Lern-Modul kann in manchen Fällen auch für diese Datensätze eine belastbare Schätzung vornehmen, ob die Daten der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform ausreichende Ähnlichkeit zu den zu erwarteten Daten haben.
Zusätzlich oder alternativ kann in manchen Beispielen anhand der einen oder mehreren Schätzungen 40a, 40b eine Abdeckung eines Parameterraums durch die zu validierende oder zu verifizierende Closed-Loop-Testplattform und/oder die mindestens eine Referenz-Testplattform bestimmt werden. Zum Beispiel können Bereiche identifiziert werden, zu denen noch keine Daten der Referenz-Testplattform vorliegen. Für diese Bereiche können zusätzliche Daten angefordert und/oder erhoben werden. Zum Beispiel können für die zu validierende oder zu verifizierende Closed-Loop-Testplattform und/oder die mindestens eine Referenz-Testplattform Daten angefordert und/oder erhoben werden, in denen bestimmte Betriebssituationen oder Betriebsszenarien behandelt werden (z.B. wenn es zu Abschnitten in den Datensätzen der Referenz-Testplattform keine ähnlichen Abschnitte der zu validierenden oder zu verifizierenden Closed-Loop- Testplattform gibt, oder umgekehrt)
Zusätzlich oder alternativ können gezielte neue Datensätze für die zu validierende oder zu verifizierende Closed-Loop-Testplattform angefordert (und erzeugt) werden, um eine Ähnlichkeit mit den Datensätzen der Referenz-Testplattform zu erhöhen (z.B. durch Fuzzing der Eingangsdaten).
Wenn eine Closed-Loop-Testplattform mit den Techniken der vorliegenden Offenbarung validiert oder verifiziert wurden ist, kann das darin enthaltene zu testende System freigegeben und im Weiteren verwendet werden (z.B. in einem Produkt oder in einer nachgelagerten Stufe einen Entwicklungsprozesses). Die vorliegende Offenbarung umfasst auch Einsetzen des in der Closed-Loop-Test- plattform enthaltenen Systems.
In den vorhergehenden Abschnitten wurden die Techniken der vorliegenden Offenbarung meistens anhand der Verfahren der vorliegenden Offenbarung erläutert. Die Verfahren der vorliegenden Offenbarung können in manchen Beispielen automatisiert (z.B. Computer-implementiert) ausgeführt werden.
Die vorliegende Offenbarung betrifft auch eine Recheneinheit, die dazu ausgelegt ist, die Verfahren gemäß der vorliegenden Offenbarung auszuführen. Die Recheneinheit kann jede geeignete Form in Bezug auf ihre Hardware oder Software annehmen (z.B. eine Stand-Alone-Recheneinheit oder eine verteilte Recheneinheit, z.B. eine Recheneinheit in einer Cloud).
Die vorliegende Offenbarung betrifft auch ein Computer-Programm, das Instruktionen enthält, die, wenn sie auf einer Recheneinheit ausgeführt werden, die Recheneinheit dazu bringen, die Schritte der Verfahren der vorliegenden Offenbarung auszuführen.
Die vorliegende Offenbarung betrifft auch ein Computer-Programm-Produkt oder Signal, das die Computer-Programme der vorliegenden Offenbarung enthält.

Claims

Ansprüche
1. Verfahren zum Training eines Maschinen-Lern-Moduls zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zur Validierung oder Verifizierung eines Systems, umfassend:
Bereitstellen (101) von einer Mehrzahl von Datensätzen (20, 22) von zwei oder mehr Closed-Loop-Testplattformen, darunter mindestens eine Referenz - Testp I attfo rm , wobei jeder Datensatz (20, 22) Eingangsdaten und zugehörige Ausgangsdaten eines getesteten Systems in einer jeweiligen Closed-Loop-Test- plattform enthält;
Bestimmen (102) von Ähnlichkeiten (50) von Abschnitten der Eingangsdaten (31 -38) für Paare der Mehrzahl von Datensätzen (20, 22), wobei jedes Paar von Datensätzen einen Datensatz einer der mindestens einen Referenz-Testplattformen enthält;
Bestimmen (103) von Ähnlichkeiten (50) von Abschnitten der Ausgangsdaten, die den Abschnitten von Eingangsdaten (31 -38) zugehörig sind; und
Trainieren (104) eines Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und der Datensätze der Mehrzahl von Datensätzen der mindestens einen Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform unter Verwendung der bestimmten Ähnlichkeiten (50), um ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform zu erzeugen.
2. Verfahren gemäß Anspruch 1 , wobei das Maschinen-Lern-Modul nur einen Teil der Ausgangsdaten und/oder Eingangsdaten als Eingangsgröße erhält und die Schätzung der Ähnlichkeit der der Eingangsdaten und Ausgangsdaten als Ausgangsgröße erzeugt Verfahren gemäß Anspruch 2, wobei der Teil der Eingangsdaten und/oder Ausgangsdaten Informationen umfasst, die ein mit der jeweiligen Closed- Loop -Testplattform erfasstes oder simuliertes Betriebsszenario oder eine mit der jeweiligen Closed-Loop-Testplattform erfasste oder simulierte Betriebssituation eines in der Closed-Loop-Testplattform enthaltenen Systems charakterisieren. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 3, wobei die Abschnitte der Ausgangsdaten und/oder Eingangsdaten (31 -38) Abschnitte aus Zeitschrieben umfassen. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 4, wobei die Abschnitte der Ausgangsdaten und/oder Eingangsdaten (31 -38) ausgewählt sind, um Daten zu einer oder mehrere vorbestimmter Betriebssituationen oder einem oder mehreren vorbestimmten Betriebsszenarios des zu testenden Systems in der jeweiligen Closed-Loop-Testplattform zu enthalten. Verfahren gemäß Anspruch 5, wobei die vorbestimmten Betriebssituationen oder Betriebsszenarios kritische Betriebssituationen oder Betriebsszenarios des Systems sind, optional wobei die kritischen Betriebssituationen oder Betriebsszenarios die Verletzung eines vorbestimmten Sicherheitsziels umfassen. Verfahren gemäß einem der Ansprüche 1 bis 6, wobei das Bestimmen der Ähnlichkeiten von Abschnitten der Eingangsdaten Bestimmen eines Abstandes eines ersten Abschnitts (31 ; 32; 33; 38) der Eingangsdaten eines ersten Datensatzes (20) des jeweiligen Paares und eines zweiten Abschnitts (34; 35; 36; 37) der Eingangsdaten des zweiten Datensatzes (22) des Paares umfasst. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 7, wobei das Bestimmen der Ähnlichkeiten von Abschnitten der Eingangsdaten (31 -38) Komprimieren der einzelnen Abschnitte und Vergleichen der komprimierten Abschnitte von Eingangsdaten umfasst. Verfahren gemäß Anspruch 8, wobei Komprimieren der einzelnen Abschnitte eine Erzeugung eines für den jeweiligen Abschnitt (31 -38) charakteristischen Datums mit geringer Dimensionalität als der ursprüngliche Abschnitt umfasst. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 9, wobei das System ein Fahrzeug oder ein Modul zum Einsatz in einem Fahrzeug umfasst. Verfahren gemäß einem der vorangehenden Ansprüche 1 bis 10, wobei die mindestens eine Referenz-Testplattform mindestens eine Testplattform, die das System im Feld oder auf einem Teststand umfasst, umfasst. Verfahren zum Validieren oder Verifizieren einer Closed-Loop-Testplatt- form zum Testen eines Systems, umfassend:
Bereitstellen (501) eines Datensatzes einer Closed-Loop-Testplattform zum Testen eines Systems;
Einspeisen (502) zumindest eines Teils des Datensatzes der Closed- Loop -Testplattform in ein Maschinen-Lern-Modul zum Validieren oder Verifizieren einer Closed-Loop-Testplattform, wobei das Maschinen-Lern-Moduls auf eine Schätzung der Ähnlichkeit von Eingangsdaten und Ausgangsdaten eines Datensatzes einer zu validierenden oder zu verifizierenden Closed-Loop-Testplattform und Datensätzen mindestens einer Referenz-Testplattform als Funktion von Eingangsdaten und/oder Ausgangsdaten des Datensatzes der zu validierenden oder zu verifizierenden Closed-Loop-Testplattform trainiert ist; und Ausgeben (503) einer oder mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten des Datensatzes der Closed-Loop- Testplattform zum Testen eines Systems und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul. Verfahren gemäß Anspruch 12, wobei die Closed-Loop-Testplattform zum Testen eines Systems eine Closed-Loop-Testplattform ist, die das zu testende System, die Umgebung des zu testenden Systems, oder beide, simuliert, ist/sind. Verfahren gemäß Anspruch 12 oder Anspruch 13, weiter umfassend: Ausgeben mehrerer Schätzungen der Ähnlichkeit von Eingangsdaten und Ausgangsdaten des Datensatzes der Closed-Loop-Testplattform zum Testen eines Systems und den Datensätzen der mindestens einer Referenz-Testplattform mit dem Maschinen-Lern-Modul, wobei die mehreren Schätzungen Schätzungen der Ähnlichkeit für verschiedene Werte von Betriebsparameter des getesteten Systems und/oder verschiedenen Betriebsszenarien sind. Recheneinheit, das dazu ausgelegt ist, die Verfahren gemäß einem der Ansprüche 1 bis 14 auszuführen. Computer-Programm, das Instruktionen enthält, die, wenn sie auf einer Recheneinheit ausgeführt werden, die Recheneinheit die Verfahren gemäß einem der Ansprüche 1 bis 14 ausführen lassen. Computer-Programm-Produkt oder Signal, das das Computer-Programm gemäß Anspruch 16 enthält.
PCT/EP2023/069333 2022-07-25 2023-07-12 Techniken zum validieren oder verifizieren von closed-loop-testplattformen WO2024022819A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022207563.3 2022-07-25
DE102022207563.3A DE102022207563A1 (de) 2022-07-25 2022-07-25 Techniken zum validieren oder verifizieren von closed-loop-testplattformen

Publications (1)

Publication Number Publication Date
WO2024022819A1 true WO2024022819A1 (de) 2024-02-01

Family

ID=87312241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/069333 WO2024022819A1 (de) 2022-07-25 2023-07-12 Techniken zum validieren oder verifizieren von closed-loop-testplattformen

Country Status (2)

Country Link
DE (1) DE102022207563A1 (de)
WO (1) WO2024022819A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021100149A1 (de) * 2020-08-05 2022-02-10 Dspace Digital Signal Processing And Control Engineering Gmbh Computerimplementiertes Verfahren zum Bereitstellen eines Test-Verlaufs zu testender Verkehrsszenarien
WO2022042822A1 (en) * 2020-08-24 2022-03-03 Siemens Industry Software Netherlands B.V. Validating a software-driven system based on real-world scenarios

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021100149A1 (de) * 2020-08-05 2022-02-10 Dspace Digital Signal Processing And Control Engineering Gmbh Computerimplementiertes Verfahren zum Bereitstellen eines Test-Verlaufs zu testender Verkehrsszenarien
WO2022042822A1 (en) * 2020-08-24 2022-03-03 Siemens Industry Software Netherlands B.V. Validating a software-driven system based on real-world scenarios

Also Published As

Publication number Publication date
DE102022207563A1 (de) 2024-01-25

Similar Documents

Publication Publication Date Title
WO2009037042A2 (de) Verfahren und vorrichtung zur ermittlung einer eintrittswahrscheinlichkeit
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
WO2022028935A1 (de) Computerimplementiertes verfahren zum bereitstellen eines test-verlaufs zu testender verkehrsszenarien
DE102021210107A1 (de) Computerimplementierte Verfahren, Module und System zur Anomalieerkennung in industriellen Fertigungsprozessen
WO2024022819A1 (de) Techniken zum validieren oder verifizieren von closed-loop-testplattformen
EP3451101B1 (de) Verfahren zum bestimmen einer fehlerursache eines fehlers in einer fahrzeugkomponente
DE102021109126A1 (de) Verfahren zum Testen eines Produkts
DE102021109129A1 (de) Verfahren zum Testen eines Produkts
EP3979009A1 (de) Erzeugen eines vereinfachten modells für xil-systeme
EP3757698A1 (de) Verfahren und vorrichtung zur bewertung und auswahl von signal-vergleichsmetriken
DE102019219067A1 (de) Verfahren zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102021109127A1 (de) Verfahren zum Testen eines Produkts
DE102021111724B4 (de) Verfahren und Computerprogramm zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
DE102017213764A1 (de) Vorrichtung zur Zuverlässigkeitsanalyse eines mechatronischen Systems
EP3764185A1 (de) Verfahren zum testen eines systems
EP4300360A1 (de) Verfahren zur diebstahlerkennung von maschinenlernmodulen sowie diebstahlmeldesystem
DE102008060970A1 (de) Vorrichtung zum Erzeugen eines markierten Referenzdatenstroms
DE102021109131A1 (de) Verfahren zum Testen eines Produkts
DE102020205527A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102020215387A1 (de) Verfahren zum Optimieren eines Testsatzes zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102021202335A1 (de) Verfahren und Vorrichtung zum Prüfen eines technischen Systems
DE102021102460A1 (de) Verfahren zur Durchführung einer Simulation
DE102023102523A1 (de) Verfahren zum effizienten szenariobasierten Testen eines automatisierten Fahrsystems
DE102021109128A1 (de) Verfahren zum Testen eines Produkts

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23741688

Country of ref document: EP

Kind code of ref document: A1