Vehicle control device and vehicle platform

Abstract

To smooth the behavior of a vehicle until the start of evacuation travel.SOLUTION: The car control device 110 is connected between a driving system 210 including a first computer module 211A and a second computer module 211B and a base car 120 that performs automatic driving according to a command transmitted 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. On condition that both the communication with the first computer module 211A and the communication with the second computer module 211B are disabled, the processor 1102 transmits a signal for starting the retracting traveling control to the traveling control device 130 different from the vehicular control device 110, and causes the traveling control device 130 to execute the traveling control according to the last received request value until the retracting traveling control is started (S21).SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a vehicle control device and a vehicle platform. [Background technology]

[0002] Patent Document 1 (JP 2018-132015 A) discloses a conventional vehicle. The vehicle is equipped with a power system, a power supply system, and an autonomous driving system. The power system is a part that comprehensively manages the power of the vehicle. The autonomous driving system is a part that comprehensively executes autonomous driving control of the vehicle. [Prior art documents] [Patent documents]

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

[0004] It is conceivable to attach an autonomous driving system (autonomous driving kit) externally to the vehicle body (vehicle platform). In this case, the autonomous driving kit is connected to the vehicle platform via communication, and autonomous driving is achieved by controlling the vehicle body according to commands from the autonomous driving kit. For redundancy, this communication can be performed by both a first computer module and a second computer module in the autonomous driving kit. For example, if communication with the first computer module becomes unavailable during autonomous driving based on commands from the first computer module, autonomous driving continues based on commands from the second computer module. If communication with both the first and second computer modules becomes unavailable, an evacuation control is executed on the vehicle platform to stop the vehicle.

[0005] However, there is a risk that the vehicle's behavior will become unnatural from the time when both communications become unavailable until the evacuation driving control is executed.

[0006] The present disclosure has been made in consideration of the above-mentioned problems, and its purpose is to smooth the behavior of the vehicle until the start of evacuation running. [Means for solving the problem]

[0007] A vehicle control device according to one aspect of the present disclosure is connected between a driving system including a first computer module and a second computer module and a base vehicle that performs automatic driving in accordance with commands transmitted 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 including a predetermined API defined for each signal. The processor controls the base vehicle in accordance with the commands by executing the program. If communication with both the first computer module and the second computer module becomes unavailable, the processor transmits a signal to a driving control device different from the vehicle control device to initiate evacuation driving control, and causes the driving control device to perform driving control in accordance with the last received request value until evacuation driving control is initiated.

[0008] A vehicle platform according to an aspect of the present disclosure includes a base vehicle and a vehicle control device. The base vehicle performs autonomous driving in accordance with commands transmitted from a first computer module of a driving system or a second computer module of the driving system. The vehicle control device is connected between the driving system and the base vehicle. The base vehicle includes a cruise control device different from the vehicle control device. The vehicle control device includes a memory and a processor. The memory stores a program including a predetermined API defined for each signal. The processor controls the base vehicle in accordance with the commands by executing the program. The processor, on a condition that communication with both the first computer module and the second computer module has become unavailable, transmits a signal to the cruise control device to initiate evacuation cruise control, and causes the cruise control device to perform cruise control in accordance with the last received request value until evacuation cruise control is initiated. [Effects of the Invention]

[0009] According to the present disclosure, the behavior of the vehicle can be made smooth until the start of evacuation running. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a diagram showing a schematic configuration of a vehicle 1 according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram showing an internal control system of the vehicle 1. [Figure 3] 2 is a diagram showing a partial detailed view of the control system inside the vehicle 1. FIG. [Figure 4] 10 is a flowchart showing the flow of limp-aside related processing executed by the VCIB 110. [Figure 5] 5 is a flowchart showing in detail the processing of a first processor 1112A in step 04 of FIG. 4, etc. DETAILED DESCRIPTION OF THE INVENTION

[0011] 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.

[0012] FIG. 1 is a diagram illustrating a schematic configuration of a vehicle 1 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 module 200. The autonomous driving module 200 functions as both an autonomous driving kit (ADK) for autonomous driving (i.e., autonomous driving by the vehicle alone) and a remote driving kit (RDK) for remote driving (i.e., autonomous driving based on signals from outside the vehicle). Autonomous driving allows the vehicle 1 to travel independently. Autonomous driving allows the vehicle 1 to travel without receiving instructions from outside the vehicle 1 or from a person (driver) inside the vehicle. Autonomous driving may be what is generally referred to as "fully autonomous driving." Remote driving allows the vehicle 1 to travel without receiving instructions from a person (driver) inside the vehicle. During remote driving, the vehicle 1 may travel based on instructions from a device outside the vehicle, or may travel based on remote control by a person outside the vehicle. The driving plan for remote driving may be generated by the vehicle 1 based on a signal from outside the vehicle, or may be generated outside the vehicle 1 (for example, on the cloud CL). In this embodiment, in both autonomous driving and remote driving, the vehicle 1 generates a driving plan for automatic driving.

[0013] The control system for the vehicle 1 according to 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 that displays the environment of the vehicle 1 (e.g., the surrounding scenery and the road on which the vehicle is traveling), and an input device 530 that accepts remote operations (e.g., driving operations for traveling and body system operations). The remote cockpit 500 may have a driver's seat similar to that of a general vehicle. A user can monitor and operate the vehicle 1 from a remote location by using the remote cockpit 500. The control device 510 of the remote cockpit 500 communicates with the vehicle 1 through a communication system (including a cloud CL). The cloud CL has computer functions and communicates with both the remote cockpit 500 and the vehicle 1. The cloud CL transmits signals based on remote operations performed on the input device 530 to the vehicle 1. The cloud CL also transmits signals based on information from the vehicle 1 to the remote cockpit 500. In this embodiment, a user (person) operates the vehicle 1 through the input device 530. However, this is not limited to this, and the vehicle 1 may be remotely controlled from outside the vehicle by an AI (artificial intelligence) instead of a person. The cloud CL may store the latest map information and traffic information. Edge computing technology may be used to reduce the amount of data processed by the cloud CL or to shorten delay times in remote driving.

[0014] The VP100 includes a vehicle control device 110 and a base vehicle 120. In this embodiment, the vehicle control device 110 is a vehicle control interface box. The vehicle control device 110 may be referred to as "VCIB110" below. By adding the VCIB110 to the base vehicle 120, the VP100 is formed to which the autonomous driving module 200 can be attached and detached. The vehicle 1 is then completed by attaching the autonomous driving module 200 to the VP100. The 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 attached to the rooftop of the base vehicle 120. However, the attachment position of the autonomous driving module 200 can be changed as appropriate.

[0015] 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 base vehicle 120 is not limited to this, and may be an xEV other than a BEV. The base vehicle 120 includes a cruise control device 130, various systems and sensors (wheel speed sensors 127A, 127B, steering angle sensor 127C, etc.) for controlling the base vehicle 120, and an HMI (Human Machine Interface) 128. The cruise control device 130 is specifically an integrated control manager (hereinafter referred to as an "ICM (Integrated Control Manager)"). The cruise control device 130 may be referred to as the "ICM 130" hereinafter. The ICM 130 functions as a control device different from the VCIB 110. The ICM 130 integrates and controls various systems related to the operation of the base vehicle 120 based on the detection results of on-board sensors. The HMI 128 includes an input device and an alarm device. The HMI 128 may also include a navigation system.

[0016] FIG. 2 is a diagram showing a control system inside the vehicle 1. FIG. 3 is a diagram showing a part of the control system inside the vehicle 1 in detail. With reference to FIGS. 1 to 3, the autonomous driving module 200 includes a driving system (hereinafter referred to as "DS") 210 for autonomous driving of the vehicle 1. The VCIB 110 is connected between the DS 210 and the base vehicle 120. The DS 210 includes a computer assembly (hereinafter referred to as "DSCOM") 211, a recognition sensor 212, an attitude sensor 213, a sensor cleaner 216, and an HMI (Human Machine Interface) 218.

[0017] The DSCOM 211 includes a first computer module (hereinafter, sometimes referred to as the "first CM") 211A and a second computer module (hereinafter, sometimes referred to as the "second CM") 211B. Each of the first CM 211A and the second CM 211B includes a processor and a storage device that stores autonomous driving software using the API described below, and is configured to enable the processor to execute the autonomous driving software. The DSCOM 211 switches between autonomous driving and remote driving depending on the value of the driving ID described below. Specifically, the DSCOM 211 outputs commands related to autonomous driving if the driving ID value is "ADK," and outputs commands related to remote driving if the driving ID value is "RDK." Commands from the DSCOM 211 are sent to the VP 100 via the VCIB 110. The base vehicle 120 performs autonomous driving according to commands transmitted from the first CM 211A or the second CM 211B via the VCIB 110.

[0018] The recognition sensor 212 includes a sensor that acquires information (environmental information) indicating the external environment of the vehicle 1. 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 (attitude information) regarding the attitude of the vehicle 1. 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.

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

[0020] In the vehicle 1, the control systems related to the behavior (running, stopping, turning) of the vehicle 1 have redundancy. A first CM 211A and a second CM 211B give instructions to the main control system and the sub-control system, respectively. Corresponding to these, the VCIB 110 includes a control unit 111A of the main control system (hereinafter referred to as the "first VCIB") and a control unit 111B of the sub-control system (hereinafter referred to as the "second VCIB").

[0021] 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 unit includes a battery, a traction motor that receives power from the battery, and an operation unit that accepts accelerator operation from the driver, and applies propulsion force in the direction of travel indicated by the shift range. The P-Lock device includes, in addition to the parking lock mechanism and actuator, an operation unit that accepts parking operation from the driver.

[0022] The active safety system 125 includes a PCS (Pre-Collision Safety) system. The PCS system prevents a collision when it determines that there is a collision risk for the vehicle 1. The ECU of the active safety system 125 determines the possibility of a collision for the vehicle 1 while it is moving. The base vehicle 120 is equipped with a camera 129A and radar sensors 129B, 129C (FIG. 1) for detecting a collision risk. The ECU of the active safety system 125 determines whether there is a collision risk using signals received from the camera 129A and the radar sensors 129B, 129C. If it determines that there is a collision risk, the ECU activates the PCS.

[0023] In this embodiment, signals (API signals) defined by an API (Application Program Interface) are used for communication between the DS210 and the VCIB 110. The DS210 is configured to process various signals defined by the API. The DS210 outputs various commands to the VCIB 110 in accordance with the API. Hereinafter, each of the various commands output from the DS210 to the VCIB 110 will also be referred to as an "API command." Furthermore, the DS210 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 DS210 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.

[0024] In this embodiment, the DS210 uses the API commands described below. The vehicle mode command is an API command that requests a transition to automatic mode or manual mode. The automatic mode and manual mode will be 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 will be described later. Note that the requested values, which will be described later, include the requested acceleration and / or deceleration values. The immobilization command is an API command that requests application or release of immobilization. Application of immobilization means turning the EPB to the ON state (activated state) and setting the shift range to P (parking).

[0025] Some of the API commands used in the vehicle 1 have been described above. The VCIB 110 receives various API commands from the DS 210. When the VCIB 110 receives an API command from the DS 210, 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 DS 210, it outputs an internal command corresponding to the API command to the base vehicle 120.

[0026] The VCIB 110 includes a memory 1101 and a processor 1102. A program including a predetermined API defined for each signal is stored in the memory 1101. The processor 1102 executes the program to control the base vehicle 120 in accordance with instructions from the DS 210 (i.e., various API commands).

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

[0028] The first VCIB 111A (first processor 1112A) is configured to be able to receive commands (i.e., various API commands) from the first CM 211A. The first memory 1111A stores a program including a predetermined API defined for each signal. The first processor 1112A is configured to be able to control the base vehicle 120 in accordance with commands from the first CM 211A by executing the program.

[0029] The second VCIB 111B (second processor 1112B) is configured to be able to receive commands (i.e., various API commands) from the second CM 211B. The second memory 1111B stores a program including a predetermined API defined for each signal. The second processor 1112B is configured to be able to control the base vehicle 120 in accordance with commands from the second CM 211B by executing the program.

[0030] The first VCIB 111A (first processor 1112A) and the second VCIB 111B (second processor 1112B) may communicate directly with each system of the base vehicle 120 or may communicate via the ICM 130 shown in Figures 1 and 3.

[0031] Next, the API status will be described. The DS 210 grasps the status of the base vehicle 120 using, for example, the API status described below.

[0032] The vehicle mode status is an API status that indicates the vehicle mode state. The vehicle mode includes manual mode and automatic mode. Manual mode is a vehicle mode in which the vehicle is under the control of the driver (human). Automatic mode is a vehicle mode in which the vehicle platform (including the base vehicle) is under the control of the autonomous driving kit. In the initial state, the vehicle mode is manual mode. The driver can select the desired vehicle mode through the in-vehicle HMI.

[0033] The driving direction status is an API status that indicates the current shift range. The traveling direction status is an API status that indicates the traveling direction of the vehicle. The vehicle speed status is an API status that indicates the longitudinal speed of the vehicle and outputs the absolute value of the vehicle speed. The immobilization status is an API status that indicates the immobilization state (e.g., the state of EPB and shift P).

[0034] The driving identification status (hereinafter referred to as "driving ID") is an API status that indicates whether the communication between the DS210 (DSCOM211) and the VCIB110 (first VCIB111A and second VCIB111B) is for autonomous driving or remote driving. The driving ID outputs the value "ADK" during autonomous driving and the value "RDK" during remote driving. This driving ID makes it easier to achieve both autonomous driving and remote driving.

[0035] 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 DS210. 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 DS210.

[0036] As described above, the vehicle 1 according to this embodiment is provided with the VCIB 110, which receives control information from the DS 210. In addition to the VCIB 110, the ICM 130 is provided, which receives commands from the VCIB 110 and controls the vehicle's running. When the vehicle 1 is to run in an evacuation mode, it is possible that the ICM 130 controls the evacuation running. In this embodiment, as will be described below, the vehicle 1 is configured so that the vehicle's behavior is smooth when control is switched from control in response to a control request from the VCIB 110 to control of the evacuation running by the ICM 130.

[0037] Fig. 4 is a flowchart showing the flow of the limp-aside related processing executed by the VCIB 110. As shown in Fig. 4, the program for this processing is stored in the memory 1101, and is called from a higher-level processing at predetermined intervals and executed by the processor 1102 of the vehicle control device 110. Specifically, the program for this processing is executed by the first processor 1112A and the second processor 1112B working together.

[0038] The first processor 1112A determines whether or not the vehicle is in an automatic driving mode using the RDK (step (hereinafter, sometimes abbreviated as "S") 01). If it is determined that the vehicle is not in an automatic driving mode using the RDK (NO in S01), the first processor 1112A returns the processing to be executed to the upper processing.

[0039] On the other hand, if it is determined that the vehicle 1 is in an automatic driving mode using the RDK (YES in S01), the first processor 1112A determines whether the vehicle 1 is in a limp-aside control state (S02). The limp-aside control is a control for automatically stopping the vehicle 1 by appropriately evacuating the vehicle 1 when control of the RDK (DS210) fails. If it is determined that the vehicle 1 is not in a limp-aside control state (NO in S02), the first processor 1112A determines whether communication between the first CM211A and the first processor 1112A has been interrupted (S03). If it is determined that 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 in accordance with a command from the first CM211A (S04), and returns the processing to be executed to the upper-level processing.

[0040] FIG. 5 is a flowchart showing in detail the processing of the first processor 1112A in step S04 of FIG. 4. As shown in FIG. 5, in step S04 in this embodiment, the first processor 1112A first transmits a command to the ICM 130 to accept a request from the first processor 1112A and not to accept a request from the second processor 1112B (S041A). Then, the first processor 1112A transmits 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. In this manner, S04 is executed. In addition to the above processing, in S04, the first processor 1112A also transmits the first request value received from the first CM 211A to the second processor 1112B of the second VCIB 111B (S043A).

[0041] As such, in steps S01 to S04, the second processor 1112B is not involved in the driving control of the vehicle 1. However, as shown in Fig. 5, the second processor 1112B of the second VCIB 111B performs the processing described below during steps S01 to S04.

[0042] The second processor 1112B receives from the first processor 1112A the first request value (see S043A) that the first processor 1112A received from the first CM 211A (S051B). Furthermore, the second processor 1112B determines whether or not communication between the second CM 211B and the second processor 1112B has been interrupted (S051B). If it is determined that communication between the second CM 211B and the second processor 1112B has not been interrupted (NO in S051B), the second processor 1112B transmits the second request value received from the second CM 211B to the CIM 130 (S052B). Specifically, the second request value is an acceleration request value. Furthermore, the second processor 1112B also transmits the second request value received from the second CM 211B to the first processor 1112A of the first VCIB 111A (S053B). Thereafter, the second processor 1112B returns the processing to be executed to the upper process.

[0043] Furthermore, if it is determined that communication between the second CM 211B and the second processor 1112B has been interrupted (YES in S52B), the second processor 1112B transmits information indicating that communication with the second CM 211B has been interrupted to the first processor 1112A of the first VCIB 111A (S054B). Then, the second processor 1112B transmits the first request value received from the first processor 1112A, rather than the second request value, to the ICM 130 (S055B). Thereafter, the second processor 1112B returns the processing to be executed to the upper process.

[0044] Here, the limp-aside related processing will be explained again. As shown in Fig. 4, when it is determined that communication between the first CM 211A and the first processor 1112A has been interrupted (YES in S03), the first processor 1112A determines whether communication between the second CM 211B and the second processor 1112B has been interrupted (S11). This determination is made based on whether communication interruption information (see S054B in Fig. 5) has been received from the second processor 1112B. When it is determined that communication between the second CM 211B and the second processor 1112B has not been interrupted (NO in S11), the second processor 1112B controls the traveling of the vehicle 1 in accordance with a command from the second CM 211B (S12), and the first processor 1112A returns the processing to be executed to the upper processing. In S12, specifically, the first processor 1112A accepts a request from the second processor 1112B and transmits a command to the ICM 130 not to accept a request from the first processor 1112A. Then, since the second processor 1112B transmits the second request value received from the second CM 211B to the ICM 130 (see S052B in FIG. 5), the second processor 1112B essentially performs driving control of the vehicle 1 in accordance with the command from the second CM 211B.

[0045] When the first processor 1112A determines that communication between the first CM 211A and the first processor 1112A has been interrupted (YES in S03) and that communication between the second CM 211B and the second processor 1112B has been interrupted (YES in S11), the first processor 1112A requests the ICM 130 to perform limp-aside control (S21). The first processor 1112A then causes the ICM 130 to perform cruise control in accordance with the request value last received by the VCIB 110 from the DS210 (S22), and returns the processing to be executed to the upper process. As a result, the first processor 1112A causes the ICM 130 to perform cruise control in accordance with the request value last received by the VCIB 110 from the DS210 until evacuation cruise control (limp-aside control) is initiated. More specifically, the first processor 1112A commands the ICM 130 to execute cruise control in accordance with the request value last received by the ICM 130 from the second processor 1112B until the evacuation cruise control is initiated. Even more specifically, the request value includes a request value for acceleration, and the cruise control includes control of the brake control units 121A and 121B of the brake system 121 and the propulsion control unit 123C of the powertrain system 123.

[0046] Here, the request value that the ICM 130 last received from the second processor 1112B will be described. If communication between the second CM 211B and the second processor 1112B is interrupted (YES in S11) while the second processor 1112B is controlling the traveling of the vehicle 1 in accordance with a command from the second CM 211B (S12), the request value that the ICM 130 last received from the second processor 1112B will be the second request value that the second processor 1112B received from the second CM 211B (S053B in FIG. 5). As a result, the request value that the ICM 130 follows to control the vehicle 1 will be the same immediately before and after the communication interruption with the second CM 211B, and therefore the behavior of the vehicle 1 from the time of communication interruption to the start of evacuation traveling can be smoothed.

[0047] On the other hand, if communication between the second CM 211B and the second processor 1112B has already been interrupted (YES in S051B of FIG. 5) while the first processor 1112A is controlling the traveling of the vehicle 1 in accordance with a command from the first CM 211A (S04), and communication between the first CM 211A and the first processor 1112A is interrupted under this circumstance (YES in S03 and YES in S11), the request value that the ICM 130 last received from the second processor 1112B will be the first request value that the first processor 1112A received from the first CM 211A (S043A and S055B of FIG. 5). As a result, the request value that the ICM 130 follows to control the vehicle 1 will be the same immediately before and after the interruption of communication with the first CM 211A, and therefore the behavior of the vehicle 1 from the time of communication interruption to the start of evacuation traveling can be smoothed. Furthermore, even if communication with the second CM 211B is interrupted before communication with the first CM 211A is interrupted, the interruption of communication with the first CM 211A can be used as a trigger to switch control from that by the first processor 1112A to that by the second processor 1112B. By simplifying the conditions for switching control in this way, functional safety can be improved when an abnormality occurs in the first processor 1112A.

[0048] If the first processor 1112A determines that the vehicle 1 is in the limp-aside control state (YES in S02), the processor 1102 does not control the vehicle 1 (S31). At this time, the ICM 130 is executing evacuation travel control (limp-aside control) regardless of the last request value received from the second processor 1112B, so the processor 1102 does not interfere with this control.

[0049] Next, the first processor 1112A determines whether the ICM 130 is performing a deceleration process (S32). If it is determined that the ICM 130 is not performing a deceleration process (NO in S32), the first processor 1112A determines whether the ICM 130 is performing a vehicle stop maintenance process (S33). If it is determined that the ICM 130 is performing a deceleration process (YES in S32) or is maintaining a vehicle stop (YES in S33), the first processor 1112A switches the vehicle mode from the automatic driving mode to the manual driving mode (S41). If it is determined that the ICM 130 is not performing a deceleration process (NO in S32) and is not maintaining a vehicle stop (NO in S33), the first processor 1112A returns the processing to be executed to the upper process.

[0050] In this embodiment, when the RDK is in automatic mode, the processing from S02 onwards in Fig. 4 is executed. However, this is not limiting, and the processing from S02 onwards may also be executed when the ADK is in automatic mode.

[0051] In addition, in this embodiment, the ICM 130 executes the RDK limp-aside control. However, this is not limiting, and the above disclosure can be applied even when the RDK limp-aside control is executed by a control device other than the ICM 130, as long as the RDK limp-aside control is executed by a control device other than the VCIB 110.

[0052] As described above, the vehicle control device 110 according to this embodiment is connected between the driving system 210 including the first computer module 211A and the second computer module 211B and the base vehicle 120, which performs autonomous driving in accordance with commands transmitted 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 including a predetermined API defined for each signal. The processor 1102 executes the program to control the base vehicle 120 in accordance with the commands. If communication with both the first computer module 211A and the second computer module 211B becomes unavailable (YES in S03, YES in S11), the processor 1102 transmits a signal to initiate evacuation travel control to a travel control device 130 different from the vehicle control device 110 (S21), and causes the travel control device 130 to perform travel control in accordance with the last received request value until evacuation travel control is initiated (S22).

[0053] According to the above configuration, after communication between both the first computer module 211A and the second computer module 211B becomes unavailable, driving control is performed according to the last received request value until evacuation driving begins, thereby making the behavior of the vehicle 1 smooth.

[0054] In the vehicle control device 110 according to this embodiment, the processor 1102 includes a first processor 1112A and a second processor 1112B. The first processor 1112A is configured to be able to receive commands from the first computer module 211A. The second processor 1112B is configured to be able to receive commands from the second computer module 211B. When communication between the first processor 1112A and the first computer module 211A is possible (NO in S03), the first processor 1112A executes driving control in accordance with the command received from the first computer module 211A (S041A, S042A), and transmits the required value received from the first computer module 211A to the second processor 1112B (S043A). If communication between the first processor 1112A and the first computer module 211A becomes unavailable (YES in S03), but communication between the second processor 1112B and the second computer module 211B is available (NO in S11), the second processor 1112B executes driving control in accordance with the command received from the second computer module 211B (S12). If communication between the second processor 1112B and the second computer module 211B becomes unavailable (YES in S11) while the second processor 1112B is executing driving control (S12), the second processor 1112B causes the driving control device 130 to execute driving control in accordance with the request value last received from the second computer module 211B (see S053B) until evacuation driving control is started (S22). If communication between the first processor 1112A and the first computer module 211A becomes impossible (YES in S03), and if 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 in accordance with the request value last received from the first computer module 211A (see S043A, S055B) from the first processor 1112A until evacuation driving control is initiated (S22).

[0055] According to the above configuration, regardless of whether communication between the second processor 1112B and the second computer module 211B is possible, when communication between the first processor 1112A and the first computer module 211A becomes impossible, driving control is executed based on the request value received by the second processor 1112B. Furthermore, by simplifying the conditions for switching from control by the first processor 1112A to control by the second processor 1112B, it is possible to improve functional safety when an abnormality occurs in the first processor 1112A.

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

[0057] This allows the programs executed by the first processor 1112A and the second processor 1112B to partially share the same programs (S043A and S053B), thereby improving the efficiency of maintenance and management of the vehicle control device 110.

[0058] In the vehicle control device 110 according to this embodiment, the required value includes a required value of acceleration.

[0059] This makes it possible to prevent a sudden change in acceleration or deceleration of the vehicle 1 from occurring after both the first computer module 211A and the second computer module 211B have become unable to communicate and until evacuation travel begins.

[0060] The vehicle platform 100 according to this embodiment includes a base vehicle 120 and a vehicle control device 110. The base vehicle 120 performs autonomous driving in accordance with commands transmitted from a first computer module 211A of the driving system 210 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 cruise control device 130 that 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 including a predetermined API defined for each signal. The processor 1102 executes the program to control the base vehicle 120 in accordance with the commands. On the condition that communication with both the first computer module 211A and the second computer module 211B has become impossible (YES in S11), the processor 1102 sends a signal to the driving control device 130 to start evacuation driving control (S21), and causes the driving control device 130 to execute driving control in accordance with the last received request value until evacuation driving control is started (S22).

[0061] According to the above configuration, after communication between both the first computer module 211A and the second computer module 211B becomes unavailable, driving control is performed according to the last received request value until evacuation driving begins, thereby making the vehicle's behavior smoother.

[0062] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The 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]

[0063] 1 Vehicle, 100 VP, 110 VCIB, 111A 1st VCIB, 111B 2nd VCIB, 120 Base vehicle, 121 Brake 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 sensor, 127C Steering angle sensor, 128, 218 HMI, 129A Camera, 129B, 129C Radar sensor, 130 ICM, 200 Autonomous driving module, 210 DS, 211 DSCOM, 211A 1st CM, 211B 2nd 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.

Claims

1. A vehicle control device connected between a driving system including a first computer module and a second computer module and a base vehicle that performs automatic driving in accordance with a command transmitted from the first computer module or the second computer module, a memory storing a program including a predetermined API defined for each signal; a processor that executes the program to control the base vehicle in accordance with the instructions; The vehicle control device, wherein the processor, on the condition that communication with both the first computer module and the second computer module has become impossible, sends a signal to start evacuation driving control to a driving control device different from the vehicle control device, and causes the driving control device to perform driving control in accordance with the last received request value until the evacuation driving control is started.

2. the processors include a first processor and a second processor; the first processor is configured to receive the command from the first computer module; the second processor is configured to receive the command from the second computer module; When communication between the first processor and the first computer module is possible, the first processor executes driving control in accordance with the command received from the first computer module, and transmits the required value received from the first computer module to the second processor; When communication between the first processor and the first computer module becomes unavailable, if communication between the second processor and the second computer module is available, the second processor executes driving control in accordance with the command received from the second computer module; When the second processor is executing the driving control and communication between the second processor and the second computer module becomes impossible, the second processor causes the driving control device to execute the driving control in accordance with the request value last received from the second computer module until the evacuation driving control is started; 2. The vehicle control device according to claim 1, wherein, if communication between the second processor and the second computer module is not possible at the time when communication between the first processor and the first computer module is not possible, the second processor causes the driving control device to perform driving control in accordance with the request value last received from the first computer module from the first processor until the evacuation driving control is initiated.

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 transmits the request value received from the second computer module to the first processor.

4. The vehicle control device according to claim 1 , wherein the required value includes a required value of acceleration.

5. a base vehicle that performs automatic driving in accordance with a command transmitted from a first computer module of a driving system or a second computer module of the driving system; a vehicle control device connected between the driving system and the base vehicle; the base vehicle includes a driving control device different from the vehicle control device, The vehicle control device includes: a memory storing a program including a predetermined API defined for each signal; a processor that executes the program to control the base vehicle in accordance with the instructions; The processor, on the condition that both communication with the first computer module and communication with the second computer module become unavailable, sends a signal to the driving control device to initiate evacuation driving control, and causes the driving control device to perform driving control according to the last received request value until the evacuation driving control is initiated.

Images