vehicle

Abstract

To perform appropriate control after restart of an interface between an automatic driving system and a vehicle.SOLUTION: The control microcomputer in the 1VCIB performs a step (S22) of returning when the internal IGR is in the OFF state (YES in the S21), a step (S23) of acquiring the operation mode of the 2VCIB, a step (S24) of executing the CAN cut process when the history is in the ON state (YES in the S24) or when the history is in the OFF state (NO in the 2VCIB) and the operation mode of the S26 is the automatic mode (YES in the), and a step () of executing the CAN cut process when the operation mode of the is the manual mode (NO in the), S25 2VCIB S26, continuing the CAN communication (S27).SELECTED DRAWING: Figure 3

Description

[Technical Field]

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

[0002] In recent years, autonomous driving systems that allow vehicles to travel without receiving user operations have been developed. For example, autonomous driving systems may be provided separately from the vehicle via an interface so that they can be installed in existing vehicles.

[0003] For example, Japanese Patent Application Laid-Open Publication No. 2018-132015 (Patent Document 1) discloses a technology in which automatic driving control of a vehicle is comprehensively executed by a computer constituting an automatic driving system provided in the vehicle. [Prior art documents] [Patent documents]

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

[0005] In cases where an autonomous driving system is provided separately from a vehicle via an interface, a computer constituting the interface may be restarted due to an operational malfunction during autonomous driving or the like. In this case, it is conceivable to set the autonomous driving mode as the initial value of the driving mode after the restart in order to continue autonomous driving even after the computer is restarted. However, the computer constituting the interface may be restarted not only due to an operational malfunction but also due to, for example, a software update. In such cases, if the autonomous driving mode is set after the restart, control similar to that in the case where an operational malfunction has occurred may be performed, and appropriate control may not be possible.

[0006] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide a vehicle that can be appropriately controlled after restarting the interface between the autonomous driving system and the vehicle. [Means for solving the problem]

[0007] A vehicle according to an aspect of the present disclosure includes an autonomous driving system that performs autonomous driving of the vehicle and a vehicle platform capable of receiving commands related to autonomous driving from the autonomous driving system. The vehicle platform executes vehicle control in one of an autonomous mode using the autonomous driving system and a manual mode. The vehicle platform includes a base vehicle and a vehicle control interface that interfaces between the vehicle platform and the autonomous driving system. The vehicle control interface includes a first control device capable of controlling the base vehicle according to the operational mode, and a second control device capable of communicating with the first control device and controlling the base vehicle according to the operational mode. The first control device sets the automatic mode if the operational mode acquired from the second control device after restarting the first control device is the automatic mode, and sets the manual mode if the operational mode acquired from the second control device after restarting is the manual mode.

[0008] In this way, after restart, the operation mode acquired from the second control device is set, and it is possible to quickly return to the operation mode before restart. Therefore, even if restart occurs due to an operation malfunction during automatic driving, it is possible to continue the automatic mode after restart. Therefore, it is possible to perform control corresponding to the operation malfunction during automatic driving after restart. Furthermore, for example, if restart occurs due to a software update while in manual mode, manual mode is set after restart, and therefore control corresponding to the operation malfunction during automatic driving is suppressed. Therefore, it is possible to perform appropriate control after restart of the first control device.

[0009] In one embodiment, the first control unit cuts off communication with the second control unit and the base vehicle if automatic mode is set after reboot.

[0010] In this way, if automatic mode is set after restart, there is a possibility that an unintended restart has occurred, so by cutting off communication with the second control device and the base vehicle, it is possible to prevent the second control device and the base vehicle from being affected by the operation of the first control device.

[0011] Additionally, in one embodiment, the first control unit maintains communication with the second control unit and the base vehicle if manual mode is set after reboot.

[0012] In this way, if manual mode is set after a restart, there is a possibility that an intentional restart such as a software update has occurred, and communication with the second control device and base vehicle is maintained, thereby preventing any impact on the operation of the first control device.

[0013] In yet another embodiment, the first control device stores historical information when the vehicle's start switch indicates an activated state and the operating mode is automatic mode, and if the historical information is stored after restart, it cuts off communication with the second control device and the base vehicle.

[0014] In this way, it is possible to prevent the second control device and the base vehicle from being affected by the operation of the first control device. [Effects of the Invention]

[0015] According to the present disclosure, it is possible to provide a vehicle that can be appropriately controlled after restarting the interface between the autonomous driving system and the vehicle. [Brief explanation of the drawings]

[0016] [Figure 1] 1 is a diagram illustrating an example of a schematic configuration of a vehicle according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram for explaining the configuration and functions of a VCIB. [Figure 3] 10 is a flowchart illustrating an example of processing executed by a control microcomputer. [Figure 4] 4 is a time chart illustrating an example of an operation of a vehicle according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

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

[0018] FIG. 1 is a diagram illustrating an example of a schematic configuration of a vehicle according to an embodiment of the present disclosure. Referring to FIG. 1, vehicle 1 includes a vehicle platform (VP) 100 and a detachable autonomous driving kit (ADK) 200. VP 100 includes a vehicle control interface box (VCIB) 110 and a base vehicle 120. Vehicle 1 capable of autonomous driving is configured by attaching ADK 200 to a predetermined position (for example, a rooftop) of VP 100. Base vehicle 120 is an electrically powered vehicle such as an electric vehicle or a hybrid vehicle.

[0019] The ADK 200 includes an automatic driving system (hereinafter referred to as "ADS") 210 for performing automatic driving of the vehicle 1. The ADS 210 includes a computer assembly (hereinafter referred to as "CA") 211, a recognition sensor 212, an attitude sensor 213, a sensor cleaner 216, and an HMI (Human Machine Interface) 218.

[0020] The CA 211 includes computer modules (hereinafter referred to as "ADC") 211A and 211B. Each of the ADCs 211A and 211B includes a processor and a storage device that stores autonomous driving software that utilizes the API described below, and is configured so that the processor can execute the autonomous driving software. The recognition sensor 212 acquires environmental information that indicates 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 attitude information related to 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.

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

[0022] The VCIB 110 is configured to communicate with both the base vehicle 120 and the ADK 200 via a communication bus using CAN (Controller Area Network) communication or the like. In the vehicle 1, the control systems related to the behavior (running, stopping, turning) of the vehicle 1 have redundancy. The ADCs 211A and 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 includes a computer equipped with a processor and a storage device.

[0023] The brake system 121 includes a braking device, a brake pedal, and brake control units 121A and 121B. The steering system 122 includes a steering device, a steering wheel, and steering control units 122A and 122B. The powertrain system 123 includes a shift device, a vehicle drive device, an EPB (Electric Parking Brake) device, a parking lock device (P-Lock device), an EPB control unit 123A, a P-Lock control unit 123B, and a propulsion control unit 123C. The shift device determines a shift range and switches the propulsion direction and gear change mode of the vehicle 1 according to the determined shift range. The shift device includes a gear change device and a shift lever. The vehicle drive device applies propulsion force in the propulsion direction indicated by the shift range. The vehicle drive device includes a drive battery, a traction motor powered by the drive battery, and an accelerator pedal. The P-Lock device further includes an actuator that operates a parking lock mechanism and an operation unit that accepts parking operations.

[0024] Fig. 2 is a diagram illustrating the configuration and functions of the VCIB 110. Referring to Fig. 2, the first VCIB 111A includes a control microcomputer (control microcomputer) 11 and an ASIC (Application Specific Integrated Circuit) 12.

[0025] The control microcomputer 11 includes a processor 11a and a storage device 11b. The control microcomputer 11 receives power from a battery 20. The battery 20 includes a drive battery, an auxiliary battery, or the like. A DC / DC converter may be provided between the control microcomputer 11 and the battery 20. The storage device 11b includes a RAM (Random Access Memory). The storage device 11b receives power from a backup power source such as the battery 20.

[0026] The ASIC 12 includes a WDC (watchdog timer circuit). The WDC is configured to detect a periodic clock signal input from the control microcontroller 11 and monitor the normal operation of the control microcontroller 11. If the clock signal is not input to the ASIC 12 within the timer period, the ASIC 12 (WDC) determines that the control microcontroller 11 is operating abnormally and outputs a reset signal to the control microcontroller 11. Upon receiving the reset signal, the control microcontroller 11 enters a power-off state and restarts after being reset (microcontroller reset). The control microcontroller 11 and the ASIC 12 communicate with each other via SPI (Serial Peripheral Interface). SPI communication is a synchronous serial communication that transmits data in synchronization with a clock. The control microcontroller 11 transmits a TTF (time-to-fail) signal to the ASIC 12 via SPI communication. The ASIC 12 transmits counter reset information to the control microcontroller 11 via SPI communication.

[0027] The second VCIB 111B also includes a control microcomputer (control microcomputer) 21 similar to the control microcomputer 11. The control microcomputer 21 includes a processor and a storage device. The control microcomputer 21 also receives power from the battery 20. The control microcomputer 11 and the control microcomputer 21 communicate with each other via CAN. Furthermore, each of the control microcomputers 11 and 21 is configured to be able to communicate with both the base vehicle 120 and the ADK 200 via CAN.

[0028] In this embodiment, signals (API signals) defined by an API (Application Program Interface) are used for communication between the ADK200 and the VCIB110. The ADK200 is configured to process various signals defined by the API. The ADK200 outputs various commands to the VCIB110 in accordance with the API. Hereinafter, each of the various commands output from the ADK200 to the VCIB110 will also be referred to as an "API command." The API command includes instructions related to autonomous driving control. The ADK200 (ADCs 211A, 211B) determines the value of the API command. Furthermore, the ADK200 receives various signals indicating the status of the base vehicle 120 from the VCIB110 in accordance with the API. Hereinafter, each of the various signals received by the ADK200 from the VCIB110 will also be referred to as an "API status." Both the API command and the API status correspond to an API signal.

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

[0030] The vehicle mode command is an API command that requests a transition to automatic mode or manual mode. The ADK200 can select the operating mode (vehicle mode) of the vehicle 1 using the vehicle mode command. 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 described below. 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).

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

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

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

[0034] The propulsion 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 a value of "0" when the vehicle is traveling forward, a value of "1" when the vehicle is traveling backward, and a value of "2 (Standstill)" when all wheels (4 wheels) show a speed of "0" for a predetermined 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.

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

[0036] The vehicle 1 further includes a start switch 30 that accepts user operation to switch the VP 100 control system (including the control microcomputers 11 and 21 and various ECUs of the base vehicle 120) on and off. The user operates the start switch 30 to switch the VP 100 control system on (on) and off (off). When the control system shuts down, the start switch 30 is turned off. In this embodiment, an ignition relay (IGR) (not shown) is switched on (closed) and off (open) depending on the state (on / off) of the start switch 30. The control microcomputer 11 is configured to detect the state of the start switch 30 (IGR state) and its own operating state. Hereinafter, information indicating the operating state of the control microcomputer 11 is referred to as the “internal IGR.” The control microcomputer 11 sequentially acquires the internal IGR. When the control microcomputer 11 is powered on, the internal IGR is on (operating). When the control microcomputer 11 is in the shutdown process or power-off state, the internal IGR indicates off (stopped state). When the start switch 30 is turned on, the control microcomputer 11 starts up and enters the power-on state. When the start switch 30 is turned off, the control microcomputer 11 starts the shutdown process, and when the shutdown process is completed, the control microcomputer 11 enters the power-off state.

[0037] In this embodiment, an interface computer (hereinafter referred to as "IFCOM") included in the VCIB 110 detects an operating mode selected from a selection of multiple operating modes (e.g., manual mode, automatic mode, and standby mode) and outputs it to the base vehicle 120. The control microcomputer 11 selects either the control microcomputer 11 or the control microcomputer 21 as the IFCOM. For example, when the control microcomputer 11 is in a normal state, the control microcomputer 11 is selected as the IFCOM. Also, when there is a possibility that the control microcomputer 11 is damaged, the control microcomputer 21 can operate as the IFCOM. Since both the control microcomputer 11 and the control microcomputer 21 can function as the IFCOM, the robustness of the VCIB 110 is increased.

[0038] The IFCOM converts the API command from the ADK200 into an internal command and outputs the obtained internal command to the base vehicle 120 together with the above-mentioned operating mode. The IFCOM acquires an API status using vehicle information from the base vehicle 120 and outputs the acquired API status to the ADK200. The operating mode is selected, for example, by the user, the base vehicle 120, or the ADK200. A server outside the vehicle may also switch the operating mode of the vehicle 1 as necessary. The control device of the base vehicle 120 controls the vehicle 1 according to the operating mode detected (acquired) by the IFCOM.

[0039] The control microcomputer 11 periodically detects the selected operation mode and the state (on / off) of the start switch 30. Each time the control microcomputer 11 detects an operation mode, it records operation mode information indicating the detected operation mode in the storage device 11b. When the control microcomputer 11 is restarted, the control microcomputer 11 detects the selected operation mode based on the operation mode information recorded immediately before the control microcomputer 11 is stopped. Furthermore, if the detected state of the start switch 30 indicates operation (first requirement) and the detected operation mode is automatic mode (second requirement), the control microcomputer 11 records predetermined information (history information) in the storage device 11b. If at least one of the first requirement and the second requirement is not met, the control microcomputer 11 erases the history information in the storage device 11b. The history information may be recorded by polling. Hereinafter, the state in which the storage device 11b stores history information is referred to as "history ON," and the state in which the storage device 11b does not store history information is referred to as "history OFF." The control microcomputer 11 determines whether the history information is ON upon restart. If it is determined that the history is ON, the ASIC 12 executes the CAN cut process after restarting the control microcomputer 11. During the CAN cut, the CAN output from the control microcomputer 11 is cut off. As a result, communication between the control microcomputer 11 and each of the control microcomputer 21 and the base vehicle 120 is cut off.

[0040] If the control microcomputer 11 restarts while the automatic mode is selected and the start switch 30 is in an activated state (turned on), it is highly likely that the stop of the control microcomputer 11 was unintentional (for example, a stop caused by an internal abnormality or a power supply abnormality in the control microcomputer 11), and the control microcomputer 11 may have been damaged. Therefore, in the above configuration, communication between the control microcomputer 11 and the control microcomputer 21 is stopped to prevent the control microcomputer 21 from being affected by the control microcomputer 11. With this configuration, even if an abnormality occurs in the control microcomputer 11, the control microcomputer 21 is more likely to operate normally.

[0041] While communication between the control microcomputer 11 and the control microcomputer 21 is stopped, the control microcomputer 11 selects the control microcomputer 21 as the IFCOM. On the other hand, if the control microcomputer 11 starts up normally after communication between the control microcomputer 11 and the control microcomputer 21 is stopped, the control microcomputer 11 releases the communication interruption (CAN cut) and selects the control microcomputer 11 as the IFCOM. The IFCOM periodically detects the selected operating mode and outputs the detected operating mode to the control device of the base vehicle 120 each time the operating mode is detected. Like the control microcomputer 11, the control microcomputer 21 may also have a non-volatile storage device. The restarted control microcomputer 21 may detect the selected operating mode based on the operating mode information recorded in the storage device immediately before it was stopped. The base vehicle 120 recognizes the selected operating mode based on the information from the IFCOM (VCIB 110). During the period when the operating mode is not output from the VCIB 110 to the base vehicle 120, the base vehicle 120 may recognize that the selected operating mode is the manual mode, activate the active safety system 125, and execute deceleration control of the vehicle 1 using the active safety system 125. Alternatively, the base vehicle 120 may notify the driver that the vehicle 1 is operating in the manual mode. Hereinafter, information indicating the selected operating mode will be referred to as the "internal VEMDST." The base vehicle 120 successively acquires the internal VEMDST and controls the vehicle 1 according to the latest internal VEMDST.

[0042] In the vehicle 1 described above, the control microcomputer 11 may be restarted during autonomous driving due to a malfunction of the control microcomputer 11 or the like. In this case, the automatic mode may be set as the initial value of the operation mode to be selected after the restart so that the autonomous driving can continue even after the restart of the control microcomputer 11. However, the restart of the control microcomputer 11 may be caused not only by an operational malfunction but also by, for example, a software update. In such a case, if the automatic mode is set after the restart, the same control as when an operational malfunction occurs (i.e., CAN cut) may be performed, and appropriate control may not be possible.

[0043] Therefore, in this embodiment, if the operating mode obtained from the control microcomputer 21 after restarting the control microcomputer 11 is the automatic mode, the control microcomputer 11 sets the automatic mode, and if the operating mode obtained from the control microcomputer 21 after restarting is the manual mode, the control microcomputer 11 sets the manual mode.

[0044] In this way, after the control microcomputer 11 is restarted, the operation mode acquired from the control microcomputer 21 is set, and the operation mode before the restart can be quickly restored. Therefore, even if the control microcomputer 11 is restarted due to an operation malfunction during automatic driving, the automatic mode continues after the restart, and control can be performed to deal with an operation malfunction during automatic driving, such as the suspension of communication with the control microcomputer 21. Furthermore, for example, if the control microcomputer 11 is restarted due to a software update while in manual mode, the manual mode is set after the restart, and communication with the control microcomputer 21 continues.

[0045] 3 is a flowchart showing an example of processing executed by the control microcomputer 11. In the following, each step in the flowchart is abbreviated as "S." When the control microcomputer 11 starts up normally, it selects itself as IFCOM and starts S10 and the subsequent processing flow (hereinafter referred to as "S10 flow").

[0046] In S10, the state of the start switch 30 (state of the IGR) and the current operating mode (selected operating mode) are detected, and the detection result is recorded in the storage device 11b. As a result, operating mode information indicating the detected operating mode is recorded in the storage device 11b. Next, in S11, the control microcomputer 11 determines whether the ignition relay (IGR) is in the ON state. If the IGR is in the ON state (YES in S11), this means that the first requirement is met. In S12, the control microcomputer 11 determines whether the operating mode detected in S10 is the automatic mode. If the detected operating mode is the automatic mode (YES in S12), this means that the second requirement is met. If both the first requirement and the second requirement are met (YES in both S11 and S12), the control microcomputer 11 turns the history ON in S13. Thereafter, the process proceeds to S21. If the first requirement is met but the second requirement is not met (YES in S11 and NO in S12), the control microcomputer 11 turns the history OFF in S14. Then, the process proceeds to S21. If the first requirement is not met (NO in S11), the control microcomputer 11 turns off the history in S15. Then, the process proceeds to S30. The control microcomputer 11 stores information about the on / off state of the history in the RAM. When the RAM is initialized, the information about the on / off state of the history is set to an initial value (a value indicating the history off state in this embodiment).

[0047] In S21, the control microcomputer 11 acquires the current internal IGR and determines whether the acquired internal IGR indicates OFF. If the internal IGR indicates ON (NO in S21), the control microcomputer 11 is likely to be normal, and the process returns to S10. In this case, the control microcomputer 11 operates as an IFCOM while executing the process from S10. On the other hand, if the internal IGR indicates OFF in a state that satisfies the first requirement (YES in S21), the control microcomputer 11 has stopped for some reason. In this case, the control microcomputer 11 recovers (restarts) in the following S22. Furthermore, the recovered control microcomputer 11 acquires the operating mode of the control microcomputer 21 in the following S23. The control microcomputer 11, for example, acquires information about the current operating mode from the control microcomputer 21. In the following S24, the control microcomputer 11 determines whether the history is ON. If it is determined that the history is OFF (NO in S24), the process proceeds to S26. On the other hand, if it is determined that the history is ON (YES in S24), the process proceeds to S25. In S25, the ASIC 12 executes CAN cut processing based on the signal from the control microcomputer 11. This cuts off communication between the control microcomputer 11 and each of the control microcomputer 21 and the base vehicle 120. Thereafter, the process returns to S10.

[0048] In S26, the control microcomputer 11 determines whether the current operating mode of the control microcomputer 21 is the automatic mode. If it is determined that the current operating mode of the control microcomputer 21 is the automatic mode (YES in S26), the process proceeds to S25. On the other hand, if it is determined that the current operating mode of the control microcomputer 21 is the manual mode (NO in S26), the process proceeds to S27. In S27, CAN communication between the control microcomputer 11 and the control microcomputer 21 continues. Thereafter, the process returns to S10.

[0049] When the CAN cut process is executed and the control microcomputer 21 becomes active, it operates the vehicle 1 in automatic mode. In automatic mode, the control microcomputer 21 may execute stop control (safety stop control) of the vehicle 1 in accordance with instructions from the ADK 200. Then, after the vehicle 1 stops, the control microcomputer 21 may execute restart of the control system. Alternatively, the control microcomputer 21 may request the user to operate the start switch 30 to restart the control system. This restarts the control system of the vehicle 1 (including the control microcomputer 11). However, this is not limited to this, and the activated control microcomputer 21 may continue driving the vehicle 1 in automatic mode. The control microcomputer 21 may execute, for example, automatic driving control similar to that of the control microcomputer 11, or automatic driving control that is more limited than that. The limit may be a speed limit.

[0050] Regardless of whether the control microcomputer 11 is in an active or inactive state, if the user turns off the startup switch 30, the determination in S11 is NO, and the control microcomputer 11 executes a shutdown process in S30. When the shutdown process is completed, the control microcomputer 11 enters a power-off state, and the S10 flow ends.

[0051] The operation of the VCIB 110 based on the above-described structure and flowchart will be described with reference to FIG. 4. FIG. 4 is a time chart showing an example of the operation of the vehicle 1 according to an embodiment of the present disclosure. Lines L1 to L9 in FIG. 4 indicate state transitions of the control microcomputer 11. Specifically, line L1 indicates the presence or absence of power supply to the control microcomputer 11, line L2 indicates the state of the IGR, line L3 indicates the state of the internal IGR, line L4 indicates the state of the internal VEMDST, line L5 indicates the history state, line L6 indicates the state of the operating mode (sub-VEMDST) acquired from the control microcomputer 21, line L7 indicates a change in the clock signal for the WDC, line L8 indicates a change in the TTF signal, and line L9 indicates the presence or absence of a CAN cut.

[0052] As shown by line L1 in FIG. 4, when the power supply to the control microcomputer 11 is stopped (power supply failure), the control microcomputer 11 restarts when the power supply is resumed. At this time, as shown by line L2, the IGR remains on, and as the power supply is stopped, the internal IGR changes to the on state as shown by line L3. As shown by line L4, when the control microcomputer 11 restarts while the vehicle 1 is operating in the automatic mode, the history information stored in the backup RAM is initialized as shown by line L5 in FIG. 4, and the state changes to the off state. Therefore, the processing of S26 in FIG. 3 is executed. That is, it is determined whether the current operating mode of the control microcomputer 21 is the automatic mode. Since the current operating mode of the control microcomputer 21 is the automatic mode as shown by line L6 in FIG. 4, the CAN cut processing is executed as shown by L9 in FIG. 4. In this case, the IFCOM is switched from the control microcomputer 11 to the control microcomputer 21. As a result, the vehicle 1 resumes operation in the automatic mode.

[0053] On the other hand, for example, if a software update is performed in the control microcomputer 11 while the vehicle 1 is operating in manual mode, the control microcomputer 11 restarts after the software update process is completed. When the control microcomputer 11 restarts while the vehicle 1 is operating in manual mode, the history information stored in the RAM is initialized, and the history information changes to the OFF state. Therefore, the process of S26 in FIG. 3 is executed. That is, a determination is made as to whether the current operating mode of the control microcomputer 21 is automatic mode, and since the current operating mode of the control microcomputer 21 is manual mode, CAN communication continues. In this case, the control microcomputer 11 is maintained as the IFCOM.

[0054] If the battery 20 is replaced (removed) while the vehicle 1 is operating in the manual mode, the control microcomputer 11 restarts with the history turned off. Therefore, the process of S25 in Fig. 3 is not executed, and CAN communication continues because the operating mode is the manual mode.

[0055] As described above, according to the vehicle 1 of this embodiment, after restart, the operation mode acquired from the control microcomputer 21 is set, and therefore the operation mode before restart can be quickly restored. Therefore, even if the vehicle 1 is restarted due to an operation malfunction during autonomous driving, the automatic mode can be continued after restart. Therefore, control corresponding to an operation malfunction during autonomous driving can be performed after restart. For example, if the automatic mode is set after restart, there is a possibility that an unintended restart has occurred. Therefore, by cutting off communication with the control microcomputer 21 and the base vehicle 120, the control microcomputer 21 and the base vehicle 120 can be prevented from being affected by the operation of the control microcomputer 11. Furthermore, for example, if the vehicle 1 is restarted due to a software update while in manual mode, the manual mode is set after restart, and therefore control corresponding to an operation malfunction during autonomous driving is prevented from being performed. For example, if the manual mode is set after restart, there is a possibility that an intentional restart, such as a software update, has occurred. Therefore, maintaining communication between the control microcomputer 21 and the base vehicle 120 prevents unnecessary cutting off of communication between the control microcomputer 11 and the base vehicle 120, which prevents a communication abnormality from being recorded in the base vehicle 120 and thus prevents the operation of the control microcomputer 11 from being affected. Therefore, it is possible to provide a vehicle that can be appropriately controlled after restarting the interface between the autonomous driving system and the vehicle.

[0056] Furthermore, if historical information is stored after a restart, there is a possibility that an unintended restart has occurred, so by stopping communication with the control microcontroller 21, it is possible to prevent the control microcontroller 21 from being affected by the operation of the control microcontroller 11.

[0057] The vehicle 1 according to this embodiment records the operation mode information in a backup RAM. By using the backup RAM as the storage device 11b, the operation mode information recorded in the backup RAM immediately before the control microcomputer 11 is stopped is retained even after the control microcomputer 11 is restarted. The backup RAM has the advantage of a faster access speed than a nonvolatile memory such as a flash memory. Furthermore, the information stored in the backup RAM can be read at any time immediately after the control microcomputer 11 is started, and can be initialized as necessary. However, this is not limited to this, and a nonvolatile memory such as a flash memory can also be used as the storage device 11b.

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

[0059] 1 Vehicle, 11, 21 Control microcomputer, 30 Start switch, 100 Vehicle platform, 110 Vehicle control interface, 111A First VCIB, 111B Second VCIB, 120 Base vehicle, 200 Autonomous driving kit.

Claims

1. An autonomous driving system that automatically drives a vehicle; a vehicle platform capable of receiving commands related to the autonomous driving from the autonomous driving system; The vehicle platform is controlled in one of an automatic mode using the automatic driving system and a manual mode; the vehicle platform includes a base vehicle and a vehicle control interface that interfaces between the vehicle platform and the automated driving system; The vehicle control interface a first control device capable of controlling the base vehicle in accordance with the operation mode; a second control device capable of communicating with the first control device and controlling the base vehicle in accordance with the operation mode; The first control device If the operation mode acquired from the second control device after restarting the first control device is the automatic mode, setting the automatic mode; If the operation mode acquired from the second control device after the restart is the manual mode, the vehicle is set to the manual mode.

2. The vehicle according to claim 1 , wherein the first control device cuts off communication with the second control device and the base vehicle when the automatic mode is set after the restart.

3. The vehicle of claim 1 , wherein the first control unit maintains communication with the second control unit and the base vehicle if the manual mode is set after the restart.

4. The first control device storing history information when the start switch of the vehicle indicates an activated state and the operation mode is the automatic mode; The vehicle according to claim 1 , wherein, if the history information is stored after a restart, communication with the second control device and the base vehicle is cut off.

Images