Keys and electric vehicles
By integrating a key with virtual mobility information and communication capabilities, the electric vehicle simulates the driving environment and sounds of other vehicles, addressing the lack of realism in existing systems and enhancing the user experience.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- TOYOTA JIDOSHA KK
- Filing Date
- 2024-12-27
- Publication Date
- 2026-07-09
AI Technical Summary
Existing techniques for simulating the operating environment of virtual mobility in electric vehicles lack the necessary information transmission methods to enhance the sense of realism for users.
A key for starting an electric vehicle is equipped with a storage device containing virtual mobility information and a communication device to transmit this information to the vehicle, allowing the vehicle's processors to simulate the driving environment and generate corresponding sounds, enhancing the user's sense of realism.
The solution enables a more immersive experience by transmitting virtual mobility information directly through the key, allowing the electric vehicle to simulate the driving environment and sounds of other vehicles, thereby increasing the sense of realism for the user.
Smart Images

Figure 2026115227000001_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to a key for starting an electric vehicle capable of simulating an operating environment of target virtual mobility and an electric vehicle that can be started by a starting operation using the key.
Background Art
[0002] Techniques for vehicles that simulate virtual mobility are known. For example, Patent Document 1 discloses a technique for simulating the driving characteristics and sounds of a manual transmission vehicle. With this technique, a driver can obtain a sense of presence as if driving a manual transmission vehicle.
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] Techniques for simulating an operating environment of virtual mobility in an electric vehicle are known. There is room for improvement in the method of providing an electric vehicle with information necessary for simulating the operating environment of virtual mobility.
[0005] One object of the present disclosure is to provide a technique for transmitting, using a key for starting an electric vehicle, information necessary for the electric vehicle to simulate an operating environment of virtual mobility.
Means for Solving the Problems
[0006] A first aspect relates to a key for starting an electric vehicle capable of simulating an operating environment of target virtual mobility. The key includes a storage device and a communication device. The storage device is configured to include virtual mobility information. Virtual mobility information includes information necessary to simulate the driving environment of one or more virtual mobility devices, including the target virtual mobility device. The communication device is configured to transmit virtual mobility information to the electric vehicle.
[0007] The second perspective relates to electric vehicles that can be started using a key-based ignition operation. The electric vehicle comprises one or more processors that simulate the driving environment of the target virtual mobility, and a communication device. One or more processors, The virtual mobility information held by one or more keys is obtained via a communication device. Based on the acquired virtual mobility information, the driving environment of the target virtual mobility device is simulated. It is configured in this way. Virtual mobility information includes information necessary to simulate the driving environment of one or more virtual mobility devices, including the target virtual mobility device. [Effects of the Invention]
[0008] According to the configuration described herein, the virtual mobility information necessary for the electric vehicle to simulate the target virtual mobility is transmitted from the key. As a result, the means for starting the electric vehicle and the means for transmitting the virtual mobility information are the same, allowing the electric vehicle user to experience a greater sense of realism. [Brief explanation of the drawing]
[0009] [Figure 1] This is a conceptual diagram showing a vehicle and vehicle management system according to this embodiment. [Figure 2] This is a conceptual diagram illustrating the "simulation mode" provided by the vehicle management system according to this embodiment. [Figure 3] This block diagram shows an example of a functional configuration related to the generation and output of simulated sounds for virtual mobility. [Figure 4] This block diagram shows another example of a functional configuration related to the generation and output of simulated sounds for virtual mobility. [Figure 5] It is a schematic diagram showing the process in which the simulation mode using the physical keys is started. [Figure 6] It is a flowchart regarding the process of starting the simulation mode using the physical keys. [Figure 7] It is a schematic diagram showing the relationship between the vehicle start operation and the simulation mode. [Figure 8] It is a flowchart when the simulation mode is started in conjunction with the vehicle start operation. [Figure 9] It is a schematic diagram explaining the specified operation. [Figure 10] It is a schematic diagram showing the case where the user has the first physical key and the second physical key. [Figure 11] It is a flowchart showing the switching process of the target virtual mobility. [Figure 12] It is a block diagram showing a configuration example of the vehicle and the physical keys. [Figure 13] It is a block diagram showing a first configuration example of the power control system of the electric vehicle according to the present embodiment. [Figure 14] It is a diagram showing the MT vehicle model included in the manual mode torque calculation unit. [Figure 15] It is a diagram showing a comparison between the torque characteristics of an electric motor realized by motor control using an MT vehicle model and the torque characteristics of an electric motor realized by normal motor control as an electric vehicle. [Figure 16] It is a block diagram showing a second configuration example of the power control system of the electric vehicle according to the present embodiment.
Embodiments for Carrying Out the Invention
[0010] Embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0011] 1. Vehicle and Vehicle Management System Figure 1 is a conceptual diagram showing a vehicle 10 and a vehicle management system 100 according to this embodiment. For example, the vehicle 10 is an electric vehicle that uses an electric motor 44 as its driving power source. Examples of electric motors 44 include brushless DC motors and three-phase AC synchronous motors. As another example, the vehicle 10 may be an engine-powered vehicle that uses an internal combustion engine as its driving power source.
[0012] Vehicle 10 is equipped with various sensors 11. These sensors 11 detect the driving state of vehicle 10. Examples of sensors 11 include an accelerator position sensor, a brake position sensor, a steering angle sensor, a steering torque sensor, a wheel speed sensor, an acceleration sensor, a rotational speed sensor, a position sensor, and a recognition sensor. The accelerator position sensor detects the amount of operation of the accelerator pedal. The brake position sensor detects the amount of operation of the brake pedal. The steering angle sensor detects the steering angle of the steering wheel. The steering torque sensor detects the steering torque of the steering wheel. The wheel speed sensor detects the rotational speed of the wheels of vehicle 10. The acceleration sensor detects the lateral and longitudinal acceleration of vehicle 10. The rotational speed sensor detects the rotational speed of the electric motor 44. The position sensor detects the position of vehicle 10. An example of a position sensor is a GNSS (Global Navigation Satellite System) sensor. The recognition sensor is a sensor for recognizing (detecting) the surrounding conditions of vehicle 10. Examples of recognition sensors include cameras, LiDAR (Light Detection and Ranging), radar, and others.
[0013] Furthermore, the vehicle 10 is equipped with one or more speakers 70. For example, the speaker 70 is an in-vehicle speaker that outputs sound into the interior of the vehicle 10. In another example, the speaker 70 may be an exterior speaker that outputs sound outside the vehicle 10. The vehicle 10 may have both in-vehicle and exterior speakers.
[0014] The vehicle management system 100 is applied to such a vehicle 10 and manages the vehicle 10. The entire vehicle management system 100 may be installed on the vehicle 10. As another example, at least a part of the vehicle management system 100 may be contained in an external management server outside of the vehicle 10. In that case, the vehicle management system 100 may manage the vehicle 10 remotely. As yet another example, the vehicle management system 100 may be distributed between the vehicle 10 and the management server.
[0015] Generally speaking, the vehicle management system 100 includes one or more processors 101 (hereinafter simply referred to as processor 101) and one or more storage devices 102 (hereinafter simply referred to as storage devices 102). The processor 101 performs various processes. Examples of processors 101 include general-purpose processors, application-specific processors, CPUs (Central Processing Units), GPUs (Graphics Processing Units), ASICs (Application Specific Integrated Circuits), FPGAs (Field-Programmable Gate Arrays), integrated circuits, conventional circuits, and / or combinations thereof. The processor 101 can also be called circuitry or processing circuitry. Circuitry is hardware programmed to realize the described functions, or hardware that performs those functions. The storage devices 102 store various information. Examples of storage devices 102 include volatile memory, non-volatile memory, HDDs (Hard Disk Drives), SSDs (Solid State Drives), etc. The functions of the vehicle management system 100 are realized through the cooperation of the processor 101 and the storage devices 102.
[0016] One or more vehicle management programs 105 (hereinafter simply referred to as vehicle management program 105) are computer programs executed by a processor 101. The functions of the vehicle management system 100 may be realized through the cooperation of the processor 101 executing the vehicle management program 105 and a storage device 102. The vehicle management program 105 is stored in the storage device 102. Alternatively, the vehicle management program 105 may be recorded on a computer-readable recording medium.
[0017] 2. Simulation mode that simulates virtual mobility Figure 2 is a conceptual diagram illustrating the "simulation mode" provided by the vehicle management system 100 according to this embodiment. The simulation mode is a mode in which "virtual mobility" is simulated (reproduced) in the vehicle 10. For example, the virtual mobility to be simulated is a vehicle of a different type from vehicle 10. Other examples include trains, airplanes, etc., as the virtual mobility to be simulated.
[0018] For example, if vehicle 10 is an electric vehicle, the vehicle management system 100 may simulate (reproduce) the "driving characteristics" of other vehicles in that electric vehicle. The other vehicle to be simulated (virtual mobility) may be another electric vehicle or a manual transmission vehicle (MT vehicle). For example, the vehicle management system 100 may simulate (reproduce) the driving characteristics of an MT vehicle in an electric vehicle. Details of the "MT mode (manual mode)" for simulating the driving characteristics of an MT vehicle in an electric vehicle will be explained in Section 7 later. In any case, the vehicle management system 100 manages virtual mobility model data that represents a model of virtual mobility and reproduces the driving characteristics of virtual mobility based on that virtual mobility model data. As a result, the driver of vehicle 10 can get the feeling that they are driving a virtual mobility vehicle.
[0019] It is also possible to switch between the simulated virtual mobility devices. Specifically, multiple types of virtual mobility model data are provided for multiple types of virtual mobility devices. The user of vehicle 10 specifies their preferred virtual mobility device, and the vehicle management system 100 reproduces the driving characteristics using the virtual mobility data for the virtual mobility device specified by the user. This allows the driver of vehicle 10 to feel as if they are driving their preferred virtual mobility device.
[0020] As another example, the vehicle management system 100 may simulate (reproduce) the "sound" of the virtual mobility in the vehicle 10. That is, the vehicle management system 100 may generate a simulated sound that simulates the sound of the virtual mobility and output the simulated sound through the speaker 70 of the vehicle 10. Typically, the sound to be simulated (reproduced) is the driving sound or running sound of the virtual mobility. The virtual mobility to be simulated is, for example, a vehicle. The vehicle to be simulated may be a gasoline-powered car or an electric vehicle. For example, if vehicle 10 is an electric vehicle and the virtual mobility is a gasoline-powered car, the vehicle management system 100 will simulate (reproduce) the engine sound of the gasoline-powered car in the electric vehicle. Note that the virtual mobility to be simulated is not limited to a vehicle, but may also be a train, an airplane, etc.
[0021] Generally speaking, the driving characteristics and sounds of virtual mobility can be said to represent the environment while driving the virtual mobility. Therefore, the driving characteristics and sounds of virtual mobility are included in the concept of the "driving environment" of virtual mobility. In other words, in simulation mode, the vehicle management system 100 simulates the driving environment of virtual mobility in vehicle 10 based on virtual mobility model data. When the vehicle management system 100 simulates the driving environment of virtual mobility in vehicle 10, as a result, vehicle 10 also simulates the drivability of virtual mobility 30. In other words, "the vehicle management system 100 simulating the driving environment of virtual mobility in vehicle 10" and "vehicle 10 simulating the driving environment of virtual mobility" are equivalent.
[0022] The following provides a more detailed explanation of the generation and output of simulated sounds that mimic the sounds of virtual mobility. For the purposes of this explanation, we will consider a simulated engine sound that mimics the engine sound of a gasoline-powered vehicle as an example. However, this disclosure is applicable to other sounds as well. For generalization purposes, "simulated engine sound" should be read as "simulated sound" in the following explanation.
[0023] Figure 3 is a block diagram showing an example of a functional configuration related to the generation and output of simulated sounds for virtual mobility. The vehicle management system 100 includes, as functional blocks, a driving state acquisition unit 110, a sound source data management unit 120, a sound generation unit 130, and an output unit 140. These functional blocks may be realized, for example, through the cooperation of a processor 101 that executes a vehicle management program 105 and a storage device 102.
[0024] The driving state acquisition unit 110 acquires driving state information DRV indicating the driving state of the vehicle 10. The driving state information DRV includes information about the driver's driving operations, information about the vehicle 10's driving state, information about the surrounding conditions of the vehicle 10, etc. Typically, the driving state information DRV includes information detected by sensors 11 mounted on the vehicle 10. For example, the driving state information DRV includes the amount of accelerator pedal operation (accelerator opening), the amount of brake pedal operation (brake opening), steering angle, steering speed, steering torque, wheel speed, vehicle speed, longitudinal acceleration, lateral acceleration, rotational speed of the electric motor 44, etc. The driving state information DRV may also include the position of the vehicle 10. The driving state information DRV may also include the surrounding conditions of the vehicle 10 recognized (detected) by the recognition sensors.
[0025] Furthermore, the driving state information DRV includes the virtual engine rotation speed Ne. Here, it is assumed that the vehicle 10 uses a virtual engine as the power source for driving. The virtual engine rotation speed Ne is the rotation speed of the virtual engine when it is assumed that the vehicle 10 is driven by the virtual engine. For example, the driving state acquisition unit 110 may calculate the virtual engine rotation speed Ne so that it increases as the wheel speed increases. Also, if the vehicle 10 has a manual mode (MT mode) as described later, the driving state acquisition unit 110 may calculate the virtual engine rotation speed Ne in manual mode based on the wheel speed, the overall reduction ratio, and the slip ratio of the virtual clutch. Details of the method for calculating the virtual engine rotation speed Ne in manual mode will be described later.
[0026] The sound source data management unit 120 stores and manages basic sound source data 200 used to generate simulated engine sounds. The sound source data management unit 120 is mainly implemented by one or more storage devices 102. Typically, the basic sound source data 200 includes multiple types of sound source data. These multiple types of sound source data include, for example, sound source data for sounds caused by engine combustion (for low, medium, and high rotational speeds), sound source data for sounds caused by the drive system such as gears (for low, medium, and high rotational speeds), noise sound source data, event sound (e.g., grinding noise, engine stall sound) sound source data, etc. Each sound source data is pre-generated through simulations based on engine models and vehicle models of engine-powered vehicles. Each sound source data is flexibly adjustable. That is, at least one of the sound pressure and frequency of the sound indicated by the sound source data can be flexibly adjusted.
[0027] The sound generation unit 130 (sound simulator) is a simulator that generates a simulated engine sound. The sound generation unit 130 acquires at least a portion of the driving state information DRV from the driving state acquisition unit 110. In particular, the sound generation unit 130 acquires information on the virtual engine rotation speed Ne and vehicle speed from the driving state acquisition unit 110. The sound generation unit 130 also reads the basic sound source data 200 from the sound source data management unit 120. Then, the sound generation unit 130 generates a simulated engine sound corresponding to the driving state of the vehicle 10 (virtual engine rotation speed Ne and vehicle speed) by combining one or more sound source data included in the basic sound source data 200. The engine sound data ES is data that indicates the generated simulated engine sound.
[0028] It should be noted that the generation of simulated engine sounds is a well-known technique and is not particularly limited in this embodiment. For example, the simulated engine sound may be generated using a well-known engine sound simulator used in games, etc. Alternatively, one could have a map of virtual engine rotation speed Ne-frequency and a map of virtual engine torque-sound pressure, and increase or decrease the frequency of the simulated engine sound in proportion to the virtual engine rotation speed Ne, and increase or decrease the sound pressure in proportion to the virtual engine torque.
[0029] The output unit 140 receives engine sound data ES generated by the sound generation unit 130. Based on the engine sound data ES, the output unit 140 outputs a simulated engine sound through the speaker 70. This allows the user (driver) of the vehicle 10 to feel as if they are driving a virtual mobility device.
[0030] The vehicle management system 100 may further include an HMI unit 150. The HMI (human machine interface) relays information between the user of the vehicle 10 and the vehicle management system 100. The HMI unit 150 includes at least an input device and an output device. Examples of input devices include a touch panel, switches, buttons, a microphone, etc. Examples of output devices include a display device such as a display or indicator, and a speaker 70. The user of the vehicle 10 can generate a simulated engine sound and switch the output ON / OFF via the input device.
[0031] Figure 4 is a block diagram showing another example of a functional configuration related to the generation and output of simulated sounds for virtual mobility. In the example shown in Figure 4, the sound source data management unit 120 stores and manages multiple types of basic sound source data 200 (200-A, 200-B, 200-C, etc.) corresponding to each of the multiple types of virtual mobility (A, B, C, etc.). In other words, the sound source data management unit 120 stores and manages basic sound source data 200 for each virtual mobility. Each basic sound source data 200 is pre-generated based on the engine model and vehicle model of the corresponding virtual mobility.
[0032] The user of vehicle 10 can specify a simulated target from among several types of virtual mobility. Specifically, the sound source data management unit 120 or the sound generation unit 130 presents the user with several types of virtual mobility through the HMI unit 150 (display device). The user uses the HMI unit 150 (input device) to select one of the several types of virtual mobility. The sound generation unit 130 obtains one of several types of basic sound source data 200 from the sound source data management unit 120 that corresponds to the virtual mobility specified by the user. Then, the sound generation unit 130 generates a simulated engine sound using the obtained basic sound source data 200 (e.g., basic sound source data 200-B corresponding to virtual mobility B). This allows the driver of vehicle 10 to feel as if they are driving their preferred virtual mobility. In addition, the user of vehicle 10 can switch the simulated engine sound output from speaker 70 using the display device.
[0033] 3. Transition to simulated mode using a key. In this embodiment, the vehicle management system 100 may utilize a "key" to activate the vehicle 10 in order to provide the user of the vehicle 10 with a stronger sense of presence (a feeling as if they were riding in a virtual mobility device). The user can activate the vehicle 10 by using this key. This key can be used to activate the vehicle 10 by inserting it into a keyhole provided on the vehicle 10 and turning it, for example, like a key for a conventional vehicle. Hereinafter, a key of this type that is inserted into a keyhole will be referred to as a "physical key 20". In addition to being activated by the physical key 20, the vehicle 10 may also be activated by a method such as a push-button start switch, which is currently the mainstream method. Furthermore, the physical key 20 may also have a function to unlock or lock the vehicle 10 using radio waves (a so-called smart entry key function).
[0034] The physical key 20 contains "virtual mobility information 40". The virtual mobility information 40 contains information necessary to simulate the driving environment of the virtual mobility 30. For example, the virtual mobility information 40 is information that identifies the vehicle type and ID of the virtual mobility 30. The specific configuration of the vehicle 10 and the physical key 20 will be described later.
[0035] In simulation mode, the vehicle management system 100 simulates the driving environment of virtual mobility 30 in vehicle 10 based on virtual mobility information 40. When the vehicle management system 100 simulates the driving environment of virtual mobility 30 in vehicle 10, as a result, vehicle 10 simulates the drivability of virtual mobility 30. In other words, "the vehicle management system 100 simulating the driving environment of virtual mobility 30 in vehicle 10" and "vehicle 10 simulating the driving environment of virtual mobility 30" are equivalent. Furthermore, in the following explanation, "simulating the driving environment of virtual mobility 30" may be simply referred to as "simulating virtual mobility 30." Also, in the following explanation, the virtual mobility 30 that is the subject of the simulation may be referred to as the "target virtual mobility."
[0036] Figure 5 is a schematic diagram showing the process of initiating a simulation mode using a physical key. The diagram illustrates a situation where a user with a physical key 20 approaches the vehicle 10 to use it. The physical key 20 contains virtual mobility information 40, which is information necessary for the vehicle 10 to simulate the driving environment of virtual mobility 30. The vehicle 10 communicates with the physical key 20 to obtain the virtual mobility information 40.
[0037] For example, vehicle 10 can communicate wirelessly with physical key 20 within communication range CR. Communication range CR is the range in which vehicle 10 and physical key 20 can communicate wirelessly with each other. In other words, communication range CR is the range in which vehicle 10 and physical key 20 can establish wireless communication. Communication range CR is determined by the wireless communication method between vehicle 10 and physical key 20, the wireless communication performance of vehicle 10, and the wireless communication performance of physical key 20. Examples of wireless communication methods include near-field communication (NFC) and ultra-wideband (UWB). Typically, communication range CR extends outside of vehicle 10.
[0038] Vehicle 10 acquires virtual mobility information 40 through communication with a physical key 20. The vehicle management system 100 acquires the virtual mobility information 40 obtained through communication between vehicle 10 and the physical key 20. The vehicle management system 100 may acquire the virtual mobility information 40 when the physical key 20 is outside of vehicle 10. Then, the vehicle management system 100 starts a simulation mode based on the virtual mobility information 40 obtained from the physical key 20. Upon starting the simulation mode, vehicle 10 simulates virtual mobility 30. That is, in the simulation mode, vehicle 10 simulates the driving environment (driving characteristics and sound) of virtual mobility 30.
[0039] When the vehicle management system 100 obtains virtual mobility information 40 from a physical key 20 located outside the vehicle, it can start the calculations necessary to initiate the simulation mode earlier, resulting in a smoother start to the simulation mode. For example, the vehicle management system 100 can initiate the simulation mode based on the virtual mobility information 40 even before the user possessing the physical key 20 boards the vehicle 10. For example, when the user opens and closes the door to board the vehicle 10, the vehicle management system 100 can output a door opening and closing sound corresponding to the virtual mobility 30 via the speaker 70. This allows the user to experience a door opening and closing sound of their choice.
[0040] Figure 6 is a flowchart showing the process for starting a simulated mode using the physical key 20.
[0041] In step S110, the vehicle management system 100 determines whether the vehicle 10 and the physical key 20 can communicate. Specifically, if the physical key 20 is within the communication range CR, the two can communicate. For example, if the vehicle 10 and the physical key 20 establish wireless communication, the vehicle management system 100 determines that the vehicle 10 and the physical key 20 can communicate. If the vehicle 10 and the physical key 20 can communicate (step S110; Yes), the process proceeds to step S120. If the vehicle 10 and the physical key 20 cannot communicate (step S110; No), the process repeats step S110.
[0042] In step S120, the vehicle 10 obtains virtual mobility information 40 necessary to simulate virtual mobility 30 from the physical key 20 via communication. The vehicle management system 100 obtains the virtual mobility information 40 obtained through communication between the vehicle 10 and the physical key 20 in this way. The process then proceeds to step S130.
[0043] In step S130, the vehicle management system 100 starts a simulation mode. For example, the vehicle management system 100 obtains virtual mobility model data corresponding to the virtual mobility information 40 from an external management server and starts the simulation mode using the virtual mobility model data. Alternatively, the virtual mobility information 40 may include the virtual mobility model data itself. However, due to data volume constraints, it is preferable that the information transmitted from the physical key 20 is limited to vehicle type and ID, and that the actual model data necessary for starting the simulation mode is provided by an external server. The process then proceeds to step S140.
[0044] In step S140, the vehicle management system 100 determines whether the termination condition for the simulation mode is met. The termination condition for the simulation mode is, for example, that a switch that determines whether the simulation mode is enabled or disabled becomes disabled. Such a switch may be a physical switch or operated via a touch panel. This switch function is implemented by an HMI unit 150 operated by the user. If the termination condition for the simulation mode is met (step S140; Yes), the process ends. On the other hand, if the termination condition for the simulation mode is not met (step S140; No), the simulation mode is maintained. In other words, the process repeats step S140 until the termination condition is met.
[0045] The vehicle management system 100 may start a simulated mode in conjunction with the vehicle 10's startup operation. Figure 7 is a schematic diagram showing the relationship between the vehicle 10's startup operation and the simulated mode. This figure illustrates the situation where the vehicle management system 100 acquires virtual mobility information 40 from the physical key 20, and then the user starts the vehicle 10. This startup operation may be performed using the physical key 20 or by operating the start switch. The vehicle management system 100 starts the simulated mode in conjunction with the vehicle 10's startup. In conjunction with the start of the simulated mode, the vehicle management system 100 may output a simulated startup sound, which simulates the startup sound of the virtual mobility 30, through the speaker 70. For example, if the virtual mobility 30 is an engine-powered vehicle, the vehicle management system 100 outputs the sound of its engine starting.
[0046] Figure 8 is a flowchart showing the case when the simulation mode is started in conjunction with the start operation of vehicle 10. The difference from the flowchart shown in Figure 6 is that step S125 is inserted between step S120 and step S130. In step S125, the vehicle management system 100 determines whether or not the start operation of vehicle 10 has been performed. If it is determined that the start operation of vehicle 10 has been performed (step S125; Yes), the vehicle management system 100 proceeds to step S130. If it is determined that the start operation of vehicle 10 has not been performed (step S125; No), the vehicle management system 100 repeats step S125.
[0047] When the simulation mode is started in conjunction with the vehicle 10's startup operation, the user can experience a stronger sense of realism. In particular, when the startup operation is performed using the physical key 20, the user can feel as if they are starting the virtual mobility 30 itself with the key corresponding to the virtual mobility 30. When a simulated startup sound of the virtual mobility 30 is output in conjunction with the startup operation using the physical key 20, the user can experience an even more pronounced sense of realism in driving the virtual mobility 30.
[0048] In the example shown in Figure 8, the virtual mobility information 40 is already obtained at step S120. Therefore, the vehicle management system 100 may perform the calculations necessary to start the simulation mode based on the virtual mobility information 40 before the startup operation (step S125). This makes the start of the simulation mode smoother.
[0049] 4.Specified operation 4-1. Key specification operation and HMI specification operation In simulation mode, the virtual mobility 30 that is the subject of simulation is hereinafter referred to as the "target virtual mobility." The target virtual mobility may be specified by a "specification operation" performed by the user. Figure 9 is a schematic diagram illustrating the specification operation. The specification operation includes a "key specification operation," which is the operation of starting the vehicle 10 with a physical key 20, and an "HMI specification operation," which is the operation of operating the HMI unit 150 provided in the vehicle 10 to specify it.
[0050] The key assignment operation is an operation to specify a target virtual mobility based on the virtual mobility information 40 contained in the physical key 20 used to start the vehicle 10. In this case, the virtual mobility 30 specified in the virtual mobility information 40 contained in the physical key 20 used to start the vehicle 10 becomes the target virtual mobility. The key assignment operation is also a startup operation to start the vehicle 10, and the simulation mode starts when the vehicle 10 is started with the physical key 20. For example, the first physical key contains first virtual mobility information for simulating the driving environment of the first virtual mobility. When a startup operation using the first physical key is performed, the vehicle management system 100 designates the first virtual mobility as the target virtual mobility and simulates the driving environment of the first virtual mobility based on the first virtual mobility information. The mode that simulates the target virtual mobility specified by the key assignment operation is specifically called the "key assignment simulation mode".
[0051] The HMI designation operation is an operation in which the user designates a target virtual mobility by operating the HMI unit 150. As an example of the HMI designation operation, the vehicle management system 100 displays multiple types of virtual mobility on a touch panel (included in the HMI unit 150), and the user designates a target virtual mobility from among them. The HMI designation operation may be performed by a user terminal owned by the user (e.g., smartphone, tablet, etc.). Alternatively, the HMI designation operation may be performed by voice input using a microphone. Furthermore, the HMI designation operation may be performed by a physical switch provided in the vehicle 10. The physical switch may be dedicated to the HMI designation operation, or it may be implemented by operating an existing mechanism (shift lever, shift button, etc.) in a specific manner. Also, if the vehicle 10 has an MT mode as described later, the HMI designation operation may be performed by operating a device (lever, paddle, pedal, etc.) used for operating the MT mode. Thus, the HMI unit 150 may include input devices provided in the vehicle 10, or it may include the user's user terminal. HMI specification operations are operations input via the HMI unit 150. Note that HMI specification operations are different from the startup operations that start the vehicle 10, and therefore the vehicle 10 will not start as a result of HMI specification operations. The mode that simulates the target virtual mobility specified by the HMI specification operation is specifically called the "HMI specification simulation mode." Note that if the target virtual mobility is the same, there is no difference in the simulated driving environment between the key specification simulation mode and the HMI specification simulation mode.
[0052] 4-2. Multiple Types of Virtual Mobility Let's consider a scenario where the vehicle management system 100 acquires virtual mobility information 40 corresponding to multiple types of virtual mobility 30. Figure 10 is a schematic diagram showing the case where the user has a first physical key 201 and a second physical key 202. The first physical key 201 contains first virtual mobility information 401, which is information necessary for the vehicle management system 100 to simulate the first virtual mobility 301. Similarly, the second physical key 202 contains second virtual mobility information 402, which is information necessary for the vehicle management system 100 to simulate the second virtual mobility 302. In this case, the vehicle management system 100 acquires the first virtual mobility information 401 from the first physical key 201 and the second virtual mobility information 402 from the second physical key 202. In this state, the target virtual mobility to be simulated has not been identified, so the vehicle management system 100 cannot start the simulation mode. Therefore, when the vehicle management system 100 acquires virtual mobility information 40 corresponding to multiple types of virtual mobility 30, the specified operation is effective in starting the simulation mode.
[0053] In the example shown in Figure 10, there are four possible patterns for the specified operation. <1> Designation of the first virtual mobility 301 by the first physical key 201 <2> Designation of the second virtual mobility 302 by the second physical key 202 <3> Designation of the first virtual mobility 301 by the HMI unit 150 <4> Designation of the second virtual mobility 302 by HMI unit 150
[0054] It is also possible to switch the target virtual mobility by specifying an operation. Switching the target virtual mobility is done as follows:
[0055] The operation to switch from a target virtual mobility specified by a key assignment operation to another target virtual mobility using a physical key 20 is performed by swapping the physical key 20 (corresponding to arrow SW1 in Figure 10). For example, suppose the vehicle management system 100 is currently simulating the first virtual mobility 301 through a key assignment operation using the first physical key 201. In this case, the target virtual mobility can be switched from the first virtual mobility 301 to the second virtual mobility 302 by removing the first physical key 201 from the keyhole and inserting (turning) the second physical key 202 into the keyhole. To switch the target virtual mobility from the second virtual mobility 302 to the first virtual mobility 301, the reverse operation is performed. In other words, the target virtual mobility can be switched by performing a vehicle 10 startup operation using a physical key 20 containing different virtual mobility information 40. Since inserting and removing the physical key 20 involves starting and stopping the vehicle 10, the timing at which this key swapping operation can be performed is limited. For example, when vehicle 10 is parked and in the parking range, the system is designed to allow the key to be swapped. The same applies when switching to a target virtual mobility specified by an HMI operation using a physical key 20 (corresponding to arrow SW2 in Figure 10).
[0056] The operation to switch from a target virtual mobility specified by an HMI specification operation to another target virtual mobility via an HMI specification operation is performed via the HMI unit 150 (corresponding to arrow SW3 in Figure 10). For example, suppose that the first virtual mobility 301 is currently specified as the target virtual mobility by an HMI specification operation. In this case, the target virtual mobility can be switched from the first virtual mobility 301 to the second virtual mobility 302 by selecting the second virtual mobility 302 via an HMI specification operation. To switch the target virtual mobility from the second virtual mobility 302 to the first virtual mobility 301, the reverse operation is performed. In other words, the target virtual mobility can be switched by specifying a different virtual mobility via an HMI specification operation. Note that since the HMI specification operation does not involve starting or stopping the vehicle 10, the timing of the switch is not particularly limited. For example, the user can switch the target virtual mobility at any time by operating the touchscreen, using voice input, or operating a physical switch. The same applies when switching the target virtual mobility specified by a key assignment operation using the HMI unit 150 (corresponding to arrow SW4 in Figure 10).
[0057] In general, N physical keys 201 to 20N are used, where N is an integer greater than or equal to 1. The i-th physical key 20i (i=1 to N) contains i-th virtual mobility information, which is information that specifies the i-th virtual mobility. A specification operation is an operation that designates the i-th virtual mobility as the target virtual mobility. One form of a specification operation is a key specification operation, which is an operation that starts the vehicle 10 using the i-th physical key 20i. Another form of a specification operation is an HMI specification operation, which is an operation that designates the i-th virtual mobility as the target virtual mobility via an input device provided by the vehicle 10 or a user terminal held by the user of the vehicle 10.
[0058] Figure 11 is a flowchart showing the switching process for the target virtual mobility.
[0059] In step S200, the vehicle management system 100 determines whether the specified operation has been performed. If the specified operation has been performed (step S200; Yes), the process proceeds to step S210. If the specified operation has not been performed (step S200; No), the process repeats step S200.
[0060] In step S210, the vehicle management system 100 determines whether the specified operation determined in step S200 was a key specification operation. If the entered specified operation was a key specification operation (step S210; Yes), the process proceeds to step S220. On the other hand, if the entered specified operation was not a key specification operation (step S210; No), the process proceeds to step S230.
[0061] In step S220, the vehicle management system 100 starts the key assignment simulation mode. That is, the vehicle management system 100 considers the virtual mobility 30 corresponding to the physical key 20 used in the key assignment operation as the target virtual mobility and starts the simulation mode. After that, the process returns to the beginning.
[0062] In step S230, the vehicle management system 100 determines that the input specified operation is an HMI specified operation. Therefore, in step S230, the vehicle management system 100 starts the HMI specified simulation mode. That is, the vehicle management system 100 considers the virtual mobility 30 specified by the HMI specified operation as the target virtual mobility and starts the simulation mode. After that, the process returns to the beginning.
[0063] Thus, when a user possesses multiple physical keys 20, the user can enjoy a simulated mode by specifying the virtual mobility 30 associated with each physical key 20 through a designated operation. It is also possible to switch between target virtual mobilitys through a designated operation. This allows the user of the vehicle 10 to experience various virtual mobility 30 driving environments corresponding to the types of physical keys 20 they possess.
[0064] The vehicle management system 100 may provide notifications prompting the user to perform a specified operation. For example, consider the case where the vehicle management system 100 acquires multiple types of virtual mobility information 40, as shown in Figure 10. In this case, the vehicle management system 100 provides a notification via the HMI unit 150 (display and speaker 70) prompting the user to specify either the first virtual mobility 301 or the second virtual mobility 302. This allows the user to select the virtual mobility that best suits their preferences, even if they have multiple physical keys 20 when boarding the vehicle 10.
[0065] 4-3. When multiple specified operations are performed If the same operation is performed multiple times, the vehicle management system 100 will, in principle, determine the target virtual mobility according to the most recent operation. In other words, the most recent operation will, in principle, override any previously entered operations. The switching operation shown in Figure 10 illustrates an example where the target virtual mobility is changed according to the most recent operation.
[0066] Exceptionally, if multiple designated operations are performed within a certain period (hereinafter referred to as the first period), the vehicle management system 100 may process multiple designated operations according to a predetermined priority rule. The first period is a period that can be set arbitrarily.
[0067] One example of a priority rule is to prioritize processing earlier specified operations. For example, consider a situation where vehicle 10 is started with a physical key 20 and the startup sound of the target virtual mobility is being output. In this case, if the user mistakenly performs an HMI specified operation and switches the target virtual mobility, the switch will occur while the simulated startup sound is being output. This can cause discomfort to the user and may detract from the sense of realism. Therefore, even if further specified operations are performed by HMI specified operations, prioritizing the earlier specified operation, the key specified operation with the physical key 20, will reduce the likelihood of the vehicle 10 user feeling uncomfortable. Accordingly, the first period in this case should ideally be about the duration of the simulated startup sound (e.g., a few seconds to about 10 seconds).
[0068] Another example of a priority rule is that if both a key assignment operation and an HMI assignment operation are entered during the first period, the key assignment operation will be processed with priority over the HMI assignment operation. By deliberately setting it this way, the sense of realism obtained from the operation of starting the vehicle 10 using the physical key 20 can be further enhanced.
[0069] 5. Example Configuration Figure 12 is a block diagram showing an example configuration of the vehicle 10 and the physical key 20. This figure shows an example where the entire vehicle management system 100 is installed in the vehicle 10. As mentioned in Section 1, a part of the vehicle management system 100 may be included in a management server outside the vehicle 10. The management server can communicate with the vehicle 10, obtain various necessary information from the vehicle 10, and provide various information to the vehicle. The processor 101, storage device 102, vehicle management program 105, and HMI unit 150 have been described previously, so their explanation is omitted here.
[0070] The physical key 20 comprises one or more processors 111 (hereinafter simply referred to as processor 111) and one or more storage devices 112 (hereinafter simply referred to as storage devices 112). The processors 111 perform various processes. Examples of processors 111 include general-purpose processors, application-specific processors, CPUs (Central Processing Units), GPUs (Graphics Processing Units), ASICs (Application Specific Integrated Circuits), FPGAs (Field-Programmable Gate Arrays), integrated circuits, conventional circuits, and / or combinations thereof. The processors 111 can also be called circuits or processing circuitry. Circuitry is hardware programmed to realize the described functions, or hardware that performs those functions. The storage devices 112 store various information. Examples of storage devices 112 include volatile memory, non-volatile memory, HDDs (Hard Disk Drives), SSDs (Solid State Drives), etc.
[0071] The storage device 112 stores virtual mobility information 40. Virtual mobility information 40 is information necessary to simulate virtual mobility. Virtual mobility information 40 includes information for identifying the target virtual mobility, such as the vehicle type and ID of the virtual mobility. Virtual mobility information 40 may also include virtual mobility model data.
[0072] The physical key 20 is equipped with a communication device 162. The communication device 162 includes an antenna and a transmitting / receiving circuit for wireless communication. The communication device 162 transmits virtual mobility information 40 stored in the storage device 112 to the vehicle 10. More specifically, the processor 111 establishes wireless communication with the vehicle 10 via the communication device 162. The processor 111 also retrieves the virtual mobility information 40 stored in the storage device 112. Then, the processor 111 transmits the virtual mobility information 40 retrieved from the storage device 112 to the vehicle 10 via the communication device 162.
[0073] Meanwhile, the vehicle 10 is equipped with a communication device 161. The communication device 161 includes an antenna and a transmitting / receiving circuit for wireless communication. The communication device 161 receives virtual mobility information 40 transmitted from the physical key 20. More specifically, the processor 101 of the vehicle 10 establishes wireless communication with the physical key 20 via the communication device 161. The processor 101 then acquires the virtual mobility information 40 transmitted from the physical key 20 via the communication device 161. Examples of wireless communication methods between the vehicle 10 and the physical key 20 include near-field communication (NFC) and ultra-wideband communication (UWB).
[0074] The processor 101 of the vehicle 10 starts a simulation mode based on the acquired virtual mobility information 40. Typically, it downloads virtual mobility model data (sound source data and driving characteristic data) corresponding to the vehicle type and ID of the virtual mobility included in the virtual mobility information 40 from an external management server. The processor 101 then starts a simulation mode based on the virtual mobility model data. The processor 101 may download the virtual mobility model data each time it starts a simulation mode. Alternatively, the processor 101 may store the model data it has downloaded once in the storage device 102 of the vehicle 10 and use it again when simulating the same virtual mobility 30 without downloading it again.
[0075] 6. Variations Up to this point, we have described that the transmission of virtual mobility information 40 to the vehicle 10 is performed by a key (physical key 20) that can activate the vehicle 10. As a variation, the transmission of virtual mobility information 40 to the vehicle 10 may be performed by a "medium" that does not have the shape of a key. This "medium" does not have the shape to be inserted into a keyhole like the physical key 20, but it has at least the same storage device 112 and communication device 162 as the physical key 20. In other words, the storage device 112 of the medium stores the virtual mobility information 40, and the communication device 162 transmits the virtual mobility information 40 to the vehicle 10. A miniature car having the shape of the virtual mobility 30 is given as an example of such a medium. As another example, the medium may be a user's user terminal (e.g., a smartphone).
[0076] Vehicle 10 may communicate with a medium located outside of vehicle 10 and acquire virtual mobility information 40 from the medium located outside of vehicle 10. In this case, the vehicle management system 100 can acquire the virtual mobility information 40 when the medium is located outside of vehicle 10. Therefore, the vehicle management system 100 can perform the calculations necessary to start the simulation mode based on the virtual mobility information 40 in advance, before the user boards vehicle 10. This makes the start of the simulation mode smoother. In other words, even when a medium that does not have a key shape is used, the technical effect of making the start of the simulation mode smoother can be obtained.
[0077] 7. Application to electric vehicles equipped with manual mode (MT mode) The electric motors used as the power source in conventional electric vehicles (EVs) have significantly different torque characteristics compared to the internal combustion engines used as the power source in conventional vehicles (CVs). Due to these differences in torque characteristics, CVs require a transmission, whereas electric vehicles generally do not. Of course, conventional electric vehicles do not have a manual transmission (MT) that allows the driver to manually switch gear ratios. Therefore, there is a significant difference in driving feel between driving a conventional vehicle with an MT (hereinafter referred to as an MT vehicle) and driving an electric vehicle.
[0078] On the other hand, the torque of an electric motor can be controlled relatively easily by controlling the applied voltage and field. Therefore, with an electric motor, it is possible to obtain the desired torque characteristics within the motor's operating range by implementing appropriate control. Taking advantage of this characteristic, the torque of an electric vehicle can be controlled to simulate the torque characteristics unique to a manual transmission (MT) vehicle. Furthermore, a simulated shifter can be installed in an electric vehicle to allow the driver to experience a driving sensation similar to that of an MT vehicle. In this way, it becomes possible to simulate an MT vehicle in an electric vehicle.
[0079] In other words, the electric vehicle controls the output of the electric motor to simulate the driving characteristics (torque characteristics) unique to a manual transmission (MT) vehicle. The driver operates a simulated shifter to perform a simulated manual gear change. In response to the driver's simulated manual gear change, the electric vehicle changes its driving characteristics (torque characteristics) to simulate an MT vehicle. As a result, the driver of the electric vehicle can get the feeling that they are driving an MT vehicle. The electric motor control mode used to simulate the driving characteristics and manual gear change operation of an MT vehicle will be referred to as "manual mode" or "MT mode" below.
[0080] The following considers the case where the vehicle 10 related to this disclosure is an electric vehicle 10E equipped with an MT mode. In MT mode, the electric vehicle 10E may generate a simulated engine sound in response to the driver's driving operations and output the simulated engine sound through the speaker 70. Since not only the driving operations of an MT vehicle but also the engine sound of an MT vehicle are reproduced, the satisfaction of drivers seeking realism is increased. The following describes an example configuration of the electric vehicle 10E equipped with an MT mode. Examples of MT modes include "sequential shift mode" and "3-pedal mode".
[0081] 7-1. First Configuration Example (Sequential Shift Mode) Figure 13 is a block diagram showing a first configuration example of the power control system of the electric vehicle 10E according to this embodiment. The electric vehicle 10E is equipped with an electric motor 44, a battery 46, and an inverter 42. The electric motor 44 is a power device for driving. The battery 46 stores electrical energy to drive the electric motor 44. In other words, the electric vehicle 10E is a battery electric vehicle (BEV) that runs on the electrical energy stored in the battery 46. The inverter 42 converts the DC power input from the battery 46 during acceleration into driving power for the electric motor 44. The inverter 42 also converts the regenerative power input from the electric motor 44 during deceleration into DC power and charges the battery 46.
[0082] The electric vehicle 10E is equipped with an accelerator pedal 22 for the driver to input acceleration requests to the electric vehicle 10E. The accelerator pedal 22 is equipped with an accelerator position sensor 32 for detecting the accelerator opening degree.
[0083] The electric vehicle 10E is equipped with a sequential shifter 24. The sequential shifter 24 may be a paddle-type shifter or a lever-type pseudo-shifter.
[0084] The paddle shifters are dummies and not genuine paddle shifters. They have a structure similar to the paddle shifters found on clutchless manual transmission vehicles. The paddle shifters are mounted on the steering wheel. They feature an upshift switch and a downshift switch to determine the operating position. The upshift switch emits an upshift signal 34u when pulled towards the user, and the downshift switch emits a downshift signal 34d when pulled towards the user.
[0085] On the other hand, the lever-type dummy shifter, like the paddle-type shifter, is a dummy that is different from the actual shifter. The lever-type dummy shifter has a structure that resembles the lever-type shifter found in clutchless manual transmission vehicles. The lever-type dummy shifter is configured to output an upshift signal 34u when the shift lever is moved forward, and a downshift signal 34d when the shift lever is moved backward.
[0086] Wheel speed sensors 36 are provided on the wheels 26 of the electric vehicle 10E. The wheel speed sensors 36 are used as vehicle speed sensors to detect the vehicle speed of the electric vehicle 10E. In addition, a rotational speed sensor 38 is provided on the electric motor 44 to detect its rotational speed.
[0087] The electric vehicle 10E is equipped with a control unit 50. The control unit 50 is typically an electronic control unit (ECU) installed in the electric vehicle 10E. The control unit 50 may be a combination of multiple ECUs. The control unit 50 comprises an interface, memory, and a processor. An in-vehicle network is connected to the interface. The memory includes RAM for temporarily recording data and ROM for storing programs and various data related to programs that can be executed by the processor. The program consists of multiple instructions. The processor reads and executes the program and data from memory and generates control signals based on signals obtained from each sensor.
[0088] For example, the control device 50 controls the electric motor 44 by PWM control of the inverter 42. The control device 50 receives signals from the accelerator position sensor 32, the sequential shifter 24 (upshift switch and downshift switch if the sequential shifter 24 is a paddle-type shifter), the wheel speed sensor 36, and the rotational speed sensor 38. The control device 50 processes these signals and calculates a motor torque command value for PWM control of the inverter 42.
[0089] The control device 50 includes an automatic mode (EV mode) and a manual mode (MT mode) as control modes. The automatic mode is the normal control mode for driving the electric vehicle 10E as a typical electric vehicle. The automatic mode is programmed to continuously change the output of the electric motor 44 in response to the operation of the accelerator pedal 22. On the other hand, the manual mode is a control mode for driving the electric vehicle 10E like a manual transmission vehicle. The manual mode is programmed to change the output characteristics of the electric motor 44 in response to the operation of the accelerator pedal 22 in response to upshift and downshift operations on the sequential shifter 24. This manual mode (MT mode) corresponds to the "sequential shift mode". The automatic mode and manual mode are switchable.
[0090] The control device 50 includes an automatic mode torque calculation unit 54 and a manual mode torque calculation unit 56. Each unit 54 and 56 may be an independent ECU, or it may be an ECU function obtained by executing a program stored in memory on a processor.
[0091] The automatic mode torque calculation unit 54 has a function to calculate the motor torque when the electric motor 44 is controlled in automatic mode. The automatic mode torque calculation unit 54 stores a motor torque command map. The motor torque command map is a map that determines the motor torque from the accelerator opening and the rotational speed of the electric motor 44. Signals from the accelerator position sensor 32 and the rotational speed sensor 38 are input to each parameter of the motor torque command map. The motor torque corresponding to these signals is output from the motor torque command map. Therefore, in automatic mode, even if the driver operates the sequential shifter 24, that operation is not reflected in the motor torque.
[0092] The manual mode torque calculation unit 56 includes an MT vehicle model. The MT vehicle model is a model for calculating the drive wheel torque that should be obtained by operating the accelerator pedal 22 and the sequential shifter 24, assuming that the electric vehicle 10E is an MT vehicle.
[0093] The MT vehicle model provided by the manual mode torque calculation unit 56 will be described with reference to Figure 14. As shown in Figure 14, the MT vehicle model includes an engine model 561, a clutch model 562, and a transmission model 563. The engine, clutch, and transmission virtually realized by the MT vehicle model are referred to as the virtual engine, virtual clutch, and virtual transmission, respectively. The engine model 561 models the virtual engine. The clutch model 562 models the virtual clutch. The transmission model 563 models the virtual transmission.
[0094] Engine model 561 calculates the virtual engine speed Ne and virtual engine output torque Teout. The virtual engine speed Ne is calculated based on the wheel rotation speed Nw, the overall reduction ratio R, and the virtual clutch slip ratio Rslip. For example, the virtual engine speed Ne is expressed by equation (1) below. Equation (1): Ne = Nw × R / (1 - Rslip)
[0095] The virtual engine output torque Teout is calculated from the virtual engine rotational speed Ne and the accelerator pedal opening Pap. As shown in Figure 14, a map defining the relationship between the accelerator pedal opening Pap, the virtual engine rotational speed Ne, and the virtual engine output torque Teout is used to calculate the virtual engine output torque Teout. This map provides the virtual engine output torque Teout for each accelerator pedal opening Pap relative to the virtual engine rotational speed Ne. The torque characteristics shown in Figure 14 can be set to simulate a gasoline engine, a diesel engine, a naturally aspirated engine, or a turbocharged engine.
[0096] The clutch model 562 calculates the torque transmission gain k. The torque transmission gain k is a gain used to calculate the degree of torque transmission of the virtual clutch according to the virtual clutch opening Pc. The virtual clutch opening Pc is normally 0%, and temporarily opens to 100% in conjunction with the switching of the virtual gear stage of the virtual transmission. The clutch model 562 has a map as shown in Figure 14. In this map, the torque transmission gain k is given for the virtual clutch opening Pc. In Figure 14, Pc0 corresponds to the position where the virtual clutch opening Pc is 0%, and Pc3 corresponds to the position where the virtual clutch opening Pc is 100%. The range from Pc0 to Pc1 and the range from Pc2 to Pc3 are dead zones where the torque transmission gain k does not change with respect to the virtual clutch opening Pc. The clutch model 562 calculates the clutch output torque Tcout using the torque transmission gain k. The clutch output torque Tcout is the torque output from the virtual clutch. For example, the clutch output torque Tcout is given by the product of the virtual engine output torque Teout and the torque transfer gain k (Tcout = Teout × k).
[0097] Furthermore, clutch model 562 calculates the slip ratio Rslip. The slip ratio Rslip is used to calculate the virtual engine speed Ne in engine model 561. Similar to the torque transmission gain k, a map can be used to calculate the slip ratio Rslip, where the slip ratio Rslip is given to the virtual clutch opening Pc.
[0098] The transmission model 563 calculates the gear ratio r. The gear ratio r is the gear ratio determined by the virtual gear stage GP in the virtual transmission. The virtual gear stage GP is increased by one step when the sequential shifter 24 is upshifted. Conversely, the virtual gear stage GP is decreased by one step when the sequential shifter 24 is downshifted. The transmission model 563 has a map as shown in Figure 14. In this map, the gear ratio r is assigned to the virtual gear stage GP such that the larger the virtual gear stage GP, the smaller the gear ratio r becomes. The transmission model 563 calculates the transmission output torque Tgout using the gear ratio r obtained from the map and the clutch output torque Tcout. For example, the transmission output torque Tgout is given by the product of the clutch output torque Tcout and the gear ratio r (Tgout = Tcout × r). The transmission output torque Tgout changes discontinuously according to the gear ratio r switching. This discontinuous change in transmission output torque Tgout creates a shift shock, giving the vehicle the feel of having a stepped transmission.
[0099] The MT vehicle model calculates the drive wheel torque Tw using a predetermined reduction ratio rr. The reduction ratio rr is a fixed value determined by the mechanical structure from the virtual transmission to the drive wheels. The value obtained by multiplying the reduction ratio rr by the gear ratio r is the aforementioned overall reduction ratio R. The MT vehicle model calculates the drive wheel torque Tw from the transmission output torque Tgout and the reduction ratio rr. For example, the drive wheel torque Tw is given by the product of the transmission output torque Tgout and the reduction ratio rr (Tw = Tgout × rr).
[0100] The control device 50 converts the drive wheel torque Tw calculated in the MT vehicle model into a required motor torque Tm. The required motor torque Tm is the motor torque required to achieve the drive wheel torque Tw calculated in the MT vehicle model. The reduction ratio from the output shaft of the electric motor 44 to the drive wheels is used to convert the drive wheel torque Tw into a required motor torque Tm. The control device 50 then controls the inverter 42 to control the electric motor 44 according to the required motor torque Tm.
[0101] Figure 15 shows a comparison of the torque characteristics of an electric motor 44 realized by motor control using an MT vehicle model with the torque characteristics of an electric motor 44 realized by normal motor control as an electric vehicle (EV). As shown in Figure 15, motor control using an MT vehicle model can realize torque characteristics (solid line in the figure) that simulate the torque characteristics of an MT vehicle, depending on the virtual gear stage set by the sequential shifter 24. Note that in Figure 15, the number of gear stages is set to 6.
[0102] 7-2. Second Configuration Example (3-Pedal Mode) Figure 16 is a block diagram showing a second configuration example of the power control system of the electric vehicle 10E according to this embodiment. Here, only the configurations that differ from the first configuration example described above will be explained. Specifically, in the second configuration example, the electric vehicle 10E is equipped with a pseudo-shift lever (pseudo-shift device) 27 and a pseudo-clutch pedal 28 instead of the sequential shifter 24 provided in the first configuration example. The pseudo-shift lever 27 and pseudo-clutch pedal 28 are merely dummies and are different from the actual shift lever and clutch pedal.
[0103] The simulated shift lever 27 has a structure that mimics the shift lever found in a manual transmission (MT) vehicle. The placement and feel of the simulated shift lever 27 are equivalent to those of an actual MT vehicle. The simulated shift lever 27 has positions corresponding to each gear, such as 1st, 2nd, 3rd, 4th, 5th, 6th, reverse, and neutral. The simulated shift lever 27 is equipped with a shift position sensor 27a that detects the gear by determining which position the simulated shift lever 27 is in.
[0104] The simulated clutch pedal 28 has a structure that simulates the clutch pedal found in a manual transmission (MT) vehicle. The placement and feel of the simulated clutch pedal 28 are equivalent to those of an actual MT vehicle. The simulated clutch pedal 28 is operated when the simulated shift lever 27 is operated. In other words, the driver depresses the simulated clutch pedal 28 when they want to change the gear setting using the simulated shift lever 27, and releases the pedal when the gear setting change is complete, returning the simulated clutch pedal 28 to its original position. The simulated clutch pedal 28 is equipped with a clutch position sensor 28a for detecting the amount the simulated clutch pedal 28 is depressed.
[0105] The control device 50 receives signals from the accelerator position sensor 32, the shift position sensor 27a, the clutch position sensor 28a, the wheel speed sensor 36, and the rotational speed sensor 38. The control device 50 processes these signals and calculates a motor torque command value for PWM control of the inverter 42.
[0106] The control device 50, similar to the first configuration example described above, includes an automatic mode and a manual mode as control modes. The automatic mode is programmed to continuously change the output of the electric motor 44 in response to the operation of the accelerator pedal 22. On the other hand, the manual mode is a control mode for driving the electric vehicle 10E like a manual transmission vehicle. In the manual mode, the output and output characteristics of the electric motor 44 in response to the operation of the accelerator pedal 22 are programmed to change in response to the operation of the simulated clutch pedal 28 and the simulated shift lever (simulated shift device) 27. This manual mode (MT mode) corresponds to the "3-pedal mode". The automatic mode and manual mode are switchable.
[0107] The vehicle model provided by the manual mode torque calculation unit 56 is the same as that shown in Figure 14. However, the virtual clutch opening Pc is replaced by the amount of depression of the pseudo clutch pedal 28 detected by the clutch position sensor 28a. In addition, the virtual gear stage GP is determined by the position of the pseudo shift lever 27 detected by the shift position sensor 27a. [Explanation of Symbols]
[0108] 10: Vehicles 11: Sensor 20: Physical key 22: Accelerator pedal 24: Sequential shifter 26 :Wheel 27: Simulated shift lever 27a: Shift position sensor 28: Simulated clutch pedal 28a: Clutch position sensor 30: Virtual Mobility 32: Accelerator position sensor 34d: Downshift signal 34u: Upshift signal 36: Wheel speed sensor 38: Rotation speed sensor 40: Virtual Mobility Information 42: Inverter 44: Electric motor 46: Battery 50: Control device 54: Automatic Mode Torque Calculation Unit 56: Manual Mode Torque Calculation Unit 70: Speaker 100: Vehicle Management System 150: HMI Unit 200: Basic sound source data 561: Engine Model 562: Clutch Model 563: Transmission Model DRV: Driving Status Information ES: Engine sound data GP: Virtual Gear Stage Ne: Virtual engine rotation speed Nw: Rotational speed Pap: Accelerator opening Pc: Virtual clutch opening Tcout: Clutch output torque Teout: Virtual engine output torque Tgout: Transmission output torque
Claims
1. A key for starting an electric vehicle capable of simulating the driving environment of the target virtual mobility, Equipped with a memory device and a communication device, The storage device is configured to include virtual mobility information, The virtual mobility information includes information necessary to simulate the driving environment of one or more virtual mobilitys, including the target virtual mobility. The communication device is configured to transmit the virtual mobility information to the electric vehicle. key.
2. An electric vehicle that can be started by a key-based ignition operation, One or more processors that simulate the driving environment of the target virtual mobility, Communication equipment and Equipped with, The one or more processors described above are: The communication device acquires virtual mobility information held by one or more keys. Based on the acquired virtual mobility information, the driving environment of the target virtual mobility is simulated. It is configured in such a way, The virtual mobility information includes information necessary to simulate the driving environment of one or more virtual mobility devices, including the target virtual mobility device. Electric vehicle.
3. An electric vehicle according to claim 2, The first key has first virtual mobility information, which includes information necessary to simulate the driving environment of the first virtual mobility, When the startup operation using the first key is performed, the one or more processors set the first virtual mobility as the target virtual mobility and simulate the operating environment of the first virtual mobility based on the first virtual mobility information. It is configured to Electric vehicle.
4. An electric vehicle according to claim 3, The one or more processors further include: In conjunction with the aforementioned startup operation, a simulated startup sound that mimics the startup sound of the target virtual mobility device is output. It is configured to Electric vehicle.
5. An electric vehicle according to claim 2, The virtual mobility information includes information necessary to simulate the driving environments of multiple virtual mobility devices. The one or more processors further include: Of the aforementioned multiple virtual mobility options, the i-th virtual mobility option, specified by a designated operation performed by the user of the electric vehicle, is simulated as the target virtual mobility option. It is configured to Electric vehicle.
6. An electric vehicle according to claim 5, The number of keys is N (N ≥ 1), Of the N keys, the i-th key (i = 1 to N) has i-th virtual mobility information, which is information specifying the i-th virtual mobility. The aforementioned designation operation includes the activation operation using the i-key. Electric vehicle.
7. An electric vehicle according to claim 5, The aforementioned designated operation includes operations entered via an input device provided by the electric vehicle or via the user's user terminal. Electric vehicle.
8. An electric vehicle according to claim 5, The one or more processors described above are: Provide the user with a notification prompting them to perform the specified operation. It is configured to Electric vehicle.
9. An electric vehicle according to claim 5, If the aforementioned designation operation is performed multiple times, the one or more processors are configured to determine the target virtual mobility according to the most recent designation operation. Electric vehicle.
10. An electric vehicle according to claim 5, If the specified operation is performed multiple times during the first period, the one or more processors process the multiple specified operations according to a predetermined priority rule. It is configured to Electric vehicle.
11. An electric vehicle according to claim 10, The aforementioned priority rule is to process the specified operation that was entered earlier with higher priority. Electric vehicle.
12. An electric vehicle according to claim 10, The number of keys is N (N ≥ 1), Of the N keys, the i-th key (i = 1 to N) has i-th virtual mobility information, which is information specifying the i-th virtual mobility. The key specification operation is the activation operation using the i key, HMI designation operations are operations that are entered via an input device provided by the electric vehicle or via the user's user terminal. The priority rule is that if both the key designation operation and the HMI designation operation occur during the first period, the key designation operation will be processed with priority over the HMI designation operation. Electric vehicle.