Field Device and Method for Parameterizing the Field Device

Abstract

A field device and method for parameterizing a field device via a parameter, wherein to provide validation, a first checking characteristic is calculated by the field device based on the parameter and a device ID stored, where the first checking characteristic is transferred to an engineering system, the parameter to be validated and the device ID are additionally transferred to the engineering system and are output on a display, where to confirm correct parameterization, a user can input the read first checking characteristic at an operating unit of the engineering system, which first checking characteristic is then transferred back to the field device, where the received checking characteristic is compared with the calculated checking characteristic to validate the parameter such that external calculations of checking characteristics are advantageously unrequired and relation of the validation to the correct field device is ensured.

Claims

1.-6. (canceled)

7. A method for parameterizing a field device with at least one parameter, the at least one parameter being input into the field device via an operating unit or transferred to the field device via a first logical interface and deposited in a memory of the field device, the field device calculating, based on at least the deposited at least one parameter and a device ID of the field device, a first checking characteristic, the first checking characteristic being also deposited in the memory and transferred via a second logical interface to an engineering system and output on a display, the method comprising: transferring, by the field device, the at least one parameter via a third logical interface which is data-diverse with respect to the first interface to the engineering system and outputting said at least one parameter on the display; transferring, by the field device, the device ID to the engineering system and outputting said device ID on the display; transferring to the field device a first checking characteristic input by a user after visual checking the at least one parameter and the device ID on the engineering system in a predefined format via a fourth interface which is data-diverse with respect to the second interface; and comparing, by the field device, the received first checking characteristic to the calculated first checking characteristic to validate the at least one parameter.

8. The method as claimed in claim 7, wherein a state of completed validation of the at least one parameter is deposited in the memory of the field device in an event of conformity between the received first checking characteristic and the calculated first checking characteristic.

9. The method as claimed in claim 8, wherein further comprising: calculating, by the field device calculates upon conclusion of a validation of the at least one parameter, based on parameters deposited in the field device, a second checking characteristic; and transferring the calculated second checking characteristic to the engineering system and outputting said on the display.

10. The method as claimed in claim 8, wherein a function test is performed on the field device in response to a corresponding input by an user on an operating unit of the engineering system in an event of a completed validation of the at least one parameter; and wherein the field device changes to a safe mode and this safe mode state is deposited in the memory of the field device in an event of a fault-free completion of the function test, following confirmation thereof, on a corresponding input by a user on the operating unit.

11. The method as claimed in claim 9, wherein a function test is performed on the field device in response to a corresponding input by an user on an operating unit of the engineering system in an event of a completed validation of the at least one parameter; and wherein the field device changes to a safe mode and this safe mode state is deposited in the memory of the field device in an event of a fault-free completion of the function test, following confirmation thereof, on a corresponding input by a user on the operating unit.

12. The method as claimed in claim 10, wherein validation of the at least one parameter is monitored via an automatic state machine implemented in the field device.

13. A field device for parameterizing the field device with at least one parameter, the field device comprising: a computing unit; and memory; wherein the field device is configured to: receive at least one parameter via a first logical interface and deposit said received at least one parameter in the memory; calculate, based on the deposited at least one parameter and a device ID of the field device, a first checking characteristic; deposit the calculated first checking characteristic in said memory; transfer said calculated first checking characteristic via a second logical interface to an engineering system for output on a display; wherein the field device is further configured to: transfer the at least one parameter via a third logical interface which is data-diverse with respect to the first logical interface to the engineering system for output of at least one parameter on the display; transfer the device ID to the engineering system; receive a first checking characteristic on the engineering system input in a predefined format via a fourth interface which is data-diverse to the second interface; and compare the received first checking characteristic to the calculated first checking characteristic to validation of the at least one parameter.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The invention and embodiments and advantages are explained in more detail below with reference to the drawings, which depict an exemplary embodiment of the invention, in which:

[0022] FIG. 1 is a schematic block diagram of an automation system in accordance with the invention;

[0023] FIG. 2 is a schematic block diagram of a safety-critical field device in accordance with the invention;

[0024] FIG. 3 is a schematic block diagram of the memory of the field device of FIG. 2; and

[0025] FIG. 4 is a state diagram of an automatic machine in the field device in accordance with the invention; and

[0026] FIG. 5 is a flowchart of the method in accordance with the invention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

[0027] FIG. 1 depicts an automation system 1, which is used in an automated industrial plant, not depicted in further detail, to control a process. In the automation system 1, a control system 2, here a SIMATIC PCS 7, a commissioning tool 3, here a SIMATIC PDM, an engineering station 4 and field devices F1, F2, . . . Fn are interconnected by a network 5 for data communication. The network 5 can be any kind of network, such as an industrial network with a PROFIBUS, PROFINET, HART or FF protocol. However, non-industrial networks, for example a wide area network (WAN), the internet or any wireless networks are also suitable. In contrast to connections for the exchange of process values for functionally safe open-loop/closed-loop control, the network 5 does not have to be subject to functional safety requirements. The commissioning tool 3 and the engineering station 4 are used to parameterize the safety-critical field devices F1, F2, . . . Fn. The engineering station 4 is provided with an operating unit 6 via which a user 7 can make various operator inputs required to perform the method for parameterizing a field device. The operating unit 6 simultaneously serves as a display for outputting data that the operator is required to check visually during the performance of the method.

[0028] It should be understood, the control system 2, the commissioning tool 3 and the engineering station 4 can be implemented by any number of computing units, for example, in contrast to the exemplary embodiment depicted, by only one computing unit which then combines the functions of the three components mentioned.

[0029] The field devices F1, F2, . . . Fn are each supplied with a safety manual, which describes the exact sequence during the performance of the method. In addition, device description files matching each of the field devices F1, F2, . . . Fn are supplied, where these specify the sequence of the method in the engineering system 4 and operate interfaces so that the data required for the dialogues described in the safety manual is made available.

[0030] It should be understood, as an alternative to a device description file written in Electronic Device Description Language (EDDL), the method can be supported on the engineering station side 4 by means/methods such as Device Type Manager (DTM) or Field Device Integration (FDI).

[0031] FIG. 2 shows the basic field device structure using the example of a field device Fx, which can be any one of the field devices F1, F2, . . . Fn and which meets the requirements of functional safety. The field device Fx is provided with two logical interfaces S1 and S2, which are both configured for communication via the automation network 5. The interface S2 is data-diverse with respect to the interface S1, which means that, in the exemplary embodiment depicted, separate address spaces and diverse data formats for data transfer are used for the two interfaces S1 and S2. Furthermore, the field device Fx has a computing unit 20, a memory 21 and an operating unit 22, which is provided with a keyboard and a display for on-site operation by a user 23. In the case of purely remote operation, the operating unit 22 can be omitted.

[0032] FIG. 3 shows an extract from the content of the memory 21 of the field device Fx (FIG. 2). A program segment for implementing an automatic state machine ZA with encoding of the respective states Z is deposited as part of the firmware. Further memory areas are provided to store the user parameters, SCUP, which can be input into the field device Fx via an operating unit 22 or transferred to the field device Fx via a first logical interface S1, and which are visually checked by the user for validation, and the installation parameters, SCIP, which can be verified via a function test. A serial number SN that is also deposited in the memory 21 is used for the unique identification of the field device Fx (FIG. 2). In addition, values of a first checking characteristic P1, which in the present application, is also referred to as a validation key, and a second checking characteristic P2, hereinafter also referred to as a fingerprint, are deposited in the memory 21. The fingerprint can also incorporate further parameters that are not relevant to safety. Hence, it can also be used for the unique characterization of a configuration. The calculation of the two checking characteristics P1 and P2 is performed within a field device via the computing unit 20 (FIG. 2) based on the user parameters, SCUP, and the serial number SN or based on the user parameters, SCUP, the installation parameters, SCIP, and the serial number SN. For this, a cyclic redundancy check (CRC) function is used in each case. As already described in DE 10 2010 062 908 B4 mentioned in the introduction, it is obviously also alternatively possible to use other known methods to calculate checking characteristics. Another possibility would be a hash function, a simple checksum, a message integrity code (MIC) or a message authentication code (MAC). This list is not complete. An important factor in the selection of the method is a low probability of any other configuration leading to the same result with the calculation of the checking characteristic. In addition, a first checking characteristic P1 received by the field device during the performance of the method can be deposited in the memory 21.

[0033] FIG. 4 is a simplified depiction of an automatic state machine ZA implemented in the field device Fx (FIG. 2). The automatic state machine ZA ensures that a prespecified procedure is observed during the commissioning of the field device. The section of the automatic state machine ZA depicted includes the states unsafe mode 40, validation 41A of the user parameters, SCUP, validation 41B of the installation parameters, SCIP, and safe mode 42. Before a change of state occurs, a check is performed to ensure the request for the change of state is correctly assigned to the respective field device. For this, the automatic state machine ZA checks the serial number SN (FIG. 3) of the field device. If the serial number does not match, then the request is discarded. The use of the automatic state machine ZA, internally calculated checking characteristics P1 and/or P2 and the individual serial number as a device ID excludes the possibility of deviations from the prespecified course, corruption of the parameters or a faulty device assignment. In addition, a plausibility check of the selected parameterization can be performed in the respective field device. Parameters that conflict with the safe mode block transition from the unsafe mode 40 to validation 41A, 41B. The parameters conflicting with the safe mode can be displayed to a user on the display of the operating unit 22 (FIG. 2) or the operating unit 6 (FIG. 1) so the user can effect a remedy by changing the parameters suitably.

[0034] Before validation is entered, the field device has been completely parameterized, such as via SIMATIC PDM over the interface S1 (FIG. 2). Each field device has a unique identification feature, a device ID, which is stored in the field device and output on the display of the operating unit 6 (FIG. 1) of the engineering system on each input dialog for checking by the user. The display can, for example, have the following appearance:

[0035] Tag: KV1474-F30

[0036] Product name: SITRANS P 410

[0037] Serial number: 12345678-12345

[0038] For this, the serial number can, for example, be read out via the interface S1 (FIG. 2) for the engineering system. In addition, this identification feature can also be applied on the housing of the device. The user is required to record the identification feature and to verify on each input dialog that the correct field device is addressed with the dialog.

[0039] Write protection is provided for the device parameters to exclude the possibility of the parameters being changed by unauthorized users or because the device is addressed incorrectly. Transition from the safe mode 40 to validation 41A, 41B is only possible when write protection is activated for the parameters SCUP and SCIP. For the validation process, the write protection is partially deactivated for the user so that only the user inputs required for changing the state of the field device according to FIG. 4 can be performed.

[0040] Proceeding from the state 40, the unsafe mode, if the user wishes, it is then possible to follow a direct path 43 to enter the state 42, the safe mode. The user is responsible for the functional safety of his/her plant and is hence responsible for deciding whether or not validation should be performed. This path 43 should only be taken if it can be ensured that parameterization was correct on the delivery of the field device. Therefore, this is not recommended and is only possible with on-site operation on the field device.

[0041] On the other hand, a path 44 for entering the state 41A in which first a validation of the user parameters, SCUP, is performed is recommended.

[0042] If the fact that the user parameters, SCUP, have already been validated is deposited in the field device memory, then they do not need to be validated again and this step can be skipped. For this, the state of a successful validation of the user parameters, SCUP, is stored in the field device thus enabling, in the event of validation being interrupted, for example, after an on/off cycle, re-entry after the most recently completed step of the validation of the user parameters, SCUP.

[0043] If no previous validation of the user parameters, SCUP, has occurred, to enable the validation of the user parameters, SCUP, to be performed by the computing unit 20 (FIG. 2) on the basis of the user parameters, SCUP, and the device ID received via the interface S1 (FIG. 2) and deposited in the memory 21 (FIG. 3), a first checking characteristic P1 (FIG. 3), the so-called validation key is then calculated and stored in the memory 21 (FIG. 3). The validation key P1 is transferred to the engineering station 4 (FIG. 1) as a character string via a second logical interface, which in the example described is identical to the first logical interface S1. In addition, the user parameters, SCUP, are transferred to the engineering system 4 (FIG. 1) via a third logical interface which, in the present application, is identical to the logical interface S2 and data-diverse with respect to the first logical interface S1, in the form of one or more strings. The transfer in string format is only an example of diversity of data transfer. However, also conceivable would be a transfer as an integer instead of a floating-point number or a bit-inverse representation of the transferred data in each case.

[0044] Data diversity between the first logical interface S1 and the third logical interface S2 is achieved because an additional address space is used for access via the third logical interface S2 and because, when the parameters are transferred via the first logical interface S1, the data is represented in the form originally defined in the transfer protocol, such as parameterization via SIMATIC PDM, while in the case of back-transfer via the third logical interface S2, a string representation is used. The calculation of the validation Key P1 inter alia includes the device ID. Consequently, the validation key is then unique for each field device even if the parameterization of different field devices is identical. This is, for example, advantageous with a redundant 1oo2 (1 out of 2) architecture in which two field devices of the same type are used.

[0045] In addition to the above-described output of the device ID, the user parameters, SCUP, communicated by the field device and the validation key are output on the display of the operating unit 6 of the engineering system 4 (FIG. 1) and in one example depicted as follows with only one user parameter Measurement Range:

[0046] Measurement Range: 100 mbar

[0047] validation key: 56789.

[0048] For validation, the user now verifies the correctness of the user parameters, SCUP, and the device ID displayed on the operating unit 6 of the engineering system 4 (FIG. 1), and to confirm their correctness enters the value of the validation key displayed in an input field offered on the display of the operating unit 6. When the validation key has been entered correctly, the user can press a button Start Function Test or a button: Skip Function Test to acknowledge the correctness of the displayed values and at the same time select whether there should be a transition from the state 41A via a path 45 into the state 41B, in which the function test is performed or via a path 46 directly into the state 42, namely the safe mode. It should be understood, a button Cancel is also provided in addition to the two above-described buttons. If the parameterization has faults, then the user can cancel the validation at this point. The field device then changes from the state 41A via a path 47 into the state 40, the unsafe mode.

[0049] When the correctness of the displayed values has been acknowledged, the validation key input is transferred via a fourth logical interface, which is formed as data-diverse with respect to the second logical interface S1, to the field device where it is deposited as a received first checking characteristic P1 in the memory 21. In the described exemplary embodiment, data diversity is achieved because the back-transfer of the validation key to the field device occurs as a pure numerical value, while a string format is used for the transfer of the validation key calculated in the field device to the engineering station. It should be understood, the required data diversity could alternatively be achieved with reversed data formats for the two transfer directions. The fourth interface used can, for example, be the same interface S2 that is already used to implement the third logical interface.

[0050] Transition into the state 41B or 42, only occurs in the event, that it is established in the field device that the received validation key P1 matches the validation key P1 calculated previously by the field device. In addition, the validation key P1 is rejected by the field device if the third logical interface S2 was not used for the back-transfer of the user parameters, SCUP, from the field device to the engineering system.

[0051] A change of state results in a change to the value of the state code Z (FIG. 3) deposited in the memory 21. As a result, the state of acknowledgement, i.e., the progress achieved in the parameterization of the field device, is also stored in the field device after on/off cycles. The field device calculates a second checking characteristic P2 (FIG. 3), the so-called fingerprint, and deposits this in the memory 21. The calculation of the fingerprint P2 is based on complete parameterization, i.e., the user parameters, SCUP, and the installation parameters, SCIP, and the device ID of the field device. This fingerprint P2 can, on the one hand, be requested by a user 23 on the display of the operating unit 22 of the field device Fx (FIG. 2) 23 and is also, for example, transferred to the engineering system 4 via the logical interface S1 (FIG. 1) so that the value of the fingerprint P2 is output on the remote display of the operating unit 6 (FIG. 1). The display of the fingerprint, for example, in a line Fingerprint: 34512

[0052] in turn occurs jointly with the above-described display of the device ID thus enabling unique assignment to the respective field device. The user can record the respective value of the fingerprint P2 for the field device in the user documents thus enabling the validity of the parameterization with reference to the fingerprints P2 even after on/off cycles. This ensures the integrity of the parameterization even after downtimes and despite any concurrent accesses to the parameterization of the field device. If a value of the fingerprint P2 currently calculated by the field device no longer matches the recorded value, a change to the parameterization of the field device is identified and the user can verify the parameterization and if necessary, perform a re-parameterization and validation.

[0053] Although it is possible to skip the function test in accordance with the path 46 in FIG. 4, this is not recommended. To ensure functional safety, the user should select the path 45 for the progress of the parameter validation and for performing the function test in the state 41B of the field device. If the function test is passed, then the correctness of the installation parameters, SCIP, should also be checked and transition into the state 42, safe mode, in accordance with a path 48 is possible. To activate the safe mode, the user actuates a button Function Test Passed and Fingerprint Valid. If, on the other hand, the user establishes a fault during the function test, a button Functional Commissioning Test Failed can be pressed and the field device changes, in accordance with a path 49, to the state 40, i.e. into unsafe mode.

[0054] Following the parameterization of a field device, the recommended method, controlled by the automatic state machine ZA (FIG. 3), requires two steps for transition from the unsafe mode, corresponding to state 40 in FIG. 4, into the safe mode, state 42:

[0055] First step: Verification of correct parameterization and the validation thereof with the aid of the validation key P1, which includes the device ID, and

[0056] Second step: Confirmation that a function test has been passed with a new display of the device ID to ensure input to the correct field device.

[0057] For a transition from the safe mode into the unsafe mode, the automatic state machine again requires two steps, although these are not depicted in FIG. 4 for purposes of clarity:

[0058] First step: The user requests the desired transition and confirms the device identification and

[0059] Second step: The user reconfirms the request for the desired transition.

[0060] Only then does the state of the field device change to the unsafe mode. If the input of the confirmation required in the second step does not take place within a prespecified time, then the field device returns to the state safe mode.

[0061] For purposes of clarity, FIG. 4 does not depict any further states, such as a safety-fault state. A method for confirming safety faults established in the safe mode, requires a user to check the device ID first. The identified field device only changes to the unsafe mode after confirmation. Therefore, the field device remains in the safety-fault state until the user sends the command to acknowledge, which the device ID contains as a token. It is, therefore, also possible in an advantageous development of the method to leave a fault state and, after revalidation to change back to the safe mode if no permanent error was established without on-site operation of the device being required.

[0062] FIG. 5 is a flowchart of the method for parameterizing a field device with at least one parameter, where the at least one parameter SCUP is input into the field device Fx via an operating unit 22 or transferred to the field device Fx via a first logical interface S1 and deposited in a memory 21 of the field device Fx. In accordance with the method of the invention, the field device Fx calculates, based on at least the deposited at least one parameter SCUP and a device ID SN of the field device Fx, a first checking characteristic P1, where the first checking characteristic is also deposited in the memory 21 and transferred via a second logical interface S1 to an engineering system 4 and output on a display 6.

[0063] The method comprises, transferring, by the field device Fx, the at least one parameter SCUP via a third logical interface S2 which is data-diverse with respect to the first interface to the engineering system 4 and outputting the at least one parameter SCUP on the display 6, as indicated in step 510. Next, the device ID SN is transferred by the field device Fx to the engineering system 4 and output on the display 6, as indicated in step 520.

[0064] Next, a first checking characteristic P1 input by a user after visual checking the at least one parameter SCUP and the device ID SN on the engineering system 4 in a predefined format is transferred to the field device Fx via a fourth interface S2 which is data-diverse with respect to the second interface, as indicated in step 530.

[0065] Next, the received first checking characteristic P1 comparing by the field device Fx to the calculated first checking characteristic P1 to validate the at least one parameter SCUP, as indicated in step 540.

[0066] Thus, while there have been shown, described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.