System and method for optimizing vehicle performance using machine learning

Abstract

To meet the need for a vehicle-performance optimization system that is simple for an end user to operate while enabling implementation of machine learning.SOLUTION: A method, a system, and an apparatus for optimizing vehicle performance are provided. The method includes the steps of: receiving vehicle-state data before operating a vehicle; generating input data for a machine-learning (ML) model on the basis of the vehicle-state data, the ML model being configured to output at least one of predicted vehicle performance and a predicted vehicle parameter on the basis of the vehicle-state data; proposing an optimized vehicle parameter by the ML model on the basis of the input data; and sending an instruction to tune the vehicle on the basis of the optimized vehicle parameter.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] Systems and methods consistent with exemplary embodiments of the present disclosure relate to optimizing vehicle performance using machine learning techniques. [Background technology]

[0002] In related technology, a vehicle operator and a vehicle mechanic may work together to tune a vehicle to optimize the vehicle's operating performance (e.g., to improve the vehicle's acceleration time, engine stability, etc.). In particular, in the case of vehicle operation for motorsports, the vehicle operator may provide feedback regarding the vehicle's performance based on the current conditions of the racetrack (e.g., surface type, surface condition, weather, temperature, humidity, wind direction, wind speed, etc.) as well as subjective performance details (speed, stability, etc.). Sensors (e.g., speedometer, camera, etc.) that may be implemented on the vehicle may provide the feedback automatically. The vehicle mechanic may interpret this feedback and make tuning adjustments to the vehicle accordingly (e.g., software-based adjustments to the electronic control unit (ECU) or hardware-based adjustments to the vehicle's physical components (such as suspension, tire pressure, etc.)). The process of the vehicle operator providing feedback to the vehicle mechanic is then repeated so that vehicle performance can ultimately be optimized.

[0003] Related techniques are exhaustive because they require human interpretation of the data. For example, a vehicle mechanic may misinterpret the data and suggest an incorrect tuning adjustment, which may not be identified as incorrect until the next iteration when the vehicle operator provides feedback. This can result in excessive time required to achieve optimal vehicle performance.

[0004] Although software modeling may be implemented to optimize vehicle performance, it does not implement machine learning (ML) models, particularly large-scale language models (LLMs). Furthermore, such software modeling requires technical software knowledge, making it difficult for vehicle operators or vehicle mechanics to understand how to use it.

[0005] In related techniques, rule-based simulation software is used to search for the best tuning adjustments by repeatedly simulating physical and mechanical phenomena, which requires large computational resources and time, making it difficult to obtain optimal tuning adjustments from input data in a timely manner.

[0006] Therefore, there is a need for a vehicle performance optimization system that is simple for end users to operate, yet capable of implementing machine learning. Summary of the Invention

[0007] According to one or more exemplary embodiments, an apparatus and method for optimizing vehicle performance are provided. In particular, the apparatus and method according to the exemplary embodiments perform the steps of receiving vehicle state data before operating the vehicle, generating input data for a machine learning (ML) model based on the vehicle state data, the ML model being configured to output at least one of predicted vehicle performance or vehicle parameters based on the vehicle state data, obtaining optimized vehicle parameters based on the input data based on the ML model, and transmitting instructions for tuning the vehicle based on the optimized vehicle parameters.

[0008] According to an embodiment, the vehicle state data includes a first report from a vehicle driver indicating the state of the vehicle driver and a second report from a vehicle mechanic indicating the state of the vehicle, and generating input data for the ML model includes converting the first report and the second report into machine-readable parameters using a large-scale language model (LLM).

[0009] According to an embodiment, the step of obtaining optimized vehicle parameters includes a step of interacting with at least one of a driver and a vehicle mechanic via a chat interface, the chat interface being configured to iteratively suggest optimized vehicle states and optimized vehicle parameters from the LLM based on predicted vehicle performance.

[0010] The step of sending instructions to tune the vehicle includes sending first instructions to an electronic control unit (ECU) of the vehicle to tune software-related parameters of the vehicle, and sending second instructions to a vehicle mechanic to tune hardware-related parameters of the vehicle, wherein the second instructions are generated as an instruction manual using the LLM.

[0011] According to an embodiment, the method further includes receiving vehicle performance data after operating the vehicle; generating, using the LLM, a Requirements as Code (RaC) file based on the vehicle performance data; generating simulated vehicle data based on the RaC file; and training an ML model based on the simulated vehicle data.

[0012] The step of training the ML model is further based on actual vehicle data from vehicle performance data, where the vehicle performance data includes feedback from a vehicle driver, sensor data from the vehicle, and feedback from a vehicle mechanic, and the actual vehicle data corresponds to the sensor data.

[0013] The RaC file includes a file identifier that identifies the RaC file, driver information that identifies the vehicle driver and the vehicle driver's state, vehicle information that identifies the vehicle model and the vehicle's state, metrics information that defines one or more metrics related to the vehicle's performance and criteria for meeting the one or more metrics, and environmental conditions during operation of the vehicle.

[0014] According to an embodiment, the method further includes evaluating the ML model based on the simulated vehicle data and / or the actual vehicle data, and deploying the trained ML model based on evaluating that the ML model satisfies one or more metrics in the RaC file.

[0015] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be realized by practice of the illustrated embodiments of the present disclosure. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 is a diagram of exemplary components of an apparatus according to an exemplary embodiment. [Figure 2] FIG. 2 is a block diagram illustrating a system architecture for vehicle optimization according to one or more exemplary embodiments. [Figure 3] FIG. 3 is a block diagram illustrating interactions within a server in accordance with one or more exemplary embodiments. [Figure 4] FIG. 4 is a block diagram illustrating a data flow for training and evaluating a machine learning model, according to one or more exemplary embodiments. [Figure 5] FIG. 5 is a diagram illustrating an exemplary structure of a Requirements-as-Code (RaC) file, according to one or more embodiments. [Figure 6A] FIG. 6A is a flowchart illustrating a method for optimizing vehicle performance including a driver, a vehicle, a vehicle mechanic, and a server according to one or more exemplary embodiments. [Figure 6B] FIG. 6B is a flowchart illustrating a method for optimizing vehicle performance including a driver, a vehicle, a vehicle mechanic, and a server according to one or more exemplary embodiments. [Figure 6C] FIG. 6C is a flowchart illustrating a method for optimizing vehicle performance including a driver, a vehicle, a vehicle mechanic, and a server according to one or more exemplary embodiments. [Figure 7] FIG. 7 is a flow chart diagram illustrating a method for receiving optimized vehicle tuning parameters according to one or more embodiments. [Figure 8] FIG. 8 is a flowchart diagram illustrating a method for training a machine learning model according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0017] The features, advantages, and significance of exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements, and in which:

[0018] The following detailed description of exemplary embodiments refers to the accompanying drawings. The present disclosure provides illustration and description, but is not intended to be exhaustive or to limit one or more exemplary embodiments to the precise form disclosed. Modifications and variations are possible in light of the disclosure or may be acquired from practice of one or more exemplary embodiments. Furthermore, one or more features or components of one exemplary embodiment may be incorporated into or combined with another exemplary embodiment (or one or more features of another exemplary embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it will be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be rearranged.

[0019] It will be apparent that the systems and / or methods and / or non-transitory computer-readable storage media described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods does not limit one or more exemplary embodiments. Thus, the operation and behavior of the systems and / or methods and / or non-transitory computer-readable storage media will be described herein without reference to specific software code. It will be understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0020] Although particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible example embodiments. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim set forth below may depend directly on only one claim, the disclosure of possible example embodiments includes each dependent claim in combination with all other claims in the claim set.

[0021] No element, act, or instruction used herein should be construed as critical or essential unless expressly described as such. Also, as used herein, the terms "have," "having," "include," "including," or equivalents thereof are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0022] As used herein, the term "software component" refers to an individual component or unit of software that implements one or more features. These software components depend on other software components. Multiple software components having the same software component type may be provided. Specifically, the type of a software component indicates what the software component is intended for (e.g., SDK, integration, system testing, etc.). Each of these software component types has standards (e.g., ISO standards) that must be passed for the software component to pass a particular development stage (e.g., the coverage stage, where the user still intends to collect and evaluate only code coverage metrics). These standards are evaluated in terms of metrics. According to some embodiments, each software component has an identifier, including, but not limited to, a version number and a function name.

[0023] 1 is a diagram of exemplary components of a device 100. As shown in FIG. 1, the device 100 includes a bus 110, a processor 120, a memory 130, a storage component 140, an input component 150, an output component 160, and a communication interface 170.

[0024] Bus 110 includes components that enable communication between components of device 100. Processor 120 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 120 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or another type of processing component. In one or more exemplary embodiments, processor 120 includes one or more processors that are programmable to perform functions. Memory 130 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 120.

[0025] Storage component 140 stores information and / or software related to the operation and use of device 100. For example, storage component 140 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. Input component 150 includes components (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that enable device 100 to receive information, for example, via user input. Additionally or alternatively, input component 150 may include sensors for detecting information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 160 includes components (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)) that provide output information from device 100.

[0026] Communication interface 170 includes, for example, transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 100 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. Communication interface 170 enables device 100 to receive information from and / or provide information to other devices. For example, communication interface 170 includes, but is not limited to, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.

[0027] Device 100 may perform one or more of the example processes described herein. According to one or more example embodiments, device 100 performs these processes in response to processor 120 executing software instructions stored by a non-transitory computer-readable medium, such as memory 130 and / or storage component 140. A computer-readable medium is defined herein as a non-transitory memory device. A memory device may include memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0028] The software instructions may be loaded into memory 130 and / or storage component 140 from another computer-readable medium or from another device via communication interface 170. When executed, the software instructions stored in memory 130 and / or storage component 140 cause processor 120 to perform one or more of the processes described herein.

[0029] Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more of the processes described herein. Thus, one or more exemplary embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0030] The number and arrangement of components shown in Figure 1 are provided as an example. In fact, device 100 may include additional components, fewer components, different components, or components arranged differently than those shown in Figure 1. Additionally or alternatively, one set of components (e.g., one or more components) of device 100 may perform one or more functions that are described as being performed by another set of components of device 100.

[0031] 2 is a block diagram illustrating a system architecture for vehicle optimization according to one or more exemplary embodiments. A server 200, a driver's portable device 210, a vehicle 220, a mechanic's portable device 230, and external sensors 240 are provided, each implemented by a device such as device 100.

[0032] The server 200 is responsible for collecting data from the driver's portable device 10, the vehicle 220, the mechanic's portable device 230, and external sensors 240. The server 200 can interpret the collected data (e.g., using machine learning techniques) and provide instructions to tune the vehicle's hardware (HW) and software (SW) accordingly.

[0033] The driver's portable device 210 is operated by a driver 211, and the mechanic's portable device 230 is operated by a vehicle mechanic 231. The driver 211 is responsible for driving the vehicle 220, and the vehicle mechanic 231 is responsible for maintaining, monitoring, and tuning the vehicle 220. The driver's portable device 210 and the mechanic's portable device 230 are typically implemented using mobile phones (e.g., smartphones), although in some examples, the mobile devices are implemented using various computing devices such as, but not limited to, tablets, vehicle consoles, laptops, desktop computers, etc. A user of the mobile device (e.g., the driver or vehicle mechanic) can provide input using various methods, including, but not limited to, a physical keyboard, a touchscreen, or voice (using speech-to-text interpretation). While two separate mobile devices are shown in FIG. 2, it should be understood that in some examples, these may be the same mobile device.

[0034] The driver 211 can interact with the driver's portable device 210 (e.g., via a GUI) to report driving conditions before a drive or to provide a feedback report after a drive. For example, the driving conditions include the driver's condition (e.g., the driver's attention, health, vision, etc.). In some embodiments, the driving conditions include sensor data obtained from a health meter and the driver's portable device 210, or a health report generated by a medical professional through an interview with the driver. According to some embodiments, the driving conditions include driving constraints for the day. In some embodiments, the driving conditions include performance metric priorities. The driving feedback report includes the driver's condition and can also include sensor data taken from the vehicle during the drive (e.g., graphs showing speed performance, fuel level, engine temperature, etc.). According to embodiments, this is automatically collected from the vehicle 220 or manually entered by the driver 211. The report is provided in a natural language format, particularly a language that is easily interpretable by humans. According to embodiments, the report may be provided in the form of a checklist. The driver's portable device 210 can transmit these reports to the server 200.

[0035] The vehicle 220 includes a receiver for receiving instructions (e.g., messages) from the server 200, based on which the vehicle can automatically tune software-related parameters (e.g., electronic / power and / or engine-related settings). An electronic control unit (ECU) in the vehicle 220 can be used to tune the SW parameters. The vehicle also has other hardware (HW) that needs to be tuned directly by the vehicle mechanic 231. The vehicle 220 is also equipped with sensors for collecting vehicle sensor data (e.g., speedometer data) and sending them to a sensor data collector in the server 200.

[0036] Vehicle mechanic 231 can interact with mechanic's portable device 230 (e.g., via a GUI) to provide a pre-drive vehicle condition report (e.g., tire pressure, suspension height, etc.). The report is provided in a natural language format. According to embodiments, the report may be provided in the form of a checklist. Mechanic's portable device 230 can transmit these reports to server 200. Mechanic's portable device 230 can receive instructions from server 200 (e.g., in the format of a natural language instruction manual) to tune the vehicle hardware. Vehicle mechanic 231 can interpret the instructions and tune the vehicle hardware of vehicle 220 accordingly. Although not shown in FIG. 2 , it should be understood that vehicle mechanic 231 can also provide a post-drive vehicle condition feedback report. According to embodiments, vehicle mechanic 231 can provide a feedback report via mechanic's portable device 230 about the quality of the instructions received from server 200 (e.g., with respect to readability, accuracy of instructions, etc.) so that server 200 can improve the quality of the instructions in the future. In some embodiments, the vehicle mechanic 231 can provide information about vehicle tuning constraints via the mechanic's portable device 230 prior to driving.

[0037] External sensors 240 are configured to measure data related to conditions external to vehicle 220 and transmit the collected sensor data to server 200. According to an embodiment, external sensors 240 are separate from the vehicle or part of the vehicle, depending on the particular implementation. External sensors 240 may also collect data related to the vehicle environment (e.g., weather, humidity, etc.).

[0038] FIG. 3 is a block diagram illustrating interactions within a server 300 according to one or more exemplary embodiments. Server 300 corresponds to server 200 as illustrated in FIG. 2 above. Server 300 implements at least two machine learning (ML) models. In particular, a main ML model 310 (also referred to herein as “model X310”) is provided that is configured to receive software / hardware-related input vehicle parameters, vehicle / driver states, and output predictions of vehicle performance for each vehicle state and driver state, so that a vehicle mechanic, a driver, and a large-scale language model (LLM) can efficiently search for the best parameters and states for optimizing vehicle performance. Vehicle performance may include lap times, balance, air resistance, cornering stiffness, vehicle fuel economy, or driver satisfaction scores. According to one embodiment, model X310 directly outputs tuning parameters to optimize vehicle performance. A large-scale language model (LLM) 320 (also referred to herein as "Model Y 320") is provided to convert unstructured data written in natural language into structured data (e.g., machine-interpretable code, text data, yaml files, table data, etc.) and convert structured data into unstructured data.

[0039] According to an embodiment, a driving condition report (e.g., from the driver's portable device 210 from FIG. 2 above) and / or a vehicle condition report (e.g., from the mechanic's portable device 230 from FIG. 2 above) before driving are converted from natural language to machine-interpretable code by model Y 320. A sensor data collector 370 collects sensor data from external sensors (e.g., external sensors 240 from FIG. 2 above) as well as vehicle sensors disposed on the vehicle, and the collected sensor data is also converted to machine-interpretable code by model Y 320. Thus, model input data 361 is generated based on the machine-interpretable code to be used as input for model X 310.

[0040] Based on the model input data 361 (representing inputs related to vehicle and driver states) and the deployed version of model X 310, the model inference server 360 can output / determine as predicted output 362 the vehicle's hardware (HW) and software (SW) related parameters that need to be tuned to optimize the vehicle's performance.

[0041] Once the tuning parameters are determined in the predicted output 362, instructions are sent to tune the vehicle for more optimal performance. This is done by processing the predicted output 362 into an appropriate format using the model Y 320. The SW parameters are sent directly to the vehicle's ECU for tuning. On the other hand, the HW parameters are not automatically adjusted / tuned by the vehicle, but rather need to be addressed by a vehicle mechanic. Thus, the model Y 320 interprets the tuning parameters in terms of the HW parameters and provides instructions in natural language, e.g., in the form of an instruction manual. For example, the model Y 320 provides instructions for the vehicle mechanic, such as how to adjust tire pressure, including which tools to use. It is contemplated that a portable device belonging to the vehicle mechanic (e.g., the mechanic's portable device 230) or some other device may be used to receive the instruction manual.

[0042] According to an embodiment, a chat interface 380 is provided on the server 300 for interacting with a chat GUI on a vehicle mechanic's portable device (e.g., the mechanic's portable device 230) for tuning the vehicle. In particular, the chat interface 380 communicates with the model Y 320 to assist the vehicle mechanic in searching for the best parameters and conditions for tuning the vehicle (e.g., providing advice on how to perform a particular step, suggesting the best tuning parameters and conditions, suggesting tuning parameters that are most sensitive to performance metrics, providing feedback on the mechanic's suggested parameters and conditions, etc.). According to an embodiment, an instruction manual can also be provided through the chat interface. It should be understood that the driver's portable device (e.g., the driver's portable device 210) may include a chat GUI for other purposes (e.g., driver assistance-related). Additionally, the chat interface 380 may be implemented to allow the vehicle driver and the vehicle mechanic to provide reports.

[0043] According to an embodiment, the feedback report received after driving is converted by the model Y 320 from natural language into structured data (e.g., machine-interpretable code, text data, a YAML file, table data, etc.), hereinafter referred to as a requirements-as-code (RaC) file 331. The RaC file contains information about the requirements (e.g., what output is expected to be provided by the server 300 or the model X 310, what the performance criteria for the output are, what the driving conditions are for that day, what constraints (tuning parameter constraints) need to be taken into account, etc.). For example, the RaC file is a coded file that includes a file identifier that identifies the RaC file, driver information that identifies the vehicle driver and the vehicle driver's state, vehicle information that identifies the vehicle model, vehicle identification number (VIN), and vehicle state, metrics information that defines one or more metrics related to the vehicle's performance and criteria for satisfying the one or more metrics, and the environmental conditions during vehicle operation. This file can be easily interpreted by a computer.

[0044] The RaC file is stored, for example, in the RaC database 330. The RaC file is used to generate simulated data 352 using the simulator 340 according to the information in the RaC file (e.g., requirements, constraints, conditions, vehicle information, driver information). For example, a simulation is performed using the simulator 340 to simulate vehicle performance (e.g., a lap around a racetrack) under multiple conditions (including, but not limited to, conditions that may occur during actual driving) based at least on conditions (relating to the environment) that may occur or existed during actual driving. In some embodiments, the simulator 340 generates simulated data 352 including simulation results for all possible combinations of conditions under the requirements described in the RaC file. The simulated data 352 is collected in a database to be used to train and evaluate the model X 310. In some embodiments, the RaC file may be used to define test metrics and criteria used by the model evaluator 312 (described below).

[0045] Actual data 351 (e.g., vehicle sensor data collected during driving and received from the vehicle driver's mobile device) is received from sensor data collector 370, directly from the vehicle's sensor data collector. Thus, the combination of actual data 251 and simulated data 352 forms main dataset 350, which is used to generate a specific dataset for training and evaluating model X 310. In some embodiments, the actual data 351 is additionally included in the information in the RaC file for more accurate simulation (e.g., closer to the actual data) and to define accurate test criteria for model X according to the actual data 351.

[0046] The main dataset 350 is utilized to generate a training dataset used by the model trainer 311 to train the model X310. The training dataset is used as input data by the model trainer 311 and also as ground truth data corresponding to the output of the model X310. Training the model X310 is intended to further optimize the model X310's ability to translate driving / vehicle states into vehicle performance and / or tuning parameters. After training, the trained model X310 is evaluated by the model evaluator 312 (the term "evaluated" is used interchangeably with the term "tested" in the following specification) to check whether the metrics and criteria defined in the RaC file 331 (received from the RaC database 330) are met. The model evaluator 312 can use an evaluation dataset (the "evaluation dataset" is also referred to as the "test dataset") generated from the main dataset 350 to perform the evaluation.

[0047] After evaluating the trained model X310, the model evaluator 312 determines that the metrics and criteria are met. In this case, the model deployer 313 deploys an updated version of the trained model X310 to the model inference server 360. According to some embodiments, a first portion of the metrics and criteria from the RaC file is used to determine whether the model is deployable, and a second portion of the metrics and criteria from the RaC file is not used to determine whether the model is deployable. For example, when the RaC file includes 1) a metric of the difference between the ground truth data and the best spring force time prediction result and 2) a metric of the spring force time relative to the target spring force time, only 1) should be used to determine whether the model is deployable, and 2) may not be used to determine whether the model is deployable. This is because, for example, according to some embodiments, the prediction accuracy measured by 1) is only important for determining whether the model is deployable.

[0048] Once the model is deployed, it is used to predict vehicle performance and / or optimized vehicle parameters from input parameters generated by model Y 320 according to input from the vehicle mechanic, the driver, and sensor data. Prior to deployment, the optimized vehicle parameters and predicted outcomes are provided to the vehicle 220, the vehicle mechanic via the portable device 230, and the vehicle driver 211 via the device 210. If the trained model is not deployed because metrics and criteria are not met, the trained model is not used to predict outcomes provided thereto. The performance of model X 310, which determines the optimized vehicle parameters for tuning, can be improved through feedback using an ML training / evaluation process.

[0049] FIG. 4 is a block diagram illustrating a data flow for training and evaluating a machine learning model, according to one or more exemplary embodiments.

[0050] A RaC file 400 (such as the RaC file 331 shown above in FIG. 2) is used as input for a simulation scenario generator 401. Metric types and criteria, as well as vehicle information, driver information, environmental conditions, and environmental constraints, are used to create a scenario for simulating driving. Thus, a simulation scenario 402 can be generated as input to a simulator 403 to generate simulated data 410 based on simulating driving using the conditions specified in the simulation scenario 402. The simulated data 410 is stored in a database.

[0051] The database of actual data 411 contains actual data based on actual driving. For example, the actual data is received automatically from sensors disposed in the vehicle or is manually entered after driving. The combination of the simulated data 410 and the database of actual data 411 forms the training and evaluation dataset 420 that is used to generate values ​​for model inputs 421 or ground truth data 422. That is, the model inputs 421 are used as direct inputs to model X 430, and the ground truth data 422 (of model inputs 421) is used to validate the output of model X 430.

[0052] According to an embodiment, model input values ​​421 are input to model X 430. Model output 431 will be the prediction made by model X 430. Model output 431 is compared to ground truth data 422 using loss calculator 432, and based on the difference between the prediction in model output 431 and the ground truth data 422, model trainer 433 can adjust model X 430 so that the predictions become more accurate.

[0053] According to an embodiment, the model inputs 421 include, but are not necessarily limited to, external parameters such as driving course, driver ID, driver state, driver skill, time of day, weather, wind speed, wind direction, temperature, atmospheric pressure and humidity, vehicle hardware parameters such as vehicle hardware type, ride height, spring force gradient, anti-roll bar stiffness, bump stops, toe, camber, overall grip related to the vehicle suspension and vehicle dynamics, and vehicle software parameters.

[0054] According to an embodiment, model output values ​​(as part of model output 431) include, but are not necessarily limited to, lap time, handling, balance, ride height, air resistance, downforce, tire cornering stiffness, Z-force, and driver satisfaction score.

[0055] It should be reiterated that the above list of model input and output parameters is merely exemplary, and other parameters are possible depending on the particular implementation.

[0056] FIG. 5 is a diagram illustrating an exemplary structure of a requirements-as-code (RaC) file 500 according to one or more embodiments.

[0057] Requirement ID 501, requirement summary 502, and requirement description 503 are used to enable a system administrator to quickly understand what a particular RaC file 500 is used for (e.g., which scenario it represents). Requirement ID 501 is any unique identifier including numbers, alphabets, and special characters (e.g., XYZ-1234) used to uniquely identify RaC file 500. Requirement summary 502 is a concise description of what RaC file 500 is used for, and requirement description 503 is a detailed version of requirement summary 502. Requirement summary 502 and requirement description 503 are written in natural language.

[0058] The driver information 510 includes a driver ID 511 and a driver status 512. The driver ID 511 is any unique identifier including numbers, alphabets, and special characters (e.g., XYZ-1234) used to uniquely identify a driver. The driver status 512 is one or more parameters related to the driver's condition (e.g., the driver's fatigue level, body temperature, weight, etc.). The driver information 510 includes other information related to the driver (e.g., health condition for that day, driving preferences for that day, etc.).

[0059] Vehicle information 520 includes vehicle model 521, vehicle ID 522, and vehicle status 523. Vehicle model 521 identifies the specific make and model of the vehicle. Vehicle ID 522 is any unique identifier including numbers, letters, and special characters (e.g., XYZ-1234) used to uniquely identify a vehicle, or more specifically, a VIN. Vehicle status 523 is one or more parameters related to the state of the vehicle (e.g., the vehicle's tire pressure, weight, suspension height, fuel level, etc.).

[0060] In some embodiments, vehicle information 520 also includes other information about the vehicle. For example, vehicle information 520 may include information about constraints on the vehicle, including value constraints on tunable parameters of the vehicle.

[0061] Metric Types and Criteria 530 defines one or more metric types (531-1, 531-2, ..., 531-N) and metric criteria (532-1, 532-2, ..., 532-N). The metric types (531-1, 531-2, ..., 531-N) indicate what kind of metrics are being checked. For example, lap time is a metric type. As another example, the difference between ground truth data and the predicted result of lap time may be a metric type. As another example, best spring force gradient may be a metric type. As another example, the difference between ground truth data and the predicted result of best spring force gradient may be a metric type. For yet another example, acceleration rate may be a metric type. The metric criteria (532-1, 532-2, ..., 532-N) indicate specific conditions that must be met for the corresponding metric type. For example, if lap time is a type of metric, the metric criterion for lap time is "120 seconds or less." For example, if acceleration rate is a type of metric, the metric criterion is acceleration rate going from 0 to 60 mph in less than 5 seconds. According to an embodiment, the metric may be the regression error between the model output and the ground truth of the model output value (e.g., as shown in FIG. 4). For example, if the difference between the ground truth data and the predicted result of lap time is a type of metric, the metric criterion for the difference is "1.0 second or less."

[0062] Conditions 540 (environmental conditions) define external conditions related to the location where the vehicle is being driven. Examples include road surface 541, road surface condition 542, temperature 543, humidity 544, wind direction 545, wind speed 546, and weather 547. However, it should be understood that this is a non-exhaustive list and other types of conditions may be included. In some embodiments, the value of the condition is a specific value (e.g., when the condition is temperature, 10°C (Celsius)). In some embodiments, the value of the condition is a range value (e.g., when the condition is temperature, 10°C < temperature < 20°C).

[0063] 6A, 6B, and 6C are flow chart diagrams illustrating a method for optimizing vehicle performance including a driver, a vehicle, a vehicle mechanic, and a server, according to one or more embodiments. Although not explicitly shown, the driver and vehicle mechanic perform operations to communicate with the server via mobile devices (see FIG. 2).

[0064] 6A , in operation S601, driving conditions (including the conditions for that day) are checked and reported by the driver before driving. Similarly, in operation S602, a vehicle mechanic checks and reports the vehicle's conditions before driving. In some embodiments, the vehicle mechanic and driver write their reports via a GUI on a mobile device. In some embodiments, the vehicle mechanic and driver handwrite the reports on paper, and the reports are scanned via optical character recognition (OCR) on the mobile device. The reports sent in operations S601 and S602 are combined and received by a server in operation S603. In some embodiments, the driver provides a report including information about the driving constraints for that day. In some embodiments, the vehicle mechanic provides a report including information about the vehicle's tunable parameter constraints for that day.

[0065] In operation S604, the server uses model Y (eg, model Y 320) to convert the report into input data for model X (eg, model X 310).

[0066] In operation S605, an inference server implementing model X is used to infer optimized tuning parameters for the predicted performance under the given conditions and tuning performance, or conditions received from the report. This is done by inputting the input data from operation 604 into the inference server implementing model X (e.g., model inference server 360 having deployed model X deployed by model deployer 313), and inferring optimized parameters from this.

[0067] In operation S606, the driver and vehicle mechanic can view the predicted performance and optimized parameters and provide feedback (e.g., via a chat interface). In operation S607, the server receives the feedback.

[0068] In some embodiments, the Model Y may also provide suggestions to the driver and vehicle mechanic as to whether the predicted performance and / or optimized parameters (output values) are acceptable according to the metric information and criteria 530 in RaC file 500 so that the driver and vehicle mechanic can provide feedback in response to the suggestions.

[0069] If the predicted performance and / or optimized parameters (output values) are determined to be unacceptable, then operations S604-S607 are repeated until input data generation for Model X via Model Y in operation S604 corrects the model inputs and is deemed acceptable by the driver, vehicle mechanic, and Model Y.

[0070] If the output values ​​are determined to be acceptable, then in operation S608 the final HW and SW parameters are determined.

[0071] 6B, in operation S609, the vehicle SW parameters are transferred to the vehicle. In operation S612, the vehicle receives the SW parameters, and in operation S613, the vehicle SW parameters are updated (e.g., via the ECU).

[0072] In operation S610 (performed simultaneously with or after operation S609), model Y generates an instruction manual for tuning the vehicle HW. In operation S614, a vehicle mechanic receives the instruction manual (e.g., via the vehicle mechanic's mobile device or via a received file such as a text or PDF file that is manually printed out). In operation S615, the vehicle mechanic tunes the vehicle HW based on the instruction manual received in operation S614 so that the HW parameters are satisfied.

[0073] In operation S616, once the vehicle is tuned, a drive is performed. Thereafter, in operation S617, the driver writes a feedback report of the drive, in operation S618, the vehicle collects a sensor log of vehicle data from the drive, and in operation S619, the vehicle mechanic writes a feedback report of the vehicle's condition. In some embodiments, the vehicle mechanic's report includes feedback on the quality of the instruction manual. According to embodiments, the format of the feedback report is similar to or different from that of the pre-drive. In operation S620, an external sensor log is collected at the server. Operations S617-S620 may be performed in any order. In operation S621, the feedback and sensor data from operations S617-S620 are received by the server.

[0074] 6C , in operation S622, model Y is used to generate an RaC file or update an existing RaC file in the RaC database. In operation S623, the simulator generates simulated data based on the RaC file in a main dataset that is used to train and evaluate (test) model X. In operation S624, training data and evaluation (test) data are prepared based on the main dataset. In some embodiments, model Y updates itself according to feedback from drivers and vehicle mechanics to improve the quality of the instruction manuals provided to vehicle mechanics and the quality of the chat.

[0075] In operation S625, training is performed on model X using the training data prepared in operation S624. In operation S626, evaluation is performed using the evaluation data prepared in operation S624, and in particular, the evaluation checks whether metrics from the RaC file are satisfied. If the metrics are satisfied (e.g., the metrics pass the criteria), then in operation S627, the updated model X is deployed to the inference server.

[0076] FIG. 7 is a flow chart diagram illustrating a method 700 for receiving optimized vehicle tuning parameters, according to one or more embodiments.

[0077] In operation S710, vehicle condition data is received before operating the vehicle. The vehicle condition data includes a first report from a vehicle driver indicating the condition of the vehicle driver and a second report from a vehicle mechanic indicating the condition of the vehicle. Generating input data for an ML model (e.g., Model X) includes converting the first report and the second report into machine-readable parameters using a large-scale language model (LLM) (e.g., Model Y). The parameters include either or both continuous values, such as floating-point values, or discrete values, such as categorical variables. The ML model is configured to output at least one of predicted vehicle performance or vehicle parameters based on the vehicle condition data.

[0078] In operation S720, input data for a machine learning model is generated based on the vehicle condition data received in operation S710.

[0079] In operation S730, the ML model suggests optimized vehicle parameters based on the input data generated in operation S720. According to an embodiment, this includes interaction by at least one of the driver and the vehicle mechanic with a chat interface, which is configured to iteratively suggest optimized vehicle states and optimized vehicle parameters from the LLM based on predicted vehicle performance.

[0080] In operation S740, instructions for tuning the vehicle are transmitted based on the optimized vehicle parameters inferred in operation S730. First instructions for tuning software-related parameters of the vehicle are transmitted to an electronic control unit (ECU) of the vehicle, and second instructions for tuning hardware-related parameters of the vehicle are transmitted to a vehicle mechanic. According to embodiments, the second instructions are generated as an instruction manual using the LLM. In some embodiments, the instruction manual includes instructions for tuning the software-related parameters and the hardware-related parameters.

[0081] 8 is a flowchart illustrating a method 800 for training a machine learning model according to one or more embodiments. It should be understood that, according to embodiments, method 800 may be performed after the operations in method 700.

[0082] Referring to FIG. 8, in operation 810, performance data regarding the performance of Model X (e.g., the accuracy of the predictions of Model X) and / or vehicle performance data after operating the vehicle is received.

[0083] In operation S820, a requirements as code (RaC) file is generated using the LLM based on the vehicle performance data received in operation S810. The RaC file includes a file identifier that identifies the RaC file, driver information that identifies the vehicle driver and the vehicle driver's state, vehicle information that identifies the vehicle model and the vehicle's state, metrics information that defines one or more metrics related to the vehicle's performance and criteria for satisfying the one or more metrics, and environmental information during operation of the vehicle.

[0084] In operation S830, simulated vehicle data is obtained based on the RaC file generated in operation S820.

[0085] According to some embodiments, when the performance of model X is determined to be suboptimal or poor, simulated vehicle data is obtained, including weak scenes in which model X did not perform well, so that model X can overcome the weak scenes by training it on the data for the weak scenes. In some embodiments, when the performance of model X is determined to be suboptimal or poor due to overfitting during model training, a greater amount of simulated vehicle data is obtained to obtain better generalization performance without overfitting to the training data.

[0086] In operation S840, an ML model is trained based on the simulated vehicle data and actual vehicle data from the vehicle performance data. The vehicle performance data includes feedback from the vehicle driver, sensor data from the vehicle, and feedback from the vehicle mechanic, and the actual vehicle data corresponds to sensor data received from the vehicle (or from an external sensor). In some embodiments, of the simulated vehicle data and the actual vehicle data, only the simulated vehicle data is used to train the ML model.

[0087] In operation S850, the ML model is evaluated based on the simulated vehicle data and the actual vehicle data.

[0088] In operation S860, the trained ML model is deployed based on evaluating that the ML model satisfies one or more metrics in the RaC file.

[0089] Optimized vehicle performance can be achieved by providing a machine learning (ML) model that can output vehicle parameters for tuning a vehicle based on provided vehicle state data. The ML model can be trained and re-evaluated based on simulated and actual vehicle data, allowing for improvements to the ML model (thereby further improving vehicle performance when using the ML model). Large-scale language models (LLMs) are implemented, allowing users to easily interpret data output from the ML model in natural language, and allowing the ML model to receive input data from users that is originally in natural language. The know-how of experienced vehicle mechanics is thus accumulated in the LLM through repeated feedback, facilitating the transfer of know-how to other vehicle mechanics. Additionally, the know-how of experienced vehicle drivers is thus accumulated in the LLM through repeated feedback, facilitating the transfer of know-how to other vehicle drivers.

[0090] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the exemplary embodiment or embodiments to the precise forms disclosed. Modifications and variations are possible in light of the disclosure or may be acquired from practice of the exemplary embodiment or embodiments.

[0091] One or more exemplary embodiments relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, one or more of the components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). A computer-readable medium includes a non-transitory computer-readable storage medium having computer-readable program instructions thereon for causing a processor to perform operations.

[0092] A computer-readable storage medium is a tangible device that can hold and store instructions for use by an instruction execution device. Computer-readable storage media are, for example, but not limited to, electronic, magnetic, optical, electromagnetic, or semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves on which instructions are stored, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through electrical wires.

[0093] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0094] The computer readable program code / instructions for performing operations are either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or equivalents, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In one or more exemplary embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), executes computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform aspects or operations.

[0095] These computer-readable program instructions may be provided to a general-purpose computer, special-purpose computer, or other programmable data processing device to manufacture a machine, such that the instructions, executed by a processor of the computer or other programmable data processing device, create means for implementing the function(s) / act(s) identified in the flowchart and / or block diagram block(s). These computer-readable program instructions may be stored on a computer-readable storage medium capable of directing a computer, programmable data processing device, and / or other apparatus to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that implement an aspect of the function(s) / act(s) identified in the flowchart and / or block diagram block(s).

[0096] The computer-readable program instructions may be loaded into a computer, other programmable data processing device, or another device to cause the computer, other programmable device, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions, which execute on the computer, other programmable device, or other device, implement the function / acts identified in a block or blocks of the flowcharts and / or block diagrams.

[0097] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible example implementations of systems, methods, and computer-readable media according to one or more exemplary embodiments. In this regard, each block in the flowcharts or block diagrams represents a microservice, module, segment, or portion of instructions comprising one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than depicted in the figures. In one or more alternative exemplary implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or near concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by special-purpose hardware-based systems that perform the specified functions or acts or execute a combination of special-purpose hardware and computer instructions.

[0098] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods does not limit one or more exemplary embodiments. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A processor-implemented method for optimizing vehicle performance, comprising: receiving vehicle status data prior to operating the vehicle; generating input data for a machine learning (ML) model based on the vehicle state data, the ML model configured to output at least one of predicted vehicle performance or vehicle parameters based on the vehicle state data; obtaining optimized vehicle parameters based on the input data based on the ML model; transmitting instructions to tune the vehicle based on the optimized vehicle parameters; A method comprising:

2. 2. The method of claim 1, wherein the vehicle state data includes a first report from a vehicle driver indicating a state of the vehicle driver and a second report from a vehicle mechanic indicating a state of the vehicle, and generating input data for the ML model includes converting the first report and the second report into machine-readable parameters using a large language model (LLM).

3. 3. The method of claim 2, wherein obtaining the optimized vehicle parameters includes interacting with at least one of the driver and the vehicle mechanic via a chat interface, the chat interface configured to iteratively suggest optimized vehicle states and optimized vehicle parameters from the LLM based on the predicted vehicle performance.

4. The step of transmitting instructions to tune the vehicle includes: sending a first instruction to an electronic control unit (ECU) of the vehicle to tune a software-related parameter of the vehicle; sending second instructions to the vehicle mechanic for tuning hardware-related parameters of the vehicle, the second instructions being generated as an instruction manual using the LLM; The method of claim 2 , comprising:

5. receiving vehicle performance data after operating the vehicle; generating a requirements-as-code (RaC) file based on the vehicle performance data using the LLM; generating simulated vehicle data based on the RaC file; training the ML model based on the simulated vehicle data; The method of claim 4 further comprising:

6. 6. The method of claim 5, wherein training the ML model is further based on actual vehicle data from the vehicle performance data, the vehicle performance data including feedback from the vehicle driver, sensor data from the vehicle, and feedback from the vehicle mechanic, and the actual vehicle data corresponds to the sensor data.

7. The RaC file is a file identifier that identifies the RaC file; driver information identifying the vehicle driver and a state of the vehicle driver; vehicle information identifying the vehicle model and the state of the vehicle; metric information defining one or more metrics related to the vehicle's performance and criteria for meeting the one or more metrics; environmental conditions during operation of the vehicle; The method of claim 6, comprising:

8. evaluating the ML model based on simulated vehicle data and / or the actual vehicle data; deploying the trained ML model based on evaluating that the ML model satisfies the one or more metrics in the RaC file; The method of claim 7 further comprising:

9. 1. A device for optimizing vehicle performance, comprising: at least one memory storing computer-executable instructions; at least one processor executing the computer-executable instructions to: receiving vehicle status data prior to operating the vehicle; generating input data for a machine learning (ML) model based on the vehicle state data, the ML model configured to output at least one of predicted vehicle performance or vehicle parameters based on the vehicle state data; obtaining optimized vehicle parameters based on the input data based on the ML model; transmitting instructions to tune the vehicle based on the optimized vehicle parameters; at least one processor configured to execute Equipment comprising:

10. 10. The apparatus of claim 9, wherein the vehicle state data includes a first report from a vehicle driver indicating a state of the vehicle driver and a second report from a vehicle mechanic indicating a state of the vehicle, and the at least one processor is configured to generate input data for the ML model by converting the first report and the second report into machine-readable parameters using a large language model (LLM).

11. 11. The apparatus of claim 10, wherein the at least one processor is configured to obtain the optimized vehicle parameters by performing the step of interacting with at least one of the driver and the vehicle mechanic via a chat interface, the chat interface being configured to iteratively suggest optimized vehicle states and optimized vehicle parameters from the LLM based on the predicted vehicle performance.

12. The at least one processor: sending a first instruction to an electronic control unit (ECU) of the vehicle to tune a software-related parameter of the vehicle; sending second instructions to the vehicle mechanic for tuning hardware-related parameters of the vehicle, the second instructions being generated as an instruction manual using the LLM; 11. The device of claim 10, configured to transmit instructions to tune the vehicle by executing:

13. The at least one processor executes the computer-readable instructions to: receiving vehicle performance data after operating the vehicle; generating a requirements-as-code (RaC) file based on the vehicle performance data using the LLM; generating simulated vehicle data based on the RaC file; training the ML model based on the simulated vehicle data; The apparatus of claim 12 , further configured to perform:

14. 14. The apparatus of claim 13, wherein training the ML model is further based on actual vehicle data from the vehicle performance data, the vehicle performance data including feedback from the vehicle driver, sensor data from the vehicle, and feedback from the vehicle mechanic, and the actual vehicle data corresponds to the sensor data.

15. The RaC file is a file identifier that identifies the RaC file; driver information identifying the vehicle driver and a state of the vehicle driver; vehicle information identifying the vehicle model and the state of the vehicle; metric information defining one or more metrics related to the vehicle's performance and criteria for meeting the one or more metrics; environmental conditions during operation of the vehicle; 15. The device of claim 14, comprising:

16. The at least one processor executes the computer-executable instructions to: evaluating the ML model based on simulated vehicle data and / or the actual vehicle data; deploying the trained ML model based on evaluating that the ML model satisfies the one or more metrics in the RaC file; 16. The apparatus of claim 15, further configured to perform:

17. receiving vehicle status data prior to operating the vehicle; generating input data for a machine learning (ML) model based on the vehicle state data, the ML model configured to output at least one of predicted vehicle performance or vehicle parameters based on the vehicle state data; obtaining optimized vehicle parameters based on the input data based on the ML model; transmitting instructions to tune the vehicle based on the optimized vehicle parameters; A computer program product for causing at least one processor to execute a method comprising:

18. the vehicle state data includes a first report from a vehicle driver indicating a state of the vehicle driver and a second report from a vehicle mechanic indicating a state of the vehicle, and generating input data for the ML model includes converting the first report and the second report into machine-readable parameters using a large-scale language model (LLM); obtaining the optimized vehicle parameters includes interacting with at least one of the driver and the vehicle mechanic via a chat interface, the chat interface being configured to iteratively suggest optimized vehicle states and optimized vehicle parameters from the LLM based on the predicted vehicle performance; The step of transmitting instructions to tune the vehicle includes: sending a first instruction to an electronic control unit (ECU) of the vehicle to tune a software-related parameter of the vehicle; sending second instructions to the vehicle mechanic for tuning hardware-related parameters of the vehicle, the second instructions being generated as an instruction manual using the LLM; 18. The computer program of claim 17, comprising:

19. The method comprises: receiving vehicle performance data after operating the vehicle; generating a requirements-as-code (RaC) file based on the vehicle performance data using the LLM; generating simulated vehicle data based on the RaC file; training the ML model based on the simulated vehicle data; Further comprising:

20. The computer program product of claim 18, wherein training the ML model is further based on actual vehicle data from the vehicle performance data, the vehicle performance data including feedback from the vehicle driver, sensor data from the vehicle, and feedback from the vehicle mechanic, and the actual vehicle data corresponds to the sensor data.

20. The method comprises: evaluating the ML model based on simulated vehicle data and / or the actual vehicle data; deploying the trained ML model based on evaluating that the ML model satisfies the one or more metrics in the RaC file; 20. The computer program of claim 19, further comprising:

Images