Execution environment for executing event-oriented control programs

Abstract

The invention relates to an execution environment for executing an event-oriented control program of a programmable logic controller, wherein the control program comprises a plurality of function modules to be executed sequentially, the execution environment being designed to execute the function modules event-controlled upon occurrence of activation events associated with the respective function modules. Here, the respective activation events of the function modules to be executed sequentially form an event chain. The execution environment comprises a monitoring module for monitoring an execution duration of the function modules of the event chain, wherein the monitoring module is designed to check whether the execution duration exceeds a predefined duration.

Description

Technical Field

[0001] The present invention relates to an execution environment for executing event-oriented control programs for programmable logic controllers and a method for executing event-oriented control programs for programmable logic controllers. Background Technology

[0002] Programmable logic controllers (PLCs) are used in automation technology to control automated processes and machine flows. For this purpose, PLCs are typically connected to sensors that acquire the state of the automated process and transmit sensor signals representing that state to the controller. The controller then generates output signals for controlling actuators based on the logical associations of the read sensor signals, whereby the actuators influence the state of the automated process based on the output signals. Sensors can be, for example, position sensors, rotation sensors, switches, optical encoders, etc., while actuators can be, for example, drivers, relays, or contactors.

[0003] The logic associations used to process the read sensor signals and generate the output signals are typically components of the control program of a programmable logic controller (PLC), which is stored in the controller's memory module. To execute the control program, the PLC typically includes an execution environment that executes the control instructions of the control program in a pre-defined order. Additionally, the execution environment can manage the working memory required to execute control commands and / or coordinate the reading of sensor signals and the output of output signals.

[0004] To ensure reliable control of automated processes, the execution environment must typically be configured to provide an output signal within a predefined reaction time after reading sensor signals. Such systems are also known as real-time control systems. Here, the execution environment must ensure adherence to the predefined reaction time regardless of the system's load and the design of the control program, such as potential programming errors. If the reaction time is exceeded, the execution environment can initiate an appropriate error response. Providing an output signal within the predefined reaction time can also be a prerequisite for the safety-oriented control of the automated process.

[0005] Typically, real-time control systems are implemented using a cyclic execution environment. In this environment, fixed time windows are defined within each cycle for reading sensor signals, calculating output signals, and outputting output signals. These time windows repeat periodically over multiple cycles. The time windows also define the maximum response time of the control system. Therefore, in the case of a cyclic control system, to monitor the response time, it is sufficient to check at the end of each processing cycle whether all the necessary output data exists.

[0006] In addition to periodic control programs and execution environments, event-driven control programs, such as those defined in the standard IEC 61499, are also used in automation technology. These programs comprise multiple functional modules, where the reading of sensor signals, the logical association of read sensor signals, or the output of output signals is achieved through combinations of individual functional modules and additional user-defined program text (code). Here, the execution of functional modules is event-controlled, occurring when activation events associated with each functional module occur; specifically, the execution of a previous functional module generates the activation event for the next functional module to be executed.

[0007] Furthermore, while event-driven execution models are suitable for distributed control systems, the lack of predefined processing cycles means that adherence to predefined response times cannot be guaranteed during execution. To reduce the probability of exceeding response times, the computational power in event-driven controllers is often significantly over-engineered, for example, exceeding 50%. This reduces the probability of insufficient computational power for timely execution of functional modules under high loads; however, it still cannot guarantee adherence to predefined execution times. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide an execution environment for executing event-oriented control programs with improved real-time capabilities and a method for executing event-oriented control programs.

[0009] The aforementioned technical problem is solved by the execution environment for executing event-oriented control programs and the method for executing event-oriented control programs according to the present invention. Further extensions are also provided.

[0010] An execution environment is proposed for executing an event-oriented control program of a programmable logic controller (PLC), wherein the control program comprises multiple functional modules to be executed sequentially. The execution environment is designed to execute the functional modules in an event-controlled manner upon the occurrence of activation events associated with each functional module, wherein the activation events of the sequentially executed functional modules form an event chain. The execution environment includes a monitoring module for monitoring the execution duration of the functional modules in the event chain, wherein the monitoring module is designed to check whether the execution duration exceeds a pre-given duration.

[0011] It has been recognized within the scope of this invention that, even in the case of event-oriented control programs, adherence to a pre-defined execution duration can be achieved by forming event chains of functional modules to be executed sequentially and monitoring the time required to execute each event chain. If the pre-defined duration is exceeded, a predefined reaction can then be performed, such as stopping the execution of the control program, and / or triggering an overrun reaction, such as transferring the controlled machine to a safe state. This is particularly feasible for real-time applications also implemented using event-oriented control programs, where a response to sensor signals received by the controller must be performed within a pre-defined duration.

[0012] The functional modules of the control program can each include at least one logical association, wherein the execution of each logical association of a functional module is triggered by an activation event associated with that functional module. The logical associations of the functional modules can, for example, be corresponding components of the algorithms of related functional modules. The functional modules to be executed sequentially in the control program can each be designed to generate an activation event upon execution, which triggers the execution of the next functional module in the event chain. In this regard, the functional modules in the event chain are interconnected, for example, through event connections, such that the activation event of each subsequent functional module is generated when the functional module directly preceding it is executed. Here, the event connections can define the relationships between activation events in the various functional modules. The control program can, for example, conform to the requirements of standard IEC 61499, and the functional modules can, for example, be function blocks as defined in that standard.

[0013] Typically, an event chain can include all activation events, which are generated based on a pre-defined start event to trigger the execution of functional modules to be executed sequentially, up to the terminating module to be executed as the last functional module in the event chain. The start event can be, for example, an external activation event, provided when an external input interface of the execution environment is activated. The external input interface can be, for example, an interface with an execution resource of the control unit that executes the execution environment. Specifically, the external input interface can be an external interface of the device executing the control program, such as a sensor input.

[0014] For example, a start event can be provided based on sensor signals received through the control unit, such as when a sensor signal is received through the control unit or when the state of a sensor signal received through the control unit changes. The start module activated by the start event as the first functional module can be, for example, a service interface function block configured as a responder function block according to IEC 61499.

[0015] The termination module is defined by the last functional module in the event chain. After the termination module is executed, no activation signals are generated for other functional modules used to execute the control program. The termination module can be, for example, a functional module designed to output output signals for the actuator through an external output interface of the execution environment. The termination module can be, for example, a service interface function block configured as a requester function block according to IEC 61499. The termination module can also be a functional module designed to change the internal state of the controller or store data values ​​for further use, such as during the execution of the control program.

[0016] A pre-defined duration can define, for example, the controller's response time to an input signal. The input signal can, for example, trigger the activation of the starting module of an event chain. The event chain can, for example, include all activation events triggered by receiving sensor signals via an input interface, which occur sequentially until a terminating module based on the sensor signal has been executed, and which, for example, outputs an output signal based on the sensor signal via an output interface, changes the state based on the sensor signal, or stores data values ​​based on the sensor signal.

[0017] During the execution of the control program and / or the execution of each functional module in the event chain, the monitoring module checks whether the execution duration exceeds a pre-defined duration. The monitoring module can be constructed separately from the execution module of the execution environment, which executes each functional module in the event chain. Such an execution module may, for example, include a scheduler. The execution module may, for example, manage an event queue, storing activation events to be executed. The execution environment or execution module may, for example, be configured to process activation events stored in the queue using a FIFO (first-in-first-out) or LIFO (last-in-first-out) method.

[0018] The control program may include, for example, multiple event chains, and the execution environment may be designed to execute each event chain sequentially or in parallel. The monitoring module can then be designed to check whether the execution duration of the functional modules in each event chain exceeds a pre-defined duration for each event chain. Here, the pre-defined durations for each event chain may be the same or at least partially or completely different from each other.

[0019] An execution environment may include multiple sub-environments that can be executed separately from each other, wherein each sub-environment is configured to execute on separate execution resources of the controller. Execution resources may be, for example, tasks, processors, etc. For example, execution resources may be resources defined in IEC 61499.

[0020] Typically, execution resources can be provided through one or more logical units of the controller, such as a CPU or microprocessor. Here, execution resources can provide mechanisms and context information that allow control programs to be executed on the logical units. Each logical unit can be configured to provide more than one, for example, two, execution resources in parallel and independently of each other.

[0021] Monitoring the execution duration via a monitoring module can be limited, for example, to functional modules executing on the same execution resource or within the same sub-environment. Therefore, when program portions or event chains of different priorities are executed in different sub-environments, the different execution priorities of each functional module can be considered in the monitoring. Typically, each event chain of the control program may consist only of functional modules, each executing on the same execution resource of the programmable logic controller. Alternatively, at least one event chain may also include functional modules executing on different execution resources.

[0022] The monitoring module can be designed to determine the elapsed execution duration based on a timestamp indicating the start of the execution duration. Here, the monitoring module can compare the timestamp with the current time to determine the elapsed execution duration. Alternatively, the monitoring module can be configured to determine the elapsed execution duration using a periodic pulse generator, wherein the monitoring module is configured to count the pulses generated by the pulse generator and determine the elapsed execution duration from the number of pulses.

[0023] The monitored execution duration can begin with the start of execution of the first functional module in the event chain. Alternatively, the monitored execution duration can also begin with the generation of the start event to account for the delay between the generation of the start event and the start of execution of the first functional module or the start module of the event chain.

[0024] The monitored execution duration may also include an additional delay that elapses before the start event is generated. This additional delay may include, for example, a period of time elapsed since an externally originating event, occurring outside the execution environment and triggering the start event, has occurred, such as since the generation or acquisition of a sensor signal that triggers the execution of the event chain. The delay may also include dead time, which occurs when reading sensor signals via a data connection, such as a fieldbus connection.

[0025] The monitoring environment can be designed to determine the execution duration by checking the fill level of the event queues in the execution environment. Here, the execution environment or execution module can manage separate queues for each event chain or for each start event. The execution duration ends when the queue is empty.

[0026] The execution environment or execution module can be configured for event-triggered scheduling. The execution environment can also be configured to distribute the available computing power of the programmable logic controller (PLC) according to predefined criteria, such as evenly distributing it across the functional modules of the control program (fair scheduling). For this purpose, the execution environment can implement periodic time-series control. For example, the execution environment can periodically query all instances of the functional modules for any unoccurred activation events (cyclic scan approach) and process the unoccurred activation events according to a predefined order.

[0027] The execution environment or execution module can be designed to periodically process activation events for each functional module. Here, the monitoring module can be designed to determine the execution duration by checking at the end of each cycle whether all functional modules triggered by activation events of the relevant cycle have been executed. Exceeding a predetermined duration can be determined, for example, by the existence of unprocessed activation events from the ended processing cycle after the end of a processing cycle. The monitoring module can be configured, for example, to aggregate the unprocessed activation events of each functional module in the event chain after each processing cycle.

[0028] The execution environment or execution module can be configured, for example, by using queues allocated to each functional module and / or by using tags to assign each activation event to a predetermined, such as the current processing cycle. Each queue or tag can here contain or display only the activation events of the respective functional module.

[0029] The monitoring module can be configured to check once after the last functional module in the execution event chain whether the execution duration exceeds a pre-defined duration. This enables monitoring of resource-efficient execution duration.

[0030] The monitoring module can also be configured to check whether the execution duration exceeds a pre-defined duration after each functional module that executes the activation event associated with the event chain. This allows for timely detection of exceeding the pre-defined duration and initiation of associated exceedance responses during event chain processing. Simultaneously, the computational overhead for monitoring the execution duration remains low.

[0031] The monitoring module can be configured, for example, to periodically check whether the execution duration exceeds a pre-defined duration.

[0032] The monitoring module can, for example, execute in parallel with the execution module, or as a separate task. The monitoring module may also include timers, such as hardware timers, which execute in parallel with the execution module. An interrupt is generated when the timer expires.

[0033] For example, a timer can be initialized for a pre-defined duration and start when the execution of an event chain begins, and end when the execution of the event chain ends. The monitoring module can then determine that the timer has exceeded the pre-defined duration by doing so.

[0034] Timers can also be initialized with a periodic duration, after which it should be checked whether all functional modules of the event chain have been executed and whether a pre-given duration has been exceeded. Timers can be started at the beginning of the event chain execution. If the monitoring module determines after the timer expires that all functional modules of the event chain have not been executed, but the pre-given duration has not been exceeded, the timer can be re-initialized and started with the periodic duration.

[0035] The execution environment may also include a statistics module configured to statistically analyze the elapsed execution duration, for example, after the execution of each functional module. For instance, the statistics module may determine statistical parameters of the lifetime of each activation event during its processing, such as minimum and / or maximum and / or average values. With such a statistics module, delays exceeding a pre-defined duration can be easily located when processing event chains.

[0036] The lifetime of each activation event can be the time period that has elapsed since the start of the execution duration. For example, the lifetime of each activation event can be calculated when the relevant activation event is provided at the event output of a preceding functional module and / or when the relevant activation event is entered at the event input of the relevant functional module and / or when the relevant activation event is processed by the execution algorithm of the relevant functional module. The lifetime of each activation event can also be calculated, for example, based on at least one timestamp indicating the start of the execution duration.

[0037] In one implementation of the execution environment, the first activation event of the event chain is a start event generated when the external input interface of the execution environment is activated, and / or the last of the functional modules to be executed sequentially forms a termination module for inducing a system response. As the execution duration, the response time between the activation of the input interface and the system response based on the activation of the input interface can therefore be monitored. This enables effective monitoring of the response time to input signals received via the input interface.

[0038] System responses may include, for example, activating external output interfaces of the execution environment. Alternatively or additionally, system responses may also include changes to the internal state of the execution environment, such as changes to the internal state of objects managed within the execution environment. Alternatively or additionally, system responses may also include storing data values ​​for further use.

[0039] Each event chain of the control program can be defined such that the starting module of each event chain is activated by activating the external input interface of the execution environment, and the terminating module of each event chain triggers a system response of the execution environment. For example, a unique event chain can be defined for each combination of such starting and terminating modules.

[0040] According to one implementation, the execution environment is configured to generate a timestamp indicating the start of the execution duration, and a monitoring module is configured to determine the execution duration by comparing the timestamp with the current time. This timestamp allows for a simple determination of the execution duration elapsed at any subsequent time point. Furthermore, when the activation event of an event chain is processed in multiple different sub-environments of the execution environment, such timestamps enable reliable determination of the execution duration, for example, by transmitting timestamps over event connections between various sub-modules of the execution environment.

[0041] A timestamp can, for example, indicate the point in time when the execution of the first module in an event chain begins. Alternatively or additionally, a timestamp can also indicate the point in time when the start event is created. Thus, the delay between the creation of the start event and the execution of the start module can be taken into account when examining the execution duration.

[0042] The timestamp may also take into account an additional delay time prior to the creation of the start event. This delay time may include the delay preceding the creation of the start event due to nondeterministic data processing and / or nondeterministic data transmission, such as the nondeterministic transmission of sensor signals. Specifically, the delay time may include the dead time for the transmission of sensor signals via the bus system.

[0043] The monitoring module can be configured to check the execution duration by comparing the current time with the timestamp of the activation event of the corresponding executed functional module. This check can be performed, for example, once after each functional module is executed, or it can be performed during its execution. The monitoring module can also be configured to compare the timestamp with the current time only after each functional module in the event chain has been executed. Alternatively, the monitoring module can compare the timestamp with the current time during the execution of each functional module in the event chain, for example, multiple times or periodically.

[0044] The execution environment can be configured, for example, to associate the same timestamp with all active events in the event chain.

[0045] According to one implementation, the execution environment is configured to first associate a timestamp with the start event that triggers the execution of a first functional module in the event chain. Upon execution of each functional module, an activation event is created for the functional module to be executed subsequently, and the timestamp of the activation event of the corresponding executed functional module is associated with the activation event of the subsequent functional module. This enables the timestamp to be iteratively associated with all activation events in the event chain during the runtime of the control program.

[0046] The execution environment may, for example, associate a timestamp with a start event during the runtime of the control program and / or at its creation. Subsequently, during the runtime of the control program and / or at its respective creation, the execution environment may also associate a timestamp with all subsequent activation events created based on the start event in the event chain, for example by copying the timestamps of the corresponding executed functional modules. Activation events for functional modules to be executed subsequently may be generated separately during or at the end of the execution of each functional module.

[0047] According to one embodiment, the execution environment for executing functional modules includes multiple sub-environments that can be executed separately from each other, wherein the sub-environments can be executed on separate execution resources of the controller. An event chain includes a first functional module triggered by a start event of the event chain and executed in a first sub-environment, and a second functional module triggered by a subsequent event in the event chain and executed in a second sub-environment. Furthermore, a monitoring module includes a first sub-module and a second sub-module, wherein the first sub-module is configured to monitor the execution duration in the first sub-environment, and wherein the second sub-module is configured to monitor the execution duration in the second sub-environment.

[0048] Submodules based on the monitoring module can also monitor whether the execution duration exceeds a pre-defined duration across resources. Here, submodules can connect to each other via communication connections, exchanging information to determine the elapsed execution duration. For example, information about the elapsed execution duration during execution in a first sub-environment can be transmitted from a first submodule to a second submodule via a communication connection. This communication connection can be implemented, for example, via a bus system, such as a fieldbus system, between the first and second execution resources.

[0049] The transmitted information may include, for example, the sub-execution duration that has already elapsed in the first sub-environment during execution, or be composed of sub-execution durations. The second sub-environment may take the sub-execution durations into account when monitoring the execution duration, for example, by adding the sub-execution durations to other sub-execution durations determined in the second sub-environment.

[0050] The transmitted information may include or consist of the start time of the execution duration. For example, the transmitted information may include or consist of a timestamp indicating the start of the execution duration. For example, the timestamp may be transmitted from the first execution environment to the second execution environment, for instance, via an event connection linking the first and second sub-environments. Then, in the second sub-environment, the timestamp may be associated with a first activation event created within the event chain in the second sub-environment. Additionally, the timestamp may also be associated with all other activation events created in the second execution environment. If the second sub-environment is configured to determine the execution duration based on the timestamps associated with each activation event, the sub-execution duration can be considered when creating the timestamps of the activation events for the first functional module to be executed in the second sub-environment.

[0051] According to one implementation, the execution environment is configured to transmit a timestamp indicating the start of the monitored execution duration from a first sub-environment to a second sub-environment via a communication connection. Thus, the second submodule can determine the execution duration simply by comparing the transmitted timestamp with the current time.

[0052] In this regard, the transmitted timestamp represents the aforementioned information used to determine the execution duration that has elapsed in the first sub-environment during execution. To determine the current time, the first and second sub-environments may include a time base synchronized with each other.

[0053] According to one embodiment, the execution environment includes a communication channel between a first and a second sub-environment, wherein the execution environment is configured to transmit via the communication channel an overdue duration determined by the second sub-module to the first sub-module. This also enables the first sub-module to trigger an overdue response triggered by the overdue duration.

[0054] For example, all devices that execute the event chain of a functional module can perform actions beyond the reaction, especially in the case of sub-modules implemented on different devices.

[0055] A communication channel used for transmission that exceeds a predetermined duration can also be called an over-channel. An over-channel can be implemented as a bidirectional communication channel between two sub-environments.

[0056] In addition to the first and second sub-environments, the execution environment may include a third sub-environment, and the monitoring module may include a third sub-module. The third sub-environment and the third sub-module can execute on the controller's own execution resources or on the controller's own execution resources. The control program may include multiple sequentially executed additional functional modules, which form another event chain. The first additional functional module of the additional event chain can execute in the first sub-environment, and the second additional functional module can execute in the third sub-environment.

[0057] The first and third sub-environments can be connected to each other via an additional communication channel. The execution environment can be configured to transmit, via the additional communication channel, an overrun of a predetermined duration, determined by the second sub-module and transmitted to the first sub-module, to the third sub-module. Receiving an overrun of the predetermined duration transmitted via the additional communication channel can trigger an overrun response in the third sub-module.

[0058] Typically, if a pre-given duration for executing an event chain is exceeded, an overrun reaction can be triggered in all execution resources of one of the functional modules in the event chain. An overrun reaction can also be additionally triggered in all execution resources that execute functional modules of another event chain associated with the event chain. This other event chain associated with the event chain can, for example, be an event chain containing at least one functional module that executes in the same sub-environment as one of the functional modules in the event chain.

[0059] Additional event chains associated with an event chain can also be all event chains for controlling the device portion and / or sub-functions of the device controlled by the control program. Alternatively or additionally, additional event chains associated with an event chain can also include all event chains associated with a pre-defined group of peripheral devices of the device, such as a pre-defined group of sensors and / or actuators (e.g., drivers, motors, etc.) and / or I / O channels, for example, for analyzing and / or controlling the peripheral device group. Thus, execution beyond the response can be limited to the event chain and all additional event chains associated with it, and therefore, for example, to the device portion or the sub-functions of the controlled device.

[0060] For each event chain in another event chain associated with a given event chain, different override responses can be triggered to execute the execution resources of the related other event chain. For example, for one part of said other event chain, a transition to a safe state can be executed as an override response, while for another part of said other event chain, a stop controlled by the user program can be executed. For this purpose, the associated event chains, such as the event chains of individual device parts, can be defined in the programming environment used to create the control program. Furthermore, the relationships between associated event chains can be defined.

[0061] To activate a functional module to be executed in the second sub-environment, the first sub-environment can connect to the second sub-environment via an event channel. Here, after executing the last functional module in the first sub-environment, an activation event for activating the first functional module in the second sub-environment is transmitted via the event channel. Along with the activation event, an associated timestamp may also be transmitted via the event channel.

[0062] Event channels and / or exceedance channels can be implemented, for example, through a communication connection connecting the first execution resource and the second execution resource, such as a bus system. Exceedances for a pre-given duration, determined by the second submodule, can be transmitted to the first submodule via exceedance channels using exceedance messages.

[0063] Multiple event channels can be set between two sub-environments to transmit multiple activation events, such as activation events of multiple event chains. Correspondingly, multiple override channels can also be set between the two sub-environments. Alternatively, a single override channel can be set between the two sub-environments, for example, when the first sub-environment triggers the same override response for each event chain if all overrides exceed a pre-defined duration.

[0064] The first overrun response performed by the first sub-environment when the duration exceeds a predetermined time, as determined by the second sub-environment, may be different from the second overrun response performed by the second sub-environment when the duration exceeds a predetermined time.

[0065] Typically, in all implementations of the execution environment, the executed overrun response can be configured by the user. An overrun response may, for example, include the output of an output signal. An overrun response may also trigger the execution of a separate control program or input to another control program executing in parallel, such as input to a non-safety-oriented standard control program. The overrun response can respectively cause a transition of the machine controlled by the controller to a safe state.

[0066] Furthermore, exceeding the allowed response time may include interrupting the execution of the control program in at least one sub-environment of the execution environment or in all sub-environments of the execution environment. However, if the duration exceeds a pre-given time limit, the control program may also continue execution in at least one sub-environment or in all sub-environments.

[0067] In addition to exceeding the time limit message, diagnostic information can also be transmitted from the second subenvironment to the first subenvironment via the exceeding channel. The diagnostic information may include, for example, a flag of the subenvironment in which a predetermined time limit has been exceeded. This flag may also be, for example, a flag of a sub-device of the execution subenvironment executing resources or controllers. If the first subenvironment forwards the time limit exceeding the time limit determined by the second subenvironment to another subenvironment, the first subenvironment may forward the flag along with the exceeding message. In these cases, it may also be determined in another subenvironment in which the predetermined time limit has been exceeded.

[0068] Each sub-environment can be constructed to evaluate the transmitted flag and perform over-reactions based on the transmitted flag, for example, performing different over-reactions in cases of different transmitted flags.

[0069] Additionally, the diagnostic information may also include event flags, wherein the event flags describe an activation event that, when executed, has been determined to have exceeded a pre-given duration.

[0070] Alternatively or additionally, each submodule may also be configured to directly store diagnostic information, for example, on the sub-device executing the corresponding submodule or on a central device connected to the sub-devices via a data connection.

[0071] According to one implementation, the execution environment includes sub-environments connected to multiple other sub-environments via communication channels. The sub-environments connected to the multiple other sub-environments are designed to transmit messages received via one of the communication channels for a predetermined duration to all the remaining sub-environments connected via the communication channels. This enables easy forwarding of multiple messages based on a point-to-point principle.

[0072] Subenvironments connected to multiple other subenvironments can be designed to store information about a communication channel, received through which for a predetermined duration, for example, so that the information can be provided to the evaluation module of the execution environment at a later point in time. Subenvironments connected to multiple other subenvironments can also be designed to transmit diagnostic information to all the remaining subenvironments connected via the communication channel. Therefore, based on the point-to-point principle, not only are messages distributed, but diagnostic information is also distributed.

[0073] In one implementation of the execution environment, the control program includes at least two event chains, each including an activation event for activating at least one common functional module. The control program is designed to generate a first activation event of a first event chain after the common functional module is executed, and alternatively or cumulatively generate a second activation event of a second event chain. A monitoring module is then designed to check whether the execution duration of the functional module in the first event chain exceeds a predetermined duration, and to check whether the execution duration of the functional module in the second event chain exceeds another predetermined duration, or not to perform a check on the execution duration of the functional module in the second event chain.

[0074] By monitoring activation events generated from all self-executing common functional modules of the first event chain and activation events generated from all self-executing common functional modules of the second event chain in different ways, especially according to different pre-given durations, the monitoring of the execution duration of each event chain can be flexibly adapted, for example, to adapt to different priorities or security requirements when executing each event chain.

[0075] The first and second activation events can be assigned different priorities or pre-defined durations, for example, during their generation in the execution of the control procedure, or in the form of additional information or attributes associated with the relevant activation events. These priorities or durations can then be applied to all subsequent events generated based on the first or second activation event. The association between activation events generated by a common functional module and the first and second event chains, or the priorities or pre-defined durations of the first and second activation events, can be stored in the control procedure, and may have been assigned, for example, during the establishment of the control procedure.

[0076] Common functional modules may include, for example, algorithms or logical associations that generate intermediate information. This intermediate information can then be used by the functional modules of the first event chain to perform time-critical and / or safety-critical control of the actuator, while the functional modules of the second event chain further process the intermediate information within the scope of non-time-critical and / or non-safety-critical functions, such as storing the intermediate information for subsequent analysis. In these cases, the pre-given duration for the first event chain may differ from the pre-given duration for the second event chain, or it may be possible to check only whether the execution duration of the first event chain exceeds the pre-given duration without checking the execution duration of the second event chain.

[0077] In one implementation of the execution environment, the monitoring module is designed to check whether a pre-defined total duration for the execution of multiple functional modules in an event chain has been exceeded. The total duration can also be pre-defined for the execution of all functional modules in the event chain. By pre-defining the total duration for multiple or all functional modules in the execution event chain, delays in the execution of individual functional modules can be compensated for by rapidly executing other functional modules without prematurely determining that the pre-defined duration has been exceeded.

[0078] In one implementation of the execution environment, the monitoring module is designed to check whether a pre-defined individual duration has been exceeded for the execution of each functional module in the event chain. This enables the early detection of periods that are about to be exceeded, considering the total allowed duration for all functional modules in the execution event chain.

[0079] Here, different individual durations can be pre-defined for the individual durations of functional modules executing in different sub-environments of the execution environment. Alternatively, individual durations can be pre-defined uniformly for all functional modules executing in the corresponding identical sub-environments. However, individual durations can also be pre-defined individually for each separate functional module in the event chain. For at least one of the different individual durations, for example, for each individual duration, an unrestricted duration can also be pre-defined separately.

[0080] The monitoring module can be configured to execute an exceedance response once it is determined that one of the individual durations has been exceeded. The exceedance response can be associated with either the individual duration that has been exceeded or with the functional module that has exceeded its individual duration.

[0081] Each functional module can be predefined for the monitoring module. When executing a functional module, for example during controller initialization, a check can be paused to see if an associated predefined single duration has been exceeded. Alternatively or additionally, a sub-environment can be predefined to pause the check on whether the executed functional module has exceeded an associated predefined single duration.

[0082] In one implementation of the execution environment, the monitoring module is designed to monitor whether the execution duration of multiple event chains exceeds a pre-defined duration, wherein a pre-defined duration for each event chain is pre-defined based on the start event that triggers each event chain. This enables differentiation between start events when a pre-defined duration is given, and, for example, assigning different durations (e.g., shorter durations) to time-critical and / or safety-critical start events, such as start events based on time-critical and / or safety-critical sensor signals, compared to time-non-critical and / or safety-non-critical start events.

[0083] In one implementation of the execution environment, the monitoring module is designed to trigger an overrun response, such as an alarm message, and / or a control response, such as a control response for transferring a machine controlled by a control program to a safe state, when a predetermined duration is exceeded. The overrun response can be, in particular, a safety response.

[0084] The monitoring module can be designed to monitor whether the execution duration of an event chain exceeds a pre-defined duration and additionally monitor whether it exceeds another pre-defined duration, triggering different exceedance responses when the pre-defined duration is exceeded and when the other pre-defined duration is exceeded. For example, the other pre-defined duration may be shorter than the pre-defined duration, and the additional exceedance response triggered when the other pre-defined duration is exceeded may be a pre-information indicating the danger of exceeding the pre-defined duration and the subsequent triggered exceedance response.

[0085] Other overrun responses may be warning messages, such as alarms or diagnostic messages, and overrun responses may also be control responses, such as those used to transfer a machine controlled by a control program to a non-critical and / or controlled and / or safe state.

[0086] The overrun module can be designed to interrupt the execution of functional modules via the execution module once the monitored execution duration exceeds a pre-defined duration. In these cases, the execution module can execute the overrun procedure used to control the overrun response, rather than the functional modules in the event chain.

[0087] In one implementation of the execution environment, the monitoring module is designed to check whether the execution duration exceeds a pre-defined duration after each functional module associated with an activation event in the event chain is executed. In this design of the monitoring module, the computational power required to monitor the execution duration is limited compared to, for example, continuously monitoring the execution duration. The execution duration can be checked for exceeding the pre-defined duration only after each functional module associated with an activation event in the event chain is executed.

[0088] In one extended implementation of the execution environment, the monitoring module is designed to check whether the execution duration exceeds a pre-defined duration during each functional module in the execution event chain. This enables a particularly timely response to instances where the execution duration exceeds the pre-defined duration.

[0089] Furthermore, a method for executing an event-oriented control program for a programmable logic controller is described, wherein the control program includes a plurality of functional modules to be executed sequentially, and wherein the functional modules are executed in an event-controlled manner upon the occurrence of an activation event associated with each functional module. Here, the method includes the following steps:

[0090] - An event chain is formed by the activation events of the functional modules to be executed sequentially;

[0091] - The execution duration of the functional modules that monitor the event chain;

[0092] - Check if the execution duration exceeds the pre-defined duration.

[0093] This method can be implemented by a computer. In particular, it can be executed using the described execution environment. Conversely, the execution environment can be designed to execute individual or all steps of the described method when executed on a controller. In this regard, all effects and extensions disclosed in conjunction with the execution environment also relate to the described method, and vice versa.

[0094] The formation of event chains from activation events can be performed, for example, during the analysis of the control program before its execution. The analysis of the control program can be performed, for example, using a programming environment designed to create the control program. When forming the event chain, all functional modules executed sequentially from the start module to the end module can be identified, and the associated activation events can be summarized within the event chain. Similarly, separate event chains can be formed for all possible combinations of the start and end modules.

[0095] Furthermore, a programmable logic controller with a memory module is described, wherein the memory module stores an execution environment, as described, for execution by the controller. The controller can provide multiple execution resources. Here, the execution resources can be arranged at least partially distributed across different sub-devices of the controller. The sub-devices can be connected to each other via communication connections, such as wireless and / or wired connections. The communication connection can be, for example, a fieldbus system. Each sub-device can include its own separately constructed memory module, and each memory module can store a sub-environment of the execution environment to be executed by the relevant sub-device.

[0096] Furthermore, a non-volatile computer-readable medium is described, on which instructions for performing individual or all steps of the described methods or for implementing the described execution environment are stored. The computer-readable medium may be configured as a physical medium, such as a CD or DVD, or as a data storage location accessible via a data connection, such as the Internet. The medium may be configured as, for example, an online software repository or a cloud data storage device. Attached Figure Description

[0097] The present invention will now be described by way of example with reference to the accompanying drawings. Here, schematic diagrams are provided respectively:

[0098] Figure 1 A machine with a controller for executing event-driven control programs is shown;

[0099] Figure 2 The functional modules of the control program are shown;

[0100] Figure 3 The execution environment for executing control programs by the controller is shown;

[0101] Figure 4 The event chain of the control program is shown;

[0102] Figure 5 This illustrates transfers between the controller's execution resources exceeding a pre-defined duration;

[0103] Figure 6 This illustrates the further overlay of transfers between the controller's execution resources for a pre-given duration;

[0104] Figure 7 Another implementation of the execution environment is shown;

[0105] Figure 8 Another implementation of the execution environment is shown;

[0106] Figure 9 Another implementation of the execution environment is shown;

[0107] Figure 10 Another implementation of the execution environment is shown;

[0108] Figure 11 Another implementation of the execution environment is shown;

[0109] Figure 12 Another implementation of the execution environment is shown. Detailed Implementation

[0110] Figure 1 Machine 1 is shown, exemplarily configured to process workpiece 195. Machine 1 includes a conveyor 186 and a gripper 181 on which workpiece 195 is conveyed, received by the gripper 181, and subsequently placed in another location. To move the gripper 181, machine 1 includes a lateral movement mechanism 182 driven by a first actuator 183 and a height movement mechanism 184 driven by a second actuator 185. The conveyor 186 is driven by a third actuator 187. Actuators 183, 185, and 187 are configured herein as electrically driven devices.

[0111] In addition to actuators 183, 185, and 187, machine 1 also includes a safety-oriented sensor 188 for measuring the distance between gripper 181 and each workpiece 195 on conveyor 186, and another non-safety-oriented sensor 189. Sensor 189 is configured as a user interface and can be used to pre-given characteristic data of workpiece 195.

[0112] Machine 1 also includes a programmable logic controller (PLC) 5, which is connected to actuators 183, 185, 187 and sensors 188, 189 via a communication connection 60 configured as a fieldbus. The PLC 5 includes a first sub-device 310 and a second sub-device 320, which are separately connected to the communication connection 60. Through the communication connection 60, input signals are transmitted from sensors 188, 189 to the sub-devices 310, 320 of the controller 5, and output signals are transmitted from the sub-devices 310, 320 to actuators 183, 185, 187.

[0113] The controller 5 has an event-oriented control program 10, wherein a first subroutine 11 of the control program 10 is stored in the memory module of the first sub-device 310, and a second subroutine 12 of the control program 10 is stored in the memory module of the second sub-device 320. The control program 10 includes all instructions for reading sensor signals via the communication connection 60, generating output signals by means of logical associations of the read sensor signals, and outputting the output signals via the communication connection 60.

[0114] To execute control program 10, controller 5 includes execution environment 100, which has a first sub-environment 101 executed on a first sub-device 310 and a second sub-environment 102 executed on a second sub-device 320. Sub-environments 101 and 102 of execution environment 100 each include an execution module 120 for executing control program 10 and sub-modules 111 and 112 of a monitoring module 110 for monitoring the execution duration of control program 10 by programmable logic controller 5. Here, the first sub-module 111 of monitoring module 110 is part of the first sub-environment 101, and the second sub-module 112 of monitoring module 110 is part of the second sub-environment 102.

[0115] When executing control program 10, it must be ensured that the actuators 183, 185 used to move the gripper 181 respond to an input signal read via a safety-oriented sensor 188 for a predetermined duration. This input signal indicates that the gripper 181 is approaching the workpiece 195. Otherwise, there is a risk that the gripper 181 may collide uncontrollably with the workpiece 195 and damage it. In this respect, the input signal provided by the safety-oriented sensor 188 is a safety-critical input signal.

[0116] Conversely, the parameters of workpiece 195 read by sensor 189 are used solely to optimally match the movement of gripper 181 to the inertia of workpiece 195. For this purpose, the read parameters are used to generate matching output signals for actuators 183 and 185 during the execution of control program 10. The generation of the matching output signals is a non-safety-oriented part of control program 10, which is not subject to time constraints.

[0117] The monitoring module 110 is designed to monitor whether the execution duration of a portion of the control program 10 exceeds a predetermined duration. This portion controls the gripper 181's response to input signals provided by a safety-critical sensor 188, and, upon exceeding the predetermined duration, triggers a safety response to transfer the machine 1 to a safe state, i.e., to stop the gripper 181 and the conveyor 186. For example, such a delay in responding to the input signal from sensor 188 may occur if the continuous generation of a matched output signal based on a sensor signal from sensor 189 is not interrupted in time, for example, due to a programming error in the control program 10.

[0118] Control program 10 executes according to standard IEC 61499 and includes multiple functional modules constructed as functional blocks according to IEC 61499. Figure 2Two of these functional modules 20 are illustrated exemplarily. Each functional module 20 is interconnected via an event connection 80 and a data connection 82. Here, each event connection 80 connects the event output of the preceding functional module 84 to the event input of the subsequent functional module 85. Each functional module 20 receives an activation event via the event input, which triggers the execution of the respective functional module 20. Each functional module 20 provides an activation event on its side via an event output, which causes the execution of the subsequent functional module 85. Data required for the execution of each functional module 20 is transmitted between the functional modules 20 via the data connection 82.

[0119] Figure 3 The implementation of execution environment 100 on sub-devices 310 and 320 of programmable logic controller 5 is shown. For executing control program 10, first sub-device 310 provides first execution resource 311 and second execution resource 312. Second sub-device 320 provides third execution resource 321 and fourth execution resource 322. Execution environment 100 includes a first sub-environment 101 executed via first execution resource 311 and a second sub-environment 102 executed via third execution resource 321. Further sub-environments 104 of execution environment 100 are correspondingly executed via second and fourth execution resources 312 and 322.

[0120] The control program 10 includes a first application 15, a second application 16, and a third application 17. Applications 15, 16, and 17 each include functional modules 20 interconnected via event connections and data connections. The first and second applications 15 and 16 each include a start module 21 and first and second termination modules 27 and 28 respectively connected to the start module 21 of their respective applications. The third application 17 includes only one termination module 27 connected to the start module 21. Here, each termination module 27 and 28 can be respectively connected via... Figure 3 Additional functional modules 20, not shown, are connected to their respective start modules 21. Furthermore, each application 15, 16, and 17 may have more than one start module 21. The start modules 21 are service functional blocks constructed as transponder functional blocks according to IEC 61499.

[0121] When executing control program 10, starting from each start module 21, all functional modules 20 connected to each other via event connections are executed sequentially until each termination module 27, 28 is executed. The first application 15 is executed in a distributed manner in the first sub-environment 101 using the first execution resource 311 and in the second sub-environment 102 using the third execution resource 321. Here, the program portion executing the first termination module 27 is executed entirely in the first sub-environment 101, and the program portion executing the second termination module 28 is executed partly in the first sub-environment 101 and partly in the second sub-environment 102. The second application 16 is executed entirely in another sub-environment 104 using the second execution resource 312, and the third application 17 is distributed between the second sub-environment 102 and another sub-environment 104 using the fourth execution resource 322.

[0122] In the illustrated control program 10, the execution of the start module 21 is triggered accordingly by an external origin event 45, which includes the detection of sensor signal 132 by sensors 188 and 189. Sensor signal 132 is transmitted to sub-devices 310 and 320 of the controller 5 via communication connection 60 and is read by the interface module 130 of the execution environment 100 via an external input interface 131 connected to communication connection 60. Upon execution of termination modules 27 and 28, output signals 134 are generated for actuators 183, 185, and 187 of the machine 1, respectively. Output signals 134 are transmitted to actuators 183, 185, and 187 via the external output interface 133 of the interface module 130 and the communication connection 60 connected to the output interface 133.

[0123] If different execution resources 311, 312, 321, and 322 are used to execute successive functional modules 20, then the event connections and data connections between related functional modules 20 are executed through communication connections that interconnect execution resources 311, 312, 321, and 322. For example, if execution resources 311, 312, 321, and 322 are implemented on different sub-devices 310 and 320, then... Figure 1 The fieldbus 60 shown, or the internal bus system of each sub-device 310, 320, in the case where execution resources 311, 312, 321, 322 are implemented on the same sub-device 310, 320.

[0124] The monitoring module 110 is designed to monitor the execution duration of the program portions of the control program 5 used to execute the respective termination modules 27, 28. For this purpose, event chains are formed, each event chain detecting all activation events of the following functional modules 20, and sequentially executing these functional modules 20 in response to one of the input signals 132 until one of the termination modules 27, 28 is executed. Here, a separate event chain is formed for each combination of one of the input signals 132 and one of the termination modules 27, 28 executed based on the associated input signal 132.

[0125] exist Figure 4 The diagram illustrates an exemplary first event chain 31, which includes activation events 40 for all functional modules 20, generated sequentially starting from the start module 21 of the third application 17 and continuing until the termination module 27 of the third application 17 is executed. The first event chain 31 includes a start event 41 for activating the start module 21 and three subsequent events 43 for sequentially activating the two additional functional modules 20 and the termination module 27.

[0126] In addition, Figure 4 The diagram shows a second event chain 32 and a third event chain 33. The second event chain 32 includes the following activation events 40 for all functional modules 20, which are generated starting from the start module 21 of the first application 15 and continuing until the execution of the first termination module 27 of the first application 15. The third event chain 33 includes the following activation events 40 for all functional modules 20, which are generated starting from the start module 21 of the first application 15 and continuing until the execution of the second termination module 28 of the first application 15.

[0127] The second and third event chains 32 and 33 are triggered either by the same external origin event 45 or by the same input signal 132. They each include a start event 41 for activating a start module 21, which forms a common functional module 24 for the second and third event chains 32 and 33. Furthermore, they each include a follow-up event 43 for activating another common functional module 24. After executing this other common functional module 24, a first activation event 51 for activating a first follow-up module 25 and a second activation event 52 for activating a second follow-up module 26 are generated. The first activation event 51 is part of the second event chain 32, and the second activation event 52 is part of the third event chain 33.

[0128] Following the first activation event 51, the second event chain 32 also includes a subsequent event 43 for activating the first termination module 27 of the first application 15. The second functional module 26 activated by the second activation event 52 simultaneously forms the second termination module 28 of the first application 15, so the third event chain 33 does not include another activation event 40 after the second activation event 52.

[0129] For in Figure 3 The control program 10 shown in the figure also ultimately generates in Figure 4 The fourth and fifth event chains are not shown. The fourth and fifth event chains include all activation events of the following functional modules, which are executed sequentially starting from the start module 21 of the second application 16 until the first or second termination module 27, 28 of the second application 16 is executed.

[0130] The monitoring module 110 is configured to perform a first check 95, in which it checks whether the first execution duration 201 of the functional module 20 of the first event chain 31 exceeds a first predetermined duration. If the first execution duration 201 exceeds the first predetermined duration, the monitoring module 110 executes a first exceedance response.

[0131] The first execution duration 201 begins with the origin event 45 that triggers the execution of the first event chain 31 and ends with the termination of the execution of the termination module 27 of the first event chain 31. To check the first execution duration 201, the monitoring module 110 generates a first timestamp containing the time of the origin event 45. For this purpose, the monitoring module 110 adds the time of the generation of the start event 41 that triggers the start module 21 to an additional delay time that has elapsed since the origin event 45 and during the transmission of the input signal 132 via the data connection 60. The timestamp is copied when a subsequent event 43 occurs and transmitted between the functional modules 20 via the event connection, along with the subsequent event 43.

[0132] Similar to the first check 95 of the first execution duration 201, the monitoring module 110 is configured to perform a second check 96 and a third check 97. The second check 96 checks whether the second execution duration 202 of the functional module 20 of the second event chain 32 exceeds a second predetermined duration, and the third check 97 checks whether the third execution duration 203 of the third event chain 33 exceeds a third predetermined duration. If the second predetermined duration is exceeded, a second exceedance response is executed, and if the third predetermined duration is exceeded, a third exceedance response is executed.

[0133] Because the termination module 27 of the first event chain 31 is executed via the fourth execution resource 322, the first check 95 is performed by a submodule of the monitoring module 110 executed via the fourth execution resource 322. The second check 96 is performed by a submodule of the monitoring module 110 executed via the third execution resource 321, and the third check 97 is performed by a submodule of the monitoring module 110 executed via the first execution resource 311.

[0134] Figure 5 It shows a transfer from the fourth execution resource 322 to the third execution resource 321 for a first predetermined duration determined on the fourth execution resource 322 during the execution of the first event chain 31.

[0135] The third and fourth execution resources 321 and 322 are connected via an internal communication connection 61, such as an internal bus connection, of the second sub-device 320. A communication channel 62 is established via the internal communication connection 61, through which a first, predetermined duration exceeding 90, determined on the fourth execution resource 322, is transmitted to the third execution resource 321. Based on the transmitted duration exceeding 90, the sub-module of the monitoring module 110 executing on the third execution resource 321 triggers its own duration response. Additionally, an activation event 40 for activating one of the subsequent modules 25 of the first event chain 31 is also transmitted via the internal communication connection 61.

[0136] In an alternative implementation, the third and fourth execution resources 321, 322 can be executed on separate sub-devices 310, 320 of the controller 5. In this case, the communication channel 62 can also be executed via an external communication connection connecting the two sub-devices 310, 320, for example via a fieldbus 60.

[0137] Figure 6 The diagram illustrates transmissions exceeding 90% of the pre-given duration for the second and third event chains 32, 33 during execution via communication connection 60. Here, a variant of execution environment 100 is shown, in which the first termination module 27 and the second termination module 28 of the first application 15 both execute on the third execution resource 321.

[0138] To transmit the transmission of a second pre-given duration exceeding 90 during the execution of the second event chain 32, and to transmit the transmission of a third pre-given duration exceeding 90 during the execution of the third event chain 33, separate communication channels 62 are respectively set up via communication connection 60. Communication channels 62 are implemented via communication data, based on which it can be distinguished whether the first or second execution durations 202, 203 have exceeded their respective pre-given durations. This enables the matching of overrun reactions triggered in the first execution resource 311 based on whether the execution durations 202, 203 have exceeded their pre-given durations in event chains 32, 33.

[0139] In an alternative implementation, the first and second pre-given durations exceeding 90 can also be transmitted via a single communication channel 62, thereby reducing the amount of data transmitted. In this case, it is impossible to distinguish which event chain 32, 33 exceeds its pre-given duration in the first execution resource 311, and the same overrun response is always executed.

[0140] Figure 7 An embodiment of the execution environment 100 is shown, wherein the termination modules 27 and 28 of the second and third event chains 32, 33 are executed in separate execution resources, namely in the third execution resource 321 and another execution resource 323. Here, the first and third execution resources 311, 321 and the other execution resource 323 are implemented on separate sub-devices of the controller 5, wherein the sub-devices are connected to each other via a fieldbus 60. In this embodiment, a predetermined duration of more than 90% determined in each execution resource is also transmitted on the fieldbus 60 via the communication channel 62.

[0141] exist Figure 8 The diagram illustrates one embodiment of execution environment 100, wherein a second sub-environment 102, executing on a third execution resource 321, is connected not only to the first sub-environment 101 but also to another sub-environment 104 via communication channel 62. Additionally, the first sub-environment 101 and / or the other sub-environment 104 are connected in some respects to another sub-environment 104 of execution environment 100 via communication channel 62.

[0142] The sub-modules of monitoring module 110 executing in each of the sub-environments 101, 102, and 104 are respectively configured to forward overages, determined during the execution of the event chain itself and of a predetermined duration, to all connected sub-environments 101, 102, and 104 and the sub-modules of monitoring module 110 executing therein via communication channel 62. Additionally, the sub-modules of monitoring module 110 executing in each of the sub-environments 101, 102, and 104 are respectively configured to forward overages received via one of the communication channels 62 via the remaining communication channels 62.

[0143] exist Figure 9 The diagram illustrates one embodiment of the execution environment 100, in which only the execution duration 203 of the third event chain 33 is checked to see if it exceeds a predetermined duration, but the execution duration of the second event chain 32 is not checked to see if it exceeds a predetermined duration. For this purpose, the control program 10 stores information such that the event connection for transmitting the first activation event 51 is associated with the event chain 32 whose execution duration is not checked, and stores additional information such that the event connection for transmitting the second activation event 52 is associated with the event chain 33 whose execution duration is checked.

[0144] When activation events 51 and 52 are created during the runtime of control program 10, the stored information can then be used to trigger a check on the execution duration of the third event chain 33 and to disable a check on the execution duration of the second event chain 32. This information can be stored, for example, as attributes associated with each event connection. Generally, for each event connection of control program 10, the following information can be stored: whether the activation event transmitted through the corresponding event connection is part of an event chain, and whether the execution duration of the event chain is monitored.

[0145] In the embodiment of the execution environment 100 described in conjunction with the foregoing figures, the execution duration of each event chain 31, 32, and 33 is checked only after the execution of termination modules 27 and 28 to see if it exceeds a predetermined duration. In an alternative embodiment of the execution environment 100, the execution duration of each event chain 31, 32, and 33 may also be checked after the execution of each functional module 20 to see if it exceeds a predetermined duration.

[0146] This replacement implementation method is in Figure 10 As shown in the diagram. Here, in the check 95 performed after the execution of the second functional module 20, it has been determined that the first predetermined duration 105 has exceeded 90, and the over-response has been triggered. Therefore, in conjunction with... Figures 1 to 9 Compared to the described implementation, in this implementation, less time elapses between the end of the predetermined duration 150 and the end of the inspection module 110 determining that the predetermined duration 150 has ended.

[0147] As in Figure 11 As shown, the check 95 to determine whether the predetermined duration of 90 has been exceeded can also be performed during the execution of each functional module 20, for example, at periodic intervals. In this implementation, whether the predetermined duration of 90 has been exceeded is determined almost instantly.

[0148] Figure 12An implementation of the execution environment 100 is shown, wherein the execution duration of the event chain 31 is checked to see if it exceeds a pre-given duration by monitoring whether the execution duration of each functional module 20 used to execute the event chain 31 exceeds a pre-given duration 220. Figure 12 The difference is that the pre-given durations 220 for executing each functional module 20 may also be of different lengths. In an alternative embodiment, it may also be additionally checked whether the overall execution duration of the event chain 31 exceeds the total duration, for example, at periodic time intervals during the execution of functional modules 20 and / or after the execution of each functional module 20 and / or only after the execution of the termination module 27.

[0149] Combination Figures 9 to 12 Variations of the described execution environment 100 may exist together or separately in a similar manner in combination. Figures 1 to 8 The described implementation method.

[0150] List of reference numerals

[0151] 1 machine

[0152] 5 Programmable Logic Controller

[0153] 10 Control Procedure

[0154] 11 First Subroutine

[0155] 12 Second Subroutine

[0156] 15 First Application

[0157] 16 Second Application

[0158] 17 Third Application

[0159] 20 functional modules

[0160] 21 Start Module

[0161] 24 Common functional modules

[0162] 25 First Subsequent Module

[0163] 26 Second Subsequent Module

[0164] 27 First Termination Module

[0165] 28 Second Termination Module

[0166] 31 First Event Chain

[0167] 32 Second Event Chain

[0168] 33 Third Event Chain

[0169] 40 Activation Events

[0170] 41. Start Event

[0171] 43. Subsequent Events

[0172] 45 Externally Originating Events

[0173] 51 First Activation Event

[0174] 52 Second Activation Event

[0175] 60 Communication Connection

[0176] 61 Internal communication connections

[0177] 62 communication channels

[0178] 80 Event Connections

[0179] 82 Data Connection

[0180] 84. The preceding functional modules

[0181] 85 Subsequent functional modules

[0182] 90% or more

[0183] 95 First Inspection

[0184] 96 Second Inspection

[0185] 97 Third Review

[0186] 100 Execution Environment

[0187] 101 First Sub-environment

[0188] 102 Second Sub-environment

[0189] 104 Other sub-environments

[0190] 105. Pre-defined duration

[0191] 110 monitoring module

[0192] 111 First Submodule

[0193] 112 Second Submodule

[0194] 120 Execution Module

[0195] 130 Interface Module

[0196] 131 External Input Interface

[0197] 132 Input Signal

[0198] 133 External Output Interface

[0199] 134 Output Signal

[0200] 181 Clamp

[0201] 182 Lateral Kinematics

[0202] 183 First Actuator

[0203] 184. Height Kinematics

[0204] 185 Second Actuator

[0205] 186 Conveyor

[0206] 187 Third Actuator

[0207] 188 Safety Orientation Sensor

[0208] 189 Sensor

[0209] 195 workpieces

[0210] 201 First execution duration

[0211] 202 Second Execution Duration

[0212] 203 Third Execution Duration

[0213] 220 Single Duration

[0214] 310 First Sub-device

[0215] 311 First Execution Resource

[0216] 312 Second Execution Resource

[0217] 314 Additional execution resources

[0218] 320 Second Sub-device

[0219] 321 Third Execution Resource

[0220] 322 Fourth Execution Resource

[0221] 323 Additional execution resources

Claims

1. An execution environment for executing an event-oriented control program of a programmable logic controller, wherein the control program comprising a plurality of function modules to be executed in succession, wherein the execution environment is designed to execute the function modules in an event-controlled manner upon occurrence of activation events associated with the respective function modules, wherein the activation events of the function modules to be executed in succession form an event chain, wherein the execution environment comprises a monitoring module for monitoring an execution duration of the function modules of the event chain, wherein the monitoring module is designed to check whether the execution duration exceeds a predefined duration, wherein the monitoring module is constructed separately from an execution module of the execution environment, which executes the function modules of the event chain.

2. The execution environment according to claim 1, wherein a first activation event of the event chain forms a start event which occurs upon activation of an external input interface of the execution environment, and / or wherein a last function module of the function modules to be executed in succession forms a termination module for causing a system reaction of the execution environment.

3. The execution environment according to claim 1 or 2, wherein, the execution environment is designed to generate a timestamp indicating the start of the execution duration, wherein the monitoring module is designed to determine the execution duration by comparing the timestamp with a current time.

4. The execution environment according to claim 3, wherein the execution environment is designed to first associate the timestamp with a start event of the event chain, which triggers execution of a first function module, wherein upon execution of a respective function module an activation event is established for a function module to be executed subsequently, respectively, and wherein a timestamp of the activation event of the respective executed function module is associated with the activation event of the function module to be executed subsequently.

5. The execution environment according to claim 1 or 2, wherein the execution environment for executing the function modules comprises a plurality of sub-environments which can be executed separately from one another, wherein the sub-environments can be executed on separate execution resources of the controller, wherein the event chain comprises a first function module triggered by a start event of the event chain and executed in a first sub-environment and a second function module triggered by a subsequent event of the event chain in time and executed in a second sub-environment, wherein the monitoring module comprises a first sub-module and a second sub-module, wherein the first sub-module is designed to monitor the execution duration in the first sub-environment, and wherein the second sub-module is designed to monitor the execution duration in the second sub-environment.

6. The execution environment according to claim 5, wherein the execution environment is designed to transmit a timestamp indicating the start of the monitored execution duration from the first sub-environment to the second sub-environment via a communication connection.

7. The execution environment according to claim 5, wherein, the execution environment comprises a communication channel between the first sub-environment and the second sub-environment, wherein the execution environment is designed to transmit an overrun of the predefined duration determined by the second sub-module to the first sub-module via the communication channel.

8. The execution environment according to claim 5, wherein the execution environment comprises a sub-environment connected to a plurality of further sub-environments via communication channels, wherein the sub-environment connected to the plurality of further sub-environments is designed to transmit an overrun of the predefined duration received via one of the communication channels to all remaining sub-environments of the sub-environments connected via communication channels via the remaining communication channels.

9. The execution environment according to claim 1 or 2, wherein, the control program comprises at least two event chains comprising activation events for activating at least one common function module, wherein the control program is designed to generate a first activation event of a first event chain after execution of the common function module and alternatively or cumulatively to generate a second activation event of a second event chain, wherein the monitoring module is designed to check whether the execution duration of the function module of the first event chain exceeds the predefined duration, wherein the monitoring module is designed to check whether the execution duration of the function module of the second event chain exceeds another predefined duration or to perform no check of the execution duration of the function module of the second event chain.

10. The execution environment according to claim 1 or 2, wherein the monitoring module is designed to check whether a predefined total duration of the execution of a plurality of function modules of an event chain is exceeded and / or wherein the monitoring module is designed to check whether a predefined individual duration of the execution of individual function modules of an event chain is exceeded.

11. The execution environment according to claim 1 or 2 wherein the monitoring module is designed to monitor whether the execution duration of a plurality of event chains exceeds a predefined duration, respectively, wherein the predefined duration for the individual event chains is predefined in dependence on a start event triggering the individual event chains, respectively.

12. The execution environment according to claim 1 or 2, wherein the monitoring module is designed to trigger an overrun reaction and / or a control reaction upon exceeding the predefined duration.

13. The execution environment according to claim 1 or 2, wherein the monitoring module is designed to check whether the execution duration exceeds a predefined duration after the execution of a function module associated with an individual activation event of an event chain, respectively.

14. The execution environment according to claim 1 or 2, wherein the monitoring module is designed to check whether the execution duration exceeds a predefined duration during the execution of an individual function module of an event chain.

15. A method for executing an event-oriented control program of a programmable logic controller, wherein the control program comprises a plurality of function modules to be executed in succession, wherein the function modules are executed in an event-controlled manner by means of an execution environment upon occurrence of an activation event associated with the individual function modules, respectively, wherein the execution environment is designed to transmit an overrun of the predefined duration determined by the second sub-module to the first sub-module via the communication channel. wherein the method comprises the following steps: - forming an event chain from activation events of function modules to be executed in succession; - monitoring the execution duration of the function modules of the event chain by means of a monitoring module of the execution environment; - checking by means of the monitoring module whether the execution duration exceeds a predefined duration, wherein the monitoring module is constructed separately from an execution module of the execution environment, which executes the individual function modules of the event chain.

Images