SECURITY DEVICE FOR BUILDING-RELATED PASSENGER CONVEYOR SYSTEM

Abstract

A security device for a building-related passenger transport system includes a microcontroller having a memory, a processor and a communication interface. A security module is stored in the memory and, when it is executed on the processor, receives security-relevant signals from components of the passenger conveyor system, evaluates the signals with regard to a security problem and transmits a warning signal to a controller of the passenger conveyor system in the event of a security problem. An update module is stored in the memory and, when it is executed on the processor, receives a software package via the communication interface and updates at least parts of the security module with the software package. The microcontroller is configured such that the security module is able to be amended only by the update module.

Claims

1-14. (canceled)

15. A security device for a building-related passenger transport system, the security device comprising: a microcontroller having a memory, a processor and a communication interface; a security module stored in the memory and, when executed on the processor, the security module receives security-relevant signals from components of the passenger transport system, evaluates the security-related signals with regard to a predetermined security problem, and transmits a warning signal to a controller of the passenger transport system when the security-related signals indicate the security problem; an update module stored in the memory and, when executed on the processor, the update module receives a software package via the communication interface and updates at least parts of the security module with the software package; wherein the microcontroller is configured such that the security module is only able to be amended by the update module; wherein the processor has a first processor core on which the security module is executed; wherein the processor has a second processor core on which the update module is executed; and wherein the microcontroller restricts access of the second processor core to regions of the memory in which the security module is stored.

16. The security device according to claim 15 wherein the microcontroller includes a hypervisor that restricts access of the executed update module and the executed security module to the memory and restricts access of the update module to the regions of the memory in which the security module is stored.

17. The security device according to claim 16 wherein the hypervisor is a hardware component of the microcontroller.

18. The security device according to claim 16 wherein the hypervisor is a software module stored in the memory.

19. The security device according to claim 16 wherein the hypervisor forwards the security-relevant signals from components of the passenger transport system to the security module and forwards the software package to the update module.

20. The security device according to claim 15 wherein the update module receives the security-relevant signals via the communication interface and forwards the security-relevant signals to the security module.

21. The security device according to claim 15 including a plurality of the security module stored in the memory and wherein the update module updates each of the security modules.

22. The security device according to claim 15 wherein the memory includes a non-volatile memory and a volatile memory.

23. The security device according to claim 22 wherein the update module is stored in the non-volatile memory in encrypted form, and including a boot loader module stored in the non-volatile memory that, when executed on the processor, decrypts the update module and loads the decrypted update module into the volatile memory.

24. The security device according to claim 15 including at least one of a private key stored in a protected non-volatile memory of the microcontroller and a public key of a provider of the software package stored in the protected non-volatile memory of the microcontroller.

25. The security device according to claim 24 wherein the microcontroller uses the private key to decrypt the update module and uses the public key to authenticate a provider of the software package.

26. A method for updating software of the security device according to claim 15, the method comprising the steps of: authenticating a provider of the software package via the communication interface by the update module; receiving the software package via the communication interface by the update module; and updating at least a part of the security module with the software package by the update module.

27. The method according to claim 26 including a step of decrypting the software package by the update module.

28. The method according to claim 27 wherein the software package is at least partially encrypted using a symmetric encryption method.

29. The method according to claim 26 including the update module making regular requests for a software package for updating the security module to the provider.

Description

DESCRIPTION OF THE DRAWINGS

[0033] FIG. 1 schematically shows a building-related passenger conveyor system in the form of an elevator system having a security device according to an embodiment of the invention.

[0034] FIG. 2 shows a security device according to an embodiment of the invention.

[0035] FIG. 3 shows a security device according to a further embodiment of the invention.

[0036] FIG. 4 shows a microcontroller for a security device according to a further embodiment of the invention.

[0037] FIG. 5 shows a microcontroller for a security device according to a further embodiment of the invention.

[0038] FIG. 6 shows a flow chart for a method for updating software of a security device according to an embodiment of the invention.

[0039] The drawings are merely schematic and not to scale. Like reference signs refer to like or equivalent features in the various drawings.

DETAILED DESCRIPTION

[0040] FIG. 1 shows a building-related passenger conveyor system 10 in the form of an elevator system 10. An elevator system is described below by way of example. However, it should be understood that other passenger conveyor systems 10, such as escalators or moving walkways, can also include a security device, as described in the following.

[0041] The elevator system 10 comprises an elevator shaft 12, in which an elevator car 14 and a counterweight 16 can be moved. For this purpose, the elevator car 14 and the counterweight 16 are suspended on a cable-like or belt-like suspension means 18, which can be moved by a drive machine 20. The operation of the elevator system 10 and in particular the drive machine 20 can be controlled with the aid of a central control unit 22.

[0042] In order to be able to ensure correct functioning and, in particular, safety of the elevator system 10, a plurality of security sensors 26 are accommodated in a building 24 that accommodates the elevator system 10. In this case, the security sensors 26 are arranged distributed over the building 24. The security sensors 26 can, for example, comprise a door switch 28 or be connected to a door switch 28, which can monitor a closure state of doors 30 of the elevator system 10, in particular of doors to building floors. Furthermore, a ladder 32 can also be mounted close to a floor or a pit of the elevator shaft 12, for example, the correct stored positioning of which ladder on a side wall of the elevator shaft 12 is monitored, for example, by means of a switch 33 which is connected to a security sensor 26.

[0043] The security sensors 26 can, for example, be connected to a security device 36 via a serial bus 34, which system, based on the signals from the security sensors 26, generates a warning signal when the signals indicate that there is a security problem. When the controller 22 receives a warning signal, it can, for example, stop the operation of the elevator system 10 or prevent the system from starting operation.

[0044] FIG. 2 shows a functional structure of a security device 36 in which a plurality of software modules, such as an update module 38 and one or more security modules 40, 40′, 40″, are executed by a microcontroller 42. The security device 36 can exchange data by means of a data communication unit 44, which data is provided, for example, via the internet 46 by a provider 48, for example an internet server. In particular, the provider can provide a software package 50 for one or more of the security modules 40, 40′, 40″, which can be downloaded and possibly decrypted by the update module 38 by means of the data communication unit 44. The update module 38 can then use the data from the software package 50 to update one or more of the security modules 40, 40′, 40″.

[0045] The data communication unit 44 can be, for example, a router or a mobile radio unit which is connected to the security device 36 via a local area network (LAN) or is integrated therein.

[0046] The security modules 40, 40′, 40″ carry out security-relevant functions of the passenger conveyor system 10. In doing so, they receive security-relevant signals 52 from the security sensors 26 and provide a warning signal 52′ to the central controller 22. It is possible for there to be redundant security modules 40, 40′ which generate the warning signal 52′ for the central controller 22. For example, redundant security modules 40, 40′ can monitor one another for malfunctions. For example, the same software code can be executed on different cores of the microcontroller 42 as redundant security modules 40, 40′. Furthermore, it is possible for a further security module 40″ to generate a further warning signal 52′ for a further controller 22′ of the passenger conveyor system 10. For example, an elevator system having a plurality of drives 20 could have a plurality of controllers 22, 22′, all of which should be stopped when a security sensor 26 signals problems.

[0047] The various software modules, such as the security modules 40, 40′, 40″ and the update module 38, can be shielded from one another in the microcontroller 42. This can be done in that some or all of the software modules are assigned their own memory regions to which other software modules are not given access and/or by restricting the data communication between the software modules.

[0048] FIG. 3 shows a security device 36 and in particular the microcontroller 42 thereof in greater detail. The security device 36 can include a data communication unit 44 via which data can be received and transmitted via the serial bus 34. These data can include the software package 50, the security-relevant signals 52 from the security sensors 26, and the warning signal 52′ to the central controller 22.

[0049] The microcontroller 42 comprises a communication interface 54 via which the microcontroller can exchange data with the data communication unit 44. Furthermore, the microcontroller 42 can comprise a plurality of processor cores 56, 56′. The software modules 38, 40, 40′, 40″ can be executed on one or more of these processor cores 56, 56′.

[0050] The microcontroller 42 further comprises a memory 58, which can be made up from a non-volatile memory 60 and a volatile memory 62. Data stored in the non-volatile memory 60 remain stored when the security device 36 or the microcontroller 42 is no longer supplied with power. The data stored in the volatile memory 62 can be lost in the process.

[0051] For example, the non-volatile memory 60 can be a protected memory that can only be changed with a mechanical intervention in the security device 36 (such as opening a housing).

[0052] A boot loader 64, the update module 38, and one or more security modules 40 can be stored in the non-volatile memory 60. The update module 38, which is stored in encrypted form in the non-volatile memory 60, can be decrypted with the boot loader 64 which can be called up when the security device 36 is started.

[0053] A private key 66 for the security device 36 and/or a public key 68 of the provider 48 of the software package 50 can also be located in the non-volatile memory 60. It is possible that only, i.e. solely the memory regions in which the boot loader 64 and the keys 66, 68 are stored, are protected as described above.

[0054] The update module 38 can be decrypted with the private key 66. The provider 48 can, for example, be authenticated with the public key 68 when a data communication is established therewith.

[0055] The microcontroller 42 is now configured in such a way that the security module 40 is only, i.e. solely, able to be amended by the update module 38. In this way, unintentional or unauthorized changes to the security module 40 can be prevented or at least made more difficult. In the following, only the security module 40 is discussed. It should be understood that the other security modules 40′, 40″ can also always be meant.

[0056] One possible configuration of the microcontroller 42 is that the security module 40 is executed on the first processor core 56 and that the update module 38 is executed on the second processor core 56′, wherein the access of the second processor core 56′ is restricted to regions of the memory 58 in which the security module 40 is stored. This can be achieved, for example, in that each of the processor cores 56, 56′ is assigned its own exclusive memory region to which the other processor core 56, 56′ has no access.

[0057] The microcontroller 42 can furthermore have a hypervisor 70 which restricts access from the executed software modules 38, 40 to the memory 58. The hypervisor 70 can be a hardware component of the microcontroller 42. However, it is also possible that the hypervisor 70 is a software module stored in the memory 58. The hypervisor 70 can be configured in such a way that it restricts access by software modules 38, 40 to the memory 58 and/or data communication between the software modules 38, 40 with one another and/or with the communication interface 54.

[0058] For example, the hypervisor 70 can restrict access of the update module 38 to regions of the memory 58 in which the security module 40 is stored.

[0059] FIGS. 4 and 5 show embodiments of the microcontroller 42 in which the communication between the software modules 38, 40 is restricted by the hypervisor 70. It should be understood that the software modules 38, 40 can be executed in the same or in different processor cores and/or that the memory regions to which they have access can also be restricted.

[0060] FIG. 4 shows an example of a microcontroller 42 in which the external communication is limited to the update module 38 by means of the hypervisor 70. The hypervisor 70 forwards the complete communication via the communication interface 54 to the update module 38. In addition, the hypervisor 70 prevents communication of the security module 40 via the communication interface. The update module 38 receives the security-relevant signals 52 and forwards them to the security module 40. Conversely, the security module 40 transmits the warning signal 52′ to the update module 38, which forwards the warning signal 52′ via the communication interface 54. In addition, the update module 38 can update the security module 40 with the data from the software package 50.

[0061] In the example of FIG. 5, the hypervisor 70 restricts the communication of the respective software module 38, 40 to the data that it is allowed to transmit and receive. The hypervisor 70 forwards the security-relevant signals 52 from the sensors 26 of the passenger transport system 10 to the security module 40 and also forwards the warning signal 52′ to the communication interface 54. In addition, the hypervisor 70 forwards the software package 50 to the update module 38. It is not possible for the update module to generate a warning signal 52′. The update module 38 can update the security module 40 with the data from the software package 50. However, it is not possible for the security module 40 to change data or code of the update module 38.

[0062] FIG. 6 shows a flow chart for a method for updating software of a security device 36, as shown, for example, in the preceding drawings.

[0063] In step S10, the update module 38 regularly queries the provider 48 via the external interface as to whether the software package 50 is available. This can occur once a day, for example. In this case, the provider 48 of the updated software 50 can also be authenticated, i.e. it can be checked whether the provider 48 is really the provider from which software package 50 is to be requested. The authentication can be carried out using the public key 66, for example.

[0064] For example, the provider 48 can be a server which is provided by a manufacturer and/or those responsible for the maintenance of the system 10 for software updates.

[0065] If there is updated software, a corresponding software package 50 is received from the update module 38 via the communication interface 54 in step S12. For example, a header of the software package 50 can first be received, in which information about the scope of the software to be updated is stored. It is possible that not all of the software but only parts of it should be updated. This can be stored in the header.

[0066] It is also possible that the software package 50 and/or the updated software thereof, are encrypted using a symmetric encryption method. The associated temporary key can be determined for this purpose by means of the two keys 66, 68.

[0067] If the software package 50 or parts thereof are encrypted, the update module 38 performs the decryption in step S14.

[0068] In step S16, the software of the security module 40 to be updated is replaced by the update module. The corresponding memory regions of the non-volatile memory 60 can be overwritten. In step S18, the method then returns to step S10 to resume the regular query.

[0069] Finally, it should be noted that terms such as “comprising,” “including,” etc. do not preclude other elements or steps, and terms such as “a” or “an” do not preclude a plurality. It must further be noted that features or steps that have been described with reference to one of the above embodiments can also be used in combination with other features or steps of other embodiments described above.

[0070] In accordance with the provisions of the patent statutes, the present invention has been described in what is considered to represent its preferred embodiment. However, it should be noted that the invention can be practiced otherwise than as specifically illustrated and described without departing from its spirit or scope.