Method for gaining permitted access to a field device to be serviced, and corresponding system

Abstract

The invention discloses a method for gaining permitted access to a field device (FG) to be serviced by a service technician (BN), comprising the following steps which are carried out by the manufacturer of the field device (FG): operating a ticket server (TS); linking the field device (FG) to the ticket server (TS); creating an account for a service technician (BN) with access data and specific access rights to the field device (FG) on the ticket server (TS); and activating the receipt of account tickets (T) in the field device (FG); and comprising the following steps which are carried out by the user: determining an identifier for the field device (FG); linking the field device (FG) to the service technician's (BN) account on the ticket server (TS); having the ticket server (TS) generate an account ticket (T) for the service technician (BN) for the field device (FG); registering a transport means on the ticket server (TS) and transmitting the ticket (T) to the transport means; transporting the ticket (T) to the field device (FG) via the transport means; having the field device (FG) check the ticket (T) to ascertain whether the ticket (T) was actually created by the ticket server (TS); creating an account for the service technician (BN) on the field device (FG) with the specified access rights if the check is positive; and registering the service technician (BN) on the field device (FG) via the account. The invention also relates to a system for carrying out the method.

Description

[0001] Method for obtaining authorized access to a field device and corresponding system requiring maintenance

[0002] The invention relates to a method for obtaining authorized access to a field device requiring maintenance by a service technician and a system designed to carry 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 controllers, 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 controlling actuators.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 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 10 2018 102 608 A1, which describes a transport mechanism to 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 with the field device. For online field devices, i.e., field devices that are permanently connected to an IP-enabled network, "Single Sign-On" (SSO) solutions are known, for example, via OIDC / OAuth2, as specified by OPC UA Security and CIP Security, and which are also prevalent on the internet.There are also established solutions in the enterprise IT environment, such as MS Active Directory or LDAP.

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

[0011] Occasionally, a field device requires maintenance. This might involve firmware updates, calibrations, or cleaning parts of the device. These tasks are typically performed by a service technician. For this type of work, the technician needs access to the field device, specifically its software. This allows them to change settings or adjust parameters. The technician therefore requires certain access permissions to the field device.

[0012] Some field devices have an unlock code—a code that allows service technicians to access the device—hard-coded within the device itself. Unauthorized individuals could thus gain unrestricted access to the field device if they knew this code. It's also possible that access to the field device is possible using a known code, such as the serial number. This is not only insecure but also costly for the field device manufacturer to use the individual serial number as the unlock code.

[0013] The invention is based on the objective of providing a simple and safe way to grant service technicians access to a field device.

[0014] The problem is solved by a method according to claim 1 and by a system according to claim 10. Specifically, the solution is achieved by the following steps, which are performed by the field device manufacturer: operating a ticket server; linking the field device to the ticket server; creating a service technician account with access data and specific access rights for the field device on the ticket server; and activating the receipt of account tickets on the field device; as well as the steps performed by the user: determining an identifier for the field device; linking the field device to the service technician's account on the ticket server; generating an account ticket from the ticket server for the service technician for the field device; registering a means of transport with the ticket server and sending the ticket to the means of transport; transporting the ticket via the means of transport to the field device;The field device checks whether the ticket was actually created by the ticket server; if the check is successful, it creates an account for the service technician on the field device with the defined access rights; and the service technician logs in to the field device via this account.

[0015] To implement this idea, a ticket server is required, which is in a mutual, cryptographic trust relationship with the field devices and the operating unit required for offline operation.

[0016] "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.This document states that an additional functionality not previously activated for the specific field device is to be enabled.

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

[0018] In one embodiment, the means of transporting the ticket is a control unit, whereby the control unit connects to the field device, for example via Bluetooth, or a memory card, such as an SD card, or a digital protocol, for example HART, or whereby the field device is connected to the ticket server and the transport of the ticket takes place via this connection.

[0019] One design allows the service technician to log in to the account on the field device using the same access data as for the ticket server.

[0020] One implementation involves the service technician transmitting the identifier for the field device using their account on the ticket server.

[0021] One embodiment provides that the identifier for the field device is determined via a control unit. In one embodiment, the control unit is a mobile device, in particular a tablet or a smartphone. The identifier can be photographed or scanned by the control unit.

[0022] One implementation involves using the field device's serial number as the identifier. This can be printed on the field device numerically or alphanumerically. In one implementation, the identifier is printed in a machine-readable format, for example, as a QR code (generally as a two-dimensional code / barcode). This allows the control unit to easily read and transmit the identifier. Transmission can be done via an app.

[0023] One implementation involves using a cryptographic key pair with a private and a public key, specifically according to the IEEE 802.1AR standard. According to IEEE 802.1AR, a device receives an initial "Device Identifier" (IDevID) during the manufacturing process. This IDevID is a certificate issued by the manufacturer and stored in the manufacturer's database. The user retrieves the hash of the public key from the field device instead of its serial number and submits this value to the server. This allows the user to locate the corresponding field device. This hash could also be signed with the field device's private key. The manufacturer can then verify that the requester is indeed in possession of the device.

[0024] One implementation involves identifying numerous field devices requiring maintenance and creating an account ticket for each device. In this configuration, the access credentials are the same for all field devices.

[0025] One configuration involves granting the service technician temporary access to the field device account. Another configuration specifies that the point in time when the service technician gains access to the field device is in the future. This allows the necessary preparations for successful service work to be completed before the actual work begins.

[0026] An advantageous design of the procedure stipulates that, after the validity period expires, the account is automatically deactivated on the corresponding field device. Reactivation with the same ticket is not possible; a new ticket can reactivate access.

[0027] One implementation envisages that the ticket includes binary code for the account on the field device itself, for example as an executable file on the field device.

[0028] 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 field device, one ticket server and one operating unit.

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

[0030] This will be explained in more detail using the following figure.

[0031] Fig. 1 shows the claimed system.

[0032] The invention is based on an established field device ticket server infrastructure. There is a ticket server (TS) operated by the field device manufacturer (FG). The field device (FG) is linked to the ticket server (TS) via a "join process," as shown below. This is represented by a dotted line in Fig. 1. The linking process takes place, for example, during the production of the field devices, but in any case, before the field device (FG) is delivered to the respective user. The field device (FG) and the ticket server have performed a key exchange and, after a Diffie-Hellman key exchange, have determined the common symmetric key (secret). Cryptographically relevant information is thus exchanged beforehand, for example, in the form of a public key from each key pair, in order to subsequently verify authenticity and integrity.

[0033] The user typically operates a variety of different field devices; a single field device (FG) is shown. The "user" is, for example, a plant operator. Such a ticket server (TS) can be implemented, for instance, on the applicant's IoT infrastructure, such as the "Netilion" platform of the Endress+Hauser Group. Additional services can also be provided via this platform.

[0034] The field device FG has modules that handle user access management on the device side. Using this user access management, the user can create multiple users per field device, each with different access rights. Furthermore, the field device FG is configured to create and receive Tickets T (see below). Tickets are described, for example, in DE 10 2018 102 608 A1 and DE 10 2019 131 860 A1.

[0035] The field device FG includes a central security component, a so-called "Field Device Authentication Module" (FDAM). The FDAM in the field device FG verifies whether the ticket originates from the ticket server TS. Sensitive data, such as logs, account databases, keys, certificates, and interface configurations, are stored encrypted in this Field Device Authentication Module (FDAM). This data is encrypted, for example, 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 in this example is bound to this key. The FDAM is also responsible for decrypting the ticket. If necessary, a hash is used as protection against modification.

[0036] The field device FG can be an online field device, meaning it communicates directly with the ticket server TS via a network. However, in the case described in Fig. 1, the field device FG is an offline field device, meaning there is no direct communication connection with the ticket server TS. The tickets T can then be transmitted from the ticket server TS to the corresponding field device FG via a transport medium, such as an operator unit BE, and vice versa (see below). In principle, it doesn't matter how the ticket reaches the device, which is described in more detail below. The ticket's content is securely encrypted with this key and is unreadable and unusable by third parties.

[0037] A claimed system comprises the ticket server TS, one or more field devices FG and one or more operator units BE.

[0038] The operating unit BE is, in particular, a mobile device, such as a smartphone or tablet. The operating unit BE also has a wireless interface, specifically a Bluetooth interface. In one embodiment, the operating unit BE is linked to the ticket server TS via a "join process," but this is not a mandatory requirement for the claimed method to function. A join process between the operating unit BE and the ticket server TS has already been performed, resulting in a cryptographically secured, mutual trust relationship between the ticket server TS and the operating unit BE. The process is similar to the join process between the field device FG and the ticket server TS. The cryptographic trust relationship is symbolically represented by the dotted line in Fig. 1.The join process includes, for example, the creation and sending of join tickets from the ticket server TS to the operator unit BE, thereby transmitting cryptographic information, specifically designed for calculating (symmetric) keys, for example through a Diffie-Hellman key exchange. Cryptographically relevant information is exchanged beforehand, for example in the form of a public key from each key pair, in order to then verify authenticity and integrity.

[0039] The control unit BE runs one or more apps A, which are designed, among other things, to connect and configure the field device FG.

[0040] An account was created on the ticket server TS for a service technician BN, with login credentials and specific access rights for the field device FG. These access rights are granted, for example, to roles such as "Production", "Service", or "Developer".

[0041] The service technician (BN) can be an internal employee of the user. Alternatively, the service technician can be an employee of the field device manufacturer (FG) who comes to the plant operator's facility for a specific type of maintenance. A manufacturer's service technician may have different authorization than the customer's service technician. For example, the manufacturer's technician may be able to temporarily use features even if the customer has not (yet) purchased them, or make critical settings that could damage the device if used incorrectly.

[0042] The field device FG is designed to receive tickets in general, specifically account tickets T.

[0043] After the user orders the field device FG, the field device FG is delivered.

[0044] After some time in operation, a maintenance order is now placed, for example for calibration, repair or other reasons.

[0045] According to the invention, the following additional steps are now performed by the user: An identifier for the field device FG is determined, for example the serial number, for example via the operating unit BE.

[0046] Service technician BN logs into the ticket server TS and transmits the serial number (identifier) ​​of the field device FG on which the service is to be performed. This links the field device FG to service technician BN's account on the ticket server TS.

[0047] Then, the ticket server TS creates an account ticket T for the service technician for the specific field device FG, specifically for the service technician role with the appropriate access permissions. The account ticket T is cryptographically secured, meaning it is signed and encrypted. Generally, it is important that the field device FG, using the FDAM (see above), can decrypt and read the content. The content of ticket T can also be encoded as a bit string. In one implementation, the ticket and the corresponding data are specified according to Abstract Syntax Notation One (ASN.1), for example, encoded using Distinguished Encoding Rules (DER).

[0048] For example, a ticket can be several hundred bytes in size.

[0049] In other words, the account ticket T is created. The service technician BN receives an account with one of the system permissions "(Manufacturer) Service," "Developer," or "Production" for the field device FG. The link is established by using the symmetric key to encrypt ticket T, which is generated from the stored public key of the field device FG (identified, for example, by its serial number) and the private key of the ticket server TS. This ticket T can then only be decrypted by the one (correct) field device FG, and the account for the service technician BN is then created on the field device FG. Subsequently, the technician can log in to the device and operate with the appropriate permissions.

[0050] Ticket T contains, or corresponds to, a transaction. A transaction is 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 T is required to be executed either completely and without errors, or not at all.

[0051] A ticket generally defines order data for a work order to be carried out. This order data can include, for example, the following: login data, unique identifier 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. In this document, however, the primary purpose of a "ticket" is to create an account for the service technician (BN) on the field device (FG), enabling the service technician to log in to the field device. The ticket (T) therefore contains metadata that is at least partially specific to the respective field device, such as the serial number or another unique identifier.Furthermore, the ticket contains the "actual" content (often referred to as the "payload" in English). In this case, that means instructions for creating an account on the field device.

[0052] A transport device is registered with the ticket server TS, and the ticket T is sent to the transport device. This is indicated by reference numeral (1) in Fig. 1. The ticket T is then transmitted to the field device FG via any transport device, i.e., any data transmission channel – e.g., manually, via an operating unit, via a wireless or wired network (e.g., HART, Bluetooth) – or it is stored on a storage medium, e.g., a USB stick or SD card, and transmitted to the field device FG. The transport route via the operating unit BE is shown, which will be explained in more detail below.

[0053] Ticket T is transported and transferred to the field device FG via the transport means. This is indicated by reference numeral (2) in Fig. 1. For example, a connection is established, such as via Bluetooth, between the field device FG and the control unit BE using the app A, and ticket T is transferred in this way. The field device FG has, for example, an integrated Bluetooth interface.

[0054] The field device FG then checks whether ticket T was actually created by the ticket server TS. More precisely, the FDAM validates and decrypts the ticket.

[0055] If the test is positive, an account for the service technician BN is created on the field device FG with the defined access rights and, if applicable, the stored validity period.

[0056] Finally, the service technician BN logs in via the account on the field device FG. The service technician BN can now log in with the same password as on the ticket server TS. Furthermore, the service technician BN now has access to the field device FG with the rights he has assigned to the ticket server TS. Thus, the service technician BN can log in to the field device FG via various interfaces for his service activities.

[0057] User BN logs into the field device FG using their access credentials. 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). Login is via username and password. If the field device FG can verify the validity of these credentials and the login time falls within the defined validity period, user BN logs into the field device FG using their control unit BE. Access to the field device FG is then granted according to the assigned access rights.

[0058] Reference symbol list

[0059] An App

[0060] BE control unit

[0061] BN User / User / Service Technician

[0062] FG Field Device

[0063] T Ticket

[0064] TB Confirmation Ticket

[0065] TS Ticketserver

[0066] ZF additional functionality from FG

Claims

Patent claims 1. Procedure for a service technician to obtain authorized access to a field device (FD) to be serviced, comprising the steps to be carried out by the field device (FD) manufacturer: - Operating a ticket server (TS); - Linking the field device (FG) to the ticket server (TS); - Creating a service technician (BN) account with login credentials and specific access rights for the field device (FG) on the ticket server (TS); and - Enabling the receipt of account tickets (T) in the field device (FG); and comprehensively the steps to be performed by the user: - Determining an identifier for the field device (FG); - Linking the field device (FG) to the service technician's (BN) account on the ticket server (TS); - Generating an account ticket (T) from the ticket server (TS) for the service technician (BN) for the field device (FG); - Registering a means of transport with the ticket server (TS) and sending the ticket (T) to the means of transport; - Transporting the ticket (T) via the means of transport to the field device (FG); - Checking the ticket (T) by the field device (FG) to see if the ticket (T) was actually created by the ticket server (TS); - Creating an account for the service technician (SN) on the field device (FD) with the defined access rights if the check is successful; and - Login of the service technician (BN) via the account on the field device (FG).

2. Method according to claim 1, wherein the means of transport for the ticket (T) is an operating unit (BE), wherein the operating unit (BE) connects to the field device (FG), for example via Bluetooth, or is a memory card, for example an SD card, or a digital protocol, for example HART, or wherein the field device (FG) is in contact with the ticket server (TS) and the transport of the ticket (T) takes place via this connection.

3. Method according to claim 1 or 2, wherein the service technician (BN) logs in to the account on the field device (FG) using the same access data as on the ticket server (TS).

4. Method according to any of the preceding claims, the service technician (BN) transmits the identifier for the field device (FG) using his account on the ticket server (TS).

5. Method according to one of the preceding claims, wherein the identification of the identifier for the field device (FG) is carried out via an operating unit (BE).

6. Method according to any of the preceding claims, wherein the identifier is the serial number of the field device (FG).

7. Method according to one of the preceding claims, wherein the identifier is a cryptographic key pair comprising a private and a public key, in particular according to the IEEE 802.1 AR standard.

8. Method according to one of the preceding claims, wherein a plurality of field devices are identified for maintenance and an account ticket is created for each field device.

9. Method according to any of the preceding claims, wherein the account on the field device (FG) for the service technician (BN) is time-limited.

10. Method according to any of the preceding claims, wherein the ticket (T) comprises binary code for the account on the field device (FG) itself, for example as an executable file on the field device (FG).

11. System designed to carry out the method according to one of the preceding claims, comprising at least one field device (FG), one ticket server (TS) and one operating unit (BE).

12. System according to the preceding claim, wherein the control unit (CU) is a mobile terminal, in particular a tablet or a smartphone.

Images