WO2023031135A1

WO2023031135A1 - Model-based predictive control of an electric vehicle

Info

Publication number: WO2023031135A1
Application number: PCT/EP2022/073979
Authority: WO
Inventors: Markus Stephan HUG; Alexander DOMAHIDI; Vasilis LEFKOPOULOS
Original assignee: Embotech Ag
Priority date: 2021-09-03
Filing date: 2022-08-29
Publication date: 2023-03-09
Also published as: EP4396030A1; CH718944A2

Abstract

The invention relates to a model-based predictive (MPC) control of an electric vehicle. It is notably directed to a method that comprises: executing an MPC algorithm (13) involving a high-level solver module (13.1), a longitudinal vehicle dynamics model (14), and a cost function (15) that is associated with the high-level solver module (13.1). The high-level solver module (13.1) is executed during a current route section, by taking into account the longitudinal vehicle dynamics model (14) to calculate a longitudinal trajectory (31) mini-mising the cost function (15), for the electric vehicle (1) to travel over a prediction horizon in accordance with the calculated cost function. The cost function (15) contains a first term (16) describing an amount of energy (–E_Bat) to be supplied by a battery (9) of the electric vehicle (1) over the prediction horizon in accordance with the calculated longitudinal trajectory (31), the battery (9) serving as an energy store for an electric machine (8) for driving the electric vehicle (1). It further contains a second term (17) describing a travel time deviation percentage (T_t) between a predicted travel time (t_p) and a minimum travel time (t_min). The predicted travel time (t_p) describes how long the electric vehicle (1) re-quires to travel over the prediction horizon according to the calculated longitudinal trajectory, while the minimum travel duration (tmin) describes a minimum time period which the electric vehicle (1) requires to travel over the prediction horizon.

Description

MODEL-BASED PREDICTIVE CONTROL OF AN ELECTRIC VEHICLE

The invention relates to model-based predictive control of an electric vehicle. In particular, it is directed to methods and computer program products for model-based predictive control of an electric vehicle.

Today's intelligent cruise control systems (e.g., the so-called "Predictive Green ACCs") of vehicles can take into account the route topology, but typically decide on the driving strategy (and thus the longitudinal control) in a rule-based manner. The rule-based implementation usually leads to suboptimal solutions in terms of energy consumption, comfort and travel time. With increasing complexity of the driving system, such a control system also becomes more complex and requires a high tuning and calibration effort. Optimal operation of a vehicle (e.g., with regard to the performance goals of energy consumption, comfort, and travel time) is only possible with good knowledge of the route to be driven. A driver of a vehicle must therefore drive with foresight but has only limited insight into the further course of the route and no insight into the vehicle-specific driving efficiencies.

Embodiments of the present invention provides methods for vehicle control systems which address the problems described above. The essential features of the present invention are described in the appended independent claims. Advantageous embodiments are described in the dependent claims, the following detailed description, and the accompanying drawings.

A first aspect of the present invention concerns a method for model-based predictive control of an electric vehicle, which revolves around executing a model-based predictive (MPC) algorithm involving a high-level solver module, a longitudinal vehicle dynamics model, and a cost function that is associated with the high-level solver module. The method is a computer-implemented method. The high-level solver module is executed during a current route section, with a view to calculating a longitudinal trajectory over a certain prediction horizon. The high-level solver module is executed by taking into account the longitudinal vehicle dynamics model, so as to calculate the longitudinal trajectory, which is achieved by minimising the cost function. This way, the electric vehicle can eventually travel over the prediction horizon in accordance with the calculated longitudinal trajectory.

The process is typically iterated, whereby longitudinal trajectories are iteratively computed for successive route sections. Note, the current route section precedes the route section corresponding to the prediction horizon and can thus be regarded as a "preceding" route section. That being said, the longitudinal trajectory may also be calculated for a predetermined route section or a pre-planned route section. Remarkably, in the present context, the cost function contains at least two terms. The first term describes (i.e., reflects or captures) an amount of energy to be supplied by a battery of the electric vehicle over the prediction horizon in accordance with the calculated longitudinal trajectory. I.e., this amount of energy corresponds to the energy that the battery will have supplied at the end of the prediction horizon, according to the calculated longitudinal trajectory. The battery serves as an energy store for an electric machine for driving the electric vehicle.

The second term describes a travel time deviation percentage between a predicted travel time and a minimum travel time. The predicted travel time describes how long the electric vehicle requires (i.e., the time duration required for the vehicle) to travel over the prediction horizon, according to the calculated longitudinal trajectory. The minimum travel duration describes a minimum time period which the electric vehicle requires to travel over the prediction horizon.

Thus, according to the present invention, executing the MPC algorithm causes to execute a high-level solver module, which, in turn, causes to minimise a cost function. The present invention relies on the so-called "model predictive control" (MPC) approach. The first term of the cost function describes the energy to be supplied by the battery of the electric vehicle, i.e., the cumulated energy that will have been supplied at the end of the prediction horizon, whereas the second term describes the percentage deviation of the travel time from the fastest possible time to reach the prediction horizon. The quantities involved in the cost function are used to obtain an approximate trajectory from the high-level solver module (i.e., a calculated longitudinal trajectory), where this trajectory extends until the end of the prediction horizon (or travel horizon). In general, the prediction horizon can be defined in terms of time and/or space (namely a distance). For example, the prediction horizon can be set to a length between 400 and 1200 metres (e.g., by way of natural numbers N), for example a length of 500 metres.

Model-based predictive control usually relies on three process steps. In a first step, a virtual driving horizon (prediction horizon) is determined, e.g., from available map data and sensor information. The prediction horizon serves to a trajectory planner and controller for generating a longitudinal trajectory of the vehicle, e.g., a speed or acceleration. In a second step, an iterative online computation of a longitudinal trajectory is carried out by optimising the trajectory with respect to existing performance goals according to the MPC approach. In a third step, the calculated trajectory is implemented, automatically, by sending it to the vehicle.

In the present context, combining a high-level solver module with a cost function as described above provides an optimal solution for an electric vehicle with a short planning horizon, while at the same time meeting requirements for fast computation cycles. In this sense, a method for model-based predictive control of an electric vehicle is provided.

An "electric vehicle" can be understood as a vehicle that is driven by electrical energy. Energy can initially be supplied to the electric vehicle in the form of electrical energy. The electrical energy can then be stored in a battery of the electric vehicle (battery electric vehicle). Alternatively, the electrical energy may be supplied permanently from the outside, e.g., via a conductor rail, an overhead line or by induction. The electric vehicle may for example be driven exclusively by at least one electric machine, i.e., without assistance from an internal combustion engine (and so not exclusively by an internal combustion engine). The electric vehicle is, for example, an automobile (e.g., a passenger car weighing less than 3.5 t). Alternatively, the electric vehicle may be a motorbike, scooter, moped, bicycle, e-bike or pedelec (pedal electric cycle), bus or truck (e.g., weighing over 3.5 t). The invention can also be used in small, light electric vehicles of micromobility, these vehicles being used in particular in urban transport and for the first and last mile in rural areas. The first and last mile can be understood as those routes and paths forming the first and last link of a mobility chain. This is, for example, the route from home to the train station or the route from the train station to the workplace. The vehicle can belong to a fleet of vehicles, for example. The vehicle can be controlled by a driver, possibly supported by a driver assistance system. However, the vehicle can also be controlled, for example, remotely and/or (at least partially) autonomously.

As said, the cost function contains at least two terms. For the first term and for the second term, at least one control parameter can be defined in each case, which is used to multiply the amount of energy (first term) or the percentage deviation (second term). In particular, two control parameters can be defined for the first term and the second term; a first control value is defined individually for the first term and for the second term, while a second (common) control value is defined for the first term and for the second term, which enters directly into the first term and into the second term (in particular with its difference from the value one). By using a high common control value, the costs for the amount of energy can be more significant (in the cost function) and the solution of the optimisation process can be correspondingly more energy-efficient, but less time-efficient. Conversely, by selecting a low common control value, the costs for the amount of energy can be less significant and the solution of the optimisation process can be correspondingly less energyefficient but more time-efficient.

For example, in embodiments, the energy quantity of the first term is multiplied by a control parameter A. The travel time deviation percentage of the second term is multiplied by a factor (1 - A), which is the difference between the value one and the control parameter A, by which the energy quantity of the first term is multiplied. The control parameter A is set to a relatively high value if costs for the amount of energy are to have a relatively high impact. Furthermore, the control parameter A is set to a relatively low value if costs for the energy quantity are to be relatively weakly weighted. In this example, the control parameter A typically assume values between zero and one, e.g., real numerical values.

In order to calculate the travel time deviation, the high-level solver module can for instance be executed in an upstream solver call. For this first call (corresponding to a first iteration), maximum weight is placed on the travel time deviation factor. This has the effect of determining the fastest possible time to reach the horizon (corresponding to a minimum travel time). In a second solver call (second iteration), during which an approximate planning of the trajectory is carried out, this value is selected as a reference for calculating the travel time deviation for the present trajectory. That is, the minimum travel duration is calculated by a first execution of the high-level solver module, where the control parameter A is set to a minimum value during the first execution of the high-level solver module, such that the difference between the value one and the control parameter A is maximum. The predicted travel time is calculated by a second execution of the high-level solver module, during which the control parameter A is set to a value different from the minimum value (e.g., to a higher value), and the minimum travel time is taken into account in the calculation of the predicted travel time.

The driving losses of the electric vehicle can be estimated and used as a basis to calculate the size of the energy quantity. For this purpose, a general (or specially developed) vehicle model can be used, which can be integrated into the solver and executed online, i.e., in real time. Note, the terminology "online" or "real time" refers to requirements in terms of throughputs required for ensuring sufficiently fast predictions in view of, e.g., enabling a safe autonomous, semi-autonomous, automated (or partly automated) motion of the vehicle 1. One or more types of losses can be taken into account in the model for the calculation of the driving losses and thus for the determination of the required amount of energy, such as air friction losses, rolling friction losses, and drive losses, each according to respective physical models. The integration of the aforementioned losses into the longitudinal model can be done via a loss model. In this sense, the longitudinal model can include a loss model describing an operational behaviour of the electric vehicle with respect to their losses, resulting in an overall (i.e., total) loss function of the electric vehicle. The calculation of the amount of energy that is to be supplied by (i.e., "extracted" from) the battery of the electric vehicle according to the calculated longitudinal trajectory over the prediction horizon is accordingly performed by taking into account the overall loss of the electric vehicle.

The approximate planning (longitudinal trajectory) of the trajectory is preferably calculated iteratively by the high-level solver module. In that case, executing the MPC algorithm causes the high-level solver module to iteratively re-calculate the longitudinal trajectory, e.g., every 200 milliseconds. That is, a new trajectory is computed at each iteration. More generally, the average time interval between two iterations can typically vary between 100 and 1000 milliseconds, though preferably at least every 200 milliseconds, this depending on the system capability. At the end of each iteration, a new planning is completed and fed into the signal flow.

The cost function may contain another quantity describing the braking force of a mechanical wheel brake (also called friction brake) of the electric vehicle. This braking force may for instance quadratically penalize the cost function. This further quantity results in lowering (or even avoiding) the use of the mechanical brake. That is, in embodiments, the cost function includes a third term describing a braking force of a mechanical wheel brake of the electric vehicle. The braking force of the mechanical wheel brake can notably be multiplied by a control parameter individually determined for the third term. As already mentioned, the braking force of the mechanical wheel brake of the electric vehicle can be squared in this third term, for higher impact.

The cost function may further comprise a fourth term and a fifth term. The fourth term describes a kinetic energy of the electric vehicle. The kinetic energy of the electric vehicle can also be multiplied by a control parameter individually defined for the fourth term. The fifth term describes a torque which is applied by the electric machine to drive the electric vehicle. The torque of the electric machine can also be multiplied by a control parameter individually defined for the fifth term. The torque of the electric machine can further be squared in this fifth term, if necessary. The fourth and fifth terms, especially in combination with the third term, enable a particularly reliable and consistent solution to be found, as the present inventors observed.

The long-term approximate planning of the trajectory is typically path-based. This allows a correct, optimal handling of non-dynamic (i.e., static) objects that are within the prediction horizon. Examples of such static objects are gradients, speed limits, other traffic signs (e.g., "stop" or "give way" signs), road turns or traffic lights, embodiments, information about static objects is passed to the high-level solver module in the form of constraints, which the high-level solver module takes into account to calculate the longitudinal trajectory.

Dynamic horizon objects can also be taken into account when calculating the velocity trajectory. Due to long computing times, this is preferably only done in an approximate framework in the high-level solver module. In embodiments, information about dynamic objects is transferred to the high-level solver module, again in the form of constraints, which the high-level solver module takes into account to calculate the longitudinal trajectory.

When adapted to dynamic objects, the longitudinal trajectory may have to be corrected by a more reactive actuator. The approximate longitudinal trajectory, as calculated by the high-level solver module, is typically provided purely as a suggestion that the human driver may want or will have to override, especially during dynamic driving manoeuvres. In embodiments, the calculated longitudinal trajectory may comprise a speed trajectory according to which the vehicle is to travel over the prediction horizon.

Furthermore, the longitudinal trajectory can alternatively or additionally comprise a state of charge trajectory that describes an evolution of a state of charge of the battery, which serves as an energy storage device for the electric machine of the vehicle, whereby the vehicle can be driven by means of the electric machine. The state of charge (SoC) typically corresponds to the current energy content of the electric battery in relation to its maximum energy content.

Furthermore, the longitudinal trajectory may alternatively or additionally comprise a braking force trajectory for a braking system of the vehicle, according to which the braking system provides braking forces (less than or equal to zero) over the prediction horizon. Instead of the above mentioned braking forces, corresponding braking torques can also be included as part of the longitudinal trajectory. The acceleration trajectory refers to accelerations on at least one wheel of the vehicle and may possibly include negative accelerations to be applied by the braking system of the vehicle.

According to another aspect, the invention is embodied as a computer program product for model-based predictive control of an electric vehicle. The computer program product comprises a computer readable storage medium having program instructions embodied therewith, wherein the program instructions are executable by processing means of the vehicle to cause the processing means to perform the steps according to any of the above methods.

Computerized methods and computer program products embodying the present invention will now be described, by way of non-limiting examples, and in reference to the accompanying drawings.

The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, and which together with the detailed description below are incorporated in and form part of the present specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present disclosure, in which :

Fig. 1 is schematic representation of a vehicle, the drive train of which comprises an electric machine and a brake system;

Fig. 2 shows details of an exemplary drive train for the vehicle according to Fig. 1;

Fig. 3 depicts a flow according to a method according to embodiments for model-based predictive control of a vehicle according to Fig. 1, and

Fig. 4 is an example of a cost function that can be involved in the flow of Fig. 3.

RECTIFIED SHEET (RULE 91) ISA/EP Fig. 1 shows a vehicle 1, e.g., a passenger car. The vehicle 1 comprises a computerized system 2 for model-based predictive control of the vehicle 1. In this example, the system 2 comprises a processor unit 3, a memory unit 4, a communication interface 5 and a recording unit 6, in particular for recording status data relating to the vehicle 1.

The vehicle 1 further comprises a drive train 7, which may comprise, for example, an electric machine 8 operable as a motor and as a generator, a battery 9, a transmission 10 and a brake system 19. The electric machine 8 is designed to drive wheels of the vehicle 1 via the gearbox 10 in motor mode. The battery 9 can supply the electrical energy required for this, in particular via power electronics 18. Conversely, the battery 9 can be charged by the electric machine 8 via the power electronics 18 when the electric machine 8 is operated in generator mode (recuperation). The battery 9 can optionally also be charged at an external charging station.

In the example of Fig. 2, the drive train 7 is a purely electric drive train that does involve any assistance by an internal combustion engine. The vehicle 1 is therefore assumed to be a pure-electric vehicle, also called all-electric vehicle. In this example, the electric machine 8 can drive two front wheels 22 and 23 of the vehicle 1, by applying a positive driving torque via the transmission 10 and a front differential gear 21, both mounted on a front axle 25. A first rear wheel 26 and a second rear wheel 28 are mounted on a rear axle 29 of the vehicle 1; they are not driven in this example. In variants, the vehicle is configured as a rear-wheel drive or a, all-wheel drive. The front wheels 22, 23 and the rear wheels 26, 28 can be braked by the brake system 19 of the drive train 7. To this aim, the brake system 19 may possibly be designed to apply a negative braking torque.

A computer program 11 may be stored in the memory unit 4. The computer program 11 can be executed by the processing unit 3. To this aim, the processing unit 3 and the memory unit 4 can be connected to each other by means of a communication interface 5. When the computer program product 11 is executed on the processing unit 3, it directs the processing unit 3 to perform functions as described herein, as well as other functions, if necessary.

The computer program 11 captures an MPC algorithm 13, which involves a high-level solver module 13.1. The MPC algorithm 13 further involves a longitudinal dynamics model 14 of the vehicle 1. The high-level solver module 13.1 can thus access the longitudinal dynamics model 14. Further, the MPC algorithm 13 involves a high-level cost function 15, which is associated with the high-level solver module 13.1, whereby the cost function can be minimised upon executing the solver. The task of the high-level solver module 13.1 is to propose optimised guidance for the vehicle 1, for example with regard to speed restrictions and stopping points as well as traffic lights and inclines. In doing so, according to the high- level cost function 15, an energy consumption of the vehicle 1, a time period required by the vehicle 1 to travel over and reach the high-level prediction horizon, and a frequency with which the braking system 19 of the vehicle 1 is actuated during the high-level prediction horizon, are to be optimized. Note, the above quantities are normally captured in the cost function so as to be minimised upon minimizing the overall cost function.

The high-level cost function 15 shown in Fig. 4 can, for example, include five terms to be minimised, as explained in more detail below.

First term 16. The first term 16 contains information about an amount of energy -E_Bat, which is to be supplied by (and, thus, somehow extracted from) the battery 9 of the vehicle 1 according to the longitudinal trajectory 31 that is calculated by means of the high-level solver module 13.1 over the prediction horizon. The battery 9 serves as energy storage for the electric machine 8 for driving the electric vehicle 1. The value for the amount of energy -E_Bat enters negatively into the first term 16, since it is an energy that is extracted from the battery 8.

Second term 17. The second term 17 contains information about a travel time deviation percentage T_t between a predicted travel time t_p and a minimum travel time tmin. The predicted travel time t_p describes how long the electric vehicle 1 needs to reach (i.e., cross) the prediction horizon according to the longitudinal trajectory 31 calculated by means of the high-level solver module 13.1. The minimum travel duration tmin describes a minimum time period which the electric vehicle 1 requires to reach the prediction horizon. The relationship can be calculated, for example, according to the formula T_t = ^{tp tmin}. If it is as- min sumed, for example, that a prediction horizon can be traversed as quickly as possible in 20 seconds (minimum travel time tmin = 20 seconds), but the high-level Solver 13.1 calculates an optimal longitudinal trajectory 31 according to which the electric vehicle 1 should traverse the prediction horizon in 25 seconds (t_p = 25 seconds), then this results in a travel time deviation percentage of 25 % (7) =

²⁵~₀ ²⁰ = = 25%). Note, the travel time

deviation T_t can equally be expressed as a fraction or a percentage in the present context.

Third term 24. The third term 24 describes a braking force F_Br of a mechanical wheel brake of the electric vehicle 1. The braking force F_Br may for instance be a cumulative braking force, which is applied by the wheel brake within the prediction horizon, in accordance with the longitudinal trajectory 31 calculated by means of the high-level solver module 13.1. In embodiments, the mechanical wheel brake is the brake system 19 described above or at least a part thereof. The braking force F_Br can also be squared in the cost function 15, contrary to the assumption made in Fig. 4. In that case, the braking force quadratically penalised, which results in essentially avoiding the use of the mechanical brake, in operation. Fourth term 30. The fourth term 30 describes a kinetic energy E_kin of the electric vehicle 1. The kinetic energy Ekin may notably be a cumulative energy, with which the vehicle 1 travels over the prediction horizon according to the longitudinal trajectory 31 as calculated by means of the high-level solver module 13.1.

Fifth term 34. The fifth term 34 describes a torque M_mot, which is applied by the electric machine 8 for driving the electric vehicle 1 over the prediction horizon according to the longitudinal trajectory 31 calculated by means of the high-level solver module 13.1. The torque of the electric machine 8 is squared in the fifth term 34.

The fourth 30 and the fifth term 34, especially in combination with the third term 24, make it possible to achieve particularly reliable and consistent trajectory solution in practice.

Each of the five terms 16, 17, 24, 30, 34 can advantageously be accounted for with an individual setting parameter, whereby:

- the amount of energy -E_Bat is multiplied by a first individual control parameter w_Bat,

- the travel time deviation percentage T_t is multiplied by a second individual control parameter w_t,

- the braking force F_Br is multiplied by a third individual control parameter w_Br,

- the kinetic energy E_kin is multiplied by a fourth individual control parameter w_Kin, and

- the torque M_mot is multiplied by a fifth individual control parameter Wmot-

In this context, "individual" can notably be understood to mean that the aforementioned control parameters can be varied independently of each other, so that, for example, the first individual control parameter w_Bat can be selected so as to be lower than the second individual control parameter w_t, should the optimisation emphasize the required travel time more than energy consumption, for example.

The amount of energy -E_Bat of the first term 16 can further be multiplied by a common control parameter A. The travel time deviation percentage T_t of the second term 17, on the other hand, is multiplied by a factor (1 - A), i.e., is the difference between 1 (the value one) and the common control parameter A, by which the amount of energy -E_Bat of the first term 16 is multiplied. In this context, that the control parameter A is a "common" parameter means that the control parameter A is present in both the first term 16 and the second term 17.

The common control parameter A can, for example, assume values between zero and one, in particular any real numerical values in this interval, although quantified values (e.g., 0.0, 0.1, 0.2, etc.) may also be used. By selecting a high (i.e., large) common control value A (e.g., close to 1), the costs for the amount of energy -E_Bat can be more significant, and the solution of the optimisation process can be correspondingly more energy efficient, but less time efficient. Conversely, by choosing a low (i.e., small) common control value A, the costs for the amount of energy -Eeat can be less important, and the solution of the optimisation process can be correspondingly less energy efficient but more time efficient.

The longitudinal dynamics model 14 comprises a loss model 27 of the vehicle 1. The loss model 27 describes the operating behaviour of efficiency-relevant components with regard to their efficiency or with regard to their loss, e.g., the electric machine 8 and the brake system 19. Furthermore, the loss model may also describe, in particular, air friction losses, rolling friction losses, and other drive losses, according to respective physical models. This results in an overall loss of the vehicle 1.

The processor unit 3 executes the MPC algorithm 13 and thereby predicts a behaviour of the vehicle 1 for a sliding, path-based high-level prediction horizon 24 (e.g., corresponding to a length of 500 m). The optimised approximate planning of the longitudinal trajectory 31 is preferably operated iteratively by the high-level solver module 13.1, e.g., every 200 milliseconds (though the target range will typically be between 100 and 1000 milliseconds, depending on the system). Each time a new planning is completed, it is fed into the signal flow and the vehicle is accordingly operated, e.g., autonomously or semi autonomously.

The prediction is based on the longitudinal dynamics model 14. The processing unit 3 calculates, by executing the high-level solver module 13.1, an optimised high-level longitudinal trajectory 31 according to which the vehicle 1 should travel within the high-level prediction horizon 24. The optimised high-level longitudinal trajectory 31 is calculated during a current section of the route (i.e., a section preceding the route section corresponding to the prediction horizon) by taking into account the longitudinal dynamics model 14, whereby the high-level cost function 15 is minimised. To do this, the high-level solver module 13.1 takes into account the long-term approximate planning of the longitudinal trajectory 31 and uses the MPC approach. The long-term approximate planning of the high-level longitudinal trajectory 31 is path-based. This allows for a correct, optimal handling of nondynamic horizon objects (e.g., gradients, speed limits, and other traffic signs, such as "Stop" or "Give way" signs, bends, and traffic lights). This process is typically iterated, whereby longitudinal trajectories are iteratively computed for successive route sections.

In the example flow of Fig. 3, the high-level longitudinal trajectory 31 comprises a speed trajectory 31.1 according to which the vehicle 1 is to move over the high-level prediction horizon 24. In particular, optimised speed values can be assigned to waypoints that the vehicle 1 is to travel along. Furthermore, the high-level longitudinal trajectory 31 comprises a state of charge (SoC) trajectory 31.2, which SoC describes an optimal evolution of the state of charge of the battery 9. Furthermore, the high-level longitudinal trajectory 31 for the braking system 19 comprises a braking force trajectory 31.3, which assigns a braking force to the waypoints (zero or less than zero), which the braking system 19 applies for braking the vehicle 1.

The detection unit 6 can measure current state variables of the vehicle 1, record corresponding data and feed it to the high-level solver module 13.1. Information about static objects and/or route data from an electronic map of a navigation system 20 of the vehicle 1 for a look-ahead horizon or prediction horizon (e.g., 500 m) in front of the vehicle 1 can also be updated, in particular cyclically, and transferred to the high-level solver module 13.1. The route data may include, for example, gradient information, curve information, and information about speed limits, as well as traffic lights and stopping points. Furthermore, a road turn curvature can be converted into a speed limit for the vehicle 1 via a maximum permissible lateral acceleration. In addition, the detection unit 6 can be used to locate the vehicle, in particular via a signal generated by a Global Navigation Satellite System (GNSS) sensor 12 for precise localisation on the electronic map. Furthermore, the detection unit for detecting the external environment of the vehicle 1 may comprise an environment sensor 33, e.g., a radar sensor, a camera system and/or a lidar sensor. In this way, dynamic objects may also be detected in the area of the external environment of the vehicle 1, e.g., moving objects such as other vehicles or pedestrians.

To calculate the travel time deviation T_t, the high-level solver module 13.1 can be executed in an upstream solver call. During this first call, the maximum weight is placed on the factor of the travel time deviation T_t. This results in determining the fastest possible time duration to reach the horizon (the minimum travel time). In the second solver call, during which the approximate planning of the trajectory 31 is performed, this value is selected as a reference for calculating the travel time deviation T_t for the trajectory 31 at issue. In other words, the minimum travel duration tmin is calculated by a first execution of the high-level solver module 13.1, where the setting parameter A is fixed to a minimum value (e.g., to the value 0) during the first execution of the high-level solver module 13.1. Thus, the difference (1 - A) between the value one and the setting parameter A is maximum (e.g., 1 - A = 1 - 0 = 1). The predicted travel time t_p is calculated by a second execution of the high-level solver module 13.1. During the second execution of the high-level solver module 13.1, the actuating parameter A is set to a value that differs from the minimum value (e.g., to a higher value, for example to the value 0.6. Thus, the difference 1 - A increases to the value 1 - A = 1 - 0.6 = 0.4. Since A = 0.6 is directly multiplied by the amount of energy -E_Bat, the centre of gravity of the calculation is shifted towards the amount of energy -E_Bat- The minimum travel time tmin is taken into account in the calculation of the predicted travel time t_p.

Computerized devices can be suitably designed for implementing embodiments of the present invention as described herein. In that respect, it can be appreciated that the methods described herein are at least partly non-interactive, i.e., automated. Automated parts of such methods can be implemented in software, hardware, or a combination thereof. In exemplary embodiments, automated parts of the methods described herein are implemented in software, as a service or an executable program (e.g., an application), the latter executed by suitable digital processing devices.

For instance, a typical computerized device (or unit) may include a processor and a memory (possibly including several memory units) coupled to one or memory controllers. The processor is a hardware device for executing software, as e.g., loaded in a main memory of the device. The processor, which may in fact comprise one or more processing units, can be any custom made or commercially available processor.

The memory typically includes a combination of volatile memory elements (e.g., random access memory) and nonvolatile memory elements, e.g., a solid-state device. The software in memory may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The software in the memory may for instance capture methods as described herein in accordance with exemplary embodiments and a suitable operating system (OS). The OS essentially controls the execution of other computer (application) programs and provides scheduling, inputoutput control, file and data management, memory management, and communication control and related services. It may further control the distribution of tasks to be performed by the processing units.

The methods described herein shall typically be in the form of executable program, script, or, more generally, any form of executable instructions, although part (or all) of the algorithms described herein are preferably executed according to nonlinear programming instructions.

The computerized unit can further include a display controller coupled to a display. In exemplary embodiments, the computerized unit further includes a network interface or transceiver for coupling to a network (not shown). In addition, the computerized unit will typically include one or more input and/or output (I/O) devices, (or peripherals) that are communicatively coupled via a local input/output controller. A system bus interfaces all components. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components. The I/O controller may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to allow data communication.

When the computerized unit is in operation, one or more processing units executes software stored within the memory of the computerized unit, to communicate data to and from the memory and/or the storage unit (e.g., a hard drive and/or a solid-state memory), and to generally control operations pursuant to software instruction. The methods described herein and the OS, in whole or in part are read by the processing elements, typically buffered therein, and then executed. When the methods described herein are implemented in software, the methods can be stored on any computer readable medium for use by or in connection with any computer related system or method. Computer readable program instructions described herein can for instance be downloaded to processing elements from a computer readable storage medium, via a network, for example, the Internet and/or a wireless network. A network adapter card or network interface may receive computer readable program instructions from the network and forwards such instructions for storage in a computer readable storage medium interfaced with the pro- cessing means.

REFERENCE SIGNS

Acommon Control parameter -E_Bat Amount of energy

Ekin Kinetic energy

F_Br Braking force

Mmot Torque

T_t Travel time deviation percentage t_p Predicted travel time tmin Minimum travel time w_Bat First individual setting parameters w_t Second individual control parameter w_Br Third individual control parameter w_Kin Fourth individual control parameter

Wmot Fifth individual control parameter

1 Vehicle

2 System

3 Processor unit

4 Memory unit

5 Communication interface

6 Capture unit

7 Drive train

8 Electric machine

9 Battery

10 Gearbox

11 Computer programme product

12 GNSS sensor

13 MPC algorithm

13.1 High-level solver module

14 Longitudinal dynamics model

15 High-level cost function

16 First term high-level cost function

17 Second term high-level cost function

18 Power electronics

19 Brake system

20 Navigation system

21 Front differential gear

22 Front wheel

23 Front wheel Third term high-level cost function

Front axle

Rear wheel

Loss model

Rear wheel

Rear axle

Fourth term high-level cost function

High-level longitudinal trajectory

Speed trajectory

State of charge trajectory

Braking force trajectory

Environment sensor

Fifth term high-level cost function

Claims

1. A method for model-based predictive control of an electric vehicle (1), wherein the method comprises executing a model-based predictive algorithm, or MPC algorithm (13), involving a high-level solver module (13.1), a longitudinal vehicle dynamics model (14), and a cost function (15) that is associated with the high-level solver module (13.1), whereby the high- level solver module (13.1) is executed during a current route section, by taking into account the longitudinal vehicle dynamics model (14) to calculate a longitudinal trajectory (31) minimising the cost function (15), for the electric vehicle (1) to travel over a prediction horizon in accordance with the calculated longitudinal trajectory, wherein the cost function (15) contains: a first term (16) describing an amount of energy (- E_Bat) to be supplied by a battery (9) of the electric vehicle (1) over the prediction horizon in accordance with the calculated longitudinal trajectory (31), the battery (9) serving as an energy store for an electric machine (8) for driving the electric vehicle (1); and a second term (17) describing a travel time deviation percentage (T_t) between a predicted travel time (t_p) and a minimum travel time (tmin), wherein the predicted travel time (t_p) describes how long the electric vehicle (1) requires to travel over the prediction horizon according to the calculated longitudinal trajectory, and the minimum travel duration (tmin) describes a minimum time period which the electric vehicle (1) requires to travel over the prediction horizon.

2. A method according to claim 1, wherein executing the MPC algorithm (13) further causes to multiply the amount of energy (- E_Bat) of the first term (16) by a control parameter (A), multiply the travel time deviation percentage (T_t) of the second term (17) by a factor that is the difference (1 - A) between the value one and the control parameter (A) by which the amount of energy (-E_Bat) of the first term is multiplied, and set the control parameter (A) in accordance with said amount of energy.

3. A method according to claim 2, wherein the control parameter (A) is set to a relatively high value if costs for the amount of energy (-E_Bat) are to have a relatively high impact, and a relatively low value if costs for the amount of energy (-E_Bat) are to have a relatively low impact.

4. A method according to any one of claims 1, 2, or 3, wherein executing the MPC algorithm (13) causes to calculate the minimum travel time (tmin) by running the high-level solver module (13.1) in a first iteration, set the control parameter (A) to a minimum value during the first iteration so that the difference (1 - A) between the value one and the control parameter (A) is maximum, calculate the predicted travel time (t_p) by running again the high-level solver module (13.1) in a second iteration, and set the control parameter (A) to a value different from the minimum value during the second iteration, wherein the minimum travel time (tmin) is taken into account when calculating the predicted travel time (t_p).

5. A method according to any one of the preceding claims, wherein the longitudinal model (14) includes a loss model (27), the loss model (27) describes an operational behaviour of the electric vehicle (1) with regard to its loss, resulting in an overall loss of the electric vehicle (1), and executing the MPC algorithm (13) causes to calculate the amount of energy (-E_Bat) to be supplied by the battery (8) of the electric vehicle (1) according to the calculated longitudinal trajectory over the prediction horizon, by taking into account the overall loss of the electric vehicle (1).

6. A method according to any one of the preceding claims, wherein executing the MPC algorithm (13) causes the high-level solver module (13.1) to iteratively re-calculate the longitudinal trajectory (31) every 100 to 1000 milliseconds.

7. Method according to one of the preceding claims, wherein the cost function (15) contains a third term (24) which describes a braking force (F_Br) of a mechanical wheel brake (19) of the electric vehicle (1).

8. A method according to claim 7, wherein the cost function further contains a fourth term (30) describing a kinetic energy (E_km) of the electric vehicle (1), and a fifth term (34) describing a torque (M_Mot) applied by the electric machine (8) for driving the electric vehicle (1).

9. Method according to any one of the preceding claims, wherein 18 executing the MPC algorithm (13) further causes to transfer information about static objects to the high-level solver module (13.1) as constraints that the high-level solver module (13.1) takes into account to calculate the longitudinal trajectory (31).

10. Method according to any one of the preceding claims, wherein executing the MPC algorithm (13) further causes to transfer information about dynamic objects to the high-level solver module (13.1) as constraints that the high-level solver module (13.1) takes into account to calculate the longitudinal trajectory (31).

11. A method according to any one of the preceding claims, wherein the calculated longitudinal trajectory (31) comprises at least one of the following trajectories: a speed trajectory (31.1), according to which the electric vehicle (1) is to travel over the prediction horizon; a state of charge trajectory (31.2) describing an evolution of a state of charge of the battery (9) over the prediction horizon; and a braking force trajectory (31.3) for a braking system (19) of the vehicle (1), for the braking system (19) to apply braking forces over the prediction horizon according to the braking force trajectory (31.3).

12. A computer program product for model-based predictive control of an electric vehicle, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by processing means of the electric vehicle to cause the processing means to perform a method according to any one of the preceding claims.