Runtime Environment and Method for Creating an Event-Driven Execution Model of an Industrial Application

Abstract

A runtime environment for execution of an event driven control program for a distributed control system including one or multiple computing resources, wherein the control program includes at least two function blocks. The runtime environment includes for each computing resource an event executor which is configured for execution of sets of events and respective associated data on the respective computing resource. And wherein the runtime environment includes for each function block a memory resource, which memory resource is configured to: store a set of events and associated data for each function block if the data is produced by the function block; and/or store a reference to a set of events and associated data for each function block if the data is consumed by the function block.

Claims

1. A runtime environment for execution of an event driven control program for a distributed control system comprising at least one computing resource, wherein the control program comprises at least two function blocks: wherein the runtime environment is configured to execute each function block event driven when any of the each respectively function block associated trigger events occur; wherein the runtime environment comprises for each computing resource an event executor which is configured for execution of sets of events and respective associated data on the respective computing resource; wherein the runtime environment comprises for each function block a memory resource, which memory resource is configured to: store a set of events and associated data for each function block if the data is produced by the function block; and/or store a reference to a set of events and associated data for each function block if the data is consumed by the function block.

2. The runtime environment according to claim 1, wherein any of the at least two function blocks is a composite function block comprising multiple function blocks.

3. The runtime environment according to claim 1, wherein the set of events and associated data is stored with a function block state in an instance memory.

4. The runtime environment according to claim 1, wherein said reference corresponds to a set of datastructures held by the runtime environment for each input and output event and its associated data, representing the event and data connections between each function block.

5. The runtime environment according to claim 1, wherein the computing resource contains a function block network composed of function blocks instances represented by instance memories, and event and data connections represented by datastructures inside the runtime environment.

6. The runtime environment according to claim 3, wherein while executing, the corresponding instance memory for each function block holds and keeps a complete state of a function block instance over the whole lifetime of the function block.

7. The runtime environment according to claim 3, wherein an instance memory is defined at least by all current values of input data, output data and internal variables.

8. The runtime environment according to claim 3, wherein when one trigger event occurs for a function block, the runtime environment is configured to set binary values representing the event as well as the corresponding input data in the instance memory of the function block instance, and to execute an algorithm of the function block producing new output data in an internal buffer for the data output and marking new output events to be fired by setting the binary values representing the output event in the instance memory.

9. The runtime environment according to claim 8, wherein the algorithm of the function block writes a value to an internal buffer of a respective output variable and when an output event associated with said value is fired, said value is copied from the internal buffer to an external buffer after the execution of the algorithm of the function block.

10. The runtime environment according to claim 4, wherein the datastructure for each Input Event contains two variables, one variable Data Transfer To Queue DTTQ object describing what data is associated with an event that is to be put on the queue, the other variable Data Transfer From Queue DTFQ object describing what data should be copied where for an event that is to be executed.

11. The runtime environment according to claim 10, wherein the variable DTTQ and DTFQ objects consist of a source or destination pointer, an offset in the event data structure and a function pointer to a cast and/or copy function.

12. The runtime environment according to claim 1, wherein the runtime environment uses an eventqueue, which may be a ring buffer and stores the set of event datastructures scheduled for execution.

13. The runtime environment according to claim 12, wherein the event datastructure contains the timestamp when the event is being queued and also a placeholder for a timestamp when the event is being executed.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0068] By way of example only, the embodiments of the present disclosure will be described with reference to the accompanying drawings, wherein:

[0069] FIG. 1A illustrates schematically an example of a function block according to IEC 61499;

[0070] FIG. 1B illustrates schematically an example of a function block in more detail according to IEC 61499;

[0071] FIG. 10 illustrates schematically an example of a network of function blocks in accordance with IEC 61499;

[0072] FIG. 2 illustrates schematically an example of an automation system for which a distributed control software application based on function blocks may be developed;

[0073] FIG. 3A illustrates schematically an example of data handling by function blocks in accordance with the invention;

[0074] FIG. 3B illustrates another example of function block internal data handling and an event queue in accordance with the invention;

[0075] FIG. 4 illustrates schematically a data structure for an Event Output Handle;

[0076] FIG. 5 illustrates schematically an example of a method for processing an event output;

[0077] FIG. 6 illustrates schematically an example of a data structure for an Event Input Handle;

[0078] FIG. 7 illustrates schematically an example of a method for processing an event input of a source function block;

[0079] FIG. 8 illustrates schematically an example of a method for creating an new event input for a target function block.

DETAILED DESCRIPTION

[0080] Referring to FIG. 2, an example of an automation system 200 is shown for which a control software application may be developed to implement and execute control of the system. The system 200 includes a PC running an engineering tool 210. The engineering tool 210 references libraries 211 containing a collection of function block types and libraries containing a collection of objects for various hardware components. A library may be dedicated to a specific field of technology, such as discrete manufacture, continuous process, water, hydraulics or HVAC, through which objects are available common to that particular field.

[0081] A central communication bus 220 connects the various elements of the system 200. On one side components for providing interaction of the operator with the system, such as an Human Machine Interface HMI 230, a SCADA System 240, a cloud platform 250, and a fog control server 260. On another side are automation hardware components, commonly referred to as edge or field devices, such as various sensors 281, 283, 285 and actuators 282, 284, 286 that are connected via I/O modules 271, 272 and a Programmable Logic Controller PLC 270 to the central communication bus 220. Sensor 281 and actuator 282 are connected via I/O module 271 to PLC 270, whereas sensor 283 and actuator 284 are connected to PLC 270 directly. Sensor 285 and actuator 286 are connected to I/O module 272. PLC 270 and I/O module 272 may communicate via central communication bus 220 with various systems for operator control, such as HMI 230 and SCADA System 240.

[0082] In the example of FIG. 2, the PLC 270, the I/O module 271 and I/O module 272 each have a processor capable of executing code. In addition, also the edge devices sensor 283 and actuator 284 are capable of executing code. In other examples, also one or more of the other edge devices such as sensors 281, 285 and/or actuators 282, 246 may be equipped with processing capabilities.

[0083] The Engineering tool 210 is used to design an application program at a functional level for the automation system 200, commonly referred to as an engineering phase. This includes taking in account parameters and measurements relevant to the particular process at hand. And engineering the operation of the complete system. The engineering phase further includes providing the necessary signals and control options for one or more operators and/or supervisors. The result will be a network of function blocks, referred to as an application, that performs the required functionalities when executed. A portion of an example of a network of function blocks is shown in FIG. 10.

[0084] The engineered application, i.e. the network of function blocks will be compiled according to the two-step compiling process explained above. First creating intermediate code for each type of Function Block. Secondly creating code capable of being executed by specific hardware components available in the automation system 200. So, in this sense it may be said that the function blocks of the network are distributed over the processing resources available in the automation system 200.

[0085] Accordingly, a discovery process can be performed for identifying hardware resources with processing capacity. The hardware may also be pre-determined by an engineer or provided as a file listing the processing resources included in libraries. Processing resources may include dedicated physical hardware devices, smart devices including edge devices such as sensors and actuators equipped with generic CPU's, and virtual devices, such as virtual machines and/or containers. The use of virtual devices allows the use of a cloud computing infrastructure, which may be global and off-premise, such as cloud 250, or may be local and on-premise, such as fog 260.

[0086] In order to represent the various elements of the system in the engineering tool, including hardware, processing resources and/or virtual resources, each element should be defined and described using respective library objects. This means that for each element of the system the control logic, visualization, connection and documentation are to be provided as aspects and made available within each respective library object. Hence, for each type of system element there should be a library object.

[0087] So, during the engineering phase, an engineer will design an application that is to be run and distributed over execution resources making up the automation system 200. This is done by selecting and connecting instances of library objects representing the respective elements of the automation system.

[0088] Event Scheduler and Memory Structure

[0089] With reference to FIGS. 3A and 3B, the inner structure and operation of the Runtime environment for execution of an event driven control program for a distributed control system will be explained. The Runtime includes at least one computing resource and the control program includes at least two function blocks 300, 310. The runtime environment is configured to execute each function block 300, 310 event driven when any of the trigger events respectively associated with each function block occurs. Thereto, the runtime environment includes for each computing resource a scheduler 301, such as e.g. an event execution thread, which is configured for execution of sets of events with respective associated data on the respective computing resource.

[0090] The computing resource therefore contains a function block network composed of function blocks instances, Event and Data connections represented by specific memory structures inside the runtime environment.

[0091] While executing, the corresponding instance memory 302, 312 for each function block 310, 320 holds and keeps the complete state of the function block instance over the whole lifetime of the function block. Thus instance memory is defined by all current values of the Input Data IN(n), Output Data OUT(n) and Internal Variables INT(n). Additionally for a Basic function block the instance memory keeps the current State of the ECC and memory representation of each Input Event EI(n) and each Output Event EO(n) in form of a binary value in case of a Basic function block. Additionally to the instance memory the runtime environment keeps a set of datastructures so called Event Input Handles EIH for each Input Event and respectively Event Output Handles EOH for each Output Event. These handles represent the Event and Data connections between each function block and it's Event/Data association of the FBs Interface. The datastructures are designed in a way to allow efficient transfer of data and events between the function blocks by the Executor. For this purpose they get created and filled once at application setup time and used during execution.

[0092] In one embodiment, the internal state of the function block may be represented by a set of events and associated data, which is stored in a memory resource as an instance of the internal state 302, 312. Such set of events and data may include values for incoming events Ei0 and Ei1, values for outgoing events Eo2 and Eo3, values for input data IN0-IN4, values for output data Out0-Out4, and sets of values for internal data int0-int4, such as output data Out-Out4 calculated and to be exposed with a next output event.

[0093] In one embodiment, the inputs IN0-I N4 and outputs OUT0-OUT4 may be described as variables IN(n) with index n=0, 1, 2, . . . and OUT(n) with index n=0, 1, 2, . . . . Similarly, the input events and output events may be described as variables Ei(n) with index n=0, 1, 2, . . . and Eo(n) with index n=0, 1, 2, . . . .

[0094] In one embodiment, the runtime environment may further include an instance memory 302, 312 for each function block 300, 310. Each instance memory 302, 312 is configured to store sets of events and associated data and/or store a reference to another set of events and associated data. This depends on whether the current trigger event will be producing data and/or a next event. Or if the current trigger event will be consuming data and/or a previous event. So, based on the event trigger being event-producing or event-consuming, the memory resource 302, 312 may store the set of events and associated data for each function block if the data is produced by the function block. And/or it may store a reference to a set of events and associated data for each function block if the data is consumed by the function block.

[0095] When one trigger event occurs for the first function block 300, Ei0 or Ei1, the runtime will set the binary value representations of the Event as well as the associated Input Data in the instance memory of the function block instance. Followed by executing the algorithm of the function block producing new output data in the internal buffer of the Data Output Do(int) and marking new Output Events to be fired by setting the binary value representations of the Output Events in the instance memory.

[0096] With this referenced approach it is possible to use different cores for executing parallel branches of linked function blocks.

[0097] In accordance with the IEC 61499 paradigm an output data variable, e.g. like OUT0-OUT4, should only be updated, meaning presented external i.e. exposed outside of a function block if the associated output event, e.g. Eo2 or Eo3, is fired. For example, inside a basic function block algorithm, a new value may be obtained for the output variable, but if no associated event is fired when the algorithm finishes, the already exposed output data variable should retain the old value. As a connected input data variable, meaning an input variable of another function block that is connected to this output data variable, should continue to read the old value. As a result, in the runtime environment, new values of output variables should be buffered. This achieved which is achieved by storing both the newly obtained values OUT0-4 as Do(Internal) and the currently exposed values OUT0-4 as Do(External). Accordingly, the function block algorithm writes to the internal buffer of the respective variable, and when the associated output event is fired, the value is copied from the internal buffer Do(int) to the external buffer Do(ext) after the execution of the algorithm.

[0098] In case of a composite function block, the internal buffer will be equivalent to the connected (external) output variable of a member function block instance. Therefore the internal buffer for composites is not present. As an adaption, a composite function block may only update the output variables in response to a triggering of the associated output events, no double buffer is required inside a composite function block.

[0099] In the following, the handling of data within a function block network and use of an event queue will be described in more detail.

[0100] Handling Output Events

[0101] Starting with the output data side i.e. the data that is to be exposed, an example of a data structure and the handling of data will be described when one of the output events is triggered, e.g. from an Execution Control Chart ECC or algorithm of a basic function block or from events coming from an internal function bock inside a composite function block.

[0102] When the output event is fired, the function block instance looks up its variable Event Output Handle, which is an array referred to as EOH(n), where n is the index for the output event being fired, so n=0 refers to Eo(0) and n=1 refers to Eo(1). Each object in the array EOH(n), contains two variables, one variable Event Connection List ECL containing the connection between events, the other variable Data Transfer List DTL containing the output data variables associated with the output event. See FIG. 4.

[0103] The Event Connection List ECL is an array of objects with each array object describing one event connection, which includes a pointer to the target function block instance TarFB and it includes the input event index EvtID, e.g. Ei1 or Ei6, that the output event is connected to. See FIG. 4.

[0104] The Data Transfer List DTL is an array of objects with each array object describing one output data variable that is associated with the output event. Each array object contains two data pointers, a source pointer src and a destination pointer dst, and a function pointer fnc describing which function should be called to handle the datatype: a casting function or a memory copy function. For an output data transfer between the internal and external buffer of a function block, it will always be a memory copy and no cast will be possible. See FIG. 4.

[0105] Referring to FIG. 5, with the data structure as explained, when a scheduler i.e. event executor fires one of the output events, the following actions will be performed.

[0106] For the output event Eo(n), the respective Event Connection List and Data Transfer List will be retrieved 501 from the Event Output Handle EOH(n).

[0107] Next, within the Data Transfer List for the respective output event the associated array objects are identified and the source pointer src, destination pointer dst and function pointer fnc are retrieved 502 in order to copy the output variables from the internal buffer to the external buffer 324. For a composite function block this is representing the copy of the external buffer Do(ext) of the connected member function block to the external buffer Do(ext) of composite.

[0108] Furthermore, within the Event Connection List for the respective output event the associated array objects are retrieved 503 identified and the target function block, TarFB, and event identifier i.e. event, ID Ei(n), are used to trigger a relevant method on the target function block instance to create and to put an event onto the event queue 503.

[0109] Queueing an Event

[0110] The target function block instance triggered by the corresponding TarFB and event ID Ei(n) from the Event Connection List, retrieves a variable Event Input Handle, which is an array referred to as EIH(n), where n is the index for the input event being fired, so n=0 refers to Ei(0) and n=1 refers to Ei(1). Each object in the array EIH(n), contains two variables, one variable Data Transfer To Queue DTTQ object describing what data is associated with an event that is to be put on the queue, the other variable Data Transfer From Queue DTFQ object describing what data should be copied where for an event that is to be executed. Both objects DTTQ and DTFQ basically describe the connection between destination input variable IN(n) and associated input event Ei(n).

[0111] The variable Data Transfer To Queue DTTQ is an array, see FIG. 6, wherein each array element i.e. DTTQ object contains a source pointer src Do which points to the memory location of the external buffer of the output data variable of the source function block for this data connection. Each array element further contains an offset variable describing an offset m of each data value in the event data structure for Event Input n. In this context, it may mean that the value format is not uniquely defined, but that the type may be one of various value data representations. This offset m is pre-calculated during application setup time, so no time is wasted on calculation during event execution. This means that for each event the memory location may directly be retrieved. Each array element further contains a function pointer castFct describing the datatype casting function or memory copy function that is to be called. This cast function is executed if there's an type cast between the source and destination of this data connection, otherwise it will be a simple memory copy function. Type cast means that a variable having a certain type may be converted to another type, like e.g. from an Integer type to a floating point type or string type. A cast function may also be required in case of data types with different bit width or length. More of such various kinds of data types are e.g. defined in the standard IEC 61499, which in turn may refer again to IEC61311.

[0112] Similar to the variable DTTQ, the variable Data Transfer From Queue DTFQ is likewise an array, see FIG. 6, wherein each array element i.e. DTFQ object contains a destination pointer dst Di which points to the memory location of the input data variable of the destination function block for this data connection. Each array element further contains a unionized offset variable describing the same offset of the respective data variable inside the event datastructure. This offset m is also pre-calculated for each data associated with the Event n during application setup time, so no time is wasted on calculation during event execution. Each array element further contains a function pointer castFct describing the datatype casting function or memory copy function that is to be called.

[0113] In other words, the variables DTTQ and DTFQ consist of a source or destination pointer, an offset in the event data structure and a function pointer to a cast and/or copy function. With the data structures as described above, the scheduler i.e. event executor may queue the event that is to be executed in an event queue which may be a ring buffer and stores the set of event datastructures scheduled for execution, and which e.g. was identified by retrieving 503 TarFb and Ei(n) from the ECL. While referring to FIG. 7, this is done by performing the following:

[0114] Retrieving the El H(n) object 701 by looking up the target function block's Event Input Handle EIH(n) with n the identifier of the input event that is triggered.

[0115] Creating the event data structure 702 on the event queue, which may e.g. be a ring buffer, and fill in the metadata in the event header. The metadata may include the length of the event, destination input event identifier Ei(n), pointer to target function block and the timestamp when the event is being queued and also a placeholder for a timestamp when the event is being executed.

[0116] Retrieving 703 from the Event Input Handle EIH(n) object, the Data Transfer To Queue DTTQ array.

[0117] For each DTTQ object m of the DTTQ array retrieving the source pointer src Do, the offset m and the function pointer castFct.

[0118] Adding the output variable value 704, based on the function pointer either by type cast or copy, to the proper place in the event data structure as indicated by offset m.

[0119] Event Execution

[0120] Event execution means that the scheduler i.e. event executor takes an event datastructure from the queue and uses the metadata from the event header to identify the target function block and respective Input Event to be executed Accordingly, the scheduler will perform actions prior to algorithm execution to put the data of one event data structure at the proper memory location associated with each function block instance. While referring to FIG. 8, this is done by performing the following method:

[0121] Retrieving 801 the event datastructure of the currently scheduled event from the event queue.

[0122] Retrieving 801, based on the event input ID Ei(n) of the event header, the destination function blocks' Event Input Handle EIH(n) objects with n the Event Input ID Ei(n) of the input event that is fired.

[0123] Retrieving 802 the DTFQ array from the retrieved EIH(n) for Input Event n. For each DTFQ object retrieving the pointer pointing to the Input Data Variable dst Di, the offset m pointing to the data value in the event data structure and the function pointer castFct.

[0124] Copying 803 the data variable value from the event data structure to the correct memory location for the input data variable Ei(n).

[0125] Executing 803 the function block algorithm according to the definition of the ECC, it's current ECC state and the Input Event being triggered and filling the timestamp into the event datastructure header when the event is being executed

[0126] By performing the above actions, the scheduler executes one of the events that was queued. And execution would continue by performing the next event in the queue.

[0127] In a distributed system having multiple resources, each resource will have an event executor which is implemented as an event executor thread. This one event executor thread per resource is responsible for performing the actions as described above: transferring events and data from the source function block to the destination function block and then execute the algorithm(s) or other logic of the destination function block.

[0128] This thread runs continuously, checking if the event queue is empty, and if it is not empty, the executor takes the first event out of the event queue and uses the information contained in the event header to find the destination function block and starts to copy the data attached to the event to the associated input data variables of the destination function block. Once all the values of the input data variables have been set, the executor then executes the one or more relevant algorithms inside the function block instance that correspond to the input event ID. The executor may arrange calling of algorithm associated with a certain function block that is required to calculate the output data from the input data.

[0129] This execution of one event in turn may or may not queue new events to the event queue. Therewith the execution of one event is completed and the timestamp for execution time is filled in the metadata of the eventheader. The executor thread will then continue by checking for the next event in the queue and execute it if the queue is not empty. If the event queue is empty, the thread is then suspended, put to sleep, until a service thread like e.g. network socket wakes up the event executor thread again by queuing a new event, with which the executor thread resumes event execution.

[0130] Timestamping the queuing time as well as the execution time of the event as part of the event datastructure header allows advanced tracing of the temporal execution behavior of the function block network. This can be used to watch and monitor execution times while executing.

[0131] Moreover, a recording of this event queue datastructure can be used for offline diagnosis after an application error lead to some unexpected behavior of the user application.

[0132] In one embodiment, a recording of the event queue containing all the event datastructures and therefore the queuing and execution times of all function blocks can be used to determine the sequence of executed function blocks. Moreover, the recorded timestamps allow to analyze the exact behavior of the application in a timely manner.

[0133] Moreover, such a recording can be stored by the occurrence of a certain error to allow an analysis afterwards to identify the original cause of such an error.