Device management system and method for commissioning field devices with error resolution

Abstract

A device management system for performing validation prior to commissioning at least one field device. The system includes a commissioning tool operable to receive at least one source file relating to the at least one field device for import operation, and a processor operable to check the source file for any error. If at least one error is found in the source file, the processor is operable to refer to an error resolution database for providing guidance on resolution of error associated with the source file without terminating the import operation.

Claims

1. A device management system for performing validation prior to commissioning at least one field device comprising: a commissioning tool configured to receive at least one source file relating to the at least one field device in an import operation; and a processor configured to check the at least one source file for any error, wherein the processor is further configured to provide guidance on resolution of at least one error found in the at least one source file using rules for error handling retrieved from an error resolution database without terminating the import operation, the rules defining at least one auto fix option based on a device property and validation criteria associated with the at least one error.

2. The device management system of claim 1, wherein the processor is further configured to convert the at least one source file to a device list file.

3. The device management system of claim 2, wherein the processor is further configured to convert the at least one source file to a device list file and a mapping list file.

4. The device management system of claim 1, wherein the error resolution database comprises a device error resolution database and a mapping error resolution database.

5. The device management system of claim 1, wherein the commissioning tool is further configured to provide an error handling interface for displaying the at least one error and the guidance is a suggested correction for the at least one error.

6. The device management system of claim 1, wherein the commissioning tool is in data communication with a control system, the control system interfacing with the at least one field device.

7. The device management system of claim 1, wherein the commissioning tool is in data communication with a repository for purpose of generation, supplementation and update of the error resolution database.

8. The device management system of claim 7, wherein the repository comprises at least one field device information file, a registration file, a protocol device registration file and a control system loop information file.

9. The device management system of claim 4, wherein the device error resolution database or the mapping error resolution database are stored as .xml file format.

10. The device management system of claim 5, wherein the suggested correction is updatable at any time the error handling interface is provided.

11. The device management system of claim 5, wherein if the at least one error is associated with a parameter which is non-mandatory, the suggested correction is in the form of an empty entry.

12. The device management system of claim 5, wherein if the at least one error is associated with a parameter which is mandatory, the suggested correction is based on a modification of the parameter which is mandatory to comply with a validation rule.

13. The device management system of claim 4, wherein if the at least one error is associated with a parameter related to the path or address of the at least one field device, then the suggested correction is in the form of an input for the entry of the correct path or address of the at least one field device.

14. A method for performing validation prior to commissioning at least one field device comprising the steps of: receiving at least one source file relating to the at least one field device in an import operation; and checking the at least one source file for any error and providing guidance on resolution of at least one error found in the at least one source file using rules for error handling retrieved from an error resolution database without terminating the import operation, the rules defining at least one auto fix option based on a device property and validation criteria associated with the at least one error.

15. The method of claim 14, further comprising the step of converting a portion of the at least one source file to a device list file.

16. The method of claim 15, wherein the step of converting includes converting the at least one source file to a device list file and a mapping list file.

17. The method of claim 14, wherein an error handling interface for displaying the at least one error is provided and the guidance is in the form of a suggested correction for the at least one error.

18. The method of claim 17, wherein if the at least one error is associated with a parameter which is mandatory, the suggested correction is based on a modification of the parameter which is mandatory to comply with a validation rule.

19. The method of claim 17, wherein if the at least one error is associated with a parameter related to the path or address of the at least one field device then the suggested correction is in the form of an input for entry of the correct path or address of the at least one field device.

20. A non-transitory computer readable medium containing executable software instructions thereon wherein when executed performs the method of performing validation prior to commissioning at least one field device comprising the steps of: receiving at least one source file relating to the at least one field device in an import operation; and checking the at least one source file for any error and providing guidance on resolution of at least one error found in the at least one source file using rules for error handling retrieved from an error resolution database without terminating the import operation, the rules defining at least one auto fix option based on a device property and validation criteria associated with the at least one error.

Description

BRIEF DETAILS OF THE DRAWINGS

(1) In order that this invention may be more readily understood and put into practical effect, reference will now be made to the accompanying drawings, which illustrate preferred embodiments of the invention by way of example only, wherein:

(2) FIG. 1A, FIG. 1B and FIG. 1C are system block diagrams of field device management systems in accordance with various embodiments of the invention;

(3) FIG. 2 is a flow chart showing the incorporation of an error handling (“Auto fix”) feature in the import device operation in accordance with an embodiment of the invention;

(4) FIG. 3 shows an example user interface of the error handling (“auto fix”) feature in accordance with an embodiment of the invention;

(5) FIG. 4A and FIG. 4B are example tables illustrating the rule bases for handling errors in the device list file;

(6) FIG. 5A and FIG. 5B are example tables illustrating the rule bases for handling errors in the mapping list file; and

(7) FIG. 6 is a flow chart showing how the device list file and mapping list file are processed once the error handling (“auto fix”) feature is in operation.

(8) Other arrangements of the invention are possible and, consequently, the accompanying drawings are not to be understood as superseding the generality of the description of the invention.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

(9) In the description, the term ‘source file’ includes, but is not limited to, input/output list files, device list files, and engineering files (with device list file or I/O list file, if necessary). It is to be appreciated that the engineering files are suitable to be used for configuration of a plant asset management system or a plant control system. The plant asset management system or plant control system may be used for monitoring and/or control of an industrial plant. The various files (source, device, I/O, engineering) may comprise electronic data containing information relating to specific parameters of the field devices, the asset management system, and/or the plant control system.

(10) Throughout the description, the term ‘device list file’ include parameters or properties associated with field devices such as (but not limited to) ‘system’, ‘device tag’, ‘device path’, ‘communication type’, ‘device address’, and ‘input output type’ etc. The term ‘mapping list file’ will include parameters or properties associated with field devices such as (but not limited to) ‘device tag’, ‘system tag name’, ‘connection type’, etc.

(11) In accordance with an embodiment of the invention there is a device management system 100 for performing validation prior to commissioning at least one field device. The device management system 100 is suited, but not limited to facilitate the commissioning process of field devices in the context of a field device management system as shown in FIG. 1.

(12) With reference to FIG. 1, a system block diagram of a field device management system 10 is shown. The field device management system comprises a control system 122 in data communication with at least one field devices 140. The control system 122 is operable to be in data communication with the device management system 100.

(13) The device management system 100 comprises a commissioning tool 102 and a repository 104. The commissioning tool 102 is arranged and configured to communicate with the at least one field devices 140, the repository 104 and with the control system 122. The commissioning tool 102 is configured to refer files stored in the repository 104 for purpose of performing automatic commissioning processes and procedures for the at least one field device 140. Commissioning tool 102 can be implemented by software in combination with hardware, and may be complemented by servers and processors to implement the functions as known to a skilled person.

(14) The repository 104 is configured to have a field device information file 106, a registration file 108, a protocol device registration file 110, a control system loop information file 112 and any other temporary or permanent files, if any. In another embodiment, the repository 104 includes list files associating each field device with certain property(ies). Example of such list file includes a “vendor list file” retrievable by the commissioning tool 102 during operation.

(15) The field device information file 106 comprises a list of field devices which are configured to be in communication with the field device commissioning system, and describes one or more properties for each field device. Examples of such property include “device tag”, “device model”, “device ID”, “manufacturer/vendor ID” and “revision Number”. The field device information file 106 can be referred by the commissioning tool 102 to allow the commissioning tool 102 to perform a task to identify a type of the field device. As an example, identification of the field device 140 may include checks on whether the field device 140 is a pressure transmitter, a temperature transmitter or a flow meter.

(16) The registration file 108 lists, for each field device, device communication commands which are to be executed to the respective field device 140 for a desired task or check function. The registration file 108 can be referred by the commissioning tool 102 to allow the commissioning tool 102 to identify a specific type of device communication command, such as a “HART Command 54”, and then to execute it to a field device 140 which is a HART field device. The protocol device registration file 110 lists field devices 140 which are registered in a respective protocol database. For example, a HART field device may be registered with HART communication foundation. A HART field device registration file is created from HART field devices which are registered with the HART communication foundation. For Foundation Fieldbus H1 (“FF-H1”) field devices which are registered in the Fieldbus foundation, a corresponding FF-H1 registration file is created. The protocol device registration file 110 can be implemented as separate files, one for each communication protocol.

(17) Alternatively, the protocol device registration file 110 can be implemented as one file including field devices registered in all protocols with a suitable identifier to distinguish the respective protocols for the respective field devices. In some cases, the protocol device registration file 110 may include specific field devices such as field devices which are pressure transmitters.

(18) The control system loop information file 112 comprises, for each field device, a list of the respective or associated configuration parameters in the control system 122. If the control system 122 comprises function blocks, the function blocks information and association of function with the field devices 140 are included in the control system loop information file 112. The association or ‘map’ between the function blocks with the field devices 140 is included as a mapping table. The control system loop information file 112 is updated to the repository 104 when required, such as for each change in any field device or configuration parameters in the control system 122. The update is done by importing the control system loop information file 112 as the need arises.

(19) The at least one field device 140 may include a field device based on HART communication protocol and/or a field device based on FF-H1 communication protocol. The HART and/or FF-H1 field device may perform specific functions such as a pressure transmitter, temperature transmitter or flow meter.

(20) In other embodiments shown in FIG. 1B and FIG. 1C, the commissioning tool 102 may be in direct or indirect data communications with:

(21) i. servers and processors to implement at least one of control system 122; and

(22) ii. Input-output (I/O) module 160 providing a necessary interface to communicate with the field devices. In particular, the Input-output (I/O) module comprises a device which is operable to receive and transmit various types of electrical and electronic signals to control and monitor field devices in a network including field devices and at least a control system, a device management system and a commissioning tool.

(23) The control system 122 may be in direct data communication with the field devices 140 according to some embodiments of the invention. The commissioning tool 102 or the control system 122 is in direct data communication with the I/O module 160 when it is in indirect data communication with the field devices according to some embodiments of the invention.

(24) In another embodiment, the control system 122 may not be necessary or may be integrated with the commissioning tool 102 for direct or indirect communication with the field devices 140 via the I/O module 160.

(25) The commissioning tool 102 in normal operation, as part of the import device operation is operable to receive source files for import.

(26) In an embodiment, commissioning tool 102 incorporates an error handling function comprising an “auto fix” function that allows a user, such as an engineer, the opportunity to modify or correct any errors/incorrect information regarding a field device during the import device operation directly so as to avoid abortion and the need to repeat the import device operation from start whenever an error is discovered. Advantageously, guidance may be provided to the user to aid the user in correction or rectification of any error(s) discovered during the import device operation. An example of the guidance provided may be in the form of a suggested solution or recommended solution presented to the user for acceptance. Such suggested solutions are particularly useful for inexperienced user(s).

(27) Referring to FIG. 2, an import device flow chart incorporating the error handling function is shown. The import device flow chart may be implemented in the form of software having a user graphical interface 300. The user graphical interface 300 comprises an interface for error handling and may also be referred to as an error handling interface 300. The flow chart commences with a start step 202 awaiting input from a user to import files. The input may be in the form of a drop down menu or a click button as known to a skilled person. When the user input is received, the commissioning tool 102 shows an interface, preferably in the form of an electronic form for the user to select the source file (step 204). The selection may be in the form of a ‘path’ or an URL link to the source file location within a computer or dedicated server functioning as a repository. The computer and the repository may be in a network or spread across distributed networks according to some embodiments of the invention.

(28) Upon receiving the source file, the commissioning tool 102 validates the entries within the source file and check for errors (step 206). If any error is detected, the error handling user interface 300 would be provided for the user to have an opportunity to rectify the error (step 208); instead of terminating the process as described in the background section.

(29) In an embodiment, an example of the error handling user interface 300 is shown in FIG. 3. The error handling interface 300 includes various items. An example list of items which are used to configure the error handling interface 300 is shown in Table 1. The example items in the Table 1 under column header “Item” are illustrated by same alphabets in FIG. 3.

(30) In table 1, column “Control” refers to a location or a visual representation for the item on the error handling interface 300. The location or a visual representation is configured to enable at least one of a display function or a control function for the item. Examples of the location or visual representation may include “Button”, “Label”, and “Checkbox” etc.

(31) The column “Default” refers to a default display or control value. For example, a checkbox is “Uncheck” by default when the checkbox is configured to be included in the interface for item C and item I.

(32) The column “Constraints” describes a limitation such as access rights and restrictions for the item (if any).

(33) TABLE-US-00001 TABLE 1 User interface for error handling (auto-fix with reference to FIG. 3) Item Item Name Description Control Default Constraints A Errors found Contain list of devices that Data grid N/A none have errors in source file B Device Tag Device Tag of field devices Data grid N/A Read only that comprise error(s). column C Check Box If engineers want to import Data grid Uncheck If engineers devices that have errors check box want to check and replace the error with column all devices, auto fix value, they need to they can check this check box, check the otherwise, the device will “check all not be imported into the box” in the commissioning tool column header D Auto fix Contain list of property Data grid N/A none property values and auto fix values values for these properties E Device Contain all properties of Data grid N/A Read only Property device that have invalid column value (e.g. Device ID, Vendor etc.) F Source file Original value of device Data grid N/A Read only values property in source file column G Auto fix Value that the Data grid N/A Users can values commissioning tool textbox easily edit the suggests to users using column value if they this value to fix the errors. don't want to Based on a predefined rule use the base. default value that commissioning tool provides H Update rule When this button is Data grid N/A none clicked, it will update the button auto fix rule with the column suggested value that users provide in the Auto fix value column. “Update rule” button is available for some properties that allow users to update auto fix rule. I Show All When uncheck this Checkbox Uncheck none Device checkbox, only device Properties properties that have errors will be shown. When check this checkbox, all the device properties will be shown J Back Move to the previous Button N/A None page, in this case, the Summary page data previously provided by the user in the previous page remains available K Resolve Allow engineers to resolve Button N/A Only shown if any conflicts in the Conflict there are Resolution page that conflicts to follows resolve Move to the Conflict Resolution page L Save Save the devices and Button N/A none mappings from the source files to the system Skip the Conflict Resolution page (if applicable), meaning it will go directly to the Results page, and use the existing values in the system if there are any conflicts Move to the Import Devices results page M Cancel Cancel the Import Devices Button N/A none operation; no changes are made to the system Move to the Import Devices interrupted page

(34) The error handling interface 300 therefore provides an opportunity for a user to:

(35) a. fix an error without resetting the import operation process if the user wishes to continue import a particular field device that has an error (see item C);

(36) b. for each error, provide at least one suggested solution where applicable, and hence some form of guidance, on how to resolve the error (see item G);

(37) c. provides the flexibility for a user to update one or more suggested solutions to resolve the errors (see item H).

(38) The predefined or predetermined rule base or error resolution databases mentioned in item G of Table 1 is detailed in FIG. 4 and FIG. 5. FIGS. 4a and 4b refer to the rule base comprising a device error resolution database with suggested solutions for various errors related to a device list file. FIGS. 5a and 5b refer to the rule base comprising a mapping error resolution database with suggested solutions for various errors related to a mapping list file.

(39) It is to be appreciated that the rule bases in either FIG. 4 or FIG. 5 may be updatable by an authorized user such as a developer. The values associated with the parameters to be updated by an authorized user may be done manually or automatically. In an embodiment, values are updated automatically to the rule base when the values are input by authorized user(s) for a first time. This will be further elaborated.

(40) The rule base for resolving errors in the device list file and the mapping list file may be organized such that when an error in the device list file is detected, the commissioning tool 102 checks through the rule base (which may be presented as a table format) to retrieve a suitable auto-fix solution/rule to be applied for error resolution. The table comprises the following six parameters categorized into six columns:—‘device property’, ‘mandatory’, ‘description’, ‘data type’, ‘validation’ and ‘auto fix rule’. It is to be appreciated that more or less columns may be added or subtracted where necessary. For example, the ‘description’ column may be removed as it serves merely as an information source to facilitate ease of understanding and does not affect the operations of the error handling process. The six parameters are further described in turn.

(41) ‘Device Property’—refers to device information, protocol and other information as may be referred from the files 106, 108, 110, 112 in the repository 104;

(42) ‘Mandatory’—whether the error is caused an entry which is mandatory for the import operation. If not mandatory, a quick suggested solution is to leave the field blank as part of error resolution, i.e. ‘Show empty value’;

(43) ‘Description’—information relating to the device property. To facilitate understanding for a user;

(44) ‘Data type’—the data type for the device property which the commissioning tool 102 will accept, such as string, binary, numeric etc. A wrong data type for a device property will generate an error;

(45) ‘Validation’—further restrictions on data type. For example, if a data type is string, further restrictions may be placed on maximum number of characters, specific string input, type of string input etc.

(46) ‘Auto-fix rule’—the suggested solution when an error is detected. The suggested solution is generated to comply with the data type and validation parameters.

(47) The workings of the rule base will be further illustrated in the context of the operation when a user imports a source file. From the table, a few scenarios will be described to illustrate the robustness of the auto fix function. It is to be appreciated that these scenarios are non-exhaustive.

(48) Scenario A

(49) Where there is an error in the device file relating to the parameter ‘device tag’, the commissioning tool 102 will retrieve the physical device tag and replace the erroneous device tag provided the physical device tag complies with the string data type, and is within 32 specified valid characters. Otherwise the device is considered as invalid. The device tag is a mandatory parameter and therefore it cannot be left blank. Where the parameter ‘device tag’ is invalid, the error handling interface 300 is shown with an empty value displayed as the suggested solution for a user to enter a valid parameter. If the user does not enter a valid parameter or if he/she enters another invalid parameter, then the device will not be imported. Referring to the item C check box of FIG. 3, the device will be unchecked and the import device will continue for other devices, where applicable.

(50) Scenario B

(51) In contrast, if the error relates to the parameter ‘device ID’, which is a non-mandatory parameter, then a suggested solution is to leave the parameter blank. Accordingly, the error handling interface 300 will be displayed for the user to accept the recommended solution or make changes complying with the data type and validation parameters.

(52) Scenario C

(53) There are instances where the error cannot be resolved as these are deemed ‘fatal errors’. In such cases, the auto-fix page will not be displayed and the user will be requested to repeat the import device operation. These errors are related to the path and address of the field device, i.e. see ‘Device path’ which are paths connected to the field communications server, and ‘Device address’ which is the address of the device in the field network in hexadecimal numbers.

(54) Scenario D

(55) There are some parameters which are mandatory but the commissioning tool does not have a suggested solution. In such cases, an empty value will be displayed as the suggested solution and the user prompted to enter a valid value (see for example ‘System tag name’ in FIG. 5).

(56) Scenario E

(57) In most cases, if an erroneous parameter is due to a string length exceeding a predetermined number of characters, for example 255 characters, then a sample solution that contains 255 characters for device will be suggested for the user's consideration.

(58) It is to be appreciated that the device list file and mapping list file rule bases may be generated, supplemented and/or updated from various sources. In particular the auto fix rule device file may be generated, supplemented and/or updated from a field device vendor list and/or model list; and the auto fix rule mapping file may be generated, supplemented and/or updated from a connection type list and a block type list file.

(59) Preferably, the auto fix rule base comprises one or more files in extensible markup language (.xml) format. For example, the ‘validation’ parameter and ‘auto fix rule’ parameter in FIG. 4 and FIG. 5 may be in the form of an .xml file for update by a developer/user when necessary. The ‘auto fix rule’ parameter may further be modified by a user overriding the suggestion solution in the error handling interface 300.

(60) The sequence of processing of source file to detect errors for subsequent auto fix is described with reference to FIG. 6. The process 600 commence with a consolidation of all invalid devices in the device list file (step 602). These invalid devices are deemed ‘invalid’ due to at least one error in the device list file derived from the source file during import operation.

(61) The commissioning tool 102 then loops through each invalid device (step 604), and for each invalid device, the commissioning tool 102 refers to the rule base (see FIG. 4) to provide suggested solution to resolve the at least one errors.

(62) Where there is no suggested solution, a blank or empty value may be shown, with the validation parameter and data type parameter to further guide the user to input a correct value (step 606). Any updated auto fix values in the auto fix device list file will next be stored (step 608) for reference by a developer, who may then make the decision whether to update the auto fix rule base for device based on any new input provided by the user.

(63) Once all invalid devices have been processed, the auto fix operation for resolving errors of the device list file ends (step 610).

(64) The process is repeated for the invalid mappings in the mapping list file, where it commences with a consolidation of all invalid mappings in the mapping list file (step 612). These invalid mappings are deemed ‘invalid’ due to at least one error in the mapping list file derived from the source file during import operation.

(65) The commissioning tool 102 loops through each invalid mapping (step 614), and for each invalid mapping, the commissioning tool 102 refers to the rule base (see FIG. 5) to provide suggested solution to resolve the at least one errors. Where there is no suggested solution, a blank or empty value may be shown, with the validation parameter and data type parameter to further guide the user to input a correct value (step 616). Any updated auto fix values in the mapping fix device list file will next be stored (step 618) for reference by a developer, who may then make the decision whether to update the auto fix rule base for mapping based on any new input provided by the user.

(66) Once all invalid mappings have been processed, the auto fix operation for resolving errors of the mapping list file ends (step 620).

(67) It is to be appreciated that where no errors are detected or if there is a ‘fatal error’, the error handling interface 300 will not be shown.

(68) Once the auto error fix step 208 is completed, the process continues with the display of a conflict resolution step 210 which is to be distinguished from the error fix step 208. Conflict resolution step 210 is required where there are duplicate entries in the import operation process which must be resolved.

(69) In the event where a user wishes to reset the import device operation task due to duplicates, he will be able to do so via a reset task step 212. A ‘results’ interface will then be shown displaying the successful/unsuccessful status of the import device operation (step 214).

(70) It is to be appreciated that at any one step 202 to 212, a user may cancel or abort the import device operation (step 216).

(71) In accordance with another embodiment of the invention there comprises a method for performing validation prior to commissioning at least one field device 140 comprising the steps of receiving at least one source file relating to the at least one field device for import operation (step 204); converting a portion of the source file into a device list file; and checking the device list file for any error; wherein if at least one error is found in the device list file; providing guidance on resolution of error associated with the device list file without the need to terminate the import device operation and repeating the import device operation due to an error. The method may include the steps 202 to 216 as shown in FIG. 2, and to facilitate ease of users' input, the method may include the generation and display of an auto error handling interface 300 as shown in FIG. 3. In addition to a device list file, where applicable and if function blocks within the control system 122 exist then a mapping list file may also be generated during the conversion of source file. The process and resolution of errors, including the reference to the rule bases for guidance provided to a user to resolve any error without the need to terminate or restart the import device operation is as described in the earlier embodiment and will not be further elaborated.

(72) In accordance with another embodiment of the invention there comprises a non-transitory computer readable medium that stores a computer program to be executed by the commissioning tool 102 described in the earlier embodiment. In particular, the computer program incorporates the auto-fix function and associated rule bases such that when executed, causes the commissioning tool to display the error handling interface 300 when at least one error is found, without the need to terminate or restart the import device operation.

(73) It is to be understood that the above embodiments have been provided only by way of exemplification of this invention, and that further modifications and improvements thereto, as would be apparent to persons skilled in the relevant art, are deemed to fall within the broad scope and ambit of the present invention described herein. In particular: Although the invention was described in the context of a specific commissioning tool, it is to be appreciated that the invention may be applied to other device management systems and commissioning tools. The commissioning tool may be in data communications with servers and processors (whether remote or otherwise) where applicable to implement the error handling/resolution function.

(74) It would be further appreciated that although the invention covers individual embodiments, it also includes combinations of the embodiments discussed. Therefore, features described in one embodiment not being mutually exclusive to a feature described in another embodiment may be combined to form yet further embodiments of the invention.