Method for signing a device report of a field device

Abstract

The invention relates to a method for signing a device report (36) of a field device (10), comprising: - providing a system (100) comprising a field device (10), a communication unit (20) and a computing unit (30), wherein the field device (10) stores raw data (11) and a first private key (12) for creating a first signature (13), wherein the computing unit (30) has a first public key (36) complementary to the first private key (12), and a second private key (32) for creating a second signature (33), wherein the communication unit (20) is connected to the field device (10) and the computing unit (30) for communication; and - requesting raw data (11) from the field device (10) by means of the communication device (20).

Description

[0001] Procedure for signing a device report from a field device

[0002] The invention relates to a method for signing a device report of a field device.

[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 control units, 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 operating devices are frequently used to operate field devices (e.g., to configure parameters or retrieve data). These are connected to a field device either via cable (e.g., a service interface) or wirelessly (e.g., via Bluetooth). Examples of operating devices include laptops, mobile devices such as smartphones or tablets, or central asset management stations.

[0007] To operate the field devices, appropriate operating programs (operating tools) are required. These run either independently on the higher-level units or in the mobile operating devices (Endress+Hauser FieldCare, PACTware, AMS Fisher-Rosemount, Siemens PDM) or are integrated into control room applications (Siemens PCS7, ABB Symphony, Emerson Delta V). The term "operating" includes, among other things, configuring the field device, updating the field device, and / or querying and visualizing process data and / or diagnostic data from the field device.

[0008] The integration of field devices into such operating programs is achieved via device drivers or device descriptions. These are provided by the device manufacturers so that the higher-level units, or the operating programs running on these higher-level units, can recognize and interpret the meaning of the information supplied by the field devices. Such an operating program, into which the device descriptions or device drivers are loaded, is also referred to as a framework application.

[0009] For comprehensive operation of field devices, special device drivers, so-called DTMs (Device Type Managers), are available that comply with the FDT (Field Device Tool) specifications or correspond to FDI packages in the FDI environment. Many field device manufacturers supply corresponding DTMs for their field devices. The DTMs encapsulate all variables and functions of the respective field device and usually offer a graphical user interface for operating the devices within the framework application.

[0010] The device drivers offer the possibility to evaluate, diagnose, and / or verify certain device functionalities. Many modern field devices, for example, enable a self-test, such as within the framework of so-called "Heartbeat Technology" (a self-test functionality or SIL functionality implemented in the applicant's field devices). The results of these self-tests, evaluations, etc., are output by the device driver in a report. This report contains the relevant report parameters, i.e., test results, device status, etc. The report is typically sent directly to a printer and printed in physical form. The report is then processed, for example, by service personnel, who perform a visual inspection and subsequently sign it. After signing, the report is scanned or stored physically.

[0011] A method for creating such reports is known, for example, from DE 10 2021 124 249 A1. However, a disadvantage of this method is that creating and storing physical reports is costly. Therefore, the creation of electronic reports is proposed in the prior art. However, a problem here is that the authenticity of the report cannot yet be guaranteed.

[0012] It is therefore an object of the invention to provide a method which enables the safe, authentic and simple creation of a device report.

[0013] This problem is solved according to the invention by a method for signing a device report of a field device according to claim 1.

[0014] The method according to the invention comprises:

[0015] Providing a system comprising a field device, a communication unit, and a computing unit, wherein the field device stores raw data and a first private key for creating a first signature, wherein the computing unit comprises a first public key complementary to the first private key, and a second private key for creating a second signature, and wherein the communication unit is communicatively connected to the field device and the computing unit.

[0016] Requests for raw data from the communication unit to the field device, signing of the raw data with the first signature by the first private

[0017] Key to the field device,

[0018] Reading the signed raw data from the field device by the communication unit,

[0019] Storing the signed raw data in the computing unit by the

[0020] Communication unit,

[0021] Verification of the authenticity of the first signature of the signed raw data with the first public key by the computing unit,

[0022] Generating a device report based on the signed raw data, depending on the check performed by the computing unit.

[0023] Signing the device report with the second signature using the second private key of the computing unit,

[0024] Providing a second public key complementary to the second private key for verifying the authenticity of the second signature of the signed device report.

[0025] The method according to the invention makes it possible to create a device report whose authenticity can be reliably verified. Furthermore, it ensures that the creation of the device report is secure and simple.

[0026] According to one embodiment of the invention, the signed raw data are combined with the device report as a signed combination report when generating the device report.

[0027] According to a further embodiment of the invention, the signed

[0028] Raw sensor data and a sensor trend are determined from the signed raw data. According to one embodiment of the invention, the device report is in PDF format, and the signed raw data is attached to the PDF, embedded as metadata in the PDF, embedded as a Data Matrix code, or embedded as a QR code in the PDF.

[0029] According to one embodiment of the invention, the computing unit is a local computer.

[0030] According to one embodiment of the invention, the computing unit is a local server or an external server.

[0031] According to one embodiment of the invention, the device report is stored on the local server or the external server.

[0032] According to one embodiment of the invention, the signed raw data contains an identification code to identify the field device.

[0033] According to one embodiment of the invention, the communication unit is part of the computing unit and is implemented in a sandbox module.

[0034] The invention is explained in more detail with reference to the following description of the figures. It shows:

[0035] - Fig. 1 : a schematic representation of the method according to the invention.

[0036] Figure 1 shows a system 100 comprising a field device 10, a communication unit 20, and a computing unit 30. The system 100 enables the creation of a secure and authenticatable device report for the field device 10.

[0037] The field device 10 stores raw data 11 and an initial private key 12 for creating an initial signature 13. The initial private key 12 is stored in a protected area of ​​the field device 10. The raw data 11 includes, for example, parameter data of the field device 10 or of the sensor or sensors connected to the field device 10. The field device 10 comprises a sensor, such as a pH sensor, a conductivity sensor, or another sensor (not shown). The field device 10 is capable of exchanging data with the communication unit 20, as indicated by the arrows between the field device 10 and the communication unit 20. This exchange or communication takes place, for example, via a Bluetooth module, a WLAN module, or another communication module, such as a wired communication module capable of communicating via HART.

[0038] The communication unit 20 is, for example, a tablet, smartphone, or a PC with so-called "FieldCare" software. The communication unit 20 is capable of sending a data request to the field device 10, for example, to read parameter data from the field device 10. The communication unit 20 is capable of storing the data read from the field device 10 in the processing unit 30, in particular in a memory location, e.g., a specific folder. The communication unit 20 preferably includes a driver 21, which is capable of communicating with the field device 10 and with the processing unit 30. The driver 21 is preferably embedded in a sandbox module 22 on the communication unit 20. The sandbox module 22 protects the communication unit 20 from access by the driver 21.

[0039] The computing unit 30 has a first public key 36 that is complementary to the first private key 12, and a second private key 32 for creating a second signature 33. The first public key 36 is suitable for verifying the first signature 13, with which the raw data 11 was signed with the first private key 12. The computing unit 30 is, for example, a local computer, a Windows PC (so-called on-premise machine), a local server, an external server, a Windows Server (so-called on-premise service), or an internet-based service such as "Netilion".

[0040] Figure 1 also shows a user module 40, which is, for example, a PC, tablet, smartphone, or similar device, and is suitable for displaying the device report of the field device 10 and verifying it using a second public key 41. Naturally, the user module 40 includes suitable software for opening the device report, such as software for reading PDF documents. In this case, the software is, of course, suitable for verifying a signed device report using the second public key 41.

[0041] The following section describes the inventive method for signing a device report of a field device.

[0042] First, the system 100 described above, consisting of the field device 10, the communication unit 20, and the computing unit 30, is of course deployed. All components of the system 100 are ready for operation.

[0043] Next, the communication unit 20 requests raw data 11 from the field device 10. This is illustrated in Figure 1 by the arrow from the communication unit 20 to the field device 10. The request is preferably made by the driver 21, which is operated in the sandbox module 22.

[0044] Then the raw data 11 is signed with the first signature 13 by the first private key 12 of the field device 10.

[0045] According to an optional embodiment of the invention, when signing the raw data 11, an identification code suitable for identifying the field device 10 is also appended to and signed with the raw data 11.

[0046] The signed raw data 14 is now read from the field device 10 by the communication unit 20. This step is illustrated in Figure 1 by the arrow from the field device 10 to the communication unit 20. Preferably, this readout is again performed by the driver 21.

[0047] The signed raw data 14 is then stored in the processing unit 30 by the communication unit 20. The signed raw data 14 is preferably stored in a specific folder, which is regularly checked for new content by the processing unit 30. This storage is also preferably performed by the driver 21. The driver 21 operates entirely within the sandbox module 22. This means that the requesting of raw data 11, the retrieval of the signed raw data 14, and the storage of the signed raw data 14 take place in a protected environment. This ensures that no so-called man-in-the-middle attacks or manipulation of the transferred data can occur.

[0048] Furthermore, the authenticity of the first signature 13 of the signed raw data 14 is checked by the computing unit 30 using the first public key 36. For this purpose, the computing unit 30 uses the first public key 36 to decrypt the first signature 13 with which the raw data was signed.

[0049] After verifying the authenticity of the first signature 13, a device report 31 is generated based on the signed raw data 14, depending on the verification by the processing unit 30. This means that if the verification of the authenticity of the first signature 13 shows that the first signature 13 was indeed created by the first private key 12 from the field device 10, then the signed raw data 14 is used to create a user-readable device report 31, for example, in the form of a PDF document or in another common format. The processing unit 30 has significantly more processing power than the field device 10 to generate the device report quickly. This has the advantage that the field device 10 is equipped with relatively low-power and therefore energy-efficient electronic computing components compared to the processing unit 30.The field device 10 is therefore ideally suited for use in, for example, potentially explosive atmospheres. A further advantage of generating the device report 31 solely on the processing unit 30 and not in the field device 10 is that the data size of the signed raw data 14 is significantly smaller than that of the device report 31 generated by the processing unit 30. This makes it possible, for example, to read the signed raw data 14 from the field device 10 using 4...20 mA data communication. Preferably, the device report 31 is stored on a server, such as a Windows SQL Server or a Netilion Library. The generated device report 31 is preferably stored on a local or external server.

[0050] According to an optional embodiment, the signed raw data 14 are evaluated by the processing unit 30 to determine, for example, a sensor trend. In this embodiment, the signed raw data 14 naturally include sensor data from a sensor connected to the field device 10, for example, a pH sensor, a conductivity sensor, or another sensor.

[0051] The device report 31 is then signed with the second signature 33 using the second private key 32 of the computing unit 30, resulting in a signed device report 34. The signed device report 34 generated in this way is secure against manipulation.

[0052] According to one embodiment, the signed raw data 14 is simultaneously signed by the processing unit 30 using the second private key 32 along with the user-readable device report 31, resulting in a so-called signed combination report 35. The signed raw data 14 is thus combined with the device report 31. Here, the signed raw data 14 is, for example, integrated as metadata in the device report 31. Alternatively, the signed raw data 14 is integrated as a data matrix code or a QR code in the device report 31. This has the advantage that the signed raw data 14 can be securely provided to the user so that they can evaluate it. For example, this makes it possible to perform the sensor trend analysis described above on a unit other than the processing unit 30. The user uses, for example, the application module 40 to read the signed device report 34.

[0053] Naturally, the signed device report 34 or the signed combination report 35 is provided to a user, as shown in Figure 1 by the arrow between the computing unit 30 and the user module 40.

[0054] Finally, a second public key 41, complementary to the second private key 32, is provided to verify the authenticity of the second signature 33 of the signed device report 34. This allows the user to verify the authenticity of the second signature 33 of the signed device report 34 using the user module 40, which utilizes the second public key 41. The use of the second public key 41 is preferably performed by software, such as PDF reader software like Adobe, which uses the second public key 41 when opening the signed device report 34 and indicates to the user that the opened PDF has been authenticated. Thus, authentication using the second public key 41 takes place in the background when the signed device report 34 is opened.Conventional PDF reading software typically includes such a function, which allows the use of keys for document authentication.

[0055] Thanks to the signed raw data 14 stored in the signed combination report 35, a user can infer a trend in the sensor's development. For example, sensor aging can be detected in this way.

[0056] The identification code mentioned above can also preferably be read by the user module 40 using the second public key 41 and the signed device report 34 or the signed combination report 35, thus enabling key-chain tracking. This makes it possible, for example, to determine which first private key 12 was used by the field device 10 to provide the raw data 11 with the first signature 13.

[0057] Reference symbol list

[0058] 10 field devices

[0059] 11 raw data

[0060] 12 first private key

[0061] 13 first signature

[0062] 14 signed raw data

[0063] 15 storage

[0064] 20 communication units

[0065] 21 drivers

[0066] 22 Sandpit Module

[0067] 30 computing units

[0068] 31 Device Report

[0069] 32 second private key

[0070] 33 second signature 34 signed device report

[0071] 35 signed combination report

[0072] 36 first public key 40 user module

[0073] 41 second public key

[0074] 100 System

Claims

Patent claims 1. Procedure for signing a device report (36) of a field device (10) comprising: - Providing a system (100) comprising a field device (10), a communication unit (20) and a computing unit (30), wherein the field device (10) stores raw data (11) and a first private key (12) for creating a first signature (13), wherein the computing unit (30) has a first public key (36) complementary to the first private key (12), and a second private key (32) for creating a second signature (33), wherein the communication unit (20) is communicatively connected to the field device (10) and the computing unit (30), - Requests for raw data (11) by the communication unit (20) to the field device (10), - Signing the raw data (11) with the first signature (13) using the first private key (12) of the field device (10), - Reading the signed raw data (14) from the field device (10) by the communication unit (20), - Storing the signed raw data (14) in the computing unit (30) by the communication unit (20), - Checking the authenticity of the first signature (13) of the signed raw data (14) with the first public key (36) by the computing unit (30), - Generating a device report (31) based on the signed raw data (14) depending on the check by the computing unit (30), - Signing the device report (31) with the second signature (33) using the second private key (32) of the computing unit (30), - Providing a second public key (41) complementary to the second private key (32) for verifying the authenticity of the second signature (33) of the signed device report (34).

2. Method according to claim 1, wherein the signed raw data (14) are combined with the device report (36) as a signed combination report (36) when generating the device report (36).

3. Method according to claim 2, wherein the signed raw data (14) comprise sensor data and a sensor trend is determined from the signed raw data (14).

4. Method according to claim 1 or 2, wherein the device report (31) is in PDF format and the signed raw data (14) is attached to the PDF or included as metadata in the PDF or included as a Data Matrix code in the PDF or included as a QR code in the PDF.

5. Method according to any of the preceding claims, wherein the computing unit (30) is a local computer.

6. Method according to any one of claims 1 to 4, wherein the computing unit (30) is a local server or an external server.

7. Method according to claim 6, wherein the device report (31) is stored on the local server or the external server.

8. Method according to any of the preceding claims, wherein the signed raw data (14) includes an identification code to identify the field device (10).

9. Method according to one of the preceding claims, wherein the communication unit (20) is part of the computing unit (30) and is implemented in a sandbox module (22).

Images