Method, test bench setup and vehicle for performing a stability test of an embedded vehicle architecture

Abstract

Method for performing a stability test of an embedded vehicle architecture (100), wherein the embedded vehicle architecture (100) comprises several different individual systems that are networked to form a coherent and interacting system, wherein the vehicle architecture (100) comprises at least the following elements: a first control unit (A) and a second control unit (B), wherein the first control unit (A) is in communication with at least one sensor (1, 3), wherein the second control unit (B) is in communication with at least one sensor (2), and wherein the first control unit (A) and the second control unit (B) are in communication with each other via a vehicle network (X), the method comprising: - Providing at least one driving situation, - generating at least partially random and / or invalid input values ​​for the first control unit (A) and the second control unit (B), - Logging events in the vehicle network (X), - Check whether the first control unit (A) and / or the second control unit (B) are available, in particular using alive messages, - Declaring the at least one driving situation as an extreme situation if the first control unit (A) and / or the second control unit (B) are / is not available, - Saving a data sequence that led to the extreme situation, - adapting the vehicle architecture (100), in particular by a software iteration on the first control unit (A) and / or the second control unit (B), - Playing back the data sequence that led to the extreme situation in order to check the adapted vehicle architecture (100) for stability.

Description

[0001] The invention relates to a method for performing a stability test of an embedded vehicle architecture. Furthermore, the invention relates to a corresponding computer program product for performing a corresponding method. Furthermore, the invention relates to a test bench setup for performing a stability test of an embedded vehicle architecture. Furthermore, the invention relates to a vehicle for performing a stability test of an embedded vehicle architecture.

[0002] Modern vehicles are increasingly characterized by the use of sensors (ranging from simple sensors that measure physical quantities to predictive sensor technology) and electronic data processing using control units and central computers, all of which are interconnected. The software component continues to rise, so that many programs are developed individually and then integrated into a vehicle architecture. Despite thorough (unit) testing of individual sensors, control units, or software components, critical errors, even system crashes, can occur in the interaction of all components. It is practically impossible to describe all possible scenarios and test the integrated vehicle architecture against them.

[0003] The object of the invention is to provide a method for performing a stability test of an embedded or integrated, in particular electronic, vehicle architecture. In particular, the object of the invention is to test the stability of embedded or integrated vehicle architectures against various errors in an improved, reliable, secure, targeted, systematic, and, if possible, automated manner. Preferably, the object of the invention is to test the stability of embedded or integrated vehicle architectures in such a way that it can be ensured that a system crash does not occur during vehicle operation.

[0004] The object of the invention is achieved by: a method for conducting a stability test of an embedded vehicle architecture having the features of the independent method claim. Furthermore, the object of the invention is achieved by: a computer program product having the features of the independent product claim. Furthermore, the object of the invention is achieved by: a test bench setup for conducting a stability test of an embedded vehicle architecture having the features of the independent system claim. Furthermore, the object of the invention is achieved by: a vehicle having the features of the co-ordinate independent device claim.

[0005] The invention provides: a method for performing a stability test of an embedded vehicle architecture, wherein the vehicle architecture has at least the following elements: a first control unit and a second control unit, wherein the first control unit is in communication with at least one sensor, wherein the second control unit is in communication with at least one sensor, and wherein the first control unit and the second control unit are in communication with each other via a vehicle network (e.g. CAN, LIN, MOST, FlexRay, Ethernet, etc.), the method comprises the following actions / procedural steps: - Providing at least one (or more) driving situation(s), e.g. through hardware and / or software simulation and / or test drive, - generating at least partially random and / or invalid input values ​​(e.g. in the form of simulated sensor values, e.g. within and / or outside a configurable value range) for the first control unit and the second control unit, e.g. using a hardware and / or software random number generator, - Logging events in the vehicle network, e.g. using a log storage, - Check whether the first control unit and / or the second control unit are available, for example using alive messages, which are checked by a diagnostic module, for example, - Declaring at least one driving situation as an extreme situation or an error situation if the first control unit and / or the second control unit are / is not available, - Storing, preferably permanently storing, a data sequence that led to the extreme situation, e.g. in a separately designed error memory or within the log memory, - Adapting the vehicle architecture, e.g. through a software iteration on the first control unit and / or the second control unit, - Replay the data sequence that led to the extreme situation to check the stability of the adapted vehicle architecture.

[0006] The actions / process steps can preferably be performed repeatedly. Advantageously, all extreme situations can be permanently saved and replayed during each software iteration. Preferably, the process can be performed repeatedly until no new extreme situation is detected. With this approach, it is irrelevant which control units and / or sensors are embedded or integrated into the vehicle architecture. This approach works generically for different control units and / or sensors as well as for different vehicle architectures.

[0007] The invention recognizes that a major challenge in the development of embedded or integrated electronic vehicle architectures lies in the networking / integration of many different individual systems, such as control units, sensors, etc., into a coherent and interacting system. Although individual systems, such as control units, sensors, etc., can be easily tested individually, e.g. via unit tests, the networking / integration of many different individual systems exponentially increases the possible input values ​​as well as secondary conditions and environmental conditions, so that errors can still occur after networking / integration of apparently error-free individual systems. Particularly critical are errors that occur in extreme situations and lead to the crash of one or more control units. For example, a single sensor could paralyze the entire vehicle network, e.g. through a so-calledA "denial of service" attack, in which the sensor floods the vehicle network with messages, especially if adequate protection mechanisms are not integrated into the vehicle network. These extreme or marginal situations are sometimes unpredictable, as real-world traffic conditions and the resulting sensor values, as well as secondary and environmental conditions, result in virtually infinite possibilities that cannot be fully predicted and / or tested. Furthermore, since they occur rarely, these errors are particularly difficult to detect and eliminate with regard to stable operation.

[0008] The invention proposes the advantageous, novel use of a so-called fuzzing approach for software testing. A random data generator can generate millions of random and / or invalid input values ​​and pass the values ​​to the software under test in order to check whether the software crashes or whether potential security vulnerabilities are revealed. Advantageously, it is proposed that data sequences that lead to crashes and / or security vulnerabilities are saved and played back during one or each new software iteration in order to check the adapted vehicle architecture for stability. In this way, stability tests can be significantly improved. The stability of embedded or integrated vehicle architectures can thereby be significantly improved.Integrated vehicle architectures can thus be ensured with increased reliability, so that system crashes can be avoided with increased safety during vehicle operation.

[0009] Firstly, it is conceivable in the method that the at least one driving situation is simulated on a test bench. The at least one driving situation can be provided by a simulation device, in particular a hardware-in-the-loop simulator, which can be connected to the vehicle architecture. Furthermore, it is conceivable that the simulation device can replace at least one control unit and / or one sensor in the vehicle architecture. Furthermore, it is conceivable that the simulation device can be connected to the vehicle network. The simulation device, in particular the hardware-in-the-loop simulator, can be implemented with a software fuzzer.The hardware-in-the-loop simulator can simulate at least one driving situation, while the software fuzzer randomly generates millions or billions of different input values ​​and preferably packages them into a specific data packet with a corresponding device address or topic. The exact nature of these random and / or invalid input values, e.g., their value range, which control data is specified to control the data flow, etc., can be configured in advance. It is also possible to randomly generate invalid data packets to test how the vehicle architecture reacts to them. These diverse input values ​​generated in this way are passed one after the other to the vehicle architecture, e.g., to the vehicle network and / or to a control unit.At the same time, a logger records the data packets occurring across the entire vehicle network and also checks whether control units and sensors are still available. This allows the entire vehicle architecture to be tested against an extremely large number of sample data sets, which also take extreme situations or corrupted data packets into account, and thus to be checked for stability and robustness. If one or more components crash, the logging data can be used to precisely trace which data caused the crash and thus improve error checking in the respective component. Preferably, the resulting error data sequence is saved so that it can be replayed after one and / or each subsequent software iteration in order to reproduce the error situation and observe the changed behavior.Depending on the design of the overall development process, this approach can be implemented in continuous deployment / continuous integration (CD / CI) processes to automatically repeat targeted tests after new software iterations and / or to verify a system response.

[0010] Secondly, it is conceivable in the method that the at least one driving situation is generated by a test vehicle and / or that the at least one driving situation is provided during a test drive. In this case, the at least one driving situation can be provided by a testing device that is connected to the vehicle architecture. Furthermore, it is conceivable that the testing device can replace at least one control unit and / or one sensor in the vehicle architecture. Furthermore, it is conceivable that the testing device can be connected to the vehicle network. The testing device can, for example, have a hardware fuzzer. Furthermore, several testing devices with several hardware fuzzers can be used instead of several sensors in the vehicle architecture. The testing device can have various interfaces in order to connect to the vehicle network (e.g.directly at the gateway via CAN, LIN, MOST, FlexRay, Ethernet, etc.) and / or to a control unit and to be able to communicate with the vehicle network and / or the control unit. Furthermore, the checking device can have a log memory to log events in the vehicle network. The checking device can also have an interface to an external computer to log the data externally. The hardware fuzzer can be configured to generate random input values ​​within a configured input value range and preferably package these into a specific data packet with a corresponding device address or topic. In doing so, it can also generate corrupt data packets. Advantageously, predefined sequences of input values ​​can also be played back (so-called "replay") in order to reproduce previously observed errors.Furthermore, the verification device can be provided with appropriate certificates so that it appears to the remaining components in the vehicle network as an original control unit or sensor (so-called "mocking"). In this way, the hardware fuzzer can now also input random values ​​into the vehicle network. The verification device and / or the external computer logs all data packets that pass through the vehicle network via a "logger." Furthermore, the verification device can also be designed with an interface to a diagnostic unit or with its own diagnostic unit in order to check the availability of other control units and sensors. Advantageously, this approach eliminates the need for a test bench.In an existing vehicle, one or more sensors / control units / central computers can be replaced with such a monitoring device, and the behavior of the remaining components can be monitored in response to the millions or billions of data packets provided. Furthermore, with appropriate implementation, higher speeds can be achieved, as this functionality can also be implemented, for example, via a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0011] Furthermore, it is conceivable for the method to provide at least one driving situation using a software-in-the-loop simulator that simulates the vehicle architecture. This allows the method to be implemented without additional hardware, i.e., without actual vehicle hardware. However, this could be an oversimplification, as physical effects such as higher power requirements, heat problems, and throttling cannot occur. However, testing would be simpler, and all processing steps of all control units and sensors could be logged more easily. The sequence of input data to be sent can also be precalculated (similar to "rainbow tables" in "password hacking"), allowing for even more specific influence on the testing process and the ability to repeat critical situations in a targeted manner.

[0012] Furthermore, it can be provided that the at least partially random and / or invalid input values ​​for the first control unit and the second control unit are at least partially generated by a software-based random number generator. The software-based random number generator can preferably construct a grid structure, e.g., using a Sobel operator, in order to distribute randomly generated values ​​across a value range as evenly as possible and without repetition. It is conceivable that the software-based random number generator can be provided on a hardware-in-the-loop simulator. Thus, the method can be carried out using a test bench.

[0013] Furthermore, it can be provided that the at least partially random and / or invalid input values ​​for the first control unit and the second control unit are generated at least partially by a hardware-based random number generator. It is conceivable that the hardware-based random number generator can replace at least one control unit and / or one sensor in the vehicle architecture. Thus, the method can be carried out using a test vehicle.

[0014] Advantageously, the at least partially random and / or invalid input values ​​can be configured within a specific value range. At the same time and / or additionally, corrupt input values ​​can be configured outside the specific value range. In this way, the input values ​​can cover as diverse and / or unexpected driving situations as possible.

[0015] The invention further provides a computer program product comprising instructions that, when executed by a computer, cause the computer to perform a method that can be executed as described above. The computer program product according to the invention can achieve the same advantages as those described above in connection with the method according to the invention. These advantages are incorporated herein by reference.

[0016] In addition, the invention provides: a test bench setup for performing a stability test of an embedded vehicle architecture, comprising: - a first control unit, - a second control unit, - at least one sensor for the first control unit, - at least one sensor for the second control unit, wherein the first control unit and the second control unit are connected to each other (in terms of communication and / or control technology) via a vehicle network, - and a simulation device, wherein the simulation device comprises a simulator for at least one driving situation, wherein the simulation device comprises a random number generator for generating at least partially random and / or invalid input values ​​for the first control unit and the second control unit, wherein the simulation device is designed to log events in the vehicle network, wherein the simulation device is designed to check whether the first control unit and / or the second control unit are / is available, in particular by means of alive messages, wherein the simulation device is designed to declare the at least one driving situation as an extreme situation if the first control unit and / or the second control unit are / is not available, wherein the simulation device has an error memory to store, preferably permanently store, a data sequence that has led to the extreme situation, wherein the simulation device is designed to play back the data sequence that led to the extreme situation, preferably after adapting the vehicle architecture, in particular by a software iteration on the first control unit and / or the second control unit, in order to check an adapted vehicle architecture for stability.

[0017] Using the test bench setup according to the invention, the same advantages can be achieved that were described above in connection with the method according to the invention. These advantages are incorporated herein by reference.

[0018] In addition, the simulation device can have a computing unit and a memory unit in which a code is stored which, when at least partially executed by the computing unit, carries out a method as described above.

[0019] Furthermore, the simulation device can comprise a hardware-in-the-loop simulator. It is conceivable that the simulation device can replace at least one control unit and / or one sensor in the vehicle architecture. Furthermore, it is conceivable that the simulation device can be connected to the vehicle network.

[0020] The random number generator can, for example, comprise a software-based random number generator. The software-based random number generator can be designed to create a grid structure to distribute randomly generated values ​​across a range of values ​​as evenly as possible and without repetition. The software-based random number generator can, for example, be provided on a hardware-in-the-loop simulator.

[0021] The random number generator can also have a hardware-based random number generator.

[0022] Furthermore, the invention provides: a vehicle for performing a stability test of an embedded vehicle architecture, comprising: - a first control unit, - a second control unit, - at least one sensor for the first control unit, - at least one sensor for the second control unit, wherein the first control unit and the second control unit are connected to each other via a vehicle network, and wherein at least one control unit and / or one sensor in the vehicle architecture is replaced by a checking device, wherein the checking device comprises a random number generator for generating at least partially random and / or invalid input values ​​for the first control unit and the second control unit, wherein the checking device is designed to play back a data sequence which has led to an extreme situation, preferably after an adaptation of the vehicle architecture, in particular by a software iteration on the first control unit and / or the second control unit, in order to check an adapted vehicle architecture for stability.

[0023] The vehicle according to the invention can achieve the same advantages as those described above in connection with the method according to the invention. These advantages are incorporated herein by reference.

[0024] The checking device can advantageously have a computing unit and a memory unit in which a code is stored which, when at least partially executed by the computing unit, carries out a method as described above.

[0025] According to a further advantage, the checking device can be designed and / or have a communication interface to an external checking device in order to log events in the vehicle network.

[0026] According to a further advantage, the checking device can have a diagnostic unit and / or a communication interface to an internal vehicle diagnostic unit in order to check whether the first control unit and / or the second control unit are / is available, for example by checking alive messages.

[0027] The checking device can further be designed and / or have a communication interface to an external checking device in order to declare the at least one driving situation as an extreme situation if the first control unit and / or the second control unit are / is not available.

[0028] Advantageously, the checking device may comprise an error memory and / or a communication interface to an external checking device in order to store, preferably permanently store, a data sequence that has led to the extreme situation.

[0029] Furthermore, it is conceivable that the random number generator may comprise a hardware-based random number generator.

[0030] The random number generator can also have a software-based random number generator.

[0031] The invention is further illustrated in more detail with reference to the figures. It should be noted that the figures are merely descriptive and are not intended to limit the invention in any way. They show: Fig. 1 a schematic representation of a test bench setup for performing a stability test of an embedded vehicle architecture, and Fig. 2 a schematic representation of a vehicle for performing a stability test of an embedded vehicle architecture.

[0032] The Fig. 1 and Fig. 2 serve to explain a method for performing a stability test of an embedded vehicle architecture 100.

[0033] As the Fig. 1 and Fig. 2, the vehicle architecture 100 comprises at least a first control unit A and a second control unit B. The first control unit A can be in communication with at least one sensor 1, 3 in order to activate corresponding actuators of a corresponding vehicle function depending on sensor signals. The second control unit B can be in communication with at least one sensor 2 in order to activate corresponding actuators of a corresponding vehicle function depending on sensor signals.

[0034] The first control unit A and the second control unit B communicate with each other via a vehicle network X (e.g. CAN, LIN, MOST, FlexRay, Ethernet, etc.).

[0035] The procedure includes the following actions / procedural steps: - Providing at least one (or more) driving situation(s), e.g. through hardware and / or software simulation and / or test drive, - Generating at least partially random and / or invalid input values ​​(e.g. in the form of simulated sensor values, e.g. in and / or outside a configurable value range) for the first control unit A and the second control unit B, e.g. using a hardware-related (cf. Fig. 1) and / or software random number generator (cf. Fig. 2), - Logging events in the vehicle network X, e.g. using a log storage, - Check whether the first control unit A and / or the second control unit B are available, e.g. using alive messages, which are checked, for example, by an on-board and / or separate diagnostic unit, - Declaring at least one driving situation as an extreme situation or an error situation if the first control unit A and / or the second control unit B are / is not available, - Storing, preferably permanently storing, a data sequence that led to the extreme situation, e.g. in a separately designed error memory or within the log memory, - Adapting the vehicle architecture 100, for example by at least one or more software iterations on the first control unit A and / or the second control unit B, - Playing back the data sequence that led to the extreme situation in order to check the adapted vehicle architecture 100 for stability.

[0036] The actions / procedural steps can preferably be performed repeatedly, e.g., driving situation by driving situation. Advantageously, all detected extreme situations can be permanently saved and replayed with each new software iteration to check the stability of the adapted vehicle architecture.

[0037] Preferably, the method can be repeated until no more, or at least until no new, extreme situations are detected. The method is generically suitable for different control units A, B and / or sensors 1, 2, 3, as well as for different vehicle architectures 100.

[0038] A major challenge in the development of embedded or integrated electronic vehicle architectures 100 is that many different individual systems, such as control units A, B, sensors 1, 2, 3, etc., are networked / integrated into a coherent and interacting architecture. While individual systems, such as control units A, B, sensors 1, 2, 3, etc., can be individually tested for stability, e.g., using unit tests, the networking / integration of many different individual systems can exponentially increase the possible input values, as well as constraints and environmental conditions, so that errors can still occur after the networking / integration of apparently error-free individual systems.

[0039] For example, an error can be critical and lead to an extreme situation, even to the point of one or more control units crashing, in which the sensor floods the vehicle network X with messages (a so-called "denial of service" attack), especially if sufficient protective mechanisms are not integrated into the vehicle network X. These extreme situations or error situations cannot be ultimately predicted, since the real traffic situation and the sensor values ​​recorded thereby, as well as secondary conditions and environmental conditions, can change infinitely. Using the method, a wide variety of expected and / or unexpected errors can advantageously be simulated and checked with regard to stable operation of the vehicle architecture 100.

[0040] To this end, a so-called fuzzing approach for software testing is used in a beneficial, novel way. A random data generator can generate millions of random and / or invalid input values ​​and pass the values ​​to the software under test in the respective control unit A or B to check whether the software crashes or whether potential security vulnerabilities are revealed.

[0041] Advantageously, it is proposed that data sequences that lead to the failure of control units A, B, and / or the entire vehicle architecture 100 be saved and replayed during one or each new software iteration in order to recheck the adapted vehicle architecture 100 for stability during the "dangerous" data sequences. In this way, the stability tests can be significantly improved. The stability of embedded or integrated vehicle architectures 100 can thereby be significantly improved. The stability of embedded or integrated vehicle architectures 100 can thereby be ensured with increased reliability, so that system crashes are as unlikely as possible during operation of the vehicle 102.

[0042] As the Fig. 1, the method can be carried out using a test bench setup 101. The at least one driving situation can be provided by a HIL simulation device, for example in the form of a hardware-in-the-loop simulator, which can be connected to the vehicle architecture 100 for data and / or control purposes. It is conceivable that the HIL simulation device can replace at least one control unit and / or one sensor in the vehicle architecture 100. Furthermore, it is conceivable that the HIL simulation device can be connected to the vehicle network X.

[0043] The HIL simulation device, in particular the hardware-in-the-loop simulator, can be implemented, for example, with a software fuzzer. At least one driving situation can be simulated using the hardware-in-the-loop simulator, while the software fuzzer randomly generates millions or billions of different input values ​​in the form of random and / or invalid sensor values ​​and, if necessary, packages these into a specific data packet with corresponding device addressing or a topic. The exact appearance of these random and / or invalid input values, e.g., their value range, which control data is specified to control the data flow, etc., can be configured in advance. However, it is also possible to randomly generate invalid data packets in order to test how the vehicle architecture 100 reacts to them. These diverse input values ​​generated in this way are sent one after the other to the vehicle architecture 100, e.g.to the vehicle network X and / or to individual control units A, B. In parallel, a logger logs the data packets occurring in the entire vehicle network X and additionally checks whether control units A, B and sensors 1, 2, 3 are still available. In this way, the entire vehicle architecture 100 can be tested against an extremely large number of sample data, which also take extreme situations or corrupt data packets into account, and thus checked for stability and robustness. If one or more control units A, B and sensors 1, 2, 3 crash, the logging data can be used to precisely trace which data caused the crash. This allows error checking in the respective component to be improved.Preferably, the error data sequence caused is stored in order to replay it after one and / or after each subsequent software iteration for the first control unit A and / or the second control unit B in order to specifically reproduce the error situation and observe the changed behavior of the vehicle architecture 100. Depending on the design of the overall development process, the approach can be as in . Fig. 1, continuous deployment / continuous integration procedures (CD / CI) can be implemented to automatically repeat the targeted tests after new software iterations and / or to specifically check a system response.

[0044] As the Fig. 2, the method can be carried out using a vehicle 102, for example in the form of a test vehicle. The at least one driving situation can be generated by a test vehicle and / or the at least one driving situation can be provided during a test drive. The at least one driving situation can be provided by a checking device HF that is connected to the vehicle architecture 100. It is conceivable that the checking device HF can replace at least one control unit A, B and / or one sensor 1, 2, 3 in the vehicle architecture 100. Furthermore, it is conceivable that the checking device HF can be connected to the vehicle network X.

[0045] The HF checking device can, for example, comprise a hardware fuzzer. Furthermore, multiple HF checking devices with multiple hardware fuzzers can be used in the vehicle architecture 100 instead of multiple control units A, B and / or sensors 1, 2, 3.

[0046] The HF testing device can have various interfaces in order to connect to the vehicle network X (e.g. directly to the gateway via CAN, LIN, MOST, FlexRay, Ethernet, etc.) and / or to the respective control unit A, B, as well as to be able to communicate with the vehicle network X and / or the respective control unit A, B.

[0047] Furthermore, the HF checking device can have a log memory to log events in the vehicle network X. However, the HF checking device can also have an interface to an external computer to log the data externally.

[0048] The HF verification device can, for example, be implemented with a hardware-based random number generator. The hardware fuzzer can be configured to generate random input values ​​within a configured value range and preferably package them into a specific data packet with a corresponding device address or topic. In doing so, it can also generate corrupted data packets. Advantageously, predefined sequences of input values ​​can also be replayed to reproduce previously observed errors.

[0049] Furthermore, the HF verification device can be provided with appropriate certificates so that it appears to the remaining components in the vehicle network X as an original control unit or sensor (so-called "mocking"). This allows the hardware fuzzer to also transmit random values ​​to the vehicle network X.

[0050] The HF verification device and / or the external computer logs all data packets that pass through the vehicle network X via a “logger”.

[0051] Furthermore, the checking device HF can also be designed with an interface to a diagnostic unit or with its own diagnostic unit in order to be able to check the availability of other control units A, B and / or sensors 1, 2, 3. Advantageously, with this approach, as in Fig. 2, a test bench can be dispensed with.

[0052] Thus, even in an existing vehicle 102, one or more sensors 1, 2, 3 / control units A, B / central computer can be replaced by such an RF monitoring device, and the behavior of the remaining components can be monitored on the millions / billions of data packets provided by the vehicle. Furthermore, higher speeds can be achieved, since this functionality can also be implemented, for example, via a so-called field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0053] Furthermore, it is conceivable that the procedure, although it is in the Fig. 1 and Fig.2, it is not illustrated for reasons of simplicity that the method can be implemented in software. The at least one driving situation can be provided by a software-in-the-loop simulator that fully simulates the vehicle architecture 100. In this way, the method can be enabled without additional hardware, i.e., without actual vehicle hardware. This makes testing easier. Furthermore, all processing steps of all control units A, B and sensors 1, 2, 3 can be logged more easily.

[0054] The sequence of input data to be sent can also be pre-calculated (similar to “rainbow tables” in “password hacking”) in order to have an even more specific influence on the testing process and to be able to repeat critical situations in a targeted manner.

[0055] The above description of the figures describes the present invention exclusively by way of example. Of course, individual features of the embodiments can be freely combined with one another, provided this is technically feasible, without departing from the scope of the invention. List of reference symbols 1 sensor 2 sensors 3 Sensor 100 Vehicle Architecture 101 Test bench setup 102 vehicles A control unit B control unit HF testing device HIL simulation device X vehicle network

Claims

[1] Method for performing a stability test of an embedded vehicle architecture (100), wherein the embedded vehicle architecture (100) comprises several different individual systems that are networked to form a coherent and interacting system, wherein the vehicle architecture (100) comprises at least the following elements: a first control unit (A) and a second control unit (B), wherein the first control unit (A) is in communication with at least one sensor (1, 3), wherein the second control unit (B) is in communication with at least one sensor (2), and wherein the first control unit (A) and the second control unit (B) are in communication with each other via a vehicle network (X), the method comprising: - Providing at least one driving situation, - generating at least partially random and / or invalid input values ​​for the first control unit (A) and the second control unit (B), - Logging events in the vehicle network (X), - Check whether the first control unit (A) and / or the second control unit (B) are available, in particular using alive messages, - Declaring the at least one driving situation as an extreme situation if the first control unit (A) and / or the second control unit (B) are / is not available, - Saving a data sequence that led to the extreme situation, - adapting the vehicle architecture (100), in particular by a software iteration on the first control unit (A) and / or the second control unit (B), - Playing back the data sequence that led to the extreme situation in order to check the adapted vehicle architecture (100) for stability. [2] Method according to claim 1, wherein the at least one driving situation is simulated on a test bench, and / or wherein the at least one driving situation is provided by a simulation device (HIL), in particular a hardware-in-the-loop simulator, which is connected to the vehicle architecture (100), wherein in particular the simulation device (HIL) replaces at least one control unit (A, B) and / or one sensor (1, 2, 3) in the vehicle architecture (100), and / or wherein the simulation device (HIL) is connected to the vehicle network (X). [3] Method according to claim 1, wherein the at least one driving situation is generated by a test vehicle, and / or wherein the at least one driving situation is provided during a test drive, and / or wherein the at least one driving situation is provided by a checking device (HF) which is connected to the vehicle architecture (100), wherein in particular the checking device (HF) replaces at least one control unit (A, B) and / or one sensor (1, 2, 3) in the vehicle architecture (100), and / or wherein the checking device (HF) is connected to the vehicle network (X). [4] The method of claim 1, wherein the at least one driving situation is provided by a software-in-the-loop simulator that simulates the vehicle architecture (100). [5] Method according to one of the preceding claims, wherein the at least partially random and / or invalid input values ​​for the first control unit (A) and the second control unit (B) are at least partially generated by a software-based random number generator, wherein in particular the software-based random number generator builds a grid structure to distribute randomly generated values ​​over a range of values, preferably without repetitions, wherein the software-based random number generator is preferably provided on a hardware-in-the-loop simulator. [6] Method according to one of the preceding claims, wherein the at least partially random and / or invalid input values ​​for the first control unit (A) and the second control unit (B) are at least partially generated by a hardware-based random number generator, wherein in particular the hardware-based random number generator replaces at least one control unit (A, B) and / or one sensor (1, 2, 3) in the vehicle architecture (100). [7] Computer program product comprising instructions which, when the computer program product is executed by a computer, cause the computer to carry out a method according to one of the preceding claims. [8] Test bench setup (101) for carrying out a stability test of an embedded vehicle architecture (100), wherein the embedded vehicle architecture (100) comprises several different individual systems that are networked to form a coherent and interacting system, comprising: - a first control unit (A), - a second control unit (B), - at least one sensor (1, 3) for the first control unit (A), - at least one sensor (2) for the second control unit (B), wherein the first control unit (A) and the second control unit (B) are connected to each other via a vehicle network (X), - and a simulation device (HIL), wherein the simulation device (HIL) comprises a simulator for at least one driving situation, wherein the simulation device (HIL) comprises a random number generator for generating at least partially random and / or invalid input values ​​for the first control unit (A) and the second control unit (B), wherein the simulation device (HIL) is designed to log events in the vehicle network (X), wherein the simulation device (HIL) is designed to check whether the first control unit (A) and / or the second control unit (B) are / is available, in particular by means of alive messages, wherein the simulation device (HIL) is designed to declare the at least one driving situation as an extreme situation if the first control unit (A) and / or the second control unit (B) are / is not available, wherein the simulation device (HIL) has an error memory to store, preferably permanently store, a data sequence that has led to the extreme situation, wherein the simulation device (HIL) is designed to play back the data sequence that led to the extreme situation, preferably after adapting the vehicle architecture (100), in particular by a software iteration on the first control unit (A) and / or the second control unit (B), in order to check an adapted vehicle architecture (100) for stability. [9] Test bench structure (101) according to the preceding claim, wherein the simulation device (HIL) has a computing unit and a memory unit in which a code is stored which, when at least partially executed by the computing unit, carries out a method according to one of the preceding claims, and / or wherein the simulation device (HIL) comprises a hardware-in-the-loop simulator, wherein in particular the simulation device (HIL) replaces at least one control unit (A, B) and / or one sensor (1, 2, 3) in the vehicle architecture (100), and / or wherein the simulation device (HIL) is connected to the vehicle network (X), and / or wherein the random number generator comprises a software-based random number generator, wherein in particular the software-based random number generator is designed to build a grid structure in order to distribute randomly generated values ​​over a range of values, preferably without repetitions, wherein the software-based random number generator is preferably provided on a hardware-in-the-loop simulator, or wherein the random number generator comprises a hardware-based random number generator. [10] Vehicle (102) for performing a stability test of an embedded vehicle architecture (100), wherein the embedded vehicle architecture (100) comprises several different individual systems that are networked into a coherent and interacting system, comprising: - a first control unit (A), - a second control unit (B), - at least one sensor (1, 3) for the first control unit (A), - at least one sensor (2) for the second control unit (B), wherein the first control unit (A) and the second control unit (B) are connected to each other via a vehicle network (X), and wherein at least one control unit (A, B) and / or one sensor (1, 2, 3) in the vehicle architecture (100) is replaced by a checking device (HF), wherein the checking device (HF) has a random number generator for generating at least partially random and / or invalid input values ​​for the first control unit (A) and the second control unit (B), wherein the checking device (HF) is designed to play back a data sequence which has led to an extreme situation, preferably after an adaptation of the vehicle architecture (100), in particular by a software iteration on the first control unit (A) and / or the second control unit (B), in order to check an adapted vehicle architecture (100) for stability. [11] Vehicle (102) according to the preceding claim, wherein the checking device (HF) has a computing unit and a memory unit in which a code is stored which, when at least partially executed by the computing unit, carries out a method according to one of the preceding claims, wherein the checking device (HF) is designed and / or has a communication interface to an external checking device to log events in the vehicle network (X), and / or wherein the checking device (HF) has a diagnostic unit and / or a communication interface to an in-vehicle diagnostic unit in order to check whether the first control unit (A) and / or the second control unit (B) are / is available, in particular by means of alive messages, and / or wherein the checking device (HF) is designed and / or has a communication interface to an external checking device to declare the at least one driving situation as an extreme situation if the first control unit (A) and / or the second control unit (B) are / is not available, and / or wherein the checking device (HF) has an error memory and / or has a communication interface to an external checking device to store, preferably permanently store, a data sequence that has led to the extreme situation, and / or wherein the random number generator comprises a hardware-based random number generator, or wherein the random number generator comprises a software-based random number generator.

Images