A power management system and a vehicle

Abstract

A power management system includes a processor configured to: for at least one electronic vehicle component from a plurality of electronic vehicle components of the vehicle: receive component data from at least one component data source; receive vehicle-external data from at least one vehicle-external data source; input the received component data and the received vehicle-external data to a component-specific power consumption model that models the power consumption of the respective component to output a component-specific estimated future power consumption of the respective component; determine a target power state of each component using the estimated future power consumptions of the components; determine a power policy using the target power state of each component, wherein the power policy defines a target operating state for each component, the respective component should transition to; and instruct, in accordance with the power policy, each component to transition to the respective target operating state.

Description

A Power Management System and a VehicleTechnical Field

[0001] Various aspects of this disclosure relate generally to a power management system and a vehicle.Background

[0002] Today's vehicles often have power management systems with static and fixed power management policies set during manufacturing, lacking real-time data integration. This may lead to inaccurate estimations of driving range, as the systems are not designed to adjust to dynamic external conditions or current energy consumption.Brief Description of the Drawings

[0003] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various embodiments of the invention are described with reference to the following drawings, in which:FIG. 1 shows a vehicle in accordance with various aspects of this disclosure;FIG. 2 shows a block diagram illustrating various electronic vehicle components in a vehicle, the vehicle being in communication with a communication network;FIG. 3 shows various data sources and a vehicle state monitor in accordance with various aspects of this disclosure;FIG. 4 shows a high level diagram of an LSTM architecture in accordance with various aspects of this disclosure;FIG. 5 shows a block diagram illustrating a process in accordance with various aspects of this disclosure; andFIG. 6 shows a flow diagram illustrating a method for power management, the method carried out by a processor.Description

[0004] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the invention may be practiced.

[0005] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0006] The word "over" used with regards to a deposited material formed “over” a side or surface, may be used herein to mean that the deposited material may be formed "directly on”, e.g. in direct contact with, the implied side or surface. The word "over" used with regards to a deposited material formed “over” a side or surface, may be used herein to mean that the deposited material may be formed "indirectly on” the implied sideor surface with one or more additional layers being arranged between the implied side or surface and the deposited material.

[0007] The terms “processor” or “controller” as, for example, used herein may be understood as any kind of entity that allows handling data. The data may be handled according to one or more specific functions executed by the processor or controller. Further, a processor or controller as used herein may be understood as any kind of circuit, e.g., any kind of analog or digital circuit. A processor or a controller may thus be or include an analog circuit, digital circuit, mixed-signal circuit, logic circuit, processor, microprocessor, Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), integrated circuit, Application Specific Integrated Circuit (ASIC), etc., or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as a processor, controller, or logic circuit. It is understood that any two (or more) of the processors, controllers, or logic circuits detailed herein may be realized as a single entity with equivalent functionality or the like, and conversely that any single processor, controller, or logic circuit detailed herein may be realized as two (or more) separate entities with equivalent functionality or the like.

[0008] A “vehicle” is to be understood to include any type of driving object and may be a driving object with a combustion engine, an electric driving object, a hybrid driving object, or a combination thereof. A vehicle may be or may include an automobile, a bus, a mini bus, a van, a truck, a mobile home, a vehicle trailer, a motorcycle, a bicycle, a tricycle, a moving robot, a personal transporter, a ship, a drone, an aircraft and the like.

[0009] A “ground vehicle” is to be understood to include any type of vehicle, as described above, which drives on the ground, e.g. on a street or a road. In various aspects of this disclosure, the vehicle may be a ground vehicle (e.g. a partially or completely autonomous vehicle), such as a truck, a car, a motorcycle, and the like.

[0010] The term “autonomous vehicle” refers to a vehicle capable of implementing at least one navigational change without driver input. A navigational change refers to a change in one or more of steering, braking, or acceleration / deceleration of the vehicle. To be autonomous, a vehicle needs not to be fully automatic (for example fully operational without driver or without driver input). An autonomous vehicle may include those that may operate under driver control during certain time periods and without driver control during other time periods. Autonomous vehicles may also include vehicles that control only some aspects of vehicle navigation, such as steering (e.g., to maintain a vehicle course between vehicle lane constraints) or some steering operations under certain circumstances (but not under all circumstances), but may leave other aspects to the driver (e.g., braking or braking under certain circumstances). Autonomous vehicles may also include vehicles that share the control of one or more aspects of vehicle navigation under certain circumstances (e.g., hands-on, such as responsive to a driver input) and vehicles that control one or more aspects of vehicle navigation under certain circumstances (e.g., hands-off, such as independent of driver input). Autonomous vehicles may also include vehicles that control one or more aspects of vehicle navigation under certain circumstances, such as under certain environmental conditions (e.g., spatial areas, roadway conditions). In some aspects, autonomous vehicles may handle some orall aspects of braking, speed control, velocity control, and / or a steering of the vehicle. An autonomous vehicle may include those that may operate without a driver.

[0011] In the context of this disclosure, “vehicle operation data” are understood to mean any type of feature related to the operation of a vehicle, including the status of the vehicle such as the tires of the vehicle, the type of vehicle, the age of the manufacturing of the vehicle, and thus generally static vehicle operation data. However, “vehicle operation data” may also include features changing during the operation of the vehicle, for example environmental conditions, such as weather conditions or road conditions during the operation of the vehicle, and thus generally varying vehicle operation data.

[0012] Various embodiments herein may utilize one or more machine learning models to perform functions of the vehicle (or other functions described herein). The term “model” as, for example, used herein may be understood as any kind of algorithm, which provides output data from input data. A machine learning model may be executed by a computing system to progressively improve performance of a specific task. In some aspects, parameters of a machine learning model may be adjusted during a training phase based on training data and a trained machine learning model may then be used during an inference phase to make predictions or decisions based on input data. In some aspects, the trained machine learning model may be used to generate additional training data and an additional machine learning model may be adjusted during a second training phase based on the generated additional training data. A trained additional machine learning model may then be used during an inference phase to make predictions or decisions based on input data.

[0013] The machine learning models described herein may take any suitable form or utilize any suitable techniques. For example, any of the machine learning models may utilize supervised learning, semi-supervised learning, unsupervised learning, or reinforcement learning techniques.

[0014] In supervised learning, the model may be built using a training set of data that contains both the inputs and corresponding desired outputs. Each training instance may include one or more inputs and a desired output. Training may include iterating through training instances and using an objective function to teach the model to predict the output for new inputs. In semi-supervised learning, a portion of the inputs in the training set may be missing the desired outputs.

[0015] In unsupervised learning, the model may be built from a set of data which contains only inputs and no desired outputs. The unsupervised model may be used to find structure in the data (e.g., grouping or clustering of data points) by discovering patterns in the data. Techniques that may be implemented in an unsupervised learning model include, e.g., self-organizing maps, nearest-neighbor mapping, k-means clustering, and singular value decomposition.

[0016] Reinforcement learning models may be given positive or negative feedback to improve accuracy. A reinforcement learning model may attempt to maximize one or more objectives / rewards. Techniques that may be implemented in a reinforcement learning model may include, e.g., Q-learning, temporal difference (TD), and deep adversarial networks.

[0017] Various embodiments described herein may utilize one or more classification models. In a classification model, the outputs may be restricted to a limited set of values.The classification model may output a class for an input set of one or more input values. An input set may include sensor data, such as image data, radar data, LIDAR data and the like. A classification model as described herein may for example classify certain driving conditions and / or environmental conditions, such as weather conditions, road conditions, and the like. References herein to classification models may contemplate a model that implements, e.g., any one or more of the following techniques: linear classifiers (e.g., logistic regression or naive Bayes classifier), support vector machines, decision trees, boosted trees, random forest, neural networks, or nearest neighbor.

[0018] Various embodiments described herein may utilize one or more regression models. A regression model may output a numerical value from a continuous range based on an input set of one or more values. References herein to regression models may contemplate a model that implements, e.g., any one or more of the following techniques (or other suitable techniques): linear regression, decision trees, random forest, or neural networks.

[0019] A machine learning model described herein may be a neural network. The neural network may be any kind of neural network, such as a convolutional neural network, an autoencoder network, a variational autoencoder network, a sparse autoencoder network, a recurrent neural network, a deconvolutional network, a generative adversarial network, a forward thinking neural network or a sum-product neural network and the like. The neural network may include any number of layers and the training of the neural network, i.e. adapting the layers of the neural network, may be based on any kind of training principle, such as backpropagation, i.e. the backpropagation algorithm.

[0020] Various aspects of this disclosure provide a method for dynamic vehicle power policy optimization through use of vehicle energy consumption demand data.

[0021] Various aspects of this disclosure provide a software (SW) system that monitors and adjusts the power consumption of electronic vehicle components based on a diverse set of data signals used to optimize, over time, the power usage at the vehicle level while ensuring safety and operational conditions. It is to be noted that although various aspects are described as a SW system, various aspects may be implemented as a complete hardware (HW) system or as a hybrid system, i.e. partially as a SW system and partially as a HW system.

[0022] This system may leverage Artificial Intelligence / Machine Learning (AI / ML) algorithms to incorporate diverse data types such as weather, location, user preferences, driving behavior, and vehicle and battery telemetry (as examples of vehicle external data) to define (or amend) a power policy that partially or completely deactivates or operates in an energy saving operation mode, e.g. shutdowns, systems or electronic vehicle components that are not needed to make vehicles more energy efficient.

[0023] Various aspects of this disclosure may enable automotive manufacturers to improve expected vehicle range per battery kWh, as well as improve battery life through a decrease of battery cycle counts over time and reduce the kWh of vehicle battery packs.

[0024] Various aspects of this disclosure provide a method to dynamically optimize a vehicle-platform’s power policy by utilizing different vehicle data sources, such as vehicle telematics data (e.g., speed, battery state of charge, etc.) and external data (e.g., user / vehicle fleet preferences, vehicle location, weather conditions, planned vehicle route,vehicle driving conditions) to continuously identify optimizations for electronic vehicle components’ power states in order to reduce energy consumption at vehicle level.

[0025] FIG. 1 shows a vehicle 100 in accordance with various aspects of this disclosure. The vehicle 100 may include a plurality of electronic devices (which will also be referred to as electronic vehicle components) such as e.g. one or more processors 102 (e.g. integrated with or separate from an engine control unit (ECU) of the vehicle 100) and a plurality of various sensors, e.g. one or more image acquisition devices 104 such as e.g. one or more cameras, a position sensor 106 such as a Global Navigation Satellite System (GNSS), e.g. a Global Positioning System (GPS).

[0026] The vehicle 100 may further include sensors such as e.g. a speed sensor 108 (e.g., a speedometer) for measuring a speed of the vehicle 100. The vehicle 100 may also include one or more accelerometers (either single axis or multiaxial) (not shown) for measuring accelerations of the vehicle 100 along one or more axes. The vehicle 100 may further include additional sensors or different sensor types such as an ultrasonic sensor, a thermal sensor, one or more radar sensors 110, one or more LIDAR sensors 112 (which may be integrated in the head lamps of the vehicle 100), and the like. The radar sensors 110 and / or the LIDAR sensors 112 may be configured to provide pre-processed sensor data, such as radar target lists or LIDAR target lists. It is to be noted that other sensors may also be provided in the vehicle 100. A data interface may couple some or all the sensors of the vehicle 100, such as the sensors mentioned above, to some or all, e.g. to each, of the one or more processors 102.

[0027] The vehicle 100 may further include a plurality of actors such as e.g. a touch screen, a microphone, a loudspeaker, one or more buttons and / or switches, and the like,and one or more (e.g. wireless) transceivers, and / or one or more displays, . The wireless transceivers may be configured to different desired radio communication protocols or standards. By way of example, a first wireless transceiver may be configured in accordance with a short-range mobile radio communication standard such as e.g. Bluetooth, Zigbee, and the like. Furthermore, a second wireless transceiver may be configured in accordance with a Medium or Wide Range mobile radio communication standard such as e.g. a 3G (e.g. Universal Mobile Telecommunications System - UMTS), a 4G (e.g. Long Term Evolution - LTE), or a 5G mobile radio communication standard in accordance with corresponding 3GPP (3rdGeneration Partnership Project) standards. A third wireless transceiver may be configured in accordance with a Wireless Local Area Network communication protocol or standard such as e.g. in accordance with IEEE 802.11 (e.g. 802.11, 802.11a, 802.11b, 802.11g, 802.1 In, 802. l ip, 802.11-12, 802.1 lac, 802.1 lad, 802.1 lah, and the like). The one or more wireless transceivers may be configured to transmit signals via an air interface. The image acquisition devices may each include any type of device suitable for capturing at least one image from an environment of the vehicle 100. Moreover, any number of image acquisition devices 104 may be used to acquire images to input to a processor such as an image processor. All these and other components of the vehicle 100 consume electrical power. Therefore, a power management system may be provided, which is configured to operate (e.g. control the electronic devices) in accordance with one or more dynamic power management policies.

[0028] A conventional vehicle (e.g. an electric vehicle (EV) or an internal combustion engine (ICE) vehicle) does not have dynamic power management policiesimplemented at the vehicle-level - they are often defined by subsystems. Instead, they rely on Smart Driving Modes (e.g., Eco driving mode, Sport driving mode) or on regenerative braking systems to reduce and compensate for energy consumption. In very few cases (e.g., Tesla vehicles), power and battery management for EVs is loosely integrated with mapping services for charging station routing that updates as the vehicle is driving, for example, but it lacks any other real-time contextual data integration, such as weather or vehicle-fleet information. Therefore, there is no solution in the market that addresses power management at the vehicle level in a dynamic manner.

[0029] In various aspects of this disclosure, power management policies are not only defined and designed at sub-system level and are consider the system of systems interactions that a modern vehicle has. This means that benefits from real-time contextual data integration into power management policies at the vehicle level are realized. Various aspects of this disclosure address power consumption management at vehicle level of a vehicle (e.g. an EV or an ICE) and define a method to optimize vehicle power policies based on a full range of data that combines both vehicle-level power consumption data and external data sources such as weather, location, traffic conditions, etc. for a more efficient vehicle. Various aspects of this disclosure may also help Electric Vehicles to be more efficient with a reliable and more accurate battery usage and range estimation.

[0030] FIG. 2 shows a block diagram 200 illustrating various electronic vehicle components in a vehicle (which may include the vehicle electronic components such as e.g. the sensors of vehicle 100 in FIG. 1), e.g. an EV, the vehicle being in communication with a communication network 202.

[0031] Various aspects of this disclosure may use a vehicle-platform power management system which has an architecture that allows a central hub to define specific vehicle component’s power states to save energy. A high-level overview of this vehicleplatform power management system is depicted in the block diagram 200 of FIG. 2. This power management system may provide an interface 204 to provide access to a cloud platform 206 that may provide external data sources 208 used to improve vehicle’s energy consumption. It is to be noted that one or more pre-defined power policies for one or more vehicles (of the same type or of a different type) may be stored in the cloud platform 206 (however, the one or more power policies may also be stored in a memory of the vehicle). Furthermore, various models (e.g. such as one or more models as described above) may also be stored in the cloud platform 206 (however, one or more models may also be stored in a memory of the vehicle). The one or more models may be trained or untrained (which may then be trained (or otherwise amended) by the vehicle during operation of the vehicle). Furthermore, the one or more models, even when already (partially or completely) trained, may be further trained (or otherwise amended) by the vehicle during operation of the vehicle.

[0032] Similarly as with a conventional Personal Computer (PC) where an Operating System (OS) may put devices (e.g., hard disk, network interfaces, peripherals, etc.) to a sleep state when they are not in use or may wake them up via an interruption signal, the vehicle-platform power management system 200 may put vehicle components (e.g., ECUs, sensors, etc.), also referred to as electronic vehicle components, to sleep, completely power them off, throttle down their operating frequency, or wake them up again for user interaction. In other words, the vehicle-platform power managementsystem 200 (e.g. the vehicle 100, e.g. the one or ore processors 102) may be configured to control the operating state of each electronic vehicle component to operate the same in different operating states, wherein respective electronic vehicle component may have a different power consumption in each operating state or at least in some of the operating states.

[0033] FIG. 2 shows various examples of electronic vehicle components 210, 212, 214 such as e.g. one or more engine control units (ECUs) 210, one or more actuators and / or one or more sensors 212 (which may include the sensors 104, 106, 108, 110, 112 of FIG. 1 and other sensors, as desired) or one or more electrification ECUs 214, which may all be coupled to the one or more processors 102, e.g. via a communication connection such as e.g. a vehicle platform communication backbone circuitry 216.

[0034] Various aspects of this disclosure may determine (e.g. define or amend) one or more power policies for the vehicle 100. The one or more power policies dictate target power states (and e.g. the corresponding operating state(s)) of a given electronic vehicle component 210, 212, 214 at a particular point in time. The one or more processors 102 may decide and instruct (and thus control), in accordance with the determined one or more power policies, which electronic vehicle component(s) 210, 212, 214 to power off or on or in which operating state the respective electronic vehicle component should transfer (in other words transition) to. The one or more processors 102 may orchestrate this holistically at vehicle-platform level.

[0035] With this SW (and / or HW) system, a vehicle manufacturer may pre-define one or more power policies that trigger when certain conditions are met to e.g. shut down (for the operation of the vehicle 100) non-essential systems, e.g. one or more non-essential electronic vehicle components 210, 212, 214. For example, during Electric Vehicle (EV) charging, there are some electronic vehicle components 210, 212, 214 that may not be needed, such as Advanced Driver Assistance Systems (ADAS)-related ECUs and sensors. But these pre-defined one or more power policies may not be useful when the operating conditions of the vehicle 100 do not match the ones when the one or more power policies were defined. This may result in inefficiencies that may lead to significant power draining by unnecessary subsystems or electronic vehicle components 210, 212, 214. Therefore, in various aspects of this disclosure, the vehicle 100 may actively monitor and adjust power consumption across different levels of its operational hierarchy. The determined one or more power policies may be dynamic and change over time, adjusting the power states of electronic vehicle components to context changes, user inputs, and / or external factors.

[0036] In order to dynamically define and adjust one or more power policies and electronic vehicle components’ power state(s), data concerning components’ power capabilities and utilization, driver behavior and preferences, and vehicle- external factors form the foundation for insights that provide continual optimization of both power generation and consumption. The one or more processors 102 may be configured to dynamically define and / or adjust one or more power policies and vehicle components' power states (and corresponding operating states). This may involve creating a SW system that may respond (e.g. in real-time) to various inputs and conditions to optimize a vehicle energy usage holistically. Therefore, various aspects of this disclosure may define a series of SW (and / or HW) components that monitor, collect, and aggregate data from multiple data sources. The one or more processors 102 may be configured toimplement (and carry out) an ensemble of algorithms (e.g. implemented as models such as the models as described above) may use data from these data sources with each algorithm (e.g. implemented as model) tailored to forecast energy use patterns of a specific electronic vehicle component or subsystem by utilizing power consumption and contextual data sources. The one or more processors 102 may provide collective insights generated by these algorithms and may use the same to create new or adapt existing one or more power policies at vehicle-level. The one or more power policies illustratively dictate the power states of the electronic vehicle components analyzed, e.g. without compromising safety and utilization while at the same time realizing significant energy savings.

[0037] FIG. 3 shows various data sources 304 and a vehicle state monitor 302 in accordance with various aspects of this disclosure in a further block diagram 300.

[0038] To begin with, e.g. in order to dynamically adapt electronic vehicle components’ power states, the one or more processors 102 may implement the vehicle state monitor 302 (VSM) that may be understood to be a part of a Central Compute’s Central System Power Management (CSPM) (also implemented by the one or more processors 102). The vehicle state monitor 302 may be configured to collect and aggregate data from the different data sources 304. By way of example, the vehicle state monitor 302 may typically use the following data sources (which may be part of or form a “pool”, in other words, of a plurality of data sources) 304:

[0039] One or more of the following component data sources:

[0040] — a data source providing data describing a power consumption of the respective electronic vehicle component 308 (in other words, a data source providing datadescribing vehicle component power consumption - e.g. the current, the voltage, and / or the temperature of a respective electronic vehicle component of the one or more electronic vehicle components);

[0041] a data source providing data describing a battery status 312, in particular a battery cell temperature and / or a battery cell charge level and / or a battery pack’s state of charge and / or a battery charge status and / or a battery discharge status (in other words, battery telemetry data- e.g. battery cells temperature and charge level, battery pack’s state of charge and voltage, battery discharge and charge); and / or

[0042] — a power management descriptor 318 describing an electronic vehicle component power capability and / or an electronic vehicle component power state (in other words one or more power management descriptors - e.g. vehicle component power capabilities, power states, and features.

[0043] One or more of the following vehicle-external data sources:

[0044] — a data source providing data describing vehicle driver behavior data and / or vehicle driver behavior preferences 306, in particular vehicle acceleration, vehicle speed, vehicle jerk (in other words a data source providing data describing driver behavior data and preferences - e.g. vehicle acceleration, vehicle speed, vehicle jerk, and other information related to user driving behavior);

[0045] — a data source providing data describing traffic information and / or charging stations 310, in particular traffic conditions based on the vehicle’s route and location and / or a charging station status (in other words a data source providing data describing traffic and charging stations - e.g. traffic conditions based on the vehicle’s route and location, and charging stations status);

[0046] — a data source providing data describing satellite-based data 314 (e.g.Global Positioning System (GPS) data or Galileo data) about the location of the vehicle;

[0047] — a data source providing data describing weather 314 (e.g. a data source providing data describing vehicle-external temperature and location affecting the vehicle’s environment); and / or

[0048] — a data source providing data describing vehicle fleet data about a plurality of vehicles 316 (in other words a data source providing data describing vehicle fleet data - e.g. power-related data crowdsourced from fleets of vehicles on e.g. a cloud platform).

[0049] Predicting the power consumption of an electronic vehicle component 210, 212, 214 of the vehicle 100 using a diverse set of information involves understanding the complex relationships between these electronic vehicle components 210, 212, 214 and how they impact power usage for a given piece of hardware (HW). Additionally, not all data sources 306, 308, 310, 312, 314, 316, 318 may be available at a given time for a given vehicle 100. Some vehicles may have reduced connectivity capabilities or in- vehicle features that may result in certain real-time information not being available. Therefore, a pre-mapping of data sources 306, 308, 310, 312, 314, 316, 318 may be performed to link data inputs that are relevant for predicting the power usage of a given electronic vehicle component 210, 212, 214. For example, to predict the power consumption of the Heating, Ventilation and Air Conditioning (HVAC) sub-system of the vehicle 100, weather forecast data, vehicle occupancy, and user preferences data may be provided and used along with the current or past system’s power consumption.Moreover, to e.g. predict the power consumption of one or more electric motors of the vehicle 100 (in case the vehicle 100 is an EV), map topology along the vehicle’s route,driving style characterizations, and past energy consumption data collected from a fleet of vehicles that drove the same route may be provided and used along with current motor’s electric current and electric power drawn from a battery of the vehicle 100.

[0050] By way of example, at every time step t, the VSM 302 pulls the data from the multiple data sources 306, 308, 310, 312, 314, 316, 318 available and for each data source 306, 308, 310, 312, 314, 316, 318, it creates a feature vector as follows:

[0051] Let {£>■£, £>2, , DM] represent the M different data sources 306, 308, 310, 312, 314, 316, 318, where each data source Dthas its own dimensionality dt. The feature vector Xj from each data sourcemay be represented as:

[0052] where X! is the feature vector for the i-th data source Di and xtj represents the j-th feature of Xj.

[0053] Then, for each electronic vehicle component or subsystem C, withC = 1, ... , IV, where it is desired to predict its power consumption, the VSM 302 may build a composite vector representation V that combines the subset of features needed as the concatenation of the individual feature vectors.

[0054] To do this, it is provided to define S as the subset of data sources 306, 308, 310, 312, 314, 316, 318 selected from the available M data sources 306, 308, 310, 312, 314, 316, 318,

[0055] Furthermore, various aspects define an indicator function 7(i) that returns “1” if the i-th data source is included in the subset S and “0” otherwise, and will use the same as will be described in more detail below:7(i) = {1 if i S, 0 if i g S }. (2)

[0056] Moreover, the composite vector representation VNthat includes only the feature vectors from the data sources 306, 308, 310, 312, 314, 316, 318 in subsets is defined as the concatenation of the individual feature vectors weighted by the indicator function:

[0057] The one or more processors 102 may be configured to use vector VNas input for the component’s energy modeling (symbolized by block 320 in FIG. 3).

[0058] The component’s energy modeling (CEM), e.g. implemented by the one or more processors 102, will now be described in more detail (block 320 in FIG. 3).

[0059] After the vector representation of the data inputs are identified, different prediction models may be applied that make use of the data inputs relevant to a respective electronic vehicle component 210, 212, 214 to which the SW system is trying to predict its power consumption. These models may range from simple linear regressions to more complex machine learning algorithms, each with varying degrees of sophistication and accuracy. Using an ensemble of algorithms (e.g. models) to predict power consumption of electronic vehicle components 210, 212, 214 or subsystems, while more complex to implement and usually requires expert knowledge to build these models, it may achieve greater accuracy by allowing fine-tuning of the models. This approach also provides more flexibility to introduce system constraints defined by the Original Equipment Manufacturer (OEM) or the electronic vehicle component’s manufacturer, ensuring that the predictions not only reflect real-world usage but also adhere to the specifications and limitations set by the designers of the vehicle electronic system.

[0060] Once the data is collected and aggregated in the previous process, the one or more processors 102 may implement a Component Energy Modeling (CEM) algorithm and may use the same to predict the future power consumption Ycof a given electronic vehicle component C, C = 1, ... , IV, for a given window of time (e.g., in the next one or more seconds, e.g. in the range from about 15 second to about 45 seconds, e.g. about 30 seconds, e.g. in the next one or more minutes, e.g. in the range from about 1 minute to about 10 minutes, e.g. about 5 minutes, or more than about 10 minutes, e.g. in the range from about 15 minutes to about 45 minutes or even more, e.g. about 30 minutes). This parameter (i.e. the window of time) may be adjusted based on current vehicle conditions or pre-defined by a vehicle manufacturer.

[0061] In order to predict future energy consumption, a model architecture like a Long short-term memory (LSTM) network (see e.g. LSTM network 400 as shown in FIG. 4) may be provided as its architecture is suitable to predict time series data. The LSTM architecture 400 may have an input layer 402 designed to accept the specific features relevant to each electronic vehicle component C, VN, one or more hidden layers 404 where the number of LSTM units (neurons) in each layer 402, 404 will depend on the complexity of the electronic vehicle component 210, 212, 214 and the amount of data available, and an output layer 406 with a (e.g. linear) activation function that will predict the energy consumption of electronic vehicle component C 210, 212, 214. A suitable loss function for this network architecture 400 may be the Mean Squared Error, which is suitable to distinguish between the predicted energy consumption and the actual values during a training phase of the LSTM. It is to be noted that this loss function may be used to train also other type of models as described above. Furthermore, it is to be noted thatother loss functions may also be provided. A high level diagram of the LSTM architecture 400 is shown in FIG. 4.

[0062] While each electronic vehicle component C might use different inputs and do the prediction using a different model, all the CEM algorithms will predict the same information - the energy consumption at regular time intervals (e.g., every hour or every 15 minutes or any other desired regular time interval or irregular time intervals) within a future time frame.

[0063] In the case the CEM is implemented by the one or more processors 102 with the LSTM architecture 400, the final output Y (t) of the LSTM 400 at time step t is typically computed using a hidden state htpassed through a fully connected layer with its own weights Wyand bias by, followed by an activation function appropriate for the task (e.g., linear for regression tasks):T(t) = ( / )(Wy■ ht+ by). (4)

[0064] The CEM training and deployment (which may be implemented by the one or more processors 102 or by any other processor) will now be described in more detail:

[0065] Although the specific model architecture selected may differ based on the implementation, supervised learning models may be used to predict the energy consumption of an electronic vehicle component 210, 212, 214. The training process of such a model requires collecting and preparing historical energy consumption data alongside relevant features, such as operating conditions and usage patterns (i.e., the data sources £>i). The data required for training is typically collected from a fleet of vehicles and may be augmented by using simulation models of electronic vehicle components or subsystems. The CEM’s performance is evaluated using a validation setduring training to tune hyperparameters and prevent overfitting and its accuracy is assessed on a separate test set to estimate its performance on new data.

[0066] This training process may be carried out on a vehicle-external platform (e.g., the cloud environment, i.e. the cloud platform 206 from FIG. 2) that has access to data lakes hosting the data and has a mechanism to deploy such model to vehicles via over the air updates. In this way, a baseline model may be built based on fleet data and may be improved over time as the vehicle drives over time and generates more data. However, it is to be noted that the training process may be performed partially or completely by the vehicle 100, e.g. during operation (e.g. driving) of the vehicle 100.

[0067] Referring again to FIG. 3, vehicle topology energy modeling, electronic vehicle component power state definition, and vehicle power policy definition (block 322 in FIG. 3) will now be described in more detail:

[0068] Once the one or more processors 102 have completed to compute the prediction of energy consumption per electronic vehicle component 210, 212, 214, the one or more processors 102 determine and / or use a vehicle topology energy model (not shown in FIG. 4). The vehicle topology energy model may be built by combining a system topology definition (defined e.g. in the CSPM of FIG. 2) that contains information about the electronic vehicle components’ 210, 212, 214 dependencies to other electronic vehicle components 210, 212, 214 or subsystems as well as optionally in addition safety and operational requirements, which may be defined by the electronic vehicle component manufacturer. The vehicle topology energy model identifies power-related dependencies between electronic vehicle components 210, 212, 214 that may dictate specific power requirements, needed to define a desired (target) power state (and correspondingoperating state (also referred to as target operating state), e.g. inactive state, any one of different sleep states with different wake up times and power consumptions, any one of different active operating state with different power consumption) an electronic vehicle component 210, 212, 214 should be in.

[0069] Block 324 in FIG. 3 describes the application of the determined one or more power policies (also referred to as one or more energy management policies), in other words, e.g. the one or more processors 102 may be configured to instruct, in accordance with the one or more power policies, each electronic vehicle component of the plurality of electronic vehicle components 210, 212, 214 to transition to the respective target operating state.

[0070] FIG. 5 depicts an overall flow diagram 500 for a vehicle-platform power policy based on future energy consumption and power-related requirements.

[0071] The one or more processors 102 may be configured to implement the process as a rule-based approach that combines the predicted energy consumption with the electronic vehicle component’s operational requirements and dependencies. This process would ensure that functional safety requirements are met that the component stays within its intended operational conditions.

[0072] For example, the anti-blocking system (ABS) system in a vehicle is a safety- critical feature that under normal driving conditions, e.g. during long periods of steady cruising (e.g., highway driving), may not be actively engaged. Under this condition, the CEM might predict that its energy consumption will be low. However, the ABS has a functional safety requirement to be ready to activate at any moment when needed. This implies that certain electronic vehicle components of the ABS, such as sensors andhydraulic pumps, must remain in a standby state to be capable of fast activation. This situation imposes a condition where the ABS system cannot be completely powered down. On the other hand, if the CEM predicts low usage of the infotainment system - a non-safety critical feature, such as during overnight parking or when the driver of the vehicle is using smartphone integration for navigation and music instead of the built-in system (i.e. electronic vehicle components) of the vehicle, the system (e.g. the one or more processors 102) may decide to power it down or put the infotainment system into a low-power sleep mode to conserve energy.

[0073] By way of example, in 502, data from the various available data sources 306, 308, 310, 312, 314, 316, 318 is collected and the one or more processors 102 may determine, using the respective component-specific model (CEM) 504, 506, 508, the respective future power consumption Yc(e.g. Y , Y2, YN) and may input the same to the vehicle topology energy model 510 as explained above.

[0074] Then, the one or more processors 102 may input the output of the vehicle topology energy model 510 to the determining (in other words defining) of the vehicle component power state (block 512 in FIG. 5). Thus, illustratively, once the one or more processors 102 identify the dependencies between electronic vehicle components 210, 212, 214 (using the vehicle component topology), the one or more processors 102 may determine (in other words defined) a respective optimal power state (and the corresponding operating state) of each electronic vehicle component 210, 212, 214 by taking into account its predicted future power consumption Kw(t), its dependencies, and e.g. the supported vehicle power states (e.g., Normal Operation, Sleep, Deep Sleep, Off), as defined e.g. in the CSPM.

[0075] By determining the target power state for each electronic vehicle component 210, 212, 214 through the predictive modeling and analysis of operational requirements, the one or more processors 102 may construct (in other words determine) or amend (e.g. adjust) the one or more (vehicle) power policies to realize energy savings (block 514 in FIG. 5). The one or more power policies are constructed by defining the power states the vehicle components should transition to, based on the vehicle power-topology. Once a power policy is defined, the central compute (e.g. the one or more processors 102) may then communicate with the vehicle subsystems (i.e. the electronic vehicle components 210, 212, 214) to carry out the power state transitions. To achieve this, in-vehicle software mechanisms are provided across electronic vehicle components (e.g., ADAS ECU, HVAC ECU) that are able to realize the power directives mandated by the central compute (e.g. the one or more processors 102). This creates a continuous optimization feedback loop within the vehicle's platform, enabling real-time energy conservation and extending the vehicle's battery life by ensuring that components are only fully powered when necessary and otherwise maintained in energy-saving states.

[0076] FIG. 6 shows a flow diagram illustrating a method 600 for power management, the method carried out by a processor, e.g. by the one or more processors 102. The method 600 may include, in 602, for at least one, e.g. for a plurality of, e.g. for each electronic vehicle component of a vehicle from a plurality of electronic vehicle components 210, 212, 214 of the vehicle 100: receiving 604 component data from at least one component data source; receiving 606 vehicle-external data from at least one vehicleexternal data source; inputting 608 the received component data and the received vehicleexternal data to a component-specific power consumption model that models the powerconsumption of the respective electronic vehicle component to output a componentspecific estimated future power consumption of the respective electronic vehicle component. The method 600 may further include, in 610, determining a target power state of each electronic vehicle component using the estimated future power consumptions of the plurality of electronic vehicle components, and, in 612, determining a power policy using the target power state of each electronic vehicle component, wherein the power policy defines a target operating state for each electronic vehicle component of the plurality of electronic vehicle components, the respective electronic vehicle component should transition to. The method 600 may further include, in 614, instructing, in accordance with the power policy, each electronic vehicle component of the plurality of electronic vehicle components to transition to the respective target operating state.

[0077] In the following, various aspects of this disclosure will be illustrated:

[0078] Example 1 is a power management system. The power management system may include a memory; and a processor coupled to the memory, the processor configured to: for at least one, e.g. for a plurality of, e.g. for each electronic vehicle component of a vehicle from a plurality of electronic vehicle components of the vehicle: receive component data from at least one component data source; receive vehicle-external data from at least one vehicle-external data source; input the received component data and the received vehicle-external data to a component-specific power consumption model that models the power consumption of the respective electronic vehicle component to output a component-specific estimated future power consumption of the respective electronic vehicle component. The processor may further be configured to determine a target powerstate of each electronic vehicle component using the estimated future power consumptions of the plurality of electronic vehicle components, and to determine a power policy using the target power state of each electronic vehicle component, wherein the power policy defines a target operating state for each electronic vehicle component of the plurality of electronic vehicle components, the respective electronic vehicle component should transition to, and to instruct, in accordance with the power policy, each electronic vehicle component of the plurality of electronic vehicle components to transition to the respective target operating state.

[0079] In Example 2, the subject matter of Example 1 may optionally include that the processor is further configured to select at least one available component data source as the at least one component data source from a plurality of component data sources predefined for the respective electronic vehicle component, each component data source associated with an electronic vehicle component, each component data source providing data associated with the electronic vehicle component.

[0080] In Example 3, the subject matter of any one of Examples 1 or 2 may optionally include that the processor is further configured to select at least one vehicleexternal data source as the at least one vehicle-external data source from a plurality of vehicle-external data sources predefined for the respective electronic vehicle component, each vehicle-external data source providing data related to a driving-related information associated the vehicle.

[0081] In Example 4, the subject matter of any one of Examples 1 to 3 may optionally include that the processor is further configured to implement each component-specific power consumption model using a model trained to predict an energy consumption pattern of the respective electronic vehicle component.

[0082] In Example 5, the subject matter of any one of Examples 1 to 4 may optionally include that the processor is further configured to determine the power policy by newly determining the power policy or by amending a stored power policy.

[0083] In Example 6, the subject matter of any one of Examples 1 to 4 may optionally include that the processor is further configured to determine the power policy by amending a stored power policy during a driving of the vehicle.

[0084] In Example 7, the subject matter of any one of Examples 1 to 6 may optionally include that the at least one component data source is a component data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing a power consumption of the respective electronic vehicle component; a data source providing data describing a battery status, in particular a battery cell temperature and / or a battery cell charge level and / or a battery pack’s state of charge and / or a battery charge status and / or a battery discharge status; and a power management descriptor describing an electronic vehicle component power capability and / or an electronic vehicle component power state.

[0085] In Example 8, the subject matter of any one of Examples 1 to 7 may optionally include that the at least one vehicle-external data source is a vehicle-external data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing vehicle driver behavior data and / or vehicle driver behavior preferences, in particular vehicle acceleration, vehicle speed, vehicle jerk; a data source providing data describing traffic information and / orcharging stations, in particular traffic conditions based on the vehicle’s route and location and / or a charging station status; a data source providing data describing satellite-based data about the location of the vehicle; a data source providing data describing weather; and a data source providing data describing vehicle fleet data about a plurality of vehicles.

[0086] In Example 9, the subject matter of any one of Examples 1 to 8 may optionally include that the processor is further configured to output the componentspecific estimated future power consumption of the respective electronic vehicle component as an estimate for a predefined time frame.

[0087] In Example 10, the subject matter of any one of Examples 1 to 9 may optionally include that the processor is further configured to determine the target power state of each electronic vehicle component using a predefined vehicle component topology that comprises information about dependencies between at least some of the electronic vehicle components of the plurality of electronic vehicle components.

[0088] In Example 11, the subject matter of Example 10 may optionally include that the processor is further configured to determine the target power state of each electronic vehicle component further using safety requirements regarding the respective electronic vehicle component.

[0089] In Example 12, the subject matter of any one of Examples 10 or 11 may optionally include that the processor is further configured to determine the target power state of each electronic vehicle component using operational requirements regarding the respective electronic vehicle component.

[0090] In Example 13, the subject matter of any one of Examples 1 to 12 may optionally include that the processor is further configured to determine the target power state of each electronic vehicle component using a rule-based system.

[0091] In Example 14, the subject matter of any one of Examples 1 to 13 may optionally include that the processor is further configured to determine the power policy using a plurality of predefined available vehicle power states of the vehicle.

[0092] In Example 15, the subject matter of any one of Examples 1 to 14 may optionally include that the processor configured to instruct the each electronic vehicle component comprises the processor configured to control the each electronic vehicle component to transition to the respective target operating state.

[0093] Example 16 is a vehicle. The vehicle may include a power management system of any one of Examples 1 to 15, and the plurality of electronic vehicle components.

[0094] Example 17 is a method for power management. The method is carried out by a processor. The method may include for at least one, e.g. for a plurality of, e.g. for each electronic vehicle component of a vehicle from a plurality of electronic vehicle components of the vehicle: receiving component data from at least one component data source; receiving vehicle-external data from at least one vehicle- external data source; inputting the received component data and the received vehicle-external data to a component-specific power consumption model that models the power consumption of the respective electronic vehicle component to output a component-specific estimated future power consumption of the respective electronic vehicle component. The method may further include determining a target power state of each electronic vehicle componentusing the estimated future power consumptions of the plurality of electronic vehicle components; determining a power policy using the target power state of each electronic vehicle component, wherein the power policy defines a target operating state for each electronic vehicle component of the plurality of electronic vehicle components, the respective electronic vehicle component should transition to; and instructing, in accordance with the power policy, each electronic vehicle component of the plurality of electronic vehicle components to transition to the respective target operating state.

[0095] In Example 18, the subject matter of Example 17 may optionally include that the method further includes selecting at least one available component data source as the at least one component data source from a plurality of component data sources predefined for the respective electronic vehicle component, each component data source associated with an electronic vehicle component, each component data source providing data associated with the electronic vehicle component.

[0096] In Example 19, the subject matter of any one of Examples 17 or 18 may optionally include that the method further includes selecting at least one vehicle-external data source as the at least one vehicle-external data source from a plurality of vehicleexternal data sources predefined for the respective electronic vehicle component, each vehicle-external data source providing data related to a driving -related information associated the vehicle.

[0097] In Example 20, the subject matter of any one of Examples 17 to 19 may optionally include that each component-specific power consumption model is implemented using a model trained to predict an energy consumption pattern of the respective electronic vehicle component.

[0098] In Example 21, the subject matter of any one of Examples 17 to 20 may optionally include that the power policy is determined by newly determining the power policy or by amending a stored power policy.

[0099] In Example 22, the subject matter of any one of Examples 17 to 21 may optionally include that the power policy is determined by amending a stored power policy during a driving of the vehicle.

[0100] In Example 23, the subject matter of any one of Examples 17 to 22 may optionally include that the at least one component data source is a component data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing a power consumption of the respective electronic vehicle component; a data source providing data describing a battery status, in particular a battery cell temperature and / or a battery cell charge level and / or a battery pack’s state of charge and / or a battery charge status and / or a battery discharge status; and a power management descriptor describing an electronic vehicle component power capability and / or an electronic vehicle component power state.

[0101] In Example 24, the subject matter of any one of Examples 17 to 23 may optionally include that the at least one vehicle-external data source is a vehicle-external data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing vehicle driver behavior data and / or vehicle driver behavior preferences, in particular vehicle acceleration, vehicle speed, vehicle jerk; a data source providing data describing traffic information and / or charging stations, in particular traffic conditions based on the vehicle’s route and location and / or a charging station status; a data source providing data describing satellite-baseddata about the location of the vehicle; a data source providing data describing weather; and a data source providing data describing vehicle fleet data about a plurality of vehicles.

[0102] In Example 25, the subject matter of any one of Examples 17 to 24 may optionally include that the component-specific estimated future power consumption of the respective electronic vehicle component is output as an estimate for a predefined time frame.

[0103] In Example 26, the subject matter of any one of Examples 17 to 25 may optionally include that the target power state of each electronic vehicle component is determined using a predefined vehicle component topology that comprises information about dependencies between at least some of the electronic vehicle components of the plurality of electronic vehicle components.

[0104] In Example 27, the subject matter of Example 26 may optionally include that the target power state of each electronic vehicle component is determined further using safety requirements regarding the respective electronic vehicle component.

[0105] In Example 28, the subject matter of any one of Examples 26 or 27 may optionally include that the target power state of each electronic vehicle component is determined using operational requirements regarding the respective electronic vehicle component.

[0106] In Example 29, the subject matter of any one of Examples 17 to 28 may optionally include that the target power state of each electronic vehicle component is determined using a rule-based system.

[0107] In Example 30, the subject matter of any one of Examples 17 to 29 may optionally include that the power policy is determined using a plurality of predefined available vehicle power states of the vehicle.

[0108] In Example 31, the subject matter of any one of Examples 17 to 30 may optionally include that the method further includes controlling the plurality of electronic vehicle components.

[0109] Example 32 is a computer readable medium, storing instructions which, when executed by a processor, implement a method for power management of any one of Examples 17 to 31.

[0110] Example 33 is a power management system. The power management system may include: for at least one, e.g. for a plurality of, e.g. for each electronic vehicle component of a vehicle from a plurality of electronic vehicle components of the vehicle: means for receiving component data from at least one component data source; means for receiving vehicle-external data from at least one vehicle-external data source; means for inputting the received component data and the received vehicle-external data to a component-specific power consumption model that models the power consumption of the respective electronic vehicle component to a means for outputting a component-specific estimated future power consumption of the respective electronic vehicle component. The power management system may further include means for determining a target power state of each electronic vehicle component using the estimated future power consumptions of the plurality of electronic vehicle components; means for determining a power policy using the target power state of each electronic vehicle component, wherein the power policy defines a target operating state for each electronic vehicle component ofthe plurality of electronic vehicle components, the respective electronic vehicle component should transition to; and means for instructing, in accordance with the power policy, each electronic vehicle component of the plurality of electronic vehicle components to transition to the respective target operating state.

[0111] In Example 34, the subject matter of Example 33 may optionally include that the power management system further includes means for selecting at least one available component data source as the at least one component data source from a plurality of component data sources predefined for the respective electronic vehicle component, each component data source associated with an electronic vehicle component, each component data source providing data associated with the electronic vehicle component.

[0112] In Example 35, the subject matter of any one of Examples 33 or 34 may optionally include that the power management system further includes means for selecting at least one vehicle-external data source as the at least one vehicle-external data source from a plurality of vehicle-external data sources predefined for the respective electronic vehicle component, each vehicle-external data source providing data related to a driving-related information associated the vehicle.

[0113] In Example 36, the subject matter of any one of Examples 33 to 35 may optionally include that each means for component-specific power consumption model is implemented using a model trained to predict an energy consumption pattern of the respective electronic vehicle component.

[0114] In Example 37, the subject matter of any one of Examples 33 to 36 may optionally include that the means for determining the power policy comprise means for newly determining the power policy or by amending a stored power policy.

[0115] In Example 38, the subject matter of any one of Examples 33 to 37 may optionally include that the means for determining the power policy comprise means for amending a stored power policy during a driving of the vehicle.

[0116] In Example 39, the subject matter of any one of Examples 33 to 38 may optionally include that the at least one component data source is a component data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing a power consumption of the respective electronic vehicle component; a data source providing data describing a battery status, in particular a battery cell temperature and / or a battery cell charge level and / or a battery pack’s state of charge and / or a battery charge status and / or a battery discharge status; and a power management descriptor describing an electronic vehicle component power capability and / or an electronic vehicle component power state.

[0117] In Example 40, the subject matter of any one of Examples 33 to 39 may optionally include that the at least one vehicle-external data source is a vehicle-external data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing vehicle driver behavior data and / or vehicle driver behavior preferences, in particular vehicle acceleration, vehicle speed, vehicle jerk; a data source providing data describing traffic information and / or charging stations, in particular traffic conditions based on the vehicle’s route and location and / or a charging station status; a data source providing data describing satellite-based data about the location of the vehicle; a data source providing data describing weather; and a data source providing data describing vehicle fleet data about a plurality of vehicles.

[0118] In Example 41, the subject matter of any one of Examples 33 to 40 may optionally include that the means for outputting the component-specific estimated future power consumption of the respective electronic vehicle component output the component-specific estimated future power consumption as an estimate for a predefined time frame.

[0119] In Example 42, the subject matter of any one of Examples 33 to 41 may optionally include that the means for determining the target power state of each electronic vehicle component use a predefined vehicle component topology that comprises information about dependencies between at least some of the electronic vehicle components of the plurality of electronic vehicle components.

[0120] In Example 43, the subject matter of Example 42 may optionally include that the means for determining the target power state of each electronic vehicle component further use safety requirements regarding the respective electronic vehicle component.

[0121] In Example 44, the subject matter of any one of Examples 42 or 43 may optionally include that the means for determining the target power state of each electronic vehicle component use operational requirements regarding the respective electronic vehicle component.

[0122] In Example 45, the subject matter of any one of Examples 33 to 44 may optionally include that the means for determining the target power state of each electronic vehicle component use a rule-based system.

[0123] In Example 46, the subject matter of any one of Examples 33 to 45 may optionally include that the means for determining the power policy use a plurality of predefined available vehicle power states of the vehicle.

[0124] In Example 47, the subject matter of any one of Examples 33 to 46 may optionally include that the power management system further includes means for controlling the plurality of electronic vehicle components.

[0125] While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

ClaimsWhat is claimed is:

1. A power management system, comprising: a memory; and a processor coupled to the memory, the processor configured to: for at least one electronic vehicle component of a vehicle from a plurality of electronic vehicle components of the vehicle: receive component data from at least one component data source; receive vehicle-external data from at least one vehicle-external data source; input the received component data and the received vehicle-external data to a component-specific power consumption model that models the power consumption of the respective electronic vehicle component to output a component-specific estimated future power consumption of the respective electronic vehicle component; determine a target power state of each electronic vehicle component using the estimated future power consumptions of the plurality of electronic vehicle components; determine a power policy using the target power state of each electronic vehicle component, wherein the power policy defines a target operating state for each electronic vehicle component of the plurality of electronic vehicle components, the respective electronic vehicle component should transition to; andinstruct, in accordance with the power policy, each electronic vehicle component of the plurality of electronic vehicle components to transition to the respective target operating state.

2. The power management system of claim 1, wherein the processor is further configured to select at least one available component data source as the at least one component data source from a plurality of component data sources predefined for the respective electronic vehicle component, each component data source associated with an electronic vehicle component, each component data source providing data associated with the electronic vehicle component.

3. The power management system of any one of claims 1 or 2, wherein the processor is further configured to select at least one vehicle-external data source as the at least one vehicle- external data source from a plurality of vehicle-external data sources predefined for the respective electronic vehicle component, each vehicle-external data source providing data related to a driving- related information associated the vehicle.

4. The power management system of any one of claims 1 or 2, wherein the processor is further configured to implement each component-specific power consumption model using a model trained to predict an energy consumption pattern of the respective electronic vehicle component.

5. The power management system of any one of claims 1 or 2, wherein the processor is further configured to determine the power policy by newly determining the power policy or by amending a stored power policy.

6. The power management system of any one of claims 1 or 2, wherein the processor is further configured to determine the power policy by amending a stored power policy during a driving of the vehicle.

7. The power management system of any one of claims 1 or 2, wherein the at least one component data source is a component data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing a power consumption of the respective electronic vehicle component; a data source providing data describing a battery status, in particular a battery cell temperature and / or a battery cell charge level and / or a battery pack’s state of charge and / or a battery charge status and / or a battery discharge status; and a power management descriptor describing an electronic vehicle component power capability and / or an electronic vehicle component power state.

8. The power management system of any one of claims 1 or 2,wherein the at least one vehicle-external data source is a vehicle-external data source selected from a group of data sources consisting of one or more of the following data sources: a data source providing data describing vehicle driver behavior data and / or vehicle driver behavior preferences, in particular vehicle acceleration, vehicle speed, vehicle jerk; a data source providing data describing traffic information and / or charging stations, in particular traffic conditions based on the vehicle’s route and location and / or a charging station status; a data source providing data describing satellite-based data of the location of the vehicle; a data source providing data describing weather; and a data source providing data describing vehicle fleet data of a plurality of vehicles.

9. The power management system of any one of claims 1 or 2, wherein the processor is further configured to output the component-specific estimated future power consumption of the respective electronic vehicle component as an estimate for a predefined time frame.

10. The power management system of any one of claims 1 or 2, wherein the processor is further configured to determine the target power state of each electronic vehicle component using a predefined vehicle component topologythat comprises information about dependencies between at least some of the electronic vehicle components of the plurality of electronic vehicle components.

11. The power management system of claim 10, wherein the processor is further configured to determine the target power state of each electronic vehicle component further using safety requirements regarding the respective electronic vehicle component.

12. The power management system of any one of claims 10 or 11, wherein the processor is further configured to determine the target power state of each electronic vehicle component using operational requirements regarding the respective electronic vehicle component.

13. The power management system of any one of claims 1 or 2, wherein the processor is further configured to determine the target power state of each electronic vehicle component using a rule-based system.

14. The power management system of any one of claims 1 or 2, wherein the processor is further configured to determine the power policy using a plurality of predefined available vehicle power states of the vehicle.

15. The power management system of any one of claims 1 or 2, wherein the processor configured to instruct the each electronic vehicle component comprises theprocessor configured to control the each electronic vehicle component to transition to the respective target operating state.

16. A vehicle, comprising: a power management system of any one of claims 1 or 2, and the plurality of electronic vehicle components.

Images