Method for integrating field device into operating system of automation system

Abstract

The invention relates to a method for integrating field devices into an operating system of an automation system, in which the operating system comprises at least one transmission medium and a ticket server communicating with the transmission medium, the ticket server and existing field devices located in the facility being designed to create and / or process tickets, the present invention relates to a method for ordering a field device in a receipt containing in each case at least one cryptographically secure item of information and defining in the receipt in each case a recipient from a group of a receipt server and an existing field device, the method comprising: placing an order by a customer for the field device; generating, by the manufacturer's server, registration data for the field device based on the order, wherein the registration data includes identification information of the field device and a first password related information item; and registering the field device as an existing field device on the ticket server, wherein the registration data is sent to the ticket server during the registration process and the second password related information of the ticket server is stored in the field device.

Description

Technical Field

[0001] The invention relates to a method for integrating a field device into an operating system of an automation system, wherein the operating system comprises at least one transmission medium and a ticket server communicating with the transmission medium, wherein the ticket server and the field device are designed to create and / or process a ticket, which in each case contains at least one cryptographically secure information item and in which in each case one or more recipients from the group of ticket server and field device are defined, wherein the ticket server and the field device are designed to send the created ticket to the transmission medium, wherein the transmission medium sends the ticket to the recipient, and wherein the recipient checks the authenticity and integrity of the ticket. Background Art

[0002] The field devices used in industrial facilities are already known from the prior art. Field devices are often used in process automation engineering and in manufacturing automation engineering. In principle, all devices that are process-oriented and supply or process-related information are referred to as field devices. Field devices are therefore used to detect and / or influence process variables. Measuring devices or sensors are used to detect process variables. These are, for example, used for pressure and temperature measurement, conductivity measurement, flow measurement, pH measurement, filling level measurement, etc., and detect corresponding process variables of pressure, temperature, conductivity, pH value, filling level, flow, etc. Actuators are used to influence process variables. These are, for example, pumps or valves that can influence the flow of a fluid in a pipeline or the filling level in a tank. In addition to the aforementioned measuring devices and actuators, field devices are also understood to include remote I / O, radio adapters, or are generally devices arranged at the field level.

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

[0004] In modern factories, field devices are usually connected via fieldbus (Profibus ® 、Foundation ® Fieldbus, HART ® The superordinate unit is connected to a superordinate unit via a communication network (such as a bus system). Usually, the superordinate unit is a control system (DCS) or a control unit, such as an SPC (stored program control). The superordinate unit is used for process control, process visualization and process monitoring, as well as the commissioning of field devices, etc. The measured values ​​detected by the field devices (especially by sensors) are sent to one (in some cases multiple) superordinate units via the corresponding bus system. In addition, data transmission from the superordinate unit to the field devices via the bus system is also necessary, especially for the configuration and parameterization of the field devices and for controlling actuators.

[0005] The mobile control unit can also be used to operate field devices that have implemented the FDT frame application. For example, there are control units that are connected to a fieldbus network. However, the control unit can also communicate with the field device via a wireless communication connection based in particular on the Bluetooth standard. The applicant produces and sells a device that allows the control unit to be coupled to the field device as a so-called Bluetooth gateway. The field device is connected to the Bluetooth gateway via a wire, in particular using the HART or CDI communication standard. Alternatively, the field devices themselves have their own Bluetooth interface.

[0006] If a mobile device such as a smartphone or tablet is used as the control unit for wireless communication with the field device, application programs - so-called apps - are available, which make operating functions of the field device available to the mobile device.

[0007] In industrial environments, most installed field devices have no or only very basic protection against unauthorized access. In these field devices, it is usually possible to access all device parameters directly or, for example, after entering an unlock code. As a result of the German Federal Security Act [Bundessicherheitsgesetz], more and more field devices with individual user accounts and role-based authorization are entering the market. For access via a user interface or machine interface, a "permanent" authorization is required in a certain sense, which is usually permitted by a prior authentication. The authorization must be chosen so that the accessing users (permanently) have all the authorizations they need to perform their tasks. Standards such as IEC 62443-4-2 describe how authentication mechanisms at the state of the art can be implemented.

[0008] Due to the huge amount of management work that occurs for the login data of field devices, techniques for central user management are emerging, as has been common practice in IT departments for many years for IT devices (e.g., printers, workstations, etc.). An example of such a concept is disclosed in DE 10 2018 1026 08 A1, in which a transmission medium is provided to which user data is transmitted from a user database, wherein access to the field device is permitted after checking the user data.

[0009] There is also an idea for limiting the access permissions required by people to a minimum. For example, DE102019131860 A1 discloses providing a digital order ticket sent from a server to a mobile device, which order ticket contains access rights and authorization tasks for a field device. This order ticket is sent when a connection is established with the field device. If authorization is available, the tasks contained in the order ticket, such as parameterizing actions or performing functional tests, can be processed using the field device.

[0010] Field devices that can be managed with such an operating system must be connected to a unit to be managed (a user management system in the form of a ticket server) after delivery to the customer. This usually takes place by means of a key exchange between the field device and the management unit, which must be performed manually by the customer. In the case of a large number of field devices, this involves personnel and cost expenditures that should not be underestimated. Summary of the invention

[0011] Based on this problem, the object of the invention is to connect a field device to a control system with user management in a simple manner.

[0012] The object is achieved by a method for integrating a field device into an operating system of an automation system, wherein the operating system comprises at least one transmission medium and a ticket server communicating with the transmission medium, wherein the ticket server and the field device are designed to create and / or process a ticket, the ticket in each case containing at least one cryptographically secure information item and in which one or more recipients from the group of the ticket server and the field device are defined in each case, wherein the ticket server and the field device are designed to send the created ticket to the transmission medium, wherein the transmission medium sends the ticket to the recipient, and wherein the recipient checks the authenticity and integrity of the ticket, the method comprising:

[0013] Orders are placed by customers for on-site equipment;

[0014] generating, by a server of the manufacturer, registration data for the field device based on the order, wherein the registration data includes identification information of the field device and first password-related information items; and

[0015] The field device is registered at the ticket server as an existing field device, wherein during the registration process registration data are sent to the ticket server and second password-related information items of the ticket server are stored in the field device.

[0016] The core of the method according to the invention is to provide a mechanism for connecting field devices to the ticket server already at the time of production. Thus, at the time of delivery to the customer, the field device will already be registered on the ticket server. The customer can then start managing the new field device directly via the ticket server in his facility system.

[0017] A ticket is a digital, tamper-proof data packet that contains additional data in addition to the signature (or authenticity verification code) of the unit that issued the ticket (in this case, the ticket server or the field device). If the transmission medium is, for example, an operating unit, the additional data is the authorization for the operating unit to perform a defined task on the field device. In addition to the authorization for this task, the ticket can also contain, for example, a valid value range for a field device parameter to be written. With the help of the signature, the recipient of the ticket can check the authenticity and integrity of the ticket. For this verification, the field device requires a first cryptographically relevant information item of the ticket server. If the ticket is created by the field device, the ticket server can perform the verification with the help of a second cryptographically relevant information item of the ticket server.

[0018] The password-related information includes, for example, a public key of a key pair (wherein the key pair consists of a private key and a corresponding public key, the private key being written into the field device in the case of a first password-related information item, or remaining on the ticket server in the case of a second password-related information item). Alternatively, it is information required for a so-called "challenge" by means of which the field device and the ticket server establish a trust relationship.

[0019] Examples of field devices mentioned within the scope of the method according to the invention have already been cited as examples in the introduction to the description.

[0020] Existing field devices are field devices which have already been put into operation by the customer as required and which handle defined tasks within the scope of their intended application (for example, detecting and / or influencing measured variables of process engineering operations).

[0021] An advantageous embodiment of the method provides that the registration module is assigned to the ticket server, wherein the registration data are transmitted from the manufacturer's server to the registration module, wherein the second password-related information item is transmitted from the registration module to the manufacturer's server, and wherein the registration module registers the field device as an existing field device on the ticket server. In particular, it is provided that the registration data are transmitted to the registration module in the form of a first exchange ticket created by the manufacturer's server, and wherein the second password-related information item is transmitted to the manufacturer's server in the form of a second exchange ticket created by the registration module or by the ticket server.

[0022] The exchange ticket is a ticket as defined above. The registration data can be found in the first exchange ticket in particular as "additional data". The second cryptographically relevant information item is located in particular as "additional data" in the second exchange ticket. In particular, the cryptographically relevant information which is provided for mutual verification of the authenticity and integrity of the exchange ticket has been exchanged in advance between the ticket server or the registration module and the manufacturer's server.

[0023] According to one embodiment of the method, it is provided that a software module or a hardware module is used as the registration module. In the case where the ticket server is a local server located within the system or close to the system and connected to the system network via a local network, the registration module can be designed as a hardware module. In the case where the ticket server is a cloud-based server and can be connected via the Internet, the registration module can be designed as a software module.

[0024] The first variant of the method provides for generating a digital image of the field device during the ordering process, wherein registration data is transmitted from the manufacturer's server to the digital image of the field device, wherein the second password-related information item is transmitted from the registration module to the digital image of the field device, wherein the registration data is transmitted from the digital image of the field device to the registration module during the registration process. The digital image is a virtual representation of a field device having the same properties as a real field device. For example, the digital image is assigned the same configuration and parameter settings as the real field device. For example, after the production of the field device is completed, or at any other time point when the physical field device exists, the field device must be synchronized with its digital image so that the second password-related information item is written into the field device.

[0025] According to a second variant of the method, provision is made for the manufacturer's server and the registration module to be in communication connection, wherein the registration data are transmitted from the manufacturer's server to the registration module via the communication connection, and wherein the second password-related information item is transmitted from the registration module to the manufacturer's server via the communication connection. This second password-related information item is then written into the field device during production or after production has been completed.

[0026] According to an embodiment of the second variant of the method, provision is made for the manufacturer's server to access the registration module via its REST API for the purpose of mutual data or information transfer. A REST API (also called a RESTful API) is an architectural style of an application programming interface (API) for defining access to data and / or information and the use of data and / or information. It is used for mutual communication between different instances.

[0027] According to a third variant of the method, it is provided that the server of the manufacturer and the registration module are not in communication connection.

[0028] According to an embodiment of a third variant of the method, provision is made for the registration data to be entered by the user into the registration module via a graphical user interface. For example, the registration data are generated by the manufacturer server as a code (e.g. a hexadecimal code or BASE32 or BASE64) and can be output to the user as a (human-readable) character string (so-called "string") entered by the user into the registration module. In particular, the registration module in this variant is designed as a software module. Alternatively, the user accesses a web server of the registration module designed as a hardware module by means of a computing unit.

[0029] According to an alternative embodiment of the third variant of the method, provision is made for the registration data or the first exchange ticket containing the registration data to be present as an optically detectable code, in particular as a barcode or as a QR code, wherein an optical detection unit is assigned to the registration module, and wherein the registration module reads the code via the optical detection unit. For this purpose, the registration module can be designed as a (portable) hardware module comprising an optical detection unit. Alternatively, an operating unit, such as a mobile device, can be used which comprises an optical detection unit and is communicatively connected to the registration module (which can be designed as a hardware module or a software module).

[0030] The optical detection unit is, for example, a photodiode or a camera.

[0031] The code can be transmitted to the user as a paper printout.Alternatively, the optically detectable code can be located on the manufactured field device, for example on a nameplate or, for example as a sticker, on the housing of the field device.

[0032] According to another alternative embodiment of the third variant of the method, it is provided that the first exchange ticket is transferred from the manufacturer's server to the data carrier and thereby the first exchange ticket is transferred from the data carrier to the registration module. For example, as part of the delivery of the field device, the data storage device (e.g. a USB stick or an SD card) is delivered to the customer by the manufacturer of the field device.

[0033] For the second password-related information item originating from the ticket server, provision is then made that the second password-related information item is transferred to the manufacturer's server during the ordering process by the user, in particular by user input or by transmitting a file containing the second password-related information item.

[0034] After the field device has been registered on the ticket server, it can now be provided that an operating unit is provided as a transmission medium for operating an existing field device located in the installation, wherein the ticket contains data authorizing the operating unit to execute a defined work order on the defined existing field device. The field device verifies the ticket for authenticity and integrity (with the aid of the second cryptographically relevant information item) and releases the corresponding operating function for the operating unit.

[0035] Alternatively, a storage medium can be used as a transmission medium. In this case, for example, activation of the corresponding operating function is effected on an operating unit (eg a touch display) of the field device.

[0036] After executing the work order, the field device can likewise use the transmission medium to send a confirmation ticket back to the ticket server.

[0037] A method according to one of the preceding claims, wherein the operating unit authenticates itself to an existing field device defined in the corresponding order ticket. This is particularly useful in case the order ticket and the associated task are bound to a specific operating unit. Authentication means that the operating unit has to prove its identity to the field device after the ticket has been transferred, for example by sending an (unchangeable) identification to the field device or by adding its own signature to the order ticket. Such machine-to-machine authentication typically uses one of the following methods:

[0038] 1.: The operating unit claims to be the owner of a specific key pair and thereby transmits the public key of the key pair. Using the challenge-response method, the operating unit must prove to the field device that it owns the associated private key of the key pair.

[0039] 2.: The operating unit sends a signed message with its identification to the field device. The field device verifies the signature and, if there are no problems, assumes that the stated identity is correct.

[0040] 3.: Similar to 2., but the message is encrypted with the identity of the control unit. The field device decrypts the message and then trusts the content.

[0041] In cases 2. and 3., trust is based on signatures or encryption. These methods usually use a so-called pre-shared key (PSK), a key that both parties must know before communication can begin. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The present invention is explained in more detail with reference to the following figures. The following is shown:

[0043] Figure 1 is a first exemplary embodiment of a method according to the invention;

[0044] Figure 2 is a second exemplary embodiment of a method according to the invention; and

[0045] Figure 3 is a third exemplary embodiment of a method according to the invention. DETAILED DESCRIPTION

[0046] Figure 1A first exemplary embodiment is shown. In a first step 1., an order from a customer is received by the manufacturer's server HS of a field device manufacturer. In the process of placing the order, the customer enters the exact details of the field device FG to be ordered together with the identification of the ticket server TS for operating the customer's existing field devices into the manufacturer's server HS. After verifying the customer's order data (e.g. whether the ticket server TS specified by the customer in the process of the order actually belongs to the customer), the order is created.

[0047] The manufacturer's server then creates registration data RD associated with the ordered field device FG. The registration data consists of an identification information item ID of the field device FG (eg a serial number) and a first password-related information item KR1.

[0048] In a second step 2., a communication connection is established between the manufacturer's server HS and the customer's ticket server TS, in particular via the Internet. The manufacturer's server HS sends registration data RD to the ticket server TS via the communication connection. In addition, the ticket server TS sends a second cryptographically relevant information item KR2 to the manufacturer's server via the communication connection. For example, the cryptographically relevant information KR1, KR2 comprises a public key of a key pair.

[0049] The registration data RD and the second cryptographically relevant information item KR2 are sent in the form of a so-called order ticket. An order ticket is a ticket which, in addition to the signature of the unit that issued the ticket (in this case the ticket server TS or the manufacturer's server HS), contains a digital tamper-proof data packet of additional data. The other data are the registration data RD or the second cryptographically relevant information item KR2. With the help of previously exchanged information, such as a public key, the ticket server TS and the manufacturer's server HS are able to verify the respective order ticket with respect to integrity and authenticity and process its content only if the verification is successful.

[0050] The communication between the ticket server TS and the manufacturer's server HS is realized via the REST API of the registration module RD. After successful authentication, the registration module RD processes the registration data RD and stores the first password-related information item KR1 on the ticket server TS under the identification information ID of the field device FG. It can also be provided that the data exchange between the ticket server TS and the manufacturer's server HS is realized via the registration module.

[0051] In step 3., the field device FG is produced. During production or after production is completed, the second cryptographically relevant information item KR2 is written into the field device FG. In the case where the cryptographically relevant information is a public key, the private key corresponding to the first cryptographically relevant information item KR1 sent to the ticket server TS is also written into the field device FG.

[0052] In step 4., the field device FG is delivered to the customer and installed in the measuring station of his facility. By exchanging the password-related information KR1, KR2, the field device FG and the ticket server TS have become known to each other. The field device FG can be operated via the transmission medium TM. For this purpose, the ticket server TS sends the ticket to the field device FG. In this case, the transmission medium TM is an operating unit, in particular a laptop or a mobile device in the form of a smartphone or tablet. Alternatively, the transmission medium can also be a storage medium. The term "transmission medium" can also be understood as a network via which the ticket is sent directly from the ticket server TS to the field device FG.

[0053] In this case, the control unit is connected to the ticket server TS via a mobile network or via a local network as a transmission medium TM. The connection between the control unit and the field device FG can be realized, for example, wirelessly via a Bluetooth connection or via a wired connection (for example via the CDI protocol). In the case where the field device FG is to be operated, the ticket issued by the ticket server TS contains data authorizing the operating unit to perform a defined work order on a defined existing field device. Here, the ticket is signed with the help of the private key of the key pair. The field device FG verifies the ticket for authenticity and integrity (with the help of the second password-related information item KR2, in this case the public key of the key pair), and releases the corresponding operating function for the operating unit. The field device FG confirms that the operating action has been performed by issuing a ticket, which is transmitted back to the ticket server TS via the transmission medium. The ticket server is able to verify the integrity and authenticity of this ticket with the help of the first password-related information item.

[0054] exist Figure 2 A second exemplary embodiment of the method is shown in Figure 1 The methods described are largely similar. In particular, method steps 1., 3. and 4. correspond to Figure 1 The exemplary embodiment differs from the reference in step 2. Figure 1 Describe the method.

[0055] The manufacturer's server HS and the ticket server TS cannot establish a communication connection with each other. The sending of the registration data RD or the first exchange ticket containing the registration data RD from the manufacturer's server HS or the registration module RM to the ticket server TS is carried out in the form of an optically detectable code, in particular a barcode, or as a QR code. For this purpose, the registration module RM of the ticket server TS is assigned an optical detection unit OE, by means of which the optical code can be read.

[0056] The optical detection unit EE can be designed as a (portable) hardware module, which is the registration module RM. Alternatively, an operating unit, such as a mobile device, can be used which comprises the optical detection unit OE and is communicatively connected to the registration module RM. The optical detection unit OE can be, for example, a photodiode or a camera.

[0057] The code can be transmitted to the user as a paper printout. Alternatively, the optically detectable code can also be located on the manufactured field device FG, for example on a nameplate or, for example as a sticker, on the housing of the field device.

[0058] The second password-related information item KR2 from the ticket server is transmitted by the user to the manufacturer's server. This can be achieved by user input or by transmitting a file containing the second password-related information item KR2.

[0059] exist Figure 3 A third exemplary embodiment of the method is shown in Figure 1 The methods described are largely similar. In particular, method steps 1. and 4. correspond to Figure 1 This exemplary embodiment differs from the reference in steps 2. and 3. Figure 1 Describe the method.

[0060] Here too, the manufacturer's server HS and the ticket server TS cannot establish a communication connection with each other. During the ordering process of the field device FG, a digital image DT is created for this field device FG. A digital image (also called a "digital twin") is a virtual representation of a field device with the same properties as the real field device FG. For example, the digital image DT is assigned the same configuration and parameter settings as the real field device FG.

[0061] In a second step 2., the manufacturer's server HS sends registration data RD to the digital image DT of the field device FG. Furthermore, the ticket server TS or the registration module RM sends a second password-related information item KR2 to the digital image FT of the field device FG.

[0062] In step 3., for example after production of the field device FG or at another point in time when the field device FG is already physically present, the field device FG will synchronize with its digital image DT in order to write the second password-related information item KR 2 into the field device FG.

[0063] The method according to the invention makes it possible to provide a mechanism for connecting field devices FG to ticket servers TS already at the time of production. Field devices FG are therefore already registered on the ticket server when delivered to the customer. The customer can then start managing new field devices FG directly via the ticket server in his facility system.

[0064] List of reference numerals

[0065] 1., 2., ..., 4. Method steps

[0066] API REST API

[0067] Digital images of DT field devices

[0068] FG Field Devices

[0069] HS Manufacturer's Server

[0070] ID Identification information of the field device

[0071] KR1 First password related information items

[0072] KR2 Second password related information items

[0073] OE Optical Inspection Unit

[0074] RD Registration Data

[0075] RM Registration Module

[0076] TM Transmission Medium

[0077] TS Ticket Server.

Claims

1. A method for integrating a field device (FG) into an operating system of an automation system, wherein: The operating system comprises at least one transmission medium (TM) and a ticket server (TS) communicating with the transmission medium (TM), wherein the ticket server (TS) and existing field devices located in the system are designed to create and / or process tickets, the tickets in each case containing at least one cryptographically secure information item and in each case defining one or more recipients from the group of the ticket server (TS) and the existing field devices, wherein the ticket server (TS) and the existing field devices are designed to send the created tickets to the transmission medium (TM), wherein the transmission medium (TM) sends the tickets to the recipients, and wherein the recipients check the authenticity and integrity of the tickets, the method comprising: - an order is placed by the customer for said field device (FG); - generating, by a manufacturer's server (HS) based on the order, registration data (RD) for the field device (FG), wherein the registration data (RD) comprises identification information (ID) of the field device (FG) and first password-related information items (KR1); and - registering the field device (FG) as an existing field device on the ticket server (TS), wherein during the registration process the registration data (RD) are sent to the ticket server (TS) and a second password-related information item (KR2) of the ticket server (TS) is stored in the field device (FG).

2. The method according to claim 1, wherein: The ticket server (TS) is assigned a registration module (RM), wherein the registration data (RD) are transmitted from the manufacturer's server (HS) to the registration module (RM), wherein the second password-related information item (KR2) is transmitted from the registration module (RM) to the manufacturer's server (HS), and wherein the registration module (RM) registers the field device (FG) as an existing field device on the ticket server (TS).

3. The method according to claim 2, wherein: The registration data (RD) is transmitted to the registration module (RM) in the form of a first exchange ticket created by the manufacturer's server (HS), and wherein the second password-related information item (KR2) is transmitted to the manufacturer's server (HS) in the form of a second exchange ticket created by the registration module (RM) or the ticket server (TS).

4. The method according to claim 3 or 4, wherein: A software module or a hardware module is used as the registration module (RM).

5. The method according to claim 2, wherein: A digital image (DT) of the field device (FG) is generated during an ordering process, wherein the registration data (RD) is transmitted from the manufacturer's server (HS) to the digital image (DT) of the field device (FG), wherein the second password-related information item (KR2) is transmitted from the registration module (RM) to the digital image (DT) of the field device (FG), wherein the registration data (RD) is transmitted from the digital image (DT) of the field device (FG) to the registration module (RM) during a registration process.

6. The method according to claim 2, wherein: The manufacturer's server (HS) and the registration module (RM) are in a communication connection, wherein the registration data (RD) are transmitted from the manufacturer's server (HS) to the registration module (RM) via the communication connection, and wherein the second password-related information item (KR2) is transmitted from the registration module (RM) to the manufacturer's server (HS) via the communication connection.

7. The method according to claim 6, wherein: The manufacturer's server (HS) accesses the registration module (RM) via its REST API (API) for the purpose of mutual data or information transfer.

8. The method according to claim 2, wherein: The manufacturer's server (HS) and the registration module (RM) are not in communication connection.

9. The method according to claim 8, wherein: The registration data (RD) is input into the registration module (RM) by a user via a graphical user interface.

10. The method according to claim 8, wherein: The registration data (RD) or the first exchange note containing the registration data (RD) are present as an optically detectable code, in particular as a barcode or as a QR code, wherein an optical detection unit (OE) is assigned to the registration module (RM) and wherein the registration module (RM) reads the code via the optical detection unit.

11. The method according to claims 4 and 8, wherein: The first exchange ticket is transmitted from the manufacturer's server (HS) to a data carrier, and wherein the first exchange ticket is transmitted from the data carrier to the registration module (RM).

12. The method according to claim 8, wherein: The second password-related information item (KR2) is communicated to the manufacturer's server (HS) during the ordering process by the user, in particular by user input or by transmitting a file containing the second password-related information item (KR2).

13. The method according to one of the preceding claims, wherein: An operating unit for operating an existing field device located in the installation is provided as a transmission medium (TM), wherein the ticket contains data authorizing the operating unit to execute a defined work order on a defined existing field device.

14. The method according to one of the preceding claims, wherein: The operating unit authenticates itself to the existing field device defined in the corresponding ticket.

Images