Battery power budget allocation for vehicle ECMs implemented in IoT ecosystems

Abstract

An Internet of Things (IoT) ecosystem includes an electronic control module (ECM) implemented in a vehicle and configured to perform specialized functions of features of the IoT ecosystem, where the IoT ecosystem includes IoT devices, and an IoT controller configured to obtain context data and assign at least one battery power budget for the ECM and a corresponding one of the specialized functions based on the context data. At least a portion of the context data is received from the IoT devices and the ECM. The ECM is configured to implement the specialized functions based on the at least one battery power budget.

Description

[0001] introduce

[0002] The information provided in this section is for the purpose of generally presenting the context of this disclosure. Within the scope described in this section, the work of the currently named inventors and aspects of this description that might not otherwise conform to the prior art at the time of filing are neither expressly nor implicitly acknowledged as prior art relative to this disclosure.

[0003] This disclosure relates to the Internet of Things (IoT) ecosystem and vehicle and battery power budget allocation systems.

[0004] A home (or residential) ecosystem is an interconnected network of smart devices and can include a central hub and multiple IoT devices that communicate wirelessly with the hub. An example of a home ecosystem is Amazon. Apple and Google IoT devices can include smart speakers, appliances, smart plugs, smart lights, smart switches, and more. Users can control the status of IoT devices via a central hub or via ecosystem applications running on, for example, mobile phones. Summary of the Invention

[0005] An Internet of Things (IoT) ecosystem is disclosed, comprising: an electronic control module (ECM) implemented in a vehicle and configured to perform dedicated functions characteristic of the IoT ecosystem, wherein the IoT ecosystem includes IoT devices; and an IoT controller configured to: acquire context data and allocate at least one battery power budget for a corresponding dedicated function in the ECM and the dedicated functions based on the context data. At least a portion of the context data is received from the IoT devices and the ECM. The ECM is configured to implement the dedicated functions based on the at least one battery power budget.

[0006] Among other features, the IoT controller is implemented in vehicles, portable access devices, charging stations, building central hubs, or in IoT devices separate from vehicles.

[0007] Among other features, the IoT controller is configured to provide a recommended battery power budget in the ECM, and to receive an acceptance or rejection response from the ECM for the recommended battery power budget from the IoT controller.

[0008] Among other features, one of the ECMs is configured to perform at least one of the following: i) request additional battery power relative to the recommended battery power in the recommended battery power budget for one of the ECMs, and ii) negotiate the battery power budget for one of the ECMs with the other ECMs in the ECMs.

[0009] Among other features, the IoT controller is configured to allocate a battery power budget to one of the ECMs. The ECM is configured to determine whether to accept or change the allocated battery power budget for that ECM.

[0010] Among other features, the IoT controller is configured to implement a battery power budgeting process that includes allocating a total battery power budget to the vehicle's ECMs and providing the total battery power budget to one of the ECMs. One of the ECMs is configured to determine a battery power budget for the remaining ECMs based on the total battery power budget.

[0011] Among other features, the IoT controller is configured to: monitor changes in events using the ECM; determine whether the change in events necessitates at least one of the following: i) updating the total battery power budget, and ii) adjusting one or more battery power budgets of the ECM; collect updated context data; and in response to determining that it is necessary to update the total battery power budget or to adjust the one or more battery power budgets, collect updated context data, and based on the updated context data, update at least one of the following: the updated total battery power budget, and the one or more battery power budgets.

[0012] Among other features, the IoT controller or ECM is configured to: monitor attributes of a dedicated function used to determine key performance indicators (KPIs); calculate the KPI for each of these attributes; determine whether the KPI score is equal to a threshold or a detected anomaly; store the KPI score in a KPI confidence rating matrix in response to the KPI score being equal to the threshold or a detected anomaly; determine whether to adjust at least one battery power budget for one or more of the features and dedicated functions in response to the determination to make an adjustment; and adjust the at least one battery power budget in response to the determination to make an adjustment.

[0013] Among other features, the IoT controller or ECM is configured to: monitor key performance indicator (KPI) anomalies of attributes of dedicated functions; calculate anomaly scores; determine whether one of the anomaly scores is greater than a threshold; and if it is greater than the threshold, perform at least one of the following: i) stop execution of at least one of the features and functions associated with the one of the anomaly scores that is greater than the threshold, and ii) disengage one of the ECMs associated with the one of the anomaly scores that is greater than the threshold.

[0014] Among other features, the IoT controller or ECM is configured to: queue features based on an activity schedule; map features to the ECM based on at least one battery power budget; determine if multiple features are requested; if multiple features are requested, perform a pre-tuning evaluation of the features relative to ecosystem resources; and run a conflict procedure to determine the execution order of the requested features.

[0015] Among other features, at least some of the IoT devices are located in or attached to a building.

[0016] Among other features, a method for allocating battery power to a vehicle ECM in an IoT ecosystem. The method includes: acquiring context data at an IoT controller; allocating at least one battery power budget to a corresponding function in the ECM and a dedicated function based on the context data, wherein the dedicated function is a feature of the IoT ecosystem, and wherein at least a portion of the context data is received from IoT devices and the ECM in the IoT ecosystem; and implementing the dedicated function via the ECM based on the at least one battery power budget.

[0017] Among other features, the IoT controller is implemented in vehicles, portable access devices, charging stations, building central hubs, or in IoT devices separate from vehicles.

[0018] Among other features, the method further includes: recommending a battery power budget for one of the ECMs via an IoT controller, and receiving an acceptance or rejection response from one of the ECMs for the recommended battery power budget from the IoT controller.

[0019] Among other features, the method further includes: allocating a battery power budget to one of the ECMs via an IoT controller; and determining via the ECM whether to accept or change the allocated battery power budget to one of the ECMs.

[0020] Among other features, the method further includes: implementing a battery power budgeting process via an IoT controller, the process including allocating a total battery power budget to the vehicle and providing the total battery power budget to one of the ECMs; and determining a battery power budget for the remaining ECMs in the ECMs based on the total battery power budget via one of the ECMs.

[0021] Among other features, the method further includes: monitoring changes in events using the ECM; determining whether the change in events necessitates at least one of the following: i) updating the total battery power budget, and ii) adjusting one or more battery power budgets of the ECM; collecting updated contextual data; collecting updated contextual data in response to determining that it is necessary to update the total battery power budget or to adjust the one or more battery power budgets; and updating at least one of the following based on the updated contextual data: the updated total battery power budget, and the one or more battery power budgets.

[0022] Among other features, the method further includes: monitoring attributes of a dedicated function used to determine key performance indicators (KPIs); calculating a KPI for each of these attributes; determining whether a KPI score equals a threshold or is a detected anomaly; storing the KPI score in a KPI confidence rating matrix in response to a KPI score equaling a threshold or a detected anomaly; determining whether to adjust at least one battery power budget for one or more of the features and dedicated functions in response to the determination to make an adjustment; and adjusting the at least one battery power budget in response to the determination to make an adjustment.

[0023] Among other features, the features further include: monitoring key performance indicators (KPIs) anomalies of attributes of dedicated functions; calculating anomaly scores; determining whether one of the anomaly scores is greater than a threshold; and if it is greater than the threshold, performing at least one of the following: i) stopping the execution of at least one of the features and functions associated with the one of the anomaly scores that is greater than the threshold, and ii) deactivating one of the ECMs associated with the one of the anomaly scores that is greater than the threshold.

[0024] Among other features, the method further includes: queuing features based on an activity schedule; mapping features to an ECM based on at least one battery power budget; determining whether multiple features have been requested; if multiple features have been requested, performing a pre-tuning evaluation of the features relative to ecosystem resources; and running a conflict procedure to determine the execution order of the requested features.

[0025] Further applications of this disclosure will become apparent from the detailed description, claims, and drawings. The detailed description and specific examples are intended for illustrative purposes only and are not intended to limit the scope of this disclosure.

[0026] This disclosure provides the following examples:

[0027] Example 1. An Internet of Things (IoT) ecosystem, comprising:

[0028] Multiple electronic control modules (ECMs) implemented in the vehicle and configured to perform dedicated functions characteristic of the IoT ecosystem, which includes multiple IoT devices; and

[0029] An IoT controller is configured to acquire context data and allocate at least one battery power budget based on the context data for corresponding dedicated functions among the plurality of ECMs and the dedicated functions, wherein at least a portion of the context data is received from the plurality of IoT devices and the plurality of ECMs.

[0030] The plurality of ECMs are configured to implement the dedicated functions based on the power budget of the at least one battery.

[0031] Example 2. According to the IoT ecosystem described in Example 1, wherein the IoT controller is implemented in the central hub of the vehicle, portable access device, charging station, building, or in an IoT device separate from the vehicle.

[0032] Example 3. According to the IoT ecosystem described in Example 1, wherein the IoT controller is configured to recommend a battery power budget for one of the plurality of ECMs, and to receive an acceptance or rejection response from the one of the plurality of ECMs for the recommended battery power budget from the IoT controller.

[0033] Example 4. According to the IoT ecosystem described in Example 3, the one of the plurality of ECMs is configured to perform at least one of the following: i) request additional battery power relative to the battery power recommended in the recommended battery power budget for the one of the plurality of ECMs, and ii) negotiate the battery power budget for the one of the plurality of ECMs with the other ECMs.

[0034] Example 5. Based on the IoT ecosystem described in Example 1, wherein:

[0035] The IoT controller is configured to allocate the battery power budget to one of the plurality of ECMs; and

[0036] The plurality of ECMs are configured to determine whether to accept or change the allocated battery power budget for one of the plurality of ECMs.

[0037] Example 6. The IoT ecosystem described in Example 1, wherein:

[0038] The IoT controller is configured to implement a battery power budgeting process, which includes allocating a total battery power budget to the plurality of ECMs of the vehicle and providing the total battery power budget to one of the plurality of ECMs; and

[0039] One of the plurality of ECMs is configured to determine the battery power budget for the remaining ECMs among the plurality of ECMs based on the total battery power budget.

[0040] Example 7. According to the IoT ecosystem described in Example 1, wherein the IoT controller is configured to:

[0041] Utilize the aforementioned multiple ECMs to monitor changes in events;

[0042] Determine whether the change in the event makes it necessary to: i) update the total battery power budget, and ii) adjust one or more battery power budgets of the plurality of ECMs;

[0043] Collect updated context data; and

[0044] In response to determining that it is necessary to update the total battery power budget or to adjust one or more battery power budgets, updated context data is collected, and based on the updated context data, at least one of the following is updated: the total battery power budget and the one or more battery power budgets.

[0045] Example 8. According to the IoT ecosystem described in Example 1, wherein the IoT controller or the plurality of ECMs are configured to:

[0046] Monitor the attributes of the dedicated function used to determine key performance indicators (KPIs);

[0047] Calculate the KPI for each of the attributes;

[0048] Determine whether the KPI score equals the threshold or is a detected anomaly;

[0049] In response to the KPI score being equal to the threshold or an anomaly being detected, the KPI score is stored in the KPI confidence rating matrix;

[0050] In response to the KPI score not being equal to the threshold and not being an anomaly, determine whether to adjust at least one battery power budget for one or more of the feature and the dedicated function; and

[0051] In response to determining to make an adjustment, the power budget of the at least one battery is adjusted.

[0052] Example 9. According to the IoT ecosystem described in Example 1, wherein the IoT controller or the plurality of ECMs are configured to:

[0053] Monitor for anomalies in the key performance indicators (KPIs) of the attributes of the dedicated function;

[0054] Calculate the anomaly score;

[0055] Determine whether one of the abnormal scores is greater than a threshold; and

[0056] If the score is greater than the threshold, then at least one of the following is performed: i) stop executing at least one of the features and functions associated with one of the abnormal scores that are greater than the threshold, and ii) deactivate one of the plurality of ECMs associated with one of the abnormal scores that are greater than the threshold.

[0057] Example 10. According to the IoT ecosystem described in Example 1, wherein the IoT controller or the plurality of ECMs are configured to:

[0058] The features are queued based on the activity scheduling table;

[0059] The features are mapped to the plurality of ECMs based on the at least one battery power budget;

[0060] Determine if multiple features were requested;

[0061] If multiple features are requested, a pre-adjustment evaluation of the features relative to ecosystem resources is performed; and

[0062] Run the conflict procedure to determine the execution order of the requested features.

[0063] Example 11. An IoT ecosystem according to Example 1, wherein at least some of the IoT devices are located in or attached to a building.

[0064] Example 12. A method for distributing battery power to multiple electronic control modules (ECMs) of a vehicle in an Internet of Things (IoT) ecosystem, the method comprising:

[0065] Acquire context data at the IoT controller, and based on the context data, allocate at least one battery power budget for a corresponding dedicated function among the plurality of ECMs and dedicated functions, wherein the dedicated function is a feature characteristic of the IoT ecosystem, and wherein at least a portion of the context data is received from the plurality of IoT devices and the plurality of ECMs in the IoT ecosystem; and

[0066] The dedicated function is implemented via the plurality of ECMs based on the power budget of the at least one battery.

[0067] Example 13. The method according to Example 12, wherein the IoT controller is implemented in the vehicle, portable access device, charging station, building central hub or in an IoT device separate from the vehicle.

[0068] Example 14. The method according to Example 12 further includes: recommending a battery power budget for one of the plurality of ECMs via the IoT controller, and receiving an acceptance or rejection response from the one of the plurality of ECMs for the recommended battery power budget from the IoT controller.

[0069] Example 15. The method described in Example 12 further includes:

[0070] The battery power budget is allocated to one of the multiple ECMs via the IoT controller; and

[0071] Through the plurality of ECMs, determine whether to accept or change the battery power budget allocated to one of the plurality of ECMs.

[0072] Example 16. The method according to Example 12 further includes:

[0073] The battery power budgeting process is implemented via the IoT controller, the battery power budgeting process including allocating a total battery power budget to the vehicle and providing the total battery power budget to one of the plurality of ECMs; and

[0074] The battery power budget is determined for the remaining ECMs among the plurality of ECMs based on the total battery power budget via one of the ECMs.

[0075] Example 17. The method described in Example 12 further includes:

[0076] Utilize the aforementioned multiple ECMs to monitor changes in events;

[0077] Determine whether the change in the event makes it necessary to: i) update the total battery power budget, and ii) adjust one or more battery power budgets of the plurality of ECMs;

[0078] Collect updated context data;

[0079] In response to determining that it is necessary to update the total battery power budget or to adjust one or more battery power budgets, updated contextual data is collected; and

[0080] Based on the updated context data, update at least one of the following: the updated total battery power budget, and the one or more battery power budgets.

[0081] Example 18. The method according to Example 12 further includes:

[0082] Monitor the attributes of the dedicated function used to determine key performance indicators (KPIs);

[0083] Calculate the KPI for each of the attributes;

[0084] Determine whether the KPI score equals the threshold or is a detected anomaly;

[0085] In response to the KPI score being equal to the threshold or an anomaly being detected, the KPI score is stored in the KPI confidence rating matrix;

[0086] In response to the KPI score not being equal to the threshold and not being an anomaly, determine whether to adjust at least one battery power budget for one or more of the feature and the dedicated function; and

[0087] In response to determining to make an adjustment, the power budget of the at least one battery is adjusted.

[0088] Example 19. The method according to Example 12 further includes:

[0089] Monitor for anomalies in the key performance indicators (KPIs) of the attributes of the dedicated function;

[0090] Calculate the anomaly score;

[0091] Determine whether one of the abnormal scores is greater than a threshold; and

[0092] If the score is greater than the threshold, then at least one of the following is performed: i) stop executing at least one of the features and functions associated with one of the abnormal scores that are greater than the threshold, and ii) deactivate one of the plurality of ECMs associated with one of the abnormal scores that are greater than the threshold.

[0093] Example 20. The method according to Example 12 further includes:

[0094] The features are queued based on the activity scheduling table;

[0095] The features are mapped to the plurality of ECMs based on the at least one battery power budget;

[0096] Determine if multiple features were requested;

[0097] If multiple features are requested, a pre-adjustment evaluation of the features relative to ecosystem resources is performed; and

[0098] Run the conflict procedure to determine the execution order of the requested features. Attached Figure Description

[0099] This disclosure will be more fully understood based on the detailed description and accompanying drawings, in which:

[0100] Figure 1 This is a functional block diagram of an example IoT ecosystem, including vehicles and IoT controllers, based on this disclosure;

[0101] Figure 2 This is a functional block diagram of an IoT ecosystem as part of an embodiment of the present disclosure, the IoT ecosystem including an IoT controller and a vehicle, the IoT controller being implemented separately from the vehicle, the vehicle including a main electronic control module (ECM) and a secondary ECM;

[0102] Figure 3 This is a functional block diagram of an IoT ecosystem as part of an embodiment of the present disclosure, the IoT ecosystem including an IoT controller and a vehicle, the IoT controller being separate from the vehicle, the vehicle including multiple ECMs;

[0103] Figure 4 This is a functional block diagram of an IoT ecosystem as part of an embodiment of the present disclosure, which includes an example vehicle having an IoT controller and multiple ECMs;

[0104] Figure 5 This is a functional block diagram of an example vehicle according to an embodiment of the present disclosure, the example vehicle including an IoT controller or main ECM and multiple other ECMs;

[0105] Figure 6A and Figure 6B (Collectively referred to as FIG6) illustrates a centralized method for allocating battery power budget according to an embodiment of the present disclosure;

[0106] Figure 7 The illustration depicts a decentralized method for allocating battery power budgets according to embodiments of the present disclosure;

[0107] Figure 8 The illustration depicts a decentralized method for deactivating ECM and / or one or more features and / or corresponding functions according to embodiments of the present disclosure; and

[0108] Figure 9The illustration depicts a decentralized method according to embodiments of the present disclosure for mapping features to ECMs, performing pre-tuning evaluation of features, and resolving conflicts between features and / or ECMs.

[0109] In the accompanying drawings, reference numerals may be used repeatedly to identify similar and / or identical elements. Detailed Implementation

[0110] Vehicles can be part of a home IoT ecosystem (or smart home ecosystem) and / or other IoT ecosystems (e.g., IoT ecosystems in commercial locations, airports, etc.). Vehicles can play a vital role in the connected home experience and can be one of the most frequently used smart devices in an individual's daily life. Both home IoT devices and vehicles can utilize features that require vehicle connectivity. As a few examples, features can include an individual's scheduled event calendar, emergency call and tracking features, security monitoring and alarm features, etc. Home IoT devices and vehicles benefit from vehicle connectivity to share feature information and / or perform feature-related functions. When a vehicle is at home (parked and turned off), its ability to remain connected to the home ecosystem and share feature information and perform feature-related functions may be limited. This may be due to the number of ECMs involved and the corresponding vehicle systems and / or the state of charge of low-voltage and high-voltage batteries and / or battery packs within the vehicle.

[0111] Examples described in this article include systems and methods for managing battery power consumption of the ECM and corresponding vehicle systems during vehicle shutdown. When the vehicle is off, the powertrain is not engaged, the vehicle ignition (if equipped) is off, one or more vehicle motors are de-energized, the infotainment system is off, and exterior and interior lighting is typically off. While in the off state, the vehicle operates in connected mode and performs battery management operations. By remaining in connected mode, the time required for wake-up and re-establishment of connections is avoided, resulting in less latency in performing operations.

[0112] When in connected mode, one or more communication links have been established between: i) one or more ECMs, telematics modules, and / or IoT controllers of the vehicle, and ii) a cloud-based server, such as a back-end server. The back-end could be the back-end of a service provider (e.g., the vehicle manufacturer). The back-end could also communicate with a central hub and / or IoT controller of a building IoT ecosystem (such as a home or office IoT ecosystem, an airport IoT ecosystem, or other facility IoT ecosystems).

[0113] Battery power management includes managing the battery power consumption limits for each ECM in the vehicle during the off state. A vehicle can have dozens of ECMs (e.g., 50-100 ECMs). Each ECM can be implemented as part of a corresponding vehicle system (such as an electric motor control system, engine control system, transmission control system, infotainment system, telematics system, collision avoidance system, braking system, steering system, etc.) and controls the operations performed by that corresponding vehicle system.

[0114] Examples in this article include the use of an IoT controller, which can be inside or outside the vehicle. The IoT controller collects contextual data and, based on this contextual data, allocates an amount (or a corresponding percentage) of the battery power budget to each ECM. Contextual data refers to a specific dataset used within a given context of the algorithm. As examples, contextual data can refer to: i) data indicating whether the vehicle is plugged into a charger to charge the vehicle battery, ii) data indicating the availability of access to an electronic calendar, iii) data indicating the availability of access to a user's location, such as via cellular devices, iv) data indicating the vehicle's scheduled trips, v) the time up to when an event (such as a dinner event) occurs, vi) holiday and / or travel dates, and so on.

[0115] In one embodiment, the IoT controller determines how to utilize the allocated amount of battery power budget. In another embodiment, each ECM determines how to utilize the allocated amount. For each implemented feature, the IoT controller or the corresponding ECM determines how to utilize the allocated amount. As used herein, the term "feature" can refer to a device, component, and / or technical element that contributes to vehicle functionality, vehicle safety, and / or the user experience of the vehicle. A function can refer to the operational and performance capabilities of a given feature implemented by the vehicle for the user. As used herein, an attribute can refer to a parameter used, calculated, and / or output from a particular function. An example of a feature is an emergency call made by the vehicle to a cloud-based server in the event of a collision. This feature is implemented by multiple ECMs of the vehicle. The ECMs operate to collect data and then make a call to the cloud-based server to upload the data. As another example, a feature can refer to a safety monitoring mode when the vehicle is off. The vehicle can perform many features that require connectivity, such as checking the vehicle's charging status, remotely communicating with the vehicle to turn on or start the heater, lock the doors, close the windows, turn the lights on or off, etc. These features can be derived from, for example, a central hub (examples of which are...). Figure 1 (As shown in the image), triggered by portable access devices, vehicles, charging stations, or other devices.

[0116] The examples disclosed herein include a method for dynamically allocating, monitoring, increasing, and limiting the battery power budget allocated to each ECM of a vehicle based on contextual data that is not traditionally available to vehicles. The battery power budget of an ECM can refer to the amount of charge of one or more batteries and / or battery packs that the ECM can use when the vehicle is off and in connected mode. These examples enable additional features on the vehicle to be implemented when the vehicle is off, while still meeting the minimum number of days required for the vehicle to remain off and in connected mode without the vehicle batteries being recharged. Vehicles with internal combustion engines may have a first required number of days (e.g., 14 days) to remain off and in connected mode, while electric vehicles (EVs) may have a second required number of days (e.g., 40 days). After the required number of days, the ability to connect and / or perform certain functions may cease if one or more batteries of the vehicle are not charged. The required number of days is based on the vehicle's maximum charging capacity, whether the vehicle has one or more high-voltage battery packs (e.g., battery packs operating at 100-800V) or only low-voltage batteries (e.g., 12V or 48V batteries). Vehicles with higher maximum charging capacity typically have higher days requirements. Battery budget management and battery budget allocation for each ECM are based on pre-estimated demand and battery state of charge for each ECM. The contextual data mentioned above can be correlated with a time frame shorter than the minimum number of days required for the vehicle to remain off and in connected mode without the battery being recharged.

[0117] These examples allow for dynamic determination of battery power budget allocation based on access to an increasing amount of contextual data available to each IoT device, whether inside or outside the vehicle. IoT devices in a home environment can access a variety of information and controls for controlling the device. As an example, information may include details and / or controls associated with EV chargers, electronic calendars, and mobile devices (e.g., portable access devices such as mobile phones, tablets, wearable devices such as smartwatches, etc.).

[0118] Battery power budget allocation and limiting can be determined and implemented inside or outside the vehicle. Centralized and decentralized approaches are disclosed. The battery power budget for the functions of an ECM or ECM can be provided as power over a set time period and / or in milliampere-hours (mAh). Minimum and maximum battery power budgets can be provided for each ECM and / or the functions performed by each ECM. As an example, the disclosed centralized approach includes an IoT controller that collects information from all relevant connected devices within the ecosystem and from the vehicle ECM. The IoT controller allocates a battery power budget for each vehicle ECM based on the power requirements of the devices in the vehicle's ecosystem and the collected contextual data. The IoT controller ensures that operations performed during shutdown continue. In one embodiment, the IoT controller enables and / or triggers charging, disables unwanted functions, and limits the power consumption of selected ECMs in the vehicle ECM to allow the selected features to continue consuming power and remain active. The IoT controller can take precedence over a central hub in a home or facility (e.g., which is disabled and / or has its charging delayed due to the time of day associated with peak power consumption). If the IoT controller determines that the vehicle battery needs to be charged to remain in connected mode and / or be able to perform certain functions, then the IoT controller may take precedence over a central hub that requests that charging be disabled.

[0119] In one embodiment, and if the IoT controller is located outside the vehicle, the IoT controller instructs one or more ECMs in the vehicle to report the power needs of other ECMs in the vehicle to the IoT controller. Along with the power needs of each ECM, the one or more ECMs may also indicate why the requested power is needed and which features the requested power will support. The reporting may be periodic or occur when certain conditions are met. In one embodiment, the IoT controller configures the reporting frequency from the ECMs to further conserve battery consumption. The earlier the event occurs, the more frequent (or higher) the reporting.

[0120] As an example, the disclosed decentralized approach involves the IoT controller and ECM determining the battery power budget. These determinations are not performed by a single controller as in centralized approaches. The vehicle ECM, or a subset of ECMs, makes some battery power budget decisions independently (i.e., without instructions from another ECM or IoT controller). In embodiments, the ECM makes decisions to manage its battery power budget based on internal logic when context data is shared with the ECM and / or when the ECM determines that more power should be reserved for higher-priority functions performed by the ECM. The IoT controller can share context data with the ECM to aid in the decision-making process performed internally by the ECM. For example, the IoT controller can share with the ECM that the charger is plugged in and can be turned on if the battery is low. As another example, the IoT controller can share the driver's schedule or the time of the next scheduled trip. The vehicle ECM can use this information to manage its own battery budget consumption.

[0121] Figure 1 An IoT ecosystem 100 is illustrated, comprising a vehicle 102, a portable access device 104, a charging station 106, a building 108, and a cloud-based server 110 and an IoT controller 112. The IoT controller 112 can be implemented in the vehicle 102, the portable access device 104, the charging station 106, the building 108, a building's central hub 114, or elsewhere. When implemented in a vehicle, the IoT controller can be implemented separately from the telematics module 120 and can be separate from or implemented as part of one of the ECMs 116. When implemented in the portable access device 104, the IoT controller can be separate from or integrated as part of the control module 130. When implemented in the charging station 106, the IoT controller can be separate from or integrated as part of the charging control module 136. When implemented in a building, the IoT controller can be implemented as part of the central hub 114. The IoT controller performs the operations described above and other operations disclosed below to manage the battery power budget, which may include setting battery power budget limits for the ECM 116 of vehicle 102. Regarding Figure 2-9 Other example ECMs are referenced and described. Other examples that could be included in the IoT ecosystem are... Figure 2-5 As shown in the image.

[0122] Vehicle 102 includes an ECM 116, a telematics module 120, a power supply 122, and a charging system 124. Portable access device 104 may be a mobile phone, tablet, wearable device (e.g., a smartwatch), key fob, etc., and includes a control module 130, a memory 132, and a transceiver 134. Charging station 106 includes a charging control module 136, a charger 138, and a transceiver 140. Building 108 includes a central hub 114, an IoT device 142, and a modem 143 (e.g., a Wi-Fi modem). TM Modem and transceiver 144. Building 108 can be a residential, commercial, or other building. Cloud-based server 110 includes server control module 146, memory 148, and transceiver 150.

[0123] The IoT controller 112 can communicate with the vehicle 102, portable access device 104, charging station 106, and / or building 108 via a cloud-based server 110 and / or via one or more other cloud-based servers and / or via a distributed network. The IoT controller 112 can also communicate with the vehicle 102, portable access device 104, charging station 106, and / or building 108 via a modem 143 and the cloud-based server 110. This communication may include radio frequency (RF) signals, Wi-Fi, etc. TM Signals, Local Area Network (LAN) signals, Thread signals, Signal, Transmission and reception of Bluetooth Low Energy (BLE) signals, Ultra Wideband (UWB) signals, etc. Wi-Fi TM The use of signals minimizes the communication time between the IoT controller 112 and the vehicle 102, portable access device 104, charging station 106, and / or building 108, which reduces the power consumption associated with this communication. Wi-Fi TM The communication is faster and cheaper than, for example, cellular communication. This communication allows vehicle 102 to perform more operations when it is off and in connected mode. When IoT controller 112 is part of the vehicle, it can communicate with modem 143 and / or transceiver 150 via telematics module 120 and cloud-based server 110. When IoT controller 112 is implemented as part of portable access device 104, it can communicate with modem 143 and / or transceiver 150 via transceiver 134 and cloud-based server 110. When IoT controller 112 is implemented as part of charging station 106, it can communicate with modem 143 and / or transceiver 150 via transceiver 140 and cloud-based server 110.

[0124] Charging stations (or vehicle chargers) can be installed in buildings, on building walls, or as standalone charging stations near buildings. Central hub 114 can be a home (or residential) hub, a commercial building hub, or other central hubs with a corresponding ecosystem including IoT device 142. IoT device 142 may include speakers, Wi-Fi... TM Compatible devices include appliances (e.g., refrigerators, washing machines, dryers, ovens, etc.), lights, light bulbs, plugs, switches, buttons, etc. IoT devices refer to devices that can connect to the internet and share data.

[0125] IoT Ecosystem 100 can implement protocols for the home ecosystem, such as Amazon. ecosystem, Apple ecosystem and / or Google Ecosystem protocols. The central hub 114 and IoT device 142 can be configured to operate and communicate according to one of these ecosystems. The central hub 114 can communicate with a cloud-based server (as associated with one of these ecosystems).

[0126] Figure 2 A portion 200 of an IoT ecosystem is illustrated, comprising an IoT controller 202 and a vehicle 204. The IoT controller 202 is implemented separately from the vehicle 204, which includes a main electronic control module (ECM) 206 and a secondary ECM 208. The main ECU 206 communicates with the IoT controller 202 via a cloud-based server 210. The IoT controller 202 may be implemented at a device 212, such as a building central hub, portable access device, charging station, etc. The IoT controller 202 can make battery power budget decisions and provide those decisions directly or indirectly to the main ECM 206. The main ECM 206 can then make battery power budget decisions relative to ECM 208. The main ECM 206 can generate a battery power budget for ECM 208. This can include the battery power budget for the functionality of each or some of the ECMs 208. One or more of the ECMs 208 can generate a battery power budget for the functionality of that one or more ECMs. In one embodiment, the main ECM 206 also operates as a telematics module. In another embodiment, the main ECM 206 also operates as a vehicle control module.

[0127] Figure 3 A portion 300 of an IoT ecosystem is shown, comprising an IoT controller 302 and a vehicle 304, with the IoT controller 302 separate from the vehicle 304, which includes multiple ECMs 306. Although Figure 3 The main ECM is not shown, but vehicle 304 may include, for example, Figure 2 The main ECM is shown. The IoT controller 302 can be implemented at a device 312, such as a building's central hub, portable access device, charging station, etc. The IoT controller 302 can make battery power budget decisions and provide those decisions directly or indirectly to the ECM 306 via a cloud-based server 314. A corresponding battery power budget can be allocated to each of the ECMs 306, either i) allocating a portion of the battery power budget to the functions implemented by that ECM based on the allocation provided from the IoT controller 302, or ii) determining a portion of the battery power budget to allocate to the functions implemented by that ECM separately without receiving an allocation from the IoT controller 302. The allocation can be determined based on the amount of time the ECM is off, when the next trip of the vehicle 304 is expected, when the next charging event is expected, etc. Therefore, battery power budgets can be set and adjusted at both the ECM and functional levels.

[0128] Figure 4 A portion 400 of an IoT ecosystem is shown, which includes an example vehicle 402 having an IoT controller 404 and multiple ECMs 406. The IoT controller can communicate directly or indirectly with a cloud-based server 408.

[0129] Figure 5 A host vehicle 500 is shown, including a battery power management system 501, which may include an IoT controller or a main ECM 502 and multiple other ECMs 503. ECMs 503 may include the main ECM. Although shown as a separate ECM, ECMs 503 can be implemented as part of the host vehicle 500's system, such as those mentioned below. Figure 5 This is part of any system shown herein. The IoT controller or main ECM 502 may operate in the same or similar manner as any of the IoT controllers and main ECMs mentioned herein.

[0130] The main vehicle 500 can represent Figure 1-4 The vehicle 500 is any one of vehicles 102, 204, 304, and 402. Vehicle 500 includes an infotainment module 507 and a telematics module 508, each of which can be implemented as one of an ECM 503. The ECM 503 can be implemented as an access module, a vehicle control module, a braking control module, a steering control module, etc. The host vehicle 500 can be a partially or fully autonomous vehicle, a vehicle with assisted driving capabilities, or a non-autonomous vehicle.

[0131] The host vehicle 500 further includes one or more power sources 509 and a propulsion system 510. The vehicle control module can control the operation of the host vehicle 500, including the propulsion system 510 and other systems described below. The power source 509 may include one or more batteries and / or battery packs, a generator, a converter, control circuitry, terminals for high-voltage and low-voltage loads, and one or more battery sensors 512 for detecting the state of the power source 509 (including voltage, current levels, state of charge, etc.). A charging system 511 may be included to charge the power source 509. As mentioned herein, the charging system 511 may be plugged into a building charging station and / or a charger.

[0132] The telematics module 508 provides wireless communication services within the main vehicle 500 and communicates wirelessly with secure access devices, service providers, network devices (e.g., cloud-based network devices, central office devices, and / or back-end devices), other vehicles, mobile devices, infrastructure devices, and other devices external to and / or internal to the main vehicle 500. The telematics module 508 can support... BLE, UWB, Near Field Communication (NFC), Cellular Networks, Legacy (LG) Transmission Control Protocol (TCP), Long Term Evolution (LTE) and / or other wireless communications, and / or according to The telematics module 508 may operate using BLE, UWB, NFC, cellular networks, and / or other wireless communication protocols. The telematics module 508 may include one or more transceivers 513 and a navigation module 514 with a Global Positioning System (GPS) and GNSS (or Global Navigation Satellite System) receiver 516. The navigation module 514 may include an inertial measurement unit (IMU) 517 and an odometer / wheel sensor 519. The transceivers 513 communicate wirelessly with network devices inside and outside the host vehicle 402, including cloud-based network devices, central stations, back-end systems, and portable network devices. The transceivers 513 may perform pattern recognition, channel addressing, channel access control, and filtering operations.

[0133] Navigation module 514 executes a navigation application to provide navigation services. The navigation services may include location identification services to identify where the host vehicle 500 is located. The navigation services may also include guiding the driver and / or directing the host vehicle 500 to a selected location. Navigation module 514 may communicate with a central station to collect map information indicating traffic flow levels, traffic object identification and location (e.g., the location and type of signs), route information, weather information, etc. As an example, if the host vehicle 500 is an assisted and / or automated driving vehicle, navigation module 514 may guide vehicle control module 506 along a selected route to a selected destination. GPS and GNSS receiver 516 may provide: location information; speed and / or direction (or heading) of the host vehicle 500, other vehicles and objects (e.g., pedestrians and cyclists); and / or global clock timing information.

[0134] Includes one or more HUDs (also known as augmented reality (AR) HUDs) 521, and may include one or more HUD control modules (one HUD control module 523 is shown). HUD control module 523 communicates with module 506 and can display information about devices within the building and ecosystem, such as the status of secure access devices and IoT devices. This can include the status of these devices (e.g., on, off, locked, unlocked, turned on, closed, etc.).

[0135] The infotainment module 507 may include and / or be connected to an audio system 522 and / or a video system, which includes one or more displays. Displays 520, 521 and the audio system 522 may be part of a human-machine interface. Displays 520, 521 may include instrument panel and / or center console displays, etc. In addition to displays 520, 521 and the audio system 522, haptic devices (e.g., steering wheel and / or seat vibration devices) may be used to interact with vehicle occupants such as drivers or passengers. This interaction will be further described below. Messages may be displayed, audibly played, and / or indicated via displays 520, 521, the audio system 522, haptic devices, and / or via one or more other output devices.

[0136] The infotainment module 507 can provide various information, including the aforementioned device information, warnings, and proactive messages, such as: status information; routing information; whether driving operations are autonomously controlled, restricted, and / or prevented; gear shifter status; upcoming and currently performed operations (e.g., braking, acceleration, steering); detected objects (or obstacles); vehicle status information; diagnostic information; predictive information; entertainment features and information; and so on. The infotainment module 507 can be used to guide the vehicle operator to a location, indicate trip estimates (e.g., distance to a selected destination), and other information.

[0137] The propulsion system 510 may include one or more torque sources, such as one or more electric motors and / or one or more engines (e.g., internal combustion engines). Figure 1 In the example shown, the host vehicle 500 includes an engine 530 and one or more electric motors 532. The torque sources are controlled independently. The propulsion system 510 includes a motor control system 534, which includes one or more electric motors 532 and a motor control module 536, which can control the operation of one or more electric motors 532 based on signals from a vehicle control module. The propulsion system 510 may include a gear selector and / or shifter 535 for setting the gear of the transmission 537 and / or for setting the drive state of one or more of the torque sources. The gear selector and / or shifter 535 may be an electronic selector (e.g., one or more electrical switches), a mechanical and / or electrical shifter, or other selector and / or shifter. The propulsion system 510 may be controlled based on the position of an accelerator 539 (e.g., accelerator pedal, throttle body, etc.).

[0138] ECM 503 and modules 507, 508, and 523 can communicate with each other directly or indirectly via one or more buses 540 (such as a Controller Area Network (CAN) bus and / or other suitable interfaces). The vehicle control module can control the operation of vehicle modules, devices, and systems based on feedback from sensors 550 and information and / or instructions received from cloud-based network devices.

[0139] Sensor 550 may include external sensor 552, internal sensor 554, and other sensors 556. External sensor 552 may include radar and / or lidar sensor 558 and imaging and audio devices (e.g., visible spectrum camera, long-wave infrared camera, short-wave infrared camera, ambient light sensor, and microphone or microphone array) 560. External sensor 552 may be used to detect objects outside the host vehicle 500 and / or in the path of the host vehicle 500. These objects may include lane markings and objects, other vehicles, pedestrians, cyclists, etc. External sensor 552 may include sensors for determining the position and / or range of vehicle 500 relative to objects and / or devices.

[0140] Internal sensor 554 may include one or more internal imaging sensors (e.g., cameras) 563 and microphones or microphone arrays 564. Internal sensor 554 may be part of a driver monitoring system (DMS). Camera 563 may be used to detect, track, and / or monitor vehicle occupants, including detecting the position of vehicle occupants in the vehicle, anatomical features of vehicle occupants (e.g., face, arms, hands, legs, etc.), head position, and / or eyes, etc. Internal sensor 554 may be used to detect the gaze direction of the driver and / or vehicle occupants. Internal sensor 554 may include door sensors, seat belt sensors, seat sensors, etc. Door sensors may indicate whether a door is open or closed. Seat belt sensors may indicate whether a seat belt is fastened. Seat sensors may include, for example, load sensors, strain gauges, and / or piezoresistive or piezoelectric sensors to detect whether an occupant is in a particular seat and the occupant's weight.

[0141] Other sensors 556 may include, as shown, a gear selector and / or shifter sensor 567, a vehicle speed sensor 566, an acceleration sensor (e.g., longitudinal and lateral acceleration sensors) 568, and a fuel level sensor 570, as well as other sensors. Additional sensors may also be included, such as brake system sensors (brake sensor 579 is shown) and steering system sensors (steering angle sensor 581 is shown). The gear selector and / or shifter sensor 567 generates a signal indicating the state of the gear selector and / or shifter 535.

[0142] The vehicle control module may further include a mode selection module and a parameter adjustment module. The parameter adjustment module can be used to adjust the parameters of the host vehicle 500. The vehicle control module can perform autonomous operation based on interaction with the vehicle occupants. As an example, the vehicle control module can operate in fully or partially autonomous mode and can control the propulsion system 510, braking system 576, and steering system 578. In one embodiment, the vehicle control module controls the operation of system 510, 576, and 578 based on or without interaction with the vehicle occupants. The vehicle control module can i) perform autonomous operations such as steering, braking, acceleration, etc., and / or ii) display and / or audibly play messages, perform tactile operations via tactile devices, and / or output messages and / or corresponding signals via other output devices.

[0143] The host vehicle 500 may further include a memory 580. The memory 580 may store sensor data 582, parameters 584, applications 586, algorithms 588, historical data 590, on-board inputs 591, off-board inputs 592 from other devices outside the host vehicle 500, and ECM battery power budgets and limits 593. Sensor data and parameters may include the location of security access devices, the location of mobile access devices, the location of the host vehicle, occupant location, occupant weight, occupant heart rate, the location of the host vehicle and other vehicles, vehicle speed, vehicle acceleration, battery charge status, fuel level, etc. Applications 586 may include applications executed by modules 507, 508, and ECM 503. An ECM battery power budget and one or more limits may be stored for each ECM 503. The ECM battery power budget and one or more limits may be used for a set time period. If the ECM battery power budget is used within the set time period, the function of that ECM may be limited or stopped until additional power is reallocated to the ECM and / or a new ECM battery power budget is allocated to the ECM.

[0144] Although the memory 580 and the vehicle control module are shown as separate devices, they can be implemented as a single device. The memory 580 may also store historical data 590 and other data, such as driver driving modes, driver refueling modes, driver parking modes, typical work schedules, typical driving schedules, upcoming events, other driver modes, data collected and / or generated by at least one of modules 507, 508 and ECM 503, traffic data, navigation data, map data, GPS / GNSS data, route data, speed data, and acceleration data, etc.

[0145] The vehicle control module can control the operation of the following items based on parameters set by modules 507, 508, and ECM 503: propulsion system 510, video system (including displays 520, 521), audio system 522, haptic devices, braking system 576, steering system 578, seat system 596, and / or other devices and systems. Seat system 596 may include seat sensor 597 for detecting the presence and / or changes in occupants, such as changes in driver position. Vehicle control module 506 can set at least some of the parameters based on signals received from sensor 550.

[0146] The vehicle control module 506 can receive power from the power source 509, which can be supplied to the propulsion system 510, braking system 576, steering system 578, seat system 596, etc. The power supplied to the haptic device, motor 532, braking system 576, steering system 578, seat system 596, and / or their actuators can be controlled by the vehicle control module to adjust, for example: motor speed, torque, and / or acceleration; braking pressure; steering wheel angle; pedal position; the state of the haptic device; etc. This control can be based on the outputs of sensors 550, navigation module 514, GPS and GNSS receiver 516, data and information received from external devices, and data and information stored in memory 580.

[0147] The vehicle control module 506 can determine various parameters, including vehicle speed, motor speed, gear status, accelerator position, brake pedal position, amount of regenerative (charging) power, amount of power automatically started / stopped from discharging, and / or other information. The vehicle control module can control the operation of system 510, 576, and 578 based on these parameters. The vehicle control module can also display vehicle status information based on these parameters.

[0148] The host vehicle 500 may include various systems for assisting the driver, for performing autonomous operations, and / or for instructing vehicle occupants on information about the host vehicle's environment. For example, the host system may include a navigation system that provides map information indicating lane boundaries, street locations, speed limits, the geographic location of the selected destination, etc. The host system may provide the driver with instructions to drive to the selected destination and / or may perform autonomous operations based on map information, such as braking, steering, and acceleration, to drive the vehicle to the destination.

[0149] As another example, the host vehicle 500 may include an object detection and collision warning system for detecting approaching objects and executing countermeasures and / or taking evasive actions to prevent a collision. The vehicle control module determines the position of the object relative to the host vehicle 500 and the trajectories of the object and the host vehicle 500. If it is determined that the host vehicle 500 may collide with one of the objects, one or more warning signals may be generated to indicate a potential collision to the driver and / or the object of concern. These warnings may be provided in addition to the digital approaches and other information described herein. The vehicle control module 506 may also, or alternatively, execute one or more other countermeasures (e.g., applying brakes to decelerate the host vehicle, changing the steering angle of the host vehicle, etc.) to prevent a collision.

[0150] In one embodiment, as described above Figure 1-5 The IoT controller mentioned above allocates and / or recommends battery power budgets for one or more ECMs in the vehicle. The one or more ECMs then accept, reject, change, and / or negotiate updated battery power budgets for themselves. The agreed battery power budget for each ECM is determined by exchanging signals; this negotiation can occur between two or more ECMs without involving the IoT controller. The one or more ECMs can request additional battery power compared to the battery power recommended by the IoT controller. The request for additional battery power can be i) provided to the IoT controller, which can then determine whether to allocate additional battery power and send one or more updated battery power budgets to the one or more ECMs, or it can be provided to one or more other ECMs to initiate negotiation between the ECMs. Battery power budget decisions for ECMs can be made by: the IoT controller; and IoT devices detached from the vehicle where the ECMs reside, such as... Figure 1 One of the IoT devices 142 in the vehicle; the vehicle's main ECM; or the vehicle's secondary ECM. In one embodiment, the battery power budget of the one or more ECMs is determined independently of the IoT controller.

[0151] The following methods can be used by Figure 1-5 This is implemented through the system within the framework.

[0152] Figure 6A and Figure 6B (Collectively referred to as Figure 6) illustrates a centralized approach to battery power budget allocation for the vehicle's ECM. During this centralized approach, the IoT controller (e.g., Figure 1-5One of the IoT controllers in the system can communicate with an ECM. In one embodiment, the IoT controller communicates with an ECM, and that ECM then makes battery power budget decisions for the other ECMs in the vehicle. The IoT controller can periodically receive context data updates at a predetermined frequency based on when the next vehicle driving event is expected to occur. The closer the time to the next vehicle driving event, the more frequent the context updates. The following operations can be performed iteratively.

[0153] At 600, the first ECM of the host vehicle determines whether the host vehicle is in a connected mode used for communication with the IoT controller and / or a cloud-based server. In one embodiment, the first ECM is the master ECM. If so, operation 602 is performed.

[0154] At 602, the first ECM determines whether the host vehicle's telematics module is connected to the IoT controller. If not, operation 604 is executed; otherwise, operation 606 is executed.

[0155] At 604, the first ECM selects the default battery power budget allocation, which can be stored in memory (e.g., ...). Figure 5 In the memory of 580).

[0156] At 606, the first ECM performs a battery power budget allocation process, which may include the following operations: 608, 610, 612, 614, 616.

[0157] At point 608, the IoT controller and / or the first ECM determines and / or acquires updated contextual information (or data), including battery level information, whether the vehicle is connected to a charger, information about when the vehicle's next trip or driving event will occur, and / or other contextual information. In one embodiment, the IoT controller determines this information and shares it with the first ECM.

[0158] At 610, based on contextual information, the IoT controller and / or the first ECM allocates a battery power budget to the vehicle ECM, which is part of the IoT controller's ecosystem. In one embodiment, the IoT controller allocates the battery power budget and provides it to the first ECM, which then shares the battery power budget with other ECMs. In another embodiment, the IoT controller determines the vehicle's total battery power budget and shares this total battery power budget with the first ECM, which then determines its own battery power budget and that of other ECMs based on the total battery power budget. As described below with respect to operation 616, operation 610 may consider received additional battery power budget requests.

[0159] At point 612, the IoT controller and / or the first ECM monitors one or more changes in the event, such as changes in the function performed, changes in the charging state of the vehicle battery, updates to context information, updates on when the next driving event or power-on event of the vehicle will occur, etc.

[0160] At 614, the IoT controller and / or the first ECM determines whether one or more changes in the event necessitate battery power budget adjustments. If so, operation 608 can be performed; otherwise, operation 616 can be performed.

[0161] At 616, the IoT controller and / or the first ECM determines whether there is any additional battery power budget request, such as a second ECM requesting additional power to continue an operation and / or a currently running process. If so, operation 608 can be performed; otherwise, the method can terminate. The request can be sent from the second ECM to the first ECM, which can then relay the request to the IoT controller or determine an updated budget. This may include reducing the budget of one or more other ECMs to account for the additional power requested by the second ECM.

[0162] In one embodiment, the following are performed simultaneously and / or sequentially. Figure 7-9 .

[0163] Figure 7 A decentralized approach to battery power budget allocation is illustrated. During this decentralized approach, the IoT controller (e.g., Figure 1-5 One of the IoT controllers in the system can communicate with multiple ECMs, including providing battery power budgets to each of these ECMs. Each ECM can then make battery power budget decisions for the functions performed by the ECM. Each ECM has its own algorithm to monitor itself, and it is aware of the timing and operations performed and associated with the functions, applications, and attributes of that ECM. Each ECM has its own Key Performance Indicators (KPIs), is aware of its own degradation over a predetermined period of time, and is able to better allocate the remaining portion of the ECM's battery power budget. This allocation can be based on received over-the-air updates. Over-the-air updates include contextual data. One example over-the-air update is the expected date when the energy allocated to the ECM is expected to be depleted. Another example over-the-air update is the expected date when the ECM's energy is depleted. The following operations can be performed iteratively.

[0164] At point 700, the IoT controller and / or ECM periodically or based on one or more events monitor attributes to determine key performance indicators (KPIs).

[0165] At 702, the IoT controller and / or ECM monitors the KPIs. The ECM can connect and communicate with the IoT controller and share over-the-air updates, comparing the KPIs to maximum, target, and / or expected KPIs, and making adjustments as appropriate in the following operations. At 702A, the IoT controller and / or ECM calculates the KPI for each of one or more attributes. At 702B, the IoT controller and / or ECM determines whether one of the KPI scores equals a threshold or a detected anomaly. A detected anomaly refers to a KPI score outside a predetermined range of expected KPI scores. As an example, an anomaly is detected when the KPI score exceeds ±5-10% of the expected KPI score. If so, operation 704 is performed; otherwise, operation 706 is performed.

[0166] At point 704, the IoT controller and / or ECM stores the scores in a KPI confidence rating matrix, which can be stored in the vehicle, in the memory of a portable access device, in the memory of a central hub, in the memory of a charger, etc. The KPI confidence rating matrix is ​​a table that correlates KPI scores with confidence values ​​indicating whether the KPI scores are accurate. The KPI confidence rating matrix can be used to assess the accuracy of future KPI scores and / or should be used to determine whether battery power budget adjustments are necessary. The KPI confidence rating matrix can also be used to determine whether the ECM can reliably perform a specific application. ECMs have different power consumption rates and may be suitable for certain applications.

[0167] At 706, the IoT controller and / or ECM determines whether to adjust the battery power budget for one or more features and / or functions of one or more ECMs. If yes, operation 708 is performed; otherwise, operation 710 is performed.

[0168] At point 708, the IoT controller and / or ECM adjusts the battery power budget. In one embodiment, adjustments are made for features, functions, and / or ECMs that are expected or currently consuming the most power. In another embodiment, adjustments are made for features, functions, and / or ECMs that are expected or currently consuming a predetermined percentage of the total battery power budget for one or more of the vehicle or ECMs. These adjustments include reallocating the available remaining battery power budget before the next expected charging event. Adjustments can be made based on the priority level of features and functions. More battery power can be allocated to higher-priority features and functions.

[0169] At 710, the IoT controller and / or ECM can determine whether one or more ECMs are still engaged (i.e., turned on, running, and consuming power). When engaged, an ECM can be referred to as a source ECM or a sink ECM. A source ECM consumes less power than expected and / or allocated. An ECM that does not consume power but is expected to consume power and / or is allocated a certain percentage of the total battery power budget can be considered a source ECM. A sink ECM consumes more power than expected and / or allocated. If one or more ECMs are still engaged, operation 700 can be performed; otherwise, the method can terminate. In one embodiment, operation 708 is subsequently performed to adjust which ECMs are source ECMs and which are sink ECMs.

[0170] Figure 8 A decentralized approach for deactivating ECM and / or one or more features and / or corresponding functions is shown. The following operations can be performed iteratively: 800, 802, 804.

[0171] At 800, the IoT controller (e.g., Figure 1-5 One of the IoT controllers in the system) and / or ECM monitors for KPI anomalies. KPI anomalies can be monitored for features, functions, and / or ECM.

[0172] At 802, the IoT controller and / or ECM calculates an anomaly score for each KPI. This includes calculating a value ranging from 0 to 100, which quantifies the degree to which the KPI value differs from the expected KPI value, with higher scores indicating larger anomalies.

[0173] At step 804, the IoT controller and / or ECM determine whether one or more of the anomalous scores exceed a corresponding predetermined threshold (or limit). Different predetermined thresholds can be assigned to each KPI anomalous score. Two or more anomalous scores can be assigned the same predetermined threshold. If so, the feature, function, and / or ECM associated with the KPI score exceeding the corresponding predetermined threshold is stopped and / or deactivated.

[0174] At step 806, the IoT controller and / or ECM stop and / or deactivate features, functions, and / or ECMs that have KPI anomalies exceeding corresponding predetermined thresholds. This process may end after step 806, or it may be repeated to continue monitoring other features, functions, and / or ECMs that are still running and / or engaged.

[0175] Figure 9 A decentralized approach is presented for: mapping features to ECMs based on energy budget availability; performing pre-tuning evaluations of features; and resolving conflicts between features and / or vehicle ECMs. The following operations can be performed iteratively.

[0176] At 900, the IoT controller (e.g., Figure 1-5 One of the IoT controllers and / or ECM in the system performs feature queuing based on an activity scheduler. The queue stores the identifiers of the features and the order in which they are executed. Two or more features can be executed simultaneously. The queue can be a first-in, first-out (FIFO) queue. In one embodiment, the queue is... Figure 5 It is part of the memory 580 in the memory. In another embodiment, the queue is part of the memory 132 or the memory of the central hub 114 or the charging station 106.

[0177] At position 902, the IoT controller and / or ECM maps features to one or more ECMs based on energy budget availability (or battery power budget availability).

[0178] At 904, the IoT controller and / or ECM determine whether there are multiple features for which a request to be executed exists. If so, operation 906 can be executed; otherwise, operation 908 can be executed.

[0179] At point 906, the IoT controller and / or ECM perform a pre-commissioning evaluation of a feature relative to ecosystem resources, which can operate when the vehicle is off. This can include mapping features to ecosystem resources, which includes assigning features to one or more ECMs and corresponding hardware to execute the features. Resource management can be implemented for functions to be implemented by one or more ECMs (e.g., over-the-air updates). The IoT controller can assign features to ECMs, and the ECMs can determine when to execute the feature and the hardware involved in executing the feature. The IoT controller can grant permissions to the ECMs to allow them to make decisions about when and for how long to execute the feature and the power that can be consumed when executing the feature. The ECMs can negotiate permissions with the IoT controller.

[0180] At step 908, the IoT controller and / or ECM executes a conflict procedure. This involves determining the order in which features are executed and / or whether more than one feature is executed simultaneously. This can be based on the feature's priority level, whether the feature is non-urgent or urgent, etc. In one embodiment, urgent features are executed before non-urgent features. If multiple urgent features are requested, their execution is based on priority and battery power availability. Similarly, if multiple non-urgent features are requested, their execution is based on priority and battery power availability. This method may terminate after operations 906 and 908.

[0181] The examples described above include using an IoT controller to dynamically allocate the battery power budget for each ECM in a vehicle. Examples also include using an IoT controller to provide intelligence (or logic) to the vehicle's ECM to modify the ECM's internal power consumption algorithms. Examples include feature-based battery power budget allocation. An ECM can request additional battery power budgets from a network of devices and / or request battery power budgets previously allocated to network devices. Examples include creating new operating modes for an ECM in a powered-off state, which includes creating battery power budgets for the features and functions implemented by the ECM. Battery power budget negotiation algorithms are used to negotiate battery power budgets between connected devices.

[0182] The examples described above enable more features to be implemented when the vehicle is off, and increase the number of days the vehicle can remain connected and connected when off before needing to be charged. Further examples include IoT controllers that help the ECM make better decisions regarding battery power budget allocation. These examples enhance the user's IoT ecosystem experience by providing additional features that can be implemented when the vehicle is off and connected to the IoT ecosystem. These examples ensure that high-priority feature operations can be performed when the vehicle is off and connected.

[0183] The foregoing description is merely illustrative in nature and is in no way intended to limit this disclosure, its application, or use. The broad teachings of this disclosure can be implemented in many forms. Therefore, while this disclosure includes specific examples, its true scope should not be so limited, as other modifications will become apparent upon examination of the drawings, specification, and appended claims. It should be understood that one or more steps within a method may be performed in a different order (or simultaneously) without altering the principles of this disclosure. Furthermore, while each embodiment is described above as having specific features, any one or more of those features described with respect to any embodiment of this disclosure may be implemented in any other embodiment and / or combined with features of any other embodiment, even if such combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and the arrangement of one or more embodiments with respect to each other remains within the scope of this disclosure.

[0184] Spatial and functional relationships between components (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including “connection,” “joint,” “coupled,” “proximity,” “adjacent,” “on top of,” “above,” “below,” and “set.” Unless explicitly stated as “direct,” the relationship between the first and second components described in the above disclosure can be a direct relationship, where no other intermediate components exist between the first and second components, but it can also be an indirect relationship, where one or more intermediate components exist (spatially or functionally) between the first and second components. As used herein, the phrase “at least one of A, B, and C” should be interpreted as meaning logically (A or B or C) using the non-exclusive logical “OR,” and should not be interpreted as meaning “at least one of A, at least one of B, and at least one of C.”

[0185] In the accompanying drawings, the direction of the arrows, as indicated by the arrows, typically illustrates the flow of information (e.g., data or instructions) of interest to the illustration. For example, when components A and B exchange various types of information, but the information transmitted from component A to component B is relevant to the illustration, the arrow can point from component A to component B. This unidirectional arrow does not imply that no other information is transmitted from component B to component A. Furthermore, for information sent from component A to component B, component B can send a request for or confirmation of receipt of that information to component A.

[0186] In this application, including the following definitions, the term "module" or "controller" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include the following: application-specific integrated circuit (ASIC); digital, analog, or mixed-signal analog / digital discrete circuit; digital, analog, or mixed-signal analog / digital integrated circuit; combinational logic circuit; field-programmable gate array (FPGA); processor circuitry (shared, dedicated, or grouped) that executes code; memory circuitry (shared, dedicated, or grouped) that stores code executed by the processor circuitry; other suitable hardware components that provide the described functionality; or combinations of some or all of the foregoing, such as in a system-on-a-chip.

[0187] This module may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces connected to a local area network (LAN), the Internet, a wide area network (WAN), or a combination thereof. The functionality of any given module of this disclosure can be distributed among multiple modules connected via the interface circuits. For example, multiple modules can allow for load balancing. In a further example, a server (also referred to as a remote or cloud) module may perform some functions on behalf of a client module.

[0188] The term "code" as used above can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, data structures, and / or objects. The term "shared processor circuit" covers a single processor circuit that executes some or all of the code from multiple modules. The term "group processor circuit" covers a processor circuit that, in conjunction with additional processor circuitry, executes some or all of the code from one or more modules. References to multiple processor circuits cover multiple processor circuits on discrete dies, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above. The term "shared memory circuit" covers a single memory circuit that stores some or all of the code from multiple modules. The term "group memory circuit" covers a memory circuit that, in conjunction with additional memory, stores some or all of the code from one or more modules.

[0189] The term "memory circuit" is a subset of the term "computer-readable medium." As used herein, the term "computer-readable medium" does not cover transient electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); therefore, the term "computer-readable medium" can be considered tangible and non-transitory. Non-limiting examples of non-transitory, tangible computer-readable media are non-volatile memory circuits (such as flash memory circuits, erasable programmable read-only memory circuits, or mask read-only memory circuits), volatile memory circuits (such as static random access memory circuits or dynamic random access memory circuits), magnetic storage media (such as analog or digital magnetic tape or hard disk drives), and optical storage media (such as CDs, DVDs, or Blu-ray discs).

[0190] The apparatus and methods described in this application can be implemented, in part or in whole, by a special-purpose computer created by configuring a general-purpose computer to execute one or more specific functions embodied in a computer program. The aforementioned function blocks, flowchart components, and other elements serve as a software specification that can be routinely translated into a computer program by a skilled technician or programmer.

[0191] A computer program includes processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. A computer program may also include or depend on stored data. A computer program may encompass a basic input / output system (BIOS) that interacts with the hardware of a special-purpose computer, device drivers that interact with specific devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0192] Computer programs may include: (i) descriptive text to be parsed, such as HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Notation); (ii) assembly code; (iii) object code generated from source code by a compiler; (iv) source code for execution by an interpreter; (v) source code for compilation and execution by a just-in-time (JIT) compiler; and so on. As an example only, source code can be written using syntax from languages ​​including: C, C++, C#, Objective C, Swift, Haskell, Go, SQL, R, Lisp, etc. Fortran, Perl, Pascal, Curl, OCaml, HTML5 (Hypertext Markup Language 5th Edition), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Lua, MATLAB, SIMULINK and

Claims

1. An Internet of Things (IoT) ecosystem, comprising: Multiple electronic control modules (ECMs) are implemented in the vehicle and configured to perform dedicated functions characteristic of the IoT ecosystem, which includes multiple IoT devices; as well as An IoT controller is configured to acquire context data and allocate at least one battery power budget based on the context data for corresponding dedicated functions among the plurality of ECMs and the dedicated functions, wherein at least a portion of the context data is received from the plurality of IoT devices and the plurality of ECMs. The plurality of ECMs are configured to implement the dedicated functions based on the power budget of the at least one battery.

2. The IoT ecosystem of claim 1, wherein the IoT controller is implemented in the vehicle, portable access device, charging station, building hub or in an IoT device separate from the vehicle.

3. The IoT ecosystem of claim 1, wherein the IoT controller is configured to recommend a battery power budget for one of the plurality of ECMs, and to receive an acceptance or rejection response from the one of the plurality of ECMs for the recommended battery power budget from the IoT controller.

4. The IoT ecosystem of claim 3, wherein the one of the plurality of ECMs is configured to perform at least one of the following: i) requesting additional battery power relative to the battery power recommended in the recommended battery power budget for the one of the plurality of ECMs, and ii) negotiating the battery power budget for the one of the plurality of ECMs with the other ECMs.

5. The IoT ecosystem according to claim 1, wherein: The IoT controller is configured to allocate the battery power budget to one of the plurality of ECMs; and The plurality of ECMs are configured to determine whether to accept or change the allocated battery power budget for one of the plurality of ECMs.

6. The IoT ecosystem according to claim 1, wherein: The IoT controller is configured to implement a battery power budgeting process, which includes allocating a total battery power budget to the plurality of ECMs of the vehicle and providing the total battery power budget to one of the plurality of ECMs; as well as One of the plurality of ECMs is configured to determine the battery power budget for the remaining ECMs among the plurality of ECMs based on the total battery power budget.

7. The IoT ecosystem of claim 1, wherein the IoT controller is configured to: Utilize the aforementioned multiple ECMs to monitor changes in events; Determine whether the change in the event makes it necessary to: i) update the total battery power budget, and ii) adjust one or more battery power budgets of the plurality of ECMs; Collect updated context data; as well as In response to determining that it is necessary to update the total battery power budget or to adjust one or more battery power budgets, updated context data is collected, and based on the updated context data, at least one of the following is updated: the total battery power budget and the one or more battery power budgets.

8. The IoT ecosystem of claim 1, wherein the IoT controller or the plurality of ECMs is configured to: Monitor the attributes of the dedicated function used to determine key performance indicators (KPIs); Calculate the KPI for each of the attributes; Determine whether the KPI score equals the threshold or is a detected anomaly; In response to the KPI score being equal to the threshold or an anomaly being detected, the KPI score is stored in the KPI confidence rating matrix; In response to the KPI score not being equal to the threshold and not being an anomaly, determine whether to adjust at least one battery power budget for one or more of the feature and the dedicated function; as well as In response to determining to make an adjustment, the power budget of the at least one battery is adjusted.

9. The IoT ecosystem of claim 1, wherein the IoT controller or the plurality of ECMs is configured to: Monitor for anomalies in the key performance indicators (KPIs) of the attributes of the dedicated function; Calculate the anomaly score; Determine whether one of the abnormal scores is greater than a threshold; and If the score is greater than the threshold, then at least one of the following is performed: i) stop executing at least one of the features and functions associated with one of the abnormal scores that are greater than the threshold, and ii) deactivate one of the plurality of ECMs associated with one of the abnormal scores that are greater than the threshold.

10. The IoT ecosystem of claim 1, wherein the IoT controller or the plurality of ECMs is configured to: The features are queued based on the activity scheduling table; The features are mapped to the plurality of ECMs based on the at least one battery power budget; Determine if multiple features were requested; If multiple features are requested, a pre-calibration evaluation of the features relative to ecosystem resources is performed. as well as Run the conflict procedure to determine the execution order of the requested features.

Images