Process control unit and method for exchanging process variables between processes

Abstract

The process control unit according to the present invention, such as a programmable logic controller or SPS or PLC (Programmable Logic Controller), is configured to execute multiple control processes, wherein at least one first control process processed on the process control unit is configured according to the present invention so that in order to process the first control process, the process variables are not directly exchanged with the second control process, but the exchange is performed via an intermediately connected distribution module. Based on the distribution rules, it is determined which control process or control processes the process variables are transferred to. A particular advantage of the present invention is that the exchange of process variables has greater flexibility, and the exchange of process variables is now performed with the aid of a distribution module, in contrast to freezing the "logical link" by program technology in each control process. Advantageously, there is no need to restart the process control unit and the resulting production failure. Additional resources in the process control unit or engineering system can be reduced or avoided. Due to the reduced complexity, control systems and engineering systems can be developed more simply and thus more quickly.

Description

Technical Field

[0001] The invention relates to a process control unit, in particular for controlling or regulating a machine or a plant. The invention also relates to a method for exchanging process variables between processes. Background Art

[0002] In process and production automation technology, field devices are understood to be all types of devices that detect or process process-related information in a process-oriented manner. To detect process variables, measuring devices or sensors are used (e.g. for pressure measurement, temperature measurement, conductivity measurement, flow measurement, pH measurement, level measurement). To influence process variables, actuators are used, such as pumps or valves. In addition to the above-mentioned sensors and actuators, field devices are also understood to be all types of devices arranged at the field level.

[0003] The measured values ​​detected by the sensors are usually transmitted via a field bus to one or more process control units, which further process these measured values ​​if necessary. In the opposite direction, data are also transmitted from the process control unit to the field device, in particular for controlling the actuator and for configuring and parameterizing the field device.

[0004] Although modern process control units appear to be no different from the widely used minicomputer architecture in their computing core (usually a microprocessor or microcontroller with an allocated volatile working memory for executing the control program and a number of I / O interfaces), the sensitivity of the control task and its possible influence on the industrial process leads to some peculiarities. These peculiarities, in particular, establish a strong coupling between the physical external world (i.e. the system to be controlled) and the hardware and software of the process control unit. The process control unit is responsible for a specific, preconfigured scope of the automation task and locally stores the data and software required for this.

[0005] The expansion of this automation task (e.g., the expansion of the process control unit with additional inputs or outputs or the software update of the control program) currently requires a complete switchover of the control program running on the process control unit, which entails a system stop, a recompile of the control program and a system restart. The update or switchover of the control program thus results in a temporary production failure of the system to be controlled by the process control unit. Such production failures are generally to be avoided in process and production automation technology.

[0006] Therefore, the prior art has recognized the necessity of modular design of software on process control units, that is, the necessity of redesigning the current largely monolithic control program into multiple modular cooperating control processes.

[0007] However, the following problems arise with process control units known to date when modifying, replacing or updating modular control processes during ongoing operation: Currently, the interprocess data exchange between the control processes is defined in the respective control processes. It is therefore not possible to dynamically introduce additional or modified control processes, since the modified interprocess data exchange between the modified control process and the existing control process is not suitable for all process variables, for example if more or different process variables are to be communicated for the modified control process than for the original control process. Furthermore, it is currently not possible to dynamically redirect the interprocess data exchange of an existing, ongoing control process while its communication partner (the control process to be modified) is undergoing an update. Summary of the invention

[0008] Against this background, the present invention is faced with the task of creating a process control unit which ensures a more flexible inter-process exchange of process variables for a plurality of control processes.

[0009] This object is achieved by a process control unit having the features of claim 1. The process control unit according to the invention is configured to execute a plurality of control processes, at least one of which takes over the actual control task, i.e. the control of the industrial process. Other control processes support the control task or provide additional functionality.

[0010] According to the invention, at least one first control process to be processed on the process control unit is configured such that process variables are not exchanged directly with a second control process for processing the first control process, but rather via an interposed distribution module.

[0011] The process variable comprises a process variable identifier (eg address, process variable name etc.) and a process variable value, in particular a numerical value of a measured variable in a predetermined (otherwise arbitrary) data format, or a binary value or flag indicating the presence or absence of a condition.

[0012] According to the invention, an allocation module is provided for exchanging the process variables, by which the process variables transmitted by the first control process are received, the process variable identifiers of the process variables are read and transmitted to an allocation rule. Based on the allocation rule, it is determined to which control process or control processes the process variables are transmitted. Then, at least one process variable is transmitted to the control process based on the control process determined from the allocation rule.

[0013] The particular advantage of the invention is the increased flexibility of the exchange of process variables, which now takes place with the aid of distribution modules, in contrast to the "logical wiring" that is frozen in the individual control processes in a program-based manner. For this purpose, the control processes are configured so that process variables are usually transferred to the distribution modules, from which they are forwarded based on distribution rules. This measure allows the recipient of a process variable to be replaced by another recipient by changing the distribution rules. Alternatively, further recipients of process variables can also be added by correspondingly changing the distribution rules. Such a measure could previously only be achieved by more complex changes and recompilation of the control processes that transmit the process variables.

[0014] The object is also achieved by a method for inter-process exchange of process variables within a process control unit and by a computer program for executing the method according to the invention. The computer program is executed as a control process in at least one processor of the process control unit, and the at least one processor executes the method using the processing.

[0015] Further embodiments of the invention are the subject matter of the dependent claims.

[0016] According to an advantageous embodiment, for one or more process variables transmitted to one or more control processes, the process variable identifier read in the assignment module is replaced by a process variable identifier predefined by the assignment rule before the transmission. This replacement of the process variable identifier is meaningful, for example, if the process variable identifier has already been replaced by another process variable identifier in the recipient control process or if the process variable is to be redirected intentionally to a process variable recipient.

[0017] According to an advantageous design provision, the process variable is passed to the control process in a loop-oriented manner. The process control unit usually works in a loop-oriented manner, wherein at least one control process or an operating system of the process control unit controls the loop. The control process updates the input process image applied by the sensor of the production facility at the input end of the process control unit and passes the input process image to at least one other control process. Then, after processing the control instruction, the control process transmits the output process image, which is then forwarded to the actuator of the production facility via the output end by the control process or another control process or the operating system. Then, the control cycle restarts. The cycle time can be fixedly predetermined or asynchronously designed. In addition, the control process can include a plurality of tasks to be executed cyclically, each task having a different cycle time. Then, a corresponding input process image is provided for each task, which is converted from the instruction of the task to the output process image. The individual process images can have different sizes here, that is, different data volumes. The fast tasks of the control program usually only require a small amount of process data here, while the slower tasks mostly process a large amount of process data.

[0018] According to an alternative advantageous design, the at least one process variable is transferred to the at least one second control process within a predeterminable time period. According to this embodiment, when the process variable is received at the distribution module, for example, a timer is started, by which the time period before the value is transferred to the recipient of the process variable is determined. Alternatively, a time stamp is assigned to the process variable at the distribution module, by which the time stamp determines the moment of transferring the value to the recipient of the process variable. The time or the time period can be defined in time units, cycles of a clock generator or steps of a counter.

[0019] According to an alternative design provision, the allocation module has an interface to a configuration process running outside the process control unit. This advantageous measure ensures that the configuration process can access the allocation module to change the allocation rules without having to change or even recompile the program code on which the allocation module is based.

[0020] According to an advantageous embodiment, at least one control process is provided for processing an iterative sequence of control instructions for controlling an industrial process running outside the process control unit. The at least one control process implements the actual control task of the process control unit using the connected field devices.

[0021] According to an advantageous embodiment, it is provided that the allocation module is a control process by which the process variable is stored in a definable storage area of ​​a volatile or non-volatile memory.

[0022] According to an advantageous embodiment, the allocation module comprises a data bus with an allocated bus database. The data bus can be configured to transfer at least one process variable value as a function of an allocated process variable identifier in the bus database. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Further embodiments and advantages of the present invention are explained in detail below based on the accompanying drawings.

[0024] Figure 1 An embodiment of a process control unit according to the invention is shown in a schematic diagram;

[0025] Figure 2 A schematic diagram of a logical link for exchanging at least one process variable between two controlled processes according to the prior art is shown;

[0026] Figure 3 A schematic diagram showing a logical link for exchanging at least one process variable between two control processes according to one embodiment; and

[0027] Figure 4 A schematic diagram showing a logical link for exchanging at least one process variable between an internal control process and an external control process according to one embodiment; and

[0028] Figure 5 A schematic diagram of a logical link for exchanging at least one process variable between a plurality of control processes according to one embodiment is shown. DETAILED DESCRIPTION

[0029] Figure 1 An embodiment of a process control unit 100 according to the invention is shown, which is used to control an installation 500, which is composed of, for example, a robot 510 and a production machine 520. The process control unit 100 is, for example, in the form of a programmable logic controller or SPS or PLC (Programmable Logic Controller).

[0030] The process control unit 100 comprises a memory area 102 indicated by a dashed line, into which a plurality of control processes SP1 , SP2 , SP3 , SP4 are loaded, which are processed in parallel by a microprocessor or microcontroller (not shown).

[0031] One or more modular collaborative control processes SP1, SP2, SP3, SP4 are used to implement special functions, such as link control, process control, time function, counting function and arithmetic function, so as to control different types of machines and processes through digital or analog input and output signals. For this purpose, the process control unit 100 usually has interfaces 140, 142 for controlling facilities, machines or for connecting field devices. The interfaces 140, 142 are adapted to the communication mode of the connected facilities, machines or field devices (here, the robot 510 and the production machine 520).

[0032] exist Figure 1 In the example of , the first interface 140 for controlling the robot 510 is constructed as a fieldbus interface 140, and the second interface 142 for controlling the production machine 520 is constructed as a digital input-output interface 142. The first-mentioned fieldbus interface 140 particularly supports industrial communication standards such as Profibus, Foundation Fieldbus, HART, WirelessHART, etc. Ultimately, the interfaces 140 and 142 are controlled based on the collaborative control processes SP1, SP2, SP3, SP4 so that the facility, the machine or the process works in a prescribed manner.

[0033] The process control unit 100 also has at least one interface 130 for packet-oriented communication with any communication partner (not shown), such as a field device, a superordinate server (e.g. a control console for superordinate control of an industrial process) or an engineering system for transmitting updated program data from an engineering system to the process control unit 100.

[0034] In addition to fieldbuses, wired or wireless Ethernet network connections are also increasingly used for industrial communication, which should be applied to the field device communication level in the future due to its various advantages. Such packet-oriented field devices are connected to the process control unit 100 via an interface 130 for packet-oriented communication. The packet-oriented communication is usually constructed in an industrial environment based on IP (Internet Protocol), that is, according to the Ethernet standard of the protocol family IEEE802 or in accordance with the Ethernet standard. The industrial requirement for deterministic data exchange with field devices in the sub-millisecond range (also commonly referred to as real-time capability) currently still requires the process control unit 100 as the direct superior level of the field device, and will not make the process control unit unnecessary in the future.

[0035] From today's perspective, future Ethernet-based field device communication should allow for the use of the manufacturer- and platform-independent industrial standard OPC UA (Open Platforms Communication Unified Architecture) as well as the extension of the IEEE-802.1 Ethernet standard with real-time capabilities, which are currently the subject of standardization activities as TSN (Time Sensitive Networks). In addition to deterministic data transmission in the submillisecond range, requirements regarding easy configurability and interoperability across manufacturers are also addressed with TSN.

[0036] In addition to the control processes SP1, SP2, SP3, SP4, further input-output processes IO1, IO2 are also put into operation in the storage area 102, which control the interface 130 for packet-oriented communication. These input-output processes IO1, IO2 themselves can be designed as control processes similar to the control processes SP1, SP2, SP3, SP4. Alternatively, the input-output processes IO1, IO2 can also take a different position than the control processes SP1, SP2, SP3, SP4, for example because these input-output processes are components of the operating system (not shown) of the process control unit 100. The input-output processes IO1, IO2 contain, for example, a web server application or an OPC-UA application.

[0037] Among the plurality of control processes SP1, SP2, SP3, SP4 in the process control unit 100, for example two control processes SP2, SP4 are provided to control an industrial process on the installation 500, while the other control processes SP1, SP3 support the control or provide additional functionality.

[0038] Due to the modular nature of the control processes SP1, SP2, SP3, SP4, it is necessary to exchange data between the control processes SP1, SP2, SP3, SP4. This data exchange is generally discussed below as the exchange of process variables. These process variables include all data exchanged between processes, such as binary values ​​(e.g., flags, which indicate the presence or absence of a condition), addresses of storage units to be read or written or values ​​of said addresses, in addition to numerical values, character strings, etc. In particular, the content of these process variables is not limited to the content of supporting the actual industrial control tasks of the process control unit 100.

[0039] In the prior art, the interprocess data exchange between modular control processes is currently defined in the respective control process itself, for example using a shared memory cell in a register or a cache, to which both control processes have read or write access. For this purpose, it is currently provided that a link is created in the program code of the respective control process itself. Such currently practiced program-technical links are performed, for example, via the address of a shared memory cell or a pointer to the address of a shared memory cell.

[0040] Figure 2 Detailed description of the exchange of process variables between two control processes SP1, SP2 according to the prior art is shown in . The first control process SP1 has three process variables v1.1, v1.2, v1.3 in part. The second control process SP2 also has three process variables v2.1, v2.2, v2.3 in part.

[0041] The process variable v1.1 of the first control process SP1 is logically connected to the process variable v2.3 of the second control process SP2. This logical connection (shown in the figure by the line connecting the process variables) should be understood as implementing read or write access to the process variable v2.3 of the second control process SP2 in the program code of the first control process SP1. Conversely, read or write access to the process variable v1.1 of the first control process SP1 is implemented in the program code of the second control process SP2. Here, reference to various other process external variables can be made in the program itself - or alternatively triggered or re-evaluated by the operating system - by referencing the address of a shared storage unit or a pointer to the address of a shared storage unit. In each case, the reference to the process external variable is implemented in the program code of the corresponding control program itself.

[0042] Interprocess data exchange between modular control processes defined in the corresponding control processes themselves has several disadvantages:

[0043] - Additional or (for example during an update) modified control processes cannot be introduced dynamically, since, for example, if more or different process variables are to be communicated for the modified control process than for the original control process, the interprocess data exchange between the modified control process and the existing control process is not suitable for all process variables.

[0044] Furthermore, it is currently not possible to dynamically redirect the inter-process data exchange of an existing, running control process while at the same time the communication partner of this control process (the control process to be changed) is undergoing an update.

[0045] If a configuration change is required during operation, in which the process variable v1.1 is no longer to be logically linked to the process variable v2.2 of the second control process SP2, but is to be logically linked to the process variable v2.3, for example, then the following process is unavoidable with current programming technology:

[0046] - Stop the operation of the process control unit 100;

[0047] - modifying the source code of the first control process SP1 with respect to the described logical linking of the process variable v1.1 with the process-external process variable v2.3;

[0048] - compiling the modified source code of the first control process SP1 and loading the compiled program code into the process control unit 100; and

[0049] - Restart the process control unit 100 .

[0050] Current process control units therefore lack flexibility due to their monolithic structure and their strong coupling of hardware and software. Currently, scalability in terms of the functionality of the process control units can only be achieved by adding further process control units. Changes in the physical or data technology world often require reconfiguration, recompilation and often also restarting of the participating process control units. In this case, in addition to the running components, the recompiled components must also be stored on the process control unit, which means an increased memory requirement.

[0051] The present invention solves these existing problems by abandoning the inter-process data exchange between modular control processes defined in the corresponding control process itself. According to the invention, the data exchange of process variables is not carried out directly between the control processes, but via the intermediate distribution modules.

[0052] A process variable includes a process variable identifier (eg address, process variable name, etc.) and a process variable value, in particular a numerical value of a measured variable in a predefined (otherwise arbitrary) data format or a binary value or flag which indicates the presence or absence of a condition.

[0053] Re-reference Figure 1 According to the invention, an allocation module ASU is provided for exchanging process variables, by which the process variables transmitted from the first control process SP1 are received and then the allocation of the process variables is determined, i.e. to which control process or control processes the process variables are transmitted.

[0054] In a first simple embodiment, the allocation module ASU is designed as a common data bus between a plurality of control processes. According to the invention, the allocation now takes place dynamically, i.e. during the operation of the process control units. This dynamic allocation takes place based on allocation rules, which in this embodiment are stored, for example, in a link table assigned to the data bus. The link table is implemented, for example, as a data structure or database that can be managed by software.

[0055] According to this design of the present invention, the change of the allocation can be triggered by the allocation module ASU during the ongoing operation of the process control unit without stopping the operation of the process control unit 100, changing the source code of the control process, recompiling and loading the control process or restarting the process control unit 100. The allocation module ASU is designed here as a data bus, which has a link table assigned to the data bus.

[0056] The allocation table (not shown) of the allocation module ASU can advantageously be created and managed simply, since only the corresponding process variables of the participating control processes are linked to one another via the allocation table. The process variable identifiers used in the control processes (e.g. variable names, data types and other information of the individual software components) can be collected, for example, by a configuration process (e.g. an engineering system) running outside the process control unit and used for the linking. This allows the engineering design to check the consistency of the connections. The allocation can be carried out both textually (i.e. in the form of structured representations of allocation rules) and graphically (i.e. in the form of machine-readable wiring diagrams).

[0057] When the process control unit 100 is started up, the configuration of the linked process variables can be stored in the assignment table, i.e. Figure 3 , which process variable comprises a process variable identifier v1.1 in a first control process SP1 and a process variable identifier v2.2 in a second control process SP2. The data structure of the assignment table, in which the assignment of process variable identifiers v1.1 and v2.2 is described when the process control unit is started, can be adapted at any time during operation, i.e. dynamically. Figure 3 This is shown by dashed lines which alternatively or additionally connect the data bus of the distribution module ASU to further process variable identifiers v1.2, v1.3, v2.1, v2.3.

[0058] In the ongoing operation, the first control process SP1 is configured so that the process variable (process variable identifier v1.1 is assigned to the process variable in the first control process SP1) is exchanged with the second control process SP2 via the allocation module ASU in the following manner, i.e. the process variable transmitted from the first control process SP1 is received from the allocation module ASU. The process variable identifier v1.1 of the process variable is then read in the allocation module ASU. The process variable is then passed to the allocation rule in the allocation module ASU. According to the allocation rule, the process variable identifier v1.1 read in the allocation module is replaced by the process variable identifier v2.3 predetermined by the allocation rule. The allocation module ASU passes the process variable, which now has the process variable identifier v2.3, to the second control process SP2. The process variable value preferably remains unchanged.

[0059] In a second embodiment, the distribution module ASU is designed to control the process. Figure 1 As a result, the allocation module ASU is now schematically located within the dashed area of ​​the memory area 102 , in which a plurality of control processes SP1 , SP2 , SP3 , SP4 are loaded.

[0060] In the allocation module ASU, the process variables are stored in a definable memory area, ie, for example, in registers of a processor-oriented register memory which are managed by the allocation module ASU.

[0061] The allocation according to this second embodiment is basically carried out as described above based on the first embodiment. During the ongoing operation, the first control process SP1 is set to exchange the process variable (the process variable identifier v1.1 is assigned to the process variable in the first control process SP1) with the second control process SP2 via the allocation module ASU, so that the process variable transmitted from the first control process SP1 is first received from the allocation module ASU. The process variable identifier v1.1 of the process variable is then read in the allocation module ASU. The process variable is then passed to the allocation rule in the allocation module ASU. The allocation rule is implemented, for example, as an allocation table or a database, which is accessed by the control process of the allocation module ASU. According to the allocation rule, the process variable identifier v1.1 read in the allocation module ASU is replaced by the process variable identifier v2.3 predetermined by the allocation rule. The allocation module ASU passes the process variable now having the process variable identifier v2.3 to the second control process SP2. The process variable value preferably remains unchanged.

[0062] If the process variable identifiers v1.1, v2.3 are different, the above-mentioned assignment rule is an optional step, in which the process variable identifier v1.1 read in the assignment module is replaced by the process variable identifier v2.3 specified by the assignment rule. In the case of identical process variable identifiers, i.e., for example, in the case of a system-wide valid and readable process variable identifier "Temperature_Sensor_34", this measure can be omitted.

[0063] The dynamic change of the allocation rules is explained in detail below. If a configuration change is required so that a process variable with process variable identification v1.1 should no longer be logically linked to a process variable with process variable identification v2.2 of a second control process SP2, but is instead logically linked to a process variable with process variable identification v2.3, for example, then the program technology linking known in the prior art inevitably brings about a change of the participating control processes SP1, SP2, which includes a restart of the system.

[0064] The previously known process control units can only implement the possibility of changing the control processes SP1, SP2, SP3, SP4 in the running system with great effort in terms of engineering and hardware operating system. In order to implement the changes, for example, memory space in which the changes can be temporarily stored must be reserved in the memory area 102 of the process control unit 100 for these possible changes. The program must be compiled for the changes, and only certain changes can be made during ongoing operation.

[0065] By using the device according to the invention with the participation of the allocation unit ASU, such changes to the participating control processes SP1, SP2 are advantageously not necessary. Instead, the allocation rules in the allocation unit ASU are changed by means of access, which can also be made during the operation of the process control unit 100, using a configuration process (e.g. in a simple engineering system).

[0066] According to one embodiment, the allocation module ASU has an interface to a configuration process running outside the process control unit. Figure 1 , for example, by the allocation module ASU accessing the interface 130 for packet-oriented communication via one of the input-output processes IO1, IO2 to form a program-technical interface. Alternatively, the allocation module ASU has a separate (not shown) external interface. Via this interface, for example, a web server application is executed which allows access to the allocation rules. Both embodiments of the allocation module ASU form an interface to a configuration process (not shown) running outside the process control unit 100.

[0067] This advantageous measure ensures that the configuration process can access the assignment module ASU in order to modify the assignment rules without having to modify or even recompile the entire program code on which the assignment module 100 is based.

[0068] A further advantageous embodiment is described below, which likewise uses the above-described interface of the distribution module ASU to a process running outside the process control unit. For testing purposes, it is often useful to specifically control or test the behavior of the control program or the behavior of individual physical components in the interaction within the process control unit 100.

[0069] In the exemplary case, reference should now be made to Figure 4 It is assumed that the behavior of a process variable having a process variable identification v1.1 valid in the first control process SP1 is to be checked. To this end, an external process SPE running on an external checking device (not shown) is run via the above-mentioned interface, which accesses the allocation module ASU and thus the allocation rules of the allocation module ASU via the interface.

[0070] The external process SPE first causes the allocation to the process variable with the process variable identifier v_ext by entering it in the allocation rules of the allocation unit ASU. Then, the existing allocation of the process variable with the process variable identifier v1.1 valid in the first control process SP1 is no longer (or no longer only) logically linked to the process variable identifier v2.2 of the second control process SP2, but is logically linked to the process variable with the process variable identifier v_ext. Therefore, the link between the process variable identifier v1.1 and the process variable identifier v_ext is created dynamically, that is, during the operation of the process control unit 100. The previously valid link between the process variable identifier v1.1 and the process variable identifier v2.2 is either additionally retained (as symbolically shown by a solid line in the figure) or separated by deleting the link entry between the process variable identifier v1.1 and the process variable identifier v2.2 in the allocation table.

[0071] The first-mentioned setting additional link is particularly suitable for diagnostic or monitoring purposes, wherein the exchange of process variables with process variable identification v1.1 valid in the first control process SP1 and process variables with process variable identification v2.2 valid in the second control process SP2 should remain unaffected for monitoring or diagnostic purposes. The second-mentioned setting alternative link is particularly suitable for simulation purposes, wherein for simulation or test purposes, the exchange of process variables with process variable identification v1.1 valid in the first control process SP1 should be replaced by an exchange with process variable identification v_ext valid in the external process SPE. The external process SPE provides simulated process variables, more precisely process variables with process variable values ​​generated for simulation purposes. The operation with the help of simulated values ​​can be carried out similarly to the above-mentioned test operation, that is, the following operation can be realized, in which real measured variables with simulated values ​​are temporarily shared without interrupting the entire system.

[0072] Another advantageous design is described below, which enables a fail-safe and / or highly available operation of the process control unit 100. In an exemplary case, reference should now be made to Figure 5 Assumption: The first temperature sensor T1 provides the following process variable: In the control process SP2 that controls the first temperature sensor T1, the process variable is assigned a process variable identifier v2.2. The second temperature sensor T2 provides the following process variable: In the control process SP3 that controls the second temperature sensor T2, the process variable is assigned a process variable identifier v3.1.

[0073] The two temperature sensors T1 , T2 are arranged here adjacent to each other, but physically independently of one another at the same measuring location, so that the two temperature sensors T1 , T2 ideally measure the same temperature value. Starting from a first control process SP1 , this temperature value is required at repeated intervals.

[0074] In order to read the temperature value, the first control process SP1 is configured so that a process variable containing the temperature value as a process variable value is read via the allocation module ASU, and a process variable identifier v1.1 is assigned to the process variable in the control process SP1. The process variable identifier v2.2 of the process variable is read in the allocation module ASU, and the control process SP2 that controls the first temperature sensor T1 transfers the process variable containing the temperature value as a process variable value to the allocation module ASU using the process variable identifier v2.2. The process variable is transferred to the allocation rule in the allocation module ASU. According to the allocation rule, the process variable identifier v2.2 read in the allocation module is replaced by the process variable identifier v1.1 predetermined by the allocation rule. The allocation module ASU transfers the process variable, which now has the modified process variable identifier v1.1, to the first control process SP1. The process variable value preferably remains unchanged. Therefore, the allocation rule is configured to link the process variable identifier v2.2 with the process variable identifier v1.1.

[0075] If the first temperature sensor T1 now fails, the first control process SP1 of the process control unit 100 or another control process can cause a dynamic switch to the temperature sensor T2, which has the same value in terms of the measured temperature value. This switch is carried out by changing the entry in the assignment rule, in which the link between the process variable identifier v3.1 and the process variable identifier v1.1 is now established. In the process, the first control process SP1 now obtains the temperature measurement value from the second temperature sensor T2.

[0076] In an extension of the above-described design, the distribution module ASU, which is itself designed to control the process, is designed such that the process variable value (here the temperature measured value) of the process variable is monitored by the distribution module ASU itself. If a defined tolerance range for the monitored process variable value is exceeded, the distribution module ASU can trigger an error or alarm condition, which may lead to further actions, by which, for example, the process control unit 100 is placed in a safe state.

[0077] In an extension of the above-described design, for some applications, a link between more than two process variable identifiers is also advantageous. Such applications relate, for example, to the implementation of safety-related systems in which a plurality of control processes operate simultaneously and redundantly using the values ​​of other control processes provided by the process variables.

[0078] Therefore, in combination with the above-mentioned design of dynamic variable switching, a fail-proof and highly available process control unit can also be realized, in which it is possible not only to switch between process variables (e.g. sensor values) that are independent of the rest of the system during operation, but also to switch between components (in particular control processes) that are dependent on other process variables of the system.

[0079] In a simple design, the distribution module ASU does not necessarily need to work in a cycle-oriented manner. In other words, this simple design of the distribution module ASU behaves agnostic with respect to the time requirements of the process variables to be transmitted. In this simple design of the distribution module ASU, the modified process variable can be provided without any special time boundary conditions as soon as the process variable identifier of a process variable and / or its process variable value undergoes a change.

[0080] In an alternative design of the distribution module ASU, the distribution module actively participates in synchronization events of the process control unit 100, wherein at least one process variable is passed on to at least one control in a cyclically oriented manner. Furthermore, in another design of the invention, the distribution module ASU can be designed flexibly in order to serve scenarios with different requirements for deterministic data exchange (often also referred to as real-time criticality). Thus, together with the synchronization between components or control processes of the process control unit 100, any real-time scenario can be covered. This includes time-limited, cycle-bound processing methods as are known in conventional SPS (programmable logic controllers), as well as alternatively or additionally event-driven free processing or completely time-unconstrained variable processing.

[0081] The independence of the process variables linked to one another via the assignment module ASU allows not only mixed operation with different process variables, but also cyclic or freely mixed operation between event-based processing and time-independent processing via free multiple links. This can mean, for example, that slow, time-noncritical monitoring components can also use the same process variables as those used for strictly cyclic processing.

[0082] In summary, the process control unit according to the present invention is configured to execute multiple control processes, wherein at least one first control process processed on the process control unit is configured according to the present invention so that in order to process the first control process, the process variables are not directly exchanged with the second control process, but the exchange is performed via an intermediately connected allocation module. Based on the allocation rule, it is determined which control process or control processes the process variables are transferred to. A particular advantage of the present invention is that the exchange of process variables has greater flexibility, and in contrast to freezing the "logical link" by program technology in each control process, the exchange of process variables is now performed with the aid of an allocation module. Advantageously, there is no need to restart the process control unit and the resulting production failure. Additional resources in the process control unit or engineering system can be reduced or avoided. Due to the reduced complexity, control systems and engineering systems can be developed more simply and thus more quickly.

Claims

1. A process control unit, configured to execute a plurality of control processes (SP1, SP2, ..., SP4), wherein the control process unit comprises: a memory in which the plurality of control processes (SP1, SP2, . . . , SP4) and the allocation module are loaded, wherein at least one control process (SP2, SP4) is arranged to control an industrial process (500) running outside the process control unit (100), - wherein at least one first control process (SP1) is configured such that, for processing the first control process, process variables are exchanged with at least one second control process (SP2) via the distribution module (ASU); - wherein the process variable comprises a process variable identifier and a process variable value; and - The allocation module (ASU) is configured to exchange the process variables so as to receive a process variable transmitted by the first control process (SP1), dynamically determine the allocation of the process variable based on an allocation rule, i.e., to which control process or to which control processes the process variable is to be transmitted, read the process variable identifier of the process variable and transmit it to the allocation rule, trigger a change to the allocation during the ongoing operation of the process control unit by replacing the process variable identifier with a process variable identifier predetermined by the allocation rule, and transmit the process variable to at least one second process variable (SP2) based on the allocation rule and the process variable identifier predetermined by the allocation rule.

2. The process control unit according to claim 1, wherein: The process variables are transferred to the at least one second control process (SP2) in a loop-oriented manner.

3. A process control unit according to any one of the preceding claims 1 to 2, wherein: The process variable is transmitted to the at least one second control process (SP2) within a predeterminable time period.

4. A process control unit according to any one of the preceding claims, wherein: The allocation module (ASU) has an interface to a configuration process (SPE) running outside the process control unit (100).

5. A process control unit according to any one of the preceding claims, wherein: At least one control process (SP2, SP4) is configured to process an iterative sequence of control instructions for controlling an industrial process (500) running outside the process control unit (100).

6. A process control unit according to any one of the preceding claims, wherein: The assignment module (ASU) is a control process by which the process variables are stored in a definable storage area of ​​a volatile or non-volatile memory.

7. A process control unit according to any one of the preceding claims 1 to 6, wherein: The allocation module (ASU) comprises a data bus with an allocated bus database.

8. The process control unit according to claim 7, wherein: The data bus is configured to transmit at least one process variable value as a function of a process variable identifier assigned in the bus database.

9. A method for inter-process exchange of process variables in a process control unit (100), in which a plurality of control processes (SP1, SP2, ..., SP4) are executed, wherein at least one control process (SP2, SP4) is arranged to control an industrial process running outside the process control unit (100), and wherein process variables of a first control process (SP1) are exchanged with at least one second control process (SP2) via an assignment module (ASU), wherein the process variables comprise a process variable identifier and a process variable value, the method comprising: - receiving, by means of said allocation module (ASU), at least one process variable delivered by said first control process (SP1); - dynamically determining the allocation of the at least one process variable based on an allocation rule, ie to which control process or to which control processes the at least one process variable is transferred; - reading the process variable identifier from the process variable and passing the process variable identifier to the allocation rule; - during the ongoing operation of the process control unit, initiating a change in the assignment by replacing the process variable identifier with a process variable identifier specified by the assignment rule; as well as - Based on the assignment rule and the process variable identifier specified by the assignment rule, at least one process variable is transferred to at least one second control process.

10. The method according to claim 9, wherein: The at least one process variable is transferred to the at least one second control process (SP2) in a loop-oriented manner.

11. The method according to any one of the preceding claims 9 to 10, wherein: The at least one process variable is transmitted to the at least one second control process (SP2) within a predeterminable time period.

12. A computer program product having a program code for carrying out the method according to any one of claims 9 to 11 when the program code is executed as a control process in at least one processor of a process control unit (100).

Images