DATA-DRIVEN SYSTEMS AND METHODS FOR PRODUCEING DAILY VEHICLE LOGS FOR DURABILITY AND RELIABILITY ASSESSMENTS

Abstract

The system creates a logbook for each user profile out of a multitude of user profiles, based on a variety of travel patterns, vehicle type driving cycle information, and load information, resulting in a multitude of logbooks. Based on these logbooks, the system generates a multitude of load profiles for each vehicle component of the vehicle type and determines a load parameter distribution. This distribution is used to update vehicle information. For example, the distribution can be used to reconcile or verify a design parameter, a test parameter, a maintenance parameter, or a warranty parameter.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] This application claims the benefit of the preliminary US patent application No. 63 / 726,465, filed on November 29, 2024, which is hereby incorporated herein by reference in its entirety. INTRODUCTION

[0002] The present disclosure is directed towards the production of logbooks of vehicle usage for durability and reliability assessments. SUMMARY

[0003] Under certain circumstances, stress factors, including tensile, electrical, thermal, and structural loads, influence vehicle design and durability. For electric vehicle drive systems, for example, the present disclosure can be applied to analyze the magnitude and repetition of these loads, as well as their temporal evolution over the vehicle's lifetime. The sequence, timing, and characteristics of these loads over the lifetime can affect factors such as charge and discharge cycles, active motor heating, and damage to drive system components (e.g., batteries, inverters).In some embodiments, instead of relying solely on a single-user load profile that exhibits representative driving cycles with respect to cumulative damage corresponding to the actual damage covered by the warranty, the present disclosure utilizes high-resolution, cloud-based vehicle data, thereby generating a representative population that accurately reflects the frequency, type, and sequence of real driving, parking, and charging loads. In some embodiments, the method and systems of the present disclosure integrate reference information (e.g., vehicle-measured data, investigation data, and test data) to model user journey patterns, driving profiles, and charging behavior.In some embodiments, the present disclosure is aimed at generating lifetime vehicle usage patterns for a diverse group of users and identifying warranty-critical failures for one or more components or systems of the vehicle. For example, the warranty-critical failure for each component may occur in a different subset of users, whereby the total population covers the durability loads for the entire powertrain system or vehicle.

[0004] In some embodiments, the present disclosure relates to methods for generating load profiles for use in design, testing, maintenance, and warranty analysis. The methods can be performed by processing equipment based on computer instructions stored on a non-volatile, computer-readable medium. The methods include creating a logbook for each user profile of a plurality of user profiles based on a plurality of trip patterns, driving cycle information of a vehicle type, and load information to produce a plurality of logbooks. The methods also include generating a plurality of load profiles corresponding to a vehicle component of the vehicle type based on the plurality of logbooks and determining a distribution of load parameters based on the plurality of load profiles.In some embodiments, generating the logbook for each user profile of the plurality of user profiles includes generating a trip pattern for each user profile to produce the plurality of trip patterns according to the vehicle type, generating a trip history for each user profile based on the plurality of trip patterns and based on driving cycle information of the vehicle type to produce a plurality of trip histories, and generating the charging information based on the trip pattern and trip history for each user profile. In some embodiments, the methods include determining the plurality of user profiles based on a plurality of predetermined user archetypes corresponding to a target customer base. In some embodiments, the methods include generating the plurality of trip patterns based on a stochastic, multi-year model.In some embodiments, the plurality of user profiles is a first plurality of user profiles, and the methods include determining a second plurality of user profiles and repeating the generation of the logbook for each user profile and the generation of the plurality of load profiles based on the second plurality of user profiles. In some embodiments, each logbook includes a respective plurality of trips, and the generation of the plurality of load profiles includes applying a load model to each respective plurality of trips.

[0005] In some embodiments, the methods include determining an estimated lifetime of the vehicle component based on the multitude of load profiles and vehicle component information. In some embodiments, the methods include identifying a subset of user profiles from the multitude of user profiles corresponding to an attribute, wherein a subset of logbooks from the multitude of logbooks corresponds to the subset of user profiles. In some such embodiments, the methods include identifying a target load corresponding to the vehicle component based on the subset of logbooks and determining at least one of a design parameter, a test parameter, a maintenance parameter, or a warranty parameter based on the target load.In some embodiments, the methods include generating a design parameter for the vehicle component based on a multitude of load profiles or distributions, and manufacturing the vehicle component based on the design parameter. In some embodiments, the methods include generating a test parameter for the vehicle component based on a multitude of load profiles or distributions, applying test conditions to the vehicle component based on the test parameter, and recording data corresponding to the vehicle component's response to the test conditions. In some embodiments, the methods include generating a maintenance parameter for the vehicle component based on a multitude of load profiles or distributions, and scheduling maintenance of the vehicle component based on the maintenance parameter.In some embodiments, the methods include modifying, based on the plurality of load profiles or the distribution, at least one of (i) a design parameter of the vehicle component or (ii) a test parameter for the vehicle component. In some embodiments, the methods include determining warranty information corresponding to the vehicle component based on the plurality of load profiles and generating a warranty notification based on the warranty information. For example, the warranty information includes a target warranty period for the vehicle type, and each of the plurality of logbooks covers the target warranty period. In some embodiments, the methods include determining a remaining service life of the vehicle component based on the plurality of load profiles and generating a display of the remaining service life on a user interface.In some embodiments, the methods include updating a threshold corresponding to the plurality of load profiles in a memory of a vehicle of the specified vehicle type. In some embodiments, the methods include receiving updated information corresponding to the vehicle component and updating the plurality of load profiles based on the updated information. In some embodiments, the methods include generating a usage distribution for one or more loads based on the plurality of logbooks. In some embodiments, the methods include generating a damage distribution for one or more loads based on the plurality of logbooks and a damage model.In some embodiments, the multitude of load profiles includes a damage distribution for the multitude of travel patterns, and the methods include determining the damage distribution based on the multitude of travel patterns and reference information corresponding to the vehicle component.

[0006] In some embodiments, the present disclosure relates to systems for generating load profiles for use in design, testing, maintenance, and warranty analysis. The systems can be implemented by processing equipment based on computer instructions stored on a non-volatile, computer-readable medium, wherein the computer instructions are executable by the processing equipment to perform any of the methods described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present disclosure is described in detail according to one or more different embodiments with reference to the following figures. The drawings are for illustrative purposes only and represent only typical or exemplary embodiments. These drawings are provided to aid understanding of the concepts disclosed herein and are not to be construed as limiting the breadth, scope, or applicability of these concepts. It should be noted that, for the sake of clarity and to simplify presentation, these drawings are not necessarily to scale. Fig. Figure 1 is a block diagram of an illustrative system for managing population information for usage dynamics according to some embodiments of the present disclosure; Fig. Figure 2 is a block diagram of an illustrative system for creating logbooks according to some embodiments of the present disclosure; Fig. Figure 3 is a block diagram of illustrative driving information according to some embodiments of the present disclosure; Fig. 4A and Fig. 4B show illustrative driving information according to some embodiments of the present disclosure; Fig. Figure 5 is a block diagram illustrating a process for using load information to assign load events according to some embodiments of the present disclosure; Fig. Figure 6 shows illustrative charging information for assigning charging events according to some embodiments of the present disclosure; Fig. Figure 7 is a block diagram illustrating distribution information according to some embodiments of the present disclosure; Fig. Figures 8A-8C show an illustrative output based on logbooks according to some embodiments of the present disclosure; Fig. Figure 9 is a flowchart illustrating a process for creating and using logbooks according to some embodiments of the present disclosure; and Fig. Figure 10 is a flowchart illustrating a process for using logbooks to improve fault analysis according to some embodiments of the present disclosure. Description

[0008] Vehicle powertrain systems generally need to be designed to be durable and reliable over the vehicle's design lifetime, for example, to minimize wear and warranty claims. Durable designs may require estimating the fluctuations and accumulations of loads that can be, or are expected to be, applied to the vehicle's powertrain over its lifetime. These loads may be applied by customers in the field. Identifying the most damaging real-world loads that are applied or are expected to be applied can aid in generating durable designs. Currently, this estimation is typically performed using expert opinions (e.g., based on field failures) and limited data from new vehicles, taking into account the most conservative load patterns.This creates the potential for either over- or under-dimensioning each of the various components, thereby increasing design, testing, and warranty costs. Furthermore, an analysis based solely on limited representative historical usage data, user scenarios, and industry experience may fail to capture the diverse failure modes of different powertrain components. For example, reliance on such representative data could force designers to add more material mass, size, and capacity to a vehicle or system, thereby increasing lifecycle emissions, reducing sustainability, and driving up costs.

[0009] The present disclosure relates to methods and systems for combining data from existing customers and real-world driver travel patterns with driving, charging, and weather data from various public databases to generate a synthetic population of customers and their daily vehicle usage, extending from purchase to the end of the vehicle's design lifetime. In some embodiments, the methods and systems of the present disclosure provide lifetime loads for a customer population, enabling a more accurate estimation of warranty-critical loads. Under certain circumstances, this allows for the establishment of more realistic durability and reliability targets and the reduction of costs in design, testing, and warranty claims.For example, the system creates numerous logbooks based on a variety of user profiles, travel patterns, vehicle driving cycle information, and charging information. The system also generates a load profile for each vehicle component based on these logbooks.

[0010] In some embodiments, the present disclosure is aimed at generating day-by-day time-sequenced load patterns for a large number of customers. For example, a day-by-day approach may be preferred over weekly estimates or other coarser estimates. To illustrate, the present disclosure may enable the generation of a large number of towing usage variations (e.g., once a week in the summer, but with varying frequency in the fall) instead of assigning a once-a-week towing load or other coarser approximation.

[0011] In some embodiments, the present disclosure is directed toward creating more realistic customer profiles. For example, instead of attempting to quantify a single worst-case user who might be a warranty-critical user, or a single representative user who might overlook nuances and cross-couplings, the present disclosure is directed toward varying the intensity of different use cases using patterns observed in data to stochastically generate a population of users and then quantitatively arrive at a design-critical customer.While the individual worst-case user can be estimated by combining the most aggressive off-road driving with the most aggressive towing and the most frequent track driving, essentially "stacking the worst cases," this can lead to the creation of a design-critical customer that likely does not exist. The present disclosure is intended to improve the characterization of which customers are design-critical for each system or component.

[0012] In some embodiments, the present disclosure is directed to create logbooks associated with a user population, thereby enabling the identification of which users within the population are design-critical for a particular component or subsystem. In an illustrative example, instead of generating a single design-critical customer for an entire powertrain, the techniques of the present disclosure can distinguish between a user who is most damaging to the engine and one who is most damaging to the battery or the half-shafts, since they need not be the same user.

[0013] In some embodiments, the methods and systems of this disclosure can enable a reduction in vehicle oversizing, component costs, testing costs, and overall vehicle costs. In some embodiments, this disclosure aims to reduce design blind spots that may arise from a lack of real-world usage data, thereby reducing warranty costs. For some components, this could also reduce size and mass, potentially leading to more sustainable vehicles. Such illustrative benefits can, for example, help improve profitability, sustainability, and market performance.

[0014] In some embodiments, the present disclosure is directed toward generating a time sequence of driving, parking, and charging of the vehicle over its lifetime for different customers. For example, different customer archetypes (e.g., aggressive drivers, trailer and off-road vehicle users, cold-climate users) can be identified by analyzing existing fleet data and a target customer population for different vehicle variants. Existing publicly available travel pattern data (e.g., the U.S. Department of Transportation's National Household Travel Survey) can be used to create trip logs (e.g., a trip-by-trip list of journeys over the vehicle's lifetime) for the different customers.Similarly, fleet data, public driving data, any other suitable data, or any combination thereof can be analyzed to generate, for example, a set of representative real-world driving cycles for on-road driving, off-road driving, towing, and track driving. Each trip in the logbook can be linked to a representative driving cycle. Subsequently, charging sessions (e.g., slow and fast charging sessions) between driving events are introduced into these logbooks using an analysis of reference charging behavior (e.g., from fleet data). Accordingly, customer usage logbooks are created with a sequence of driving (e.g., different types of trips and driving styles), parking (e.g., in different locations and at different times), and charging (e.g., using different charger types).These logs can then be converted into load sequences using vehicle simulation models to generate vehicle-specific lifetime load patterns for customers. For example, these loads can form the basis for setting design and testing targets for durability and reliability. This approach enables the generation of customer usage distributions, quantifying the loads and activities to which the vehicle is subjected during its lifetime (e.g., warranty period) with the customer. This disclosure can be applied to the durability and reliability of the powertrain or to any other component or process of the vehicle. For example, this disclosure can be applied to understand the structural stresses in the design of chassis and body structures (e.g.,The stress on the door handle and hinge can be estimated based on the distance traveled, the frequency and number of door openings. In another example, the present disclosure can also be implemented to analyze and modify how and in what order a vehicle's thermal system or lighting is used, thereby influencing its design. In some embodiments, the present disclosure is applied to estimate a "remaining lifetime" that can be used to design controls that increase real-world range or maintain system performance as the vehicle ages. In some embodiments, the present disclosure provides a pathway to customized vehicle controls to enhance a targeted customer experience.

[0015] Fig. Figure 1 is a block diagram of an illustrative system 100 for managing population information on usage dynamics according to some embodiments of the present disclosure. As illustrated, the system 100 includes a travel manager 110, a drive manager 120, a load manager 130, reference information 170, design target information 180, and an output manager 190. For example, the reference information 170 and the design target information 180 can be received by the travel manager 110, the drive manager 120, and the load manager 130 to produce an output 135, which is provided to an output manager 140, which can then provide updated information 199 to iterate, repeat, or refine the output 135.

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

[0017] The travel manager 110 is configured to create or retrieve user archetypes, customer information 181, and travel data 171, and to generate travel patterns for each user profile from a multitude of user profiles. Each user profile can be created based on a combination of distributions of user types, and each user profile can correspond to a vehicle instance. The travel pattern can be generated based on a stochastic model (e.g., a Markov chain or any other suitable model) that sequences a multitude of events representing driving activities or other vehicle usage activities with a daily resolution. The travel pattern can span years, for example, corresponding to an expected vehicle lifespan, a target warranty period, or any other predetermined period of interest for lifecycle analysis of vehicle components and systems.The Travel Manager 110 outputs a variety of travel patterns, one for each user, which includes a sequence of many vehicle usage events (e.g., trips).

[0018] The Trip Manager 120 is configured to use trip patterns as input, assign a trip cycle to each vehicle usage event (e.g., each trip), and apply vehicle load information. For example, a trip pattern might include a commute, and the Trip Manager 120 can apply a trip cycle to the trip that corresponds to a commuter trip cycle. The trip cycle can include an average speed (e.g., based on distance or road type); a number of stops, starts, and turns; average acceleration and / or peak acceleration / deceleration; average or peak engine speed, transmission speed, shaft speed, wheel speed, or any other indication of a load; a predefined template selected from a variety of templates appropriate to the type of trip; any other suitable usage information; or any combination thereof.In some embodiments, the trip manager 120 can use vehicle information 182 as input, which may include trip cycle information (e.g., templates) for the vehicle type being analyzed. The vehicle type and the corresponding vehicle information 182 may include a production vehicle (e.g., a vehicle available for sale with examples on the road), a concept vehicle (e.g., in the concept or design stage), or any other vehicle for which usage events and trip cycles can be estimated. The output of the trip manager 120 may include a trip cycle for each trip for each user profile (e.g., a total equal to the sum of all trips for all user profiles).

[0019] The Charge Manager 130 is configured to use driving cycles, charge information 183, and charge data 173, along with determined charging behavior information, as input to assign charging events to each trip log. For example, the input to the Charge Manager 130 can be a sequence of events for each user profile, which may include driving events (e.g., trips). The Charge Manager 130 can apply a discharge / charge model (e.g., based on information from charge information 183, charge data 173, or both) to determine a state of charge for the vehicle before, during, or after each event. Based on a charging behavior model, the Charge Manager 130 can determine when a specific user profile will charge and which type of charger will be used.For example, charging behavior can be determined for each user profile based on statistical data and actual charging behavior, along with predicted charging behavior for each user archetype. The Charge Manager 130 can sequentially analyze driving cycles to determine a charging event, insert a charging event into the logbook, determine a new state of charge, and repeat the process as it continues through the rest of the sequence. For example, the Charge Manager 130 can insert multiple charging events for each user profile (e.g., for each logbook) at a suitable point within the event sequence, add a state of charge measurement to each driving event in the logbook (e.g., a charging measurement), insert a cumulative number of charging events / cycles, or a combination thereof.The output of the Charging Manager 130 can be a multitude of logbooks, one for each user profile, each containing a multitude of driving and charging events arranged in a sequence that extends over a predetermined period (e.g., a target vehicle lifetime).

[0020] The output manager 140 is configured to evaluate results based on predetermined criteria (e.g., using load models, damage models, or any other suitable models), create distributions based on measurements specific to each logbook, perform updates or modifications to design parameters, test parameters, warranty information (e.g., warranty notifications), save results or data for use in future modeling (e.g., saved in reference information 170, design target information 180, or both), perform any other suitable actions, or a combination thereof.For example, Output Manager 140 can be configured to perform or manage iterations by determining results and disrupting one or more of Trip Managers 110, Driving Managers 120, or Charging Managers 130 based on updates to trip patterns, driving cycles, or charging events. To illustrate, Output Manager 140 can analyze results and then modify a component design, which may require updating vehicle load information to generate the driving cycles and charging behavior (e.g., the trip pattern may persist under certain circumstances).

[0021] Fig. Figure 2 is a block diagram of an illustrative system 200 for creating logbooks according to some embodiments of the present disclosure. In some embodiments, system 200 is an example of system 100 of Fig. 1. As illustrated, the system 200 includes a trip pattern generator 210, a driving cycle generator 220, a charging behavior generator 230, and a lifetime load generator 240. For example, the system 200 can take as input one or more data sets, parameters, algorithms, any other suitable information, or any combination thereof, and then output logbooks assigned to one or more simulated users for a predetermined warranty period of a vehicle. The logbooks can be used by a damage estimator to determine a distribution of expected usage, damage, wear rates or amounts, number of cycles, condition measures, or any other suitable measure corresponding to one or more components, subsystems, or assemblies of the vehicle.For example, a total of N logbooks can be generated for a predetermined warranty period of Y years or M miles of usage for a specific vehicle make / model / configuration. These N logbooks can be fed into models to determine system usage estimates. The distribution of these usage estimates can then be analyzed to determine aggregated cumulative usage distributions. This distribution can also include energy throughput, mileage, number of charges, average speed, state of charge (SOC), any other suitable values, or distributions thereof.

[0022] In some embodiments, the trip pattern generator 210 determines user archetypes based on trip data 271. The trip pattern generator 210 creates a trip log for each user in a group of simulated users, starting from an initial time (e.g., purchase of the vehicle) to an end time (e.g., a predetermined number of days, years, or miles). For each user, the trip pattern generator 210 generates a sequence of trips, with multiple trips possible per day. In some embodiments, a set of rules is applied for each day to determine the trips for that day. In some embodiments, the trip pattern generator 210 can stochastically chain trip days using one or more chaining rules. The trip pattern generator 210 can include a frequency of different driving modes (e.g., trailer frequency) and distribution parameters that specify the intensity of use (e.g.,estimate trailer weight), extract representative travel days (e.g. sequence of driving activities on weekdays, weekends, in summer and winter), generate stochastic driving history using rule-based Markov chaining, or a combination thereof.

[0023] In some embodiments, the driving cycle generator 220 determines a driving cycle for each trip in each user's logbook. A driving cycle can include, for example, a time series of speed, gradient, towing, any other variable, or any combination thereof for each trip. Based on driving cycle information, the driving cycle generator 220 can determine mean speed, variation in acceleration, variation in gradient, vehicle mass, variation in lateral acceleration, trip length, or any other suitable measurement to determine torque, power, current, temperature, or any other quantity. The driving cycle generator 220 can use a model of the drive system to estimate torque, power, current, temperature, or the other quantity for each trip on each day for each user. The driving cycle generator 220 can identify key driving cycle statistics that influence degradation modes (e.g.,(Energy throughput can be most strongly influenced by the average speed and the standard deviation of acceleration during driving), drive cycles are clustered based on these main statistics, and representative drive cycles are selected (e.g., drive cycles with low speed and high acceleration, drive cycles with steep gradient and acceleration), and drive cycles are assigned to the trip history generated by the trip pattern generator 210 to create a driving / idling history. The trip history can also include a parking history.

[0024] In some embodiments, the charging behavior generator 230 determines the charging behavior for each user's driving and parking patterns, for each trip of each day. The charging behavior generator 230 can add charging events to users' trip logs, add charging information for each trip (e.g., after each trip), or otherwise supplement the output of the driving cycle generator 220 with charging information. The charging behavior generator 230 can extract representative charging parameters from fleet charging behavior (e.g., probability of connecting at different states of charge), calculate a change in state of charge based on the driving history, and assign a charging session when the vehicle is parked appropriately.

[0025] In an illustrative example, the system can create logbooks 231 which, after processing by the charging behavior generator 230, include a list of events for each user. For example, for each user out of N total users, the respective logbook 231 can include a list of driving events and charging events. For example, as illustrated, logbooks 231 can include a number of rows corresponding to the sum across all user profiles of all driving events for each user profile.

[0026] In some embodiments, the lifetime load generator 240 determines damage distributions for a component or system of the vehicle. For example, because the logbook includes detailed information, the lifetime load generator 240 can determine the number of certain events, the intensity of certain events, cumulative loads, or other values ​​to estimate wear, damage, or service life. In another example, the lifetime load generator 240 can generate a histogram corresponding to a distribution of results (e.g., energy consumption in W*h / mile, % of users with cell welding damage, % of users with power module damage, user mileage over a period such as 10 years, % of medium-speed driving). In yet another example, the lifetime load generator 240 can determine a distribution of percentages of driving types (e.g.,Neighborhood, city street, urban hill climb, country road, motorway, mountain climb, Davis Dam incline, high-speed track or any other suitable driving cycle).

[0027] In an illustrative example, the system can aim to replicate the vehicle usage of a real-world customer population and includes the correct proportion of different archetypes of users that constitute the target customer population for the vehicle (e.g., the correct proportion of users in regions with varying ambient temperature fluctuations, users who drive off-road, and users who tow trailers). The system assigns each user in the synthetic population a sequence of trip, drive, park, and charge operations, and each such operation is quantified (e.g., the type of drive and drive cycle, as well as the type and amount of charge). The system can use data from telemetry and surveys and utilize a sequence of three models: trip, drive, and charge models.

[0028] In another example, the system can use time-series data as input, including vehicle speed, gradient, driving mode, ambient temperature, battery state of charge (SOC), and charging type or power. The system can also use additional data as input, such as location, trip purpose, energy consumption, or similar information. Under certain circumstances, time-series data may be available in vehicle telemetry data or combined from various sources (e.g., it is not necessary to obtain all data from the same source). In some embodiments, the system combines time-series and event-based driving, trip, and charging data from different datasets and users to estimate usage patterns.

[0029] In another example, the system can use publicly available datasets corresponding to other vehicles to model usage patterns (e.g., trip survey data from the 2017 National Household Travel Survey (NHTS), driving cycle data from the National Renewable Energy Laboratory (NREL)). Additionally, the system can use telemetry data. In some embodiments, the system does not need to use identifiable information about individual customers and vehicles from telemetry data, but rather aggregated or anonymized data. In an illustrative example, NHTS data can include a description of trips taken on a single day by over 130,000 different households in the United States on various days of a year. This data includes the day, date, length, duration, purpose, origin, destination type, trip departure time, odometer reading, and vehicle type.Furthermore, NREL driving cycle data can include approximately 120,000 GPS-based vehicle speed time series collected from various vehicles in the USA. The present disclosure may use such data, any other suitable data, or any combination thereof. Travel patterns

[0030] Fig. Figure 3 is a block diagram illustrating travel information 300 according to some embodiments of the present disclosure. The travel information 300 may include information about the sequence of trips in a day from the household (e.g., from the National Highway Traffic Safety Administration (NHTSA)).

[0031] Each trip can, for example, extend from a starting point to a destination and optionally back to the starting point (e.g., the return trip can alternatively be a separate trip event). For example, an illustrative trip might include an identification of a location (e.g., home, office, work, store, park, identified location on a map), departure and arrival times and dates (e.g., times t0, t1, t2, t3, t4, t5 of Fig. 3), a length of each leg of the journey (e.g. distances d1, d2 and d3 from Fig. 3) include any other suitable information or any combination thereof. Travel information may be stored in any suitable manner on any suitable device. For example, travel information 300 may be stored in cloud-based storage, on a hard drive, a 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 web page), a package, or in any other suitable form. The travel information 300 may be collected from one or more sources by downloading, querying and responding, timed data transmission, or any other suitable method at any suitable interval.

[0032] In some embodiments, the system segments the target population into a variety of user archetypes (e.g., users who drive off-road, tow, do neither, or do both). For example, the system may use a target customer study, telemetry data from existing vehicle fleets, or any other suitable information source. In some embodiments, the system creates a day-by-day log of synthetic users from the day of vehicle purchase (e.g., Day 1) to the end of the vehicle's design life (e.g., Day n), which may span several years. In some embodiments, the system can account for any anticipated change of ownership and adjust the travel pattern accordingly (e.g., updating a user profile based on a different archetype for subsequent events).In some embodiments, the logbook is created by stochastically chaining logbooks based on the travel data using one or more chaining rules. For illustration, the travel events for each day can depend on the events or characteristics of a previous day, a previous event, a season, a time of day, a day of the week, any other suitable information, or any combination thereof.

[0033] In an illustrative example, reference data (e.g., NHTSA data) could include one-day travel data from households in the US over a period of time (e.g., one year). In some embodiments, the system applies a combination of random sampling and chaining, constrained by a set of chaining rules. Accordingly, each user's trip log is created. The chaining rules might include, for example: 1. Travel days assigned to a work week or a weekend must be corresponding work week travel days or weekend travel days from the dataset. This can account for differences in travel patterns on weekends and weekdays; 2. Travel days in a month are selected from travel days observed in the same month from the dataset. This can account for the influence of the seasons on travel patterns; and 3. Each subsequent travel day assigned in the logbook must begin at the same location (e.g., at home, at work, or other suitable locations) where the previous travel day ended (e.g., the last travel event of the previous day).

[0034] Additionally, if a vehicle trip indicates that the vehicle was driven at midnight, the next day can begin with a driving state. The system can generate an output 320, which can include logbooks 321 corresponding to a set of synthetic users and containing time-sequenced patterns of trips and parking (e.g., user identification USER, time / date DAY, start time T1, end time T2, trip type REF, and any other suitable information X). The logbooks 321 can be stored on any suitable device (e.g., storage device 325) in any suitable format (e.g., database 326). Driving cycles

[0035] Fig. Figure 4A is a block diagram of illustrative driving information 400 according to some embodiments of the present disclosure. As illustrated, the driving information 400 includes a distribution of driving cycles (e.g., about 120,000 of NREL) divided into average speed (e.g., ordinate 402 as illustrated) and trip length (e.g., abscissa 401 as illustrated) categories, with the percentage of driving cycles in each category listed within the category. For example, it may be observed that there is a positive correlation between average speed and trip length (e.g., short trips have lower average speeds and long 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 takes place in short trips of less than 10 miles in length and at average speeds below 40 mph (see, for example, fields 410 and 420 of ). Fig. 4B). Each entry (e.g., each discretization 405, as illustrated) can correspond to a number (e.g., the percentage of driving cycles in the distribution), where the shading (e.g., the shading scale 406) corresponds to the percentage of driving cycles. For example, the two-dimensional distribution over abscissa 401 and ordinate 402 can be normalized to one for all driving cycles (e.g., the distribution can be numerically integrated over both dimensions to normalize). In another example, a set of one-dimensional distributions over ordinate 402 for a given width on abscissa 401 can each be normalized to one for all speeds (e.g., the distribution can be numerically integrated over ordinate 402 to normalize). In another example, a set of one-dimensional distributions over the abscissa 401 for a given width in the ordinate 402 can be normalized to one for all journeys (e.g.The distribution can be numerically integrated over the abscissa (401) to normalize it. The ranges of the abscissa (401) and the ordinate (402) can be chosen as any suitable values ​​and can correspond to a range of values ​​in available data. As illustrated, the scale of the abscissa (401) and the ordinate (402) need not be linear or regular, and any suitable discretization can be applied to generate the distribution.

[0036] In some embodiments, the system uses a driving model to assign driving cycles (e.g., time series of speed and gradient) to each trip in the users' logs. In other embodiments, the system analyzes a driving cycle database (e.g., reference driving information) to obtain a reduced set of driving cycles that cover the range of variations in real-world driving (e.g., representative driving cycles). The driving cycles in the driving cycle database can be classified by (e.g., categorized or otherwise arranged, sorted, or grouped by) mean speed, trip length, net change in gradient, standard deviation or other variation in gradient, standard deviation or other variation in acceleration (e.g., representative of driver aggressiveness), any other suitable information, or any combination thereof.For example, for each category, a single driving cycle is selected that is closest to all other driving cycles in that category and is designated as the representative driving cycle for that category. Any suitable measure of the proximity between time series can be used to identify the representative driving cycle for the category (e.g., a Jensen-Shannon divergence). In some embodiments, the system can classify trips based on average speed (e.g., city if less than 35 mph, otherwise highway), adjust driving cycles (e.g., shorten them for length), select driving cycles of a suitable length, use an energy-per-mile estimate to estimate battery state of energy, or use any other suitable criteria.

[0037] Shown in fields 410 and 420 of Fig. 4B are two representative driving cycles for different driving cycle behavior (e.g., categories of discretization of Fig. 4A, for a respective mean driving speed and mean driving length). In fields 410 and 420, the abscissa subdivisions are increments of 1000 seconds, and the ordinate subdivisions are increments of 20 mph. Both categories represent long highway journeys, but with very different mean speeds, thus capturing significant real-world variations in driving that cannot be represented by a single highway cycle. For example, driving cycle 421 in field 420, due to its near-constant high-speed driving, may be more likely to thermally damage a drive system, whereas driving cycle 411 in field 410 may be more likely to damage a gearbox and inverter through sharp accelerations from low to high speeds, resulting in high RMS currents and instantaneous torques.

[0038] In some embodiments, the system assigns a driving cycle to each trip in the logbooks based on a set of identified representative driving cycles. The system can assign the driving cycle 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 can use telemetry data to determine gradient and driving aggressiveness as additional criteria for assigning driving cycles to trips. Using driver aggressiveness as a criterion, for instance, each user can be classified as an aggressive, moderate, or mild driver, and only the driving cycles with correspondingly high, medium, or low standard deviations of acceleration will be assigned to that user.In this way, a user's personal characteristics can influence the selection of the driving cycle for a trip in the logbook assigned to that user.

[0039] In some embodiments, the system uses average driving speed and trip length as indicators of energy consumption during the trip. The system can output a variety of trip logs that exhibit time-sequenced patterns of travel and parking events, quantifying the driving in each travel event using an appropriate driving cycle. For example, the trip log generated based on travel patterns is augmented with driving cycle information to produce an updated trip log. In another example, referencing tabular data, the system populates columns for each row of a trip log (e.g., corresponding to a travel event for a user) with driving cycle information (e.g., driving cycle ID, energy per mile, total miles, average speed, state of charge before and after the trip, and any other suitable information). Charging behavior

[0040] Fig. Figure 5 is a block diagram illustrating process 500 for using charging information to assign charging events according to some embodiments of the present disclosure. The charging information can be used in conjunction with logbooks 231 to determine, for example, charging events over the vehicle's lifetime. For example, a logbook created in step 501 can include a sequence of trips and the driving cycles used on those trips. The system can then use a suitable vehicle model so that the driving cycles can be converted into time series of torque usage, power usage, temperature change, energy usage, any other suitable parameter, or any combination thereof. For example, these quantities represent the load on the vehicle and indicate a cause of wear on the vehicle's components.This information can be supplemented / updated with estimated charging sequence information for the vehicle. This information is important for the charging events themselves and to ensure that the vehicle is able to complete the trips recorded in the logbook. This information also allows the system to account for changes in the vehicle's electrical and thermal loads during and after charging.

[0041] Process 510 is directed towards a mid-trip charge analysis to determine whether each trip can be completed using the state of charge (SOC) at the start of the trip and the trip characteristics. For each trip in each trip log, the system uses a charge model that probabilistically maps charging events between trips (e.g., in each trip log) based on the vehicle's parked location, the available parking time, the vehicle's SOC due to trips undertaken 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 a single trip requires more energy than is available for a full charge (e.g.,If the system determines "NO" (whether energy is available to complete the trip), it can insert a fast-charging session performed during the trip into the trip log (e.g., at step 506). In another example, the system can assume that the trip duration for such trips reported in the trip already includes breaks that can be used for fast charging. Under certain circumstances, the system can assume that the change in trip duration beyond the use of these breaks, if any, is so small that it does not affect the departure time for the next trip in the trip log. In some embodiments, the system implements process 510 to determine, for each trip in each trip log, whether a charging operation must be completed during the trip in order to either complete the trip, a segment, or part of the trip, or otherwise maintain a minimum state of charge (SOC) of the vehicle.In some embodiments, during process 510, the system injects loading events into the logbook at step 506 (e.g., either between trips, within a trip, or between sections of a partitioned trip that have been segmented into one or more sections based on step 506).

[0042] Process 520 is directed towards a post-trip charging analysis to determine whether a charging event needs to be entered into the trip log. Step 512 concludes by determining whether there is sufficient time between events (e.g., the end of one event and the start of the next) to allow L2 charging (e.g., AC charging or lower-current charging). For example, L2 charging could be equivalent to a residential AC charger or otherwise a Level 2 charger. If there is time to achieve 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 the location, the system determines the probability of several types of charging occurring at one or more of steps 522, 526, and 530 and selects, for example, the most probable charging modality.Based on the most likely modality, 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 a potential post-trip state of charge (SOC) based on the next event. The system then proceeds to step 516 to determine if the current SOC is sufficient to reach the next event. If it is, the system proceeds to step 518. If it is insufficient, the system proceeds to step 532 and inserts a public charging session (e.g., one scheduled to take place at a public charging station).

[0043] In an illustrative example with reference to Fig. 5. The system can use a charging model that parameterizes charging behavior using probabilities of connecting to a charger at home, at work, and in public as a function of the vehicle's state of charge (SOC) and a user readiness factor: f_home (SOC, readiness), f_work (SOC, readiness), f_public (SOC, readiness). For example, the user readiness factor is a real number between 0 and 1 and can allow the system to model differences between users regarding their willingness to charge their vehicle. To illustrate, a very risk-averse user who charges when the battery SOC falls below the upper threshold has a user readiness factor of 1. The most risk-prone user, who only charges when the battery SOC reaches its lower threshold or when charging is necessary to complete the next trip, might have a user readiness factor of 0.In some embodiments, each user in the group can be assigned a user readiness factor, randomly selected from a uniform distribution. The probability of unplugging a fast charger can be modeled similarly (e.g., the user does not have to wait until the state of charge (SOC) reaches 100%). In the case of charging at home or at work, it can be assumed that the vehicle is either fully charged or charged until it remains parked before the start of the next trip.

[0044] Fig. Figure 6 shows illustrative charging information for assigning charging events according to some embodiments of the present disclosure. As in Fig. As illustrated in Figure 6, the system can apply one or more charging modes (e.g., Level 2 or L2 charging or Fast Charging (FC)). Fig. Figure 6 shows illustrative examples of charging probabilities that the system can use. Box 610 shows the probability of a user connecting to an L2 charger as a function of the initial SOC (e.g., the probability is 100% for SOCs below approximately 0.6). Box 620 shows the probability of connecting to a DC fast charger as a function of the initial SOC (e.g., curve 621 is for a risk-averse user who tolerates a lower SOC, and curve 622 is for a risk-averse user who requires a higher SOC). In some embodiments, a variety of distributions or a two-dimensional distribution can be used, where a risk aversion measure for each user can be used to determine the probability of charging (e.g., the distribution is distributed over SOC and risk aversion measure).Field 630 shows an illustrative probability of a user unplugging a DC fast charger as a function of the final state of charge (SOC) (e.g., a very low or zero probability if the SOC is below approximately 0.9). In some embodiments, the system can determine criteria for when and how a user charges the vehicle. For example, the system can apply rules such as: if SOE > 30% and at home, then charge 70% of the time; if SOE <= 30% and at home or at work, then charge; if a long trip is planned and the SOE is insufficient (DOD > 80%), then fast charge; and if at work for more than one period (e.g., 30 minutes), then charge with an L2 charger. Furthermore, the system can apply rules for users who may only be able to use fast chargers, such as: if SOE <= 40%, then fast charge. And if a long trip is planned that will reduce the SOE by 20%, then stop and charge quickly.The system can use any suitable rules and criteria when assigning charging events to each trip and each driving cycle in the logbook.

[0045] Although the in the Fig. Since the six illustrative probability distributions shown are empirically derived from user data, the system can use a charging model that is parametric. For example, the system can consider personal charging preferences, which can be addressed through user readiness parameters and charging thresholds. The system can estimate the parameters or probabilities based on the data to allow the methodology to be adapted to any available and suitable charging dataset. For example, the synthetic population generated by this approach considers variations in charging behavior and their impact on damage over the vehicle's lifetime. After inserting the charging information into the logbooks, the system can output the logbooks for distribution analysis, load history analysis, or other actions. Logbooks and distributions

[0046] Fig. Figure 7 is a block diagram illustrating distribution information 700 according to some embodiments of the present disclosure. The distribution information 700 can include the logbooks of the plurality of simulated users, including logbooks 701-704 (e.g., driving events with corresponding driving cycles and charging events). For example, the system can output updated logbooks of synthetic users containing chronologically ordered sequences of travel, driving, parking, and charging events. In some embodiments, the system can couple the output with a suitable vehicle model to provide, for example, a time series of torque, power, current, or any other load over the lifetime of the vehicle. An abbreviated (only the first three days) example of logbook 701 is shown in Figure 7. Fig. Figure 7 illustrates each trip, showing its start and end times, trip cycle identifier (e.g., NREL, HWY, A, including a number of repetitions), energy consumption (watt-hours / mile), trip length (e.g., in miles or km), average speed (e.g., in mph or km / h), starting state of charge (e.g., in percent), and whether a charging event occurs after the trip and the type of charging. In some embodiments, the system can generate load profiles and damage distributions for each component or system of interest. It is understood that the length of a trip log can be any suitable period (e.g., it can include any suitable number of events), such as 5 years, 10 years, an estimated or target vehicle lifespan, a target warranty lifespan, or any other suitable duration.The damage distribution can be used, for example, to identify the user (or group of users) most damaging to the component (e.g., the component's warranty-critical durability loads). Accordingly, the system can apply a load model, a damage model, or both to each event in each logbook, thus determining a cumulative estimate of the load or damage (e.g., after each event, at a frequency such as annually, at the end of the vehicle's service life, or at another logbook duration). Load profiles and analysis

[0047] Fig. Figures 8A-8C show an illustrative output based on logbooks according to some embodiments of the present disclosure. In an illustrative example, the system can generate logbooks and then determine battery cell degradation based on the logbooks. Fig. Figures 8A-8C illustrate results. Under certain circumstances, battery cells in EV battery packs can be subject to degradation due to use (stress) and lifetime (calendar aging), which reduces the usable battery energy over time. To ensure customers have adequate range at the end of the warranty period or design lifetime, 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 generally influenced by the total energy usage cycles during driving and charging, the power dissipation amplitudes, and the number of fast-charging events (e.g., those that are both power- and thermally stressful).The system can be configured to predict the distribution of total energy consumption, energy consumption per mile (an indicator of power input), the number of fast-charging sessions, and the amount of charge transferred during those sessions. As discussed herein, any suitable reference data can be used (e.g., an NHTS dataset for trip data and NREL driving cycles for driving characterization). For validation, the system can, for example, use a limited set of statistics derived from telemetry data from vehicles of interest.

[0048] To illustrate, the system can determine the total mileage for each of N logbooks at a specific point in the year (e.g., a warranty period or another suitable predetermined duration). The distribution of N mileage data points can be used to generate a distribution similar to the one illustrated in field 810. In an illustrative example, the system can generate a set of 1000 synthetic users using the travel model and NHTS data. Field 810 of Fig. Figure 8A shows an example 10-year cumulative mileage distribution of these users (e.g., percentage of users plotted as a function of total mileage M), compared to field 820, which illustrates real 10-year odometer data from approximately 10,000 vehicles in the NHTS data. The subdivisions on the abscissa in fields 810 and 820 are increments of 30,000 miles. The subdivisions on the ordinate in field 810 are increments of 10%, and the subdivisions on the ordinate in field 820 are increments of 5%. As illustrated, the stochastically generated users show a similar 10-year mileage distribution, particularly at and above the mean. The error is less than 5% for the mean mileage and less than 1% for the 95th percentile mileage. This demonstrates the ability of the travel model to create logbooks with realistic, lifelong usage.The synthetic data are more conservative for users with low mileage, but these users are less likely to have high cumulative damage due to very low overall usage.

[0049] Fig. Figure 8B illustrates distributions of the percentage of vehicles and the mean speed over Y years in boxes 830 and 840. The subdivisions on the abscissa in boxes 830 and 840 are increments of 15 mph. The subdivisions on the ordinate in box 830 are increments of 5%, and the subdivisions on the ordinate in box 840 are increments of 10%. In some embodiments, the system assigns driving cycles to the logbooks of N synthetic users. The distribution of the mean speed over the lifetime for all synthetic users is shown in box 830. Fig. 8B shown (e.g., 250 users were used for field 830), compared to the distribution of average driving speeds shown in data from actual users in field 840. Fig. 8B were observed. As illustrated in fields 830 and 840 (e.g., showing the percentage of vehicles / users plotted as a function of mean speed S), the distribution derived from the synthetic users may be similar to that derived from the real-world data (e.g., exhibiting a higher 95th percentile mean speed). This may mean that, under certain circumstances, driving cycle assignments are representative of real-world use, at least with respect to mean speeds and trip lengths. In some embodiments, the system may use other measurements, such as acceleration, when OEM fleet data is used over the NHTS data, which does not include acceleration information. For the purposes of this disclosure, the Fig. 8A and Fig. 8B presents a synthetic population approach for determining accurate travel and driving time profiles over the lifetime. Average speed and trip lengths can also be good indicators of energy consumption under certain circumstances, enabling the system to generate an accurate distribution of these parameters through the travel and driving models to reliably estimate cell degradation loads (e.g., or any other suitable loads).

[0050] Based on the logbooks, the distribution of total energy consumption (i.e., energy throughput) can be generated using a suitable vehicle model. In field 850 of Fig. Figure 8B shows a distribution of the estimated lifetime energy consumption for the synthetic population, i.e., energy supplied to and consumed by the vehicle's battery pack (e.g., represented as a percentage of vehicles plotted as a function of the total energy throughput E in MWh). The subdivisions on the abscissa in column 850 are increments of 20 MWh, and the subdivisions on the ordinate are increments of 10%. For example, for each trip log, the system can determine the cumulative energy added and consumed for all events to arrive at a total value. This set of total values ​​(e.g., N values ​​for N synthetic users) can be used to generate a distribution for statistical analysis (e.g., the 95% value or any other suitable value).

[0051] Field 860 of Fig. Figure 8C shows an estimated distribution of the number of fast charging events per week and the depth of fast charging within those events for two types of customers: (a) those least likely to use fast charging due to access to both L2 charging and fast charging (e.g., distribution 862), and (b) those who do not have regular access to L2 charging and use only fast charging (e.g., distribution 861). While the latter customer type, who exclusively uses fast charging, represents an unrealistic scenario, it represents the most damaging charging behavior and serves as an upper bound for cell damage estimates. Subdivisions along the x-axis increase by one (e.g., corresponding to 0, 1, 2, 3, or 4 fast charges per week). Subdivisions along the y-axis increase by 5% in charge depth per charging event (e.g., at the state of charge).The size of the marker for each data point of distributions 861 and 862 corresponds to the 8-year mileage, which ranges from 30,000 to 180,000 miles).

[0052] In fields 870 and 880 of Fig. In field 8C, distributions 871 and 881 correspond to users who have access to both L2 and DCFC chargers, and distributions 872 and 882 correspond to users who only have access to a DCFC charger. Field 870 illustrates the distribution of users by NC (Near-Cold) the number of fast charges per week (e.g., each division along the abscissa represents 2 charges / week). Field 880 illustrates the distribution of users by DC (Depth of Charge) the average depth of charge (e.g., each division along the abscissa represents 20% SOC). Fields 870 and 880 of Fig. The 8C distribution illustrates that users with access to both 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 overall mileage may perform more fast charges and larger quantities of them. Conversely, users who rely solely on fast chargers (e.g., distribution 882) may have a more even distribution of charge depth around 55% SOC, and among these, users with higher mileage charge more frequently. Most importantly, the illustrative distribution suggests that users critical to vehicle durability are likely to have around 2 or 3, and certainly fewer than 4, fast-charging sessions per week.

[0053] In some embodiments, these results offer a robust method for designing for durability and reliability, and a data-driven approach to defining test targets for durability and reliability at all stages of vehicle design and development. The results in Fig. The distributions illustrated in 8C can be generated based on the logbooks of N users, and the load profiles of the battery systems can be analyzed to determine design, testing, maintenance, or warranty thresholds.

[0054] Fig. Figure 9 is a flowchart illustrating process 900 for creating and using logbooks according to some embodiments of the present disclosure.

[0055] Step 902 involves generating a multitude of user profiles. These profiles can correspond to simulated users, with attributes generated based on statistical or other reference information. For example, a set of N user profiles can be generated, where N is statistically significant (e.g., to provide useful results in determining a load distribution). Each user profile can include a measurement value for one or more archetype measurements. Archetype measurements can include household size, age, activity level, risk aversion, employment type / location, usage type (e.g., recreation, work, commuting), usage frequency, home charger type, proximity to DCFC chargers, access to chargers and charger types, driving aggressiveness, nearby ground topology (e.g., rural road, paved road, terrain), any other appropriate measurement, or any combination thereof.For example, step 902 can be performed by the travel manager 110 from . Fig. 1 or the travel pattern generator 210 from Fig. 2. In another example, step 902 can be performed by processing equipment and the user profiles can be found in travel data 171 of Fig. 1 or travel dates 271 of Fig. 2 will be saved.

[0056] Step 904 includes generating a travel pattern for each user profile. Step 904 might involve determining a set of events that occur sequentially based on a stochastic, multi-year model. For example, for each user, the corresponding travel pattern might include trips that occur with a specific start time, end time, duration, and character. For example, a trip might include leaving home, driving along a route (which could include one or more road types), and arriving at a destination (such as a workplace, store, mall, facility, vacation spot, maintenance site, or any other appropriate destination type). The travel pattern might extend over several years to build a trip history and load profile that can be used over the lifetime of a vehicle type.For example, step 904 can be performed by the travel manager 110 from . Fig. 1 or the travel pattern generator 210 from Fig. 2 will be carried out.

[0057] Step 906 includes generating a trip history for each user profile based on the trip pattern. In some embodiments, step 906 includes generating the trip history based on the trip pattern and trip cycle information. For example, step 906 may include applying a trip cycle from a library of reference trip cycles to each trip based on logical rules, stochastic rules (e.g., using reference distributions), chaining rules, or any other suitable criterion to generate trip cycle information for each trip in each logbook. The trip history may include, for each trip, a trip cycle identifier, a number of repetitions (e.g.,a reference driving cycle), an average driving speed, an average acceleration / deceleration, a peak acceleration / deceleration, a number of starts, a number of stops, a number of curves, an average energy consumption, a total energy consumption, a peak power, a distance, a road type characteristic (e.g., paved, smooth, rough, off-road), any other suitable characteristic relating to driving characteristics for a trip, or any combination thereof. For example, step 906 can be performed by the driving manager 120 of . Fig. 1 or the driving cycle generator 220 from Fig. 2 will be carried out.

[0058] Step 908 includes creating a logbook for each user profile. In some embodiments, step 908 may include process 500 for inserting charging events into each logbook to produce logbooks containing trip and charging event information. The output of step 908 may be a set of N logbooks for N synthetic users, each logbook containing a variety of trips with corresponding trip information and a variety of charging events with charging information. For example, step 908 may be performed by the charging manager 130 of Fig. 1 or the charging behavior generator 230 from Fig. 2. To complete, insert which charging events into the preliminary logbooks issued in step 906.

[0059] Step 910 includes generating a load history for each logbook entry corresponding to a vehicle component or system, based on the logbook entries. The load history can be generated for a single component or system of the vehicle. For example, Step 910 can include applying one or more load models to the logbook to determine a cumulative load for each component or system. The cumulative load can include a cumulative value for each trip or a single entry at the end of the vehicle's service life or another predefined period. Step 910 can also include applying one or more damage models to the logbook or load history to estimate cumulative damage for each component or system.

[0060] Step 912 involves determining a distribution of a load parameter, a damage parameter, or both based on the multitude of load histories, corresponding to a vehicle component or system, based on the logbooks. The distribution can include a single value from each load history (e.g., one value for each logbook or user / vehicle) or a multitude of values. For example, the load parameter for each load history can include a single cumulative load determined at a predetermined time (e.g., the vehicle's lifetime or another suitable time period). For illustration, a set of load parameters can be extracted from the load histories, corresponding to a set of times (e.g., each year), a set of loads (e.g., each corresponding to a specific model), or a combination thereof.For example, step 912 may include using the results of the load model or a plurality of load models to determine a load parameter, such as a 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 service life or another predefined period. The cumulative damage may also include a cumulative value for each trip or a single entry at the end of the vehicle's service life or another predefined period. In some embodiments, step 912 includes determining a plurality of distributions, each corresponding to a specific vehicle component or system (e.g., with a corresponding load or damage model for each).

[0061] In an illustrative example, a load model can include an algorithm to determine force, torque, pressure, stress, strain, displacement, number of cycles, any other suitable parameter, or any combination thereof, based on the driving cycle information for each trip. Accordingly, the system can apply the load model to each trip in each logbook to determine a corresponding load. At a predetermined endpoint or lifetime, the cumulative load for each of the N logbooks can be collected, and a distribution can be generated in step 912 to determine how the load has accumulated for each of the vehicles. Any number of suitable load models and damage models can be applied to the logbooks to generate any number of suitable distributions.For example, for a set of logbooks, load models can be applied to each suitable vehicle component or system to determine respective load profiles and damage estimates. Processes 920, 930, 940, and 950, as discussed below, provide examples of how load profiles can be used in accordance with this disclosure.

[0062] Process 920 is design-oriented and includes steps 922 and 924. Step 922 involves determining or modifying a design parameter of the vehicle component or system. For example, in step 922, a load profile can be generated for each logbook, and a distribution can be created. The distribution can include a percentage of vehicles with a cumulative load (e.g., a load value at the end of the vehicle's service life). Accordingly, the percentage of vehicles within a load threshold can be determined. Step 924 involves updating the load profile based on the design parameter. For example, for a predetermined percentage threshold (e.g.,95%, 97%, or another suitable value) a design parameter in the load model or damage model is updated at step 924, and the load profiles can be updated based on the updated model. In another example, the service life can be extended to achieve further load values. Accordingly, an iterative process 920 can be applied to align a predetermined load value and a predetermined percentage. For example, the iterations can continue until 95% of the vehicles have a predetermined number of cycles, miles, actuations, (un)charge cycles or starts / stops, total load, damage measurement, wear measurement, any other suitable measurement, or any combination thereof.In another example, iterations can continue until 99% of vehicles reach a predetermined number of cycles, miles, actuations, (un)charge cycles or starts / stops, total load, damage measurement, wear measurement, any other suitable measurement, or any combination thereof. In some embodiments, a distribution of values ​​of a design parameter can be applied as part of the load model to generate a load profile with a distribution of cumulative loads. Accordingly, no iteration is required, and the distribution of cumulative loads can be analyzed to determine the design parameter that best leads to the target value (e.g., a percentage of a vehicle threshold).

[0063] Process 930 is focused on testing and includes steps 932 and 934. Step 932 involves determining or modifying a test parameter of the vehicle component or system. Step 934 involves performing tests on the vehicle component or system. The distribution may include a percentage of vehicles with a cumulative load (e.g., a load value at the end of the vehicle's service life). Accordingly, a series of tests may be applied to predict failures, wear, damage, or other usage characteristics. Step 934 involves performing the test on the vehicle component or system based on the test parameter, which may include a force, torque, pressure, stress, strain, displacement, number of cycles, any other suitable parameter, any schedule or modulation thereof, or any combination thereof.The results of the test in step 934 can be used to refine the load model or damage model, which can be used for iteration in step 910 (e.g. for the design process 920, which can be carried out in conjunction with process 930).

[0064] Process 940 is directed toward determining warranty information and includes steps 942 and 944. Step 942 involves determining or modifying warranty information for the vehicle component or system. Step 944 involves generating a warranty notification regarding the vehicle component or system. For example, step 942 might include selecting a load or damage threshold based on the load histories from step 910. For instance, if a particular vehicle component or system is to be warranted for a target number of miles or years, the load histories can be used to determine a distribution of damage or usage over time for that specific vehicle component or system. To align a target number of vehicles within a window corresponding to the absence of an expected warranty issue (e.g.,If a load or damage measure falls below a threshold, the warranty time can be adjusted to achieve the target percentage, or process 920 can be used to modify a design so that the resulting distribution after step 910 achieves the target percentage. Accordingly, once the distribution results in an estimated target percentage of vehicles below a load or damage threshold, the warranty notification can be generated at step 944. For example, pre-sale process 940 can be applied to align the vehicle design and warranty design based on the expected load or damage to the vehicle component or system, as determined based on the load histories from step 910.

[0065] Process 950 is focused on managing vehicle maintenance and includes steps 952 and 954. Step 952 involves determining or modifying a maintenance parameter of the vehicle component or system. For example, a maintenance plan may be determined for a vehicle type, specifying a series of maintenance operations to be performed at time-based or mileage-related milestones in vehicle use. Step 954 involves planning, performing, or both the maintenance of the vehicle component or system (e.g., based on the maintenance plan). For example, step 952 may include selecting a load or damage threshold based on the load histories from step 910.For example, if a specific vehicle component or system is to be serviced at a target number of miles or years, the load histories can be used to determine a distribution of damage or use over time for that specific vehicle component or system. To align a target number of vehicles within a window according to expected maintenance (e.g., with a load or damage measure at or below a threshold), the maintenance time can be adjusted to achieve the target percentage, or Process 920 can be used to modify a design so that the resulting distribution after Step 910 achieves the target percentage.Accordingly, once the distribution results in an estimated target percentage of vehicles exhibiting less than a stress or damage threshold, the maintenance plan can be determined, and maintenance can be scheduled and performed at step 954. For example, process 9450 can be applied to align the vehicle design and maintenance plan based on the expected stress or damage to the vehicle component or system, as determined based on the load profiles from step 910.

[0066] Fig. Figure 10 is a flowchart illustrating process 1000 for the application of logbooks to improve fault analysis according to some embodiments of the present disclosure.

[0067] Step 1002 involves creating a logbook for each of a multitude of user profiles. For example, step 1002 can correspond to steps 902-908 of process 900. Step 1002 can include creating N logbooks, each containing a corresponding multitude of trips with driving cycles and a multitude of charging events. In an illustrative example, at step 1002, the system can generate a multitude of entries for each of the N user profiles (e.g., M jEntries for user profile j). Field 1050 illustrates that N logbooks can be created, each containing any suitable number of entries (e.g., some users may have fewer or more entries than others). For each entry, the system can determine a variety of relevant information (e.g., along a line in field 1050) represented by headings AZ (e.g., although any suitable number of headings may be used). In some embodiments, for example, each logbook is created independently, and the ensemble is used to represent a variety of real drivers and vehicles.

[0068] Step 1004 includes determining the component load based on component reference information and each logbook entry. A component load can be determined for each logbook entry corresponding to a specific user profile. For example, each logbook entry can include vehicle component load and usage information. The load can include a force (such as shear force, bending force, tensile force, compressive force), a torque, a number of cycles, any other suitable indication of a load, or any combination thereof. In another example, for each trip in a logbook entry, the vehicle speed, acceleration / deceleration, braking, suspension operation, electrical current profile, voltage profile, temperature, thermal behavior (such as heat generation), and number of cycles can be determined and recorded.Accordingly, a load history can be generated for each logbook, including a history of multiple journeys and multiple years of loads applied to the vehicle component or system. The entirety of all load histories then provides a comprehensive set of information to which statistical analysis can be applied (e.g., in step 1006). In some embodiments, the component reference information can include a usage type, a displacement type, material properties, features, interfaces, any other suitable information corresponding to the component, or any combination thereof.

[0069] In an illustrative example, at step 1004, the system can generate a load for each trip in each logbook. This load can include a load (e.g., force, torque, stress, strain), a number of cycles, any other suitable information that might correspond to failure or damage, or any combination thereof. Field 1051 illustrates that N load profiles can be generated, one for each logbook, and each load profile can contain a total of T jInclude trips for user j. For each trip of the T trips in each logbook, the system can determine load metrics based on a model (e.g., a load model, a dynamic model, a kinetic model, a lookup table, or any other suitable model type). In some embodiments, the logbook can include charging events in addition to trips (e.g., where the vehicle is going), which may be included in the load history. For example, vehicle components or systems used during charging, such as the battery system and the onboard charging system, may be subjected to a load (e.g., cycles) during charging, for which a usage, wear, or damage model can be applied at step 1006.

[0070] Step 1006 includes determining an accumulated load based on the component load from step 1004. The accumulated load is based on the load for each trip, for each vehicle. While a load history can include a temporal or event-based sequence of loads, the accumulated load represents a value at the end of time or sequence that corresponds to total wear at a point in time after significant use (e.g., at the end of a service life, at the end of the warranty period, or at another concluding milestone).

[0071] A damage model can be applied to the loading sequence to calculate the accumulated load or damage estimate. In some embodiments, step 1006 includes determining a single damage prediction for each vehicle (e.g., N values ​​in total) based on a single loading mode and damage mode. In other embodiments, step 1006 includes determining D damage prediction values ​​for each vehicle (e.g., D*N values ​​in total) based on one or more loading modes and one or more damage modes. For example, the damage model may include a spalling model and a fracture model, or any other set of models corresponding to the relevant damage modes.In another example, the damage model can include a thermal model to estimate temperatures, temperature differences, heat transfer rates, gradients, their maximum or minimum values, or any combination thereof. In another example, the damage model can include an electrical model to estimate currents, voltages, voltage differences, power rates, resistances or impedances, their maximum or minimum values, or any combination thereof. In yet another example, the damage model can include a flow model or fluid dynamics model to estimate pressures, pressure differences, corrosion, their maximum or minimum values, or any combination thereof.In another example, a model can include a multiphysics model that may incorporate aspects of electromagnetics, heat transfer, fluid dynamics, solid dynamics, surface chemistry, any other suitable physical or chemical phenomena, or any combination thereof.

[0072] In an illustrative example, at step 1006, the system can determine a damage measure for each load history, for each user profile. Field 1060 illustrates that a distribution of damage measures can be generated based on the N load histories and a damage model (e.g., with N data points). For example, in some embodiments, the system can determine a damage measure corresponding to a specific damage mode for each load history and then generate a damage distribution based on the N measures (e.g., one for each logbook and its corresponding load history). Each measure can be a representative accumulated value corresponding to a column in the table in field 1051. For example, a distribution similar to the one illustrated in field 1060 can be generated for each load measure (e.g., each column) in the table in field 1051.In another example, a distribution similar to that illustrated in field 1060 can be generated based on a variety of load measures (e.g., multiple columns) from the table in field 1051. For illustration, the distribution can include a damage measure value at a vehicle lifetime or another suitable reference time. The time can be specified, and the damage measure corresponding to that time can be extracted for each damage prediction and aggregated to form the distribution (e.g., distribution 1061, as illustrated). In some embodiments, data collected in step 1005 (e.g., validation data from vehicles in the field corresponding to the vehicle type) can be used to validate the load model, the damage model, or both (e.g., to fine-tune the models). For example, distribution 1062 can be generated based on the data collected in step 1005.In some embodiments, as illustrated, a 95th percentile damage estimate can be generated and compared for the modeled data (e.g., estimate 1063) and for the collected data (e.g., estimate 1064) to validate the load and damage models. The illustrative distributions of field 1060 can be generated similarly for any suitable damage prediction, optionally including any appropriate validation data. Based on the analysis of the distribution determined in step 1006, design, testing, maintenance, or warranty actions can be determined or modified. For example, for a target load, the system can determine a subset of load profiles that meet the target (e.g., a fraction of the logbooks).

[0073] In step 1008, for example, the system determines critical lifetime loads for durability design. In some embodiments, the system can identify an Nth percentile damage estimate (e.g., 95% or any other suitable target) and validate or modify a design parameter of the vehicle component or system. For example, process 1000 can be iterated to determine an optimized design parameter. The design parameter can include a material selection, thickness, diameter, width, length, cross-section, angle, shape, contour, feature property, any other suitable dimensional or compositional aspect, or any combination thereof. For example, a diameter or taper of a vehicle powertrain half-shaft can be determined based on an iterative application of process 1000.

[0074] In step 1010, for example, the system determines critical lifetime loads for testing and test selection. In some embodiments, the system can identify a test type and test conditions to which the vehicle component or system must be subjected to validate a model. The load profiles generated in step 1004 or the damage prediction determined in step 1006 can be used to adapt the testing process. For example, process 1000 can be iterated to determine an optimized design parameter. The test parameter can include a duration, a test load, a number of cycles, a variation in load, any other suitable aspect of testing the component or system, or any combination thereof. For example, test conditions can be determined based on an iterative application of process 1000.

[0075] In step 1012, the system determines critical lifetime loads to evaluate field warranty estimates, for example. In some embodiments, the system can identify a reliability target for the vehicle component or system. For example, process 1000 can be iterated to determine optimized warranty information. The warranty information can include a time period, a failure or damage mode, an expected failure rate (e.g., based on damage prediction), any other suitable information corresponding to a component's service life and replacement, or any combination thereof. For example, warranty information can be determined or modified based on an iterative application of process 1000.

[0076] In an illustrative example, the system can generate a variety of logbooks (e.g., at step 908 or step 1002) based on a variety of synthetic user profiles. The logbooks can be partially based on trip patterns, which may include route information (e.g., number of curves, curve severity), driving style (e.g., speed over time or average speed, peak acceleration / deceleration, average acceleration / deceleration), or a combination thereof, which can be input into a vehicle drivetrain model (e.g., at step 906 or step 1004). The vehicle drivetrain model can output a load, such as torque and articulation angle, for a vehicle half-shaft for each trip over the vehicle's lifetime from the logbook. The half-shaft can connect a transmission to a wheel, and chipping can occur based on torque, steering angle, and ride height (e.g.,(how aggressively the vehicle is driven). A damage model can be applied to the output load to estimate damage from each trip for each vehicle. For example, the damage model, referencing a vehicle half-wave, can include a chipping damage model that can be applied to each trip to produce an accumulated half-wave chipping damage prediction for each logbook (e.g., for each vehicle in the set of N vehicles by N users). Based on the accumulated damage prediction generated in step 1006, the system can determine damage thresholds over the vehicle lifetime for each load profile. For example, by specifying a percentage (e.g., 90%, 95%, 99%, or another suitable threshold) corresponding to the accumulated damage prediction (e.g., the distribution of the accumulated damage prediction across the N vehicles), a quantitative damage estimate can be determined.In another example, the design can be adjusted by iterating the process 1000 times so that the percentage matches a target damage measurement (e.g., by adjusting the distribution).

[0077] The foregoing serves only to illustrate the principles of this disclosure, and various modifications may be made by a person skilled in the art without departing from the scope of protection of this disclosure. The embodiments described above are presented for illustrative purposes and are not intended to be limiting. This disclosure may also take many other forms than those expressly described herein. Accordingly, it is emphasized that this disclosure is not limited to the explicitly disclosed methods, systems, and devices, but is intended to include variations and modifications thereof that are within the spirit of the following claims. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 63 / 726,465

[0001]

Claims

[1] Procedure, encompassing: Creating, using processing equipment, a logbook for each user profile of a multitude of user profiles based on a multitude of travel patterns, driving cycle information of a vehicle type and loading information, to produce a multitude of logbooks; Generating a large number of load profiles according to a vehicle component of the vehicle type based on the large number of logbooks; Generating a distribution of a load parameter based on the multitude of load profiles; and Determining vehicle information based on the distribution of the load parameter using the processing equipment. [2] Method according to claim 1, further comprising generating a design parameter for the vehicle component based on the plurality of load profiles. [3] Method according to claim 1, further comprising generating a test parameter for the vehicle component based on the plurality of load profiles. [4] Method according to claim 1, further comprising generating a maintenance parameter for the vehicle component based on the plurality of load profiles. [5] Method according to claim 1, further comprising modifying, based on the plurality of load profiles, at least one of (i) a design parameter of the vehicle component or (ii) a test parameter of the vehicle component. [6] The method of claim 1, further comprising: Determine, based on the multitude of load profiles, warranty information corresponding to the vehicle component, wherein the warranty information includes a target warranty period for the vehicle type, and wherein each of the multitude of logbooks spans the target warranty period; and Generating a warranty notification based on the warranty information. [7] Method according to claim 1, further comprising: Determine, using the processing equipment, a remaining service life of the vehicle component based on the multitude of load profiles; and Generating a display of the remaining lifespan on a user interface. [8] Method according to claim 1, further comprising updating a threshold value corresponding to the plurality of load profiles in a memory of a vehicle of vehicle type. [9] The method of claim 1, further comprising: Receiving updated information that corresponds to the vehicle component; and Updating the multitude of load profiles based on the updated information. [10] The method of claim 1, further comprising generating a damage distribution based on the plurality of load profiles and a damage model. [11] Method according to claim 1, wherein each logbook comprises a respective plurality of journeys and wherein generating the plurality of load profiles comprises applying a load model to each respective plurality of journeys. [12] The method of claim 1, further comprising determining the plurality of user profiles based on a plurality of predetermined user archetypes corresponding to a target customer base. [13] The method of claim 1, further comprising generating the plurality of travel patterns based on a stochastic, multi-year model. [14] Method according to claim 1, wherein the plurality of user profiles is a first plurality of user profiles, the method further comprising: Defining a second set of user profiles; and Repeated generation of the logbook for each user profile and generation of the multitude of load profiles based on the second multitude of user profiles. [15] Method according to claim 1, wherein creating the logbook for each user profile of the plurality of user profiles comprises the following: Generating a travel pattern for each user profile to produce the multitude of travel patterns according to the vehicle type; Generating a trip history for each user profile based on the multitude of travel patterns and driving cycle information to produce a variety of trip histories; and Generating charging information based on the travel pattern and driving history for each user profile. [16] The method of claim 1, further comprising: Identifying a subset of user profiles from the multitude of user profiles that corresponds to an attribute, where a subset of logbooks corresponds to the multitude of logbooks of the subset of user profiles; Identifying a target load according to the vehicle component based on the subset of logbooks; and Determine at least one of a design parameter, a test parameter, a maintenance parameter, or a warranty parameter based on the target load. [17] System, encompassing: a processing equipment configured to: Creating a logbook for each user profile of a multitude of user profiles based on a multitude of travel patterns, driving cycle information of a vehicle type and charging information, to result in a multitude of logbooks; Generating a multitude of load profiles according to a vehicle component of the vehicle type based on the multitude of travel patterns; Generating a distribution of a load parameter based on the multitude of load profiles; and Determining vehicle information based on the distribution of the load parameter. [18] System according to claim 17, wherein the processing equipment is further configured to generate the logbook for each user profile of the plurality of user profiles by: Generating a travel pattern for each user profile to produce the multitude of travel patterns according to the vehicle type; Generating a trip history for each user profile based on the multitude of travel patterns and driving cycle information to produce a variety of trip histories; and Generating charging information based on the travel pattern and driving history for each user profile. [19] Non-transitory computer-readable medium on which instructions are encoded which, when executed by processing equipment, cause the processing equipment to: Creating a logbook for each user profile of a multitude of user profiles based on a multitude of travel patterns, driving cycle information of a vehicle type and charging information, to result in a multitude of logbooks; Generating a multitude of load profiles according to a vehicle component of the vehicle type based on the multitude of travel patterns; Generating a distribution of a load parameter based on the multitude of load profiles; and Determining vehicle information based on the distribution of the load parameter. [20] Non-transitory computer-readable medium according to claim 19, further comprising instructions that cause the processing equipment to create the logbook for each user profile of the plurality of user profiles by: Generating a travel pattern for each user profile to produce the multitude of travel patterns according to the vehicle type; Generating a trip history for each user profile based on the multitude of travel patterns and driving cycle information to produce a variety of trip histories; and Generating charging information based on the travel pattern and driving history for each user profile.

Images