Vehicle management system, vehicle control method and electric vehicle

Abstract

The invention relates to a vehicle management system, a vehicle control method and an electric vehicle. A vehicle management system applied to a vehicle is provided with one or more processors and virtual maintenance. The one or more processors generate a simulated driving environment that simulates a driving environment of the virtual moving body. The virtual maintenance is a maintenance that is virtually performed on the virtual moving body. The one or more processors execute a first environment change process for changing the simulated driving environment on the basis of a maintenance index indicating the degree of necessity of the virtual maintenance, and execute a second environment change process for changing the simulated driving environment in accordance with at least the virtual maintenance.

Description

Technical Field

[0001] This disclosure relates to a technique for reproducing the environment of a virtual mobile body in a vehicle. Background Technology

[0002] Japanese Patent Application Publication No. 2022-036005 discloses a vehicle control device that controls audio equipment to generate virtual sounds of a virtual vehicle with a virtual engine inside the cabin of an actual vehicle. Summary of the Invention

[0003] For actual vehicles, the driving environment (driving characteristics, sound, vibration, etc.) changes as they are driven. One reason for this change is the deterioration or wear and tear of consumable parts, and the accumulation of deposits on various parts. Furthermore, the goal is to restore the changed driving environment to its original state by replacing consumable parts or removing deposits through maintenance. Current technology does not include simulations of driving environments that take this into account.

[0004] This disclosure provides a vehicle management system, a vehicle control method, and an electric vehicle that allows vehicle users to experience a more realistic driving environment by incorporating maintenance perspectives into a simulated driving environment.

[0005] The first aspect of this disclosure relates to a vehicle management system applied to a vehicle. The vehicle management system includes one or more processors and virtual maintenance. The one or more processors are configured to generate a simulated driving environment that simulates the driving environment of a virtual mobile body. The virtual maintenance is maintenance performed virtually on the virtual mobile body. The one or more processors are configured to perform a first environment change process that alters the simulated driving environment based on maintenance indicators representing the necessity of the virtual maintenance. The one or more processors are configured to perform a second environment change process that alters the simulated driving environment at least in accordance with the virtual maintenance.

[0006] The second aspect of this disclosure relates to a vehicle control method. In the control method, (i) a simulated driving environment simulating the driving environment of a virtual mobile body is generated; (ii) maintenance is virtually performed on the virtual mobile body; (iii) a first environment change process is performed to change the simulated driving environment based on a maintenance index representing the necessity of the virtually performed maintenance, i.e., virtual maintenance; and (iv) a second environment change process is performed to change the simulated driving environment at least in accordance with the virtual maintenance.

[0007] The third aspect of this disclosure relates to an electric vehicle that uses an electric motor as a power source for driving. The electric vehicle includes one or more processors configured to generate a simulated driving environment that simulates the driving environment of a virtual mobile body. Virtual maintenance is maintenance performed virtually on the virtual mobile body. The one or more processors are configured to perform a first environment change process that alters the simulated driving environment based on maintenance indicators representing the necessity of the virtual maintenance. The one or more processors are configured to perform a second environment change process that alters the simulated driving environment at least in accordance with the virtual maintenance.

[0008] Based on the aforementioned vehicle management system, vehicle control method, and electric vehicle, the first environmental change processing, based on maintenance indicators, generates changes in the driving environment of the virtual mobile body within the vehicle 10 as a simulated driving environment. The second environmental change processing, in response to virtual maintenance, further alters the simulated driving environment that has changed through the first environmental change processing. By combining the first and second environmental change processing, it is possible to reproduce the changes in the driving environment accompanying the actual vehicle's operation and the process of restoring the changed driving environment through maintenance. Thus, the user of the vehicle 10 can more realistically experience the feeling of riding in a virtual mobile body. Attached Figure Description

[0009] The features, advantages, and technical and industrial significance of exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which the same reference numerals show the same elements, and wherein:

[0010] Figure 1 This is a conceptual diagram illustrating a vehicle and vehicle management system according to one embodiment of the present disclosure.

[0011] Figure 2 This is a conceptual diagram used to illustrate the simulation mode of the vehicle management system.

[0012] Figure 3 This is a block diagram illustrating an example of a functional structure in a vehicle and vehicle management system according to the described embodiment, associated with the generation and output of simulated sound of a virtual mobile body.

[0013] Figure 4 This is a block diagram illustrating another example of the functional structure associated with the generation and output of simulated sound of the virtual mobile body.

[0014] Figure 5 This is a coordinate graph illustrating an overview of environmental change handling in the vehicle and vehicle management system according to the described embodiment.

[0015] Figure 6AThis is a flowchart illustrating a series of processes in the vehicle and vehicle management system of the described embodiment that are associated with the second environmental change processing.

[0016] Figure 6B This is a flowchart illustrating a series of processes in the vehicle and vehicle management system of the described embodiment that are associated with the second environmental change processing.

[0017] Figure 7A This is a schematic diagram illustrating an example of a maintenance notification prompt screen in a vehicle and vehicle management system according to the described embodiment.

[0018] Figure 7B This is a schematic diagram illustrating another example of a maintenance notification prompt screen in a vehicle and vehicle management system according to the described embodiment.

[0019] Figure 8A This is a graph illustrating a variation of the second environmental change treatment.

[0020] Figure 8B This is a graph illustrating a variation of the second environmental change treatment.

[0021] Figure 9 This is a block diagram illustrating the on-board devices and management server that constitute the vehicle management system.

[0022] Figure 10 This is a block diagram illustrating a first structural example of a power control system in the case where the vehicle is an electric vehicle.

[0023] Figure 11 This is a diagram showing examples of the engine model, clutch model, and transmission model that constitute the MT vehicle model.

[0024] Figure 12 This is a graph showing the torque characteristics of an electric motor achieved through motor control using the MT vehicle model.

[0025] Figure 13 This is a block diagram illustrating a second structural example of a power control system in the case where the vehicle is an electric vehicle. Detailed Implementation

[0026] Embodiments of this disclosure are described with reference to the accompanying drawings.

[0027] The following section describes the vehicle and vehicle management system. Figure 1This is a conceptual diagram illustrating the vehicle 10 and vehicle management system 100 according to this embodiment. For example, the vehicle 10 is an electric vehicle that uses an electric motor 44 as a power unit for driving. Examples of electric motors 44 include a brushless DC motor and a three-phase AC synchronous motor. As another example, the vehicle 10 may also be an engine vehicle that uses an internal combustion engine as a power unit for driving.

[0028] Vehicle 10 is equipped with various sensors 11. These sensors 11 detect the driving status of vehicle 10. Examples of the various sensors 11 include accelerator position sensors, brake position sensors, steering angle sensors, steering torque sensors, wheel speed sensors, acceleration sensors, rotational speed sensors, position sensors, and recognition sensors. The accelerator position sensor detects the amount of accelerator pedal operation. The brake position sensor detects the amount of brake pedal operation. 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 sensors detect the rotational speed of the wheels of vehicle 10. The acceleration sensors detect the lateral acceleration and longitudinal acceleration of vehicle 10. The rotational speed sensor detects the rotational speed of the electric motor 44. The position sensors detect the position of vehicle 10. Examples of position sensors include GNSS (Global Navigation Satellite System) sensors. Recognition sensors are used to identify (detect) the surrounding conditions of vehicle 10. Examples of recognition sensors include cameras, LiDAR (Light Detection and Ranging), and radar.

[0029] Furthermore, the vehicle 10 is equipped with one or more speakers 70. For example, the speaker 70 is an interior speaker that outputs sound into the passenger compartment of the vehicle 10. As another example, the speaker 70 can also be an exterior speaker that outputs sound to the outside of the vehicle 10. The vehicle 10 may have both interior and exterior speakers. Alternatively, the speaker 70 can also be a vibrating speaker. The vibrating speaker is installed under the seat or in the vehicle body, etc., to directly cause the object on which the vibrating speaker is installed to vibrate.

[0030] The vehicle management system 100 is applied to manage the vehicle 10. The vehicle management system 100 can also be entirely integrated into the vehicle 10. As another example, at least a portion of the vehicle management system 100 can be contained in a management server external to the vehicle 10. In this case, the vehicle management system 100 can also remotely manage the vehicle 10. As yet another example, the vehicle management system 100 can also be distributed across the vehicle 10 and the management server.

[0031] Generally speaking, the vehicle management system 100 includes one or more processors 101 (hereinafter referred to as processor 101) and one or more storage devices 102 (hereinafter referred to as storage device 102). The processor 101 performs various processes. Examples of processors 101 include general-purpose processors, special-purpose 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 a circuitry or processing circuitry. A circuitry is hardware programmed to implement or perform a function. The storage device 102 stores various information. Examples of storage devices 102 include volatile memory, non-volatile memory, HDDs (Hard Disk Drives), and SSDs (Solid State Drives). The functions of the vehicle management system 100 are realized through the cooperation of the processor 101 and the storage device 102.

[0032] One or more vehicle management programs 105 (hereinafter referred to as vehicle management programs 105) are computer programs executed by processor 101. The functions of the vehicle management system 100 can also be implemented through the cooperation of processor 101 executing vehicle management programs 105 and storage device 102. Vehicle management programs 105 are stored in storage device 102. Alternatively, vehicle management programs 105 can also be recorded on a computer-readable recording medium.

[0033] Next, we will explain the simulation mode of simulating virtual moving bodies. Figure 2 This is a conceptual diagram illustrating the "simulation mode" of the vehicle management system 100 in this embodiment. The simulation mode is a mode that simulates (reproduces) a "virtual mobile body" in the vehicle 10. For example, the virtual mobile body that becomes the object of simulation is a vehicle of a different type than the vehicle 10. As another example, the virtual mobile body that becomes the object of simulation could also be a tram, an airplane, etc.

[0034] For example, if vehicle 10 is an electric vehicle, vehicle management system 100 can also simulate (reproduce) the "driving characteristics" of other vehicles within that electric vehicle. The other vehicles (virtual mobile bodies) used for simulation can be other electric vehicles or manual transmission (MT) vehicles. For example, vehicle management system 100 can also simulate (reproduce) the driving characteristics of MT vehicles within an electric vehicle. Details of the "MT mode (manual mode)" for simulating the driving characteristics of MT vehicles within an electric vehicle will be explained later. In either case, vehicle management system 100 manages virtual mobile body model data representing the model of the virtual mobile body and reproduces the driving characteristics of the virtual mobile body based on this virtual mobile body model data. Thus, the driver of vehicle 10 can experience a feeling similar to driving a virtual mobile body.

[0035] It also allows switching between the virtual mobile vehicles to be simulated. Specifically, it prepares various virtual mobile vehicle model data related to multiple virtual mobile vehicles. The user of vehicle 10 specifies their preferred virtual mobile vehicle, and the vehicle management system 100 uses the virtual mobile vehicle data related to the user-specified virtual mobile vehicle to reproduce driving characteristics. Thus, the driver of vehicle 10 can experience the feeling of driving their favorite virtual mobile vehicle. The virtual mobile vehicle to be simulated can also be selected by the user of vehicle 10. In this case, the user can select the virtual mobile vehicle to be simulated from multiple virtual mobile vehicles according to their own preferences. In this case where the user selects the object to be simulated, the "simulation mode" can also be called "on-demand mode". In addition, when on-demand mode is applied in vehicle 10, vehicle 10 can also be called an "on-demand vehicle". On-demand mode is particularly effective when the user wants to personally experience driving their favorite virtual vehicle.

[0036] As another example, the vehicle management system 100 can also simulate (reproduce) the "sound" of a virtual mobile entity within the vehicle 10. That is, the vehicle management system 100 can generate a simulated sound that mimics the sound of a virtual mobile entity and output this simulated sound through the speaker 70 of the vehicle 10. Typically, the simulated (reproduced) sound is the driving sound or travel sound of the virtual mobile entity. The virtual mobile entity that becomes the object of simulation is, for example, a vehicle. The vehicle that becomes the object of simulation can be either a motorized vehicle or an electric vehicle. For example, if the vehicle 10 is an electric vehicle and the virtual mobile entity is a motorized vehicle, the vehicle management system 100 simulates (reproduces) the engine sound of the motorized vehicle within the electric vehicle. Furthermore, the virtual mobile entity that becomes the object of simulation is not limited to vehicles; it can also be a tram, an airplane, etc.

[0037] As a further example, the vehicle management system 100 can also simulate (reproduce) the "vibration" of a virtual moving body within the vehicle 10. That is, the vehicle management system 100 can generate simulated vibrations that mimic the vibrations of the virtual moving body and output these simulated vibrations through the vehicle 10's speaker 70 (vibration speaker). Typically, the simulated (reproduced) vibrations are those generated during the movement of the virtual moving body. Similar to the case of simulated sound, examples of virtual moving bodies that become the object of simulation include engine vehicles, electric vehicles, trams, and airplanes.

[0038] Generally speaking, the driving characteristics, sounds, vibrations, etc., of a simulated virtual vehicle can be included in the generation of a "simulated driving environment." A simulated driving environment can be defined as an environment that reproduces the sensations a person experiences while riding in a virtual vehicle.

[0039] The generation and output of simulated sound, which simulates the sound of a virtual moving body, are described in more detail below. Furthermore, in the following description, as an example, a pseudo-engine sound simulating the engine sound of an engine vehicle is considered. However, this disclosure can also be applied to other sounds in the same way. In a general sense, "simulated sound" will be used instead of "pseudo-engine sound" in the following description.

[0040] Figure 3 This is a block diagram illustrating an example of a functional structure associated with the generation and output of simulated sound for a virtual mobile object. As functional blocks, the vehicle management system 100 includes 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 can also be implemented, for example, through the cooperation of a processor 101 executing the vehicle management program 105 and a storage device 102.

[0041] 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 related to driving operations performed by the driver, information related to the driving state of the vehicle 10, and information related to the surrounding conditions of the vehicle 10. 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, front-rear acceleration, lateral acceleration, and the rotational speed of the electric motor 44. 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 identified (detected) by identification sensors.

[0042] Additionally, the driving state information DRV includes the virtual engine rotation speed Ne. Here, it is assumed that vehicle 10 uses the virtual engine as a power unit for driving. The virtual engine rotation speed Ne is the rotation speed of the virtual engine when vehicle 10 is assumed to be driven by the virtual engine. For example, the driving state acquisition unit 110 can also calculate the virtual engine rotation speed Ne in a manner that the virtual engine rotation speed Ne increases with the wheel speed. Furthermore, when vehicle 10 has a manual mode (MT mode) as described later, the driving state acquisition unit 110 can also calculate the virtual engine rotation speed Ne in manual mode based on wheel speed, overall reduction ratio, and slip ratio of the virtual clutch. Details regarding the calculation method of the virtual engine rotation speed Ne in manual mode will be described later.

[0043] The sound source data management unit 120 stores and manages the basic sound source data 200 used to generate pseudo engine sounds. The sound source data management unit 120 is primarily implemented through one or more storage devices 102. Typically, the basic sound source data 200 contains various sound source data. These various sound source data include, for example, sound source data for sounds generated by engine combustion (for low speed, medium speed, and high speed), sound source data for sounds generated by drive systems such as gears (for low speed, medium speed, and high speed), noise sound source data, and sound source data for event alert sounds (e.g., creaking sounds, engine stop sounds), etc. Each sound source data is pre-generated through simulations of engine models and vehicle models based on the engine vehicle. Each sound source data can be flexibly adjusted; that is, at least one of the sound pressure level and frequency of the sound indicated by the sound source data can be flexibly adjusted.

[0044] The sound generation unit 130 (sound simulator) is a simulator for generating pseudo engine sounds. The sound generation unit 130 obtains at least a portion of the driving state information (DRV) from the driving state acquisition unit 110. Specifically, the sound generation unit 130 obtains information about the virtual engine rotation speed Ne and vehicle speed from the driving state acquisition unit 110. Additionally, the sound generation unit 130 reads basic sound source data 200 from the sound source data management unit 120. Then, the sound generation unit 130 generates pseudo engine sounds corresponding to the driving state (virtual engine rotation speed Ne, vehicle speed) of the vehicle 10 by combining one or more sound source data included in the basic sound source data 200. Engine sound data ES is data representing the generated pseudo engine sound.

[0045] Furthermore, the generation of pseudo-engine sounds is a well-known technique, and there are no particular limitations in this embodiment. For example, pseudo-engine sounds can also be generated using well-known engine sound simulators used in games, etc. Alternatively, a method can be employed where a virtual engine rotation speed Ne-frequency mapping and a virtual engine torque-sound pressure mapping are provided, and the frequency of the pseudo-engine sound is increased or decreased proportionally to the virtual engine rotation speed Ne, and the sound pressure is increased or decreased proportionally to the virtual engine torque.

[0046] The output unit 140 receives engine sound data ES generated by the sound generation unit 130. Then, based on the engine sound data ES, the output unit 140 outputs a pseudo engine sound through the speaker 70. As a result, the driver of the vehicle 10 can experience a feeling similar to driving a virtual mobile vehicle.

[0047] The vehicle management system 100 may also include a user interface 150. The user interface 150 includes an input device and a display device. Examples of input devices include touch panels, switches, buttons, etc. Examples of display devices include monitors, touch panels, etc. Users of the vehicle 10 (e.g., drivers, passengers) can use the user interface 150 to enable / disable the generation and output of pseudo-engine sounds.

[0048] Figure 4 This is a block diagram illustrating another example of the functional structure associated with the generation and output of simulated sound of a virtual moving body. Figure 4 In the example shown, the sound source data management unit 120 stores and manages various basic sound source data 200 (200-A, 200-B, 200-C...) corresponding to various virtual mobile entities (A, B, C...). That is, the sound source data management unit 120 stores and manages the basic sound source data 200 for each virtual mobile entity. Each basic sound source data 200 is pre-generated based on the engine model and vehicle model of the corresponding virtual mobile entity.

[0049] The user of vehicle 10 can specify a simulated object from a variety of virtual mobile entities. Specifically, the sound source data management unit 120 or the sound generation unit 130 prompts the user with a variety of virtual mobile entities through the user interface 150 (display device). The user uses the user interface 150 (input device) to specify one virtual mobile entity from the variety of virtual mobile entities. The sound generation unit 130 obtains one of the virtual mobile entities corresponding to the user-specified virtual mobile entity from the various basic sound source data 200 obtained from the sound source data management unit 120. Then, the sound generation unit 130 uses the obtained basic sound source data 200 (e.g., basic sound source data 200-B corresponding to virtual mobile entity B) to generate a pseudo engine sound. Thus, the driver of vehicle 10 can experience the feeling of driving their favorite virtual mobile entity. In addition, the user of vehicle 10 can also use the user interface 150 to switch the pseudo engine sound output from the speaker 70.

[0050] Next, the handling of environmental changes will be explained. For a real vehicle, the driving environment (driving characteristics, sound, vibration, etc.) changes as it is driven. One reason for changes in the driving environment is the deterioration or consumption of consumables such as engine oil and transmission oil, or the accumulation of deposits (combustion residues) inside the engine. Therefore, maintenance is performed to replace or replenish consumables, or to remove deposits, in order to restore the changed driving environment to its original state. The vehicle management system 100 of this embodiment reproduces the changes in the driving environment associated with maintenance. That is, the vehicle management system 100 changes the simulated driving environment as the vehicle 10 is driven, and in response to maintenance virtually performed on the virtual mobile body, the simulated driving environment changes again. As a result, the user of the vehicle 10 can experience the feeling of riding in the virtual mobile body more realistically. The maintenance virtually performed on the virtual mobile body will be referred to as "virtual maintenance" below.

[0051] The vehicle management system 100 performs processing that alters the simulated driving environment in conjunction with virtual maintenance. This processing will be referred to as "environmental change processing." Through environmental change processing, the sounds, driving characteristics, vibrations, and other factors generated in the vehicle 10 change.

[0052] Next, virtual maintenance will be explained. Virtual maintenance includes replenishing or replacing virtual consumables for the virtual mobile device. Virtual consumables refer to consumables that deteriorate or are consumed during the virtual operation of the virtual mobile device. Examples of virtual consumables include engine oil, transmission fluid, brake fluid, gasoline, and engine air filters. In other words, virtual maintenance includes replenishing or replacing various oils, replenishing gasoline, and replacing air filters.

[0053] Virtual maintenance includes removing virtual attachments from a virtual mobile vehicle. Virtual attachments are objects that adhere to the virtual mobile vehicle during its virtual movement. An example of a virtual attachment is deposits (combustion residue) inside an engine. Therefore, virtual maintenance includes removing these deposits.

[0054] Virtual maintenance involves virtually replacing components of a virtual vehicle. These components include tires, rims, mufflers, etc.

[0055] Virtual maintenance is performed by the vehicle management system 100. On the other hand, the decision to perform virtual maintenance can be made by either the vehicle management system 100 or the user of the vehicle 10. The user can instruct the vehicle management system 100 to perform virtual maintenance at any given time. Alternatively, the vehicle management system 100 can also notify the user of the vehicle 10 of virtual maintenance at appropriate times (details will be described later). In this case, the user can convey the virtual maintenance instruction to the vehicle management system 100 by responding to the notification.

[0056] Next, the details of environmental change processing will be explained. The changes in the simulated driving environment caused by environmental change processing vary depending on the content of the virtual maintenance corresponding to that simulated driving environment. For example, if the virtual maintenance is topping up or changing the engine oil, the magnitude of the single-stage component of the simulated engine sound changes due to the virtual maintenance. Furthermore, in an actual vehicle, the engine friction changes due to topping up or changing the engine oil. This change in engine friction causes a change 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. Additionally, if the virtual maintenance is topping up or changing the transmission fluid, 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 accompanying changes in driving force that occur in an actual vehicle. Furthermore, if the virtual maintenance involves the air filter, 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 accompanying changes in driving force that occur in an actual vehicle.

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

[0058] Next, the first environment change processing will be explained. The first environment change processing (first processing) is the process of changing the simulated driving environment between virtual maintenance sessions. In the first processing, the vehicle management system 100 changes the simulated driving environment based on "maintenance indicators" that indicate the necessity of virtual maintenance. As a simple example, maintenance indicators include driving distance and driving time based on the last virtual maintenance session. Typically, the first processing gradually changes the simulated driving environment between virtual maintenance sessions.

[0059] As a more complex example, the consumption of virtual consumables and the attachment of virtual attachments in a virtual mobile body can also be used as maintenance indicators. In this case, the vehicle management system 100 calculates the consumption of virtual consumables and the attachment of virtual attachments in the virtual mobile body through simulation based on the driving history and operation history of the vehicle 10.

[0060] For example, the vehicle management system 100 calculates the engine oil consumption in the virtual moving body, and calculates the changes in engine warm-up performance, the changes in the primary component of engine sound explosion, and the changes in engine friction corresponding to 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 (pseudo-engine sound).

[0061] The vehicle management system 100 calculates the amount of deposits adhering to the engine interior of the virtual moving body and calculates the corresponding change in knocking sound. The vehicle management system 100 considers this change and reflects the sound in the simulated driving environment (pseudo-engine sound). The vehicle management system 100 can also reproduce, based on the amount of deposits, changes in driving characteristics caused by misfires due to spark plug deterioration and changes in driving characteristics during engine start-up.

[0062] Next, the second environmental change processing will be explained. The second environmental change processing (the second processing) is the processing that changes the simulated driving environment in response to virtual maintenance. Typically, the second processing changes the simulated driving environment discontinuously in response to virtual maintenance.

[0063] That is, the first process generates a simulated driving environment in vehicle 10 based on maintenance indicators, which is a process of changing the driving environment as the virtual vehicle moves. The second process is a process of restoring the simulated driving environment that has changed through the first process to its original state in response to virtual maintenance. By combining the first and second processes, it is possible to reproduce the changes in the driving environment that accompany the actual vehicle's movement and the process of restoring the changed driving environment through maintenance.

[0064] Reference Figure 5 For example, consider the scenario where the virtual mobile vehicle is a motorized vehicle and virtual maintenance is the replacement or replenishment of engine oil. First, consider the state where the engine oil of the virtual mobile vehicle is virtually replaced or replenished through virtual maintenance IM1 performed at time t1. Then, the sound generated by the first process gradually changes until virtual maintenance IM2 (time t2). In this case, the maintenance indicator specifying the degree of sound change can be either a simple indicator such as driving distance, or the amount of engine oil consumed in the virtual mobile vehicle obtained through simulation. In the former case, the engine oil consumption is approximated using a simple indicator, so the data volume and processing load are small. On the other hand, in the latter case, the engine oil consumption is accurately calculated through simulation, so the reliability as a maintenance indicator is high, but the data volume and processing load tend to increase. The engine oil of the virtual mobile vehicle is virtually replaced or replenished through virtual maintenance IM2 (time t2). In response to virtual maintenance IM2, the vehicle management system 100 executes the second process. Through the second process, the sound generated in the vehicle 10 changes. Figure 5 In the example, through the second process, the generated sound returns to the state immediately following the virtual maintenance IM1 (state 1). Furthermore, the state after the second process does not necessarily need to be the same as the state formed by the previous virtual maintenance.

[0065] Next, the processing flow in the second process will be explained. Figure 6A and Figure 6B This is a flowchart illustrating a series of processes associated with the second process. The processes shown in the diagram are executed repeatedly at regular intervals.

[0066] Figure 6A This is a flowchart illustrating a scenario where the vehicle management system 100 prompts the user of vehicle 10 with a notification related to whether to perform virtual maintenance (hereinafter referred to as the "maintenance notification"). Specifically, the maintenance notification includes an option to ask whether to perform virtual maintenance.

[0067] 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 this determination based on the relationship between a pre-set threshold and the current value of the maintenance indicator. For example, if the driving distance, the amount of virtual attachments, or the consumption of virtual consumables, which are maintenance indicators, exceed the threshold, it is determined that virtual maintenance is required. If virtual maintenance is determined to be required (step S11: "Yes"), the process proceeds to step S12. If virtual maintenance is determined not to be required (step S11: "No"), the process ends.

[0068] In step S12, the vehicle management system 100 sends a maintenance notification to the user. The maintenance notification may be presented visually or audibly, for example, through the user interface 150 within the vehicle 10. Alternatively, the maintenance notification may be sent to the user's personal information terminal (smartphone, tablet, PC, etc.). The user who receives the maintenance notification responds by choosing whether to have the vehicle management system 100 perform virtual maintenance.

[0069] In step S13, the vehicle management system 100 refers to the user's response to the maintenance notification. If the user selects to perform virtual maintenance (step S13: "Yes"), the process proceeds to step S14. If the user does not select to perform virtual maintenance (step S13: "No"), the process ends. The "user does not select to perform virtual maintenance" category 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.

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

[0071] Figure 6B This is a flowchart illustrating the scenario where the vehicle management system 100 does not notify the user of maintenance. In this case, there is no need to process maintenance notifications or assess user responses. Figure 6A Steps S12-13 in the process. In other words, when the vehicle management system 100 determines that virtual maintenance is required, it automatically performs virtual maintenance and the second processing without considering the user's intention.

[0072] Next, as a variation, we will illustrate an example of a notification screen for the user. Figure 7A and Figure 7B This is a schematic diagram showing an example of a maintenance notification screen. Figure 7AA basic example is shown. The screen displays a message (MSG) indicating that virtual maintenance is required. Additionally, along with the message MSG, an option to perform / not perform virtual maintenance is displayed. If the user selects "Perform," the vehicle management system 100 performs virtual maintenance and the second processing step.

[0073] Figure 7B This is another example of a prompt screen. The screen displays multiple options A through C, equivalent to "Perform Maintenance." These options A through C indicate what kind of maintenance is being performed. For example, in the case of a virtual maintenance update involving engine oil change, options A through C represent different engine oil products. The vehicle management system 100 can also change the content of the second process based on each option. Thus, users can choose various virtual maintenance options according to their preferences, thereby generating a simulated driving environment that faithfully reproduces the user's choices. For example, some options can be offered for a fee, or different prices can be set for each option. Furthermore, the number of options is not limited to... Figure 7B Examples (3).

[0074] Next, a variation of the second environmental change treatment will be described. Figure 8A and Figure 8B This is a graph illustrating several variations of the second treatment. The basic structure of the graph is similar to... Figure 5 same.

[0075] Figure 8A An example of a second process that considers the driving history of vehicle 10 is shown. The driving history includes the history of driving status information (DRV), accumulated mileage, and driving time. That is, the driving history can be said to represent how long vehicle 10 has been used up to the present and how it has been used. Figure 8A In this case, we consider the scenario where vehicle 10 has accumulated a considerable driving distance. Without considering the driving history of vehicle 10, as shown by the dashed line in the graph, a second process in response to virtual maintenance IM2a is executed. As a result, the simulated driving environment returns to the first state (i.e., the same state immediately following virtual maintenance IM1). On the other hand, considering the driving history of vehicle 10 (virtual maintenance IM2b), the simulated driving environment transitions to a second state different from the first state (the solid line in the graph). This process reproduces the phenomenon that, based on driving history, even when a typical vehicle undergoes maintenance, the driving environment does not return to the same state as during the last maintenance. Therefore, the user can faithfully and personally experience the changes in the virtual mobile body over the years corresponding to the changes in vehicle 10 through the simulated driving environment.

[0076] Figure 8BAn example of a second process that introduces the concept of a "virtual maintenance recommendation period" is shown. In this example, the vehicle management system 100 sets a virtual maintenance recommendation period (the first period in the figure) when it notifies the user of the need for virtual maintenance. When virtual maintenance is performed during the first period (virtual maintenance IM2a is performed at time t2a), as shown by the dashed line in the graph, the simulated driving environment returns to the first state through the second process. On the other hand, when virtual maintenance is performed after the first period has elapsed (virtual maintenance IM2b is performed at time t2b), the simulated driving environment transitions to a third state different from the first state (the solid line in the graph). This process reproduces the phenomenon that in a typical vehicle, if the appropriate maintenance period has passed, even if maintenance is performed, the driving environment cannot return to the original state.

[0077] Next, the reproduction of the maintenance history of the target vehicle will be explained. The vehicle management system 100 can also change the simulated driving environment in vehicle 10 based on the history of "actual" maintenance performed on vehicles that actually exist or have actually existed (target vehicles). When the maintenance history of the target vehicle is digitized, the vehicle management system 100 reads the maintenance history data (target history) of the target vehicle and records the target history to 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 "third environment change processing (third processing)". Through the third processing, for example, the maintenance history of a vehicle previously owned by a user of vehicle 10 is reproduced in vehicle 10. The user can personally experience the feeling of driving their preferred vehicle.

[0078] Next, we will explain the various application scenarios. Figure 9 This is a block diagram illustrating the on-board device 400 and management server 300 that constitute the vehicle management system 100. The on-board device 400 and the management server 300 can communicate via a communication network.

[0079] The vehicle-mounted device 400 is mounted on the vehicle 10. The vehicle-mounted device 400 includes one or more processors 401 (hereinafter referred to as processor 401), one or more storage devices 402 (hereinafter 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, special-purpose processors, CPUs, GPUs, ASICs, FPGAs, integrated circuits, conventional circuits, and / or combinations thereof. The processor 401 can also be referred to as a circuitry or processing circuitry. The storage device 402 stores 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 vehicle-mounted device 400 are realized through the cooperation of the processor 401 and the storage device 402. Program 405 is a computer program executed by the processor 401. The functions of the vehicle-mounted device 400 can also be achieved through the cooperation of the processor 401 executing program 405 and the storage device 402. Program 405 is stored in the storage device 402. Alternatively, program 405 can also be recorded to a computer-readable recording medium.

[0080] The management server 300 includes one or more processors 301 (hereinafter referred to as processors 301), one or more storage devices 302 (hereinafter 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, special-purpose processors, CPUs, GPUs, ASICs, FPGAs, integrated circuits, conventional circuits, and / or combinations thereof. The processor 301 can also be referred to as a circuit or a processing circuit. The storage device 302 stores various information. Examples of storage devices 302 include volatile memory, non-volatile memory, HDDs, SSDs, etc. The communication device 303 communicates with the on-board units 400 of the numerous vehicles 10. The functions of the management server 300 are realized through the cooperation of the processor 301 and the storage device 302. Program 305 is a computer program executed by the processor 301. The functions of the management server 300 can also be realized through the cooperation of the processor 301 executing program 305 and the storage device 302. The program 305 is stored in the storage device 302. Alternatively, the program 305 may also be recorded to a computer-readable recording medium.

[0081] The processor 401 of the vehicle-mounted device 400 and the processor 301 of the management server 300, or a combination thereof, are equivalent to Figure 1One or more processors 101 are shown. The storage device 402 of the vehicle-mounted device 400 and the storage device 302 of the management server 300, or a combination thereof, are equivalent to... Figure 1 One or more storage devices 102 are shown. The program 405 of the vehicle-mounted device 400 and the program 305 of the management server 300, or a combination thereof, are equivalent to... Figure 1 The vehicle management procedure 105 is shown in the figure.

[0082] For example, the aforementioned driving status 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 vehicle-mounted device 400. In this case, analog sound management is performed within the vehicle 10.

[0083] As another example, the sound source data management unit 120 can also be included in the management server 300. In this case, the sound source data management unit 120 manages the basic sound source data 200 used in multiple vehicles 10 together. Therefore, 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 vehicle-mounted 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. Managing the basic sound source data 200 used in multiple vehicles 10 together in the management server 300 is suitable from the viewpoint of managing the basic sound source data 200.

[0084] Next, we will explain the application of electric vehicles with a manual mode (MT mode). The electric motor used as the power unit in a typical electric vehicle has significantly different torque characteristics compared to the internal combustion engine used in a conventional vehicle (CV). Due to this difference in torque characteristics, CVs must be equipped with a transmission, whereas typical electric vehicles do not. Of course, typical electric vehicles do not have a manual transmission (MT) where the gear ratio is changed manually by the driver. Therefore, there is a significant difference in driving feel between driving a conventional vehicle with MT (hereinafter referred to as an MT vehicle) and driving an electric vehicle.

[0085] On the other hand, the torque of an electric motor can be relatively easily controlled by adjusting the applied voltage and magnetic field. Therefore, with appropriate control, the desired torque characteristics can be obtained within the operating range of an electric motor. This characteristic can be effectively utilized to control the torque of an electric vehicle and simulate the torque characteristics unique to a manual transmission (MT) vehicle. Furthermore, to provide the driver with a driving feel similar to that of an MT vehicle, a pseudo-shifter can be installed in the electric vehicle. Thus, it is possible to simulate an MT vehicle within an electric vehicle.

[0086] In other words, the electric vehicle controls the output of its electric motor to simulate the driving characteristics (torque characteristics) unique to a manual transmission (MT) vehicle. The driver operates a fake shifter to perform a simulated manual shifting operation. In response to the simulated manual shifting operation performed by the driver, the electric vehicle simulates an MT vehicle, causing a change in its driving characteristics (torque characteristics). Thus, the driver of the electric vehicle can experience a feeling similar to driving an MT vehicle. Hereinafter, the control mode of the electric motor used to simulate the driving characteristics and manual shifting operation of an MT vehicle will be referred to as "manual mode" or "MT mode".

[0087] Next, consider the case where the vehicle 10 of this disclosure is an electric vehicle 10E equipped with a MT mode. In MT mode, the electric vehicle 10E can also generate a pseudo engine sound corresponding to the driver's driving operation and output the pseudo engine sound via the speaker 70. Because not only the driving operation of the MT vehicle is reproduced, but also the engine sound of the MT vehicle is reproduced, the satisfaction of drivers who require a realistic experience is improved. Below, a structural example of the electric vehicle 10E equipped with a MT mode will be described. As examples of MT modes, "sequential shift mode" and "three-pedal mode" are shown.

[0088] Next, the first structural example (sequential shifting mode) will be explained. Figure 10 This is a block diagram illustrating a first structural example of the power control system of the electric vehicle 10E according to this embodiment. The electric vehicle 10E includes an electric motor 44, a battery 46, and an inverter 42. The electric motor 44 is a power unit for driving. The battery 46 stores electrical energy to drive the electric motor 44. That is, the electric vehicle 10E is a battery electric vehicle (BEV) that drives by the electrical energy stored in the battery 46. During acceleration, the inverter 42 converts the DC power input from the battery 46 into driving power for the electric motor 44. In addition, during deceleration, the inverter 42 converts the regenerative power input from the electric motor 44 into DC power and charges the battery 46.

[0089] The electric vehicle 10E is equipped with an accelerator pedal 22 for the driver to input acceleration requirements for the electric vehicle 10E. An accelerator position sensor 32 for detecting the accelerator opening is provided at the accelerator pedal 22.

[0090] The electric vehicle 10E is equipped with a sequential shifter 24. The sequential shifter 24 can be either a paddle shifter or a lever-type pseudo-shifter.

[0091] A paddle shifter is a virtual device, distinct from the traditional paddle shifter. It mimics the design of a paddle shifter found in clutchless manual transmission (MT) vehicles. The paddle shifter is mounted on the steering wheel. It includes upshift and downshift switches that determine the operating position. The upshift switch sends an upshift signal 34u by pulling it towards the driver's side, and the downshift switch sends a downshift signal 34d by pulling it towards the driver's side.

[0092] On the other hand, the lever-type pseudo-shifter, like the paddle shifter, is a virtual device different from the original shifter. The lever-type pseudo-shifter has a structure that mimics the lever-type shifter found in clutchless manual transmission (MT) vehicles. The lever-type pseudo-shifter is configured to output an upshift signal 34u by pushing the shift lever forward and a downshift signal 34d by pushing the shift lever backward.

[0093] A wheel speed sensor 36 is installed at the wheel 26 of the electric vehicle 10E. The wheel speed sensor 36 is used as a vehicle speed sensor to detect the speed of the electric vehicle 10E. In addition, a rotation speed sensor 38 is installed at the electric motor 44 to detect the rotation speed of the electric motor 44.

[0094] The electric vehicle 10E includes a control unit 50. Typically, the control unit 50 is an electronic control unit (ECU) mounted on the electric vehicle 10E. The control unit 50 can also be a combination of multiple ECUs. The control unit 50 includes an interface, memory, and a processor. An in-vehicle network is connected to the interface. The memory contains RAM for temporarily recording data and ROM for storing programs executable by the processor and various data associated with the programs. The program consists of multiple commands. The processor reads the program and data from the memory to execute it, generating control signals based on signals obtained from various sensors.

[0095] For example, control unit 50 controls electric motor 44 via PWM control of inverter 42. Signals are input to control unit 50 from accelerometer position sensor 32, sequential shifter 24 (which, if the sequential shifter 24 is a paddle shifter, is an upshift and downshift switch), wheel speed sensor 36, and rotational speed sensor 38. Control unit 50 processes these signals and calculates the motor torque command value used for PWM control of inverter 42.

[0096] As control modes, the control device 50 includes an automatic mode (EV mode) and a manual mode (MT mode). 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 based on the operation of the accelerator pedal 22. On the other hand, the manual mode is the control mode for driving the electric vehicle 10E like a manual transmission (MT) vehicle. The manual mode is programmed to change the output characteristics of the electric motor 44 relative to the operation of the accelerator pedal 22 based on upshifting and downshifting operations of the sequential shifter 24. This manual mode (MT mode) is equivalent to a "sequential shifting mode." The automatic mode and manual mode can be switched.

[0097] 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 can be a separate independent ECU, or the function of an ECU can be obtained by a processor executing a program recorded in memory.

[0098] The automatic mode torque calculation unit 54 has the function of calculating 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 determined based on the accelerator opening and the rotational speed of the electric motor 44. The signals from the accelerator position sensor 32 and the rotational speed sensor 38 are input as parameters to the motor torque command map. The motor torque corresponding to these signals is output according to the motor torque command map. Therefore, in automatic mode, even if the driver operates the sequential shifter 24, this operation is not reflected in the motor torque.

[0099] The manual mode torque calculation unit 56 has an MT vehicle model. The MT vehicle model is used to calculate the drive wheel torque that should be obtained by operating the accelerator pedal 22 and the sequential shifter 24 when the electric vehicle 10E is assumed to be an MT vehicle.

[0100] Reference Figure 11 To illustrate the MT vehicle model supported by the manual mode torque calculation unit 56. For example... Figure 11 As shown, the MT vehicle model includes an engine model 561, a clutch model 562, and a transmission model 563. Furthermore, the engine, clutch, and transmission, virtually implemented through the MT vehicle model, are respectively referred to as a virtual engine, a virtual clutch, and a virtual transmission. In engine model 561, the virtual engine is modeled. In clutch model 562, the virtual clutch is modeled. In transmission model 563, the virtual transmission is modeled.

[0101] Engine model 561 calculates the virtual engine rotational speed Ne and the virtual engine output torque Teout. The virtual engine rotational speed Ne is calculated based on the wheel rotational speed Nw, the overall reduction ratio R, and the slip ratio Rslip of the virtual clutch. For example, the virtual engine rotational speed Ne is represented by the following equation (1).

[0102] Equation (1): Ne = Nw × R / (1 - Rslip)

[0103] The virtual engine output torque Teout is calculated based on the virtual engine's rotational speed Ne and the accelerator opening Pap. In the calculation of the virtual engine output torque Teout, as follows... Figure 11 As shown, a mapping is used that defines the relationship between the accelerator opening Pap, the virtual engine rotational speed Ne, and the virtual engine output torque Teout. In this mapping, the virtual engine output torque Teout is given relative to the virtual engine rotational speed Ne for each accelerator opening Pap. Figure 11 The torque characteristics shown can be set to simulate those of a gasoline engine or a diesel engine. Furthermore, the torque characteristics can be set to simulate those of a naturally aspirated engine or a turbocharged engine.

[0104] Clutch model 562 calculates the torque transmission gain k. The torque transmission gain k is the gain used to calculate the degree of torque transmission of the virtual clutch corresponding to the virtual clutch opening Pc. The virtual clutch opening Pc is typically 0%, but can be temporarily opened to 100% in conjunction with the switching of virtual gears in the virtual transmission. Clutch model 562 has... Figure 11 The mapping shown is used to assign torque transfer gain k to the virtual clutch opening Pc. Figure 11 In the diagram, 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 ranges from Pc0 to Pc1 and from Pc2 to Pc3 are the insensitive regions where the torque transmission gain k does not change due to the virtual clutch opening Pc. 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 transmission gain k, as shown in equation (2).

[0105] Equation (2): Tcout=Teout×k

[0106] Additionally, clutch model 562 calculates the slip ratio Rslip. The slip ratio Rslip is used in the calculation of the virtual engine rotational speed Ne performed by engine model 561. In the calculation of the slip ratio Rslip, similar to the torque transmission gain k, a mapping of the slip ratio Rslip to the virtual clutch opening Pc can be used.

[0107] The transmission model 563 calculates the gear ratio (gear shift ratio) r. The gear ratio r is determined in the virtual transmission using the virtual gear GP. Upon upshifting by the sequential shifter 24, the virtual gear GP shifts up one gear. Conversely, upon downshifting by the sequential shifter 24, the virtual gear GP shifts down one gear. The transmission model 563 has… Figure 11 The mapping is shown. In this mapping, the gear ratio r is given for the virtual gear GP in such a way that the larger the virtual gear GP is, the smaller the gear ratio r is. The transmission model 563 uses the gear ratio r obtained from the mapping and the clutch output torque Tcout to calculate the transmission output torque Tgout. For example, as shown in equation (3), the transmission output torque Tgout is given by the product of the clutch output torque Tcout and the gear ratio r.

[0108] Equation (3): Tgout=Tcout×r

[0109] The transmission output torque Tgout varies discontinuously according to the gear ratio r. This discontinuous variation in the transmission output torque Tgout produces shift shocks, exhibiting characteristics of a vehicle equipped with a stepped transmission.

[0110] The MT vehicle model uses a predetermined reduction ratio rr to calculate the drive wheel torque Tw. 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 gear ratio r by the reduction ratio rr is the aforementioned total reduction ratio R. The MT vehicle model calculates the drive wheel torque Tw based on the transmission output torque Tgout and the reduction ratio rr. For example, as shown in equation (4), the drive wheel torque Tw is given by the product of the transmission output torque Tgout and the reduction ratio rr.

[0111] Equation (4): Tw = Tgout × rr

[0112] The control unit 50 converts the drive wheel torque Tw calculated from the MT vehicle model into a required motor torque Tm. The required motor torque Tm is the motor torque needed to achieve the drive wheel torque Tw calculated from the MT vehicle model. In the conversion from drive wheel torque Tw to required motor torque Tm, a reduction ratio from the output shaft of the electric motor 44 to the drive wheel is used. Then, the control unit 50 controls the inverter 42 and the electric motor 44 according to the required motor torque Tm.

[0113] Figure 12 This graph compares the torque characteristics of an electric motor 44 implemented using motor control in an MT vehicle model with the torque characteristics of an electric motor 44 implemented using typical motor control for an electric vehicle (EV). Based on motor control using an MT vehicle model, such as... Figure 12 As shown, based on the virtual gear set by the sequential shifter 24, torque characteristics similar to those of a manual transmission (MT) vehicle can be achieved (solid line in the figure). Furthermore, in Figure 12 In the middle, the number of gears is set to 6.

[0114] Next, the second structural example (three-pedal mode) will be explained. Figure 13 This is a block diagram illustrating a second structural example of the power control system of the electric vehicle 10E according to this embodiment. Here, only the structure different from the first structural example described above will be explained. Specifically, in the second structural example, the electric vehicle 10E has a pseudo gear lever (pseudo shifting device) 27 and a pseudo clutch pedal 28 instead of the sequential shifter 24 provided in the first structural example. The pseudo gear lever 27 and the pseudo clutch pedal 28 are ultimately just virtual objects different from the original gear lever and clutch pedal.

[0115] The pseudo-gear lever 27 has a structure that simulates the gear lever of a manual transmission (MT) vehicle. The configuration and operation of the pseudo-gear lever 27 are identical to those of an actual MT vehicle. The pseudo-gear lever 27 has positions corresponding to gears such as 1st, 2nd, 3rd, 4th, 5th, 6th, reverse, and neutral. A shift position sensor 27a is provided at the pseudo-gear lever 27 to detect the gear position by determining its location.

[0116] The dummy clutch pedal 28 has a structure that simulates the clutch pedal of a manual transmission (MT) vehicle. The configuration and operation of the dummy clutch pedal 28 are identical to those of an actual MT vehicle. The dummy clutch pedal 28 is operated when the dummy gear lever 27 is used. That is, when the driver wants to change gears using the dummy gear lever 27, they depress the dummy clutch pedal 28; when the gear change is complete, they depress the pedal and return it to its original position. A clutch position sensor 28a is provided at the dummy clutch pedal 28 to detect the amount of depressing of the dummy clutch pedal 28.

[0117] Signals from the accelerator position sensor 32, shift position sensor 27a, clutch position sensor 28a, wheel speed sensor 36, and rotational speed sensor 38 are input to the control unit 50. The control unit 50 processes these signals and calculates the motor torque command value for PWM control of the inverter 42.

[0118] Similar to the first structural example described above, the control device 50 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 based on the operation of the accelerator pedal 22. On the other hand, the manual mode is a control mode for driving the electric vehicle 10E, such as a manual transmission (MT) vehicle. The manual mode is programmed to change the output and output characteristics of the electric motor 44 relative to the operation of the accelerator pedal 22 based on the operation of the dummy clutch pedal 28 and the dummy gear lever (dummy shifting device) 27. This manual mode (MT mode) is equivalent to a "three-pedal mode." The automatic mode and manual mode can be switched.

[0119] The manual mode torque calculation unit 56 has a vehicle model and in Figure 11 The same applies as shown in the diagram. However, the virtual clutch opening Pc is replaced by the amount of depressing of the dummy clutch pedal 28 detected by the clutch position sensor 28a. Furthermore, the virtual gear GP is determined by the position of the dummy shift lever 27 detected by the shift position sensor 27a.

Claims

1. A vehicle management system applied to a vehicle, characterized in that it comprises: One or more processors are configured to create a simulated driving environment that generates a driving environment that simulates a virtual moving object; as well as Virtual maintenance refers to maintenance performed virtually on the virtual mobile entity. Wherein, the one or more processors are configured to perform a first environment change process to change the simulated driving environment based on maintenance indicators representing the necessity of the virtual maintenance, and, The one or more processors are configured to perform a second environment change process that at least corresponds to the virtual maintenance and causes a change in the simulated driving environment.

2. The vehicle management system according to claim 1, characterized in that, The one or more processors are further configured to determine whether to perform the virtual maintenance based on the maintenance metrics.

3. The vehicle management system according to claim 1, characterized in that, The one or more processors are further configured to prompt the user of the vehicle with a notification based on the maintenance metrics, including an option to ask whether to perform the virtual maintenance.

4. The vehicle management system according to claim 3, characterized in that, The notification also includes options to indicate the content of the virtual maintenance.

5. The vehicle management system according to claim 3, characterized in that, The one or more processors are further configured to change the degree of change in the simulated driving environment based on the second environmental change processing when the virtual maintenance is performed during the first period and when the virtual maintenance is performed after the first period.

6. The vehicle management system according to any one of claims 1 to 5, characterized in that, The one or more processors are configured to perform the second environmental change processing in correspondence with the virtual maintenance and the vehicle's driving history.

7. The vehicle management system according to any one of claims 1 to 5, characterized in that, Virtual consumables are consumables that are virtually consumed during the virtual movement of the virtual mobile entity, and... The virtual maintenance includes replenishing or replacing the virtual consumables.

8. The vehicle management system according to claim 7, characterized in that, The maintenance metrics include the consumption of the virtual consumables.

9. The vehicle management system according to any one of claims 1 to 5, characterized in that, Virtual attachments are objects that are virtually attached to the virtual moving body as it moves virtually. The virtual maintenance includes removing the virtual attachments.

10. The vehicle management system according to claim 9, characterized in that, The maintenance metrics include the amount of virtual attachments.

11. The vehicle management system according to any one of claims 1 to 5, characterized in that, The simulated driving environment includes vibrations that are virtually generated as the virtual vehicle moves.

12. The vehicle management system according to any one of claims 1 to 5, characterized in that, It also includes one or more storage devices configured to record the actual maintenance history of the target vehicle, i.e., the target history. The one or more processors are further configured to perform a third environment change process to change the simulated driving environment based on the object history.

13. A method for controlling a vehicle, characterized in that, include: A simulated driving environment was generated that simulated the driving environment of a virtual mobile object; The virtual mobile body is virtually maintained; A first environmental change process is performed to alter the simulated driving environment based on maintenance indicators representing the necessity of the virtually implemented maintenance. as well as Perform a second environmental change process that alters the simulated driving environment in accordance with at least the virtual maintenance.

14. An electric vehicle that uses an electric motor as a power unit for driving, characterized in that, This includes one or more processors that constitute a simulated driving environment that generates a driving environment that simulates a virtual moving body. in, Virtual maintenance refers to maintenance performed virtually on the virtual mobile body. The one or more processors are configured to perform a first environment change process to alter the simulated driving environment based on maintenance metrics indicating the necessity of the virtual maintenance, and... The one or more processors are configured to perform a second environment change process that at least corresponds to the virtual maintenance and causes a change in the simulated driving environment.

Images