Vehicle management device, vehicle management system, vehicle management method, and program

Abstract

To check a report early.SOLUTION: A vehicle management device (vehicle management server 30) includes: a log update unit 110 configured to cause a log holding unit 130 to hold a log related to the operation of a vehicle 10 received from a vehicle terminal 20; a state derivation unit 112 configured to read the log and derive a vehicle state based on the log; an event update unit 114 configured to generate an event based on a change in the derived vehicle state and cause an event holding unit 138 to hold it; and a report generation unit 116 configured to read the event and generate a report related to an operation state of the vehicle 10 based on the event.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a vehicle management device, a vehicle management system, a vehicle management method, and a program for managing vehicles.

Background Art

[0002] Techniques for automatically recording the operating states of vehicles engaged in transportation, such as taxis and trucks, are known. For example, Patent Document 1 discloses a technique for transferring operation data accumulated in a vehicle operation recording device to a recording medium by a single operation over a plurality of vehicle operations. With such a technique, a driver can save the trouble of having to store operation data in a recording medium every time the vehicle operation work is completed.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] To check the operating state of a taxi, for example, operation data is sequentially accumulated in the taxi. Then, the accumulated operation data is analyzed all at once after the operation work is completed, and a report showing the analysis result is output. An operator who manages taxis can grasp the operating state of each taxi based on such a report. Also, a taxi driver can review his or her own operation work through the report.

[0005] Therefore, operators and drivers desire to check the report as soon as possible after the operation work is completed. However, since it takes a certain amount of time to read and analyze the accumulated operation data, operators and drivers have not been able to check the report early.

[0006] In view of such problems, an object of the present invention is to provide a vehicle management device, a vehicle management system, a vehicle management method, and a program capable of checking a report at an early stage.

Means for Solving the Problems

[0007] In order to solve the above problems, the vehicle management device of the present invention includes a log update unit that causes a log holding unit to hold a log related to the operation of a vehicle received from a vehicle terminal, a state derivation unit that reads the log and derives a vehicle state based on the log, an event update unit that generates an event based on a change in the derived vehicle state and causes the event to be held in an event holding unit, and a report generation unit that reads the event and generates a report related to the operation state of the vehicle based on the event.

[0008] The frequency F at which the log is held by the log update unit L The frequency F at which the vehicle state is derived by the state derivation unit S The frequency F at which the event is generated by the event update unit E The frequency F at which the report is generated by the report generation unit R is F L >F S >F E >F R may satisfy the relationship.

[0009] The vehicle management device may include a backup update unit that causes the backup holding unit to hold the log received from the vehicle terminal, and a re-execution unit that reads the log held in the backup holding unit and causes the log to be held in the log holding unit in response to clearing of the log holding unit and the event holding unit.

[0010] To solve the above problems, the vehicle management system of the present invention includes the above-described vehicle management device and the vehicle terminal disposed in the vehicle. The vehicle terminal includes a log acquisition unit that acquires a log related to the operation of the vehicle, and a log transmission unit that transmits the acquired log to the vehicle management device. The vehicle management device further includes a report transmission unit that transmits the generated report to an external device.

[0011] To solve the above problems, the vehicle management method of the present invention is executed by one or more computers, holds a log related to the operation of the vehicle received from a vehicle terminal in a log holding unit, reads out the log, derives a vehicle state based on the log, generates an event based on a change in the derived vehicle state, holds the event in an event holding unit, reads out the event, and generates a report related to the operation state of the vehicle based on the event.

[0012] To solve the above problems, the program of the present invention causes a computer to function as a log update unit that holds a log related to the operation of the vehicle received from a vehicle terminal in a log holding unit, a state derivation unit that reads out the log and derives a vehicle state based on the log, an event update unit that generates an event based on a change in the derived vehicle state and holds the event in an event holding unit, and a report generation unit that reads out the event and generates a report related to the operation state of the vehicle based on the event.

Advantages of the Invention

[0013] According to the present invention, it becomes possible to check a report at an early stage.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The dimensions, materials, and other specific numerical values shown in such embodiments are merely examples for facilitating the understanding of the invention, and do not limit the present invention unless otherwise specified. In the present specification and drawings, elements having substantially the same function and configuration are denoted by the same reference numerals to omit redundant description, and elements not directly related to the present invention are not shown.

[0016] (Vehicle Management System 1) FIG. 1 is a block diagram for explaining the outline of the vehicle management system 1. The vehicle management system 1 includes a vehicle 10, a vehicle terminal 20, a vehicle management server 30, and a business operator server 40.

[0017] The vehicle 10 is, for example, a taxi or a hire car that conducts the business of transporting general passengers, and can transport users (persons). Further, a vehicle terminal 20 is arranged in the vehicle 10. There are a plurality of vehicles 10 and vehicle terminals 20. Here, taxis and hire cars are cited as the vehicle 10, but it is not limited to such cases, and various moving bodies such as trucks for transporting goods, delivery vehicles for delivering meals, private cars, company cars belonging to companies and facilities, business vehicles (company cars for making outside rounds), work vehicles (company cars for performing work), etc. can be adopted.

[0018] The vehicle terminal 20 is an information processing device that can be used by the driver of the vehicle 10 and is associated with the vehicle 10. Examples of the vehicle terminal 20 include a smartphone, a personal computer, a tablet PC, etc. Note that an information processing device provided integrally or separately in the vehicle 10 can also function as the vehicle terminal 20. The vehicle terminal 20 includes a display unit 22, an input unit 24, and a communication unit 26.

[0019] The display unit 22 includes a liquid crystal display and an organic EL (Electro Luminescence), and displays various information such as a notification that its own vehicle 10 has become the target of a dispatching request from an arbitrary user, the destination position where the user gets off, and the moving route to the destination position. The input unit 24 includes a touch panel and a switch superimposed on the display unit 22, and accepts the driver's input. The communication unit 26 establishes communication with, for example, a vehicle management server 30 through a base station 2 and a network network 3.

[0020] Further, the vehicle terminal 20 has a semiconductor integrated circuit including a processor, a ROM in which programs and the like are stored, a RAM as a work area, etc. The processor of the vehicle terminal 20 functions as a log acquisition unit 100 and a log transmission unit 102, which will be described later, by operating a program.

[0021] The vehicle management server (vehicle management device) 30 is an information processing device (computer) that manages a plurality of vehicles 10. The vehicle management server 30 establishes communication with, for example, the vehicle terminal 20 through the network network 3 and the base station 2, and also establishes communication with, for example, the operator server 40 through the network network 3. The vehicle management server 30 can appropriately dispatch the vehicle 10 in response to a user's vehicle dispatch request. In addition, the vehicle management server 30 manages the operating state of the vehicle 10. Here, the description will focus on the management of the operating state of the vehicle 10 by the vehicle management server 30.

[0022] Note that the vehicle management server 30 is composed of one or more information processing devices and can perform distributed processing or parallel processing. When the vehicle management server 30 is composed of a plurality of information processing devices, the plurality of information processing devices may be connected to each other through the network network 3. Each information processing device has a semiconductor integrated circuit including one or more processors, a ROM storing programs, etc., and a RAM as a work area.

[0023] The processor functions as an instance (execution means) such as a functional unit described later by operating a program. Note that one processor of one information processing device may function as a plurality of instances (multi-threading), a plurality of processors included in one information processing device may each function as an instance, or processors of a plurality of information processing devices may each function as an instance.

[0024] For example, the processor of the vehicle management server 30 functions as a log update unit 110, a status derivation unit 112, an event update unit 114, a report generation unit 116, a report transmission unit 118, a backup update unit 120, and a re-execution unit 122, which will be described later, by operating a program. Also, the RAM of the vehicle management server 30 functions as a log holding unit 130, a previous log holding unit 132, a previous status holding unit 134, a start trigger holding unit 136, an event holding unit 138, a report holding unit 140, and a backup holding unit 142, which will be described later. Hereinafter, the log update unit 110, the status derivation unit 112, the event update unit 114, the report generation unit 116, the report transmission unit 118, the backup update unit 120, and the re-execution unit 122 may be collectively referred to as functional units. Also, the log holding unit 130, the previous log holding unit 132, the previous status holding unit 134, the start trigger holding unit 136, the event holding unit 138, the report holding unit 140, and the backup holding unit 142 may be collectively referred to as holding units.

[0025] The operator server (external device) 40 is an information processing device owned by an operator engaged in the taxi business (passenger automobile transportation business), and manages the vehicles 10 belonging to the business office. The operator server 40 establishes communication with, for example, the vehicle management server 30 through the network network 3.

[0026] An operator may desire to check the operating status of the vehicles 10 belonging to his or her own business office. In this case, for example, it is conceivable that the operation data is sequentially accumulated in the vehicle 10, the accumulated operation data is analyzed after the operation work is completed, and output as a report. However, since it takes a certain amount of time to read and analyze the accumulated operation data, the operator cannot check the report early.

[0027] Therefore, in this embodiment, the vehicle management server 30 collects information regarding the operation of the vehicle 10 from the vehicle terminal 20 provided in the vehicle 10 and generates a report. At this time, the vehicle management server 30 accumulates and analyzes the information regarding the operation of the vehicle 10 in real time, and generates a report at an appropriate timing. Then, the vehicle management server 30 transmits the generated report to the operator server 40 as an external device. In this way, the operator can check the report at an early stage.

[0028] Here, the operator server 40 is cited as an external device that is the destination of the report transmission, but not limited to such a case, and various devices that require the report can be applied. For example, the external device may be the vehicle terminal 20, and the vehicle management server 30 may transmit the generated report to the vehicle terminal 20. With such a configuration, the driver of the vehicle 10 can check the report at an early stage and review his / her own operation work.

[0029] (Vehicle Management Method) FIG. 2 is an explanatory diagram for explaining the processing units of the vehicle management method by the vehicle management system 1. In the vehicle management method of FIG. 2, each functional unit in each device executes a predetermined process in parallel and independently in response to a predetermined trigger. For example, when the log acquisition unit 100 of the vehicle terminal 20 acquires a log related to the operation of the vehicle 10 (S1), the log transmission unit 102 of the vehicle terminal 20 transmits the acquired log to the vehicle management server 30 (S2). When the log update unit 110 of the vehicle management server 30 receives the log from the vehicle terminal 20, it causes the received log to be stored in the log storage unit 130 (S3). When the log read timing arrives, the state derivation unit 112 of the vehicle management server 30 reads the log and derives the vehicle state based on the log (S4). When the derived vehicle state changes, the event update unit 114 of the vehicle management server 30 generates an event based on the change in the vehicle state and causes the event storage unit 138 to store the event (S5). When the time to read an event arrives, the report generation unit 116 of the vehicle management server 30 reads the event and generates a report on the vehicle's operating status based on the event (S6). When the report is generated, the report transmission unit 118 of the vehicle management server 30 transmits the generated report to the business operator server 40 (S7). In this way, each process is executed only when the preceding process is executed and the result of that process satisfies a predetermined trigger condition. Each process will be described in detail below.

[0030] (Log acquisition process S1) The log acquisition unit 100 of the vehicle terminal 20 sequentially acquires logs, for example, at a predetermined interval (for example, 5 seconds). Here, the log is information related to the operation of the vehicle 10, and includes acquisition time, vehicle position, operation state, rental information, operation information, etc. The acquisition time indicates the time when the log was acquired. The vehicle position indicates the position of the vehicle 10 on a map. The vehicle position may include, for example, longitude and latitude information acquired through a Global Positioning System (GPS) or an Inertial Measurement Unit (IMU). The operation state indicates the business state related to the transportation business in the taxi business, and is expressed, for example, as empty, pick-up, rental, payment, and delivery. In addition, the operation state may include information that the user canceled the vehicle 10 after the dispatch was confirmed, information that the driver accepted the dispatch request from the user, information that the vehicle is traveling on a toll road, and the like. The rental information indicates the fare and additional charges (midnight charge, pick-up charge, reservation charge, waiting charge, toll road charge, etc.) at the time when the vehicle 10 is being rented. The operation information indicates the operation history when the driver operates the vehicle terminal 20 (tapping, scrolling).

[0031] (Log transmission process S2) When the log acquisition unit 100 acquires a log, the log transmission unit 102 of the vehicle terminal 20 associates the log with a vehicle ID capable of identifying the vehicle 10 and transmits the log to the vehicle management server 30. Therefore, the transmission timing of the log transmission unit 102 is also at a predetermined interval (e.g., 5 seconds) like the log acquisition timing of the log acquisition unit 100. Note that, although an example in which the log is associated with the vehicle ID and transmitted to the vehicle management server 30 will be described here, this is not limiting, and the log may be associated with a vehicle terminal ID capable of identifying the vehicle terminal 20 and transmitted to the vehicle management server 30.

[0032] (Log update process S3) When the log update unit 110 of the vehicle management server 30 receives a log from the vehicle terminal 20, it causes the log received from the vehicle terminal 20 to be stored in the log storage unit 130. The log storage unit 130 is a memory for storing logs. The log storage unit 130 is configured, for example, with a FIFO (First In, First Out) memory, and is used as a queue. Hereinafter, a FIFO memory will be simply abbreviated as FIFO. When the log update unit 110 receives a log, it enqueues it in the log storage unit 130.

[0033] (State derivation process S4) When the time to read a log arrives, the state derivation unit 112 of the vehicle management server 30 reads out the log that was held earliest in the log holding unit 130. Specifically, the state derivation unit 112 dequeues the logs held in the log holding unit 130 in order, starting with the log that was held earliest (earliest), at a processing interval that allows the vehicle state, described later, to be appropriately derived. Therefore, when logs are stored in the log holding unit 130, the read out timing arrives repeatedly at a period equal to the processing interval, and when no logs are stored in the log holding unit 130, the read out timing arrives immediately in response to the enqueuing of the log, provided that the processing interval has elapsed since the time the log was last read.

[0034] As described above, there are a plurality of vehicles 10 and vehicle terminals 20. Furthermore, each vehicle terminal 20 periodically transmits a log to the vehicle management server 30 at a predetermined interval, but between the plurality of vehicle terminals 20, logs are transmitted to the vehicle management server 30 asynchronously. Therefore, if the vehicle management server 30 were to receive all the logs from the plurality of vehicle terminals 20, the reception frequency would be biased, and processing of the logs would be concentrated. Therefore, a FIFO is used as the log holding unit 130.

[0035] FIG. 3 is an explanatory diagram for explaining the operation of the log update unit 110 and the state derivation unit 112. For example, when the vehicle management server 30 receives log A, the log update unit 110 enqueues log A to the log retention unit 130 as shown in FIG. 3(a). At this time, since no log is yet retained in the log retention unit 130, the state derivation unit 112 cannot dequeue the log. Next, when the log update unit 110 receives logs B, C, and D in a concentrated manner at once, it enqueues logs B, C, and D to the log retention unit 130 in that order as shown in FIG. 3(b). At this time, the state derivation unit 112 dequeues log A, which was retained first, from the log retention unit 130. This dequeuing causes log A to be deleted from the log retention unit 130. After that, unless a new log is received, the log update unit 110 cannot enqueue the log to the log retention unit 130 as shown in FIG. 3(c). At this time, the state derivation unit 112 dequeues the log B that was held earliest from the log holding unit 130. However, after dequeuing the log B, the state derivation unit 112 does not dequeue the logs C and D from the log holding unit 130 until the above-mentioned processing interval spent on deriving the vehicle state for the log B has elapsed.

[0036] In this way, it is possible to absorb the bias in the enqueue frequency of logs by using FIFO as the log holding unit 130. Therefore, the state derivation unit 112 can dequeue logs at stable processing intervals regardless of the bias in the enqueue frequency of logs.

[0037] Moreover, the state derivation unit 112 derives the vehicle state based on the log read from the log storage unit 130. The vehicle state is information obtained by processing the information required for generating a report from the log and / or deleting information unnecessary for generating the report.

[0038] 4 is an explanatory diagram for explaining the operation of the state derivation unit 112. In the previous log storage unit 132, a storage area is reserved for all vehicles 10 managed by the vehicle management server 30, and past values ​​of logs are stored in association with the vehicle ID of the vehicle 10. Note that the past value is not limited to the value of one log dequeued one time ago (previous value), but may include values ​​of multiple logs dequeued before that. The state derivation unit 112 refers to the vehicle ID associated with the current value of log A read from the log storage unit 130, and reads, for example, the past value of log A associated with the same vehicle ID from the previous log storage unit 132, as shown in FIG. 4(a).

[0039] Next, the state derivation unit 112 derives the vehicle state based on one or more past values ​​of log A and the current value of log A, or based only on the current value of log A, as shown in Fig. 4(b). The state derivation unit 112 may derive the vehicle state by, for example, comprehensively determining multiple past values ​​of log A stored in the log storage unit 130 within a predetermined period and the current value of log A. When the vehicle state is derived in this manner, the state derivation unit 112 stores the current value of log A in the previous log storage unit 132 to use it as the past value of log A in the next state derivation process, as shown in Fig. 4(c).

[0040] Here, the vehicle state is, for example, the current value of the log plus differential information such as vehicle speed. The vehicle speed is an estimated value of the vehicle speed of the vehicle 10, and is obtained, for example, by dividing the differential distance between the current vehicle position and the previous vehicle position by the log update interval (for example, 5 seconds).

[0041] Furthermore, the state derivation unit 112 derives the vehicle state only when the received log contains content necessary for generating a report. The log contains information that is not necessary for generating a report, such as operation information and information that the user has canceled the vehicle 10. Therefore, if all of the information contained in a received log is not necessary for generating a report, the state derivation unit 112 does not derive the vehicle state for that log. With this configuration, most of the received logs can be excluded, making it possible to reduce the processing load on the vehicle management server 30.

[0042] Here, an example has been described in which the state derivation unit 112 excludes the log itself when the received log contains content unnecessary for report generation. In addition to or instead of this, the state derivation unit 112 may exclude content unnecessary for report generation from the received log and leave only the content necessary for report generation.

[0043] (Event update process S5) Based on the change in the vehicle state derived by the state derivation unit 112, the event update unit 114 of the vehicle management server 30 generates a trigger (start trigger or end trigger). Here, the change in the vehicle state includes the occurrence of an event in the vehicle state and the end of an event in the vehicle state. The trigger indicates an event that can be a start condition or an end condition of an event. The vehicle state is added as information to the trigger.

[0044] FIG. 5 is an explanatory diagram for explaining the operation of the event update unit 114. A storage area is secured in the previous state holding unit 134 for all vehicles 10 managed by the vehicle management server 30, and the previous value of the vehicle state is held in association with the vehicle ID of the vehicle 10. The event update unit 114 refers to the vehicle ID associated with the current value of the vehicle state A derived by the state derivation unit 112, and reads out, as shown in FIG. 5(a), for example, the previous value of the vehicle state A associated with the same vehicle ID from the previous state holding unit 134.

[0045] Next, as shown in FIG. 5(b), the event update unit 114 may generate a trigger based on the previous value of the vehicle state A and the current value of the vehicle state A. When generating a trigger, the event update unit 114 overwrites the current value of the vehicle state A in the previous state holding unit 134 for use as the previous value of the vehicle state A in the next event update process, as shown in FIG. 5(c).

[0046] Here, since the state derivation unit 112 excludes logs unnecessary for report generation, the number of vehicle states and triggers can be made smaller than the number of logs, and the storage capacity of the previous state holding unit 134 can be reduced. Also, the execution frequency at which the state derivation unit 112 derives vehicle states and the execution frequency at which the event update unit 114 generates triggers can be made lower than the execution frequency at which the log update unit 110 holds logs, and the processing load on the vehicle management server 30 can be reduced.

[0047] The following illustrates the modes of trigger generation. For example, if the vehicle speed in the previous value of vehicle state A is less than 0.1 km / h and the vehicle speed in the current value of vehicle state A is 0.1 km / h or more, the event update unit 114 generates a trigger indicating that the vehicle 10 has changed from a stopped state to a running state. On the other hand, if the vehicle speed in the previous value of vehicle state A is 0.1 km / h or more and the vehicle speed in the current value of vehicle state A is less than 0.1 km / h, the event update unit 114 generates a trigger indicating that the vehicle 10 has changed from a running state to a stopped state.

[0048] Also, if the vehicle position of the previous value of vehicle state A is within the business office and the vehicle position of the current value of vehicle state A is outside the business office, the event update unit 114 generates a trigger indicating that the vehicle 10 has left the business office. On the other hand, if the vehicle position of the previous value of vehicle state A is outside the business office and the vehicle position of the current value of vehicle state A is within the business office, the event update unit 114 generates a trigger indicating that the vehicle 10 has returned to the business office. Similarly, if the vehicle position of the previous value of vehicle state A is outside the designated waiting area, which is a designated area where the vehicle 10 can wait for a user to board, such as a station, a busy street, or a taxi stand provided at a facility, and the vehicle position of the current value of vehicle state A is within the designated waiting area, the event update unit 114 generates a trigger indicating that the vehicle 10 has entered the designated waiting area. On the other hand, if the vehicle position of the previous value of vehicle state A is within the designated waiting area and the vehicle position of the current value of vehicle state A is outside the designated waiting area, the event update unit 114 generates a trigger indicating that the vehicle 10 has left the designated waiting area. Also, if the vehicle position of the previous value of vehicle state A is outside the boarding desired position, which is the position where the user wishes to board, and the vehicle position of the current value of vehicle state A is within the boarding desired position, the event update unit 114 generates a trigger indicating that the vehicle 10 has entered the boarding desired position. On the other hand, if the vehicle position of the previous value of vehicle state A is within the boarding desired position and the vehicle position of the current value of vehicle state A is outside the boarding desired position, the event update unit 114 generates a trigger indicating that the vehicle 10 has left the boarding desired position. Note that the boarding desired position is not limited to a point. Considering the case where the vehicle 10 cannot stop at the boarding desired position or the user may move before the vehicle 10 arrives, it may be within a range of a predetermined distance (for example, 10 m) from the point of the boarding desired position.

[0049] Also, if the operating state of the previous value of vehicle state A is other than empty and the operating state of the current value of vehicle state A is empty, the event update unit 114 generates a trigger indicating that the vehicle 10 has become empty. On the other hand, if the operating state of the previous value of vehicle state A is empty and the operating state of the current value of vehicle state A is other than empty, the event update unit 114 generates a trigger indicating that the vehicle 10 is no longer empty.

[0050] Subsequently, the event update unit 114 generates an event based on the occurrence of a start trigger and an end trigger. Here, the event indicates the operation history of the vehicle 10 to be described in the report.

[0051] FIG. 6 is an explanatory diagram for explaining the operation of the event update unit 114. In the start trigger holding unit 136, a storage area is secured for one or a plurality of events in all the vehicles 10 managed by the vehicle management server 30, and the start trigger can be held in association with the vehicle ID of the vehicle 10. When a start trigger A, which is a start condition for an event, occurs for vehicle A while the start trigger A is not held in the start trigger holding unit 136, the event update unit 114 associates the start trigger A with the vehicle ID of vehicle A and holds it in the start trigger holding unit 136 as shown in FIG. 6(a).

[0052] When the start trigger A is held in the start trigger holding unit 136, the event update unit 114 waits for an end trigger A, which is an end condition for the event, to occur. When an end trigger A for vehicle A occurs while the start trigger A is held in the start trigger holding unit 136, the event update unit 114 generates an event based on the start trigger A and the end trigger A as shown in FIG. 6(b). When the event update unit 114 generates an event, it deletes the start trigger A from the start trigger holding unit 136 as shown in FIG. 6(c).

[0053] Note that after a start trigger occurs, if another type of start trigger related to the same vehicle occurs, accordingly, the event corresponding to the start trigger that occurred previously may end. The event update unit 114 waits in the start trigger holding unit 136 for, for example, an end trigger A1 that is an event end condition to occur while a start trigger A1 related to vehicle A is being held. Then, when another type of start trigger A2 related to vehicle A occurs and the event corresponding to start trigger A1 ends due to the occurrence of start trigger A2, the event update unit 114 assumes that end trigger A1 has occurred in response to the occurrence of start trigger A2. Then, the event update unit 114 generates an event based on start trigger A1 and end trigger A1. When the event update unit 114 generates an event, it deletes start trigger A1 from the start trigger holding unit 136 and holds start trigger A2.

[0054] The following illustrates an event generation mode. For example, assume that a trigger that vehicle 10 has left the workplace occurs as a start trigger, and a trigger that vehicle 10 has returned to the workplace occurs as an end trigger. In this case, the event update unit 114 generates an event that the driver of vehicle 10 is on duty, together with the start time and the end time. Note that the start time and the end time use the log acquisition time in the trigger.

[0055] Also, assume that a trigger that the vehicle 10 has changed from a running state to a stopped state occurs as a start trigger, and a trigger that the vehicle 10 has changed from a stopped state to a running state occurs as an end trigger. In this case, the event update unit 114 generates an event that the user was waiting to board at either the desired boarding position or the designated waiting area together with the start time and end time, on condition that the difference between the start time and end time is a predetermined time (for example, 5 minutes) or more, and the vehicle position in the stopped state is either the desired boarding position or the designated waiting area. At this time, the desired boarding position or the designated waiting area is also added to the event. On the other hand, the event update unit 114 generates an event that the driver was taking a rest together with the start time and end time, on condition that the difference between the start time and end time is a predetermined time (for example, 5 minutes) or more, and the vehicle position in the stopped state is neither the desired boarding position nor the designated waiting area. At this time, the vehicle position is also added to the event.

[0056] Furthermore, the event update unit 114 may accumulate vehicle position information while waiting for the occurrence of the end trigger A after the start trigger is held in the start trigger holding unit 136. For example, when a trigger that the vehicle 10 becomes unoccupied occurs as a start trigger, the event update unit 114 accumulates vehicle position information at a predetermined interval (for example, 5 seconds) on condition that the vehicle 10 is in a traveling state. Then, when a trigger that the vehicle 10 is no longer unoccupied occurs as an end trigger, the event update unit 114 generates an event called the movement trajectory of the vehicle 10 when unoccupied together with the start time and end time. At this time, the accumulated vehicle position information is added to the event as an array.

[0057] Meanwhile, the vehicle management server 30 knows the vehicle positions of multiple vehicles 10, and also knows the positions where users are likely to board the vehicles 10 based on the past riding records of users. Therefore, in the case where the vehicle 10 accepts boarding requests from users while traveling, that is, in the case of a so-called cruising vehicle, the vehicle management server 30 can derive a driving route that increases the probability of users boarding.

[0058] FIG. 7 is an explanatory diagram for explaining the display mode of the vehicle terminal 20. When the vehicle management server 30 derives a travel route 150 that increases the user's boarding probability, the vehicle management server 30 transmits the travel route 150 to the vehicle terminal 20. As shown in FIG. 7, the vehicle terminal 20 displays a map in the vicinity of the vehicle 10 on the display unit 22, and superimposes the travel route 150 indicated by the broken line in FIG. 7 on the map. By driving the vehicle 10 according to such a travel route 150, the driver can increase the user's boarding probability.

[0059] However, depending on the driver, there may be a case where the vehicle 10 is driven along a travel route 152 indicated by a solid line in FIG. 7 from point A to point B without following the travel route 150. In this case, the event update unit 114 may generate an event that the driver did not follow the travel route 150.

[0060] For example, as a start trigger, when a trigger that the vehicle 10 has deviated from the travel route 150 occurs, the event update unit 114 accumulates information on the vehicle position at predetermined intervals (for example, 5 seconds) on the condition that the vehicle state is empty. Then, as an end trigger, when a trigger that the vehicle 10 has returned to the travel route 150 or a trigger that the operation state of the vehicle 10 has become other than empty (for example, picking up a passenger, hired driving, return trip) occurs, the event update unit 114 generates an event of a movement trajectory in which the vehicle 10 has deviated from the travel route 150 and traveled together with the start time and the end time. At this time, the accumulated vehicle position information is added as an array to the event.

[0061] In addition, the vehicle management server 30 can derive a designated waiting area that can increase the user's boarding probability and a stand (gasoline stand, LP gas stand, charging stand, hydrogen stand) that can improve the time efficiency of fuel replenishment or charging of the vehicle 10. The event update unit 114 may generate an event to that effect when the driver does not head for the designated waiting area or the stand.

[0062] Then, the event update unit 114 causes the generated event to be held in the event holding unit 138. The event holding unit 138 is a memory for holding events. The event holding unit 138, like the log holding unit 130, is configured by, for example, a FIFO and used as a queue. That is, the event update unit 114 enqueues the generated event in the event holding unit 138.

[0063] Here, since the trigger is held only when the vehicle state changes and events are generated based on the trigger, the number of events can be made smaller than the number of vehicle states, and the storage capacities of the start trigger holding unit 136 and the event holding unit 138 can be made smaller. Also, the execution frequency at which the event update unit 114 generates events can be made lower than the execution frequency at which the state derivation unit 112 derives the vehicle state, and the processing load on the vehicle management server 30 can be reduced.

[0064] (Report generation process S6) When the read timing of an event arrives, the report generation unit 116 of the vehicle management server 30 reads the event held first in the event holding unit 138. Specifically, the report generation unit 116 dequeues, in order, the events held in the event holding unit 138 starting from the event held first, at a processing interval at which an appropriate report can be generated as described later. Here, the report is information that can grasp the operation state (operation history) of the vehicle 10. For example, in the report, the operation history is listed in chronological order. Also, the report may include the result of aggregating and processing the operation history. Therefore, when events are accumulated in the event holding unit 138, the read timing arrives repeatedly with the processing interval as a cycle, and when no events are accumulated in the event holding unit 138, the read timing arrives immediately in response to the enqueueing of an event on the condition that the processing interval has elapsed since the timing of the previous event read.

[0065] As described above, there are a plurality of vehicles 10 and vehicle terminals 20. Further, events occur asynchronously between individual vehicles 10. Therefore, the occurrence frequencies of events in the plurality of vehicles 10 are biased, and there is a possibility that the processing for events may be concentrated in the vehicle management server 30. Therefore, a FIFO is used as the event holding unit 138.

[0066] FIG. 8 is an explanatory diagram for explaining the operations of the event update unit 114 and the report generation unit 116. For example, when the event update unit 114 generates an event, as shown in FIG. 8(a), it enqueues event A in the event holding unit 138. At this time, since no event is yet held in the event holding unit 138, the report generation unit 116 cannot dequeue the event. Subsequently, when the event update unit 114 generates events B, C, and D in a concentrated manner at once, as shown in FIG. 8(b), it enqueues events B, C, and D in the event holding unit 138 in that order. At this time, the report generation unit 116 dequeues the earliest held event A from the event holding unit 138. By such dequeueing, event A is deleted from the log holding unit 130. Thereafter, when the event update unit 114 does not generate an event, as shown in FIG. 8(c), it does not enqueue the event in the event holding unit 138. At this time, the report generation unit 116 dequeues the earliest held event B from the event holding unit 138. However, after the report generation unit 116 dequeues event B, it does not dequeue events C and D from the event holding unit 138 until the above-described processing interval for deriving the vehicle state with respect to event B has elapsed.

[0067] In this way, by using a FIFO as the event holding unit 138, it becomes possible to absorb the bias in the event enqueueing frequency. Therefore, the report generation unit 116 can dequeue events at a stable processing interval regardless of the bias in the event enqueueing frequency.

[0068] Subsequently, the report generation unit 116 generates a report based on the event read from the event holding unit 138 and holds it in the report holding unit 140.

[0069] FIG. 9 is an explanatory diagram for explaining the operation of the report generation unit 116. When the report generation unit 116 reads out the event first held in the event holding unit 138, based on the vehicle ID associated with the event, from the report holding unit 140, as shown in FIG. 9, a report associated with the same vehicle ID is referred to. The report generation unit 116 adds an event record to the report associated with the vehicle ID, and as shown in FIG. 9(a), holds the event in the added event record together with its start time and end time.

[0070] Also, if such an event is an event for obtaining the total time, for example, "user waiting in the designated waiting area", the report generation unit 116 derives the total of the event "user waiting in the designated waiting area" generated during the working hours, and updates the aggregation result shown in FIG. 9(b).

[0071] Here, since a plurality of events are accumulated as records and one report is generated for each vehicle 10, the execution frequency of generating reports can be made lower than the execution frequency of generating events, and the processing load on the vehicle management server 30 can be reduced. However, the report generation unit 116 can generate reports not only in units of vehicle 10, but also in various units such as a specified plurality of vehicle 10 units, driver units, operator units, etc.

[0072] Note that when a report is generated, the information held in the holding unit becomes unnecessary and can be discarded. Therefore, unlike the case where the accumulated operation data is collectively analyzed after the end of the operation business, it is not necessary to leave the information in the holding unit after the end of the operation business.

[0073] (Report transmission process S7) When the report generation unit 116 of the vehicle management server 30 generates a report, the generated report is transmitted to the operator server 40 after the end of the operation business. In this way, the operator can check the report early using the operator server 40 or a terminal connected thereto.

[0074] Here, an example where the report transmission unit 118 transmits a report to the operator server 40 after the operation work is completed has been described. However, not limited to such a case, the report transmission unit 118 can transmit a report on the logs received so far to the operator server 40 at any timing desired by the operator.

[0075] FIG. 10 is an explanatory diagram for explaining the execution frequency of each functional unit. As described above, in the present embodiment, a plurality of holding units such as a log holding unit 130, a previous log holding unit 132, a previous state holding unit 134, a start trigger holding unit 136, an event holding unit 138, and a report holding unit 140 are used. Also, as described above, the frequency F at which the log is held by the log update unit 110, shown by (A) in FIG. 10 L , the frequency F at which the vehicle state is derived by the state derivation unit 112, shown by (B) in FIG. 10 S , the frequency F at which an event is generated by the event update unit 114, shown by (C) in FIG. 10 E , the frequency F at which a report is generated by the report generation unit 116, shown by (D) in FIG. 10 R is F L > F S > F E > F R is configured to satisfy the relationship. Therefore, even if the load increases or the amount of information increases in the subsequent processing, it is possible to surely generate a report without causing the processing to be delayed.

[0076] However, if it takes time to access the holding unit or the writing and reading to the holding unit become slow, there is a risk that each process such as the log holding by the log update unit 110, the derivation of the vehicle state by the state derivation unit 112, the generation of events by the event update unit 114, and the generation of reports by the report generation unit 116 may be delayed. Therefore, in the present embodiment, a volatile memory (for example, static memory) that maintains information while the power is on is adopted for part or all of the holding unit. However, since the volatile memory is expensive, it is not realistic to adopt it for all holding units. Therefore, for the holding unit that does not adopt the volatile memory, a non-volatile recording medium such as an HDD (Hard Disk Drive) is adopted.

[0077] Here, among the holding units, one or a plurality of holding units with high execution frequency are configured with volatile memory. For example, the log holding unit 130 with high execution frequency, the previous log holding unit 132, the previous state holding unit 134, the start trigger holding unit 136, and the event holding unit 138 are configured with volatile memory. And the report holding unit 140 is configured with a non-volatile recording medium. The report holding unit 140 may be configured with an RDB (Relational DataBase), which is a database managed so that a plurality of tabular data can be associated and used, for example.

[0078] Note that the holding unit configured with volatile memory and the holding unit configured with non-volatile recording medium are not limited to the above example, and the holding unit with high execution frequency may be preferentially configured with volatile memory, and the other holding units may be configured with non-volatile recording medium.

[0079] With such a configuration, while suppressing the running cost, the access speed to the holding unit can be increased, so that the vehicle management server 30 can accumulate and analyze information related to operation in real time.

[0080] However, while volatile memory has the advantage of fast access, it has the drawback that when the power is cut off, the information stored in it is cleared. Therefore, for example, if part or all of the holding unit is composed of volatile memory, when the power is cut off, all the information stored in the holding unit will be cleared, and the events based on that information cannot be reflected in the report.

[0081] Therefore, when the content of the holding unit is cleared, for the information for which events have not yet been generated, the process of having the log holding unit 130 hold the log is re-executed to resume the accumulation of information and restore the information in the volatile memory.

[0082] FIG. 11 is an explanatory diagram showing a mode of restoring the information in the holding unit. As described above, the log update unit 110 normally causes the received log to be held in the log holding unit 130. In parallel with this, the backup update unit 120 of the vehicle management server 30 causes the received log to be held in the backup holding unit 142. The backup holding unit 142 is composed of a non-volatile recording medium. The backup holding unit 142 can store at least the logs for a time (for example, 5 minutes) during which information for which events have not been generated can be restored.

[0083] Then, when the power is cut off and the information in part or all of the holding unit is cleared, and then the power is restored, the re-execution unit 122 of the vehicle management server 30 restores the information in the holding unit. Specifically, at the time of restoration, the re-execution unit 122 reads out the logs after the time when the power was cut off from the logs held in the backup holding unit 142 in the order in which they were held first, and causes them to be held in the log holding unit 130.

[0084] Note that the backup update unit 120 also causes the received log to be held in the backup holding unit 142 even at the time of restoration. In this way, newly generated logs can also be held in the log holding unit 130 via the backup holding unit 142.

[0085] The log retention unit 130 has a storage capacity capable of retaining logs even when logs are concentrated. Therefore, the re-execution unit 122 can cause the log retention unit 130 to retain logs at short intervals so that the processing of the state derivation unit 112 is not delayed during restoration. In this way, after a predetermined time (for example, 10 minutes), the information of all retention units is restored. When the number of newly retained logs in the backup retention unit 142 becomes less than a predetermined number, it switches to the normal state, and the log update unit 110 causes the received logs to be retained in the log retention unit 130.

[0086] With such a configuration, even when the information of the retention unit is cleared in the vehicle management server 30, it is possible to appropriately restore the information of the retention unit while continuously retaining the logs received thereafter.

[0087] As described above, the execution frequencies of log retention by the log update unit 110, vehicle state derivation by the state derivation unit 112, event generation by the event update unit 114, and report generation by the report generation unit 116 are in the relationship of log retention by the log update unit 110 > vehicle state derivation by the state derivation unit 112 > event generation by the event update unit 114 > report generation by the report generation unit 116. Therefore, even if the load or the amount of information increases in the later-stage processing compared to the earlier-stage processing, it is possible to surely generate a report without delaying the processing.

[0088] Also, by configuring the log retention unit 130 and the event retention unit 138 with FIFO, it is possible to absorb the bias in the enqueue frequency of logs and events.

[0089] Therefore, the vehicle management server 30 can accumulate and analyze the logs received from the vehicle terminal 20 in real time and generate a report at an appropriate timing. In this way, the operator and the driver of the vehicle 10 can confirm the operation state of the vehicle 10 at an early stage through the report.

[0090] In this way, the vehicle management device (for example, the vehicle management server 30) includes a log update unit 110 that causes the log holding unit 130 to hold the log related to the operation of the vehicle 10 received from the vehicle terminal 20, a state derivation unit 112 that reads the log and derives the vehicle state based on the log, an event update unit 114 that generates an event based on the change in the derived vehicle state and causes the event holding unit 138 to hold the event, and a report generation unit 116 that reads the event and generates a report on the operation state of the vehicle 10 based on the event. With such a configuration, the vehicle management server 30 can accumulate and analyze the log received from the vehicle terminal 20 in real time and generate a report at an appropriate timing. In this way, the operator and the driver of the vehicle 10 can confirm the operation state of the vehicle 10 at an early stage through the report.

[0091] Also, the frequency F at which the log is held by the log update unit 110 L , the frequency F at which the vehicle state is derived by the state derivation unit 112 S , the frequency F at which the event is generated by the event update unit 114 E , the frequency F at which the report is generated by the report generation unit 116 R are such that F L > F S > F E > F R may satisfy the relationship. With such a configuration, even if the load or the amount of information increases in the latter-stage processing compared to the former-stage processing, it is possible to surely generate a report without causing the processing to be delayed.

[0092] The vehicle management device may include a backup update unit 120 that causes the backup holding unit 142 to hold the log received from the vehicle terminal 20, and a re-execution unit 122 that reads the log held in the backup holding unit 142 and causes the log holding unit 130 to hold it in response to the clearing of the log holding unit 130 and the event holding unit 138. With such a configuration, even when the information in the holding unit is cleared in the vehicle management server 30, it is possible to appropriately restore the information in the holding unit while continuously holding the log received thereafter.

[0093] In addition, the vehicle management system 1 includes the above-described vehicle management device (for example, the vehicle management server 30) and a vehicle terminal 20 disposed in the vehicle 10. The vehicle terminal 20 includes a log acquisition unit 100 that acquires a log related to the operation of the vehicle 10, and a log transmission unit 102 that transmits the acquired log to the vehicle management device. The vehicle management device further includes a report transmission unit 118 that transmits the generated report to an external device (for example, the operator server 40 or the vehicle terminal 20). With such a configuration, in the vehicle management system 1, the log received from the vehicle terminal 20 can be accumulated and analyzed in real time, and a report can be generated at an appropriate timing. Thus, the operator or the driver of the vehicle 10 can check the operation state of the vehicle 10 at an early stage through the report.

[0094] In addition, the vehicle management method is executed by one or more computers. The method includes holding, in a log holding unit 130, a log related to the operation of the vehicle 10 received from the vehicle terminal 20, reading the log, deriving a vehicle state based on the log, generating an event based on a change in the derived vehicle state, holding the event in an event holding unit 138, reading the event, and generating a report related to the operation state of the vehicle 10 based on the event. By using such a vehicle management method, the log received from the vehicle terminal 20 is accumulated and analyzed in real time, and a report is generated at an appropriate timing. Thus, the operator or the driver of the vehicle 10 can check the operation state of the vehicle 10 at an early stage through the report.

[0095] Further, the program causes the computer to function as a log update unit 110 that causes the log holding unit 130 to hold logs related to the operation of the vehicle 10 received from the vehicle terminal, a state derivation unit 112 that reads the logs and derives the vehicle state based on the logs, an event update unit 114 that generates an event based on the change in the derived vehicle state and causes the event holding unit 138 to hold the event, and a report generation unit 116 that reads the event and generates a report related to the operation state of the vehicle 10 based on the event. By using such a program, the logs received from the vehicle terminal 20 are accumulated and analyzed in real time, and a report is generated at an appropriate timing. Thus, the operator and the driver of the vehicle 10 can confirm the operation state of the vehicle 10 at an early stage through the report.

[0096] As described above, the preferred embodiments of the present invention have been described with reference to the accompanying drawings. Needless to say, the present invention is not limited to such embodiments. It is obvious that those skilled in the art can conceive of various modification examples or correction examples within the scope described in the claims, and it is naturally understood that they also belong to the technical scope of the present invention.

[0097] In addition, a program that causes the computer to function as the vehicle management server 30 and a recording medium such as a flexible disk, a magneto-optical disk, a ROM, a CD, a DVD, a BD, etc. that records the program and is readable by a computer are also provided. Here, the program refers to data processing means described in an arbitrary language and description method.

[0098] Note that each process shown in this specification does not necessarily need to be processed in time series in the order described in the flowchart, and may include parallel or subroutine processing.

Explanation of Reference Numerals

[0099] 1 Vehicle management system 10 Vehicle 20 Vehicle terminal (external device) 30 Vehicle management server (vehicle management device) 40 Operator Server (External Device) 100 Log Acquisition Unit 102 Log Transmission Unit 110 Log Update Unit 112 Status Derivation Unit 114 Event Update Unit 116 Report Generation Unit 118 Report Transmission Unit 120 Backup Update Unit 122 Re - execution Unit 130 Log Retention Unit 132 Previous Log Retention Unit 134 Previous Status Retention Unit 136 Start Trigger Retention Unit 138 Event Retention Unit 140 Report Retention Unit 142 Backup Retention Unit

Claims

1. A log update unit that causes a log holding unit to hold logs related to the operation of a vehicle received from a vehicle terminal; A state derivation unit that reads the log and derives a vehicle state based on the log; An event update unit that generates an event based on a change in the derived vehicle state and causes the event to be held in an event holding unit; A report generation unit that reads the event and generates a report on the operation state of the vehicle based on the event; A vehicle management device comprising the above.

2. The frequency F at which the log is retained by the log update unit Ｌ , the frequency F at which the vehicle state is derived by the state derivation unit Ｓ , the frequency F at which the event is generated by the event update unit Ｅ , the frequency F at which the report is generated by the report generation unit Ｒ is F Ｌ > F Ｓ > F Ｅ > F Ｒ The vehicle management device according to claim 1, which satisfies the relationship of

3. A backup update unit that causes a backup holding unit to hold the log received from the vehicle terminal; A re-execution unit that reads the log held in the backup holding unit in response to clearing of the log holding unit and the event holding unit and causes the log to be held in the log holding unit; The vehicle management device according to Claim 1, comprising the above.

4. A vehicle management system comprising the vehicle management device according to any one of Claims 1 to 3; The vehicle terminal disposed in the vehicle; wherein the vehicle terminal comprises a log acquisition unit that acquires logs related to the operation of the vehicle; a log transmission unit that transmits the acquired log to the vehicle management device; and the vehicle management device further comprises a report transmission unit that transmits the generated report to an external device.

5. A vehicle management method executed by one or more computers, the method comprising: holding, in a log holding unit, logs related to the operation of a vehicle received from a vehicle terminal; reading the log and deriving a vehicle state based on the log; generating an event based on a change in the derived vehicle state and holding the event in an event holding unit; reading the event and generating a report on the operation state of the vehicle based on the event.

6. A program for causing a computer to function as a log update unit that causes a log holding unit to hold logs related to the operation of a vehicle received from a vehicle terminal; a state derivation unit that reads the log and derives a vehicle state based on the log; an event update unit that generates an event based on a change in the derived vehicle state and causes the event to be held in an event holding unit; a report generation unit that reads the event and generates a report on the operation state of the vehicle based on the event. ​ ​

Images