Computer-implemented method for configuring at least one device of system

Abstract

The invention relates to a computer-implemented method (100) for configuring at least one device (50) of a system (90), comprising the steps of:-providing (102) first data (10) of the at least one device (50) relating to device-specific data of the at least one device (50); -generating (104), based on the first data (10), at least a first maintenance job (15) describing a change request requirement applied to the at least one device (50); creating (106) at least a first approval ticket (17) on the basis of the generated first verification check process (18) of the first maintenance work (15) of the at least one device (50); -processing (112) the at least first maintenance work (25) with the at least first approval ticket (17) to perform the configuration of the at least one device (50).

Description

Technical Field

[0001] The present invention relates to a computer-implemented method for configuring at least one device of a system. Background Art

[0002] Process plants use multiple (field) devices, such as temperature or pressure sensors, valves, etc., to collect information from the physical process and regulate (actuate) it. Such devices are relatively complex, allowing the configuration of dozens to hundreds of parameters and the upgrading of the internal firmware that provides these parameters and interprets them.

[0003] Changes to device parameters and their firmware may lead to unpredictable consequences within the physical plant and therefore need to be treated with the same sensitivity as changes in a distributed control system (DCS), such as changes to the parameters of a PID control loop. For example, US Pat. No. 8,239,498 B2 describes a system and method for facilitating changes to resource configurations within an enterprise.

[0004] However, such (field) devices offer many different access possibilities. These range from fieldbus connections to the DCS, to dedicated hardware or Bluetooth-accessible parameterization interfaces, to embedded web servers or push buttons on the device. All of these access interfaces are difficult to secure and maintain, and in practice are often uncontrolled.

[0005] These issues need to be addressed. Summary of the Invention

[0006] It would therefore be advantageous to provide an improved solution for configuring and maintaining at least one device of a system in an efficient, safe and automated manner.

[0007] The objects of the invention are solved by the subject-matter of the independent claims, wherein further embodiments are incorporated in the dependent claims.

[0008] In a first aspect of the present invention, there is provided a computer-implemented method for configuring at least one device of a system, comprising the steps of:

[0009] - providing first data of the at least one device associated with device-specific data of the at least one device;

[0010] - generating, based on said first data, at least a first maintenance task describing requirements of the change request to be applied to said at least one device;

[0011] - creating at least a first authorization ticket based on the generated first verification check process of the first maintenance work of the at least one device;

[0012] - processing said at least first maintenance work using said at least first authorization ticket to perform configuration of said at least one device.

[0013] In other words, the core concept behind the present invention is to update the configuration of a system, which may include maintaining and / or updating at least one device in the system. This configuration can be performed automatically and efficiently, saving valuable resources during the entire configuration process for the devices connected to the system. Updating, within the meaning of the present invention, can mean updating the software, such as firmware, of the devices in the industrial system. Furthermore, updating system components produces effects in the physical plant associated with the configured devices.

[0014] These devices can be field devices or any other type of device. A system of such devices can be industrial equipment, where a physical process needs to be controlled by the devices, which need to be configured in the manner described in accordance with the present invention. The system can also be, for example, a production system in the manufacturing or process industry.

[0015] The invention also allows solving the following problems, which typically arise with the configuration of devices in a system, and which are listed as just a few examples:

[0016] Changing device configuration via covert channels (e.g., display or Bluetooth) without the DCS being aware of it.

[0017] Over time, the system itself degraded from its planned state and an undocumented system state emerged.

[0018] The worst case scenario is the exchange of the entire device, e.g. due to an emergency, which is never reflected in the factory documentation which could invalidate the factory certification.

[0019] Intended changes are not controlled a priori in an automated manner; the plant owner / operator manages the process without the field devices / DCS being aware of the potential for unsafe / unintended configurations of field devices.

[0020] The same applies to device firmware updates that may change the meaning of certain device parameters and thus invalidate the device under test configuration resulting in an invalid system state.

[0021] As a first important aspect of the present invention and to overcome the aforementioned problems and challenges, the present invention utilizes a so-called Verification of Request (VoR) type implementation or mechanism for device and / or DCS configuration. Such an implementation provides a set of rules to audit and verify changes, such as write access to the contents of a control system, which can be implemented as a Core Process Control (CPC) domain. For the definition of CPC and VoR domains, reference can be made to prior art publications surrounding the "NAMUR Open Architecture," for example: https: / / www.namur.net / en / focus-topics / namur-open-architecture.html.

[0022] As a second important aspect of the present invention, a so-called "ticket-based" system is used that operates and uses cryptographically signed "change authorization tickets" to complete "change requests" to devices to be configured in the system. Change requests include, but are not limited to, changing certain parameters of a specific device, invoking methods on a device, updating device firmware, or applying parameter changes in general.

[0023] The change request itself may originate from a (possibly cloud-based) application, such as a maintenance application that maintains an inventory of installed / available devices in an organizational unit (e.g. a site, a factory, a factory section, a production line) and also connects to external systems (e.g. a component supplier's IT system) to obtain the latest available device information including their firmware update options.

[0024] The ticket to complete the change request is issued by the VoR component and is enforced / confirmed or fulfilled by the field device management software or even the (field) device itself.

[0025] An authorization ticket, or more generally, a ticket, describes an approved change in a specific device of the system, such as a firmware update or a parameter change.

[0026] Furthermore, the present invention allows linking the ticket creation process to enterprise systems such as MES or ERP / SAP via MoM / IOM, allowing for its gradual refinement towards execution. An example is linking a change ticket to other system parameters, such as at a specific point in time during an allowed maintenance window, or generalizing a ticket to a group of devices, such as a mass update of firmware for sensors of the same type.

[0027] Therefore, the present invention has the following advantages:

[0028] Seamless integration of verification of request mechanisms from the owner / operator perspective: changes to automation software (e.g., setpoints of control loops) and equipment parameters (e.g., alarm ranges) must go through the same process with regard to ordinary VoR mechanisms.

[0029] Improves engineering efficiency and eliminates possible human errors when configuring equipment in factory systems.

[0030] Enables autonomous systems to automatically apply corrections to devices in a secure and confidential manner when problems are detected.

[0031] Compatibility with different existing VoR concepts allows for broad customer acceptance.

[0032] Opportunity to add additional features to the change application process and traceability for devices from different customers or manufacturers.

[0033] According to one example, the method comprises the step of improving the first maintenance work after generating the first approval ticket by:

[0034] - generating a second maintenance task by adding second data to the second maintenance task based on the generated first maintenance task;

[0035] - Creating a second authorization ticket based on the generated second verification check process of the second maintenance work of the at least one device. In this way, the first maintenance work is improved and elaborated in an efficient manner to obtain a second improved maintenance work.

[0036] According to an example, the first data includes at least one of the following: multiple devices of the system, static information and / or dynamic information of the at least one device. In this way, the configuration of the system can be completed in an efficient manner that is easy to adapt to changing application scenarios.

[0037] According to one example, the second data include further device-specific data specifying the second (improved) maintenance work. In this way, the second (improved) maintenance work can be enriched with useful data that contributes to improving the replacement process of the at least one device.

[0038] According to an example, the first data and / or the second data are at least partially obtained by an external data provider. In this way, the change process of the device can be performed in a more detailed and efficient manner taking into account the changing application scenarios within the system.

[0039] According to an example, the first maintenance work is started by a user command and / or automatically. In this way, the operation of the device change or configuration process can be flexibly performed according to the changed application scenario.

[0040] According to one example, a first maintenance task is generated at a first system level of the system, and a second maintenance task is generated at a second system level of the system. In this way, the separation of different change or configuration process steps can be achieved at different granularities depending on the system on which the configuration process is implemented or executed.

[0041] According to one example, the first verification check process includes a digital signature of the first authorization ticket, which indicates whether the configuration of the at least one device is permitted. In this way, the security requirements of the system are effectively implemented.

[0042] According to one example, the second verification check process includes at least one of the following checks: a security standard check of at least one device, and a check of at least one device-related setting and / or parameter of at least one device. In this way, the security requirements of the system are effectively implemented to ensure a specified security level for the system or configuration processes performed within the system.

[0043] According to one example, the results of the first and / or second verification check procedures are at least partially stored in the corresponding authorization ticket. In this way, approved security settings can be effectively provided / implemented for processing the configuration process of at least one device.

[0044] According to one example, the at least one authorization ticket comprises a cryptographic signature of the corresponding maintenance work. In this way, a predetermined security standard for the maintenance work is ensured.

[0045] According to an example, the at least one device is a field device of the system and / or a device of a specific category. In this way, an efficient configuration process is allowed to be performed on at least one device or a plurality of specific devices in the system.

[0046] In a second aspect of the invention, a computer system is provided, which is configured to perform a computer-implemented method for configuring at least one device of a system according to any of the preceding examples and / or according to the first aspect.

[0047] In a third aspect of the invention, there is provided a computer comprising a processor configured to perform the method according to the first aspect and / or according to any of the preceding examples.

[0048] In a fourth aspect of the present invention, there is provided a computer program product comprising instructions which, when the computer program is executed by a processor of a computer, cause the computer to control the method of the first aspect.

[0049] In a fifth aspect, there is provided a machine-readable data medium and / or a download product comprising the computer program according to the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Exemplary embodiments will be described below with reference to the accompanying drawings.

[0051] The following are attached:.

[0052] Figure 1 A schematic flow chart of the method of the present invention is shown;

[0053] Figure 2 A schematic flow chart illustrating a method according to an embodiment of the present invention is shown; and

[0054] Figure 3 A computer system for configuring at least one device of a system according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0055] Figure 1 A schematic flow chart of a method 100 for configuring at least one device 50 of the system 90 of the present invention is shown. Configuration in the sense of the present invention may mean changing at least one parameter of a device 50, updating the software of said device 50, or replacing a device 50 according to a changed application scenario.

[0056] In the context of the present invention, the at least one device 50 may be a (field) device of a system 90 having a plurality of devices 50 and / or a specific category of devices 50 .

[0057] In a first step 102 , first data 10 of at least one device 50 are provided, which are associated with device-specific data of the at least one device 50 .

[0058] Optionally, the first data 10 includes at least one of the following: multiple devices 50 of the system 90 , static information 11 and / or dynamic information 12 of at least one device 50 .

[0059] The static information 11 may be, for example, device location, device type, serial number, firmware version, etc. The static information 11 may be delivered via the (I) system or otherwise include a digital inventory of the device.

[0060] The dynamic information 12 of at least one device 50 may be, for example, information providing the current state or status of the device 50, which allows for continuous monitoring of the device status. The dynamic information 12 may be delivered via (i) a system or otherwise comprising a digital inventory of the device. In this context, it should be noted that in examples of the present invention, reading data (such as serial numbers, etc.) from field devices does not need to be complete.

[0061] In a second step 104 , at least one or at least a first maintenance task 15 is generated based on the first data 10 , describing the change request requirements to be applied to the at least one device 50 .

[0062] Optionally, the first maintenance job 15 is initiated by a user command, eg via an app or web interface, and / or automatically, the VoR mechanism allowing / limiting the user's permission to initiate changes on at least one device 50 of the system 90 .

[0063] In a third step 106 , at least one first authorization ticket 17 is created based on the generated first VoR verification check process 18 of the first maintenance work 15 of the at least one device 50 .

[0064] Optionally, the first authentication check process 18 includes a digital signature of the first authorization ticket 17, which indicates whether permission to configure the at least one device 50 is allowed. The digital signature of the first authorization ticket 17 means whether a specific entity is allowed to initiate changes on a specific site of the system 90 or device 50. Authentication in the sense of the present invention may also include the term "verification".

[0065] In an optional fourth step 108, an improvement of the first maintenance work 15 after the step of generating 106 the first authorization ticket 17 can be performed by the following sub-steps:

[0066] - generating 109 a second (improved) maintenance work 25 based on the generated first maintenance work 15 by adding the second data 20 to the second maintenance work 25;

[0067] - creating 110 a second authorization ticket 27 based on the generated second verification check process 28 of the second maintenance work 25 of the at least one device 50 .

[0068] In such an optional scenario, when performing the step of improving at least the first maintenance work 15 to obtain the second maintenance work 25 , the step of processing 112 includes processing the second maintenance work 25 with the second authorization ticket 27 to perform configuration of the at least one device 50 .

[0069] In this way, the first maintenance work 15 is improved and refined. In another example, according to a certain application scenario, if necessary, the improvement of the first maintenance work 15 can be performed multiple times to improve or refine the second maintenance work 25 at different times. This means that the improvement can be performed multiple times. Figure 2 Step 109 in the process is used to obtain a final second (improved) maintenance job 25 that meets certain requirements or standards. Figure 2 This alternative is described.

[0070] However, step 108 may be omitted, and the method may be performed using only the generated first maintenance work 15 (step 104 ) and its corresponding first approval ticket 17 (step 106 ) without further refinement of the generated first maintenance work 15 .

[0071] The second maintenance work 25 may include information such as a device identification, a technical device location (e.g., an OPC UA endpoint), an action (e.g., a firmware update or parameter change), supplemental data (e.g., a byte stream representing a new firmware binary, or a set of parameter values to be applied to the device 50) based at least in part on the second data 20.

[0072] Optionally, the second data 20 also include device-specific data specifying a second maintenance work 25 .

[0073] The second data 20 may comprise information mapping, for example, an abstract device identification (serial number) to a technical device location (eg an IP / hostname of an OPC UA endpoint, or an I / O interface location of a HART interface of a device).

[0074] Furthermore, additional deployment-related adjustments can be made to the work, such as detailing changed time frames based on scheduling information, such as maintenance window information obtained from an MES / ERP system like SAP.

[0075] In step 110 , a second authorization ticket 27 is created based on the generated second verification check process 28 of the second maintenance work 25 of the at least one device 50 .

[0076] Optionally, the second verification check process 28 includes at least one of the following checks: a security standard check of at least one device 50 , and a check of at least one device-related setting and / or parameter of at least one device 50 .

[0077] In this way, a cross-check is performed by the VoR component whether the second maintenance work 25 matches all safety standards of the specific plant system 90 .

[0078] Examples of rule-based VoR checks may include:

[0079] - Check if the parameters are within the correct range,

[0080] - Check if the device is allowed to be put into "maintenance" mode to perform updates,

[0081] - Check if the firmware version is "approved" by the site or enterprise (here we assume that the owner / operator performs some pre-testing of the firmware on various devices before scheduling updates across the enterprise).

[0082] Optionally, the first authorization ticket 17 and the second authorization ticket 27 comprise a cryptographic signature of the respective maintenance work 15 , 25 .

[0083] Optionally, the results of the first authentication check process 18 and / or the second authentication check process 28 are at least partially stored in the respective authorization ticket 17 , 27 .

[0084] In a sixth step 112 , a second maintenance job 25 is processed with the second authorization ticket 27 to perform configuration of the at least one device 50 .

[0085] Regarding the configuration or change process of at least one device 50 of the system 90, other aspects are of interest:

[0086] In the case where the field device 50 is an OPC UA device, a field information management (FIM) or another OPC UA client, such as within an edge device, can be used to authorize the change by processing the ticket and subsequently obtaining an authenticated and authorized session to the field device and performing the required changes, such as writing parameters or triggering a firmware update method. This method can be applied to any standardized device and therefore does not require any changes to the field device other than security configuration.

[0087] In the case of a fieldbus field device 50 behind a FIM: In this case the FIM is responsible for validating the ticket and invoking the changes described in the maintenance work. Security between the FIM and the field device is handled by the FIM according to the security measures supported within the device and the field device.

[0088] Ticketing: The method of the present invention allows maintenance work and tickets to be passed directly to the device (eg, via OPC UA method calls). The field device performs the evaluation of the maintenance work and authorization ticket and applies the changes directly within the firmware of the device 50.

[0089] In the following, optional features of the above-described method steps are presented in a more detailed manner.

[0090] Optionally, the first data 10 and / or the second data 20 are at least partially obtained by an external data provider 60. Thus, the system 90 can be connected to an external repository or a third-party supplier (e.g., a non-ABB supplier) via an interface to provide updated information about available device updates or parameter configurations.

[0091] Optionally, first maintenance work 15 is generated at first system level 16 of system 90, and second maintenance work 25 is generated at second system level 26 of system 90. First system level 16 may be a so-called central monitoring and operating level (M+O). Second level 17 may be a more refined level below first level 17. However, it should be noted that the method of the present invention can also be implemented in system 90 without using different implementation levels, but rather using only one level for all method steps.

[0092] Figure 3 A computer system 95 is shown for configuring at least one device 50 of system 90 according to an embodiment of the present invention.

[0093] The computer system 95 is configured to perform a computer-implemented method 100 for configuring at least one device 50 of the system 90 .

[0094] Computer system 95 may be part of or implemented in system 90 and / or may be partially externally connected to system 90 .

[0095] In this implementation, the system 90, which may be an industrial system, has at least one interface to an external data provider 60. Such an interface may be implemented as a device vendor-specific API adapter, generated to connect the central M+O control engine to a third-party vendor, or through a standardized API, such as by implementing an Asset Management Shell API (IEC 63278) interface.

[0096] In this article, some key aspects of the present invention are summarized as follows:

[0097] The idea of the present invention is to bundle equipment changes and DCS changes into one VoR system to ensure seamless processing and user experience for the owner / operator when applying changes to critical parts of a process plant.

[0098] Planned changes to field devices are denoted as so-called "device maintenance work", such as firmware updates, parameter changes, device replacement (of the same type) with parameter restoration, replacement with a new device type, etc.

[0099] For example, a device maintenance job may be initiated bottom-up when a maintenance engineer needs to approve a parameter change, or top-down when, for example, an available firmware update for a device is detected and needs to be propagated down to the field device list of device 50 .

[0100] According to the present invention, the following embodiments can be implemented:

[0101] The connection from the CPC via the information diode allows the M+O domain to create an inventory of the existing field devices within the plant ("Inventory" box). This inventory stores device twins containing at least static information such as device location, device type, serial number, firmware version, etc. Furthermore, the central M+O domain can access dynamic data from the devices, such as their error status or current parameter configuration. This allows for continuous monitoring of device status and the detection of unplanned inconsistencies, such as those caused by urgent repairs.

[0102] Based on this device twin, the central M+O can connect to external repositories, such as those of device vendors of non-ABB field devices, and retrieve, for example, available field device updates. This can happen via device vendor-specific API adapters produced to connect the central M+O to third-party vendors, or via standardized APIs, such as by implementing the Asset Management Shell API (IEC 63278) interface.

[0103] Based on inventory data, maintenance jobs are created automatically by the central M+O (first level) or by users through an app / web interface. This job describes a specific change to be applied to a specific device or device class (e.g., a group of the same type of device at a specific location). The first step of the VoR mechanism can be applied at the central M+O level, for example, whether a specific user is allowed to initiate a change at a specific site. These verification steps are signed in a partial approval ticket, similar to the digital signature of the maintenance job data entity.

[0104] The job is propagated downwards to the internal management M+O level (second level), where additional checks are performed on the maintenance work itself and the partial approval ticket for completing the maintenance work. The internal M+O or gateway knows the specific site system layout and can provide additional information to the maintenance work, such as mapping the abstract device identity (serial number) to the technical device location (IP / hostname for OPC UA endpoints, or I / O interface location for example for a device's HART interface).

[0105] Furthermore, additional, on-premises-related adjustments can be made to the work, such as detailing changed timeframes based on scheduling information, such as maintenance windows obtained from an MES / ERP system like SAP. [This is beyond the state of the art.] Based on these changes, detailed maintenance work is created, which is again cross-checked using a VoR rules-based engine to match all safety standards for the specific plant.

[0106] The content of the detailed work description may be, for example: device identification, technical device location (e.g., OPC UA endpoint), action (e.g., firmware update or parameter change), supplementary data (e.g., a byte stream representing a new firmware binary, or a set of parameter values to be applied to the device).

[0107] After passing the rule-based checks, the verified results are stored and signed off in an approval ticket that is provided along with a detailed work description.

[0108] The job description and at least one approval ticket (which is a cryptographic signature of the job) may now be handled differently depending on the device capabilities and / or available infrastructure:

[0109] 1) OPC UA Device: In the case where the field device is an OPC UA device, a FIM or other OPC client, such as within Edgenius, can be used to authorize changes by processing the ticket and subsequently obtaining an authenticated and authorized session to the field device and performing the required changes, such as writing parameters or triggering a firmware update method. [This method works with any standardized OPC UA PA-DIM device, so no changes to the field device are required other than security configuration.]

[0110] 2) HART or Fieldbus field devices after FIM: In this case, the FIM is responsible for validating the ticket and invoking the changes described in the maintenance work. Security between the FIM and the field device is handled by the FIM according to the security measures supported within the device and field device.

[0111] Reference numerals

[0112] 10First Data

[0113] 11Static Information

[0114] 12 Dynamic Information

[0115] First maintenance work

[0116] First system level

[0117] First approved bill

[0118] First inspection procedure

[0119] Second data

[0120] 25 Second maintenance work

[0121] Second system level

[0122] 27 Second Approved Note

[0123] 28 Second verification check process

[0124] 50 devices

[0125] 60 External Data Provider

[0126] 90 System

[0127] 95 Computer Systems

[0128] 100 Methods

[0129] 102 offers

[0130] 104 generated

[0131] Creation of 106

[0132] 108 Improvements

[0133] 109 Generation

[0134] 110 Creation

[0135] 112 processing

Claims

1. A computer-implemented method (100) for configuring at least one device (50) of a system (90), comprising the steps of: - providing (102) first data (10) of said at least one device (50) in relation to device-specific data of said at least one device (50); - generating (104) at least a first maintenance task (15) based on said first data (10), said at least first maintenance task describing a change request requirement to be applied on said at least one device (50); - creating (106) at least a first authorization ticket (17) based on the generated first verification check process (18) of the first maintenance work (15) of the at least one device (50); - processing (112) said at least first maintenance task (25) to perform configuration of said at least one device (50) using said at least first authorization ticket (17).

2. The computer-implemented method (100) of claim 1, comprising the step of refining (108) the first maintenance work (25) after generating (106) the first approval ticket (17) by: - based on the generated first maintenance work (15), generating (109) a second maintenance work (25) by adding the second data (20) to the second maintenance work (25); - creating (110) a second authorization ticket (27) based on a second verification check process (28) of the generated second maintenance work (25) of the at least one device (50).

3. A computer-implemented method (100) according to any one of the preceding claims, wherein the first data (10) comprises at least one of the following: the number of the devices (50) of the system (90), static information (11) and / or dynamic information (12) of at least one of the devices (50).

4. The computer-implemented method (100) of claim 2, wherein the second data (20) further comprises device-specific data specifying the second maintenance work (25).

5. The computer-implemented method (100) according to any one of the preceding claims, wherein the first data (10) and / or the second data (20) are at least partially obtained via an external data provider (60).

6. The computer-implemented method (100) according to any one of the preceding claims, wherein the maintenance work (15, 17) is initiated by a user command and / or automatically.

7. The computer-implemented method (100) of any one of the preceding claims, wherein the first maintenance work (15) is generated on a first system level (16) of the system (90), and the second maintenance work (25) is generated on a second system level (26) of the system (90).

8. A computer-implemented method (100) according to any one of the preceding claims, wherein the first validation check process (18) comprises a digital signature of the first authorization ticket (17), the digital signature indicating permission whether the configuration of the at least one device (50) is allowed.

9. A computer-implemented method (100) according to any one of the preceding claims, wherein the second verification check process (28) includes at least one of the following checks: a security standard check of the at least one device (50), a check of at least one device-related setting and / or parameter of the at least one device (50).

10. The computer-implemented method (100) according to any one of the preceding claims, wherein the results of the first validation check process (18) and / or the second validation check process (28) are at least partially stored in the respective authorization ticket (17, 27).

11. The computer-implemented method (100) according to any one of the preceding claims, wherein at least one of the authorization tickets (17, 27) comprises a cryptographic signature of the corresponding maintenance work (15, 25).

12. A computer system (95) configured to perform the computer-implemented method (100) for configuring at least one device (50) of a system (90) according to any one of the preceding method claims 1 to 11.

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

14. A computer program product comprising instructions which, when the computer 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.

15. A machine-readable data medium and / or download product comprising a computer program according to claim 14.

Images