vehicle

Abstract

To appropriately output a signal indicating a rotating direction of a wheel from a vehicle body to an automatic operation system in a vehicle in which an automatic operation is enabled.SOLUTION: A vehicle control interface performs: setting a signal indicating a rotating direction of a wheel at value "0" in the case of receiving, from a VP, information that indicates "Forward" (S13); setting a signal indicating a rotating direction of a wheel at value "1" in the case of receiving, from the VP, information indicating "Reverse" (S15); setting a signal indicating a rotating direction of a wheel at value "3" in the case of receiving, from the VP, information indicating "Invalid value" (S16); and outputting, to an ADK, a signal indicating a rotating direction of a wheel (S17).SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates to a vehicle configured to be capable of autonomous driving. [Background technology]

[0002] In recent years, development of technologies related to autonomous driving of vehicles has been progressing. For example, Japanese Patent Application Laid-Open No. 2018-132015 (Patent Document 1) discloses a vehicle equipped with a power system that comprehensively manages the power of the vehicle, a power supply system that comprehensively manages the power supply of various on-board devices, and an autonomous driving system 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 that the autonomous driving system can be configured to be externally attached to the vehicle itself. In this case, autonomous driving is achieved by controlling the vehicle according to commands from the autonomous driving system. To improve the accuracy of autonomous driving, it is desirable to appropriately output (communicate) the vehicle state to the autonomous driving system. One example of the vehicle state is the rotation direction of each wheel.

[0005] The present disclosure has been made to solve the above-mentioned problem, and its purpose is to appropriately output a signal indicating the direction of wheel rotation from the vehicle body to an autonomous driving system in a vehicle configured to be capable of autonomous driving. [Means for solving the problem]

[0006] (1) A vehicle according to this disclosure is a vehicle configured to be equipped with an automated driving system, and includes a vehicle platform that controls the vehicle in accordance with commands from the automated driving system, and a vehicle control interface that interfaces between the vehicle platform and the automated driving system. The vehicle platform determines the rotation direction of the wheels based on pulses input from wheel speed sensors mounted on the wheels. The vehicle control interface outputs a signal indicating the determined rotation direction to the automated driving system.

[0007] According to the above configuration, the vehicle is provided with a vehicle control interface that acts as an interface between the vehicle platform and the automated driving system, whereby a signal indicating the rotation direction of the wheels determined by the vehicle platform can be appropriately output to the automated driving system via the vehicle control interface.

[0008] (2) In one embodiment, the vehicle platform determines the direction of rotation of the wheels when two consecutive pulses indicating the same direction are input from the wheel speed sensors.

[0009] According to the above configuration, the vehicle platform determines the rotation direction of the wheels when it receives two consecutive pulses indicating the same direction from the wheel speed sensor, thereby reducing erroneous detection of the rotation direction of the wheels compared to when the rotation direction of the wheels is determined every time a pulse is received from the wheel speed sensor.

[0010] (3) In one embodiment, the vehicle control interface determines whether the direction of wheel rotation is: If the rotation direction of the wheel is determined to be the direction that will move the vehicle forward, a signal indicating Forward is output to the automated driving system, and if the rotation direction of the wheel is determined to be the direction that will move the vehicle backward, a signal indicating Reverse is output to the automated driving system.

[0011] According to the above configuration, an appropriate signal according to the rotation direction of the wheels can be output to the automatic driving system.

[0012] (4) In one embodiment, the vehicle control interface outputs a signal indicating an invalid value to the automated driving system if the direction of rotation of the wheels is not determined.

[0013] According to the above configuration, if the rotation direction of the wheels cannot be determined, a signal indicating this (a signal indicating an invalid value) can be output to the automatic driving system.

[0014] (5) In one embodiment, after the vehicle is started, the vehicle control interface outputs a signal indicating Forward to the automated driving system until the direction of rotation of the wheels is determined.

[0015] It is assumed that the probability of a vehicle moving forward is higher than the probability of it moving backward after starting up. According to the above configuration, the vehicle control interface outputs a signal indicating Forward to the automated driving system until the rotation direction of the wheels is determined after starting up the vehicle, so that the wheel rotation direction with a high probability can be output to the automated driving system even until the rotation direction of the wheels is determined. [Effects of the Invention]

[0016] In a vehicle configured to be capable of automatic driving, a signal indicating the direction of wheel rotation can be appropriately output from the vehicle body to the automatic driving system. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a diagram illustrating an overview of a MaaS system in which a vehicle according to an embodiment of the present disclosure is used. [Figure 2] FIG. 2 is a diagram showing detailed configurations of a vehicle control interface, a VP, and an ADK. [Figure 3] FIG. 10 is a diagram for explaining the setting of a signal indicating the rotation direction of a wheel. [Figure 4] 10 is a flowchart showing the procedure of a process executed by the VP for determining the rotation direction of the wheels. [Figure 5] 10 is a flowchart showing a processing procedure for transmitting the rotation direction of each wheel to the ADK. [Figure 6] This is an overall configuration diagram of MaaS. [Figure 7] FIG. 1 is a system configuration diagram of a MaaS vehicle. [Figure 8] FIG. 1 is a diagram showing a typical flow of an autonomous driving system. [Figure 9] FIG. 10 is a diagram showing an example of a timing chart of an API related to stopping and starting a MaaS vehicle. [Figure 10] FIG. 10 is a diagram showing an example of a timing chart of an API related to shift changes in a MaaS vehicle. [Figure 11] FIG. 10 is a diagram showing an example of a timing chart of an API related to wheel locking of a MaaS vehicle. [Figure 12] FIG. 10 is a diagram illustrating a limit value of a change amount of a tire turning angle. [Figure 13] FIG. 10 is a diagram illustrating accelerator pedal intervention. [Figure 14] FIG. 10 is a diagram illustrating brake pedal intervention. [Figure 15] This is an overall configuration diagram of MaaS. [Figure 16] FIG. 1 is a system configuration diagram of a vehicle. [Figure 17] FIG. 2 is a diagram illustrating a power supply configuration of a vehicle. [Figure 18] FIG. 10 is a diagram illustrating a strategy for safely stopping the vehicle when an abnormality occurs. [Figure 19] FIG. 1 is a diagram showing the layout of typical functions in a vehicle. DETAILED DESCRIPTION OF THE INVENTION

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

[0019] <Overall structure>

[0020] FIG. 1 is a diagram illustrating an overview of a MaaS (Mobility as a Service) system in which a vehicle according to an embodiment of the present disclosure is used.

[0021] Referring to FIG. 1, the MaaS system includes a vehicle 10, a data server 500, and a mobility service platform (hereinafter referred to as "MSPF"). ) 600 and autonomous driving-related mobility services 700.

[0022] The vehicle 10 includes a vehicle body 100 and an autonomous driving kit (hereinafter also referred to as an "ADK (Autonomous Driving Kit)") 200. The vehicle body 100 includes a vehicle control interface 110 and a vehicle platform (hereinafter also referred to as a "VP (Vehicle Platform)"). The device includes a data communication module (DCM) 120 and a data communication module (DCM) 190.

[0023] The vehicle 10 can perform autonomous driving in accordance with commands from an ADK 200 attached to the vehicle body 100. Although the vehicle body 100 and the ADK 200 are shown in separate locations in FIG. 1, the ADK 200 is actually attached to the rooftop of the vehicle body 100, for example. The ADK 200 can also be detached from the vehicle body 100. When the ADK 200 is detached, the vehicle body 100 can be driven manually by the user. In this case, the VP 120 executes driving control in manual mode (driving control according to user operation).

[0024] The vehicle control interface 110 is a CAN (Controller Area Network) or The vehicle control interface 110 can communicate with the ADK 200 via Ethernet (registered trademark) or the like. The vehicle control interface 110 uses a predetermined API (Application Programming Interface) defined for each signal to be communicated. By executing the ADK200 Interface, various commands can be received from the ADK200. The vehicle control interface 110 outputs the state of the vehicle main body 100 to the ADK 200 by executing a predetermined API defined for each signal to be communicated.

[0025] When the vehicle control interface 110 receives a command from the ADK 200, it outputs a control command corresponding to the command to the VP 120. The vehicle control interface 110 also acquires various information about the vehicle main body 100 from the VP 120 and outputs the status of the vehicle main body 100 to the ADK 200. The configuration of the vehicle control interface 110 will be described in detail later.

[0026] The VP 120 includes various systems and sensors for controlling the vehicle body 100. The VP 120 executes various vehicle controls in accordance with commands issued from the ADK 200 via the vehicle control interface 110. In other words, the VP 120 executes various vehicle controls in accordance with commands from the ADK 200, thereby enabling the vehicle 10 to be driven automatically. The configuration of the VP120 will be explained in detail later.

[0027] The ADK 200 includes an autonomous driving system (hereinafter also referred to as an "ADS (Autonomous Driving System)") for performing autonomous driving of the vehicle 10. The ADK 200 includes, for example, The ADK 200 creates a driving plan for the vehicle 10 and outputs various commands for driving the vehicle 10 in accordance with the created driving plan to the vehicle control interface 110 in accordance with an API defined for each command. The ADK 200 also receives various signals indicating the status of the vehicle main body 100 from the vehicle control interface 110 in accordance with an API defined for each signal, and reflects the received vehicle status in the creation of the driving plan. The configuration of the ADK 200 (ADS) will also be explained later.

[0028] DCM 190 includes a communication interface that enables vehicle main body 100 to communicate wirelessly with data server 500. DCM 190 outputs various types of vehicle information, such as speed, position, and autonomous driving status, to data server 500. DCM 190 also receives various types of data, for example, for managing the traveling of autonomously driven vehicles, including vehicle 10, in an autonomous driving-related mobility service 700 from mobility service 700 via MSPF 600 and data server 500.

[0029] The MSPF 600 is a unified platform to which various mobility services are connected. In addition to the autonomous driving-related mobility service 700, various mobility services (not shown) (for example, various mobility services provided by ride-sharing operators, car-sharing operators, insurance companies, rental car operators, taxi operators, etc.) are connected to the MSPF 600. The various mobility services including the mobility service 700 can use the APIs published on the MSPF 600 to use the various functions provided by the MSPF 600 according to the service content.

[0030] The autonomous driving-related mobility service 700 provides a mobility service using autonomous driving vehicles including the vehicle 10. The mobility service 700 can use an API published on the MSPF 600 to acquire, for example, driving control data of the vehicle 10 that communicates with the data server 500 and / or information stored in the data server 500 from the MSPF 600. The mobility service 700 also uses the API to transmit, for example, data for managing autonomous driving vehicles including the vehicle 10 to the MSPF 600.

[0031] The MSPF600 also provides an API for accessing various vehicle status and vehicle control data required for ADS development. ADS operators can use the vehicle status and vehicle control data stored in the data server 500 as the API.

[0032] <Vehicle configuration>

[0033] 2 is a diagram showing detailed configurations of the vehicle control interface 110, the VP 120, and the ADK 200. Referring to FIG. 2, the ADK 200 includes a computer 210, an HMI (Human Machine Interface) 230, a recognition sensor 260, and an attitude sensor 270. , and a sensor cleaner 290.

[0034] During the autonomous driving of the vehicle 10, the computer 210 uses various sensors described below to acquire information on the environment around the vehicle, the attitude, behavior, and position of the vehicle 10, etc. The computer 210 also acquires the state of the vehicle 10 from the VP 120 via the vehicle control interface 110, and sets the next operation of the vehicle 10 (acceleration, deceleration, turning, etc.). The vehicle control interface 110 outputs various commands to the vehicle control interface 110 to realize the next operation of the vehicle 10 that has been set.

[0035] The HMI 230 accepts user input operations for the vehicle 10. The HMI 230 is configured to be able to accept, for example, input by touch operation on a display screen and / or input by voice. The HMI 230 also presents information to the user of the vehicle 10 by displaying the information on the display screen. In addition to or instead of displaying information on the display screen, the HMI 230 may present information to the user of the vehicle 10 by voice. The HMI 230 provides information to the user and accepts input operations, for example, during autonomous driving, during manual driving by the user, or during a transition between autonomous driving and manual driving.

[0036] The recognition sensor 260 includes a sensor for recognizing the environment around the vehicle, such as a LIDAR (Laser Imaging Detection and Ranging), a millimeter wave radar, and a camera. It is composed of at least one of the following:

[0037] LIDAR emits pulsed laser light (infrared light) and measures distance based on the time it takes for the emitted light to reflect off an object and return. Millimeter-wave radar emits short-wavelength radio waves at an object and detects the radio waves reflected off the object and returns to measure the distance and / or direction to the object. The camera is, for example, located behind the rearview mirror inside the vehicle and captures images of the area ahead of the vehicle 10. By performing image processing on the images captured by the camera, it becomes possible to recognize other vehicles, obstacles, people, etc. ahead of the vehicle 10. Information acquired by the recognition sensor 260 is output to the computer 210.

[0038] The attitude sensor 270 detects the attitude, behavior, or position of the vehicle 10. The attitude sensor 270 includes, for example, an IMU (Inertial Measurement Unit) and a GPS (Global Positioning System).

[0039] The IMU detects, for example, accelerations in the forward / backward, left / right, and up / down directions of the vehicle 10, as well as angular velocities in the roll, pitch, and yaw directions of the vehicle 10. The GPS detects the position of the vehicle 10 using information received from multiple GPS satellites orbiting the Earth. The information acquired by the attitude sensor 270 is output to the computer 210.

[0040] Sensor cleaner 290 is configured to be able to remove dirt adhering to various sensors. For example, sensor cleaner 290 removes dirt from a camera lens, a laser, and / or an irradiating portion of a radio wave using a cleaning liquid and / or a wiper.

[0041] The vehicle control interface 110 includes a vehicle control interface box (VCIB) 111A and a VCIB 111B. Each of the VCIBs 111A and 111B includes an electronic control unit (ECU). ), specifically, the CPU (Central Processing Unit) and memory (Read Only Memory (ROM) and Random Access Memory (RAM)) are built in (neither is shown). VCIB111A and VCIB111B basically have the same functions. VCIB111A and VCIB111B differ in some of the connections to the multiple systems that make up VP120.

[0042] Each of the VCIB 111A and the VCIB 111B is communicably connected to the computer 210 of the ADK 200 via a CAN or the like. Furthermore, the VCIB 111A and the VCIB 111B are communicably connected to each other.

[0043] Each of the VCIBs 111A and 111B relays various commands from the ADK 200 and outputs them as control commands to the VP 120. More specifically, each of the VCIBs 111A and 111B executes a program stored in memory to convert various commands output from the ADK 200 into control commands used to control each system of the VP 120, and outputs the converted control commands to the connected system. Each of the VCIBs 111A and 111B also processes or relays various vehicle information output from the VP 120 and outputs it to the ADK 200 as vehicle status.

[0044] Furthermore, for some systems of VP120, such as the brake system and steering system, VCIB111A and VCIB111B are provided with equivalent functions, thereby providing redundancy in the control system between ADK200 and VP120. Therefore, when a failure occurs in part of the system, the function of VP120 (turning, stopping, etc.) can be maintained by switching over to an appropriate control system or by shutting off the control system where the failure occurred.

[0045] The VP 120 includes brake systems 121A and 121B, steering systems 122A and 122B, an EPB (Electric Parking Brake) system 123A, a P-Lock system 123B, a propulsion system 124, and a PCS (Pre-Crash Safety) system. 125 and a body system 126.

[0046] Of the multiple systems of VP 120, brake system 121B, steering system 122A, EPB system 123A, P-Lock system 123B, propulsion system 124, and body system 126 are communicatively connected to VCIB 111A via a communication bus.

[0047] Of the multiple systems of the VP 120, the brake system 121A, the steering system 122B, and the P-Lock system 123B are connected to the VCIB 111B via a communication bus so as to be able to communicate with each other.

[0048] Brake systems 121A and 121B are configured to be able to control multiple braking devices (not shown) provided on each wheel of vehicle 10. The braking devices include, for example, a disc brake system that operates using hydraulic pressure adjusted by an actuator. Brake system 121A and brake system 121B may be configured to have equivalent functions. Alternatively, one of brake system 121A and brake system 121B may be configured to be able to independently control the braking force of each wheel, and the other may be configured to be able to control the same braking force to be generated on each wheel.

[0049] A wheel speed sensor 127 is connected to the brake system 121B. The wheel speed sensor 127 is provided on each wheel of the vehicle 10. The wheel speed sensor 127 detects the rotation speed and rotation direction of the wheel. The wheel speed sensor 127 outputs the detected rotation speed and rotation direction of the wheel to the brake system 121B. For example, the wheel speed sensor 127 outputs different pulses when rotating in a direction that moves the vehicle 10 forward and when rotating in a direction that moves the vehicle 10 backward. As will be described later, the brake system 121B determines the rotation direction of each wheel based on the pulses from the wheel speed sensor 127. Then, the brake system 121B outputs information indicating the determined rotation direction of each wheel to the VCIB 111A.

[0050] Each of the brake systems 121A and 121B receives a command from the ADK 200 as a control command via the vehicle control interface 110 and operates in accordance with the control command. For example, brake systems 121A and 121B control the braking devices using a braking command generated in one of brake systems 121A and 121B, and when an abnormality occurs in one of the brake systems, the other brake system controls the braking device using a braking command generated in the other brake system.

[0051] The steering systems 122A and 122B are configured to be able to control the steering angle of the steering wheels of the vehicle 10 using a steering device (not shown). The steering device may be, for example, a rack and pinion type EPS (Electric Power Steering) that can adjust the steering angle using an actuator. include.

[0052] Steering system 122A and steering system 122B have equivalent functions. Each of steering systems 122A and 122B receives a command from ADK 200 as a control command via vehicle control interface 110 and generates a steering command for the steering device in accordance with the control command. For example, steering systems 122A and 122B control the steering device using a steering command generated in one of steering systems 122A and 122B, and if an abnormality occurs in one of the steering systems, the steering system controls the steering device using a steering command generated in the other steering system.

[0053] Pinion angle sensor 128A is connected to steering system 122A. Pinion angle sensor 128B is connected to steering system 122B. Each of pinion angle sensors 128A and 128B detects the rotation angle (pinion angle) of a pinion gear connected to a rotary shaft of an actuator. Pinion angle sensors 128A and 128B output the detected pinion angles to steering systems 122A and 122B, respectively.

[0054] The EPB system 123A is configured to be able to control an EPB (not shown) provided on at least one of the wheels. The EPB is provided separately from the braking device and fixes the wheel by operating an actuator. The EPB, for example, activates drum brakes for parking brakes provided on some of the wheels of the vehicle 10 to fix the wheel. The EPB also fixes the wheel by operating the braking device, for example, using an actuator that is separate from the brake systems 121A and 121B and that can adjust the hydraulic pressure supplied to the braking device. The EPB system 123A receives commands from the ADK 200 as control commands via the vehicle control interface 110 and controls the EPB in accordance with the control commands.

[0055] The P-Lock system 123B is configured to be able to control a P-Lock device (not shown) provided on the transmission of the vehicle 10. The P-Lock device fixes the rotation of the output shaft of the transmission by fitting a protrusion provided on the tip of a parking lock pole into the teeth of a gear (lock gear) connected to a rotating element in the transmission. The position of the parking lock pole is adjusted by an actuator. The P-Lock system 123B receives commands from the ADK 200 as control commands via the vehicle control interface 110 and controls the P-Lock device according to the control commands.

[0056] The propulsion system 124 is configured to be capable of switching shift ranges using a shift device (not shown) and to be capable of controlling the driving force of the vehicle 10 in the traveling direction using a drive source (not shown). The shift device is configured to be able to select one of a plurality of shift ranges. The drive source includes, for example, a motor generator and / or an engine. The propulsion system 124 receives commands from the ADK 200 as control commands via the vehicle control interface 110 and controls the shift device and the drive source in accordance with the control commands.

[0057] The PCS system 125 is communicatively connected to the brake system 121B. The PCS system 125 uses the detection results of the camera / radar 129 to execute control to avoid a collision of the vehicle 10 or to mitigate damage. For example, the PCS system 125 detects an object ahead and determines whether there is a possibility that the vehicle 10 will collide with the object based on the distance to the object. If it determines that there is a possibility of a collision with the object, the PCS system 125 outputs a braking command to the brake system 121B to increase the braking force.

[0058] The body system 126 controls various devices in accordance with, for example, the driving state or driving environment of the vehicle 10. The various devices include, for example, turn signals, headlights, hazard lights, a horn, front wipers, rear wipers, etc. The body system 126 receives commands from the ADK 200 as control commands via the vehicle control interface 110 and controls the various devices in accordance with the control commands.

[0059] Note that an operating device may be provided separately that allows the user to manually operate the above-mentioned braking device, steering device, EPB, P-Lock, shift device, various devices, drive source, etc.

[0060] <Determining and outputting the direction of wheel rotation>

[0061] In autonomous driving, it is desirable for the ADK200 to appropriately acquire the state of the vehicle body 100 in order to create an appropriate driving plan. One important parameter indicating the state of the vehicle body 100 is the rotation direction of each wheel. By acquiring the rotation direction of each wheel, the ADK200 can recognize, for example, the driving state of the vehicle 10. In this embodiment, the rotation direction of each wheel determined by the VP120 is output to the ADK200 via the vehicle control interface 110. The intervention of the vehicle control interface 110 allows the rotation direction of each wheel to be appropriately transmitted from the VP120 to the ADK200. Note that in this embodiment, the brake system 121B of the VP120 determines the rotation direction of each wheel. However, this is not limited to the brake system 121B determining the rotation direction of each wheel, and the rotation direction of each wheel may be determined by a system other than the VP120. Furthermore, although an example in which the vehicle 10 has four wheels will be described below, the present disclosure can be similarly applied to vehicles having three or fewer wheels or five or more wheels.

[0062] <<Wheel rotation direction output: Vehicle control interface>>

[0063] The vehicle control interface 110 sets a signal (vehicle state) indicating the rotation direction of each wheel to be output to the ADK 200 according to information (vehicle information) indicating the rotation direction of each wheel received from the VP 120. Specifically, the vehicle control interface 110 sets a signal (WheelSpeed_FL_Rotation) indicating the rotation direction of the left front wheel, a signal (WheelSpeed_FR_Rotation) indicating the rotation direction of the right front wheel, a signal (WheelSpeed_RL_Rotation) indicating the rotation direction of the left rear wheel, and a signal (WheelSpeed_RR_Rotation) indicating the rotation direction of the right rear wheel according to the information indicating the rotation direction of each wheel. By outputting the signals indicating the rotation directions of the above four wheels to the ADK 200, the ADK 200 can recognize the rotation direction of each wheel. The vehicle control interface 110 sets the signals indicating the rotation direction of each wheel according to FIG. 3. When there is no need to particularly distinguish between the wheels, the above four signals may be collectively referred to as a signal indicating the rotation direction of the wheel (WheelSpeed_Rotation).

[0064] FIG. 3 is a diagram for explaining the setting of a signal that indicates the rotation direction of a wheel. FIG. 3 shows the relationship between the rotation direction of a wheel and a value. Specifically, the value is shown in the "value" column, and the rotation direction of the wheel is shown in the "Description" column. Remarks are written in the "remarks" column.

[0065] Referring to Fig. 3, a value of 0 indicates a rotation direction (Forward) that moves the vehicle 10 forward. A value of 1 indicates a rotation direction (Reverse) that moves the vehicle 10 backward. A value of 3 indicates an invalid value, that is, indicates that the rotation direction of the wheel has not been determined. Note that in this embodiment, a value of 2 is not used, but it can be set appropriately and used.

[0066] If the information indicating the rotation direction received from VP 120 indicates "Forward", the vehicle control interface 110 sets the value of the signal indicating the rotation direction of the wheels (WheelSpeed_Rotation) to 0. If the information indicating the rotation direction received from VP 120 indicates "Reverse", the vehicle control interface 110 sets the value of the signal indicating the rotation direction of the wheels to 1. If the information indicating the rotation direction of the wheels received from VP 120 indicates "Invalid value", the vehicle control interface 110 sets the value of the signal indicating the rotation direction of the wheels to 3.

[0067] As described above, the vehicle control interface 110 sets values ​​for the signal indicating the rotation direction of the left front wheel, the signal indicating the rotation direction of the right front wheel, the signal indicating the rotation direction of the left rear wheel, and the signal indicating the rotation direction of the right rear wheel.

[0068] When the vehicle control interface 110 sets a signal indicating the rotation direction of the wheels, it outputs the signal indicating the set rotation direction of the wheels to the ADK 200. Upon receiving the signal indicating the rotation direction of the wheels, the ADK 200 can recognize the rotation direction of each wheel based on the value indicated by the signal. Note that the vehicle control interface 110 may output the signal indicating the rotation direction of the left front wheel, the signal indicating the rotation direction of the right front wheel, the signal indicating the rotation direction of the left rear wheel, and the signal indicating the rotation direction of the right rear wheel individually to the ADK 200, or may output them all together to the ADK 200.

[0069] After the vehicle 10 is started, until the rotation direction of each wheel is determined in the VP 120, the vehicle control interface 110 sets the signals indicating the rotation direction of the wheels so that the rotation direction of each wheel indicates "Forward." That is, the vehicle control interface 110 sets the value of 0 to the signal indicating the rotation direction of the left front wheel, the signal indicating the rotation direction of the right front wheel, the signal indicating the rotation direction of the left rear wheel, and the signal indicating the rotation direction of the right rear wheel. This is because it is assumed that the probability of the vehicle 10 moving forward is higher than the probability of it moving backward. As a result, it is possible to output a likely (highly probable) rotation direction of the wheels to the ADK 200 even until the rotation direction of the wheels is determined.

[0070] <<Determining the direction of wheel rotation: VP>>

[0071] VP 120 (brake system 121B in this embodiment) determines the rotation direction of each wheel (front left wheel, front right wheel, rear left wheel, rear right wheel) and outputs information indicating the determined rotation direction to vehicle control interface 110. A method for determining the rotation direction of the wheels will be specifically described below.

[0072] Pulses are input to the VP 120 (brake system 121B) from the wheel speed sensor 127 at every predetermined control period. When the VP 120 receives two consecutive pulses indicating the same direction, it determines that direction as the rotation direction of the wheels. For example, when the VP 120 receives two consecutive pulses indicating a rotation direction that moves the vehicle 10 forward, it determines that the rotation direction of the wheels is the same as the rotation direction of the wheels. The VP120 determines the direction of rotation of the wheels to be "Forward." Then, the VP120 uses the information indicating the determined "Forward" as information indicating the direction of rotation of the wheels. Furthermore, when two consecutive pulses indicating a rotation direction for moving the vehicle 10 backward are received, the VP120 determines the direction of rotation of the wheels to be "Reverse." Then, the VP120 uses the information indicating the determined "Reverse" as information indicating the direction of rotation of the wheels. As described above, the reason for determining the direction of rotation of the wheels when two consecutive pulses indicating the same direction are received is to suppress erroneous detection.

[0073] On the other hand, if the rotation direction indicated by the pulse received this time is different from the rotation direction indicated by the pulse received last time, VP120 does not update the rotation direction of the wheel. In this case, VP120 maintains the previously determined rotation direction of the wheel (previous value). VP120 determines the previously determined rotation direction of the wheel as the rotation direction of the wheel, and sets information indicating the determined rotation direction ("Forward," "Reverse," or "Invalid value") as information indicating the rotation direction of the wheel.

[0074] Furthermore, due to some kind of abnormality, such as a communication abnormality, pulses may not be input from the wheel speed sensor 127. If the VP 120 does not receive pulses from the wheel speed sensor 127 in the current control cycle, it determines that an abnormality has occurred. Then, the VP 120 regards the information indicating "Invalid value" as information indicating the rotation direction of the wheels.

[0075] To summarize the above, the VP 120 sets information indicating "Forward," "Reverse," or "Invalid value" as information indicating the rotation direction of the wheels based on pulses received from the wheel speed sensor 127. Then, the VP 120 outputs the information indicating the rotation direction of the wheels to the vehicle control interface 110. Note that the information indicating the rotation direction of the wheels includes information for identifying the wheels.

[0076] <Processing procedure for determining the direction of wheel rotation>

[0077] FIG. 4 is a flowchart showing the procedure of the process executed by VP 120 to determine the rotation direction of the wheels. The process of the flowchart in FIG. 4 is repeatedly executed by VP 120 at predetermined control intervals. Note that in FIG. 4 and FIG. 5 described later, an example of determining the rotation direction of the left front wheel is explained as a representative example, but similar processes are executed in parallel for the other wheels (right front wheel, left rear wheel, right rear wheel). Also, the process of the flowchart in FIG. 4 will be explained as being realized by software processing by VP 120, but part or all of it may be realized by hardware (electrical circuitry) created within VP 10.

[0078] The VP 120 determines whether or not a pulse has been input from the wheel speed sensor 127 (Step 1; hereinafter, step is abbreviated as "S"). If it determines that a pulse has been input from the wheel speed sensor 127 (YES in S1), the VP 120 determines whether or not the input pulse is a pulse indicating the same rotation direction as the previous time (same direction pulse) (S2).

[0079] If the input pulse indicates the same rotation direction as the previous time (YES in S2), VP120 determines the rotation direction indicated by the pulse as the rotation direction of the wheel (S3). Specifically, VP120 determines the rotation direction of the wheel as "Forward" or "Reverse," and associates the determined information with information for identifying the wheel to determine the rotation direction of the left front wheel.

[0080] On the other hand, if the input pulse indicates a rotation direction different from the previous one (NO in S2), the rotation direction of the wheel cannot be determined, so the VP120 determines the rotation direction of the wheel from the previously determined direction. The previously determined rotation direction of the wheel is maintained (previous value) (S4). That is, the VP120 maintains the previously determined rotation direction of the wheel until a new rotation direction of the wheel is determined. In this case, the VP120 associates the information indicating the previous rotation direction of the wheel ("Forward", "Reverse", or "Invalid value") with the information for identifying the wheel, and sets it as information indicating the rotation direction of the left front wheel.

[0081] If it is determined in S1 that there is no pulse input from the wheel speed sensor 127 (NO in S1), the VP 120 determines that data could not be acquired due to some kind of abnormality, such as a communication abnormality, and confirms the abnormality (S5). In this case, the VP 120 associates the information indicating "Invalid value" with information for identifying the wheel, and sets it as information indicating the rotation direction of the left front wheel.

[0082] The VP 120 outputs information indicating the rotation direction of the left front wheel determined in S3, S4 or S5 to the vehicle control interface 110 (S6). Then, the VP 120 advances the process to return.

[0083] <Processing procedure for transmitting wheel rotation direction to ADK>

[0084] Fig. 5 is a flowchart showing the procedure for transmitting the rotation direction of each wheel to the ADK 200. The processing of the flowchart in Fig. 5 is repeatedly executed at predetermined control intervals by the vehicle control interface 110. Note that, although the processing of the flowchart in Fig. 5 will be described as being realized by software processing by the vehicle control interface 110, part or all of it may also be realized by hardware (electrical circuitry) created within the vehicle control interface 110.

[0085] The vehicle control interface 110 determines whether or not information indicating the rotation direction of the left front wheel has been received from the VP 120 (S11).

[0086] When the information indicating the rotation direction of the left front wheel is received from the VP 120 (YES in S11), the vehicle control interface 110 determines whether the information indicating the rotation direction of the left front wheel is information indicating "Forward" (S12). If the information indicating the rotation direction of the left front wheel is information indicating "Forward" (YES in S12), the vehicle control interface 110 sets the value of 0 to the signal indicating the rotation direction of the left front wheel (WheelSpeed_FL_Rotation) (S13).

[0087] If the information indicating the rotation direction of the left front wheel is not information indicating "Forward" (NO in S12), the vehicle control interface 110 determines whether the information indicating the rotation direction of the left front wheel is information indicating "Reverse" (S14). If the information indicating the rotation direction of the left front wheel is information indicating "Reverse" (YES in S14), the vehicle control interface 110 sets the value of 1 to the signal indicating the rotation direction of the left front wheel (S15).

[0088] If the information indicating the rotation direction of the left front wheel is not information indicating "Reverse" (NO in S14), the vehicle control interface 110 sets the value of the signal indicating the rotation direction of the left front wheel to 3 (S16). The fact that the information indicating the rotation direction of the left front wheel is neither "Forward" nor "Reverse" is because the information indicating the rotation direction of the left front wheel is information indicating an "Invalid value."

[0089] Also, if the information indicating the rotation direction of the left front wheel is not received from the VP 120 (NO in S11), the vehicle control interface 110 sets the value of 3 to the signal indicating the rotation direction of the left front wheel (S16). There is a possibility that a communication error has occurred between the interface 110 and the network.

[0090] When a signal indicating the rotation direction of the left front wheel is set, the vehicle control interface 110 outputs the signal indicating the set rotation direction of the left front wheel to the ADK 200. This allows the ADK 200 to recognize the rotation direction of the left front wheel.

[0091] As described above, the MaaS system according to this embodiment is provided with a vehicle control interface 110 that interfaces between the VP 110 and the ADK 200. This allows the wheel rotation direction determined by the VP 120 to be appropriately output to the ADK 200. By appropriately outputting the wheel rotation direction to the ADK 200, the ADK 200 can create a more accurate driving plan, thereby improving the accuracy of autonomous driving.

[0092] Furthermore, even if the developers of the vehicle main body 100 and the ADK200 are different, the two can be linked by developing the vehicle main body 100 and the ADK200 in accordance with the procedures and data formats (API) defined for the vehicle control interface 110.

[0093] In this embodiment, an example has been described in which the VP 120 determines the rotation direction of the wheels, but the vehicle control interface 110 may be configured to determine the rotation direction of the wheels.

[0094] [Variation 1]

[0095] In this embodiment, the vehicle control interface 110 receives information indicating the rotation direction of the wheels from the VP 120 and sets a signal indicating the rotation direction of the wheels in accordance with the relationship between the rotation direction of the wheels and the value shown in Fig. 3. However, for example, if the VP 120 sets information indicating the rotation direction of the wheels in accordance with the above relationship, the vehicle control interface 110 may relay the information indicating the rotation direction of the wheels to the ADK 200. This also makes it possible to appropriately output the rotation direction of the wheels to the ADK 200.

[0096] [Variation 2]

[0097] In the embodiment, an example has been described in which, when VP120 receives two consecutive pulses indicating the same direction, the VP120 determines the direction as the rotation direction of the wheel. However, determining the rotation direction of the wheel is not limited to receiving two consecutive pulses indicating the same direction. For example, VP120 may determine the direction as the rotation direction of the wheel when it receives a predetermined number of consecutive pulses indicating the same direction. The predetermined number can be set to a value of three or more pulses. This can further reduce erroneous detection of the rotation direction of the wheel.

[0098] In addition, for example, the rotation direction of the wheels may be determined with one pulse. That is, the VP 120 may determine the rotation direction of the wheels every time it receives a pulse from the wheel speed sensor 127.

[0099] [Aspect]

[0100] It will be appreciated by those skilled in the art that the exemplary embodiments described above are examples of the following aspects.

[0101] (Item 1) A vehicle according to one aspect is a vehicle configured to be able to be equipped with an autonomous driving system. The vehicle includes a vehicle platform that controls the vehicle in accordance with commands from the autonomous driving system, and a vehicle control interface that interfaces between the vehicle platform and the autonomous driving system. The vehicle platform determines the rotation direction of the wheels based on pulses input from wheel speed sensors mounted on the wheels. The vehicle control interface outputs a signal indicating the determined rotation direction to the autonomous driving system.

[0102] (Item 2) In the vehicle described in item 1, the vehicle platform determines the rotation direction of the wheels when two consecutive pulses indicating the same direction are input from the wheel speed sensor.

[0103] (3) In the vehicle described in paragraph 1 or paragraph 2, the vehicle control interface outputs a signal indicating Forward to the automated driving system when the rotation direction of the wheel is determined to be a rotation direction that will move the vehicle forward, and outputs a signal indicating Reverse to the automated driving system when the rotation direction of the wheel is determined to be a rotation direction that will move the vehicle backward.

[0104] (4) In a vehicle described in any one of paragraphs 1 to 3, the vehicle control interface outputs a signal indicating an invalid value to the automated driving system if the rotation direction of the wheels is not determined.

[0105] (5) In the vehicle described in paragraph 3 or 4, after the vehicle is started, the vehicle control interface outputs a signal indicating Forward to the automated driving system until the direction of rotation of the wheels is determined.

[0106] (Item 6) A vehicle according to one embodiment includes an automated driving system that creates a driving plan, a vehicle platform that controls the vehicle in accordance with commands from the automated driving system, and a vehicle control interface that interfaces between the vehicle platform and the automated driving system. The vehicle platform determines the rotation direction of the wheels based on pulses input from wheel speed sensors mounted on the wheels. The vehicle control interface outputs a signal indicating the determined rotation direction to the automated driving system.

[0107] (Item 7) In the vehicle described in item 6, the vehicle platform determines the rotation direction of the wheels when two consecutive pulses indicating the same direction are input from the wheel speed sensor.

[0108] (Article 8) In a vehicle described in paragraph 6 or paragraph 7, the vehicle control interface outputs a signal indicating Forward to the automated driving system when the rotation direction of the wheel is determined to be a rotation direction that will move the vehicle forward, and outputs a signal indicating Reverse to the automated driving system when the rotation direction of the wheel is determined to be a rotation direction that will move the vehicle backward.

[0109] (Article 9) In a vehicle described in any one of paragraphs 6 to 8, the vehicle control interface outputs a signal indicating an invalid value to the automated driving system if the rotation direction of the wheels is not determined.

[0110] (10) In the vehicle described in paragraph 8 or paragraph 9, after the vehicle is started, the vehicle control interface outputs a signal indicating Forward to the automated driving system until the direction of rotation of the wheels is determined.

[0111] (Item 11) A method for controlling a vehicle according to one aspect is a method for controlling a vehicle configured to be equipped with an automated driving system. The vehicle includes a vehicle platform that controls the vehicle in accordance with commands from the automated driving system, and a vehicle control interface that interfaces between the vehicle platform and the automated driving system. The control method is The method includes a step in which the system determines the rotation direction of the wheels based on pulses input from wheel speed sensors provided on the wheels, and a step in which the vehicle control interface outputs a signal indicating the determined rotation direction to the autonomous driving system.

[0112] (Item 12) In the vehicle control method described in item 11, the vehicle platform determines the rotation direction of the wheels when two consecutive pulses indicating the same direction are input from the wheel speed sensors.

[0113] (Clause 13) The vehicle control method described in clause 11 or 12 further includes the steps of: when the rotation direction of the wheel is determined to be a rotation direction that moves the vehicle forward, the vehicle control interface outputting a signal indicating Forward to the automated driving system; and when the rotation direction of the wheel is determined to be a rotation direction that moves the vehicle backward, the vehicle control interface outputting a signal indicating Reverse to the automated driving system.

[0114] (Clause 14) In the vehicle control method described in any of clauses 11 to 13, the method further includes a step in which the vehicle control interface outputs a signal indicating an invalid value to the automated driving system if the rotation direction of the wheels is not determined.

[0115] (Clause 15) The vehicle control method described in clause 13 or 14 further includes a step in which the vehicle control interface outputs a signal indicating Forward to the automated driving system until the direction of rotation of the wheels is determined after the vehicle is started. [Example]

[0116] Toyota's MaaS Vehicle Platform API Specification for ADS Developers [Standard Edition #0.1] Revision History [Table 1] table of contents 1. Outline 4 1.1. Purpose of this Specification 4 1.2. Target Vehicle 4 1.3. Definition of Term 4 1.4. Precaution for Handling 4 2. Structure 5 2.1. Overall Structure of MaaS 5 2.2. System structure of MaaS vehicle 6 3. Application Interfaces 7 3.1. Responsibility sharing of when using APIs 7 3.2. Typical usage of APIs 7 3.3. APIs for vehicle motion control 9 3.3.1. Functions 9 3.3.2. Inputs 16 3.3.3. Outputs 23 3.4. APIs for BODY control 45 3.4.1. Functions 45 3.4.2. Inputs 45 3.4.3. Outputs 56 3.5. APIs for Power control 68 3.5.1. Functions 68 3.5.2. Inputs 68 3.5.3. Outputs 69 3.6. APIs for Safety 70 3.6.1. Functions 70 3.6.2. Inputs 70 3.6.3. Outputs 70 3.7. APIs for Security 74 3.7.1. Functions 74 3.7.2. Inputs 74 3.7.3. Outputs 76 3.8. APIs for MaaS Service 80 3.8.1. Functions 80 3.8.2. Inputs 80 3.8.3. Outputs 80 1. Outline 1.1. Purpose of this Specification This document is an API specification of Toyota Vehicle Platform and contains the outline, the usage and the caveats of the application interface. This document is the API specification for Toyota's Vehicle Platform and provides an overview of the Application Interface. It includes instructions on how to use the product and precautions to take.

[0117] 1.2. Target Vehicle e-Palette, MaaS vehicle based on the POV(Privately Owned Vehicle) manufactured by Toyota The vehicles covered in this document are MaaS vehicles based on the e-Palette and commercially available vehicles manufactured by Toyota. do.

[0118] 1.3. Definition of Term [Table 2] 1.4. Precaution for Handling This is an early draft of the document. All the contents are subject to change. Such changes are notified to the users. Please note that some parts are still TBD will be updated in the future. This book is an Early Draft version. Please note that the information may be subject to change. If there are any changes to the information, we will contact you separately. Also, since the detailed design is still in progress, there are some TBD items here and there, but we will update them accordingly.

[0119] 2. Structure 2.1. Overall Structure of MaaS The overall structure of MaaS with the target vehicle is shown. The overall configuration of MaaS using the target vehicles is shown below (Figure 6). Vehicle control technology is being used as an interface for technology providers. Technology providers can receive open API such as vehicle state and vehicle control, necessary for development of automated driving systems. The target vehicles in this document are those that interface vehicle control technology to ADS operators. ADS operators will disclose the vehicle status and vehicle operation status necessary for the development of autonomous driving systems. Both controls can be used as APIs.

[0120] 2.2. System structure of MaaS vehicle The system architecture as a premise is shown. The assumed system configuration is shown below (Figure 7). The target vehicle will adopt the physical architecture of using CAN for the bus between ADS and VCIB. In order to realize each API in this document, the CAN frames and the bit assignments are shown in the form of “bit assignment table” as a separate document. The vehicle covered by this document has a physical configuration in which the connection bus to the vehicle (VCIB) is configured as CAN. . To implement each API in this book using CAN, you will need to specify the CAN frame and data bit assignments separately. It is presented as a "bit assignment table."

[0121] 3. Application Interfaces 3.1. Responsibility sharing of when using APIs Basic responsibility sharing between ADS and vehicle VP is as follows when using APIs. The basic division of responsibilities between ADS and VP when using the API is as follows: [ADS] The ADS should create the driving plan, and should indicate vehicle control values ​​to the VP. [VP] The Toyota VP should control each system of the VP based on indications from an ADS .

[0122] Typical usage of APIs In this section, typical usage of APIs is described. This section describes typical API usage. CAN will be adopted as a communication line between ADS and VP. Therefore, basically, APIs should be executed every defined cycle time of each API by ADS. CAN is used as the communication line between ADS and VP. Therefore, the API basically It must be executed at the interval defined for each API. A typical workflow of ADS of when executing APIs is as follows. A typical flow of ADS when executing an API is shown below (Figure 8).

[0123] 3.3. APIs for vehicle motion control In this section, the APIs for vehicle motion control which is controllable in the MaaS vehicle is described. This section explains the vehicle control API that can be controlled by MaaS vehicles and how to use it. .

[0124] Functions 3.3.1.1.Standstill, Start Sequence The transition to the standstill (immobility) mode and the vehicle start sequence are described. This function presupposes the vehicle is in Autonomy_State = Autonomous Mode. The request is rejected in other modes. This section describes how to transition to Standstill and how to start. This function assumes that Autonomy_State = Autonomous Mode. Requests made in any other case will be rejected. The diagram below shows an example. The figure below shows an example. Acceleration Command requests deceleration and stops the vehicle. Then, when Longitudinal_Velocity is confimed as 0[km / h], Standstill Command=“Applied” is sent. After the brake hold control is finished, Standstill Status becomes “Applied”. Until then, Acceleration Command has to continue deceleration request. Either Standstill Command=”Applied” or Acceleration Command's deceleration request were canceled, the transition to the brake hold control will not happen. After that, the vehicle continues to be standstill as far as Standstill Command=”Applied” is being sent. Acceleration Command can be set to 0 (zero) during this period. The Acceleration Command requests deceleration and stops the vehicle. After that, when Longitudinal_Velocity is confirmed as 0 [km / h], it requests Standstill Command = "Applied". When brake hold control is completed, Standstill Status = "Applied". Then During this time, the Acceleration Command must continue to request deceleration. If Standstill Command = "Applied" or the deceleration request of Acceleration Command is canceled, the system will not transition to brake hold control. After that, Standstill will continue as long as Standstill Command = "Applied" is requested. During this time, Acceleration Command can be set to 0. If the vehicle needs to start, the brake hold control is canceled by setting Standstill Command to “Released”. At the same time, acceleration / deceleration is controlled based on Acceleration Command. When you want to start moving, release the brake hold by setting Standstill Command = “Released”. At the same time, acceleration and deceleration are controlled according to the Acceleration Command (Fig. 9). EPB is engaged when Standstill Status = ”Applied” continues for 3 minutes. EPB will activate after 3 minutes of Standstill Status = "Applied".

[0125] 3.3.1.2. Direction Request Sequence The shift change sequence is described. This function presupposes that Autonomy_State = Autonomous Mode. Otherwise, the request is rejected. This describes how to change shifts. This function assumes Autonomy_State = Autonomous Mode. Any other request will be rejected. Shift change happens only during Actual_Moving_Direction=”standstill”). Otherw ise, the request is rejected. Shift changes can only be performed when the vehicle is stopped (Actual_Moving_Direction="standstill"). Otherwise, the request will be rejected. In the following diagram shows an example. Acceleration Command requests deceleration and makes the vehicle stop. After Actual_Moving_Direction is set to ”standstill”, any shit position can be requested by Propulsion Direction Command. (In the example below, “D”→”R”). During shift change, Acceleration Command has to request deceleration. After the shift change, acceleration / decekeration is controlled based on Acceleration Command value. The figure below shows an example. The Acceleration Command requests a deceleration to stop the vehicle. After Actual_Moving_Direction="standstill", Propulsion Direction Command A desired shift range is requested by (In the example below, switching from "D" to "R") During a shift change, the Acceleration Command must simultaneously request Deceleration. After the change, acceleration / deceleration is performed as necessary according to the Acceleration Command value (Fig. 10).

[0126] WheelLock Sequence The engagement and release of wheel lock is described. This function presupposes Autonomy_State = Autonomous Mode, other wise the request is rejected. This section describes how to apply and release WheelLock. This function is only available when Autonomy_State = Autonomous Mode. Requests made in any other mode will be rejected. This function is conductible only during vehicle is stopped. Acceleration Command requests deceleration and makes the vehicle stop. After Actual_Moving_Direction is set to ”standstill”, WheelLock is engaged by Immobilization Command = “Applied”. Acceleration Command is set to Deceleration until Immobilization Status is set to “Applied”. This function can only be performed when the Acceleration Command is Deceleration. Request speed and stop the vehicle. After Actual_Moving_Direction="standstill", apply WheelLock with Immobilization Command="Applied". Until the Immobilization Status becomes "Applied", the Acceleration Command is Deceleration (-0.4m / s^2). If release is desired, Immobilization Command = “Release” is requested when the vehicle is stationary. Acceleration Command is set to Deceleration at that time. To release the immobilization, request Immobilization Command = "Release" while the vehicle is stopped. At that time, the Acceleration Command should be Deceleration. After this, the vehicle is accelerated / decelerated based on Acceleration Command value. After that, the acceleration / deceleration is performed according to the value of Acceleration Command (Figure 11).

[0127] 3.3.1.4. Road_Wheel_Angle Request Steering Method This function presupposes Autonomy_State = “Autonomous Mode”, and the request is rejected otherwise. This function is based on the Autonomy_State = “Autonomous Mode” condition. Requests made in any other state will be rejected. Tire Turning Angle Command is the relative value from Estimated_Road_Wheel_Angle _Actual. Tire Turning Angle Command is entered relative to Estimated_Road_Wheel_Angle_Actual. To exert effort. For example, in case that Estimated_Road_Wheel_Angle_Actual =0.1 [rad] while the vehicle is going straight; If ADS requests to go straight ahead, Tire Turning Angle Command should be set to 0+0.1 =0.1[rad]. If ADS requests to steer by -0.3 [rad], Tire Turning Angle Command should be set to -0.3+0.1 = -0.2[rad] For example, if the vehicle is traveling straight, but Estimated_Road_Wheel_Angle_Actual indicates 0.1 [rad]. If you want to request a straight line from ADS, the Tire Turning Angle Command will output 0+0.1 = 0.1 [rad]. To exert effort. If you want to request steering of -0.3 [rad] from ADS, specify a Tire Turning Angle Command of -0.3 + 0.1 = -0.2 [rad].

[0128] 3.3.1.5. Rider Operation 3.3.1.5.1. Acceleration Pedal Operation While in Autonomous driving mode, accelerator pedal stroke is eliminated from the vehicle acceleration demand selection. During autonomous driving mode, operation of the accelerator pedal is excluded from the selection of the vehicle's required acceleration.

[0129] 3.3.1.5.2. Brake Pedal Operation The action when the brake pedal is operated. In the autonomy mode, target vehicle deceleration is the sum of 1) estimated deceleration from the brake pedal stroke and 2) deceleration request from AD system This section describes the operation when the brake pedal is operated. During autonomous driving mode, 1) the acceleration / deceleration estimated from the amount of brake pedal operation, and 2) The sum of the deceleration request input from the system is set as the target acceleration of the vehicle.

[0130] 3.3.1.5.3. Shift_Lever_Operation Shift lever operation In Autonomous driving mode, driver operation of the shift lever is not reflected in Propulsion Direction Status. If necessary, ADS confirms Propulsion Direction by Driver and changes shift position by using Propulsion Direction Command. During autonomous driving mode, the driver's shift lever operation is is not reflected in the If necessary, ADS checks the Propulsion Direction by Driver and If necessary, a change in shift position is requested using a Propulsion Direction Command.

[0131] 3.3.1.5.4. Steering Operation When the driver (rider) operates the steering, the maximum is selected from 1) the torque value estimated from driver operation angle, and 2) the torque value calculated from requested wheel angle. When the driver operates the steering wheel, The maximum value is selected from the torque value estimated from the driver's operation amount and the torque value calculated from the requested steering angle. Note that Tire Turning Angle Command is not accepted if the driver strongly turns the steering wheel. The above-mentioned is determined by Steering_Wheel_Intervention flag. However, if the driver applies strong steering force, the Tire Turning Angle Command will not be accepted. The above is determined by the Steering_Wheel_Intervention flag.

[0132] Inputs [Table 3] 3.3.2.1. Propulsion Direction Command Request to switch between forward (D range) and back (R range) Shift range (R / D) switching request Values [Table 4] Remarks ·Only available when Autonomy_State = “Autonomous Mode”. Only Autonomy_State = “Autonomous Mode” can be used ·D / R is changeable only the vehicle is stationary (Actual_Moving_Direction=”standstill”). Switch only when the vehicle is stopped (Actual_Moving_Direction="standstill") It is possible. ·The request while driving (moving) is rejected. If requested while driving, decline ·When system requests D / R shifting, Acceleration Command is sent deceleration(-0.4m / s^2) simultaneously. (Only while brake is applied.) When requesting D / R switching, a deceleration value is also requested via Acceleration Command. (Assuming operation with the brakes held) ·The request may not be accepted in following cases. ·Direction_Control_Degradation_Modes = ”Failure detected” Your request may not be accepted in the following cases: ·Direction_Control_Degradation_Modes = ”Failure detected”

[0133] 3.3.2.2. Immobilization Command Request to engage / release WheelLock Request WheelLock application / release. Values [Table 5] Remarks ·Available only when Autonomy_State = “Autonomous Mode”. Only Autonomy_State = “Autonomous Mode” can be used ·Changeable only when the vehicle is stationary (Actual_Moving_Direction=”standstill”). Switch only when the vehicle is stopped (Actual_Moving_Direction="standstill") It is possible. ·The request is rejected when vehicle is running. If requested while driving, decline ·When Apply / Release mode change is requested, Acceleration Command is set to deceleration(-0.4m / s^2). (Only while brake is applied.) When requesting a change in Applied / Released, a deceleration value (-0.4m / s^2) for the Acceleration Command is also requested. (Assuming operation with the brakes held)

[0134] Standstill Command Request the vehicle to be stationary Request permission / release from parking hold Values [Table 6] Remarks ·Only available when Autonomy_State = “Autonomous Mode”. Only Autonomy_State = “Autonomous Mode” can be used ·Confirmed by Standstill Status = “Applied”. Check if Standstill Status = “Applied”. ·When the vehicle is stationary (Actual_Moving_Direction=”standstill”), transition to Stand Still is enabled. If the vehicle is stopped (Actual_Moving_Direction="standstill"), transition to Standstill is allowed. ·Acceleration Command has to be continued until Standstill Status becomes “Applied” and Acceleration Command's deceleration request (-0.4m / s^2) should be continued. Until Standstill Status = "Applied", it is necessary to continue requesting "Applied" and request a deceleration value (-0.4m / s^2) for the Acceleration Command. Requests may not be accepted. For details, see TBD. There are more cases where the request is not accepted. Details are TBD Acceleration Command Command vehicle acceleration. Indicate vehicle acceleration Values Estimated_Max_Decel_Capability to Estimated_Max_Accel_Capability [m / s2] Remarks ·Only available when Autonomy_State = “Autonomous Mode”. Only Autonomy_State = “Autonomous Mode” can be used ·Acceleration (+) and deceleration (-) request based on Propulsion Direction Status direction. Acceleration (+) and deceleration (-) requests for the direction of the Propulsion Direction Status. ·The upper / lower limit will vary based on Estimated_Max_Decel_Capability and Estimated_Max_Accel_Capability. Estimated_Max_Decel_Capability and Estimated_Max_Accel_Capability determine the acceleration. The upper and lower limits vary. ·When acceleration more than Estimated_Max_Accel_Capability is requested, the request is set to Estimated_Max_Accel_Capability. If you request a value greater than or equal to Estimated_Max_Accel_Capability, The required value is controlled as Estimated_Max_Accel_Capability. ·When deceleration more than Estimated_Max_Decel_Capability is requested d, the request is set to Estimated_Max_Decel_Capability. If you request a value greater than or equal to Estimated_Max_Decel_Capability, The required value is controlled as Estimated_Max_Decel_Capability. ·Depending on the accel / brake pedal stroke, the requested acceleration may not be met. See 3.4.1.4 for More detail. Depending on the amount of accelerator or brake pedal operation, the vehicle may not respond to the requested acceleration. For details, see 3.3.1.4 ·When Pre-Collision system is activated simultaneously, minimum acceleration (maximum deceleration) is selected. If the Pre-Collision System is activated simultaneously, the minimum acceleration required by each system will be selected.

[0135] 3.3.2.5. Tire Turning Angle Command Requires front tire turning angle. Values [Table 7] Remarks ·Left is positive value(+). right is negative value(-). ·Available only when Autonomy_State = “Autonomous Mode” Only Autonomy_State = “Autonomous Mode” can be used ·The output of Estimated_Road_Wheel_Angle_Actual when the vehicle is going straight, is set to the reference value (0). The value output by Estimated_Road_Wheel_Angle_Actual when the vehicle is going straight is set as the reference value (0). ·This equests relative value of Estimated_Road_Wheel_Angle_Actual. (See 3.4.1.1 for details) Requests the relative value of Estimated_Road_Wheel_Angle_Actual (see 3.4.1.1 for details). ·The requested value is within Current_Road_Wheel_Angle_Rate_Limit. Request a steering angle value that does not exceed Current_Road_Wheel_Angle_Rate_Limit. ·The requested value may not be fulfilled depending on the steer angle by the driver. Depending on the amount of steering by the driver, the value may not be achieved.

[0136] 3.3.2.6. Autonomization Command Request to transition between manual mode and autonomy mode Values [Table 8] Remarks ·The mode may be able not to be transitioned to Autonomy mode. (eg In case that a failure occurs in the vehicle platform.)

[0137] Outputs [Table 9]

[0138] 3.3.3.1. Propulsion Direction Status Current shift range Current shift range Values [Table 10] Remarks ·When the shift range is indeterminate., this output is set to “Invalid Value ". If the shift range is indefinite, "Invalid value" is output. ·When the vehicle becomes the following status during VO mode, [Propulsion Direction Status] will turn to “P”. - [Longitudinal_Velocity] = 0 [km / h] - [Brake_Pedal_Position] < Threshold value (TBD) (in case of being determined that the pedal isn't depressed) - [1st_Left_Seat_Belt_Status] = Unbuckled - [1st_Left_Door_Open_Status] = Opened 3.3.3.2. Propulsion Direction by Driver Shift lever position by driver operation Shift lever position operated by the driver Values [Table 11] Remarks ·Output based on the lever position operated by driver When the driver operates the lever, it outputs according to the lever position. ·If the driver releases his hand of the shift lever, the lever returns to the central position and the output is set as “No Request”. When the driver releases the lever, the lever returns to its original position and outputs "No request" ·When the vehicle becomes the following status during NVO mode, [Propulsion Direction by Driver] will turn to “1(P)”. - [Longitudinal_Velocity] = 0 [km / h] - [Brake_Pedal_Position] < Threshold value (TBD) (in case of being determined that the pedal isn't depressed) - [1st_Left_Seat_Belt_Status] = Unbuckled - [1st_Left_Door_Open_Status] = Opened 3.3.3.3. Immobilization Status Output EPB and Shift-P status Outputs the state of EPB and shift P. Values <primary>

Table 12

Table 20

Table 21

Table 22

Table 44

Table 45

Table 46

Table 47

Table 48

Table 49

Table 50

Table 51

Table 52

Table 53

Table 63

Table 64

Table 67

Table 68

Table 69

Table 70

Table 71

Table 72

Table 73

Table 74

Table 75

Table 87

[0139] Toyota's MaaS Vehicle Platform Architecture Specification [Standard Edition #0.1] Revision History [Table 105] table of contents 1. General Concept 4 1.1. Purpose of this Specification 4 1.2. Target Vehicle Type 4 1.3. Target Electronic Platform 4 1.4. Definition of Term 4 1.5. Precaution for Handling 4 1.6. Overall Structure of MaaS 4 1.7. Adopted Development Process 6 1.8. ODD(Operational Design Domain) 6 2. Safety Concept 7 Outline 7 2.2. Hazard analysis and risk assessment 7 2.3. Allocation of safety requirements 8 2.4. Redundancy 8 3. Security Concept 10 Outline 10 3.2. Assumed Risks 10 3.3. Countermeasure for the risks 10 3.3.1. The countermeasure for a remote attack 11 3.3.2. The countermeasure for a modification 11 3.4. Handling of Retained Data Information 11 3.5. Vulnerability Response 11 3.6. Contract with the Operator 11 4. System Architecture 12 4.1. Outline 12 4.2. Physical LAN architecture (in-vehicle) 12 4.3. Power Supply Structure 14 5. Function Allocation 15 5.1. in a healthy situation 15 5.2. in a single failure 16 6. Data Collection 18 6.1. At event 18 6.2. Constantly 18 1. General Concept 1.1. Purpose of this Specification This document is an architecture specification of Toyota's MaaS Vehicle Platform and contains the outline of system in vehicle level. This document is an architectural specification for Toyota's Vehicle Platform and describes an overview of the vehicle-level system. 1.2. Target Vehicle Type This specification is applied to the Toyota vehicles with the electronic platform called 19ePF[ver.1 and ver.2]. The representative vehicle with 19ePF is shown as follows. e-Palette, Sienna, RAV4, and so on. This document applies to vehicles that use 19-electron power plants. Representative vehicles equipped with 19-electron power plants include the e-Palette, Sienna, and RAV4. 1.3. Definition of Term [Table 106] 1.4. Precaution for Handling This is an early draft of the document. All the contents are subject to change. Such changes are notified to the users. Please note that some parts are still TBD will be updated in the future. This book is an Early Draft version. Please note that the information may be subject to change. If there are any changes to the information, we will contact you separately. Also, since the detailed design is still in progress, there are some TBD items here and there, but we will update them accordingly. 2. Architectural Concept 2.1. Overall Structure of MaaS The overall structure of MaaS with the target vehicle is shown. The overall configuration of MaaS using the target vehicle is shown below (Figure 15). Vehicle control technology is being used as an interface for technology providers. Technology providers can receive open API such as vehicle state and vehicle control, necessary for development of automated driving systems. The target vehicles in this document are those that interface vehicle control technology to ADS operators. We will disclose this information as a source. ADS providers can use the vehicle status and vehicle control information required for developing autonomous driving systems as APIs. 2.2. Outline of system architecture on the vehicle The system architecture on the vehicle as a premise is shown. The prerequisite system configuration on the vehicle side is shown below (Figure 16). The target vehicle of this document will adopt the physical architecture of using CAN for the bus between ADS and VCIB. In order to realize each API in this document, the CAN frames and the bit assignments are shown in the form of "bit assignment chart" as a separate document. The vehicle covered by this document has a physical configuration in which the vehicle (VCIB) and ADS connection bus is configured with CAN. In order to realize each API in this document with CAN, separate CAN frames and data bit assignments are required. It is presented as a "bit assignment table." 2.3. Outline of power supply architecture on the vehicle The power supply srcitecture as a premise is shown as follows. The assumed power supply configuration is shown below (Figure 17). The blue colored parts are provided from an ADS provider. parts are provided from the VP. The blue part is installed under the responsibility of ADS, and the orange part is installed under the responsibility of VP. The power structure for ADS is isolated from the power structure for VP. Also, the ADS provider should install a redundant power structure isolated from the VP. 3. Safety Concept Overall safety concept The basic safety concept is shown as follows. The basic safety concepts are as follows: The strategy of bringing the vehicle to a safe stop when a failure occurs is shown as follows. Below is a strategy for safely stopping the vehicle even when an abnormality occurs (Figure 18). 1. After occurring a failure, the entire vehicle execute "detecting a failure" and "correcting an impact of failure" and then achieves the safety state 1. Once an abnormality occurs, "detect the abnormality" and "correct the effect of the abnormality" to achieve safe state 1. 2. Obeying on the instructions from the ADS, the entire vehicle stops in a safety space at a safety speed (assumed less than 0.2G). Follow the ADS instructions and stop in a safe place at a safe deceleration rate (assuming less than 0.2G). However, depending on a situation, the entire vehicle should happen a deceleration more than the above deceleration if needed. However, this does not apply if a deceleration greater than the above is necessary depending on the situation. 3. After stopping, in order to prevent to slip down, the entire vehicle achieves the safety state 2 by activating the immobilization system. After stopping, the vehicle immobilization system is activated to prevent the vehicle from rolling over, and the vehicle enters a safe state 2. Achieve this. [Table 107] See the separated document called "Fault Management" regarding notifiable single failure and expected behavior for the ADS. For information on single faults that can be notified to ADS and the behavior expected in such cases, please refer to the separate document "Fault Management." Redundancy The redundant functionalities with Toyota's MaaS vehicle is shown. Toyota's MaaS vehicles have the following redundant functions: Toyota's Vehicle Platform has the following redundant functionalities to meet the safety goals led from the functional safety analysis. Toyota's vehicle platforms have redundancy in the following functions to meet the safety goals derived from functional safety analysis. Redundant Braking Redundant Brakes Any single failure on the Braking System doesn't cause to lose braking functionality. However, depending on where the failure occurred in, the capability left might not be equivalent to the primary system's capability. In this case, the braking system is designed to prevent that the capability becomes to 0.3G or less. A single fault in the braking system will not result in loss of braking function. In some places, the performance may not be the same as that of the primary system. Even in such cases, the capability is designed to not fall below 0.3G. Redundant Steering Redundant Steering Any single failure on the Steering System doesn't cause to lose steering functionality. However, depending on where the failure occurred in, the capability left might not be equivalent to the primary system's capability. In this case, the steering system is designed to prevent that the capability becomes to 0.3G or less. A single failure within the steering system will not cause a loss of steering function. However, depending on the location of the failure, the steering system may not perform at the same level as the primary system. Even in such cases, the steering system is designed to ensure that capability does not fall below 0.3G. Redundant Immobilization Redundant vehicle fixing Toyota's MaaS vehicle has 2 immobilization systems. ie P lock and EPB. Therefore, any single failure of immobilization system doesn't cause to lose the immobilization capability. However, in the case of failure, maximum stationary slope angle is less steep than the systems are healthy. Toyota's MaaS vehicles have two independent systems, P-lock and EPB, for vehicle immobilization functions. Therefore, the vehicle immobilization function will not be lost in the event of a single failure. However, if a failure occurs, the maximum tilt angle that can be immobilized will be reduced compared to when two systems are used simultaneously. Redundant Power redundant power supply Any single failure on the Power Supply System doesn't cause to lose power supply functionality. However, in case of the primary power failure, the secondary power supply system keeps to supply power to the limited systems for a certain time. A single failure within the power supply system will not cause a loss of power supply functionality. However, if the primary power supply system fails, the secondary power supply system will continue to supply power to limited systems for a certain period of time. Redundant Communication Redundant Communication Any single failure on the Communication System doesn't cause to lose all the communication functionality. System which needs redundancy has physical redundant communication lines. For more detail imformation, see the chapter "Physical LAN architecture (in-vehicle)”. A single failure in the communication system will not cause the entire communication function to fail. For systems that require redundancy, communication lines are physically redundant. For details, see the in-vehicle physical LAN architecture. See 4. Security Concept Outline Regarding security, Toyota's MaaS vehicle adopts the security document issued by Toyota as an upper document. Regarding security, the security measures standard issued by 46F will be used as the upper document. . none 4.2. Assumed Risks The entire risk includes not only the risks assumed on the base e-PF but also the risks assumed for the Autono-MaaS vehicle. Not only the threats expected from the electronic platform on which it is based, but also the threats inherent to Autono-MaaS vehicles The sum of these is defined as the total anticipated threat. The entire risk is shown as follows. The threats assumed in this document are as follows: [Remote Attack] - To vehicle Spoofing the center ECU Software Alteration DoS Attack Sniffering - From vehicle Spoofing the other vehicle ·Software Alternation for a center or a ECU on the other vehicle ·DoS Attack to a center or other vehicle Uploading illegal data [Modification] Illegal Reprogramming Setting up an illegal ADK ·Installation of an unauthenticated product by a customer 4.3. Countermeasure for the risks The countermeasure of the above assumed risks is shown as follows. The response policy for the anticipated threats mentioned above is shown below. 4.3.1. The countermeasure for a remote attack The countermeasure for a remote attack is shown as follows. Countermeasures against remote attacks are listed below. Since the autonomous driving kit communicates with the operator's center, it is necessary to ensure end-to-end security. In addition, since it has the function of issuing driving control instructions, it is necessary to have multi-layered defense within the autonomous driving kit. A secure microcomputer and security chip should be used within the autonomous driving kit to provide sufficient security as the first layer of access from outside. It also has a second layer of security by using a Cure microcomputer and security chip. (In the autonomous driving kit, the first layer of defense prevents direct intrusion from the outside, and the second layer of defense prevents direct intrusion from the outside.) (having multiple layers of defense, such as a layer of defense and a second layer of defense) 4.3.2. The countermeasure for a modification The countermeasure for a modification is shown as follows. Countermeasures against modifications are shown below. To prepare for fake autonomous driving kits, implement device authentication and message authentication. Measures will be taken to prevent tampering when storing keys, and key sets will be changed for each vehicle and autonomous driving kit pair. Alternatively, include in the contract that the operator will adequately manage the system to prevent the installation of unauthorized kits. In preparation for Autono-MaaS vehicle users installing counterfeit products, the operating company will The contract will include a provision to prevent unauthorized access. When applying it to an actual vehicle, a threat analysis is also conducted, and the autonomous driving kit will have been fully adapted to the latest vulnerabilities at the time of LO. 5. Function Allocation 5.1. In a healthy situation The allocation of representative functionalities is shown as below. The layout of typical functions is shown below (Figure 19). [Function allocation] [Table 108] 5.2. in a single failure See the separated document called "Fault Management" regarding notifiable single failure and expected behavior for the ADS. For information on single faults that can be notified to ADS and the behavior expected in such cases, please refer to the separate document "Fault Management."

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

[0141] 10 vehicle, 100 vehicle body, 110 vehicle control interface, 111A, 111B vehicle control interface box (VCIB), 120 vehicle platform (VP), 121A, 121B Brake system, 122A, 122B Steering system, 123A EPB system, 123B P-Lock system, 124 Propulsion system, 125 PCS system, 126 Body system, 127 Wheel speed sensor, 128A, 128B Pinion angle sensor, 129 Camera / radar, 190 DCM, 200 Autonomous driving kit (ADK), 210 Computer, 230 HMI, 260 Recognition sensor, 270 Attitude sensor, 290 Sensor cleaner, 500 Data server, 600 Mobility service platform (MSPF), 700 Autonomous driving related mobility services.< / secondary> < / primary>

Claims

1. A vehicle configured to be able to mount an automated driving system, a vehicle platform that controls the vehicle in accordance with commands from the automated driving system; a vehicle control interface that interfaces between the vehicle platform and the automated driving system; The vehicle platform determines the rotation direction of the wheels based on pulses input from wheel speed sensors provided on the wheels; The vehicle control interface outputting a signal indicating the determined rotation direction to the automatic driving system; further outputting a signal indicating the direction of travel of the vehicle to the automated driving system; When a certain period of time has elapsed in a state where the speeds of all vehicles are zero, a signal indicating "Standstill" is output to the automated driving system as a signal indicating the direction of travel of the vehicles, receiving a Standstill Command from the automated driving system requesting brake hold control; When the brake hold control is completed in response to the Standstill Command, a signal indicating that the brake is being held is output to the automated driving system, and when the vehicle platform receives the Standstill Command from the automated driving system via the vehicle control interface, the vehicle platform executes the brake hold control on the condition that the vehicle is stopped, The vehicle control interface receives an Acceleration Command indicating a deceleration request from the automated driving system from the time the Standstill Command is received until the vehicle control interface outputs a signal indicating that the brakes are being held.

2. The vehicle control interface When the rotation direction of the wheel is determined to be a rotation direction that moves the vehicle forward, a signal indicating "Forward" is output to the automatic driving system; The vehicle according to claim 1 , wherein when the rotation direction of the wheels is determined to be a rotation direction that causes the vehicle to move backward, a signal indicating "Reverse" is output to the automatic driving system.

3. A vehicle as described in claim 1 or claim 2, wherein the vehicle control interface outputs a signal indicating an invalid value to the autonomous driving system if the rotation direction of the wheel cannot be determined.

4. A vehicle as described in claim 2 or claim 3, wherein after the vehicle is started, the vehicle control interface outputs a signal indicating Forward to the autonomous driving system until the direction of rotation of the wheels is determined.

Images