Data-driven system and method for generating daily diaries of vehicle usage for durability and reliability assessment

Abstract

The present disclosure relates to data-driven systems and methods for generating daily diaries of vehicle usage for durability and reliability assessment. The system generates a trip diary for each of a plurality of user profiles based on a plurality of trip patterns, driving cycle information, and charging information for a vehicle type to produce a plurality of trip diaries. The system generates a plurality of load histories for vehicle components corresponding to the vehicle type based on the plurality of trip diaries and determines a distribution of load parameters. The distribution is used to update vehicle information. For example, the distribution can be used to adjust or validate, for example, design parameters, test parameters, maintenance parameters, or warranty parameters.

Description

[0001] Cross-references to related applications

[0002] This disclosure claims the benefit of U.S. Provisional Patent Application No. 63 / 726,465, filed November 29, 2024, the contents of which are hereby incorporated herein by reference in their entirety.

[0003] introduction

[0004] This disclosure relates to generating travel logs of vehicle use for durability and reliability assessment. Summary of the Invention

[0005] In some cases, stress factors, including traction loads, electrical loads, thermal loads, and structural loads, are taken into account in vehicle design and durability. For example, for electric vehicle propulsion systems, this disclosure can be applied to analyze the magnitude and repetition of these loads, as well as their temporal history throughout the vehicle's lifespan. The sequence, timing, and characteristics of these loads over their lifespan can influence factors such as charge and discharge cycles, active motor heating, and damage to propulsion system components (e.g., batteries, inverters). In some embodiments, this disclosure uses high-fidelity cloud-based vehicle data, rather than relying solely on single-user load profiles with representative driving cycles that account for cumulative damage equivalent to real-world damage covered by the warranty, thereby allowing the generation of representative populations that accurately reflect the frequency, type, and sequence of real-world driving, parking, and charging loads. In some embodiments, the methods and systems of this disclosure integrate reference information (e.g., vehicle measurement data, survey data, and test data) to model user travel patterns, driving profiles, and charging behavior. In some embodiments, this disclosure relates to generating vehicle lifecycle usage patterns for different user sets and identifying warranty-critical damage to one or more components or systems of the vehicle. For example, critical damage to each component may occur in different user subsets, so the overall group covers the durability load of the entire propulsion system or vehicle.

[0006] In some embodiments, this disclosure relates to a method for generating load history for design, testing, maintenance, and warranty analysis. The method can be executed by processing equipment based on computer instructions stored in a non-transitory computer-readable medium. The method includes generating trip logs for each of multiple user profiles based on multiple travel patterns, driving cycle information of vehicle type, and charging information, to generate multiple trip logs. The method also includes generating multiple load histories corresponding to vehicle components of that vehicle type based on the multiple trip logs, and determining the distribution of load parameters based on the multiple load histories. In some embodiments, generating the trip log for each of the multiple user profiles includes: generating travel patterns for each user profile to generate multiple travel patterns corresponding to that vehicle type; generating driving history for each user profile based on the multiple travel patterns and driving cycle information of that vehicle type to generate multiple driving histories; and generating charging information based on the travel patterns and driving history of each user profile. In some embodiments, the method includes determining the multiple user profiles based on multiple predetermined user prototypes corresponding to a target customer group. In some embodiments, the method includes generating the multiple travel patterns based on a randomized multi-year model. In some implementations, the plurality of user profiles is a first plurality of user profiles, and the method includes determining a second plurality of user profiles, and repeatedly generating the trip log for each user profile and generating the plurality of load histories based on the second plurality of user profiles. In some implementations, each trip log includes a corresponding plurality of trips, and generating the plurality of load histories includes applying a load model to each of the corresponding plurality of trips.

[0007] In some embodiments, the method includes determining an estimated lifespan of the vehicle component based on the plurality of load histories and vehicle component information. In some embodiments, the method includes identifying a subset of user profiles corresponding to attributes in the plurality of user profiles, wherein a subset of trip logs in the plurality of trip logs corresponds to the subset of user profiles. In some such embodiments, the method includes identifying a target stress corresponding to the vehicle component based on the trip log subset, and determining at least one of design parameters, test parameters, maintenance parameters, or warranty parameters based on the target stress. In some embodiments, the method includes generating design parameters for the vehicle component based on the plurality of load histories or the distribution, and manufacturing the vehicle component based on the design parameters. In some embodiments, the method includes generating test parameters for the vehicle component based on the plurality of load histories or the distribution, applying test conditions to the vehicle component based on the test parameters, and recording data corresponding to the vehicle component's response to the test conditions. In some embodiments, the method includes generating maintenance parameters for the vehicle component based on the plurality of load histories or the distribution, and scheduling maintenance of the vehicle component based on the maintenance parameters. In some embodiments, the method includes modifying at least one of the following based on the plurality of load histories or the distribution: (i) design parameters of the vehicle component or (ii) test parameters of the vehicle component. In some embodiments, the method includes determining warranty information corresponding to the vehicle component based on the plurality of load histories, and generating a warranty notification based on the warranty information. For example, the warranty information includes a target warranty life for the vehicle type, and each of the plurality of trip logs spans the target warranty life. In some embodiments, the method includes determining the remaining life of the vehicle component based on the plurality of load histories, and generating an indication of the remaining life at a user interface. In some embodiments, the method includes updating a threshold corresponding to the plurality of load histories in the memory storage of a vehicle of the vehicle type. In some embodiments, the method includes receiving updated information corresponding to the vehicle component, and updating the plurality of load histories based on the updated information. In some embodiments, the method includes generating a usage distribution of one or more loads based on the plurality of trip logs. In some embodiments, the method includes generating a damage distribution of one or more loads based on the plurality of trip logs and a damage model. In some implementations, the multiple load histories include damage distributions of the multiple travel modes, and the method includes determining the damage distributions based on the multiple travel modes and reference information corresponding to the vehicle components.

[0008] In some embodiments, this disclosure relates to a system for generating load history for design, testing, maintenance, and warranty analysis. The system may be implemented by a processing apparatus based on computer instructions stored in a non-transitory computer-readable medium, wherein the computer instructions may be executed by the processing apparatus to perform any of the methods described above. Attached Figure Description

[0009] The present disclosure is described in detail with reference to the following accompanying drawings, which illustrate one or more various embodiments. The drawings are provided for illustrative purposes only and show only typical or exemplary embodiments. These drawings are provided to facilitate understanding of the concepts disclosed herein and should not be considered as limitations on the breadth, scope, or applicability of these concepts. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of explanation.

[0010] Figure 1 This is a block diagram of an exemplary system for managing and using dynamic group information according to some embodiments of this disclosure;

[0011] Figure 2 This is a block diagram of an exemplary system for generating travel logs according to some embodiments of this disclosure;

[0012] Figure 3 This is a flowchart illustrating travel information based on some implementation schemes of this disclosure;

[0013] Figure 4A and Figure 4B Exemplary driving information according to some embodiments of this disclosure is shown;

[0014] Figure 5 This is a block diagram illustrating an exemplary process for assigning charging events using charging information, according to some embodiments of this disclosure.

[0015] Figure 6 Exemplary charging information for assigning charging events according to some embodiments of this disclosure is shown;

[0016] Figure 7 This is a block diagram illustrating the distribution information according to some embodiments of this disclosure;

[0017] Figures 8A to 8C An exemplary output based on a travel log is shown according to some embodiments of this disclosure;

[0018] Figure 9 This is a flowchart illustrating an exemplary process for generating and using travel logs according to some embodiments of this disclosure; and

[0019] Figure 10This is a flowchart illustrating an exemplary process for applying travel logs to improve fault analysis, according to some embodiments of this disclosure. Detailed Implementation

[0020] Vehicle powertrains must typically be designed to be durable and reliable throughout the vehicle's design life to minimize wear and warranty requirements, for example. Durability design may require estimating the variations and accumulation of loads that may be applied to or are expected to be applied to the vehicle's powertrain during its lifespan. These loads may be applied by the customer in the field. Identifying the most damaging real-world loads applied or expected to be applied can help generate a durability design. Currently, such estimations are typically done using expert opinions (e.g., based on field failures) and limited data from new vehicles, while considering the most conservative load patterns. In doing so, over-design or under-design may occur for each component among different parts, increasing design, testing, and warranty costs. Furthermore, analysis based solely on limited representative historical usage data, user scenarios, and industry experience may fail to capture the different failure modes of different propulsion components. For example, reliance on such representative data may force designers to add more material mass, size, and capacity to the vehicle or its systems, thereby also increasing life-cycle emissions, reducing sustainability, and increasing costs.

[0021] This disclosure relates to methods and systems for combining data from existing customers and real-world driver travel patterns, as well as driving, charging, and weather data from various public databases, to generate a comprehensive population of customers and their daily vehicle usage, spanning from purchase to the end of the vehicle's design life. In some embodiments, the methods and systems of this disclosure provide a lifecycle load for the customer population, which allows for more accurate estimation of warranty-critical loads. In some cases, this allows for setting more realistic durability and reliability targets and reducing the costs of design, testing, and warranty requirements. For example, the system generates multiple trip logs based on multiple user profiles, multiple travel patterns, vehicle driving cycle information, and charging information. The system also generates a load history corresponding to vehicle components based on the multiple trip logs.

[0022] In some implementations, this disclosure relates to generating daily time-series load patterns for a wide variety of customers. For example, a daily approach may be preferred over weekly estimates or other coarser estimates. For illustration, this disclosure may allow for the generation of various traction usage variations (e.g., weekly in summer, but changing frequency in autumn) instead of assigning weekly traction loads or another coarser approximation.

[0023] In some implementations, this disclosure relates to generating more realistic customer profiles. For example, this disclosure relates to using patterns observed in data to vary the intensity of different use cases to randomly generate user groups and then quantitatively identify design-critical customers, rather than attempting to quantify a single worst-case user who might be a warranty-critical user, or a single representative user who might miss nuances and cross-couplings. While a single worst-case user could be estimated by combining the most aggressive off-road driving with the most aggressive traction and the most frequent track driving—essentially “stacked worst cases”—this could lead to generating design-critical customers that might not exist. This disclosure relates to improving the characterization of which customers are design-critical for each system or component.

[0024] In some implementations, this disclosure relates to generating travel logs associated with user groups, thereby allowing identification of which users within the group are design-critical for the corresponding components or subsystems. In an exemplary example, the techniques of this disclosure can differentiate between the user most likely to damage the motor and the user most likely to damage the battery or half-shaft (because they do not need to be the same user), rather than generating a single design-critical customer for the entire powertrain.

[0025] In some embodiments, the methods and systems of this disclosure can allow for reduced over-design of vehicles, lowering component costs, testing costs, and total costs. In some embodiments, this disclosure relates to reducing blind spots in the design that may arise due to a lack of real-world usage data, thereby reducing warranty costs. For some components, this may also reduce size and weight, potentially leading to more sustainable vehicles. Such illustrative benefits, for example, can help improve profitability, sustainability, and performance in the market.

[0026] In some implementations, this disclosure relates to generating time series of driving, parking, and charging of a vehicle over its lifespan for different customers. For example, different customer profiles (e.g., aggressive drivers, traction and off-road users, cold-climate users) can be identified by analyzing existing fleet data and target customer groups for different vehicle variants. Trip logs (e.g., a trip-by-trip list of trips over the vehicle's lifespan) can be generated for different customers by referencing existing public mobility pattern data (e.g., the U.S. Department of Transportation's National Household Mobility Survey). Similarly, fleet data, public driving data, any other suitable data, or any combination thereof, can be analyzed to generate a set of representative real-world driving cycles for, for example, road driving, off-road driving, traction, and track driving. Each trip in the trip log can be associated with a representative driving cycle. Charging sessions (e.g., slow and fast charging sessions) are then incorporated into these logs between trip events using analysis of reference charging behavior (e.g., from fleet data). Thus, customer usage logs with sequences of driving (e.g., different types of trips and driving styles), parking (e.g., at different locations and times), and charging (e.g., using different charger types) are generated. These logs can then be converted into load sequences using a vehicle simulation model to generate a customer's vehicle-specific lifecycle load pattern. For example, these loads can form the basis for design and testing objectives used to set durability and reliability. This method allows for the generation of customer usage distributions, quantifying the loads and activities experienced by the vehicle for the customer throughout its lifespan (e.g., warranty life). This disclosure can be applied to the durability and reliability of the powertrain, or any other component or process of the vehicle. For example, this disclosure can be applied to understanding structural loads in the design of chassis and body structures (e.g., based on trips, loads on door handles and hinges can be estimated by estimating the frequency and count of door openings). In another example, this disclosure can also be implemented to analyze and modify how vehicle thermal systems or lighting are used and in what order, thereby affecting their design. In some embodiments, this disclosure is applied to estimating "remaining life," which can be used to design controls to increase real-world extent or maintain system performance as the vehicle ages. In some embodiments, this disclosure provides a path to tailor vehicle controls to improve the target customer experience.

[0027] Figure 1This is a block diagram of an exemplary system 100 for managing dynamic group information according to some embodiments of this disclosure. As shown, system 100 includes a trip manager 110, a driving manager 120, a charging manager 130, reference information 170, design target information 180, and an output manager 190. For example, reference information 170 and design target information 180 may be received by trip manager 110, driving manager 120, and charging manager 130 to generate output 135 provided to output manager 140, which may then provide update information 199 to iterate, repeat, or refine output 135.

[0028] In some implementations, system 100 is implemented in the context of one or more vehicles, electric vehicles, or other suitable systems or collections, groups, or fleets thereof. For example, reference information 170 may include data corresponding to one or more vehicle types for multiple users (e.g., data collected from the field, data collected during design), and system 100 may be used to generate output 135 corresponding to one of the one or more vehicles, another suitable vehicle, or any combination thereof.

[0029] The trip manager 110 is configured to generate or retrieve user profiles, customer information 181, and trip data 171, and generate trip patterns for each of multiple user profiles. Each user profile may be generated based on a combination of distributions of user types, and each user profile may correspond to a vehicle instance. Trip patterns may be generated based on a stochastic model (e.g., a Markov chain or any other suitable model) that sorts multiple events together, representing driving activities or other vehicle use activities at a daily resolution. Trip patterns may be extended over several years, for example, corresponding to the expected vehicle lifecycle, the target warranty lifecycle, or other predetermined times of interest for vehicle component and system lifecycle analysis. The trip manager 110 outputs multiple trip patterns, one for each user, which includes a sequence of numerous vehicle use events (e.g., trips).

[0030] Driving manager 120 is configured to take travel patterns as input, assign driving cycles to each vehicle usage event (e.g., each trip), and apply vehicle load information. For example, a travel pattern may include a commuting trip, and driving manager 120 may apply a driving cycle corresponding to the commuting driving cycle to that trip. Driving cycles may include average speed (e.g., based on distance or road type); the number of stops, starts, and turns; average and / or peak acceleration / deceleration; average or peak motor speed, gear speed, shaft speed, wheel speed, or any other load indication; a predetermined template corresponding to the trip type selected from a plurality of templates; any other suitable usage information; or any combination thereof. In some embodiments, driving manager 120 may take vehicle information 182 as input, which may include driving cycle information (e.g., templates) for the type of vehicle being analyzed. The vehicle type and corresponding vehicle information 182 may include production vehicles (e.g., vehicles available for sale whose instances are already on the road), concept vehicles (e.g., in the concept or design phase), or any other vehicle for which usage events and driving cycles can be estimated. The output of the driving manager 120 may include driving cycles for each trip of each user profile (e.g., the total number equal to the sum of all trips of all user profiles).

[0031] Charging manager 130 is configured to take driving cycles, charging information 183, and charging data 173, along with determined charging behavior information, as input to assign charging events to each trip log. For example, the input to charging manager 130 could be a sequence of events for each user profile, which could include driving events (e.g., trips). Charging manager 130 can apply a discharge / charge model (e.g., based on information from charging information 183, charging data 173, or both) to determine the vehicle's charging status before, during, or after each event. Based on the charging behavior model, charging manager 130 can determine when a particular user profile will be charged and what type of charger will be used. For example, for each user profile, charging behavior can be determined based on statistics and real-world charging behavior, as well as the expected charging behavior for each user profile. Charging manager 130 can sequentially analyze driving cycles to determine charging events, insert charging events into the trip log, determine new charging statuses, and repeat the process while continuing to complete the remainder of the sequence. For example, for each user profile (e.g., for each trip log), the charging manager 130 may insert multiple charging events (e.g., at appropriate points in the event sequence), add charging status metrics to each driving event in the trip log (e.g., charging metrics), insert cumulative counts of charging events / cycles, or combinations thereof. The output of the charging manager 130 may be multiple trip logs, one trip log per user profile, each trip log including multiple driving and charging events arranged in a sequence spanning a predetermined time period (e.g., target vehicle lifespan).

[0032] Output manager 140 is configured to evaluate results based on predetermined criteria (e.g., using a load model, damage model, or any other suitable model), compile distributions based on metrics determined for each trip log, perform updates or modifications to design parameters, test parameters, warranty information (e.g., warranty notices), store results or data for future modeling (e.g., stored in reference information 170, design target information 180, or both), and perform any other suitable actions or any combination thereof. For example, output manager 140 may be configured to perform or manage iterations by determining results based on updates to trip modes, driving cycles, or charging events and perturbing one or more of trip managers 110, driving managers 120, or charging managers 130. As an example, output manager 140 may analyze results and then modify component designs, which may require updating vehicle load information to generate driving cycles and charging behaviors (e.g., in some cases, maintaining trip modes).

[0033] Figure 2 This is a block diagram of an exemplary system 200 for generating travel logs according to some embodiments of this disclosure. In some embodiments, system 200 is... Figure 1 An example of System 100. As shown in the figure, System 200 includes a trip pattern generator 210, a driving cycle generator 220, a charging behavior generator 230, and a lifecycle load generator 240. For example, System 200 can take one or more sets of data, parameters, algorithms, any other suitable information, or any combination thereof as input, and then output a trip log for the vehicle's predetermined warranty life associated with one or more simulated users. The trip log can be used by a damage estimator to determine the distribution of expected use, damage, wear rate or amount, number of cycles, health metrics, or any other suitable metric corresponding to one or more parts, subsystems, or components of the vehicle. For example, for a specific vehicle brand / model / configuration, a total of N trip logs can be generated for a predetermined warranty life of Y years or M miles. The N trip logs can be input into the model to determine the system's usage estimate. The distribution of the usage estimate can then be analyzed to determine the aggregate cumulative usage distribution, such as the distribution of energy throughput, mileage, number of charging cycles, average speed per trip, SOC, any other suitable value, or any distribution thereof.

[0034] In some implementations, the travel pattern generator 210 determines user prototypes based on travel data 271. The travel pattern generator 210 generates travel logs for each simulated user in a set of simulated users, ranging from an initial time (e.g., purchase of a vehicle) to an end time (e.g., the number of days, years, or miles booked). For each user, the travel pattern generator 210 generates a sequence of trips, where there may be multiple trips per day. In some implementations, a set of rules is applied to each day to determine the trips for that day. In some implementations, the travel pattern generator 210 may use one or more linking rules to randomly link travel days. The travel pattern generator 210 may estimate the frequency of various driving modes (e.g., traction frequency) and a distribution parameter specifying usage intensity (e.g., traction weight), extract representative travel days (e.g., sequences of driving activity for weekdays, weekends, summer, and winter), and use rule-based Markov chains to generate random travel histories, or combinations thereof.

[0035] In some implementations, driving cycle generator 220 determines the driving cycle for each trip in each user's trip log. The driving cycle may include, for example, time series of speed, gradient, traction, any other variable, or any combination thereof for each trip. Based on the driving cycle information, driving cycle generator 220 may determine changes in average speed, acceleration, gradient, vehicle mass, lateral acceleration, trip length, and any other suitable metric to determine torque, power, current, temperature, or other quantities. Driving cycle generator 220 may employ a model of the driving system to estimate torque, power, current, temperature, or other quantities for each user's trip per day. Driving cycle generator 220 may identify key driving cycle statistics affecting degradation patterns (e.g., energy throughput may be most affected by the average speed and standard deviation of acceleration), cluster the driving cycles based on these key statistics, select representative driving cycles (e.g., low-speed, high-acceleration driving cycles, high-gradient, and high-acceleration driving cycles), and assign the driving cycles to the trip history generated by trip pattern generator 210 to generate a driving / idling history. The driving history may also include parking history.

[0036] In some implementations, the charging behavior generator 230 determines the charging behavior of each user's driving and parking patterns for each trip per day. The charging behavior generator 230 may add charging events to the user's trip log, add charging information for each trip (e.g., after each trip), or otherwise append charging information to the output of the driving cycle generator 220. The charging behavior generator 230 may extract representative charging parameters (e.g., the probability of insertion under different SOCs) from fleet charging behavior, calculate SOC changes following driving history, and assign charging sessions when vehicles are properly parked.

[0037] In an exemplary example, the system may generate a travel log 231, which, after being processed by the charging behavior generator 230, includes a list of events for each user. For example, for each of a total of N users, the corresponding travel log in travel log 231 may include a list of driving events and charging events. For example, as shown, travel log 231 may include the same number of lines as the sum of the total number of trip events for each user profile across all user profiles.

[0038] In some implementations, the lifecycle load generator 240 determines the distribution of damage to components or systems of a vehicle. For example, because a travel log includes detailed information, the lifecycle load generator 240 may determine the number of certain events, the intensity of certain events, cumulative load, or other values ​​to estimate wear, damage, or service life. In another example, the lifecycle load generator 240 may generate a distribution corresponding to the results (e.g., in W...). Histograms of energy consumption per h / mile, percentage of users with battery welding damage, percentage of users with power module damage, user mileage over a time period such as 10 years, and percentage of trips at average speed. In another example, lifecycle load generator 240 can determine the percentage distribution of driving type (e.g., community, city roads, urban inclines, rural roads, highways, inclines, Davis Dam gradients, high-speed tracks, or any other suitable driving cycle).

[0039] In an illustrative example, the system may be designed to replicate vehicle use by a real customer group and include the correct proportions of different prototype users forming the target customer group for the vehicle (e.g., the correct proportions of users in areas with different ambient temperature variations, users engaging in off-road driving, and users engaging in towing). The system assigns a series of trip, drive, parking, and charging events to each user in the composite group, and each such event is quantified (e.g., driving type and driving cycle, and charging type and charging amount). The system may use data from telemetry and surveys and employs a rhythm of three models: a trip, driving, and charging model.

[0040] In another example, the system can take time-series data on vehicle speed, gradient, driving mode, ambient temperature, battery SOC, and charging type or charging power as input. For example, the system can also take additional data as input, such as location, trip purpose, and energy usage. In some cases, the time-series data may be available in vehicle telemetry data or may be combined from different sources (e.g., it does not need to rely on obtaining all data from the same source). In some implementations, the system combines time-series and event-based data on driving, trips, and charging from different datasets and different users to estimate usage behavior.

[0041] In another example, the system may use public datasets corresponding to other modes of transportation to model usage behavior (e.g., travel survey data from the National Household Travel Survey 2017 (NHTS) or driving cycle data from the National Renewable Energy Laboratory (NREL)). Additionally, the system may use telemetry data. In some implementations, instead of using identifiable information about individual customers and vehicles from the telemetry data, the system may use aggregated or anonymized data. In an exemplary example, NHTS data may include descriptions of trips taken by more than 130,000 different households across the United States on different days of the year. This data includes weekday, date, length, duration, purpose, origin, destination type, departure time of the trip, odometer mileage, and type of vehicle driven. Furthermore, NREL driving cycle data may include approximately 120,000 GPS-based vehicle speed time series collected from different modes of transportation across the United States. This disclosure may use such data, any other suitable data, or any combination thereof.

[0042] Travel modes

[0043] Figure 3 This is a block diagram of exemplary travel information 300 according to some embodiments of this disclosure. Travel information 300 may include information about a sequence of trips throughout the day from a home (e.g., from the National Highway Traffic Safety Administration (NHTSA)). Each trip may, for example, extend from a starting point to a destination and optionally return to the starting point (e.g., a return trip may alternatively be another separate trip event). For example, an exemplary trip may include location identification (e.g., home, office, workplace, store, park, marked location on a map), departure and arrival times and dates (e.g., Figure 3 The times t0, t1, t2, t3, t4, t5), and the length of each segment of the journey (e.g., Figure 3 The travel information (distances d1, d2, and d3), any other suitable information, or any combination thereof. The travel information may be stored in any suitable manner on any suitable device. For example, travel information 300 may be stored on a cloud-based storage device, hard drive, server, or any other suitable storage, and may be accessed as a file, a collection of files, a collection of values ​​(e.g., from a webpage), a group, or any other suitable form. Travel information 300 may be collected from one or more sources at any suitable interval via download, query and response, timed data push, or any other suitable method.

[0044] In some implementations, the system segments the target group into multiple user prototypes (e.g., off-road driving, towing, neither, or both). For example, the system may use target customer studies, telemetry data from an existing vehicle fleet, or any other suitable information source. In some implementations, the system generates a comprehensive daily travel log of the user from the vehicle purchase date (e.g., Day 1) to the end of the vehicle's design life (e.g., Day n), which may span several years. In some implementations, the system may consider any anticipated changes in ownership and adjust travel patterns accordingly (e.g., updating the user profile based on another prototype of subsequent events). In some implementations, the travel log is generated by randomly linking travel days based on travel data using one or more linking rules. For illustration, daily travel events may depend on the events or nature of the previous day, prior events, time of year, time of day, day of week, any other suitable information, or any combination thereof.

[0045] In an exemplary example, the reference data (e.g., NHTSA data) may include daily travel data from U.S. households over a period of time (e.g., one year). In some implementations, the system applies a combination of random sampling and linking, constrained by a set of linking rules. Thus, a travel log is generated for each user. Linking rules may include, for example:

[0046] 1. Travel days assigned to weekdays or weekends must be travel days from either weekdays or weekends in the dataset, respectively. This explains the differences in travel patterns between weekends and weekdays;

[0047] 2. Select travel days from the travel days observed in the same month within the dataset. This can explain the impact of seasons on travel patterns; and

[0048] 3. Each subsequent travel day assigned in the diary must begin at the same location (e.g., home, workplace, or other suitable location) where the previous travel day ended (e.g., the last travel event of the previous day).

[0049] Additionally, if the vehicle's itinerary indicates that the vehicle is driving at midnight, the next day can begin from the driving status. The system can generate output 320, which may include a trip log 321 corresponding to a group of integrated users and contains a time-series pattern of trips and stops (e.g., user ID USER, time / date DAY, start time T1, end time T2, trip type REF, and any other suitable information X). The trip log 321 can be stored in any suitable format (e.g., database 326) on any suitable device (e.g., storage device 325).

[0050] Driving Cycle

[0051] Figure 4A This is a block diagram of exemplary driving information 400 according to some embodiments of this disclosure. As shown, driving information 400 includes a distribution of driving cycles (e.g., approximately 120,000 from NREL) distributed into bins for average speed (e.g., vertical axis 402 as shown) and trip length (e.g., horizontal axis 401 as shown), where the percentage of driving cycles in each bin is listed on the bin. For example, a positive correlation can be observed between average speed and trip distance (e.g., shorter trips have lower average speeds, while longer trips have higher average speeds). Additionally, the density of driving cycles is higher at lower speeds and trip lengths, indicating that most real-world driving occurs on short trips less than 10 miles in length and with average speeds below 40 mph (e.g., see [link to relevant documentation]). Figure 4B Panels 410 and 420). Each entry (e.g., each discretization 405 as shown in the figure) may correspond to a number (e.g., a percentage of driving cycles in the distribution), where shading (e.g., shading scale 406) corresponds to the percentage of driving cycles. For example, for all trips, a two-dimensional distribution across x-axis 401 and y-axis 402 may be normalized to one (e.g., the distribution may be numerically integrated across both dimensions to normalize). In another example, for a given width in x-axis 401, a set of one-dimensional distributions across y-axis 402 may be normalized to 1 for each speed (e.g., the distribution may be numerically integrated across y-axis 402 to normalize). In another example, for a given width in y-axis 402, a set of one-dimensional distributions across x-axis 401 may be normalized to 1 for each trip (e.g., the distribution may be numerically integrated across x-axis 401 to normalize). The ranges of x-axis 401 and y-axis 402 may be chosen to be any suitable values ​​and may correspond to a range of values ​​in the available data. As shown in the figure, the ratio of the horizontal axis 401 to the vertical axis 402 does not need to be linear or regular, and any suitable discretization can be applied to generate the distribution.

[0052] In some implementations, the system uses a driving model to assign driving cycles (e.g., time series of speed and gradient) to each trip in the user's log. In some implementations, the system analyzes a driving cycle database (e.g., reference driving information) to obtain a reduced set of driving cycles (e.g., representative driving cycles) covering the range of variation in real-world driving. Driving cycles in the driving cycle database can be categorized (e.g., compartmented or otherwise arranged, ordered, or grouped) by average speed, trip distance, net gradient variation, standard deviation or other variation of gradient, standard deviation or other variation of acceleration (e.g., representing driver aggression), any other suitable information, or any combination thereof. For example, for each compartment, a single driving cycle that is closest to all other driving cycles in that compartment is selected and designated as the representative driving cycle for that compartment. Any suitable measure of proximity between time series can be used to identify the representative driving cycle for a compartment (e.g., Jensen-Shannon divergence). In some implementations, the system may classify trips based on average speed (e.g., urban if less than 35 mph, otherwise highway), adjust driving cycles (e.g., cut-off length) or select driving cycles of appropriate length, use energy per mile estimates to estimate battery state of energy, or any other suitable criterion.

[0053] Figure 4B Panels 410 and 420 show two representative driving cycles with different driving cycle behaviors (e.g., Figure 4A The discretized bins (for corresponding average travel speed and average travel length) are used. In panels 410 and 420, the horizontal axis is divided in 1000-second increments, and the vertical axis is divided in 20-mph increments. Both bins represent long highway trips, but the average speeds are very different, thus capturing significant real-world variations in driving that cannot be represented by a single highway cycle. For example, driving cycle 421 in panel 420 is more likely to cause thermal damage to the propulsion system due to its near-constant high-speed driving, while driving cycle 411 in panel 410 is more likely to affect the gearbox and inverter with sharp acceleration from low to high speeds, resulting in high RMS current and instantaneous torque.

[0054] In some implementations, the system assigns driving cycles to each trip in the travel log based on a representative set of identified driving cycles. The system may assign driving cycles based on average speed, distance, trip purpose, any information available in the reference data, additional modeling assumptions, any other suitable information, or any combination thereof. For example, the system may use telemetry data to determine gradient and driving aggression as additional criteria for assigning driving cycles to trips. When using driver aggression as a criterion, for example, each user may be classified as an aggressive, moderate, or mild driver, and only driving cycles with corresponding high, medium, or low acceleration standard deviations are assigned to that user. In this way, a user's personal characteristics can influence the selection of driving cycles for trips in the travel log associated with that user.

[0055] In some implementations, the system uses average trip speed and trip length as indicators of energy usage during driving. The system can output multiple trip logs of trips and parking events with time-series patterns, where appropriate driving cycles are used to quantify driving in each trip event. For example, trip logs generated based on trip patterns are appended with driving cycle information to produce updated trip logs. In another example, referring to list data, for each row of the trip log (e.g., corresponding to a user's trip event), the system populates columns with driving cycle information (e.g., driving cycle identifier, energy per mile, total miles, average speed, charging status before and after the trip, and any other suitable information).

[0056] Charging behavior

[0057] Figure 5 This is a block diagram of an exemplary process 500 for assigning charging events using charging information, according to some embodiments of this disclosure. The charging information can be used in conjunction with a trip log 231, for example, to determine charging events within the vehicle's lifespan. For example, the trip log generated at step 501 may include a series of trips and driving cycles used on those trips. The system can then use a suitable vehicle model such that the driving cycles can be converted into time series of torque usage, power usage, temperature variations, energy usage, any other suitable parameters, or any combination thereof. These quantities, for example, represent loads on the vehicle and indicate causes of wear on vehicle components. This information can be appended / updated with estimated charging sequence information for the vehicle. This information is important for the charging events themselves and for ensuring that the vehicle completes its trips in the trip log. This information also allows the system to consider changes in the vehicle's electrical and thermal loads during and after charging.

[0058] Process 510 involves in-trip charging analysis to determine whether the State of Charge (SOC) at the start of the trip can be used to complete each trip and to determine the characteristics of the trip. For each trip in each trip log, the system... In some implementations, the system uses a charging model that probabilistically assigns charging events between trips (e.g., in each trip log) based on the vehicle's parking location, available parking time for charging, the vehicle's SOC due to trips taken prior to the parking event, the energy required to complete the next trip (e.g., at step 502), any other suitable information, or any combination thereof. For example, if the system determines at step 504 that the energy required for a single trip is greater than the energy available for a full charge (e.g., determining that there is no energy available to complete the trip), the system may insert a fast-charging session during the trip into the trip log (e.g., at step 506). In another example, the system may assume that the trip duration of such trips reported during the trip already includes rest periods available for fast charging. In some cases, the system may assume that variations in trip duration beyond these rest periods (if any) will be small enough not to affect the departure time of the next trip in the trip log. In some implementations, the system implements process 510 to determine for each trip in each trip log whether charging is required during the trip to complete the trip, a portion of the trip, or a segment, or otherwise maintain the vehicle's minimum SOC. In some implementations, during process 510, the system injects a charging event into the trip log at step 506 (e.g., between trips, within a trip, or between segments of a partitioned trip that has been divided into one or more segments based on step 506).

[0059] Process 520 involves post-trip charging analysis to determine whether a charging event needs to be inserted into the trip log. Step 512 includes determining whether there is sufficient time between events (e.g., the end of the first event and the start of the next event) to allow for L2 charging (e.g., AC charging or lower current charging). For example, L2 charging could correspond to a residential AC charger or a Level 2 charger. If there is time for L2 charging, the system then proceeds to step 518 to determine where the vehicle is parked (e.g., the location where the previous trip ended). Based on this location, the system determines the probability of several types of charging at one or more of steps 522, 526, and 530, and, for example, selects the most likely charging mode. Based on the most likely mode, the system inserts the corresponding type of charging event into the trip log at one or more of steps 524, 528, and 532. If there is insufficient time for L2 charging between events, the system proceeds to step 514 to determine the potential post-trip SOC based on the next event. The system then proceeds to step 516 to determine whether the current SOC is sufficient to allow the next event. If sufficient, the system proceeds to step 518. If insufficient, the system proceeds to step 532 and inserts a public charging session (e.g., at a public charger).

[0060] In the exemplary example, refer to Figure 5 The system can use a charging model that parameterizes charging behavior using the probabilities of plugging in a charger at home, at work, and in public places as a function of the vehicle's SOC and the user's urgency factor: f_home(SOC, urgency), f_work(SOC, urgency), f_public(SOC, urgency). For example, the user urgency factor is a real number between 0 and 1, allowing the system to model differences in urgency among users regarding their vehicle's charging needs. For illustration, the most risk-averse user who charges when the battery SOC drops below an upper threshold has a user urgency factor of 1. The most adventurous user who charges only when the battery SOC reaches its lower threshold or when charging is needed to complete the next trip might have a user urgency factor of 0. In some implementations, a user urgency factor randomly sampled from a uniform distribution can be assigned to each user in this set. The probability of unplugging a fast charger can be modeled similarly (e.g., the user does not need to wait for the SOC to reach 100%). When charging at home or work, it can be assumed that the vehicle is either fully charged before the start of the next trip or continues to charge while the vehicle is parked.

[0061] Figure 6 Exemplary charging information for assigning charging events according to some embodiments of this disclosure is shown. For example... Figure 6As shown, the system can apply one or more charging modes (e.g., Level 2 or L2 charging, or fast charging (FC)). Figure 6 An illustrative example of charging probabilities usable by the system is shown. Panel 610 shows the probability of a user plugging in an L2 charger as a function of the initial SOC (e.g., 100% probability for an SOC below about 0.6). Panel 620 shows the probability of plugging in a DC fast charger as a function of the initial SOC (e.g., trace 621 is for risk-averse users who tolerate lower SOCs, and trace 622 is for risk-averse users who require higher SOCs). In some embodiments, multiple distributions or a two-dimensional distribution may be used, where each user's risk aversion metric can be used to determine the charging probability (e.g., a distribution across SOC and risk aversion metric). Panel 630 shows an illustrative probability of a user unplugging a DC fast charger as a function of the ending SOC (e.g., a very low or zero probability when the SOC is below about 0.9). In some embodiments, the system may determine criteria for when and how a user charges the vehicle. For example, the system can apply rules such as: charge for 70% of the time if SOE > 30% and the user is at home; charge if SOE <= 30% and the user is at home or work; fast charge if a long trip is imminent and SOE is low (DOD > 80%); and use an L2 charger if the user is working for more than a period of time (e.g., 30 minutes). Furthermore, the system can apply rules for users who may only use fast chargers, such as: fast charge if SOE <= 40%; and stop and fast charge if a long trip is planned that will reduce SOE by 20%. The system can use any suitable rules and criteria to assign charging events to each trip and driving cycle in the trip log.

[0062] although Figure 6 The illustrative probability distribution depicted is derived empirically from user data, but the system can use a charging model as a parametric model. For example, the system can consider individual preferences in charging behavior that can be adapted to user urgency parameters and charging thresholds. The system can estimate parameters or probabilities based on data to allow the method to be applied to any available and suitable charging dataset. For example, the comprehensive population generated by this method considers variations in charging behavior and their impact on damage over the entire lifespan. After inserting charging information into the travel log, the system can output the travel log for distribution analysis, load history analysis, or other actions.

[0063] Travel diary and distribution

[0064] Figure 7This is a block diagram of exemplary distribution information 700 according to some embodiments of this disclosure. Distribution information 700 may include trip logs of multiple simulated users, including trip logs 701 to 704 (e.g., trip events with corresponding driving cycles and charging events). For example, the system may output an updated trip log of a comprehensive user, containing a time-sequential sequence of trip, driving, parking, and charging events. In some embodiments, the system may couple the output with an appropriate vehicle model to provide time series of torque, power, current, or any other load, for example, over the vehicle's lifespan. Figure 7 Example of a truncated (first three days only) trip log 701 is illustrated, showing each trip, its start and end times, driving cycle identifier (e.g., NREL, HWY, A, including the number of repetitions), energy consumption (watt-hours / mile), trip length (e.g., in miles or km), average speed (e.g., in mph or km / hr), initial SOC (e.g., in percentage), and whether a charging event occurred after the trip and the type of charging. In some implementations, the system can generate load history and damage distribution for any component or system of interest. It should be understood that the length of the trip log can be any suitable time period (e.g., including any suitable number of events), such as 5 years, 10 years, estimated or target vehicle life, target warranty life, or any other suitable duration. The damage distribution can be used, for example, to identify the user (or user group) most damaging to the component (e.g., the warranty-critical durability load of the component). Therefore, for each trip log, the system can apply a load model, a damage model, or both to each event to determine a cumulative estimate of load or damage (e.g., after each event, at a frequency such as annually, or at the end of the vehicle life or other log duration).

[0065] Load history and analysis

[0066] Figures 8A to 8C An exemplary output based on a travel log is shown according to some embodiments of this disclosure. In the exemplary example, the system can generate a travel log and then determine battery cell degradation based on the travel log. Figures 8A to 8CIllustrative results are shown. In some cases, battery cells in an EV battery pack may experience degradation due to use (load) and lifespan (calendar aging), which reduces usable battery energy over time. To provide customers with a reasonable range at the end of the warranty period or design life, battery cells can be designed so that the battery retains a certain percentage of its usable battery energy at the end of its life. Battery degradation is a complex electrochemical process and is typically influenced by the total energy usage cycles during driving and charging, the magnitude of power draw, and the number of fast-charging events (e.g., simultaneous power and thermal stress). The system can be configured to predict total energy consumption, energy consumption per mile (an indicator of power draw), the number of fast-charging sessions, and the distribution of charge within these fast-charging sessions. As discussed herein, any suitable reference data can be used (e.g., the NHTS dataset for trip data and the NREL driving cycles for driving characterization). For example, for validation, the system can use a limited amount of statistical information obtained from telemetry data from the vehicle of interest.

[0067] For illustration, for each travel log in N logs, the system can determine the total mileage at the Y-year marker (e.g., warranty life or other suitable predetermined duration). The distribution of the N data points of mileage can be used to generate a distribution similar to that shown in panel 810. In the illustrative example, using travel models and NHTS data, the system can generate a set of 1000 integrated users. Compared to panel 820, which illustrate 10 years of real-world odometer data from approximately 10,000 vehicles in the NHTS data, Figure 8A Panel 810 shows an exemplary 10-year cumulative mileage distribution for these users (e.g., a percentage of users plotted as a function of total mileage M). The x-axis divisions in panels 810 and 820 are in increments of 30,000 miles. The y-axis divisions in panel 810 are in increments of 10%, and those in panel 820 are in increments of 5%. As shown, randomly generated users exhibit a similar 10-year mileage distribution, specifically at and above the mean. The error in mean mileage is less than 5%, and the error in 95th percentile mileage is less than 1%. This indicates the ability of the travel model to generate travel logs with lifecycle usage similar to real-world conditions. The aggregate data is more conservative for low-mileage users, but those users are unlikely to have high cumulative damage based on very low overall usage.

[0068] Figure 8BPanels 830 and 840 illustrate the distribution of vehicle percentage and average trip speed over year Y. The horizontal axis in panels 830 and 840 is divided in 15 mph increments. The vertical axis in panel 830 is divided in 5% increments, and the vertical axis in panel 840 is divided in 10% increments. In some implementations, the system assigns driving cycles to the trip logs of N integrated users. (Compared to...) Figure 8B Compared to the distribution of average travel speed observed in data from actual users in panel 840, the average speed distribution over the lifetime of all integrated users is... Figure 8B Panel 830 is shown (e.g., 250 users for panel 830). As shown in panels 830 and 840 (e.g., showing the percentage of vehicles / users plotted as a function of average trip speed S), the distribution developed from aggregated users may resemble the distribution from real-world data (e.g., exhibiting a higher 95th percentile average trip speed). This may mean that, in some cases, driving cycles at least relative to average trip speed and trip distance are assigned to represent real-world usage. In some implementations, when using OEM fleet data instead of NHTS data that does not contain acceleration information, the system may use other metrics, such as acceleration. For the purposes of this disclosure, Figure 8A and Figure 8B A comprehensive population approach is demonstrated for determining an accurate history of trips and driving time throughout the entire lifespan. In some cases, average speed and trip length can also be good indicators of energy use, allowing the system to generate an accurate distribution of these parameters through trip and driving models to confidently estimate battery degradation loads (e.g., or any other suitable loads).

[0069] Based on travel logs, appropriate transportation models can be used to generate the distribution of total energy use (i.e., energy throughput). Figure 8B Panel 850 shows the distribution of estimated lifecycle energy consumption for the integrated group, i.e., the energy added to and consumed from the vehicle's battery pack (e.g., plotted as a percentage of the vehicle's total energy throughput E in MWhr). The horizontal axis of panel 850 is divided in 20 MWhr increments, and the vertical axis is divided in 10% increments. For example, for each trip log, the system can determine the cumulative energy added to and consumed for all events to determine a total value. This total value (e.g., N values ​​for N integrated users) can be used to generate a distribution to perform statistical analysis (e.g., the 95% value or any other suitable value).

[0070] Figure 8CPanel 860 shows the estimated distributions of the number of weekly fast charging events and the depth of fast charging in these events for two types of customers: (a) those customers least likely to use fast charging due to access to both L2 charging and fast charging (e.g., distribution 862), and (b) those customers who do not regularly access L2 charging and only use fast charging (e.g., distribution 861). The latter type of customer, who strictly only uses fast charging, although unrealistic, represents the most destructive charging behavior and serves as an upper limit for the estimated battery cell damage. The divisions along the horizontal axis increase by 1 (e.g., corresponding to 0, 1, 2, 3, or 4 fast chargers per week). The divisions along the vertical axis increase by 5% on the depth of charging (e.g., SOC) for each charging event. The size of the markers for each data point in distributions 861 and 862 corresponds to mileage over 8 years, ranging from 30k to 180k miles.

[0071] exist Figure 8C In panels 870 and 880, distributions 871 and 881 correspond to users with access to both the L2 and DCFC chargers, while distributions 872 and 882 correspond to users with access only to the DCFC charger. Panel 870 illustrates the distribution of users on the number of fast charges per week (NC) (e.g., each scale along the horizontal axis corresponds to 2 charges / week). Panel 880 illustrates the distribution of users on the median depth of charge (DC) (e.g., each scale along the horizontal axis corresponds to 20% of the state of charge). Figure 8C Panels 870 and 880 illustrate that users who have access to two types of chargers (e.g., L2 and DCFC) may tend to charge less per charging session and typically have fewer fast charging events per week. In some such cases, users with high total mileage may have more fast charging counts and higher fast charging amounts. In contrast, users who rely solely on fast chargers (e.g., distribution 882) may have a more uniform distribution of charging depth around 55% SOC, and among these users, those with more mileage charge more frequently. Most importantly, the illustrative distributions suggest that endurance-critical users may have approximately two or three, and certainly fewer than four, fast charging sessions per week.

[0072] In some implementations, these results provide a robust way to design durability and reliability, as well as a data-driven approach to designing durability and reliability test targets at all stages of vehicle design and development. Figure 8C The distribution shown can be generated based on the travel logs of N users, and the load history of the battery system can be analyzed to determine design, testing, repair, or warranty thresholds.

[0073] Figure 9This is a flowchart of an exemplary process 900 for generating and using travel logs according to some embodiments of this disclosure.

[0074] Step 902 includes generating multiple user profiles. User profiles may correspond to simulated users and have attributes generated based on statistical or other reference information. For example, a set of N user profiles may be generated, where N is statistically significant (e.g., to provide useful results in determining the historical distribution of load). Each user profile may include metrics of one or more prototype metrics. Prototype metrics may include household size, age, activity level, risk aversion, employment type / location, usage type (e.g., recreation, work, commuting), usage frequency, type of home charger, proximity to a DCFC charger, access to chargers and charger types, driving aggression, nearby ground topology (e.g., rural roads, paved roads, off-road), any other suitable metrics, or any combination thereof. For example, step 902 may be generated by… Figure 1 Travel Manager 110 or Figure 2 The travel pattern generator 210 performs this step. In another example, step 902 can be performed by a processing device, and the user profile can be stored... Figure 1 Travel data 171 or Figure 2 The travel data is from 271.

[0075] Step 904 includes generating travel patterns for each user profile. Step 904 may include, for example, determining a set of sequentially occurring events based on a stochastic multi-year model. For example, for each user, the corresponding travel pattern may include trips occurring with a corresponding start time, end time, duration, and role. For example, a trip may include leaving home, driving along a route (e.g., which may include one or more road types), and arriving at a destination (e.g., a type such as a workplace, shop, shopping mall, facility, vacation location, repair location, or any other suitable destination type). For example, travel patterns may span multiple years to construct a driving history and load distribution usable over the lifetime of the vehicle type. For example, step 904 may be... Figure 1 Travel Manager 110 or Figure 2 The travel pattern generator 210 is executed.

[0076] Step 906 includes generating a driving history for each user profile based on travel patterns. In some implementations, step 906 includes generating the driving history based on travel patterns and driving cycle information. Step 906 may include applying driving cycles from a reference driving cycle library to each trip, for example, based on logical rules, random rules (e.g., using a reference distribution), linking rules, or any other suitable criteria, to generate driving cycle information for each trip in each travel log. For each trip, the driving history may include an identifier of the driving cycle, the number of repetitions (e.g., of a reference driving cycle), average trip speed, average acceleration / deceleration, peak acceleration / deceleration, number of starts, number of stops, number of turns, average power consumption, total energy consumption, peak power, distance, road type metrics (e.g., paved, smooth, rough, off-road), any other suitable metrics related to the driving characteristics of the trip, or any combination thereof. For example, step 906 may be... Figure 1 Driving Manager 120 or Figure 2 The driving cycle generator 220 is executed.

[0077] Step 908 includes generating a travel log for each user profile. In some implementations, step 908 may include process 500 for inserting charging events into each travel log to generate a travel log with trip and charging event information. The output of step 908 may be a set of N travel logs for N integrated users, each travel log including multiple trips with corresponding trip information and multiple charging events with charging information. For example, step 908 may be... Figure 1 Charging Manager 130 or Figure 2 The charging behavior generator 230 completes, inserting the charging event into the temporary travel log output in step 906.

[0078] Step 910 includes generating a load history corresponding to a vehicle component or system for each trip log. A load history can be generated for the components or systems of the vehicle. For example, step 910 may include applying a load model or multiple load models to the trip logs to determine the cumulative load for each component or system. The cumulative load may include a cumulative value for each trip, or a single entry at the end of the vehicle's lifespan or other predefined duration. Step 910 may also include applying a damage model or multiple damage models to the trip logs or load history to estimate the cumulative damage for each component or system.

[0079] Step 912 includes determining a distribution of load parameters, damage parameters, or both, corresponding to a vehicle component or system based on trip logs, based on multiple load histories. This distribution may include a single value from each load history (e.g., a value for each trip log or each user / vehicle), or multiple values. For example, the load parameter for each load history may include a single cumulative load determined at a predetermined time (e.g., vehicle lifespan or other suitable time span). For illustration, a set of load parameters may be extracted from the load histories, corresponding to a set of times (e.g., years), a set of loads (e.g., each load corresponding to a corresponding model), or a combination thereof. For example, step 912 may include determining load parameters, such as the cumulative load for each component or system, using the results of a load model or multiple load models. The cumulative load may include a cumulative value for each trip, or a single entry at the end of the vehicle's lifespan or other predefined duration. The cumulative damage may include a cumulative value for each trip, or a single entry at the end of the vehicle's lifespan or other predefined duration. In some embodiments, step 912 includes determining multiple distributions, each corresponding to a specific vehicle component or system (e.g., each distribution has a corresponding load or damage model).

[0080] In an exemplary example, the load model may include an algorithm that determines force, torque, pressure, stress, strain, displacement, number of cycles, any other suitable parameters, or any combination thereof, based on driving cycle information for each trip. Therefore, for each trip in each travel log, the system may apply the load model to determine the corresponding load. At a predetermined end or lifespan, accumulated loads can be collected for each of the N travel logs, and a distribution may be generated at step 912 to determine how the load accumulates for each vehicle component in the vehicle. Any number of suitable load models and damage models may be applied to the travel logs to generate any number of suitable distributions. For example, for a set of travel logs, the load model for each suitable vehicle component or system may be applied to determine the corresponding load history and damage estimate. As described below, processes 920, 930, 940, and 950 provide examples of how load history can be used according to this disclosure.

[0081] Process 920 relates to design and includes steps 922 and 924. Step 922 includes determining or modifying design parameters for vehicle components or systems. For example, at step 922, a load history can be generated for each trip log, and a distribution can be generated. The distribution may include the percentage of vehicles with accumulated load (e.g., load value at the end of the vehicle's life). Thus, the percentage of vehicles within a load threshold can be determined. Step 924 includes updating the load history based on design parameters. For example, for a predetermined percentage threshold (e.g., 95%, 97%, or other suitable value), the design parameters can be updated in a load model or damage model at step 924, and the load history can be updated based on the updated model. In another example, the lifespan can be extended to achieve additional load values. Therefore, an iterative process 920 can be applied to align predetermined load values ​​and predetermined percentages. For example, iteration can continue until 95% of the vehicles have a predetermined number of cycles, miles, actuation, (discharge) charge cycles or start / stop, total load, damage metric, wear metric, any other suitable metric, or any combination thereof. In another example, iteration can continue until 99% of the vehicles reach a predetermined number of cycles, miles, actuation, (discharge)-charge cycles or start / stop, total load, damage metric, wear metric, any other suitable metric, or any combination thereof. In some implementations, the distribution of design parameter values ​​can be applied as part of the load model to generate a load history with a distribution of cumulative load. Therefore, iteration is not required, and the distribution of cumulative load can be analyzed to determine the design parameters that optimally produce the target values ​​(e.g., a percentage threshold for the vehicles).

[0082] Process 930 involves testing and includes steps 932 and 934. Step 932 includes determining or modifying test parameters for a vehicle component or system. Step 934 includes performing tests on the vehicle component or system. The distribution may include a percentage of the vehicle with accumulated loads (e.g., load values ​​at the end of the vehicle's life). Thus, a set of tests can be applied to predict failures, wear, damage, or other usage characteristics. Step 934 includes performing tests on the vehicle component or system based on test parameters, which may include forces, torques, pressures, stresses, strains, displacements, cycle counts, any other suitable parameters, any scheduling or modulation thereof, or any combination thereof. The test results at step 934 can be used to refine the load model or damage model, which can be used for iteration at step 910 (e.g., for design process 920, which may be performed consistently with process 930).

[0083] Process 940 involves determining warranty information and includes steps 942 and 944. Step 942 includes determining or modifying warranty information for a vehicle component or system. Step 944 includes generating a warranty notice for the vehicle component or system. For example, step 942 may include selecting a load or damage threshold based on the load history from step 910. For example, if a particular vehicle component or system is covered under warranty for a target number of miles or years, the load history can be used to determine the distribution of damage or use of that particular vehicle component or system over time. To align a target number of vehicles within a window corresponding to vehicles that do not have the expected warranty issues (e.g., have load or damage metrics below the threshold), the warranty period may be adjusted to produce a target percentage, or process 920 may be used to modify the design so that the distribution obtained after step 910 reaches the target percentage. Thus, a warranty notice can be generated at step 944 once the distribution results in an estimated target percentage of vehicles having load or damage thresholds. For example, process 940 can be applied before sale to adjust vehicle design and warranty design based on expected loads or damage to vehicle components or systems, as determined based on the load history of step 910.

[0084] Process 950 relates to managing vehicle maintenance and includes steps 952 and 954. Step 952 includes determining or modifying maintenance parameters for vehicle components or systems. For example, a maintenance schedule may be determined for vehicle type, where a set of maintenance operations will be performed at vehicle usage time or mileage milestones. Step 954 includes scheduling, executing, or simultaneously scheduling and executing maintenance for vehicle components or systems (e.g., maintenance-based scheduling). For example, step 952 may include selecting load or damage thresholds based on the load history from step 910. For example, if a particular vehicle component or system will be maintained at a target mileage or years, the load history can be used to determine the distribution of damage or use of that particular vehicle component or system over time. To align a target number of vehicles within a window corresponding to expected maintenance (e.g., load or damage metrics that are less than or meet a threshold), maintenance timing may be adjusted to produce a target percentage, or process 920 may be used to modify the design such that the distribution obtained after step 910 achieves the target percentage. Therefore, once the distribution results in an estimated target percentage of vehicles having load or damage thresholds, a maintenance plan can be determined, and maintenance can be scheduled and performed at step 954. For example, process 9450 can be applied to adjust vehicle design and maintenance plans based on anticipated loads or damage to vehicle components or systems, as determined based on the load history from step 910.

[0085] Figure 10 This is a flowchart of an exemplary process 1000 for applying travel logs to improve fault analysis, based on some embodiments of this disclosure.

[0086] Step 1002 includes generating a travel log for each of the multiple user profiles. For example, step 1002 may correspond to steps 902 through 908 of process 900. Step 1002 may include generating N travel logs, each travel log including a corresponding number of trips with driving cycles and multiple charging events. In an exemplary example, at step 1002, for each of the N user profiles, the system may generate multiple entries (e.g., M entries for user profile j). j N travel logs can be generated (e.g., some users may have fewer or more entries than others). For each entry, the system can determine multiple corresponding pieces of information (e.g., along the rows in panel 1050), illustrated with headings A through Z (e.g., although any suitable number of headings may be used). In some implementations, for example, each travel log is generated independently, and the set is used to represent multiple real-world drivers and vehicles.

[0087] Step 1004 includes determining the component load based on component reference information and each trip log. For each trip log corresponding to a corresponding user profile, the component load can be determined. For example, each trip log may include loads on the vehicle component and usage information. For example, loads may include forces (e.g., such as shear force, bending force, tension, compressive force), torque, number of cycles, any other suitable load indication, or any combination thereof. In another example, for each trip in the trip log, vehicle speed, acceleration / deceleration, braking action, suspension action, current distribution, voltage distribution, temperature, thermal behavior (e.g., heat generation), and number of cycles can be determined and included in the trip log. Therefore, for each trip log, a load history can be generated, including a multi-trip, multi-year history of loads applied to the vehicle component or system. The collection of all load histories then provides a rich set of information to which statistical analysis can be applied (e.g., at step 1006). In some embodiments, the component reference information may include usage patterns, displacement patterns, material properties, characteristics, interfaces, any other suitable information corresponding to the component, or any combination thereof.

[0088] In the illustrative example, at step 1004, the system can generate a load for each trip in each travel log. This load may include loads (e.g., force, torque, stress, strain), number of cycles, any other suitable information corresponding to a fault or damage, or any combination thereof. Panel 1051 illustrates the generation of N load histories, one load history per travel log, and each load history may include a total T for user j. jFor each of the T trips in each trip log, the system can determine the load metric based on a model (e.g., a load model, dynamic model, kinetic model, lookup table, or any other suitable type of model). In some implementations, in addition to the trip (e.g., the location of the vehicle's journey), the trip log may also include charging events that can be included in the load history. For example, for vehicle components or systems used during charging, such as battery systems and on-board charging systems, which may be subjected to loads (e.g., cycling) during charging, a usage, wear, or damage model can be applied at step 1006.

[0089] Step 1006 includes determining the cumulative load based on the component load from step 1004. The cumulative load is based on the load for each trip of each vehicle. While load history may include time-based or event-based load sequences, the cumulative load represents the value at the end of a time or sequence, corresponding to the total wear at a point after significant use (e.g., at the end of life, the end of a warranty span, or other final milestone). Damage models can be applied to the load sequences to calculate the cumulative load or damage estimate. In some embodiments, step 1006 includes determining a single damage prediction (e.g., a total of N values) for each vehicle based on a single load pattern and a damage pattern. In some embodiments, step 1006 includes determining D damage prediction values ​​(e.g., a total of D values) for each vehicle based on one or more load patterns and one or more damage patterns. (N values). For example, the damage model may include a spalling model and a fracture model, or any other set of models corresponding to the respective damage modes. In another example, the damage model may include a thermal model to estimate temperature, temperature difference, heat transfer rate, gradient, their maximum or minimum values, or any combination thereof. In another example, the damage model may include an electrical model to estimate current, voltage, voltage difference, power ratio, resistance or impedance, their maximum or minimum values, or any combination thereof. In another example, the damage model may include a flow model or a hydrodynamic model to estimate pressure, pressure difference, corrosion, their maximum or minimum values, or any combination thereof. In another example, the model may include a multiphysics model, which may include aspects of electromagnetic, heat transfer, hydrodynamic, solid dynamics, surface chemistry, any other suitable physical or chemical phenomena, or any combination thereof.

[0090] In an illustrative example, at step 1006, the system may determine a damage metric for each load history and for each user profile. Panel 1060 illustrates a distribution of damage metrics (e.g., with N data points) that can be generated based on N load histories and a damage model. For example, in some implementations, for each load history, the system may determine a damage metric corresponding to the corresponding damage pattern and then generate a damage distribution based on the N metrics (e.g., one metric for each trip log and corresponding load history). Each metric may be a representative sum of columns corresponding to the table in panel 1051. For example, a distribution similar to that shown in panel 1060 may be generated for each load metric (e.g., each column) of the table in panel 1051. In another example, a distribution similar to that shown in panel 1060 may be generated based on multiple load metrics (e.g., several columns) of the table in panel 1051. For illustration, the distribution may include values ​​of the damage metrics over the vehicle's lifespan or other suitable reference time. Time may be specified, and damage metrics corresponding to each time may be extracted for each damage prediction and aggregated to form a distribution (e.g., distribution 1061 as shown). In some implementations, the data collected at step 1005 (e.g., validation data from vehicles in the field corresponding to the vehicle type) can be used to validate the load model, damage model, or both (e.g., to adjust the model). For example, distribution 1062 can be generated based on the data collected at step 1005. In some implementations, as shown, 95th percentile damage estimates can be generated for the modeling data (e.g., estimate 1063) and the collected data (e.g., estimate 1064), and compared to validate the load and damage models. The exemplary distribution of panel 1060 can be similarly generated for any suitable damage prediction, optionally incorporating any suitable validation data. Based on the analysis of the distribution determined at step 1006, design, testing, maintenance, or warranty actions can be identified or modified. For example, for a target load, the system can determine a subset of the load history that achieved the target (e.g., a portion of a travel log).

[0091] At step 1008, the system determines, for example, critical lifecycle loads for durability design. In some implementations, the system may identify the Nth percentile (e.g., 95% or any other suitable target) damage estimate and validate or modify design parameters for vehicle components or systems. For example, process 1000 may be iteratively applied to determine optimized design parameters. Design parameters may include material selection, thickness, diameter, width, length, cross-section, angle, shape, profile, characteristic features, any other suitable dimensional or compositional aspects, or any combination thereof. For example, the diameter or taper of a half-shaft in a vehicle drivetrain may be determined based on iterative application of process 1000.

[0092] At step 1010, the system identifies, for example, key lifecycle loads for testing and test selection. In some embodiments, the system may identify test types and test conditions to accept vehicle components or systems for model validation. The load history generated at step 1004 or the damage prediction determined at step 1006 can be used to customize the testing process. For example, process 1000 can be iteratively applied to determine optimized design parameters. Test parameters may include duration, test load, number of cycles, load variation, any other suitable aspect of the test component or system, or any combination thereof. For example, test conditions may be determined based on iterative application of process 1000.

[0093] At step 1012, the system identifies critical lifecycle loads to assess, for example, field warranty estimates. In some implementations, the system may identify reliability targets for vehicle components or systems. For example, process 1000 may be iteratively applied to determine optimized warranty information. Warranty information may include time periods, failure or damage modes, expected failure rates (e.g., based on damage predictions), any other suitable information corresponding to the component's lifespan and its replacement, or any combination thereof. For example, warranty information may be determined or modified based on iterative applications of process 1000.

[0094] In an exemplary example, the system may generate multiple trip logs based on multiple comprehensive user profiles (e.g., at step 908 or step 1002). The trip logs may be based in part on trip patterns, which may include route information (e.g., number of turns, turn severity), driving style (e.g., speed or average speed over time, peak acceleration / deceleration, average acceleration / deceleration), or combinations thereof, which may be input to a vehicle propulsion model (e.g., at step 906 or step 1004). The vehicle propulsion model may output loads from the trip logs for each trip throughout the vehicle's lifespan, such as the torque and joint angle of the vehicle's half-shafts. Half-shafts connect gearboxes to wheels, and spalling may occur based on torque, steering angle, and ground clearance (e.g., the aggressiveness of vehicle driving). A damage model may be applied to the output loads to estimate damage for each trip of each vehicle. For example, referring to a vehicle half-shaft, the damage model may include a spalling damage model, which can be applied to each trip to generate a cumulative half-shaft spalling damage prediction for each trip log (e.g., for each of N vehicles in a set of N users). Based on the cumulative damage prediction generated at step 1006, the system can determine a damage threshold over the vehicle's lifespan for each load history. For example, a quantitative damage estimate can be determined by specifying a percentage (e.g., 90%, 95%, 99%, or any other suitable threshold) corresponding to the cumulative damage prediction (e.g., the distribution of the cumulative damage prediction across the N vehicles). In another example, the design can be adjusted via iterative process 1000 so that the percentage aligns with a target damage metric (e.g., by adjusting the distribution).

[0095] The foregoing description is merely illustrative of the principles of this disclosure, and various modifications can be made by those skilled in the art without departing from the scope of this disclosure. The above embodiments are presented for illustrative purposes and not for limitation. This disclosure may also take many forms other than those expressly described herein. Therefore, it should be emphasized that this disclosure is not limited to the methods, systems, and apparatus expressly disclosed, but is intended to include variations and modifications thereof, which are within the spirit of the following claims.

Claims

1. A method, the method comprising: The processing equipment uses driving cycle information and charging information based on multiple travel modes and vehicle types to generate travel logs for each user profile in multiple user profiles, thus generating multiple travel logs. Based on the multiple travel logs, generate multiple load histories for vehicle components corresponding to the vehicle type; The distribution of load parameters is generated based on the multiple load histories; as well as The processing equipment is used to determine vehicle information based on the distribution of the load parameters.

2. The method according to claim 1, further comprising generating design parameters for the vehicle component based on the plurality of load histories.

3. The method of claim 1, further comprising generating test parameters for the vehicle component based on the plurality of load histories.

4. The method of claim 1, further comprising generating maintenance parameters for the vehicle components based on the plurality of load histories.

5. The method of claim 1, further comprising modifying at least one of the following based on the plurality of load histories: (i) design parameters of the vehicle component or (ii) test parameters of the vehicle component.

6. The method according to claim 1, further comprising: Warranty information corresponding to the vehicle component is determined based on the plurality of load histories, wherein the warranty information includes a target warranty life for the vehicle type, and wherein each of the plurality of travel logs spans the target warranty life; as well as A warranty notice is generated based on the warranty information.

7. The method according to claim 1, further comprising: The remaining life of the vehicle components is determined using the processing equipment based on the multiple load histories. as well as An indication of the remaining lifespan is generated at the user interface.

8. The method of claim 1, further comprising updating a threshold corresponding to the plurality of load histories in a memory storage device of the vehicle of the vehicle type.

9. The method according to claim 1, further comprising: Receive update information corresponding to the vehicle component; as well as The multiple load histories are updated based on the updated information.

10. The method of claim 1, further comprising generating a damage distribution based on the plurality of load histories and damage models.

11. The method of claim 1, wherein each travel log comprises a plurality of corresponding trips, and wherein generating the plurality of load histories comprises applying a load model to each of the plurality of corresponding trips.

12. The method of claim 1, further comprising determining the plurality of user profiles based on a plurality of predetermined user prototypes corresponding to a target customer group.

13. The method of claim 1, further comprising generating the plurality of travel patterns based on a stochastic multi-year model.

14. The method of claim 1, wherein the plurality of user profiles are a first plurality of user profiles, the method further comprising: Identify the second or more user profiles; as well as The travel log is generated repeatedly for each user profile, and the multiple load histories are generated based on the second multiple user profiles.

15. The method of claim 1, wherein generating the travel log for each of the plurality of user profiles comprises: For each user profile, a travel pattern is generated to produce the multiple travel patterns corresponding to the vehicle type; Based on the multiple travel modes and the driving cycle information, a driving history is generated for each user profile to produce multiple driving histories. as well as The charging information is generated based on each user's travel patterns and driving history in their profile.

16. The method according to claim 1, further comprising: Identify a subset of user profiles corresponding to attributes in the plurality of user profiles, wherein the subset of travel diaries in the plurality of travel diaries corresponds to the subset of user profiles; The target stress corresponding to the vehicle component is identified based on the subset of travel logs. as well as At least one of the design parameters, test parameters, maintenance parameters, or warranty parameters is determined based on the target stress.

17. A system comprising: Processing equipment, the processing equipment being configured to: Based on driving cycle information and charging information of multiple travel modes and vehicle types, a travel log is generated for each user profile in multiple user profiles to produce multiple travel logs. Based on the multiple travel modes, generate multiple load histories for vehicle components corresponding to the vehicle type; The distribution of load parameters is generated based on the multiple load histories; as well as Vehicle information is determined based on the distribution of the load parameters.

18. The system of claim 17, wherein the processing equipment is further configured to generate the travel log for each of the plurality of user profiles by: For each user profile, a travel pattern is generated to produce the multiple travel patterns corresponding to the vehicle type; Based on the multiple travel modes and the driving cycle information, a driving history is generated for each user profile to produce multiple driving histories. as well as The charging information is generated based on each user's travel patterns and driving history in their profile.

19. A non-transitory computer-readable medium having instructions encoded thereon, the instructions causing the processing equipment, when executed by a processing equipment, to: Based on driving cycle information and charging information of multiple travel modes and vehicle types, a travel log is generated for each user profile in multiple user profiles to produce multiple travel logs. Based on the multiple travel modes, generate multiple load histories for vehicle components corresponding to the vehicle type; The distribution of load parameters is generated based on the multiple load histories; as well as Vehicle information is determined based on the distribution of the load parameters.

20. The non-transitory computer-readable medium of claim 19, further comprising instructions for causing the processing apparatus to generate the travel log for each of the plurality of user profiles by: For each user profile, a travel pattern is generated to produce the multiple travel patterns corresponding to the vehicle type; Based on the multiple travel modes and the driving cycle information, a driving history is generated for each user profile to produce multiple driving histories. as well as The charging information is generated based on each user's travel patterns and driving history in their profile.

Images