Vehicle control device and vehicle platform

Abstract

The invention relates to a vehicle control device and a vehicle platform. The present invention smoothens the behavior of a vehicle until the start of back-off travel. A vehicle control device is connected between a driving system including a first computer module and a second computer module and a base vehicle that performs automatic driving according to a command sent from the first computer module or the second computer module. A vehicle control device includes a memory and a processor. If both communication between the processor and the first computer module and communication between the processor and the second computer module are not possible, the processor transmits, to a travel control device that is different from the vehicle control device, a signal for starting the retreat travel control. And causes the travel control device to execute travel control in accordance with the last received request value until the retreat travel control starts.

Description

Technical Field

[0001] This disclosure relates to vehicle control devices and vehicle platforms. Background Technology

[0002] Patent document 1 (Japanese Patent Application Publication No. 2018-132015) discloses a conventional vehicle. This vehicle is equipped with a powertrain system, a power supply system, and an automatic driving system. The powertrain system is the part that comprehensively manages the vehicle's power. The automatic driving system is the part that comprehensively executes the automatic driving control of the vehicle.

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent Document 1: Japanese Patent Application Publication No. 2018-132015

[0006] Consider an autonomous driving system (autonomous driving kit) externally mounted on the vehicle body (vehicle platform). In this case, the autonomous driving kit is connected to the vehicle platform via communication, and the vehicle body is controlled according to commands from the autonomous driving kit, thereby achieving autonomous driving. For redundancy, this communication can be performed separately from a first computer module and a second computer module in the autonomous driving kit. For example, when communication with the first computer module becomes impossible during autonomous driving based on commands from the first computer module, autonomous driving continues based on commands from the second computer module. Furthermore, if communication between both the first and second computer modules becomes impossible, reverse driving control to bring the vehicle to a stop is executed in the vehicle platform.

[0007] However, during the period from when communication between the two becomes impossible until the retreat control is executed, the vehicle's behavior may become unnatural. Summary of the Invention

[0008] This disclosure was made in view of the aforementioned problems, and its purpose is to make the behavior of the vehicle smooth from the start of the avoidance maneuver.

[0009] According to one aspect of this disclosure, a vehicle control device is connected between a driving system and a base vehicle, wherein the driving system includes a first computer module and a second computer module, and the base vehicle performs autonomous driving according to commands sent from the first computer module or the second computer module. The vehicle control device includes a memory and a processor. The memory stores a program containing defined APIs according to each signal definition. The processor controls the base vehicle according to commands by executing the program. Conditioned that communication between the processor and the first computer module and communication between the processor and the second computer module becomes impossible, the processor sends a signal initiating a retreat driving control to a driving control device separate from the vehicle control device, and causes the driving control device to perform driving control according to the last received request value until the retreat driving control begins.

[0010] According to one aspect of this disclosure, a vehicle platform includes a base vehicle and a vehicle control unit. The base vehicle performs autonomous driving according to commands sent from a first computer module or a second computer module of the driving system. The vehicle control unit is connected between the driving system and the base vehicle. The base vehicle includes a driving control unit different from the vehicle control unit. The vehicle control unit includes a memory and a processor. The memory stores a program containing defined APIs according to each signal. The processor executes the program to control the base vehicle according to commands. Conditional on the condition that communication between the processor and the first computer module and communication between the processor and the second computer module becomes impossible, the processor sends a signal to the driving control unit to initiate retreat driving control, and causes the driving control unit to execute driving control according to the last received request value until retreat driving control begins.

[0011] Invention Effects

[0012] According to this disclosure, the behavior of the vehicle up to the start of the avoidance maneuver can be made smooth. Attached Figure Description

[0013] Figure 1 This is a diagram showing the schematic configuration of vehicle 1 according to an embodiment of the present disclosure.

[0014] Figure 2 This is a diagram showing the internal control system of vehicle 1.

[0015] Figure 3 This is a diagram that shows in detail a portion of the control system inside vehicle 1.

[0016] Figure 4 This is a flowchart representing the process of handling limp-side-related actions performed by VCIB110.

[0017] Figure 5 It is a detailed representation Figure 4 The flowchart shows the processing of the first processor 1112A in step 04.

[0018] Explanation of reference numerals in the attached figures

[0019] 1: Vehicle; 100: VP; 110: VCIB; 111A: First VCIB; 111B: Second VCIB; 120: Base vehicle; 121: Braking system; 121A, 121B: Brake control unit; 122: Steering system; 122A, 122B: Steering control unit; 123: Powertrain system; 123A: EPB control unit; 123B: P-Lock control unit; 123C: Propulsion control unit; 125: Active safety system; 126: Body system; 127A, 127B: Wheel speed sensors; 127C: Steering angle sensor; 128, 218: HMI; 129A 129B, 129C: Camera; 130: ICM; 200: Autopilot module; 210: DS; 211: DSCOM; 211A: First CM; 211B: Second CM; 212: Recognition sensor; 213: Attitude sensor; 216: Sensor cleaner; 500: Remote cockpit; 510: Control device; 520: Display device; 530: Input device; 1101: Memory; 1102: Processor; 1111A: First memory; 1111B: Second memory; 1112A: First processor; 1112B: Second processor; CL: Cloud. Detailed Implementation

[0020] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that the same or equivalent parts in the drawings are labeled with the same reference numerals, and their descriptions will not be repeated.

[0021] Figure 1 This is a diagram showing the schematic configuration of vehicle 1 according to an embodiment of the present disclosure. (Refer to...) Figure 1Vehicle 1 is equipped with a Vehicle Platform (VP) 100 and an autonomous driving module 200. The autonomous driving module 200 functions as both an Autonomous Driving Kit (ADK) for autonomous driving (i.e., vehicle-independent autonomous driving) and a Remote Driving Kit (RDK) for remote driving (i.e., autonomous driving based on signals from outside the vehicle). In autonomous driving, Vehicle 1 can drive independently. Through autonomous driving, Vehicle 1 can drive in a manner that receives no instructions from outside the vehicle or from a person inside the vehicle (driver). Autonomous driving can also be autonomous driving, generally referred to as "fully autonomous driving." In remote driving, Vehicle 1 can drive in a manner that receives no instructions from a person inside the vehicle (driver). In remote driving, Vehicle 1 can drive based on instructions from devices outside the vehicle or based on remote operations performed by a person outside the vehicle. The driving plan for remote driving can be generated by Vehicle 1 based on signals from outside the vehicle or generated from outside the vehicle (e.g., cloud CL). In this embodiment, whether in autonomous driving or remote driving, vehicle 1 generates a driving plan for autonomous driving.

[0022] The control system of vehicle 1 in this embodiment includes a remote cockpit 500 located outside the vehicle 1. The remote cockpit 500 includes a control device 510, a display device 520 for displaying the environment of vehicle 1 (e.g., surrounding scenery and the road being driven on), and an input device 530 for accepting remote operations (e.g., driving operations and vehicle system operations). The remote cockpit 500 may also have a driver's seat based on a typical vehicle. A user can monitor / operate vehicle 1 from a remote location using the remote cockpit 500. The control device 510 of the remote cockpit 500 communicates with vehicle 1 via a communication system (including a cloud CL). The cloud CL has computer functionality and communicates with both the remote cockpit 500 and vehicle 1. The cloud CL sends signals to vehicle 1 based on remote operations of the input device 530. Furthermore, the cloud CL sends signals to the remote cockpit 500 based on information from vehicle 1. In this embodiment, the user (person) operates vehicle 1 via the input device 530. However, this is not the only possibility; AI (Artificial Intelligence) could also remotely operate vehicle 1 from outside the vehicle, replacing a human. It should be noted that the cloud CL (Cloud Controller) can also hold the latest map and traffic information. Edge computing technology can also be utilized to reduce the amount of data processed by the cloud CL or to shorten latency during remote driving.

[0023] VP100 includes a vehicle control unit 110 and a base vehicle 120. In this embodiment, the vehicle control unit 110 is a vehicle control interface box. Hereinafter, the vehicle control unit 110 will sometimes be referred to as "VCIB110". By adding VCIB110 to the base vehicle 120, VP100 is formed that allows the autonomous driving module 200 to be mounted and dismounted. Furthermore, by mounting the autonomous driving module 200 onto VP100, vehicle 1 is completed. VCIB110 is configured to communicate with both the base vehicle 120 and the autonomous driving module 200 via a communication bus. In this embodiment, the autonomous driving module 200 is mounted on the roof of the base vehicle 120. However, the mounting position of the autonomous driving module 200 can be appropriately changed.

[0024] 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 also be an xEV other than a BEV. The base vehicle 120 includes a driving control device 130, various systems and sensors (wheel speed sensor 127A, wheel speed sensor 127B, steering angle sensor 127C, etc.) for controlling the base vehicle 120, and an HMI (Human Machine Interface) 128. Specifically, the driving control device 130 is an integrated control manager (hereinafter referred to as "ICM"). Hereinafter, the driving control device 130 will sometimes be referred to as "ICM130". The ICM130 functions as a control device different from the VCIB110. The ICM130 performs integrated control of various systems related to the operation of the base vehicle 120 based on the detection results of the on-board sensors. The HMI128 includes input devices and reporting devices. HMI128 may also include a navigation system.

[0025] Figure 2 This is a diagram showing the internal control system of vehicle 1. Figure 3 This is a diagram showing in detail a portion of the control system inside vehicle 1. (Refer to...) Figures 1 to 3 The autonomous driving module 200 includes a driving system (hereinafter referred to as "DS") 210 for performing autonomous driving of the vehicle 1. VCIB 110 is connected between DS 210 and the base vehicle 120. DS 210 includes a computer component (hereinafter referred to as "DSCOM") 211, a recognition sensor 212, a posture sensor 213, a sensor cleaner 216, and an HMI (human-machine interface) 218.

[0026] DSCOM 211 includes a first computer module (hereinafter, sometimes referred to as "first CM") 211A and a second computer module (hereinafter, sometimes referred to as "second CM") 211B. Each of the first CM 211A and the second CM 211B has a processor and a storage device for storing autonomous driving software utilizing the API (Application Program Interface) described later. Each of the first CM 211A and the second CM 211B is configured to execute the autonomous driving software via the processor. DSCOM 211 switches between autonomous driving and remote driving based on the value of the driving ID described later. Specifically, if the driving ID value is "ADK", DSCOM 211 outputs commands related to autonomous driving; if the driving ID value is "RDK", DSCOM 211 outputs commands related to remote driving. Commands from DSCOM 211 are sent to VP 100 via VCIB 110. The base vehicle 120 performs autonomous driving according to the commands sent from the first CM 211A or the second CM 211B via VCIB 110.

[0027] The identification sensor 212 includes a sensor that acquires information representing the external environment of the vehicle 1 (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 the vehicle 1 (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 a reporting device.

[0028] 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").

[0029] In vehicle 1, the control system related to the behavior (driving / stopping / turning) of vehicle 1 is redundant. The first CM211A and the second CM211B provide instructions to the main control system and the auxiliary control system, respectively. Accordingly, VCIB110 includes a control unit (hereinafter referred to as "first VCIB") 111A of the main control system and a control unit (hereinafter referred to as "second VCIB") 111B of the auxiliary control system.

[0030] The braking system 121 includes a braking mechanism, an operating unit that receives braking operations from the driver, and braking control units 121A and 121B. The steering system 122 includes a steering mechanism, an operating unit that receives steering operations from the driver, and steering control units 122A and 122B. The powertrain system 123 includes a gear shifting device, a vehicle drive unit, 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" refers to Electric Parking Brake, and "P-Lock" refers to Parking Lock. The gear shifting device determines the gear position and switches the propulsion direction and transmission mode of the base vehicle 120 according to the determined gear position. In addition to the gear shifting mechanism, the gear shifting device also includes an operating unit that receives gear shifting operations from the driver. The vehicle drive system includes a battery, a driving motor that receives power from the battery, and an operating unit that receives acceleration commands from the driver. The vehicle drive system provides propulsion in the direction of travel indicated by the gear position. The P-Lock device, in addition to a parking lock mechanism and actuator, also includes an operating unit that receives parking commands from the driver.

[0031] The active safety system 125 includes a PCS (Pre-Collision Safety) system. The PCS system prevents a collision when it determines there is a risk of collision with vehicle 1. The ECU of the active safety system 125 determines the likelihood of a collision with vehicle 1 while it is in motion. The base vehicle 120 includes a camera 129A and radar sensors 129B and 129C for sensing the risk of collision. Figure 1 The ECU of the active safety system 125 uses signals received from camera 129A and radar sensors 129B and 129C to determine if there is a collision risk. If a collision risk is determined to be present, the ECU activates the PCS system.

[0032] In this embodiment, signals defined by an API (Application Programming Interface) (API signals) are used in the communication between DS210 and VCIB110. DS210 is configured to process various signals defined by the API. DS210 outputs various commands to VCIB110 according to the API. Hereinafter, the various commands output from DS210 to VCIB110 will be referred to as "API commands". Furthermore, DS210 receives various signals indicating the status of the base vehicle 120 from VCIB110 according to the API. Hereinafter, the various signals received by DS210 from VCIB110 will be referred to as "API status". Both API commands and API status are equivalent to API signals.

[0033] In this embodiment, the DS210 uses the API commands described below. The vehicle mode command is an API command that requests a switch to automatic driving mode or manual driving mode. Automatic driving mode and manual driving mode will be described later. The directional control command is an API command that requests a gear shift (R (reverse) / D (drive)). The acceleration command is an API command that indicates the vehicle's acceleration. The acceleration command requests acceleration (+) and deceleration (-) relative to the direction indicated by the directional control conditions described later. It should be noted that the requested values ​​described later include the requested values ​​for acceleration and / or deceleration. The lock command is an API command that requests applying or deactivating lock. Applying lock means putting the EPB in the ON state (operating state) and setting the gear to P (park).

[0034] The above describes some of the API commands used in vehicle 1. VCIB110 receives various API commands from DS210. When VCIB110 receives an API command from DS210, it converts the API command into a signal form that can be executed by the control device of the base vehicle 120. Hereinafter, the API command after being converted into a signal form that can be executed by the control device of the base vehicle 120 will also be referred to as an "internal command". When VCIB110 receives an API command from DS210, it outputs the internal command corresponding to the API command to the base vehicle 120.

[0035] VCIB110 includes a memory 1101 and a processor 1102. The memory 1101 stores a program containing a defined API for each signal. The processor 1102 executes the program to control the base vehicle 120 according to commands from DS210 (i.e., various API commands).

[0036] The first VCIB 111A includes a computer comprising a first memory 1111A and a first processor 1112A. The second VCIB 111B includes a second memory 1111B and a second processor 1112B. In other words, the memory 1101 in VCIB 110 includes the first memory 1111A and the second memory 1111B, and the processor 1102 in VCIB 110 includes the first processor 1112A and the second processor 1112B.

[0037] The first VCIB111A (first processor 1112A) is configured to receive commands (i.e., various API commands) from the first CM211A. The first memory 1111A stores a program containing defined APIs for each signal. The first processor 1112A is configured to control the base vehicle 120 according to commands from the first CM211A by executing this program.

[0038] The second VCIB111B (second processor 1112B) is configured to receive commands (i.e., various API commands) from the second CM211B. The second memory 1111B stores a program containing defined APIs for each signal. The second processor 1112B is configured to control the base vehicle 120 according to commands from the second CM211B by executing this program.

[0039] The first VCIB111A (first processor 1112A) and the second VCIB111B (second processor 1112B) can communicate directly with the various systems of the base vehicle 120, or via... Figure 1 and Figure 3 The ICM130 shown communicates with various systems of the base vehicle 120.

[0040] Next, the API status will be explained. The DS210 uses the API status described below to understand the status of the base vehicle 120, for example.

[0041] Vehicle mode status is an API status indicating the vehicle's driving mode. Vehicle modes include manual driving mode and autonomous driving mode. Manual driving mode is when the vehicle is under the control of a driver (human). Autonomous driving mode is when the vehicle platform (including the base vehicle) is under the control of the autonomous driving module 200. Initially, the vehicle mode is manual driving mode. The driver can select the desired vehicle mode via the onboard HMI.

[0042] The directional propulsion status indicates the current gear position in the API. The travel direction status indicates the vehicle's travel direction in the API. The vehicle speed status indicates the vehicle's longitudinal speed in the API, outputting the absolute value of the vehicle speed. The stationary status indicates a stationary state (e.g., the state of EPB and gear P).

[0043] The driving identification status (hereinafter referred to as "Driving ID") is an API status indicating whether the communication between the DS210 (DSCOM211) and VCIB110 (first VCIB111A and second VCIB111B) is for autonomous driving or remote driving. In autonomous driving, the Driving ID outputs the value "ADK", and in remote driving, it outputs the value "RDK". This Driving ID facilitates the integration of both autonomous and remote driving.

[0044] The above describes some of the API states used in vehicle 1. VCIB110 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 DS210. VCIB110 acquires API states with values ​​set to represent the state of the base vehicle 120, and outputs the obtained API states to DS210.

[0045] As described above, in the vehicle 1 of this embodiment, a VCIB 110 is provided to receive control information from the DS 210. Furthermore, separate from the VCIB 110, an ICM 130 is provided to receive commands from the VCIB 110 to control the vehicle's movement. In the case of reversing movement of the vehicle 1, it is considered that the reversing movement is controlled by the ICM 130. In this embodiment, as will be explained below, the vehicle 1 is configured such that when switching from control corresponding to a control request from the VCIB 110 to reversing movement control performed by the ICM 130, the vehicle's behavior is smooth.

[0046] Figure 4 This is a flowchart illustrating the process of handling limp-aside operations performed by the VCIB110. For example... Figure 4 As shown, the program for this process is stored in memory 1101 and is called and executed from the higher-level processor by the processor 1102 of the vehicle control device 110 at predetermined intervals. Specifically, the program for this process is executed through the cooperation of the first processor 1112A and the second processor 1112B.

[0047] The first processor 1112A determines whether it is in an RDK-based autonomous driving mode (step (hereinafter, sometimes referred to as "S") 01). If it is determined that it is not in an RDK-based autonomous driving mode (no in S01), the first processor 1112A returns the executed process to the higher-level process.

[0048] On the other hand, if it is determined that the vehicle is in an RDK-based autonomous driving mode (yes in S01), the first processor 1112A determines whether the vehicle 1 is in a limp-to-the-side control state (S02). Limp-to-the-side control is used to enable the vehicle 1 to perform appropriate backing and automatically stop in the event of a malfunction in the RDK (DS210) control. If it is determined that the vehicle 1 is not in a limp-to-the-side control state (no in S02), the first processor 1112A determines whether the communication between the first CM211A and the first processor 1112A has been interrupted (S03). If it is determined that the communication between the first CM211A and the first processor 1112A has not been interrupted (no in S03), the first processor 1112A controls the driving of the vehicle 1 according to the command from the first CM211A (S04) and returns the executed processing to the higher-level processing.

[0049] Figure 5 It is a detailed representation Figure 4 The flowchart shows the processing of the first processor 1112A in step 04, etc. (See attached flowchart). Figure 5 As shown, in step 04 of this embodiment, the first processor 1112A first sends a command to the ICM 130 to accept the request from the first processor 1112A and not accept the request from the second processor 1112B (S041A). Then, the first processor 1112A sends the first request value received from the first CM 211A to the ICM 130 (S042A). Specifically, the first request value is an acceleration request value. Thus, S04 is executed. It should be noted that in S04, while performing the above processing, the first processor 1112A also sends the first request value received from the first CM 211A to the second processor 1112B of the second VCIB 111B (S043A).

[0050] Thus, in steps S01 to S04, the second processor 1112B does not participate in the driving control of vehicle 1. However, as Figure 5 As shown, the second processor 1112B of the second VCIB111B performs the following processing during steps S01 to S04.

[0051] The second processor 1112B receives a first request value from the first processor 1112A, which is received from the first CM211A (see S043A). Furthermore, the second processor 1112B determines whether communication between the second CM211B and the second processor 1112B has been interrupted (S051B). If it is determined that communication between the second CM211B and the second processor 1112B has not been interrupted (no in S051B), the second processor 1112B sends the second request value received from the second CM211B to the ICM130 (S052B). Specifically, the second request value is an acceleration request value. Moreover, the second processor 1112B also sends the second request value received from the second CM211B to the first processor 1112A of the first VCIB111A (S053B). Afterwards, the second processor 1112B returns the executed processing to the higher-level processing.

[0052] Furthermore, if it is determined that communication between the second CM211B and the second processor 1112B has been interrupted (yes in S051B), the second processor 1112B sends a message indicating that communication between the second processor 1112B and the second CM211B has been interrupted to the first processor 1112A of the first VCIB111A (S054B). Then, the second processor 1112B sends the first request value, instead of the second request value, received from the first processor 1112A to the ICM130 (S055B). Afterward, the second processor 1112B returns the executed process to the previous process.

[0053] Here, we will again explain the handling related to limp-to-the-edge maneuvers. For example... Figure 4 As shown, if it is determined that communication between the first CM211A and the first processor 1112A has been interrupted (yes in S03), the first processor 1112A determines whether communication between the second CM211B and the second processor 1112B has been interrupted (S11). This determination is based on whether a communication interruption message has been received or not (see reference). Figure 5 The process is performed according to S054B. If it is determined that communication between the second CM211B and the second processor 1112B is not interrupted (not in S11), the second processor 1112B controls the movement of the vehicle 1 according to the command from the second CM211B (S12), and the first processor 1112A returns the executed processing to the higher-level processor. Specifically, in S12, the second processor 1112B sends a command to the ICM130 to accept the request from the second processor 1112B and not accept the request from the first processor 1112A. In this way, since the second processor 1112B has already sent the second request value received from the second CM211B to the ICM130 (see S054B), the second processor 1112B controls the movement of the vehicle 1 according to the command from the second CM211B (S12), and the first processor 1112A returns the executed processing to the higher-level processor. Figure 5 (S052B), therefore the second processor 1112B essentially performs driving control of vehicle 1 according to commands from the second CM211B.

[0054] If the first processor 1112A determines that communication between the first CM211A and the first processor 1112A has been interrupted (yes in S03), and communication between the second CM211B and the second processor 1112B has been interrupted (yes in S11), the second processor 1112B requests limp-side control from the ICM130 (S21). Then, the second processor 1112B causes the ICM130 to execute driving control according to the request value last received from the DS210 by the VCIB110 (S22), and returns the executed process to the higher-level process. As a result, the second processor 1112B causes the ICM130 to execute driving control according to the request value last received from the DS210 by the VCIB110 until the retreat driving control (limp-side control) begins. More specifically, the second processor 1112B issues a command to the ICM 130, causing the ICM 130 to execute driving control according to the last requested value received by the ICM 130 from the second processor 1112B, until the retreat driving control begins. More specifically, the requested value includes a requested value for acceleration, and the driving control includes the control of the braking control units 121A and 121B of the braking system 121 and the control of the propulsion control unit 123C of the powertrain system 123.

[0055] Here, the last request value received by ICM130 from the second processor 1112B will be explained. During the period (S12) when the second processor 1112B controls the movement of vehicle 1 according to the command from the second CM211B, if communication between the second CM211B and the second processor 1112B is interrupted (yes in S11), the last request value received by ICM130 from the second processor 1112B is the second request value received by the second processor 1112B from the second CM211B. Figure 5 (S053B). Thus, shortly before and shortly after the communication interruption with the second CM211B, the ICM130 follows the same request value for controlling the vehicle 1, thereby enabling smooth behavior of the vehicle 1 from the communication interruption to the start of reverse driving.

[0056] On the other hand, during the period when the first processor 1112A controls the driving of the vehicle 1 according to the command from the first CM211A (S04), the communication between the second CM211B and the second processor 1112B has been interrupted (in Figure 5In the case where communication between the first CM211A and the first processor 1112A is interrupted (as stated in both S03 and S11), the last request value received by the ICM130 from the second processor 1112B is the first request value received by the first processor 1112A from the first CM211A. Figure 5 (S043A and S055B). Therefore, shortly before and shortly after the communication interruption with the first CM211A, the requested value followed by the ICM130 for controlling the vehicle 1 is the same, thus enabling smooth behavior of the vehicle 1 from the communication interruption to the start of reverse driving. Furthermore, even if the communication interruption with the second CM211B occurs before the communication interruption with the first CM211A, the control executed by the first processor 1112A can be switched to the control executed by the second processor 1112B, triggered by the communication interruption with the first CM211A. By simplifying the conditions for switching control in this way, functional safety can be improved in the event of anomalies related to the first processor 1112A.

[0057] If the first processor 1112A determines that the vehicle 1 is in a limp-to-the-side control state (yes in S02), the processor 1102 does not control the vehicle 1 (S31). At this time, the ICM 130 does not perform reverse driving control (limp-to-the-side control) based on the last request value received from the second processor 1112B, so the processor 1102 does not interfere with this control.

[0058] Next, the first processor 1112A determines whether it is in a deceleration process executed by the ICM 130 (S32). If it is determined that it is not in a deceleration process executed by the ICM 130 (no in S32), the first processor 1112A determines whether it is in a stop-and-hold process executed by the ICM 130 (S33). If it is determined that it is in a deceleration process executed by the ICM 130 (yes in S32) or in a stop-and-hold process executed by the ICM 130 (yes in S33), the first processor 1112A switches the vehicle mode from automatic driving mode to manual driving mode (S41). If it is determined that it is not in a deceleration process executed by the ICM 130 (no in S32) and is not in a stop-and-hold process executed by the ICM 130 (no in S33), the first processor 1112A returns the executed process to the previous process.

[0059] It should be noted that, in this embodiment, the execution is assumed to be performed while in an RDK-based autonomous driving mode. Figure 4 The processing after S02. However, it is not limited to this, and it can also be set to perform the processing after S02 even when in ADK-based autonomous driving mode.

[0060] Furthermore, in this embodiment, the RDK limp-to-the-edge control is performed by the ICM130. However, it is not limited to this; the RDK limp-to-the-edge control can be performed by any control device different from the VCIB110. In the case where the control is performed by a control device different from the ICM130, the aforementioned disclosure can also be applied.

[0061] As described above, the vehicle control device 110 of this embodiment is connected between the driving system 210 and the base vehicle 120. The driving system 210 includes a first computer module 211A and a second computer module 211B. The base vehicle 120 performs autonomous driving according to commands sent from the first computer module 211A or the second computer module 211B. The vehicle control device 110 includes a memory 1101 and a processor 1102. The memory 1101 stores a program containing a defined API defined for each signal. The processor 1102 controls the base vehicle 120 according to commands by executing the program. When communication between the processor 1102 and the first computer module 211A and communication between the processor 1102 and the second computer module 211B becomes impossible (yes in S03 and S11), the processor 1102 sends a signal to start the retreat driving control to a driving control device 130 that is different from the vehicle control device 110 (S21), and causes the driving control device 130 to perform driving control according to the last received request value until the retreat driving control starts (S22).

[0062] According to the above configuration, after communication between the first computer module 211A and the second computer module 211B becomes impossible, driving control is performed according to the last received request value during the period until the start of the retreat driving, thus enabling the behavior of vehicle 1 to be smooth.

[0063] In the vehicle control device 110 of this embodiment, the processor 1102 includes a first processor 1112A and a second processor 1112B. The first processor 1112A is configured to receive commands from a first computer module 211A. The second processor 1112B is configured to receive commands from a second computer module 211B. When communication between the first processor 1112A and the first computer module 211A is possible (not in S03), the first processor 1112A executes driving control according to the commands received from the first computer module 211A (S041A, S042A), and sends the request value received from the first computer module 211A to the second processor 1112B (S043A). When communication between the first processor 1112A and the first computer module 211A becomes impossible (yes in S03), and communication between the second processor 1112B and the second computer module 211B is possible (no in S11), the second processor 1112B executes driving control according to the command received from the second computer module 211B (S12). When the second processor 1112B is executing driving control (S12), and communication between the second processor 1112B and the second computer module 211B becomes impossible (yes in S11), the second processor 1112B causes the driving control device 130 to execute driving control according to the last request value received from the second computer module 211B (see S053B) until retreat driving control begins (S22). When communication between the first processor 1112A and the first computer module 211A becomes impossible (yes in S03), and communication between the second processor 1112B and the second computer module 211B becomes impossible (yes in S051B), the second processor 1112B causes the driving control device 130 to perform driving control according to the request value last received from the first computer module 211A by the first processor 1112A (see S043A, S055B) until the retreat driving control begins (S22).

[0064] Based on the above configuration, regardless of whether communication between the second processor 1112B and the second computer module 211B is possible, at the point in time when communication between the first processor 1112A and the first computer module 211A is not possible, driving control based on the request value received by the second processor 1112B is executed. Furthermore, by simplifying the conditions for switching from control executed by the first processor 1112A to control executed by the second processor 1112B, functional safety can be improved in the event of anomalies related to the first processor 1112A.

[0065] In the vehicle control device 110 of this embodiment, if communication between the second processor 1112B and the second computer module 211B is possible (not in S051B), the second processor 1112B sends the request value received from the second computer module 211B to the first processor 1112A (S053B).

[0066] This allows for partial sharing of the program executed by the first processor 1112A and the program executed by the second processor 1112B (S043A and S053B). Furthermore, it enables more efficient maintenance and management of the vehicle control device 110.

[0067] In the vehicle control device 110 of this embodiment, the requested value includes a requested value for acceleration.

[0068] Therefore, after communication between the first computer module 211A and the second computer module 211B becomes impossible, the acceleration or deceleration of vehicle 1 changes drastically during the period until the start of the reverse driving.

[0069] The vehicle platform 100 of this embodiment includes a base vehicle 120 and a vehicle control device 110. The base vehicle 120 performs autonomous driving according to commands sent from a first computer module 211A or a second computer module 211B of the driving system 210. The vehicle control device 110 is connected between the driving system 210 and the base vehicle 120. The base vehicle 120 includes a driving control device 130, which is different from the vehicle control device 110. The vehicle control device 110 includes a memory 1101 and a processor 1102. The memory 1101 stores a program containing a defined API defined for each signal. The processor 1102 controls the base vehicle 120 according to commands by executing the program. When communication between the processor 1102 and the first computer module 211A and communication between the processor 1102 and the second computer module 211B becomes impossible (in S11, this is true), the processor 1102 sends a signal to the driving control device 130 to start the retreat driving control (S21), and causes the driving control device 130 to perform driving control according to the last received request value until the retreat driving control starts (S22).

[0070] Based on the above configuration, after communication between the first computer module 211A and the second computer module 211B becomes impossible, driving control is performed according to the last received request value during the period until the start of the reverse driving, thus enabling smooth vehicle behavior.

[0071] The embodiments disclosed herein should be considered illustrative at all points and not restrictive. The scope of this disclosure is not shown 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.

Claims

1. A vehicle control device connected between a driving system and a base vehicle, the driving system comprising a first computer module and a second computer module, the base vehicle performing autonomous driving according to commands sent from the first computer module or the second computer module, wherein... The vehicle control device includes: The memory stores programs containing a defined application programming interface (API) for each signal. as well as The processor controls the base vehicle according to the commands by executing the program. The processor sends a signal to initiate reverse driving control to a driving control device different from the vehicle control device, provided that communication between the processor and the first computer module and communication between the processor and the second computer module become impossible. The driving control device then performs driving control according to the last received request value until the reverse driving control begins.

2. The vehicle control device according to claim 1, wherein, The processor includes a first processor and a second processor. The first processor is configured to receive the commands from the first computer module. The second processor is configured to receive the commands from the second computer module. When communication between the first processor and the first computer module is possible, the first processor executes driving control according to the commands received from the first computer module, and sends the request values ​​received from the first computer module to the second processor. When communication between the first processor and the first computer module becomes impossible, but communication between the second processor and the second computer module becomes possible, the second processor executes driving control according to the commands received from the second computer module. When communication between the second processor and the second computer module becomes impossible while the second processor is performing driving control, the second processor causes the driving control device to perform driving control according to the request value last received from the second computer module until the retreat driving control begins. At a point in time when communication between the first processor and the first computer module becomes impossible, and communication between the second processor and the second computer module also becomes impossible, the second processor causes the driving control device to perform driving control according to the request value last received from the first processor from the first computer module, until the retreat driving control begins.

3. The vehicle control device according to claim 2, wherein, When communication between the second processor and the second computer module is possible, the second processor sends the request value received from the second computer module to the first processor.

4. The vehicle control device according to any one of claims 1 to 3, wherein, The requested values ​​include the requested values ​​for acceleration.

5. A vehicle platform, comprising: The base vehicle performs autonomous driving according to commands sent from a first computer module of the driving system or a second computer module of the driving system; and A vehicle control device is connected between the driving system and the base vehicle. The base vehicle includes a driving control device that is different from the vehicle control device. The vehicle control device includes: The memory stores programs containing a defined application programming interface (API) for each signal. as well as The processor controls the base vehicle according to the commands by executing the program. The processor sends a signal to the driving control device to initiate retreat driving control on the condition that communication between the processor and the first computer module and communication between the processor and the second computer module become impossible, and causes the driving control device to execute driving control according to the last received request value until the retreat driving control begins.

Images