JP6609529B2 - Railway security system - Google Patents

Description

  The present invention relates to software remote loading in a railway security system having a fail-safe device.

  In the railway security system, fail-safety is most important. As a matter of course, it is necessary not to perform dangerous side control for normal train control, but to prevent dangerous side control even when an abnormality or failure occurs in a system or apparatus.

  Regarding the functions related to system safety and fail-safety, it is desirable to simplify the system configuration and operation as much as possible in order to avoid unintended dangerous control factors from the viewpoint of testability. As computer performance and network speed increase, the functions implemented in railway security systems are also increasing.

  The railway security system is composed of a plurality of devices, and the functions required for each device are diversified. For example, a combination of software versions of multiple devices, such as failsafe devices operating with reference to each other's outputs, sending non-failsafe devices that do not directly control trains, and sending instructions for changing the control operation mode of failsafe devices If it is not optimal, a desired operation cannot be performed and the fail-safe property of the entire system may be impaired.

  On the other hand, when updating the railway security system, it is necessary to perform the update work at night from the end of the train operation until the start of the next day's train operation. There must be. If the system cannot be updated in time, the next day's train operation cannot be started, especially in places with high train operation density, such as the Tokyo metropolitan area, which may have a major impact on train operation. is there.

  In order to update the entire system in a limited time, a method of loading the software remotely has been adopted for updating the conventional railway security system. In software remote loading, a maintenance staff issues a remote loading instruction to a loading target device from a remote loading maintenance terminal, and loads software.

  In software update by remote loading, software is rewritten at the time of loading, and therefore, there is a possibility that the loaded software may not be activated due to a rewrite failure due to a hardware failure or the like. In addition, although the loading operation itself is systemized, since the maintenance instruction is given by the maintenance staff, there is a possibility that an incorrect version of the software is loaded due to a human error.

  On the other hand, by providing multiple loading software storage destinations, it is possible to quickly start the original software when a rewrite failure occurs, or until the optimal version of software is loaded. Attempts have been made to launch software in a degraded state.

  Patent Document 1 describes the operation when an abnormality occurs in software rewriting. “The latest version of the application exists on the operation side, and the old version of the application exists on the standby side. In the above, it is possible to switch the standby side file to the operational side again, return it to the version before the refurbishment, and immediately restart it, thereby shortening the use suspension period.

  Japanese Patent Laid-Open No. 2004-26883 discloses an operation when an auxiliary storage device loaded with software fails. In the operating state where the online function is reduced, only the function related to software update in the auxiliary storage device is enabled, and the software suitable for system operation is transferred from the remote maintenance device. Can be done. "

JP-A-2004-272652 JP 2006-248484 A

  Conventionally, maintenance personnel ensure that software version consistency is ensured by confirming that the software version combination of each device is optimal at the time of system update. However, the consistency of the software version of each device is not ensured due to a human error. There was a possibility that the system would work in the state.

  Therefore, in software update work by remote loading of a railway security system having a fail-safe device, there is a problem in ensuring the software version consistency of each device including the fail-safe device at the time of software update.

In order to solve the above problems, one of the typical railroad security systems of the present invention includes a loading instruction device that loads software to another device, and a loading target device that is loaded with software from the loading instruction device. The loading instructing device includes an instructing device storage unit that stores loading data of the loading target device and pre-update software version information that is software version information before the loading target device is updated, and version information notified from the loading target device. When the consistency check result information that is the check result of the consistency of the pre-update software version information stored in the instruction device storage unit is generated and the consistency check result information confirms that the consistency is normal Consistency check result information and loading data An instruction device control unit that transmits the information to the loading target device, and the loading target device notifies the loading instruction device of version information, which is version information of the software of the own device, and the consistency from the loading instruction device. When it is confirmed that the consistency is normal by the receiving unit that receives the confirmation result information and the loading data, the target device storage unit that stores the loading data, and the consistency confirmation result information, the loading data is transferred to the target device. This is achieved by including a target device control unit to be stored in the storage unit.

  According to the present invention, the loading instruction device checks the software version consistency of the pre-update and post-update systems based on the version information from the loading target device and the version information of the loading data stored in its auxiliary storage device. Thus, it is possible to reliably prevent the system from operating with a combination of software versions whose consistency has not been confirmed. Thus, according to the present invention, software remote loading in a railway security system in a state where consistency is ensured can be realized.

It is the figure which showed the example of the apparatus structure of the railway security system of Example 1. FIG. FIG. 3 is a diagram illustrating an example of functional blocks of each device according to the first embodiment. 6 is a flowchart illustrating an example of processing related to software version consistency confirmation and loading of the loading instruction apparatus according to the first exemplary embodiment. 6 is a flowchart illustrating an example of processing related to software version consistency confirmation and loading of the loading target apparatus according to the first exemplary embodiment. 12 is a flowchart illustrating an example of processing related to software version consistency confirmation and loading of the loading instruction apparatus according to the second embodiment. 12 is a flowchart illustrating processing related to software version consistency confirmation and loading of the loading instruction apparatus according to the fourth embodiment. 15 is a flowchart illustrating an example of processing related to software version consistency confirmation and loading of a loading target apparatus according to a fourth embodiment.

  Hereinafter, an embodiment of a railway security system according to the present embodiment will be described with reference to the drawings.

  FIG. 1 is a diagram illustrating an example of a device configuration of a railway security system according to the present embodiment. The loading instruction device 110 and the loading target devices 120, 130, 140, and 150 are connected on the same communication path, and can perform transmission / reception of loading data and transmission / reception of version information.

  FIG. 2 is a diagram illustrating an example of functional blocks of each device according to the present embodiment.

  In the instruction device storage unit 111, software version information before and after the update of the loading target devices 120, 130, 140, and 150 is registered in advance. Furthermore, the software before and after the update of the loading target devices 120, 130, 140, and 150 is stored in the instruction device storage unit 111 in advance.

  The instruction device control unit 112 confirms the software consistency of the loading target devices 120, 130, 140, and 150, and transmits the updated software to each device.

  The version information notifying unit 121 notifies the loading instruction device 110 of the software version information of its own device.

  The receiving unit 122 receives software consistency information and updated software from the loading instruction apparatus 110.

  The target device storage unit 123 stores software.

  The target device control unit 124 confirms the consistency of the software and stores the software received from the loading instruction device 110 in the target device storage unit 123. In addition, the own apparatus is activated and operated by software stored in the target apparatus storage unit 123.

  The functional blocks of the loading target devices 130, 140, and 150 are the same as those of the loading target device 120.

  FIG. 3 is a flowchart showing processing related to software version consistency confirmation and loading of the loading instruction apparatus 110. This process is performed when the maintenance staff explicitly instructs the loading instruction device 110. However, the loading instruction device 110 may be performed by designating the execution date and time, or the loading instruction device 110 may be performed at a constant cycle. May be.

  In step S301, the instruction device control unit 112 starts this processing. Then, the process proceeds to step S302.

  In step S302, the instruction device control unit 112 receives software version information from each of the loading target devices 120, 130, 140, and 150. Then, the process proceeds to step S303.

  In step S303, the instruction device control unit 112 receives the software version information received from each loading target device 120, 130, 140, 150 and each loading target device 120, 130, 140 registered in advance in the instruction device storage unit 111. , 150 is compared with the pre-update software version information, and consistency confirmation result information is generated that the consistency is normal if the version is the same, and the consistency is abnormal if the version is not the same. Then, the process proceeds to step S304.

  In step S304, the instruction device control unit 112 confirms consistency from the consistency confirmation result information. If the consistency is normal, the process proceeds to step S305. If the consistency is abnormal, the process proceeds to step S306. Even when version information cannot be received from the loading target devices 120, 130, 140, and 150, the consistency is treated as abnormal. When the consistency is not normal, the maintenance staff may be notified by a message or the like that the version information does not match. Furthermore, the maintenance staff may be notified by a message or the like so as to perform reloading or rollback to the pre-update system.

  In step S305, the instruction device control unit 112 acquires the updated software of the loading target devices 120, 130, 140, and 150 from the instruction device storage unit 111, and loads them together with the consistency check result information, 130, 140, 150. Then, the process proceeds to step S306.

  In step S306, the instruction device control unit 112 ends this process.

  FIG. 4 is a flowchart showing processing related to software version consistency confirmation and loading of the loading target devices 120, 130, 140, and 150. This processing is performed at a constant cycle in each of the loading target devices 120, 130, 140, and 150. Since this processing is the same for the loading target devices 120, 130, 140, and 150, only the loading target device 120 will be described.

  In step S401, the target device control unit 124 starts this processing. Then, the process proceeds to step S402.

  In step S <b> 402, the target device control unit 124 acquires software version information of the software stored in the target device storage unit 123 and transmits it to the loading instruction device 110. Thereafter, the process proceeds to operation S403.

  In step S403, the target device control unit 124 receives the loading data and the like (loading data (that is, updated software) and consistency check result information, the same applies hereinafter) from the loading instruction device 110 to the receiving unit 122. Let Thereafter, the process proceeds to operation S404.

  In step S <b> 404, the target device control unit 124 confirms whether the receiving unit 122 has successfully received the loading data or the like. When the signal has been received normally, the process proceeds to step S405. When the signal has not been received normally, the process proceeds to step S407.

  In step S405, the target device control unit 124 confirms consistency from the consistency confirmation result information. If the consistency is normal, the process proceeds to step S406. If the consistency is not normal, the process proceeds to step S407. When the consistency is not normal, the maintenance staff may be notified by a message or the like that the version information does not match.

  In step S <b> 406, the target device control unit 124 stores the loading data in the target device storage unit 123. At this time, the maintenance staff may be notified by a message or the like that the loading has been normally completed. Further, the updated version information registered in the loading instruction device 110 can be re-registered as pre-update version information. However, there is a possibility that a problem is detected after the system is updated and the system is returned to the state before the update. The version information re-registration before and after the update registered in the loading instruction apparatus 110 may not be performed. Thereafter, the process proceeds to operation S407.

  In step S407, the target device control unit 124 ends this process.

  According to this embodiment, the loading instruction apparatus 110 can confirm the version of the software before update of each of the loading target apparatuses 120, 130, 140, and 150, and can confirm that the software to be updated is correct. it can.

  The second embodiment is based on the first embodiment, but the conditions under which the loading instruction device 110 transmits loading data to the loading target devices 120, 130, 140, and 150 are different. That is, step S304 in FIG. 3 is different from the first embodiment.

  FIG. 5 is a flowchart illustrating processing related to software version consistency confirmation and loading of the loading instruction apparatus 110 according to the second embodiment. 3 differs from FIG. 3 in that it is S501. Others are the same.

  In step S501, the instruction device control unit 112 confirms consistency from the consistency confirmation result information. In addition, the instruction device control unit 112 includes the updated software version information stored in the instruction device storage unit 111 and the loading target devices 120, 130, 140, and 150. Based on the software version information received from each of 140 and 150, it is confirmed whether the version information is different before and after the update. If the consistency is normal and the version information is different before and after the update, the process proceeds to step S305. Otherwise, the process proceeds to step S306.

  According to the present embodiment, the loading instruction device 110 can transmit loading data or the like when the software before and after the update is different. Therefore, the communication load of the communication path, the loading instruction device 110 and each loading target device 120, The processing load of 130, 140, 150 can be suppressed.

  The third embodiment is based on the second embodiment, but the processing content of step S303 in FIG. 5 is different.

  In step S <b> 303 of FIG. 5 in this embodiment, the instruction device control unit 112 receives the software version information received from each loading target device 120, 130, 140, and 150 and each loading registered in advance in the instruction device storage unit 111. Comparison with the pre-update software version information of the target devices 120, 130, 140, 150, the consistency check result before update that the consistency is normal if the version is the same, and the consistency is abnormal if the version is not the same Generate information.

  Further, the instruction device control unit 112 acquires version information from the updated software stored in the instruction device storage unit 111 for each of the loading target devices 120, 130, 140, and 150, and stores it in the instruction device storage unit 111. Acquire updated software version information that has been registered, compare these version information, and if the versions are the same, the consistency is normal, and if the versions are not the same, the consistency is abnormal Confirmation result information is generated.

  Further, the instruction device control unit 112 determines that the consistency is normal when the consistency is normal than the pre-update consistency check result information and the consistency is normal than the post-update consistency check result information. Generate information. In other cases, consistency check result information is generated assuming that the consistency is abnormal. Then, the process proceeds to step S501.

  According to this embodiment, it is possible to check the version of the updated software, and it is possible to avoid operating each loading target device 120, 130, 140, 150 with incorrect software.

  The fourth embodiment is based on the third embodiment, except that the software version information is confirmed even after the loading instruction apparatus 110 transmits the loading data or the like.

  That is, for the loading instruction device 110, the processing after step S305 in FIG. 5 is different. The processing after step S406 in FIG. 4 is different for each loading target device 120, 130, 140, 150.

  FIG. 6 is a flowchart illustrating processing related to the software version consistency check and loading of the loading instruction apparatus 110 according to the fourth embodiment.

  The process in step S305 is the same as that in the third embodiment, except that the transition destination is step S601.

  In step S <b> 601, the instruction device control unit 112 receives software version information from each loading target device 120, 130, 140, 150. Then, the process proceeds to step S602.

  In step S <b> 602, the instruction device control unit 112 receives the software version information received from each loading target device 120, 130, 140, 150 and each loading target device 120, 130, 140 registered in advance in the instruction device storage unit 111. 150, the post-loading consistency check result information is generated that the consistency is normal if the version is the same, and the consistency is abnormal if the version is not the same. Then, the process proceeds to step S603.

  In step S <b> 603, the instruction device control unit 112 transmits post-loading consistency check result information to the loading target devices 120, 130, 140, and 150. Then, the process proceeds to step S306.

  FIG. 7 is a flowchart illustrating an example of processing related to the software version consistency check and loading of each loading target device 120, 130, 140, 150 according to the fourth embodiment.

  The process in step S406 is the same as that in the third embodiment, except that the transition destination is step S701.

  In step S <b> 701, the target device control unit 124 acquires the software version information of the software stored in the target device storage unit 123 and transmits it to the loading instruction device 110. Then, the process proceeds to step S702.

  In step S <b> 702, the target device control unit 124 causes the receiving unit 122 to receive post-loading consistency check result information from the loading instruction device 110. Then, the process proceeds to step S703.

  In step S703, the target device control unit 124 confirms consistency from the post-loading consistency confirmation result information. If the consistency is normal, the process proceeds to step S407. If the consistency is not normal, the process proceeds to step S704.

  In step S704, the target device control unit 124 intentionally damages the loading data (that is, the updated software) stored in the target device storage unit 123 so that it cannot be activated by the software. Thereafter, the process proceeds to operation S407.

  Since the system update work time is limited, it is desirable to secure a plurality of areas for loading software in the target device storage unit 123 of the target devices 120, 130, 140, and 150. Whether there are a plurality of loading areas does not affect the effect of the present invention.

  According to the present embodiment, when the version of the loading data (that is, the updated software) stored in the target device storage unit 123 is recognized as abnormal, it is intentionally damaged, and the loading target device 120 causes the software to be loaded. Therefore, it is possible to prevent a dangerous event from occurring by operating with an unexpected software.

  In the present invention, the communication path used at the time of loading and the method for ensuring the reliability in the auxiliary storage device of the loading instruction device and the loading target device are not mentioned. By using a CRC or ECC memory, it is possible to separately take measures for ensuring reliability.

  In addition, this invention is not limited to an above-described Example, Various modifications are included. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.

110: Loading instruction device 111 ... Instruction device storage unit
112 ... Indicator control unit
120, 130, 140, 150 ... loading target device 121 ... version information notification unit
122: Receiver
123 ... Target device storage unit 124 ... Target device control unit

Claims (3)

A loading instruction device for loading software into another device, and a loading target device loaded with software from the loading instruction device,
The loading instructing device, an instructing device storage unit that stores loading data that is software after updating the loading target device and pre-update software version information that is software version information before updating the loading target device;
Generating consistency check result information that is a check result of consistency between the version information notified from the loading target device and the pre-update software version information stored in the instruction device storage unit; and the consistency check result information An instruction device controller that transmits the consistency confirmation result information and the loading data to the loading target device when it is confirmed that the consistency is normal.
The loading target device includes a version information notification unit that notifies the loading instruction device of the version information that is version information of software of the device itself;
A receiving unit for receiving the consistency check result information and the loading data from the loading instruction device;
A target device storage unit for storing the loading data;
A target device control unit that stores the loading data in the target device storage unit and updates the software when the consistency check result information confirms that the consistency is normal ;
The indicating device storage unit stores updated software version information that is updated software version information of the loading target device,
The instruction device control unit includes the consistency confirmation result information in the confirmation result of the consistency between the version information notified from the loading target device and the pre-update software version information stored in the instruction device storage unit, A railway security system, which is generated by adding a result of confirming consistency between the version information of the loading data and the updated software version information . In the railway security system according to claim 1,
The instruction device control unit generates post-loading consistency check result information, which is a check result of consistency between version information notified from the loading target device after loading and the updated software version information, and transmits the generated information to the loading target device. And
The version information notification unit transmits the version information of the loading data stored in the target device storage unit to the loading instruction device after the loading data is stored in the target device storage unit,
The receiving unit receives the post-loading consistency check result information from the loading instruction device;
The target device control unit may damage the loading data stored in the target device storage unit when it cannot be confirmed that the consistency is normal based on the post-loading consistency check result information. Railway security system. In the railway security system according to any one of claims 1 to 2,
When the consistency check result information confirms that the consistency is normal, and when the version information of the loading data is different from the version information notified from the loading target device, the instruction device control unit The railway security system , wherein the consistency check result information and the loading data are transmitted to the loading target device .

Images