vehicle

Abstract

To appropriately stop a vehicle in an emergency by an emergency stop system for the vehicle.SOLUTION: A vehicle includes: a vehicle platform for controlling the vehicle; and an automated driving kit for transmitting a command for automated driving to the vehicle platform. The vehicle platform includes: an accelerator pedal operated by a driver to accelerate the vehicle; a first emergency stop system for stopping the vehicle when an abnormality occurs in the automated driving kit; and a second emergency stop system for stopping the vehicle when an emergency state occurs in the driver. During operation of the second emergency stop system, the automated driving kit requests the vehicle platform to prohibit acceleration of the vehicle by the accelerator pedal. During operation of the first emergency stop system, the vehicle platform prohibits the acceleration of the vehicle by the accelerator pedal, regardless of whether or not a request is made by the automated driving kit.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates to autonomously driven vehicles. [Background technology]

[0002] Japanese Patent Application Laid-Open Publication No. 2019-177807 (Patent Document 1) discloses a vehicle equipped with an autonomous driving kit. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-177807 Summary of the Invention [Problem to be solved by the invention]

[0004] However, even in vehicles equipped with an autonomous driving kit, there is a human driver who operates the vehicle and may drive the vehicle manually as necessary. Therefore, it is conceivable to equip the vehicle with an emergency stop system that stops the vehicle in the event of a driver emergency (for example, when the driver's physical condition deteriorates and the driver is unable to drive). However, if the driver becomes unable to move with the accelerator pedal depressed, acceleration control according to the accelerator pedal operation may prevent the emergency stop system from bringing the vehicle to an emergency stop.

[0005] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to appropriately stop a vehicle in an emergency using an emergency stop system of the vehicle. [Means for solving the problem]

[0006] A vehicle according to one embodiment of the present disclosure includes a vehicle platform (hereinafter referred to as "VP") that controls the vehicle and an autonomous driving kit (hereinafter referred to as "ADK") that transmits commands for autonomous driving to the VP. The VP includes an accelerator pedal operated by the driver to accelerate the vehicle, a first emergency stop system that stops the vehicle when an abnormality occurs in the ADK, and a second emergency stop system that stops the vehicle when an emergency occurs to the driver. The ADK requests the VP to prohibit acceleration of the vehicle by the accelerator pedal while the second emergency stop system is operating. The VP prohibits acceleration of the vehicle by the accelerator pedal while the first emergency stop system is operating, regardless of whether a request is received from the ADK. [Effects of the Invention]

[0007] According to the present disclosure, in the event of an emergency, the vehicle's emergency stop system can properly stop the vehicle. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram showing a schematic configuration of a vehicle according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram showing details of a control system for the vehicle shown in FIG. [Figure 3] 3 is a flowchart illustrating vehicle control according to an embodiment of the present disclosure. [Figure 4] 4 is a flowchart showing details of processing related to AFSS in the vehicle control shown in FIG. 3. [Figure 5] 4 is a flowchart showing details of a process relating to manual driving in the vehicle control shown in FIG. 3. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals, and description thereof will not be repeated.

[0010] FIG. 1 is a diagram illustrating a schematic configuration of a vehicle according to an embodiment of the present disclosure. Referring to FIG. 1, the vehicle 1 includes a vehicle platform (VP) 100 and an autonomous driving kit (ADK) 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, 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 then completed by attaching the ADK 200 to the VP 100. In this embodiment, the ADK 200 is attached to the rooftop of the base vehicle 120. However, the attachment position of the ADK 200 can be changed as appropriate.

[0011] The base vehicle 120 is, for example, a commercially available xEV (electric vehicle). In this embodiment, a BEV (electric vehicle) is adopted as the base vehicle 120. However, the present invention 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, and various systems and sensors (wheel speed sensors 127A, 127B, steering angle sensor 127C, 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.

[0012] Fig. 2 is a diagram showing details of the control system of the vehicle 1. Referring to Fig. 2 together with Fig. 1, the ADK 200 includes an autonomous driving system (hereinafter referred to as "ADS") 210 for autonomously driving the vehicle 1. The 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 an HMI (Human Machine Interface) 218.

[0013] The ADSCOM 211 includes a first computer module (hereinafter referred to as the "first ADC") 211A and a second computer module (hereinafter referred to as the "second ADC") 211B. Each of the first ADC 211A and the second ADC 211B includes a processor and a storage device that stores autonomous driving software using an API (described later), and is configured to enable the processor to execute the autonomous driving software. The recognition sensor 212 includes a sensor that acquires information indicating the external environment of the vehicle 1 (hereinafter also referred to as "environmental information"). The recognition sensor 212 may include at least one of a camera, a millimeter-wave radar, and a lidar. The attitude sensor 213 acquires information regarding the attitude of the 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 the vehicle 1. The HMI 218 includes an input device and an alarm device.

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

[0015] In the vehicle 1, the control systems related to the behavior (running, stopping, turning) of the vehicle 1 have redundancy. The first ADC 211A and the second ADC 211B give instructions to the main control system and the sub-control system, respectively. The VCIB 110 includes a control unit (hereinafter referred to as the "first VCIB") 111A of the main control system and a control unit (hereinafter referred to as the "second VCIB") 111B of the sub-control system. Each control unit may include a computer equipped with a processor and a storage device. The first VCIB 111A and the second VCIB 111B may communicate with each system directly or via the integrated control manager 130 shown in FIG. 1.

[0016] The brake system 121 includes a braking mechanism, an operation unit that accepts brake operation from the driver, and brake control units 121A and 121B. The steering system 122 includes a steering mechanism, an operation unit that accepts steering operation from the driver, and steering control units 122A and 122B. The powertrain system 123 includes a shift device, a vehicle drive device, an EPB device, a P-Lock device, an EPB control unit 123A, a P-Lock control unit 123B, and a propulsion control unit 123C. "EPB" stands for electric parking brake, and "P-Lock" stands for parking lock. The shift device determines a shift range and switches the propulsion direction and gear change mode of the base vehicle 120 according to the determined shift range. In addition to the gear change mechanism, the shift device further includes an operation unit that accepts shift operation from the driver. The vehicle drive device applies propulsion force in the propulsion direction indicated by the shift range. The vehicle drive device includes a battery and a traction motor that receives power from the battery. The vehicle drive device further includes an accelerator pedal that is operated by the driver to accelerate the vehicle 1. In addition to the parking lock mechanism and the actuator, the P-Lock device further includes an operation unit that accepts parking operations from the driver.

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

[0018] The PCS system prevents a collision when it determines that there is a collision risk for vehicle 1. The ECU of safety system 125 determines the possibility of a collision for vehicle 1 while it is moving. Base vehicle 120 is equipped with camera 129A and radar sensors 129B and 129C (FIG. 1) for detecting a collision risk. The ECU of safety system 125 determines whether there is a collision risk using signals received from camera 129A and radar sensors 129B and 129C. If a collision risk is determined to exist, the ECU activates the PCS. As a result, the PCS system initiates an alert in the direction in which the collision risk is detected. If the collision risk cannot be avoided by manual driving, the PCS system sequentially executes pre-fill control, braking control, and brake hold control. Pre-fill control applies hydraulic pressure to the extent that the clearance between the brake pads and rotors is reduced before braking control, thereby accelerating the rise of brake deceleration. When brake hold control is completed, the alert stops and the EPB device is activated. The PCS system continues to issue alerts unless the collision risk is eliminated. When the risk of collision disappears, the PCS is deactivated (deactivated).

[0019] The EDSS stops the vehicle 1 when an emergency occurs to the driver. An emergency stop switch 128 ( FIG. 1 ) for notifying the driver of an emergency is installed in the passenger compartment of the vehicle 1. The number and location of the emergency stop switches 128 are arbitrary. The emergency stop switch 128 is configured to switch between an ON state and an OFF state in response to an operation by a passenger (user). The state (ON / OFF) of the emergency stop switch 128 is input to the ECU of the safety system 125. The emergency stop switch 128 may be a push button. A user inside the vehicle can notify the base vehicle 120 that an emergency occurs to the driver by turning the emergency stop switch 128 to the ON state (for example, by pressing the button).

[0020] The AFSS stops the vehicle 1 if an abnormality occurs in the ADK 200. The method of detecting an ADK abnormality will be described later (see S23 and S26 in Figure 3). The AFSS activates when a predetermined first activation condition is met in automatic mode. The EDSS activates when a predetermined second activation condition is met in manual mode. These emergency stop systems assist in stopping the vehicle. Specifically, when activated, the AFSS or EDSS sequentially performs deceleration control to reduce (lower) the vehicle speed, deceleration control to stop the vehicle, and stop-maintenance control to maintain the stopped state. Then, when the stop-maintenance control is completed, the EPB device activates. The operation status of the emergency stop system is notified to the ADK 200 by the emergency stop status, which will be described later.

[0021] In this embodiment, the AFSS, EDSS, and PCS systems correspond to examples of the "first emergency stop system," "second emergency stop system," and "collision prevention system" according to the present disclosure, respectively. Various control devices provided in the base vehicle 120 function, either individually or in cooperation, as the "first control device" according to the present disclosure. The first ADC 211A and the second ADC 211B each function as the "second control device" according to the present disclosure. Furthermore, the first VCIB 111A and the second VCIB 111B each function as the "third control device" according to the present disclosure.

[0022] In this embodiment, signals (API signals) defined by an API (Application Program Interface) are 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 in accordance with the API. Hereinafter, each of the various commands output from the ADK 200 to the VCIB 110 will also be referred to as an "API command." The ADK 200 also receives various signals indicating the status of the base vehicle 120 from the VCIB 110 in accordance with the API. Hereinafter, each of the various signals received by the ADK 200 from the VCIB 110 will also be referred to as an "API status." Both the API command and the API status correspond to an API signal.

[0023] In this embodiment, the ADK 200 uses the API commands described below. The vehicle mode command is an API command that requests a transition to automatic mode or manual mode. Automatic mode and manual mode are described later. The propulsion direction command is an API command that requests a change in the shift range (R / D). The acceleration command is an API command that indicates the acceleration of the vehicle. The acceleration command requests acceleration (+) and deceleration (-) in the direction indicated by the propulsion direction status, which is described later. The immobilization command is an API command that requests the application or release of immobilization. Applying immobilization means turning the EPB to the ON state (activated state) and setting the shift range to P (parking).

[0024] The EDSS accelerator pedal inhibit command (hereinafter referred to as the "EDSS support command") is an API command for inhibiting accelerator override (acceleration of the vehicle by the accelerator pedal) for EDSS control. The EDSS support command is set to either the value "0" indicating that accelerator override is permitted, or the value "1" indicating that accelerator override is prohibited. When EDSS is operating, the ADK200 inhibits accelerator override using the EDSS support command. By inhibiting accelerator override, accelerator pedal operation is inhibited, and the vehicle will not accelerate even if the driver depresses the accelerator pedal. Note that if the value of the AFSS operation status described below is "1," accelerator pedal operation is inhibited even if the value "0" is set in the EDSS support command.

[0025] The AFSS activation command is an API command for permitting or prohibiting AFSS activation. The AFSS activation command is set to one of the following values: "0" indicating no request, "1 (Activate AFSS)" which permits AFSS activation, or "2 (Inactivate AFSS)" which prohibits AFSS activation. However, while the AFSS is in operation, the base vehicle 120 (VP100) will not accept an activation prohibition request (AFSS activation command = 2) from the ADK200.

[0026] The safety system drive control override command (hereinafter referred to as the "preventive change command") is an API command for prohibiting or canceling the operation of the PCS. However, the ADK200 can prohibit or cancel the operation of the PCS using the preventive change command only when the vehicle mode is automatic.

[0027] Some of the API commands used in the vehicle 1 have been described above. The VCIB 110 receives various API commands from the ADK 200. When the VCIB 110 receives an API command from the ADK 200, it converts the API command into a signal format that can be executed by the control device of the base vehicle 120. Hereinafter, the API command converted into a signal format that can be executed by the control device of the base vehicle 120 is also referred to as an "internal command." When the VCIB 110 receives an API command from the ADK 200, it outputs an internal command corresponding to the API command to the base vehicle 120.

[0028] Next, the API status will be described. The ADK 200 grasps the state of the base vehicle 120 using, for example, the API status described below.

[0029] The vehicle mode status is an API status that indicates the vehicle mode state. The vehicle modes include manual mode, automatic mode, and standby mode. Manual mode is a vehicle mode in which the vehicle is under the control of a driver (human). Automatic mode is a vehicle mode in which the vehicle platform (including the base vehicle) is under the control of an autonomous driving kit. Standby mode is a vehicle mode in which the vehicle is prohibited from moving. In the initial state, the vehicle mode is manual mode. The driver can select the desired vehicle mode through the in-vehicle HMI. The base vehicle 120 determines the vehicle mode taking into account the situation of the vehicle 1 and the driver's selection. The vehicle mode status outputs the corresponding values ​​"0", "1", and "2" when the current vehicle mode is manual mode, automatic mode, or standby mode, respectively.

[0030] The forward direction status is an API status that indicates the current shift range. The travel direction status is an API status that indicates the direction in which the vehicle is traveling. The travel direction status outputs the value "0" when the vehicle is traveling forward, the value "1" when the vehicle is traveling backward, and the value "2 (Standstill)" when all wheels (4 wheels) show a speed of "0" for a certain period of time. The vehicle speed status is an API status that indicates 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 that indicates the immobilization state (for example, the state of EPB and shift P).

[0031] The AFSS operation status is an API status indicating the activation state of the AFSS. The AFSS operation status outputs a value of "1 (AFSS Active)" when AFSS operation is permitted and a value of "2 (AFSS Inactive)" when AFSS operation is prohibited. Immediately after the VCIB 110 computer starts up, the AFSS operation status outputs a value of "0 (Unknown)." In this embodiment, the AFSS operation status indicating "1" or "2" is one of the conditions for transitioning the vehicle mode to automatic mode. Therefore, when the vehicle mode is manual mode, the ADK 200 determines whether to permit or prohibit AFSS operation by an AFSS operation command. The ADK 200 can enable / disable the AFSS function by an AFSS operation command. However, the ADK 200 cannot enable / disable the EDSS function.

[0032] The safety system alarm status (hereinafter referred to as the "first prevention status") is an API status that indicates the status of the safety system (alarm). The safety system drive control status (hereinafter referred to as the "second prevention status") is an API status that indicates the status of the safety system (drive control). The first and second prevention statuses indicate the operating status of the PCS.

[0033] The ADS / safety system arbitration status (hereinafter referred to as "first arbitration status") is an API status that indicates the result of arbitration between the ADS request and the safety system request. The ADS / safety system arbitrated requested acceleration (hereinafter referred to as "second arbitration status") is an API status that indicates the requested acceleration after arbitration between the ADS and the safety system. The second arbitration status outputs the requested acceleration as ground acceleration. A positive value for the requested acceleration indicates a request for acceleration, and a negative value for the requested acceleration indicates a request for deceleration.

[0034] When both the safety system 125 and the ADS210 request acceleration, if the acceleration requested by the safety system 125 is smaller than the acceleration requested by the ADS210, the first arbitration status outputs "1", the acceleration requested by the ADS210 is selected, and the second arbitration status outputs the acceleration (positive value) requested by the ADS210. When both the safety system 125 and the ADS210 request deceleration, if the deceleration (absolute value) requested by the safety system 125 is larger than the deceleration (absolute value) requested by the ADS210, the first arbitration status outputs "2", the deceleration requested by the safety system 125 is selected, and the second arbitration status outputs the deceleration (negative acceleration) requested by the safety system 125.

[0035] The VP emergency shutdown system status (hereinafter referred to as "emergency shutdown status") is an API status that indicates the operation status of the emergency shutdown system (AFSS or EDSS). The emergency shutdown status outputs a value of "0" if the emergency shutdown system is not operating, and a value of "1" if the emergency shutdown system is operating.

[0036] The communication system performance degradation status (hereinafter referred to as the "communication abnormality status") is an API status that indicates ADK communication abnormality information that may affect autonomous driving. The communication abnormality status outputs the value "0 (Normal)" when there is no abnormality in the ADK200 communication, and outputs the value "7 (Loss of function)" when there is a possibility of a communication loss with the ADK200.

[0037] The above describes some of the API statuses used in the vehicle 1. The VCIB 110 receives various sensor detection values ​​and state determination results from the base vehicle 120, and outputs various API statuses indicating the state of the base vehicle 120 to the ADK 200. The VCIB 110 acquires an API status in which a value indicating the state of the base vehicle 120 is set, and outputs the acquired API status to the ADK 200.

[0038] 3 is a flowchart for explaining the control of the vehicle 1 according to this embodiment (particularly, the automatic driving control during normal operation). Each step in the flowchart is simply represented by "S."

[0039] Referring to FIG. 3, a series of processes from S11 to S15 are repeatedly executed by any of a plurality of control devices (for example, the integrated control manager 130 and the control devices of each system shown in FIGS. 1 and 2) provided in the base vehicle 120. In S11, the base vehicle 120 determines whether the vehicle mode of the vehicle 1 is the automatic mode. If the vehicle mode is the automatic mode (YES in S11), the process proceeds to S12. In S12, the safety system 125 determines whether there is a collision risk. If there is a collision risk (YES in S12), the PCS is activated in S13, and if there is no collision risk (NO in S12), the PCS is stopped in S14. Thereafter, the process proceeds to S15.

[0040] In S15, the base vehicle 120 acquires current vehicle information and transmits the acquired vehicle information to the VCIB 110. The current vehicle information includes information indicating that the vehicle mode is automatic mode, various sensor detection values ​​indicating the current state of the base vehicle 120, and a state determination result based on a user operation or the sensor detection values. The current vehicle information also includes information indicating the state of the safety system 125 (such as a PCS), and, if arbitration between an active PCS and an ADS (see S18 described below) has been performed, further includes information indicating the arbitration result and the required acceleration after arbitration. The base vehicle 120 may store the current vehicle information in a storage device, linking it to the acquisition time.

[0041] In the following S16, the base vehicle 120 determines whether an ADK abnormality (ADK Failure) has occurred. In this embodiment, if the base vehicle 120 has not received a notification informing it of an ADK abnormality (S41 in FIG. 4, described later), the base vehicle 120 determines that an ADK abnormality has not occurred (NO in S16) and proceeds to S17. In S17, the base vehicle 120 determines whether an autonomous driving command has been received from the ADK 200. If the base vehicle 120 has not received an autonomous driving command (NO in S17), the process returns to the first step (S11). In the autonomous mode, while no ADK abnormality has occurred and no autonomous driving command has been received, the above-described S11 to S17 are repeatedly executed.

[0042] A series of processes from S21 to S26 is basically executed by the first VCIB 111A. However, if an abnormality occurs in the first VCIB 111A, the second VCIB 111B executes each process instead of the first VCIB 111A. When the VCIB 110 receives current vehicle information from the base vehicle 120, it starts a series of processes from S21 to S26.

[0043] In S21, the VCIB 110 acquires API status (for example, the various API statuses described above) indicating the current state of the base vehicle 120 based on the current vehicle information. The VCIB 110 may determine the values ​​of the various API statuses based on the detected values ​​of the various sensors. The VCIB 110 may associate the acquired values ​​of the various API statuses with the acquisition time and store them in a storage device. In the following S22, the VCIB 110 transmits the various API statuses acquired in S21 to the ADK 200. Thereafter, the process proceeds to S23.

[0044] The series of processes from S31 to S35 are basically executed by the first ADC 211A. However, if an abnormality occurs in the first ADC 211A, the second ADC 211B executes each process instead of the first ADC 211A. When the ADK 200 receives the above API status from the VCIB 110, it starts the series of processes from S31 to S35.

[0045] In S31, the ADK 200 determines whether the received vehicle mode status indicates the automatic mode. If the vehicle mode status does not indicate the automatic mode (NO in S31), the ADK 200 does not create a driving plan for automatic driving, and in S35 sends an API command to the VCIB 110 to support vehicle control in the manual mode (see S65 and S66 in FIG. 5, which will be described later). On the other hand, if the vehicle mode status indicates the automatic mode (YES in S31), the ADK 200 proceeds to S32.

[0046] In S32, the ADK200 creates a driving plan based on the detection results of various sensors (e.g., environmental information and attitude information) and the API status acquired from the VCIB110. The driving plan is data indicating the target behavior of the vehicle 1 over a predetermined period of time. The ADK200 may calculate the behavior (attitude, etc.) of the vehicle 1 and create a driving plan suited to the state of the vehicle 1 and the external environment. In this embodiment, when the ADK200 receives a communication abnormality status indicating a value of "7", the second ADC211B creates a driving plan for evacuation driving (e.g., driving to evacuate to a safe parking space). In addition, the ADK200 can prohibit or cancel the operation of the PCS by a preventive change command.

[0047] In the next step S33, the ADK 200 extracts control-related physical quantities (such as acceleration and tire turning angle) from the driving plan created in step S32. In the next step S34, the ADK 200 divides the physical quantities extracted in step S33 into API cycles. In the next step S35, the ADK 200 executes the API using the physical quantities divided in step S34. Specifically, the ADK 200 determines values ​​of various API commands based on the physical quantities divided in step S34. This results in obtaining API commands for realizing the physical quantities according to the driving plan. The ADK 200 may store the obtained API commands in a storage device, along with the values ​​of each API status received from the VCIB 110, in association with the acquisition time. The ADK 200 then transmits the obtained API commands to the VCIB 110. The API commands indicate commands (including autonomous driving commands) for the base vehicle 120. When the processing of step S35 is executed, the processing flow of steps S31 to S35 ends. However, this processing flow starts each time the ADK 200 receives an API status (S22). Therefore, as long as the vehicle mode is automatic and no ADK abnormality occurs, the ADK 200 continuously issues commands for automatic driving.

[0048] After transmitting the API status (S22), the VCIB 110 determines in S23 whether an abnormality has occurred in the communication between the ADK 200 and the VCIB 110. The VCIB 110 may determine whether or not a communication abnormality caused by a disconnection has occurred by checking for a disconnection in the communication line. Alternatively, the VCIB 110 may transmit a confirmation signal to the ADK 200 and determine whether or not a communication abnormality has occurred based on whether or not a reply has been received from the ADK 200. Alternatively, the VCIB 110 may determine that a communication abnormality has occurred if it does not receive an API command within a predetermined time after transmitting the API status. If an abnormality has occurred in the communication between at least the first ADC 211A and the VCIB 110, YES is determined in S23.

[0049] If there is no abnormality in the communication between the ADK 200 and the VCIB 110 (NO in S23), the VCIB 110 receives the API command (S35). In the following S24, the VCIB 110 converts each received API command into an internal command. Through this signal conversion, internal commands corresponding to the various API commands are obtained. In the following S25, the VCIB 110 transmits the obtained internal command to the base vehicle 120. In the automatic mode, an internal command for automatic driving (automatic driving command) is transmitted in S25. When the processing of S25 is executed, the processing flow of S21 to S26 ends. However, this processing flow is started each time the VCIB 110 receives vehicle information from the base vehicle 120.

[0050] When the base vehicle 120 receives the above-mentioned automatic driving command (S25) (YES in S17), it executes automatic driving control in accordance with the received automatic driving command in the following S18. If the PCS is operating and the acceleration or deceleration requested by the ADK 200 differs from the acceleration or deceleration requested by the PCS system, the base vehicle 120 determines one requested acceleration (acceleration: positive value, deceleration: negative value) through the above-mentioned arbitration. Then, the base vehicle 120 executes automatic driving control in accordance with the requested acceleration after arbitration. The automatic driving of the vehicle 1 is executed by the processing of S18. Then, the processing returns to the initial S11.

[0051] If an abnormality has occurred in the communication between the ADK 200 and the VCIB 110 (YES in S23), the VCIB 110 executes processing for detecting an ADK abnormality in S26. Then, as a result of the processing in S26, the base vehicle 120 determines that an ADK abnormality has occurred (YES in S16), and executes processing related to the AFSS in the subsequent S60.

[0052] Fig. 4 is a flowchart showing the details of S26 and S60. In Fig. 4, a series of processes from S41 to S47 corresponds to the process of S26 (Fig. 3), and a series of processes from S51 to S59 corresponds to the process of S60 (Fig. 3).

[0053] 4, in S41, the VCIB 110 transmits a notification to the base vehicle 120 informing it of an ADK abnormality. Subsequently, in S42, the VCIB 110 determines whether or not an abnormality has occurred in the communications of all the ADS computers (in this embodiment, the first ADC 211A and the second ADC 211B). If an abnormality has occurred in the communications of all the ADS computers (YES in S42), the VCIB 110 transmits an AFSS activation command indicating a value of "1 (permitted)" to the base vehicle 120 in S43. Thereafter, the process proceeds to S44. On the other hand, if the communications of any of the ADS computers are normal (NO in S42), the process proceeds to S45.

[0054] When the base vehicle 120 receives the notification of S41, a YES determination is made in S16 of FIG. 3, and a series of processes from S51 to S59 is initiated. In S51, the base vehicle 120 determines whether the AFSS activation condition is met. In this embodiment, the AFSS activation condition is met when both an abnormality occurs in communication between the ADK 200 and the VCIB 110 (first AFSS requirement) and the AFSS activation command indicates a value of "1 (permit)" (second AFSS requirement) are met. The AFSS activation condition is not met when at least one of these requirements is not met. As described above, since the VCIB 110 detects a communication abnormality (S26 of FIG. 3), the first AFSS requirement is met. If an abnormality occurs in communication with both the first ADC 211A and the second ADC 211B, the base vehicle 120 receives an AFSS activation command indicating a value of "1 (permit)" from the VCIB 110, and therefore the second AFSS requirement is also met, and the AFSS activation condition is met. On the other hand, if an abnormality occurs in communication only with the first ADC 211A, whether the second AFSS requirement is met depends on the value of the AFSS activation command determined by the ADK 200.

[0055] In this embodiment, the AFSS activation condition (first activation condition) is met when an abnormality occurs in the ADK 200's communication while the ADK 200 permits AFSS activation in automatic mode. This condition makes it easier for the AFSS to activate at the appropriate time. However, the AFSS activation condition is not limited to this condition and can be changed as appropriate. For example, the AFSS activation condition may be met when an abnormality occurs in the ADK 200's communication, regardless of whether the ADK 200 permits AFSS activation.

[0056] If the AFSS activation condition is met (YES in S51), the AFSS is activated in S52, and then the process proceeds to S53. If the AFSS activation condition is not met (NO in S51), the AFSS is not activated, and the process proceeds to S53. In S53, similar to S15 in FIG. 3, the base vehicle 120 acquires current vehicle information and transmits it to the VCIB 110. The current vehicle information includes information indicating the operation status (activated / inactivated) of the AFSS.

[0057] In S44 or S45, the VCIB 110 receives the current vehicle information from the base vehicle 120, and similarly to S21 and S22 in FIG. 3, acquires various API statuses indicating the current state of the base vehicle 120 based on the current vehicle information and transmits them to the ADK 200. In both S44 and S45, the transmitted API statuses include a communication abnormality status and an emergency stop status. The communication abnormality status indicates a value of "7." The emergency stop status indicates a value according to the judgment result of S51. When the processing of S44 is executed, the processing flow ends. On the other hand, when the processing of S45 is executed, the processing proceeds to S46, which will be described later.

[0058] After transmitting the vehicle information in S53 described above, the base vehicle 120 determines in S54 whether the AFSS is operating. If the AFSS is operating (YES in S54), the base vehicle 120 executes AFSS control in S55. AFSS control decelerates the vehicle 1 until it comes to a stop, and after it stops, it is held stopped and immobilized. While the AFSS is operating, acceleration of the vehicle 1 by the accelerator pedal is prohibited. AFSS control (S55) continues until immobilization is complete (NO in S56). When immobilization is complete (YES in S56), the AFSS is stopped (inactive) in S57, and the vehicle mode transitions to manual mode in S58. Thereafter, the process returns to the process flow of FIG. 3 and proceeds to S80, which will be described later.

[0059] In S46, the VCIB 110 determines whether the ADK 200 permits the AFSS to operate. If the ADK 200 permits the AFSS to operate (YES in S46), the process flow ends. In this case, the AFSS operates in S52 described above. On the other hand, if the ADK 200 prohibits the AFSS from operating (NO in S46), the VCIB 110 transmits a command from the ADK 200 to the base vehicle 120 in S47. More specifically, when the ADK 200 receives the API status (S45), the second ADC 211B starts a series of processes from S31 to S35 in FIG. 3. The second ADC 211B generates an API command for evacuation travel based on the received API status and transmits it to the VCIB 110. In this case, the AFSS does not operate (NO in S54). In S59, the base vehicle 120 executes automatic driving control for evacuation traveling in accordance with the command (S47) received from the VCIB 110. After the processing of S47 and S59 is executed, the processing returns to the processing flow of Fig. 3. Then, if the situation does not change, the above-described processing is executed again in S26 and S60 of Fig. 3, and automatic driving control for evacuation traveling continues.

[0060] 3 again, if the vehicle mode is not the automatic mode (NO in S11), base vehicle 120 executes processing related to manual driving in S80. FIG. 5 is a flowchart showing the details of S80.

[0061] Referring to FIG. 5, in S61, the base vehicle 120 determines whether the vehicle mode is the manual mode. If the vehicle mode is the standby mode, NO is determined in S61, and the process returns to the process flow (S11) of FIG. 3. If the vehicle mode is the manual mode (YES in S61), the base vehicle 120 checks various user inputs to the vehicle 1 from the user in S62. The user inputs include operations for manual driving by the driver and operations of the emergency stop switch 128 by the driver or a passenger. In the following S63, the base vehicle 120 determines whether the EDSS activation condition is met. In this embodiment, the EDSS activation condition is met when the emergency stop switch 128 is in the ON state, and the EDSS activation condition is not met when the emergency stop switch 128 is in the OFF state.

[0062] In this embodiment, the EDSS activation condition (second activation condition) is met when the vehicle 1 receives an input informing the driver that an emergency situation has occurred in manual mode. Such a condition makes it easier for the EDSS to activate at an appropriate time. However, the input for activating the EDSS is not limited to an input in response to a user operation (e.g., a button operation) as described above, but may also be a voice input. Furthermore, the EDSS activation condition can be changed as appropriate. For example, in a vehicle equipped with a system that detects that a driver emergency situation has occurred (e.g., a system that determines the driver's situation by image recognition), the EDSS activation condition may be met when the system detects that the driver emergency situation has occurred.

[0063] If the EDSS activation condition is met (YES in S63), the EDSS is activated in S64, and then the process proceeds to S65. If the EDSS activation condition is not met (NO in S63), the EDSS is not activated, and the process proceeds to S65. In S65, similar to S15 in FIG. 3, the base vehicle 120 acquires current vehicle information and transmits it to the VCIB 110. The current vehicle information includes information indicating the EDSS activation status (activated / inactivated).

[0064] When the VCIB 110 receives the current vehicle information (S65), a series of processes from S21 to S26 in FIG. 3 is started. Through the process of S22, the ADK 200 receives various API statuses indicating the current state of the base vehicle 120. Then, in S35 in FIG. 3, the ADK 200 transmits to the VCIB 110 an EDSS support command indicating a value (1 / 0) corresponding to the EDSS operation status (operated / inoperated). Then, in S25 in FIG. 3, the VCIB 110 transmits to the base vehicle 120 an internal command (ADK command) corresponding to the API command (including the EDSS support command) received from the ADK 200.

[0065] In S66, the base vehicle 120 acquires the ADK command corresponding to the current vehicle information from the VCIB 110. Then, in S67, the base vehicle 120 reflects the ADK command in vehicle control in manual mode. For example, if the EDSS support command indicates a value of "1," the base vehicle 120 disables accelerator pedal operation among the driving operations (manual driving operations) by the driver confirmed in S62.

[0066] In the following S71, the base vehicle 120 determines whether the EDSS is operating. If the EDSS is operating (YES in S71), the base vehicle 120 executes EDSS control in the following S76. EDSS control decelerates the vehicle 1 until it stops, and after stopping, it is held stationary and immobilized. While the EDSS is operating, the ADK 200 transmits an EDSS support command indicating a value of "1," and the processing of S67 prohibits acceleration of the vehicle 1 using the accelerator pedal. The base vehicle 120 may reflect manual driving operations other than accelerator operation (S62) in the EDSS control. The EDSS control (S76) continues until immobilization is complete (NO in S77). When immobilization is complete (YES in S77), the EDSS is stopped (deactivated) in S78. Thereafter, the processing returns to the processing flow (S11) of FIG. 3.

[0067] If the EDSS is not activated (NO in S71), the process proceeds to S72. In S72, the safety system 125 determines whether there is a collision risk. If there is a collision risk (YES in S72), the PCS is activated in S73. If there is no collision risk (NO in S72), the PCS is deactivated in S74. Then, the process proceeds to S75. In S75, the base vehicle 120 executes manual driving control of the vehicle 1 in accordance with the driving operation by the driver confirmed in S62. In this manual driving control, acceleration of the vehicle 1 by the accelerator pedal is permitted. After the process of S75 is executed, the process returns to the process flow (S11) of FIG. 3. If the EDSS activation condition is not met in the manual mode, the above-described process is executed again in S80 of FIG. 3, and manual driving control continues.

[0068] As described above, the vehicle 1 according to this embodiment includes the VP100 (vehicle platform) and the ADK200 (autonomous driving kit). The ADK200 requests the VP100 to prohibit acceleration of the vehicle 1 by the accelerator pedal while the EDSS is operating (see S65 to S67 in FIG. 5). The VP100 prohibits acceleration of the vehicle by the accelerator pedal while the AFSS is operating, regardless of whether or not a request is received from the ADK200 (see S55 in FIG. 4). With this configuration, acceleration of the vehicle 1 by the accelerator pedal is prohibited by a request from the ADK200 while the EDSS is operating. This makes it easier for the EDSS to properly stop the vehicle 1 when an emergency occurs to the driver. In this way, the ADK200 supports proper operation of the EDSS, thereby improving the emergency stopping performance of the VP100. Furthermore, while the AFSS is operating, an abnormality occurs in the ADK200. Therefore, the VP 100 prohibits acceleration of the vehicle 1 by the accelerator pedal regardless of whether or not there is a request from the ADK 200. This makes it easier for the AFSS to stop the vehicle 1 appropriately when an abnormality occurs in the ADK 200. With the above configuration, it becomes possible to stop the vehicle 1 appropriately using the AFSS and EDSS in an emergency.

[0069] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The technical scope of the present disclosure is defined by the claims, not by the description of the above embodiments, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0070] 1 vehicle, 100 vehicle platform, 110 vehicle control interface box, 120 base vehicle, 125 safety system, 128 emergency stop switch, 200 autonomous driving kit.

Claims

1. A vehicle comprising a vehicle platform that controls the vehicle and an autonomous driving kit that transmits commands for autonomous driving to the vehicle platform, The vehicle platform includes an accelerator pedal operated by a driver to accelerate the vehicle, a first emergency stop system that stops the vehicle when an abnormality occurs in the autonomous driving kit, and a second emergency stop system that stops the vehicle when an emergency occurs to the driver; The autonomous driving kit requests the vehicle platform to prohibit acceleration of the vehicle by the accelerator pedal while the second emergency stop system is activated; The vehicle platform prohibits acceleration of the vehicle by the accelerator pedal while the first emergency stop system is activated, regardless of whether there is a request from the autonomous driving kit.

2. the vehicle is configured to be operable in an autonomous mode in which the vehicle platform is under the control of the autonomous driving kit and in a manual mode in which the vehicle is under the control of the driver; the first emergency stop system is activated when a first activation condition is met in the automatic mode; 2. The vehicle of claim 1, wherein the second emergency stop system is activated when a second activation condition is met in the manual mode.

3. The first activation condition is met when an abnormality occurs in communication of the autonomous driving kit while the autonomous driving kit permits activation of the first emergency stop system, 3. The vehicle of claim 2, wherein the second activation condition is met when the vehicle receives an input that notifies the driver that an emergency situation has occurred.

4. The vehicle platform further includes a collision prevention system that prevents a collision when it determines that there is a collision risk related to the vehicle; The vehicle of claim 1 , wherein the vehicle platform arbitrates when the acceleration or deceleration requested by the autonomous driving kit differs from the acceleration or deceleration requested by the collision prevention system.

5. the vehicle platform comprises a base vehicle including a first controller; The autonomous driving kit includes a second control device that determines commands related to autonomous driving control, the vehicle platform further comprises a vehicle control interface box including a third controller configured to be able to communicate with both the first controller and the second controller; the first control device is configured to transmit vehicle information regarding the base vehicle to the third control device; An API signal defined by an API (Application Program Interface) is used for communication between the second control device and the third control device, the API signal includes an API command indicating an instruction to the base vehicle and an API status indicating a state of the base vehicle; the third control device is configured to convert the API command from the second control device into a signal executable by the first control device and transmit the converted signal to the first control device; The vehicle described in any one of claims 1 to 4, wherein the third control device is configured to acquire the API status using the vehicle information from the first control device and transmit the acquired API status to the second control device.

Images