Method for managing an active field device, and corresponding system

Abstract

The invention discloses a method for managing an active field device (FG), having the steps of: operating a ticket server (TS); linking an operating unit (BE1) to the ticket server (TS); logging into the active field device (FG) by manually inputting access data, the log-in step being carried out only once; by means of the operating unit (BE1), changing the log-in access data for the active field device (FG); storing the access data in the operating unit (BE1); by means of the operating unit (BE1), creating a ticket containing the current access data for accessing the active field device (FG); transferring the ticket (T) to the ticket server (TS); and storing the current access data for accessing the active field device (FG). The invention also relates to a system for carrying out the method.

Description

[0001] Procedure for managing an existing field device and corresponding system

[0002] The invention relates to a method for managing an inventory field device and a system designed for carrying out the method.

[0003] Field devices are already known from the state of the art and are used in industrial plants. They are widely employed in process automation as well as in manufacturing automation. Field devices are defined as all devices that are used close to the process and that provide or process process-relevant information. Thus, field devices are used to acquire and / or influence process variables. Measuring instruments or sensors are used to acquire process variables. These are used, for example, for measuring pressure and temperature, conductivity, flow rate, pH, level, etc., and acquire the corresponding process variables such as pressure, temperature, conductivity, pH value, level, and flow rate. Actuators are used to influence process variables.These include, for example, pumps or valves that can influence the flow of a liquid in a pipe or the fill level in a container. In addition to the aforementioned measuring devices and actuators, field devices also include remote I / Os, radio adapters, and generally any devices located at the field level.

[0004] A large number of such field devices are produced and distributed by the Endress+Hauser Group.

[0005] In modern industrial plants, field devices are typically connected to higher-level units via communication networks such as fieldbuses (Profibus®, Foundation® Fieldbus, HART®, etc.). These higher-level units are usually control systems (DCS) or automation systems, such as a PLC (programmable logic controller). The higher-level units are used, among other things, for process control, process visualization, process monitoring, and commissioning of the field devices. The measured values ​​acquired by the field devices, especially sensors, are transmitted via the respective bus system to one (or possibly several) higher-level unit(s). In addition, a

[0006] Data transmission from the higher-level unit via the bus system to the field devices is required, especially for the configuration and parameterization of field devices and for the control of actuators.

[0007] Mobile control units can also be used to operate field devices. For example, there are control units that connect to the fieldbus network. The control unit can also communicate with the field devices via a wireless connection, particularly based on a Bluetooth standard. The applicant manufactures and distributes devices that, as so-called Bluetooth gateways, allow the connection of control units to the field devices. The field device is connected to a Bluetooth gateway via a wired connection, particularly using the HART or CDI communication standards. Alternatively, the field devices themselves have their own Bluetooth interfaces.

[0008] In the case of using a mobile device, such as a smartphone or tablet, as an operating unit for wireless communication with the field devices, application programs, so-called apps, are available which provide the operating functions for the field device to the mobile device.

[0009] In industrial environments, most installed field devices have no or only very basic protection against unauthorized access. This means that all device parameters can usually be accessed directly or, for example, after entering an unlock code. Due to the Federal Security Act, field devices with individual user accounts and role-based authorization are increasingly coming onto the market. Access via a user or machine interface therefore requires a kind of "permanent" authorization, which is usually granted through prior authentication.

[0010] To reduce the administrative burden of managing individual field devices to an acceptable level, some efforts are being made to establish centralized management, similar to the long-standing practice in the IT sector for managing IT equipment (e.g., printers, workstations, etc.). An example of such a concept is disclosed in DE 102018 102 608 A1, which describes a transport device onto which user data is transferred from a user database. After verifying the user data, the field device is granted access to it.

[0011] There are also ideas for limiting the access permissions required by humans to a minimum. For example, German patent DE 10 2019 131 860 A1 discloses the use of a digital ticket, which is transmitted from a server ("ticket server") to the mobile device and contains the access rights and authorized tasks for the field device. This ticket is transmitted when a connection is established with the field device. With the appropriate authorization, the tasks specified in the ticket, such as parameterization actions or performing functional tests, can be processed using the field device.

[0012] Under the assumed conditions, the field devices and their configuration interfaces are well protected, and only authenticated and authorized users have access, for example, to configure the device.

[0013] However, entering user data, such as username and password, via the control unit every time a field device is operated is error-prone and time-consuming.

[0014] For online field devices, meaning field devices permanently connected to an IP-enabled network, "Single Sign-On" (SSO) solutions are commonly used, for example, via OIDC / OAuth2, as specified by OPC UA Security and CIP Security, and prevalent on the internet. Established solutions also exist in enterprise IT environments, such as MS Active Directory or LDAP. The vast majority of field devices have significant resource limitations (e.g., low permissible power consumption in explosive environments, limited storage capacity, low processing power, etc.) and are mostly connected to the control system via 4–20 mA or HART. Even in systems using the PROFINET fieldbus standard, for example, the field devices are often decoupled from the system bus via remote I / Os.They therefore do not have a permanent connection to an IP-enabled network, unlike online field devices, which, however, are very rarely used in plants. Nevertheless, offline field devices also have additional digital configuration interfaces (for example, a local display, Bluetooth interfaces, a point-to-point web server, etc.) that necessitate the access control for user accounts described above.

[0015] The method mentioned above and presented in DE 10 2019 131 860 A1 cannot be readily implemented using existing field devices. This is because the field device must possess the necessary functionalities and corresponding software interfaces, which may not be retrofittable.

[0016] A plant operator who operates both "new" and "old" field equipment must therefore manage two different systems in parallel.

[0017] The document, which was still unpublished on the filing date of the present document,

[0018] German patent DE 102023 128 606 discloses a method for centralized user management, even for existing field devices (so-called "brownfield" field devices), without modifying the software or hardware of the field devices. Separate software or hardware is used. The core of the method consists of the transport device performing a "mapping," i.e., a transformation, between the ticket, which is created and transmitted from a user database, and an operator telegram, which is transmitted to the field device.

[0019] The invention is based on the objective of providing a means to manage existing field devices and to ensure secure access to them. This objective is achieved by a method according to claim 1 and by a system according to claim 9.

[0020] Specifically, the solution involves a process comprising the following steps: operating a ticket server; and linking a control unit to the ticket server; logging into the existing field device by manually entering the access data, whereby this step is only performed once; changing the access data for logging into the existing field device by the control unit; saving the access data on the control unit; creating a ticket from the control unit with the current access data for the existing field device; transferring the ticket to the ticket server; and saving the current access data for the existing field device.

[0021] With the idea according to the invention, it is possible to use software in the control unit to “pretend” or simulate an existing field device.

[0022] To implement this idea, a ticket server is required, which is in a mutual, cryptographic trust relationship with the operating units.

[0023] "Mutual cryptographic trust" means that the components have been mutually acquainted beforehand. The ticket server and field device have therefore performed mutual authentication. For this purpose, cryptographic information, such as the public key of a key pair, was exchanged (for example, via a Diffie-Hellman key exchange). Thus, the data exchange between the respective components that possess this trust fulfills the security objectives of "integrity," "confidentiality," and "availability." A ticket can include a digital signature to confirm its authenticity (the ticket has not been altered) and / or to confirm the authenticity of the ticket server. In other words, the field device "trusts" the ticket and its contents because the field device and the ticket server have a mutual trust relationship.

[0024] Examples of field devices have already been listed in the introductory part of the description. Network components, such as edge devices and gateways, also fall under the definition of a field device within the scope of the invention described here.

[0025] One embodiment provides that the step "Login to the existing field device by manually entering the access data" is performed by connecting the control unit to the existing field device, particularly wirelessly via Bluetooth, and by manually entering the access data on the control unit. Another embodiment provides that the step "Login to the existing field device by manually entering the access data" is performed by entering the access data directly on the existing field device, whereby the existing field device is put into a state to be connected to a control unit, particularly wirelessly via Bluetooth, and the control unit is selected.

[0026] One design provides for the following step: synchronizing the current access data for the existing field device with all operating units.

[0027] One design envisages the following step: Login to the existing field device via a control unit, without having to enter access data.

[0028] One configuration provides for the ticket server to be operated by the manufacturer of the existing field device.

[0029] One design allows for manual login directly on the existing field device using the current access data.

[0030] An advantageous design of the procedure provides that, after the validity period expires, the control unit is automatically logged out of the corresponding field devices. Re-registration with the ticket is then no longer possible.

[0031] According to an advantageous embodiment of the procedure, the access data includes a username and a password.

[0032] According to one embodiment, the ticket server is designed as an application within a cloud platform, using the same user data for authentication as it uses for authentication with the cloud platform itself. This allows the ticket server to be embedded in the user's existing cloud environment, thereby reducing the administrative overhead of managing numerous accounts across various services. The system is designed to implement the method according to the invention and comprises at least one physical device, a ticket server, and an operator panel.

[0033] One design of the system provides that the control unit is a mobile device, in particular a tablet or a smartphone.

[0034] One design provides for the mobile device to include a Secure Element.

[0035] This will be explained in more detail with reference to the following figure. Figure 1 shows the claimed system.

[0036] The invention is based on an established field device ticket server infrastructure. There is a ticket server (TS), which is operated, for example, by the field device manufacturer. Such a ticket server (TS) can be implemented, for instance, on the applicant's HoT infrastructure, such as the "Netilion" platform of the Endress+Hauser Group. Additional services can also be provided via this platform. Alternatively, the ticket server (TS) can be operated by the user themselves. The user typically operates a large number of different field devices. The "user" is, for example, a plant operator.

[0037] The facility includes several new field devices that are compatible with the one from the

[0038] DE 10 2019 131 860 A1 known procedures for field device management and user management are managed and administered.

[0039] The system also contains several legacy field devices that cannot be administered via this method. One such legacy field device (FG) is shown. The operator wants to manage the "new" field devices and the legacy field devices (FG) in the same way as possible. The legacy field devices (FG) have a wireless interface, such as Bluetooth. These devices are offline, meaning there is no direct communication connection with the ticket server (TS).

[0040] A claimed system comprises the ticket server, one or more inventory field devices FG, and one or more operator units BE1, BE2. The operator unit BE1, BE2 is, in particular, a mobile device, such as a smartphone or tablet. The operator unit BE1, BE2 also has a wireless interface, specifically a Bluetooth interface.

[0041] The operator devices BE1 and BE2 are linked to the ticket server TS via a "join process." A join process between operator devices BE1 and BE2 and the ticket server TS has already been performed, resulting in a cryptographically secured, mutually trusted relationship between the ticket server TS and the operator devices BE1 and BE2. The join process involves the creation and sending of join tickets from the ticket server TS to the operator devices BE1 and BE2, thereby transmitting cryptographic information, specifically designed for calculating (symmetric) keys. Cryptographically relevant information is exchanged beforehand, for example, in the form of a public key from each key pair, to then verify authenticity and integrity.

[0042] User BN has an account on the inventory field device FG shown here. According to the invention, the following steps are now performed.

[0043] The user logs into the existing field device (FG) by manually entering their access data, a step that is only performed once. The access data includes the username and a corresponding password. These existing field devices are field devices without user management; that is, there is only one type of user, usually with extensive rights, for example, as an "administrator." For this type of device, a device-specific password is often assigned, such as the serial number or similar. This password is often not changed.

[0044] The login process can be performed in two different ways: either by wirelessly connecting, for example via Bluetooth, the BE1 control unit to the FG field device and manually entering the access data on the BE1 control unit, thereby granting access to the field device. The control unit includes a corresponding app (A) for this purpose. Alternatively, this step is performed by entering the access data directly on the FG field device. Then, if not already done, the FG field device is put into a state that allows it to be wirelessly connected to the BE1 control unit, for example via Bluetooth. App A can also be used for this. Finally, the FG field device is connected to the BE1 control unit.

[0045] The access data for logging into the existing field device FG is then changed by the operating unit BE1 and stored on the operating unit BE1. For this purpose, the operating unit BE1 includes a memory module M, primarily designed as a secure element. Memory module M is thus linked to the hardware of the operating unit BE1.

[0046] The changed access data, especially the password, is specific to the existing field device FG and is significantly more complex than the initial password. For example, the password now contains considerably more characters than before, approximately 12 characters or more, including uppercase and lowercase letters, special characters, etc.

[0047] The control unit BE1 thus includes, for example as part of App A, a central security component, a so-called Field Device Authentication Module (FDAM). In newer field devices, the FDAM is integrated into the field device itself. During the current login process, the FDAM is simulated in the control unit BE1 / BE2 using a subset of the functionalities of a field device FDAM. Sensitive data, such as logbooks, account databases, keys, certificates, and interface configurations, are stored encrypted in this FDAM. This data is encrypted using a key generated from a master key stored in the device's memory chip. Since this master key is unique for each manufactured memory chip, the encrypted data is bound to this key.

[0048] Finally, the operator unit BE1 creates a ticket T (see below) containing the current access data for the existing field device FG. This ticket T is transferred to the ticket server TS, where the current access data is stored. The transfer occurs, for example, via mobile network or Wi-Fi. A validity period for the ticket can also be defined if required. Depending on the criticality of the system and standard operational procedures, the validity period is variable (e.g., hours, for this shift, etc.). Whenever the access data is changed via an operator unit, it is transferred to the ticket server TS via ticket T. The ticket T contains, or corresponds to, a transaction. A transaction is generally a sequence of program steps that are considered a logical unit because, after error-free and complete execution, they leave the data in a consistent state.Therefore, a transaction is required to be either fully and error-free or not executed at all.

[0049] A ticket generally defines order data for a work order to be carried out. This order data can include, for example, the following: unique identification of the service employee or user, the field device, the work order (e.g., maintenance, activation of a defined parameter, calibration, replacement of the field device, etc.), and, if applicable, the time period in which the work order is to be carried out.

[0050] In this document, a "ticket" primarily refers to the following two aspects: First, a ticket contains the access data for a field device (FG) as described above and is transferred from the operating unit (BE1) to the ticket server (TS). Second, a ticket (T) enables login to the field device (FG) using an authorized device, an operating unit (BE1, BE2), or an authorization tool. To allow access to the field device (FG) from other operating units, the current access data for the existing field device (FG) is synchronized with all operating units (BE1, BE2). The current access data is thus collected centrally in the ticket server (TS) and distributed to all operating units (BE1, BE2), enabling access to the existing field device (FG) from all operating units (BE1, BE2).

[0051] By submitting ticket T to field device FG, user BN is automatically authorized to execute the work order. The ticket thus contains the access authorization (login credentials) for field device FG. Ticket T therefore serves as an identifier (e.g., user's name) and as an authenticator (e.g., it contains a password or password equivalent for direct access to the field device), and it also includes the authorization to operate the field device accordingly. By using a password equivalent instead of a password, the actual password does not need to be disclosed. The password may also have a limited validity period. Therefore, when the user submits ticket T to the field device, the login credentials are automatically transmitted to the field device. After the order has been completed, ticket T automatically becomes invalid.The ticket is encrypted with a shared symmetric key and secured with HMAC (e.g., ChaCha20-Poly1305) and contains the defined validity period and login information, such as the username of user BN and a password verifier (an intermediate value for a cryptographic function used by the field device and operator unit to determine a shared symmetric key for the field device and operator unit) from the ticket server TS database. Alternatively, a plaintext password or a random temporary password can be included instead of the password verifier. Logging into the existing field device FG via an operator unit BE1 or BE2 is therefore possible without having to enter any access data. However, the alternative method of manual login directly at the existing field device FG using the current access data remains available. Depending on the complexity of the access data, this method is considerably longer.

[0052] In one process step, user BN logs in to the field device FG. User BN is physically present at the field device FG and selects it to establish a connection (for example, by selecting it from a LiveList). If the field device FG can verify this as valid and the login time falls within the defined validity period, user BN logs in to the field device FG using their operating unit BE1.

[0053] Reference symbol list

[0054] An App

[0055] BE1, BE2 Control unit BN User / User

[0056] FG stock field device

[0057] M storage as a Secure Element

[0058] T Ticket

[0059] TS Ticketserver

Claims

Patent claims 1. Procedure for managing an existing field device (FG), comprising the following steps: - Operating a ticket server (TS); and - Linking a control unit (BE1) to the ticket server (TS); - Login to the existing field device (FG) by manually entering the access data, whereby this step is only performed once; - Changing the access data for logging into the existing field device (FG) via the operating unit (BE1); - Saving the access data on the control unit (BE1); - Creating a ticket from the control unit (BE1) with the current access data for the existing field device (FG); - Transferring the ticket (T) to the ticket server (TS); and - Saving the current access data for the existing field device (FG).

2. Method according to claim 1, wherein the step “login to the existing field device (FG) by manual entry of the access data” is carried out by, in particular wirelessly, connecting the operating unit (BE1) to the existing field device (FG), in particular by Bluetooth, and manually entering the access data at the operating unit (BE1).

3. Method according to claim 1, wherein the step “Login to the existing field device (FG) by manual entry of the access data” is performed by entering the access data directly on the existing field device (FG), wherein the existing field device (FG) is put into a state to be connected to an operating unit (BE1), in particular wirelessly, in particular via Bluetooth, and the operating unit (BE1) is selected.

4. Method according to any of the preceding claims, comprising the step - Synchronize the current access data for the existing field device (FG) with all operating units (BE1 , BE2).

5. Method according to any of the preceding claims, comprising the step - Login to the existing field device (FG) via an operating unit (BE1 , BE2) without having to enter access data.

6. Method according to one of the preceding claims, wherein after the step “changing the access data for the login on the existing field device (FG) by the operating unit (BE1)” the following step is performed: - Transferring a password verification key and a string from the operator unit (BE1 , BE2) to the inventory field device (FG), wherein the password verification key in the operator unit (BE1 , BE2) is calculated based on the changed access data, in particular using scrypt and an elliptic curve, in particular Curve25519.

7. Method according to one of the preceding claims, wherein the ticket server (TS) is operated by the manufacturer of the existing field device (FG).

8. Method according to one of the preceding claims, wherein a manual login directly on the existing field device (FG) is enabled with the current access data.

9. System designed to carry out the method according to one of claims 1 to 7, comprising at least one inventory field device (FG), a ticket server (TS) and an operating unit (BE1).

10. System according to claim 8, wherein the control unit (BE1 , BE2) is a mobile terminal, in particular a tablet or a smartphone.

11. System according to claim 9, wherein the mobile terminal comprises a Secure Element.

Images