[go: up one dir, main page]

EP3622451A1 - Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs - Google Patents

Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs

Info

Publication number
EP3622451A1
EP3622451A1 EP18720650.3A EP18720650A EP3622451A1 EP 3622451 A1 EP3622451 A1 EP 3622451A1 EP 18720650 A EP18720650 A EP 18720650A EP 3622451 A1 EP3622451 A1 EP 3622451A1
Authority
EP
European Patent Office
Prior art keywords
test
sut
tests
result
environment
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP18720650.3A
Other languages
English (en)
French (fr)
Inventor
Holger Naundorf
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dspace GmbH
Original Assignee
Dspace GmbH
Dspace Digital Signal Processing and Control Engineering 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 Dspace GmbH, Dspace Digital Signal Processing and Control Engineering GmbH filed Critical Dspace GmbH
Publication of EP3622451A1 publication Critical patent/EP3622451A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06395—Quality analysis or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00—Computing arrangements based on specific mathematical models
    • G06N7/01—Probabilistic graphical models, e.g. probabilistic networks

Definitions

  • the invention relates to a method and a test system for
  • test coverage Methods for product maturity determination are known from the prior art, in which the product maturity of a technical system is determined by means of test coverage. Under test coverage is here in
  • the ratio of tests performed to the total number of tests executable for the technical system or the ratio of successfully performed tests to the total number of tests that can be performed on the technical system.
  • product maturity is determined by means of test coverage, and proposals are made for improving the test coverage.
  • the object of the invention is to provide a device which further develops the prior art.
  • a method for determining a product maturity by means of tests comprises executing a test case by means of a test environment applied to a test object, and there is no result for at least one test, and the method comprises the steps of setting rules for calculating a probability that a test for which there is no result will be successful or unsuccessful, the rules using as input variables present or expected results of tests and returning probabilities as output variables, calculating the probability that a test for which no result is present, will be successful, by means of at least part of the predetermined rules, as well as representation of the product maturity in dependence of the probabilities calculated in the previous step.
  • An advantage of the method according to the invention is that the product maturity of a technical system is evaluated not only on the basis of already performed tests, but also tests that have not yet been carried out are taken into account in the evaluation. In the event that not all tests are performed, this results in a more complete picture of product maturity, otherwise you will get more meaningful statements about product maturity at an earlier stage, as the tests that are still in the future will also be included in the evaluation. Furthermore, based on this forward-looking consideration, an improved selection of the tests still to be performed and their order can be made. Further, it is advantageous that by means of the method easier to find but meaningful representations of product maturity found and presented can be. Statements about product maturity can simply be made according to the existing criteria, such as: B.
  • test object is an at least partially autonomously driving vehicle, a part of an at least partially autonomously driving vehicle or a functionality of an at least partially autonomously driving vehicle
  • test case is a driving maneuver of the at least partially autonomously driving vehicle, a driving maneuver with the part of the at least partially autonomously driving vehicle or a driving maneuver in which the functionality of an at least partially autonomously driving vehicle is taken into account
  • TE test environment
  • test case or a test environment or a test object in a first and a second version, wherein the second version represents a state of development of the test case or the test environment or the test object, the time of the development of the first version of the test case or Test environment or the test object.
  • the predetermined rules represent a technical or statistical relationship between a first test case, a first test environment or a first test object in the first or second version and a second test case, a second test environment or a second test object in the first or second version.
  • the result of a test may take at least the values "Test Success” (passed) and "Test Failed”.
  • the predetermined rules are automatically created and / or verified by analyzing a database of at least a portion of the tests, including test cases, test environments, test objects, and results.
  • the analysis comprises a static evaluation of relationships of tests, in particular relationships of tests with positive results.
  • a first set of tests is determined using a statistical distribution, with results being or being generated for the first set of tests.
  • the determination of the tests of the first group of tests is based on one or more further static distributions of the test cases, the test environments and / or the test objects.
  • the static distribution and / or one or more of the further static distributions are random distributions.
  • the calculation of the probability that a test for which no Result, will be successful from the static distribution of the tests, the test cases, the test environments, and / or the test objects.
  • the presentation of the product maturity takes place in the form of a numerical, in particular percentage, test coverage or in the form of a, in particular color-coded graphic.
  • one or more criteria are specified and some of the tests for which in the second method step a probability that the test will be successful or unsuccessful have been calculated will be executed or suggested for execution, with the ones to be executed or executed proposed tests meet at least one of the given criteria.
  • At least one of the predetermined criteria is above or below a threshold for the probability that the test will be successful or unsuccessful.
  • a weighting is assigned to a test case (TC), a test environment (TE), a test object (SUT) or a combination of at least two elements from test case (TC), test environment (TE) and test object (SUT) and the weighting is taken into account in calculating the likelihood that a test for which no result will be successful or unsuccessful in the second step and / or in the presentation of the product maturity in the last step.
  • a threshold value of the product maturity is determined and, if the threshold for product maturity is exceeded, the test object (SUT) is released for a further development step.
  • test object is assigned to a class of test objects (SUT), in particular by means of a level of the degree of automation, and the threshold value of the product maturity is defined as a function of the assigned class.
  • SUT class of test objects
  • the object is also achieved by a test system for testing a technical system, wherein the test system carries out one of the methods described above.
  • Figure 1 shows schematically the composition of a test
  • Test environment TE
  • test case TC
  • test object SUT
  • FIG. 2 schematically shows the relationships between test (1)
  • Test environment TE
  • test case TC
  • test object SUT
  • result of the test TR
  • FIG. 3 schematically shows the storage or storage of
  • FIG. 4 schematically shows the prediction of results (TR)
  • FIG. 5 schematically shows the prediction of results (TR)
  • Figure 6 is a tabular representation of results of tests
  • Figure 7 is a tabular representation of predicted
  • Results of test (1) schematically the derivation of rules (5) from the in a data storage (3) stored or stored tests (1) and results of tests (TR).
  • schematic representation of an at least partially autonomously driving vehicle schematic representation of a classification into levels of different degrees of automation in at least partially autonomously driving vehicles.
  • a test (1) comprises at least one test environment (TE) from a possible plurality of test environments (TE), one test case (TC) from a possible plurality of test cases (TC) and one test object ("system under test”).
  • TE test environment
  • TC test case
  • TC test case
  • SUT test object
  • the aim of the maturity determination of a technical system is to evaluate product characteristics such as performance, reliability or user-friendliness. From this it follows whether a next stage, a so-called milestone, has been reached in the development of the technical system. The final milestone in most cases is the release of the product for sale or delivery of the product.
  • test cases There is, among other things, on the functionality to be tested and the objectives to be achieved for safety and reliability
  • HIL tests hardware-in-the-loop tests
  • test cases can be developed on the HIL test environments (usually special real-time computers)
  • An example of such a test tool is the software product AutomationDesk from dSPACE
  • simulation environments so-called offline simulators, are also used, some of which can be executed on commercially available PCs.
  • TE test environments
  • HIL offline simulator
  • test (1) test environment (TE), test object (SUT) and result (TR) of a test (1) are shown schematically.
  • data are collected which represent, at least partially, a result (TR) of the test (1) or from which a result (TR) of the test (1) can be derived.
  • TR result of the test (1)
  • TC test case
  • TE test environment
  • SUT test object
  • TR test results
  • results (TR) are assigned to the test (1) in order to be able to understand the conditions of the corresponding test execution in the later evaluation of the test results (TR).
  • Typical results (TR) of tests (1) are "passed” and "failed". Since the use of the English terms "passed” and "failed" in the environment of testing and test administration are more common, they are also used in the following.
  • the technical system to be tested is a control device for an automobile
  • the test object (SUT) is typically a prototype of this control device which is connected to an HIL simulator.
  • the HIL simulator and the executable test software will then provide one Test environment (TE).
  • TE Test environment
  • the exact configuration of the HIL simulator is relevant for the traceability and reproducibility of the tests (1) and is defined as a test environment (TE).
  • Changes to the hardware or software of the HIL simulator result in a new test environment (TE).
  • TE test environment
  • TC test case
  • SUT test object
  • TR results of the test (1) are stored and for the purpose of traceability with the test (1 ) connected.
  • This data is preferably stored in a database and managed by a test management tool with connection to the database.
  • a test management tool is the SYNECT software from dSPACE.
  • the depiction in FIG. 3 schematically shows the storage or storage of test cases (TC) and test objects (SUT) in a data storage system (3).
  • the data storage can be a file system, a database or another, known from the prior art, electronic data storage. It is also possible that in the data storage only representatives of the actual test cases (TC) or test objects (SUT) or references to the actual test cases (TC) or test objects (SUT) are stored. This is e.g. useful or even necessary if the test objects are not electronically available data but physically present objects (eg electronic devices). From the stored test cases (TC) and test objects (SUT) different tests (1) can then be generated by distribution to one or more test environments (TE).
  • TE test environments
  • FIG. 4 schematically shows the determination according to the invention of expected test results (TR).
  • TR expected test results
  • the former shows dashed rather than solid lines in the figures.
  • Rules (5) are used to calculate the test results (TR) and assigned probabilities. These rules (5) can be specified by the user or created automatically by evaluating existing databases.
  • An example of such a rule is that a test (1) comprising a test object (SUT) in a third version (V3) provides 99% of the same test result (TR) as a test (1) comprising the same test object (SUT) in a second version (V2) if test environment (TE) and test case (TC) are the same for both tests (1).
  • TR expected test results
  • the expected result of the test comprising version 2 (V2) of the test object (SUT) is calculated by means of a rule (5) from the present test result (TR) of the test (1) comprising version 1 (VI) of the test object (SUT) and the expected result of the test comprising version 3 (V3) of the test object (SUT) is calculated by means of a rule (5) from the expected test result (TR) of test (1) comprising version 2 (V2) of the test object (SUT).
  • the probability of the expected test result (TR) from the previous calculation is taken into account. An example of this is given if in the previous example to FIG.
  • the result (TR) of the test (1) comprising the test object (SUT) in version 2 (V2) is not present but in an analogous manner from an existing test result (TR ) of a test (1) comprising the test object (SUT) in version 1 (VI), with a probability of 99%.
  • the calculation of the test result (TR) for test (1) comprising the test object (SUT) in version 3 (V3) by means of the same rule (5) also results in the test result (TR) for the test (1) comprising the Test object (SUT) in version 3 (V3) 99% equal to the test result (TR) for test (1), comprising the test object (SUT) in version 2 (V2).
  • FIG. 6 shows tabular results (TR) of tests (1).
  • FIG. 5 shows by way of example a database stored in a data storage system (3).
  • the product maturity of version 3 of the test object (SUT) is shown in tabular form and analogously to the tables in FIG.
  • the individual fields of the table contain, according to the method of the invention, calculated expected results of the illustrated test (1), as well as the correspondingly calculated associated probabilities. It is readily apparent that the representation determined by means of the invention and shown in FIG. 7 gives a significantly better, because more complete, overview of the product maturity of the test object (SUT) in version 3 than the comparable representation in the lower third of FIG.
  • the fields of the table can also be displayed in color or in addition to the textual contents. Typically, green is used for tests (1) with the result passed and red for tests (1) with the result faiied. To represent the probabilities it is additionally possible to vary the hue or the color intensity of the green and red fields.
  • test objects SUT
  • the test environments TE1, TE2, TE3
  • the test cases could be HIL simulators with different software configurations , which different vehicle types represent.
  • the test cases TC1, TC2, TC3) could be, for example, the prevention of window closing (TC1), the emergency opening of the window in an accident (TC2), and the automatic closing of the window when the car is locked.
  • the product maturity resulting according to the invention, as shown in FIG. 7, can now be used for different conclusions, depending on the criterion of evaluation and status in development.
  • the lack of positive test results for the test case TC3 can lead to it being executed again or possibly after any improvement in the corresponding functionality. It could also be decided that the current development milestone (eg, safety-related tests with over 90% probability passed) has been achieved and the next stage of development is being addressed.
  • FIG. 8 schematically shows an automatic derivation of the rules (5), represented by the filled-in arrow, from a database, stored in a data storage system (3), comprising tests (1) and test results (TR). As shown in FIG. 2, the test results (TR) are assigned to tests (1).
  • the automatic derivation can be z. B. create one or more rules (5) from a common correlation.
  • test (1) comprising a specific combination of test case (TC) and test object (SUT) is associated with a result (TR) percentage more frequently than a predefined threshold and from this the rule (5) is derived it will be that other tests (1) comprising the same combination of test case (TC) and test object (SUT) with a probability equal to the threshold will have the same result (TR) as the previously determined tests (1).
  • At least partially or even fully autonomous vehicles have one or more sensors for collecting data, in particular data about the environment of the vehicle. Additionally, such vehicles typically have one or more interfaces to communicate with their environment. The figure Figure 9 illustrates this schematically. Typical sensors are radar, Lidar- or optical camera sensors, with which the environment is detected. The data exchange is usually realized via mobile radio standards (eg 4G or 5G). Furthermore, satellite-based systems (eg GPS) are frequently used for determining the position.
  • Level 0 stands for a system without assistance systems, in which all driving maneuvers, especially steering, acceleration and braking emanate only from the driver.
  • Level 1 is referred to as assisted driving, as either steering or acceleration and braking are done automatically at times.
  • Known systems are z.
  • ACC Adaptive Cruise Control
  • level 2 the system temporarily performs both steering, acceleration and braking tasks.
  • This level of automation is called semi-automated driving. In levels 1 and 2, the driver must be able to intervene at any time so that he can take full control of the vehicle again at any time.
  • High Automated Driving is Level 3.
  • the vehicle drives automatically and the driver merely represents a fallback position if the system can not cope with a traffic situation.
  • the system will in such cases prompt the driver to intervene and to perform driving maneuvers appropriate to the traffic situation.
  • This is the Driver given a finite but beyond the typical human reaction time period. Therefore, the driver can temporarily turn his attention away from the traffic.
  • levels 4 and 5 the automated system takes complete control and the driver no longer has to intervene. Whereby in Level 4 this may only apply in certain traffic situations (eg motorway driving), while at Level 5 the vehicle can cope with any traffic situation and thus practical driving without driver can be on the way.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Game Theory and Decision Science (AREA)
  • Artificial Intelligence (AREA)
  • Mathematical Optimization (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computational Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

Gemäß dem Gegenstand der Erfindung wird ein Verfahren zur Bestimmung einer Produktreife mittels Tests beansprucht, wobei ein Test die Ausführung eines Testfalls mittels einer Testumgebung angewendet auf ein Testobjekt umfasst, und für mindestens einen Test kein Ergebnis vorliegt, und das Verfahren die Schritte Vorgabe von Regeln zur Berechnung einer Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird, wobei die Regeln als Eingangsgrößen vorliegende oder erwartete Ergebnisse von Tests verwenden und als Ausgangsgrößen Wahrscheinlichkeiten zurückgeben und Berechnung der Wahrscheinlichkeit dass eine Test, für welchen kein Ergebnis vorliegt, erfolgreich sein wird, mittels mindestens eines Teils der vorgegebenen Regeln und Darstellung der Produktreife in Abhängigkeit der im vorherigen Schritt berechneten Wahrscheinlichkeiten umfasst.

Description

Produktreifebestimmung eines technischen Systems und insbesondere eines autonom fahrenden
Fahrzeugs
Die Erfindung betrifft ein Verfahren und ein Testsystem zur
Produktreifebestimmung eines technischen Systems gemäß dem Oberbegriff des Patentanspruchs 1.
Insbesondere im Bereich teilautonom oder autonom fahrender Fahrzeuge ergibt sich der Bedarf, Fahrzeuge, Teile von Fahrzeugen (z.B. elektronische Steuergeräte) und Fahrfunktionen (z. B. als Algorithmen der auf den
Steuergeräten ausgeführten Software) zu testen. Da diese Fahrfunktionen in großen Teilen als sicherheitskritisch zu bewerten sind, ist es erforderlich, ein ausreichend sicheres Kriterium für die Freigabe des nächsten
Entwicklungsschrittes zu definieren und zu überprüfen. Insbesondere nach Abschluss des letzten Entwicklungsschrittes, da dann die Serienproduktion des Fahrzeuges beginnt. Im Falle teilautonom oder autonom fahrender Fahrzeuge ist dies besonders schwierig, da die Anzahl aller möglichen zu testenden Szenarien durch die nie vollständig abbildbare Realität der Verkehrssituation quasi unendlich ist. Es muss also ein sinnvolles, in endlicher Zeit überprüfbares und ausreichend sicheres Kriterium für die Freigabe des nächsten Entwicklungsschrittes gefunden werden.
Aus dem Stand der Technik sind Verfahren zur Produktreifebestimmung bekannt, bei denen die Produktreife eines technischen Systems mittels Testabdeckung bestimmt wird. Unter Testabdeckung wird hierbei im
Allgemeinen das Verhältnis von ausgeführten Tests zur Gesamtzahl von, für das technische System ausführbaren, Tests oder das Verhältnis von erfolgreich ausgeführten Tests zur Gesamtzahl von, für das technische System ausführbaren, Tests verstanden. In der Veröffentlichung der europäischen Patentanmeldung EP3082000A1 wird die Produktreife mittels Testabdeckung ermittelt und es werden Vorschläge zur Verbesserung der Testabdeckung gemacht. Vor diesem Hintergrund besteht die Aufgabe der Erfindung darin, eine Vorrichtung anzugeben, die den Stand der Technik weiterbildet.
Die Aufgabe wird durch ein Verfahren zur Bestimmung einer Produktreife mit den Merkmalen des Patentanspruchs 1, sowie durch ein Testsystem mit den Merkmalen des Patentanspruchs 15 gelöst. Vorteilhafte
Ausgestaltungen der Erfindung sind Gegenstand von abhängigen
Unteransprüchen.
Gemäß dem Gegenstand der Erfindung wird ein Verfahren zur Bestimmung einer Produktreife mittels Tests beansprucht, wobei ein Test die Ausführung eines Testfalls mittels einer Testumgebung angewendet auf ein Testobjekt umfasst, und für mindestens einen Test kein Ergebnis vorliegt, und das Verfahren die Schritte, Vorgabe von Regeln zur Berechnung einer Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird, wobei die Regeln als Eingangsgrößen vorliegende oder erwartete Ergebnisse von Tests verwenden und als Ausgangsgrößen Wahrscheinlichkeiten zurückgeben, Berechnung der Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich sein wird, mittels mindestens eines Teils der vorgegebenen Regeln, sowie Darstellung der Produktreife in Abhängigkeit der im vorherigen Schritt berechneten Wahrscheinlichkeiten umfasst.
Ein Vorteil des erfindungsgemäßen Verfahrens ist es, dass die Produktreife eines technischen Systems nicht nur anhand schon ausgeführter Tests bewertet wird, sondern auch noch nicht ausgeführte Tests bei der Bewertung berücksichtigt werden. Für den Fall, dass nicht alle Tests ausgeführt werden, ergibt sich hierdurch insgesamt ein vollständigeres Bild der Produktreife, andernfalls erhält man zu einem früheren Zeitpunkt aussagekräftigere Aussagen zur Produktreife, da auch die noch in der Zukunft liegenden Tests in die Bewertung mit einfließen. Des Weiteren kann auf der Grundlange dieser in die Zukunft schauenden Betrachtung eine verbesserte Auswahl der noch auszuführenden Tests und ihrer Reihenfolge getroffen werden. Weiter ist es vorteilhaft, dass mittels des Verfahrens leichter einfach zugängliche aber aussagekräftige Darstellungen der Produktreife gefunden und dargestellt werden können. Aussagen zur Produktreife können einfach nach den vorliegenden Kriterien, wie z. B. den vorliegenden Testfällen, Testumgebungen oder Testobjekten zusammengefasst bzw. gruppiert werden. In einer Ausführungsform ist ein Testobjekt (SUT) ein zumindest teilweise autonom fahrendes Fahrzeug, ein Teil eines zumindest teilweise autonom fahrenden Fahrzeugs oder eine Funktionalität eines zumindest teilweise autonom fahrenden Fahrzeugs, und ist ein Testfall (TC) ein Fahrmanöver des zumindest teilweise autonom fahrenden Fahrzeugs, ein Fahrmanöver mit dem Teil des zumindest teilweise autonom fahrenden Fahrzeugs oder ein Fahrmanöver, bei welchem die Funktionalität eines zumindest teilweise autonom fahrenden Fahrzeugs berücksichtigt wird, und ist eine Testumgebung (TE) eine, insbesondere auch virtuelle, Umgebung des zumindest teilweise autonom fahrenden Fahrzeugs oder eines Fahrzeugs umfassend den Teil des zumindest teilweise autonom fahrenden Fahrzeugs oder die Funktionalität eines zumindest teilweise autonom fahrenden Fahrzeugs. In einer anderen Ausführungsform liegt ein Testfall oder eine Testumgebung oder ein Testobjekt in einer ersten und einer zweiten Version vor, wobei die zweite Version einen Entwicklungsstand des Testfalls oder der Testumgebung oder des Testobjektes repräsentiert, der zeitlich nach dem Entwicklungsstand der ersten Version des Testfalls oder der Testumgebung oder des Testobjektes liegt.
In einer Weiterbildung der zuvor beschriebenen Ausführungsform wird mittels der Regeln oder zusätzlich zu den Regeln vorgegeben ein Teil der vorliegenden und erwarteten Ergebnisse der Tests nicht bei Berechnung der Wahrscheinlichkeit, dass ein Test erfolgreich oder nicht erfolgreich sein wird, zu berücksichtigen, wobei der Teil nicht zu berücksichtigender Ergebnisse von einer oder mehrerer Versionen mindestens eines Testfalls, mindestens einer Testumgebung und/oder mindestens eines Testobjektes abhängt, wobei der mindestens eine Testfall, die mindestens eine Testumgebung und/oder das mindestens eine Testobjekt von dem Test umfasst wird. In einer weiteren Ausführungsform repräsentieren die vorgegebenen Regeln einen technischen oder statistischen Zusammenhang zwischen einem ersten Testfall, einer ersten Testumgebung oder einem ersten Testobjekt in der ersten oder zweiten Version und einem zweiten Testfall, einer zweiten Testumgebung oder einem zweiten Testobjekt in der ersten oder zweiten Version.
In einer anderen Ausführungsform kann das Ergebnis eines Tests mindestens die Werte „Test erfolgreich" (passed) und „Test fehlgeschlagen" (failed) annehmen. In einer weiteren anderen Ausführungsform werden die vorgegebenen Regeln automatisch mittels Analyse eines Datenbestandes zumindest eines Teils der Tests, umfassend Testfälle, Testumgebungen, Testobjekte und Ergebnisse, erstellt und/oder verifiziert.
In einer Weiterbildung der vorherigen Ausführungsform umfasst die Analyse eine statische Auswertung von Zusammenhängen von Tests, insbesondere Zusammenhänge von Tests mit positiven Ergebnissen.
In einer Ausführungsform wird vor dem Verfahrensschritt der Berechnung der Wahrscheinlichkeit eine erste Gruppe von Tests mittels einer statistischen Verteilung ermittelt, wobei für die erste Gruppe von Tests Ergebnisse vorliegen oder erzeugt werden.
In einer Weiterbildung der vorherigen Ausführungsform basiert die Ermittlung der Tests der ersten Gruppe von Tests auf einer oder mehr weiteren statischen Verteilungen der Testfälle, der Testumgebungen und/oder der Testobjekte. In einer anderen Weiterbildung der vorherigen Ausführungsformen sind die statische Verteilung und/oder eine oder mehr der weiteren statischen Verteilungen zufällige Verteilungen.
In einer alternativen Weiterbildung der vorherigen Ausführungsformen hängt die Berechnung der Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich sein wird, von der statischen Verteilung der Tests, der Testfälle, der Testumgebungen und/oder der Testobjekte ab.
In einer weiteren Ausführungsform erfolgt die Darstellung der Produktreife in Form einer nummerischen, insbesondere prozentualen, Testabdeckung oder in Form einer, insbesondere farbkodierten Grafik.
In einer alternativen Ausführungsform werden ein oder mehr Kriterien vorgegeben und ein Teil der Tests, für welchen im zweiten Verfahrensschritt eine Wahrscheinlichkeit, dass der Test erfolgreich oder nicht erfolgreich sein wird, berechnet wurde, werden ausgeführt oder zur Ausführung vorgeschlagen, wobei die auszuführenden oder zur Ausführung vorgeschlagenen Tests mindestens eines der vorgegebenen Kriterien erfüllen.
In einer anderen Ausführungsform ist mindestens eines der vorgegebenen Kriterien die Über- oder Unterschreitung eines Schwellwertes für die Wahrscheinlichkeit, dass der Test erfolgreich oder nicht erfolgreich sein wird . In einer weiteren Ausführungsform ist einem Testfall (TC), einer Testumgebung (TE), einem Testobjekt (SUT) oder einer Kombination von mindestens zwei Elementen aus Testfall (TC), Testumgebung (TE) und Testobjekt (SUT) eine Gewichtung zugeordnet und die Gewichtung wird bei Berechnung der Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird, im zweiten Schritt und/oder bei der Darstellung der Produktreife im letzten Schritt berücksichtigt.
In einer alternativen Ausführungsform wird ein Schwellwert der Produktreife festgelegt und bei Überschreitung des Schwellwertes der Produktreife, das Testobjekt (SUT) für einen weiteren Entwicklungsschritt freigegeben.
In eine Weiterbildung der vorherigen Ausführungsform wird das Testobjekt einer Klasse von Testobjekten (SUT), insbesondere mittels eines Levels des Automatisierungsgrades, zugeordnet und der Schwellwert der Produktreife in Abhängigkeit der zugeordneten Klasse festgelegt. Ebenfalls gelöst wird die Aufgabe durch ein Testsystem zum Testen eines technischen Systems, wobei das Testsystem eines der zuvor beschriebenen Verfahren ausführt.
Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnungen näher erläutert. Hierbei werden gleichartige Teile mit identischen
Bezeichnungen beschriftet. Darin zeigt:
Figur 1 schematisch die Zusammensetzung eines Tests (1) aus
Testumgebung (TE), Testfall (TC) und Testobjekt (SUT),
Figur 2 schematisch die Zusammenhänge zwischen Test (1),
Testumgebung (TE), Testfall (TC), Testobjekt (SUT) und Ergebnis des Tests (TR),
Figur 3 schematisch die Ablagen bzw. Speicherung von
Testfällen (TC) und Testobjekten (SUT) und die
Ableitung unterschiedlicher Tests (1) hieraus,
Figur 4 schematisch die Vorhersage von Ergebnissen (TR)
nicht ausgeführter Tests (1) mittels Regeln (5),
Figur 5 schematisch die Vorhersage von Ergebnissen (TR)
nicht ausgeführter Tests (1) mittels Regeln (5),
Figur 6 eine tabellarische Darstellung von Ergebnissen von Tests
(1) bezogen auf unterschiedliche Versionen eines
Testobjektes (SUT),
Figur 7 eine tabellarische Darstellung von vorhergesagten
Ergebnissen von Test (1), schematisch die Ableitung von Regeln (5) aus den in einer Datenablage (3) abgelegten bzw. abgespeicherten Tests (1) und Ergebnissen von Tests (TR). schematische Darstellung eines zumindest teilweise autonom fahrenden Fahrzeugs. schematische Darstellung eine Klasseneinteilung in Level unterschiedlichen Automatisierungsgrades bei zumindest teilweise autonom fahrenden Fahrzeugen.
In der Abbildung der Figur 1 ist schematisch die Zusammensetzung eines Tests (1) dargestellt. Ein Test (1) umfasst dabei mindestens eine Testumgebung (TE) aus einer möglichen Mehrzahl von Testumgebungen (TE), einen Testfall (TC) aus einer möglichen Mehrzahl von Testfällen (TC) und ein Testobjekt (engl .„System under test") (SUT) aus einer möglichen Mehrzahl von Testobjekten (SUT).
Ziel der Reifebestimmung eines technischen Systems ist es, Produkteigenschaften wie Performanz, Zuverlässigkeit oder Benutzerfreundlichkeit zu bewerten. Hieraus ergibt sich, ob eine nächste Stufe, ein sogenannter Meilenstein, in der Entwicklung des technischen Systems erreicht ist. Der in den meisten Fällen letzte Meilenstein ist die Freigabe des Produktes zum Verkauf bzw. die Auslieferung des Produktes. Ein Bereich, in dem die Produktreife vor allem in Bezug auf Zuverlässigkeit und Sicherheit eine große Rolle spielt, ist der Automobilsektor und hierbei auch die Entwicklung von Steuergeräten (engl,„electronic control unit", ECU). Die Testobjekte (SUT) können also Steuergeräte, die auf den Steuergeräten auszuführende Software oder Teil dieser Software sein. Die Auswahl der Testfälle (TC) hängt dabei unter anderem von der zu testenden Funktionalität und den zu erreichenden Zielen an Sicherheit und Zuverlässigkeit ab. In der Automobilbranche haben sich sogenannte „Hardware-in-the-loop"-Tests (HIL- Tests) für die Absicherung real vorliegender Steuergeräte etabliert. Mit entsprechenden Testwerkzeugen lassen sich auf den HIL-Testumgebungen (meist spezielle echtzeitfähige Rechner) Testfälle (TC) entwickeln und ausführen. Ein Beispiel für ein solches Testwerkzeug ist der Software- Produkt AutomationDesk der Firma dSPACE. Beim Testen von Steuergerätesoftware kommen auch Simulationsumgebungen, sogenannte Offline-Simulatoren zum Einsatz, welche zum Teil auf handelsüblichen PCs ausgeführt werden können. Von den hier beispielhaft dargestellten Testumgebungen (TE), HIL- und Offline-Simulator, können auch mehrere gleichartige oder verschiedene zum Testen eingesetzt werden. Hierdurch können für die Testfälle (TC) evtl. unterschiedliche Testumgebungen (TE) genutzt werden.
In der Abbildung der Figur 2 sind schematisch Zusammenhänge zwischen Test (1), Testumgebung (TE), Testobjekt (SUT) und Ergebnis (TR) eines Tests (1) dargestellt. Bei der Ausführung eines Tests (1) werden Daten erhoben, welche, zumindest teilweise, ein Ergebnis (TR) des Tests (1) darstellen oder aus welchen sich ein Ergebnis (TR) des Tests (1) ableiten lässt. Typischerweise wird ein Testfall (TC) innerhalb oder mittels einer Testumgebung (TE) zum Testen eines Testobjektes (SUT) ausgeführt (engl. „executed"). Bei oder nach dieser Ausführung werden Ergebnisse (TR) der Ausführung des Tests (1), auch Testergebnisse (TR) genannt, z. B. durch schreiben einer Datei (engl,„write") festgehalten. Diese Ergebnisse (TR) sind bzw. werden dem Test (1) zugeordnet, um bei der späteren Auswertung der Testergebnisse (TR) die Bedingungen der entsprechenden Testausführung nachvollziehen zu können. Typische Ergebnisse (TR) von Tests (1) sind„Test erfolgreich" (engl,„passed") und„Test fehlgeschlagen" (engl,„failed"). Da die Verwendung der Englischen Begriffe„passed" und„failed" im Umfeld des Testens und der Testverwaltung allgemein gebräuchlicher sind, werden diese auch im Folgenden verwendet. Ist zum Beispiel das zu testende technische System ein Steuergerät für ein Automobil, ist das Testobjekt (SUT) typischerweise ein Prototyp dieses Steuergerätes, welches mit einem HIL-Simulator verbunden ist. Der HIL- Simulator und die auf diesem ausführbare Testsoftware stellen dann eine Testumgebung (TE) dar. Dabei ist für die Nachvollziehbarkeit und Reproduzierbarkeit der Tests (1) die genaue Konfiguration des HIL-Simulator relevant und wird als eine Testumgebung (TE) definiert. Bei Änderungen an der Hard- oder Software des HIL-Simulators ergibt sich eine neue Testumgebung (TE). Nach der Ausführung des Tests (1), umfassend die Testumgebung (TE), den Testfall (TC) und das Testobjekt (SUT), werden die Ergebnisse (TR) des Tests (1) gespeichert und zum Zweck der NachVerfolgbarkeit mit dem Test (1) verknüpft. Diese Daten werden bevorzugt in einer Datenbank abgespeichert und von einem Testmanagement-Werkzeugt mit Anbindung an die Datenbank verwaltet. Ein Beispiel für ein solches Testmanagement-Werkzeug ist die Software SYNECT der Firma dSPACE.
In der Abbildung der Figur 3 ist schematisch die Ablage bzw. Speicherung von Testfällen (TC) und Testobjekten (SUT) in einer Datenhaltung (3) dargestellt. Die Datenhaltung kann dabei ein Dateisystem, eine Datenbank oder eine andere, aus dem Stand der Technik bekannte, elektronische Datenhaltung sein. Ebenfalls ist es möglich, dass in der Datenhaltung lediglich Repräsentanten der eigentlichen Testfälle (TC) bzw. Testobjekte (SUT) oder Referenzen auf die eigentlichen Testfälle (TC) bzw. Testobjekte (SUT) abgelegt sind . Dies ist z.B. sinnvoll oder sogar notwendig, wenn die Testobjekte keine elektronisch vorliegenden Daten, sondern physikalisch vorliegende Objekte (z. B. elektronische Geräte) sind. Aus den abgelegten Testfällen (TC) und Testobjekten (SUT) können dann durch Verteilung auf ein oder mehrere Testumgebungen (TE) unterschiedliche Tests (1) erzeugt werden.
In der Abbildung der Figur 4 ist schematisch die erfindungsgemäße Bestimmung zu erwartender Testergebnisse (TR) dargestellt. Zur Unterscheidung der zu erwartenden Testergebnisse (TR) von den vorliegenden Testergebnissen (TR) sind in den Abbildungen erstere mit gestrichelten statt durchgezogenen Linien dargestellt. Zur Berechnung der Testergebnisse (TR) und zugeordneter Wahrscheinlichkeiten werden Regeln (5) verwendet. Diese Regeln (5) können vom Nutzer vorgegeben oder durch Auswertung von bestehenden Datenbeständen automatische erstellt werden. Ein Beispiel für eine solche Regel ist, dass ein Test (1), umfassend ein Testobjekt (SUT) in einer dritten Version (V3), zu 99% das gleiche Testergebnis (TR) liefert, wie ein Test (1), umfassend dasselbe Testobjekt (SUT) in einer zweiten Version (V2), wenn Testumgebung (TE) und Testfall (TC) bei beiden Tests (1) gleich sind.
In der Abbildung der Figur 5 ist schematisch ebenfalls die erfindungsgemäße Bestimmung zu erwartender Testergebnisse (TR) dargestellt. Die zuvor beschriebene Berechnung eines Testergebnisses (TR) kann auch von einem zuvor berechneten statt von einem vorliegenden Testergebnis (TR) mittels einer Regel (5) abgeleitet werden. Dieser Fall ist in Figur 5 dargestellt, wobei sich die dargestellten Tests (1) nur in der Version (VI, V2, V3) des Testobjektes (SUT) unterscheiden. Das erwartete Ergebnis des Tests umfassend die Version 2 (V2) des Testobjektes (SUT) wird mittels einer Regel (5) aus dem vorliegenden Testergebnis (TR) des Tests (1) umfassend die Version 1 (VI) des Testobjektes (SUT) berechnet und das erwartete Ergebnis des Tests umfassend die Version 3 (V3) des Testobjektes (SUT) wird mittels einer Regel (5) aus dem erwarteten Testergebnis (TR) des Tests (1) umfassend die Version 2 (V2) des Testobjektes (SUT) berechnet. Dabei wird in der zweiten Berechnung die Wahrscheinlichkeit des erwarteten Testergebnisses (TR) aus der vorherigen Berechnung berücksichtigt. Ein Beispiel hierfür ist gegeben, wenn in dem vorherigen Beispiel zu Figur 4 das Ergebnis (TR) des Tests (1), umfassend des Testobjekt (SUT) in Version 2 (V2) nicht vorliegt, sondern in analoger Weise aus einem vorliegenden Testergebnis (TR) eines Tests (1), umfassend des Testobjekt (SUT) in Version 1 (VI), mit einer Wahrscheinlichkeit von 99% berechnet wird . Die Berechnung des Testergebnisses (TR) zum Test (1), umfassend des Testobjekt (SUT) in Version 3 (V3) mittels der gleichen Regel (5) führt ebenfalls dazu, dass das Testergebnis (TR) zum Test (1), umfassend das Testobjekt (SUT) in Version 3 (V3) zu 99% gleich dem Testergebnis (TR) zum Test (1), umfassend des Testobjekt (SUT) in Version 2 (V2). Insgesamt ergibt sich dann 98,01% (=(99/100)*(99/100)*100) für die Wahrscheinlichkeit, dass das Testergebnis (TR) zum Test (1), umfassend das Testobjekt (SUT) in Version 3 (V3) gleich ist wie das Testergebnis (TR) zum Test (1), umfassend das Testobjekt (SUT) in Version 1 (VI). Alternativ zu den unterschiedlichen Versionen (VI, V2, V3), sind auch andere Variationen der Testfälle (TC), Testumgebungen (TE) oder Testobjekte (SUT), wie z.B. Varianten oder unterschiedliche Elemente einer zusammengehörigen Gruppe, möglich. In der Abbildung der Figur 6 sind tabellarisch vorliegende Ergebnisse (TR) von Tests (1) dargestellt. Dabei liegen unterschiedliche Testumgebungen (TE1, TE2, TE3), unterschiedliche Testfälle (TC1, TC2, TC3) und ein Testobjekt (SUT) in unterschiedlichen, aufeinanderfolgenden Versionen (Versionl, Version2, Version3) vor. Die leeren Felder der Tabellen repräsentieren Tests (1), für welche kein Ergebnis (TR) vorliegt. Damit stellt Figur 5 beispielhaft einen in einer Datenhaltung (3) abgelegten Datenbestand dar.
In der Abbildung der Figur 7 ist tabellarisch und in Analogie zu den Tabellen in Figur 5 die Produktereife der Version 3 des Testobjektes (SUT) dargestellt. Die einzelnen Felder der Tabelle enthalten nach dem erfindungsgemäßen Verfahren berechnete erwartete Ergebnisse der dargestellten Test (1), sowie die entsprechend berechneten zugehörigen Wahrscheinlichkeiten. Es ist ohne weiteres erkennbar, dass die mittels der Erfindung bestimmte und in Figur 7 gezeigte Darstellung einen deutlich besseren, weil vollständigeren Überblick über die Produktreife des Testobjektes (SUT) in der Version 3 gibt, als die vergleichbare Darstellung im unteren Drittel der Figur 6. Zur weiter verbesserten schnellen Lesbarkeit können die Felder der Tabelle zusätzlich oder alternativ zu den textuellen Inhalten auch farbig dargestellt werden. Typischer Weise wird hierbei grün für Tests (1) mit dem Ergebnis passed und rot für Tests (1) mit dem Ergebnis faiied verwendet. Zur Darstellung der Wahrscheinlichkeiten ist es zusätzlich möglich den Farbton bzw. die Farbintensität der grünen und roten Felder zu variieren.
Unter der Annahme, dass das Testobjekt (SUT) ein Steuergeräte- Prototyp eines Steuergerätes für eine Automobil ist, welche für die Steuerung der Funktion des elektrischen Fensterhebers zuständig ist, könnten die Testumgebungen (TE1, TE2, TE3) HIL-Simulatoren mit unterschiedlichen Softwarekonfigurationen sein, welche unterschiedliche Fahrzeugtypen repräsentieren. Die Testfälle (TC1, TC2, TC3) könnten beispielhaft das Verhindern des Einklemmens bei sich schließendem Fenster (TC1), das Notfallöffnen des Fensters bei einem Unfall (TC2) und das automatische Schließen des Fensters beim Abschließen des Autos sein. Die sich erfindungsgemäß ergebende Produktreife, wie in Figur 7 dargestellt, kann nun je nach Bewertungsmaßstab und Status in der Entwicklung zu verschiedenen Schlüssen genutzt werden. Zum einen kann das Fehlen von positiven Testergebnissen zum Testfall TC3 dazu führen, dass dieser, nach evtl. Verbesserung der entsprechenden Funktionalität erneut bzw. überhaupt ausgeführt werden soll. Es könnte auch beschlossen werden, dass der aktuelle Meilenstein in der Entwicklung (z. B. sicherheitsrelevante Tests mit über 90% Wahrscheinlichkeit passed) erreicht wurde und die nächste Stufe der Entwicklung angegangen wird .
Ebenfalls können aus der erfindungsgemäß bestimmten Produktreife, wie in Figur 7 dargestellt, weitere Informationen gewonnen bzw. diese weiter verdichtete werden. Zum Beispiel kann geschlussfolgert werden, dass weniger als vier Tests (1) mit einer Wahrscheinlichkeit von über 90% als passed bewertet werden.
In der Abbildung der Figur 8 ist schematisch eine automatische Ableitung der Regeln (5), dargestellt durch den ausgefüllten Pfeil, aus einem, in einer Datenhaltung (3) gespeicherten, Datenbestand, umfassend Tests (1) und Testergebnisse (TR), dargestellt. Wie in Figur 2 dargestellt sind die Testergebnisse (TR) dabei Tests (1) zugeordnet. Die automatische Ableitung kann dabei z. B. aus einer häufig vorliegenden Korrelation eine oder mehr Regeln (5) erstellen. Ein mögliches Beispiel ist hier, dass ein Test (1), umfassend einen bestimmte Kombination von Testfall (TC) und Testobjekt (SUT), prozentual häufiger als eine vorgegebene Schwelle mit einem Ergebnis (TR) verknüpft ist und hieraus die Regel (5) abgeleitet wird, dass andere Tests (1), umfassend die gleiche Kombination von Testfall (TC) und Testobjekt (SUT), mit einer der Schwelle entsprechenden Wahrscheinlichkeit das gleich Ergebnis (TR) haben wird, wie die zuvor ermittelten Tests (1). Zumindest teilweise oder sogar vollständig autonom fahrende Fahrzeugen verfügen über ein oder mehrere Sensoren zur Erfassung von Daten, insbesondere Daten über die Umgebung des Fahrzeugens. Außerdem haben solche Fahrzeuge typischerweise ein oder mehr Schnittstellen zu Datenaustausch mit ihrer Umgebung . Die Abbildung Figur 9 stellt dies schematisch dar. Typische Sensoren sind hier Radar-, Lidar- oder optische Kamera-Sensoren, mit welchen die Umgebung erfasst wird . Der Datenaustausch wird in der Regel über mobile Funkstandards (z.B. 4G oder 5G) realisiert. Weiter kommen zur Positionsbestimmung häufig satellitengestützte System (z. B. GPS) zum Einsatz.
Im Bereich der Fahrerassistenz-Systeme bzw. als deren Weiterentwicklung des hochautomatisierten oder sogar autonomen Fahrens werden typischerweise unterschiedliche Stufen oder Level des Automatisierungsgrades definiert. Diese sind in Abbildung Figur 10 dargestellt. Hierbei steht Level 0 für ein System ohne Assistenzsysteme, bei dem alle Fahrmanöver, insbesondere Lenken, Beschleunigen und Bremsen nur vom Fahrer ausgehen. Bei Level 1 spricht man vom assistierten Fahren, da hier entweder Lenken oder Beschleunigen und Bremsen zeitweise automatisch erfolgen. Bekannte Systeme sind z. B. Tempomaten bzw. System zur automatischen Abstandsregulierung (engl. Adaptive Cruise Control ACC). Bei Level 2 übernimmt das System zeitweise sowohl Lenk- als auch Beschleunigungs- und Bremsaufgaben. Man spricht bei diesem Grad der Automatisierung von teilautomatisiertem Fahren. In den Leveln 1 und 2 muss der Fahrer jederzeit eingreifen können, so dass er jederzeit wieder die volle Kontrolle über das Fahrzeug übernehmen kann. Damit übernimmt das System zwar zeitweise Teile der Fahraufgaben, der Fahrer muss aber das Verkehrsgeschehen jederzeit verfolgen und, im Rahmen seiner natürlichen Reaktionszeit, eingreifen können. Als Hochautomatisiertes Fahren (HAF) (engl, highly automated driving HAD) bezeichnet man Level 3. Hierbei fährt das Fahrzeug automatisch und der Fahrer stellt lediglich eine Rückfallposition dar, falls das System mit einer Verkehrssituation nicht zurechtkommt. Das System wird in solchen Fällen den Fahrer auffordern einzugreifen und ein, der Verkehrssituation angemessene, Fahrmanöver auszuführen. Hierzu wird dem Fahrer eine endliche, aber über die typische menschliche Reaktionszeit hinausgehende Zeitspanne gegeben. Daher kann der Fahrer seine Aufmerksamkeit zeitweise vom Straßenverkehr abwenden. In den Leveln 4 und 5 übernimmt das automatisierte System die vollständige Kontrolle und der Fahrer muss nicht mehr eingreifen. Wobei in Level 4 dies ggf. nur in bestimmten Verkehrssituationen (z.B. Autobahnfahrten) gilt, während bei Level 5 das Fahrzeug jede Verkehrssituation bewältigen und damit praktische auch Fahrerlos unterwegs sein kann.
Diese unterschiedlichen Stufen der Automatisierung erfordern verschiedengroße Sicherheit beim Absichern bzw. Testen der entsprechenden automatisierten Fahrfunktionen. Entsprechend ihres Risikos kann somit die Produktfreigabe oder auch nur der nächste Schritt im Entwicklungsprozess bei unterschiedlicher Sicherheit bezügliche der Produktreife erfolgen. Ein Level 3 System muss vielleicht nur mit einer Wahrscheinlichkeit von 99% keine Fehler aufweisen, da der Fahrer als Rückfallposition zur Verfügung steht, während Systeme der Level 4 oder 5 mit 99,9% Wahrscheinlichkeit keine Fehler aufweisen dürfen. Das Erreichen diesen unterschiedlichen Schwellwerte kann mit dem erfindungsgemäßen Verfahren zur Produktreifebestimmung ermittelt bzw. überprüft werden. Da die Produktreife sich aus den vorhandenen Testergebnissen (TR) bestimmt, ist die Verteilung der vorhandenen Testergebnisse (TR) für die Qualität der berechneten Produktreife mit ausschlaggebende. Wurden zum Beispiel alle vorliegenden Testergebnisse (TR) mit nur einer Testumgebung (TE) erzeugt, ist die Qualität der Aussagen über Testergebnissen (TR) auf anderen Testumgebungen (TE) wahrscheinlich wenig aussagekräftigt. Um eine möglichst aussagekräftige Produktreife zu erhalten, kann es daher von Vorteil sein, die vorliegenden Testergebnisse (TR) anhand einer vorgebbaren Verteilung von zuvor auszuführenden Tests (1) zu erzeugen. Diese Verteilung kann z. B. eine Zufallsverteilung sein. Das Wissen um die Art der Verteilung der vorhandenen Testergebnisse (TR), kann dann auch zusätzlich bei der Bewertung der Produktreife verwendet werden.

Claims

Patentansprüche:
1. Verfahren zur Bestimmung einer Produktreife mittels Tests,
wobei ein Test die Ausführung eines Testfalls (TC) mittels einer Testumgebung (TE) angewendet auf ein Testobjekt (SUT) umfasst, und für mindestens einen Test kein Ergebnis (TR) vorliegt, und
das Verfahren folgende Schritte umfasst:
a) Vorgabe von Regeln zur Berechnung einer Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird,
wobei die Regeln als Eingangsgrößen vorliegende oder erwartete Ergebnisse von Tests verwenden und als Ausgangsgrößen Wahrscheinlichkeiten zurückgeben,
b) Berechnung der Wahrscheinlichkeit dass eine Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird, mittels mindestens eines Teils der vorgegebenen Regeln, und c) Darstellung der Produktreife in Abhängigkeit der im vorherigen Schritt berechneten Wahrscheinlichkeiten. 2. Verfahren zur Bestimmung einer Produktreife mittels Tests,
wobei ein Test die Ausführung eines Testfalls (TC) mittels einer Testumgebung (TE) angewendet auf ein Testobjekt (SUT) umfasst, und für mindestens einen Test kein Ergebnis (TR) vorliegt,
ein Testobjekt (SUT) ein zumindest teilweise autonom fahrenden Fahrzeugs, ein Teils eines zumindest teilweise autonom fahrenden
Fahrzeugs oder eine Funktionalität eines zumindest teilweise autonom fahrenden Fahrzeugs ist,
ein Testfall (TC) ein Fahrmanöver des zumindest teilweise autonom fahrenden Fahrzeugs, ein Fahrmanöver mit dem Teil des zumindest teilweise autonom fahrenden Fahrzeugs oder ein Fahrmanöver, bei welchem die Funktionalität eines zumindest teilweise autonom fahrenden Fahrzeugs berücksichtigt wird, ist, eine Testumgebung (TE) eine, insbesondere auch virtuelle, Umgebung des zumindest teilweise autonom fahrenden Fahrzeugs oder eines Fahrzeugs umfassend den Teil des zumindest teilweise autonom fahrenden Fahrzeugs oder die Funktionalität eines zumindest teilweise autonom fahrenden Fahrzeugs, ist und
das Verfahren folgende Schritte umfasst:
d) Vorgabe von Regeln zur Berechnung einer Wahrscheinlichkeit, dass ein Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird,
wobei die Regeln als Eingangsgrößen vorliegende oder erwartete Ergebnisse von Tests verwenden und als Ausgangsgrößen Wahrscheinlichkeiten zurückgeben,
e) Berechnung der Wahrscheinlichkeit dass eine Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird, mittels mindestens eines Teils der vorgegebenen Regeln, und f) Darstellung der Produktreife in Abhängigkeit der im vorherigen Schritt berechneten Wahrscheinlichkeiten.
Verfahren nach Anspruch 1 oder 2, wobei
ein Testfall (TC) oder eine Testumgebung (TE) oder ein Testobjekt (SUT) in einer ersten und einer zweiten Version vorliegt,
wobei die zweite Version einen Entwicklungsstand des Testfalls (TC) oder der Testumgebung (TE) oder des Testobjektes (SUT) repräsentiert, der zeitlich nach dem Entwicklungsstand des Testfalls (TC) oder der Testumgebung (TE) oder des Testobjektes (SUT) liegt.
Verfahren nach Anspruch 3, wobei
mittels der Regeln oder zusätzlich zu den Regeln vorgegeben wird einen Teil der vorliegenden und erwarteten Ergebnisse der Test nicht bei Berechnung der Wahrscheinlichkeit, dass ein Test erfolgreich oder nicht erfolgreich sein wird, zu berücksichtigen, wobei der Teil nicht zu berücksichtigender Ergebnisse von einer oder mehrerer Versionen mindestens eines Testfalls (TC), mindestens einer Testumgebung (TE) und/oder mindestens eines Testobjektes (SUT) abhängt, wobei der mindestens eine Testfall (TC), die mindestens eine Testumgebung (TE) und/oder das mindestens eine Testobjekte (SUT) von dem Test umfasst wird .
5. Verfahren nach einem der vorherigen Ansprüche, wobei
die vorgegebenen Regeln einen technischen oder statistischen Zusammenhang zwischen mindestens einem ersten Testfall (TC), einer ersten Testumgebung (TE) oder eines ersten Testobjektes (SUT) in der ersten oder zweiten Version und mindestens einem zweiten Testfall (TC), einer zweiten Testumgebung (TE) oder eines zweiten Testobjektes (SUT) in der ersten oder zweiten Version repräsentieren.
6. Verfahren nach einem der vorherigen Ansprüche, wobei
das Ergebnis eines Tests mindestens die Werte „Test erfolgreich" (passed) und„Test fehlgeschlagen" (failed) annehmen kann.
7. Verfahren nach einem der vorherigen Ansprüche, wobei
die vorgegebenen Regeln automatisch mittels Analyse eines Datenbestandes zumindest eines Teils der Tests, umfassend Testfälle (TC), Testumgebungen (TE), Testobjekte (SUT) und Ergebnisse, erstellt und/oder verifiziert werden.
8. Verfahren nach Anspruch 7, wobei
die Analyse eine statische Auswertung von Zusammenhängen von Tests, insbesondere Zusammenhänge von Tests mit positiven Ergebnissen, umfasst.
9. Verfahren nach einem der vorherigen Ansprüche, wobei
vor dem Verfahrensschritt b) eine erste Gruppe von Tests mittels einer statistischen Verteilung ermittelt wurde und für die erste Gruppe von
Tests Ergebnisse vorliegen oder erzeugt werden.
10. Verfahren nach Anspruch 9, wobei die Ermittlung der Tests der ersten Gruppe von Tests auf einer oder mehr weiteren statischen Verteilungen der Testfälle (TC), der Testumgebungen (TE) und/oder der Testobjekte (SUT) basiert.
11. Verfahren nach Anspruch 9 oder 10, wobei
die statische Verteilung und/oder eine oder mehr der weiteren statischen Verteilungen zufällige Verteilung sind.
12. Verfahren nach einem der Ansprüche 9 bis 11, wobei
die Berechnung der Wahrscheinlichkeit dass ein Test, für welchen kein
Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird, von der statischen Verteilung der Tests, der Testfälle (TC), der Testumgebungen (TE) und/oder der Testobjekte (SUT) abhängt.
13. Verfahren nach einem der vorherigen Ansprüche, wobei
die Darstellung der der Produktreife in Form einer nummerischen, insbesondere prozentualen, Testabdeckung oder in Form einer, insbesondere farbkodierten Grafik erfolgt.
14. Verfahren nach einem der vorherigen Ansprüche, wobei
ein oder mehr Kriterien vorgegeben werden und ein Teil der Test für welchen in Verfahrensschritt b) eine Wahrscheinlichkeit, dass der Test erfolgreich oder nicht erfolgreich sein wird, berechnet wurde ausgeführt oder zur Ausführung vorgeschlagen werden, wobei die auszuführenden oder zur Ausführung vorgeschlagenen Tests mindestens eines der vorgegebenen Kriterien erfüllen.
15. Verfahren nach Anspruch 14, wobei
mindestens eines der vorgegebenen Kriterien die Über- oder Unterschreitung eines Schwellwertes für die Wahrscheinlichkeit, dass der
Test erfolgreich oder nicht erfolgreich sein wird, ist.
16. Verfahren nach einem der vorherigen Ansprüche, wobei einem Testfall (TC), einer Testumgebung (TE), einem Testobjekt (SUT) oder einer Kombination von mindestens zwei Elementen aus Testfall (TC), Testumgebung (TE) und Testobjekt (SUT) eine Gewichtung zugeordnet ist und die Gewichtung bei Berechnung der Wahrscheinlichkeit dass eine Test, für welchen kein Ergebnis vorliegt, erfolgreich oder nicht erfolgreich sein wird in Schritt b) und/oder der Darstellung der Produktreife in Schritte c) berücksichtigt wird .
17. Verfahren nach einem der vorherigen Ansprüche, wobei
ein Schwellwert der Produktreife festgelegt ist und bei Überschreitung des
Schwellwertes der Produktreife, das Testobjekt (SUT) für einen weiteren Entwicklungsschritt freigegen wird .
18. Verfahren nach Anspruch 17, wobei
das Testobjekt einer Klasse von Testobjekten (SUT), insbesondere mittels eines Level des Automatisierungsgrades, zugeordnet wird und der Schwellwert der Produktreife in Abhängigkeit der zugeordneten Klasse festgelegt wird .
19. Testsystem zum Testen eines technischen Systems, insbesondere eines elektronischen Steuergerätes oder eines Teils eines elektronischen Steuergerätes, wobei der Testsystem eines der Verfahren der Ansprüche 1 bis 18 ausführt.
EP18720650.3A 2017-05-09 2018-05-08 Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs Pending EP3622451A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP17170127.9A EP3401849A1 (de) 2017-05-09 2017-05-09 Produktreifebestimmung eines technischen systems
PCT/EP2018/061759 WO2018206522A1 (de) 2017-05-09 2018-05-08 Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs

Publications (1)

Publication Number Publication Date
EP3622451A1 true EP3622451A1 (de) 2020-03-18

Family

ID=58709788

Family Applications (2)

Application Number Title Priority Date Filing Date
EP17170127.9A Ceased EP3401849A1 (de) 2017-05-09 2017-05-09 Produktreifebestimmung eines technischen systems
EP18720650.3A Pending EP3622451A1 (de) 2017-05-09 2018-05-08 Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP17170127.9A Ceased EP3401849A1 (de) 2017-05-09 2017-05-09 Produktreifebestimmung eines technischen systems

Country Status (4)

Country Link
US (1) US20200074375A1 (de)
EP (2) EP3401849A1 (de)
CN (1) CN110603546A (de)
WO (1) WO2018206522A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111782499B (zh) * 2019-04-03 2023-09-22 北京车和家信息技术有限公司 测试用例生成方法及系统
EP4390699A1 (de) * 2022-12-20 2024-06-26 dSPACE GmbH Computer-implementiertes verfahren zum bestimmen kompatibler systemelemente und system
DE102022134027A1 (de) * 2022-12-20 2024-06-20 Dspace Gmbh Computer-implementiertes Verfahren zum Bestimmen Algorithmusversions-kompatibler Test- und/oder Simulationsdaten und entsprechendes System

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3082000A1 (de) * 2015-04-15 2016-10-19 dSPACE digital signal processing and control engineering GmbH Verfahren und system zum testen eines mechatronischen systems

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167545A (en) * 1998-03-19 2000-12-26 Xilinx, Inc. Self-adaptive test program
US7272752B2 (en) * 2001-09-05 2007-09-18 International Business Machines Corporation Method and system for integrating test coverage measurements with model based test generation
US7216339B2 (en) * 2003-03-14 2007-05-08 Lockheed Martin Corporation System and method of determining software maturity using Bayesian design of experiments
US6853952B2 (en) * 2003-05-13 2005-02-08 Pa Knowledge Limited Method and systems of enhancing the effectiveness and success of research and development
US8869116B2 (en) * 2006-11-13 2014-10-21 Accenture Global Services Limited Software testing capability assessment framework
CN100451988C (zh) * 2006-11-14 2009-01-14 无敌科技(西安)有限公司 一种实现单元测试的方法及系统
MY148164A (en) * 2009-12-31 2013-03-15 Petroliam Nasional Berhad Petronas Method and apparatus for monitoring performance and anticipate failures of plant instrumentation
CN101901298A (zh) * 2010-05-19 2010-12-01 上海闻泰电子科技有限公司 一种通讯产品成熟度输出系统及方法
CN101908020B (zh) * 2010-08-27 2012-05-09 南京大学 一种基于分类挖掘和版本变更的测试用例优先化方法
CN106342306B (zh) * 2011-06-24 2013-01-16 中国人民解放军国防科学技术大学 漏检情况下的产品测试性指标获取方法
JP5692414B2 (ja) * 2011-12-15 2015-04-01 富士通株式会社 検知装置、検知プログラムおよび検知方法
EP2728465A1 (de) * 2012-11-01 2014-05-07 Tata Consultancy Services Limited System und Verfahren zur Bewertung der Produktreife
DE102013006011A1 (de) * 2013-04-09 2014-10-09 Airbus Defence and Space GmbH Modulare Testumgebung für eine Mehrzahl von Testobjekten
DE102013006012A1 (de) * 2013-04-09 2014-10-09 Airbus Defence and Space GmbH Mehrbenutzerfähige Testumgebung für eine Mehrzahl von Testobjekten
CN103646147A (zh) * 2013-12-23 2014-03-19 中国空间技术研究院 一种宇航元器件的成熟度综合评价方法
US20180068248A1 (en) * 2015-02-16 2018-03-08 Lawrence Fu Method and system for attributing and predicting success of research and development processes
JP6387777B2 (ja) * 2014-06-13 2018-09-12 富士通株式会社 評価プログラム、評価方法、および評価装置
CN104881551B (zh) * 2015-06-15 2018-02-06 北京航空航天大学 电工电子产品成熟度评估方法
US10417119B2 (en) * 2016-03-11 2019-09-17 Intuit Inc. Dynamic testing based on automated impact analysis
CN112629551B (zh) * 2016-12-23 2024-04-26 御眼视觉技术有限公司 具有施加的责任约束的导航系统
US11086761B2 (en) * 2017-03-20 2021-08-10 Devfactory Innovations Fz-Llc Defect prediction operation

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3082000A1 (de) * 2015-04-15 2016-10-19 dSPACE digital signal processing and control engineering GmbH Verfahren und system zum testen eines mechatronischen systems

Also Published As

Publication number Publication date
WO2018206522A1 (de) 2018-11-15
EP3401849A1 (de) 2018-11-14
CN110603546A (zh) 2019-12-20
US20200074375A1 (en) 2020-03-05

Similar Documents

Publication Publication Date Title
AT521607B1 (de) Verfahren und Vorrichtung zum Testen eines Fahrerassistenzsystem
DE102018128289B4 (de) Verfahren und vorrichtung für eine autonome systemleistung und zur einstufung
EP3082000B1 (de) Verfahren und system zum testen eines mechatronischen systems
AT523834B1 (de) Verfahren und System zum Testen eines Fahrerassistenzsystems
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
DE102018128890A1 (de) Verfahren und Testvorrichtung zum Testen eines Fahrassistenzsystems für ein Kraftfahrzeug
WO2017114883A1 (de) Verfahren zum konfigurieren einer co-simulation für ein gesamtsystem
DE102011088805A1 (de) Verfahren zum Entwickeln und/oder Testen eines Fahrerassistenzsystems
WO2018206522A1 (de) Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs
WO2022251890A1 (de) Verfahren und system zum testen eines fahrerassistenzsystems für ein fahrzeug
DE102021123597A1 (de) Verfahren und Steuergerät zur automatisierten Applikation von Fahrerassistenzsystemen im Serienbetrieb
EP4105811A1 (de) Computerimplementiertes verfahren zum szenariobasierten testen und/oder homologation von zu testenden zumindest teilweise autonomen fahrfunktionen durch key performance indicators (kpi)
AT523850B1 (de) Computergestütztes Verfahren und Vorrichtung zur wahrscheinlichkeitsbasierten Geschwindigkeitsprognose für Fahrzeuge
AT524821A1 (de) Verfahren und System zum Erzeugen von Szenariendaten zum Testen eines Fahrerassistenzsystems eines Fahrzeugs
DE102019213797A1 (de) Verfahren zur Bewertung einer Sequenz von Repräsentationen zumindest eines Szenarios
EP4086773A1 (de) Computerimplementiertes verfahren zum automatischen bereitstellen eines hinweises für testprozesse
WO2021089499A1 (de) Verfahren und system zum prüfen einer automatisierten fahrfunktion durch reinforcement-learning
DE102020005467A1 (de) Verfahren zum Verfügbarmachen von anonymisierten, ADAS relevanten Fahrzeugdaten
DE102022107338B3 (de) Verfahren zum Testen von automatisierten Fahrzeugfunktionen
DE102023000357B3 (de) Verfahren zum Erzeugen von Testdaten für eine Simulation eines Assistenzsystems eines zumindest teilweise assistiert betriebenen Kraftfahrzeugs, Computerprogrammprodukt, computerlesbares Speichermedium sowie elektronische Recheneinrichtung
DE102023103652A1 (de) Computerimplementiertes Verfahren zur Berechnung einer Berechnungsausgangsgröße aus einer Berechnungseingangsgröße
EP4174660A1 (de) Verfahren zum testen von steuergeräte
EP4325366A1 (de) Verfahren und system zum ausführen eines virtuellen tests

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191209

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210712

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DSPACE GMBH