Energy capacity system for a vehicle

Abstract

A computer-implemented method is disclosed that, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include receiving, at a centralized electronic control unit (ECU) from a first controller of a plurality of controllers, an energy request, generating, via a capacity algorithm of the centralized ECU, a capacity query, issuing, via the centralized ECU, the capacity query to one or more of the plurality of controllers, and receiving, at the centralized ECU from the one or more of the plurality of controllers, one or more donation responses. The operations further include aggregating the one or more donation responses, adjusting, via the capacity algorithm, an energy capacity of the first controller, and determining, via the capacity algorithm, a fulfillment status of the first controller based on the adjusted energy capacity.

Description

Technical Field

[0001] This disclosure generally relates to energy capacity systems for vehicles. Background Technology

[0002] The information provided in this section is intended to provide a general overview of the background of this disclosure. To the extent described in this section, the work of the currently named inventors, and aspects of the description that may not conform to the prior art at the time of submission, are neither explicitly nor implicitly acknowledged as prior art relative to this disclosure.

[0003] Modern vehicles are often equipped with multiple electronic control units (ECUs), which consume varying amounts of energy even when the vehicle's ignition is off. For example, these ECUs rely on a reserve battery to continue operating for a predetermined period after ignition inactivity. Depending on the situation, an ECU can remain operational for days or even weeks before the reserve battery is depleted. Once the reserve battery is depleted, the ECU loses power, rendering the features controlled by that ECU inaccessible to the user. Therefore, an enhanced reserve battery system is needed that can provide an additional energy source to the ECU, preventing it from depleting its allocated energy capacity. Summary of the Invention

[0004] In some aspects, a computer-implemented method causes data processing hardware to perform operations when executed by data processing hardware. The operations include receiving an energy request from a first controller among a plurality of controllers at a centralized electronic control unit (ECU), generating a capacity query via a capacity algorithm of the centralized ECU, issuing the capacity query to one or more of the plurality of controllers via the centralized ECU, and receiving one or more donation responses from one or more of the plurality of controllers at the centralized ECU. The operations also include aggregating one or more donation responses, adjusting the energy capacity of the first controller via the capacity algorithm, and determining the fulfillment status of the first controller based on the adjusted energy capacity via the capacity algorithm.

[0005] In some examples, an energy request may include capacity consumption of a first controller. Operations may include assigning an updated operating mode to the first controller via a capacity algorithm, and restricting the operational functions of the first controller based on the updated operating mode via the capacity algorithm. In some cases, receiving an energy request may include receiving multiple energy requests from multiple controllers. Operations may also include assigning a priority order to each of the multiple energy requests via a capacity algorithm. At least one of the multiple energy requests may receive the first priority in the priority order.

[0006] Optionally, generating a capacity query may include determining the assigned priority order of the received energy requests and issuing a capacity query to the controller with the first priority in the assigned priority order among a plurality of controllers. The operation may also include identifying one or more controllers among the plurality of controllers configured with high energy capacity. In some cases, issuing a capacity query may include issuing a capacity query to one or more controllers among the plurality of controllers configured with high energy capacity.

[0007] In other aspects, an energy capacity system for a vehicle includes a plurality of controllers and a centralized electronic control unit (ECU) communicatively coupled to each of the plurality of controllers. Each of the plurality of controllers includes energy capacity. The centralized ECU includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include receiving an energy request from a first controller of the plurality of controllers, receiving one or more donation responses from one or more of the plurality of controllers, aggregating one or more donation responses, and adjusting the energy capacity of the first controller via a capacity algorithm of the centralized ECU.

[0008] In some examples, the operation may include allocating an updated operating mode of a first controller via a capacity algorithm, and restricting the operational functions of the first controller based on the updated operating mode via the capacity algorithm. Optionally, receiving energy requests may include receiving multiple energy requests from multiple controllers. The operation may further include generating a priority matrix including multiple priority orders, the multiple priority orders including a first priority, and assigning a priority order from the priority matrix to each of the multiple energy requests via a capacity algorithm, at least one of the multiple energy requests receiving the first priority.

[0009] In some cases, generating a capacity query may include determining the assigned priority order of received energy requests and issuing a capacity query to the controller with the highest priority in the assigned priority order among a plurality of controllers. The operation may also include identifying one or more controllers among the plurality of controllers configured with high energy capacity. The operation may also include generating a capacity query via a capacity algorithm of a centralized ECU. Optionally, issuing a capacity query may include issuing a capacity query to one or more controllers among the plurality of controllers configured with high energy capacity. The operation may also include issuing a capacity query to one or more of the plurality of controllers via a centralized ECU.

[0010] In another aspect, an energy capacity system for a vehicle includes a plurality of controllers and a centralized electronic control unit (ECU) communicatively coupled to each of the plurality of controllers. Each of the plurality of controllers includes an energy capacity. The centralized ECU includes an energy reservoir, data processing hardware, and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. Operations include receiving an energy request from a first controller among the plurality of controllers, providing an energy source from the energy reservoir to the first controller, and adjusting the energy capacity of the first controller via a capacity algorithm.

[0011] In some examples, the operation may include allocating updated energy capacity to a first controller via a capacity algorithm, and limiting the operational functions of the first controller based on the updated energy capacity via the capacity algorithm. Optionally, receiving energy requests may include receiving multiple energy requests from multiple controllers, assigning a priority order to each of the multiple energy requests via a capacity algorithm, receiving a first priority in at least one of the multiple energy requests in the priority order, and generating a capacity query includes determining the assigned priority order of the received energy requests, and issuing a capacity query for the controller among the multiple controllers that has the first priority in the assigned priority order. Attached Figure Description

[0012] The accompanying drawings described herein are for illustrative purposes only for the selected configurations and are not intended to limit the scope of this disclosure.

[0013] Figure 1 This is a schematic diagram of a vehicle equipped with an energy capacity system according to this disclosure;

[0014] Figure 2 This is an exemplary block diagram of an energy capacity system according to the present disclosure;

[0015] Figure 3 It is a schematic diagram of an energy capacity system according to this disclosure, which has a centralized electronic control unit (ECU) communicating with a depletion controller and multiple donation controllers;

[0016] Figure 4 This is an example flowchart of an energy capacity system based on this disclosure; and

[0017] Figure 5 This is an exemplary method of operation for an energy capacity system according to the present disclosure.

[0018] Throughout the accompanying drawings, corresponding reference numerals indicate the respective parts. Detailed Implementation

[0019] The example configuration will now be described more fully with reference to the accompanying drawings. The example configuration is provided so that this disclosure will be thorough and will fully communicate the scope of this disclosure to those skilled in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configuration of this disclosure. It will be apparent to those skilled in the art that the specific details are not required, that the example configuration may be implemented in many different forms, and that the specific details and exemplary configuration should not be construed as limiting the scope of this disclosure.

[0020] The terminology used herein is for the purpose of describing specific exemplary configurations only and is not intended to be limiting. As used herein, the singular articles “a,” “an,” and “the” may also be intended to include plural forms unless the context clearly indicates otherwise. The terms “comprising,” “including,” “containing,” and “having” are inclusive, thus specifying the presence of features, steps, operations, elements, and / or components, but not excluding the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein should not be construed as requiring them to be performed in the specific order discussed or shown, unless specifically identified as such. Additional or alternative steps may be employed.

[0021] When an element or layer is referred to as “on another element or layer,” “joined to,” “connected to,” “attached to,” or “linked to” another element or layer, it may be directly on, joined to, connected to, attached to, or linked to the other element or layer, or there may be intermediate elements or layers present. Conversely, when an element is referred to as “directly on another element or layer,” “directly joined to,” “directly connected to,” “directly attached to,” or “directly linked to” another element or layer, there may be no intermediate elements or layers present. Other terms used to describe relationships between elements should be interpreted in a similar manner (e.g., “between” vs. “directly between,” “adjacent” vs. “directly adjacent,” etc.). As used herein, the term “and / or” includes any and all combinations of one or more of the related listed items.

[0022] The terms first, second, third, etc., may be used herein to describe various elements, components, regions, layers, and / or parts. These elements, components, regions, layers, and / or parts should not be limited by these terms. These terms are used only to distinguish individual elements, components, regions, layers, or parts. Terms such as “first,” “second,” and other numerical terms do not imply order or sequence unless the context clearly indicates otherwise. Therefore, the first element, component, region, layer, or part discussed below may be referred to as the second element, component, region, layer, or part without departing from the teachings of the example configuration.

[0023] In this application, including the following definitions, the term "module" may be replaced by the term "circuit". The term "module" may refer to or be a part of an application-specific integrated circuit (ASIC), or include ASICs; digital, analog, or mixed-signal analog / digital discrete circuits; digital, analog, or mixed-signal analog / digital integrated circuits; combinational logic circuits; field-programmable gate arrays (FPGAs); processors (shared, dedicated, or grouped) that execute code; memory (shared, dedicated, or grouped) that stores code executed by the processor; other suitable hardware components that provide the functions described; or some or all of the above, such as in a system-on-a-chip.

[0024] The term "code" as used above can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, and / or objects. The term "shared processor" includes a single processor that executes some or all of the code from multiple modules. The term "group processor" includes a processor, in conjunction with an additional processor, that executes some or all of the code from one or more modules. The term "shared memory" includes a single memory that stores some or all of the code from multiple modules. The term "group memory" includes memory, in conjunction with additional memory, that stores some or all of the code from one or more modules. The term "memory" can be a subset of the term "computer-readable medium." The term "computer-readable medium" does not include transient electrical and electromagnetic signals propagating through the medium and can therefore be considered tangible, non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, including non-volatile memory, magnetic memory, and optical memory.

[0025] The apparatus and methods described in this application may be implemented, in whole or in part, by one or more computer programs executed by one or more processors. The computer program includes processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer program may also include and / or depend on stored data.

[0026] A software application (i.e., a software resource) can refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and game applications.

[0027] Non-transitory memory can be a physical device used for temporary or permanent storage of programs (e.g., instruction sequences) or data (e.g., program state information) for use by a computing device. Non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used in firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and magnetic disks or magnetic tapes.

[0028] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0029] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These different implementations may include implementations in one or more computer programs executable and / or interpretable on a programmable system, the programmable system including at least one programmable processor, at least one input device, and at least one output device, the programmable processor being dedicated or general-purpose, coupled to receive data and instructions from and send data and instructions to the storage system.

[0030] The processes and logic flows described in this specification can be executed by one or more programmable processors, also known as data processing hardware, which execute one or more computer programs to perform functions by manipulating input data and generating output. These processes and logic flows can also be executed by special-purpose logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include or be operatively coupled to one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, to receive data from or transfer data to, or both. However, a computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. Processors and memory may be supplemented or incorporated therein by dedicated logic circuitry.

[0031] To provide interaction with the user, one or more aspects of this disclosure can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touchscreen, and optional keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including sound, speech, or tactile input. Furthermore, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0032] refer to Figure 1-3The energy capacity system 10 for vehicle 100 includes a centralized electronic control unit (ECU) 12 configured to execute a capacity algorithm 14. The centralized ECU 12 is communicatively coupled to a plurality of controllers 102 of vehicle 100. The plurality of controllers 102 are configured to perform various operational functions of vehicle 100, which can be controlled by a user or otherwise utilized when the ignition 104 of vehicle 100 is inactive. For example, each of the plurality of controllers 102 is configured with a predefined energy capacity 106 that can be monitored by the centralized ECU 12. The predefined energy capacity 106 is configured to provide sufficient energy source 108 to the corresponding controller 102 to execute one or more operational functions 110 of the controller 102, as described in more detail below.

[0033] Multiple controllers 102 can be configured to perform various operational functions 110, including but not limited to window controls, lighting, user interface systems, and communication services. A predefined energy capacity 106 for each controller 102 is configured to provide sufficient energy source 108 to power the operational functions 110 of each controller 102 for a predetermined period of time. For example, multiple controllers 102 can be configured to perform operational functions 110 for one to two weeks before consuming energy source 108. The predetermined period of time for operational functions 110 is reflected by the predefined energy capacity 106 of each controller 102. In some cases, a user may deplete energy source 108 before the predetermined period of time, thereby depleting the predetermined energy capacity 106. The energy capacity system 10 is configured to monitor energy source 108 across multiple controllers 102 and to exchange energy source 108 among controllers 102 using a centralized ECU 12, as described in more detail below.

[0034] Still referencing Figure 1-3 The centralized ECU 12 includes data processing hardware 16 and memory hardware 18 in communication with the data processing hardware 16. The memory hardware 18 stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform the operations described herein. The data processing hardware 16 is configured to execute a capacity algorithm 14 in response to one or more energy requests 112 from one or more of a plurality of controllers 102. Energy requests 112 include capacity depletion 112a of a depleted controller 102a (i.e., the first controller 102a) among the plurality of controllers 102. For example, a depleted controller 102a may issue an energy request 112 in response to capacity depletion 114 of a predetermined energy capacity 106. The centralized ECU 12 is configured to receive energy requests 112 at the capacity algorithm 14 and, in response, may generate a capacity query 20.

[0035] Capacity query 20 is configured to reflect capacity depletion 112a, such that capacity query 20 can specify an energy value 20a requested by the depleted controller 102a. Capacity query 20 is configured to identify one or more controllers 102 that may have energy sources 108 available for use by other controllers 102. For example, centralized ECU 12 may generate capacity query 20 in response to an energy request 112 from a first controller 102a, and may transmit capacity query 20 to one or more donation controllers 102b (i.e., the remaining plurality of controllers 102). Donation controllers 102b provide donation response 116 to centralized ECU 12, indicating whether one or more donation controllers 102b have additional or backup energy sources 108. Donation response 116 may include values ​​associated with the remaining energy sources 108 in the predefined energy capacity 106 of each controller 102b.

[0036] In some cases, donation response 116 may indicate that donation controller 102b has a minimum available power source 108. Centralized ECU 12 is configured to compare donation responses 116 from each of the donation controllers 102b to identify which donation controller 102b to draw power source 108 to fulfill power request 112. Centralized ECU 12 may also aggregate donation responses 116 and selectively draw power source 108 from one or more of the donation controllers 102b. Centralized ECU 12 can be connected via Bluetooth. ,Bluetooth Low-energy or any other low-energy communication technology is communicatively coupled to each of the multiple controllers 102. Therefore, the centralized ECU 12 can draw energy from the donation controller 102b from the energy source 108 without depleting the predefined energy capacity 106 of the respective donation controller 102b. The centralized ECU 12 can identify which of the donation controllers 102b are configured with high energy capacity 106a upon receiving a donation response 116.

[0037] High energy capacity 106a is defined as exceeding the potentially usable energy capacity 106 of the energy source 108 of the corresponding controller 102. For example, controller 102 may have a predefined energy capacity 106 equal to the energy capacity 106 of other controllers 102, but remain inactive when ignition 104 is inactive. Therefore, the centralized ECU 12 can classify the exemplary controller 102 as having high energy capacity 106a due to the available energy source 108. In other cases, the corresponding controller 102 may be configured with a predefined energy capacity 106 greater than the predefined energy capacity 106 of other controllers 102, such that the amount of energy source 108 is greater than that of other controllers 102. The centralized ECU 12 may be configured to target controllers 102 having high energy capacity 106a. For example, a capacity query 20 may be issued to controllers 102 having high energy capacity 106a.

[0038] In other cases, the centralized ECU 12 may receive multiple energy requests 112 from one or more of the controllers 102. For example, a first depleted controller 102a1 and a second depleted controller 102a2 may each issue an energy request 112 to the centralized ECU 12. In response, the centralized ECU 12 may include a priority matrix 22 stored in memory hardware 18, configured with a priority order 24 for each of the controllers 102. Each of the controllers 102 is also configured with a priority order 24, which is provided to the centralized ECU 12 along with the energy requests 112. Upon receiving multiple energy requests 112, the centralized ECU 12 uses the priority matrix 22 to compare the priority order 24 received with each energy request 112. The priority matrix 22 causes at least one of the multiple energy requests 112 to receive a first priority 24a, such that the centralized ECU 12 may prioritize the depleted controller 102a with the first priority 24a.

[0039] For example, capacity algorithm 14 is configured to determine the assigned priority order 24 of energy request 112 before generating capacity query 20. Once priority order 24 is determined, capacity algorithm 14 issues capacity query 20 for the depleted controller 102a with a first priority 24a. In the example above, the first depleted controller 102a1 may have a higher priority order 24 than the second depleted controller 102a2. Priority order 24 may be determined based on the associated operational functions 110 of the depleted controller 102a. If the first depleted controller 102a1 has operational functions 110 related to security functions such as communication, and the second depleted controller 102a2 has operational functions 110 related to internal lighting control, then capacity algorithm 14 assigns the first priority order 24a to the first depleted controller 102a1.

[0040] In some cases, each of the multiple controllers 102 can be pre-programmed with a priority order 24, allowing a priority matrix 22 to be embedded within a centralized ECU 12. In such an example, the centralized ECU 12 utilizes the priority matrix 22 in a similar manner to that described above and can use it as a lookup or reference matrix. For example, the centralized ECU 12 may receive an energy request 112 from a depleted controller 102a and utilize the priority matrix 22 to identify the relevant priority order 24. The priority order 24 is typically determined based on need. For example, a safety and security operation 110 will have a higher priority order 24 than an operation 110 involving interior lighting or climate control.

[0041] Further reference Figure 1-3The centralized ECU 12 can also adjust the energy capacity 106 for the depleted controller 102a via capacity algorithm 14 after receiving the donation response 116. The adjusted energy capacity 106 provides the depleted controller 102a with the ability to accept and utilize the additional energy source 108. The centralized ECU 12 is configured to receive the energy source 108 from the donation controller 102b and allocate the donated energy source 108 to the depleted controller 102a. Capacity algorithm 14 is also configured to assign an updated operating mode 110a to the depleted controller 102a. The updated operating mode 110a is configured to limit the operating functions 110 of the depleted controller 102a based on the updated operating mode 110a. For example, the updated operating mode 110a may limit the operating functions 110 to prioritize safety and security functions that may be associated with the depleted controller 102a. In other cases, the updated operating mode 110a may result in limiting the operating functions 110 to only the critical or primary functions of the depleted controller 102a.

[0042] Still referencing Figure 1-3 In some examples, the centralized ECU 12 is configured with an energy reservoir 30. The energy reservoir 30 may be the remainder of the centralized energy source 32 used by the centralized ECU 12, which may be redirected to the depleted controller 102a in response to energy request 112. The capacity algorithm 14 may receive the energy request 112 from the depleted controller 102a and may redirect a portion of the centralized energy source 32 from the energy reservoir 30 to the depleted controller 102a. In this configuration, the capacity algorithm 14 does not issue a capacity query 20 because the energy reservoir 30 is used to fulfill the energy request 112. The centralized ECU 12 is configured with a separate energy source 34 for operating the centralized ECU 12, such that the centralized energy source 32 stored in the energy reservoir 30 is reserved for fulfilling the energy request 112.

[0043] Regardless of whether the centralized ECU 12 utilizes either the donation response 116 or the energy reservoir 30, the centralized ECU 12 updates the depleted controller 102a with a fulfillment status 40. The fulfillment status 40 is defined by the satisfied energy request 112. For example, the depleted controller 102a may receive an energy source 108 from the centralized ECU 12 corresponding to the energy request 112. The fulfillment status 40 provides the centralized ECU 12 with a metric to monitor when the energy request 112 has been fulfilled. Once the fulfillment status 40 is satisfied, the centralized ECU 12 can remove the energy request 112 from the queue 36 of the capacity algorithm 14.

[0044] Now for reference Figure 4The diagram illustrates an example flowchart of an energy capacity system 10 comprising a centralized ECU 12 and each controller 102. At 400, the centralized ECU 12 receives an energy request 112, and at 402, a depleted controller 102a, including the one requesting energy 112, is recorded. At 404, a capacity algorithm 14 determines a priority order 24 for the depleted controllers 102a. At 406, the capacity algorithm 14 compares the priority order 24 of the depleted controllers 102a with a priority matrix 22, and at 408 determines whether to approve the energy request 112 based on the priority order 24. If the centralized ECU 12 rejects the energy request 112, the capacity algorithm 14 removes the energy request 112 from the queue at 410. If the centralized ECU 12 grants the energy request 112, the capacity algorithm 14 determines at 412 whether an available donation response 116 exists.

[0045] If an available donation response 116 exists, the capacity algorithm determines at 414 whether energy request 112 has been fulfilled. If energy request 112 is fulfilled, the centralized ECU 12 at 416 transmits the amount of energy source 108 requested in energy request 112 to the depleted controller 102a and removes energy request 112 from the queue. If energy request 112 cannot be fulfilled, the centralized ECU 12 at 418 transmits the amount of available energy source 108 (i.e., a partial amount or none) and at 420 modifies energy request 112 to reflect the remaining required energy source 108 that has not yet been fulfilled. Then, at 422, the centralized ECU 12 adjusts the amount of remaining energy source 108 for the relevant donation controller 102b.

[0046] If no donation response 116 is available, the capacity algorithm 14 returns to monitor at 424 whether any donation response 116 has been received. If a donation response 116 is received, the capacity algorithm 14 records the associated donation controller 102b and the amount of donated energy source 108 at 426.

[0047] Now for reference Figure 5An exemplary operation method 500 of an energy capacity system 10 is illustrated. At 502, a centralized ECU 12 receives an energy request 112 from a first depleted controller 102a among a plurality of controllers 102. A capacity algorithm 14 of the centralized ECU 12 generates a capacity query 20 at 504 and issues the capacity query 20 to one or more of the plurality of controllers 102 at 506. At 508, the centralized ECU 12 receives one or more donation responses 116 from one or more of the plurality of controllers 102. The plurality of controllers 102 sending the donation responses 116 are donation controllers 102b. The centralized ECU 12 aggregates the one or more donation responses 116 at 510 and adjusts the energy capacity 106 of the first depleted controller 102a via the capacity algorithm 14 at 512. The capacity algorithm 14 determines the fulfillment state 40 of the first controller 102a based on the adjusted energy capacity 106 at 514.

[0048] Many embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are also within the scope of the following claims.

[0049] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or limiting of this disclosure. Individual elements or features of a particular configuration are generally not limited to that particular configuration, but where applicable, they are interchangeable and can be used in selected configurations, even if not specifically shown or described. This can also be varied in many ways. Such variations should not be considered as departing from this disclosure, and all such modifications are intended to be included within the scope of this disclosure.

Claims

1. A computer-implemented method, when executed by data processing hardware, to cause the data processing hardware to perform operations including: Receives energy requests from the first controller among multiple controllers at the centralized electronic control unit (ECU); Capacity queries are generated via a capacity algorithm from a centralized ECU. Capacity queries are sent to one or more of multiple controllers via a centralized ECU; Receive one or more donation responses from one or more of multiple controllers at a centralized ECU; Aggregate one or more donation responses; The energy capacity of the first controller is adjusted via a capacity algorithm. as well as The performance status of the first controller is determined based on the adjusted energy capacity using a capacity algorithm.

2. The method according to claim 1, wherein, The energy request includes the capacity consumption of the first controller.

3. The method of claim 1 further includes assigning an updated operating mode to the first controller via the capacity algorithm, and restricting the operating functions of the first controller based on the updated operating mode via the capacity algorithm.

4. The method according to claim 1, wherein, Receiving the energy request includes receiving multiple energy requests from the plurality of controllers.

5. The method according to claim 4, further comprising: The capacity algorithm assigns a priority order to each of the plurality of energy requests, with at least one of the energy requests having the first priority in the priority order.

6. The method according to claim 5, wherein, Generating the capacity query includes: determining the assigned priority order of the received energy requests, and issuing a capacity query for the controller with the first priority in the assigned priority order among the plurality of controllers.

7. The method of claim 1, further comprising identifying one or more controllers among the plurality of controllers configured with high energy capacity.

8. The method according to claim 7, wherein, Issuing the capacity query includes issuing a capacity query to one or more of the plurality of controllers that are configured with the high energy capacity.

9. An energy capacity system for a vehicle, comprising: Multiple controllers, each of which includes energy capacity; and A centralized electronic control unit (ECU) that is communicatively coupled to each of a plurality of controllers includes: Data processing hardware; and Memory hardware that communicates with data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform the method according to claim 1.

10. A vehicle equipped with an energy capacity system according to claim 9.

Images