DE102010014720A1 - Method for verifying code of target program used for software for automotive electronics for engine, involves comparing output test variables corresponding to each program section of target program and program code - Google Patents

Abstract

A test plan is created for functional modules of source model (Q) for analyzing functional and worth-dependent association between output and input variables (AM,EM). The input/output test variables (ET-T,AT-T) from test plan (T) are assigned for each functional module. Each program section of target program (Z) is executed and input test variables are processed. The output test variables (AT-P-Z,AT-T) corresponding to each program section of target program and program code (P) are compared. The error in program section of target program is determined if comparison result is not affirmative.

Description

Technical area

The invention relates to a method for verifying a target program generated from a source model.

State of the art

The requirements in the automotive electronics, software for engine or other powertrain control devices or comfort control devices to create grow with increasing complexity. It is therefore pursued in the field of automotive electronics strategy to generate the software model-based using automatic code generation.

Due to the steadily growing functional complexity with regard to the safeguarding measures, this approach to software production also requires new innovative measures to cost-effectively address the generated ECU software with suitable rational instruments from the point of view of series commissioning and documentation effort.

Model-based ECU software usually consists of at least two parts. One part is filled in by the model software and traditionally contains the physical solutions for the application area and is developed by the functional developers and physically tested. The other part is called basic software and usually contains the operating system, diagnostics service functions and the driver parts, which could not be realized from the point of view of software generation or only with considerable and cumbersome modeling in the model world. The effort can be considered disproportionate to manually generated solutions.

Regardless of whether the software components have been created manually or automatically, they must be tested appropriately. In automotive electronics, a distinction is made here between model-based functional development using code generation and software creation and integration.

The software test, in connection with the automatic model-based code generation, should check and determine the freedom of the calculations between the model and the software transmitted on the control unit. In the process, errors in the tool chain or in the hardware of the microcontroller, which are often themselves still in the development process, can be detected.

So far, in the automotive electronics environment, the electronic control unit with a measurement and Verstellsystemanbindung, for example, via XCP in various versions equipped, made on the commercial measurement and adjustment systems, such as INCH, CANAPE, CalDesk, certain detection and manipulation options. The software tester uses this infrastructure to verify the flawless software function. The access to the model software and the resulting testability depend to a considerable extent on the measurement and calibration values provided by the model. The feature developer, who typically replicates Simulink physics, must provide extensive support for comprehensive and complete software protection, typically requiring additional overhead that goes far beyond what is functionally essential. Under the discrepancy between additionally required test modeling and physical functional necessity, the software tester is uninfluenceably dependent on the functional developer. The functional developer must perform tasks to build this test infrastructure, which will only pay off in the subsequent test process.

This requires the programmer software certain program parts that must always be performed or expected, so that the information-processing programs are supplied with information.

This claimed on the one hand, the system computational burden with work that would not be mandatory for the function of the ECU software.

On the other hand, additional effort must be expended within the model software (models) for this information access type to be supported by the test system. On the one hand, a mandatory modularization is necessary and on the other hand, a bypass modeling at the The output side of the modules is required to allow non-real-time injection of stimulus test vectors from previous modules.

This additional model-technical effort costs additional processor computation time and processor resources. The working time of the functional developer to generate the test infrastructure also requires increased effort, which is required only in the subsequent test phase.

From the DE 10 2004 014 290 A1 is a method for creating procedures for testing software that has been created from data flow models and that is subjected to automatic test conditions by means of a data processing device and an executable test case generator software.

The Tesffallgenerator software generates a test plan consisting of individual test cases for the software to be tested.

For each model block, test-relevant algorithms are implemented in the form of a test case algorithm and a traceback algorithm.

In each test case, a range of values for each of its input signals is assigned to a model block by the test case algorithm.

Each such range of values is tracked by the traceback algorithm in the system under test through the individual blocks to the inputs of the system under test. The results are checked and saved.

Object of the invention

The object of the invention is to provide a method for verifying a target program generated from a source model, which ensures a complete software-side functional test on the basis of model-based specifications.

Solution of the task

The object is achieved by a method according to claim 1.

Advantages of the invention

The inventive method takes into account the modularization of source model and target program for verifying the software. The modularization of the source model is also present in the target program in a sequential arrangement, so that individual function modules (models) of the source model can be localized as functions of the target program in the working memory and can be selected during the execution of the software under test conditions. It is thus possible to apply the test information (test vectors and associated output values) obtained module-by-module from the physically based source model for the modules of the target program. As complete a test coverage as possible can be achieved, whereby the code of the target program is tested in binary form on the target hardware. A connection to a hardware in the loop simulation environment is not necessary.

A source model can consist of several function modules as described. Alternatively, without subdivision modularization, the entire content of a source model corresponds to a functional module, but this complicates the organization of software development and testing. However, the method according to the invention can also be used without subdivision modularization.

In two steps, a program code, for example a C code, is generated from a preferably graphically supported development environment from the physically based source model, from which in turn the target program's binary code is generated. The physical function test of the models can be done with a suitable simulation at the level of the graphically supported development environment. Test vectors for the models can also be obtained from the models present in the development environment, for example DE 10 2004 014 290 A1 , are generated, wherein these test vectors are loaded in the target program on the target hardware at the corresponding processing position, so that a module-oriented based on the functions of the source program software test takes place.

The two-time generation can cause "translation errors" that can lead to a falsification of the respective program code. Furthermore, the handware, for example, a microcontroller of a controller, be faulty, which can lead to incorrect execution of the program code.

From these error sources, which may be present on the software and / or hardware side, result in erroneous calculation values of the output variables of the target program or possibly a non-execution of a target program part. To verify the target program for these sources of error, input test values for stimulation are written to the input variables of a modularized program part of the target program. The input test values are processed according to the program code during execution of the program part. At the end of execution of the program code, the output test values (i.e., output-side calculation results) of the output variables are read out. The input test values correspond to the test vectors generated from the source model.

Each readout output value (actual value) is compared with an output test value (setpoint) of the test plan. A successful verification, d. H. A flawless generation of the target program from the source model, is in a match within a previously set tolerance band of both values. If exact match is required, the bandwidth must be set to 0.

The input test values (stimulation) and output test values (results, setpoints) are generated using a test plan. The test plan includes an analysis of a functional and value-dependent mapping between the input variables and the output variables of a model-based function module. Such a method is for example in the DE 10 2004 014 290 A1 disclosed. An alternative test plan generation can be done from the calculation (simulation) of the models within the modeling platform. The test plan generation leads in each case to stimulations and setpoint values of the results, which enable the functional validation of the function module against the specifications, for example from a requirement specification request of the client.

The omission of the test infrastructure known from the prior art according to the invention makes it possible to use smaller and therefore more cost-effective processors. Furthermore, considerable labor and thus costs for generating a test infrastructure according to the prior art are saved by using a Verstellsystemschnittstelle.

In the generation of the target program, information, preferably in the form of a file, is advantageously produced, which documents the (local) position of the input variables and output variables in the working memory (RAM) of a microcontroller.

During the generation of the target program, information is created in the form of a file showing the relation, i. H. the relationship or mapping between the code of the autocode-generated source model and the program code of the target program is documented in the microcontroller.

The test plan defines the respective function modules to be tested, whereby from the information about the (local) position of the input variables and output variables and the information about the relation, i. H. the relationship or the association between the program code of the source model and the code of the target program, the processing position of the corresponding program part of the target program to be tested, d. H. whose start and / or end mark (start and destination addresses of the program part) is determined.

The initial marking represents the beginning of an execution of a program part, ie the call of the respective subroutine of the destination program. By determining the start of the execution of the respective program part, it is possible, before calling this program part, to write the corresponding variables (values of the excitation or stimulation test vector) to the respectively likewise localized memory cells before processing or calling the function, so that the program part of the target program, which corresponds to the functional module to be tested for which the test vector was determined, can be loaded with the corresponding values of the test vector. For this purpose, the processing of the processor of the microcontroller is stopped, so that the corresponding values can be written before further processing. The values are thus currently available for processing and can not be overwritten by other program parts.

Initial marking and / or end marking of a program part of the target program are read for this purpose in one or possibly several registers with program interruption function of the microcontroller. The microcontroller must have a technical prerequisite for interrupting the Program flow, which with the help of a (interrupt) register both the external processing control and the access to a random access memory (RAM) allows to read out or write variables. This is possible, for example, by means of a so-called OCDS (English chip debug system).

The end mark represents the end of execution of the program part, i. H. The time after which a value has been assigned to the output variable. This value is read out and compared with the corresponding comparison value from the test plan. The inventive method can also be used for performing integration tests. Here, the error-free integration of independently created subroutines is checked according to the architecture of the entire software. The arrangement and thus call order of the modules is checked here.

In an alternative embodiment of the method according to the invention, the target hardware on which the target program is to be executed can be replaced by a simulation environment. In this case, the target program is executed in a target environment simulating the controller, with the logical sequences that run on a controller designed in hardware when the target program is executed being simulated. The described test execution according to the invention takes place in the same way, wherein the control unit is designed as a program-technical entity, which carries out the process control. This uses the same information for the test. However, the target environment in this embodiment is not hardware, but simulative software on a non-embedded computing machine. The electronic program control / interruption unit required for an above-described application of the test method on a target hardware, which performs process control via the OCDS interface of a controller, for example, is replaced by a program instance, which, however, manages and processes the same qualitative data.

drawings

Show it:

1 : a schematic overview of the components involved in the process;

2 : a further schematic overview of the components involved in the method,

3 : The mapping of functionally created modules in the memory area.

The 1 shows a schematic overview of the components involved in the process. A source model Q comprises, for example, three model-based function modules F1, F2 and F3. These function modules F1, F2 and F3 of the source model Q are models created in a preferably graphically supported development environment (for example Simulink).

From the source model Q, a program code P is generated in step G. The program code P can be, for example, C or C ++ program code.

A program code P also comprises three program parts P1_P, P2_P, P3_P in this example. The program part P1_P corresponds functionally to the function module F1. Similarly, the program parts P2_P and P3_P correspond to the function modules F2 and F3.

In a further step, binary code of a target program Z is generated from the program code P for a selected target hardware with the aid of a cross-compiler. The target program Z comprises three program parts P1_Z, P2_Z, P3_Z, which are present sequentially, which is in 3 is shown in more detail. The program part P1_Z corresponds functionally to the program part P1_P.

Likewise, the remaining program parts P2_Z, P3_Z of the target program Z correspond to the program parts P2_P, P3_P of the program code P functionally.

The function module F1 comprises an input variable E1_F1 and two output variables A1_F1, A2_F1.

The function module F2 comprises three input variables E1_F2, E2_F2, E3_F2 and an output variable A1_F2.

The function module F3 comprises two input variables E1_F3, E2_F3 and two output variables A1_F3, A2_F3.

Due to the respective generation G, the program parts P1_P, P2_P, P3_P of the program code P and the program parts P1_Z, P2_Z, P3_Z of the target program Z include corresponding input and output variables Function module 1 Function module 2 Function module 3 program code target code program code target code program code target code inputs E1_P1_P E1_P1_Z E1_P2_P E1_P2_P E1_P2_P E1_P2_Z E2_P2_Z E3_P2_Z E1_P3_P E2_P3_P E1_P3_Z E2_P3_Z outputs A1_P1_P A2_P1_P A1_P1_Z A1_P1_Z A1_P2_P A1_P2_Z A1_P3_P A2_P3_P A1_P3_Z A2_P3_Z

For the function module F1, a test plan T1 was created based on the models of the source model. The test plan T1 comprises an analysis of a functional and value-dependent assignment between the input variables E1_F1 and the output variables A1_F1, A2_F1 of the function module F1. The test plan can be created automatically, program-based. Furthermore, it can be generated by empirically determined stimulation in connection with the calculation methods of the model-based development environment.

Furthermore, the test plan T1 contains a determination of permissible value ranges of the input variables E1_F1 and the output variables A1_F1, A2_F1. In addition, the test plan T1 comprises an input test value ET1_T1 for the input variable E1_F1 and an output test value AT1_T1 for the output variable A1_F1 and an output test value AT2_T1 for the output variable A2_F1.

Likewise, a test plan T2, T3 was created for each of the function modules F2, F3.

The method according to the invention carries out a verification of the target program Z.

For this purpose, at the beginning of the execution of the program code of a program part P1_Z, P2_Z, P3_Z, for example the program part P2_Z, the input variable E1_P2_Z the input test value ET1_T2, the input variable E2_P2_Z the input test value ET2_T2 and the input variable E3_P2_Z the input test value ET3_T3 assigned. Thereafter, the program code of the program part P2_Z is executed and in this case the input test values ET1_T2, ET2_T2, ET3_T2 are processed.

At the end of execution of the program code of the program part P2_Z, an output test value AT1_P2_Z of the output variable A1_P2_Z is read out.

The output test value AT1_P2_Z is compared in a comparison unit V with the output test value AT1_T2. If the two values match, there is no erroneous generation G of the program code of the program part P2_Z of the target program Z from the program part P2_Q of the program code P of the source model Q. Otherwise, there is a faulty generation G or software and / or hardware a mask problem on the possibly still in development microcontroller chip.

It should be noted that it is quite legitimate to use the output variables in the signal path of the previously arranged function modules as input variables of the module to be tested.

Decisive here is that with the obtained from the information of the source model test vectors for the individual function modules, a test of the corresponding program parts of the target program, which are stored sequentially in the program memory and processed by the processor of the microcontroller, can take place. The writing of the corresponding values of the test vector takes place on global variables of the correspondingly localized memory space before the execution of the respective program part, wherein the execution of the processor is temporarily interrupted by the necessarily existing technical possibility of an OnChipDebugg unit. After execution, the corresponding value of the output variable is read from the memory, whereby the processing of the program is also interrupted for this to allow readout of the values and an interim overwriting of other program parts, the z. B. normally would be interrupted by a fast clocked OSEK task to prevent.

The 2 shows a further schematic overview of the individual components. From the program code P, a target program Z is generated. The generation G takes place, for example, by means of a so-called tool chain, which includes compiling, locating and linking.

During generation, in addition to the code, for example the binary code for introduction to the microcontroller, a file is also produced from which the position Pos of the input variables E_P_Z and output variables A_P_Z can be determined in a memory Sp of a microcontroller .mu.C.

Furthermore, in the generation G, a file is created which has the relation Rel, d. H. the assignment, between the program code P of the source model Q and the program code of the target program Z documented. This assignment is important for the method according to the invention because it allows the function module based on its function name and further attributes in the linear one-dimensional target program memory to be located on the symbol-based development environment via the symbol table so as to inform the interrupt unit of the stop at which address of the microcontroller.

These two files about the position Pos and Relation Rel are also transmitted to a test control unit TK. The test control unit TK comprises at least one test plan T and the comparison unit V.

By means of the test plan T, functional and value-dependent assignments between the input and output variables E_F, A_F of the function module F are determined.

For example, the function module is created in a graphical model environment. Based on these assignments, an input test value ET_T is generated for each input variable E_F of the function module and an output test value AT_T is generated for each output variable A_F of the function module. This method is for example in the DE 10 2004 014 290 A1 detailed.

The program code of the target program Z is implemented on the microcontroller .mu.C of a control device.

The microcontroller μC comprises an interface S, which includes a protocol for communication with a controller K.

The controller K performs a hardware-side control of the microcontroller μC. Furthermore, the controller K is in communication with a register R.

In addition, the controller K has a read and write access to the memory Sp.

For the method according to the invention, the test control unit TK determines an initial mark AM and an end mark EM on the basis of the two files about the position Pos and the relation Rel and on the basis of the test plan T for a program part P1_Z, P2_Z, P3_Z of the target program Z. The start marker AM refers to the beginning of the program code of the program part P1_Z, P2_Z, P3_Z. The end mark EM refers to the end of the program code of the program part P1_Z, P2_Z, P3_Z.

For each program part P1_Z, P2_Z, P3_Z, the test control unit TK transmits the start marker AM and the end marker EM to the interface S of the microcontroller μC. The start marker AM and the end marker EM are read into the register R.

If only one register R is available for this purpose, these values (initial marking AM, end marking EM) must be entered sequentially and a sequence control is required. Otherwise, at least two registers R must be present.

When executing the program code of the individual program parts P1_Z, P2_Z, P3_Z, the microcontroller μC takes into account the respective start marks AM and end marks EM.

When an initial marking AM of a program part P1_Z, P2_Z, P3_Z is reached, the microcontroller .mu.C sends a corresponding feedback to the test control unit TK and interrupts the execution of the program part P1_Z, P2_Z, P3_Z.

On the basis of this feedback, the test control unit TK loads the input test value (s) ET_T according to the test plan T and transmits it to the microcontroller .mu.C.

If only one register R is present, after setting the input test values ET_T, d. H. during the interruption of the execution of the program part P1_Z, P2_Z, P3_Z, the end mark EM is entered in the register R.

If two registers R are present, the second register R is already set to the end mark EM.

The microcontroller μC then continues execution and processes the input test value (s) ET_T.

Upon reaching the end marking EM of the program part P1_Z, P2_Z, P3_Z, the microcontroller .mu.C sends a corresponding feedback to the test control unit TK and interrupts the execution of the program part P1_Z, P2_Z, P3_Z.

Due to this feedback, the test control unit TK loads the output test value (s) AT_P_Z from the microcontroller μC, d. H. there is a reading of the result variables.

The test control unit TK performs a comparison between the output test value AT_T of the test plan T and the output test value AT_P_Z of the program part P1_Z, P2_Z, P3_Z of the target program Z in the comparison unit V.

The method according to the invention establishes a correlation via the special synchronization of model, program code and tool attributes via the various software generation instances. Model-based functions can be checked with their associated test plan when processing on the target hardware.

For the inventive method already available components of the microcontroller μC (interface S and controller K) and as a result of the generation G of the target program Z resulting files (position Pos and Rel Rel) are used. Thus, no special modifications to the microcontroller .mu.C, for example replacement value switches, are required for carrying out the method according to the invention.

The inventive method can be performed on all microcontroller μC, which have an interface S for interrupting the execution of the program of the controller K.

Because real-time operating systems (RTOS Real Time Operating System) are used in complex ECUs, there may be interrupts between the beginning (AM) and end (EM) markers of faster-running (discrete-time) time slices, depending on the application Networking the model can cause a distortion of the test stimulation. This occurs, in particular, when the function 2 is supplied, for example, with the calculation results by the fast-clocked function 1. In this case, the test control unit TK performs a single-step mode of the microcontroller. This mode is retained from the start mark to the end mark. If the function module is interrupted during this time, then the TK, after returning from the more frequently called task, which may possibly contain several functions, checks whether the originally set contents of the input variables (stimulations of the target program section to be tested) still correspond to those in the test plan match given values. If this is not the case, because the faster task should have resulted in a change, then the TK restores the original value so that the system under Test (the function module) has the opportunity to get to the correct expected result, based on the given constraint come.

3 shows how the functionally generated models for the functions F1-F5 generated in the development environment by the code generation as sequentially stored in memory program parts P1_Z-P5_Z the target program. In the development environment, individual models are their content usually contain mathematical calculation rules generated, which are mapped in the functions F1-F5. Starting from the input variables E1_F1 ... to E2_F3, output values are calculated in the functions, with an output value A1_F5 being formed here by way of example. The code generation which leads to the binary target program Z generates from the partially parallel model function structure a sequential target program Z in which the individual functions are found in sequential program parts P1_Z-P5_Z.

LIST OF REFERENCE NUMBERS

A1_F1

output variable

A2_F1

output variable

A1_F2

output variable

A1_F3

output variable

A2_F3

output variable

A1_F5

output variable

A1_P1_P

output variable

A2_P1_P

output variable

A1_P2_P

output variable

A1_P3_P

output variable

A2_P3_P

output variable

A1_P1_Z

output variable

A2_P1_Z

output variable

A1_P2_Z

output variable

A1_P3_Z

output variable

A2_P3_Z

output variable

AT THE

beginning mark

AT_P_Z

Output test value

AT1_P2_Z

Output test value

AT_T

Output test value

AT1_T1

Output test value

AT2_T1

Output test value

AT1_T2

Output test value

AT1_T3

Output test value

AT2_T3

Output test value

E1_F1

input variable

E1_F2

input variable

E2_F2

input variable

E3_F2

input variable

E1_F3

input variable

E2_F3

input variable

E1_P1_P

input variable

E1_P2_P

input variable

E2_P2_P

input variable

E3_P2_P

input variable

E1_P3_P

input variable

E2_P3_P

input variable

E1_P1_Z

input variable

E1_P2_Z

input variable

E2_P2_Z

input variable

E3_P2_Z

input variable

E1_P3_Z

input variable

E2_P3_Z

input variable

EM

end mark

ET_T

Entrance test score

ET1_T1

Entrance test score

ET1_T2

Entrance test score

ET2_T2

Entrance test score

ET3_T2

Entrance test score

ET1_T3

Entrance test score

ET2_T3

Entrance test score

F1

function module

F2

function module

F3

function module

G

generation

K

controller

P

program code

P1_P

program part

P2_P

program part

P3_P

program part

P1_Z

program part

P2_Z

program part

P3_Z

program part

Pos

position

Q

source model

R

register

rel

relation

S

interface

sp

Storage

T

test plan

T1

test plan

T2

test plan

T3

test plan

TK

Test control unit

V

comparing unit

Z

target program

.mu.C

microcontroller

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• DE 102004014290 A1 [0012, 0021, 0025, 0061]

Claims (7)

Method for verifying a code of a target program (Z) which was generated from a program code (P) of a source model (Q), the program code (P) of the source model (Q) being based on at least one function module (F, F1, F2, F3) was generated, and this program code (P) has a program part (P1_P, P2_P, P3_P) which functionally corresponds to a function module (F1, F2, F3) of the source model (Q), and the program code of the target program (Z) has a program part (P1_Z, P2_Z, P3_Z ), which functionally corresponds to a program part (P1_P, P2_P, P3_P) of the program code (P), and each functional module (F1, F2, F3) comprises at least one input variable (E1_F1, E1_F2, E2_F2, E3_F2, E1_F3, E2_F3) and at least one output variable (A1_F1, A2_F1, A1_F2, A1_F3, A2_F3), and for at least one functional module (F, F1, F2, F3) a test plan (T, T1, T2, T3) is created, which is an analysis of a functional and value-dependent assignment between the input variables (E1_F1, E1_F2, E2_F2, E3_F2, E1_F3, E2_F3 ) and the output variables (A1_F1, A2_F1, A1_F2, A1_F3, A2_F3) of the function module (F, F1, F2, F3), and the input variables (E1_P1_Z, E1_P2_Z, E2_P2_Z, E3_P2_Z, E1_P3_Z, E2_P3_Z) of a program part (P1_Z, P2_Z, P3_Z) of the target program (Z) is assigned an input test value (ET_T, ET1_T2, ET2_T2, ET3_T2), the input test value (ET_T, ET1_T2 , ET2_T2, ET3_T2) was created from the test plan (T, T1, T2, T3) of the respective function module (F), and the thus specified input test value (ET_T, ET1_T1, ET1_T2, ET2_T2, ET3_T2, ET1_T3, ET2_T3) in the program part ( P1_Z, P2_Z, P3_Z) of the target program (Z), and the output test value (AT_P_Z, AT1_P2_Z) of the output variables (A1_P1_Z, A2_P1_Z, A1_P2_Z, A1_P3_Z, A2_P3_Z) is read, and this output test value (AT P_Z, AT1_P2_Z) is compared with the output test value (AT_T, AT1_T2) of the test plan (T, T1, T2, T3). A method according to claim 1, characterized in that in the generation (G) of the target program (Z) information is generated which the position (Pos) of the input variables (E_P_Z) and output variables (A_P_Z) of the respective program parts (P1_Z, P2_Z, P3_Z) , which correspond to the functional module (F1, F2, F3) of the source model (Q), in a memory (Sp) of a microcontroller (μC). A method according to claim 1 or 2, characterized in that in the generation (G) of the target program (Z) information that the Relation (Rel) between the program code (P) of the source model (Q) and the program code of the target program (Z) documented, is generated. Method according to at least one of the preceding claims, characterized in that by means of the information about the position (Pos) and the relation (Rel) and by means of the test plan (T) for at least one program part (P_Z) of the target program (Z) an initial marking (AM ) over the beginning of the program part (P_Z) and an end marking (EM) over the end of the program part (P_Z), wherein the execution of the target program at the start marker (AM) is stopped and the input test values given by the test plan (T) ( ET_T) are written to the determined positions of the respective input variables (E_P_Z), the target program is subsequently processed while processing these input test values (ET_T) and stopped again when the end marker (EM) is reached, or until then checked in the sequence under integrity monitoring of the stimulation variables of the functional test object is controlled (single step mode), wherein the initial test (AT_T_Z) and compared with the output test values (AT_T) of the test plan (T). Method according to at least one of the preceding claims, characterized in that the results of the comparisons are stored. Method according to at least one of the preceding claims, characterized in that the target program (Z) is executed in a target environment simulating the controller, the logical operations being replicated on a hardware-formed controller while the target program Z is executed within the target environment. A method according to claim 6, characterized in that the control unit (TK) is designed as a program-technical entity, which carries out the process control.

Images