Vehicle management systems and electric vehicles

The vehicle management system addresses the lack of maintenance simulation in existing technologies by altering the driving environment based on maintenance indicators and virtual maintenance, improving the realism of the driving experience.

JP2026054249APending Publication Date: 2026-03-26TOYOTA JIDOSHA KK
View PDF 1 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-09-13
Publication Date
2026-03-26

AI Technical Summary

Technical Problem

Existing vehicle simulation technologies fail to incorporate the effects of maintenance on the driving environment, such as consumable deterioration and deposit accumulation, leading to a less realistic driving experience.

Method used

A vehicle management system that simulates a driving environment by altering it based on maintenance indicators and performing virtual maintenance, including consumable replenishment and deposit removal, to recreate the changes in driving characteristics, sound, and vibrations.

Benefits of technology

Enhances the realism of the driving experience by replicating the changes in the driving environment due to maintenance, providing a more immersive simulation of virtual mobility.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026054249000001_ABST
    Figure 2026054249000001_ABST
Patent Text Reader

Abstract

The goal is to incorporate maintenance considerations into technologies that simulate driving environments, thereby allowing vehicle users to experience a more realistic driving environment. [Solution] The vehicle management system generates a simulated driving environment that simulates the driving environment of a virtual mobility device. Virtual maintenance is maintenance performed virtually on the virtual mobility device. The vehicle management system performs a first environment change process that changes the simulated driving environment based on a maintenance index that indicates the degree of need for virtual maintenance. The vehicle management system performs a second environment change process that changes the simulated driving environment in response to at least virtual maintenance.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to a technology for reproducing a virtual mobility environment in a vehicle.

Background Art

[0002] Patent Document 1 discloses a vehicle control device that controls an acoustic device so as to generate a virtual sound of a virtual vehicle equipped with a virtual engine in the passenger compartment of a real vehicle.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a real vehicle, the driving environment (driving characteristics, sound, vibration, etc.) changes as the vehicle travels. Causes of the change in the driving environment include deterioration and consumption of consumables, accumulation of deposits on each part, and the like. In addition, when consumables are replaced or deposits are removed by maintenance, the changed driving environment tries to return to its original state. In the prior art, the simulation of the driving environment incorporating such viewpoints has not been performed.

[0005] One object of the present disclosure is to incorporate the viewpoint of maintenance into the technology for simulating the driving environment so that the user of the vehicle can feel a more realistic driving environment.

Means for Solving the Problems

[0006] A first aspect relates to a vehicle management system applied to a vehicle. The vehicle management system includes one or more processors that generate a simulated driving environment simulating a driving environment of virtual mobility. Virtual maintenance is maintenance performed virtually on virtual mobility. One or more processors perform a first environment change process that alters the simulated operating environment based on maintenance indicators that show the degree of virtual maintenance required. One or more processors perform a second environment change process that alters the simulated operating environment in response to virtual maintenance.

[0007] The second perspective concerns electric vehicles that use an electric motor as the power source for propulsion. The electric vehicle is equipped with one or more processors that generate a simulated driving environment that mimics the driving environment of virtual mobility. Virtual maintenance is maintenance performed virtually on virtual mobility. One or more processors perform a first environment change process that alters the simulated operating environment based on maintenance indicators that show the degree of virtual maintenance required. One or more processors perform a second environment change process that alters the simulated operating environment in response to virtual maintenance. [Effects of the Invention]

[0008] The first environmental change processing generates a simulated driving environment in vehicle 10 based on maintenance indicators, representing changes in the driving environment of the virtual mobility. The second environmental change processing further modifies the simulated driving environment, which has been modified by the first processing, in response to virtual maintenance. The combination of the first and second processing reproduces the changes in the driving environment that accompany the actual vehicle's operation, and the process by which the modified driving environment is restored through maintenance. As a result, the user of vehicle 10 can experience a more realistic sensation of riding in the virtual mobility. [Brief explanation of the drawing]

[0009] [Figure 1] This is a conceptual diagram showing a vehicle and its vehicle management system. [Figure 2]This is a conceptual diagram illustrating the simulation modes provided by the vehicle management system. [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] This graph shows an overview of how to process environmental changes. [Figure 6] This flowchart shows a series of processes related to the second environmental change processing. [Figure 7] This is a schematic diagram showing an example of a maintenance notification screen. [Figure 8] This graph shows several variations of the second environmental change processing. [Figure 9] This is a block diagram illustrating the in-vehicle devices and management server that make up the vehicle management system. [Figure 10] This is a block diagram showing a first configuration example related to the power control system of an electric vehicle. [Figure 11] This figure shows examples of the engine model, clutch model, and transmission model that make up an MT vehicle model. [Figure 12] This figure shows the torque characteristics of an electric motor achieved through motor control using an MT vehicle model. [Figure 13] This is a block diagram showing a second example configuration related to the power control system of an electric vehicle. [Modes for carrying out the invention]

[0010] Embodiments of this disclosure will be described with reference to the attached drawings.

[0011] 1. Vehicles and Vehicle Management Systems FIG. 1 is a conceptual diagram showing a vehicle 10 and a vehicle management system 100 according to the present embodiment. For example, the vehicle 10 is an electric vehicle that uses an electric motor 44 as a driving power device. Examples of the electric motor 44 include a brushless DC motor and a three-phase AC synchronous motor. As another example, the vehicle 10 may be an engine vehicle that uses an internal combustion engine as a driving power device.

[0012] The vehicle 10 includes various sensors 11. The various sensors 11 detect the driving state of the vehicle 10. Examples of the various 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, a recognition sensor, and the like. The accelerator position sensor detects the operation amount of the accelerator pedal. The brake position sensor detects the operation amount 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 the vehicle 10. The acceleration sensor detects the lateral acceleration and longitudinal acceleration of the vehicle 10. The rotational speed sensor detects the rotational speed of the electric motor 44. The position sensor detects the position of the vehicle 10. An example of the position sensor is a GNSS (Global Navigation Satellite System) sensor. The recognition sensor is a sensor for recognizing (detecting) the situation around the vehicle 10. Examples of the recognition sensor include a camera, a lidar (Light Detection And Ranging), a radar, and the like.

[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 inside the vehicle cabin of the vehicle 10. As another example, the speaker 70 may be an out-vehicle speaker that outputs sound outside the vehicle 10. The vehicle 10 may include both an in-vehicle speaker and an out-vehicle speaker. Also, the speaker 70 may be a vibration speaker. The vibration speaker is attached under the seat, to the body, etc., and directly vibrates the attached object.

[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 mounted on the vehicle 10. As another example, at least a part of the vehicle management system 100 may be included in a management server outside 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 the processor 101) and one or more storage devices 102 (hereinafter simply referred to as the storage device 102). The processor 101 executes various processes. Examples of the processor 101 include general-purpose processors, dedicated 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 referred to as circuitry or processing circuitry. Circuitry is hardware programmed to implement the described functions, or hardware that executes the functions. The storage device 102 stores (stores) various information. Examples of the storage device 102 include volatile memory, non-volatile memory, HDDs (Hard Disk Drives), SSDs (Solid State Drives), and the like. Through the cooperation of the processor 101 and the storage device 102, the functions of the vehicle management system 100 are realized.

[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 virtual mobility being simulated. Specifically, multiple types of virtual mobility model data are provided for multiple types of virtual mobility. The user of vehicle 10 specifies their preferred virtual mobility, and the vehicle management system 100 reproduces the driving characteristics using the virtual mobility data for the virtual mobility specified by the user. This allows the driver of vehicle 10 to feel as if they are driving their preferred virtual mobility. The user of vehicle 10 may also select the virtual mobility to be simulated. In this case, the user can select the virtual mobility to be simulated from among multiple virtual mobility options according to their preference. In this way, when the user selects the target to be simulated, the "simulation mode" can also be called the "on-demand mode." Furthermore, when on-demand mode is applied to vehicle 10, vehicle 10 can also be called the "on-demand car." On-demand mode is particularly effective when the user wants to experience driving their preferred virtual vehicle.

[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 vehicles, but may also be a train, an airplane, etc.

[0021] As a further example, the vehicle management system 100 may simulate (reproduce) the "vibrations" of a virtual mobility device in the vehicle 10. That is, the vehicle management system 100 may generate simulated vibrations that simulate the vibrations of a virtual mobility device and output these simulated vibrations through the speaker 70 (vibration speaker) of the vehicle 10. Typically, the vibrations to be simulated (reproduced) are those that occur as the virtual mobility device moves. Examples of virtual mobility devices to be simulated include engine cars, electric vehicles, trains, airplanes, etc., as in the case of simulating sound.

[0022] In general terms, simulating the driving characteristics, sounds, vibrations, etc., of virtual mobility can be considered part of creating a "simulated driving environment." A simulated driving environment can be defined as an environment that reproduces the sensations a person feels when riding in virtual mobility.

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

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

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

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

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

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

[0029] Furthermore, the generation of simulated engine sounds is a well-known technique and is not particularly limited in this embodiment. For example, simulated engine sounds 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.

[0030] 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 driver of the vehicle 10 to feel as if they are driving a virtual mobility vehicle.

[0031] The vehicle management system 100 may further include a user interface 150. The user interface 150 includes an input device and a display device. Examples of input devices include a touch panel, switches, buttons, etc. Examples of display devices include a display, touch panel, etc. Users of the vehicle 10 (e.g., drivers, passengers) can use the user interface 150 to turn the generation and output of simulated engine sounds ON / OFF.

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

[0033] 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 user interface 150 (display device). The user uses the user interface 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. The user of vehicle 10 can also switch the simulated engine sound output from speaker 70 using the user interface 150.

[0034] 3. Environmental change handling In real vehicles, the driving environment (driving characteristics, sound, vibration, etc.) changes as the vehicle is driven. One reason for the change in the driving environment is that consumables such as engine oil and transmission oil deteriorate or are consumed, and deposits such as combustion residues accumulate inside the engine. Therefore, by replacing or replenishing consumables and removing deposits through maintenance, the changed driving environment attempts to return to its original state. The vehicle management system 100 according to this embodiment reproduces the changes in the driving environment related to maintenance. That is, the vehicle management system 100 changes the simulated driving environment as the vehicle 10 is driven, and also changes the simulated driving environment in response to maintenance virtually performed on the virtual mobility. As a result, the user of the vehicle 10 can feel the sensation of riding in the virtual mobility more realistically. Maintenance virtually performed on the virtual mobility will be referred to as "virtual maintenance" below.

[0035] The vehicle management system 100 performs processing to change the simulated driving environment in conjunction with virtual maintenance. This processing is hereinafter referred to as "environmental change processing." Environmental change processing changes the sounds, driving characteristics, vibrations, etc., generated in the vehicle 10.

[0036] 3-1. Virtual Maintenance Virtual maintenance includes replenishing or replacing virtual consumables of virtual mobility. Virtual consumables refer to consumables that deteriorate or are consumed as a result of virtual driving of virtual mobility. Examples of virtual consumables include engine oil, transmission oil, brake fluid, gasoline, engine air cleaner, etc. In other words, virtual maintenance includes replenishing or replacing various oils, replenishing gasoline, replacing air cleaners, etc.

[0037] Virtual maintenance includes removing virtual deposits from virtual mobility. Virtual deposits refer to objects that accumulate during the virtual driving of virtual mobility. Examples of virtual deposits include deposits (combustion residues) inside the engine. In other words, virtual maintenance includes removing deposits.

[0038] Virtual maintenance involves virtually replacing parts of a virtual vehicle, including tires, wheels, mufflers, etc.

[0039] Virtual maintenance is performed by the vehicle management system 100. On the other hand, the decision of whether or not to perform virtual maintenance may be made by the vehicle management system 100 or by the user of vehicle 10. The user can instruct the vehicle management system 100 to perform virtual maintenance of their choice at any time. Alternatively, the vehicle management system 100 may present a notification regarding virtual maintenance to the user of vehicle 10 at an appropriate time (details will be described later). In this case, the user can communicate instructions for virtual maintenance to the vehicle management system 100 by responding to the notification.

[0040] 4-1. Details of environmental change processing The changes in the simulated driving environment caused by environmental change processing vary depending on the content of the corresponding virtual maintenance. For example, if the virtual maintenance is engine oil replenishment or replacement, the virtual maintenance changes the magnitude of the primary explosion component of the simulated engine sound. Also, in actual engine vehicles, engine friction changes when engine oil is replenished or replaced. Changes in engine friction cause changes in driving characteristics (driving force). To reproduce this phenomenon, the vehicle management system 100 changes the driving characteristics (driving force) of the vehicle 10 through environmental change processing. Also, if the virtual maintenance is transmission oil replenishment or replacement, the vehicle management system 100 changes the driving force of the vehicle 10 through environmental change processing. This processing reproduces the changes in transmission friction and the resulting changes in driving force in actual vehicles. Furthermore, if the target of the virtual maintenance is the air cleaner, the vehicle management system 100 also changes the driving force of the vehicle 10 through environmental change processing. This processing reproduces the changes in the degree of engine pumping loss and the resulting changes in driving force in actual vehicles.

[0041] Figure 5 is a graph illustrating the overview of the environmental change processing. The horizontal axis of the graph represents the passage of time. The vertical axis of the graph represents the simulated driving environment generated in the vehicle 10. In this embodiment, sound is used as an example of the simulated driving environment. That is, the vertical axis of the graph shows the state of sound as defined by sound pressure and frequency. As shown in Figure 5, the environmental change processing includes a "first environmental change processing" and a "second environmental change processing". For the sake of explanation, in this embodiment and in the drawings, the "first environmental change processing" and the "second environmental change processing" are referred to as "first processing" and "second processing," respectively. The first processing is the processing of changing the simulated driving environment between virtual maintenance. The second processing is the processing of changing the simulated driving environment in response to virtual maintenance. The first processing and the second processing will be described in detail below.

[0042] <First Environmental Change Processing> The first environmental change process (first process) is a process that changes the simulated driving environment between virtual maintenance periods. In the first process, the vehicle management system 100 changes the simulated driving environment based on a "maintenance indicator" that indicates the degree of need for virtual maintenance. A simple example of the maintenance indicator is the mileage or driving time relative to the time of the previous virtual maintenance. Typically, the first process gradually changes the simulated driving environment between virtual maintenance periods.

[0043] As a more complex example, the consumption of virtual consumables and the amount of virtual deposits in virtual mobility may be used as maintenance indicators. In this case, the vehicle management system 100 calculates the consumption of virtual consumables and the amount of virtual deposits in virtual mobility through simulation, according to the driving history and operation history of the vehicle 10.

[0044] For example, the vehicle management system 100 calculates the engine oil consumption in the virtual mobility, and then calculates the changes in engine warm-up time, the changes in the primary combustion component of the engine sound, and the changes in engine friction, etc., in accordance with the calculated engine oil consumption. Furthermore, the vehicle management system 100 calculates the changes in the driving environment caused by these changes and reflects them in the simulated driving environment (simulated engine sound).

[0045] The vehicle management system 100 calculates the amount of deposits adhering to the inside of the virtual mobility's engine and calculates the change in knocking sound corresponding to the amount of deposits. The vehicle management system 100 takes this change into consideration and reflects it in the simulated driving environment (simulated engine sound). Based on the amount of deposits adhering, the vehicle management system 100 can also reproduce changes in driving characteristics caused by misfires due to spark plug deterioration, as well as changes in driving characteristics during engine startup.

[0046] <Second Environmental Change Processing> The second environmental change processing (second processing) is the process of changing the simulated operating environment in response to virtual maintenance. Typically, the second processing discontinuously changes the simulated operating environment in response to virtual maintenance.

[0047] In other words, the first process is to generate a simulated driving environment in vehicle 10 based on maintenance indicators, which corresponds to the changes in the driving environment associated with the operation of the virtual mobility device. The second process is to attempt to restore the simulated driving environment, which was changed by the first process, to its original state in response to virtual maintenance. By combining the first and second processes, the changes in the driving environment associated with the operation of a real vehicle and the process by which the changed driving environment is restored through maintenance are reproduced.

[0048] Referring to the example in Figure 5, let's consider a case where the virtual mobility is a gasoline-powered vehicle and the virtual maintenance is the replacement or replenishment of engine oil. First, let's consider a state where the engine oil of the virtual mobility is virtually replaced or replenished by virtual maintenance IM1 performed at time t1. After that, until virtual maintenance IM2 (time t2), the sound generated by the first process gradually changes. At this time, the maintenance index that defines the degree of sound change may be a simple index such as mileage, or it may be the amount of engine oil consumed in the virtual mobility obtained by simulation. In the former case, the amount of engine oil consumed is approximated and calculated using a simple index, so the amount of data and processing load are small. On the other hand, in the latter case, the amount of engine oil consumed is accurately calculated by simulation, so the reliability as a maintenance index is high, but the amount of data and processing load tend to be large. In virtual maintenance IM2 (time t2), the engine oil of the virtual mobility is virtually replaced or replenished. In response to virtual maintenance IM2, the vehicle management system 100 executes the second process. In the second process, the sound generated in the vehicle 10 changes. In the example in Figure 5, the second process returns the generated sound to the state immediately after virtual maintenance IM1 (first state). Note that the state after the second process does not necessarily have to be the same as the state of the previous virtual maintenance.

[0049] 4-3. Processing Flow Figure 6 is a flowchart showing a series of processes related to the second process. The illustrated processes are executed repeatedly at regular intervals.

[0050] Figure 6(A) is a flowchart showing when the vehicle management system 100 presents a notification to the user of vehicle 10 regarding whether or not to perform virtual maintenance (hereinafter referred to as the "maintenance notification"). Specifically, the maintenance notification includes an option asking whether or not to perform virtual maintenance.

[0051] In step S11, the vehicle management system 100 determines whether virtual maintenance is required based on maintenance indicators. Typically, the vehicle management system 100 performs the above determination based on the relationship between the set threshold and the current value of the maintenance indicator. For example, if the maintenance indicator, such as mileage, amount of virtual deposits, or consumption of virtual consumables, exceeds the threshold, it is determined that virtual maintenance is required. If it is determined that virtual maintenance is required (step S11; Yes), the process proceeds to step S12. If it is determined that virtual maintenance is not required (step S11; No), the process ends.

[0052] In step S12, the vehicle management system 100 presents the user with a maintenance notification. The maintenance notification may be presented visually or audibly, for example, through the user interface 150 in the vehicle 10. Alternatively, the maintenance notification may be presented to the user's information terminal (smartphone, tablet, PC, etc.). Upon receiving the maintenance notification, the user responds by selecting whether or not to have the vehicle management system 100 perform virtual maintenance.

[0053] In step S13, the vehicle management system 100 refers to the user's response to the maintenance notification. If the user chooses to perform virtual maintenance (step S13; Yes), the process proceeds to step S14. If the user does not choose to perform virtual maintenance (step S13; No), the process ends. "If the user does not choose to perform virtual maintenance" includes not only cases where the user actively chooses not to perform virtual maintenance, but also cases where the user does not respond to the maintenance notification for a certain period of time or longer.

[0054] In step S14, the vehicle management system 100 performs virtual maintenance. In response to the virtual maintenance, the vehicle management system 100 executes a second process. As a result, the simulated driving environment generated in vehicle 10 changes.

[0055] Figure 6(B) is a flowchart showing the case where the vehicle management system 100 does not present a maintenance notification to the user. In this case, the process of presenting the maintenance notification and the process of determining the user's response, i.e., steps S12-S13 in Figure 6(A), are unnecessary. In other words, if the vehicle management system 100 determines that virtual maintenance is necessary, it automatically performs virtual maintenance and the second process without the user's intent.

[0056] 5. Variations 5-1. Example of a notification screen for the user Figure 7 is a schematic diagram showing an example of a maintenance notification screen. (A) in Figure 7 shows a basic example. The screen displays a message MSG indicating that virtual maintenance is required. Along with the message MSG, the option to perform or not perform virtual maintenance is also displayed. If the user selects "Perform", the vehicle management system 100 executes the virtual maintenance and the second process.

[0057] Figure 7(B) shows another example of the display screen. The screen displays multiple options A to C corresponding to "Perform maintenance." Options A to C indicate what kind of maintenance will be performed. For example, if the virtual maintenance is an engine oil change, each of options A to C will indicate a different engine oil product. The vehicle management system 100 may change the content of the second process according to each option. This allows the user to select various virtual maintenance options according to their preferences, and generates a simulated driving environment that faithfully reproduces the user's selection. For example, some of the options may be offered for a fee, and different prices may be set for each option. Note that the number of options is not limited to the example in Figure 7 (3 options).

[0058] 5-2. Variations of the second environmental change processing method Figure 8 is a graph showing several variations of the second treatment. The basic structure of the graph is the same as in Figure 5.

[0059] Figure 8(A) shows an example of the second process that takes into account the driving history of vehicle 10. The driving history includes the history of the driving status information DRV, as well as the cumulative mileage and driving time. In other words, the driving history indicates how long vehicle 10 has been used and in what manner up to the present. In Figure 8(A), consider the case where the cumulative mileage of vehicle 10 is considerably long. If the driving history of vehicle 10 is not considered, the second process in response to virtual maintenance IM2a is executed, as shown by the dashed line in the graph. As a result, the simulated driving environment returns to the first state (i.e., the same state as immediately after virtual maintenance IM1). On the other hand, if the driving history of vehicle 10 is considered (virtual maintenance IM2b), the simulated driving environment transitions to a second state different from the first state (solid line in the graph). This process reproduces the phenomenon in which, depending on the driving history of a typical vehicle, the driving environment does not recover to the same level as at the time of the previous maintenance even after maintenance. This allows users to faithfully experience the aging of virtual mobility, which corresponds to the aging of vehicle 10, through a simulated driving environment.

[0060] Figure 8(B) shows an example of the second process that introduces the concept of a "virtual maintenance recommendation period." In this example, the vehicle management system 100 sets a virtual maintenance recommendation period (the first period in the figure) when it presents a notification to the user prompting virtual maintenance. If virtual maintenance is performed within the first period (if virtual maintenance IM2a is executed at time t2a), the simulated driving environment returns to the first state by the second process, as shown by the dashed line in the graph. On the other hand, if virtual maintenance is performed after the first period has elapsed (if virtual maintenance IM2b is executed at time t2b), the simulated driving environment transitions to a third state different from the first state (solid line in the graph). This process reproduces the phenomenon in typical vehicles where, if the appropriate maintenance period has passed, the driving environment does not return to its original state even after maintenance.

[0061] 5-3. Reconstruction of the maintenance history of the target vehicle The vehicle management system 100 can also change the simulated driving environment in vehicle 10 according to the "actual" maintenance history performed on an existing / existing vehicle (target vehicle). If the maintenance history of the target vehicle is digitized, the vehicle management system 100 reads the maintenance history data (target history) of that vehicle and records it in the storage device 102. Based on the recorded target history, the vehicle management system 100 changes the simulated driving environment in vehicle 10. This process can be called the "third environment change process (third process)". Through the third process, for example, the maintenance history of a vehicle previously owned by the user of vehicle 10 is reproduced in vehicle 10. The user can then experience the feeling of driving a vehicle they like.

[0062] 6. Various operational methods Figure 9 is a block diagram illustrating the in-vehicle device 400 and management server 300 that constitute the vehicle management system 100. The in-vehicle device 400 and the management server 300 can communicate with each other via a communication network.

[0063] The in-vehicle device 400 is mounted on the vehicle 10. The in-vehicle device 400 includes one or more processors 401 (hereinafter simply referred to as processor 401), one or more storage devices 402 (hereinafter simply referred to as storage devices 402), and a communication device 403. The processor 401 performs various processes. Examples of processors 401 include general-purpose processors, application-specific processors, CPUs, GPUs, ASICs, FPGAs, integrated circuits, conventional circuits, and / or combinations thereof. The processor 401 can also be called circuitry or processing circuitry. The storage devices 402 store (store) various information. Examples of storage devices 402 include volatile memory, non-volatile memory, HDDs, SSDs, etc. The communication device 403 communicates with the management server 300. The functions of the in-vehicle device 400 are realized through the cooperation of the processor 401 and the storage devices 402. Program 405 is a computer program executed by the processor 401. The functions of the in-vehicle device 400 may be realized through the cooperation of a processor 401 that executes program 405 and a storage device 402. Program 405 is stored in the storage device 402. Alternatively, program 405 may be recorded on a computer-readable recording medium.

[0064] The management server 300 includes one or more processors 301 (hereinafter simply referred to as processor 301), one or more storage devices 302 (hereinafter simply referred to as storage devices 302), and a communication device 303. The processor 301 performs various processes. Examples of processors 301 include general-purpose processors, application-specific processors, CPUs, GPUs, ASICs, FPGAs, integrated circuits, conventional circuits, and / or combinations thereof. The processor 301 can also be called circuitry or processing circuitry. The storage devices 302 store various information. Examples of storage devices 302 include volatile memory, non-volatile memory, HDDs, SSDs, etc. The communication device 303 communicates with the in-vehicle devices 400 of a large number of vehicles 10. The functions of the management server 300 are realized through the cooperation of the processor 301 and the storage devices 302. Program 305 is a computer program executed by the processor 301. The functions of the management server 300 may be realized through the cooperation of the processor 301, which executes program 305, and the storage device 302. Program 305 is stored in the storage device 302. Alternatively, program 305 may be recorded on a computer-readable recording medium.

[0065] Either the processor 401 of the in-vehicle device 400 or the processor 301 of the management server 300, or a combination thereof, corresponds to one or more processors 101 shown in Figure 1. Either the storage device 402 of the in-vehicle device 400 or the storage device 302 of the management server 300, or a combination thereof, corresponds to one or more storage devices 102 shown in Figure 1. Either the program 405 of the in-vehicle device 400 or the program 305 of the management server 300, or a combination thereof, corresponds to the vehicle management program 105 shown in Figure 1.

[0066] For example, the aforementioned driving state acquisition unit 110, sound source data management unit 120, sound generation unit 130, output unit 140, and user interface 150 may all be included in the in-vehicle device 400. In this case, the management of simulated sounds is performed within the vehicle 10.

[0067] As another example, the sound source data management unit 120 may be included in the management server 300. In this case, the sound source data management unit 120 centrally manages the basic sound source data 200 used in multiple vehicles 10. For this purpose, the basic sound source data 200 is associated with a vehicle ID. The sound source data management unit 120 manages the available basic sound source data 200 for each vehicle ID. The sound generation unit 130 of the in-vehicle device 400 downloads the available basic sound source data 200 associated with the vehicle ID from the sound source data management unit 120 of the management server 300. Centrally managing the basic sound source data 200 used in multiple vehicles 10 in the management server 300 is preferable from the viewpoint of managing the basic sound source data 200.

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

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

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

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

[0072] 7-1. First Configuration Example (Sequential Shift Mode) Figure 10 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.

[0073] 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 angle.

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

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

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

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

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

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

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

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

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

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

[0084] The MT vehicle model provided by the manual mode torque calculation unit 56 will be described with reference to Figure 11. As shown in Figure 11, 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.

[0085] 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)

[0086] The virtual engine output torque Teout is calculated from the virtual engine rotational speed Ne and the accelerator opening Pap. As shown in Figure 11, a map defining the relationship between the accelerator 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 opening Pap relative to the virtual engine rotational speed Ne. The torque characteristics shown in Figure 11 can be set to represent a gasoline engine, a diesel engine, a naturally aspirated engine, or a turbocharged engine.

[0087] 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 is temporarily opened 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 11. In this map, the torque transmission gain k is given for the virtual clutch opening Pc. In Figure 11, 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 uses the torque transmission gain k to calculate the clutch output torque Tcout. 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).

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

[0089] 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 11. 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.

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

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

[0092] Figure 12 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 12, motor control using an MT vehicle model makes it possible to realize torque characteristics (solid line in the figure) that simulate the torque characteristics of an MT vehicle, according to the virtual gear stage set by the sequential shifter 24. Note that in Figure 12, the number of gear stages is set to 6.

[0093] 7-2. Second Configuration Example (3-Pedal Mode) Figure 13 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.

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

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

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

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

[0098] The vehicle model provided by the manual mode torque calculation unit 56 is the same as that shown in Figure 11. 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]

[0099] 10…Vehicle, 11…Sensor, 44…Electric motor, 70…Speaker, 100…Vehicle management system, 110…Driving status acquisition unit, 120…Sound source data management unit, 130…Sound generation unit, 140…Output unit, 150…User interface, 200…Basic sound source data, 300…Management server, 400…In-vehicle device, DRV…Driving status information

Claims

1. A vehicle management system applicable to a vehicle, It comprises one or more processors that generate a simulated driving environment that simulates the driving environment of virtual mobility, Virtual maintenance is maintenance performed virtually on the virtual mobility, The one or more processors described above are: A first environmental change process is executed to change the simulated operating environment based on a maintenance index indicating the degree of need for the virtual maintenance. At least in response to the virtual maintenance, a second environment change process is executed to change the simulated operating environment. It is configured to Vehicle management system.

2. A vehicle management system according to claim 1, The one or more processors further include: Based on the aforementioned maintenance indicators, a determination is made as to whether or not to perform the virtual maintenance. It is configured to Vehicle management system.

3. A vehicle management system according to claim 1, The one or more processors further include: Based on the aforementioned maintenance indicators, the system presents a notification to the vehicle user that includes an option to decide whether or not to perform the virtual maintenance. Vehicle management system.

4. A vehicle management system according to claim 3, The aforementioned notice further includes options indicating the content of the virtual maintenance. Vehicle management system.

5. A vehicle management system according to claim 3, The one or more processors further include: The degree of change in the simulated operating environment due to the second environmental change processing is changed depending on whether the virtual maintenance is performed during the first period or after the first period has elapsed. It is configured to Vehicle management system.

6. A vehicle management system according to any one of claims 1 to 5, The one or more processors described above are: The second environmental change processing is executed in accordance with the virtual maintenance and the vehicle's operating history. It is configured to Vehicle management system.

7. A vehicle management system according to any one of claims 1 to 5, Virtual consumables are consumables that are virtually consumed in conjunction with the virtual driving of the virtual mobility. The virtual maintenance includes replenishing or replacing the virtual consumables. Vehicle management system.

8. A vehicle management system according to claim 7, The aforementioned maintenance indicator includes the consumption of the aforementioned virtual consumables. Vehicle management system.

9. A vehicle management system according to any one of claims 1 to 5, A virtual attachment is an object that virtually attaches to the virtual mobility as the virtual mobility moves. The virtual maintenance includes removing the virtual deposits. Vehicle management system.

10. A vehicle management system according to claim 9, The maintenance indicator includes the amount of the virtual deposits. Vehicle management system.

11. A vehicle management system according to any one of claims 1 to 5, The simulated driving environment includes vibrations that are virtually generated in conjunction with the virtual driving of the virtual mobility. Vehicle management system.

12. A vehicle management system according to any one of claims 1 to 5, It further includes one or more storage devices that record the target history, which is the actual maintenance history for the target vehicle, The one or more processors are further configured to perform a third environment change process that changes the simulated operating environment based on the target history. Vehicle management system.

13. An electric vehicle that uses an electric motor as a power source for driving, It comprises one or more processors that generate a simulated driving environment that simulates the driving environment of virtual mobility, Virtual maintenance is maintenance performed virtually on the virtual mobility, The one or more processors described above are: A first environmental change process is executed to change the simulated operating environment based on a maintenance index indicating the degree of need for the virtual maintenance. At least in response to the virtual maintenance, a second environment change process is executed to change the simulated operating environment. It is configured to Electric vehicle.

Citation Information

Patent Citations

  • Control device of vehicle

    JP2022036005A