Method for evaluating software components in a SiL environment

Abstract

The present invention relates to a method for evaluating software components in a Software-in-the-Loop (SiL) environment. The present invention relates to a method for evaluating software components in a Software-in-the-Loop (SiL) environment (201), wherein a target hardware having at least one target hardware component is mimicked by the SiL environment having at least one corresponding software component, wherein both the target hardware and the SiL environment are exposed to a test condition, wherein during the exposure of the target hardware and the SiL environment to the test condition, output data is generated not only by the target hardware but also by the SiL environment respectively, and the output data of the target hardware is compared with the output of the SiL environment, and wherein the software component is evaluated based on the comparison.

Description

Technical Field

[0001] The present invention relates to a method for evaluating software components in a Software-in-the-Loop environment, and to a computing unit and a computer program for performing the method. Background Art

[0002] Even before the target hardware is available, Software-in-the-Loop (SiL) simulation represents a possibility to test software for complex application scenarios under development, which software is to be implemented with specific hardware in its later regular operation. For example, the software to be tested may be control software for machines, devices, etc.

[0003] In the process of such a Software-in-the-Loop (SiL) simulation, the software to be tested is implemented in a suitable computing unit and integrated into an imitation of the following technical system or environment: in which technical system or in which environment the software is to be used in its later regular operation. It is ensured here that the imitation of the technical system is good enough so that the results are as realistic as possible. Summary of the Invention

[0004] According to the present invention, a method for evaluating software components in a SiL environment, a computing unit, and a computer program for performing the method are proposed. Advantageous configurations are the subject of the subsequent description.

[0005] The present invention applies measures to evaluate software components in a SiL environment by comparing output data generated not only by the target hardware but also by the SiL environment during the exposure of the target hardware and the SiL environment to the same test situation, that is, online or at runtime. No post hoc or offline evaluation is required. For example, such output data may be measurement values, sensor values, control values (Ansteuerwerte), etc., which values are generated during the operation of the SiL environment and the target hardware.

[0006] The software component is used to imitate the target hardware component. Such a target hardware component can be, for example, an integrated circuit (IC, ASIC, microprocessor, microcontroller, etc.), a sensor, and an actuator (e.g., a microelectromechanical system, MEMS). Through evaluation, it can be ascertained, in particular, how precisely or well the software component corresponds to the target hardware component, or how precisely it imitates. For example, if these output data are consistent within a pre-given tolerance threshold, the software component can be evaluated as error-free, for example, and evaluated as suitable for use in the SiL environment. However, if these output data deviate from each other by more than the pre-given tolerance threshold, this indicates, in particular, that the software component still has errors and is not yet suitable for use in the SiL environment.

[0007] If a sufficiently good or precise imitation is ascertained, the software component can be adopted for any SiL environment.

[0008] The present invention is suitable for different software components to be tested, especially for software components for implementing safety-critical vehicle functions. For example, the software component can be arranged for functions from the field of autonomous or highly autonomous driving (highly automated driving, HAD), for vehicle motion control (VMC), for driver assistance systems such as adaptive cruise control (ACC) (advanced driver assistance system, ADAS), etc. In such fields, a software component qualitatively evaluated as good can be particularly advantageously used to improve safety or for use within the scope of release argumentation.

[0009] Within the scope of the present invention, in particular, an evaluation unit can be adopted, which is connected in a data-transmitting manner not only to the target hardware but also to the SiL environment, and receives output data from the target hardware and the SiL environment. The SiL environment can be implemented completely or partially in the evaluation unit and / or a separate simulation calculation unit. Suitably, the evaluation unit is configured as a computing unit with real-time capabilities. "With real-time capabilities" means that a certain process such as a calculation operation, a task, or a data transmission is executed in a guaranteed manner within a pre-determined time.

[0010] Preferably, the target hardware component is in a vehicle (hereinafter the test vehicle). Suitably, the test vehicle then actually operates during the evaluation, however not on-site or in the real world, but particularly suitably in a pre-given test environment, for example on a so-called real driving test bench or on a suitable open space (Freifläche) (for example a test site not accessible to the public). Such a test environment can suitably be pre-given not only with hardware but also with software. For example, the test vehicle can operate in a test bench or simulator, by means of which, as a test situation, the driving of the test vehicle on a real road can be simulated. In addition, the on-site or such a road can be simulated in the form of software, in such a way that, for example, the corresponding test situation in-vehicle network signal is fed into the in-vehicle data network of the test vehicle. The test situation in-vehicle network signal is in particular a sensor signal, in particular an environmental sensor signal, such as for example a camera signal, a radar sensor signal, a GPS / GNSS signal, etc. This implementation is also referred to as Vehicle-in-the-Loop-Simulation and / or Hardware-in-the-Loop-Simulation. In such a Hardware-in-the-Loop-Simulation, in particular the embedded system (for example a control device) of the test vehicle is connected via its input and output to the corresponding simulation, which serves as an imitation of the real environment of the system. In the case of Vehicle-in-the-Loop, for example in a test bench, the entire test vehicle with its sensors and actuators is suitably connected to the corresponding simulation or imitation of the real environment. Preferably, the same test situation in-vehicle network signal is also fed into the SiL environment.

[0011] "Exposing the target hardware in a test vehicle to the test situation (Der-Testsituation-Aussetzen)" thus includes operating the test environment according to the test situation, in particular includes using the test situation manipulation signals to control the test bench and feeding the test situation in-vehicle network signals into the in-vehicle data network of the vehicle. "Exposing the SiL environment to the test situation" in particular includes feeding the test situation in-vehicle network signals into the SiL environment. Here, it should be noted that in addition to the test situation in-vehicle network signals for the in-vehicle data network of the vehicle, the test situation in-vehicle network signals for the SiL environment also include other test situation in-vehicle network signals, and the other test situation in-vehicle network signals represent the results of the test bench control. Belonging to it are in particular all in-vehicle network signals associated with the vehicle movement, such as GNSS / GPS position, speed signal, acceleration signal, etc. When the test vehicle is being tested on the test bench, some signals, such as GNSS / GPS position, speed or acceleration, are appropriately fed in by simulation, while when the test vehicle is set up in a suitable test open space, these signals are in particular fed in directly by the test vehicle sensors.

[0012] For example, the required signal generation of the test situation manipulation signals and / or the test situation in-vehicle network signals can be carried out in the computing unit in which the SiL environment is also implemented, for example in the evaluation unit or the simulation computing unit. Preferably, the signal generation computing unit is connected to the target hardware, the SiL environment and the test environment such as the test bench in a data-transmitting manner. Preferably, this connection is realized via a communication system with real-time capabilities (such as, for example, the FlexRay bus or the so-called real-time Ethernet), for example based on the network protocols UDP (User Datagram Protocol) or TCP / IP (Transmission Control Protocol / Internet Protocol).

[0013] Preferably, the test situation is generated according to the following on-site data: the on-site data are collected in the case of using the target hardware. These on-site data are in particular collected on-site, that is to say in the real world under real conditions. In particular, as these on-site data, the in-vehicle network signals of one or more on-site vehicles are detected, and the on-site vehicles are running on-site. Here, the test vehicle can, for example, appropriately operate itself as such an on-site vehicle to collect data. Similarly, for example, on-site vehicles of the same type as the test vehicle can be put into use as such on-site vehicles. Thus, the present method provides the possibility of evaluating software components while on the test bench but using real situations and the resulting data.

[0014] Preferably, at least one test situation is generated from virtual driving profiles (Fahrprofilen) and / or test cases. The test cases suitably describe the simulated, virtual environment in which the test vehicle operates, such as traffic or other road users, pedestrians, traffic signs, traffic lights, etc. For example, by means of speed and steering angle profiles and the like, the virtual driving profile predefines in particular the following journey or route in the simulated, virtual environment: the journey or route that the test vehicle and the SiL environment are to drive out of. The virtual driving profile is in particular calibrated (abgeglichen) using the test cases or generated in relation to one another.

[0015] In a particularly advantageous embodiment of the invention, the virtual driving profile and the test cases are predefined based on real-world data. Thus, suitably, the following test cases and virtual driving profiles are generated based on data collected in reality: the test cases and virtual driving profiles define the simulation environment of the test vehicle.

[0016] Suitably, at a first point in time, real-world data is collected on-site or in the real world. At a second point in time that is temporally after the first point in time, one or more test situations are generated based on the collected real-world data, in particular by means of a virtual driving profile and test cases. Furthermore, at the second point in time, a corresponding simulation of the on-site or real world is suitably generated based on the virtual driving profile and test cases. At a third point in time that is temporally after the second point in time, the target hardware and the SiL environment are exposed to the test situation.

[0017] Advantageously, generating a test situation for a vehicle includes one or more of the steps described subsequently.

[0018] The first step includes: collecting real-world data in one or more on-site vehicles that operate on-site. The on-site vehicles can in particular be of the same type as the test vehicle. In particular, in order to collect real-world data, the on-site vehicles each operate on a predefined route in a defined environment. For example, it is conceivable to collect real-world receipts by means of an on-site vehicle that operates on-site on the same route several times, or to collect real-world data by means of multiple vehicles that operate on-site on the same route once or several times. Here, the aim is to collect as much real-world data as possible in different situations. The collected real-world data on the one hand in particular describes the environment and, for example, includes road profiles, GPS coordinates, identified traffic obstacles, pedestrians, other vehicles, traffic signs, traffic lights, etc. On the other hand, the real-world data in particular describes the driving performed on-site itself and, for example, includes a speed profile.

[0019] In a second step, test data is advantageously extracted from the collected field data and the test data is processed. For example, the raw sensor data is evaluated in order to be able to identify underlying traffic situations, such as "pedestrian crossing the road". For this purpose, machine learning methods can in particular be used.

[0020] In other steps, test cases are preferably generated according to the extracted test data and according to predefined test criteria. For example, the predefined test criteria can require that certain driving maneuvers, traffic obstacles, traffic signs, etc. be included.

[0021] Optionally, test cases can be selected from all the generated test cases. In particular, the test cases are selected as critical test cases: the critical test cases use the software component to be evaluated. For example, if a software component is to be evaluated in combination with pedestrian recognition, then for testing, a test case of the following kind is appropriately selected from these test cases: a pedestrian is also included in the test case. Thus, numerous test cases for extremely different requirements can be stored in a once-created manner for later use. In later use, then only specific critical test cases are selected and tested. Thereby, the test duration is kept as short as possible.

[0022] Furthermore, according to the extracted test data and according to predefined driving criteria, virtual driving profiles are advantageously also generated. In particular, a predefined route driven in the field is used as a reference driving profile. Appropriately, the GPS coordinates of the reference driving profile can be used in order to generate the basic structure for the virtual driving profile. In particular, the predefined test conditions of the test cases (such as predefined driving maneuvers) can be related to this basic structure. Appropriately, the field data or test data is searched for according to the GPS coordinates of the relevant test conditions. The basic structure is thus appropriately filled with adapted field data.

[0023] Preferably, if the evaluation is good, the software component is certified. For example, the certification can be carried out by means of a so-called blockchain. The certified software component can in particular be released for use in a SiL environment.

[0024] The computing unit according to the invention (such as an evaluation unit) is in particular set up in program technology to carry out the method according to the invention.

[0025] It is also advantageous to implement the method according to the invention in the form of a computer program or a computer program product having program code for performing all method steps, since this results in particularly low costs, especially if the control device used for the implementation is also used for other tasks and thus already exists. Suitable data carriers for providing the computer program are in particular magnetic, optical and electrical memories, such as for example hard disks, flash memories, EEPROMs, DVDs and the like. It is also possible to download the program via a computer network (Internet, Intranet, etc.) ("Software over the air" or "Firmware over the air").

[0026] Other advantages and configurations of the invention result from the description and the attached drawings. Description of the Drawings

[0027] The invention is schematically illustrated on the basis of embodiments in the drawings, and the invention is described below with reference to the drawings.

[0028] Figure 1 A preferred embodiment of the method according to the invention is schematically shown as a block diagram.

[0029] Figure 2 A simulation computing unit is schematically shown, which can be operated according to a preferred embodiment of the method according to the invention.

[0030] Figure 3 A test vehicle in a test environment is schematically shown, which can be operated according to a preferred embodiment of the method according to the invention. Detailed Description of the Invention

[0031] The method according to a preferred embodiment of the invention is subsequently described with respect to Figures 1 to 3 Herein, in Figure 1 a preferred embodiment of the method according to the invention is schematically shown as a block diagram. In Figure 2 a simulation computing unit is schematically shown, and in Figure 3 a test vehicle in a test environment is schematically shown, and the simulation computing unit and the test vehicle can be operated according to a preferred embodiment of the method according to the invention.

[0032] In the following, the following situation is observed by way of example: The software component is an imitation of a computing unit (for example, a microcontroller) for pedestrian recognition, which evaluates the data of the vehicle's sensors (for example, a camera) and performs object recognition therein in order to be able to recognize pedestrians in the vehicle's environment.

[0033] Here, in the illustrated example, a (optional) data acquisition method occurs before the actual evaluation method described in steps 106 to 110, and this data acquisition method is described in combination with steps 101 to 105. The data collected in this data acquisition method can in particular also be obtained in another way or is already available.

[0034] In step 101, on-site data of the test area is collected in at least one on-site vehicle, in particular in such a way that in-vehicle network signals are detected and stored on the in-vehicle data network (such as CAN bus, FlexRay bus, etc.) of the on-site vehicle or directly at the computing unit (control device). The on-site data is generated, for example, by sensors such as cameras, radars, etc., by actuators such as accelerator pedals, steering wheels, etc., and by the control device, and describes, for example, road profiles, GPS coordinates, speed profiles, identified pedestrians, traffic obstacles, traffic signs, traffic lights, etc.

[0035] Preferably, the on-site data is collected here multiple times on a pre-given route. This means that at least the same on-site vehicle runs on this route multiple times, or multiple on-site vehicles each run on this route at least once.

[0036] Suitably, the test vehicle is used as at least one on-site vehicle for data acquisition, or the one or more on-site vehicles are of the same type as the test vehicle. Thus, the on-site data is compatible with the test vehicle.

[0037] Through this step 101, a virtual map is obtained, and the virtual map contains the data that appears in the test vehicle for the test area (such as a pre-given route).

[0038] In step 102, test data is extracted from the collected on-site data and the test data is processed. For example, the raw sensor data is evaluated in order to be able to identify basic traffic situations, such as "pedestrian crossing the road". For this purpose, in particular, machine learning methods can be used.

[0039] In step 103, based on the extracted test data, multiple test cases are generated according to a pre-given test standard. These test cases respectively and appropriately describe the following virtual environments: the software component to be tested can be exposed to the virtual environment. The test standard defines the (framework) conditions to be covered by the test. In particular, the test standard pre-gives certain driving maneuvers, traffic obstacles, traffic signs, etc. According to this test standard, the generation of test cases can be carried out especially automatically. For example, such a test standard can include the following situation: in this situation, a pedestrian crosses the road in front of a vehicle. Then, the following test data is searched for: in the test data, the pedestrian is in the environment of the corresponding on-site vehicle and, for example, crosses the road in front of the corresponding on-site vehicle. Therefore, the following (true) on-site data can be used to evaluate the software component: the (true) on-site data has been detected by the sensors (such as cameras or radar sensors) of the corresponding on-site vehicle in step 102 and relates to the corresponding situation of the pedestrian performing the crossing.

[0040] As long as the number of generated test cases is too large, key test cases can be selected from the multiple generated test cases in step 104, and these key test cases are then actually tested later for evaluating the software component. These test cases especially include such test cases: the test cases can be implemented not only in the simulation but also by the simulated test environment 400 (to be further elaborated later). For example, driving maneuvers that cannot be reproduced at the test bench can be filtered out here.

[0041] In step 105, virtual driving profiles are also generated using the extracted test data. These virtual driving profiles especially pre-give the following routes or paths: the routes or paths to be traced during the subsequent evaluation of the software component. The virtual driving profiles are especially calibrated using the test cases or generated based on each other. For example, these virtual driving profiles thus mimic the following route: in this route, according to the test case, a pedestrian crosses the road in front of a vehicle.

[0042] For example, first, in step 101, the GPS coordinates of the route traveled by the vehicle are pre-given as a reference driving profile to generate a basic structure or data frame. The basic mechanism is gradually filled with test data to create a virtual environment.

[0043] The test cases and the virtual driving profiles represent the following pre-given test situations: the target hardware and the SiL environment are exposed to the test situations. For example, the following route is adjusted: in this route, a pedestrian crosses the road in front of the corresponding test vehicle. For evaluation, the output data generated by the software can be compared with the output data of the target hardware here.

[0044] In steps 106 to 108, software-in-the-loop simulation is prepared and corresponding simulation hardware is set up.

[0045] In step 106, the software component to be tested is integrated into the simulation computing unit. Such a simulation computing unit is schematically shown in Figure 2 and is labeled 200.

[0046] The SiL environment is labeled 201. The SiL environment 201 especially includes the software component to be evaluated.

[0047] Via this environment, the software or the simulation computing unit can be connected to a remote computing unit 202, for example, connected to a server.

[0048] The simulation computing unit has multiple components or modules, such as a module 203 for test condition generation, a module 204 for quality assessment, a vehicle module 205 with a vehicle model, an environment module 206 with an environment model, and a driver module 207 with a driver model. In addition, a module 208 for visualization, a module 209 for navigation, and a module 210 for measurement and calibration can be set up. Via the virtual network 211, virtual control devices 212 and 213 can be simulated. In particular, through the respective components or modules 201 to 213, other components that do not exist in the test vehicle can be incorporated into the overall simulation, such other components as a virtual parking control device or an electric brake booster (iBooster).

[0049] In step 107, the simulation computing unit 200 is integrated into the test vehicle, connected to the target hardware of the test vehicle, and the test vehicle is integrated into the simulated test environment.

[0050] In step 108, the components of the simulation computing unit and the test vehicle are connected to the evaluation unit in a data-transmitting manner.

[0051] In Figure 3 a test vehicle 300, such a test environment 400, and such an evaluation unit 500 are schematically shown.

[0052] The test vehicle 300 includes an in-vehicle data network 301 (such as CAN, FlexRay, or Ethernet), at which control devices 302, 303, and sensors such as a radar unit 304 and a camera unit 305 are connected, for example. It should be understood that other components, such as other control devices, sensors, actuators, etc., can also be connected at the in-vehicle data network 301. In addition, the simulation computing unit 200 is connected to the in-vehicle data network.

[0053] For example, the recognition software can be implemented in the control device 302. The recognition software evaluates the sensor data of the camera unit 305 for pedestrian recognition. Depending on the test scenario, the simulation computing unit 200 provides these sensor data as test situation in-vehicle network signals to the control device 302 in such a way that these sensor data are fed into the in-vehicle data network 301. In parallel, the sensor data are also provided to the SiL environment 201.

[0054] The test environment of the test vehicle 300 is denoted by 400 and includes a test bench 401 and a test bench control unit 402 for controlling the test bench 401. In addition, monitors or displays 403 and 404 are provided. For example, the test bench control unit 402 is connected to the test bench 401 based on the protocol TCP / IP (Transmission Control Protocol / Internet Protocol). The connections to the displays 403, 404 can be made via an interface according to "Digital Visual Interface (DVI)".

[0055] In particular, depending on the virtual driving profile, in particular by receiving test situation in-vehicle network signals from the simulation computing unit 200 or the evaluation unit 500, the test bench control unit 402 is controlled. The test bench control unit 402 can control the test bench 401 and the displays 403 and 404 such that the driving of the test vehicle 300 can be simulated according to the virtual driving profile.

[0056] The test environment 400 in particular represents a vehicle-in-the-loop simulation for the test vehicle 300. With the test environment 400, the environment of the test vehicle 300 can be simulated as detailed as possible.

[0057] Alternatively, the test environment 400 can preferably also include a suitable test open space on which the test vehicle 300 can move freely. In the case where a suitable test open space is used as the test environment 400, the control of the test bench 401 is suitably only cancelled in the test bench control unit 402, and the control of the displays 403, 404 correspondingly remains.

[0058] With the aid of the test environment 400, for example, the driving of the test vehicle 300 is imitated or simulated according to a virtual driving profile, in which a pedestrian crosses the road. The corresponding signals of the camera unit 305 or the radar unit 304 are fed by the simulation computing unit 200 as test situation in-vehicle network signals into the in-vehicle data network of the test vehicle. Based on the in-vehicle data network, the control device 302 will generate corresponding output signals.

[0059] On the monitor 404, for example, an image or video can be presented to the driver, and the image or video was detected as in-vehicle data in the corresponding vehicle on site in step 101.

[0060] The evaluation unit 500 is configured as a computing unit with real-time capabilities and is in a data-transmitting connection via a real-time capable communication system with the simulation computing unit 200, the components of the test vehicle 300, and the test bench control unit 402. For example, the connection between the evaluation unit 500 and the simulation computing unit 200 and the components of the test vehicle 300 can be based on the UDP (User Datagram Protocol). The connection between the evaluation unit 500 and the test bench control unit 402 can also be based on UDP, for example.

[0061] If the test build shown in Figure 3 is prepared in accordance with steps 106 to 108, then software-in-the-loop simulation is performed in step 109.

[0062] With the aid of the test environment 400, the corresponding driving of the test vehicle 300 is simulated in the simulated virtual environment here, that is, the target hardware is exposed to test conditions.

[0063] At the same time, the SiL environment 201 is also exposed to this test condition. As long as real-time capable operation is required for this, the SiL environment 201 can be implemented in the real-time capable evaluation unit 500. In particular, the simulation computing unit 200 and the evaluation unit 500 can also be implemented in the same computing unit.

[0064] During the simulation process, data is generated by the simulation computing unit 200 or the implemented software components and by the target hardware components of the test vehicle 300, such as measurement values, control data for actuators, etc. In particular, during real-time or during the period when the target hardware and the SiL environment are exposed to the test condition and as long as the target hardware and the SiL environment are exposed to the test situation, these data are received and directly evaluated by the evaluation unit 500 during execution. In addition, the evaluation unit 500 or the simulation computing unit 200 controls the test bench control unit 402 with test condition control signals.

[0065] In step 110, the evaluation unit 500 evaluates the received output data and evaluates the implemented software components online in real-time and during the test run. For this purpose, algorithms or evaluation algorithms are implemented in the evaluation unit 500. In particular, the received output data are compared with each other here, and based on the received output data, the individual software components are evaluated, especially qualitatively. The components whose evaluation is within a predefined range are certified by the evaluation unit 500 and are released for regular operation.

[0066] The evaluation unit 500 compares the output data of the simulation calculation unit 200 (that is, the result of SiL) with the output data of the test vehicle 300. These output data or results should ideally be the same. If these output data are not the same below the tolerance threshold, this especially indicates that these software components do not sufficiently imitate the target hardware components and the software components cannot be released yet.

[0067] With this method, therefore, an automatic evaluation or assessment of the software components to be tested can be achieved online and in real time during software-in-the-loop simulation.

Claims

1. A method for evaluating software components in a Software-in-the-Loop (SiL) environment (201), Among them, wherein a target hardware having at least one target hardware component is emulated by an SiL environment having at least one corresponding software component, and wherein the emulation includes: the software component emulating the functions of the target hardware component, wherein both the target hardware and the SiL environment are exposed to a test condition, and since the software component is included in the SiL environment, the software component is also subjected to the test condition, wherein, during the exposure of the target hardware and the SiL environment to the test condition, output data is generated not only by the target hardware but also by the SiL environment respectively, and wherein the output data of the SiL environment is generated by a software component that emulates the corresponding target hardware component to process the test condition, wherein the output data of the target hardware is compared with the output data of the SiL environment, wherein the software component is evaluated based on the comparison, wherein, if the software component is evaluated as suitable for the SiL environment through the evaluation, software under development is tested using the software component integrated in the SiL environment, such that the software component emulates the functions of the corresponding target hardware component to process the input provided by the software under development through the test.

2. The method according to claim 1, wherein During the exposure of the target hardware and the SiL environment (201) to the test condition, the same signal is fed to the target hardware and the SiL environment (201).

3. The method according to claim 1 or 2, wherein The target hardware is in a vehicle (300).

4. The method according to claim 3, wherein During the exposure of the target hardware and the SiL environment (201) to the test condition, the vehicle (300) runs in a pre-given test environment.

5. The method according to claim 4, wherein, During the exposure of the target hardware and the SiL environment (201) to the test condition, the vehicle (300) runs on a test bench or in a suitable test open space.

6. The method according to claim 3, wherein, The target hardware is exposed to the test condition by manipulating a test bench (400) with a test condition control signal and by feeding a test condition in-vehicle network signal into an in-vehicle data network (301) of the vehicle (300).

7. The method according to claim 3, wherein, The SiL environment (201) is exposed to the test condition by feeding a test condition in-vehicle network signal into the SiL environment (201).

8. The method according to claim 1 or 2, wherein The test condition is generated based on the following on-site data: the on-site data is collected when using the target hardware.

9. The method according to claim 1 or 2, wherein If the software component is evaluated as good enough, the software component is certified.

10. A device composed of a target hardware and a computing unit (200, 500), the device being configured to execute all method steps of the method according to any one of the above claims.

11. A computer program product, the computer program product including a computer program that causes the device according to claim 10 to execute all method steps of the method according to any one of claims 1 to 9.

12. A machine-readable storage medium having a computer program stored thereon, which causes the apparatus according to claim 10 to perform all the method steps of the method according to any one of claims 1 to 9.

Images