JP7426886B2 - Delivery locker system - Google Patents

Description

The present invention relates to a delivery locker system having a function of communicating with the outside.

There is a delivery locker system that is equipped with a function to communicate with the outside world to notify the recipient of the package's arrival, and a function that allows the delivery company to grasp the status of the delivery locker before delivery.
For example, in Patent Document 1, a delivery box installed at the entrance of an apartment complex is equipped with a function to communicate with a server via a communication network, and when a package is stored, it notifies the server of the information, and when the package is stored, the information is input. A delivery locker system has been disclosed in which, when a resident returns home and enters an ID or the like into an authentication device based on the information received, the presence or absence of arrival is displayed.
Moreover, when updating the software of such a delivery locker system that is capable of communicating with the outside, it is possible to update the software from the outside using a communication network.

Japanese Patent Application Publication No. 2004-59228

As described above, the delivery locker system connected to a communication network can have its software updated from the outside, but it has the following problems.
If the delivery locker consists of multiple devices, it is necessary to update all devices, but if the update fails on the second or later devices during the sequential implementation process, the old and new devices will be updated in one system. A case occurred where the versions of . Especially when this is combined with a version for which operation is not guaranteed by the manufacturer, there is a possibility that unintended problems may occur.

SUMMARY OF THE INVENTION In view of these problems, it is an object of the present invention to provide a delivery locker system that prevents old and new versions of devices from coexisting when software is updated.

In order to solve the above problem, the invention of claim 1 is a delivery locker system that includes a delivery locker equipped with a network connection device that communicates with the outside, and a management server that communicates with the delivery locker via a communication network. The delivery locker includes a plurality of baggage storage sections each equipped with an electric lock, at least one electric lock control device for controlling the electric lock, and an operation section for locking/unlocking the electric lock. It has a main control device that controls the entire delivery locker, and the main control device updates the software of at least one of the main control device, network connection device, electric lock control device, and main control device from the management server. When the information is received, update software is obtained from the management server and software updates of the target devices are started in a preset order . If there are devices that fail to update midway, the update control is terminated and returned to the previous version . The present invention is characterized in that for devices that have already been updated, the device itself executes control to return the software version to the previous version in the reverse order of the update .

According to the present invention, when there are multiple devices to be updated with software in the system, if even one device fails to update, the old and new versions are restored, including the version of the device that has already been updated. Never mix. Therefore, it is possible to prevent unintended problems from occurring due to mixed versions.

1 is a configuration diagram showing an example of a delivery locker system according to the present invention. FIG. 3 is a sequence diagram showing the flow when updating proceeds normally. FIG. 7 is a sequence diagram showing the flow when updating fails midway.

Hereinafter, embodiments embodying the present invention will be described in detail with reference to the drawings. FIG. 1 is a configuration diagram showing an example of a delivery locker system according to the present invention, in which 1 is a delivery locker, 2 is a management server that manages the delivery locker 1, 3 is a mobile phone carried by the administrator of the delivery locker 1, and N is a communication network.
The delivery locker 1 and the management server 2 perform, for example, IP communication via the communication network N, and the delivery locker 1 and the mobile phone 3 perform, for example, SNS (Social Network Service) communication.

The delivery locker 1 includes an electric lock 11 provided for each baggage storage section (not shown) in which packages are stored, an electric lock control device 12 that controls the electric lock 11 for each group of storage sections, and a locking/unlocking operation. The main control device 15 includes an operation unit 14 that performs operations, a network connection device 13 that communicates with the outside via a communication network N, a main control device 15 that controls the entire delivery locker 1, and the main control device 15 stores software version information of each device. A setting information storage section 16 is provided.
Note that here, the electric lock control device 12 is composed of two devices, a first electric lock control device 12a and a second electric lock control device 12b. In addition to the management server 2, the network connection device 13 has a function of communicating with the mobile phone 3 carried by the administrator of the delivery locker 1.

The management server 2 includes a software information storage unit 21 that stores software information to be updated, a delivery locker information storage unit 22 that stores address information, etc. for communicating with the delivery locker 1 to be managed, and a management server that controls the management server 2. It includes a control unit 23, a management server communication IF 24 that communicates with the delivery locker 1 via the communication network N, and the like.

In the delivery locker system configured as described above, firmware (software) is updated as follows. This will be explained with reference to the sequence diagrams in FIGS. 2 and 3.
Specifically, the firmware to be updated is, for example, an IO unit for the electric lock control device 12, an IoT gateway for the network connection device 13, and a personal computer for the main control device 15, for example. Further, the IO units (not shown) of the two electric lock control devices 12 are in the relationship of a master device and a slave device, and the IO unit of the first electric lock control device 12a is the master device, and the IO unit of the second electric lock control device 12b is the master device. The IO unit is the slave device. Therefore, when the main control device 15 controls the second electric lock control device 12b, the control is performed via the first electric lock control device 12a.

First, the flow of updating the firmware of all devices without failure will be described with reference to FIG. 2. For example, regular communication is performed between the management server 2 and the main control device 15 every hour (S1), and when there is firmware version upgrade information (update information), the main control device 15 communicates with the main control device 15 through regular communication. This is recognized and information on the update target device is also obtained (S2).
Next, update software data is downloaded all at once from the management server 2 (S3), and the obtained update data is sequentially transmitted to the update target devices (S4, S5, S6). Then, update control is performed sequentially in a preset order at a determined date and time.
In this way, by transmitting the update software to the target device in advance, update control can be shortened.
Here, a case is shown in which the firmware of the main control device 15, network connection device 13, and electric lock control device 12 is updated, and the updates are performed in this order.

At the predetermined date and time, the firmware update of the main control device 15 is first started (S7), and when the update is completed, an instruction to update the firmware is issued to the network connection device 13.
The network connection device 13 that has received the update instruction updates the firmware using the update data that has already been obtained (S9).

When the update of the network connection device 13 is completed, the second electric lock control device 12b is updated, and then the first electric lock control device 12a is updated. In both cases, the update is performed using the update data that has already been obtained (S10). In this way, when the updating of all the devices to be updated is completed, the software version information in the setting information storage section 16 of the main control device 15 is rewritten and updated (S11).
Furthermore, the completion of the firmware update is notified to the mobile phone 3 via the network connection device 13.

Next, the flow when an error occurs during the update and the update fails will be described with reference to FIG. 3. Here, an example will be described in which the firmware update of the second electric lock control device 12b fails.
Since the control up to the update of the network connection device 13 is the same as that in FIG. 2, the explanation will be omitted, and the flow of control after that will be explained. The second electric lock control device 12b, which has received the version upgrade instruction (update instruction) from the main control device 15, starts update control using the update data that has already been obtained.
However, if the update fails, the second electric lock control device 12b returns to the previous version. This control to return to the old version is executed by the second electric lock control device 12b itself. Then, the update failure is notified to the main control device 15 via the first electric lock control device 12a (S12, S13).

When the main control device 15 receives the failure information, if there is a device whose version has already been updated, it issues an instruction to the device to return to the previous version. This instruction is performed in the reverse order of the update, and here the instruction is first issued to the network connection device 13.
Upon receiving the instruction, the network connection device 13 performs control to return to the previous version (S14). When this process is completed, the main control device 15 returns its version to the old version (S15).
In this way, the version is returned to the previous version in the reverse order of the software update, and the software versions of all devices are returned to the previous version before the update, and the process ends. Furthermore, the mobile phone 3 is notified via the network connection device 13 that the firmware update has failed.

In this way, if there are multiple devices in the system that are subject to software update, and even one device fails to update, the old and new versions will coexist because the version of the device that has already been updated will be reverted to the previous version. Never. Therefore, it is possible to prevent unintended problems from occurring due to mixed versions.

In the above embodiment, a case has been described in which the second electric lock control device 12b, which is updated third, fails to update, but the same applies even if the update of other devices fails, and the update is performed in the reverse order. Control to revert to the previous version is implemented.

1...Delivery locker, 2...Management server, 11...Electric lock, 12...Electric lock control device, 13...Network connection device, 14...Operation unit, 15...Main control device, 16...Settings Information storage unit, 21... Software information storage unit, 22... Delivery locker information storage unit, 23... Management server control unit, N... Communication network.

Claims (1)

A delivery locker system comprising a delivery locker equipped with a network connection device that communicates with the outside, and a management server that communicates with the delivery locker via a communication network,
The delivery locker includes a plurality of baggage storage sections each individually equipped with an electric lock;
at least one electric lock control device that controls the electric lock;
an operation unit for locking/unlocking the electric lock;
It has a main control device that controls the entire delivery locker,
When the main control device receives software update information for at least one of the main control device, the network connection device, the electric lock control device, and the main control device from the management server, the main control device updates the software to the management server. Obtain update software from , start software updates for the target device in a preset order ,
If there is a device that fails to update midway, the update control is terminated and the software is returned to the previous version.For devices that have already been updated, the software is controlled to be returned to the previous version in the reverse order of the update. A delivery locker system characterized by implementation .

Images