vehicle

Abstract

The system reduces the load on the autonomous driving kit (autonomous driving system) while performing appropriate vehicle control in each of the multiple control modes. [Solution] A vehicle capable of being equipped with ADK (Autonomous Driving Kit) comprises a VCIB (Vehicle Control Interface Box) and a vehicle system (base vehicle). The VCIB is configured to switch the control mode of the vehicle system in response to a first command from ADK. The VCIB is configured to prohibit the transition from manual mode to automatic mode based on the first command if it detects that communication between the VCIB and ADK has been interrupted, and to release the prohibition based on the receipt of a second command from ADK.

Description

Technical Field

[0001] The present disclosure relates to a vehicle capable of mounting an autonomous driving kit.

Background Art

[0002] Japanese Unexamined Patent Application Publication No. 2024-139411 (Patent Document 1) discloses that in the automatic mode, when a communication abnormality occurs between the autonomous driving kit and the vehicle control interface box, the AFSS (ADK Failure Stop System) is activated to decelerate the vehicle until the vehicle stops by the AFSS. In this control, when the vehicle stops and is immobilized, the vehicle mode transitions to the manual mode.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Patent Document 1 does not disclose the processing after the vehicle mode becomes the manual mode. There is a problem that if the vehicle mode transitions to the automatic mode before the communication between the autonomous driving kit and the vehicle control interface box is restored, the AFSS will be activated again.

[0005] Therefore, one possible approach is to prohibit the transition to automatic mode until the vehicle system (the control system of the base vehicle) is restarted. After communication is restored, restarting the vehicle system will allow the vehicle mode to transition to automatic mode. However, with this method, if a communication interruption occurs, automatic mode cannot be executed until the vehicle system is restarted. Furthermore, restarting the vehicle system takes time. Since users may intentionally stop communication between the autonomous driving kit and the vehicle control interface box for purposes such as maintenance or data collection, requiring a vehicle system restart every time a communication interruption occurs would greatly impair user convenience.

[0006] This disclosure was made to solve the above-mentioned problems, and its purpose is to appropriately control mode transitions after a communication interruption occurs between the autonomous driving kit and the vehicle control interface box. [Means for solving the problem]

[0007] According to one embodiment of the present disclosure, the following vehicle is provided, which is configured to be equipped with an autonomous driving kit. The vehicle comprises a vehicle control interface box and a vehicle system. The vehicle control interface box is configured to switch the control mode of the vehicle system in response to a first command from the autonomous driving kit. The control modes include an automatic mode in which the vehicle is under the control of the autonomous driving kit and a manual mode in which the vehicle is under the control of a driver. The vehicle control interface box is configured to prohibit the transition from manual mode to automatic mode based on the first command if it detects that communication between the vehicle control interface box and the autonomous driving kit has been interrupted, and to release the prohibition based on the receipt of a second command from the autonomous driving kit. [Effects of the Invention]

[0008] According to this disclosure, it becomes possible to properly control mode transitions after a communication interruption occurs between the autonomous driving kit and the vehicle control interface box. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows the schematic configuration of a vehicle according to an embodiment of the present disclosure. [Figure 2] This figure shows the details of each system built into the vehicle shown in Figure 1. [Figure 3] This flowchart shows the process related to operation control according to this embodiment. [Figure 4] This is a diagram illustrating the mode transition control according to this embodiment. [Figure 5] This figure shows the vehicle's state transitions based on the mode transition control shown in Figure 4. [Modes for carrying out the invention]

[0010] The embodiments of this disclosure will be described in detail below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and their descriptions will not be repeated.

[0011] Figure 1 is a diagram showing the schematic configuration of a vehicle according to this embodiment. Referring to Figure 1, vehicle 1 comprises a VP (vehicle platform) 100 and an ADK (autonomous driving kit) 200. The VP 100 includes a vehicle control interface box (hereinafter referred to as "VCIB") 110 and a base vehicle 120. By adding the VCIB 110 to the base vehicle 120, a VP 100 is formed to which the ADK 200 can be attached and detached. The VCIB 110 is configured to communicate with both the base vehicle 120 and the ADK 200 via a communication bus. The vehicle 1 is completed by attaching the ADK 200 to the VP 100.

[0012] The base vehicle 120 is, for example, a commercially available xEV (electric vehicle). In this embodiment, a BEV (battery electric vehicle) is used as the base vehicle 120. However, it is not limited to this, and the base vehicle 120 may be an xEV other than a BEV. The base vehicle 120 includes an integrated control manager 130, an HMI (Human Machine Interface) 150, and various systems and sensors for controlling the base vehicle 120 (wheel speed sensors 127A, 127B, steering angle sensor 127C, camera 129A, radar sensors 129B, 129C, etc.). The integrated control manager 130 functions as a control device. The integrated control manager 130 integrates and controls various systems related to the operation of the base vehicle 120 based on the detection results of the on-board sensors. The integrated control manager 130 and the HMI 150 are communicated together. The HMI 150 includes an input device and a notification device. Examples of notification devices include a display and a speaker. The HMI 150 may also include a touch panel display.

[0013] The mobile terminal 500 is carried and operated by the user of vehicle 1. The mobile terminal 500 is, for example, a smartphone equipped with a touch panel display. The mobile terminal 500 has a built-in computer and is configured to communicate with ADK200.

[0014] Figure 2 shows the details of each system installed in vehicle 1. Referring to Figure 2 in conjunction with Figure 1, ADK200 includes an automated driving system (hereinafter referred to as "ADS") 210 for the automated driving of vehicle 1. ADS210 includes a computer assembly (hereinafter referred to as "ADSCOM") 211, a recognition sensor 212, a posture sensor 213, a sensor cleaner 216, and an HMI (Human Machine Interface) 218.

[0015] ADSCOM211 includes computer modules (hereinafter referred to as "ADC") 211A and 211B. Each of ADC211A and 211B includes a processor and a storage device for storing autonomous driving software using the API described later, and is configured so that the autonomous driving software can be executed by the processor. Recognition sensors 212 include sensors that acquire information indicating the external environment of vehicle 1 (hereinafter also referred to as "environmental information"). Recognition sensors 212 may include at least one of a camera, millimeter-wave radar, and lidar. Attitude sensors 213 acquire information regarding the attitude of vehicle 1 (hereinafter also referred to as "attitude information"). Attitude sensors 213 may include various sensors that detect the acceleration, angular velocity, and position of vehicle 1. HMI218 includes input devices and notification devices.

[0016] The base vehicle 120 includes a brake system 121, a steering system 122, a powertrain system 123, an active safety system 125, and a body system 126. In this embodiment, each system is equipped with an electronic control unit (hereinafter also referred to as "ECU").

[0017] In vehicle 1, the control system for the vehicle's behavior (driving, stopping, turning) has redundancy. Specifically, ADC211A and 211B give instructions to the main system and sub-system, respectively. VCIB110 includes the VCI control unit 110A for the main system, the VCI control unit 110B for the sub-system, and storage 110C. Each of the VCI control units 110A and 110B may be a computer equipped with a processor and storage device. The VCI control units 110A and 110B may communicate directly with each system, or they may communicate via the integrated control manager 130 (Figure 1). Storage 110C will be described later.

[0018] The braking system 121 includes a braking device, an operation unit that receives a braking operation from the user, a main-system braking control unit 121A, and a sub-system braking control unit 121B. In the braking system 121, each of the braking control units 121A and 121B is configured to control the braking device. The braking device may be a hydraulic disk braking device. The braking device functions as a service brake. The braking device applies a braking force to the wheels of the vehicle 1.

[0019] The steering system 122 includes a steering device, an operation unit that receives a steering operation from the user, a main-system steering control unit 122A, and a sub-system steering control unit 122B. The power train system 123 includes a shift device (not shown), an EPB device 123A, a P-Lock device 123B, and a propulsion system 123C. "EPB" means an electric parking brake, and "P-Lock" means a parking lock.

[0020] The shift device determines a shift range and switches the propulsion direction and the shift mode of the base vehicle 120 according to the determined shift range. The shift device includes a transmission mechanism and an operation unit that receives a shift operation from the user. The propulsion system 123C includes a vehicle drive device, an operation unit that receives an accelerator operation from the user, and a propulsion control unit that controls the vehicle drive device. The vehicle drive device applies a propulsion force in the propulsion direction indicated by the shift range to the wheels. The base vehicle 120 accelerates by this propulsion force. The vehicle drive device includes a battery and a traveling motor that receives power supply from the battery.

[0021] The EPB device 123A includes, for example, a parking brake mechanism, an electric actuator, and an operation unit that receives an EPB request from a user. The EPB device 123A may be configured to apply a braking force to a wheel by the electric actuator to fix (immobilize) the wheel. The P-Lock device 123B includes, for example, a parking lock mechanism, an actuator, and an operation unit that receives a parking operation from a user. The P-Lock device 123B may be configured to mechanically fix the rotational position of the output shaft of the transmission by a parking lock pole that can be driven by the actuator.

[0022] The active safety system 125 includes, for example, a PCS (Pre Collision Safety) system, an EDSS (Emergency Driving Stop System), and an AFSS (ADK Failure Stop System).

[0023] In this embodiment, a signal (API signal) defined by an API (Application Program Interface) is used for communication between the ADK 200 and the VCIB 110. The ADK 200 is configured to process various signals defined by the API. The ADK 200 outputs various commands to the VCIB 110 according to the API. Hereinafter, each of the various commands output from the ADK 200 to the VCIB 110 is also referred to as an "API command". Further, the ADK 200 receives various status signals indicating the state of the base vehicle 120 from the VCIB 110 according to the above API. Hereinafter, each of the various status signals received by the ADK 200 from the VCIB 110 is also referred to as an "API status". Both the API command and the API status correspond to the API signal.

[0024] In this embodiment, the ADK 200 uses the API commands described below.

[0025] The vehicle mode command is an API command that requests a transition to automatic or manual mode. Automatic and manual modes are described later. The forward direction command is an API command that requests a switch in the shift range (R / D). The acceleration command is an API command that specifies the vehicle's acceleration. The acceleration command requests acceleration (+) and deceleration (-) in the direction indicated by the forward direction status, which is described later. The front wheel steering angle command is an API command that requests steering of the vehicle's front wheels. The immobilization command is an API command that requests the application or release of immobilization.

[0026] The above describes some of the API commands used in vehicle 1. The VCIB110 receives various API commands from the ADK200. When the VCIB110 receives an API command from the ADK200, it converts that API command into a signal format that the control system of the base vehicle 120 can execute. Hereinafter, the API command converted into a signal format that the control system of the base vehicle 120 can execute will also be referred to as an "internal command". When the VCIB110 receives an API command from the ADK200, it outputs an internal command corresponding to that API command to the base vehicle 120. In the base vehicle 120, the control system is constructed by multiple control devices (for example, the integrated control manager 130 and the control devices of each system shown in Figures 1 and 2).

[0027] Next, let's discuss API status. ADK200 uses API status, as described below, to understand the status of the base vehicle 120.

[0028] The Vehicle Mode Status is an API status that indicates the vehicle mode of the base vehicle 120. The vehicle mode of the base vehicle 120 corresponds to the control mode of the vehicle system in the base vehicle 120. The vehicle mode includes manual mode and automatic mode. Manual mode is the vehicle mode in which the base vehicle 120 is under the control of a driver (human). Automatic mode is the vehicle mode in which the base vehicle 120 is under the control of an autonomous driving kit. Initially, the vehicle mode is manual mode. The Vehicle Mode Status outputs the values ​​"0" and "1" respectively when the current vehicle mode is manual mode or automatic mode.

[0029] The forward direction status is an API status indicating the current shift range. The direction of travel status is an API status indicating the direction of travel of the vehicle. The direction of travel status outputs a value of "0" when the vehicle is moving forward, a value of "1" when the vehicle is moving backward, and a value of "2 (Standstill)" when all wheels (4 wheels) have a speed of "0" for a certain period of time. The vehicle speed status is an API status indicating the longitudinal speed of the vehicle. The vehicle speed status outputs the absolute value of the vehicle speed. The immobilization status is an API status indicating an immobilized state (e.g., EPB and shift P state).

[0030] The above describes some of the API statuses used in vehicle 1. The VCIB110 receives various sensor detection values ​​and status determination results from the base vehicle 120 and outputs various API statuses indicating the status of the base vehicle 120 to the ADK200. The VCIB110 acquires an API status in which a value indicating the status of the base vehicle 120 is set and outputs the obtained API status to the ADK200. The various API statuses are stored in the respective storage devices of the VCI control units 110A and 110B, for example, and are updated sequentially.

[0031] Figure 3 is a flowchart showing the process related to driving control performed by the base vehicle 120. The process flow F1 shown in Figure 3 is repeatedly executed by one of the control devices provided in the base vehicle 120. In the flowchart, "S" represents a step.

[0032] Referring to Figure 3, in processing flow F1, the base vehicle 120 determines in S10 whether or not to perform driving control in manual mode. The vehicle mode (driving control) is changed in response to a request from, for example, ADK200 (vehicle mode command) or VCIB110 (see S33 in Figure 4, described later). The vehicle mode command is sent from ADK200 to the base vehicle 120 via VCIB110 (see S53 in Figure 4, described later).

[0033] If the base vehicle 120 is performing driving control in manual mode (YES in S10), the base vehicle 120 acquires user operations related to the operation of vehicle 1 in S11. Specifically, the base vehicle 120 acquires the amount of operation (accelerator operation amount, brake operation amount, steering operation amount, etc.) and change operations (shift change operation, etc.) for various control parts related to the manual operation of vehicle 1. Subsequently, in S12, the base vehicle 120 performs manual driving control based on the acquired user operations. On the other hand, if the base vehicle 120 is performing driving control in automatic mode (NO in S10), the base vehicle 120 performs automatic driving control based on driving commands from ADK200 in S13 to S15, as described below.

[0034] In S13, the detection results and status determination results from various sensors indicating the status of the base vehicle 120 are transmitted from the base vehicle 120 to the VCIB110, and the various API statuses corresponding to the status of the base vehicle 120 are transmitted from the VCIB110 to the ADK200. This initiates the processing flow F2 by the ADK200.

[0035] In S21, the ADK200 receives various API statuses from the VCIB110, and in the following S22, it creates a driving plan for autonomous driving based on the various API statuses obtained from the VCIB110 and the environmental and attitude information obtained by the ADK200 itself. The driving plan is data that shows the target behavior of vehicle 1 over a predetermined period. The ADK200 may calculate the behavior of vehicle 1 (attitude, etc.) and create a driving plan that is suitable for the state of vehicle 1 and the external environment. In the following S23, the ADK200 determines various API commands (propulsion direction command, acceleration command, front wheel steering angle command, immobilization command, etc.) to execute the control required by the created driving plan (e.g., at least one of acceleration control, deceleration control, steering control, and parking control). The ADK200 may calculate the control physical quantities (acceleration, tire steering angle, etc.) required by the driving plan and determine the various API commands based on the calculation results. In the subsequent S24, the determined API commands are sent from ADK200 to VCIB110, and the corresponding driving commands (internal commands) are sent from VCIB110 to the base vehicle 120. This completes processing flow F2, and processing proceeds to S14. The driving commands correspond to automatic driving commands from ADK200 to the control system of the base vehicle 120. VCIB110 performs signal conversion between ADK200 and the base vehicle 120 to enable communication between them.

[0036] In S14, the base vehicle 120 receives various driving commands from the VCIB 110, and in the following S15, it performs automatic driving control based on those driving commands. Once the processing in S12 or S15 is completed, the process returns to the first step (S10). This allows the driving control (S12 or S15) to be performed continuously.

[0037] In this embodiment, both the VCI control units 110A and 110B shown in Figure 2 are configured to access the storage 110C. An example of the storage 110C is an SSD (Solid State Drive). The VCIB110 in this embodiment sequentially stores various data collected by the vehicle 1 (for example, detection results from various sensors, and the values ​​of API commands and API status related to the behavior of the vehicle 1) in the storage 110C. Since the collected data also includes images taken by cameras, a huge amount of data is stored in the storage 110C. For this reason, the user periodically replaces the storage 110C (LOG partitioning). The replacement frequency may be about 3 to 4 times a day. The user removes the storage 110C containing the stored data (hereinafter referred to as "first storage") from the VCIB110, installs a new storage (hereinafter referred to as "second storage") into the VCIB110, and then restarts the ADK200 while the vehicle system (the control system of the base vehicle 120) remains operational. Restarting the ADK200 allows it to recognize the second storage device, and the second storage device will then operate as storage 110C. During the ADK200 restart, communication between the VCIB110 and the ADK200 is temporarily interrupted.

[0038] Furthermore, if a communication error occurs (for example, a bus error), communication between the VCIB110 and ADK200 will be interrupted. If a communication error occurs, the user will temporarily stop the vehicle system, identify the cause of the error, eliminate the cause, restore communication, and then restart the vehicle system. In this way, if a communication error occurs between the VCIB110 and ADK200, the vehicle system will be restarted. The vehicle system may be started / stopped according to the ON / OFF state of the start switch of the base vehicle 120. Generally, the start switch is called a "power switch" or "ignition switch". The time required to restart the vehicle system is longer than the time required to restart the ADK200. The time required to restart the vehicle system may be around 5 minutes.

[0039] Hereinafter, communication between VCIB110 and ADK200 may be referred to as "ADK communication." In this embodiment, VCIB110 detects that ADK communication has been interrupted and sets the vehicle mode to manual mode, prohibiting the transition to automatic mode. This prevents the vehicle mode from becoming automatic mode after a communication error occurs but before communication is restored. However, VCIB110 releases the above prohibition when certain conditions are met. Figure 4 is a diagram illustrating the mode transition control according to this embodiment.

[0040] Referring to Figure 4 along with Figures 1 and 2, when the ADK200 is restarted, it executes processing flow F6. Specifically, in S61, the ADK200 sends a reset command to the VCIB110. For example, if the ADK200 is restarted after the aforementioned replacement of storage 110C (LOG partitioning), a reset command is issued in S61. Subsequently, in S62, the ADK200 determines whether the vehicle mode is automatic mode or not. Immediately after the ADK200 restarts, the vehicle mode is manual mode, so S62 determines NO and the process returns to S61. After that, when the ADK200 receives the automatic mode transition completion notification from the VCIB110 (described later), S62 determines YES and processing flow F6 ends.

[0041] Furthermore, the ADK200 is configured to send vehicle mode commands to the VCIB110 in response to requests from a user or an external terminal. In this embodiment, the HMI218 of the ADK200 (Figure 2) or the HMI150 of the base vehicle 120 (Figure 1) receives input from the user (for example, a mode transition request). The mobile terminal 500 shown in Figure 1 functions as an external terminal. The ADK200 uses vehicle mode commands to request the VCIB110 to transition to the vehicle mode requested by the user or external terminal. The VCIB110 is configured to switch the vehicle mode (the control mode of the vehicle system) in response to the vehicle mode commands from the ADK200. The vehicle mode command and reset command correspond to examples of the "first command" and "second command" as described herein.

[0042] The VCIB110 repeatedly executes each of the processing flows F3 to F5 described below in parallel. The VCIB110 also has a first communication flag and a second communication flag. The first communication flag indicates whether or not communication between the VCIB110 and the ADK200 has been interrupted. The second communication flag indicates the communication interruption history, more specifically, the number of times communication between the VCIB110 and the ADK200 has been interrupted. The first communication flag corresponds to an example of a "communication parameter" as described in this disclosure.

[0043] In processing flow F3, VCIB110 determines in S31 whether the first communication flag indicates "0 (communication normal)". If the first communication flag indicates "0" (YES in S31), VCIB110 determines in S32 whether ADK communication (communication between VCIB110 and ADK200) has been interrupted. As long as no interruption of ADK communication is detected (NO in S32), the determinations in S31 and S32 are repeated. Also, if an interruption of ADK communication has already been detected (NO in S31), the processing from S33 onwards is not executed.

[0044] If the first communication flag indicates "0" and an interruption in ADK communication (e.g., a communication error) is detected (YES in both S31 and S32), VCIB110 requests the base vehicle 120 to switch to manual mode in S33. In response to this request, the vehicle mode of the base vehicle 120 changes to manual mode. At this time, the base vehicle 120 may notify the user that the vehicle mode has changed to manual mode via the HMI 150. Subsequently, in S34, VCIB110 sets the first communication flag to "1 (communication interruption)". Subsequently, in S35, VCIB110 saves the communication interruption history. Specifically, VCIB110 increments (adds by 1) the second communication flag. Once the process in S35 is executed, the process returns to the first step (S31).

[0045] In processing flow F4, VCIB110 determines in S41 whether the first communication flag indicates "1". As long as the first communication flag indicates "0" (NO in S41), the determination in S41 is repeated. If the first communication flag indicates "1" (YES in S41), VCIB110 determines in S42 whether the vehicle system has been restarted. For example, if the vehicle system has been restarted after a communication fault (communication error) has been repaired, S42 is determined to be YES, and the process proceeds to S44. On the other hand, if it is determined that the vehicle system has not been restarted (NO in S42), VCIB110 determines in S43 whether it has received the aforementioned reset command (S61). If VCIB110 has received a reset command from ADK200 (YES in S43), the process proceeds to S44.

[0046] In S44, VCIB110 sets the first communication flag to "0 (communication successful)". After that, the process returns to the first step (S41). Also, if NO is determined in S43, the process returns to S41.

[0047] In processing flow F5, VCIB110 determines in S51 whether it has received a vehicle mode command from ADK200 requesting a transition to automatic mode. If VCIB110 has not received such a vehicle mode command (NO in S51), the determination in S51 is repeated. If VCIB110 is requested to transition to automatic mode by the vehicle mode command (YES in S51), VCIB110 determines in S52 whether the first communication flag indicates "0". If the first communication flag indicates "0" (YES in S52), VCIB110 requests the base vehicle 120 to transition to automatic mode in S53. In response to this request, the vehicle mode of the base vehicle 120 becomes automatic mode. Once the transition to automatic mode is complete, VCIB110 notifies ADK200 that the transition to automatic mode is complete (automatic mode transition completion notification). In the automatic mode transition completion notification, VCIB110 sends a vehicle mode status indicating automatic mode to ADK200, for example. On the other hand, if the first communication flag indicates "1" (NO in S52), the process in S53 is not executed, and the process returns to the first step (S51). Thus, when the first communication flag indicates "1", the transition from manual mode to automatic mode based on the vehicle mode command is prohibited.

[0048] Figure 5 shows the state transitions of vehicle 1 based on the mode transition control shown in Figure 4. Lines L1 to L5 in Figure 5 show the state transitions of vehicle 1 when the storage 110C is replaced (LOG split) as described above. Specifically, lines L1, L2, L3, L4, and L5 show examples of transitions for the reset command, first communication flag, second communication flag, transition request to automatic mode (vehicle mode command), and vehicle mode (vehicle mode status), respectively. "t" in Figure 5 means timing.

[0049] Referring to Figure 5, when the above LOG splitting occurs while the vehicle mode is in automatic mode, the ADK200 stops and ADK communication is interrupted. As a result, at t1, the vehicle mode is changed from automatic mode to manual mode by the process in S33 of Figure 4 (line L5), the first communication flag changes from "0" to "1" by the process in S34 of Figure 4 (line L2), and the second communication flag changes from "0" to "1" by the process in S35 of Figure 4 (line L3). With the first communication flag set to "1", the transition from manual mode to automatic mode based on the vehicle mode command is prohibited. Subsequently, when the ADK200 is started, the process in S61 of Figure 4 starts sending a reset command from the ADK200 to the VCIB110 at t2 (line L1), and the process in S44 of Figure 4 changes the first communication flag from "1" to "0" at t3 (line L2). As a result, the prohibition on the transition from manual mode to automatic mode based on the vehicle mode command is released. Subsequently, for example, based on a request from a user or external terminal, at t4, a vehicle mode command requesting a transition to automatic mode is sent from ADK200 to VCIB110 (line L4). When VCIB110 receives this vehicle mode command, the process in S53 of Figure 4 causes the vehicle mode to be changed from automatic mode to manual mode at t5 (line L5), and the transmission of reset commands is stopped at t6 (line L1).

[0050] As described above, the VP100 according to this embodiment includes the VCIB110 and the base vehicle 120, and executes processing flows F1, F3 to F5 (Figures 3 and 4). The ADK200 attached to the VP100 executes processing flows F2 and F6 (Figures 3 and 4). In this embodiment, each process is executed by one or more processors executing programs stored in one or more memories. However, these processes may be executed by hardware (electronic circuits) alone without using software. The VP100 corresponds to an example of a "vehicle capable of being equipped with an autonomous driving kit" according to this disclosure. The control system built into the base vehicle 120 corresponds to an example of a "vehicle system" according to this disclosure.

[0051] The VCIB110 is configured to prohibit the transition from manual mode to automatic mode based on the vehicle mode command (first command) when it detects that ADK communication (communication between VCIB110 and ADK200) has been interrupted, and to release this prohibition upon receiving a reset command (second command) from ADK200. In this configuration, since the transition to automatic mode is prohibited when an abnormality occurs in ADK communication, the vehicle mode is prevented from becoming automatic mode before ADK communication is restored. Furthermore, if storage 110C is replaced (LOG partitioning) is performed, the prohibition on the transition to automatic mode is released by the reset command, so automatic driving control by ADK200 becomes available without restarting the vehicle system. Thus, with the above configuration, it becomes possible to properly control mode transitions after a communication interruption occurs between ADK200 and VCIB110.

[0052] The VCIB110 is configured to prohibit the transition to automatic mode when the first communication flag indicates a communication interruption. When the VCIB110 detects an interruption in ADK communication, it sets the first communication flag to a first value (e.g., "1") indicating a communication interruption. In addition, the VCIB110 sets the first communication flag to a second value (e.g., "0") indicating normal communication, not only when a reset command is received, but also when the vehicle system is restarted, thereby releasing the prohibition on the transition to automatic mode (see processing flow F4 shown in Figure 4). With this configuration, automatic driving control by ADK200 becomes available not only when ADK200 is restarted after LOG splitting, but also when the vehicle system is restarted after a fault related to ADK communication has been repaired.

[0053] In the above embodiment, the second communication flag indicates the number of communication interruptions. This data may be used for vehicle self-diagnosis (OBD) of vehicle 1. However, the historical data indicated by the second communication flag is not limited to the number of communication interruptions. The second communication flag may indicate the presence or absence of a communication interruption using a binary value (0 / 1). Furthermore, the second communication flag is optional.

[0054] In the above embodiment, if the ADK200 is restarted after an interruption in ADK communication is detected, the vehicle mode will remain in manual mode until a user or external terminal requests the ADK200 to transition to automatic mode. However, the ADK200 is not limited to this, and may spontaneously issue a vehicle mode command requesting a transition to automatic mode after restarting. For example, in S61 of Figure 4, the ADK200 may send a vehicle mode command requesting a transition to automatic mode to the VCIB110 along with a reset command.

[0055] In the above embodiment, if an interruption in ADK communication is detected in automatic mode, VCIB110 changes the vehicle mode to manual mode (S33 in Figure 4). This prevents AFSS from activating due to the continuation of automatic mode, which would prevent vehicle 1 from continuing to drive. However, this configuration is not essential. For example, instead of changing the vehicle mode to manual mode in S33 in Figure 4, VCIB110 may prompt the user to transition to manual mode via HMI150. VCIB110 may also prohibit transitions to vehicle modes that increase the automated driving level and permit transitions to vehicle modes that decrease the automated driving level (including transitions from automatic mode to manual mode) when the first communication flag indicates a communication interruption. When the first communication flag indicates a communication interruption, ADK200 may change the vehicle mode from automatic mode to manual mode by sending a vehicle mode command to VCIB110 requesting a transition to manual mode in response to a user request.

[0056] The various features of the vehicle described above (each feature described in the embodiments and modifications) may be applied in any combination.

[0057] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims rather than by the description of the embodiments above, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of symbols]

[0058] 1 vehicle, 100 vehicle platforms, 110 vehicle control interface boxes, 120 base vehicles, 200 autonomous driving kits.

Claims

1. A vehicle capable of being equipped with an autonomous driving kit, The aforementioned vehicle comprises a vehicle control interface box and a vehicle system, The vehicle control interface box is configured to switch the control mode of the vehicle system in response to a first command from the autonomous driving kit. The control modes include an automatic mode in which the vehicle is under the control of the autonomous driving kit and a manual mode in which the vehicle is under the control of the driver. A vehicle in which the vehicle control interface box is configured to prohibit the transition from the manual mode to the automatic mode based on the first command when it is detected that communication between the vehicle control interface box and the automatic driving kit has been interrupted, and to release the prohibition based on the receipt of a second command from the automatic driving kit.

2. The vehicle control interface box holds a communication parameter indicating whether or not communication between the vehicle control interface box and the autonomous driving kit has been interrupted. The vehicle control interface box is configured to prohibit the transition from the manual mode to the automatic mode based on the first command when the communication parameter indicates a communication interruption. The vehicle according to claim 1, wherein the vehicle control interface box is configured to set the control mode of the vehicle system to manual mode and to set a first value indicating communication interruption to the communication parameter when it is detected that communication between the vehicle control interface box and the autonomous driving kit has been interrupted.

3. The vehicle according to claim 2, wherein the vehicle control interface box is configured to set the communication parameter to a second value indicating successful communication when it receives the second command while the communication parameter is showing the first value.

4. The vehicle according to claim 3, wherein the vehicle control interface box is configured to set the second value to the communication parameter even when the vehicle system is restarted while the communication parameter is showing the first value.

5. The autonomous driving kit installed in the aforementioned vehicle is The first command is sent to the vehicle control interface box in response to a request from the user or an external terminal. The autonomous driving kit is configured to send the second command to the vehicle control interface box when it is restarted. The vehicle according to any one of claims 1 to 4, wherein the time required to restart the vehicle system is longer than the time required to restart the autonomous driving kit.

Images