Dynamic Coordination and Execution of Independent Heterogeneous Program Units

Abstract

A method for executing heterogeneous program units of a program, in particular for controlling an automated system, includes forming, using a central management unit, an execution unit including program sequences having a plurality of instances of the heterogeneous program units. The heterogeneous program units are chosen from a set of the heterogeneous program units which are registered on the central management unit. The method further includes executing the plurality of instances of the heterogeneous program units of the execution unit according to a configured sequence.

Claims

1. A method for executing heterogeneous program units of a program for controlling an automated system, comprising: forming an execution unit using a central management unit, the execution unit including program sequences having a plurality of instances of the heterogeneous program units, the heterogeneous program units are chosen from a set of the heterogeneous program units which are registered on the central management unit; and executing the instances of the heterogeneous program units of the execution unit according to a configured sequence.

2. The method according to claim 1, wherein: the heterogeneous program units are written in at least two different programming languages, each of the heterogeneous program units is configured to access variables in a common data structure, and the variables in the common data structure are created by the central management unit.

3. The method according to claim 1, further comprising: inserting a further program unit into the formed execution unit; and adapting the configured sequence to execute the instances of the heterogeneous program units with the inserted further program unit.

4. The method according to claim 2, further comprising: receiving the variables from one of the registered heterogeneous program units and creating or deleting the received variables in the common data structure.

5. The method according to claim 1, further comprising: coordinating a command execution in the plurality of instances of the heterogeneous program units of the execution unit by transmitting a begin command for a command to each of the heterogeneous program units to initiate the command execution; and ending the command execution when at least one of the heterogeneous program units denies the command execution.

6. The method according to claim 5, further comprising: transmitting an execution command for the command to each of the heterogeneous program units; and cyclically repeating the transmission of the execution command until a confirmation message relating to execution of the command has been received from each of the heterogeneous program units.

7. The method according to claim 5, further comprising: transmitting an end command to each of the heterogeneous program units when the command execution is ended or the command has been successfully executed.

8. The method according to claim 5, further comprising: registering the command to each of the heterogeneous program units on the central management unit.

9. The method according to claim 1, wherein a computing unit is configured to carry out the method.

10. The method according to claim 9, wherein a computer program causes the computing unit to carry out the method when the computer program is executed on the computing unit.

11. The method according to claim 10, wherein the computer program is stored on a machine-readable storage medium.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG. 1 shows a block diagram of participating units of one example embodiment;

[0021] FIG. 2 shows a sequence diagram for the coordination of a plurality of program units according to one example embodiment; and

[0022] FIG. 3 shows a sequence diagram for the coordination of a plurality of program units according to a further example embodiment.

DETAILED DESCRIPTION

[0023] FIG. 1 shows a block diagram of one embodiment of the disclosure. The coordination and sequence control of individual program units 110a, 110b, 110c, 110d which can be written in the same or in different programming languages are performed by a central management unit 100. For this purpose, individual program units can initially register (connections 102) on this management unit 100 via an associated adapter which is present as an interface for each of the program languages that are used and can thus be defined as an available program resource. The management unit 100 can then perform the registration of the required commonly used variables or data objects together with the registration 102 of the program units or separately therefrom. To do this, each program unit 110a, 110b, 110c, 110d can report the variables that it uses to the management unit 100, for example following a query from the management unit or in a predefined sequence. Said management unit then generates (or removes) (connections 104) the respective variables in a shared data memory 140 and reports back the registered variables or the variables and an associated identifier to all registered program units, so that the individual program units 110a, 110b, 110c, 110d are then able to obtain read and/or write access to these variables in the common data memory 140.

[0024] Program units or sequences from a plurality of program units can be executed following a configuration of this type. To do this, in one embodiment, the management unit 100 can directly control the execution of one or more program sequences. It can also form execution units 120, 130 which in each case contain a subset of program units and an associated configurable order of execution. The different program units can be written in the same or in different languages; user-specific or system-specific program units, for example can similarly be used. In particular, program units can be used which are written in domain-specific languages (DSL) and are functionally freely programmable. An execution unit can thus, for example, be responsible in a control for the sequential calling of the different program units or instances of program units defined therein, such as, for example, movement control, kinematics, fieldbus drivers, etc.

[0025] As shown in FIG. 1, a plurality of instances of program units can be executed, for example, successively in a sequence in a first execution unit 120. The units that are used can be chosen from the set of registered program units and can be executed successively according to the configured sequence. An instance of the program unit 110d, for example, is thus first executed, and then the execution unit initiates the execution of a further instance of the unit 110d, and then, as shown, for example, instances of the program units 110b, 110c and 110a. Fewer or more program instances than are shown here can also be used; the execution according to the sequence is continued by the execution unit 120 until the last configured program unit (unit 110a) is reached.

[0026] It is possible to specify both the maximum runtime of all execution units and the runtimes of individual program units by means of the management unit. It is optionally also possible to monitor the complete execution of a program unit within a sequence or execution unit and to instigate specific measures if the program unit has not been completely executed, e.g. by repeating a specific part of a sequence or by waiting until the execution was successful.

[0027] The execution of system-specific program units such as motion, kinematics, fieldbus drivers, etc., is performed via the scheduler. All user-specific program units are further executed by means of the scheduler. Dialogues are developed in a newly developed interface for the configuration and visualization.

[0028] Further program units can also be dynamically registered 102 in runtime. Optionally, the valid variables and identifiers can also be communicated to newly registered program units directly during or following the registration in order to permit access to the common data memory 140.

[0029] Newly added or already previously registered independent program units can similarly be inserted dynamically in runtime into a newly generated or already existing execution unit. To do this, it is only necessary for them to be previously registered on the management unit and therefore to be available. An execution unit 130 with two instances of different or identical program units 110d, for example, can already be defined by means of the management unit, the execution of which may already have been started. A further program unit 110c can then be inserted 132 if required between the two units already defined, which is also possible in runtime. This specialization of the program unit is performed via a parameterization. The execution unit can freely adapt the configured sequence of the program units accordingly. The execution units or program sequences can therefore be dynamically modified and supplemented by the management unit through use of the registered program units. The chosen example is obviously intended only to illustrate the principle, and any number of program instances, also e.g. at different times or in different execution units, can be inserted or added.

[0030] In one embodiment, the instantiated program units can initially act independently from one another, i.e., in this variant, a fault in one program unit has no impact on another program unit. In further embodiments, it is possible to form groups consisting of a plurality of program units which, for example, together form a specific movement sequence of an actuator. This is particularly appropriate if an application at least partially necessitates dependencies between a plurality of program units and therefore a higher integrity of the program units is intended to be achieved. These groups can in each case then act again as a single program unit.

[0031] In a further embodiment, heterogeneous, independent program units can be coordinated by designing a fixed command sequence for the coordination. As described above, the program units to be coordinated can be defined as related groups or can be addressed dynamically for the coordination. A group can act as a homogeneous program unit, i.e. a fault in one program unit can be interpreted as a fault in the group. A command sequence consisting of a begin command (begin), an execution command (execute) and an end command (end) can be formed, said sequence being run cyclically for a plurality of program units to be coordinated.

[0032] FIG. 2 shows a first example of a sequence diagram for a cycle in which one of three program units to be coordinated denies the execution of a command. The performance of the sequence shown is to be understood chronologically from top to bottom. A begin command for the command to be executed in this sequence, begin(command), is first transmitted by the coordinating execution unit 200 to each of the program units 210, 220, 230. The command to be executed can be indicated, for example, as an argument of the begin command. As soon as one unit has received the begin command, it can transmit a predefined response back to the execution unit (or to any other unit which coordinates the current program sequence). The begin command thus enables the coordinated program units to respond positively to or deny a pending execution of a command.

[0033] The program units can preferably be addressed sequentially after one another. The begin command is therefore first transmitted to the first program unit 210 which, in the present case, signals back the readiness for execution by means of a corresponding confirmation message okay( ). After this response has been received, the begin command is transmitted by the execution unit 200 to the second participating program unit 220. In the present example, the execution is denied by the second program unit 220, this being signaled by the return transmission of a corresponding denial message deny( ). The begin command can then also be transmitted to the third participating program unit 230 and the corresponding response can be received.

[0034] The denial by at least one of the program units to be coordinated can then ensure that the command execution is terminated without further steps. This is communicated to all participating program units through the transmission of an end command end(command) for the command to be executed. A response to the end command is not required, but could optionally be provided. The execution sequence is thus ended for this command and a further command can be initiated.

[0035] FIG. 3 shows an example of a sequence diagram with a delay triggered by a program unit. The planned command execution is first announced once more to all participating program units by means of a begin command begin(command) specifying the respective command. Following each transmitted begin command, one of the possible responses is transmitted by the program unit. In contrast to the example from FIG. 2, all three participating program units now signal the positive readiness to execute the command by means of a confirmation message, okay( ).

[0036] Since no program unit has denied the execution and the necessary confirmation has been received from all units, an execution command execute(command) next follows for the command to be executed which instructs the actual execution or processing of the command in the individual program units 310, 320, 330. Here also, a response is transmitted back by each program unit. In the present example, the first program unit executes the corresponding command and finally immediately transmits a confirmation message okay( ) once more.

[0037] The second program unit 320 in this example can transmit a delay message, delay( ) as a response. This message can indicate that the processing of the command is not currently possible or is not possible within a predefined time period for the responding program unit. The execution command execute is then also transmitted to the third program unit 330 also and a corresponding return response is awaited.

[0038] Since a timely execution was not therefore possible for all program units in the preceding step, this step is repeated for all program unit 310, 320, 330 so that an execution command is again transmitted and the response of each program unit is in each case received.

[0039] The execution command execute(command) can be invoked cyclically until all program units have successfully completed the execution. The end command can then be transmitted again to all program units. This end command is preferably always executed and signals the synchronized ending of the command for all participating program units.

[0040] It is optionally also conceivable that, along with a confirmation or a delay of the command, a denial of the command is also permitted in response to the execution command so that, with a corresponding response of a program unit, the execution is ended by the end command.

[0041] In example embodiments, the detailed design of the command sequence could further be different depending on the command to be executed; for example, specific commands could be provided in which a termination or a denial is permitted in the execution phase, whereas, in a different group of commands, no termination is possible, but instead the cyclical repetition of the execution command is continued until the execution is correctly completed. The time period, for example, which is provided for the execution of a command and which decides whether a program unit responds with a delay message could further be defined for different groups of commands or separately for each individual command. In one variant, along with individual commands, a predefined group of commands could also be used as an argument of the command sequence so that, on invocation by the start command, the entire command group is initialized for execution.

[0042] Commands can, for example, be predefined in the system for different functionalities. Similarly, it is also possible for the existing commands to be extended by the program units. For this purpose, each program unit registered on the management unit can register one or more commands by transmitting a corresponding registration. Optionally, as with the registration of variables, the management unit can communicate the newly registered commands to all registered program units. The program units can then trigger the execution of any command via the command sequence as described in FIG. 2 or 3.

[0043] An interlocking of the commands in the program unit is not required, since the commands are executed sequentially by the management unit or execution units.

[0044] The embodiments described can be used, for example, in a wide range of different controllers.

[0045] A first program unit, for example, can copy fieldbus data from special hardware, e.g. an FPGA, into the local memory and can process the data in such a way that they can be used by other program units. A program unit of this type could typically be programmed in C/C++.

[0046] A second program unit can then access input and output data of the fieldbus devices and, for example, check whether an input (e.g. limit switch) has been set, and, if necessary, set an output, e.g. a signal light. This program unit can typically be programmed in SPS (IEC 61131-3). A third program unit can then access the data of complex fieldbus devices (for example drives) and can process them (e.g. weighting) for downstream program units. This program unit can typically be programmed in C/C++.

[0047] Further—instantiated—program units can then calculate new setpoints for their respective dataset (drive) for the respective further movement, for example using complex control algorithms. This program unit can also be provided by third parties and could have been designed, for example, in Matlab and generated according to C. These program units can all be combined into a single program sequence, or can also be divided up into a plurality of program sequences. The programming languages and program units specified here are also obviously only example variants which can be replaced by others as required.