WO2023117240A1 - Computer-implementierte testumgebung sowie verfahren zum testen von software-komponenten - Google Patents

Computer-implementierte testumgebung sowie verfahren zum testen von software-komponenten Download PDF

Info

Publication number
WO2023117240A1
WO2023117240A1 PCT/EP2022/082593 EP2022082593W WO2023117240A1 WO 2023117240 A1 WO2023117240 A1 WO 2023117240A1 EP 2022082593 W EP2022082593 W EP 2022082593W WO 2023117240 A1 WO2023117240 A1 WO 2023117240A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
test system
time
program step
software
Prior art date
Application number
PCT/EP2022/082593
Other languages
English (en)
French (fr)
Inventor
Fabian FRANZELIN
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 WO2023117240A1 publication Critical patent/WO2023117240A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Definitions

  • the invention relates to a computer-implemented test environment and a method for testing software components that are intended for execution on a specified target system.
  • Each software component comprises a sequence of several schedulable program steps, so-called runnables. This can be a function, a thread or a process.
  • the time from the triggering of a program step to the complete processing of the program step is defined as the response time of the executing system - target system or test system - for this program step.
  • Testing is done using a test system on which the software components to be tested are run with test input data, also known as recompute.
  • a time model is used during testing that describes a system state-dependent relationship between the time behavior of software components when running on the target system and the time behavior of these software components when running on the test system.
  • AD automated driving
  • the time behavior of the individual software components when executed on the target system plays an important role.
  • the software components must be tested with a large number of test data sets in order to depict a wide variety of test scenarios.
  • the target system is often not available in the test phase because it is extremely complex and specific to the respective application designed and/or because its use in the test phase is not economical. For this reason, simulations or analytical performance models of the target system, which run on common hardware systems, are often used in practice to evaluate the time behavior of software components on such target systems.
  • timing of a software component on a system - test system or target system - is intertwined with the functional and non-functional properties of that system. It depends on a large number of influencing factors, such as the function code of the software component itself, the compiler, the libraries used, the hardware architecture and the distribution of the individual program steps over the available hardware resources. These influencing variables are not independent of one another; rather, the timing of the individual program steps or functional steps and thus the time behavior of the software component as a whole changes as a function of all these aspects.
  • test software component to be tested is run exclusively on the test system. Performance parameters of the test system are recorded. Based on these performance parameters of the test system, the previously trained model then estimates the performance of the software component on the target system. With this procedure, only quantitative statements can be made about the overall performance of the tested software component on the target system. A qualified statement about how the individual program steps have affected the overall performance is not possible here and accordingly no cause analysis.
  • the invention proposes measures by which the time behavior of software components to be tested can be realistically and credibly simulated on a target system during execution on a test system, specifically reproducibly for each individual chronologically plannable program step of the software component to be tested .
  • this is achieved with the aid of a sequence planning component which is designed to schedule the individual program steps during the execution of a software component to be tested on the test system.
  • the scheduling component estimates the response times of the target system for the individual program steps, taking into account the current status of the test system using the time model. Based on this estimate, the scheduling component then specifies a response time for the test system that corresponds to the time behavior of the target system in a comparable state.
  • test system transmits a response time query to the scheduling component for the current program step.
  • the time model of the scheduling component then generates an estimate for the response time of the current program step on the target system, taking into account the current state of the test system.
  • the Flow planning component the response time request of the test system with a specification for the response time, which is selected so that the test system simulates the time behavior of the target system in a comparable state when executing the current program step in the context of the software component to be tested.
  • the measures according to the invention enable a discrete event simulation that is driven both by the execution of the software component to be tested and by the process planning component or its time model. Both are kept synchronous so that the response times provided by the time model for the current program step are always calculated on the basis of the current consistent state of the test system.
  • the response times specified in this way are for the same input, i.e. State of the test system and program step, and reproducible with the same design of the target system, so that the test system together with the flow planning component of the invention simulates the timing of software components to be tested on the target system in a realistic and credible manner.
  • the measures according to the invention thus enable qualified statements as to how the individual program steps affect the overall performance of a software component on the target system. This information is of great use for software development.
  • the measures according to the invention enable a realistic assessment of the overall performance of a tested software component on the target system, and not just an estimate as described in the prior art.
  • This assessment can simply be based on the output data that was generated when the software component to be tested was run on the test system as a function of the test input data. These output data are referred to below as test output data.
  • test output data can be compared, for example, with the output data that an earlier version of the tested software component generated for the same test input data.
  • the response times of the test system for the individual program steps of the software components to be tested can in principle be specified in different ways.
  • trigger events for the program steps of the software component to be tested are generated in an embodiment of the invention. This can be both trigger events that start a program step and trigger events that end a program step. Such trigger events are preferably generated by the scheduling component of the computer-implemented test environment according to the invention.
  • the time model used within the scope of the invention describes a connection between the time behavior of software components when running on the target system and the time behavior of these software components when running on the test system when the two systems - target system and test system - are in are in a comparable condition.
  • the time model requires information about the state of the test system when executing a software component in order to make statements about the time behavior of the target system in a comparable state when executing this software component. Therefore, within the framework of the invention, test system parameters are recorded that more or less extensively describe the state of the test system.
  • the computer-implemented test environment according to the invention includes appropriate hardware or software-implemented detection means. This means that one or more of the following test system parameters are preferably recorded during the execution of a software component to be tested:
  • the time model includes at least one pre-trained regression model, in particular a neural network. The training of such a learning-based time model is explained below by way of example in connection with FIG. 2 .
  • the time model could also include at least one simulation component that takes into account the specified system parameters of the target system, in particular parameters of the hardware architecture, the operating system, the scheduler used, the software distribution on a given hardware architecture (deployment model) and Priority models of program steps.
  • the target system here is usually an embedded application-specific hardware open-loop system (HoL), while a software open-loop system (SoL) based on a common hardware system can advantageously be used as a test system.
  • HoL embedded application-specific hardware open-loop system
  • SoL software open-loop system
  • FIG. 1 illustrates the interaction of the individual components of a test environment 100 according to the invention using a first block diagram.
  • FIG. 1 is a “quasi-static” representation of the components of a test environment 100 according to the invention for testing software components that are intended for execution on a specified target system.
  • the target system could be located in an AD project, for example.
  • the target system is not part of the test environment 100.
  • information 30 about the software components and the specification of the hardware of the target system is available to the test environment 100, such as information about the system design 31 and the software compilation and distribution 32 (build & Deploy) on the target system.
  • the software components to be tested were developed for the target system. Each software component comprises a sequence of several plannable program steps.
  • the software components are executed with test input data in the test environment 100 for test purposes.
  • the software components and the test input data are in the form of source files 33 .
  • the time behavior of the software components to be tested is simulated during execution on the target system.
  • test system 10 An essential part of the test environment 100 is a test system 10, which can differ significantly from the target system both in terms of its hardware and its software. The only technical requirement that the test system 10 must meet is that the software components to be tested can be executed on the test system 10 . As a rule, the test system 10 is a software implementation on a common hardware system that is also used for consumer applications, for example.
  • the test environment 100 includes a scheduling component 20 that uses a time model 21 for predicting the time behavior of software components when running on the target system.
  • This time model 21 describes a connection between the time behavior of software components when running on the target system and the time behavior of these software components when running on the test system 10, provided that the target system and test system are in one are in a comparable condition.
  • the time model 21 can use, for example, machine learning models or also stochastic approaches from uncertainty assessment or error analysis (uncertainty quantification), such as polynomial chaos expansion.
  • the time model 21 also uses the available target system information 30 about the system design 31 and software compilation and distribution 32 for its predictions, which is indicated by the arrows 2 and 4.
  • the arrows 2 and 3 illustrate that the target system information 30 is also used on the system level 11 of the test system 10, for example to adjust system parameters, as far as this is possible.
  • the arrows 1 and 3 illustrate that the source files 33 of the software components to be tested and test input data are made available to the test system 10 .
  • the execution of a software component to be tested with a specific set of test input data, in which a corresponding set of test output data is generated, is also referred to as recompute.
  • the software components are executed on a replay unit 12 of the test system 10, which communicates with the system level 11 for this purpose, which is indicated by arrows 5.
  • the test system 10 includes a recording unit 13 with hardware and/or software-implemented detection means for test system parameters that describe the state of the test system 10 when the individual program steps of the software components to be tested are executed.
  • the time model 21 interprets the test system parameters as information about the current state of the test system 10 and thus generates an estimate for the response time of the current program step on the target system in a comparable system state.
  • the flow planning component 20 answers the response time query of the test system 10 - indicated by arrow 7 - with a specification for the response time of the test system 10, so that the test system 10 when executing the current program step in the context of the software component to be tested the timing of the Target system replicated.
  • a trace generator 22 of the scheduling component 20 triggers events at suitable points in time, by which a program step is triggered or terminated.
  • the information about the initiation and termination of the individual program steps is also referred to as trace data and can be displayed in the form of a Gantt chart.
  • the software components to be tested during execution on the test system 10, ie the recomputes, are the users or consumers of the trace data by the individual program steps, ie the runnables, corresponding to those generated by the flow planning component Schedule trace data. This ensures that a recompute is reproducible using the same trace data and also provides reproducible test output data.
  • the scheduling component 20 takes over the entire scheduling of the software components to be tested, parallel to the execution of the software component on the test system 10. For this purpose, the scheduling component 20 estimates with the help of the time model 21 and taking into account the current status of the test system 10 the response times of the target system for the individual program steps. This estimate is the basis for specifying a response time for the test system 10 that corresponds to the time behavior of the target system in a comparable system state. Because of the differences between the target system and the test system 10, the response time specified for the test system 10 will generally not be identical to the estimated response time of the target system.
  • test system response times of all program steps of a software component are selected in such a way that they simulate the time behavior of the software component as a whole on the target system, but, for example, all test system response times are slower or faster by a factor than the estimated response times of the target system .
  • FIG. 2 refers to a test environment 200 according to the invention with a SoL test system 210 and with a scheduling component that uses a time model with a regression model 220 to estimate the response times of a HoL target system 230 for individual program steps.
  • the right half of FIG. 2 relates exclusively to the training of such a time model 220, the left half also represents its use within the scope of the method according to the invention.
  • the regression model 220 for example a neural network, is intended to determine the connection between the time behavior of software components when running on a HoL target system 230 and the time behavior of these software components when running on the SoL test system 210 using training software learn to estimate the timing of these software components on the HoL target system 230 after completion of the training phase using test system parameters that are recorded when running software components on the SoL test system 210 .
  • a first step representative training software components are selected.
  • the corresponding source code 40 is compiled on the one hand for the HoL target system 230 and on the other hand for the SoL test system 210, with the program code 41 executable on the HoL target system 230 and the program code 42 executable on the SoL test system 210 being created.
  • these two program codes 41 and 42 are then executed with the same training input data on the respective system—HoL target system 230 or SoL test system 210.
  • Both the HoL target system 230 and the SoL test system 210 record parameters that describe the state of the respective system, e.g.
  • test input data input data complexity, number of messages on the input ports, message payload analysis metrics.
  • Appropriate hardware and/or software-implemented detection means measure when a runnable is triggered, when its execution is deferred, when processor resources are allocated to it again, until its execution is finally terminated.
  • Non-functional performance model counters can also be logged along with an analysis of functional input data from runnables.
  • the regression model 220 is able, based on information about the state of the SoL test system 210 when executing a software component to be tested, to make a more or less good prediction or estimate for the response times of the individual program steps on the HoL -Target system 230 without having to run the software component to be tested on the HoL target system 230. Therefore, the HoL target system 230 can be decoupled from the time model 220 of the test environment 200 after the training phase.
  • system-specific information 30 about the HoL target system 230 such as information about the system design and software compilation and distribution (deployment model), also flows into the predictions of the regression model 220.
  • the left half of the block diagram in FIG. 2 illustrates that the SoL test system 210 according to the invention regularly during the execution of a software component 42 to be tested, here at each program step, acquires test system characteristics and, together with a response time query to the flow planning component (not shown separately here) transmitted with the pre-trained time model 220 - arrow 6.
  • the scheduling component answers this request with a specification for the response time on the SoL test system 210, which is based on the estimation of the time model 220 for the response time of the HoL target system 230 - Arrow 7.
  • the scheduling component of the test environment 200 takes over the entire scheduling of the program steps or runnables of a SoL recompute.
  • time behavior of software components to be tested on a HoL target system can be simulated reproducibly and credibly on a SOL test system with the aid of the measures according to the invention. This is made possible in particular by using a time model that describes a system state-dependent relationship between the time behavior of software components when running on the target system and the time behavior of these software components when running on the test system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Es werden eine Computer-implementierte Testumgebung (100) und ein Verfahren zum Testen von Software-Komponenten vorgeschlagen, die zur Ausführung auf einem vorgegebenen Zielsystem vorgesehen sind. Jede Software-Komponente umfasst eine Abfolge von mehreren zeitlich planbaren Programmschritten und die Zeitdauer vom Auslösen eines Programmschritts bis zur vollständigen Abarbeitung des Programmschritts ist als Antwortzeit des ausführenden Systems - Zielsystem oder Testsystem (10) - für diesen Programmschritt definiert. Das Testen erfolgt mit Hilfe eines Testsystems (10), auf dem die zu testenden Software-Komponenten mit Test-Eingabedaten ausgeführt werden, und mit Hilfe eines Zeitmodells (21), das einen systemzustandsabhängigen Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem Testsystem (10) beschreibt. Erfindungsgemäß wird während der Ausführung einer zu testenden Software- Komponente auf dem Testsystem (10) mindestens eine Testsystem-Kenngröße erfasst, die den aktuellen Zustand des Testsystems (10) beschreibt. Dann wird die Antwortzeit des Zielsystems für den aktuellen Programmschritt unter Berücksichtigung des aktuellen Zustands des Testsystems (10) mit Hilfe des Zeitmodells geschätzt und dem Testsystem (10) eine entsprechende Antwortzeit vorgegeben.

Description

Bezeichnung der Erfindung
Computer-implementierte Testumgebung sowie Verfahren zum Testen von
Software-Komponenten
Stand der Technik
Die Erfindung betrifft eine Computer-implementierte Testumgebung sowie ein Verfahren zum Testen von Software-Komponenten, die zur Ausführung auf einem vorgegebenen Zielsystem vorgesehen sind. Jede Software-Komponente umfasst eine Abfolge von mehreren zeitlich planbaren Programmschritten, sogenannten Runnables. Dabei kann es sich um eine Funktion, einen Thread oder auch um einen Prozess handeln. Die Zeitdauer vom Auslösen eines Programmschritts bis zur vollständigen Abarbeitung des Programmschritts ist als Antwortzeit oder auch Response time des ausführenden Systems - Zielsystem oder Testsystem - für diesen Programmschritt definiert. Das Testen erfolgt mit Hilfe eines Testsystems, auf dem die zu testenden Software-Komponenten mit Test-Eingabedaten ausgeführt werden, was auch als Recompute bezeichnet wird. Außerdem wird beim Testen ein Zeitmodell genutzt, das einen systemzustandsabhängigen Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem Testsystem beschreibt.
Bei der Software-Entwicklung für zeitkritische Anwendungen, wie zum Beispiel für Anwendungen aus dem Bereich des automatisierten Fahrens, sogenannten AD(automated driving)-Anwendungen, spielt das Zeitverhalten der einzelnen Software-Komponente beim Ausführen auf dem Zielsystem eine wesentliche Rolle. Bei sehr vielen Anwendungen müssen die Software-Komponenten mit einer Vielzahl von Test-Datensätzen getestet werden, um unterschiedlichste Testszenarien abzubilden. Oftmals steht das Zielsystem in der Testphase nicht zur Verfügung, da es äußerst komplex und speziell für die jeweilige Anwendung ausgelegt ist und/oder weil dessen Verwendung in der Testphase nicht wirtschaftlich ist. Deshalb werden in der Praxis zum Evaluieren des Zeitverhaltens von Software-Komponenten auf derartigen Zielsystemen häufig Simulationen oder analytische Performance-Modelle des Zielsystems verwendet, die auf gängigen Hardwaresystemen laufen.
Das Zeitverhalten einer Software-Komponente auf einem System - Testsystem oder Zielsystem - ist mit den funktionalen und nicht-funktionalen Eigenschaften dieses Systems verflochten. Es hängt von einer Vielzahl von Einflussgrößen ab, wie z.B. vom Funktionscode der Software-Komponente selbst, vom Compiler, von den verwendeten Bibliotheken, von der Hardware-Architektur und von der Verteilung der einzelnen Programmschritte auf die zur Verfügung stehenden Hardware-Ressourcen. Diese Einflussgrößen sind nicht unabhängig voneinander, vielmehr ändert sich das Timing der einzelnen Programmschritte bzw. Funktionsschritte und damit das Zeitverhalten der Software-Komponente insgesamt in Abhängigkeit von all diesen Aspekten.
In X. Zheng, P. Ravikumar, L. K. John and A. Gerstlauer, "Learning-based analytical cross-platform performance prediction," 2015 International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS), 2015, pp. 52-59, doi: 10.1109/SAMOS.2015.7363659. wird vorgeschlagen, die Performance von Software-Komponenten bei der Ausführung auf einem Zielsystem mit Hilfe eines lern-basierten analytischen Modells zu schätzen. In der Trainingsphase dieses Models wird ein Trainingsset von unterschiedlichen Software-Komponenten sowohl auf dem Testsystem als auch auf einer zeitgenauen Simulation des Zielsystems ausgeführt. Dabei werden auf dem Testsystem Performance-Kenngrößen und auf der Simulation des Zielsystems entsprechende Performance Referenzen erfasst. Diesen Messgrößen immanent ist die Beziehung zwischen Testsystem und Zielsystem, die während der Trainingsphase extrahiert und auf das analytische Modell abgebildet wird. Nach Abschluss der Trainingsphase wird das trainierte analytische Modell wie folgt zum Testen von Software-Komponenten eingesetzt: Die zu testende Software-Komponente wird ausschließlich auf dem Testsystem ausgeführt. Dabei werden Performance-Kenngrößen des Testsystems erfasst. Auf Basis dieser Performance-Kenngrößen des Testsystems schätzt das vorab trainierte Modell dann die Performance der Software-Komponente auf dem Zielsystem. Mit dieser Vorgehensweise lassen sich lediglich quantitative Aussagen zur Gesamtperformance der getesteten Software-Komponente auf dem Zielsystem machen. Eine qualifizierte Aussage darüber, wie sich die einzelnen Programmschritte auf die Gesamtperformance ausgewirkt haben, ist hier nicht möglich und dementsprechend auch keine Ursachenanalyse.
Aufgabe der Erfindung
Mit der Erfindung werden Maßnahmen vorgeschlagen, durch die das Zeitverhalten von zu testenden Software-Komponenten auf einem Zielsystem während der Ausführung auf einem Testsystem in realistischer und glaubwürdiger Weise nachgebildet werden kann, und zwar reproduzierbar für jeden einzelnen zeitlich planbaren Programmschritt der zu testenden Software- Komponente.
Kern und Vorteile der Erfindung
Dies wird erfindungsgemäß mit Hilfe einer Ablaufplanungskomponente erreicht, die dazu ausgelegt ist, während der Ausführung einer zu testenden Software- Komponente auf dem Testsystem die zeitliche Planung der einzelnen Programmschritte vorzunehmen. Dazu schätzt die Ablaufplanungskomponente die Antwortzeiten des Zielsystems für die einzelnen Programmschritte unter Berücksichtigung des aktuellen Zustands des Testsystems mit Hilfe des Zeitmodells. Auf Basis dieser Schätzung gibt die Ablaufplanungskomponente dem Testsystem dann eine Antwortzeit vor, die dem Zeitverhalten des Zielsystems in einem vergleichbaren Zustand entspricht.
Demnach werden während der Ausführung einer zu testenden Software- Komponente regelmäßig aktuelle Testsystem-Kenngrößen erfasst und an die Ablaufplanungskomponente übermittelt, wo sie als Informationen über den aktuellen Zustand des Testsystems interpretiert werden. Außerdem übermittelt das Testsystem für den jeweils aktuellen Programmschritt eine Antwortzeit- Anfrage an die Ablaufplanungskomponente. Das Zeitmodell der Ablaufplanungskomponente generiert dann unter Berücksichtigung des aktuellen Zustands des Testsystems eine Schätzung für die Antwortzeit des aktuellen Programmschritts auf dem Zielsystem. Dann beantwortet die Ablaufplanungskomponente die Antwortzeit-Anfrage des Testsystems mit einer Vorgabe für die Antwortzeit, die so gewählt ist, dass das Testsystem bei der Ausführung des aktuellen Programmschritts im Kontext der zu testenden Software-Komponente das Zeitverhalten des Zielsystems in einem vergleichbaren Zustand nachbildet.
Die erfindungsgemäßen Maßnahmen ermöglichen eine diskrete Ereignissimulation, die sowohl von der Ausführung der zu testenden Software- Komponente als auch von der Ablaufplanungskomponente bzw. deren Zeitmodell getrieben wird. Beide werden synchron gehalten, so dass die vom Zeitmodell gelieferten Antwortzeiten für den jeweils aktuellen Programmschritt immer auf Basis des aktuellen konsistenten Zustands des Testsystems berechnet werden. Die so vorgegebenen Antwortzeiten sind bei gleichem Input, i.e. Zustand des Testsystems und Programmschritt, und bei gleichem Design des Zielsystems reproduzierbar, so dass das Testsystem zusammen mit der erfindungsgemäßen Ablaufplanungskomponente das Zeitverhalten von zu testenden Software- Komponenten auf dem Zielsystem auf realistische und glaubwürdige Weise nachbildet.
Damit ermöglichen die erfindungsgemäßen Maßnahmen qualifizierte Aussagen darüber, wie sich die einzelnen Programmschritte auf die Gesamtperformance einer Software-Komponente auf dem Zielsystem auswirken. Diese Informationen sind von großem Nutzen für die Software- Entwicklung.
Von besonderem Vorteil ist außerdem, dass die erfindungsgemäßen Maßnahmen eine realistische Bewertung der Gesamtperformance einer getesteten Softwarekomponente auf dem Zielsystem ermöglichen, und nicht nur eine Schätzung, wie im Stand der Technik beschrieben. Dieser Bewertung können einfach die Ausgabedaten zugrunde gelegt werden, die beim Ausführen der zu testenden Software-Komponente auf dem Testsystem in Abhängigkeit von den Test-Eingabedaten erzeugt worden sind. Diese Ausgabedaten werden im Folgenden als Test-Ausgabedaten bezeichnet. Zur Bewertung der Gesamtperformance können die Test-Ausgabedaten beispielsweise mit den Ausgabedaten verglichen werden, die eine frühere Version der getesteten Software-Komponente für dieselben Test-Eingabedaten erzeugt hat.
Im Rahmen der Erfindung kann die Vorgabe der Antwortzeiten des Testsystems für die einzelnen Programmschritte der zu testenden Softwarekomponenten prinzipiell auf unterschiedliche Art und Weise erfolgen. In einer vorteilhaften Ausführungsform der Erfindung werden hierfür Trigger-Events für die Programmschritte der zu testenden Software-Komponente generiert. Dabei kann es sich sowohl um Trigger-Events handeln, die einen Programmschritt auslösen, als auch um Trigger-Events, die einen Programmschritt beenden. Derartige Trigger-Events werden bevorzugt von der Ablaufplanungskomponente der erfindungsgemäßen computerimplementierten Testumgebung generiert.
Wie bereits erwähnt, beschreibt das im Rahmen der Erfindung verwendete Zeitmodell einen Zusammenhang zwischen dem Zeitverhalten von Software- Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem Testsystem, wenn sich die beiden Systeme - Zielsystem und Testsystem - in einem vergleichbaren Zustand befinden. D.h. das Zeitmodell benötigt Informationen über den Zustand des Testsystems beim Ausführen einer Software-Komponente, um Aussagen über das Zeitverhalten des Zielsystems in einem vergleichbaren Zustand beim Ausführen dieser Software-Komponente zu machen. Deshalb werden im Rahmen der Erfindung Testsystem-Kenngrößen erfasst, die den Zustand des Testsystems mehr oder weniger umfänglich beschreiben. Dazu umfasst die erfindungsgemäße computerimplementierte Testumgebung entsprechende Hardware- oder Software-implementierte Erfassungsmittel. Damit werden während der Ausführung einer zu testenden Software-Komponente bevorzugt eine oder auch mehrere der folgenden Testsystem-Kenngrößen erfasst:
- Prozessorzeit eines Programmschritts (net execution time),
- Warte-/Verzögerungszeiten bei der Ausführung eines Programmschritts (time spent waiting for execution resources, e.g. cores),
- Warte-/Verzögerungszeiten beim Zugriff auf Datenspeicher/quellen (data excess related delay),
- Latenz aufgrund von Datenspeicherstrukturen (intrinsic latency of memory hierarchy),
- Verzögerungszeiten bei Bus- und Netzwerkzugriffen (Bus- and network-access delay),
- zeitplanungsbedingte Verzögerungen (scheduling related delays)
- Middleware-Latenz,
- Komplexität der Test-Eingabedaten (input data complexity, number of messages on the input ports, message payload analysis metrics). In einer bevorzugten Ausführungsform der Erfindung umfasst das Zeitmodell mindestens ein vortrainiertes Regressionsmodell, insbesondere ein neuronales Netzwerk. Das Trainieren eines derartigen lernbasierten Zeitmodells wird nachfolgend beispielhaft in Verbindung mit Fig. 2 erläutert.
Alternativ oder auch ergänzend zu einem vortrainierten Regressionsmodell könnte das Zeitmodell auch mindestens eine Simulationskomponente umfassen, die vorgegebene Systemparameter des Zielsystems berücksichtigt, insbesondere Parameter der Hardwarearchitektur, des Betriebssystems, des verwendeten Zeitplaners (scheduler), der Softwareverteilung auf eine gegebene Hardwarearchitektur (deployment model) und Prioritätsmodelle von Programmschritten.
Von besonderer Bedeutung ist der Einsatz der vorliegenden Erfindung beim Testen von Software-Komponenten im Rahmen der Entwicklung von AD- Anwendungen. Bei dem Zielsystem handelt es sich hier in der Regel um ein eingebettetes anwendungsspezifisches Hardware-open-loop System (HoL), während als Testsystem vorteilhafterweise ein Software-open-loop System (SoL) verwendet werden kann, das auf einem gängigen Hardwaresystem basiert.
Zeichnungen
Vorteilhafte Ausführungsformen und Weiterbildungen der Erfindung werden nachfolgend anhand der Figuren erläutert.
Fig. 1 veranschaulicht das Zusammenwirken der einzelnen Komponenten einer erfindungsgemäßen Testumgebung 100 anhand eines ersten Blockschaltbilds.
Fig. 2 veranschaulicht das Training eines Zeitmodells und dessen Verwendung im Rahmen des erfindungsgemäßen Verfahrens anhand eines zweiten Blockschaltbilds, das den Informationsfluss zwischen den einzelnen Komponenten einer erfindungsgemäßen Testumgebung 200 wiedergibt. Beschreibung von Ausführungsbeispielen
Bei Fig. 1 handelt es sich um eine „quasi statische“ Darstellung der Komponenten einer erfindungsgemäßen Testumgebung 100 zum Testen von Software-Komponenten, die zur Ausführung auf einem vorgegebenen Zielsystem vorgesehen sind. Das Zielsystem könnte beispielsweise in einem AD-Projekt angesiedelt sein. Das Zielsystem ist zwar nicht Teil der Testumgebung 100. Im hier beschriebenen Ausführungsbeispiel stehen der Testumgebung 100 aber Informationen 30 über die Softwareanteile und die Spezifikation der Hardware des Zielsystems zur Verfügung, wie z.B. Informationen über das Systemdesign 31 und die Softwarecompilierung und -Verteilung 32 (Build & Deploy) auf dem Zielsystem. Die zu testenden Software-Komponenten wurden für das Zielsystem entwickelt. Jede Software-Komponente umfasst eine Abfolge von mehreren zeitlich planbaren Programmschritten. Die Software-Komponenten werden zu Testzwecken mit Test-Eingabedaten in der Testumgebung 100 ausgeführt. Die Software-Komponenten und die Test-Eingabedaten liegen in Form von Source Files 33 vor. Mit Hilfe der erfindungsgemäßen Testumgebung 100 wird das Zeitverhalten der zu testenden Software-Komponenten bei der Ausführung auf dem Zielsystem nachgebildet. Dabei spielt die Zeitdauer vom Auslösen eines Programmschritts bis zur vollständigen Abarbeitung des Programmschritts, die als Antwortzeit des ausführenden Systems - Zielsystem oder Testsystem - für diesen Programmschritt definiert ist, eine wesentliche Rolle.
Wesentlicher Bestandteil der Testumgebung 100 ist ein Testsystem 10, das sich sowohl in seiner Hardware als auch softwaretechnisch deutlich vom Zielsystem unterscheiden kann. Die einzige technische Voraussetzung, die das Testsystem 10 erfüllen muss, ist, dass die zu testenden Software-Komponenten auf dem Testsystem 10 ausführbar sind. In der Regel handelt es sich bei dem Testsystem 10 um eine Software-Implementierung auf einem gängigen Hardwaresystem, das beispielsweise auch für Consumer-Anwendungen eingesetzt wird.
Des Weiteren umfasst die Testumgebung 100 erfindungsgemäß eine Ablaufplanungskomponente 20, die ein Zeitmodell 21 für die Vorhersage des Zeitverhaltens von Software-Komponenten beim Ausführen auf dem Zielsystem nutzt. Dieses Zeitmodell 21 beschreibt nämlich einen Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem Testsystem 10, sofern sich Zielsystem und Testsystem in einem vergleichbaren Zustand befinden. Das Zeitmodell 21 kann für seine Vorhersagen beispielsweise Machine-Learning-Modelle nutzen oder auch stochastische Ansätze aus der Unsicherheitsbemessung oder Fehleranalyse (Uncertainty Quantification), wie Polynomial Chaos Expansion.
Im hier dargestellten Ausführungsbeispiel nutzt das Zeitmodell 21 außerdem noch die zur Verfügung stehenden Zielsystem-Informationen 30 über Systemdesign 31 und Softwarecompilierung und -Verteilung 32 für seine Vorhersagen, was durch die Pfeile 2 und 4 angedeutet ist. Die Pfeile 2 und 3 veranschaulichen, dass die Zielsystem-Informationen 30 auch auf der Systemebene 11 des Testsystems 10 genutzt werden, beispielsweise um Systemparameter anzupassen, soweit dies möglich ist.
Die Pfeile 1 und 3 veranschaulichen, dass die Source-Files 33 der zu testenden Software-Komponenten und Test-Eingabedaten dem Testsystem 10 zur Verfügung gestellt werden. Die Ausführung einer zu testenden Software- Komponente mit einem bestimmten Satz von Test-Eingabedaten, bei der ein entsprechender Satz von Test-Ausgabedaten generiert wird, wird auch als Recompute bezeichnet. Die Ausführung der Software-Komponenten erfolgt auf einer Replay-Unit 12 des Testsystems 10, die dazu mit der Systemebene 11 kommuniziert, was durch Pfeile 5 angedeutet ist. Des Weiteren umfasst das Testsystem 10 eine Recording-Unit 13 mit Hardware- und/oder Softwareimplementierte Erfassungsmittel für Testsystem-Kenngrößen, die den Zustand des Testsystems 10 beim Ausführen der einzelnen Programmschritte der zu testenden Software-Komponenten beschreiben.
Die aktuellen Testsystem-Kenngrößen - Pfeil 6 - werden zusammen mit einer Antwortzeit-Anfrage - Pfeil 8 - für den aktuell ausgeführten Programmschritt an die Ablaufplanungskomponente 20 übermittelt. Das Zeitmodell 21 interpretiert die Testsystem-Kenngrößen als Informationen über den aktuellen Zustand des Testsystems 10 und generiert damit eine Schätzung für die Antwortzeit des aktuellen Programmschritts auf dem Zielsystem in einem vergleichbaren Systemzustand. Dann beantwortet die Ablaufplanungskomponente 20 die Antwortzeit-Anfrage des Testsystems 10 - angedeutet durch Pfeil 7 - mit einer Vorgabe für die Antwortzeit des Testsystems 10, so dass das Testsystem 10 bei der Ausführung des aktuellen Programmschritts im Kontext der zu testenden Software-Komponente das Zeitverhalten des Zielsystems nachbildet. Zur Vorgabe der Antwortzeiten des Testsystems 10 generiert im hier dargestellten Ausführungsbeispiel ein Trace Generator 22 der Ablaufplanungskomponente 20 zu geeigneten Zeitpunkten Trigger-Events, durch die ein Programmschritt ausgelöst oder beendet wird. Die Informationen über das Auslösen und Beenden der einzelnen Programmschritte werden auch als Trace-Daten bezeichnet und können in Form eines Gantt-Diagramms dargestellt werden.
Aus Sicht der Ablaufplanungskomponente 20 sind die zu testenden Software- Komponenten bei der Ausführung auf dem Testsystem 10, also die Recomputes, die Nutzer bzw. Verbraucher der Trace-Daten, indem sie die einzelnen Programmschritte, also die Runnables, entsprechend den von der Ablaufplanungskomponente generierten Trace-Daten zeitlich planen. Dadurch wird sichergestellt, dass ein Recompute bei Verwendung derselben Trace-Daten reproduzierbar ist und auch reproduzierbare Test-Ausgabedaten liefert.
Erfindungsgemäß übernimmt die Ablaufplanungskomponente 20 also die gesamte zeitliche Planung der zu testenden Software-Komponenten, und zwar parallel zur Ausführung der Software-Komponente auf dem Testsystem 10. Dazu schätzt die Ablaufplanungskomponente 20 mit Hilfe des Zeitmodells 21 und unter Berücksichtigung des aktuellen Zustands des Testsystems 10 die Antwortzeiten des Zielsystems für die einzelnen Programmschritte. Diese Schätzung ist die Basis für die Vorgabe einer Antwortzeit für das Testsystem 10, die dem Zeitverhalten des Zielsystems in einem vergleichbaren Systemzustand entspricht. Aufgrund der Unterschiede zwischen Zielsystem und Testsystem 10 wird die dem Testsystem 10 vorgegebene Antwortzeit in der Regel nicht identisch mit der geschätzten Antwortzeit des Zielsystems sein. Die Testsystem- Antwortzeiten aller Programmschritte einer Software-Komponente werden jedoch so gewählt sein, dass sie das Zeitverhalten der Software-Komponente insgesamt auf dem Zielsystem nachbilden, aber beispielsweise alle Testsystem- Antwortzeiten um einen Faktor langsamer oder schneller sind, als die geschätzten Antwortzeiten des Zielsystems.
Das Blockschaltbild der Fig. 2 bezieht sich auf eine erfindungsgemäße Testumgebung 200 mit einem SoL-Testsystem 210 und mit einer Ablaufplanungskomponente, die ein Zeitmodell mit einem Regressionsmodell 220 zur Schätzung der Antwortzeiten eines HoL-Zielsystems 230 für einzelne Programmschritte verwendet. Die rechte Hälfte der Fig. 2 bezieht sich ausschließlich auf das Training eines derartigen Zeitmodells 220, die linke Hälfte stellt auch dessen Verwendung im Rahmen des erfindungsgemäßen Verfahrens dar.
In der Trainingsphase soll das Regressionsmodell 220, beispielsweise ein neuronales Netzwerk, den Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf einem HoL-Zielsystem 230 und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem SoL- Testsystem 210 anhand von Trainings-Software lernen, um nach Abschluss der Trainingsphase anhand von Testsystem-Kenngrößen, die beim Ausführen von Software-Komponenten auf dem SoL-Testsystem 210 erfasst werden, das Zeitverhalten dieser Software-Komponenten auf dem HoL-Zielsystem 230 zu schätzen.
Dafür werden in einem ersten Schritt repräsentative Trainingssoftware- Komponenten ausgewählt. Der entsprechende Sourcecode 40 wird einerseits für das HoL-Zielsystem 230 und andererseits für das SoL-Testsystem 210 kompiliert, wobei der auf dem HoL-Zielsystem 230 ausführbare Programmcode 41 und der auf dem SoL-Testsystem 210 ausführbare Programmcode 42 entstehen. In einem nächsten Schritt werden diese beiden Programmcodes 41 und 42 dann mit den gleichen Trainings-Eingabedaten auf dem jeweiligen System - HoL-Zielsystem 230 bzw. SoL-Testsystem 210 - ausgeführt. Dabei werden sowohl vom HoL-Zielsystem 230 als auch vom SoL-Testsystem 210 Kenngrößen erfasst, die den Zustand des jeweiligen Systems beschreiben, wie z.B.
- Prozessorzeit eines Programmschritts (net execution time),
- Warte-/Verzögerungszeiten bei der Ausführung eines Programmschritts (time spent waiting for execution resources, e.g. cores),
- Warte-/Verzögerungszeiten beim Zugriff auf Datenspeicher/quellen (data excess related delay),
- Latenz aufgrund von Datenspeicherstrukturen (intrinsic latency of memory hierarchy),
- Verzögerungszeiten bei Bus- und Netzwerkzugriffen (Bus- and network-access delay),
- zeitplanungsbedingte Verzögerungen (scheduling related delays)
- Middleware-Latenz,
- Komplexität der Test-Eingabedaten (input data complexity, number of messages on the input ports, message payload analysis metrics). So messen entsprechende Hardware- und/oder Software-implementierte Erfassungsmittel, wann ein Runnable ausgelöst wird, wann seine Ausführung zurückgestellt wird, wann ihm wieder Prozessor-Ressourcen zugewiesen werden, bis seine Ausführung schließlich beendet ist. Es können auch nichtfunktionale Performance-Modell-Zähler zusammen mit einer Analyse von funktionalen Eingabedaten von Runnables protokolliert werden.
All diese für das HoL-Zielsystem 230 erfassten Daten 50 und parallel dazu für das SoL-Testsystem 210 erfassten Daten - angedeutet durch den Pfeil 6 - werden verwendet, um das Regressionsmodell 220 mit Hilfe von Machine- Learning-Methoden zu trainieren.
Nach Abschluss der Trainingsphase ist das Regressionsmodell 220 in der Lage, auf Basis von Informationen über den Zustand des SoL-Testsystems 210 beim Ausführen einer zu testenden Software-Komponente eine mehr oder weniger gute Vorhersage bzw. Schätzung für die Antwortzeiten der einzelnen Programmschritte auf dem HoL-Zielsystem 230 abzugeben, ohne dass die zu testende Software-Komponente auf dem HoL-Zielsystem 230 ausgeführt werden muss. Deshalb kann das HoL-Zielsystem 230 nach der Trainingsphase vom Zeitmodell 220 der Testumgebung 200 abgekoppelt werden.
Im hier dargestellten Ausführungsbeispiel fließen in die Vorhersagen des Regressionsmodells 220 zudem noch systemspezifische Informationen 30 über das HoL-Zielsystem 230 ein, wie z.B. Informationen über Systemdesign und Softwarecompilierung und -Verteilung (deployment model).
Die linke Hälfte des Blockdiagramms der Fig. 2 illustriert, dass das SoL- Testsystem 210 während der Ausführung einer zu testenden Software- Komponente 42 erfindungsgemäß regelmäßig, hier bei jedem Programmschritt, Testsystem-Kenngrößen erfasst und zusammen mit einer Antwortzeit-Anfrage an die Ablaufplanungskomponente (hier nicht separat dargestellt) mit dem vortrainierten Zeitmodell 220 übermittelt - Pfeil 6. Die Ablaufplanungskomponente beantwortet diese Anfrage mit einer Vorgabe für die Antwortzeit auf dem SoL-Testsystem 210, die auf der Schätzung des Zeitmodells 220 für die Antwortzeit des HoL-Zielsystems 230 beruht - Pfeil 7. Dadurch übernimmt die Ablaufplanungskomponente der erfindungsgemäßen Testumgebung 200 die gesamte Zeitplanung der Programmschritte bzw. Runnables eines SoL-Recompute. Die voranstehende Beschreibung von Ausführungsbeispielen verdeutlicht, dass das Zeitverhalten von zu testenden Software-Komponenten auf einem HoL- Zielsystem mit Hilfe der erfindungsgemäßen Maßnahmen reproduzierbar und glaubwürdig auf einem Sol-Testsystem nachbildet werden kann. Dies wird insbesondere durch die Nutzung eines Zeitmodells möglich, das einen systemzustandsabhängigen Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem Testsystem beschreibt.

Claims

Ansprüche
1. Computer-implementierte Testumgebung (100) zum Testen von Software-Komponenten, die zur Ausführung auf einem vorgegebenen Zielsystem vorgesehen sind,
• wobei jede Software-Komponente eine Abfolge von mehreren zeitlich planbaren Programmschritten umfasst und
• wobei die Zeitdauer vom Auslösen eines Programmschritts bis zur vollständigen Abarbeitung des Programmschritts als Antwortzeit des ausführenden Systems - Zielsystem oder Testsystem (10) - für diesen Programmschritt definiert ist, wobei die Testumgebung (100) mindestens umfasst:
• ein Testsystems (10) zum Ausführen von zu testenden Software-Komponenten mit Test-Eingabedaten,
• Hardware- und/oder Software-implementierte Erfassungsmittel für Testsystem- Kenngrößen, die den Zustand des Testsystems (10) beim Ausführen der zu testenden Software-Komponente beschreiben, und
• ein Zeitmodell (21), das einen systemzustandsabhängigen Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software-Komponenten beim Ausführen auf dem Testsystem (10) beschreibt; gekennzeichnet durch eine Ablaufplanungskomponente (20), die dazu ausgelegt ist, während der Ausführung einer zu testenden Software-Komponente auf dem Testsystem (10) die zeitliche Planung der einzelnen Programmschritte vorzunehmen, indem die Ablaufplanungskomponente (20) die Antwortzeiten des Zielsystems für die einzelnen Programmschritte unter Berücksichtigung des aktuellen Zustands des Testsystems (10) mit Hilfe des Zeitmodells (21) schätzt und dem Testsystem (10) eine entsprechende Antwortzeit vorgibt.
2. Computer-implementierte Testumgebung nach Anspruch 1, dadurch gekennzeichnet, dass die Ablaufplanungskomponente (20) dazu ausgelegt ist, Trigger-Events für die Programmschritte der zu testenden Software-Komponente zu generieren, so dass ein Programmschritt durch ein Trigger-Event ausgelöst oder beendet wird.
3. Computer-implementierte Testumgebung nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass Hardware- und/oder Softwareimplementierte Erfassungsmittel für eine oder mehrere der folgenden Testsystem-Kenngrößen vorgesehen sind:
- Prozessorzeit eines Programmschritts (net execution time),
- Warte-/Verzögerungszeiten bei der Ausführung eines Programmschritts (time spent waiting for execution resources, e.g. cores),
- Warte-/Verzögerungszeiten beim Zugriff auf Datenspeicher/quellen (data excess related delay),
- Latenz aufgrund von Datenspeicherstrukturen (intrinsic latency of memory hierarchy),
- Verzögerungszeiten bei Bus- und Netzwerkzugriffen (Bus- and network-access delay),
- zeitplanungsbedingte Verzögerungen (scheduling related delays)
- Middleware-Latenz,
- Komplexität der Test-Eingabedaten (input data complexity, number of messages on the input ports, message payload analysis metrics).
4. Computerimplementierte Testumgebung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das Zeitmodell (21) mindestens ein vortrainiertes Regressionsmodel, insbesondere ein neuronales Netzwerk, umfasst.
5. Computerimplementierte Testumgebung nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Zeitmodell mindestens eine Simulationskomponente umfasst, die vorgegebene Systemparameter des Zielsystems berücksichtigt, insbesondere Parameter
- der Hardwarearchitektur,
- des Betriebssystems,
- des verwendeten Zeitplaners (scheduler),
- der Softwareverteilung auf eine gegebene Hardwarearchitektur (deployment model) und
- Prioritätsmodelle von Programmschritten. 15
6. Computer-implementierte Testumgebung (200) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass als Zielsystem (230) ein Hardware-open-loop System (HoL) vorgesehen ist, das insbesondere für ein selbstfahrendes Fahrzeugs spezifiziert ist (AD-Anwendung) und dass das Testsystem (210) in Form eines Software-open-loop Systems (SoL) realisiert ist.
7. Computerimplementiertes Verfahren zum Testen von Software- Komponenten, die zur Ausführung auf einem vorgegebenen Zielsystem vorgesehen sind,
• wobei jede Software-Komponente eine Abfolge von mehreren zeitlich planbaren Programmschritten umfasst,
• wobei die Zeitdauer vom Auslösen eines Programmschritts bis zur vollständigen Abarbeitung des Programmschritts als Antwortzeit des ausführenden Systems - Zielsystem oder Testsystem (10) - für diesen Programmschritt definiert ist,
• wobei das Testen mit Hilfe eines Testsystems (10) erfolgt, auf dem die zu testenden Software-Komponenten mit Test-Eingabedaten ausgeführt werden, und
• mit Hilfe eines Zeitmodells (21), das einen systemzustandsabhängigen Zusammenhang zwischen dem Zeitverhalten von Software-Komponenten beim Ausführen auf dem Zielsystem und dem Zeitverhalten dieser Software- Komponenten beim Ausführen auf dem Testsystem (10) beschreibt; dadurch gekennzeichnet, dass während der Ausführung einer zu testenden Software-Komponente auf dem Testsystem (10)
• mindestens eine Testsystem-Kenngröße erfasst wird, die den aktuellen Zustand des Testsystems (10) beschreibt, und
• die Antwortzeit des Zielsystems für den aktuellen Programmschritt unter Berücksichtigung des aktuellen Zustands des Testsystems (10) mit Hilfe des Zeitmodells (21) geschätzt wird und dem Testsystem (10) eine entsprechende Antwortzeit vorgegeben wird.
8. Computer-implementiertes Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass auf Basis der für einen Programmschritt vorgegebenen Antwortzeit des Testsystems (10) mindestens ein Trigger-Event für den Programmschritt generiert wird, wodurch der Programmschritt ausgelöst oder beendet wird. 16
9. Computer implementiertes Verfahren nach einem der Ansprüche 7 oder 8, dadurch gekennzeichnet, dass eine oder mehrere der folgenden Testsystem- Kenngrößen erfasst werden:
- Prozessorzeit eines Programmschritts (net execution time),
- Warte-/Verzögerungszeiten bei der Ausführung eines Programmschritts (time spent waiting for execution resources, e.g. cores),
- Warte-/Verzögerungszeiten beim Zugriff auf Datenspeicher/quellen (data excess related delay),
- Latenz aufgrund von Datenspeicherstrukturen (intrinsic latency of memory hierarchy),
- Verzögerungszeiten bei Bus- und Netzwerkzugriffen (Bus- and network-access delay),
- zeitplanungsbedingte Verzögerungen (scheduling related delays)
- Middleware-Latenz,
- Signal-Nutzlast-Analysedaten (number of messages on the input ports, message payload analysis metrics),
- Komplexität der Test-Eingabedaten (input data complexity).
10. Computer implementiertes Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass beim Ausführen der zu testenden Software- Komponente auf dem Testsystem (10) in Abhängigkeit von den Test- Eingabedaten Test-Ausgabedaten erzeugt werden, die einer Bewertung der zu testenden Software-Komponente zugrunde gelegt werden.
PCT/EP2022/082593 2021-12-23 2022-11-21 Computer-implementierte testumgebung sowie verfahren zum testen von software-komponenten WO2023117240A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021214973.1A DE102021214973A1 (de) 2021-12-23 2021-12-23 Computer-implementierte Testumgebung sowie Verfahren zum Testen von Software-Komponenten
DE102021214973.1 2021-12-23

Publications (1)

Publication Number Publication Date
WO2023117240A1 true WO2023117240A1 (de) 2023-06-29

Family

ID=84462895

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/082593 WO2023117240A1 (de) 2021-12-23 2022-11-21 Computer-implementierte testumgebung sowie verfahren zum testen von software-komponenten

Country Status (2)

Country Link
DE (1) DE102021214973A1 (de)
WO (1) WO2023117240A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009054137A1 (de) * 2009-11-20 2011-05-26 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Testen einer Applikation hinsichtlich ihrer Performanz
DE102011076821A1 (de) * 2011-05-31 2012-12-06 Wolfgang Pree Gmbh Simulation von Echtzeitsystemen unter Ausnutzung vonAufrufstellen (Access Points)

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009054137A1 (de) * 2009-11-20 2011-05-26 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Testen einer Applikation hinsichtlich ihrer Performanz
DE102011076821A1 (de) * 2011-05-31 2012-12-06 Wolfgang Pree Gmbh Simulation von Echtzeitsystemen unter Ausnutzung vonAufrufstellen (Access Points)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
KRAMER TAPIO RALF ET AL: "Modellierung und Echtzeitanalyse komplexer Wirkketten in Fahrerassistenzsystemen", 26 November 2020 (2020-11-26), XP055892545, Retrieved from the Internet <URL:https://support.inchron.de/fileadmin/INCHRON/3-PDFs/EN/Paper_AutoTest_2010_INCHRON_de_PDF.pdf> [retrieved on 20220216] *
X. ZHENGP. RAVIKUMARL. K. JOHNA. GERSTLAUER: "Learning-based analytical cross-platform performance prediction", 2015 INTERNATIONAL CONFERENCE ON EMBEDDED COMPUTER SYSTEMS: ARCHITECTURES, MODELING, AND SIMULATION (SAMOS), 2015, pages 52 - 59
YAN RONGJIE ET AL: "Design Verification and Validation for Reliable Safety-Critical Autonomous Control Systems", 2018 23RD INTERNATIONAL CONFERENCE ON ENGINEERING OF COMPLEX COMPUTER SYSTEMS (ICECCS), IEEE, 12 December 2018 (2018-12-12), pages 170 - 179, XP033485803, DOI: 10.1109/ICECCS2018.2018.00026 *

Also Published As

Publication number Publication date
DE102021214973A1 (de) 2023-06-29

Similar Documents

Publication Publication Date Title
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP3082000B1 (de) Verfahren und system zum testen eines mechatronischen systems
EP2194432B1 (de) Scheduling-Verfahren
EP2120143B1 (de) Verfahren zur Ausführung von Tasks zur Berechnung eines zu simulierenden Signals in Echtzeit
DE102014110096A1 (de) Testeinrichtung zum Echtzeittest eines virtuellen Steuergeräts
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
EP3398092A1 (de) Verfahren zum konfigurieren einer co-simulation für ein gesamtsystem
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
EP3306295B1 (de) Verfahren und vorrichtung zum testen elektronischer steuerungen, insbesondere zum testen von automobilsteuerungen
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
DE102017211433A1 (de) Verfahren zum Durchführen eines Funktionstests eines Steuergeräts in einem Hardware-in-the-Loop-Test, HIL-Test, sowie HIL-Prüfstand und Steuergerät
WO2023117240A1 (de) Computer-implementierte testumgebung sowie verfahren zum testen von software-komponenten
EP3401849A1 (de) Produktreifebestimmung eines technischen systems
Englisch et al. Automated generation of tests for education in software engineering
DE102021212009A1 (de) Verfahren zur Simulation einer Hardwareeinheit in einer Recheneinheit
DE102019219067A1 (de) Verfahren zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE102022114286A1 (de) Verfahren zum Rekonstruieren eines Laufzeitfehlers eines Softwaremoduls eines Kraftfahrzeug- Steuergeräts sowie Speichermedium und Prozessorschaltung
DE102004050293B3 (de) Verfahren zur Simulation des Betriebs eines Netzwerks
DE102009054137A1 (de) Verfahren zum Testen einer Applikation hinsichtlich ihrer Performanz
WO1999038024A1 (de) Verfahren zur computergestützten optimierung von prüfspezifikationen und minimierung von prüfsoftware
DE102019216676A1 (de) Prognose eines Messwerts einer Messgröße eines technischen Systems
DE102022127868A1 (de) Verfahren zum Durchführen einer Simulation
DE102022134601A1 (de) Systeme und verfahren für das training und die bereitstellung von modellen für maschinelles lernen
CN117971375A (zh) 干涉服务分离的核电厂仿真系统
EP3764185A1 (de) Verfahren zum testen eines systems

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

Country of ref document: EP

Kind code of ref document: A1