Patent Description:
Modular plants are an established aspect of Industry <NUM> and provide benefits not only with respect to development cost but also with respect to time and material efforts. An integral layer of the modular plant structure consists of prefabricated and well-tested modules called PEAs (Process Equipment Assembly), that can readily be assembled in different combinations to realize different target systems. PEAs are typically provided with their own intelligence to provide all necessary functions for safe decentralized operation. Data exchange between PEAs is realized via a standardized interface description called Modular Type Package (MTP). The MTP approach creates the framework for interoperability between modules and the orchestration system, enabling process plants to be built up and engineered in a more modular way, with the goal of simplifying process plant engineering and life cycle management.

<CIT> discloses a "definition module" which is configured for a generic part of a process control system based on generic design data which is independent of the process control system. The definition module is then updated with specific design data for a specific part.

Notwithstanding the desire for modularization, the inventors have made the surprising recognition that plant owners typically design, create and calibrate their own modules individually, often expending significant effort in the subsequent assembly of these modules in the overall plant. The modules are then bound to a specific control system for the automation of the module interior function. Reuse of the software of a PEA is therefore hardly possible because of automation vendor binding. Every PEA is typically given its own intelligence, by means of a controller and embedded OPC UA Server. The controllers are used to automate the process functions from the PEA and expose the functions using service-oriented architecture and state-based control for the supervisory system. Binding the PEAs to specific hardware and adding a controller to each PEA brings high investment costs and vendor dependency.

The inventors have recognized that it would be advantageous to solve some or all of these problems. The invention therefore provides a method of configuring a modular plant, along with a computer and a computer program product, as defined by the appended claims.

By "controller-agnostic" is meant that the configuration file is not yet bound to a specific hardware controller on which the control software is to run, nor to the target system of which that hardware controller forms a part. The configuration file, as well as the control software configuration itself, can thus be described as being agnostic/independent of, or abstracted from, the (details of the) controller/hardware/module/target system. In other words, the control software configuration and the configuration file include only generic details of a controller/hardware/module/target system that could apply to any such element, and/or only details pertaining to a certain class/type/kind of controller/hardware/module/target system that will be exhibited by any such element of that class/type/kind. The control software configuration may also be referred to as an automation software configuration. In one example described further below, the control software configuration is provided by a virtual PEA / function module, and the controller-agnostic configuration file by a generic MTP. The control software configuration thus exists as a definition of control software decoupled from the hardware controller on which the software will run, thereby promoting software reusability, reducing or eliminating vendor dependency, and reducing development/investment costs.

Controller agnosticity may be provided in such innovative ways as omitting controller-specific parameters and/or controller-specific logic functions from the configuration file, and/or providing in the configuration file default parameters and/or default logic functions for later adaptation during plant engineering to a specific controller/hardware/module/target system, and/or providing parameters and/or default logic functions which are static/constant in that they apply to all controllers/hardware/modules/target systems (or to all controllers/hardware/modules/target systems of a certain type) and which will thus remain unchanged during subsequent plant engineering, despite integration of the modules into the target system. The parameters specify states of a state machine defining an application to be executed by the said module. Thus, in one example, the parameters comprise one or more of (i) default parameters for adaptation to the target system during the plant engineering or (ii) static parameters that will remain unchanged during the plant engineering. Additionally or alternatively, an application to be executed by the said module defines logic that is predetermined to be executable independently of state machines defining the application, in other words that is executable independently of the service and the (specifics of the) state-machine controlling the service, and therefore executable independently of the details of the target system.

In an example, the controller-agnostic configuration file furthermore advantageously specifies one or more of the following for the said module: (i) one or more parameters, (ii) one or more variables, (iii) one or more views; (iv) one or more state machines; (v) one or more applications; (vi) one or more events; (vii) one or more methods; (viii) one or more signal references; (ix) one or more signal outputs.

In an example, the binding further comprises matching input/output signals. The binding may comprise one or more of (i) assigning a further instance of controller software, instantiated according to a further such controller-agnostic configuration file, to the same hardware controller of the said module, and (ii) assigning the controller software additionally to a hardware controller of a further module of the target system. Such flexibility does not exist in the prior systems in which the modules are inherently bound to a specific control system.

In an example, the method further comprises simulating execution of the said module in a virtual control environment for testing. The virtual control environment may comprise one or more of (i) a soft controller of a specific target system; (ii) a software representation of the said module; (iii) a debugging function. The ability to perform such testing in virtual environments, as well as virtual plant orchestration, is facilitated by the controller-agnostic nature of the described control software configuration, not yet being bound to any specific hardware controller.

In an example, the said module comprises a Process Equipment Assembly (PEA). The PEA can in one example form part of a distributed control node (DCN). In any of these examples or in others, the controller-agnostic configuration file may comprise a Modular Type Package (MTP) defining the PEA/DCN, for example as a generic MTP.

In an example, the method further comprises, in a workflow for project execution: testing the control software configuration as defined by the controller-agnostic configuration file; attaching an input/output configuration to the control software configuration at the modular plant; testing the input/output configuration in conjunction with the control software configuration on a virtual controller; assigning a hardware controller to an instance of the software controller instantiated according to the controller-agnostic configuration file; adding physical input/output to the hardware controller and software controller instance; and adding pretested supervisory control and/or orchestration for plant control. Project execution is thus greatly facilitated by the controller agnosticity described herein.

In a second aspect, there is provided a computer comprising a processor configured to perform the method of configuring a modular plant.

In a third aspect, there is provided a computer program product comprising instructions which, when the program is executed by a processor of a computer, cause the computer to perform the method of configuring a modular plant.

Further aspects and examples of the invention will become apparent from and be elucidated with reference to the embodiments described hereinafter.

Exemplary embodiments will be described in the following with reference to the following drawings:-.

Modular plants may be engineered as shown in <FIG>. The engineering workflow <NUM> is split into two parts: (project-independent) module type engineering workflow <NUM> and (project dependent) plant engineering workflow <NUM>. The module type engineering workflow <NUM> may be undertaken by a module supplier or by the owner of the modular plant. The plant engineering workflow <NUM> may be undertaken by the plant owner.

Within the module type engineering workflow <NUM>, all engineering for a module type / PEA <NUM> is done, meaning: instrumentation, electrical, control engineering; physical connection of the inner process equipment; I/O marshaling and selection of the controller hardware; factory acceptance testing. A module type <NUM> is after its creation at <NUM> ready for use within a plant, because it provides an own intelligence and OPC UA server interface that can be used for controlling it. The interface of every module type <NUM> is described by generating at <NUM> an MTP <NUM>, for example according to IEC63280 ED1 ACD. Every module type <NUM> uses services to expose its inner functions to the supervisory control system as services. A service-oriented architecture may be used. Behind every service, a defined state machine is executed and the states are exposed.

The MTP <NUM> is later used for the second part, the plant engineering workflow <NUM>, where the MTPs <NUM> of the module types <NUM> are imported <NUM> and instances for the module types <NUM> are created, before being integrated at <NUM> into the plant automation. The dcentralised automation of the different module types <NUM> is integrated in a Process Orchestration Layer (POL) <NUM>.

<FIG> illustrate the module type engineering workflow <NUM> in more detail. In order to engineer a module type <NUM>, the human-machine interface (HMI) of the module type is first defined at <NUM>, which may resemble for instance the engineering of a piping and instrumentation diagram. From the HMI, a tag list is automatically derived at <NUM>. The tag list contains all tags that are used within the automation system. In the tag list, the user can change the parameters of the tags. Both, the tag type and the parameters may be compliant to IEC <NUM> ED1 ACD. In the third step <NUM>, the services for the module type <NUM> are defined. This begins with adding a service and additionally adding necessary service parameters at 203a that should be exposed to the supervisory control system. Service parameters might be for example "Amount" for a service "Fill", which is used to tell the "Fill"-service how much should be filled into the module. After the definition of the service, the state of the underlying state machine is filled with logic at 203b, 203c. The logic definition is still not bound to a target system but will later be used in steps 204a and 204b to create the target system specific information. In step 204a, the target system specific information is created and can be used for the automation of the module type <NUM>. This is now bound to the target system and the target system cannot be exchanged later on during plant engineering. In step 204b, a target system specific MTP <NUM> is created that describes the interface of the module type <NUM>.

<FIG> illustrate the plant engineering workflow <NUM> in more detail. The plant engineering workflow <NUM> also follows a four-step approach, where, in the first step <NUM>, all module types <NUM> required in the plant are added to a module library. After adding the module types <NUM>, defined by their MTPs <NUM>, those can be used at <NUM> to create a topology of the modular plant, by creating module instances in the engineering tool and connecting them by means of material and information flow. At <NUM>, the module instances can be used to define - based on their services - sequences that can be executed by the supervisory control system, POL <NUM>. The supervisory control system <NUM> is in the last step <NUM> created from the information from the engineering tool.

<FIG> illustrates the HMI definition <NUM> of a module type <NUM>, corresponding to step <NUM> of the module type engineering workflow <NUM>. The HMI editor <NUM> in conjunction with the symbol library <NUM> and the property editor <NUM> assists the user in defining the HMI. A list of equipment <NUM> is automatically generated and illustrates the structure <NUM> of the module visualizations.

<FIG> illustrates the tag definition <NUM> in the module type engineering workflow <NUM>, the engineering of the tag list, corresponding to step <NUM>. The tag editor <NUM> generates a tag list <NUM> from the HMI and presents properties <NUM> according to the relevant standard, allowing the user at <NUM> to set property values.

<FIG> illustrates the service definition <NUM> of a module type, comprising definition of the service and the service parameters, corresponding to steps 203a and 203b of the module type engineering workflow <NUM>. The user is able to define at <NUM> the state machine for the service, choosing from a list of available services <NUM>, and set service parameters using the service parameter editor <NUM>.

<FIG> illustrates the state definition <NUM> of a state of a service state machine for a module type <NUM>, according to step 203c of the module type engineering workflow <NUM>. The state editor <NUM> allows the user to choose from various defined states <NUM>, to define actions <NUM> when entering or leaving the state, to specify causes <NUM>, parameters <NUM> as cause, trip points <NUM> and interlock logic <NUM> for each state, as well as effects <NUM>, transitions as effect <NUM>, and effect commands <NUM>.

<FIG> illustrates the topology definition <NUM> of a modular plant, according to step <NUM> of the plant engineering workflow <NUM>, in which the user can use the property editor <NUM> and the topology editor <NUM> to work on the previously-defined module type library <NUM> to define the engineering structure <NUM>.

<FIG> shows the content of a virtual PEA / function module <NUM>. The inventors have developed the virtual PEA / function module <NUM> as a software description of a module type <NUM>. Broadly speaking, the virtual PEA / function module <NUM> serves as a control software configuration for a module <NUM> of a modular plant, specifying parameters for the said module that are not specific to any target system, such as default parameters. The virtual PEA / function module <NUM>, serving as the control software configuration, is provided as a controller-agnostic configuration file, in other words a target-system-independent configuration file - in one example a generic MTP <NUM> - for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the said module when the said module is integrated into a target system during plant engineering.

More particularly, instead of having a binding to a specific target system, the virtual PEA / function module <NUM> contains only the description of the functionality which the target system should contain. For example, the virtual PEA / function module <NUM> may contain the same information as the module type <NUM> described above, in addition to information concerning the logic that is executed inside the states of the services (application <NUM> in <FIG>). The application <NUM> includes the states executed in the overarching state machine. Only the state machine is externally visible. The states are defined as extended cause-and-effect matrices, as for the module type <NUM> described above. The application <NUM> optionally also contains logic that is predetermined to be executable independently of the state machines. In one example for equipment protection, if for example a valve is closed, all succeeding pumps have to be stopped to prevent them from running dry. Further examples of logic that is predetermined to be executable independently of the state machines includes opening a release valve in response pressure in a vessel becoming too high, and opening a release valve to flare in response to too much pressure in a gas pipeline. This kind of logic has to be executed always and independently of the services and the (specifics of the) state-machine controlling the service. Further such examples will be apparent to the skilled reader and are encompassed by this disclosure, which should not be taken as limiting to any one such example. This enables the virtual PEA / function module <NUM> to be portable to different kinds of target system, because the application <NUM> that should be executed within the states is not yet bound to any target system. The parameters may further specify communications for the target module <NUM>.

For every control equipment (sensor, valve, etc.) used in the module, a set of parameters is defined. There may be different kinds of parameters for the module that are not specific to any target system, as in the following non-limiting examples. Further such examples will be apparent to the skilled reader and are encompassed by this disclosure, which should not be taken as limiting to any one such example.

All the above-described parameter types are typically exposed as OPC UA variables by the OPC UA server of the module. Since the OPC UA Server does not exist in the virtual PEA / function module <NUM>, and is only later added to the function module instance, the engineer can set default values to the parameters. Those can be (i) subsequently changed during plant engineering, (ii) provided by the actual OPC UA server of the assigned target system, or (iii) set for every state of the state machines or for every service or module wide (i.e. only one parameter value is given that is used for all operating states).

As shown in <FIG>, the virtual PEA / function module <NUM>, provided as a controller-agnostic configuration file, for example in the form of a generic MTP <NUM>, specifies one or more of the following for the target module <NUM>: (i) one or more parameters <NUM>, (ii) one or more variables <NUM>, (iii) one or more views <NUM>; (iv) one or more state machines <NUM>; (v) one or more applications <NUM>; (vi) one or more events <NUM>; (vii) one or more methods <NUM>; (viii) one or more signal references <NUM>; (ix) one or more signal outputs <NUM>.

The virtual PEA / function module <NUM> thus provides for automation of PEAs that do not have an embedded controller and OPC UA server. The automation of the virtual PEA / function module <NUM> can be carried out in a central or distributed control system and it is possible to have several virtual PEAs / function modules <NUM> on one controller. The virtual PEA / function module <NUM> decouples the control application software from the controller and input/output hardware of a PEA. Instead of binding the control application software to hardware as a controller, input and output hardware design may be performed in later steps. The software description may be exported as the virtual PEA / function module <NUM> into a controller-agnostic (in other words hardware-independent) MTP <NUM>. During plant engineering, the virtual PEA / function module <NUM> can then be assigned to a controller and input/output signals can be matched. Thus, it may also be possible to assign several virtual PEAs / function modules <NUM> to a single controller and to reuse the virtual PEA / function module <NUM> with another vendor or target system later.

<FIG> illustrates the engineering workflow <NUM> as executed using function modules <NUM>. In this example, the function module engineering workflow <NUM> is carried out by a plant engineering tool <NUM>. The interface between the function module engineering <NUM> and the plant engineering tool <NUM> may be provided by the controller-agnostic MTP <NUM> of the function modules <NUM>.

The function module engineering workflow <NUM> using the virtual PEA / function module <NUM> is as the module type engineering workflow <NUM> described above, except that step 204a of the module type engineering workflow <NUM> is not executed, and that step 204b - to account for the target system being unknown, and instead of generating a target system specific MTP - comprises generating an MTP <NUM> without the target system specific information. This generic MTP <NUM> is then used to describe the function module. The MTP <NUM> may be XML-based. In <FIG>, step (a) of the function module engineering workflow <NUM> corresponds to steps <NUM>-<NUM> of the module type engineering workflow <NUM>. Step <NUM>(b) corresponds to step 204b, except that the generic MTP <NUM> is generated. Steps 204b/<NUM>(b) may be performed by a computer. Broadly speaking, the function module engineering workflow <NUM> involves a method of providing a control software configuration for a module of a modular plant, the method comprising: receiving a user definition for the said module; and automatically generating (<NUM>(b) the control software configuration (e.g. the virtual PEA / function module <NUM>) for the said module based on the user definition, comprising specifying parameters for the said module that are not specific to any target system, and providing the control software configuration as a controller-agnostic configuration file (e.g. the generic MTP <NUM>) for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the said module when the said module is integrated into a target system during a plant engineering phase.

The plant engineering workflow <NUM> using the function module <NUM> is undertaken as described above, except that step <NUM> is executed also in relation to instances of function modules <NUM> used inside the modular plant. Step <NUM>(a) comprises adding function module instances (as instances of software controllers instantiated according to respective controller-agnostic configuration files) to a plant. Cycling through the parameters, as described above, the parameters are adapted to the needs of the plant. The result is a topology of function module instances (still pure software) which shows how those are physically connected and instance parameters are adapted to the needs of the plant. In step <NUM>(b), a recipe is created that shows when which service of which module is to be executed, stopped, paused, etc. The engineer can define the orchestration of the function module instances in sequences that can later be executed in the plant automation system. In step <NUM>(c), the (hardware) controller to execute the function module instances is selected. The function module instances may be executed on separate controllers of different type (even different vendors) or several function module instances may be executed on the same controller. The control software configuration of a particular function module instance is downloaded or exported to the selected controller automatically. The controller-specific parameters necessary for the specific control system are added automatically to the respective function module instance once the controller is assigned. In addition, the process devices are assigned to the sensors and equipment defined in the function module instance. Here, for example, a physical sensor such as a laser level transmitter is assigned to the planned items from the function module instance. Additionally, device-specific parameters are automatically adapted from their default settings (e.g. the measuring range, as described above). Broadly speaking, the plant engineering workflow <NUM> involves a method of configuring a modular plant which comprises, in a plant engineering phase: receiving a user definition for the modular plant as a target system, the definition identifying modules to be integrated into the modular plant according to the user definition, wherein at least one said module is associated with a controller-agnostic configuration file specifying parameters for the said module that are not specific to any target system; and automatically binding controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the said module of the target system, the binding comprising automatically adapting the parameters to the target system according to the user definition. Thus, within the plant engineering, every instance of the virtual PEA / function module <NUM> is assigned to a specific target system, which is a new step in the engineering workflow. The actual binding to the target system is then performed in the final step, at the same time as the generation of the operations environment (steps <NUM>/<NUM>(c) in the plant engineering workflow <NUM>). This very late binding has the advantage that the virtual PEA / function module <NUM> is not bound to any target system and can be assigned to any supported target system. Additionally, multiple virtual PEAs / function modules <NUM> can be assigned to a single target system, which saves hardware costs.

<FIG> illustrates project execution <NUM> using the virtual PEA / function module <NUM>. The function modules <NUM> are first developed in the office <NUM> and "staged" in a virtual control environment <NUM>, which might involve simulation, emulators for target systems, or other debugging environments, and which may involve a Factory Acceptance Test (FAT) <NUM>. Modules are optionally developed using a module library <NUM> storing function modules (e.g. <NUM>, <NUM>, <NUM>) already engineered within other projects/plants and reusable within the plant under development. After their development, the function modules <NUM> are handed over to the yard <NUM>, where the necessary physical I/Os <NUM>, <NUM> are assigned to the function modules <NUM>. For example, I/O may be assigned at <NUM> using a DICED approach: I/O with automatic Detect, Interrogate, Configure, Enable, and Document. Until the assignment of physical I/Os, development may be undertaken in the virtual control environment <NUM>. Additionally, given that the function modules exist as pure software, the orchestration can be at least partially undertaken/prepared by way of a virtual orchestration <NUM> (as in <FIG>, plant engineering step <NUM>(b)). In the yard <NUM>, the function modules <NUM> are tested at <NUM> together with the physical I/Os <NUM>, <NUM> and everything is shipped on site, where the target system binding is ultimately performed using the plant control <NUM> / orchestration engineering <NUM> to bind the function modules <NUM> to a hardware controller <NUM> before they enter production at <NUM>. This workflow can be executed at <NUM> in a way in which the function modules are developed one by one and sequentially. However, it is also possible to have a high degree of parallelization that enables for fast project execution.

Function modules <NUM> can be discussed in conjunction with current standardization activities. One prominent example is OPAF. In OPAF, the function modules/virtual PEA can be seen as part of a distributed control node (DCN) that can be executed for a skid, package unit or other type of module. <FIG> illustrates at <NUM> the usage of function modules <NUM> of the kind described herein in the OPAF architecture. Within a DCN <NUM>, several function modules <NUM> can be executed, which might be used for the automation of several skids <NUM>, packaged units <NUM> or other types of modules <NUM> each comprising for example devices I/O <NUM>, I/O <NUM>, Process Automation Device Information Model (PA-DIM) <NUM>, and I/O if <NUM>. Within area <NUM>, the function modules <NUM> are shown and the connection to the physical instances is shown. The usage in OPAF would complement the usage of PEAs in OPAF. The skilled reader will be familiar with other elements appearing in <FIG> such as applications <NUM> comprising ERP <NUM>, quality <NUM> and other <NUM> forming e.g. part of Enterprise IT <NUM>; process operation <NUM> with applications <NUM> comprising produce <NUM>, maintain <NUM>, operate/HMI <NUM>, controls <NUM> comprising logic <NUM>, interlock and sequence <NUM>, data repositories <NUM> comprising MTP library <NUM>, information model <NUM>, and history <NUM>; skids <NUM>, package units <NUM> and other modules types <NUM> comprising PEA MTP <NUM>, I/O <NUM>, internal control <NUM>, services <NUM>, and data <NUM>. The various elements are brought together by the OPC UA - MTP information model <NUM>.

Developments made by the inventors include the virtualization of the PEA control application. Instead of having a hard binding between the PEA software and a specific target system, the virtual PEA contains all information necessary for a very late binding to the target system. Binding is done during plant engineering and the virtual PEA can be assigned to the needed target system. Same PEA types can be assigned to different target systems. It is possible to execute several virtual PEAs on the same controller. Developments made by the inventors can be summarized as follows:-.

From the above, it is clear that one or more computer programs, comprising machine-readable instructions, can be provided which when executed on one or more computers, cause the one or more computers to perform the automatically-performed steps of the described methods. Also, from the above it is clear that a non-transitory computer storage medium or computer program product, and/or a download product, can comprise the one or more computer programs. One or more computers can then operate with the one or more computer programs. One or more computers can then comprise the non-transitory computer storage medium/computer program product and/or the download product.

Claim 1:
A method of configuring a modular plant, the method comprising, in a plant engineering phase (<NUM>):
receiving a user definition for the modular plant as a target system, wherein the user definition identifies modules (<NUM>) to be integrated into the modular plant, defines a topology of the modular plant, and specifies sequences that can be executed by a process orchestration layer (<NUM>) of the modular plant, wherein at least one said module (<NUM>) is associated with a controller-agnostic configuration file (<NUM>) specifying parameters for the said module that are not specific to any target system; and
automatically binding controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the said module of the target system, the binding comprising automatically adapting the controller software to the target system according to the user definition, wherein an application (<NUM>) to be executed by the said module defines logic that is predetermined to be executable independently of state machines (<NUM>) defining the application, and wherein the parameters comprise one or more of (i default parameters for adaptation to the target system during the plant engineering or (ii static parameters that will remain unchanged during the plant engineering.