EP1525530A2

EP1525530A2 - Converter, automation device with a converter and a development environment comprising an automation device with converter

Info

Publication number: EP1525530A2
Application number: EP03783948A
Authority: EP
Inventors: Armin Amrhein; Klaus Göbel; Ulrich Göddemeier; Bernhard Jany; Werner Kuske; Thilo Opatherny; Manfred Prechtl; Georg Rupprecht; Dietmar Schulz; Lothar Trapp
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2002-08-02
Filing date: 2003-08-01
Publication date: 2005-04-27
Also published as: WO2004015564A2; DE10235504A1; WO2004015564A3

Abstract

The invention relates to a converter (51), provided for generation of a control programme (17), running or capable of running on target hardware based on a source code with a number of instructions (22, 31), automation devices with such a converter (51) and development environment with such an automation device (11) with access to a database (52) in which a transformation process (53) is stored for each instruction (22, 31), with means (54, 55, 56) for the completion of each instruction (22, 31) such that the or each parameter (36-40), which is or may be used and/or influenced by the instruction (22, 31) can be logged, whereby the transformation process (53) comprises information for the completion of the instruction (22, 31) with respect to the logging of each parameter (36-40).

Description

description

Transfer device, automation device with a transfer device and development environment with an automation device with transfer device

The present invention relates to the technical field of monitoring control programs, in particular such control programs as are used for the control and / or monitoring of technical processes. The invention relates to a conversion device, an automation device with such a conversion device and a

Development environment with such an automation device.

To monitor control programs, e.g. So-called debuggers are generally known, for example for their commissioning or maintenance. With a debugger it is e.g. B. possible to run a control program step by step, so that one instruction after the other is always executed from the large number of individual instructions from which a control program is composed. The effect of the execution of each individual instruction can be observed.

The observation option relates not only to the changes in the screen contents possibly caused by the respective instruction or to changes in the status of the technical process, but also to the contents of registers, such as B. processor registers, the respective target hardware on which the ^' control program runs.

Such a debugger is usually used on the same target hardware as the control program itself. If the debugger is limited due to limited resources of the target hardware, such as As storage space, computing power, etc., can not be executed on the target hardware, the debugger is executed on a programming or monitoring device communicatively connected to the target hardware. The de- bugger then accesses data provided for the purpose of monitoring the control program.

The performance of a debugger extends from simple monitoring functions. B. only the effects of the individual instructions can be represented up to complex possibilities of influence, in which the execution of the control program z. B. can be influenced by changing individual memory or register contents. For such complex functions, a computer, such as a personal computer, a programming device or the like, is used to execute the debugger. For simple monitoring functions, on the other hand, a monitoring device is provided for displaying the respective data, that is to say a computer with reduced performance, for example a computer. B. without storage media and input options, and at least one output device, such as a screen or printer, sufficient. In the following, such programming or monitoring devices are collectively referred to as programming devices.

A method for operating an automation system with a programming device and target hardware in the form of an automation device is known from EP 0 990 964 AI. By means of the method, the target hardware provided for the control and / or monitoring of a technical process can be monitored by means of the programming device provided for operating and monitoring the automation device. For this purpose, it is provided that one or more data addresses of the control program and a code address for each data address selected for monitoring are selected on the programming device. These addresses are transmitted from the programming device to the target hardware by means of a request telegram. When the code address is reached, the content of the data address (es) assigned is recorded on the target hardware and transmitted to the programming device as part of a result message. Such monitoring of a control program is also referred to as "remote debugging". A disadvantage of known monitoring methods and / or known debuggers, however, is that on the one hand not all information is always accessible because, for. B. the storage space of any intermediate results is not known. Furthermore, individual information - for example in the case of indirectly referenced parameters - can only be accessed with considerable effort because, with a conventional addition command of the form "add to the content of the accumulator, the content of the memory address FF03", the display of the respective memory area must be selected manually Information is not accessible at all during remote debugging, or only with significantly more effort, because remote processor debugging does not stop the processor of the target hardware executing the control program to be monitored and therefore it is not possible to "look up" the contents of individual memory addresses.

After all, when using control programs that are intended to be used on different target hardware, the structure and performance of the actual target hardware is not known. One and the same control program can therefore on a target hardware with a standard mi -troprocessor with z. B. eight processor registers or on target hardware with a special ASIC instead of the microprocessor with a large number of special registers. Naturally, in an execution such. B. of an addition command of the control program on the target hardware are influenced with the microprocessor different registers than on the target hardware with the ASIC. On the part of the monitoring or programming device for monitoring the execution of the control program, it is therefore not known which registers of the target hardware are used or influenced when the addition command is executed. In fact, it is not even known how the respective target hardware actually executes the addition command. Differences can arise if e.g. B. the microprocessor maximum for direct execution additions of the contents of registers with a width of thirty-two bits, which: ASIC is, however, able to directly carry out additions of the contents of registers with a width of sixty-four bits. When the addition command is executed, an addition of parameters of corresponding size must be broken down into two partial additions, while the ASIC can carry out the addition directly.

The invention is therefore based on the object of avoiding the disadvantages mentioned above and of specifying a possibility with which it is also possible to monitor the execution of a control program on target hardware which was not previously known.

This object is achieved according to the invention with a conversion device with the features of claim 1. The conversion device is provided for obtaining a control program which is executable or executable on a target hardware and which is based on an original code with a number of instructions. In order to win the control program, the conversion device has access to a database in which a transformation rule is stored for each permitted instruction of the source code. The conversion device supplements each instruction in such a way that the or each parameter which is used and / or influenced by the instruction or can be used and / or influenced can be logged. For this purpose, the transformation regulation includes information for supplementing the instruction with regard to the logging of the respective parameters and is evaluated accordingly by the conversion device. The parameters influenced by an instruction are understood in particular to be the individual operands of the respective instruction - in the case of an addition, that is, the two summands - but also register and memory contents and so-called flags, insofar as they are used or influenced in the execution of the instruction , The invention is based on the knowledge that when the executable control program is obtained from the source code, which is in each case the underlying code, a source code or intermediate code obtained therefrom, all the information is available which is necessary for a later, complete monitoring of the execution of the control program.

If an addition of two parameters relates to two integer values stored in the memory, the addition command "a + b" in a pseudo code is approximately as follows:

Load the contents of the memory location where the parameter "a" is stored into a register.

Add to the content of this register the content of the memory location where the parameter "b" is stored.

After executing these two commands, the sum of parameters "a" and "b" is in the register mentioned. The register mentioned is e.g. B. the so-called accumulator, which is often used in operations such as additions and the like.

On the basis of the pseudo code shown above as an example, it is clear that e.g. B. the parameter "b" cannot be monitored directly. After executing the first line of the pseudo code, the value of parameter "a" is in the register. The contents of the register could be displayed for monitoring purposes. After executing the second line of the pseudo code, the sum of the two parameters "a" and "b" is already in the

Register. The parameter "b" cannot therefore be monitored directly. Access to its value is only possible if the content of the storage location at which the parameter "b" is stored is looked up. This is associated with considerable effort, the effort again being noticeably increases if z. B. an indirect addressing of the respective memory locations is used.

However, since all the information required for its later monitoring is available when the control program is obtained, it is provided that the or each parameter which is used and / or influenced by the instruction or can be used and / or influenced can be logged. For this purpose, the individual instructions of the original code on which the control program is based are supplemented accordingly. This should be continued as an example for the pseudo code used above as the original code:

Load the contents of the memory location where the parameter "a" is stored in a register and log the contents of the register.

Add to the content of the register the content of the storage location at which the parameter "b" is stored and log the content of the storage location at which the parameter "b" is stored and log the content of the register.

The further indented passages of the pseudo code contain its additions with regard to the logging of the parameters used.

Because of the transformation rule for implementing the respective instruction of the source code, it is known how the data of the individual parameters influenced by the instruction can be reached. In the example above, the transformation instruction includes the conversion of the addition command into two separate instructions. The information associated with the transformation rule or contained in the transformation rule for logging the respective parameters is, for example, B. can be seen that when adding the value of the first summand, parameter "a", does not have to be looked up again in the memory, but that the contents of the register can be logged directly because the value of parameter "a" has been copied into the register. With regard to the actual addition part, it can be seen from the supplementary information that the value of the parameter "b" is never accessible in a register. The logging accordingly relates to the storage location at which the parameter "b" is stored.

L O

The same addition command can be executed differently on another target hardware if, for. B. Operations with three operands are permitted. For this target hardware, the addition command in a pseudo code is something like this:

15

Add the contents of the memory locations where parameter "a" and parameter "b" are stored and load the result into a register.

0 With this variant, at no time is one of the parameters "a", "b" stored in a register. The logging therefore always refers to the respective storage locations. The supplementary instruction is z. B. as follows: 5

Add the contents of the storage locations at which the parameters "a" and the parameter "b" are stored and load the result into a register and log the contents of the storage locations at which the 0 parameters "a" and "b" are stored and log the Contents of the register.

It can thus be seen that the possibility of monitoring the control program becomes completely independent of how the parameters that are influenced or can be influenced are used. To monitor the control program too knowledge of the functionality of the target hardware and even knowledge of the target hardware itself is not necessary.

The invention is therefore also particularly suitable for those use cases in which a source code is first transformed into an intermediate language. Based on this intermediate language as the source code, it can then be converted into a control program that can run on a specific target hardware. This ensures independence from the respective target hardware. When exchanging or upgrading a first target hardware for or to a second target hardware, only a conversion of the intermediate language into the machine code that can be executed by the respective target hardware is required. This implementation can even be carried out by the target hardware itself. After the control software has been created in a suitable programming language, the existing source code is transformed into the intermediate language. The control program in the intermediate language can be executed on the target hardware after it has been implemented.

The advantage of the invention thus consists, on the one hand, in the expanded monitoring options with regard to information previously not or only with considerable effort, as described above, and, on the other hand, in that, despite the most varied or previously unknown target hardware, the monitoring option of the control program running on this target hardware is retained remains.

In connection with the invention or preferred embodiments of the invention, the following terms are used as follows. The term "automation device" summarizes the hardware used to control and / or monitor the respective technical process, the target hardware. The term automation device can just as a single device, such as. B. a programmable controller or the like, as well as a combination of several such devices, for. B. communicatively with each other and connected to a host computer programmable controllers with connected peripheral devices.

With the term "control program" is the executable - z. B. in a machine code - present version of the control program. In a more general use of the term control program, however, this basically refers to all versions of the control program, namely the control program in source or source code, as created by a programmer in the respective programming language, the control program in an intermediate language - intermediate code - as a result of Transformation of the source code and the control program in the form suitable for execution on the target hardware as a result of a corresponding implementation of the control program in the intermediate language or as a result of a direct implementation of the source code.

Advantageous embodiments of the invention are the subject of the dependent claims.

An embodiment of the invention is explained in more detail with reference to the drawing. Corresponding objects or elements are provided with the same reference characters in all figures.

Show in it

1 shows a development environment with an automation device as target hardware and a programming device,

2 shows schematically the creation of a control program, 3 shows a section of a source code on which the control program is based,

4 shows a combined addition and assignment command as an example of an instruction in the source code,

5 shows an intermediate code instruction based on the combined addition and assignment instruction and

6 shows a conversion device for implementing the or each

Intermediate code instruction in an executable form and to supplement it in such a way that the or each parameter which is used and / or influenced by the instruction or can be used and / or influenced can be logged.

1 shows a development environment 10 with an automation device 11 as target hardware and a programming device 12. Automation device 11 and programming device 12 are communicatively connected to one another via separate interfaces 13, 14 and a data transmission path 15. The automation device 11 is provided in a manner known per se for controlling and / or monitoring a technical process 16 which is only shown schematically. The control and / or monitoring of the technical process 16 takes place in accordance with a control program 17 executed by the automation device 11. Any electrically conductive connection between the automation and programming device 11, 12 can be considered as the data transmission link 15. B. a serial connection or a bus (segment), in particular a fieldbus (segment). In addition, a connection by means of optical or electromagnetic signals can also be considered as the data transmission path 15. B. a fiber optic cable or the like or a (directional) radio link.

The automation device 11 is, for. B. a programmable logic controller, a process computer or otherwise Influencing the technical process 16 suitably designed standard computers. The programming device 12 is usually suitable and provided for creating or modifying a source code 18 on which the control program 17 is based. A separate programming device 12 is usually provided because peripherals in the form of at least one input and output device, such as a keyboard or a screen (not shown), are required to create or modify the source code 18. Such periphery is usually not present on the automation device 11, since it is only required temporarily - during the creation or modification of the source code 18 - and is often also unsuitable for permanent use in harsh industrial environments. Nevertheless, there are automation devices 11 in which a programming device 12 is already integrated. The following description applies accordingly to such devices.

2 schematically shows the creation of the control program 17. An intermediate code 19 and the control program 17 are obtained from the source code 18. The intermediate code 19 is generated by transforming the source code 18 into a meta or intermediate language. The control program 17 is generated by converting 21 the intermediate code 19 into a form that can be executed on the respective target hardware, the automation device 11.

3 schematically shows a section of the source code 18 on which the control program 17 is based. In a manner known per se, the source code 18 has a number of successive source code instructions 22, 23, 24, 25, the respective source code instructions 22 -25 themselves and their sequence determining the functionality of the later control program 17. The source code instructions 22-25 include e.g. B. loading and transfer commands known per se, commands for executing arithmetic or logic operations, same commands, jump commands, etc. and, if necessary, compound commands.

4 shows an example of a source code instruction 22-25, a source code instruction 22 with a combined addition, multiplication and assignment instruction "a = b + cxd". The source code instruction 22 comprises a number of parameters, namely the source code parameters "a" 26, "b" 27, "c" 28 and "d" 29. A multiplication part of the source code instruction 22 relates to the multiplication of the source code parameters "c "28 and" d "29. An addition part of the source code instruction 22 relates to the addition of the source code parameter" b "27 and the intermediate result of the multiplication part. Finally, an assignment part of the source code instruction 22 relates to the assignment of the result of the aforementioned addition to the source code parameter "a" 26.

A source code reference number 30 is assigned to the source code instruction 22 for the unique identification and referencing of each source code instruction 22-26. In the simplest case, the source code reference number 30 corresponds to a numbering of the source code instructions 22-26, so that each source code instruction 22-26 receives a unique source code reference number 30.

5 shows, as part of the intermediate code 19, an intermediate code instruction 31 in the intermediate language. The intermediate code instruction 31 corresponds to the implemented functionality of the source code instruction 22 (FIG. 4). The intermediate code instruction 31 is divided into two parts 32, 33, the first part 32 covering the addition part and the second part 33 covering the multiplication part of the source code instruction 22. In order to assign the intermediate code instruction 31 to the corresponding source code instruction 22, the intermediate code instruction 31 also includes an intermediate code reference number 34.

Source and intermediate code reference numbers 30, 34 do not necessarily have to have the same numerical value - here, for example, "117" have, however, it must be guaranteed that each source code reference number 30 is assigned exactly one intermediate code reference number 34 and vice versa. This can be done particularly easily using the same numerical value, but otherwise z. B. also achieve via a so-called look-up table. In the case of a multi-part intermediate code instruction 31, a sub-referencing 35 may also be useful. B. includes the intermediate code reference number 34 and the status of a counter incremented for each part 32, 33 of the intermediate code instruction 31. In the same way, it can be provided that for each part 32, 33 of the intermediate code instruction 31, a separate intermediate code reference number 34 is assigned and which intermediate code reference number 34 and which source code reference number 30 belong together are stored.

In the intermediate code instruction 31, an intermediate code parameter 36, 37, 38, 39 corresponds to the corresponding source code parameter 26-28. To distinguish it from the source code parameters 26-28, the intermediate code parameters 36-39 are shown with capital letters - "A" 36, "B" 37, "C" 38, "D" 39 -.

To completely monitor the execution of the intermediate code instruction 31 shown as an example, it is necessary to log all parameters influenced by the intermediate code instruction 31. To distinguish between intermediate code parameters "A" 36, "B" 37, "C" 38, "D" 39, any intermediate results are referred to as indirect parameters 40. These are designated with the Greek letter "α" - and as the only interim result with the index "1". In addition, the indirect parameters include 40 z. B. also so-called flags (not shown). This saves additional information that is generated when individual instructions are executed. Such additional information relates e.g. B. on one

Register overflow, or to an undefined result - such as when taking the square root from a negative Number . Both types of parameters must be accessible for monitoring and are therefore logged accordingly. In the following, the intermediate code parameters 36-39 and possibly indirect parameters 40 are briefly referred to as parameters.

When the "execution" of a source code instruction 22 or the "execution" of an intermediate code instruction 31 is mentioned, this naturally always means the execution of the corresponding instruction in the control program 17, because only the control program 17 actually comprises executable code. However, since each executable instruction is based on a corresponding instruction in the original code, namely the respective source or intermediate code instruction 22, 31, the term "execution" of these instructions is also used.

The logging of the parameters to be monitored is shown in FIG. 5 by two logging instructions 41, 42. Each part 32, 33 of the intermediate code instruction 31 is supplemented by a logging instruction 41, 42. The intermediate code instruction 31 itself is thus also supplemented by the logging instructions 41, 42. However, the logging instructions 41, 42 are not part of the intermediate code 19 but already part of the executable control program 17, because the logging instructions are generated with or after the implementation of the intermediate code instruction 31 into an executable form.

The logging comprises, as character string 43, the intermediate code reference number 34 in order to enable the assignment of the logged parameters to the respective intermediate code instruction 31 in which the parameters were influenced or could be influenced, as well as the intermediate code parameters 36-39 used and the intermediate result 40 used. The possibly. required logging of flags is not taken into account in the description above. However, their logging is carried out analogously to the logging of the parameters used in each case. When implementing an intermediate code instruction 31, it is known which flags can be influenced when they are executed. With an addition, there is always the risk of register overflow if the sum is greater than the width of the register in which it is to be stored. The flag

.0 logged for register overflow. In the case of a division, an undefined result, namely a division by zero, can also be considered. Accordingly, the flag for undefined results is logged for divisions. All in all, an intermediate code instruction

The solution contained in solution 31 in advance stipulates which flags, if necessary, to be influenced . When each operation is implemented, all flags that can be influenced are logged accordingly.

6 shows a memory 50 of the automation device 11 representing the target hardware. The control program 17 and at least sections of the intermediate code 19 on which the control program 17 is based are stored in the memory 50. The implementation 21 (FIG 2) of the intermediate code 19 for

25 The executable control program 17 is obtained by means of a conversion device 51 implemented as software and therefore also stored in the memory 50. The functionality of the conversion device 51 can alternatively also be implemented as hardware, in which case the corresponding. Automation device 11 z. B. a corresponding ASIC (not shown) is provided.

The control program 17 is based on an original code - according to the exemplary description of the intermediate code 19 based on the source code 18 5. The source code 18 comprises a number of instructions 22-25 (FIG. 3), wherein at least one instruction 31 (FIG. 5) intermediate code 19 belongs to each instruction 22 -25 in the source code 18.

So that the control program 17 can be monitored in the manner described above, logging of the parameters used and / or influenced or usable and / or influenceable is provided. The logging is carried out by means of the logging instructions 41, 42 (FIG. 5) that are inserted into the control program and generated when the or each intermediate code instruction 31 is implemented.

In order to convert each intermediate code instruction 31 into an executable form, the conversion device 51 has access to a database 52. A transformation rule 53 (only shown schematically) is stored in this for each permissible intermediate code instruction 31. The database 52 thus includes a transformation rule 53 for the transformation of assignment commands, a transformation rule 53 for the transformation of addition commands, a transformation rule 53 for the transformation of multiplication commands, etc. , Etc .

Furthermore, the conversion device 51 has means 54, 55, 56 for supplementing each intermediate code instruction 31 with one or more logging instructions 41, 42, so that the or each parameter 36 -40 is used and / or influenced by the intermediate code instruction 31 or can be used and / or influenced, can be logged.

The means 54, 55, 56 mentioned are implemented as software functionality and correspondingly represented as function blocks, but in individual cases can also be implemented as hardware - in the form of an ASIC (not shown).

The means 54, 55, 56 comprise a first means 54 for retrieving and analyzing in each case an instruction of the source code. des, the respective intermediate code instruction 31. To analyze the or each instruction z. B. uses the functionality of a so-called parser. After analyzing the respective intermediate code instruction 31, it is clear whether, for. B. there is an instruction with an assignment command or an instruction with an addition command, so that the corresponding transformation rule 53 is then called up from the database 52 with a second means 55 and the intermediate code instruction 31 is transformed. This second means 55 also supplements the respective intermediate code instruction 31 in such a way that the or each parameter 36-40, which is used and / or influenced by the intermediate code instruction 31 or can be used and / or influenced, can be logged. I.e. the second means 55 supplements the respective intermediate code instruction 31 with the logging instructions 41, 42 (FIG. 5). The logging instructions 41, 42 can be inserted in the control program 17 before or after the executable counterpart of the respective instruction, depending on when a parameter 36-40 is used. For instructions of the form "A = A + B" it is also z. For example, it makes sense to log parameter "A" both before the instruction is executed and after the instruction is executed. Finally, a third means 56 is provided in order to integrate the transformed - ie executable form - of the instruction together with the logging instructions 41, 42 into the control program 17.

When the control program 17 runs on the automation device 11 - the target hardware - the added logging instructions 41, 42 are executed before or after each instruction. The parameters 36-40 logged in this way are transmitted to the programming device 12 via the interfaces 13, 14 and the data transmission path 15 and can be displayed there together with the underlying source code 18 for monitoring and diagnostic purposes. The assignment of the logged parameters 36-40 to the original source code instructions 22-25 takes place by means of the source code reference number 30 and the character string 43 logged by each logging instruction 41, 42, which corresponds to the intermediate code reference number 34.

To identify the individual logged parameters 36-40, either a fixed sequence of parameters 36-40, preferably determined by the information contained in the transformation rule 53 used, is provided. I.e. it is z. For example, in the case of the first part 32 of the intermediate code instruction 31, it is known that the first logged value represents the value of the indirect parameter 40 and thus the intermediate result of the multiplication part of the underlying source code instruction 22. Accordingly, it would also be known in advance that the second and third logged values represent the value of the intermediate code parameters "C" 38 and "D" 39 and thus correspondingly the value of the corresponding source code parameters "c" 28 and "d" 29, etc. If such a fixed sequence known in advance when logging parameters 36-40 cannot be specified or does not make sense, the logged data is given declarative identifiers, e.g. B. "117: α _ι = 12, C = 2, D = 6", added. The result is a character string (string) in which "117" again represents the intermediate code reference number 34 as character string 43. The characters (chains) "oci", "C", and "D" as declarative identifiers allow the assignment of the logged values to the parameters to be monitored. Other special characters, such as ":", "=" and "," are provided for formatting the character string and thus for easier extraction of the data contained therein.

The logged parameters 36-40 are transmitted to the interface 14 of the automation device 11 and from there to the programming device 12. If no programming device 12 is connected to the automation device 11, the transmission of the logged parameters is omitted

36-40. These are then logged, as it were, "into the void". In order to regulate or limit the data volume to be transmitted via the data transmission path 15 when the programming device is connected, it is preferably provided that the transmission of the logged parameters 36-40 begins when a prerable source or intermediate code reference number 30, 34 is reached and when another one is reached specifiable source or intermediate code reference number 30, 34 ends. In this way, selectable sections of the control program 17 can be specifically examined. For this purpose, means are not shown that z. B. Are part of the interface 14 or the associated interface interface and filter the logged parameters 36-40 such that only those parameters 36-40 are transmitted to the programming device 12 via the interface 14 that were logged for such instructions that are in the range of the given source or intermediate code reference numbers 30, 34.

The invention can thus be briefly represented as follows:

To monitor the execution of a control program 17 on target hardware, it is provided that each instruction of the source code is supplemented by logging instructions 41, 42 when the control program is generated from an original code - a source code or an intermediate code based on the source code. The logging instructions 41, 42 effect the logging of all parameters 36-40 which can be used and / or influenced by the respective instruction. The logging instructions 41, 42 are supplemented on the basis of information which is part of a transformation rule 53 for transforming the respective instruction into an executable form. When transforming the respective instruction into an executable form, it is known which parameters - and if necessary. Registers, flags, and memory contents - 36-40 affects the instruction. These parameters 3 6 -40 and the information required to access them are part of the logging instructions 41, 42. This makes it possible to monitor the execution of a control program 17 on the basis of the logged parameters 36-40, regardless of the respective target hardware, since the respective value of the parameters 36-40 is logged at any time and no access, for example by means of a programming device 12, to register contents of the target hardware is required is.

Claims

claims

1. To obtain a running or executable on a target hardware control program (17), which is based on an original code with a number of instructions (22, 31), provided conversion device (51) with access to a database (52) in the for each Instruction (22, 31) a transformation rule (53) is stored, it may be that the means (54, 55, 56) for supplementing each instruction (22, 31) such that the or each parameter (36 -40), which is used and / or influenced by the instruction (22, 31) or can be used and / or influenced, can be logged, the transformation rule (53) providing information to supplement the instruction (22, 31) with regard includes the logging of the respective parameters (36-40).

2. Implementation device according to claim 1, wherein the or each parameter (36-40) can be logged before and / or after the execution of the instruction (22, 31).

3. Implementation device according to claim 1 or 2, wherein the source code is a source code (18) on which the control program (17) is based with a number of source code instructions (22-25) and the supplemented or supplemented instruction is the or each source code instruction (22- 25) is.

4. Implementation device according to claim 1 or 2, wherein the control program (17) is based on a source code (18) with a number of source code instructions (22-25) intermediate code (19) with corresponding intermediate code instructions (31) and wherein The source code is the intermediate code (19) and the supplemented or supplemented instruction is the or each intermediate code instruction (31).

5. Implementation device according to one of the above claims, wherein in addition to the or each parameter (36-40), a reference uniquely assigned to the respective instruction can be logged.

6. Automation device with a conversion device (51) according to one or more of the preceding claims.

7. Automation device according to claim 6 with means for activating and deactivating the logging.

8. Development environment with an automation device (11) according to claim 6 or 7 and a programming or monitoring device (12), each with an interface (13, 14) and a data transmission path (15) extending between them, via which the logged parameters ( 36-40) can be transmitted to the programming or monitoring device (12) for their display.

9. Development environment according to claim 8, wherein the means for activating and deactivating the logging can be controlled by the programming or monitoring device (12).