Support system, support method, and support program

Abstract

To provide a support system capable of requesting a support from an appropriate supporter.SOLUTION: A support system includes a processor and supports an autonomous travel apparatus. The processor implements generation of action history data of the autonomous travel apparatus. The processor implements monitoring of occurrence of a stack which is a condition where travel of the autonomous travel apparatus is hindered. The processor implements outputting of support request data to a supporter who matches a recovery support level. The recovery support level is a level of a recovery support from a stack which is requested from a supporter capable of implementing a recovery support from a stack. The recovery support level is a level determined based on action history data preceding the stack occurrence timing.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present disclosure relates to a support technology for remotely supporting the driving of a host vehicle and an autonomously drivable target vehicle.

Background Art

[0002] Patent Document 1 discloses a management center for managing the operation of a transport robot. The management center acquires support information including identification information of a registered user who has executed a support operation including support for returning from a non-drivable state of the transport robot and the content of the support operation. The management center awards points to the registered user according to the content of the acquired support operation.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the support required for the transport robot varies depending on the situation, and the burden level of the supporter who executes the support also varies depending on the support. In the technology of Patent Document 1, since support is uniformly requested for any registered user, it is not possible to request support according to the situation to an appropriate supporter.

[0005] An object of the present disclosure is to provide a support system capable of requesting support from an appropriate supporter. Another object of the present disclosure is to provide a support method capable of requesting support from an appropriate supporter. Still another object of the present disclosure is to provide a support program capable of requesting support from an appropriate supporter.

Means for Solving the Problems

[0006] Hereinafter, the technical means of the present disclosure for solving the problems will be described. Note that the reference numerals in parentheses described in the claims and this column indicate the correspondence with the specific means described in the embodiments described in detail later, and do not limit the technical scope of the present disclosure.

[0007] The first aspect of the present disclosure is an assistance system having a processor (5) and assisting an autonomous driving device (10), wherein the processor generates operation history data of the autonomous driving device, monitors the occurrence of a stack as a state in which the driving of the autonomous driving device is inhibited, outputs support request data to a supporter that matches the recovery support level from the stack, which is a level of recovery support from the stack to a supporter capable of executing the recovery support from the stack, and is a level corresponding to the operation history data traced back from the occurrence timing of the stack, and is configured to execute the above.

[0008] The second aspect of the present disclosure is an assistance method executed by a processor (5) to assist an autonomous driving device (10), generating operation history data of the autonomous driving device, monitoring the occurrence of a stack as a state in which the driving of the autonomous driving device is inhibited, outputting support request data to a supporter that matches the recovery support level from the stack, which is a level of recovery support from the stack to a supporter capable of executing the recovery support from the stack, and is a level corresponding to the operation history data traced back from the occurrence timing of the stack, and includes the above.

[0009] The third aspect of the present disclosure is an assistance program stored in a storage medium (4) to assist an autonomous driving device (10) and including instructions for causing a processor (5) to execute, wherein the instructions cause the operation history data of the autonomous driving device to be generated, monitoring the occurrence of a stack as a state in which the running of the autonomous driving device is inhibited, outputting support request data to a supporter (20) capable of executing recovery support from the stack, the supporter matching the recovery support level which is a level of recovery support from the stack and which is according to the operation history data traced back from the occurrence timing of the stack, including.

[0010] According to these first to third aspects, when a stack occurs in the autonomous driving device, support request data is output to a supporter matching the recovery support level according to the operation history data traced back from the occurrence timing of the stack. Therefore, it becomes possible to request support from a supporter suitable for the recovery support level. Accordingly, it becomes possible to request support from an appropriate supporter.

Brief Description of Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Best Mode for Carrying Out the Invention

[0012] Hereinafter, a plurality of embodiments of the present disclosure will be described with reference to the drawings. In each embodiment, the same reference numerals may be assigned to corresponding components, and redundant descriptions may be omitted. Further, when only a part of the configuration is described in each embodiment, the configuration of other embodiments described previously can be applied to other parts of the configuration. Furthermore, not only the combinations of configurations explicitly shown in the description of each embodiment, but also the configurations of a plurality of embodiments can be partially combined with each other as long as there is no problem with the combination.

[0013] (First Embodiment) The support system 3 of the first embodiment shown in FIG. 1 is constructed in the remote center 1 which is an external facility of the autonomous driving device 10 capable of autonomous driving. The support system 3 is configured to be operable by a plurality of operators, and remotely supports the autonomous driving of the autonomous driving device 10. The autonomous driving device 10 is an autonomous device (autonomous robot) capable of autonomous driving in any direction of front, rear, left, and right. Note that the autonomous driving device 10 can also be referred to as an autonomous vehicle. The autonomous driving device 10 is, for example, a transport vehicle that transports a load by autonomous driving. Alternatively, the autonomous driving device 10 may be used for purposes other than transporting a load (for example, information collection, etc.).

[0014] The autonomous driving device 10 is equipped with a communication system 11, a sensor system 12, a map database 15, an information presentation system 16, and a control system 17 shown in FIG. 2. The communication system 11 acquires communication information available to the autonomous driving device 10 by wireless communication. The communication system 11 may be of the V2X type that transmits and receives communication signals to and from a V2X system existing outside the autonomous driving device 10. The V2X type communication system 11 is at least one of, for example, a DSRC (Dedicated Short Range Communications) communicator and a cellular V2X (C-V2X) communicator. With the V2X type communication system 11, the autonomous driving device 10 can communicate wirelessly with the support system 3. The communication system 11 may be of the terminal communication type that transmits and receives communication signals to and from terminals existing around the autonomous driving device 10. The terminal communication type communication system 11 is at least one of, for example, a Bluetooth (registered trademark) device, a Wi-Fi (registered trademark) device, and an infrared communication device.

[0015] The sensor system 12 acquires sensor information available to the control system 17 or the support system 3 with respect to the outside and the inside of the autonomous driving device 10. For this purpose, the sensor system 12 is configured to include an external sensor 13 and an internal sensor 14.

[0016] The external sensor 13 acquires external information as sensor information from the external environment that is the surrounding environment of the autonomous driving device 10. The external sensor 13 may be of a target detection type that detects targets existing in the external environment of the autonomous driving device 10. The external sensor 13 of the target detection type includes at least one type among, for example, a camera that images the external environment, a LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging) that can detect the reflected light of the irradiated laser light as a point cloud image, a radar, and a sonar. The external sensor 13 may be of a positioning type that receives a positioning signal from an artificial satellite of the GNSS (Global Navigation Satellite System) existing in the external environment of the autonomous driving device 10. The external sensor 13 of the positioning type is, for example, a GNSS receiver or the like.

[0017] The internal sensor 14 acquires internal information as sensor information from the internal environment that is the internal environment of the autonomous driving device 10. The internal sensor 14 may be of a physical quantity detection type that detects a specific motion physical quantity in the internal environment of the autonomous driving device 10. The internal sensor 14 of the physical quantity detection type is at least one type among, for example, a speed sensor, an acceleration sensor, a gyro sensor, a wheel rotation speed sensor, and a sound sensor.

[0018] The map database 15 stores map information that can be used by the control system 17. The map database 15 is configured to include at least one type of non-transitory tangible storage medium such as, for example, a semiconductor memory, a magnetic medium, and an optical medium. The map database 15 may be a database of a locator that estimates the self-state quantity including the self-position of the autonomous driving device 10. The map database 15 may be a database of a navigation unit that navigates the travel route of the autonomous driving device 10. The map database 15 may be configured by a combination of a plurality of types among these databases or the like.

[0019] The map database 15 acquires and stores the latest map information through communication with the outside via, for example, a V2X type communication system 11. Here, the map information is digitized in two or three dimensions as information representing the driving environment of the autonomous driving device 10. In particular, as the three-dimensional map data, digital data of a high-precision map may be adopted. The map information may include road information representing at least one of, for example, the position, shape, and road surface condition of the road itself. The map information may include sign information representing at least one of, for example, the position and shape of signs and lane markings attached to the road. The map information may include structure information representing at least one of, for example, the position and shape of buildings and traffic lights facing the road.

[0020] The information presentation system 16 presents notification information to people around the autonomous driving device 10. The information presentation system 16 may be of a visual stimulation type that stimulates vision. The information presentation system 16 of the visual stimulation type is, for example, at least one of a display and a light emitting unit. The information presentation system 16 may be of an auditory stimulation type that stimulates the hearing of the passengers. The information presentation system 16 of the auditory stimulation type is, for example, at least one of a speaker and a buzzer.

[0021] The control system 17 is connected to the communication system 11, the sensor system 12, the map database 15, and the information presentation system 16 via at least one of, for example, a LAN (Local Area Network) line, a wire harness, an internal bus, and a wireless communication line. The control system 17 is configured to include at least one dedicated computer.

[0022] The dedicated computer that constitutes the control system 17 is, for example, a driving control ECU (Electronic Control Unit) that controls the autonomous driving of the autonomous driving device 10. The dedicated computer that constitutes the control system 17 has at least one memory 18 and one processor 19. The memory 18 is at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, and an optical medium, that non-temporarily stores programs, data, etc. that can be read by a computer. Here, storage may be an accumulation in which data is retained even when the autonomous driving device 10 is turned on and off, or it may be a temporary storage in which data is erased when the autonomous driving device 10 is turned on and off. The processor 19 includes at least one type, such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a RISC (Reduced Instruction Set Computer)-CPU, a CISC (Complex Instruction Set Computer)-CPU, a DFP (Data Flow Processor), and a GSP (Graph Streaming Processor), as a core.

[0023] In the control system 17, the processor 19 plans dynamic driving tasks in the future route, future trajectory, and future actions of the autonomous driving device 10 based on sensor information, etc. The control system 17 may perform judgment and planning using a vehicle driving model, such as a simulation model or a machine learning model.

[0024] Furthermore, in the control system 17, the processor 19 executes a plurality of instructions included in the control program stored in the memory 18 in order to provide information available for assistance to the assistance system 3. As a result, the control system 17 constructs a plurality of functional blocks for providing information available in the assistance of the autonomous driving device 10. The plurality of functional blocks constructed in the control system 17 include an information collection block 170, a peripheral monitoring block 171, a communication control block 172, and a presentation control block 173 as shown in FIG. 2.

[0025] The information collection block 170 collects state information regarding the state of the autonomous driving device 10. The information collection block 170 collects the internal information from the internal sensor 14 as state information. For example, the information collection block 170 collects speed data, acceleration data, attitude data, sound data, wheel rotation speed data, etc. as state information. In addition, the information collection block 170 collects processor utilization rate data and memory utilization rate data as data regarding the usage status of the processor and memory related to the control of the autonomous driving device 10 as state information.

[0026] The peripheral monitoring block 171 monitors the external environment around the autonomous driving device 10. In the monitoring, the peripheral monitoring block 171 collects external information from the external sensor 13. For example, the peripheral monitoring block 171 collects image data obtained by imaging the external environment with a camera, sensing data obtained by sensing the external environment with LiDAR, radar, etc. as external information.

[0027] The communication control block 172 controls the communication between the control system 17 and the outside of the autonomous driving device 10 via the communication system 11. The communication control block 172 transmits the state information collected by the information collection block 170 to the support system 3. The communication control block 172 transmits the external information collected by the peripheral monitoring block 171 to the support system 3. Also, the communication control block 172 receives, via the communication system 11, support request data (described later) for other road users 23 from the support system 3. In addition, after the completion of the support, the communication control block 172 may use the communication system 11 as an access point for the supporter 20 to which incentives are to be given, which will be described later.

[0028] The presentation control block 173 executes information presentation processing for the periphery of the autonomous driving device 10 via the information presentation system 16. In response to the reception of the support request data for other road users 23, the presentation control block 173 notifies the support request via the information presentation system 16. The presentation control block 173 executes notification by at least one of voice data and video data with content corresponding to the notification instruction included in the support request data.

[0029] The support system 3 is connected to the communication system 2 via at least one of, for example, a LAN line, a wire harness, an internal bus, and a wireless communication line. The communication system 2 is configured to be capable of wireless communication with the autonomous driving device 10 and terminals, etc. The support system 3 includes at least one dedicated computer. The dedicated computer constituting the support system 3 may be a monitoring server that monitors the autonomous driving of the autonomous driving device 10. The dedicated computer constituting the support system 3 may be a management server that integrally manages the operations of a plurality of autonomous driving devices 10. The dedicated computer constituting the support system 3 may be composed of a plurality of servers and its functions may be distributed.

[0030] The dedicated computer that constitutes the support system 3 has at least one memory 4 and one processor 5. The memory 4 is at least one type of non-transitory physical storage medium, such as a semiconductor memory, a magnetic medium, and an optical medium, that non-temporarily stores programs, data, etc. that can be read by the computer. Here, storage may be an accumulation in which data is retained even when the support system 3 is turned on and off, or it may be a temporary storage in which data is erased when the support system 3 is turned on and off. The processor 5 includes at least one type, such as a CPU, a GPU, a RISC-CPU, a CISC-CPU, a DFP, and a GSP, as a core.

[0031] In the support system 3, the processor 5 executes a plurality of instructions included in the support program stored in the memory 4 in order to remotely support the running of the autonomous driving device 10. As a result, the support system 3 constructs a plurality of functional blocks for remotely supporting the running of the autonomous driving device 10. The plurality of functional blocks constructed in the support system 3 include a history generation block 100, a stack monitoring block 110, a setting block 120, a matching block 130, and an output block 140, as shown in FIG. 3.

[0032] By the cooperation of these blocks, the support method by which the support system 3 supports the running of the autonomous driving device 10 is executed according to the remote support flow shown in FIG. 4. This support flow is repeatedly executed during the startup of the support system 3. Note that each "S" in this support flow means a plurality of steps executed by a plurality of instructions included in the support program.

[0033] First, in S10, the history generation block 100 generates operation history data regarding the operation history of the autonomous driving device 10. The operation history data is time-series data of operation information related to the operation of the autonomous driving device 10. The history generation block 100 acquires the operation information transmitted from the autonomous driving device 10 in the current cycle. The history generation block 100 updates the operation history data by adding the acquired operation information to the operation history data up to the previous cycle. Thereby, the history generation block 100 generates operation history data including the operation information up to the current cycle.

[0034] The operation history data includes at least one type of, for example, speed data, acceleration data, attitude data, sound data, temperature data, wheel rotation speed data, external environment monitoring data, processor usage rate data, and memory usage rate data. Note that the external environment monitoring data includes at least one type of, for example, image data by a camera and sensing data by an external environment sensor 13 other than the camera.

[0035] In the subsequent S20, the stack monitoring block 110 monitors the occurrence of a stack in the autonomous driving device 10. Here, the stack is a state in which the driving of the autonomous driving device 10 is inhibited. The stack can also be a state in which the continuous driving of the autonomous driving device 10 becomes impossible. For example, the stack monitoring block 110 determines whether a stack has occurred according to the operation history data and the position information of the autonomous driving device 10.

[0036] The stack monitoring block 110 may determine that a stack has occurred by detecting an inconsistency between the wheel rotation speed data and the position information, such as no change in position despite the wheels rotating. Or, the stack monitoring block 110 may determine that a stack has occurred by detecting an inconsistency between the driving plan and the position information, such as the autonomous driving device 10 not being able to move as per the driving plan. Or, the stack monitoring block 110 may determine that a stack has occurred when the autonomous driving device 10 takes a posture that can be presumed to be a stack state according to the attitude data.

[0037] When it is determined that no stack has occurred, this flow returns to S10 and the generation of operation history data continues. On the other hand, when it is determined that a stack has occurred, this flow shifts to S30.

[0038] In S30, the setting block 120 sets a recovery support level, which is the level set for the recovery support from the stack requested to the supporter 20. For example, the recovery support level is set in correlation with the magnitude of the support risk that occurs when the supporter 20 executes the recovery support required to recover from the occurred stack.

[0039] Here, the support risk is the degree of burden on the supporter 20 that occurs in the support. For example, the support risk includes at least one of the degree of physical burden, the degree of mental burden, and the degree of responsibility imposed on the supporter 20 in the support. The magnitude of the support risk is defined according to the type of support required for recovery and thus the stack factor.

[0040] Therefore, in determining the recovery support level, the setting block 120 first discriminates the stack factor by analyzing the operation history data traced back from the occurrence timing of the stack (hereinafter, stack timing). Then, the setting block 120 sets the recovery support level for each discriminated stack factor.

[0041] A plurality of stack factors are predefined to correlate with patterns in the operation history data. For example, the stack factors are defined to include at least one of collision, fall, abnormal posture, sensor abnormality, foreign object attachment, hardware failure, software failure, unknown cause, etc. Here, foreign object attachment means attachment of a foreign object to a part exposed to the outside for capturing outside information in the outside sensor 13, such as the lens of a camera or the radome of a radar. In the example shown in FIG. 6, the collision as a stack factor is further defined and subdivided into two types of factors depending on whether there is a fall or not. Further, the fall as a stack factor is also further defined and subdivided into two types of factors depending on whether there is a fall or not. Also, the abnormal posture as a stack factor is defined and subdivided into three types of factors: abnormal posture due to a fall, abnormal posture due to wheel detachment, and abnormal posture due to boarding.

[0042] The setting block 120 determines the stack factor based on the operation history data from the stack timing back to a specified time before the stack timing. For example, the setting block 120 determines the presence or absence of a pattern related to the stack from the operation history data, and identifies the stack factor according to the presence or absence of the pattern. For example, when the impact applied to the autonomous driving device 10 correlated with acceleration data or the like exceeds the allowable range, the setting block 120 identifies that a collision or a fall is included in the stack factor. For the setting block 120 to determine which of the collision and the fall is the stack factor, it may be determined based on the magnitude of the impact or the pattern of the impact in time series.

[0043] Also, when the magnitude of the inclination with respect to the normal posture correlated with the posture data or the like exceeds the allowable range, the setting block 120 identifies that a fall is included in the stack factor. Also, when the magnitude of the inclination with respect to the normal posture correlated with the posture data or the like exceeds a set range that is within the allowable range and smaller than the upper limit of the allowable range, the setting block 120 identifies that wheel detachment or boarding is included in the stack factor. For the setting block 120 to determine which of the wheel detachment and the boarding is the stack factor, it may be determined based on the magnitude of the inclination of the posture or the pattern of the posture change in time series.

[0044] That is, when the impact is outside the allowable range and the magnitude of the inclination is outside the allowable range, the setting block 120 identifies that collision and fall are stacking factors. On the other hand, when the impact is outside the allowable range and the magnitude of the inclination is within the allowable range, the setting block 120 identifies that a collision without a fall is a stacking factor.

[0045] Also, when the setting block 120 determines that there is wheel spin correlated with the wheel rotation speed data, it identifies that any one of wheel detachment, riding up, and falling is included in the stacking factors. That is, when the magnitude of the inclination is outside the set range and there is wheel spin, the setting block 120 identifies that the abnormal posture due to falling is a stacking factor. And when the magnitude of the inclination is within the set range and there is wheel spin, the setting block 120 identifies that the abnormal posture due to wheel detachment or riding up is a stacking factor.

[0046] Also, when the setting block 120 detects abnormal noise correlated with the sound data, it identifies that the failure of the hardware is included in the stacking factors. Further, when the processor usage rate correlated with the processor usage rate data is abnormal, the setting block 120 identifies that the failure of the software is included in the stacking factors. Also, when the memory usage rate correlated with the memory usage rate data is abnormal, the setting block 120 identifies that the failure of the software is included in the stacking factors. Further, when the setting block 120 detects an abnormal field of view of the external sensor 13 correlated with the external monitoring data, it identifies that foreign matter adhesion is included in the stacking factors. Also, when there is no pattern related to stacking in any of the operation history data, the setting block 120 identifies that the stacking factor is unknown.

[0047] Then, the setting block 120 sets the recovery support level according to the identified stack factor. The recovery support level corresponding to each stack factor is set in advance according to, for example, the support risk predicted from the stack factor. The setting block 120 sets the recovery support level based on the correspondence information between the stack factor and the recovery support level stored in advance in the memory 4 or the like and the actually identified stack factor. For example, the setting block 120 sets a larger level as the support risk increases.

[0048] For example, as shown in FIG. 6, the setting block 120 sets a large recovery support level in the order of collision with fall, collision without fall, fall with fall, fall without fall, posture abnormality due to fall, posture abnormality due to wheel detachment, posture abnormality due to boarding, sensor abnormality, foreign object attachment, hardware failure, and software failure. Also, when the stack factor is unknown, the setting block 120 sets the same recovery support level as that of the sensor abnormality, that is, level 4. Note that when a plurality of stack factors are identified, the setting block 120 may set the largest level among the recovery support levels corresponding to each stack factor.

[0049] As described above, the setting block 120 sets the recovery support level as a level corresponding to the operation history data traced back from the stack timing.

[0050] In the subsequent S40, the matching block 130 executes the matching of the supporter 20 with respect to the set recovery support level. Specifically, the matching block 130 executes the matching of the number of supporters 20 with respect to the recovery support level and the matching of the type of the supporter 20.

[0051] For example, as shown in FIG. 6, the number of supporters 20 is preset according to the recovery support level. In other words, the number of supporters 20 is preset according to the stack factor. The set number of people is, for example, the number of people (required number) defined as the minimum required to execute support. The correspondence relationship information between the recovery support level and the required number of people is prestored in the memory 4 or the like. The matching block 130 executes the matching of the number of people by specifying the actual required number of people from this correspondence relationship information.

[0052] Regarding the type of matching, the matching block 130 determines whether the actual recovery support level is included in the level range of the recoverable support levels that are preset for each type of supporter 20. When the actual recovery support level is included in the level range, the matching block 130 determines that the supporter 20 of that type matches the recovery support level.

[0053] For example, the types of supporters 20 at least include professional staff 21, temporary staff 22, and other road users 23. The professional staff 21 and the temporary staff 22 are registered in the staff database 150 in advance via terminals or the like possessed by each of the staff 21, 22. At least the identification ID and type of the staff 21, 22 are registered in the staff database 150. The position and available time zone, etc. of the staff 21, 22 may be registered in the staff database 150.

[0054] The professional staff 21 is a supporter 20 that is pre-registered and specializes in the support service. Here, specializing in the support service means engaging in the support service of the autonomous driving device 10 as a job. The professional staff 21 is a person related to the operator of the service provided by the autonomous driving device 10, for example, a person employed by the operator. The service here is the transportation service in the case of this embodiment. Also, the professional staff 21 is a person who waits at the waiting place when not performing support in engaging in the support service.

[0055] Such specialized staff 21 has a supportable recovery support level range set to the High level. That is, the specialized staff 21 has a higher upper limit of the supportable level range than the temporary staff 22 and other road users 23. Specifically, as shown in FIG. 7, the specialized staff 21 is set to be capable of providing recovery support for all levels from level 1 to level 11.

[0056]

[0055] The temporary staff 22 is a supporter 20 that provides support services when the position conditions around the pre-registered autonomous driving device 10 are met. Here, the position conditions are satisfied, for example, when within a predetermined distance range from the autonomous driving device 10. The temporary staff 22 is, for example, a person not related to the operator of the service provided by the autonomous driving device 10, such as a person not in an employment relationship with the operator. In other words, the temporary staff 22 is a person who does not normally engage in the support service as part of their regular duties. The temporary staff 22 is, for example, a store clerk within the service area provided by the autonomous driving device 10.

[0057] Such temporary staff 22 has a supportable level range set to the Mid level. That is, the temporary staff 22 has an upper limit of the supportable level range that is lower than that of the specialized staff 21 and higher than that of other road users 23. Specifically, the temporary staff 22 is set to be capable of providing recovery support for levels from level 1 to level 9.

[0058] Other road users 23 are unregistered persons around the autonomous driving device 10. Other road users 23 are, for example, pedestrians passing by the periphery of the autonomous driving device 10.

[0059] These other road users 23 have a supportable recovery support level range set to the Low level. That is, for other road users 23, the upper limit of the supportable level range is set lower than that of the professional staff 21 and the temporary staff 22. Specifically, other road users 23 are set to be able to provide recovery support at levels 1 to 7.

[0060] The matching block 130 determines, for each type of the above supportors 20, whether the actual recovery support level is included in the supportable level range. The matching block 130 determines that it matches the recovery support level for the type of supportor 20 for which it is determined that the recovery support level is included in the level range.

[0061] In the subsequent S50, the output block 140 outputs support request data for requesting support to the supportor 20 that matches the recovery support level. Regarding the detailed processing of S50, first, in S501 of FIG. 5, the output block 140 determines the matching result of the supportor 20. If it is determined that the recovery support level is included in the High level and only matches the professional staff 21, this flow proceeds to S502.

[0062] In S502, the output block 140 outputs support request data only to the professional staff 21. The support request data includes at least, for example, notification information for notifying the support request. The support request data may include at least one of a stack factor, necessary support content, position information of the stacked autonomous driving device 10, estimated time required for support, etc. Further, the output block 140 may include role information regarding the role in support in the support request data and output it. The role in support is predefined for each recovery support level, in other words, for each stack factor, as shown in FIG. 6. For example, the role includes a support operation for actually operating and moving the autonomous driving device 10, reporting to a predetermined organization, etc., safety confirmation, and traffic control.

[0063] The output block 140 communicates and outputs the support request data as communication data to the professional staff 21 via the communication system 2. For example, the output block 140 communicates and outputs the support request data to a terminal such as a smartphone held by the professional staff 21. Alternatively, the output block 140 may communicate and output the support request data to a communication device installed at the waiting place of the professional staff 21.

[0064] On the other hand, in S501, when it is determined that the recovery support level is included in the Mid level and matches the professional staff 21 and the temporary staff 22, this flow migrates to S503. In S503, the output block 140 outputs the support request data to the professional staff 21 and the temporary staff 22. The information included in the support request data for the professional staff 21 may be substantially the same as that output in S502. Also, the support request data for the temporary staff 22 includes, for example, information substantially the same as the type of information output to the professional staff 21. Note that the support request data for the temporary staff 22 may further include information regarding the incentive data described later. The output block 140 communicates and outputs the support request data for the temporary staff 22 to a terminal such as a smartphone held by the temporary staff 22.

[0065] Also, in S501, when it is determined that the recovery support level is included in the Low level and matches the professional staff 21, the temporary staff 22, and other road users 23, this flow migrates to S504. In S504, the output block 140 outputs the support request data to the professional staff 21, the temporary staff 22, and other road users 23. The output block 140 communicates and outputs the support request data to the professional staff 21 and the temporary staff 22 in the same manner as in S502 and S503. Note that the support request data output to the professional staff 21 and the temporary staff 22 may include, for example, information regarding how many other road users 23 should be gathered in addition to the information in S502 and S503.

[0066] Furthermore, the output block 140 outputs support request data as notification data to other road users 23 around the autonomous driving device 10. The output block 140 requests support from other road users 23 via the information presentation system 16 of the autonomous driving device 10.

[0067] Therefore, the notification data includes, for example, at least a notification instruction for requesting support for the autonomous driving device 10. Also, the notification data may include a notification instruction regarding at least one of a stack factor, necessary support content, expected time required for support, etc. Further, the notification data may further include information regarding incentive data.

[0068] In addition, when it is determined that the stack factor is unknown, the output block 140 may output a request for collecting additional data as support request data. The additional data is, for example, image data of the autonomous driving device 10. When the output block 140 outputs a request for collecting additional data, it guides to a transmission form from a two-dimensional code or the like. The output block 140 causes it to be displayed on the information presentation system 16 of the autonomous driving device 10 for preventing forgery of the two-dimensional code. Also, in the image data of the autonomous driving device 10, the autonomous driving device 10 may be informed so that the time and the like can be confirmed from the reflected autonomous driving device 10.

[0069] Returning to FIG. 4, in S60, the output block 140 determines whether the support by the supporter 20 has been completed. The output block 140 may determine whether the support has been completed based on, for example, a support completion report from the terminals of the staff 21, 22, a support completion notification by the autonomous driving device 10, etc. When it is determined that the support has been completed, this flow proceeds to S70. In S70, the output block 140 determines whether the supporter 20 who has implemented the support is an incentive target. The incentive targets are, for example, the temporary staff 22 and other road users 23.

[0070] When it is determined that the supporter 20 is an incentive target, this flow proceeds to S80. In S80, the output block 140 executes an incentive granting process. Specifically, the output block 140 outputs incentive data to the supporter 20. The incentive data is at least one type among, for example, electronic money, service points, and coupons.

[0071] In addition, the output block 140 may change the amount of incentive to be granted according to the scene. For example, the output block 140 may grant more incentives as the priority of the luggage being transported is higher. The priority of the luggage is set higher, for example, as the remaining time until the specified delivery deadline is shorter. Also, the output block 140 may grant more incentives as the number of supporters 20 estimated to be actually supportable is smaller.

[0072] In addition, when other road users 23 are included in the incentive granting target, the output block 140 executes a notice prompting registration. In this case, the output block 140 may output a presentation instruction for the notice prompting registration and a use instruction as an access point of the communication system 11 of the autonomous driving device 10 to the autonomous driving device 10.

[0073] In addition, the output block 140 may treat the other road users 23 registered by the user as temporary staff 22 hereafter. Alternatively, the output block 140 may set a different level range as a different type of supporter 20 from the temporary staff 22 and the unregistered other road users 23. Alternatively, the output block 140 may set the same level range as that of the unregistered other road users 23 for the registered other road users 23 as well.

[0074] According to the above first embodiment, when a stack occurs in the autonomous driving device 10, support request data is output to the supporter 20 that matches the recovery support level corresponding to the operation history data traced back from the occurrence timing of the stack. Therefore, it may be possible to request support from the supporter 20 suitable for the recovery support level. Also, this can increase the possibility that the supporter 20 responding to the request can bear the support. As a result, it becomes easier to avoid situations such as further recruiting a supporter 20 that can bear the support when the requested supporter 20 cannot bear it, and thus the time until the start of support can be shortened.

[0075] Also, according to the first embodiment, support request data is output to the number of supporters 20 that match the recovery support level for each stack factor analyzed from the operation history data. Therefore, it may be possible to request support from the number of supporters 20 suitable for the recovery support level. Accordingly, it may be possible to increase the possibility that the supporter 20 responding to the request can bear the support with the requested number of people, and the time until the start of support can be shortened.

[0076] Furthermore, according to the first embodiment, the support request data is output to the type of supporter 20 whose preset supportable recovery support level range for each type of supporter 20 matches the recovery support level corresponding to the operation history data. Therefore, support can surely be requested from the type of supporter 20 that can bear the recovery support according to the operation history data.

[0077] In addition, according to the first embodiment, support request data is output to a type of supporter 20 in which the supportable level range preset for each type of supporter 20 matches the recovery support level for each stack factor analyzed from the operation history data. Therefore, support can be surely requested from a type of supporter 20 capable of bearing the support required according to the stack factor. Accordingly, the possibility of receiving support from the supporter 20 that has responded to the support request according to the stack factor can be increased.

[0078] Also, according to the first embodiment, support request data is output to a type of supporter 20 in which the supportable level range preset for each type of supporter 20 matches the recovery support level according to the support risk predicted from the stack factor. Therefore, support can be surely requested from a type of supporter 20 that can tolerate the support risk predicted from the stack factor.

[0079] Furthermore, according to the first embodiment, the type of supporter 20 includes specialized staff 21 who are pre-registered and specialized in support services. Therefore, it is possible to request support from the specialized staff 21 as the supporter 20 specialized in support services.

[0080] In addition, according to the first embodiment, the type of supporter 20 includes temporary staff 22 who are pre-registered and provide support services when the position conditions around the autonomous driving device 10 are satisfied. Therefore, it is possible to request support from the pre-registered temporary staff 22 according to the position conditions.

[0081] Also, according to the first embodiment, incentive data is output for the recovery support by the pre-registered temporary staff 22. Therefore, it may be possible to give the temporary staff 22 an incentive to bear the support. Accordingly, the possibility of actually receiving support from the temporary staff 22 that has requested support can be increased.

[0082] Furthermore, according to the first embodiment, the types of the supporters 20 include unregistered other road users 23 around the autonomous driving device 10. Therefore, appropriate support can be requested for the unregistered other road users 23 as well, according to the matching results. Thus, for any support that matches the other road users 23, it may be possible to receive support without requesting support for each supporter 20 specialized for the support service one by one.

[0083] In addition, according to the first embodiment, registration of the user information of the other road user 23 who accessed the autonomous driving device 10 in response to the output of the support request data is executed. Therefore, it may be possible to grasp the other road users 23 who responded to the support request. As a result, it may be easier to provide information related to support to the other road users 23 who are relatively proactive in providing support.

[0084] Also, according to the first embodiment, incentive data is output for the recovery support by the registered other road users 23. Therefore, it may be possible to motivate the registered other road users 23 to bear the support also in the future. Thus, the possibility of actually receiving support from the other road users 23 who requested support may increase.

[0085] Furthermore, according to the first embodiment, the support request data includes communication data that is communicated and output from the autonomous driving device 10. Therefore, support can surely be requested from remote supporters 20.

[0086] In addition, according to the first embodiment, the support request data includes notification data that is notified and output around the autonomous driving device 10. Therefore, support can surely be requested from supporters 20 relatively close to the autonomous driving device 10.

[0087] (Second Embodiment) As shown in FIG. 8, the second embodiment is a modification of the first embodiment.

[0088] In the second embodiment, when it is determined in S501 that the recovery support level is at the Low level, this flow proceeds to S505. In S505, the output block 140 outputs notification data to the autonomous driving device 10. Then, the output block 140 stops outputting the support request data as communication data. In other words, when the recovery support level is at a level that can also be supported by other road users 23, the output block 140 stops without executing the support request for the professional staff 21 and the temporary staff 22. That is, when there are a plurality of types of supporters 20 whose level ranges include the current recovery support level, the matching block 130 preferentially selects the supporter 20 of the type with a lower upper limit of the level range as the supporter 20 to be matched.

[0089] In the subsequent S506, the output block 140 sets the waiting time for waiting for support from other road users 23. In the subsequent S507, the output block 140 determines whether the estimated number of supporters has reached the allowable number. The estimated number of supporters is the number of other road users 23 estimated to be expected as supporters 20 of the autonomous driving device 10. The output block 140 acquires external information from the autonomous driving device 10 and estimates the estimated number of supporters from the external information. For example, the output block 140 regards other road users 23 recognized as heading towards the autonomous driving device 10 as other road users 23 estimated to be expected as supporters 20.

[0090] Note that the output block 140 may determine user information such as the gender, physique, and age group of other road users 23 by image recognition of the captured image data by the external sensor 13 of the autonomous driving device 10, and use the number of people matching the recovery support level as the estimated number of supporters.

[0091] The allowable number is a threshold of the estimated number of supporters that can be supported only by other road users 23. The allowable number is set, for example, in correlation with the recovery support level. The allowable number may be the required number of people set for the recovery support level as shown in FIG. 6, or may be the number of people obtained by adding a margin to the required number of people.

[0092] When it is determined that the estimated number of supporters is less than the allowable number, this flow proceeds to S508. In S508, the output block 140 executes a process of decreasing the set waiting time. The output block 140 may decrease the time for a pre-specified period. Alternatively, the output block 140 may decrease the time for a period correlated with the estimated number of supporters.

[0093] On the other hand, when it is determined that the estimated number of supporters reaches the allowable number, this flow proceeds to S509. In S509, the output block 140 executes a process of increasing the set waiting time. The output block 140 may increase the time for a pre-specified period, or may decrease the time for a period correlated with the estimated number of supporters.

[0094] Note that the output block 140 may determine the magnitude of the increase or decrease in time in S508 and S509 from statistical information previously accumulated as the statistics of the number of people within a certain range in the service-providing area. In this case, the output block 140 may assign weights to the increase or decrease in time according to the day of the week, time zone, weather, presence or absence of surrounding events, and the like.

[0095] Next, in S510, the output block 140 determines whether the detectability of the autonomous driving device 10 has reached an acceptable range. The detectability is a parameter related to the ease of being found by other road users 23 of the autonomous driving device 10. For example, the detectability is the size of the surrounding visibility range from the autonomous driving device 10, that is, the range not blocked by obstacles. The greater the detectability, the easier it is for the autonomous driving device 10 to be detected by other road users 23. Here, the acceptable range is the range where the detectability is equal to or exceeds the threshold value. For example, when there is a range without obstacles where the azimuth angle is the threshold angle and the distance from the autonomous driving device 10 is equal to or greater than the threshold distance, the output block 140 determines that the detectability is within the acceptable range, and when it does not exist, it determines that the detectability is outside the acceptable range.

[0096] If it is determined that the detectability has not reached the acceptable range, this flow proceeds to S511. In S511, the output block 140 executes a process of decreasing the set waiting time. The output block 140 may decrease by a preset time or may decrease by a time correlated with the detectability. On the other hand, if it is determined that the detectability has reached the acceptable range, this flow proceeds to S512. In S512, the output block 140 executes a process of increasing the set waiting time. The output block 140 may increase by a preset time or may decrease by a time correlated with the detectability.

[0097] In the subsequent S513, the output block 140 determines whether support by other road users 23 has been started. The output block 140 determines the presence or absence of the start of support based on, for example, the position and movement of other road users 23 according to the external information acquired from the autonomous driving device 10. If it is determined that the support has not been started, this flow proceeds to S514. In S514, the output block 140 determines whether the waiting time has elapsed since the support was requested. If it is determined that the waiting time has not elapsed, this flow returns to S514.

[0098] On the other hand, when it is determined that the waiting time has elapsed since the support request, this flow proceeds to S515. In S515, the output block 140 outputs support request data to the professional staff 21 and the temporary staff 22. That is, the output block 140 outputs support request data to the higher-level supporters whose upper limit of the recoverable support level that can be handled is higher than that of other road users 23. Note that the output block 140 may selectively output support request data to either the professional staff 21 or the temporary staff 22. Also, the output block 140 may apply the preferential selection of the supporter 20 with a lower upper limit of the level range in S503 as well. That is, in S503, the output block 140 may output support request data only to the temporary staff 22.

[0099] (Other Embodiments) Although a plurality of embodiments have been described above, the present disclosure is not to be construed as being limited to those embodiments, and can be applied to various embodiments and combinations without departing from the gist of the present disclosure.

[0100] In a modification, the dedicated computer constituting the support system 3 may have at least one of a digital circuit and an analog circuit as a processor. Here, the digital circuit is, for example, at least one type among ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), SOC (System on a Chip), PGA (Programmable Gate Array), and CPLD (Complex Programmable Logic Device). Also, such a digital circuit may have a memory storing a program.

[0101] In a modification, when the cause of the stack is unknown, the output block 140 may request the collection of additional information from infrastructure facilities, other surrounding autonomous driving devices, etc. in addition to or instead of other road users 23.

[0102] In a modification, in addition to the stack factor, the setting block 120 may set the recovery support level according to information other than the stack factor. For example, when there is environmental information related to support risk in addition to the stack factor, the setting block 120 may correct and set the recovery support level corresponding to the stack factor. The environmental information includes, for example, at least one of internal environmental information related to the autonomous driving device 10 and external environmental information related to the outside of the autonomous driving device 10. The internal environmental information is, for example, the weight of the autonomous driving device 10, the presence or absence of heat generation, etc. The external environmental information is, for example, weather information in the stacked area, etc.

[0103] In a modification, when another road user 23 attempts to execute support, the output block 140 may output an instruction for notifying the autonomous driving device 10 to execute user registration before support.

[0104] In a modification, the setting block 120 may determine the stack factor by obtaining the determination result of the stack factor by the operator of the remote center 1. For example, the setting block 120 may determine the stack factor by receiving the input of the stack factor determined by the operator from an external image or the like. Also, when the stack factor is unknown, the setting block 120 may obtain the determination result by the operator.

[0105] In a modification, the output block 140 may output an authentication request by the terminal of the supporter 20 as support request data. The output block 140 may perform remote monitoring of the supporter 20 that executes support.

[0106] In a modification, the autonomous driving device 10 may be provided with equipment that can be used for support. For example, the autonomous driving device 10 may store tools such as a jack as equipment in a storage space provided in the vehicle body. Note that the equipment may be a component integrally attached to the autonomous driving device 10. Further, the output block 140 of the support system 3 may output, including in the support request data, equipment information such as the presence and usage method of the equipment.

[0107] In a modification, the setting block 120 may set a recovery support level according to the equipment in the autonomous driving device 10. Alternatively, the matching block 130 may perform matching of the supporter 20 according to the equipment in the autonomous driving device 10.

[0108] In a modification, the autonomous driving device 10 may be provided with an interface that can be manually moved by a switch operation. Further, the output block 140 may output, including in the support request data, a request for a monitoring role that permits a switch operation of another supporter 20 to the supporter 20. Further, the output block 140 may output, including in the support request data, a request for a monitoring role that monitors an operation of pushing the vehicle body of the autonomous driving device 10 by another supporter 20 to a specific supporter 20.

[0109] In a modification, when the output block 140 outputs support request data to a plurality of types of supporters 20, the role of the requested support may be changed according to the type. For example, when the recovery support level is levels 5 to 7, the output block 140 may request the role of safety confirmation only to the professional staff 21 or the temporary staff 22, and request other roles to other road users 23.

[0110] In a modification, the autonomous driving device 10 may be used for purposes other than cargo transportation. For example, the autonomous driving device 10 may be a cleaning robot that cleans a road surface or the like.

[0111] In addition to the description forms up to here, the support system 3 in the above-described embodiments and modifications may be implemented as a control device having at least one processor 5 and one memory 4. Specifically, the support system 3 may be implemented in the form of a processing circuit (for example, a processing ECU or the like) or a semiconductor device (for example, a semiconductor chip or the like).

[0112] (Disclosure of Technical Ideas) This specification discloses a plurality of technical ideas described in a plurality of claims listed below. Some claims may be described in a multiple dependent form in which a preceding claim is alternatively cited in a subsequent claim. Further, some claims may be described in a multiple dependent form that refers to another multiple dependent form claim. The claims described in these multiple dependent forms define a plurality of technical ideas.

[0113] (Technical Idea 1) A support system having a processor (5) and supporting an autonomous driving device (10), wherein the processor generates operation history data of the autonomous driving device, monitors the occurrence of a stack as a state in which the driving of the autonomous driving device is inhibited, outputs support request data to a supporter (20) capable of executing recovery support from the stack, the support request data being at a recovery support level that matches a level of the recovery support from the stack according to the operation history data traced back from the occurrence timing of the stack, and is configured to perform the above.

[0114] (Technical Idea 2) Outputting the support request data The support system according to Technical Idea 1, including outputting at least the support request data to the supporter whose number matches the recovery support level for each stack factor analyzed from the operation history data.

[0115] (Technical Idea 3) Outputting the support request data The support system according to Technical Idea 1 or Technical Idea 2, including outputting the support request data to the supporter of the type that matches the level range of the recoverable support level that can be supported and is preset for each type of the supporter, and the recoverable support level according to the operation history data.

[0116] (Technical Idea 4) Outputting the support request data The support system according to Technical Idea 3, including outputting the support request data to the supporter of the type that matches the level range of the recoverable support level that can be supported and is preset for each type of the supporter, and the recoverable support level for each stack factor analyzed from the operation history data.

[0117] (Technical Idea 5) The support system according to Technical Idea 4, including outputting the support request data to the supporter of the type that matches the level range of the recoverable support level that can be supported and is preset for each type of the supporter, and the recoverable support level according to the support risk predicted from the stack factor.

[0118] (Technical Idea 6) The type of the supporter includes a professional staff (21) who is pre-registered and specializes in support services, and the support system according to any one of Technical Ideas 3 to 5.

[0119] (Technical Idea 7) The type of the supporter is the support system according to any one of Technical Ideas 3 to 6 including a temporary staff (22) that provides a support service when the type of the supporter is pre-registered and satisfies the position conditions around the autonomous driving device.

[0120] (Technical Idea 8) The processor is configured to execute outputting incentive data for the recovery support by the pre-registered temporary staff, which is the support system according to Technical Idea 7.

[0121] (Technical Idea 9) The type of the supporter is the support system according to any one of Technical Ideas 3 to 8 including unregistered other road users (23) around the autonomous driving device.

[0122] (Technical Idea 10) The processor is configured to execute registering the user information of the other road user who accessed the autonomous driving device in response to the output of the support request data, which is the support system according to Technical Idea 9.

[0123] (Technical Idea 11) The processor is configured to execute outputting incentive data for the recovery support by the registered other road user, which is the support system according to Technical Idea 10.

[0124] (Technical Idea 12) Outputting the support request data includes preferentially outputting the support request data to the supporter of the type with the lowest upper limit of the level range when multiple types of supporters are matched, which is the support system according to any one of Technical Ideas 3 to 11.

[0125] (Technical Idea 13) The support request data is a support system according to any one of Technical Ideas 1 to 12 including communication data that is communicated and output from the autonomous driving device.

[0126] (Technical Idea 14) The support request data is a support system according to any one of Technical Ideas 1 to 13 including notification data that is notified and output around the autonomous driving device.

[0127] In addition, the above Technical Ideas 1 to 14 may be implemented in the form of a support method and a support program.

Explanation of Signs

[0128] 3: Support system, 4: Memory (storage medium), 5: Processor, 10: Autonomous driving device, 20: Supporter, 21: Specialist staff, 22: Temporary staff, 23: Other road users

Claims

1. A support system having a processor (5) for assisting an autonomous driving device (10), wherein the processor is configured to generate operation history data of the autonomous driving device, monitor the occurrence of a stack as a state in which the driving of the autonomous driving device is inhibited, output support request data to a supporter (20) capable of executing recovery support from the stack, the support request data being matched to a recovery support level that is a level of the recovery support from the stack and that corresponds to the operation history data traced back from the timing of the occurrence of the stack, and is configured to execute the above. The support system.

2. Outputting the support request data includes outputting at least the support request data to a number of the supporters that match the recovery support level for each stack factor analyzed from the operation history data. The support system according to claim 1.

3. Outputting the support request data includes outputting the support request data to a supporter of a type in which a preset supportable level range of the recovery support level for each type of the supporter matches the recovery support level corresponding to the operation history data. The support system according to claim 1.

4. Outputting the support request data includes outputting the support request data to a supporter of a type in which a preset supportable level range of the recovery support level for each type of the supporter matches the recovery support level for each stack factor analyzed from the operation history data. The support system according to claim 3.

5. includes outputting the support request data to a supporter of a type in which a preset supportable level range of the recovery support level for each type of the supporter matches the recovery support level according to a support risk predicted from the stack factor. The support system according to claim 4.

6. The type of the supporter includes a professional staff member (21) who is pre-registered and specializes in support services. The support system according to claim 3.

7. The type of the supporter includes a temporary staff (22) that provides a support service when it is pre-registered and satisfies the position conditions around the autonomous driving device, according to the support system of claim 3.

8. The processor is configured to execute outputting incentive data for the recovery support by the pre-registered temporary staff, according to the support system of claim 7.

9. The type of the supporter includes an unregistered other road user (23) around the autonomous driving device, according to the support system of claim 3.

10. The processor is configured to execute registering the user information of the other road user who accessed the autonomous driving device in response to the output of the support request data, according to the support system of claim 9.

11. The processor is configured to execute outputting incentive data for the recovery support by the registered other road user, according to the support system of claim 10.

12. Outputting the support request data includes preferentially outputting the support request data to the supporter of the type with the lowest upper limit of the level range when a plurality of types of the supporters match, according to the support system of claim 3.

13. The support request data includes communication data that is communicated and output from the autonomous driving device, according to the support system of claim 1.

14. The support request data includes notification data that is notified and output around the autonomous driving device, according to the support system of claim 1.

15. A support method executed by a processor (5) to support an autonomous driving device (10), comprising: generating operation history data of the autonomous driving device; monitoring the occurrence of a stack as a state in which the driving of the autonomous driving device is inhibited; outputting support request data to a supporter (20) capable of executing recovery support from the stack, the supporter matching a recovery support level that is a level of the recovery support from the stack and corresponding to the operation history data traced back from the occurrence timing of the stack; A support method including the above.

16. A support program stored in a storage medium (4) and including instructions to be executed by a processor (5) for supporting an autonomous driving device (10), wherein the instructions cause generation of operation history data of the autonomous driving device, monitor generation of a stack as a state in which running of the autonomous driving device is inhibited, output support request data to a supporter (20) capable of executing recovery support from the stack, the supporter being matched to a recovery support level from the stack, the recovery support level being a level corresponding to the operation history data traced back from a generation timing of the stack, and the support program includes the above.

Images