Method for testing a system

Abstract

A computer-implemented method for testing a system, in particular an embedded system, is presented. Herein a first error is introduced into the system, the system behavior of the system is observed after the introduction of the first error, and it is subsequently checked whether a first faulty behavior occurs. Furthermore, a machine learning system learns from the first error and from the occurrence of the first faulty behavior a probability of the system to exhibit a faulty behavior upon introduction of an error into the system depending on properties of the introduced error. Depending on the learned probability, a second error is introduced into the system, and the system behavior of the system is observed after the introduction of the second error, and it is subsequently checked whether a second faulty behavior occurs.

Description

Technical Field

[0001] The present invention relates to methods for testing computer implementations of systems, particularly embedded systems, and test systems designed for this purpose, as well as computer programs designed for this purpose. Background Technology

[0002] Developing (functionally) safe products requires various safety analyses such as FMEA (Failure Modes and Effects Analysis) or FTA (Fault Tree Analysis). These requirements are derived from functional safety standards such as ISO 26262:2011.

[0003] The core idea behind various methods used for security analysis is:

[0004] 1. Define the types of failure modes of the system under inspection.

[0005] 2. Analyze how this type of failure behavior propagates, particularly how it adversely affects other subsystems, and what its impact is on the entire system, especially its negative impact on the functional safety of the system.

[0006] 3. Perform a criticality assessment. A key aspect of this is examining whether a particular type of failure behavior directly leads to a violation of safety requirements or only results in a violation of safety requirements in combination with other failure behaviors.

[0007] 4. Improve the system. For fault behaviors that directly lead to violations of safety requirements, typically measures will be taken that can detect the fault behavior and transition the system to a safe state. For combinations of faults, the analysis team will examine the criticality and define measures as necessary.

[0008] Measures taken in this type of security analysis are typically characterized by mostly manually defined or expert-defined steps, which can quickly lead to high costs and the risk of analytical errors in the case of complex systems, especially leading to undetectable system weaknesses.

[0009] The possible reasons for this are:

[0010] 1. A large number of potential fault behavior types, system states, operating scenarios, and error combinations.

[0011] 2. Difficult to encapsulate: A typical approach to handling complexity is to break down tedious analysis tasks into smaller analysis packages for subsystems. However, this proves difficult in real-world environments because error effects depend on the specific context of each subsystem, and complex relationships exist between subsystems that must be considered.

[0012] Advances have been made in the field of model-driven security analytics, which facilitate the integration and encapsulation of security analytics. For example, DE 102018219852 discloses a method for distributing the functionality of a functional model in a distributed system with multiple networked processing nodes.

[0013] Model-driven approaches require sufficiently detailed models that can only be provided with significant effort. Often, for example, the necessary information about the provided software, hardware, mechanical, or hydraulic subsystems is not available.

[0014] Analysis involving numerous manual steps is often flawed and incomplete. Model-driven rules alone are insufficient to meet the requirements of security analysis. Therefore, improved methods are desired to ensure the security of complex systems.

[0015] Tests can be automatically generated for a system using the so-called SBT (search-based testing) method. See, for example, "Phil McMinn: Search-Based Software Testing: Past, Present and Future, Proceedings of the 2011 IEEE Fourth International Conference on Software Testing, Verification and Validation Workshops (ICSTW '11), IEEE Computer Society, Washington, DC, USA, 153-163, 2011".

[0016] Mutation testing allows for the inspection and improvement of test quality. See, for example, “Y. Jia and M. Harman: An Analysis and Survey of the Development of Mutation Testing, IEEE Transactions on Software Engineering, Vol. 37, No. 5, pp. 649-678, September-October, 2011.” The core idea of ​​mutation testing is to introduce code changes (e.g., changing from + to - in a line of code) and use the modified code in the test case. If the change is detected, it indicates that the test can find a problem in the system. Summary of the Invention

[0017] Failure behavior (often simply "failure") describes the undesirable behavior of the system under inspection. Fault (often simply "fault") describes the erroneous properties of the system. Fault injection refers to the targeted introduction of faults (i.e., erroneous properties) into the system under inspection. Fault injection can be used in testing methodologies, particularly to increase test coverage. Mutation testing provides the possibility of testing via fault injection, where portions of the system's software code are replaced with modified (mutated) software code.

[0018] A method for testing computer implementations of systems, particularly embedded systems, is proposed. Here, an embedded system refers to an electronic computer or a computer bound to (embedded in) a technological context. The computer performs monitoring, control, or regulation functions, or is responsible for some form of data or signal processing, such as in the case of encrypting or decrypting, encoding or decoding, or filtering data.

[0019] In the testing method, a first error is introduced into the system, the system behavior is observed after the first error is introduced, and then the system is checked for a first fault behavior. Preferably, the system behavior is checked based on at least one predetermined machine-readable security requirement, and if the system behavior does not meet the at least one security requirement, the fault behavior is determined.

[0020] The machine learning system calculates or learns probabilities based on the first error and the occurrence of the first fault behavior. Here, the probability of the system exhibiting fault behavior when an error with specific attributes is introduced is calculated or learned. Based on the learned probabilities, a second error is introduced into the system, and the system behavior is observed after the introduction of the second error, subsequently checking whether a second fault behavior occurs. Here, the machine learning system preferably includes an evolutionary algorithm, a genetic algorithm, or a neural network.

[0021] Therefore, learning methods are used to more effectively select or generate errors to be introduced for system testing. Specifically, it allows learning which errors (optionally: in which system states, for which environmental conditions, or in which combinations) are likely to cause faulty behavior in the system when introduced, and to identify security risks, and which errors will not. Depending on the system under test, the corresponding test system itself can be implemented as a purely software solution, or it can include hardware components, particularly to allow error injection to be performed close to the hardware under test.

[0022] In addition to improving test quality, these methods can achieve high test coverage while minimizing test overhead (computational steps, duration, memory capacity). They enable greater automation of testing methods and reliably inspect and ensure the safety of the system under test.

[0023] In a preferred configuration, the error relates to a time series within the system, specifically the time point or repetition rate of a signal, function call, or function interruption, or the error relates to a value within the system, specifically the value of a signal or parameter. The attributes of the introduced error preferably include the location of the introduced error within the system, the type of introduced error, the value or magnitude of the introduced error, or a combination of introduced errors. This allows for flexible error injection and appropriate parameterization of the learning method.

[0024] Preferably, the machine learning system also learns the probabilities based on the system's environmental conditions, system state, or operating mode. Since different security requirements can be applied to different operating modes, environmental conditions, or system states, and specific errors can trigger different system behaviors depending on the operating mode, environmental conditions, or system state, these considerations enable more robust and efficient learning.

[0025] In a preferred configuration, the error is introduced into the system by means of software or hardware for error injection. Particularly preferred is the introduction via so-called mutation or mutation testing, that is, specifically by changing or replacing a portion of the system's software code. This type of error introduction can be automated particularly efficiently, and the properties of the corresponding changes or replacements are particularly suitable for learning using machine learning methods.

[0026] Advantageously, the system is at least partially a physical prototype, at least partially implemented as hardware-in-the-loop, at least partially implemented as software-in-the-loop, and / or at least partially implemented as processor-in-the-loop. The system's environment can be simulated for the testing. Preferably, the system has both hardware and software components. In a particularly preferred configuration, the system is a control or regulation system, particularly for electrical, hydraulic, or pneumatic equipment, machines, or actuators of such equipment, and / or a system designed to regulate or control the functions of a vehicle or robot. In particular, the system can be a driver assistance system in a vehicle or a control or regulation system for controlling or regulating driving functions in a highly automated or autonomous vehicle. The described method is particularly suitable for such complex systems and provides maximum efficiency advantages.

[0027] In a particularly preferred configuration, additional errors are repeatedly introduced in a loop based on the learned probabilities. The machine learning system further learns based on the introduced errors and the fault behaviors determined for those errors. Preferably, a test termination criterion is determined based on the machine learning system or the learned probabilities, or the method is automatically terminated. Specifically, the method can be terminated if the probability of additional fault behaviors due to the introduction of additional errors does not exceed a certain threshold. This allows for fully automated execution of a comprehensive testing method, which can be terminated when necessary. High test coverage is achieved by introducing primarily and only the following errors or combinations of errors into the machine learning system, for which the system has a higher probability of exhibiting fault behaviors. If no more promising combinations are found, the method can be completed.

[0028] In a favorable configuration, the system under test is adapted based on the results of the test, particularly ensuring that the system is transitioned to a safe state if faulty behavior is identified. Attached Figure Description

[0029] Embodiments of the present invention will now be explained in more detail with reference to the accompanying drawings.

[0030] Figure 1 An exemplary test scenario with a test system and a system under inspection is illustrated schematically. Detailed Implementation

[0031] Significant improvements in the availability of high-performance and affordable test environments (e.g., hardware-in-the-loop, software-in-the-loop, processor-in-the-loop) enable the testing of multiple systems or subsystems of an entire system in simulation.

[0032] To support the analysis of complex systems in terms of functional safety, errors can be introduced (error injection) into such a test environment to automatically detect critical paths in the system. This can be done for specific failure behavior scenarios to examine the effects of specific failure behaviors and check the performance of the detection mechanism.

[0033] However, due to the manual steps and long execution time, such error injection methods for complex systems are typically very expensive. The costs associated with test definition, test automation, and test result evaluation are substantial, often increasing exponentially with the number of test cases. This is also related to the fact that errors can be introduced under various operating conditions and in various operating modes, error combinations should be frequently checked, and various types of error behaviors exist (values ​​too high, values ​​too low, oscillations, transient errors, etc.).

[0034] Therefore, achieving full test coverage in existing hardware-in-the-loop environments is impractical. Even when focusing on pure software-in-the-loop environments and in situations with high computing power (e.g., with the help of cloud computing), the complexity of test specification and result evaluation remains. Therefore, a method is proposed that allows for the automatic and meaningful reduction of the number of tests to be performed, and in this case, particularly allows for a focus on critical cases, critical errors, or critical combinations of errors.

[0035] Figure 1 A test environment with test systems 11 and 12 and the system under test or system to be tested 13 is shown. Environment 14 of system 13 is simulated. System to be tested 13 can exist as a final product, can be implemented as a prototype, or can be partially implemented as a simulation, particularly as hardware-in-the-loop, software-in-the-loop, processor-in-the-loop, or a combination thereof.

[0036] Test systems 11 and 12 include component 11, which includes a computer-implemented machine learning system and can automatically define or generate test cases including errors to be introduced. Furthermore, test systems 11 and 12 include component 12, which can receive test cases including errors to be introduced in step 111. In steps 112 and 113, test system component 12 feeds input variables corresponding to the test cases to the system under test via interfaces 101 and 102, respectively. Similarly, in step 114, test system component 12 feeds errors corresponding to the received test cases to the system under test.

[0037] In the system under test 13, paths, such as software paths and / or functional paths, are shown, which pass through function blocks 131 to 139 via input interfaces 101, 102, and 103 of the system under test and are delivered to output interfaces 104 and 105 of the system under test. In this example, in step 114, errors from test system component 12 are introduced into the paths located between input interface 102 and block 133, and between block 132 and block 136, respectively.

[0038] The environment simulation 14 of system 13 receives variables output via output interfaces 104 and 105 of the system under test at its input interfaces 106 and 107. The environment simulation 14 outputs output variables via its output interface 108, which are received by the system under test 13 at its input interface 103.

[0039] In this way, the system behavior of the system under test 13 can be examined under specific (here, simulated) environmental conditions and for specific test cases fed from the test system component 12. In particular, it can be examined whether the test cases, including the correspondingly introduced errors, lead to faulty behavior of the system under test 13.

[0040] In order to perform the inspection, test system components 11 and 12 may receive variables output from the system under test 13 via the output interface 105 of the system under test 13 in steps 115 and 116, respectively, and receive variables output from the simulation of the environment 14 via the output interface 109 of the simulation in steps 117 and 118, respectively.

[0041] Here, the errors are introduced by test systems 11 and 12, particularly under various environmental conditions of environment 14 and for various operating states or modes of operation of the system under test 13. Test systems 11 and 12 analyze the results of the tests, particularly regarding the impact of the tests on the functional safety of system 13, and especially check whether system 13 complies with predetermined safety requirements, or whether system 13 exhibits faulty behavior in this regard.

[0042] Based on the inspections and the introduced errors, the machine learning systems of test systems 11 and 12 learn which errors, error combinations, error attributes, or combinations of error attributes are likely to cause malfunctions in the system. For example, rewards can be assigned to errors, error combinations, error attributes, or combinations of error attributes in the learning system if these errors, error combinations, error attributes, or combinations of error attributes lead to an increased deviation from safety requirements. Preferably, the probabilities of errors, error combinations, error attributes, or combinations of error attributes are learned. The environmental conditions, system state, or operating mode of system 13 can also be considered for the learning method and error selection or error generation.

[0043] Based on the learned probabilities from one or more previous fault injections and test evaluations, the next test cycle is determined or adapted. This is preferably done in such a way that the selected or generated errors (particularly for the selected environmental attributes, system states, and / or operating modes of system 13) result in a higher probability of safety-related fault behavior.

[0044] Error attributes related to the learning method and the error selection or error generation may, for example, include:

[0045] -The location in the system where one or more errors are introduced.

[0046] - The type of error.

[0047] -The incorrect value or magnitude

[0048] - Incorrect combination.

[0049] Here, these errors can be implemented, for example, as errors in the time domain, such as signal delays or delays in function execution or changes in repetition rate. Instead of executing the function in a 10ms clock cycle, the function can be executed once every 100ms. Errors in the time domain can also be implemented as unintended interruptions; for example, a function interruption can occur in a time slot different from the planned or expected time slot.

[0050] The error can also be implemented as an error related to the value of a variable or parameter, such as a signal value being multiplied by a specific factor that is less than or greater than one.

[0051] Errors can preferably be introduced into the described method through mutation testing, in which portions of the software code of system 13 are replaced with modified (mutated) software code. For example, symbols, numeric values, or logical relationships in the code can be changed.

[0052] The described method can repeatedly perform the steps of error injection, system behavior evaluation or inspection, and learning in a loop. Here, in each repetition, in order to discover faulty behaviors, the most likely or the most probable remaining errors or combinations of errors that have not yet been tested can be selected.

[0053] In a particularly advantageous configuration, the test termination criterion can also be determined based on the learned probabilities. For example, the method can be repeated until it is determined that the probability of discovering other safety-critical errors or error combinations is sufficiently low, particularly below a specific probability threshold. In this case, the test algorithm or its learning algorithm then, for example, learns that, under the considered operating mode, system state, or environmental conditions, the following unintroduced errors or error combinations are unlikely to occur, for which the considered safety requirements are expected to be unmet with a sufficiently high probability. Therefore, it is no longer worthwhile to expend effort on further testing, and the automated test run automatically terminates.

[0054] The described test method can be particularly advantageous for control or regulation systems of electrical, hydraulic, or pneumatic machines and actuators. For example, this could be a control or regulation system for a vehicle or robot, such as a system for an electrical drive (high voltage or low voltage) or other drive system, or a controller for a light, luggage compartment, or door, for example.

[0055] Also advantageously, the test method can be used in driver assistance systems in vehicles and at least partially autonomous systems of vehicles or robots. In control or regulation systems for autonomous or highly automated vehicles, such methods can be used, for example, to detect robustness issues, such as failure scenarios in which the primary or backup system of the vehicle's autonomous functions fails.

[0056] Advantageously, the system under test exists here as a physical prototype or as a combination of an existing physical subsystem and a simulation subsystem. For example, the software of the system under test may be available, and electrical or electronic components may be simulated.

[0057] The system to be tested is preferably an embedded system.

[0058] Preferably, the safety requirements to be tested are clearly defined and exist in a machine-readable manner. For example, safe and unsafe system states or safe and unsafe system behaviors can be defined. For example, an unsafe system behavior can be defined for the vehicle's drive system if the driving torque exceeds 50 Nm for more than 200 ms. Such an exceedance is then identified as a faulty behavior of the system under test during the inspection.

[0059] Preferably, the test is performed under defined system states and operating modes. For example, the vehicle's drive system can be tested under the operating state of "system startup". Preferably, different safety requirements can be set for different system states and operating modes.

[0060] The error can be generated and introduced in various ways within the described method. The error can be introduced via a computer program specifically designed for error injection, or it can be introduced using hardware specifically designed for error injection.

[0061] Because the described testing method learns which errors or combinations of errors, possessing which error attributes, are promising—that is, which have a higher probability of causing malfunctioning behavior in system 13—it is not necessary to pre-introduce a fixed set of errors or combinations of errors. The method can begin error injection with a predetermined or randomly selected set of errors or combinations of errors. Errors or combinations of errors introduced in subsequent steps are then selected or generated based on the learned probabilities.

[0062] The machine learning system can use various learning methods or algorithms.

[0063] In a preferred configuration, a genetic algorithm is used. This algorithm computes a fitness function based on an initial population with error attributes. According to the fitness function, the algorithm searches for promising errors from the parents or generates promising errors from the offspring. This process can be repeated until no further improvement is observed across multiple generations.

[0064] For example, the initial population of the drive system can be given by a supply voltage of 43V, a torque request of 72Nm, an operating mode of "normal operation", and an error injection under SPI command 21, and the fitness function can be defined as an increase in undesirable torque.

[0065] In another preferred configuration, the machine learning system may be implemented using one or more neural networks, which learn which errors or combinations of errors or which error attributes or combinations of error attributes lead to the system’s faulty behavior with what probability.

Claims

1. Computer-implemented method for testing a system (13), in particular an embedded system, characterized by the following steps: introducing a first error into the system (13), observing a system behavior of the system after the introduction of the first error and subsequently checking whether a first failure behavior of the system (13) occurs, learning, by a machine learning system, a probability of a failure behavior of the system (13) upon introduction of an error into the system (13) depending on properties of the introduced error, from the first error and from the occurrence of the first failure behavior, wherein the machine learning system comprises an evolutionary algorithm, a genetic algorithm or a neural network, introducing a second error into the system (13) depending on the learned probability for the first error, and observing a system behavior of the system (13) after the introduction of the second error and subsequently checking whether a second failure behavior occurs, wherein the second error is selected or generated by the machine learning system such that the second error leads to a failure behavior with a higher probability. The error relates to a time sequence in the system (13), in particular a signal, a time point of a function call or a function interruption or a repetition rate, or the error relates to a value in the system, in particular a value of a signal or a parameter. The properties of the introduced error comprise a location in the system where the error is introduced, or a type of the introduced error, or a value or amplitude of the introduced error, or a combination of the introduced error. The machine learning system learns the probability depending on environmental conditions, system states or operating modes of the system (13). The error is introduced into the system (13) by means of software for error injection or by means of hardware for error injection. The error is introduced into the system (13) by changing or replacing a part of a software code of the system (13). The system behavior is checked based on at least one predetermined machine-readable safety requirement, and the failure behavior is determined if the system behavior does not satisfy the at least one safety requirement.

2. The method of claim 1, wherein, The system (13) is at least partially a physical prototype, at least partially implemented as hardware-in-the-loop, at least partially implemented as software-in-the-loop and / or at least partially implemented as processor-in-the-loop.

3. The method according to any of the preceding claims, characterized in that, An environment (14) of the system (13) is emulated for the test.

4. The method according to any of the preceding claims, characterized in that, The system (13) has hardware components and software components.

5. The method according to any of the preceding claims, characterized in that, The system (13) is a control system or a regulation system, in particular for an electrical, hydraulic or pneumatic device, a machine or an actuator of such a device.

6. The method according to any of the preceding claims, characterized in that, The system (13) is designed for regulating or controlling a function of a vehicle or a robot.

7. The method according to any of the preceding claims, characterized in that, The system (13) is a driver assistance system in a vehicle, or a control or regulation system which controls or regulates a driving function in a highly automated vehicle or an autonomous vehicle.

8. The method according to any of the preceding claims, characterized in that, Further errors are repeatedly introduced in a loop depending on the learned probability, and a further learning of the machine learning system is performed depending on the introduced further errors and depending on failure behaviors determined for the introduced further errors.

9. The method according to any of the preceding claims, characterized in that, ​ 10. The method according to any of the preceding claims, characterized in that, ​ 11. The method according to any of the preceding claims, characterized in that, ​ 12. The method according to any of the preceding claims, characterized in that, ​ 13. The method according to any of the preceding claims, characterized in that, ​ 14. The method according to any of the preceding claims, characterized in that, ​ 15. The method of claim 14, wherein, determining a test end criterion or ending the method depending on the machine learning system or on the learned probabilities.

16. The method of claim 15, wherein, ending the method if the probability of other faulty behavior due to the introduction of other errors does not exceed a certain threshold.

17. The method according to any of the preceding claims, characterized in that, adapting the system (13) depending on the results of the test, in particular ensuring a transition of the system (13) to a safe state in case of a determined faulty behavior.

18. A test system (11, 12) designed to perform the method according to any of the preceding claims.

19. A computer program product designed to perform the method according to any of claims 1 to 17.

20. A machine-readable storage medium having the computer program product according to claim 19.

Images