Modular device configuration

Abstract

The present invention provides a method for providing a control software configuration to a module of a modular device, the method comprising: automatically generating a control software configuration for the module based on a user definition, the control software configuration comprising specifying parameters for the module that are not specific to any target system, and providing the control software configuration as a controller-agnostic configuration file for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the module. A method for configuring a modular device is also provided, the method comprising: automatically binding controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the module of a target system, the binding comprising automatically adapting parameters to the target system based on the user definition. A data structure defining the control software configuration is also provided, the data structure being formatted as a controller-agnostic configuration file.

Description

Technical Field

[0001] The present invention relates to providing control software configuration for modules of a modular device in a module construction phase and configuring a modular device in a device construction phase. Background Art

[0002] Modular plants are an established aspect of Industry 4.0, providing benefits not only in terms of development costs, but also in terms of time and material effort. The overall layer of the modular plant structure consists of pre-manufactured and well-tested modules called PEAs (Process Equipment Assemblies) that can be easily assembled in different combinations to realize different target systems. PEAs usually have their own intelligence to provide all the functions required for safe decentralized operation. Data exchange between PEAs is achieved via standardized interface descriptions called Modular Type Packages (MTPs). The MTP approach creates a framework for interoperability between modules and orchestration systems, allowing process plants to be built and constructed in a more modular way, with the goal of simplifying process plant construction and lifecycle management. Summary of the invention

[0003] Despite the desire for modularity, the inventors have unexpectedly realized that device owners typically design, create and calibrate their own modules individually, often expending a lot of effort in the subsequent assembly of these modules in the entire device. These modules are then bound to a specific control system for automation of the module's internal functions. Due to automation vendor binding, it is almost impossible to reuse the software of the PEA. Each PEA typically has its own intelligence with the help of a controller and an embedded OPC UA server. The controller is used to automate process functions from the PEA and exposes the functionality using a service-oriented architecture and state-based control for monitoring systems. Binding the PEA to specific hardware and adding a controller for each PEA both result in high investment costs and vendor dependencies.

[0004] The inventors have recognised that it would be advantageous to address some or all of these issues.Accordingly, the present invention provides a method of providing control software configuration to modules of a modular device and a method of configuring a modular device, as well as a computer and a computer program product.

[0005] In a first aspect, a method for providing a control software configuration to a module of a modular device is provided, the method comprising: receiving a user definition for the module; and automatically generating a control software configuration for the module based on the user definition, the control software configuration comprising specifying parameters for the module that are not specific to any target system, and providing the control software configuration as a controller-agnostic configuration file so that when the module is integrated into the target system during the device building phase, controller software instantiated according to the controller-agnostic configuration file is subsequently bound to a hardware controller of the module.

[0006] In a second aspect, a method for configuring a modular device is provided, the method comprising, during a device building phase: receiving a user definition for the modular device as a target system, the definition identifying modules to be integrated into the modular device according to the user definition, wherein at least one of the modules is associated with a controller-agnostic configuration file, the controller-agnostic configuration file specifying parameters for the 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 module of the target system, the binding comprising automatically adapting the parameters to the target system according to the user definition.

[0007] "Controller agnostic" means that the configuration file has not been bound to a specific hardware controller on which the control software is to run, nor to a target system on which the hardware controller forms a part. Therefore, the configuration file and the control software configuration itself can be described as being agnostic / independent or extracted from the controller / hardware / module / target system (details). In other words, the control software configuration and the configuration file only include the general details of the controller / hardware / module / target system that can be applied to any such element and / or only include the details of the controller / hardware / module / target system of the category / type / type that will be displayed by any such element of a certain category / type / type. The control software configuration can also be referred to as an automated software configuration. In an example further described below, the control software configuration is provided by a virtual PEA / functional module, and the controller-agnostic configuration file is provided by a general MTP. Therefore, the control software configuration exists as a definition of the control software decoupled from the hardware controller on which the software will run, thereby promoting the reusability of the software, reducing or eliminating supplier dependence, and reducing development / investment costs.

[0008] Controller agnosticism can be provided in the following innovative ways: omitting controller specific parameters and / or controller specific logic functions from the configuration file, and / or providing default parameters and / or default logic functions in the configuration file for later adaptation to a specific controller / hardware / module / target system during device construction, and / or providing parameters and / or default logic functions that are static / constant because they apply to all controllers / hardware / modules / target systems (or all controllers / hardware / modules / target systems of a particular type), and therefore will remain unchanged during subsequent device construction despite the module being integrated into the target system. The parameters specify the state of a state machine that defines the application to be executed by the module. Thus, in one example, the parameters include one or more of the following: (i) default parameters for adaptation to the target system during device construction, or (ii) static parameters that will remain unchanged during device construction. Additionally or alternatively, the application definition to be executed by the module is predetermined to be executable independently of the state machine defining the application, in other words, the logic is executable independently of (the details of) the service and the state machine controlling the service, and therefore independently of the details of the target system.

[0009] In one example, the controller-agnostic configuration file also advantageously specifies one or more of the following for the 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, and (ix) one or more signal outputs.

[0010] In one example, binding further includes: matching input / output signals. Binding may include one or more of: (i) assigning another instance of controller software instantiated according to another such controller-agnostic configuration file to the same hardware controller of the module, and (ii) additionally assigning the controller software to a hardware controller of another module of the target system. This flexibility does not exist in existing systems where modules are inherently bound to specific control systems.

[0011] In an example of the first aspect, the method further comprises: simulating execution of the module in a virtual control environment for testing. The virtual control environment may include one or more of the following: (i) a soft controller of a specific target system, (ii) a software representation of the module, and (iii) a debugging function. The ability to perform such testing in a virtual environment and virtual device orchestration is facilitated by the controller-agnostic nature of the described control software configuration that has not been tied to any specific hardware controller.

[0012] In one example, the module includes a process equipment assembly (PEA). In one example, the PEA may form part of a distributed control node (DCN). In any of these examples or other examples, the controller-agnostic configuration file may include a modular type package (MTP) defining the PEA / DCN, for example, as a generic MTP.

[0013] In one example of the first aspect, the method further includes, in a workflow for project execution: testing a control software configuration as defined by a controller-agnostic configuration file; attaching an input / output configuration to the control software configuration at a modular device; testing the input / output configuration in conjunction with the control software configuration on a virtual controller; assigning a hardware controller to an instance of a software controller instantiated according to the controller-agnostic configuration file; adding physical input / output to the hardware controller and the software controller instance; and adding pre-tested supervisory control and / or orchestration for device control. Thus, the controller agnosticism described herein greatly facilitates project execution.

[0014] In a third aspect, a computer is provided, the computer comprising a processor configured to perform the method of any preceding aspect.

[0015] In a fourth aspect, a computer program product is provided, the computer program product comprising instructions which, when executed by a processor of a computer, cause the computer to perform the method of any one of the first and second aspects.

[0016] In a fifth aspect, a data structure is provided that defines a control software configuration for a module of a modular device, the control software configuration specifying parameters for the module that are not specific to any target system, the data structure being formatted as a controller-agnostic configuration file for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the module when the module is integrated into a target system during a device build phase. In one example, the virtual PEA / functional module described herein may be viewed as a data structure defining the described control software configuration for a module of a modular device. The data structure may include all and any aspects and elements of the control software configuration embodied as the virtual PEA / functional module described herein. In this regard, the data structure provides functional data for controlling the operation of the module that processes data, and therefore inherently includes the corresponding technical features of the module.

[0017] Further aspects and examples of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Exemplary embodiments are described below with reference to the following drawings.

[0019] Figure 1 A diagram illustrating the construction workflow for a modular installation;

[0020] Figure 2A and Figure 2B Diagram showing the construction workflow of module types;

[0021] Figure 3A and Figure 3B The device construction workflow is illustrated;

[0022] Figure 4 The diagram shows the HMI definition in the module type construction workflow;

[0023] Figure 5 Diagram showing the tag definition in the module type construction workflow;

[0024] Figure 6 Diagram showing the service definition in the module type construction workflow;

[0025] Figure 7 Diagram showing the state definition in the module type construction workflow;

[0026] Figure 8 The topology definition in the device construction workflow is illustrated;

[0027] Fig. 9 The contents of the virtual PEA / functional module are illustrated;

[0028] Fig.10 The diagram illustrates the construction workflow performed using virtual PEA / functional modules;

[0029] Fig.11 Illustrate the project execution using virtual PEA / functional modules;

[0030] Fig.12 The diagram illustrates the use of functional modules in the OPAF architecture. DETAILED DESCRIPTION

[0031] As shown, a modular device can be built. The build workflow 100 is divided into two parts: a (project-independent) module type build workflow 108 and a (project-dependent) device build workflow 110. The module type build workflow 108 can be undertaken by the module supplier or by the owner of the modular device. The device build workflow 110 can be undertaken by the device owner.

[0032] Within the module type build workflow 108, all builds of the module type / PEA 102 are completed, meaning: instrumentation manufacturing, electrical manufacturing, control manufacturing; physical connection of process equipment within; selection of I / O marshaling and controller hardware; factory acceptance testing. The module type 102 is ready for use within the device after its creation at 112, as it provides its own intelligence and an OPC UA server interface that can be used to control it. The interface of each module type 102 is described by generating an MTP 106 at 114, for example according to IEC63280ED1 ACD. Each module type 102 uses services to expose its internal functionality to the supervisory control system as services. A service-oriented architecture can be used. Behind each service, the defined state machine is executed and the state is exposed.

[0033] The MTP 106 is later used in the second part (plant building workflow 110), where the MTP 106 of the module type 102 is imported 116 and an instance is created for the module type 102 before integration into the plant automation at 118. The decentralized automation of the different module types 102 is integrated in the process orchestration layer (POL) 104.

[0034] Figure 2A and Figure 2B The module type building workflow 108 is illustrated in more detail. To build a module type 102, first, at 201, a human machine interface (HMI) of the module type is defined, which may be similar to the construction of, for example, a piping and instrumentation diagram. At 202, a tag list is automatically derived from the HMI. The tag list contains all tags used within the automation system. In the tag list, the user can change the parameters of the tag. Both the tag type and the parameters may conform to IEC 63280ED1 ACD. In a third step 203, the services of the module type 102 are defined. This starts with adding services and additionally adding the necessary service parameters that should be exposed to the supervisory control system at 203a. The service parameters may be, for example, an "amount" for the service "fill", which is used to tell the "fill" service how much should be filled into the module. After the services are defined, the states of the underlying state machine are filled with logic at 203b, 203c. This logic definition is still not bound to the target system, but is later used in steps 204a and 204b to create target system specific information. In step 204a, target system specific information is created and can be used for the automation of module type 102. Now, this is bound to the target system and the target system cannot be exchanged later during the device construction. In step 204b, a target system specific MTP 106 describing the interface of module type 102 is created.

[0035] Figure 3A and Figure 3BThe plant construction workflow 110 is illustrated in more detail. The plant construction workflow 110 also follows a four-step approach, where in a first step 301, all module types 102 required in the plant are added to the module library. After adding the module types 102 defined by their MTPs 106, these module types can be used at 302 to create the topology of the modular plant by creating module instances in the construction tool and connecting them with the help of material and information flows. At 303, the module instances can be used to define sequences that can be executed by the supervisory control system POL 104 based on their services. The supervisory control system 104 is created in the last step 304 based on the information from the construction tool.

[0036] Figure 4 An HMI definition 400 for a module type 102 is illustrated corresponding to step 201 of the module type building workflow 108. An HMI editor 404 assists the user in defining the HMI in conjunction with a symbol library 402 and a property editor 406. A device list 410 is automatically generated and the structure 408 of the module visualization is described.

[0037] Figure 5 The tag definition 500 (building of a tag list) in the module type building workflow 108 corresponding to step 202 is illustrated. The tag editor 502 generates a tag list 506 from the HMI and presents properties 508 according to relevant standards, allowing the user to set property values ​​at 504 .

[0038] Figure 6 A service definition 600 of a module type including definitions of services and service parameters is illustrated corresponding to steps 203a and 203b of the module type building workflow 108. A user can define a state machine for a service at 604, select from a list of available services 606, and can set service parameters using a service parameter editor 604.

[0039] Figure 7 The state definition 700 for the states of the service state machine of module type 102 is illustrated for step 203c of the module type-based workflow 108. The state editor 702 allows the user to select from various defined states 710, define actions 712 when entering or leaving a state, specify reasons 714, parameters 718 as reasons, trip points 716 and interlock logic 708 for each state, and results 704, transitions 706 as results, and result commands 720.

[0040] Figure 8A topology definition 800 of a modular device according to step 302 of the device building workflow 110 is illustrated, wherein a user may use a property editor 802 and a topology editor 804 to work on a previously defined module type library 806 to define a building structure 808 .

[0041] Fig. 9 The contents of a virtual PEA / function module 900 are shown. The inventors developed the virtual PEA / function module 900 as a software description of a module type 102. In summary, the virtual PEA / function module 900 serves as a control software configuration for a module 102 of a modular device, which specifies parameters of the module that are not specific to any target system, such as default parameters. The virtual PEA / function module 900 used as a control software configuration is provided as a controller-agnostic configuration file (in other words, a configuration file that is independent of the target system, in one example, the generic MTP 106) for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to the hardware controller of the module when the module is integrated into the target system during device construction.

[0042] More specifically, instead of being bound to a specific target system, the virtual PEA / functional module 900 contains only a description of the functions that the target system should contain. Fig. 9 In addition to the information of the logic executed in the application 914 in the virtual PEA / functional module 900, the virtual PEA / functional module 900 can also contain the same information as the module type 102 described above. The application 914 includes the state executed in the overall state machine. Only the state machine is visible externally. As for the module type 102 described above, the state is defined as an extended cause-effect matrix. The application 914 optionally also includes logic that is predetermined to be executable independently of the state machine. In an example of equipment protection, for example, if the valve is closed, all subsequent pumps must be stopped to prevent them from running dry. Other examples of logic that are predetermined to be executable independently of the state machine include: opening the release valve in response to the pressure in the container becoming too high, and opening the release valve to open in response to the pressure in the gas pipeline being too high. This type of logic must always be executed independently of the state machine (details) of the service and the control service. Other such examples are obvious to the technician and are covered by the present disclosure, and it should not be regarded as limited to any one such example. Because the application 914 that should be executed in the state has not been bound to any target system, this enables the virtual PEA / functional module 900 to be ported to different types of target systems. Parameters may also specify communications to the target module 102 .

[0043] For each control device (sensor, valve, etc.) used in a module, a set of parameters is defined. There may be different kinds of parameters for a module that are not specific to any target system, as in the non-limiting examples below. Other such examples will be apparent to the skilled person and are encompassed by the present disclosure, which should not be considered limited to any one such example.

[0044] For example, a sensor has a range, which means that it can measure 1 bar…10 bar. These parameters depend on the hardware that is ultimately used, and the sensor cannot measure outside its measurement range. When the target system and device are assigned later (during the construction of the device), those parameters are set once and remain unchanged. When different sensor types are used in different instances of the function module to measure pressure, the parameters are adjusted later (for example, during the construction of the device) when the target hardware and device are assigned to the function module instance (as an instance of the software controller instantiated according to a controller-agnostic configuration file). The block that controls the sensor can specify limits. Limits are software-defined numbers that must be within the measurement range. If the measured value exceeds / falls below the defined limits, the measured value is used to issue an alarm. These limits can be parameterized anywhere in the application. In a non-limiting example, in order to provide parameters that are not specific to any target system, default limits can be set and changed later when necessary. Typically, during startup, the limits are set wider to avoid alarm flooding, and once the module is running in a stable state, the limits are narrowed to keep the process in optimal operation.

[0045] A service may have parameters that configure how it should be performed, e.g., whether the process value is measured inside the module or comes from somewhere else. The configuration parameters may show which source is used. In one non-limiting example of a parameter that is not specific to any target system, a default source may be specified to provide a defined state for the case where no other parameterization is performed. Alternatively, the parameter may be forgotten during tuning. In another non-limiting example, a default service parameter may be given for a setpoint, e.g., a fill service should fill a container to 50%.

[0046] All of the parameter types described above are typically exposed by the module's OPC UA server as OPC UA variables. Since the OPC UA server does not exist in the virtual PEA / function module 900 and is only added to the function module instance later, the engineer can set default values ​​for the parameters. These can (i) be changed later during device construction, (ii) be provided by the actual OPC UA server of the assigned target system, or (iii) be set for each state of the state machine or for each service or module scope (i.e. only one parameter value is given for all operating states).

[0047] like Fig. 9 As shown, a virtual PEA / functional module 900 provided as a controller-agnostic configuration file, for example in the form of a generic MTP 106, specifies one or more of the following for a target module 102: (i) one or more parameters 906, (ii) one or more variables 908, (iii) one or more views 910, (iv) one or more state machines 912, (v) one or more applications 914, (vi) one or more events 916, (vii) one or more methods 904, (viii) one or more signal references 902, and (ix) one or more signal outputs 918.

[0048] Therefore, the virtual PEA / function module 900 provides automation of a PEA without an embedded controller and an OPC UA server. The automation of the virtual PEA / function module 900 can be performed in a central control system or a distributed control system, and several virtual PEA / function modules 900 can be on one controller. The virtual PEA / function module 900 decouples the control application software from the controller and input / output hardware of the PEA. Instead of binding the control application software to the hardware as a controller, the input and output hardware design can be performed in a later step. The software description can be exported as a virtual PEA / function module 900 to a controller-agnostic (in other words, hardware-independent) MTP 106. During device construction, the virtual PEA / function module 900 can then be assigned to the controller, and the input signal / output signal can be matched. Therefore, several virtual PEA / function modules 900 can also be assigned to a single controller and the virtual PEA / function module 900 can be reused later with another supplier or target system.

[0049] Fig.10 The build workflow 100 is illustrated as being performed using the functional module 900. In this example, the functional module build workflow 1004 is performed by the device build tool 1002. The interface between the functional module build workflow 1004 and the device build tool 1002 may be provided by the controller agnostic MTP 106 of the functional module 900.

[0050] The functional module building workflow 1004 using the virtual PEA / functional module 900 is the same as the module type building workflow 108 described above, except that step 204a of the module type building workflow 108 is not performed, and further that step 204b (taking into account that the target system is unknown and not generating a target system specific MTP) includes generating an MTP 106 without target system specific information. This generic MTP 106 is then used to describe the functional module. The MTP 106 can be XML based. In Fig.10, step (a) of the functional module building workflow 1004 corresponds to steps 201 to 203 of the module type building workflow 108. Step 1004(b) corresponds to step 204b, except that the generic MTP 106 is generated. Step 204b / 1004(b) can be performed by a computer. In summary, the functional module building workflow 1004 relates to a method for providing a control software configuration of a module of a modular device, the method comprising: receiving a user definition of the module; and automatically generating (1004(b)) a control software configuration (e.g., a virtual PEA / functional module 900) of the module based on the user definition, the control software configuration including parameters that specify the 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 106) for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the module when the module is integrated into a target system during the device building phase.

[0051] As described above, a device building workflow 1006 using the function module 900 is performed, except that step 304 is also performed in connection with the instance of the function module 900 used inside the modular device. Step 1006 (a) includes: adding a function module instance to the device (as an instance of a software controller instantiated according to a corresponding controller-agnostic configuration file). Through parameter loops, the parameters are adapted to the needs of the device as described above. The result is a topology of function module instances (still pure software), which shows how these instances are physically connected and how the instance parameters are adapted to the needs of the device. In step 1006 (b), a recipe is created, which shows which service of which module is to be executed, stopped, paused, etc. when. The engineer can define the arrangement of function module instances in sequence, which function module instances can later be executed in the device automation system. In step 1006 (c), the (hardware) controller that executes the function module instance is selected. Function module instances can be executed on separate controllers of different types (even different manufacturers), or multiple function module instances can be executed on the same controller. The control software configuration of a particular functional module instance is automatically downloaded or exported to the selected controller. Once the controller is assigned, the controller-specific parameters required for the particular control system are automatically added to the corresponding functional module instance. In addition, process devices are assigned to sensors and devices defined in the functional module instance. For example, here, physical sensors such as laser level transmitters are assigned to planned items from the functional module instance. Additionally, device-specific parameters are automatically adjusted according to their default settings (e.g., measurement ranges as described above). In summary, the device construction workflow 1006 relates to a method for configuring a modular device, the method comprising: receiving a user definition of a modular device as a target system, the definition identifying modules to be integrated into the modular device according to the user definition, wherein at least one of the modules is associated with a controller-agnostic configuration file, the controller-agnostic configuration file specifying parameters of the module that are not specific to any target system; and automatically binding the controller software instantiated according to the controller-agnostic configuration file to the hardware controller of the module of the target system, the binding comprising automatically adapting the parameters to the target system according to the user definition. Thus, within the device build, each instance of a virtual PEA / functional module 900 is assigned to a specific target system, which is a new step in the build workflow. The actual binding to the target system is then performed in a final step, concurrently with generating the operating environment (step 304 / 1006(c) in the device build workflow 110). This very late binding has the advantage that a virtual PEA / functional module 900 is not bound to any target system and can be assigned to any supported target system. Additionally, multiple virtual PEA / functional modules 900 can be assigned to a single target system, saving hardware costs.

[0052] Fig.11 Project execution 1100 using virtual PEA / functional modules 900 is illustrated. Functional modules 1108 are first developed in office 1102 and "staged" in virtual control environment 1106, which may involve simulation, emulator of target system or other debugging environment, and may involve factory acceptance test (FAT) 1110. Modules are optionally developed using module library 1130 storing functional modules (e.g., 1132, 1134, 1136) that have been built in other projects / devices and can be reused in the device being developed. After they are developed, functional modules 1108 are handed over to site 1112 where necessary physical I / O 1116, 1117 are assigned to functional modules 1108. For example, I / O can be assigned at 1114 using DICED approach: I / O with automatic detection, query, configuration, enabling and recording. Development can be done in virtual control environment 1106 before physical I / O is assigned. Additionally, assuming that the functional module exists as pure software, with the help of virtual orchestration 1104 (such as Fig.10 As shown, device build step 1006 (b)), the orchestration may be at least partially performed / prepared. In site 1112, the functional modules 1108 are tested at 1118 along with physical I / O 1116, 1117 and everything is shipped on site, where target system binding is ultimately performed using device control 1124 / orchestration build 1122 to bind the functional modules 1108 to the hardware controller 1120 before they go into production at 1126. This workflow can be performed in a sequential development of functional modules one by one at 1128. However, a high degree of parallelization can also be achieved, thereby achieving rapid project execution.

[0053] Functional module 900 may be discussed in connection with current standardization activities. One prominent example is OPAF. In OPAF, the functional module / virtual PEA may be considered as a part of a distributed control node (DCN), which may be implemented for a skid, package unit, or other type of module. Fig.12The use of functional modules 1244 of the type described herein in the OPAF architecture is illustrated at 1200. Within the DCN 1242, several functional modules 1244 may be executed that may be used for automation of several sleds 1274, packaged units 1284, or other types of modules 1286, each of which includes, for example, device I / O 1276, I / O 1278, process automation device information model (PA-DIM) 1280, and I / O conditions 1282 (IO if 1282). Within area 1288, the functional modules 1244 are shown and connections to physical instances are shown. The use in OPAF may complement the use of PEA in OPAF. Readers in the art will be familiar with Fig.12 1230, which forms part of, for example, enterprise IT 1230; process operations 1204 with applications 1206 including production 1212, maintenance 1214, operations / HMI 1216, controls 1208 including logic 1218, interlocks and sequences 1220, and data repositories 1210 including MTP libraries 1222, information models 1224, and history 1226; skids 1258, packaging units 1270, and other module types 1272 including PEA MTP 1260, I / O 1262, internal controls 1264, services 1266, and data 1268. The various elements are brought together by the OPC UA-MTP information model 1256.

[0054] Developments made by the inventors include virtualization of PEA control applications. Instead of having a hard binding between the PEA software and a specific target system, the virtual PEA contains all the information needed to bind to the target system very late. The binding is done during device construction and the virtual PEA can be assigned to the desired target system. The same PEA type can be assigned to different target systems. Multiple virtual PEAs can be executed on the same controller. The developments made by the inventors can be summarized as follows:

[0055] 1. Concept of virtual PEA / functional module:

[0056] o Virtual definition of PEA, which is described as target system independent MTP.

[0057] oInformation of virtual PEA, including parameters, variables, views, state machines, applications, events, methods, signal references, and signal outputs.

[0058] 2. Concept of executing virtual PEA in a virtual control environment for testing:

[0059] oThe virtual control environment may be a soft controller for a specific target system.

[0060] oThe virtual control environment may be a software representation of the PEA.

[0061] oThe virtual control environment may be of another type (e.g., debugging functionality).

[0062] 3. The concept of subsequently binding the virtual PEA to the target system:

[0063] oBinding during installation / choreography construction.

[0064] oAssign several virtual PEAs on a single controller.

[0065] o Assign the same instance of the virtual PEA to different control system hardware (e.g. AC800M and AC500).

[0066] oAssign input and output signals to the virtual PEA.

[0067] 4. Workflow of executing the project using virtual PEA / functional modules:

[0068] oStep 1: Build a virtual PEA in a virtual environment.

[0069] oStep 2: Test the virtual PEA.

[0070] oStep 3: Attach the required I / O (PA-DIM) to the virtual PEA instance at the venue.

[0071] oStep 4: Test the I / O configuration in conjunction with the virtual PEA on the virtual controller.

[0072] oStep 5: Assign the controller to the virtual PEA instance.

[0073] oStep 6: Add physical I / O to the controller and virtual PEA instance.

[0074] oStep 7: Add pre-tested supervisory controls / orchestration for device control.

[0075] As can be clearly seen from the above, one or more computer programs including machine-readable instructions can be provided, which, when executed on one or more computers, cause the one or more computers to perform the steps of automatically executing the method. In addition, as can be clearly seen from the above, a non-transient computer storage medium or a computer program product and / or a download product can include one or more computer programs. One or more computers can then operate using the one or more computer programs. Then, one or more computers can include a non-transient computer storage medium / computer program product and / or a download product.

[0076] Although the present invention has been described and illustrated in detail in the drawings and the foregoing description, such description and illustration are to be considered illustrative or exemplary rather than restrictive. The present invention is not limited to the disclosed embodiments. Other variations of the disclosed embodiments may be understood and implemented by those skilled in the art in practicing the claimed invention by studying the drawings and the disclosure.

Claims

1. A method of providing a control software configuration to a module of a modular device, the method comprising, in a module building phase: receiving a user definition for the module, wherein the user definition comprises one or more of an HMI definition, a tag definition, a service definition, a parameter definition, a state machine definition, and an internal state definition; and The control software configuration for the module is automatically generated based on the user definition, the control software configuration including specifying parameters for the module that are not specific to any target system, and providing the control software configuration as a controller-agnostic configuration file for subsequent binding of controller software instantiated according to the controller-agnostic configuration file to a hardware controller of the module when the module is integrated into the target system during a device build phase, wherein an application definition to be executed by the module is predetermined to be executable logic independent of a state machine defining the application, and wherein the parameters include one or more of: (i) default parameters for adaptation to the target system during the device build, or (ii) static parameters that are to remain unchanged during the device build.

2. The method according to claim 1, further comprising, 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 said control software configuration at said modular device; testing the input / output configuration in conjunction with the control software configuration on the virtual controller; assigning a hardware controller to an instance of a software controller instantiated according to the controller-agnostic configuration file; adding physical input / output to the hardware controller and the software controller instances; and Add pre-tested supervisory controls and / or orchestration for device control.

3. A method of configuring a modular device, the method comprising, during a device construction phase: receiving a user definition for the modular device as a target system, wherein the user definition identifies modules to be integrated into the modular device, defines a topology for the modular device, and specifies sequences executable by an orchestration layer of the modular device, wherein at least one of the modules is associated with a controller-agnostic configuration file, the controller-agnostic configuration file specifying parameters for the 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 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 definition to be executed by the module is predetermined to be executable logic independent of a state machine defining the application, and wherein the parameters comprise one or more of: (i) default parameters for adaptation to the target system during construction of the device, or (ii) static parameters that are to remain unchanged during construction of the device.

4. A method according to claim 1 or 3, wherein the logic predetermined to be executable independently of the state machine defining the application includes one of the following: (i) for equipment protection, if the valve is closed, all subsequent pumps will stop; (ii) opening the release valve in response to the pressure in the container becoming too high; (iii) opening the release valve to open in response to the pressure in the gas pipeline being too high.

5. The method of claim 1 or 3, wherein the controller-agnostic configuration file further specifies one or more of the following for the 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.

6. The method according to claim 3, wherein the binding further comprises: Match input signal / output signal.

7. A method according to claim 3 or 6, wherein the binding also includes one or more of the following: (i) assigning another instance of the controller software instantiated according to another such controller-agnostic configuration file to the same hardware controller of the module, and (ii) additionally assigning the controller software to a hardware controller of another module of the target system.

8. The method according to claim 1 or 3, further comprising: The execution of the modules is simulated in a virtual control environment for testing.

9. The method of claim 8, wherein the virtual control environment comprises one or more of the following: (i) a soft controller of a specific target system, (ii) a software representation of the module, (iii) a debugging function.

10. The method of claim 1 or 3, wherein the module comprises a process equipment component or a distributed control node.

11. The method of claim 10, wherein the controller-agnostic configuration file comprises a modular type package defining the process equipment component or distributed control node.

12. A computer comprising a processor configured to perform a method according to any one of the preceding claims.

13. 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 according to any one of claims 1 to 11.

Images