METHOD AND DEVICE FOR CONTROLLING THE SEQUENCE OF PROGRAM PARTS, PROGRAMMING METHOD, PROGRAMMING DEVICE

Abstract

A method of controlling the sequence of program parts has the following steps: initiated by the occurrence of a first event (E1), executing a first program part (P1) on a first arithmetic logic unit (RW1), wherein the first event (E1) and/or the first program part (P1) is/are assigned a first priority (Py1), and initiated by the occurrence of a second event (E2), interrupting the execution of the first program part (P1) and then executing a second program part (P2) on the first arithmetic logic unit (RW1), wherein the second event (E2) and/or the second program part (P2) is/are assigned a second priority (Py2) that is higher than the first priority (Py1), wherein the first and/or the second program part (P1, P2) is/are a function block in the sense of IEC 61499 or a part thereof or a data transmission initiated thereby.

Claims

1. A method of controlling the sequence of program parts, comprising: initiated by the occurrence of a first event, executing a first program part on a first arithmetic logic unit, wherein the first event and/or the first program part is/are assigned a first priority, and initiated by the occurrence of a second event, interrupting the execution of the first program part on the first arithmetic logic unit and then executing a second program part on the first arithmetic logic unit, wherein the second event and/or the second program part is/are assigned a second priority, wherein the second priority has a predetermined and in particular a user-defined relationship with the first priority, wherein the second priority is higher than the first priority, wherein the first and/or the second program part is/are a function block in the sense of IEC 61499 or a part thereof or a data transmission initiated thereby.

2. The method in accordance with claim 1, in which one or more program parts are parts of device control programs or plant control programs that run on a programmable logic controller.

3. The method in accordance with claim 1, in which at least one event list is kept that stores events that have occurred in accordance with the associated priority and that designates program parts still to be processed, wherein, for a plurality of priorities, respective separate event lists can be kept that in each case store events of the associated priority that have occurred and that designate program parts still to be processed, wherein the second event is entered in the event list corresponding to its priority and then, if there is no entry in any event list for a higher priority, is possibly used for the interruption of the execution of the first program part on the first arithmetic logic unit in accordance with the processing rules for the entries in the event list of its own priority.

4. The method in accordance with claim 1, in which a plurality of tasks are used that were created in advance as respective execution environments.

5. The method in accordance with claim 1, in which tasks are used that are created in real time as respective execution environments and that are removed in real time.

6. The method in accordance with claim 1, in which the second event is generated by another program part running on another arithmetic logic unit.

7. The method in accordance with claim 1, comprising: obtaining monitoring results of the occupancy and/or utilization of the first arithmetic logic unit, and in accordance with the monitoring results, when the second event occurs, initiating the interruption and the execution of the second program part on the first arithmetic logic unit.

8. The method in accordance with claim 7, in which monitoring results relating to the occupancy and/or utilization of the first arithmetic logic unit and one or more further arithmetic logic units are obtained and, in accordance with the monitoring result, when the second event occurs, the initiation of the interruption and the execution of the second program part on the first arithmetic logic unit is caused.

9. The method in accordance with claim 8, in which a decision on the assignment of the execution of the second program part to one of the monitored arithmetic logic units is made in accordance with the monitoring result.

10. The method in accordance with claim 8, in which a decision on the assignment of the execution of the second program part to one of the monitored arithmetic logic units is also made in accordance with properties of the monitored arithmetic logic units.

11. The method in accordance with claim 1, in which program parts include distinguishable parts and the interruption of the execution of the first program part takes place after processing a part included in the first program part and before starting the processing of a part following in the first program part, or during the processing of such a part.

12. The method in accordance with claim 1, in which program parts are called up and processed in accordance with an execution control planning in accordance with IEC 61499, wherein the calling up of a program part from the execution control planning can be the first event effecting the execution of the first program part and/or the second event effecting the execution of the second program part, to which event a priority can be assigned or is already assigned, and these events can overwrite or modify the determinations of the execution control planning.

13. The method in accordance with claim 1, in which the interruption of the execution of the first program part comprises the backup storage of the currently relevant device state, and in which the continuation of the previously interrupted program part comprises the loading of the device state that was backup-stored during the interruption for the arithmetic logic unit taking over the continuation.

14. The method in accordance with claim 1, in which a program part is designated as uninterruptible or as not simultaneously executable multiple times and is then also not interrupted or simultaneously executed multiple times when the other conditions occur.

15. An apparatus in accordance with IEC 61499 for performing the method in accordance with claim 1 that can be a device control or a plant control and/or a programmable logic controller and that can have at least one sensor or data input and at least one actuator or data output.

16. A programming method in which an IEC 61499-compliant programming interface is provided that is adapted for programming the method in accordance with claim 1.

17. The programming method in accordance with claim 16, in which the programming interface is or comprises a graphical user interface that is adapted to input the programming of the priority-initiated interruption of the execution of the first program part on the first arithmetic logic unit.

18. A programming apparatus for performing the programming method in accordance with claim 16.

19. An execution apparatus for IEC 61499-compliant programs, comprising at least two arithmetic logic units for the parallel execution of program parts that are triggered by events marked with priorities, an operating control that controls the execution of program parts on the arithmetic logic units based on the priorities that are associated with the events triggering the program parts, wherein the operating control is adapted to interrupt the execution of a first program part on an arithmetic logic unit and to initiate the execution of a second program part on this arithmetic logic unit if the event triggering the execution of the second program part has a higher priority than the event triggering the execution of the first program part.

20. The method in accordance with claim 4, in which a plurality of tasks are used that were created in advance as respective execution environments such that one or more tasks are created for each priority value.

21. The method in accordance with claim 5, in which tasks are used that are created in real time as respective execution environments in response to an occurring event

22. The method in accordance with claim 5, in which tasks are removed in real time at the end of the processing of a program part.

23. The method in accordance with claim 7, comprising: obtaining monitoring results of the occupancy and/or utilization of the first arithmetic logic unit from an operating system function.

24. The method in accordance with claim 13, in which the interruption of the execution of the first program part comprises the storage of the values of an arithmetic logic unit, registers, data memories, a program memory, a program pointer, files.

25. The method in accordance with claim 14, in which a program part is independently of priority assignments designated as uninterruptible or as not simultaneously executable multiple times and is then also not interrupted or simultaneously executed multiple times when the other conditions occur.

Description

[0038] Embodiments of the invention will be described in the following with reference to the drawings; there are shown

[0039] FIG. 1 generally, the interruption of a program part;

[0040] FIG. 2 competing access to an arithmetic logic unit;

[0041] FIG. 3 a plurality of event lists;

[0042] FIGS. 4a, b an example of a control program;

[0043] FIGS. 5a to c an example of a sequence in accordance with the invention;

[0044] FIG. 6 a known execution structure;

[0045] FIGS. 7a, b function blocks in the sense of IEC 61499; and

[0046] FIG. 8 a known method.

[0047] In FIG. 1, the upper row shows events occurring along the time axis. E1 is an event 13 that is assigned a priority Py 3. In general, the priorities can be assigned to the events during the programming of the control program or of the individual program parts. It is assumed that the event E1 13 leads to the execution of a first program part P1 11a. It is further assumed that a second event E2 14 occurs at the point in time t2 at which the processing of the first program part P1 has not yet been completed. The second event E2 14 has the priority Py 2 and is thus prioritized higher than the first event E1 13 with the priority 3 or the corresponding first program part P1.

[0048] Assuming that for systemic reasons it is not possible to assign the second program part P2 associated with the second event E2 to an arithmetic logic unit other than the arithmetic logic unit RW1 shown, the second event E2 14 causes the first program part P1 11a to be interrupted shortly after the point in time t2 so that the second program part P2 12, which is triggered by the second event E2 14, is executed on the first arithmetic logic unit RW1.

[0049] It is further assumed that the processing of the second program part P2 12 is completed at a later point in time t4. This is the reason to then continue the processing of the interrupted first program part 11a at a point in time t5, which is indicated by reference number 11b.

[0050] It has already been pointed out that program parts can be marked as uninterruptible. If this were the case for the program part P1 11 in the example of FIG. 1, the occurrence of the second event E2 14 at the point in time t2 would, unlike as shown in FIG. 1, not lead to the interruption of the first program part 11. Rather, the first program part 11 would be continued and the second program part P2 corresponding to the higher priority second event E2 14 would have to be assigned to another arithmetic logic unit for execution or, if necessary, would conventionally have to wait.

[0051] FIG. 2 shows in more detail one possibility of how an access conflict to arithmetic logic units can arise. Unlike in FIG. 1, events are not shown at the top and an arithmetic logic unit assignment is not shown at the bottom, but the occupancies of two arithmetic logic units with program parts are rather shown above one another. It is assumed that a program part P0 21 initially runs on an arithmetic logic unit RW0 and that, as shown, a first program part P1 11a with a priority Py=3 runs on an arithmetic logic unit RW1 starting later or possibly also earlier. For the program part P0 21, it is assumed that it generates two events at the end of its execution at the point in time t2, namely the second event E2 of the priority Py=2 already described in FIG. 1 and a further event 23 of, for example, the same priority Py=2.

[0052] The program part 24 triggered by the event 23 can then be executed on the arithmetic logic unit RW0 which has become free due to the completion of the program part P0, while the program part P2 then cannot be executed there. Accordingly, it is assigned to another arithmetic logic unit, the arithmetic logic unit RW1, for which it is assumed that the processing of the first program part P1 11a is still running at the point in time t2. The processing of the first program part P1 11a is then interrupted on this arithmetic logic unit RW1 since the program part P2 12 was called up with a higher priority and the already shown processing of the second program part P2 12 then takes place there that is assumed to be completed at the point in time t4.

[0053] At this point in time t4, the second program part P2 12 can itself generate one or more events that correspond to its regular programming and that are indicated in FIG. 2 by reference number 25. In addition, the operating control 107 can, for example, add an event 15 that can e.g. be entered in the event lists and can trigger the resumption of the processing of the first program part P1 11b. The resumption can thus be included in the priority-controlled event processing. However, it is also possible to initiate the resumption of the processing of the first program part P1 11b directly after the completion of the processing of the interrupting program part P2 12 by the operating control. For this purpose, the operating control can keep a suitable list of interrupted program parts waiting for the resumption.

[0054] A further event 15 can also be defined or generated, for instance by the operating control 107, namely an event for triggering the processing of the interrupted program part, immediately on a program part interruption shown in FIGS. 1 and 2, i.e. generally in response to a program part interruption to be performed due to an event (in the example E2 (Py:2)). This event 15 can also be provided with a priority. For example, it can be given the priority of the interrupted program part or it can be ranked higher to preferably end the interrupted program part. This further event can then be entered in the otherwise kept event list 35 or event lists 31-34 and can be processed together with the other events in a priority-controlled manner.

[0055] FIG. 3a shows a possibility of setting up event lists, sometimes also called queues. An embodiment is shown in which it is again assumed that events are provided with one of four priorities and a separate event list 31, 32, 33, 34 is kept for each of these priorities 1, 2, 3, and 4. The lists themselves then do not need to list the priorities of the events since they have already been predefined by the respective list itself. In any case, the list, however, specifies in tabular form the events of the associated priority that still have to be processed. In addition, it can, for example, list the program part for the respective event that is called up by the listed event and, if necessary, can also hold parameters that are transferred when the program is called up.

[0056] To avoid misunderstandings, it is pointed out that event lists change dynamically by adding new events, in particular the most recently generated events, and deleting previously entered events, in particular processed events, due to operational reasons. Specific representations are then snapshots in each case.

[0057] As already mentioned, the program parts triggered by events can be function blocks in the sense of IEC 61499. Accordingly, in the embodiment of FIG. 3a, the information shown in the respective right columns would be identifications of respective function blocks of IEC 61499. It is assumed for the list 31 of the priority 1 that it only holds one event E7 that triggers a program part P2 having a parameter set that is only symbolized by A. The event list 32 for priority 2 accordingly includes three events. For event E9, it is assumed that it triggers program part P3 for whose triggering no parameters have to be transferred. The event list 33 for priority 3 is assumed to be empty since no events of priority 3 are currently pending for processing. The event list 34 for priority 4 is again assumed to be occupied with some events.

[0058] In the sequence control procedure described, the system control can now process the pending events starting with the first event list 31. In the example of FIG. 3a, the event E7 of the event list 31 for priority 1 would therefore first be used for execution. The event E7 would, if possible, be assigned to a free arithmetic logic unit for processing. If this is not possible, the interruption of a lower priority process on an occupied arithmetic logic unit would be initiated as described. If the event list 31 for priority 1 is empty, the processing of the events of the event list 32 for priority 2 can be started. Unlike in the event list 31 for priority 1, there are a plurality of events in the event list 32. It must then be decided according to which criterion these events are processed. Strategies such as FIFO, LIFO, or Round Robin can be used here. If the event lists 31, 32 and 33 are empty at any point in time in the processing sequence, the processing of the events in the event list 34 can be started.

[0059] FIG. 3b shows another way of creating the event list. A single event list is created here across all the priorities. Accordingly, the priority of the respective event must also be listed in this list, because otherwise the information would then be lost. During the processing, the highest priority event is then to be selected from the list in each case and processed as described.

[0060] The event list design in accordance with FIG. 3b can thus correlate with the fact that arithmetic logic units are not defined and installed in advance, but are installed at the time of execution.

[0061] So far, the event-controlled and priority-controlled execution and, if necessary, interruption of program parts has been described. In the same way, this can apply to the event-controlled and priority-controlled execution and, if necessary, interruption of data transmissions that can in this respect also be understood as program parts.

[0062] In this description, an execution environment can be an arithmetic logic unit configured in a certain way by parameters. A task can be a program part running or executable in an execution environment. An arithmetic logic unit can be a processor with associated hardware or, generally, an allocated physical resource, for instance a computing time portion of multi-tasking-capable hardware. They can also be virtual computing resources or logically organized computing resources on a single piece of hardware that each execute a task per se at a point in time. A program part can be a function block in the sense of IEC 61499. An arithmetic logic unit can be a core in the sense of IEC 61499.

[0063] FIG. 4a shows by way of example a control program and its program parts and events defined by the programming. The squares 42 define program parts P, X, K, T, R, Y, L, U, F, M, O and N. They can be function blocks in accordance with IEC 61499. The arrows 43 symbolize events with which program parts 42 trigger one another. Said events are assigned priorities Py here that are entered in the respective arrow, i.e. below one another 1, 4, 1, 1 in the left arrow column, below one another 4, 1, 1, 2 and at the right 1 in the middle arrow column. At the left, FIG. 4a shows the sequences that are in each case generated by the defined events.

[0064] With 41, input events are defined that trigger the control program and that are not initiated by the program itself. As a rule, they are external events, for example the arrival of sensor data that lead to certain processing processes and possibly resulting device controls. In FIG. 5a, it is again assumed that the priority 1 has the highest urgency and, in contrast, the priorities 2, 3 and 4 have decreasing urgencies.

[0065] In FIG. 4a, it should be noted that a control program considered here can only be partly triggered and executed. In FIG. 4a, it is, for example, assumed that the upper row of the function blocks P and R and the lower row of the function blocks T and U are not triggered and are therefore not executed. In accordance with FIG. 4a, triggering events only take place for the function blocks X and K, which is assumed here to be more or less simultaneous for purposes of explanation.

[0066] FIG. 4b shows the representation corresponding to FIG. 4a of the control program comprising function blocks in the sense of IEC 61499. In the upper part, the event links are shown, but without priorities, that trigger the execution of the individual program parts or function blocks.

[0067] FIGS. 5a to 5c show the dynamic sequence of the processing of the program from FIGS. 4a and 4b. It is assumed that there are two arithmetic logic units and that four different priorities are used. As already mentioned, the program parts P, R, T and U are not executed here due to the lack of an external trigger. They are therefore not shown.

[0068] FIG. 5a shows the status of the control apparatus before the initial events 41 arrive. The triangles symbolize potentially running tasks, wherein a maximum of two can be simultaneously executed due to the available two arithmetic logic units RW1 and RW2. They are all in an idle mode or a state of rest. It is assumed here that the tasks are predefined and that two tasks are in each case created per priority.

[0069] FIG. 5a symbolically shows the system state before the arrival of the external events 41 in FIG. 4a. The entire system is at rest; all the arithmetic logic units are running empty. All the queues are also empty at this moment. After the arrival of the external events 41, as shown in FIG. 4a, the system starts processing the program parts X and K and, at their respective ends, they generate events of the priorities 4 and 1 to trigger the program parts Y and L. Accordingly, at the end of the processing of the program parts X and K, the fourth event list 34 and the first event list 31 have corresponding entries, while the other event lists are empty. However, it is assumed that Y is a long-running program part triggered with a low priority. It is still running when program part L has already been processed.

[0070] As already mentioned, the incoming external events 41 can also be assigned priorities by appropriate steps or can be assumed as default. This can take place in the operating control 107.

[0071] FIG. 5b shows the state in which the system is working on the processing of the program parts L and Y. At the moment when the processing of the program parts L and Y is started, the respective events are taken out of the respective event lists so that these lists are then empty again. Program part L generates three events, each for triggering the program parts F, M and O, on its completion. The first two have priority 1, the last priority 2. Therefore, there are then two entries in the first event list 31, and one entry in the second event list 32, and the remaining event lists are empty.

[0072] FIG. 5b shows the state after the completion of the processing of the program parts X and K, in which state the program part L is executed in the meantime with the task Py 1 RW2 and the program part Y is processed with the task Py 4 RW1. Accordingly, all the queues are empty after the start of the processing of the program part L. When the processing of the program part L is completed, three events are, however, generated, of which twoto trigger the program parts F and Mare entered in the first event list 31 and one is entered in the second event list 32. Two events of the highest priority, and a further event of the next lower priority 2, are then present and a program part Y of the lowest priority 4 is still being executed.

[0073] FIG. 5c shows that the two high priority events for program parts F and M lead to their execution by processing the program parts F and M on the two arithmetic logic units RW1 and RW2. To achieve this, the program part O, which was called with the second-highest priority, or just this event of the priority 2, still remains in the queue and waits, which is graphically indicated at Py2RW1. The still running program part Y is interrupted at Py4 RW1 to enable the processing of the two high priority program parts F and M. This is schematically shown in FIG. 5c. When one of the high priority program parts F and M has been processed in the working state of FIG. 5c, the second-priority program part O can be executed next. And if an arithmetic logic unit subsequently becomes free, program part Y can be completed afterwards.

[0074] In this way, it is ensured that high priority program parts can be reliably executed and are not accidentally blocked by possibly long-lasting low priority processes.

REFERENCE NUMERAL LIST

[0075] 11, 12, 21, 24, 52 program parts [0076] 13, 14, 15, 23, 25, 53 events [0077] 31 to 35 event lists [0078] 51 external event [0079] 101 circuit board [0080] 102 CPU, core [0081] 103 CPU, core [0082] 104 communication structure [0083] 105 communication input [0084] 106 communication output [0085] 107 operating control [0086] 110 function block [0087] 111 incoming event [0088] 112 outgoing event [0089] 113 input data [0090] 114 output data [0091] 115 event link [0092] 116 data link