Method for changing functionalities of a field device, and corresponding system

Abstract

The invention relates to a method for changing functionalities of a field device (FG), comprising the following steps carried out by the manufacturer of the field device (FG): operating a ticket server (TS); and linking the field device (FG) to the ticket server (TS); and comprising the following steps carried out by the user: acquiring an additional functionality for the field device (FG), in particular an additional software functionality, from the manufacturer of the field device (FG); generating a ticket (T) by means of the ticket server (TS) for the additional functionality for the field device (FG); registering a transport medium on the ticket server (TS) and transmitting the ticket (T) to a transport medium; transporting the ticket (T) to the field device (FG) by means of the transport medium; checking the ticket (T), by means of the field device (FG), as to whether the ticket (T) was actually created by the ticket server (TS); and enabling the additional functionality for the field device (FG) if the check is positive. The invention also relates to a system for carrying out the method.

Description

[0001] Methods for modifying the functionalities of a field device and corresponding system

[0002] The invention relates to a method for modifying the functionalities of a field device 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.

[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 little to no protection against unauthorized access. This means that all device parameters can typically 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 becoming available. Access via a user or machine interface therefore requires a kind of "permanent" authorization, usually granted through prior authentication. To reduce the administrative overhead for managing individual field devices to an acceptable level, some efforts are being made to implement centralized management, similar to the long-standing practice in IT for managing IT equipment (e.g., printers, workstations, etc.).An example of such a concept is disclosed in DE 102018 102 608 A1, in which a means of transport is provided to which user data is transferred from a user database, whereby access to the field device is granted after checking the user data.

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

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

[0012] With modern field devices, it is possible to purchase or activate additional functionality, often referred to as a "feature," after buying the actual device ("hardware"). Examples cited by the applicant are "Heartbeat Verification" and "ProtectBlue Extended."

[0013] For example, an activation code is sent by mail. The user has to manually enter the code via a complex on-screen input process. Naturally, this process is not cryptographically secured.

[0014] The correct code may be hard-coded in the field device and, if known, can also unlock the feature without authorization.

[0015] There is no time limit on this feature. Also, the codes usually have to be sent by mail.

[0016] The invention is based on the objective of providing a simple and safe way to unlock additional functionality in a field device.

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

[0018] 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; as well as the steps carried out by the user: purchasing additional functionality for the field device, in particular additional software functionality, from the field device manufacturer; generating a ticket from the ticket server for the additional functionality for the field device; the user logging into the ticket server and sending the ticket to a transport vehicle; transporting the ticket via the transport vehicle to the field device; the field device verifying that the ticket was indeed created by the ticket server; and activating the additional functionality for the field device if the verification is successful.

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

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

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

[0022] In one embodiment, the means of transport for the ticket is a control unit, which connects to the field device, for example via Bluetooth; or a memory card, such as an SD card; or a digital protocol, such as HART; or the field device is connected to the ticket server and the ticket is transported via this connection. One embodiment provides that the field device itself creates a confirmation ticket containing information on whether the activation of the additional functionality was successful.

[0023] One design provides for the confirmation ticket to be cryptographically secured in the field device.

[0024] One design provides that the confirmation ticket is transferred to the means of transport, in particular to the control unit.

[0025] One implementation involves transferring the confirmation ticket to the ticket server.

[0026] One design provides that the additional functionality is limited in time or is activated for a limited time.

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

[0028] One design provides that the ticket includes binary code for the additional functionality itself, for example as an executable file on the field device.

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

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

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

[0032] Fig. 1 shows the claimed system. The invention is based on an established field device ticket server infrastructure. There is a ticket server TS, which is operated by the manufacturer of the field device FG. The field device FG is linked to the ticket server TS via a "join process," see below. This linking 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 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] 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 set to a mode in which it can create and receive Tickets T (see below). Tickets are described, for example, in DE 10 2018 102 608 A1 and DE 102019 131 860 A1.

[0035] A join process between the field device FG and the ticket server TS has already been performed, resulting in a cryptographically secured, mutually trusted relationship between the ticket server TS and the field device FG. This is symbolically represented by the dotted line in Fig. 1. 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. The field device FG and the ticket server have a cryptographically secure relationship with each other (they are therefore "joined"). The field device FG and the ticket server have performed a key exchange and, after a Diffie-Hellman key exchange, have determined the shared symmetric key (secret).

[0036] This Field Device Authentication Module (FDAM) stores sensitive data, such as...

[0037] Logs, account databases, keys, certificates, and interface configurations are stored in encrypted form. This data is encrypted, for example, using a key generated from a master key stored on 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. FDAM is also responsible for decrypting the ticket. If necessary, a hash is used to protect against alteration.

[0038] The field device FG can be an online field device, meaning it communicates 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.

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

[0040] The control unit BE is, in particular, a mobile device, such as a smartphone or tablet. The control unit BE also has a wireless interface, specifically a Bluetooth interface.

[0041] In one embodiment, the operator 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 operator 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 operator 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 the creation and transmission of join tickets from the ticket server TS to the operator unit BE, thereby transmitting cryptographic information, in particular 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 be able to verify authenticity and integrity.

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

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

[0044] The user purchases additional functionality for the field device (FG), such as additional software functionality, from the field device manufacturer. These are, for example, optional device features or ordering options. Further examples are hardware functionalities that are activated via software, such as enabling the display as a touchscreen or activating a specific hardware interface, such as a communication interface like Ethernet or Profibus.

[0045] In one process step, one or more tickets T for the additional functionality ZF are then generated by the ticket server TS.

[0046] Then a means of transport is registered on the ticket server TS.

[0047] The means of transport could be, for example, the control unit BE, which would then connect to the ticket server TS via an app or browser. Alternatively, the means of transport could be a memory card, such as an SD card. In this case, the memory card registers indirectly with the ticket server via a computer. Finally, the means of transport could be a digital protocol, such as HART. In this case, the registration process would follow the same procedure.

[0048] Finally, the ticket T is sent to the transport device. In Fig. 1, the transport device is the control unit BE. The step just described is symbolized by the arrow labeled “(1)”. Then, the ticket T is transported and transferred to the field device FG via the transport device. This step is symbolized by the arrow labeled “(2)”. For example, a connection is established, such as via Bluetooth, using the app A between the field device FG and the control unit BE (see next section), and the ticket is transferred in this way.

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

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

[0052] In this document, a "ticket" primarily refers to the ability to activate additional functionality (ZF). In one configuration, the ticket includes metadata, such as fields specific to the respective field device, like its serial number or another unique identifier. Furthermore, the ticket contains the "actual" content (often referred to as the "payload"). In this context, this is information about the additional functionality itself, possibly as a Boolean value ("true / false") or as an activation code.

[0053] The content of the ticket T can also be encoded as a bit string. In one implementation, the ticket or the corresponding data is specified according to Abstract Syntax Notation One (ASN.1), for example, encoded using Distinguished Encoding Rules (DER). For example, a ticket can be several hundred bytes in size.

[0054] The ticket content is encrypted. Generally, it is important that the field device FG, with the FDAM (see above), can decrypt and read the content.

[0055] The additional ZF functionality may be time-limited or subject to a subscription model. In this case, a fee is charged at regular intervals to keep the ZF functionality activated.

[0056] As mentioned, the ticket T is transferred to the field device FG 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 is transferred to the field device FG.

[0057] Finally, in a process step, the field device FG checks whether the ticket T was actually created by the ticket server TS, and if the check is positive, the additional functionality ZF is activated on the field device FG.

[0058] In one configuration, the field device FG now creates its own ticket, namely a confirmation ticket TB, with information on whether the activation of the additional functionality ZF was successful.

[0059] This confirmation ticket TB is cryptographically secured in the field device FG, for example in the FDAM mentioned above. The confirmation ticket TB is then transmitted to the means of transport, for example to the operator unit BE (see Fig. 1). Finally, the confirmation ticket TB can be transmitted to the ticket server TS (similar transport path as described above, only "in reverse"), where the corresponding information is also stored.

[0060] Reference symbol list

[0061] An App

[0062] BE control unit

[0063] BN Users

[0064] FG Field Device

[0065] T Ticket

[0066] TB Confirmation Ticket

[0067] TS Ticketserver

[0068] ZF additional functionality from FG

Claims

1. Patent claims 1. Procedure for modifying the functionalities of a field device (FD), comprising the steps to be carried out by the field device (FD) manufacturer: - Operating a ticket server (TS); and - Linking the field device (FG) to the ticket server (TS); and comprehensively the steps to be performed by the user: - Acquiring additional functionality (S) for the field device (FD), in particular additional software functionality, from the field device (FD) manufacturer; - Generating a ticket (T) from the ticket server (TS) for the additional functionality 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); - The field device (FG) checks whether the ticket (T) was actually created by the ticket server (TS); and - Activating the additional functionality for the field device (FG) if the test is successful.

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 field device (FG) in turn creates a ticket as a confirmation ticket (TB) with the information on whether the activation of the additional functionality (ZF) was successful.

4. Method according to the preceding claim, wherein the confirmation ticket (TB) is cryptographically secured in the field device (FG).

5. Method according to one of the preceding two claims, wherein the confirmation ticket (TB) is transferred to the means of transport, in particular to the control unit (BE).

6. Method according to one of the three preceding claims, wherein the confirmation ticket (TB) is transmitted to the ticket server (TS).

7. Method according to one of the preceding claims, wherein the additional functionality (SQ) is time-limited.

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

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

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

Images