MOBILE BODY MANAGEMENT DEVICE, MOBILE BODY CONTROL DEVICE, MOBILE BODY MANAGEMENT SYSTEM, MOBILE BODY MANAGEMENT METHOD, MOBILE BODY CONTROL METHOD, MOBILE BODY MANAGEMENT PROGRAM, AND MOBILE BODY CONTROL PROGRAM

Abstract

To provide a mobile object management device, a mobile object control device, a mobile object management system, a mobile object management method, a mobile object control method, a mobile object management program, and a mobile object control program to prevent influence on other mobile objects in advance when an abnormality occurs in a mobile object.SOLUTION: A vehicle management system 90, which corresponds to a mobile object management system, includes: a vehicle management device 10, which corresponds to a mobile object management device, including a reception unit 11B that receives a detection result of an abnormality occurrence situation at a predetermined timing from parked vehicles corresponding to mobile objects whose movement functions are stopped; and a vehicle control device 20, which corresponds to a mobile object control device, including a detection unit 21A that detects the abnormality occurrence situation when a self vehicle corresponding to the mobile object provided therein is parked and a transmission unit 21B that transmits the detection result by the detection unit 21A to the vehicle management device 10.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates to a mobile object management device, a mobile object control device, a mobile object management system, a mobile object management method, a mobile object control method, a mobile object management program, and a mobile object control program. [Background technology]

[0002] Patent Document 1 proposes an on-board control device that aims to provide an on-board control system that is highly secure in consideration of cyber attacks.

[0003] This on-board control device is a device included in an on-board control system that performs automatic driving of a vehicle, and the on-board control system includes multiple driving control devices for the automatic driving of the vehicle. The on-board control device also includes a normal state unit that switches the operating state of the on-board control system from a normal state to a partial verification state when a cyberattack is detected in some of the multiple driving control devices. Here, the normal state is an operating state in which automatic driving is performed using at least one of the multiple driving control devices. The partial verification state is an operating state in which automatic driving is performed using at least one of the normal driving control devices in which a cyberattack has not been detected, and the security of each driving control device in which a cyberattack has been detected is verified. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2020 / 246031 Summary of the Invention [Problem to be solved by the invention]

[0005] The technology disclosed in Patent Document 1 allows a vehicle having multiple driving control devices to continue driving if some of the multiple driving control devices are normal. However, this technology does not take into consideration vehicles other than the vehicle that has been subjected to a cyber-attack, and therefore has the problem that if the other vehicle is subjected to a similar cyber-attack, it is not possible to avoid the effects of the attack.

[0006] As a result, for example, if self-driving vehicles become more widespread in the future and services using multiple self-driving vehicles are operated, it may become impossible to operate those services in a sound manner.

[0007] The above problems can occur not only in self-driving vehicles but also in ordinary vehicles in general, and even in other mobile objects such as transport robots and drones. Furthermore, the problems can arise not only from cyberattacks but also from various anomalies such as failures of various parts due to some cause or software malfunctions.

[0008] The present disclosure aims to provide a mobile body management device, a mobile body control device, a mobile body management system, a mobile body management method, a mobile body control method, a mobile body management program, and a mobile body control program that can prevent an abnormality in a mobile body from affecting other mobile bodies. [Means for solving the problem]

[0009] In order to achieve the above object, the mobile object management device according to the present invention includes a receiving unit (11B) that receives, at a predetermined timing, from a mobile object whose mobility function is stopped, a detection result of an abnormality occurrence state.

[0010] In addition, the mobile body control device according to the present invention includes a detection unit (21A) that detects the occurrence of an abnormality when the mobile body in which the device is installed is in a state where its mobility function is stopped, and a transmission unit (21B) that transmits the detection result by the detection unit to the mobile body management device.

[0011] In addition, the mobile object management system of the present invention includes a mobile object management device having a receiving unit that receives detection results of an abnormality occurrence status from a mobile object whose mobility function is stopped at a predetermined timing, and a mobile object control device having a detecting unit that detects an abnormality occurrence status when the mobile object in which the mobile object is installed has its mobility function stopped, and a transmitting unit that transmits the detection results by the detecting unit to the mobile object management device.

[0012] Furthermore, the mobile object management method according to the present invention receives, at a predetermined timing, a detection result of an abnormality occurrence state from a mobile object whose mobility function is stopped.

[0013] Furthermore, the mobile object control method according to the present invention detects the occurrence of an abnormality when the mobile object in which the method is installed is in a state where its mobility function is stopped, and transmits the detection result to the mobile object management device.

[0014] In addition, the mobile body management method of the present invention has a mobile body management device that receives detection results of an abnormality occurrence status from a mobile body whose mobility function is stopped at a predetermined timing, and a mobile body control device that detects an abnormality occurrence status when the mobile body in which it is installed has its mobility function stopped, and transmits the detection results to the mobile body management device.

[0015] The mobile object management program according to the present invention also causes a computer to execute a process of receiving, at a predetermined timing, a detection result of an abnormality occurrence state from a mobile object whose mobility function is stopped.

[0016] In addition, the mobile object control program of the present invention causes a computer to execute a process of detecting an abnormality occurring when the mobile object in which it is installed has its mobility function stopped, and transmitting the detection results to a mobile object management device. [Effects of the Invention]

[0017] The mobile body management device, mobile body control device, mobile body management system, mobile body management method, mobile body control method, mobile body management program, and mobile body control program of the present invention make it possible to prevent an abnormality occurring in a mobile body from affecting other mobile bodies. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 2 is a block diagram showing an example of functions of each device constituting the vehicle management system according to the embodiment. [Figure 2] FIG. 2 is a block diagram illustrating an example of functions of a communication device in the vehicle control device according to the embodiment. [Figure 3] 1 is a block diagram illustrating an example of a hardware configuration of a vehicle management device according to an embodiment. [Figure 4] FIG. 2 is a block diagram illustrating an example of a hardware configuration of a communication device according to an embodiment. [Figure 5] 1 is a block diagram showing an example of a functional configuration of a vehicle management system according to an embodiment; [Figure 6] FIG. 2 is a schematic diagram illustrating an example of a configuration of an operation management database according to the embodiment. [Figure 7] 10 is a flowchart illustrating an example of a vehicle management process according to the embodiment. [Figure 8] 10 is a flowchart illustrating an example of instruction timing determination processing according to the embodiment. [Figure 9] 10 is a flowchart illustrating an example of a process for deriving a standard recovery time according to the embodiment. [Figure 10] 10 is a flowchart illustrating an example of a result analysis process according to the embodiment. [Figure 11] 10 is a flowchart illustrating an example of a tampering detection process according to the embodiment. [Figure 12] FIG. 10 is a block diagram illustrating functions of devices constituting a vehicle management system according to another embodiment. [Figure 13] FIG. 10 is a schematic diagram illustrating a process performed by a vehicle management system according to another embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] Hereinafter, with reference to the drawings, an example of an embodiment of the present invention will be described in detail. Here, a case where a cyber-attack is used as an abnormality in the present invention, where various programs executed by an ECU (Electronic Control Unit) are tampered with is described. Also, a case where the present invention is applied to a system (hereinafter referred to as a "vehicle management system") that manages each vehicle of a service company that owns multiple vehicles (corresponding to the mobile bodies of the present invention) and provides services using the multiple vehicles. Examples of the services include a delivery service, a vehicle dispatch service, and a bus operation service, and examples of the service companies include a delivery company, a taxi company, and a bus company.

[0020] First, with reference to FIG. 1, the functions of each device constituting a vehicle management system 90 corresponding to a mobile object management system according to this embodiment will be described.

[0021] As shown in Fig. 1, a vehicle management system 90 according to this embodiment includes a vehicle management device 10, which corresponds to a mobile object management device installed in a predetermined vehicle management center, and a vehicle control device 20, which corresponds to a mobile object control device installed in each of a plurality of vehicles (hereinafter simply referred to as "vehicles") managed by the vehicle management device 10. The vehicle management device 10 and the vehicle control device 20 are mutually accessible via a network 80. Examples of the vehicle management device 10 include general-purpose information processing devices such as personal computers and server computers.

[0022] As shown in FIG. 1, a vehicle control device 10 according to this embodiment is provided with a tampering check instruction timing determination function 10a, a communication function 10b, and a result analysis function 10c.

[0023] The tamper check instruction timing determination function 10a according to this embodiment is a function that executes an instruction timing determination process (to be described later) that determines the timing to instruct each of a plurality of vehicles to be managed to check for tampering in various programs executed by the ECUs 40A to 40X. Note that, hereinafter, when the ECUs 40A to 40X are described without distinguishing between them, they will be collectively referred to as "ECU 40."

[0024] The communication function 10b according to this embodiment is a function that communicates with the plurality of vehicles via the network 80. The communication function 10b according to this embodiment transmits to each vehicle an instruction to check for tampering with the various programs at the timing determined by the tampering check instruction timing determination function 10a, and also receives detection results (described later) transmitted from the vehicle in response to the instruction.

[0025] The result analysis function 10c according to this embodiment is a function that executes a result analysis process, the details of which will be described later, that analyzes the detection results received by the communication function 10b. The tampering check instruction timing decision function 10a according to this embodiment decides the timing to give an instruction to check for tampering, taking into account the analysis results by the result analysis function 10c.

[0026] On the other hand, as shown in Figure 1, the vehicle control device 20 of this embodiment communicates with the vehicle management device 10, and also has a communication device 30 that communicates with multiple ECUs 40 installed in the vehicle in which it is installed.

[0027] Each ECU 40 according to this embodiment is provided with a tampering detection function 40a that detects tampering of the program it executes. In this embodiment, the tampering detection by the tampering detection function 40a is performed by a Secure Boot function that has been conventionally installed in vehicles, but this is not limiting. For example, a dedicated program for detecting tampering of the program may be created and applied.

[0028] Then, the communication device 30 of this embodiment sends an instruction to each ECU 40 to check for tampering using the tampering detection function 40a (hereinafter referred to as a ``tampering confirmation instruction''), receives detection results (hereinafter simply referred to as ``detection results'') of the tampering status by each ECU 40 in response to the tampering confirmation instruction, and transmits the received detection results to the vehicle management device 10.

[0029] Next, functions of the communication device 30 in the vehicle control device 20 according to this embodiment will be described with reference to FIG.

[0030] As shown in Figure 2, the communication device 30 of this embodiment is equipped with an ECU communication unit 36 ​​that communicates with the ECU 40 and a wireless communication unit 38 that communicates wirelessly with the vehicle management device 10 via the network 80, as will be described below.

[0031] As shown in FIG. 2, the communication device 30 according to this embodiment is provided with a tampering check instruction function 30a, a tampering result reporting function 30b, a receiving function 30c, and a transmitting function 30d.

[0032] The tampering check instruction function 30a according to this embodiment is a function that transmits the above-mentioned tampering check instruction to the ECU 40 via the ECU communication unit 36 ​​at the timing when the ECU 40 receives an instruction to check for tampering from the vehicle management device 10. When the ECU 40 receives this tampering check instruction, the ECU 40 detects whether or not tampering has occurred using the tampering detection function 40a provided therein, as described above, and transmits the detection result to the tampering result reporting function 30b via the ECU communication unit 36.

[0033] The falsification result reporting function 30b according to this embodiment is a function that transmits the received detection results to the vehicle management device 10 via the wireless communication unit 38. As described above, the vehicle management device 10 uses the detection results transmitted by the falsification result reporting function 30b to execute the result analysis process using the result analysis function 10c.

[0034] On the other hand, the receiving function 30c according to this embodiment receives various normal instructions from the vehicle management device 10 to the ECU 40 via the wireless communication unit 38, and transmits the received instructions to the ECU 40 via the ECU communication unit 36. Upon receiving the instructions, the ECU 40 executes processing according to the received instructions and transmits the execution results to the transmitting function 30d via the ECU communication unit 36.

[0035] The transmission function 30d according to this embodiment is a function that transmits the execution result received via the ECU communication unit 36 ​​to the vehicle management device 10 via the wireless communication unit 38.

[0036] That is, the receiving function 30c and the transmitting function 30d according to this embodiment are functions (hereinafter referred to as "existing functions") that have been previously provided in the communication device 30. In contrast, the tampering check instruction function 30a and the tampering result reporting function 30b according to this embodiment are functions (hereinafter referred to as "new functions") that have been newly provided in order to realize the present invention. In the communication device 30 according to this embodiment, the existing functions are normally applied, and the new functions are applied when the tampering is to be checked.

[0037] For this reason, in the communication device 30 according to this embodiment, the programs for realizing new functions are stored in a non-rewritable storage area in the storage unit 33, which will be described later, while the programs for realizing existing functions are stored in a rewritable storage area in the storage unit 33. This configuration makes it possible to update existing functions as needed, while significantly reducing the possibility of tampering with new functions.

[0038] Next, the hardware configuration of the vehicle control device 10 according to this embodiment will be described with reference to FIG.

[0039] The vehicle management device 10 according to this embodiment includes a CPU (Central Processing Unit) 11, a memory 12 as a temporary storage area, a non-volatile storage unit 13, an input unit 14 such as a keyboard and mouse, a display unit 15 such as an LCD display, a medium read / write device (R / W) 16, and a communication interface (I / F) unit 18. The CPU 11, memory 12, storage unit 13, input unit 14, display unit 15, medium read / write device 16, and communication I / F unit 18 are connected to one another via a bus B1. The medium read / write device 16 reads information written in a recording medium 17 and writes information to the recording medium 17.

[0040] The storage unit 13 is realized by an HDD (Hard Disk Drive), an SSD (Solid State Drive), a flash memory, or the like. A vehicle management program 13A and a result analysis program 13B, which correspond to a mobile object management program, are stored in the storage unit 13 as a storage medium. The vehicle management program 13A and the result analysis program 13B are stored (installed) in the storage unit 13 by setting a recording medium 17, on which the programs are written, in the medium reading and writing device 16, and the medium reading and writing device 16 reading the programs from the recording medium 17. The CPU 11 reads the vehicle management program 13A and the result analysis program 13B from the storage unit 13 as appropriate, expands them in the memory 12, and sequentially executes the processes of each program.

[0041] Furthermore, a vehicle operation management database 13C is stored in the storage unit 13. The vehicle operation management database 13C will be described in detail later.

[0042] Next, the hardware configuration of the communication device 30 according to this embodiment will be described with reference to FIG.

[0043] The communication device 30 according to this embodiment includes a CPU 31, a memory 32 as a temporary storage area, a non-volatile storage unit 33, the above-mentioned ECU communication unit 36, and a wireless communication unit 38. The CPU 31, the memory 32, the storage unit 33, the ECU communication unit 36, and the wireless communication unit 38 are connected to one another via a bus B2.

[0044] The storage unit 33 is realized by an HDD, an SSD, a flash memory, or the like. The storage unit 33 serving as a storage medium stores a tampering detection program 33A, which corresponds to the mobile object control program of the present invention. As described above, the storage unit 33 according to this embodiment has a rewritable storage area and a non-rewritable storage area, and the tampering detection program 33A is stored (installed) in the non-rewritable storage area of ​​the storage unit 33 when the communication device 30 is manufactured. The CPU 31 reads the tampering detection program 33A from the storage unit 33 as needed, expands it into the memory 32, and sequentially executes the processes of the tampering detection program 33A.

[0045] Next, the functional configuration of each device included in the vehicle management system 90 according to this embodiment will be described with reference to FIG.

[0046] 5, the vehicle management device 10 according to this embodiment includes an instruction unit 11A and a receiving unit 11B. The CPU 11 of the vehicle management device 10 executes the vehicle management program 13A and the result analysis program 13B, thereby functioning as the instruction unit 11A and the receiving unit 11B.

[0047] On the other hand, the vehicle control device 20 according to this embodiment includes a detection unit 21A and a transmission unit 21B. The CPU 31 of the communication device 30 provided in the vehicle control device 20 executes a tampering detection program 33A, thereby functioning as the detection unit 21A and the transmission unit 21B.

[0048] The instruction unit 11A according to this embodiment instructs the vehicle control device 20 to transmit the above-mentioned detection result at a predetermined timing. In this embodiment, as described above, the timing determined by the tampering check instruction timing determination function 10a is used as the above-mentioned predetermined timing. Also, in this embodiment, as described above, the instruction to transmit the above-mentioned detection result is used as the instruction to check for tampering.

[0049] In contrast, the detection unit 21A according to this embodiment detects the occurrence of an abnormality (in this embodiment, the above-mentioned tampering) when the vehicle is parked and receives an instruction to transmit the above-mentioned detection result. Then, the transmission unit 21B according to this embodiment transmits the detection result by the detection unit 21A to the vehicle management device 10. Note that "parked" here means a vehicle that is stopped and whose own control device (in this embodiment, the part of the vehicle control device 20 excluding the communication device 30) is stopped (including a sleep state).

[0050] In contrast to this, the receiving unit 11B according to this embodiment receives the above detection results from the parked vehicle.

[0051] Here, when the detection result received by the receiving unit 11B indicates that an abnormality has occurred, the instruction unit 11A in this embodiment instructs a vehicle (hereinafter referred to as an "associated vehicle") related to the vehicle that sent the detection result (hereinafter referred to as the "sending vehicle") to detect the occurrence of the abnormality.

[0052] In this embodiment, the relevant vehicles are those vehicles managed by the vehicle management system 90, excluding the source vehicle, that are owned by the service company that owns the source vehicle (hereinafter referred to as "first relevant vehicles"). In addition, in this embodiment, the relevant vehicles are those vehicles managed by the vehicle management system 90, excluding the source vehicle, that are equipped with the same model ECU 40 as the source vehicle (hereinafter referred to as "second relevant vehicles"). Furthermore, in this embodiment, the relevant vehicles are those vehicles managed by the vehicle management system 90, excluding the source vehicle, that are located in the area where the source vehicle is parked (hereinafter referred to as "third relevant vehicles"). However, the relevant vehicles are not limited to the first to third relevant vehicles. For example, all vehicles managed by the vehicle management system 90, excluding the source vehicle, may be used as relevant vehicles, or vehicles of the same model as the source vehicle may be used as relevant vehicles.

[0053] In this embodiment, the detection result includes detection information (information identifying the ECU 40 that executes the program in which tampering was detected) required to detect the location of the abnormality when an abnormality occurs. Therefore, by referring to the detection information received from the vehicle control device 20, the vehicle management device 10 can identify the location of the tampering when tampering occurs.

[0054] Furthermore, if there is no response from a vehicle (hereinafter referred to as the "instructed vehicle") that has responded to the instruction by the instruction unit 11A for a predetermined period of time or longer, the instruction unit 11A further instructs vehicles on the same system (hereinafter referred to as the "same system vehicle") to detect the occurrence of the above-mentioned abnormality.

[0055] In this embodiment, the same-line vehicles are defined as vehicles that are managed by the vehicle management system 90, excluding the designated vehicle, and that are equipped with an ECU 40 of the same model as the designated vehicle. However, the same-line vehicles are not limited to the designated vehicle. For example, the same-line vehicles may be defined as vehicles that are managed by the vehicle management system 90 and are the same model as the designated vehicle.

[0056] Next, the operation management database 13C according to this embodiment will be described with reference to FIG.

[0057] As shown in FIG. 6, the operation management database 13C according to this embodiment stores information such as company ID (Identification), day of the week, vehicle ID, and operation schedule.

[0058] The company ID is information that is assigned in advance as a unique ID for each service company in order to identify each of the above-mentioned service companies. The day of the week is information that indicates the day of the week itself, and the vehicle ID is information that is assigned in advance as a unique ID for each vehicle in order to individually identify each vehicle that is managed by the vehicle management system 90. The operation schedule is information that indicates the operation schedule of the corresponding vehicle on the corresponding day of the week at the corresponding service company, and stores information such as the start time of use, the parking time (parking lot), the resumption time of use, the parking time (parking lot), etc.

[0059] In the example shown in Fig. 6, for example, a vehicle with a vehicle ID of "C01" owned by a service company with a company ID of "U01" is stored to start use (operation) at 7:00 a.m. on Monday, be used until 11:45 a.m., and then be parked in parking lot A. In the example shown in Fig. 6, it is also stored that the vehicle will resume use at 1:00 p.m., be used until 8:00 p.m., and then be parked in parking lot B.

[0060] Although not shown in the figures, the memory unit 13 of the vehicle management device 10 according to this embodiment also contains, in addition to the operation management database 13C, a recovery worker database that indicates the locations (hereinafter referred to as "locations") of multiple workers (hereinafter referred to as "recovery workers") who recover tampered programs. Also, although not shown in the figures, the memory unit 13 of the vehicle management device 10 according to this embodiment also contains a recovery time database that stores, for each type of program, the time required to recover a tampered program (in this embodiment, the time required for the process of writing (updating) the program, hereinafter referred to as "write processing time"). Furthermore, the memory unit 13 also contains various databases other than the above-mentioned databases, as will be described later, but their description will be omitted.

[0061] Next, the operation of the vehicle management system 90 according to this embodiment will be described with reference to Figures 7 to 11. To avoid confusion, the following description will be given of a case where the various databases described above are constructed. The following description will also be given of a case where the location of the recovery worker is updated as needed in the recovery worker database, and the program write processing time is updated as needed to match the latest program write processing time in the recovery time database.

[0062] First, referring to Figures 7 to 9, the operation of the vehicle management device 10 according to this embodiment when the vehicle management process is executed will be described. The vehicle management process shown in Figure 7 is executed by the CPU 11 of the vehicle management device 10 executing the vehicle management program 13A. The vehicle management process shown in Figure 7 is started, for example, when a predetermined date and time arrives at which vehicle management by the vehicle management system 90 will start (6:00 AM on a weekday in this embodiment).

[0063] In this embodiment, the execution start date and time of the vehicle management process is set to 6:00 AM on a weekday, assuming that tampering may occur late at night after the service company closes. That is, in the vehicle management system 90 according to this embodiment, the business start time of each service company is assumed to be 7:00 AM on a weekday, and even if tampering occurs late at night, 6:00 AM is set as a time with a sufficient margin so that recovery can be completed by 7:00 AM on the same day. However, this is not limited to this embodiment. For example, the vehicle management process according to this embodiment may be executed continuously, or may be set to a time that is earlier than the business start time by at least the standard recovery time derived by the standard recovery time derivation process described below.

[0064] 7, the CPU 11 executes a command timing determination process configured as a subroutine program of the vehicle management program 13A for any vehicle (hereinafter referred to as a "target parked vehicle") that is currently parked among the vehicles (hereinafter referred to as a "managed vehicle") that are managed by the vehicle management system 90. The command timing determination process according to this embodiment will be described below with reference to FIG.

[0065] In this embodiment, whether a vehicle is parked is determined by referring to the operation management database 13C and determining whether the current time is a parking time zone, but the present invention is not limited to this. For example, all managed vehicles may be equipped with a positioning system such as a GPS (Global Positioning System), and whether a vehicle is parked may be determined by determining whether the position identified by the positioning system is in a parking lot. Also, for example, a vehicle may be inquired as to whether it is parked, and whether the vehicle is parked may be determined based on the response.

[0066] In step 130 of Fig. 8, the CPU 11 executes a standard recovery time derivation process configured as a subroutine program of the instruction timing determination process for the target parked vehicle. Hereinafter, the standard recovery time derivation process according to this embodiment will be described with reference to Fig. 9.

[0067] 9, the CPU 11 identifies the location where the target parked vehicle is parked (in this embodiment, the parking lot) by referring to the operation management database 13C, and identifies the location of the nearest recovery worker to the identified target parked vehicle location by referring to the recovery worker database. Then, using the identified target parked vehicle location and the identified recovery worker location, the CPU 11 derives the travel time T11 required for the recovery worker to arrive at the target parked vehicle location.

[0068] In step 152, the CPU 11 reads out the write processing time T12 of the program targeted by the ECU 40 installed in the target parked vehicle from the recovery time database. In step 154, the CPU 11 refers to the operation management database 13C to identify the number N of vehicles parked in the same parking lot as the target parked vehicle (hereinafter referred to as the "number of vehicles owned").

[0069] In step 156, the CPU 11 calculates the standard recovery time TS by substituting the travel time T11, write processing time T12, and number of owned vehicles N obtained by the above processing into the following formula (1), and then terminates this standard recovery time derivation processing. Note that the standard recovery time TS derived by the standard recovery time derivation processing represents the expected time required to restore all managed vehicles parked in the parking lot where the target parked vehicle is parked, if the above tampering is detected in the target parked vehicle.

[0070] TS=T11+T12×N (1)

[0071] When the standard recovery time derivation process is completed, the process proceeds to step 132 of the instruction timing determination process shown in FIG.

[0072] 8, the CPU 11 reads the most recent use resumption time RT of the target parked vehicle from the operation management database 13C. Then, the CPU 11 calculates the final instruction timing LCT by substituting the read use resumption time RT and the standard recovery time TS obtained by the standard recovery time derivation process into the following equation (2). Note that the final instruction timing LCT calculated here represents the timing of the final tampering confirmation instruction when the above-mentioned tampering is detected in the target parked vehicle, so that all managed vehicles parked in the parking lot where the target parked vehicle is parked can be recovered in time for the target parked vehicle to resume operation.

[0073] LCT=RT-TS (2)

[0074] In order to avoid confusion, formula (2) assumes the detection of tampering from the completion of operation of the target parked vehicle to the resumption of operation during the service company's business hours, but is not limited to this. For example, it may be configured to assume the detection of tampering from the end of business hours of the service company to the start of business hours the next day. In this case, the final instruction timing LCT is calculated using the following formula.

[0075] LCT=Use start time-TS

[0076] In step 134, the CPU 11 calculates time T1 by substituting the time at this point in time (hereinafter referred to as the "current time") CT and the final command timing LCT into the following equation (3). Note that the time T1 calculated here is the time from the current time CT to the final command timing LCT if the final command timing LCT is after the current time CT, and is the time going back from the current time CT to the final command timing LCT if the final command timing LCT is before the current time CT. If the final command timing LCT is equal to the current time CT, time T1 is 0 (zero).

[0077] T1=CT-LCT (3)

[0078] In step 136, the CPU 11 determines whether the time T1 is longer than a predetermined period (in this embodiment, 10 minutes, hereinafter referred to as the "instruction period") for instructing tampering detection, and if the determination is negative, the process proceeds to step 138. In step 138, the CPU 11 sets the final instruction timing LCT as the next instruction timing, and then ends this instruction timing determination process.

[0079] In this embodiment, as described above, the detection of tampering from the end of operation of the target parked vehicle to the resumption of operation during the service company's business hours is assumed, so the instruction period is set to 10 minutes, but this is not limited to this. For example, as described above, if the detection of tampering from the end of business hours of the service company to the start of business the next day is assumed, the instruction period may be set to 24 hours. This allows tampering to be checked once a day even if the target parked vehicle is not used for several days.

[0080] On the other hand, if the judgment in step 136 is positive, that is, if the time T1 exceeds the instruction period, the process proceeds to step 140, and the CPU 11 sets the next instruction timing to the current time CT plus the instruction period, and then terminates this instruction timing determination process.

[0081] When the instruction timing determination process is completed, the process proceeds to step 102 of the vehicle management process (main routine) shown in FIG.

[0082] In step 102 of FIG. 7, the CPU 11 determines whether the target parked vehicle is a vehicle subject to emergency confirmation obtained by a result analysis process described in detail below, and if the determination is negative, the CPU 11 proceeds to step 106, whereas if the determination is positive, the CPU 11 proceeds to step 104.

[0083] In step 104, the CPU 11 determines whether or not there is a vehicle (hereinafter referred to as the "instruction target vehicle") that corresponds to the next instruction timing derived by the instruction timing determination process, and if the determination is negative, the process proceeds to step 110, whereas if the determination is positive, the process proceeds to step 106. In step 106, the CPU 11 transmits an instruction to the instruction target vehicle to confirm the above-mentioned tampering.

[0084] In step 108, CPU 11 executes the instruction timing determination process described above, similarly to step 100. In step 110, CPU 11 determines whether a predetermined end timing for ending this vehicle management process has arrived, and if the determination is negative, the process returns to step 102, whereas if the determination is positive, the vehicle management process is ended. Note that in this embodiment, the end timing is a predetermined date and time (in this embodiment, 10:00 p.m. on a weekday) at which management of managed vehicles by the vehicle management system 90 is to end, but it goes without saying that the end timing is not limited to this.

[0085] Next, the operation of the vehicle management device 10 according to this embodiment when a result analysis process is executed will be described with reference to Fig. 10. The CPU 11 of the vehicle management device 10 executes the result analysis program 13B to execute the result analysis process shown in Fig. 10. The result analysis process shown in Fig. 10 is executed after an instruction to check for tampering is sent by the vehicle management process described above.

[0086] 10, the CPU 11 determines whether information indicating a response to the instruction to check for tampering transmitted by the vehicle management process (corresponding to "response information" to be described later) has been received within a predetermined period (10 seconds in this embodiment), and if the determination is affirmative, the process proceeds to step 208. On the other hand, if the determination is negative in step 200, i.e., if the response information has not been received within the predetermined period, the process proceeds to step 202.

[0087] In step 202, the CPU 11 adds several (five in this embodiment) of the managed vehicles that are equipped with the same model of ECU 40 as the ECU 40 installed in the target vehicle to the above-mentioned list of vehicles to be checked urgently. Note that in this embodiment, the managed vehicles that are equipped with the same model of ECU 40 are identified using a database that is constructed in advance to register information indicating the relationship between the managed vehicles and the models of the ECU 40 installed in the managed vehicles, but it goes without saying that the present invention is not limited to this.

[0088] In step 204, the CPU 11 determines whether the number of vehicles that have not received a response from vehicles equipped with the same model of ECU 40 within the predetermined period is less than a certain number (three in this embodiment), and if the determination is positive, the CPU 11 proceeds to step 208, whereas if the determination is negative, the CPU 11 proceeds to step 206.

[0089] In step 206, the CPU 11 adds all managed vehicles equipped with the ECU 40 of the same model to the list of vehicles to be urgently checked, and then proceeds to step 208.

[0090] In step 208, the CPU 11 determines whether it has received, as information indicating the detection result, information indicating that the tampering has been detected (hereinafter referred to as "detection result information"), or whether it has not received response information within the predetermined period. Hereinafter, a vehicle that has transmitted detection result information and a vehicle that has not transmitted response information within the predetermined period are referred to as an "abnormal vehicle." If the determination is negative, the result analysis process is terminated, whereas if the determination is positive, the process proceeds to step 210.

[0091] In step 210, the CPU 11 determines whether the number of abnormal vehicles to date from the same service company as the vehicle being instructed is less than a certain number (10 in this embodiment), and if the determination is positive, the CPU 11 proceeds to step 214, whereas if the determination is negative, the CPU 11 proceeds to step 212.

[0092] In step 212, the CPU 11 adds all vehicles of the service company that owns the vehicle to be instructed to the list of vehicles to be checked urgently, and then proceeds to step 214. In this embodiment, the vehicles of the same service company are identified by referring to the operation management database 13C, but it goes without saying that this is not limited to this.

[0093] In step 214, the CPU 11 determines whether the number of abnormal vehicles equipped with the same model ECU 40 as the target vehicle that have been detected up to that point is less than a certain number (10 in this embodiment), and if the determination is positive, the CPU 11 proceeds to step 218, whereas if the determination is negative, the CPU 11 proceeds to step 216.

[0094] In step 216, the CPU 11 adds all managed vehicles equipped with the ECU 40 of the same model as the ECU 40 that executes the program in which the tampering was detected to the list of vehicles to be urgently checked, and then proceeds to step 218.

[0095] In step 218, the CPU 11 determines whether the number of abnormal vehicles existing in the same district as the target vehicle up to that point is less than a certain number (five in this embodiment), and if the determination is affirmative, the result analysis process is terminated, whereas if the determination is negative, the process proceeds to step 220. Here, a district where the number of abnormal vehicles is equal to or greater than a certain number is referred to as a "target district." Note that, in this embodiment, abnormal vehicles existing in the target district are identified by referring to the traffic management database 13C, but it goes without saying that the method is not limited to this.

[0096] In step 220, the CPU 11 adds all managed vehicles present in the target area to the list of vehicles to be checked urgently, and then ends the result analysis process.

[0097] The vehicles added to the emergency check targets by the processing of steps 202 and 206 of this result analysis process correspond to the same route vehicles described above. Also, the vehicles added to the emergency check targets by the processing of step 212 correspond to the first related vehicles, the vehicles added to the emergency check targets by the processing of step 216 correspond to the second related vehicles, and the vehicles added to the emergency check targets by the processing of step 218 correspond to the third related vehicles.

[0098] Next, the operation of the vehicle control device 20 according to this embodiment when the vehicle control device 20 executes the tampering detection process will be described with reference to Fig. 11. The tampering detection process shown in Fig. 11 is executed by the CPU 31 of the communication device 30 provided in the vehicle control device 20 executing the tampering detection program 33A. The tampering detection process shown in Fig. 11 is executed at predetermined timing (in this embodiment, at predetermined intervals (for example, 10 seconds)).

[0099] In step 300 of FIG. 11, the CPU 31 determines whether or not it has received an instruction to confirm the above-mentioned tampering from the vehicle management device 10. If the determination is negative, the tampering detection process is terminated, whereas if the determination is positive, the CPU 31 proceeds to step 302.

[0100] In step 302, the CPU 31 transmits response information to the vehicle management device 10 in response to the receipt of the instruction to check for tampering, and in step 304, the CPU 31 causes each unit of the vehicle control device 20 in which the CPU 31 is mounted to return from the sleep state. During this process of returning from the sleep state, each of the ECUs 40 activates the tampering detection function 40a, which detects tampering of the program it executes, by the secure boot function described above.

[0101] Therefore, in step 306, the CPU 31 determines whether tampering has been detected by the tampering detection function 40a in at least one ECU 40, and if the determination is negative, the CPU 31 proceeds to step 310, whereas if the determination is positive, the CPU 31 proceeds to step 308.

[0102] In step 308, the CPU 31 transmits detection result information indicating that tampering has been detected to the vehicle management device 10 together with information (corresponding to the detection information described above) that can identify the ECU 40 that executes the program in which tampering has been detected. In step 310, the CPU 31 transitions each unit of the vehicle control device 20 to a sleep state, and then terminates this tampering detection process.

[0103] As described above, in the vehicle control device 20 according to this embodiment, each of the ECUs 40 is started from a sleep state in response to an instruction from the communication device 30, and therefore the communication device 30 and the ECU 40 are provided with a mechanism for this purpose. However, this is not limiting, and even if the communication device 30 is in a sleep state, the communication device 30 may be started from a remote location. According to this embodiment, even if the entire vehicle control device 20 is in a sleep state, the ECU 40 can be started from a sleep state from a remote location.

[0104] As described above, the vehicle management device 10 according to this embodiment receives the detection result of the occurrence of an abnormality from a parked vehicle at a predetermined timing. Therefore, by using the received detection result, it is possible to prevent an abnormality occurring in a vehicle from affecting other vehicles.

[0105] Furthermore, according to the vehicle management device 10 of this embodiment, if the received detection result indicates that an abnormality has occurred, the vehicle related to the vehicle is instructed to detect the occurrence of the abnormality. Therefore, if an abnormality occurs in a vehicle, it is possible to more reliably prevent the influence on other vehicles.

[0106] Furthermore, according to the vehicle management device 10 of this embodiment, the detection result includes detection information required to detect the location of the abnormality when the abnormality occurs, so that it is possible to prevent the location of the abnormality from affecting other vehicles.

[0107] Furthermore, the vehicle management device 10 according to this embodiment issues an instruction to transmit the detection results at a predetermined timing, and if there is no response from the vehicle in response to the instruction for a predetermined period of time, it further issues an instruction to vehicles on the same system to detect the occurrence of the abnormality. Therefore, it is possible to detect the occurrence of an abnormality according to the response state to the instruction to transmit the detection results.

[0108] Furthermore, the vehicle control device 20 according to this embodiment detects whether an abnormality has occurred when the vehicle is parked, and transmits the detection result to the vehicle management device 10. Therefore, by using the detection result received by the vehicle management device 10, it is possible to prevent an abnormality occurring in a vehicle from affecting other vehicles.

[0109] Furthermore, according to the vehicle control device 20 of this embodiment, when an abnormality occurs, the detection is performed by including the detection information required to detect the location of the abnormality. Therefore, by using the detection information received by the vehicle management device 10, it is possible to prevent the location of the abnormality from affecting other vehicles.

[0110] Although the above embodiment does not refer to a vehicle that performs domain control, the present invention can also be applied to a vehicle that performs domain control, as shown in Fig. 12 as an example. In Fig. 12, the same components as those shown in Fig. 1 are assigned the same reference numerals as in Fig. 1. Also, to avoid confusion, Fig. 12 illustrates only the vehicle control device 20 of one vehicle, but in reality, the present invention is applicable to vehicle control devices 20 of multiple vehicles.

[0111] 12, in this embodiment, the ECUs 40 are classified into a plurality of groups, and domain control units 50A to 50X are provided for each group. In the following description, when the domain control units 50A to 50X are not to be distinguished from one another, they will be collectively referred to as "domain control unit 50."

[0112] Each domain control unit 50 is provided with a tampering detection function 50a, a tampering investigation instruction function 50b, and a tampering reporting function 50c.

[0113] The tampering detection function 50a according to this embodiment is a function that comprehensively controls the detection of tampering of programs executed by ECUs 40 included in the corresponding group in cooperation with the tampering investigation instruction function 50b and the tampering reporting function 50c.

[0114] Furthermore, the tampering investigation instruction function 50b according to this embodiment is a function that sequentially transmits the above-mentioned tampering confirmation instruction to the ECUs 40 of the corresponding group at the timing when the instruction to check for tampering is received from the vehicle management device 10. When this tampering confirmation instruction is received, the ECU 40 detects whether or not tampering has occurred using the tampering detection function 40a provided therein, as described above, and transmits the detection result to the tampering reporting function 50c.

[0115] The tampering reporting function 50c according to this embodiment is a function that transmits the detection results sequentially received from the ECUs 40 of the corresponding group to the tampering result reporting function 30b of the communication device 30. The tampering result reporting function 30b transmits the received detection results to the vehicle management device 10.

[0116] In this embodiment as well, the present invention can be realized by substantially the same processing as in the above embodiment.

[0117] In this embodiment, as shown in Fig. 13 as an example, the domain control unit 50, the ECU 40, and the various sensors 60 connected to the ECU 40 are arranged in this order in a hierarchical structure. Therefore, as shown in Fig. 13 as an example, points may be set for each layer, and when the total value of points corresponding to the locations where abnormalities have occurred exceeds a predetermined threshold, an instruction to check for tampering may be transmitted to the related vehicles and vehicles of the same system.

[0118] In the above embodiment, the abnormality of the present invention is described as being caused by program tampering, but the present invention is not limited to this. For example, the abnormality of the present invention may be caused by a malfunction of the engine, brakes, lights, or the like.

[0119] In the above embodiment, the vehicle control device 20 detects an abnormality in response to an instruction from the vehicle management device 10, but the present invention is not limited to this. For example, the vehicle control device 20 may detect an abnormality by itself when the vehicle is parked.

[0120] In the above embodiment, the vehicle management device 10 transmits the instruction to check for tampering at the timing determined by the instruction timing determination process, but the present invention is not limited to this. For example, the instruction to check for tampering may be transmitted at predetermined intervals or at random times within a predetermined period.

[0121] In the above embodiment, when tampering is detected in one vehicle, the system instructs related vehicles and vehicles in the same line to check for tampering. However, the present invention is not limited to this. For example, when tampering is detected in a predetermined number of vehicles or more, the system instructs related vehicles and vehicles in the same line to check for tampering.

[0122] Furthermore, in the above embodiment, the process of instructing all corresponding vehicles to check for tampering does not necessarily have to target all of the vehicles, but may target only some of the vehicles.

[0123] In the above embodiment, the case where the instruction unit 11A and the receiving unit 11B are provided in the vehicle management device 10, and the detection unit 21A and the transmission unit 21B are provided in the vehicle control device 20 has been described, but this is not limiting. For example, each of these units may be provided in either the vehicle management device 10 or the vehicle control device 20, as long as the corresponding function can be executed.

[0124] In the above embodiment, a vehicle is used as the moving body of the present invention, but the present invention is not limited to this. For example, other moving bodies such as a transport robot and a drone may be used as the moving body of the present invention.

[0125] The controller and methods described herein may be implemented by a special-purpose computer having a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the apparatus and methods described herein may be implemented by a special-purpose computer having a processor configured with dedicated hardware logic circuitry. Alternatively, the apparatus and methods described herein may be implemented by one or more special-purpose computers configured by a combination of a processor executing a computer program and one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory storage medium. [Explanation of symbols]

[0126] 10 vehicle management device, 10a tampering confirmation instruction timing determination function, 10b communication function, 10c result analysis function, 11 CPU, 11A instruction unit, 11B receiving unit, 13 Memory unit, 13A Vehicle management program, 13B Result analysis program, 13C operation management database, 14 input unit, 15 display unit, 18 communication I / F unit, 20 vehicle control device, 21A detection unit, 21B transmission unit, 30 communication device, 30a Tampering confirmation instruction function, 30b Tampering result report function, 30c Receiving function, 30d transmission function, 31 CPU, 32 memory, 33 storage unit, 33A tamper detection program, 36 ECU communication unit, 38 wireless communication unit, 40 ECU, 40a Tampering detection function, 50 domain control unit, 50a Tampering detection function, 50b Tampering investigation instruction function, 50c Tampering report function, 60 Sensor, 90 Management system

Claims

1. a receiving unit (11B) that receives a detection result of an abnormality occurrence state from a moving body whose movement function is stopped at a predetermined timing; an instruction unit (11A) that, when the detection result received by the receiving unit indicates that an abnormality has occurred, instructs a moving body related to the moving body to detect the occurrence of the abnormality; the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobile management device.

2. The detection result includes detection information required to detect the location of the abnormality when the abnormality occurs. The mobile object management device according to claim 1 .

3. the instruction unit instructs transmission of the detection result at the predetermined timing. The mobile object management device according to claim 1 .

4. When there is no response from the mobile object in response to the instruction by the instruction unit for a predetermined period of time or longer, the instruction unit further instructs the mobile object of the same system to detect the occurrence of the abnormality. The mobile object management device according to claim 3 .

5. a detection unit (21A) that detects the occurrence of an abnormality when the mobile unit in which it is installed is in a state of mobile function outage and when the detection of the occurrence of an abnormality is instructed by the mobile unit management device as a mobile unit related to the mobile unit in which an abnormality has occurred; a transmission unit (21B) that transmits the detection result by the detection unit to the mobile object management device at a predetermined timing, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobile control device.

6. the detection unit performs the detection by assuming that the detection information includes detection information required to detect a location where the abnormality has occurred when the abnormality has occurred. The mobile object control device according to claim 5 .

7. a mobile object management device including: a receiving unit that receives a detection result of an abnormality occurrence state from a mobile object whose mobility function is stopped at a predetermined timing; and an instruction unit that instructs a mobile object related to the mobile object to detect the abnormality occurrence state when the detection result received by the receiving unit indicates that an abnormality has occurred; a mobile body control device including a detection unit that detects an abnormality occurrence status when the mobile body in which the mobile body control device is installed is out of mobility function and when the mobile body control device is instructed by a mobile body management device to detect an abnormality occurrence status as a mobile body related to an abnormality-occurring mobile body, and a transmission unit that transmits the detection result by the detection unit to the mobile body management device, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobile management system.

8. Receives a detection result of an abnormality occurrence state from a mobile object whose mobility function is stopped at a predetermined timing, A mobile object management method, wherein, when the received detection result indicates that an abnormality has occurred, a computer executes a process of instructing a mobile object related to the mobile object to detect an occurrence status of the abnormality, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobile object management method.

9. When the mobile unit in which the mobile unit is installed is out of service, or when the mobile unit is instructed by the mobile unit management device to detect the occurrence of an abnormality as a mobile unit related to the mobile unit in which an abnormality has occurred, the mobile unit detects the occurrence of an abnormality; A mobile object control method in which a computer executes a process of transmitting a detection result to the mobile object management device at a predetermined timing, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; A mobile object control method.

10. the mobile object management device receives a detection result of an abnormality occurrence status from a mobile object whose mobility function is stopped at a predetermined timing, and when the received detection result indicates that an abnormality has occurred, instructs a mobile object related to the mobile object to detect the abnormality occurrence status; A mobile object management method, in which a mobile object control device detects an abnormality occurrence status when a mobile object in which the mobile object control device is installed is out of mobility function and when the mobile object control device is instructed by a mobile object management device to detect an abnormality occurrence status as a mobile object related to a mobile object in which an abnormality has occurred, and transmits the detection result to the mobile object management device, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobile object management method.

11. Receives a detection result of an abnormality occurrence state from a mobile object whose mobility function is stopped at a predetermined timing, a mobile object management program for causing a computer to execute a process including, when the received detection result indicates that an abnormality has occurred, instructing a mobile object related to the mobile object to detect a state in which the abnormality has occurred, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobility management program.

12. When the mobile unit in which the mobile unit is installed is out of service, or when the mobile unit is instructed by the mobile unit management device to detect the occurrence of an abnormality as a mobile unit related to the mobile unit in which an abnormality has occurred, the mobile unit detects the occurrence of an abnormality; A mobile object control program for causing a computer to execute a process of transmitting a detection result to the mobile object management device at a predetermined timing, the moving body is a vehicle, the mobile object related to the mobile object is a service company that provides services using a plurality of the vehicles, and includes at least one of a vehicle owned by the service company that owns the vehicle in which the abnormality occurred and a vehicle located in the area where the vehicle in which the abnormality occurred is parked; the predetermined timing is determined using a standard recovery time, which is an expected time required for recovery of the mobile body; Mobile control program.

Images