SPARE ROBOT CONTROLLER

Abstract

A spare robot controller for replacing any one of a plurality of initial robot controllers configured to control operation of respective industrial robots includes a key storage storing a plurality of shared keys and a secure storage. The spare robot controller is configured to decrypt, using one of the shared keys, an encrypted backup copy of the initial robot controller to be replaced, and to store resulting data in the secure storage. In embodiments, the is configured to extract data from the secure storage during operation and to encrypt the extracted data, using a selected one of the shared keys, for storage as a backup copy in a backup storage available to all of the initial robot controllers.

Claims

1. A method for providing a spare robot control, which is to replace an initial robot controller configured to control operation of an industrial robot, the method comprising: supplying at least a shared key (K.sub.10) to the spare robot controller; enabling loading of a backup copy ({C}.sub.K10) encrypted with the shared key into the spare robot controller; and causing the spare robot controller to decrypt the loaded backup copy using the shared key and store resulting data (C) in a secure storage of the spare robot controller.

2. The method of claim 1, wherein the shared key has been shared with the initial robot controller.

3. The method of claim 1, wherein the encrypted backup copy is loaded from a backup storage.

4. The method of claim 3, wherein the backup storage is available to one or more further robot controllers.

5. The method of claim 4, wherein the backup storage comprises at least one backup copy encrypted using a further shared key (K.sub.20, K.sub.30).

6. The method of claim 1, wherein at least one further shared key (K.sub.20, K.sub.30) is supplied to the spare robot controller prior to the loading of the encrypted backup copy.

7. The method of claim 6, wherein the shared keys are supplied to the spare robot controller in a pre-programming phase, which is separate from an individualization phase including the loading of the encrypted backup copy.

8. The method of claim 7, wherein the pre-programming phase is performed by an owner of the shared key (K.sub.10).

9. The method of claim 8, wherein said owner of the shared key (K.sub.10) is an owner of any further shared keys (K.sub.20, K.sub.30) as well.

10. The method of claim 8, wherein said owner is a system administrator.

11. The method of claim 1, wherein the secure storage of the spare robot controller is an isolated trust domain.

12. The method of claim 1, wherein the backup copy includes one or more of: a system configuration of the initial robot controller; project-related data; generic software; data relating to past operation of the robot; user settings.

13. A configurable spare robot controller adapted to replace any one of a plurality of initial robot controllers configured to control operation of respective industrial robots, the spare robot controller comprising: a key storage storing a plurality of shared keys (K.sub.10, K.sub.20, K.sub.30; and a secure storage, wherein the spare robot controller is configured to decrypt, using one of the shared keys, an encrypted backup copy ({C}.sub.K10, {C}.sub.K20, {C}.sub.K30) of the initial robot controller to be replaced, and to store resulting data (C) in the secure storage.

14. The spare robot controller of claim 13, further configured to extract data from the secure storage during operation and to encrypt the extracted data, using a selected one of the shared keys, for storage as a backup copy in a backup storage available to all of the initial robot controllers.

15. The spare robot controller of claim 13, further configured to decrypt the encrypted backup copy of the initial robot controller to be replaced by sequentially trying the shared keys in the key storage.

16. The method of claim 2, wherein the encrypted backup copy is loaded from a backup storage.

17. The method of claim 2, wherein at least one further shared key (K.sub.20, K.sub.30) is supplied to the spare robot controller prior to the loading of the encrypted backup copy.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, on which:

[0013] FIG. 1 illustrates an industrial robot system in which an embodiment of the invention is implemented; and

[0014] FIG. 2 is a flowchart of a two-phase method for providing a spare robot controller according to an embodiment of the invention.

DETAILED DESCRIPTION

[0015] The aspects of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, on which certain embodiments of the invention are shown. These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, the embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0016] FIG. 1 is a schematic illustration of an industrial robot system comprising a plurality of robot controllers 10, 20, 30 controlling operation of respective industrial robots 19, 29, 39 and sharing a common backup storage 70. As illustrated by way of example for the leftmost robot controller 10, each robot controller 10, 20, 30 comprises at least a secure storage 11 and a key storage 12.

[0017] The secure storage 11 may be sized and adapted to hold one or more of: a system configuration of the robot controller 10, project-related data, generic software, data relating to past operation of the robot 19 and user settings. Clearly at least some of the enabled data may be changed or extended as a result of operating the robot controller 10 and/or robot 19, which makes regular backup copying advisable.

[0018] The secure storage 11 may be secure in the sense that all stored data are encrypted, so that any third parties gaining access to the stored bit pattern are unable to read the encoded information without access to corresponding decryption. The secure storage 11 is preferably a non-volatile memory. Such non-volatile memory may be supplemented by a dedicated runtime memory, to which data from the secure storage 11 may be moved for execution; the runtime memory preferably has protective modalities that prevent illicit access to the data to the same security standard as applies for the secure storage 11. The secure storage 11, together with any runtime memory in the robot controller 10, constitutes an isolated trust domain.

[0019] The key storage 12 stores at least a shared key K.sub.10, which the robot controller 10 uses to produce encrypted backup copies {C}.sub.K10 to be deposited in the backup storage 70. The backup copy C may be a complete image of the secure storage 11 or a subset thereof that is sufficient to prepare a spare robot controller replacing the robot controller 10. An encryption key or other secret may be used to protect the secure storage 11, which may or may not coincide with the shared key K.sub.10. It is preferable from the point of view of cybersecurity if the shared key K.sub.10 is distinct from the key or secret that protects the secure storage 11.

[0020] The key storage 12 preferably has a high level of intrusion protection. Further preferably, it allows data encryption without outputting or otherwise disclosing the shared key K.sub.10. In particular, the key storage 12 may include logic preventing any onward sharing (or passing-on) of the keys deposited therein; the sharing of keys to robot controllers may be a faculty exclusive to an appointed key owner 90. The key owner 90 may be a unique party entrusted with the key management responsibilities in the system, including the authority to create, revoke or share a particular key. The key owner 90 may be, or have been appointed by, a system administrator. It is not necessary for the robot controller 10 to be able to decrypt an encrypted backup copy {C}.sub.K10 that it has deposited in the backup storage 70. The decryption ability may be included as an optional feature, e.g., by the use of program code similar to the program code that implements decryption of the loaded backup copy in the spare robot controller 80 to be described below.

[0021] The further robot controllers 20,30 hold respective shared keys K20, K30, which may or may not differ from the key K.sub.10 of the leftmost robot controller 10. If a robot controller 10 uses a key unknown to the neighbor robot controllers 20, 30, it is certain that its encrypted backup copy in the backup storage 70 is unreadable by these. With the ongoing transition to commoditized network storage solutions (“cloud”), where it is not uncommon for one backup storage server to support robot controllers that belong to different companies or institutions, the use of distinct keys may help maintain a high standard of data security. In the interest of reducing costly key acquisition and key administration, however, all robot controllers 10, 20, 30 within one factory or one production line may use the same shared key or a minimal number of shared keys.

[0022] The solid lines in FIG. 1 represent wired or wireless data network connections. In a simplified embodiment, where the backup storage 70 is local and infrequent backups suffice, the backup data from each robot controller 10, 20, 30 may be transferred to the backup storage 70 after being temporarily stored in a portable memory. This eliminates the need to implement strong network safety and may be implemented without significant operator intervention.

[0023] To enable timely replacement if one of the robot controllers 10, 20, 30 in the system becomes defective, a spare robot controller 80 is prepared. The spare robot controller 80 may be structurally similar to any one of the robot controllers 10, 20,30 shown in the upper part of FIG. 1, i.e., including a secure storage 81 and key storage 82 with same or corresponding characteristics. In particular, the secure storage 81 is included in an isolated trust domain inside the spare robot controller 80. The secure storage 81 is suitable to receive data resulting from decryption of an encrypted backup copy of a robot controller (initial robot controller) to be replaced; for this decryption, one of the shared keys in the key storage 82 is used. Furthermore, the spare robot controller 80 is configured to extract, during operation, data from the secure storage 81 and to encrypt the extracted data, using a selected one of the shared keys, and to store the result of the encryption as a backup copy in the backup storage 70. This latter corresponds to the normal functioning of one of the robot controllers 10, 20, 30.

[0024] Accordingly, the spare robot controller 80 according to this embodiment has been prepared at least by undergoing a pre-programming phase 291 (see FIG. 2). The pre-programming phase 291 includes a first step 210 in which a plurality of shared keys K.sub.10, K.sub.20, K.sub.30 have been deposited in the key storage 82, as suggested by a broken-line arrow in FIG. 1. This enables the spare robot controller 80 to replace any of the robot controllers 10, 20, 30 in the system. The pre-programming phase 291 may have been carried out by a key owner 90 or their delegate, or by a computer-implemented or computer-supported system functionality with this role.

[0025] Once it is known which one of the robot controllers 10, 20, 30 the spare robot controller 80 shall replace, a subsequent individualization phase 292 (see FIG. 2) can be initiated. Protection is sought, in particular, for the spare robot controller 80 having undergone the pre-programming phase 291 but not yet the individualization phase 292.

[0026] The individualization phase 292 can be carried out by a party authorized to only access the backup copies in encrypted form, such as by personnel with authority to grant the spare robot controller 80 read access to the backup storage 70 but without any of the shared keys K.sub.10, K.sub.20, K.sub.30. The individualization phase 292 includes a step 212 of enabling loading of a backup copy {C}.sub.K10, which has been encrypted with one of the shared keys, into the spare robot controller 80. This is illustrated by a vertical broken-line arrow. The loading may be performed by authorizing the spare robot controller 80 to access the backup storage 70 and instructing it to retrieve the backup copy; alternatively, the party carrying out the individualization phase 292 retrieves the backup copy and supplies it to the spare robot controller 80; as a still further option, the backup storage 70 is instructed to supply the backup copy to the spare robot controller 80 in course of being individualized.

[0027] The individualization phase 292 further includes a step 214 of causing the spare robot controller to decrypt the loaded backup copy using one of the shared keys and store the resulting data C in its secure storage 81. The decryption process is illustrated by a circle inside the spare robot controller 81 at which two broken-line arrows converge and one leaves. Specifically, the spare robot controller 80 may be configured to receive an instruction as to which one of the shared keys to use. Alternatively, the spare robot controller 80 is configured to try to decrypt the loaded encrypted backup copy with the shared keys sequentially until the decryption is successful. The spare robot controller 80 may verify that decryption was successful by computing a checksum of the resulting data and comparing this with a pre-agreed or pre-specified value; as a simpler alternative, a cyclic redundancy check (CRC) may be used.

[0028] After step 214, the secure storage 81 normally contains a replica of the latest backup copy deposited by the defective robot controller, so that the individualized spare robot controller 80 is fit to substitute the latter in the system. The deployment of the individualized spare robot controller 80 may include connecting it to the backup storage 70 and to the one of the robots 19, 29, 39 that is to be controlled; necessary settings and other input that is not derivable from the restored backup copy may be entered as well. As noted above, the data C is protected from unauthorized access in the secure storage 81.

[0029] FIG. 2 is a flowchart of a method 200 for providing a spare robot controller 80. The method comprises the steps 210, 212, 214, which have been described above. The method 200 may be executed by a human operator, such as a system administrator. Alternatively, the method 200 can be implemented by a programmable computer, wherein the steps corresponds to computer-readable instructions forming a computer program. Optionally, the computer program is stored on a transitory or non-transitory, volatile or non-volatile data carrier suitable for distribution, storage or both.

[0030] The aspects of the present disclosure have mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.