Server equipment and device management method

Abstract

This invention provides a server device and a device management method that can properly manage software updates for devices. [Solution] In the management system 1, the server device 12 for managing the software versions of drive recorders 11 installed in each of the multiple commercial vehicles 10 includes: a command issuing unit 31 that issues a command for a software update to the multiple drive recorders 11 in a batch; a progress information acquisition unit 33 that acquires the progress status of the software update for each of the drive recorders 11 in response to the command; a determination unit 34 that determines that an abnormality has occurred in a drive recorder 11 whose progress status has not changed even though the conditions for starting the software update, which are determined based on information indicating the operation of the vehicle 10, have been met; and a display control unit 35 that displays that an abnormality has occurred in the drive recorder 11.

Description

Technical Field

[0001] The present invention relates to a server device and a device management method.

Background Art

[0002] Conventionally, a server device that connects to a device mounted on a vehicle and manages the device is known. For example, Patent Document 1 discloses a server that checks the current status of software updates of a device and issues update requests.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, depending on the state of the vehicle on which the device is mounted, software updates may not be started. For example, updates may not be performed while the vehicle is in motion.

[0005] In Patent Document 1, the current status of software updates can be checked, but when a device that has not been updated is checked, it is not possible to determine whether an abnormality has occurred in the device or whether the conditions for starting the update are not satisfied.

[0006] The present invention has been made in view of such problems, and an object thereof is to provide a server device and a device management method capable of appropriately managing software updates of a device.

Means for Solving the Problems

[0007] One aspect of the present invention is a server device for managing the software versions of drive recorders installed in each of a plurality of commercial vehicles, comprising: a command issuing unit that issues a command for a software update to the plurality of drive recorders in a batch; a progress information acquisition unit that acquires the progress status of the software update for each drive recorder in response to the command; a determination unit that determines that an abnormality has occurred in a drive recorder whose progress status has not changed even though the conditions for starting a software update, which are determined based on information indicating the operation of the vehicle, have been met; and a display control unit that displays that an abnormality has occurred in the drive recorder.

[0008] One aspect of the present invention is a device management method for managing the software versions of drive recorders installed in each of several commercial vehicles, comprising: a command issuance step of issuing a command for a software update to the several drive recorders in a batch; a progress information acquisition step of acquiring the progress status of the software update for each drive recorder in response to the command; a determination step of determining that an abnormality has occurred in a drive recorder whose progress status has not changed even though the conditions for starting a software update, determined based on information indicating the operation of the vehicle, have been met; and a display control step of displaying that an abnormality has occurred in the drive recorder. [Effects of the Invention]

[0009] According to the present invention, device software updates can be properly managed. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 shows an example configuration of the management system 1. [Figure 2] Figure 2 is a block diagram showing an example configuration of the server device 12. [Figure 3] Figure 3 is a block diagram showing an example configuration of the drive recorder 11. [Figure 4] Figure 4 is a flowchart showing the flow of the update management process by the server device 12. [Figure 5] Figure 5 is a flowchart showing the update process for the managed software in the drive recorder 11. [Figure 6] Figure 6 shows an example of a shift schedule for 10 vehicles on a given day. [Modes for carrying out the invention]

[0011] [One Embodiment] The following describes a management system 1 according to an embodiment of the present invention.

[0012] (Example configuration of Management System 1) Figure 1 shows an example configuration of the management system 1. The management system 1 consists of drive recorders 11-1 to 11-4 installed in each of the commercial vehicles 10-1 to 10-4 (which will be simply referred to as vehicle 10 if there is no need to distinguish them individually; the same applies in other cases), and a server device 12. The drive recorders 11 and the server device 12 are connected bidirectionally via the network W.

[0013] Although Figure 1 shows four vehicles 10 and four drive recorders 11 installed in each vehicle 10, in reality, the management system 1 may include more vehicles 10 and drive recorders 11. Also, a single vehicle 10 may be equipped with multiple drive recorders 11. Furthermore, the multiple drive recorders 11 do not need to be manufactured by the same company, of the same model, or have the same model number. In other words, the management system 1 may be composed of multiple drive recorders 11 from different manufacturers, of different models, and with different model numbers.

[0014] The drive recorder 11 executes processing as a drive recorder, such as recording images in front of and around the vehicle 10, based on a predetermined software program installed therein (hereinafter referred to as the management target software).

[0015] When the drive recorder 11 receives a command from the server device 12 to update the management target software, the drive recorder 11 updates the management target software according to the operating state of the vehicle 10 while appropriately transmitting information indicating the progress of the update (hereinafter referred to as progress information) to the server device 12.

[0016] The server device 12 manages the software version of the management target software installed in each drive recorder 11. Specifically, for example, when the function or the like of the management target software is updated, the server device 12 transmits an instruction to update to the latest software version to the drive recorder 11. The server device 12 determines whether an abnormality has occurred in the update of the management target software in the drive recorder 11 based on the progress state of the update based on the progress information transmitted from the drive recorder 11 and the operating state of the vehicle 10.

[0017] Note that the drive recorder 11 is registered as a management target device in the server device 12, and it is assumed that an ID for identifying the drive recorder 11 is determined. Although appropriately omitted in the following description, the information exchanged between the drive recorder 11 and the server device 12 includes an ID for identifying the drive recorder 11 and is appropriately used in each process.

[0018] (Configuration example of server device 12) FIG. 2 is a block diagram showing a configuration example of the server device 12. The server device 12 includes a communication unit 21, a storage unit 22, a control unit 23, and a display unit 24.

[0019] The communication unit 21 communicates with the drive recorder 11 via the network W under the control of the control unit 23.

[0020] The storage unit 22 is an information recording device constituted by a magnetic recording medium (e.g., flexible disk, magnetic tape, hard disk drive), a magneto-optical recording medium (e.g., magneto-optical disk), a semiconductor memory (e.g., EPROM (Electrically Erasable Programmable Read-Only Memory), flash ROM, RAM (Random Access Memory)), etc. The storage unit 22 stores various programs for controlling the overall operation of the server device 12 and various data acquired by the server device 12.

[0021] The control unit 23 is configured to include an arithmetic circuit such as a CPU (Central Processing Unit) and a storage circuit such as a RAM. By reading and executing the information processing program stored in the storage unit 22, the control unit 23 functions as a command issuing unit 31, an operation information acquisition unit 32, a progress information acquisition unit 33, a determination unit 34, and a display control unit 35.

[0022] The command issuing unit 31 collectively transmits commands for software update to a plurality of drive recorders 11. The command issuing unit 31 transmits commands to, for example, all the drive recorders 11 registered as management target devices. The command issuing unit 31 may also select the drive recorders 11 to which commands for software update are to be transmitted. For example, the command issuing unit 31 selects only the drive recorders 11 of the model number targeted for software update.

[0023] The operation information acquisition unit 32 acquires information (hereinafter referred to as operation information) that can determine whether the vehicle 10 is running or not. The operation information is either registered separately in the server device 12 or provided from the drive recorder 11 of the vehicle 10 or other terminals.

[0024] The progress information acquisition unit 33 acquires progress information indicating the progress state of the update of the software to be managed transmitted from the drive recorder 11.

[0025] The determination unit 34 determines, based on the operational information, the conditions under which the update of the managed software of each drive recorder 11 will begin (hereinafter referred to as the conditions for initiating the software update). Based on the progress information, if the conditions for initiating the software update have been met but the update progress status has not changed, the determination unit 34 determines that an abnormality has occurred in that drive recorder 11. The conditions for initiating the software update will be described later.

[0026] The display control unit 35 displays the judgment results from the judgment unit 34 on the display unit 24. Specifically, the display control unit 35 displays on the display unit 24 that the drive recorder 11 is abnormal if the judgment unit 34 has determined that there is an abnormality. In addition to the abnormality, the display control unit 35 may also display progress information on the display unit 24.

[0027] The display unit 24 is, for example, a liquid crystal or organic EL (Electro-Luminescence) display device, and displays the judgment results of the judgment unit 34, etc., according to the control of the display control unit 35. The display unit 24 may be provided in an external device separate from the server device 12.

[0028] (Example configuration for drive recorder 11) Figure 3 is a block diagram showing an example configuration of the drive recorder 11. The drive recorder 11 is composed of a camera 41, a communication unit 42, a storage unit 43, and a control unit 44.

[0029] Camera 41 captures images of the area around vehicle 10. More specifically, camera 41 captures images of either the interior of vehicle 10, the exterior of vehicle 10, or both.

[0030] The communication unit 42 communicates with the server device 12 via the network W, in accordance with the control of the control unit 44.

[0031] The storage unit 43 is an information recording device composed of magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), semiconductor memory (e.g., EPROM, flash ROM, RAM), etc. The storage unit 43 stores various programs, such as a software program that executes drive recorder processing as managed software and a program for controlling updates of the managed software, as well as various data acquired by the drive recorder 11.

[0032] The control unit 44 is composed of an arithmetic circuit such as a CPU and a memory circuit such as RAM. The control unit 44 makes the device function as a drive recorder by executing the managed software stored in the memory unit 43. The control unit 44 also functions as an update control unit 51 by reading and executing a program for controlling updates of the managed software.

[0033] When the update control unit 51 receives a command from the server device 12 to update the managed software, it updates the managed software according to the operating status of the vehicle 10, while appropriately transmitting progress information indicating the progress of the update to the server device 12.

[0034] (Update management process) Next, the update management process by the server device 12 will be explained with reference to the flowchart in Figure 4.

[0035] When the functions of the managed software are updated, at a predetermined timing, in step S11, the command issuing unit 31 of the server device 12 sends a software update command to each drive recorder 11 in a batch via the communication unit 21. The command issuing unit 31 may also extract the drive recorders 11 affected by the update and send the software update command to them in a batch.

[0036] In step S12, the progress information acquisition unit 33 begins receiving progress information transmitted from each drive recorder 11. In steps after step S12, if the command issuing unit 31 receives a request from the drive recorder 11 to acquire a software program for updating the managed software, it transmits the software program for updating the managed software to the drive recorder 11 via the communication unit 21.

[0037] In step S13, the determination unit 34 determines whether each drive recorder 11 meets the conditions for initiating a software update based on the operation information acquired by the operation information acquisition unit 32, and extracts the drive recorders 11 that meet those conditions. Drive recorders 11 that meet the conditions for initiating a software update will be referred to below as condition-satisfied drive recorders 11. In step S13, the display control unit 35 may display information on the display unit 24 indicating whether each drive recorder 11 meets the conditions for initiating a software update. Details of the conditions for initiating a software update will be described later.

[0038] In step S14, the determination unit 34 determines whether the progress status of the software update of the condition-satisfying drive recorder 11 has changed, based on the progress information acquired by the progress information acquisition unit 33. If the progress status of the condition-satisfying drive recorder 11 has not changed, the determination unit 34 determines that an abnormality has occurred in that drive recorder 11.

[0039] In step S15, the display control unit 35 displays the determination result from the determination unit 34 on the display unit 24. Specifically, if the display control unit 35 determines that there is an abnormality in a drive recorder 11, it displays the ID of that drive recorder 11 along with that fact on the display unit 24.

[0040] In step S16, the determination unit 34 determines whether there are any drive recorders 11 that have not been extracted as condition-satisfying drive recorders 11. If there are drive recorders 11 that have not been extracted (step S16: Yes), the determination unit 34 returns to step S13 and repeats the process.

[0041] If there are no drive recorders 11 that have not been extracted as satisfying the conditions in step S16 (step S16: No), the process ends.

[0042] The determination unit 34 may wait until all of the drive recorders 11 under management are identified as drive recorders 11 that meet the conditions, and then determine whether or not there are any abnormalities in all of the drive recorders 11 and display the results.

[0043] (Processing of drive recorder 11 in response to update management processing) Next, the update process for the managed software performed on each drive recorder 11 will be explained with reference to the flowchart in Figure 5. As mentioned earlier, multiple drive recorders 11 may be manufactured by different companies. Therefore, multiple drive recorders 11 may not have the same specifications. In other words, the process for drive recorder 11 shown in the flowchart in Figure 5 is just one example.

[0044] In step S31, when the update control unit 51 of the drive recorder 11 receives a software update command from the server device 12, in step S32, it starts updating progress information indicating the progress status of the managed software update at a predetermined frequency and sending it to the server device 12. Here, the predetermined frequency is, for example, one hour, but is not limited to this and may differ for each of the multiple drive recorders 11.

[0045] Furthermore, the update control unit 51 of the drive recorder 11 sends a request to the server device 12 to obtain a software program for updating the managed software, for example in step S31. The timing at which the drive recorder 11 sends the request to the server device 12 to obtain a software program for updating the managed software is not limited to this and may differ for each of the multiple drive recorders 11.

[0046] In step S33, the update control unit 51 starts updating the managed software at a timing corresponding to the operating status of the vehicle 10 on which the drive recorder 11 is installed. For example, the update control unit 51 starts updating the managed software when the accessory power of the vehicle 10 is turned off. The update control unit 51 starts updating the managed software when the accessory power of the vehicle 10 has been turned off for a certain period of time, for example, one hour. In other words, the timing at which the drive recorder 11 starts updating the managed software, depending on the operating status of the vehicle 10, may differ for each of the multiple drive recorders 11.

[0047] More specifically, if the update control unit 51 has already received a software program for updating the managed software from the server device 12, it will update the managed software by executing that software program. Alternatively, if the update control unit 51 has not yet received a software program for updating the managed software, it may obtain one from the server (not shown) that provides the managed software and update the managed software by executing that software program.

[0048] In step S34, if the software update process is completed (step S34: Yes), the process ends. If the software update process is not completed (step S34: No), the update control unit 51 repeats the process in step S34. The update control unit 51 may also send information regarding the completion of the software update process, such as whether it was completed successfully or abnormally, to the server device 12.

[0049] (Conditions for initiating a software update) As described above, the determination unit 34 of the server device 12 determines that an abnormality has occurred in the drive recorder 11, even though the conditions for initiating a software update have been met and the progress status has not changed (steps S13, S14). Here, an example of the conditions for initiating a software update will be explained.

[0050] (Conditions based on the scheduled end time of operation for drive recorder 11) The condition for starting a software update can be the elapsed time when the drive recorder 11 is scheduled to cease operation. This is because performing a software update while the drive recorder 11 is in operation may temporarily halt its recording function, so it is preferable to start the software update after it has ceased operation. As mentioned above, the drive recorder 11 starts updating the managed software at a timing that corresponds to the operating status of the vehicle 10 in which it is installed, but the timing may differ for each drive recorder 11. Even in such cases, by setting the condition for starting a software update based on the scheduled time when the drive recorder 11 is scheduled to cease operation, it is possible to properly manage the device's software update by only detecting an abnormality when there is a high probability that the device is malfunctioning.

[0051] The time when vehicle 10's operation ends can be set as the scheduled time when the drive recorder 11's operation ends. In this case, the operation information is obtained from a shift schedule showing the operation schedule of vehicle 10 equipped with the drive recorder 11. Specifically, the operation information acquisition unit 32 obtains a shift schedule that has been pre-registered in the server device 12. Alternatively, the operation information acquisition unit 32 obtains a shift schedule from another terminal (not shown) where the shift schedule is stored. Figure 6 shows an example of a shift schedule for each vehicle 10 for a given day. This shift schedule shows the pre-created operation schedules for vehicles 10-1 to 10-4, and the time periods indicated by the filled-in areas indicate the time periods when the vehicles are in operation.

[0052] The decision unit 34 calculates the scheduled end time for the operation of each drive recorder 11 from such a shift schedule, and sets the elapsed time of the scheduled end time for the drive recorder 11 as the condition for starting the software update. In the example shift schedule in Figure 6, the decision unit 34 sets the time when the operation of the vehicle 10 ends as the scheduled end time for the drive recorder 11, and sets the elapsed time of that scheduled end time as the condition for starting the software update. Specifically, the elapsed time of the scheduled end time for drive recorder 11-1 (16:00), the scheduled end time for drive recorder 11-2 (17:00), the scheduled end time for drive recorder 11-3 (18:00), and the scheduled end time for drive recorder 11-4 (19:00) as the conditions for starting the software update for each drive recorder 11.

[0053] In this example, each drive recorder 11 starts a software update after the vehicle 10 has finished operating.

[0054] The scheduled time for the server device 12 to stop operating the drive recorder 11, and the timing for the drive recorder 11 to start the software update, may not be the same time as the scheduled end time of operation according to the shift schedule, but may be a predetermined time after a certain period of time has elapsed. For example, it may be 30 minutes after the scheduled end time of operation according to the shift schedule. This allows for appropriate handling of situations such as when working hours exceed those specified in the shift schedule.

[0055] In the shift schedule in Figure 6, the operation of vehicle 10 is interrupted for a predetermined period of time. If this downtime is longer than the time required for the software update, the software update can be performed during this time. However, the time required for the software update of each drive recorder 11 may differ. Therefore, it is best to consider the time for the drive recorder 11 that is expected to take the longest to complete its software update. In that case, in the shift schedule in Figure 6, if the software updates for each drive recorder 11 can all be completed within one hour, the conditions for starting the software update would be that 12:00 has passed for drive recorder 11-1, 13:00 for drive recorder 11-2, 14:00 for drive recorder 11-3, and 15:00 for drive recorder 11-4.

[0056] ((Conditions based on the location information of vehicle 10)) The presence of a vehicle 10 equipped with a drive recorder 11 in a designated location can be a condition for initiating a software update. The designated location (hereinafter referred to as the non-operation location) is a place where the vehicle 10 is parked when it is not in operation, for example, the parking lot of the branch office of the company that owns the vehicle 10. If the vehicle 10 is in the non-operation location, the vehicle 10 is not in operation, so it is assumed that the drive recorder 11 is not operating, and therefore the drive recorder 11 can begin the software update. If the vehicle 10 is in the non-operation location, it is also possible that the operations manager and other vehicles (not shown) are also in the non-operation location. Therefore, by setting a condition based on the location information of the vehicle 10 as a condition for initiating a software update, it becomes possible to take a quick response if an abnormality is detected. Furthermore, if the vehicle 10 is in the non-operation location, it is also possible that there are other imaging devices, such as surveillance cameras and drive recorders installed in other vehicles (not shown). Therefore, by setting a condition based on the location information of the vehicle 10 as a condition for initiating a software update, even if an accident occurs to the vehicle 10 during the software update, the circumstances of the accident can be recorded by other imaging devices.

[0057] In this case, the operation information is information indicating a non-operating location. Based on this operation information, the determination unit 34 determines whether or not the vehicle 10 is in a non-operating location, and if the vehicle 10 is in a non-operating location, it determines that the conditions for starting a software update are met for the drive recorder 11 installed in that vehicle 10. Each drive recorder 11 starts a software update if the vehicle 10 is in a non-operating location.

[0058] This section explains how to determine whether or not vehicle 10 is located in a non-operating area.

[0059] The drive recorder 11 acquires its own location information via a GPS (Global Positioning System) receiver (not shown) and transmits that location information to the operation information acquisition unit 32 of the server device 12. The determination unit 34 of the server device 12 determines whether the vehicle 10 is in a non-operating location based on whether the location indicated by the vehicle 10's location information is in a non-operating location.

[0060] The drive recorder 11 also transmits images of the area around the vehicle 10 captured by the camera 41 to the server device 12. The determination unit 34 of the server device 12 determines whether or not the vehicle 10 is in a non-operating location by comparing the images of the area around the vehicle 10 with images of non-operating locations that it has in its possession, based on known image analysis techniques.

[0061] In this example, the images of the non-operating location scenery that are held in advance may be captured by other cameras, such as security cameras installed in the non-operating location or dashcams in other vehicles. Furthermore, if vehicle 10 is recognized by image analysis of the current image captured by other cameras present in the non-operating location, it may be determined that vehicle 10 is present in the non-operating location.

[0062] ((Conditions based on both the scheduled end time of operation of the drive recorder 11 and the location information of the vehicle 10)) The conditions for initiating a software update may also be that both of the following conditions are met: the scheduled time for the drive recorder 11 to cease operation has elapsed, and the vehicle 10 equipped with the drive recorder 11 is located in the designated location.

[0063] (Instructions for re-updating) The determination unit 34 of the server device 12 determines that an abnormality has occurred in the drive recorder 11, where the progress status has not changed even though the conditions for starting a software update have been met. In this case, the command issuing unit 31 may send a software update command to the drive recorder 11 again. In addition, the command issuing unit 31 may send a software program for updating the managed software to the drive recorder 11 again via the communication unit 21.

[0064] Up to this point, we have described an example in which the vehicle 10 equipped with the drive recorder 11 is a commercial vehicle, but it is not limited to this. The vehicle 10 equipped with the drive recorder 11 may also be a personal vehicle. In this case, the server device 12 is equipped with a driving information acquisition unit instead of the operation information acquisition unit 32. The driving information acquisition unit acquires information (hereinafter referred to as driving information) that allows the user to determine whether the vehicle 10 is driving or not. The driving information includes, for example, the user's schedule for the vehicle 10 instead of the shift schedule in the operation information, and for example, information about the user's home parking lot for the vehicle 10 instead of non-driving locations in the operation information.

[0065] Furthermore, the devices managed by the management system 1 are not limited to the drive recorder 11 installed in the vehicle 10. The management system 1 may also manage various in-vehicle devices such as in-vehicle commercial wireless devices, as well as predetermined software programs installed in the vehicle 10 itself.

[0066] [Supplementary explanation of the embodiment] The embodiments described above are all preferred examples of the present invention. The numerical values, components, arrangement positions and connection configurations of the components, and processing order in the flowcharts shown in the embodiments are examples only and are not intended to limit the present invention. Furthermore, the figures are not necessarily strictly illustrative.

[0067] The series of processes described above can be executed by hardware or by software. When the series of processes are executed by software, the programs that make up the software are installed from a program recording medium onto an information processing device, such as a general-purpose personal computer, which is either a computer built into dedicated hardware or an information processing device capable of performing various functions by installing various programs.

[0068] The program executed by the computer may be a program that processes in chronological order according to the sequence described herein, or it may be a program that processes in parallel or at necessary times, such as when it is called.

[0069] Furthermore, the embodiments of the present invention are not limited to those described above, and various modifications are possible without departing from the spirit of the invention.

[0070] [Note] The contents described in some of the embodiments above can be understood, for example, as follows:

[0071] (1) Management Server The server device 12 described above is A server device 12 for managing the software versions of drive recorders 11 installed in each of several commercial vehicles 10, A command issuing unit 31 (step S11) issues a command for a software update to multiple drive recorders 11 at once, The progress information acquisition unit 33 (step S12) acquires the progress status of the software update for each of the drive recorders 11 in response to the command, A determination unit 34 (steps S13, S14) determines that an abnormality has occurred in the drive recorder 11 if the progress status has not changed even though the conditions for initiating the software update, which is determined based on information indicating the operation of the vehicle 10, have been met, The drive recorder 11 has a display control unit 35 (step S15) that displays that an abnormality has occurred, It is equipped with.

[0072] The determination unit 34 is configured to determine that there is an abnormality if the progress status does not change even though the conditions for initiating a software update, which is determined based on information indicating the operation of the vehicle 10, are met, thus enabling proper management of software updates. For example, even if an update does not start after a software update command is issued, if the conditions for initiating the update are not met, the reason for the update not starting is that the conditions for initiating the update are not met. For example, if an update does not start after a command is issued, one possible response is to resend the command, but drive recorders 11 that do not meet the conditions for initiating the update can be excluded from the resending of the command. Also, since updates are not performed while drive recorders 11 are in operation, updates while drive recorders 11 are in operation can be prevented.

[0073] (2) Conditions based on the scheduled end time of operation The determination unit 34 calculates the scheduled time when the operation of the drive recorder 11 will end, based on the shift schedule showing the operation schedule of the vehicle 10. The condition can be that the aforementioned scheduled time has elapsed (step S13).

[0074] In this way, the conditions for initiating a software update can be determined based on the shift schedule, eliminating the need to obtain information from each drive recorder 11, for example, and making it easy to calculate the scheduled time.

[0075] (3) Conditions based on availability The determination unit 34 calculates the start time of any available time slot on the shift schedule that is longer than a predetermined time as the scheduled time.

[0076] With this configuration, the determination unit 34 can perform a software update if there is a certain amount of free time on the shift schedule.

[0077] (4) Conditions based on the location information of vehicle 10 The determination unit 34, The condition can be that the vehicle 10 is located in a place where it does not operate (step S13).

[0078] In this way, the conditions for initiating a software update can be determined based on the location information of the vehicle 10.

[0079] (5) Judgment based on images of the area around vehicle 10 The determination unit 34 may use the condition that the image of the area surrounding the vehicle 10 is an image of a landscape in a place where the vehicle 10 is not operating.

[0080] In this way, the conditions for initiating a software update can be determined based on images of the area surrounding the vehicle 10.

[0081] (6) Acquisition of images of the area around vehicle 10 Images of scenery in areas where the vehicle 10 is not operating may be captured by the camera 41 of the drive recorder 11 or by another camera.

[0082] This configuration eliminates the need to prepare a dedicated camera to capture images of scenery in areas where the vehicle 10 is not operating, thus making management simpler.

[0083] (7) Instructions for re-updating The command issuing unit 31 may issue the instruction to update again if the progress status has not changed even though the conditions have been met.

[0084] Sometimes, issuing an update command again can resolve the issue, making management easier. [Explanation of Symbols]

[0085] 1 Management System 10 vehicles 11. Dashcam 12 Server devices 21 Communications Department 22 Memory section 23 Control Unit 24 Display section 31. Command Issuance Department 32 Operation information acquisition department 33 Progress Information Acquisition Unit 34 Judgment Department 35 Display Control Unit 41 Camera 42 Communications Department 43 Storage section 44 Control Unit 51 Update Control Unit

Claims

1. A server device for managing the software versions of drive recorders installed in each of multiple commercial vehicles, A command issuing unit that issues a software update command to multiple drive recorders in a batch, A progress information acquisition unit acquires the progress status of the software update for each of the drive recorders in response to the aforementioned command, A determination unit determines that an abnormality has occurred in the drive recorder if the progress status has not changed even though the conditions for initiating the software update, which is determined based on information indicating the operation of the vehicle, have been met. The drive recorder includes a display control unit that displays a message indicating that an abnormality has occurred, A server device characterized by being equipped with the following features.

2. A server device according to claim 1, The determination unit calculates the scheduled time when the operation of the drive recorder will end, based on the shift schedule showing the vehicle's operating schedule. The above condition is that the aforementioned scheduled time has elapsed. A server device characterized by the following features.

3. A server device according to claim 2, The determination unit calculates the start time of any available time on the shift schedule that is longer than a predetermined time as the scheduled time. A server device characterized by the following features.

4. A server device according to claim 1, The determination unit determines that the vehicle is located in a place where it does not operate as a condition. A server device characterized by the following features.

5. A device management method for managing the software versions of drive recorders installed in each of multiple commercial vehicles, A command issuance step for issuing a command for a software update to multiple drive recorders in a single step, A progress information acquisition step to acquire the progress status of the software update for each of the drive recorders in response to the aforementioned command, A determination step in which it is determined that an abnormality has occurred in the drive recorder if the progress status has not changed even though the conditions for initiating the software update, which is determined based on information indicating the operation of the vehicle, have been met, A display control step that indicates that an abnormality has occurred in the aforementioned drive recorder, A device management method characterized by including the following.

Images