Automotive calibration optimisation

Abstract

A method for optimising vehicle calibration parameters, including: providing a representative real world drive cycle to a physical unit under test; generating performance data for the physical unit under test as the physical unit under test traverses the drive cycle; uploading the performance data as training data to generate a digital twin of a system, sub-system or vehicle in which the physical unit under test is configured to be used; providing vehicle performance prediction data from the digital twin to a calibration optimiser; and optimising one or more vehicle calibration parameters using the calibration optimiser.

Description

[0001] AUTOMOTIVE CALIBRATION OPTIMISATION

[0002] FIELD

[0003] Disclosed are systems and methods for optimisation of the calibration of automotive vehicles, for example to maximise energy efficiency. These include systems and methods for generating vehicle drive cycles that are representative of real world conditions for testing vehicle performance.

[0004] BACKGROUND

[0005] Modern vehicles are increasingly complex, with numerous interconnected systems and controllers. To maximise vehicle performance, the various systems must be calibrated appropriately. Optimising the calibration of the vehicle systems can lead to significant improvements in performance, such as in energy efficiency.

[0006] However, traditional methods for calibrating vehicle systems can be time-consuming, inefficient, and expensive.

[0007] Disclosed are systems and methods for making the vehicle development and optimisation process more efficient.

[0008] BRIEF DESCRIPTION OF THE INVENTION

[0009] Disclosed is a method for optimising vehicle calibration parameters, including: providing a representative real world drive cycle to a physical unit under test; generating performance data for the physical unit under test as the physical unit under test traverses the drive cycle; using the performance data as training data for a digital twin of a system, sub-system or vehicle in which the physical unit under test is configured to be used; providing vehicle performance prediction data from the digital twin to a calibration optimiser; and optimising one or more vehicle calibration parameters using the calibration optimiser.

[0010] The method may further include providing the optimised vehicle calibration parameters to the physical unit under test, and validating that the optimised vehicle calibration parameters improve the performance of the unit under test.

[0011] The method may further include generating the representative real world drive cycle.

[0012] The drive cycle may be a synthetic drive cycle generated using one or more of map data, GNSS data, and / or representative traffic flow data from traffic simulator platforms.

[0013] H 1644 WO The drive cycle may include one or more of a velocity or speed profile, a gradient profile, an elevation profile, a weather profile, and a traffic simulation profile.

[0014] The physical unit under test may be a powertrain, high voltage battery, thermal system, adaptive cruise control system, advanced driver assistance system, or part thereof.

[0015] The physical unit under test may be provided on an XiL rig or instrumented vehicle which contains the physical unit under test to determine the performance data.

[0016] The vehicle performance data may include simulated performance data for a simulated vehicle system.

[0017] The simulated vehicle system may be different to the physical unit under test.

[0018] The method may further comprise sending the optimised vehicle calibration parameters to a vehicle to recalibrate the vehicle’s vehicle calibration parameters over the lifetime of the vehicle.

[0019] Also disclosed is a method for generating journey-specific optimised vehicle calibration parameters for a vehicle, including: generating a drive cycle for the journey; simulating vehicle performance for the journey using a digital twin of the vehicle and a baseline set of vehicle calibration parameters; and optimising the vehicle calibration parameters for the journey using a calibration optimises

[0020] The method may further include inputting the journey to a navigation module, and generating the drive cycle for the journey using a drive cycle generator which uses map data from the navigation module and representative traffic flow data from traffic simulator platforms to generate the drive cycle.

[0021] The method may further include recalibrating the vehicle with the journey-specific optimised vehicle calibration parameters.

[0022] If the vehicle is determined to have deviated from the generated drive cycle during the journey, the vehicle may be recalibrated back to the baseline vehicle calibration parameters.

[0023] The drive cycle may include one or more of a velocity or speed profile, a gradient profile, an elevation profile, a weather profile, and a traffic simulation profile.

[0024] Simulating the vehicle performance for the journey may include determining a predicted vehicle energy consumption for the journey.

[0025] H 1644 WO The vehicle calibration parameters may include one or more of a torque management parameter, a thermal management parameter, and an energy management parameter.

[0026] The torque management parameter may include one or more of a torque distribution parameter between an internal combustion engine and an electric motor, a torque distribution parameter between front and rear axle, and / or a torque distribution parameter between left and right wheels of the vehicle.

[0027] Also disclosed is a method for reducing friction brake usage in a vehicle, including: generating a predicted drive cycle for a journey; simulating vehicle performance over the drive cycle using a digital twin of the vehicle and a baseline set of vehicle calibration parameters to generate a brake force profile for the journey; generating a battery state-of-charge profile for an electrical and / or thermal battery of the vehicle for the journey; determining an amount of energy that would be generated if all of the brake force in the brake force profile was provided by a regenerative braking system; determining if the electrical and / or thermal battery has sufficient capacity at each stage of the journey to receive all of the energy generated by the regenerative braking system; and generating an energy discharge profile for the journey indicating an energy to be discharged from an electrical battery of the vehicle or a thermal battery of the vehicle such that the electrical or thermal battery has capacity to receive all of the regenerated energy.

[0028] Also disclosed is a method for reducing energy consumption in a vehicle, comprising: generating a drive cycle for a journey to be driven by the vehicle; simulating the performance of the vehicle over the journey by providing the drive cycle to a digital twin of the vehicle; determining an optimum acceleration, deceleration and coasting profile for the journey to minimise energy consumption; and providing the optimum acceleration profile to a driver of the vehicle in real time as the driver completes the journey.

[0029] When linked to ACC controller, with the knowledge of expected velocity (or speed) profile, gradient profile, optimum deceleration and coasting profile are generated for the journey to minimise energy consumption; and providing the optimum deceleration and coasting profile to a driver of the vehicle in real time as the driver completes the journey.

[0030] Also disclosed is a method for condensing an input drive cycle for a vehicle or powertrain to a condensed drive cycle for a vehicle or powertrain while maintaining coverage over one or more user- defined variables of the input drive cycle, the method comprising: receiving an input drive cycle having a first duration; generating an input density function for the input drive cycle which represents the coverage of the input drive cycle over the user-defined variables; generating a target density function for a condensed drive cycle based on the input density function; segmenting the input drive cycle into a plurality of segments; and generating a condensed drive cycle having a second duration,

[0031] H 1644 WO wherein the second duration is shorter than the first duration, by concatenating segments of the input drive cycle, wherein a segment of the input drive cycle is added to the condensed drive cycle if it causes a density function of the condensed drive cycle to conform more closely to the target density function, and is not included in the condensed drive cycle if it does not.

[0032] The user-defined variables may include one or more of speed, acceleration, engine load, motor torque, and / or state of charge.

[0033] The target density function may be generated by scaling the input density function.

[0034] A filter may be applied to the concatenated segments to prevent discontinuities in variables between segments.

[0035] The density functions may be time density functions.

[0036] BRIEF DESCRIPTION OF THE FIGURES

[0037] In order that the present disclosure may be more readily understood, preferable embodiments thereof will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0038] Fig. 1 is a schematic view of a system according to the present disclosure;

[0039] Fig. 2 is a schematic view of vehicles according to the present disclosure;

[0040] Fig. 3 is a schematic view of a vehicle according to the present disclosure;

[0041] Figs. 4-15 illustrate various aspects of the system of the present disclosure;

[0042] Fig. 16 is a schematic view of a computing device according to the present disclosure;

[0043] Fig. 17 shows an example of the coverage of an input (original) drive cycle according to the present disclosure;

[0044] Fig. 18 shows an example of the coverage of a condensed drive cycle according to the present disclosure;

[0045] Fig. 19 shows an example of an input (original) drive cycle according to the present disclosure;

[0046] Fig. 20 shows a coverage heat map for the drive cycle of Fig. 19;

[0047] Fig. 21 shows an example of a condensed drive cycle derived from the input drive cycle of Fig. 19, according to the present disclosure; and

[0048] Fig. 22 shows a coverage heat map for the condensed drive cycle of Fig. 21 .

[0049] DETAILED DESCRIPTION OF THE DISCLOSURE

[0050] H 1644 WO Disclosed are systems and methods for optimising the calibration of automotive vehicles. The systems and methods disclosed herein may be used to optimise the calibration of one or more systems or sub-systems of the automotive vehicle, for example, or to optimise the calibration of the vehicle as a whole.

[0051] The vehicle 3 may be a land vehicle such as a car, truck, lorry, motorbike, or similar. The vehicle 3 may include a powertrain 30. The vehicle 3 may include one or more wheels 301 which may engage a ground surface (e.g. via a tyre), and the wheels may be considered part of the powertrain 30. The powertrain may include a power unit 302. The power unit 302 may include an internal combustion engine, a hybrid power unit comprising an internal combustion engine and an electric motor, or an electric motor, for example. As such, the vehicle 3 may be an electric vehicle in some versions, such as a battery electric vehicle, fuel cell electric vehicle, hybrid electric vehicle or plugin hybrid electric vehicle.

[0052] The vehicle 3 may include a fuel supply 304 for the power unit 302, which may include a fuel tank such as a fossil fuel (e.g. petrol / gasoline, diesel, eFuel, etc.) tank (e.g. for vehicles 3 having an internal combustion engine), or a hydrogen tank (e.g. for vehicles 3 having a hydrogen fuel cell). The vehicle 3 may include a power supply 305 for the power unit 302, such as an electric battery.

[0053] The powertrain 30 may include one or more of a transmission(s), drive shaft(s), torque converter(s), and differential(s).

[0054] The vehicle 3 may include a heating, ventilation and air conditioning system (HVAC) 32. The vehicle 3 may include one or more user input devices, such as a brake pedal, accelerator or gas pedal, steering wheel, and so on. The user input devices may enable the user to control the operation of the vehicle 3.

[0055] The vehicle 3 may include one or more controllers 31. For example, the vehicle 3 may include one or more domain controllers such as one or more of a battery management system (BMS) 311 , powertrain electronic control unit (PT ECU) or powertrain control module 312, thermal electronic control unit (thermal ECU) 313, adaptive cruise control unit (ACC) 314, and / or advanced driver assistance system (ADAS) unit 318. The vehicle 3 may include one or more zonal controllers such as one or more of a zonal powertrain controller 315 or zonal thermal controller 316.

[0056] For example, the battery management system 311 may monitor and control the operation of the power supply 305 (e.g. electric battery). For example, the battery management system 311 may monitor one or more of a battery voltage, battery temperature, battery current, battery health, battery coolant flow (if applicable), or state of balance of the battery cells. The BMS 311 may also control battery operation by determining one or more of a minimum or maximum cell voltage, charge current limit, discharge current limit, and so on.

[0057] H 1644 WO The powertrain ECU 312 may monitor and / or control a torque demand, such as a torque demand at a wheel 301. For example, in hybrid vehicles 3, the powertrain ECU 312 may determine a torque demand to be met by the internal combustion engine and / or electric motor. The powertrain ECU 312 may determine a fraction of a torque demand to be met by the internal combustion engine and a fraction of a torque demand to be met by the electric motor, for example, and may control the distribution of torque between the internal combustion engine and the electric motor. The powertrain ECU 312 may also determine a torque demand for a given user input, such as a position of the accelerator.

[0058] Each controller may include one or more calibration parameters governing the operation of the controller.

[0059] The performance of the vehicle may be optimised by optimising the calibration parameters which govern the operation of the controllers.

[0060] A system 1 and method of optimising the calibration parameters is disclosed herein.

[0061] The system 1 may include one or more real components 10 and one or more virtual components 20. In particular, the system 1 may include a unit under test 100 (which may be real). The system 1 may include a software defined vehicle or a connected vehicle 101 (which may be real). The system 1 may include a real world representative drive cycle or scenario generator 200 (which may be a virtual module). The system 1 may include a digital twin 201 (which may be a virtual module). The system 1 may include a calibration optimiser 202 (which may be a virtual module).

[0062] The method may include generating a drive cycle, and the drive cycle may be generated by a drive cycle generator 200. The drive cycle generator 200 may be implemented as a software module, for example. The drive cycle may represent a set of driving conditions to be provided to a unit under test 100, for example in order to assess the performance of the unit under test 100. The drive cycle may include one or more of a velocity or speed profile, a gradient profile, an elevation profile, a weather profile, and a traffic simulation profile. The drive cycle may be provided as an input to a virtual module such as the digital twin 201 , which may provide virtual performance data for a vehicle or vehicle component based on the input drive cycle, for example. The drive cycle may be used to generate training data for the digital twin 201 , for example. Accordingly, the generated drive cycle may be used across physical and / or virtual components or modules.

[0063] The velocity or speed profile may specify a velocity or speed over time or distance. The gradient profile may specify a gradient over time or distance. The elevation profile may specify an elevation over time or distance. The weather profile may specify weather conditions over time or distance, such as ambient temperature, wind speed, wind direction, precipitation, humidity, and / or solar load. The traffic simulation profile may specify traffic flow conditions over time, such as a congestion parameter. For example, the congestion parameter may indicate a reduction in speed compared to a baseline value, and the baseline value may represent no congestion. The traffic simulation

[0064] H 1644 WO profile may therefore represent the impact of traffic flow or congestion on the drive cycle. The traffic simulation profile may be an input to the velocity or speed profile and may thus influence the output of the velocity or speed profile. In some versions, the velocity or speed profile may be generated separately from the traffic simulation profile, and the two may then be combined to generate a modified velocity or speed profile. The traffic simulation profile may be based on historic and / or live traffic flow data for a given route or location, for example.

[0065] In some versions the drive cycle may be generated by gathering real-world drive cycle data, and may therefore be referred to as a “real” drive cycle. For example, the data may be gathered by driving a route in the real world and measuring one or more of the vehicle speed, elevation, gradient, ambient weather conditions (e.g. ambient temperature, wind speed, wind direction, precipitation), and traffic flow. The real-world data may be recorded and may thus form a drive cycle which can be provided to the unit under test 100 (or input to another component or module).

[0066] In some versions the drive cycle may be a synthetic drive cycle. The synthetic drive cycle may be generated by a synthetic drive cycle generator 200. The drive cycle may be considered “synthetic” in the sense that it is not generated by driving a route in the real world and recording measurements along the route; instead, the synthetic drive cycle may be generated virtually. For example, the synthetic drive cycle may be generated based on input data. The input data may include map data and / or representative traffic flow data from traffic simulator platforms. The map data may include road speed limits, elevation, gradient, and / or typical traffic conditions at a given time, for example. The input data may include weather data, which may be provided by weather stations and / or recorded historic weather databases for example. The weather data may be live weather data or historic weather data. The weather data may include the typical weather conditions for a given location at a given time (and this may include one or more of temperature, wind speed and direction, and precipitation).

[0067] The elevation and / or gradient profile(s) may be generated by an elevation service module. The elevation service module may use map data to generate the elevation and / or gradient profile(s). The velocity or speed profile may be generated by a routing service module. The routing service module may use map data to generate the velocity or speed profile.

[0068] A method of generating a drive cycle may include defining a start location and / or end location, and determining a route between the start and end locations. The start and end location may be defined in any way that enables the physical location of the start and end locations to be determined, such as by map coordinates, GPS coordinates, street address, post code or the like. The route between the start and end locations may follow a series of waypoints, and the waypoints may be located on a road network, for example. The route may, therefore, follow a road network, and the road network may be defined in a map, for example. The route between the start and end locations may be determined by the drive cycle generator 200, and may be chosen to provide a route of a

[0069] H 1644 WO predetermined length (distance), predetermined time (duration), or a shortest (distance or time) route between the start and end locations, for example.

[0070] The start and end locations may be input by a user (and the user may therefore interact with a corresponding user interface to input the start and end locations to the drive cycle generator 200). In some versions, a user may define a geographical region (such as a country, county, state, city, suburb or the like) for which the synthetic drive cycle is to be generated, and the drive cycle generator 200 may determine a start and end location within the defined geographical region. For example, the start and end locations may be generated randomly within the defined geographical region. The geographical region may be defined by a user by defining a boundary on a map within which the start and end points must be (and optionally also within which the entire route for the drive cycle must be - in other words, the generated route must start and end within the boundary, and must remain within the boundary while traversing the route). A user may therefore draw a boundary on a map within which the drive cycle is to be generated, and this may provide for greater flexibility than the use of predetermined geographical areas corresponding to predefined city regions or similar.

[0071] The start and end location, and the route between the start and end locations, may be input by a user in full to the drive cycle generator 200 in some versions. For example, the start location, end location, and series of waypoints between the start and end may be input by a user. Optionally, a user may record a route in the real world, for example by driving a route and recording location data along the route, and provide the recorded route to the drive cycle generator 200.

[0072] The route generation may include a step of matching route coordinates to a predefined road network. For example, a route recorded in the real world may use location data that has a relatively high margin of error. In other words, the location data recorded in the real world may not be highly accurate. This could lead to waypoints being recorded that are not precisely aligned with a road network, for example. Accordingly, the drive cycle generator 200 may align the provided location data or waypoints with a predefined road network in order to generate a route that follows a road network. This may be done by aligning each provided waypoint or location data with the closest road location in a road network map, for example.

[0073] In some versions, the route for which the drive cycle is to be generated may be provided from an external mapping module, such as a commercially available route planning application, and the route may therefore be provided to the drive cycle generator 200 via an API. The route may therefore already be aligned with a road network in such cases.

[0074] In some versions the user may define a start location, an end location, and one or more waypoints between the start and end locations through which the route must run. The route from the start location to the first user-defined waypoint, and from each subsequent waypoint (if any) to the end location, may then be determined by the drive cycle generator 200.

[0075] H 1644 WO The route between the start and end locations may therefore be generated in various different ways.

[0076] The route may be tailored further by determining a start time (e.g. time of day), a start day of the week (e.g. Monday, Tuesday, etc.), and / or a start date (e.g. day / month / year). This may allow different drive cycles to be generated for a same route to reflect different weather conditions (e.g. seasonal differences), or different traffic conditions (e.g. rush hour), for example. The user-defined route parameters, such as start time, start day of the week, and / or start date, may be used to determine corresponding aspects of the drive cycle that are dependent on those parameters, such as the weather profile and / or traffic simulation profile.

[0077] In some versions, any one or more of the profiles of the drive cycle may be user-defined (e.g. may be predetermined by the user rather than generated automatically by the drive cycle generator 200). For example, the user may define the weather conditions for the weather profile (e.g. temperature, precipitation conditions, wind speed, wind direction, humidity, solar load etc.). The user may define the traffic conditions for the traffic simulation profile, and this may be by choosing one or more preset traffic conditions (e.g. light, medium, heavy, or by choosing a point on a sliding scale e.g. choosing a traffic congestion level on a scale from 1-10).

[0078] The route for which the drive cycle is to be generated may be segmented by the drive cycle generator 200 into a plurality of segments, for example by distance. For example, each segment may comprise a predefined distance, and the segments may be of equal distance in some versions. For example, the segments may be generated by dividing the total route distance into a predefined number of segments of equal length (distance). For illustration, a 1 km route may be divided into 10 segments of 100 m each (solely for the sake of example).

[0079] An expected time of arrival (ETA) or expected journey duration (time) may be determined for each segment, and this may be based on historic or live traffic flow data, which may be provided by a mapping platform, for example. The segment ETAs or durations may therefore reflect a given set of road conditions. A traffic simulation module may generate a corresponding traffic profile for the route such that the segment ETAs match with the determined ETAs. Segmenting the route may aid the simulated drive cycle to correspond more closely to real world behaviour.

[0080] The traffic simulation module may generate the traffic profile by simulating traffic behaviour on roads in the immediate vicinity of the route. For example, the traffic simulation model may simulate traffic behaviour on the route and on roads connecting to the route. In some versions traffic may be simulated on all roads falling within a square which bounds the start and end points; however, this may lead to high computational load. Accordingly, in some versions, a polygon bounding box may be created around the route, which may follow the course of the route and may therefore exclude unnecessary roads which would otherwise be simulated if a square bounding box were to be used. This may reduce computational load.

[0081] H 1644 WO The conditions at the end of a first segment may be matched to the conditions at the start of a second segment to ensure continuity (for example, continuity of speed / velocity, continuity of acceleration / deceleration, and so on).

[0082] The determined route may be used to generate a corresponding drive cycle as defined previously.

[0083] The drive cycle may be generated from the route while adhering to one or more vehicle parameters which may define the maximum and / or minimum capabilities of a vehicle, such as a maximum acceleration or maximum deceleration, and / or maximum speed. The one or more vehicle parameters may additionally or alternatively include a vehicle weight. The vehicle parameters may be predetermined for various vehicle models and the user may simply choose a vehicle model for the drive cycle. The user may also define a driver aggression parameter for the drive cycle, which may determine how aggressively the vehicle accelerates / decelerates along the route, or the average or top speed of the vehicle along the route, for example.

[0084] The drive cycle may be generated from the route by simulating a vehicle traversing a route under the defined conditions. An example of such a simulator is SUMO traffic simulator. This may provide a speed profile for the route, taking into account traffic conditions, for example. The simulated speed profile may then be combined with one or more of the other described profiles (e.g. weather / gradient, as described) in order to determine performance data for a unit under test or a virtual equivalent under those conditions. The drive cycle may therefore go beyond a simple speed profile to assess how a vehicle may perform under different temperature conditions, different gradient conditions, and the like.

[0085] The drive cycle generator 200 may include a drive cycle condenser in some versions. The drive cycle condenser may be configured to reduce the duration (time) of a drive cycle while ensuring the drive cycle continues to be representative of the real world, thus enabling quicker testing and vehicle development. In other words, the drive cycle condenser is a tool that reduces the length of a given drive cycle, while maintaining its overall coverage pattern over the operating space, which may include speed, acceleration and / or gradient. In some versions, acceleration and gradient data may be combined into a single variable that reflects the powertrain effort. This may be suitable for testing powertrains, for example.

[0086] The drive cycle condenser may receive as an input a drive cycle, which may be formed from a single generated or recorded drive cycle or a combination of more than one generated or recorded drive cycles. The drive cycle condenser may output a shortened (time) drive cycle, which may conform to a target duration. The user may therefore set the target duration for the condensed drive cycle and the drive cycle condenser may condense one or more input drive cycles to have the target duration. The target duration may be defined as a percentage or fraction of the input duration (e.g. half, for example condensing a 2 hour input drive cycle to a 1 hour condensed drive cycle).

[0087] H 1644 WO The drive cycle condenser may use a density function, which may be a time density function: a line, surface or hypersurface of the time spent over each unit of operating space (depending on the parameters / variables chosen by the user). Coverage may be represented as a surface on a speed-acceleration plane, for example, with the coverage being expressed as the amount of time spent in a square of unit speed by unit acceleration, for example. The coverage may be expressed in units of s4rrr2. More generally, the coverage may be over any user-defined parameters / variables of the drive cycle, of which speed and acceleration are examples. The user-defined parameters may include one or more of speed, acceleration, engine load, motor torque, and / or state of charge. There may be one user-defined parameter, or one or more user-defined parameters, or a plurality of user-defined parameters, or two user-defined parameters, or three user-defined parameters and so on, depending on user choice.

[0088] The time density function may be an accumulation of points, each point represented as a normal distribution or another suitable distribution.

[0089] The drive cycle condenser may generate a time density function for the input drive cycle(s), which may be referred to as an input time density function. A target time density function for a condensed drive cycle may be generated based on the input time density function. The input time density function may be scaled to represent a drive cycle of the targeted duration, which may be referred to as a target time density function. The input time density function may be scaled by a user-defined scaling factor. The target time density function may maintain the same overall coverage trends as the input time density function while ensuring edge case inclusion in the condensed profile.

[0090] The drive cycle condenser may construct a new, condensed drive cycle by dividing the original (input) drive cycle(s) into time segments. The duration of each time segment may be predetermined by the user (for example 10 seconds). For example, the input drive cycle(s) may include speed profile(s) over time. For each segment the drive cycle condenser may calculate a time density function and evaluate whether its inclusion in the condensed drive cycle contributes to achieving the target time density function. A segment may be deemed to contribute to achieving the target time density function if, for any part of the speed x acceleration surface, the condensed drive cycle currently has a coverage of less than the target coverage, and the segment offers an increase in coverage of more than a predefined minimum. Accordingly, the segment may be added to the condensed drive cycle if it moves the condensed drive cycle time density function toward the target time density function (i.e. causes the condensed drive cycle time density function to conform more closely to the target time density function). The time density function for the condensed drive cycle may, therefore, be determined after the addition of each segment, and compared to the target time density function to determine if additional segments are required.

[0091] The drive cycle condenser may concatenate the included segments together and optionally apply filtering to remove discontinuities caused by adjacent segments not being contiguous in the original drive cycle. In other words, a filter may be used to prevent speed jumps between non-contiguous

[0092] H 1644 WO segments (segments which previously had other segments between them). The parameter tuning for condensed profile generation may be further validated using KL-Divergence based scoring, resulting in a shortened drive cycle that retains the original drive cycle’s real-world behaviour traits.

[0093] In other words, therefore, the condensed drive cycle should have a reduced time (duration) while having a time density function that is representative of the input time density function. The condensed drive cycle time density function may not be an identical scaled version of the input time density function (for example edge cases may have greater representation in the condensed time density function) but the coverage of the condensed time density function may be representative of the coverage of the input time density function, thus maintaining real-world representation.

[0094] KL divergence may be used to score the correlation between the input time density function and the condensed time density function, in order to verify that the condensed time density function is within a threshold tolerance of the input time density function.

[0095] An example of the coverage of an input drive cycle compared to a condensed drive cycle can be seen in Figs. 17 and 18. As illustrated, redundant parts of the input drive cycle have been removed (for example reducing the amount of time spent stationary), while maintaining the overall coverage.

[0096] An example of an input (original) drive cycle is shown in Fig. 19. In this example, the input drive cycle is a combination of nine drive cycles corresponding to the driving conditions in nine different locations. The nine drive cycles have been combined into one input drive cycle, which, as indicated, has a total duration of around 35,000 seconds. A coverage heat map for the input drive cycle of Fig. 19 is shown in Fig. 20, which illustrates the prominence or coverage of a given value of speed and motor torque.

[0097] Fig. 21 illustrates a condensed drive cycle derived from the input drive cycle of Fig. 19 via the drive cycle condenser described herein. As indicated, the total duration of the condensed drive cycle is a little over 6,000 seconds, which is a significant reduction compared to the input drive cycle. A coverage heat map for the condensed drive cycle of Fig. 21 is shown in Fig. 22. Comparing the heat maps of Fig. 20 and Fig. 22, it can be seen that the condensed drive cycle retains similar coverage to the input drive cycle despite having a substantially shorter duration.

[0098] The generated drive cycle may, therefore, be representative of real world driving conditions and may allow a user to tailor the drive cycle to reflect real world conditions in different locations at different times, thus enabling more efficient and diverse testing under conditions representative of the real world. This can lead to energy savings, raw material savings, reduced emissions, quicker testing, and lower costs, among other advantages.

[0099] Acceleration data as used in the drive cycle, time density function and / or coverage parameter(s) may include a contribution reflecting the impact of gravity on the vehicle. This may, therefore, take into account the gradient of the route at any given point, and account for the impact of the gradient

[0100] H 1644 WO on the work required to achieve a given acceleration and / or speed. Acceleration and gradient data may, therefore, be combined into a single variable that represents powertrain effort.

[0101] The drive cycle (whether synthetic or real) may be provided to a unit under test 100 and / or to a virtual module such as the digital twin 201. The unit under test 100 may be the vehicle 3 or a part thereof, for example a system or subsystem of the vehicle 3. For example, the unit under test 100 may be the powertrain 30 or a part thereof such as the power supply 305. The digital twin 201 may be a digital twin of the vehicle 3 or a system or subsystem of the vehicle 3, for example, or a digital twin of the unit under test 100.

[0102] The unit under test 100 may be a physical unit, and may be provided with instrumentation to measure relevant performance data for the unit under test 100. For example, if the unit under test 100 is the power supply 305, the measured performance data may include battery current, battery voltage, battery temperature, state of charge, depth of discharge, state of health, and so on. If the unit under test 100 is a powertrain 30 or part thereof, measured performance data may include torque, speed, temperature, DC bus voltage, dyno load, dyno speed, horsepower, torque demand, torque output (which may therefore be compared with the torque demand to identify lag in the system, for example), mechanical power, electrical power demand, coolant temperature, torque ramp up rate, torque ramp down rate, rate of change of torque, or any other performance data. It will be appreciated that relevant performance data will depend on the specific unit under test 100.

[0103] The performance data may be obtained by incorporating the unit under test 100 into an XiL rig. XiL may also be known as “everything-in-the-loop”, and may encompass one or more of software-in- the-loop (SiL), hardware-in-the-loop (HiL), driver-in-the-loop (DiL), and vehicle-in-the-loop (ViL). In particular, in an XiL rig, the unit under test 100 may be a physical (real) unit, and at least a part of the vehicle 3 may be simulated (virtually). The XiL rig may therefore combine real and simulated parts of the vehicle 3 to provide performance data for the unit under test 100 in the context of the vehicle 3 - to establish how the unit under test 100 would perform if incorporated into the particular vehicle 3, for example. This can allow the performance of the same unit under test 100 (for example, the power supply 305) to be evaluated for different vehicles 3 (for example, a first car compared to a second car, which may be heavier, for example). This reduces the number of real physical components needed to assess the performance of the unit under test 100, and can therefore reduce costs, reduce material use, and speed up development times.

[0104] The XiL rig may include sensors to monitor the performance characteristics of the unit under test 100, so as to generate the performance data. The sensors may differ depending on the particular unit under test 100. For example, if the unit under test 100 is the power supply 305, the sensors may include current sensors, voltage sensors, temperature sensors, and so on. If the unit under test 100 is the powertrain 30, the sensors may include current sensors, voltage sensors, temperature sensors, torque sensors, speed sensors, power sensors, and so on.

[0105] H 1644 WO The XiL rig may include one or more replicators to replicate one or more inputs influencing the performance of the unit under test 100. For example, the XiL rig may include a dyno (dynamometer) to replicate road conditions, for example by road load replication (which may also be known as road load simulation). The XiL rig may include one or more temperature controllers (such as a thermal emulator, heater and / or cooler) to replicate temperature conditions, such as the temperature conditions that would be experienced by the unit under test 100 during the generated drive cycle. These temperature conditions could include the ambient temperature indicated in the weather profile and / or temperatures associated with the operation of the vehicle 3, and may include a combination of the ambient temperature and the temperatures associated with the operation of the vehicle 3.

[0106] In some versions the unit under test 100 may be incorporated into a sample vehicle or sample vehicle fleet for testing. Performance data may therefore be gathered by driving the sample vehicle on the generated drive cycle, which may be done in the real world by driving the vehicle on a test route, or may be done by testing the sample vehicle on a dyno, or through following an impeding vehicle subjected to the test route on a proving ground for example.

[0107] The unit under test 100 may be controlled so as to simulate or emulate the generated drive cycle (e.g. to simulate or emulate the effect on the unit under test 100 of the vehicle 3 traversing the generated drive cycle). For example, if the unit under test 100 is the powertrain 30 or part thereof, it may be controlled so as to output the required velocity / speed indicated by the velocity or speed profile. If the unit under test 100 is the power supply 305, for example, then it may be controlled to simulate or emulate the charge and / or discharge parameters corresponding to the generated drive cycle (e.g. to provide the necessary power to meet the velocity / speed specified in the velocity / speed profile, and / or to receive power generated by regenerative braking throughout the drive cycle).

[0108] The system 1 may include the digital twin 201 , which may be a digital twin 201 of the vehicle 3 or a part thereof, such as the unit under test 100. The performance data may be uploaded to the digital twin 201. The digital twin 201 may be configured to simulate the performance of the vehicle 3. The digital twin 201 may therefore include one or more digital systems corresponding to real systems of the vehicle 3 - such as a digital powertrain corresponding to the powertrain 30, for example. The digital twin may include one or more of a thermal system digital twin, a HV-battery digital twin, and / or an EDU / e-motor digital twin, for example. The digital twin 201 may be generated by inputting the performance data into a machine learning module configured to simulate the performance of the unit under test 100 and / or the vehicle 3. The digital twin 201 may, therefore, be used to predict the performance of the vehicle 3 for a given drive cycle, such as to predict the energy usage of the vehicle 3 for the drive cycle.

[0109] The calibration optimiser 202 may receive input data from the drive cycle generator 200 and / or the digital twin 201. The calibration optimiser 202 may receive the generated drive cycle from the drive

[0110] H 1644 WO cycle generator 200. The calibration optimiser 202 may receive simulated vehicle performance data from the digital twin 201 , and may receive one or more calibration parameters from the digital twin 201 . The calibration optimiser 202 may optimise one or more of the calibration parameters. In some versions the calibration optimiser 202 may store the calibration parameters and may provide the calibration parameters to the digital twin 201 , and the digital twin 201 may determine simulated vehicle performance data based on the received calibration parameters.

[0111] The calibration optimiser 202 may receive the generated drive cycle from the drive cycle generator 200 and the simulated vehicle performance data from the digital twin 201 , and may optimise the calibration parameters so as to minimise or maximise one or more vehicle performance parameters, and this may be done using one or more cost functions. For example, the calibration optimiser 202 may minimise energy consumption (which may include electrical power consumption and / or fossil fuel consumption, for example) for the vehicle 3 over the course of the generated drive cycle. The calibration optimiser 202 may minimise CO2 emissions for the vehicle 3 over the course of the drive cycle. The calibration optimiser 202 may minimise heat generation and / or irreversible losses over the course of the drive cycle. In some versions a number of cost functions may be combined so as to perform global optimisation for the vehicle 3.

[0112] The calibration optimiser 202 may generate optimised calibration parameters. The optimised calibration parameters may be outputted to the digital twin or simulated control strategies for validation (and this may therefore be virtual validation). For example, the digital twin may simulate the performance of the vehicle 3 or the unit under test 100 for the same generated drive cycle, and the simulated vehicle performance data under the optimised calibration parameters may be compared with the previous vehicle performance data to verify that the vehicle performance has improved. Additionally or alternatively, the optimised calibration parameters may be provided to the unit under test 100 for physical validation. The unit under test 100 may, therefore, traverse the generated drive cycle again under the optimised calibration parameters, and the performance data associated with the optimised calibration parameters may be compared with the previous performance data to verify that the performance of the unit under test 100 or vehicle 3 has improved. The process may be iterative, with the calibration optimiser iteratively optimising the calibration parameters.

[0113] The calibration parameters may govern vehicle torque management, vehicle thermal management, and / or vehicle energy management, for example. The calibration parameters may be provided as calibration maps. The optimisation of the calibration parameters may include wheel torque request optimisation, HV-battery BMS optimisation, and / or thermal controller optimisation, for example.

[0114] The optimisation process may be performed for a series of different drive cycles. These drive cycles may each be generated by the drive cycle generator and may be representative of real world drive cycles expected to be encountered by the vehicle 3. The calibration optimiser 202 may therefore generate a series of optimised calibration parameters, and these optimised calibration

[0115] H 1644 WO parameters may be averaged to provide globally optimised calibration parameters for the vehicle 3 or the unit under test 100. The optimisation may be performed using a condensed drive cycle as described herein, which may reduce the time required.

[0116] The calibration optimiser 202 may use the digital twin 201 and one or more input drive cycle(s) in loop with a reduced order model of a control unit / module to be optimised, in order to determine updated calibration parameters for that control unit / module. The updated calibration parameters may then be input to the model of the control unit / module and the performance of the updated module may be simulated using the digital twin 201. This may be an iterative process.

[0117] The optimised calibration parameters or the globally optimised calibration parameters may be provided to a software-defined vehicle 101 , for example by an over-the-air download. The software-defined vehicle 101 may therefore be updated with the optimised or globally optimised calibration parameters, and this may improve the performance of the software-defined vehicle 101 over its lifetime.

[0118] Performance data from the software-defined vehicle 101 may be uploaded to the digital twin 201 periodically or continuously, and this may improve the accuracy of the digital twin.

[0119] The vehicle 3 may include a high-performance computer.

[0120] The digital twin 201 may be hosted remotely from the vehicle 3 or the software-defined vehicle 101 , for example on the cloud, or may be downloaded to the high-performance computer. The software- defined vehicle 101 may be considered an example of the vehicle 3.

[0121] The drive cycle generator 200, digital twin 201 and calibration optimiser 202 may enable journeyspecific calibration optimisation for the vehicle 3. The vehicle 3 may include a navigation module, or may be linked to an external navigation module (such as a smartphone app). A user may input a journey to the navigation module. The drive cycle generator may generate a drive cycle for the input journey, including one or more of the profiles described previously (e.g. using map data).

[0122] The generated drive cycle may be input to the calibration optimiser 202, which may optimise the calibration parameters for the vehicle 3 for the input journey based on the simulated vehicle performance data provided by the digital twin 201 .

[0123] The vehicle 3 may then be recalibrated with the optimised calibration parameters for the input journey. The optimised calibration parameters may be determined on the cloud and downloaded to the vehicle 3, or may be determined locally at the vehicle 3.

[0124] The optimised journey-specific calibration parameters may include, for example, one or more of optimised adaptive cruise control parameters, optimised predictive torque management parameters, optimised predictive thermal management parameters, optimised vehicle preconditioning parameters, and optimised battery management parameters.

[0125] H 1644 WO The optimised parameters may be downloaded to the relevant controller or controllers, for example to an energy management VCU, vehicle VCU, fuel cell controller, adaptive cruise control controller, powertrain ECU, thermal ECU, and / or battery management system. In some versions the optimised parameters may be downloaded to the relevant zonal controller, such as a powertrain zonal ECU or thermal zonal ECU.

[0126] The disclosed optimisation method and system 1 may be used to minimise the total cost of ownership of the vehicle 3.

[0127] For example, the drive cycle generator 200 and digital twin 201 may be used to simulate the performance of the vehicle 3 for a given journey. The performance data may include energy consumption data for example, such as predicted battery state-of-charge or depth-of-discharge data, or predicted fuel consumption. This can be used to estimate the energy / fuel required to complete the journey, and / or the predicted energy / fuel remaining in the vehicle 3 at the end of the journey.

[0128] This predicted performance data can be used to optimise the refuelling or recharging of the vehicle 3, or a fleet of vehicles 3.

[0129] For example, the amount of energy / fuel needed for the vehicle 3 to complete the journey can be predicted, and the vehicle 3 can then be provided with that amount of energy / fuel (rather than simply filling the vehicle 3 to its maximum energy / fuel capacity).

[0130] Additionally, if the journey start time is known, the vehicle 3 charging schedule can be optimised to minimise carbon intensity for the input electrical power. For example, the vehicle 3 may be charged and / or thermally pre-conditioned with energy provided by a grid supply. Thermal preconditioning may include warming or cooling a vehicle cabin, for example, and / or prewarming an engine or battery of the vehicle 3. The carbon intensity, and / or forecast carbon intensity, of the grid energy may be known (for example measured in grams of CO2 per kWh). The calibration optimiser 202 may then determine an optimum charging time and / or duration for the vehicle 3 in order to minimise the carbon intensity of the input energy.

[0131] The methods disclosed herein may also be used to provide real-time driver coaching, for example to minimise energy consumption. As described previously, a user journey may be input to a navigation module. The drive cycle generator 200 may generate a drive cycle for that journey and the digital twin 201 may be used to predict the vehicle performance for that journey. The calibration optimiser 202 may be used to determine the optimum calibration parameters for that journey, for example to minimise energy consumption.

[0132] However, instead of providing the optimised calibration parameters directly to the vehicle 3, the parameters may instead be provided to a driver, for example visually, such as via a driver coaching app configured to be displayed on a smartphone or integrated vehicle display.

[0133] H 1644 WO For example, the calibration optimiser 202 may determine a recommended acceleration and / or recommended braking for a given gradient and speed / velocity based on vehicle location (e.g. to optimise energy consumption for the journey), and may display the recommendation to the driver, for example as an indicator of how much to accelerate and / or brake in real time throughout the journey.

[0134] The calibration optimisation may also be used to minimise friction brake usage for a given journey. The vehicle 3 may include a brake system 33 including a regenerative braking system 330 and a friction brake system 331 , for example, and the regenerative braking system 330 may be configured to provide energy to an electrical battery (such as the power supply 305), load bank, and / or thermal battery 303 (which may also be referred to as a heat battery and may include a material such as a phase change material). The vehicle 3 may therefore include a brake system controller 317 to control the distribution of braking force between the regenerative and friction brake systems 330,331.

[0135] The user may input a journey to a navigation module, and the drive cycle generator 200 may generate a drive cycle for the input journey. The digital twin 201 may simulate the vehicle 3 driving the journey including the simulation of braking events. This may be used to generate a brake force profile for the journey, for example (which may be a profile of required brake force over distance or time).

[0136] The calibration optimiser 202 may use the drive cycle including the brake force profile to determine the expected regenerative braking output throughout the journey, and the associated charge levels of the electrical battery 305 and / or thermal battery 303, for example.

[0137] If the calibration optimiser 202 determines that the output regenerative braking energy exceeds the ability of the electrical battery 305 and / or thermal battery 303 to receive the output energy at any point in the journey, the calibration optimiser 202 may generate a corresponding energy discharge profile for the electrical battery and / or thermal battery 303. The energy discharge profile may ensure that the electrical battery 305 and / or thermal battery 303 has capacity to receive energy from the regenerative braking system 330, which may reduce the need to use friction braking during the journey.

[0138] The calibration optimiser 202 may, therefore, output braking calibration parameters for the journey, and the vehicle 3 may control the operation of the braking system 33 according to the braking calibration parameters. The braking calibration parameters may include a distribution of braking force between the regenerative and friction brake systems 330,331 , and may include charge / discharge parameters for the electrical battery 305 and / or thermal battery 303. Discharge parameters for the electrical battery 305 may indicate a required output power, for example, and the output power may be distributed between the powertrain 30 (e.g. electric motor) and auxiliary loads, such as the HVAC system 32. Discharge parameters for the thermal battery 303 may indicate a required heat output, for example, and the output heat may be distributed between the

[0139] H 1644 WO powertrain 30 (e.g. to warm the internal combustion engine) and auxiliary loads such as the HVAC system 32 (e.g. to warm the cabin). Excess heat may be discharged through the vehicle 3 radiator I cooling system.

[0140] For example, if the journey includes a downhill section (which would be indicated in the elevation or gradient profile), the calibration optimiser 202 may generate optimised calibration parameters indicating that power or heat output from the electrical battery 305 or thermal battery 303 should be increased before the downhill section so that capacity is available to recharge the respective batteries via regenerative braking on the downhill section. The calibration optimiser 202 may generate optimised calibration parameters indicating predictive thermal conditioning of the electrical battery 305 prior to a high power demand event such as climbing steep gradient, thereby preventing performance degradation due to electrical battery 305 cell temperatures.

[0141] Fig. 16 provides a schematic illustration of a computing device 4 that may be used to implement one or more virtual components of the disclosed technology, such as one or more software modules described herein, such as one or more of the scenario generator 200, digital twin 201 , and / or calibration optimiser 202. The computing device 4 may include a processor 41 and a computer-readable storage medium 42. The computer-readable storage medium 42 may be non- transitory computer-readable storage medium, and may be operably coupled to the processor 41. One or more components of the computing device 4 may be implemented using cloud technology. In other words, the computing device 4 may be a distributed computing device 4 in which one or more components, such as the processor 41 and / or computer-readable storage medium 42, may be distributed across a plurality of physical components and / or locations.

[0142] Software modules described herein, such as one or more of the scenario generator 200, digital twin 201 , and / or calibration optimiser 202, may comprise computer program instructions which may be executable by a processor such as the processor 41. The one or more modules may be stored on a computer-readable storage medium, such as a non-transitory computer-readable storage medium. The one or more modules may be stored on the computer-readable storage medium 42. The one or more modules may, therefore, be a computer program embodied on a non-transitory computer readable storage medium.

[0143] A computer program may be written in a programming language, including compiled or interpreted languages, or declarative or procedural languages. A computer program may include a unit suitable for use in a computing environment, including as a stand-alone program, a module, a component, or a subroutine. A computer program may or may not correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one or more

[0144] H 1644 WO computer processors located locally at one site or distributed across multiple remote sites and interconnected by a communication network.

[0145] When used in this specification and claims, the terms "comprises" and "comprising" and variations thereof mean that the specified features, steps or integers are included. The terms are not to be interpreted to exclude the presence of other features, steps or components.

[0146] The invention may also broadly consist in the parts, elements, steps, examples and / or features referred to or indicated in the specification individually or collectively in any and all combinations of two or more said parts, elements, steps, examples and / or features. In particular, one or more features in any of the embodiments described herein may be combined with one or more features from any other embodiment(s) described herein.

[0147] Protection may be sought for any features disclosed in any one or more published documents referenced herein in combination with the present disclosure.

[0148] Although certain example embodiments of the invention have been described, the scope of the appended claims is not intended to be limited solely to these embodiments. The claims are to be construed literally, purposively, and / or to encompass equivalents.

[0149] H 1644 WO

Claims

CLAIMS1. A method for optimising vehicle calibration parameters, including: providing a representative real world drive cycle to a physical unit under test; generating performance data for the physical unit under test as the physical unit under test traverses the drive cycle; using the performance data as training data for a digital twin of a system, sub-system or vehicle in which the physical unit under test is configured to be used; providing vehicle performance prediction data from the digital twin to a calibration optimiser; and optimising one or more vehicle calibration parameters using the calibration optimiser.

2. A method according to claim 1 , further including providing the optimised vehicle calibration parameters to the physical unit under test, and validating that the optimised vehicle calibration parameters improve the performance of the unit under test.

3. A method according to any preceding claim, further including generating the drive cycle.

4. A method according to claim 3, wherein the drive cycle is a synthetic drive cycle generated using map data and / or representative traffic flow data from traffic simulator platforms.

5. A method according to any preceding claim, wherein the drive cycle includes one or more of a velocity or speed profile, a gradient profile, an elevation profile, a weather profile, and a traffic simulation profile.

6. A method according to any preceding claim, wherein the physical unit under test is a powertrain, high voltage battery, thermal system, adaptive cruise control system, advanced driver assistance system, or part thereof.

7. A method according to any preceding claim, wherein the physical unit under test is provided on an XiL rig or instrumented vehicle which contains the physical unit under test to determine the performance data.

8. A method according to any preceding claim, wherein the vehicle performance data includes simulated performance data for a simulated vehicle system.

9. A method according to claim 8, wherein the simulated vehicle system is different to the physical unit under test.H 1644 WO10. A method according to any preceding claim, further comprising sending the optimised vehicle calibration parameters to a vehicle to recalibrate the vehicle’s vehicle calibration parameters over the lifetime of the vehicle.

11. A method for generating journey-specific optimised vehicle calibration parameters for a vehicle, including: generating a drive cycle for the journey; simulating vehicle performance for the journey using a digital twin of the vehicle and a baseline set of vehicle calibration parameters; and optimising the vehicle calibration parameters for the journey using a calibration optimises12. A method according to claim 11 , further including inputting the journey to a navigation module, and generating the drive cycle for the journey using a drive cycle generator which uses map data from the navigation module and representative traffic flow data from traffic simulator platforms to generate the drive cycle.

13. A method according to claim 11 or 12, further including recalibrating the vehicle with the journey-specific optimised vehicle calibration parameters.

14. A method according to any of claims 11-13, wherein if the vehicle is determined to have deviated from the generated drive cycle during the journey, the vehicle is recalibrated back to the baseline vehicle calibration parameters.

15. A method according to any of claims 11-14, wherein the drive cycle includes one or more of a velocity or speed profile, a gradient profile, an elevation profile, a weather profile, and a traffic simulation profile.

16. A method according to any of claims 11-15, wherein simulating the vehicle performance for the journey includes determining a predicted vehicle energy consumption for the journey.

17. A method according to any of claims 11-16, wherein the vehicle calibration parameters include one or more of a torque management parameter, a thermal management parameter, and an energy management parameter.

18. A method according to claim 17, wherein the torque management parameter includes one or more of a torque distribution parameter between an internal combustion engine and an electric motor, a torque distribution parameter between front and rear axle, and / or a torque distribution parameter between left and right wheels of the vehicle.H 1644 WO19. A method for reducing friction brake usage in a vehicle, including: generating a predicted drive cycle for a journey; simulating vehicle performance over the drive cycle using a digital twin of the vehicle and a baseline set of vehicle calibration parameters to generate a brake force profile for the journey; generating a battery state-of-charge profile for an electrical and / or thermal battery of the vehicle for the journey; determining an amount of energy that would be generated if all of the brake force in the brake force profile was provided by a regenerative braking system; determining if the electrical and / or thermal battery has sufficient capacity at each stage of the journey to receive all of the energy generated by the regenerative braking system; and generating an energy discharge profile for the journey indicating an energy to be discharged from an electrical battery of the vehicle or a thermal battery of the vehicle such that the electrical or thermal battery has capacity to receive all of the regenerated energy.

20. A method for reducing energy consumption in a vehicle, comprising: generating a drive cycle for a journey to be driven by the vehicle; simulating the performance of the vehicle over the journey by providing the drive cycle to a digital twin of the vehicle; determining an optimum acceleration profile for the journey to minimise energy consumption; and providing the optimum acceleration, deceleration and coasting profile to a driver of the vehicle in real time as the driver completes the journey.21 . A method for generating a drive cycle for a vehicle, comprising: generating a vehicle route defining a real-world route to be traversed by the vehicle; determining a speed profile for the route based on a traffic simulation for the route; determining one or more of a gradient profile based on map data for the route, elevation profile based on map data for the route, and / or weather profile based on weather data for the route; and generating a drive cycle based on the determined speed profile and the at least one of the gradient profile, elevation profile, and / or weather profile.

22. A method for condensing an input drive cycle for a vehicle or powertrain to a condensed drive cycle for a vehicle or powertrain while maintaining coverage over one or more user-defined variables of the input drive cycle, the method comprising: receiving an input drive cycle having a first duration; generating an input density function for the input drive cycle which represents the coverage of the input drive cycle over the user-defined variables;H 1644 WOgenerating a target density function for a condensed drive cycle based on the input density function; segmenting the input drive cycle into a plurality of segments; and generating a condensed drive cycle having a second duration, wherein the second duration is shorter than the first duration, by concatenating segments of the input drive cycle, wherein a segment of the input drive cycle is added to the condensed drive cycle if it causes a density function of the condensed drive cycle to conform more closely to the target density function, and is not included in the condensed drive cycle if it does not.

23. A method according to claim 22, wherein the user-defined variables include one or more of speed, acceleration, engine load, motor torque, and / or state of charge.

24. A method according to claim 22 or 24, wherein the target density function is generated by scaling the input density function.

25. A method according to any of claims 22-24, wherein a filter is applied to the concatenated segments to prevent discontinuities in variables between segments.

26. A method according to any of claims 22-25, wherein the density functions are time density functions.H 1644 WO

Images