Procedure for managing an existing field device and corresponding system

Abstract

The invention discloses a method for managing an existing field device (FG), comprising the steps of: operating a ticket server (TS); and linking an operator unit (BE1) to the ticket server (TS); logging into the existing field device (FG) by manually entering the access data, wherein this step is performed only once; changing the access data for logging into the existing field device (FG) by the operator unit (BE1); saving the access data on the operator unit (BE1); creating a ticket from the operator 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). The invention further discloses a system for carrying out the method.

Description

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

[0002] 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.

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

[0004] In modern industrial plants, field devices are usually connected via communication networks such as fieldbuses (Profibus). ® Foundation ® Fieldbus, HART ®, etc.) are connected to higher-level units. These higher-level units are typically control systems (DCS) or control units, 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). Data transmission from the higher-level unit to the field devices via the bus system is also necessary, particularly for configuring and parameterizing field devices and for controlling actuators.

[0005] Mobile control units can also be used to operate field devices. For example, there are control units that connect to the fieldbus network. However, 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.

[0006] 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.

[0007] 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.

[0008] To reduce the administrative burden of managing individual field devices to an acceptable level, some efforts are being made to establish a centralized management system, 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 10 2018 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] For online field devices, meaning field devices that are 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 which are also prevalent on the internet. Established solutions also exist in enterprise IT environments, such as MS Active Directory or LDAP.

[0013] 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, 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 rare in plants. Nevertheless, offline field devices also have additional digital configuration interfaces (e.g., a local display, Bluetooth interfaces, a point-to-point web server, etc.) that necessitate the access control for user accounts described above.

[0014] 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.

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

[0016] The German patent application DE 10 2023 128 606, which was still unpublished on the filing date of this document, discloses a method for centralized user management, even for existing field devices (so-called "brownfield" field devices), without requiring any changes to the software or hardware of the field devices. Separate software or hardware is used. The core of the method consists of the transport medium performing a "mapping," i.e., a transformation, between the ticket, which is created and transmitted by a user database, and an operator telegram, which is transmitted to the field device.

[0017] The invention is based on the objective of providing a way to manage existing field devices and to make access to them secure.

[0018] The problem is solved by a method according to claim 1, and by a system according to claim 9.

[0019] 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.

[0020] 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.

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

[0022] "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.

[0023] 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.

[0024] One design provides that the step "Login to the existing field device by manual entry of the access data" is carried out by, in particular wirelessly, connecting the control unit to the existing field device, in particular via Bluetooth, and by manually entering the access data on the control unit.

[0025] One embodiment provides that the step "Login to the existing field device by manual entry of the access data" is carried out 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 an operating unit, in particular wirelessly, especially via Bluetooth, and the operating 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 implementation, the ticket server is designed as an application within a cloud platform, using the same user credentials for authentication as it uses for authentication with the cloud platform itself. This allows the ticket server to be embedded within the user's existing cloud environment, thereby reducing the administrative overhead of managing numerous accounts across various services.

[0033] With regard to the system, it is provided that the system is designed to carry out the method according to the invention and comprises at least one inventory field device, a ticket server and an operating unit.

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

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

[0036] This will be explained in more detail using the following figure. It shows Fig. 1 the claimed system.

[0037] 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 IIoT 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.

[0038] The plant contains several new field devices which are managed and administered using the field device management and user management procedure known from DE 10 2019 131 860 A1.

[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 includes the ticket server, one or more existing field devices FG and one or more operator units BE1, BE2.

[0041] The control unit BE1, BE2 is primarily a mobile device, such as a smartphone or tablet. The control unit BE1, BE2 also has a wireless interface, specifically a Bluetooth interface.

[0042] 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 transmission 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.

[0043] User BN has an account on the inventory field device FG shown here.

[0044] According to the invention, the following steps are now carried out.

[0045] 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.

[0046] 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, thus 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.

[0047] 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.

[0048] 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.

[0049] The BE1 control unit 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 BE1 / BE2 control unit using a subset of the functionalities of a field device FDAM. Sensitive data, such as logs, 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.

[0050] 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.

[0051] 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 executed either completely and without errors, or not at all.

[0052] 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.

[0053] 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, login to the field device (FG) is possible using an authorized device, an operating unit (BE1, BE2), or an authorization tool via a ticket (T). To enable access to the field device (FG) with other operating units as well, 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).

[0054] By submitting ticket T to field device FG, user BN is automatically authorized to carry out 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.

[0055] 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. Reference symbol list An App BE1, BE2 Control unit BN Users FG stock field device M storage as a Secure Element T Ticket TS Ticketserver QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] DE 10 2018 102 608 A1

[0008] DE 10 2019 131 860 A1 [0009, 0014, 0038] DE 10 2023 128 606

[0016]

Claims

[1] Procedure for managing an inventory field device (FG), comprising the 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 on 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 - Synchronizing the current access data for the existing field device (FG) with all operating units (BE1, BE2). [5] Method according to any one 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 to the existing field device (FG) by the operating unit (BE1)” the following step is performed: - Transferring a password verification key and a salt 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 any 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 which is designed to carry out the method according to any one of claims 1 to 7, comprising at least one inventory field device (FG), a ticket server (TS) and an operator 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 includes a Secure Element.

Images