Method and system for logging on a user to one or more field devices of automation technology

Abstract

The invention relates to a method for logging on a user (BN) to one or more field devices (FG), comprising the steps of: operating a ticket server (TS) for user management by the manufacturer of the field device (FG); linking the field device (FG) to the ticket server (TS), as a result of which the ticket server (TS) and the field device (FG) have a cryptographically secured and mutual trust relationship and are designed for mutual transmission and reception of tickets; linking an operating unit (BE) to the ticket server (TS), as a result of which the ticket server (TS) and the operating unit (BE) are in a cryptographically secured and mutual trust relationship; logging on a user (BN) by means of first login data at the ticket server (TS) via the operating unit (BE); generating an account ticket (T) for each of the linked field devices (FG) by way of the ticket server (TS) for the user (BN) with second login data for the field device (FG); in particular, the second login data are the same as the first login data; transferring the account tickets (T) from the ticket server (TS) to the operating unit (BE); generating an SSO ticket (SSO-T) by way of the ticket server (TS) for the operating unit (BE), wherein the SSO ticket (SSO-T) comprises the second login data; transferring the SSO ticket (SSO-T) to the operating unit (BE); transporting the account ticket(s) (T) to the field device (FG) by means of the operating device (BE) and transferring the account ticket (T) to the field device (FG); checking the account ticket (T) by way of the field device (FG) in regard to whether the ticket (T) was actually created by the ticket server (TS); creating an account for the service engineer (BN) on the field device (FG) if the check is positive; and automatically logging on the user (BN) to the field device (FG) via the operating device (BE) using the second login data stored in the SSO ticket (SSO-T).

Description

[0001] Method and system for logging a user into one or more field devices of automation technology

[0002] The invention relates to a method for registering a user on one or more field devices of automation technology. Furthermore, the invention relates to a system which is designed to carry out the method according to the invention.

[0003] Field devices are already known from the state of the art and are used in industrial plants. They are widely used in process automation as well as in manufacturing automation. In principle, 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 devices 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.Mobile control units can also be used to operate field devices that have an FDT framework application implemented. For example, there are control units that are connected to the fieldbus network. However, the control unit can also communicate with the field devices via a wireless communication connection, particularly based on a Bluetooth standard. The applicant manufactures and distributes devices that, as so-called Bluetooth gateways, allow the coupling of control units with 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.

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

[0007] 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 German Federal Security Act (Bundessicherheitsgesetz), 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. The authorization must be configured so that the user has (permanently) all the permissions necessary to perform their tasks.

[0008] To reduce the administrative burden of managing individual field devices to an acceptable level, some efforts are being made to establish centralized management, similar to the long-standing practice in the IT sector for managing IT equipment (e.g., printers, workstations, etc.). An example of such a concept is disclosed in DE 102018 102608 A1, which describes a transport device onto which user data is transferred from a user database. After verifying the user data, the field device is granted access to it.

[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 job ticket, which is transmitted from a server to the mobile device and contains the access rights and authorized tasks for the field device. This job ticket is transmitted when a connection is established with the field device. If the necessary authorization is present, the tasks contained in the job ticket, such as...

[0010] Parameterization actions or performing functional tests can be carried out using the field device.

[0011] Under the assumed conditions, the field devices and their configuration interfaces are well protected, and only authenticated and authorized users have access, for example, to configure the device.

[0012] However, entering user data, such as username and password, via the control unit every time a field device is operated is error-prone and time-consuming.

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

[0014] Caching passwords in web browsers or using password safes (e.g., "KeyPass") on IT devices also represent state of the art.

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

[0016] The aforementioned state of the art is not applicable to offline field devices, and an industry-specific SSO solution that specifically includes offline devices is not available.

[0017] The patent DE 102023 133 179, which was unpublished at the time of filing of the present document, describes an SSO solution using a ticket server at the user's site. However, smaller companies or municipal authorities often lack the resources and infrastructure to implement this method. Based on this problem, the invention aims to present a concept that allows for a user-friendly registration process on field devices, even over extended periods, while maintaining security.

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

[0019] Specifically, the solution is implemented through a process comprising the following steps: The field device manufacturer operates a ticket server for user management; the field device is linked to the ticket server, establishing a cryptographically secured and mutually trusted relationship between the ticket server and the field device, enabling the mutual transmission and receipt of tickets; a control unit is linked to the ticket server, again establishing a cryptographically secured and mutually trusted relationship between the ticket server and the control unit; a user logs in to the ticket server via the control unit using their initial login credentials; the ticket server generates an account ticket for each linked field device for the user, using a second login credential for the field device (specifically, the second login credentials are the same as the first); the account tickets are then transferred from the ticket server to the control unit.Generating an SSO ticket from the ticket server for the operator panel, where the SSO ticket includes the second login credentials; transferring the SSO ticket to the operator panel; transporting the account ticket(s) via the operator panel to the field device and transferring the account ticket to the field device; verifying the account ticket on the field device to ensure it was indeed created by the ticket server; creating an account for the service technician on the field device if the verification is successful; and automatically logging the user into the field device via the operator panel using the second login credentials stored in the SSO ticket.

[0020] The invention solves the problem that, before operating field devices, for example via smartphone or control units such as the "FieldXpert" distributed by the applicant, the user has to log in to the field device each time by entering a username and password. This is error-prone – especially with secure passwords of at least 11 characters – and time-consuming.

[0021] The core of the invention lies in the implementation of a "single sign-on" concept, which is also applicable to offline field devices. This requires a central ticket server at the field device manufacturer, which establishes a mutual, cryptographic trust relationship with both the field devices and the control unit required for offline operation. A single login to the ticket server is sufficient for the user to obtain secure access to the selected field devices within a configurable validity period – for example, during a technician's entire shift – using the rights (authorization) stored in the user account. This occurs after the account ticket has been successfully transferred to the field device. The account ticket is time-limited in one configuration.

[0022] The account ticket only needs to be transferred to the field device once within the validity period; in other words, the account is only generated once within the validity period. If it already exists, it will not be created again.

[0023] For automatic login, the ticket server also creates a single sign-on ticket (SSO ticket) and transmits it to the control unit. Since the login information (referred to as "second" login data in this document) from this SSO ticket is automatically provided to the control unit during each login process, eliminating the need for manual entry by the user, the login information is no longer required.

[0024] In one implementation, the first and second login credentials are different; in particular, different passwords are used. In another implementation, a randomly generated password is used by the ticket server for single sign-on, a password the user does not know.

[0025] In one configuration, the first and second login credentials are the same. This has the advantage that the user can also log in via a different interface (e.g., a local display on a field device without SSO capability) because the user knows the password (which wouldn't be the case with a password randomly generated by the ticket server). This works if the password is the same as on the ticket server.

[0026] "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 states that an account is created on a field device using the account ticket.

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

[0028] The operator unit also establishes a mutual, cryptographic trust relationship with the ticket server. This means that the components have been previously acquainted. The registration process is analogous to registering new field devices with the ticket server. Specifically, the ticket server sends so-called "join tickets" to the operator unit, enabling the exchange of cryptographic information that establishes the trust relationship. The ticket server and the operator unit have thus 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).This ensures that the data exchange between the respective components, which have this relationship of 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 user unit "trusts" the ticket and its contents because the user unit and the ticket server have a mutual relationship of trust. In the context of this document, this means that login data is stored in the SSO ticket.

[0029] According to an advantageous embodiment of the method, the operating unit stores the account ticket in a cryptographically secured cyberwallet on the operating unit. Such a cyberwallet is a storage location on the operating unit that is cryptographically protected. Examples of such cyberwallets include application software such as Apple Wallet, Google Wallet, or Microsoft Wallet, which can be used to store vouchers, boarding passes, and similar virtual objects. The wallet can also be run as an app on the operating device.

[0030] One design stipulates that the account ticket and / or the SSO ticket are time-limited. The account ticket has a longer validity period than the SSO ticket.

[0031] An advantageous implementation of the procedure provides that, after the time limit expires, the control unit automatically logs out of the corresponding field devices. Re-login with the login ticket is then no longer possible. Another implementation provides that the field device itself generates a login confirmation ticket containing information about who logged in and whether the login was successful.

[0032] One design involves transferring the login confirmation ticket to the control unit.

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

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

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

[0036] The invention is explained in more detail with reference to the following figure. It shows

[0037] Fig. 1 : an embodiment of the system according to the invention.

[0038] This document is based on an established field device ticket server infrastructure. There is a ticket server (TS) operated by the field device manufacturer (FG). The field device (FG) is linked to the ticket server (TS) via a "join process," as shown below. This is illustrated in Fig. 1 by a dotted line between the field device (FG) and the ticket server (TS). This linking process occurs, 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 field device (FG) and the ticket server (TS) have performed a key exchange and, after a Diffie-Hellman key exchange, have determined the common symmetric key (secret). Cryptographically relevant information is thus exchanged beforehand, for example, in the form of a public key from each key pair, in order to subsequently verify authenticity and integrity.

[0039] The user typically operates a variety of different field devices; only a single field device (FG) is shown. In the following, "field device" is used in the singular, but it always refers to multiple or numerous field devices. All field devices are linked to the ticket server and stored there with corresponding data, such as serial number, type, software version, links to datasheets, properties, etc. A kind of digital twin of the field device (FG) is therefore stored in the ticket server (TS).

[0040] The "user" is, for example, a plant operator. A ticket server (TS) can be implemented on the applicant's IoT infrastructure, such as the "Netilion" platform from the Endress+Hauser Group. Additional services can also be provided via this platform. In any case, the ticket server (TS) is operated by the manufacturer of the field device (FG).

[0041] 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 configured to create and receive tickets (see below), specifically account tickets (T) and single sign-on tickets (SSO-T). In general,

[0042] “Tickets” are described, for example, in DE 102018 102608 A1 and DE 10 2019 131 860 A1.

[0043] A ticket 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.

[0044] A ticket generally defines order data for a "work order" to be carried out. This order data can include, for example: account creation, 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.

[0045] This document contains two types of tickets: via an “account-

[0046] A ticket (reference "T") creates an account for user BN on the field device FG, which user BN can then use to log in to the field device FG. The account ticket T therefore includes metadata that is at least partially specific to the respective field device, such as the serial number or another unique identifier of the field device. Furthermore, the ticket contains the "actual" content (often referred to as the "payload"). In this document, this consists of instructions for creating an account on the field device.

[0047] Secondly, a "Single Sign-On Ticket" or "SSO Ticket" (reference "SSO-T") contains the login credentials of user BN for the field device FG. For the purposes of this document, these are referred to as "second" login credentials. Ideally, the login credentials for the ticket server TS and the field device FG are the same. 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. Sensitive data, such as logs, account databases, keys, certificates, and interface configurations, are stored encrypted in this Field Device Authentication Module (FDAM). 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 for 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.

[0048] The field device FG can be an online field device, meaning it communicates directly with the ticket server TS via a network, for example, via mobile network (3G, LTE, 5G, etc.). 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 field 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.

[0049] When the field device (FG) is delivered from the manufacturer to the user, no accounts are created on the field device. However, a digital copy (see above) is located on the ticket server (TS).

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

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

[0052] The operator unit BE is also linked to the ticket server TS via a "join process." 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, for example, the creation and sending of join tickets from the ticket server TS to the operator unit BE, thereby transmitting cryptographic information, particularly 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 verify authenticity and integrity. The application on the control unit (BE) advantageously includes a cryptowallet (W) for the secure cryptographic storage of the cryptographic keys. The shared symmetric key calculated as a result of the join process is securely stored therein. Examples include Microsoft Wallet, Google Wallet, and Apple Wallet.

[0053] User BN has an account on the ticket server TS. User BN is, for example, an employee of the plant operator or a service technician from the manufacturer of the field device FG. User BN logs into the ticket server TS with their login credentials (access data; "initial" login data). The initial login credentials are, for example, a username and password. After logging in, the field devices FG are assigned to user BN's account. This is done, for example, using the serial number or information from the operator panel BE. One or more apps A run on the operator panel BE, which are designed, among other things, to connect to and configure the field device FG. Since user BN logs in with the operator panel, this information from the operator panel can be used, for example, by transferring the data from app A to the ticket server TS to create the necessary connections.In one configuration, a connection to the ticket server TS can be established directly from the app A to connect to the field device FG.

[0054] The ticket server TS then generates account tickets (T) for the linked field devices (FG), one account ticket T per field device FG. An account ticket T can be used to create an account, i.e., a login, on a field device. The account ticket preferably contains the same login credentials as the (first) login credentials of the user BN on the ticket server TS. Alternatively, second (different, possibly randomly generated) login credentials can be used. The account ticket T is encrypted with a shared symmetric key and secured, for example, with HMAC (e.g.,...).ChaCha20-Poly1305) and contains the specified validity period and login information, such as the username of user BN and, if applicable, a password verifier (an intermediate value for a cryptographic function used by the field device and operator panel to determine a common symmetric key for the field device and operator panel) from the ticket server TS database. Alternatively, a password in plaintext or a random temporary password may be included instead of the password verifier.

[0055] The ticket server TS then generates a single sign-on ticket (SSO-T) for the operator unit BN, whereby the SSO tickets contain the login data (for the ticket server TS); preferably the same login data, but possibly "second" login data. A separate SSO ticket is created for each field device (FG) linked to the ticket server TS.

[0056] The account ticket T and / or the SSO ticket may be time-limited. In one configuration, after the time limit expires, the operator unit BE automatically logs out of the corresponding field devices FG.

[0057] The account ticket T and the SSO ticket are transferred to the control unit BN. This is indicated by reference symbol (1) in Fig. 1. The SSO ticket is stored in a cryptographically secured area of ​​the control unit BN, for example in a wallet W (see above). In Fig. 1, an SSO ticket is already stored in wallet W.

[0058] The account ticket T is generally transmitted to the field device FG via any means of transport, i.e., 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 then transferred to the field device FG. The transport method via the operating unit BE is shown and preferred, which will be explained in more detail below.

[0059] The account ticket T is transported and transferred to the field device FG via the control unit BN. User BN therefore walks to the field device FG with the control unit BN. This is indicated by reference numeral (2) in Fig. 1. A connection is then established, for example via Bluetooth, using the app A between the field device FG and the control unit BE, and the account ticket T is transferred in this way. The field device FG has, for example, an integrated Bluetooth interface. This may also occur via the app A, and in one configuration, even in the background without any action required from user BN.

[0060] The field device FG then checks whether the account ticket T was actually created by the ticket server TS. More precisely, the FDAM in the field device FG validates and decrypts ticket T.

[0061] If the test is successful, an account for user BN will be created on the field device FG with the specified login data, access rights and, if applicable, the stored validity period.

[0062] Finally, user BN logs in via their account on the field device FG. User BN can generally log in with the same password as on the ticket server TS. Furthermore, user BN has access to the field device FG with the permissions they have configured on the ticket server TS. User BN logs in to the field device FG using their second login credentials. For this, user BN is physically present at the field device FG and selects it to establish a connection (for example, by selecting it from a live list). Login is performed using the username and password. If the field device FG can verify these credentials as valid and the login time falls within the defined validity period, user BN logs in to the field device FG using their control unit BE. Access to the field device FG is granted according to the assigned access rights.

[0063] According to the invention, user BN logs in automatically to the field device FG via the operator panel BE using the SSO ticket SSO-T stored in Wallet W or the login data stored in the SSO ticket. User BN does not need to do anything. Depending on the settings of the operator panel BN, proof of identity is required for a successful login process, for example, the operator panel PIN, a fingerprint on the operator panel, an eye scan, or similar. If the operator panel is configured as an iPhone, for example, "Face ID" can be used.

[0064] This process step can be repeated multiple times without the user BN having to manually enter their login information (single sign-on). Logging in to additional field devices is also possible if these have been previously selected by the user BN and prepared accordingly via tickets as described above.

[0065] The field device FG1 can then be operated by user BN using the usual tickets (see, for example, DE 102019 131 860 A1).

[0066] Furthermore, a "return channel" can be established: the field device FG creates a ticket as a "login confirmation ticket" TB with information about who logged in and whether the login was successful. This ticket TB is transmitted to the control unit BE and, if necessary, forwarded to the ticket server TS. It can be collected in an aggregated logbook compliant with national standards and used for auditing purposes.

[0067] Reference symbol list

[0068] An App

[0069] BE Control Unit BN User / User

[0070] FG Field Device

[0071] SSO-T Single Sign-On Ticket

[0072] T Account Ticket

[0073] TB Confirmation Ticket TS Ticket Server

Claims

Patent claims 1. Procedure for registering a user (BN) on one or more field devices (FG) of automation technology, comprising the steps: Operation of a ticket server (TS) for user management by the manufacturer of the field device (FG); Linking the field device (FG) with the ticket server (TS), whereby the ticket server (TS) and the field device (FG) are in a cryptographically secured and mutually trusted relationship and are designed for the mutual transmission and receipt of tickets; Linking a control unit (CU) to the ticket server (TS), whereby the ticket server (TS) and the control unit (CU) are in a cryptographically secured and mutually trusting relationship; User registration (BN) using initial login data on the ticket server (TS) via the control unit (BE); Generating one account ticket (T) for each of the linked field devices (FG) from the ticket server (TS) for the user (BN) with second login data for the field device (FG), in particular the second login data being the same as the first login data; Transferring the account tickets (T) from the ticket server (TS) to the operator unit (BE); generating an SSO ticket (SSO-T) from the ticket server (TS) for the operator unit (BE), where the SSO ticket (SSO-T) includes the second login data; Transfer of the SSO ticket (SSO-T) to the control unit (CE); Transporting the account ticket(s) (T) using the operating device (BE) to the field device (FG) and transferring the account ticket (T) to the field device (FG); The field device (FG) checks the account ticket (T) to see if the ticket (T) was actually created by the ticket server (TS); Creating an account for the service technician (SN) on the field device (FD) if the test is successful; and Automated login of the user (BN) to the field device (FG) via the operator panel (BE) using the second login data stored in the SSO ticket (SSO-T).

2. Method according to claim 1, wherein the operating unit (BE) stores the SSO ticket (SSO-T) in a cryptographically secured cyberwallet of the operating unit (BE).

3. Method according to claim 1 or 2, wherein the account ticket (T) and / or the SSO ticket (SSO-T) are time-limited.

4. A method according to the preceding claim, wherein, after the expiry of the time limit, the control unit (CU) automatically logs out of the corresponding field devices (FD).

5. A method according to any of the preceding claims, wherein the field device (FD) itself creates a ticket as a login confirmation ticket (TC) containing information about who logged in and whether the login was successful.

6. Method according to the preceding claim, wherein the login confirmation ticket (TB) is transmitted to the control unit (BE).

7. A method according to one of the two preceding claims, wherein the confirmation ticket (TB) is transmitted to the ticket server (TS).

8. A system configured to carry out the method according to one of claims 1 to 7, comprising at least one field device (FG), one ticket server (TS), and one operator unit (BE).

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

Images