DE102014008654A1 - Temporary permission - Google Patents

Abstract

Methods for accessing an automation device (11) from a first terminal (12) are described. The first terminal (12) is connected via a first connection to the automation device (11). An access request (15) is sent to a second terminal (13) separate from the automation device (11), the access request (15) being transmitted via a second connection separate from the first connection. Subsequently, a token (16, 20) is generated at the second terminal (13) based on the access request (15) and from the second terminal (13) to a user (14) of the automation device (11) via the second connection or a third one Connection that is separate to the first and second connection is transmitted. The transmitted token (16, 20) is then input to the first terminal (12) and access to the automation device (11) based on at least one information contained in the input token (16, 20) is allowed, the at least one information temporary access to the automation device (11) allowed.

Description

1. Field of the invention

The present invention relates to methods and apparatus for temporarily accessing an automation device.

2. State of the art

Automation devices are widely used today and include all machines or equipment for automating a process, such as a manufacturing process. Such automation devices are also often referred to as automation systems. Such an automation system usually comprises a multiplicity of sensors which measure various physical variables in connection with the automation system. Furthermore, such an automation system also includes a multiplicity of control circuits in order to control the process as a function of the measured values provided by the sensors. These control loops can have actuators that perform some task within the process. For this purpose, the actuators are controlled in dependence on parameters to be set, so that the actuators can assume different states. For example, these states relate to the operating state of an actuator, or its position in relation to a component to be processed, or its position in relation to another actuator. To monitor and specify these parameters and states, today's automation systems all have a man-machine interface, which is also often referred to as a user interface. This user interface informs the user about the measured physical quantities, the currently prevailing parameters and the set parameters and the state of the actuators. The user can also actively intervene in the control of the automation system via the user interface and can, for example, specify parameters and states that the components of the automation system should assume. In the simplest case, this user interface can be a switch that switches off components of the automation system, that is, puts it in an operating state in which the component is disconnected from the supply network. In the more complex case, however, the user interface can also be a computer, generally a PC, with which a wide variety of parameters and states of the automation system can be monitored and changed, for example by means of a graphical user interface of a program executed on the computer. This can also be referred to as programming or parameterizing the automation system.

In this case, it is customary for the various users of the automation system to log on to the user interface (generally a computer) with a user ID and password that are specific to them, in order then to interact with the automation system and its components, for example with the aid of a graphical user interface. The graphical user interface can either constantly display the parameters and states of the automation system for everyone, or the parameters and states only become visible when the user has logged on to the user interface with his specific user ID and password. The different users have different authorization levels, so that not every user can change all parameters and states of the automation system via the computer. For example, some users have only one authorization level, which allows them to view the individual parameters and states of the automation system, but not to change them. In this case, one also speaks of the user having read-only access. Other users, on the other hand, can not only view the parameters and states of the automation system with their authorization level, but also change them. In this case, it is also said that the user has a read and write access. Here, the most varied authorization levels and gradations between the individual users can be realized. According to the different gradations, the users can then change more or less parameters and states. Users with full access to the automation equipment are also often referred to as administrators.

In the case of a malfunction or a malfunction of a component of the automation system or the entire automation system, it may be necessary that parameters or states of the automation system must be changed for troubleshooting. Here, the problem may arise that a currently located on-site user does not have the appropriate authorization level to make the necessary changes, for example, because this user is not an administrator and, for example, only has a read access. However, with this authorization level, the user does not have the authorization to change the parameters and states of the automation system and thus does not have the option of correcting the error. Accordingly, a user with a higher privilege level must be called or the on-site user must be assigned an elevated privilege level. This can be done, for example, by giving the user the user ID and password of a user with higher Authorization level, for example an administrator. However, this can be problematic since, in this case, the user can log on to the user interface at any time, that is to say not only at the time of the occurrence of the malfunction, but also at another time with the user ID communicated to him and can change parameters and states. This can lead to unpredictable and, above all, difficult to understand mistakes. The issuance of an administrator identifier and a corresponding password can also be problematic in that the corresponding user can intervene in the authorization level assignment of the other user and increase it.

Therefore, the issue of a higher privilege level to lower privilege users is nowadays mostly circumvented by the user interface, which is generally a computer, being accessed over an existing network connection from another location, usually a service center. Using this remote access, it is then possible to control the user interface or the automation system remotely and to remedy the malfunction. The users who remote control the automation system or the user interface via a network connection have the necessary authorization level to change parameters or states of the automation system. In this case, therefore, the user on site does not have to be informed of a user ID and password of a user with a higher authorization level.

The problem which arises in such a remote control of the automation system but is that a kind of connection between the automation system or the user interface and the outside world must be created. For example, such remote access may be via the Internet if the user interface has appropriate access. However, a remote access to the automation system or the user interface via the Internet always involves a certain security risk, namely that this possibility is exploited by third parties to gain access to the automation system. Furthermore, the remote access also has the disadvantage that the user who sets the new parameters and states is not on site and therefore can not monitor and intervene directly, if the change of the parameters and states does not correct the malfunction, but a deterioration. Furthermore, in the case of remote access, there may always be delays, for example due to short-term network disturbances or the like, which may result in the situation that it is not possible to react directly to a changing situation on the automation system. In extreme cases, this can result in damage to the entire automation system.

Older automation systems are also not necessarily equipped with a user interface that allows remote access. Furthermore, there are automation systems where the user interface does not allow remote access for safety-related reasons.

It would therefore be desirable if the on-site user were at least temporarily enabled to change the parameters and states of the automation equipment to correct the malfunction without experiencing the above-mentioned disadvantages.

3. Summary of the invention

This object is achieved by the methods and apparatus of the independent claims. Preferred embodiments of the methods and devices can be found in the subclaims.

An inventive method for temporarily accessing an automation device via a first terminal connected to the automation device via a first connection comprises the steps of receiving an access request to a second terminal separately from the automation device, wherein the access request is transmitted via a second connection which is separate from the first connection, generating a token at the second terminal based on the access request, transmitting the generated token from the second terminal to a user of the automation device via the second connection or a third connection that is separate to the first and second connection, inputting the transmitted Tokens at the first terminal and accessing the automation device based on at least one piece of information contained in the input token, wherein the at least one information temporary access to the Au automation device allowed.

In this case, the automation device can be an automation system which is connected to a first terminal in the form of a user interface, that is generally to a PC. A user of the user interface, in case that he needs an increased authorization level for accessing the automation device, can send an access request to a second terminal, for example to a terminal located in a service center. The transmission of the access request happens but via a connection that is separate from the first connection, so the Connection between user interface and automation device. Separately in this case means that the second connection does not allow any access or interaction with the first connection. For example, the user interface may be connected to the automation device via an intranet connection, and the access request is transmitted by the user via a separate Internet connection. In this case, it means separately that although the connections are the same in terms of hardware technology, there is no connection by software technology, ie no exchange of information between these two connections. Separate connections can be realized in this case by software technology, for example, a firewall. However, it is also conceivable that the connections are separated by hardware technology, ie the connections are physically separated from one another. This transmitted access request can then be used at the second terminal to generate a token, this token containing at least information that allows the user temporary access to the automation device. For example, the information may include the new permission level of the user. The token may be generated based on an algorithm that uses the access request to generate the token. However, the generation can also include access to tokens already present in the memory of the second terminal, the access to the memory in this case being based on the access request. The second terminal may then transmit the generated token, for example, directly to the user via the second connection used to convey the access request. Alternatively, the second terminal may also use a different third and again separate connection to communicate the generated token to the user. For example, the access request may have been transmitted by telephone to the second terminal and the generated token may then be transmitted by e-mail or short message service via SMS or MMS to a mobile phone of the user.

After receiving the token, the user can then enter the token at the first terminal connected to the automation device, which then grants the user access to the automation device on the basis of at least one information contained in the token. Entering in this case may mean that the user inputs the received token to a peripheral device of the first terminal. For example, the user may enter the token via a keyboard, or hold the received token in front of a corresponding reader of the first terminal, or the user may store the token on a data carrier medium and have the data medium read in at the first terminal. If the information includes the new authorization level, the authorization level of the user can be changed by entering the token at the user interface so that the latter can access the automation device at least temporarily according to its new authorization level and correspondingly change parameters and states of the automation device can to remedy a malfunction occurred. Temporarily in this case means that the token and the information contained therein preferably does not have validity indefinitely, but only has validity for a finite period of time. However, it may also be that the token contains information that causes the first terminal or the automation device to give the person who has entered the token an increased, for example a preset authorization level for a certain period of time, for accessing the first terminal or to grant the automation device.

The inventive method thus not only allows the separation between the first terminal, which is connected to the automation device, and the second terminal, but also allows that an on-site user, the otherwise no or only limited access to the first terminal and accordingly had on the automation device, at least temporarily receives access to the automation device.

In a preferred embodiment of the inventive method, the method further comprises processing the inputted token for obtaining the at least one information. The processing may include extracting the information from the token. For example, the token and the information contained therein may be encrypted, so that decryption is necessary to obtain the information. In this case, for example, the token can be generated by means of an algorithm on the second terminal and only by the application of a corresponding algorithm on the part of the first terminal can the information win again from the token. A variety of encryption algorithms are known to those skilled in the art, which can be used to embed the information in the token or to use the token and its form itself as an information carrier. For example, the information contained in the token may be the new permission level of the user, and the outer form of the token, such as its bit count or packet structure, may provide information about the length of time the token and thus the new permission level are valid. Both of the aforementioned information can also be included in the token. The Processing itself can not only be done on the first terminal, ie the user interface itself, but can also be done on the automation device. Where processing on the automation device has the advantage that the token and the information contained therein for the user interface, ie the first terminal, is not visible. Processing the input token may also involve verifying the token, that is, verifying that the token is valid. The person skilled in various ways known to verify the validity of information received. Checking the validity of the token also has the advantage that an additional security measure is introduced in order to prevent tokens from being generated by unauthorized third parties, who would then allow access to the user interface or to the automation device.

In a further preferred embodiment of the method, this comprises starting a timer after the token has been entered, the time duration of the timer being based on the entered token. In this case, the time duration may be included as information in the token, for example, or the token itself indicates by its design the desired time duration, for example by its bit length. The timer may be synchronous with a system time base of the automation device or the user interface. Different system-immanent time constants can be used as the system time base, for example a system clock, a clock counter or even fixed cycle times of defined subprocesses executed by the automation device. The timer is then either incremented or decremented according to this system immanent time constant, depending on whether the timer's time should elapse from the time period or should extend to the time duration. Accordingly, the timer runs either from the time duration to zero or from zero to the time duration. At the end of the timer, ie when it is at zero or the time has been reached, the token can be invalidated. This can cause access to the automation device to stop when the timer expires. This may, for example, result in a complete cessation of access to the automation device. However, it would also be possible that the access is not completely terminated, but only a lowering of the authorization level of the user after expiration of the timer takes place. This assumes that by entering the token, the user's permission level has been raised. This increase was only valid for the specified period of time. After expiration of the timer, it may thus be necessary for the user either to log in again with his normal user ID on the user interface because the access has been completely terminated, or the user only loses his elevated authorization level when the timer expires, but can continue to use the user interface use his normal permission level. In this case, the user can be informed at fixed time intervals that the timer expires and the termination of the access or the lowering of the authorization level is imminent. These time intervals can be defined, for example, in minutes, in a number of cycles or process cycles. For example, the user may be informed every 5 minutes that the timer expires. The time duration of the timer can also be compared with a maximum permissible time duration specifically for the automation device or specifically for the first terminal, ie the user interface. If the time period specified by the token is below this maximum permitted time duration, then the time period defined in the token can be used, otherwise the specific maximum time duration can be used. However, it may also be that if the time specified in the token exceeds the maximum time allowed by the user interface or the automation device for temporary access, no access is allowed. This has the advantage that a timer can not have an unlimited period of time, but is limited to a finite amount of time.

In a further preferred embodiment of the method, this has the stopping of a started timer. For example, a timer may be stopped when the user logs out of the user interface, for example because the user wishes to view the changed states of the automation device before changing further parameters or states of the automation device. Subsequently, he can use the received token again to gain access to the automation device. In this case, but not a new timer is started, but the already started and only stopped timer is continued. For this purpose, the user interface or the automation device can mark a started timer in such a way that it is associated with an entered token, so that when the same token is entered again, not a new timer is started, but the timer which has already been started and only stopped is continued. However, the stopping of the timer may also be caused, for example, by the user interface or the automation device recognizing that the first connection has been interrupted. The timer can be continued in this case if the connection is made again. This has the The advantage that errors in the connection between the user interface and the automation device are not at the expense of the access authorization time. The time period for which a timer is stopped can also be limited in time, so that the token expires after this period has expired and a reuse of the same token is excluded. In this case, the user must direct a renewed access request to the second terminal to obtain a new token. This maximum duration of stopping a timer may either be specific to the user interface and / or automation device, or this time will result from the token itself, which may for example only be valid for a certain time. It may also be that the token specifies how long a maximum stop time may be, for example, this can be set depending on the access request. For example, a user with a very low privilege level can be assigned a token with a shorter validity and, accordingly, a shorter timeout than a user with a higher privilege level.

In a further embodiment of the method according to the invention, this further comprises storing the token in the first terminal and / or the automation device. The token entered at the first terminal may be stored in memory by the first terminal and / or the automation device. This has the advantage that all tokens used to obtain temporary access are known to the first terminal or automation device so that a token can only be used once and this token is not used a second time to gain unauthorized access the automation device can be used. Accordingly, the stored tokens can already be compared with the entered new token when entering a new token, so that it is prevented that a token is used several times. If it should be determined that a token is to be used again, the first terminal may indicate a warning that the token is invalid because it has already been used. To keep track of an unauthorized attempt to access the automation device, a preformulated message can also be sent to the administrator of the automation device. This has the advantage that the administrator of the automation device is informed that an unauthorized attempt to access the automation device has taken place. The tokens stored in the memory can also be used to identify whether in connection with an entered token still exists a timer that has not yet expired, but only stopped and on re-entering a memory already in the token, the corresponding timers are continued.

In a further embodiment of the inventive method, the access request contains at least one of an authorization identifier, a user identifier, an authorization level, information identifying the automation device, or customer ID. The authorization identifier in the access request can be an authorization identifier which indicates that the access request is being made by an authorized person. For example, this identifier may be one that has been issued to all users of the automation device so that they can identify themselves as authorized users with respect to the second terminal. The access request may also or additionally include a specific for the user of the automation device user ID. For example, this userid may be the one that the user uses to log in to the user interface. Additionally or additionally, the access request may also include the current authorization level of a user. Also, the access request may include information identifying the automation device, which may be, for example, the ID of the automation device, or a MAC address of the automation device. The access request may also already include an error code that is specific to the error that has occurred on the automation device. In this way, the second terminal can be enabled to generate the token such that it contains information which allows temporary access to the automation device only in that only specific parameters and states, namely only those relevant to the particular error, are relevant can be changed without other parameters or states can be changed. Accordingly, this allows the generation of an error-specific token that allows access only to enable the user to correct the error, but does not give the user more extensive access rights. If the user needs further access to the automation system, then a second access request must be made, which allows extended access. However, it is also possible for several error codes to already be transmitted in an access request and for a corresponding error-specific token to be generated in accordance with this plurality of error codes. The access request may also include a combination of the aforementioned information. With at least one of the aforementioned information, it is also possible for the second terminal to validate the access request, ie to check its validity. This has the advantage that not every access request leads to the generation of a token, in particular if the access request is made by unauthorized third parties.

In a further preferred embodiment of the method according to the invention, the information contained in the token is one of a creation date, an authorization level to be set, a time period for the access, a time period for the authorization level, a creator identifier, information identifying the automation device, or customer ID , For example, the token can have information about its creation date, this information can be stored, for example, in the format year / month / day. The creation date may be important in that the user interface or the automation device only considers tokens that were generated within a defined time interval, for example within one day before entry. Furthermore, the token may have a period of time for which the token is valid. This period of time may be indicated, for example, in minutes or other time-immanent constants. Furthermore, the token may include information about the level of authorization that the user can obtain with the token. In this case, this information can be absolute information, that is, the authorization level to which the user's authorization level is set when the token is entered. However, the token can also contain a relative authorization level, ie information about how high the user's authorization level is set in relation to the user's authorization level that already exists. Furthermore, the token may contain information in the form of a creator identifier, this creator identifier indicates that the second terminal from which the token was generated is valid and is authorized to generate tokens for the automation device. Furthermore, the token may contain information identifying the automation device, that is, for example, a MAC address of the automation device or the ID of the automation device. This information may for example already have been transmitted by the access request to the second terminal, and an occurrence of this information in the token may be used to verify the token. Furthermore, the token may have a checksum to verify that all information has been transmitted correctly. The token may include any combination of the aforementioned information. The token may also contain other information necessary to validate the token or to gain access to the automation device.

In a further preferred embodiment of the method according to the invention, the token is at least one of a barcode, a QR code, a string, a single- or multi-color graphic code, or a numerical value. The token can also be any combination of the aforementioned. A bar code, a QR code, a graphic code or any code from which the information contained in the token does not directly show the advantage that the user can not modify it so that individual information can be changed. For example, if the authorization level were directly apparent from the token, a user could set it to a higher level than provided by the second terminal. Otherwise, since such a token may otherwise satisfy the requirements of the validity of the token, the first terminal would set the permission level corresponding to the changed information. This can be prevented if the information contained in the token is not directly recognizable. A QR code, bar code, or graphic code further has the advantage that it can be easily communicated to the user, for example by a short message and the user can enter this via a reader on the first terminal. This is not only easy for the user, but also prevents unnecessary errors in the input, thereby saving time and eliminating the malfunction of the automation device more quickly. However, it is also possible that the token is a string in which the information is encoded by means of an algorithm and the information on the first terminal is obtained by decoding the string with a corresponding algorithm.

The above-mentioned object for obtaining temporary access to an automation device is achieved on a first terminal, which is connected via a first connection to the automation device, by entering a token at the first terminal, the token being generated by a second terminal which is separate from the automation device, and that the input token contains at least information for the temporary access to the automation device.

Furthermore, the object is achieved by a first terminal, which is connected via a first connection to an automation device and which has a means for inputting a token, wherein the token was generated by a second terminal, which is separate from the automation device, and the entered token contains at least information for the temporary access to the automation device.

Furthermore, the above object is on the side of a second terminal, which is separately from an automation device connected to a first terminal via a first connection, in that an access request is obtained via a second connection that is separate from the first connection and by generating a token based on the access request, wherein the token is at least one Containing information that allows temporary access to the automation device and by transmitting the generated token from the second terminal to a user of the automation device via the second connection or a third connection separately from the first and second connection.

The object is also achieved by a second terminal, the second terminal being separate from an automation device connected to a first terminal via a first connection, the second terminal having means for obtaining an access request, the access request being transmitted via a second connection separate from the first connection and having means for generating a token based on the access request, the token including at least information permitting temporary access to the automation device and means for communicating the generated token to a user of the automation device via the second Connection or a third connection separately from the first and second connection.

The object is also solved by a computer-readable medium embodying instructions that cause a computer to perform at least one of the above-mentioned methods.

4. Brief description of the drawings

Embodiments of the invention are explained below with reference to the drawings. Showing:

1 a schematic representation of a temporary access situation according to an embodiment of the invention;

2 a token according to an embodiment of the invention;

3 a flowchart of steps of a method according to the invention of an embodiment;

4 a flowchart of steps of a method according to the invention of an embodiment on the part of a first terminal; and

5 a flowchart of steps of a method according to the invention of an embodiment on the part of a second terminal.

5. Description of preferred embodiments

1 shows a schematic representation of a temporary access situation according to an embodiment of the invention. Here is the automation device 11 with a first terminal 12 connected. In general, the first terminal 12 a computer, for example a PC with an operating system and a program executed therefrom for controlling and monitoring the automation device 11 , Control and monitoring in this case means that with the program the parameters and states of the automation device 11 can be viewed and changed. So for example the measured values of sensors 18 the automation device 11 can be viewed or the states of actuators 18 ' and 18 '' can be viewed and changed if the user 14 of the first terminal 12 has the appropriate permission level. The individual components - for example, the sensors 18 and actuators 18 ' . 18 '' - the automation device 11 can communicate with each other with a bus system 17 be connected. By means of this bus system 17 can also be the connection between the first terminal 12 and the automation system 11 be created. By means of the bus system 17 may be the first terminal 12 then accordingly with the individual components 18 . 18 ' . 18 '' the automation device 11 communicate, so that the first terminal 12 Information about the parameters and states of the individual components of the automation device 11 can obtain. The first terminal 12 but can also be part of the automation device 11 be. The first terminal 12 but also via a network connection with the automation device 11 So with their components 18 . 18 ' . 18 '' keep in touch. The first terminal 12 can also by means of an interface (not shown here) with the components 18 . 18 ' . 18 '' keep in touch. The person skilled in the art has a multiplicity of connections between the automation device 11 and the first terminal 12 known that an information exchange between the first terminal 12 and the automation device 11 , or the first terminal 12 and the components 18 . 18 ' . 18 '' the automation device 11 allow. All possibilities that allow such an exchange of information should be covered by the fact that the automation device 11 and the first terminal 12 connected to each other. Accordingly, this connection can be realized in terms of hardware or software technology. The components 18 . 18 ' and 18 '' can also be input / output terminals with corresponding sensors and actuators are connected, as usual in known field systems. Between the terminal 12 and such input / output terminals may be arranged a controller (not shown here), which can communicate with the input / output terminals by means of a first bus and by means of a second bus with the terminal 12 can communicate. The first terminal 12 but can also be the controller itself or the terminal 12 may include this.

Furthermore, in 1 the user 14 shown at the site of the automation device 11 located and the first terminal 12 Access to the automation device 11 Has. This access can be provided with different authorization levels. A user 14 For example, it can only have read access, ie via the first terminal 12 only the current parameters and states of the automation device 11 view, whereas another user 14 a read and write access to the first terminal 12 and thus on the automation device 11 may have. This user 14 can then according to the parameters and states of the automation device 11 change.

Occurs at the automation facility 11 malfunction and has the on-site user 14 not the appropriate authorization level, parameters or states of the automation device 11 to change, to fix the malfunction, so the user can 14 but an access request 15 to a second terminal 13 send. This access request 15 can the user 14 as a user of the automation device 11 and can, for example, include its authorization level. At the second terminal 13 will then be based on the access request 15 a token 16 generates at least one information that the user 14 temporary, ie temporary, access to the automation device 11 allowed when the token is input to the first terminal 12 , In this case, this access is characterized in that the authorization level of the user 14 is increased, for example, that he has enough access rights to the malfunction of the automation device 11 to fix. For this, the token 16 For example, include information that the user's permission level 14 when entering the token 16 on the first terminal 12 up sets. As a result, the user 14 who previously might only have been authorized to view parameters and states, these can now change, leaving the user 14 that on the automation device 11 error has occurred. The token can be 16 have a time limited validity, so with the expiration of the validity of the token 16 , the user 14 his increased access rights to the automation device 11 loses. For example, it may lead to a complete termination of access by the user 14 come or after expiration of the validity of the token 16 Therefore, the access permission can be the permission level of the user 14 be set back to the original level. In the example shown here, for example, this results in the user 14 the parameters and states of the automation device 11 can only see, but this can not change.

2 schematically shows a data structure of an exemplary token 20 according to an embodiment of the invention. The token 20 In the embodiment shown here comprises data or information fields 21 to 26 , The token contains 20 a field 21 including a creation date in the format YYMMDD, a field 22 including a 12-bit duration corresponding to a numeric value from 0 to 4095, a field 23 including a 4-bit permission level corresponding to a numeric value from 0 to 15, a field 24 including a 16 bit format identifier corresponding to a numeric value from 0 to 65535, a field 25 including one the automation device 11 identifying information, for example, a 24-bit system ID corresponding to a numeric value from 0 to 16777215, and a field 26 including a checksum in the 8-bit format corresponding to a numerical value from 0 to 255. The corresponding information in the fields 21 to 26 can be individually coded, so that from the numerical value or the field state is not directly apparent which setting represents a field. Alternatively or additionally, the token 20 but also be encoded and / or encoded as a whole, to an unauthorized change of the token 20 submissions. A variety of codes and encryptions are known to those skilled in the art, which can be applied. The token 20 The information contained herein may also be presented in the form of a single numeric value or value string, or converted into a barcode, a QR code, a single- or multi-color graphic code, or any other form requiring a simple input of the token 20 allows. It is also conceivable that the information of the token 20 be stored on a dongle or other storage medium, so that with the help of the dongle / storage medium, the information can be safely and easily passed. One skilled in the art will recognize that also a different data structure than the shown data structure for the token 20 can be used.

3 shows a flowchart with the steps of a method according to the invention for obtaining a temporary access authorization or an increase in an already existing access authorization for accessing an automation device. The method can be the first step 31 that is, transmitting an access request to a second terminal, wherein the second terminal is separate from the automation device. Accordingly, the second terminal is not in direct communication with the automation device. The access request is sent by a user of the automation device to the second terminal via a connection which is separate from a connection between the automation device and a user interface provided for controlling the automation device, ie a first terminal. In step 32 the access request is received from the second terminal. The access request can thereby identify the user who sent the access request as well as the automation device for which the access request was sent. The access request may also contain other information necessary for the second terminal to process the access request and in step 33 generate a token based on the access request. This token contains at least information that allows the user who has sent the access request to the second terminal at least temporary access to the automation device or increases the access rights of the user for a limited time. In step 34 the generated token is transmitted back to the user from whom the access request originated. This transmission can either take place via the same connection that was used to transmit the access request, or a different connection can be used for this purpose. Using a connection that is different from the connection used to submit the access request can add security, since in this case it becomes more difficult for a malicious third party to intercept the communication. After submitting the access request in step 34 can the token in step 35 from the user who made the access request. This reception either takes place via the connection via which the user has also made the access request or via a different connection. In step 36 Then, the token at the first terminal, so the user interface, then entered to access the automation device can. Entering the token in step 36 can be done via a keyboard or other peripheral device of the user interface. For example, if the token is a QR code, it can be read by a user interface reader. However, other entries of the token are also possible, whereby the input option only has to correspond to the form of the token. Optionally, it may be in step 37 be necessary that the entered token must still be processed, either from the user interface or the automation device. For example, it may be that the token is encrypted and must first be decrypted so that access to the automation device can be granted via the information contained in the token. Subsequently, in step 38 be accessed via the user interface according to the information contained in the token on the automation device. For example, the token may contain information about the length of time that an access to the automation device is granted.

4 shows a flowchart with the steps of a method according to the invention for obtaining a temporary access authorization or an increase of an already existing access authorization for accessing an automation device on the part of a first terminal, ie a user interface. The procedure begins with step 41 with the input of a token at the user interface. The entered token has been previously generated by a second terminal that is separate from the automation device and the user interface. For example, the second terminal may be a service center or a computer located in a service center. Depending on which form the token has, it can be entered in different ways on the user interface. If the token is a QR code, it can be held in front of a corresponding reader of the user interface. The token can also be a file which is stored by the user on a storage medium and thus entered at the first terminal. The token thus entered, which contains at least information that allows the user access to the automation device or increases its authorization level for access to the automation device, can optionally be used in step 42 be processed either by the user interface or the automation device. With the processing of the token it is possible to extract the information from the token. For example, the information in the token may be encrypted and must first be decrypted. The processing of the token can be done on the automation device, so that the user interface does not have to be able to process the token, but to forward it only to the automation device and then to obtain the processed information from the automation device. This has the advantage that only the automation device must be aware of how the token is to be processed. On the one hand, this increases security and, on the other hand, it also has the advantage that the user interface can be exchanged, but the functionality of processing a token persists because it is stored in the automation device. With the in step 42 processed token and the information contained therein is a user in step 43 then allowed to access the automation device.

5 shows a flowchart with the steps of a method according to the invention for obtaining a temporary access authorization or an increase of an already existing access authorization for accessing an automation device on the part of a second terminal. The procedure starts with the step 51 in which the second terminal receives an access request from a user. This access request may contain at least information about the user and / or information about the automation device. This information can be used to verify the access request, ie to verify that the access request has been made by an authorized user. Furthermore, the at least one piece of information may be used in step 52 to create a token. For this purpose, the second terminal can first verify the access request and then generate a token for the user. For example, this token may be specific to the requesting user, specific to the access automation device, the problem encountered, or a combination thereof. The token contains at least one piece of information that at least temporarily allows the user access to the automation device or increases the authorization level and thus the access rights of the requesting user. Subsequently, the generated token is in step 53 transmitted to the user. For this transmission, either the connection through which the access request was received or a different connection is used.

LIST OF REFERENCE NUMBERS

11

automation equipment

12

first terminal

13

second terminal

14

user

15

access request

16

token

17

bus system

18

Component of the automation device (eg sensor)

18 '

Component of the automation device (eg actuator)

18 ''

Component of the automation device (eg actuator)

20

token

21

Creation Date

22

Time in minutes

23

permission level

24

creation identifier

25

System ID

26

checksum

31-38

steps

41-43

steps

51-53

steps

Claims (15)

A method for accessing an automation device ( 11 ) from a first terminal ( 12 ), the first terminal ( 12 ) via a first connection to the automation device ( 11 ), the method comprising: obtaining ( 32 ) an access request ( 15 ) on a second terminal ( 13 ) separately from the automation device ( 11 ), whereby the access request ( 15 ) is transmitted via a second connection which is separate from the first connection; Produce ( 33 ) of a token ( 16 . 20 ) on the second terminal ( 13 ) based on the access request ( 15 ); To transfer ( 34 ) of the generated token ( 16 . 20 ) from the second terminal ( 13 ) to a user ( 14 ) of the automation device ( 11 ) via the second connection or a third connection separate from the first and second connections; Enter ( 36 ) of the transmitted token ( 16 . 20 ) on the first terminal ( 12 ); and accessing ( 38 ) to the automation device ( 11 ) based on at least one piece of information contained in the input token ( 16 . 20 ), wherein the at least one information temporary access to the automation device ( 11 ) allowed. The method of claim 1, further comprising, processing ( 37 ) of the entered token ( 16 . 20 ) for obtaining the at least one information. The method of any one of the preceding claims, further comprising starting a timer after entering the token ( 16 . 20 ), with the timer's duration based on the token. The method of claim 3, further comprising raising a privilege level of the user ( 14 ) with starting the timer and lowering the user's permission level ( 14 ) after the timer expires. The method according to one of claims 3 or 4, further comprising terminating access to the automation device ( 11 ) after the timer expires. The method of one of the preceding claims, further comprising storing the Tokens ( 16 . 20 ) in the first terminal ( 12 ) and / or the automation device ( 11 ). The method of any one of the preceding claims, wherein the access request ( 15 ) contains at least one authorization identifier, a user identifier, an authorization level, an information identifying the automation device, an error code, or customer ID. The method according to one of the preceding claims, wherein the at least one in the token ( 16 . 20 ) information includes at least one of a creation date, a permission level to be set, a time period for the access, a time period for the permission level, an information identifying the automation device, or customer ID. The method according to one of the preceding claims, wherein the token ( 16 . 20 ) at least one of at least one bar code, a QR code, a string, a single or multi-color graphic code, or contains customer ID. A method for accessing an automation device ( 11 ) from a first terminal ( 12 ), the first terminal ( 12 ) via a first connection to the automation device ( 11 ), the method comprising: inputting ( 41 ) of a token ( 16 . 20 ) on the first terminal ( 12 ), where the token ( 16 . 20 ) was generated by a second terminal ( 13 ) separately from the automation device ( 11 ) and where the token ( 16 . 20 ) at least one information for temporary access to the automation device ( 11 ) contains; and accessing ( 43 ) to the automation device ( 11 ) based on the at least one information. The method of claim 10, further comprising, processing ( 42 ) of the entered token ( 16 . 20 ) for obtaining the at least one information. A first terminal ( 12 ) for accessing an automation device ( 11 ), the first terminal ( 12 ) via a first connection to the automation device ( 11 ), the first terminal ( 12 ) comprising: means for entering a token ( 16 . 20 ), where the token ( 16 . 20 ) was generated by a second terminal ( 13 ) separately from the automation device ( 11 ) and where the token ( 16 . 20 ) at least one information for temporary access to the automation device ( 11 ) contains; and means for accessing the automation device ( 11 ) based on the at least one information. A method for accessing an automation device ( 11 ) from a first terminal ( 12 ), the first terminal ( 12 ) via a first connection to the automation device ( 11 ), the method comprising: obtaining ( 51 ) an access request ( 15 ) on a second terminal ( 13 ) separately from the automation device ( 11 ), whereby the access request ( 15 ) is transmitted via a second connection which is separate from the first connection; Produce ( 52 ) of a token ( 16 . 20 ) on the second terminal ( 13 ) based on the access request ( 15 ), where the token ( 16 . 20 ) contains at least one piece of information, the temporary access to the automation device ( 11 ) allowed; and submit ( 53 ) of the generated token ( 16 . 20 ) from the second terminal ( 13 ) to a user ( 14 ) of the automation device ( 11 ) via the second connection or a third connection separately from the first and second connections. A second terminal ( 13 ), the second terminal ( 13 ) is separate from one with a first terminal ( 12 ) via a first connection connected automation device ( 11 ), the second terminal ( 13 ) comprising: means for obtaining an access request ( 15 ), whereby the access request ( 15 ) is transmitted via a second connection which is separate from the first connection; Means for generating a token ( 16 . 20 ) based on the access request ( 15 ), where the token ( 16 . 20 ) contains at least one piece of information, the temporary access to the automation device ( 11 ) allowed; and means for transmitting the generated token ( 16 . 20 ) to a user ( 14 ) of the automation device ( 11 ) via the second connection or a third connection separately from the first and second connections. A computer readable medium, the computer readable medium, embodies instructions that, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 9, 11 to 12, and / or 13.

Images