Method for starting up a field device, and corresponding system

Abstract

The invention discloses a method for starting up a field device (FG1, FG2), comprising the following steps carried out by the manufacturer of the field device (FG1, FG2): operating a ticket server (TS); and linking the field device (FG1, FG2) to the ticket server (TS), the field device (FG1, FG2) having no account; and comprising the following steps carried out by the operator: creating an account having access data and having specific access rights, in particular having a user name and a password, and assigning the account to the field device (FG1, FG2) by means of the ticket server (TS); generating one or more tickets (T) by means of the ticket server (TS) for the new account; transporting the ticket (T) to the field device (FG1, FG2); checking the ticket (T), by means of the field device (FG1, FG2), as to whether the ticket (T) was actually created by the ticket server (TS); storing the account on the field device (FG1, FG2) if the check is positive; and granting access to the field device (FG1, FG2) in accordance with the access rights after successful login with the access data on the field device (FG1, FG2) by the user. The invention also discloses a system for carrying out the method.

Description

[0001] Procedure for commissioning a field device and corresponding system

[0002] The invention relates to a method for commissioning a 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 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.

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

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

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

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

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

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

[0012] 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.New devices are typically shipped with pre-installed user accounts so that a user can initially log in to the field device and configure it if necessary. These initial accounts are often assigned a device-specific password, such as the serial number, which then needs to be changed for subsequent use of the device. This procedure is not very user-friendly and is often neglected by users for convenience. Furthermore, an unauthorized person could also operate the device initially, since it is known that the initial password is the serial number.

[0013] The invention is based on the objective of providing a simple and safe way to put a field device into operation.

[0014] The problem is solved by a method according to claim 1 and by a system according to claim 6.

[0015] Specifically, the solution is implemented through the following steps, which are carried out by the field device manufacturer: operating a ticket server; and linking the field device to the ticket server, whereby the field device does not include an account, i.e., it is delivered without one. The subsequent steps of the process are carried out by the user: creating an account with login credentials and specific access rights, in particular a username and password, and assigning the account to the field device via the ticket server; generating one or more tickets from the ticket server for the new account; transferring the ticket to the field device; the field device verifying that the ticket was indeed created by the ticket server; and creating the account on the field device if the verification is successful; granting access to the field device according to the access rights after successful login with the login credentials on the field device by the user.

[0016] The user here is understood as the operator or administrator. The user typically operates a variety of field devices, for example, as a plant operator. The "user" is an individual person who performs certain tasks. "Operator" is understood as a role that can also be performed by the individual "user." To implement this concept, a ticket server is required, which establishes a mutual, cryptographic trust relationship with the field devices and the control unit required for offline operation.

[0017] "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 specifically addresses the creation of the account on the field device if the check is successful and granting access to the field device according to the access rights after successful login with the access data on the field device by the user.

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

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

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

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

[0022] According to one approach, authentication on the ticket server is performed by entering user information, specifically username and password, which the user also uses for authentication in their IT office administration. Services such as "OAuth2 / OISC", "LDAP", "MS AD", etc., are used for this purpose. This has the advantage that the user can reuse existing accounts.

[0023] One approach envisions the ticket server being implemented as an application within a cloud platform, using the same user credentials for authentication that the user employs to authenticate 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.

[0024] One design allows multiple field devices to be assigned to one account with the same access data, in particular with the same username and password for all assigned field devices.

[0025] One design provides that the requirements for the access data, in particular the number of characters, use of special characters, use of numbers and letters, uppercase and lowercase letters, depend on the field device and that the field device with the lowest requirements determines these requirements.

[0026] One design stipulates that the newly created account is time-limited.

[0027] Regarding 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, a ticket server, and an operating unit. One embodiment of the system provides that the operating unit is a mobile device, in particular a tablet or a smartphone.

[0028] This will be explained in more detail using the following figures.

[0029] Fig. 1 shows the claimed system.

[0030] Fig. 2 shows the claimed system in one embodiment.

[0031] In the figures, identical features are marked with the same reference symbols.

[0032] The invention is based on an established field device ticket server infrastructure. There is a ticket server TS, operated by the manufacturer of the field devices FG1 and FG2. The field devices FG1 and FG2 are linked to the ticket server TS via a "join process," as shown below. This linking takes place, for example, during the production of the field devices, but in any case, before the field devices FG1 and FG2 are delivered to the respective user. The user typically operates a large number of different field devices; a single field device FG is shown. The "user" is, for example, a plant operator.

[0033] Such a ticket server (TS) can, for example, be implemented 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.

[0034] Field devices FG1 and FG2 have modules that handle user access management on the device side. This user access management allows the user to create multiple users per field device, each with different access rights. Furthermore, field devices FG1 and FG2 are configured to create and receive tickets (see below). Tickets are described, for example, in German patents DE 10 2018 102 608 A1 and DE 102019 131 860 A1. A join process between field devices FG1 and FG2 and the ticket server TS has already been performed, resulting in a cryptographically secured, mutually trusted relationship between the ticket server TS and field devices FG1 and FG2. Field device FG includes a central security component, a so-called "Field Device Authentication Module" (FDAM). The FDAM in the field device FG checks whether the ticket originates from the ticket server TS.The field device FG and the ticket server are cryptographically connected (they are "joined"). The field device FG and the ticket server have performed a key exchange and, after a Diffie-Hellman key exchange, have determined their shared symmetric key (secret).

[0035] This Field Device Authentication Module (FDAM) stores sensitive data, such as logs, account databases, keys, certificates, and interface configurations, in encrypted form. 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 to each memory chip produced, 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 to protect against modification.

[0036] Field devices FG1 and FG2 can be online, meaning they communicate with the ticket server via a network. However, in this case, field devices FG1 and FG2 are offline, meaning there is no direct communication connection with the ticket server TS. Tickets T can then be transmitted from the ticket server TS to the corresponding field devices FG1 and FG2 via a transport device, such as an operator panel BE, and vice versa. 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] Field devices FG1 and FG2 are delivered without an account. Furthermore, a control unit BE is provided. The control unit BE is specifically a mobile device, such as a smartphone or tablet.

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

[0039] In one process step, user BN logs into the ticket server and creates an account with login credentials and specific access rights for one or more field devices FG1, FG2. The login credentials include, for example, a username and password for the field device FG1, FG2. This account is then assigned to the field device(s) via the ticket server TS. Multiple field devices FG1, FG2 can be assigned to one account, with the same login credentials—that is, the same username and password—used for all assigned field devices FG1, FG2.

[0040] Access rights can be assigned to specific roles, such as administrator, operator, guest, etc. The corresponding user then has more or fewer options and rights.

[0041] If required, a validity period can also be defined. Depending on the criticality of the system and standard operational procedures, the validity period is variable (e.g., hours, for this shift, etc.). These steps may not be performed by user BN, but by a user with extensive access rights, such as an administrator. In one configuration, these steps can be performed by the manufacturer.

[0042] In one process step, one or more tickets T are then generated by the ticket server TS for the new account.

[0043] 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 is required to be executed either completely and without errors or not at all. A ticket generally defines order data for a work order to be carried out. This order data can include, for example: a unique identifier for the service employee or user, the field device, the work order (e.g., maintenance, enabling a defined parameter, calibration, replacing the field device, etc.), and, if applicable, the time period in which the work order is to be carried out.

[0044] In this document, the term "ticket" primarily refers to the following aspect: Login to the field device is achieved through the use of an authorized device, control unit, or authorization tool. By presenting ticket T to field device FG1 or FG2, user BN is automatically authorized to execute the work order. The ticket thus contains the access authorization for field device FG1 or FG2. Ticket T therefore serves as an identifier (e.g., the user's name) and 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. The ticket is therefore an "account ticket." 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.When the user submits ticket T to the field device, the login credentials are automatically transmitted to the field device. After the task 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 both) from the ticket server TS database. Alternatively, the ticket can contain a plaintext password or a random temporary password.

[0045] The ticket T is transferred to the field device via 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 transferred by the user to the field device.

[0046] Ticket T is therefore transported to field devices FG1 and FG2, for example, as mentioned, via the control unit BE. In one configuration, the field device is connected to the ticket server. In this case, ticket T can be transported directly via this connection.

[0047] Finally, in a process step, the field device FG1 or FG2 checks whether the ticket was actually created by the ticket server, and if the check is positive, the account is created on the field device FG1 or FG2. In other words, the account is created on the field device.

[0048] In one process step, for example, user BN logs into field device FG2 using their access credentials. User BN is physically present at field device FG2 and selects it to establish a connection (for example, by selecting it from a LiveList). Login is performed using the username and password. If field device FG2 can verify the validity of these credentials and the login time falls within the defined validity period, user BN logs into field device FG2 using their control unit BE. Access to field devices FG1 and FG2 is then granted according to the assigned access rights.

[0049] The requirements for the access data, in particular the number of characters, use of special characters, use of numbers and letters, and capitalization, depend on the field device FG1 or FG2. In one configuration, the field device FG1 or FG2 with the fewest requirements determines these requirements. For example, if a field device has only a small display, a few buttons, or a rotary / push switch, the requirements may be lower than for a field device with a touchscreen that can display a full keyboard. This makes it easier for the user to log in.

[0050] The field device FG2 can then be operated by user BN using the usual tickets (see, for example, DE 102019 131 860 A1). In the example shown in Fig. 2, a ticket server TS is operated by the manufacturer of the field devices FG1 and FG2. Additionally, the user of the field devices FG1 and FG2 has their own ticket server TS'. This ticket server TS' is regularly used for managing the accounts. The manufacturer's ticket server TS is only used in emergencies.

[0051] Reference symbol list

[0052] BE control unit

[0053] BN User / User FG1. FG2 Field device

[0054] T Ticket

[0055] TS, TS' ticket server

Claims

Patent claims 1. Procedure for commissioning a field device (FG1 , FG2), comprising the steps to be carried out by the manufacturer of the field device (FG1 , FG2): - Operating a ticket server (TS); and - Linking the field device (FG1, FG2) to the ticket server (TS), whereby the field device (FG1, FG2) does not include an account; and encompassing the steps to be performed by the user: - Creating an account with access data and specific access rights, in particular with username and password, and assigning the account to the field device (FG1 , FG2) via the ticket server (TS); - Generating one or more tickets (T) from the ticket server (TS) for the new account; - Transporting the ticket (T) to the field device (FG1 , FG2); - Checking the ticket (T) by the field device (FG1 , FG2) to see if the ticket (T) was actually created by the ticket server (TS); - Creating the account on the field device (FG1, FG2) if the check is successful; and - Granting access to the field device (FG1 , FG2) according to the access rights after successful login with the access data on the field device (FG1 , FG2) by the user.

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

3. Method according to claim 1 or 2, wherein an account is assigned to several field devices (FG1, FG2) with the same access data, in particular with the same username and password for all assigned field devices (FG1, FG2).

4. Method according to any of the preceding claims, wherein the requirements for the access data, in particular the number of characters, use of special characters, use of numbers and letters, and case sensitivity, depend on the field device (FG1, FG2) and wherein the field device (FG1, FG2) with the fewest requirements determines these requirements.

5. Method according to any of the preceding claims, wherein the account is time-limited.

6. System which is designed to carry out the method according to one of claims 1 to 5, comprising at least one field device (FG1 , FG2 ), a ticket server (TS ) and an operating unit (BE ).

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

Images