Method for changing the functionality of a field device, and corresponding system

Abstract

The invention relates to a method for changing the functionality of a field device (FG), having the steps of: operating a first ticket server (TS1) by means of the manufacturer of the field device (FG); linking the field device (FG) to the first ticket server (TS1); operating a second ticket server (TS2) by means of the user of the field device (FG); linking the field device (FG) to the second ticket server (TS2); acquiring an additional functionality (ZF) for the field device (FG), in particular an additional software functionality, from the manufacturer of the field device (FG); generating a first ticket (TF) for the additional functionality (ZF) by means of the first ticket server (TS1) and transmitting the first ticket (TF) to the second ticket server (TS2); generating a second ticket (TT) by means of the second ticket server (TS2), the second ticket comprising the first ticket (TF); registering a transport means at the second ticket server (TS2) and sending the second ticket (TT) to the transport means; transporting the second ticket (TT) to the field device (FG) via the transport means; checking the second ticket (TT) on the field device (FG) in order to determine whether the second ticket (TT) was actually created by the second ticket server (TS2); if the check is positive: checking the first ticket (TF) on the field device (FG) in order to determine whether the first ticket (TF) was actually created by the first ticket server (TS1); and if the check is positive: enabling the additional functionality (ZF) for the field device (FG) using the first ticket (TF).

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

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

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

[0013] 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 provided by the applicant are "Heartbeat Verification" or "ProtectBlue Extended."

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

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

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

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

[0018] The task is accomplished by a method according to claim 1.

[0019] Specifically, the solution is implemented through the following steps: The field device manufacturer operates a first ticket server; the field device is linked to the first ticket server; the field device user operates a second ticket server; the field device is linked to the second ticket server; the field device manufacturer acquires additional functionality for the field device, in particular additional software functionality; the first ticket server generates a first ticket for the additional functionality and transmits the first ticket to the second ticket server; the second ticket server generates a second ticket encompassing the first ticket; a means of transport is registered with the second ticket server and the second ticket is sent to the means of transport; the second ticket is transported via the means of transport to the field device.The field device checks whether the second ticket was actually created by the second ticket server; if the check is successful: the field device checks whether the first ticket was actually created by the first ticket server; and if the check is successful: activates the additional functionality for the field device using the first ticket.

[0020] To implement this idea, two ticket servers are required for end-to-end security, each establishing a mutual cryptographic trust relationship with the field devices. The first ticket server is operated by the field device manufacturer. The second ticket server is operated by the field device user. The user purchases the additional functionality ("feature") from the manufacturer, which is then transmitted to the user in the form of a ticket. The first ticket server generates an initial ticket for the additional functionality (or an activation code for it). The second ticket server generates a second ticket, which is used to transmit the first ticket within the system. After logging in via their accounts, the user then has access to the new function(s).

[0021] The claimed method verifies whether the activation is authorized by the manufacturer. Otherwise, the user could activate features at will. The activation, in the form of the initial ticket, originates from the manufacturer and is ultimately verified within the field device itself. This is convenient for the user, as the initial ticket can be distributed via the existing infrastructure within the plant, and activation occurs automatically, eliminating the need for users to log in to each device individually or enter a unique code.

[0022] "Mutual cryptographic trust" means that the components have been mutually acquainted beforehand. A ticket server and a 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 describes how to activate a previously unused additional functionality for a specific field device. Examples of field devices have already been listed in the introductory section 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.

[0023] One design envisages that the first ticket for a large number of field devices includes additional functionality.

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

[0025] One implementation provides that the field device itself creates a ticket as a confirmation ticket with information on whether the activation of the additional functionality was successful.

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

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

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

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

[0030] One aspect of the procedure stipulates that the additional functionality is automatically deactivated on the corresponding field device after the validity period expires. Reactivation with the same ticket is not possible; a new (second) ticket can reactivate the additional functionality.

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

[0032] One embodiment provides for the control unit to be a mobile device, in particular a tablet or a smartphone. This is explained in more detail with reference to the following figure.

[0033] Fig. 1 shows a system for carrying out the procedure.

[0034] The invention is based on an established field device ticket server infrastructure. The invention encompasses end-to-end security, meaning from a source at the field device manufacturer to the field device itself as the final recipient. This chain must not be interrupted, even if the user operates their own ticket server, as explained below.

[0035] There is an initial ticket server, TS1, operated by the manufacturer of the field device FG. The field device FG is linked to the ticket server TS1 via a "join process," as shown below. This link is established directly at the manufacturer's factory before delivery.

[0036] There is also a second ticket server, TS2, operated by the user of the field device FG. The field device FG is linked to the second ticket server, TS2, via a "join process," using a similar procedure to that used with the first ticket server, TS1 (see below). This linking takes place, for example, after delivery of the devices, directly at the user's site and before actual deployment in the field. The user typically operates a variety of different field devices; Figure 1 shows a single field device, FG. The "user" is, for example, a plant operator.

[0037] The field device FG has 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, the field device FG is configured to create and receive tickets (see below). Tickets are described, for example, in DE 10 2018 102 608 A1 and DE 10 2019 131 860 A1. These tickets can be used, for example, to assign or modify user rights.

[0038] A join process between the field device FG and the ticket servers TS1 and TS2 has already been performed, resulting in a cryptographically secured, mutually trusted relationship between the ticket servers TS1 and TS2 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 a first ticket TF (see below) originates from the first ticket server TS1. The FDAM in the field device FG further verifies whether a second ticket (see below) originates from the second ticket server TS2. The field device FG and the ticket servers TS1 and TS2 are cryptographically secure (they are thus "joined").For this purpose, the field device FG and the ticket servers TS1 and TS2 each performed a key exchange and, for example, determined the common symmetric key (secret) after 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 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.

[0040] The field device FG can be an online field device, meaning it communicates with the user's ticket server TS2 (not with the first ticket server TS1) 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 either ticket server TS1 or TS2. The second tickets TT can then be transmitted from the second ticket server TS2 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 second ticket TT reaches the device, which is described in more detail below. The content of the second ticket TT (namely, a "first ticket TF") is securely encrypted with this key and is unreadable and unusable by third parties.

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

[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 performed:

[0044] The user purchases an additional functionality (ZF) for the field device (FG), for example, additional software functionality, from the manufacturer (H) of the field device (FG). 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. In a subsequent process step, one or more tickets for the additional functionality (ZF) are generated, or an activation code for the additional functionality (ZF) is generated. Since the manufacturer (H) of the field device (FG) knows which functionalities are activated and which are not, the manufacturer then generates such an activation ticket (TF).The TF ticket ultimately enables the field device FG to activate a specific functionality, an additional functionality ZF. This ticket is a "first ticket" as defined in this document, also called an activation ticket TF or feature ticket (see below for a general explanation of "ticket" and "activation ticket TF"). The activation ticket TF is generated on the manufacturer's ticket server TS1. This activation ticket TF is then transmitted by the manufacturer H of the field device FG to the user, specifically to the second ticket server TS2 (at the user's location). The method of transmission is irrelevant. It can be via email, download, or physical data carrier such as a USB stick, CD-ROM, DVD, hard drive, etc. The step just described is symbolized in Fig. 1 by the arrow labeled "(0)".

[0045] To ensure that manufacturer H knows which field devices (FG) should be equipped with which additional functionality (ZF), the user submits a list of the field devices to be equipped to manufacturer H. This list includes, for example, the serial number of the corresponding devices, which is preferably unique. This submission is symbolized in Fig. 1 by the arrow at the label "(0)". Since the activation tickets for the additional functionality are specific to certain field devices (for example, a group of the user's field devices), no one else can use the activation tickets. Similarly, the user could equip all devices in a specific order with the ZF feature. In this case, the assignment can be done via an order number or similar identifier.

[0046] The TS2 ticket server at the user's site is responsible for user administration, rights assignment and management, as well as providing an overview of the functionality and additional functionality (ZF). Therefore, the activation ticket(s) (TF) is sent to the second TS2 ticket server at the user's site. However, since the manufacturer of the field device (FG) logically has the authority to grant activation (for example, only after payment of a fee), the activation ticket (TF) must originate from the manufacturer, specifically from the first TS1 ticket server.

[0047] In the next step, the second ticket server, TS2, generates a second ticket, which then incorporates the first ticket. For the purposes of this document, the "second ticket" is a transport ticket (TT). The first ticket (TF) is therefore transported using the second ticket (TT).

[0048] Then a means of transport is registered on the ticket server TS2.

[0049] The means of transport could be, for example, the control unit BE, which would then connect to the ticket server TS2 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 would register indirectly with the ticket server TS2 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.

[0050] Finally, the transport ticket TT (along with the activation ticket TF) is sent to the means of transport. In Fig. 1, the means of transport is the control unit BE. The step just described is symbolized by the arrow labeled “(1)”.

[0051] The transport ticket TT is then transported via the means of transport to the field device FG and transferred there. This step is symbolized by the arrow labeled “(2)”.

[0052] For example, a connection is established, such as via Bluetooth, between the field device FG and the control unit BE (see next section) using App A, and the transport ticket TT is transferred in this way. The transfer of the transport ticket TT can also occur in the background without any active user intervention. This is particularly the case when the field device FG is selected in the LiveList. App A displays all field devices FG that are currently within range. This list is often referred to as the "LiveList".

[0053] User BN logs into the field device FG using their specific 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 verifies these credentials as valid 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.

[0054] As explained in the preceding paragraphs, this document describes two types of tickets: an activation ticket (TF) and a transport ticket (TT). Each ticket can be specific to a particular field device (FG) (for example, linked via its serial number) or assigned to a group of field devices with specific selection criteria (for example, all field devices belonging to a particular user, a serial number range, or all pressure gauges, etc.). The activation ticket (TF) is generated by the manufacturer (H) of the field devices (first ticket server TS1), while the transport ticket (TT) is generated by the operator of the second ticket server (TS2), typically the user. The activation ticket (TF) is contained within the transport ticket (TT) and is transported to and transferred to the field device (FG) via the TT.

[0055] The activation ticket TF is used to unlock an additional functionality ZF. In one configuration, the ticket includes metadata, such as fields specific to the respective field device, like the serial number or another unique identifier. Furthermore, the ticket contains the "actual" content (often referred to as the "payload"). In this case, that's information about the additional functionality ZF itself, possibly as a Boolean value "true / false" or as an activation code.

[0056] Since the second ticket server TS2 and the field device FG, as mentioned above, are in a cryptographically secured, mutual trust relationship, the field device FG, as the receiving unit, "trusts" the transport ticket TT sent by the second ticket server TS2 and its content. Therefore, in a process step, the field device FG checks whether the transport ticket TT ("second ticket") was actually created by the second ticket server TS2.

[0057] Then, in a process step, the field device FG checks whether the transport ticket TT was actually created by the second ticket server TS2.

[0058] Since the first ticket server TS1 and the field device FG, as mentioned above, are in a cryptographically secured, mutual trust relationship, the field device FG, as the receiving unit, "trusts" the activation ticket TF generated by the first ticket server TS1 and its content. Therefore, if the check to see if the transport ticket TT originates from the second ticket server TS2 is successful, the field device FG then verifies in a process step whether the activation ticket TF ("first ticket") was indeed created by the first ticket server TS1.

[0059] If this test is positive, the additional functionality ZF for the field device FG will be activated by means of the first ticket TF.

[0060] Depending on whether the activation ticket TF is designed for a single field device or a group of field devices, the activation ticket TF can also activate additional functionality ZF for a large number of field devices. In one configuration, exactly one ticket is used per field device.

[0061] The content of a ticket can also be encoded as a bit string. In one implementation, a 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.

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

[0063] The additional functionality ZF may be time-limited or subject to a subscription model. In the latter case, a fee is charged at regular intervals to keep the additional functionality ZF activated. As mentioned, the transport ticket TT is transmitted to the field device FG via any data transmission channel – e.g., manually, via a control 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 then transmitted to the field device FG.

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

[0065] This confirmation ticket TB is cryptographically secured in the field device FG, for example in the FDAM mentioned above.

[0066] The confirmation ticket TB is then transmitted to the means of transport, for example, to the control unit BE (see Fig. 1). Finally, the confirmation ticket TB can be transmitted to the second ticket server TS2 (similar transport path as described above, only "in reverse"), where the corresponding information is also stored.

[0067] Reference symbol list

[0068] A App BE Control Unit BN User FG Field Device H Manufacturer TF Activation Ticket / Feature Ticket / First Ticket TT Transport Ticket / Second Ticket TB Confirmation Ticket

[0069] TS1 first ticket server (at the manufacturer) TS2 second ticket server (at the user's) ZF additional functionality from FG

Claims

Patent claims 1. Procedure for modifying the functionalities of a field device (FD), comprising the steps: - Operation of a first ticket server (TS1) by the manufacturer of the field device (FG); - Linking the field device (FG) to the first ticket server (TS1); - Operation of a second ticket server (TS2) by the user of the field device (FG); - Linking the field device (FG) to the second ticket server (TS2); - Acquiring additional functionality (S) for the field device (FD), in particular additional software functionality, from the field device (FD) manufacturer; - Generating an initial ticket (TF) from the first ticket server (TS1) for the additional functionality (ZF) and transmitting the initial ticket (TF) to the second ticket server (TS2); - Generating a second ticket (TT) from the second ticket server (TS2) encompassing the first ticket (TF); - Registering a means of transport on the second ticket server (TS2) and sending the second ticket (TT) to the means of transport; - Transporting the second ticket (TT) via the transport vehicle to the field device (FG); - Checking the second ticket (TT) by the field device (FG) to see if the second ticket (TT) was actually created by the second ticket server (TS2); - if the check is positive: The field device (FG) checks whether the first ticket (TF) was actually created by the first ticket server (TS1); and - if the test is positive: Activation of the additional functionality (ZF) for the field device (FG) using the first ticket (TF).

2. Method according to claim 1, wherein the first ticket (TF) for a plurality of field devices (FG) each comprises additional functionality (ZF).

3. Method according to claim 1 or 2, wherein the transport means for the second ticket (TT) 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 second ticket server (TS2) and the transport of the second ticket (TT) takes place via this connection.

4. Method according to any of the preceding claims, 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.

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

6. 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).

7. Method according to one of the three preceding claims, wherein the confirmation ticket (TB) is transferred to the second ticket server (TS2).

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

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

10. Method according to one of the preceding claims, wherein the control unit (CU) is a mobile terminal, in particular a tablet or a smartphone.

Images