Vehicle
By detecting communication interruptions through the vehicle control interface box and disabling automatic mode transitions, and then resolving the disabling by using a reset command, the problem of mode transitions after communication interruptions between the autonomous driving kit and the vehicle control interface box was solved, improving user experience and system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- TOYOTA JIDOSHA KK
- Filing Date
- 2025-11-10
- Publication Date
- 2026-05-29
AI Technical Summary
When communication between the autonomous driving kit and the vehicle control interface box is interrupted, the vehicle mode cannot be changed properly, resulting in impaired user convenience and frequent vehicle system restarts affecting the driving experience.
The vehicle control interface box detects communication interruptions and prevents the transition from manual to automatic mode. Upon communication restoration, a reset command is received to lift the restriction, thus avoiding unnecessary mode transitions and ensuring that the vehicle system continues autonomous driving control without restarting.
It enables appropriate mode transition control after communication interruption, avoids frequent restarts, improves user experience and system stability, and ensures the continuity of autonomous driving functions.
Smart Images

Figure CN122101221A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a vehicle capable of being equipped with an autonomous driving kit. Background Technology
[0002] Japanese Patent Application Publication No. 2024-139411 (Patent Document 1) discloses a control system that, in automatic mode, activates the ADK Failure Stop System (AFSS) in the event of a communication failure between the automatic driving kit and the vehicle control interface box, thereby decelerating the vehicle until it stops. In this control system, if the vehicle stops and locks, the vehicle mode switches to manual mode.
[0003] Patent Document 1: Japanese Patent Application Publication No. 2024-139411 Summary of the Invention Patent document 1 does not disclose the processing after the vehicle mode changes to manual mode. If the vehicle mode changes back to automatic mode before communication between the autopilot kit and the vehicle control interface box is restored, there is a problem of AFSS malfunctioning again.
[0004] Therefore, it is possible to consider prohibiting the transition to automatic mode until the vehicle system (the control system of the base vehicle) is restarted. After communication is restored, the vehicle mode can be switched to automatic mode by restarting the vehicle system. However, in this method, in the event of a communication interruption, automatic mode cannot be executed until the vehicle system is restarted. Moreover, restarting the vehicle system takes time. Since users may sometimes intentionally stop communication between the autonomous driving kit and the vehicle control interface box for maintenance or data collection purposes, requiring a vehicle system restart every time communication is interrupted would greatly impair user convenience.
[0005] The present invention was made to solve the above-mentioned problems, and its purpose is to properly perform mode transition control after a communication interruption occurs between the autonomous driving kit and the vehicle control interface box.
[0006] According to one aspect of the present invention, a vehicle as shown below is provided. The vehicle is configured to be equipped with an autonomous driving kit. The vehicle includes 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 according to a first command from the autonomous driving kit. The control modes include an automatic mode where the vehicle is under the control of the autonomous driving kit and a manual mode where the vehicle is under the control of the driver. The vehicle control interface box is configured to, in the event of a detected interruption in communication between the vehicle control interface box and the autonomous driving kit, prohibit the transition from manual mode to automatic mode based on the first command, and to lift the prohibition based on receiving a second command from the autonomous driving kit.
[0007] Invention Effects According to the present invention, mode switching control can be appropriately performed after a communication interruption occurs between the autonomous driving kit and the vehicle control interface box. Attached Figure Description
[0008] Figure 1 This is a diagram showing a schematic structure of a vehicle according to an embodiment of the present invention.
[0009] Figure 2 It means Figure 1 Detailed diagrams of the various systems built into the vehicle are shown.
[0010] Figure 3 This is a flowchart illustrating the processes involved in the driving control according to this embodiment.
[0011] Figure 4 This is a diagram used to illustrate the mode transition control involved in this embodiment.
[0012] Figure 5 It means based on Figure 4 The diagram shows the state transitions of a vehicle under mode change control. Detailed Implementation
[0013] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. Furthermore, identical or corresponding parts in the drawings will be labeled with the same symbols, and their descriptions will not be repeated.
[0014] Figure 1 This is a diagram showing a schematic structure of the vehicle involved in this embodiment. (Reference) Figure 1 Vehicle 1 includes 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, the VP 100 is formed, capable of mounting and dismounting the ADK 200. The VCIB 110 is configured to communicate with both the base vehicle 120 and the ADK 200 via a communication bus. Vehicle 1 is completed by mounting the ADK 200 onto the VP 100.
[0015] The base vehicle 120 is, for example, a commercially available xEV (electric vehicle). In this embodiment, the base vehicle 120 is a BEV (electric vehicle). However, it is not limited to this; the base vehicle 120 can also be an xEV other than a BEV. The base vehicle 120 includes an integrated control manager 130, a human-machine interface (HMI) 150, and various systems and sensors (wheel speed sensors 127A, 127B, steering angle sensor 127C, camera 129A, radar sensors 129B, 129C, etc.) for controlling the base vehicle 120. 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 is communicatively connected to the HMI 150. The HMI 150 includes input devices and notification devices. Examples of notification devices include a display and a speaker. The HMI 150 may include a touch panel display.
[0016] The mobile terminal 500 is carried and operated by the user of vehicle 1. The mobile terminal 500 is, for example, a smartphone with a touch panel display. The mobile terminal 500 has a built-in computer and is configured to communicate with ADK 200.
[0017] Figure 2 This is a detailed diagram showing the various systems possessed by vehicle 1. (Reference) Figure 1 and Figure 2 ADK 200 includes an autonomous driving system (hereinafter referred to as "ADS") 210 for performing autonomous driving of vehicle 1. ADS 210 includes a computer assembly (hereinafter referred to as "ADSCOM") 211, a recognition sensor 212, an attitude sensor 213, a sensor cleaner 216, and a human machine interface (HMI) 218.
[0018] ADSCOM 211 includes computer modules (hereinafter referred to as "ADC") 211A and 211B. ADC 211A and 211B each have a processor and a storage device storing autonomous driving software utilizing the API described later, and are configured to execute the autonomous driving software via the processor. The identification sensor 212 includes sensors that acquire information representing the external environment of vehicle 1 (hereinafter also referred to as "environmental information"). The identification sensor 212 may include at least one of a camera, millimeter-wave radar, and lidar. The attitude sensor 213 acquires information related to the attitude of vehicle 1 (hereinafter also referred to as "attitude information"). The attitude sensor 213 may include various sensors that detect the acceleration, angular velocity, and position of vehicle 1. The HMI 218 includes an input device and a notification device.
[0019] The base vehicle 120 includes a braking 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 includes an electronic control unit (hereinafter also referred to as "ECU").
[0020] In vehicle 1, the control system related to the behavior of vehicle 1 (driving, stopping, turning) is redundant. Specifically, ADCs 211A and 211B issue instructions to the main system and the sub-system, respectively. VCIB 110 includes a VCI control unit 110A for the main system, a VCI control unit 110B for the sub-system, and a storage device 110C. VCI control units 110A and 110B can each be a computer equipped with a processor and storage device. VCI control units 110A and 110B can communicate directly with each system, or via an integrated control manager 130 (… Figure 1 It communicates with the device. The storage device 110C will be explained later.
[0021] The braking system 121 includes a braking device, an operating unit that receives braking operations from the user, a main system braking control unit 121A, and a secondary system braking control unit 121B. In the braking system 121, the braking control units 121A and 121B are configured to control the braking device respectively. The braking device can be a hydraulic disc brake. The braking device functions as a service brake. The braking device applies braking force to the wheels of the vehicle 1.
[0022] The steering system 122 includes a steering mechanism, an operating unit that receives steering inputs from the user, a main system steering control unit 122A, and a secondary system steering control unit 122B. The powertrain system 123 includes a gear shifting device (not shown), an EPB device 123A, a P-Lock device 123B, and a propulsion system 123C. "EPB" stands for Electric Parking Brake, and "P-Lock" stands for Parking Lock.
[0023] The shifting device determines the shift range and switches the propulsion direction and transmission mode of the base vehicle 120 according to the determined shift range. The shifting device includes a transmission mechanism and an operating unit that receives shift operations from the user. The propulsion system 123C includes a vehicle drive unit, an operating unit that receives throttle operations from the user, and a propulsion control unit that controls the vehicle drive unit. The vehicle drive unit applies propulsive force in the propulsion direction indicating the shift range to the wheels. This propulsive force accelerates the base vehicle 120. The vehicle drive unit includes a battery and a driving motor that receives power from the battery.
[0024] EPB device 123A, for example, includes a parking brake mechanism, an electric actuator, and an operating unit that receives EPB requests from a user. EPB device 123A can be configured to apply braking force to the wheels via the electric actuator to fix (lock) the wheels. P-Lock device 123B, for example, includes a parking lock mechanism, an actuator, and an operating unit that receives vehicle parking operations from a user. P-Lock device 123B can be configured to mechanically fix the rotational position of the transmission output shaft via a parking lock lever that can be driven by the actuator.
[0025] Active safety systems 125 include, for example, Pre Collision Safety (PCS) system, Emergency Driving Stop System (EDSS) system, and ADK Failure Stop System (AFSS) system.
[0026] In this embodiment, communication between ADK 200 and VCIB 110 uses signals defined by an Application Program Interface (API) (API signals). ADK 200 is configured to process various signals defined by the API. ADK 200 outputs various commands to VCIB 110 according to the API. Hereinafter, each of the various commands output from ADK 200 to VCIB 110 is also referred to as an "API command". Furthermore, ADK 200 receives various status signals from VCIB 110 indicating the state of the base vehicle 120 according to the API. Hereinafter, each of the various status signals received by ADK 200 from VCIB 110 is also referred to as an "API status". Both API commands and API statuses are equivalent to API signals.
[0027] In this implementation, ADK 200 uses the API commands described below.
[0028] The Vehicle Mode command is an API command that requests a switch to Automatic or Manual mode. Automatic and Manual modes will be explained later. The Direction of Shift command is an API command that requests a change in the R / D shift range. The Acceleration command is an API command that indicates the vehicle's acceleration. The Acceleration command requests acceleration (+) and deceleration (-) relative to the direction shown in the Direction of Shift state description. The Front Wheel Steering Angle command is an API command that requests the steering of the vehicle's front wheels. The Lock command is an API command that requests the application or release of a lock.
[0029] The above describes some of the API commands used in vehicle 1. VCIB 110 receives various API commands from ADK 200. If VCIB 110 receives an API command from ADK 200, it converts the API command into a signal form that can be executed by the control system of base vehicle 120. Hereinafter, the API command converted into a signal form that can be executed by the control system of base vehicle 120 will also be referred to as an "internal instruction". If VCIB 110 receives an API command from ADK 200, it outputs the internal instruction corresponding to that API command to base vehicle 120. In base vehicle 120, multiple control devices (e.g., Figure 1 and Figure 2 The integrated control manager 130 and the control devices of each system are shown to construct a control system.
[0030] Next, the API status will be explained. ADK 200 uses the API status described below to understand the status of the base vehicle 120, for example.
[0031] The vehicle mode state represents the API state of the base vehicle 120's vehicle mode. The vehicle mode of the base vehicle 120 corresponds to the control mode of the vehicle system within the base vehicle 120. Vehicle modes include manual mode and automatic mode. Manual mode is the vehicle mode where the base vehicle 120 is under the control of a driver (human). Automatic mode is the vehicle mode where the base vehicle 120 is under the control of an autonomous driving suite. Initially, the vehicle mode is manual. The vehicle mode state outputs values "0" and "1" when the current vehicle mode is manual or automatic, respectively.
[0032] The Propulsion Direction Status is the API status indicating the current shift range. The Travel Direction Status is the API status indicating the vehicle's direction of travel. The Travel Direction 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 four wheels (4 wheels) have a speed of "0" for a certain period. The Vehicle Speed Status is the API status indicating the vehicle's longitudinal speed. The Vehicle Speed Status outputs the absolute value of the vehicle speed. The Lock Status is the API status indicating the locked state (e.g., the state of EPB and P gear).
[0033] The above describes some of the API states used in vehicle 1. VCIB 110 receives various sensor detection values and state determination results from the base vehicle 120, and outputs various API states representing the state of the base vehicle 120 to ADK 200. VCIB 110 acquires API states with values set to represent the state of the base vehicle 120, and outputs the acquired API states to ADK 200. Various API states are stored, for example, in the respective storage devices of VCI control units 110A and 110B, and are updated sequentially.
[0034] Figure 3 This is a flowchart representing the processes involved in driving control performed by the base vehicle 120. Figure 3 The processing flow F1 shown is repeatedly executed by any control device of the base vehicle 120. "S" in the flowchart represents a step.
[0035] refer to Figure 3 In processing flow F1, the base vehicle 120 determines in S10 whether to execute driving control in manual mode. Additionally, the vehicle mode (driving control) is determined, for example, based on a request from ADK 200 (vehicle mode command) or a request from VCIB 110 (see below). Figure 4 The vehicle mode command is changed from ADK 200 via VCIB 110 to the base vehicle 120 (see below). Figure 4 (S53).
[0036] When the base vehicle 120 performs driving control in manual mode ("Yes" in S10), the base vehicle 120 acquires user operations related to driving the vehicle 1 in S11. Specifically, the base vehicle 120 acquires the operation quantities (accelerator operation quantity, brake operation quantity, steering operation quantity, etc.) and change operations (gear shifting operation, etc.) of various operating units related to manual driving of the vehicle 1. Then, the base vehicle 120 performs manual driving control based on the acquired user operations in S12. On the other hand, when the base vehicle 120 performs driving control in automatic mode ("No" in S10), the base vehicle 120 performs automatic driving control based on driving instructions from ADK 200 in S13 to S15, as explained below.
[0037] In S13, the detection results and state determination results of various sensors representing the state of the base vehicle 120 are sent from the base vehicle 120 to the VCIB 110, and the various API states corresponding to the state of the base vehicle 120 are sent from the VCIB 110 to the ADK 200. Thus, the processing flow F2 executed by the ADK 200 begins.
[0038] In S21, ADK 200 receives various API states from VCIB 110. In S22, based on the API states obtained from VCIB 110 and the environmental and attitude information acquired by ADK 200 itself, a driving plan for autonomous driving is created. The driving plan is data representing the behavior of the target vehicle 1 within a specified period. ADK 200 can calculate the behavior (attitude, etc.) of vehicle 1 and create a driving plan suitable for the state of vehicle 1 and the external environment. In S23, ADK 200 determines various API commands (propulsion direction command, acceleration command, front wheel steering angle command, lock command, etc.) for executing the control requested by the created driving plan (e.g., at least one of acceleration control, deceleration control, steering control, and vehicle parking control). ADK 200 can calculate the physical quantities (acceleration, tire steering angle, etc.) of the control requested by the driving plan and determine the various API commands based on the calculation results. In subsequent S24, the various API commands determined are sent from ADK 200 to VCIB 110, and the various driving commands (internal instructions) corresponding to the API commands are sent from VCIB 110 to the base vehicle 120. Thus, processing flow F2 ends, and processing proceeds to S14. The driving commands are equivalent to automatic driving instructions from ADK 200 to the control system of base vehicle 120. VCIB 110 performs signal conversion between ADK 200 and base vehicle 120 to establish communication between them.
[0039] In S14, the base vehicle 120 receives various driving commands from the VCIB 110, and in the subsequent S15, executes automatic driving control based on these driving commands. If the processing in S12 or S15 is executed, the processing returns to the initial step (S10). Thus, driving control (S12 or S15) continues to be executed.
[0040] In this embodiment, it is configured as follows Figure 2 Both the VCI control units 110A and 110B shown can access the storage device 110C. An example of the storage device 110C is a solid-state drive (SSD). In this embodiment, the VCIB 110 sequentially accumulates various data collected from the vehicle 1 (e.g., detection results from various sensors and the respective values of API commands and API states related to the behavior of the vehicle 1) into the storage device 110C. The collected data also includes images captured by cameras, thus a large amount of data is accumulated in the storage device 110C. Therefore, the user periodically replaces the storage device 110C (LOG splitting). The replacement frequency can be approximately 3 to 4 times per day. After the user removes the data-accumulated storage device 110C (hereinafter referred to as "first storage device") from the VCIB 110 and installs a new storage device (hereinafter referred to as "second storage device") into the VCIB 110, the vehicle system (the control system of the base vehicle 120) remains operational, and the ADK 200 is restarted. Upon restarting ADK 200, the second storage device is recognized in ADK 200 and operates as storage device 110C. Communication between VCIB 110 and ADK 200 is temporary but interrupted during ADK 200 restart.
[0041] Furthermore, even in the event of a communication anomaly (e.g., a bus malfunction), communication between the VCIB 110 and ADK 200 will be interrupted. In the event of a communication anomaly, the user temporarily stops the vehicle system, identifies the cause of the anomaly, eliminates the cause, and restores communication before restarting the vehicle system. Thus, in the event of a communication anomaly between the VCIB 110 and ADK 200, the vehicle system restarts. The vehicle system can be started / stopped based on the ON / OFF state of the start switch on the base vehicle 120. Typically, the start switch is referred to as a "power switch" or "ignition switch," etc. The restart time for the vehicle system is longer than that for the ADK 200. The restart time for the vehicle system can be approximately 5 minutes.
[0042] Hereinafter, the communication between VCIB 110 and ADK 200 will sometimes be referred to as "ADK communication". In this embodiment, when VCIB 110 detects an interruption in ADK communication, it sets the vehicle mode to manual mode and prohibits the transition to automatic mode. Thus, after a communication failure occurs and before communication is restored, the vehicle mode is prevented from becoming automatic. However, if specified conditions are met, VCIB 110 will lift the aforementioned prohibition. Figure 4 This is a diagram used to illustrate the mode transition control involved in this implementation.
[0043] refer to Figure 1 , Figure 2 and Figure 4 If ADK 200 restarts, process flow F6 is executed. Specifically, in S61, ADK 200 sends a reset command to VCIB 110. For example, if ADK 200 restarts after the aforementioned replacement (LOG partitioning) of storage device 110C, a reset command is issued in S61. Next, in S62, ADK 200 determines whether the vehicle mode is automatic. If the vehicle mode becomes manual immediately after ADK 200 restarts, the determination in S62 is "no," and the process returns to S61. Then, if ADK 200 receives a notification from VCIB 110 indicating that the automatic mode transition is complete (described later), the determination in S62 is "yes," and process flow F6 ends.
[0044] Furthermore, ADK 200 is configured to send vehicle mode commands to VCIB 110 upon request from a user or external terminal. In this embodiment, ADK 200's HMI 218 ( Figure 2 ) or the HMI 150 of the base vehicle 120 ( Figure 1 It accepts input from users (e.g., mode change requests). And, Figure 1 The mobile terminal 500 shown functions as an external terminal. ADK 200 uses a vehicle mode command to request VCIB 110 to switch to the vehicle mode required by the user or external terminal. VCIB 110 is configured to switch vehicle modes (control modes of the vehicle system) based on the vehicle mode command from ADK 200. The vehicle mode command and reset command correspond to examples of the "first command" and "second command" involved in this invention, respectively.
[0045] VCIB 110 executes each of the processing flows F3 to F5 described below in parallel. Furthermore, VCIB 110 holds a first communication flag and a second communication flag. The first communication flag indicates whether communication between VCIB 110 and ADK 200 has been interrupted. The second communication flag indicates the communication interruption history, and more specifically, the number of communication interruptions between VCIB 110 and ADK 200. The first communication flag corresponds to an example of the "communication parameters" involved in this invention.
[0046] In process flow F3, VCIB 110 determines in S31 whether the first communication flag indicates "0 (communication is normal)". If the first communication flag indicates "0" ("Yes" in S31), VCIB 110 determines in S32 whether ADK communication (communication between VCIB 110 and ADK 200) is interrupted. During the period when no interruption of ADK communication is detected ("No" in S32), the determinations in S31 and S32 are repeated. Furthermore, even if an interruption of ADK communication is detected ("No" in S31), the processing after S33 is not executed.
[0047] If the first communication flag is "0" and an interruption in ADK communication is detected (e.g., a communication error) ("Yes" in both S31 and S32), VCIB 110 requests a switch to manual mode from the base vehicle 120 in S33. Based on this request, the base vehicle 120's vehicle mode becomes manual mode. At this time, the base vehicle 120 can notify the user that the vehicle mode has become manual mode via HMI 150. Next, in S34, VCIB 110 sets the first communication flag to "1 (communication interruption)". Then, in S35, VCIB 110 saves the communication interruption history. Specifically, VCIB 110 increments the second communication flag by 1 (incrementing once). If the processing in S35 is executed, the process returns to the initial step (S31).
[0048] In processing flow F4, VCIB 110 determines in S41 whether the first communication flag indicates "1". If 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), VCIB 110 determines in S42 whether the vehicle system has restarted. For example, if the vehicle system was restarted after a communication-related fault (communication anomaly) was fixed, the determination in S42 is "Yes", and processing proceeds to S44. On the other hand, if the vehicle system is determined not to have restarted ("No" in S42), VCIB 110 determines in S43 whether the aforementioned reset command has been received (S61). If VCIB 110 receives a reset command from ADK 200 ("Yes" in S43), processing proceeds to S44.
[0049] In S44, VCIB 110 sets the first communication flag to "0 (communication is normal)". Then, the process returns to the initial step (S41). And, even if the determination in S43 is "no", the process returns to S41.
[0050] In processing flow F5, VCIB 110 determines in S51 whether it has received a vehicle mode command from ADK 200 requesting a switch to automatic mode. If VCIB 110 does not receive such a vehicle mode command (in S51, "No"), the determination in S51 is repeated. Then, if VCIB 110 requests a switch to automatic mode via a vehicle mode command (in S51, "Yes"), VCIB 110 determines in S52 whether the first communication flag indicates "0". If the first communication flag indicates "0" (in S52, "Yes"), VCIB 110 requests a switch to automatic mode from the base vehicle 120 in S53. Based on this request, the vehicle mode of the base vehicle 120 becomes automatic mode. If the switch to automatic mode is complete, VCIB 110 notifies ADK 200 that the switch to automatic mode is complete (Automatic Mode Switch Completion Notification). In the automatic mode transition completion notification, VCIB 110, for example, sends the vehicle mode status indicating automatic mode to ADK 200. On the other hand, if the first communication flag is "1" ("No" in S52), the processing in S53 is not executed, and the processing returns to the initial step (S51). Thus, when the first communication flag is "1", the transition from manual mode to automatic mode based on the vehicle mode command is prohibited.
[0051] Figure 5 It means based on Figure 4 The diagram shows the state transition of vehicle 1 under mode change control. Figure 5Lines L1 to L5 in the diagram represent the state transition of vehicle 1 when the aforementioned storage device 110C has been replaced (LOG segmentation). Specifically, lines L1, L2, L3, L4, and L5 represent an example of a reset command, a first communication flag, a second communication flag, a request to switch to automatic mode (vehicle mode command), and a vehicle mode (vehicle mode state) transition, respectively. Figure 5 In this context, "t" represents time.
[0052] refer to Figure 5 If the above LOG segmentation is performed when the vehicle mode is automatic, ADK 200 will be in a stopped state, and ADK communication will be interrupted. Therefore, in t1, through... Figure 4 The S33 process changes the vehicle mode from automatic to manual (L5). Figure 4 In the S34 processing, the first communication flag changes from "0" to "1" (line L2), via... Figure 4 In the S35 processing, the second communication flag changes from "0" to "1" (line L3). By making the first communication flag "1", the transition from manual to automatic mode based on vehicle mode commands is prohibited. Then, if ADK 200 is activated, it is through... Figure 4 The S61 process begins in t2 by sending a reset command (line L1) from ADK 200 to VCIB 110. Figure 4 In the processing of S44, the first communication flag changes from "1" to "0" in t3 (line L2). This removes the restriction on switching from manual to automatic mode based on a vehicle mode command. Then, for example, based on a request from a user or external terminal, in t4, a vehicle mode command requesting a switch to automatic mode is sent from ADK 200 to VCIB 110 (line L4). If VCIB 110 receives the vehicle mode command, it then... Figure 4 In the S53 process, at t5, the vehicle mode is changed from manual mode to automatic mode (line L5), and at t6, the sending of the reset command is stopped (line L1).
[0053] As explained above, the VP 100 involved in this implementation includes VCIB 110 and base vehicle 120, and executes processing flows F1, F3 to F5 ( Figure 3 , Figure 4 ADK 200 installed on VP 100 executes processes F2 and F6. Figure 3 , Figure 4In this embodiment, each process is executed by one or more processors executing programs stored in one or more memories. However, these processes can be executed solely by hardware (electronic circuitry) without using software. VP 100 corresponds to an example of a "vehicle capable of carrying an autonomous driving kit" according to the present invention. The control system built into the base vehicle 120 corresponds to an example of a "vehicle system" according to the present invention.
[0054] VCIB 110 is configured to prevent the transition from manual mode to automatic mode based on a vehicle mode command (first command) in the event of an ADK communication interruption (communication between VCIB 110 and ADK 200), and to lift the restriction upon receiving a reset command (second command) from ADK 200. In this configuration, the transition to automatic mode is prohibited in the event of an ADK communication failure, thus preventing the vehicle mode from becoming automatic until ADK communication is restored. Furthermore, in the event of a replacement of the storage device 110C (LOG partitioning), the restriction on the transition to automatic mode is lifted by the reset command, thus enabling automatic driving control performed by ADK 200 even without restarting the vehicle system. Therefore, according to the above configuration, mode transition control can be appropriately performed after a communication interruption between ADK 200 and VCIB 110.
[0055] VCIB 110 is configured to prevent transition to automatic mode when the first communication flag indicates a communication interruption. Upon detecting an interruption in ADK communication, VCIB 110 sets the first communication flag to a first value indicating a communication interruption (e.g., "1"). Furthermore, VCIB 110 sets the first communication flag to a second value indicating normal communication (e.g., "0") not only upon receiving a reset command but also upon a vehicle system restart, thus releasing the restriction on transitioning to automatic mode (see reference). Figure 4 The processing flow shown is F4. In this structure, autonomous driving control performed by ADK 200 can be utilized not only by restarting ADK 200 after LOG segmentation, but also by restarting the vehicle system after repairing faults related to ADK communication.
[0056] In the above embodiment, the second communication flag indicates the number of communication interruptions. This data can be used for vehicle 1's on-board diagnostics (OBD). However, the historical data shown by the second communication flag is not limited to the number of communication interruptions. The second communication flag can be represented by a binary value (0 / 1) to indicate whether there was a communication interruption. Furthermore, the second communication flag can be omitted.
[0057] In the above embodiment, if ADK 200 is restarted after an interruption in ADK communication is detected, the vehicle mode remains in manual mode until the user or an external terminal requests ADK 200 to switch to automatic mode. However, this is not a limitation; ADK 200 can spontaneously issue a vehicle mode command requesting a switch to automatic mode after a restart. For example, ADK 200 can... Figure 4 In S61, along with the reset command, a vehicle mode command requesting a switch to automatic mode is sent to VCIB 110.
[0058] In the above embodiment, if an interruption of ADK communication is detected in automatic mode, VCIB 110 sets the vehicle mode to manual mode. Figure 4 (S33). This avoids the situation where AFSS activates due to continued operation in automatic mode, preventing vehicle 1 from continuing to drive. However, this structure is not mandatory. For example, VCIB 110 can... Figure 4 In S33, instead of setting the vehicle mode to manual mode, the HMI 150 prompts the user to switch to manual mode. The VCIB 110 can prohibit switching vehicle modes to increase the level of automation when the first communication flag indicates a communication interruption, but allows switching vehicle modes to decrease the level of automation (including switching from automatic mode to manual mode). When the first communication flag indicates a communication interruption, the ADK 200 can send a vehicle mode command requesting a switch to manual mode to the VCIB 110 based on a user request, thereby changing the vehicle mode from automatic mode to manual mode.
[0059] The various vehicle-related features described above (the features described in the embodiments and variations) can be combined and applied arbitrarily.
[0060] The embodiments disclosed herein are considered illustrative in all respects and not restrictive. The scope of the invention is defined not by the description of the above embodiments but by the claims, and is intended to include all modifications within the meaning and scope equivalent to the claims.
[0061] Symbol Explanation 1-Vehicle, 100-Vehicle platform, 110-Vehicle control interface box, 120-Base vehicle, 200-Autonomous driving kit.
Claims
1. A vehicle capable of being equipped with an autonomous driving kit, the vehicle being characterized in that, The vehicle is equipped with 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 according to a first command from the autonomous driving suite. The control modes include an automatic mode where the vehicle is under the control of the autonomous driving suite and a manual mode where the vehicle is under the control of the driver. The vehicle control interface box is configured to, in the event of a communication interruption between the vehicle control interface box and the autonomous driving kit, prohibit the transition from the manual mode to the automatic mode based on the first command, and lift the prohibition based on receiving a second command from the autonomous driving kit.
2. The vehicle according to claim 1, characterized in that, The vehicle control interface box holds communication parameters that indicate whether communication between the vehicle control interface box and the autonomous driving kit is interrupted. The vehicle control interface box is configured to prevent the transition from manual mode to automatic mode based on the first command in the event of a communication interruption indicated by the communication parameters. The vehicle control interface box is configured such that, upon detecting a communication interruption between the vehicle control interface box and the autonomous driving kit, the control mode of the vehicle system is set to the manual mode, and the communication parameter is set to a first value indicating a communication interruption.
3. The vehicle according to claim 2, characterized in that, The vehicle control interface box is configured such that if the second command is received when the communication parameter represents the first value, the communication parameter is set to the second value indicating normal communication.
4. The vehicle according to claim 3, characterized in that, The vehicle control interface box is configured such that even if the vehicle system restarts when the communication parameter represents the first value, the communication parameter will still be set to the second value.
5. The vehicle according to any one of claims 1 to 4, characterized in that, The autonomous driving kit installed in the vehicle is configured as follows: The first command is sent to the vehicle control interface box according to a request from a user or external terminal. When the autonomous driving suite restarts, the second command is sent to the vehicle control interface box. The vehicle system takes longer to restart than the autonomous driving suite.