阅读说明：本技术 用于改进人机接口性能的汽车电子控制单元预启动 (Automotive electronic control unit pre-start for improved human interface performance ) 是由 G·戈洛夫 于 2020-03-10 设计创作，主要内容包括：公开用于改进车辆中的电子控制单元装置的预启动的装置和方法。在一个实施例中,公开一种方法,其包括：基于与车辆的一或多个交互检测预启动条件的触发；将通电信号发射到所述车辆中的至少一个电子控制单元(ECU),所述至少一个ECU以低功率状态操作；以及在确定所述车辆已起动后即刻完全启动所述至少一个ECU。(An apparatus and method for improving pre-start of an electronic control unit device in a vehicle is disclosed. In one embodiment, a method is disclosed, comprising: detecting a trigger of a pre-start condition based on one or more interactions with the vehicle; transmitting an energizing signal to at least one Electronic Control Unit (ECU) in the vehicle, the at least one ECU operating in a low power state; and fully activating the at least one ECU upon determining that the vehicle has been started.)

1. A method, comprising:

detecting a trigger of a pre-start condition based on one or more interactions with the vehicle;

transmitting an energizing signal to at least one Electronic Control Unit (ECU) in the vehicle, the at least one ECU operating in a low power state; and

fully activating the at least one ECU upon determining that the vehicle has been started.

2. The method of claim 1, further comprising powering off the at least one ECU upon determining that the vehicle has not started.

3. The method of claim 1, the detecting a trigger for a pre-start condition comprising one or more of:

detecting a door unlock signal;

detecting a change in weight of a seat of the vehicle;

detecting a person in proximity to the vehicle;

detecting an airborne command received by an ECU of the vehicle; or

The behavioral model is polled using the current day and time.

4. The method of claim 3, the detecting a door unlock signal comprising:

detecting whether a driver side door receives the door unlocking signal or not, and pre-starting a key driver ECU as a response;

detecting whether the passenger door receives the door unlock signal, and in response pre-starting an additional ECU; or

It is detected whether the trunk receives the door unlock signal and in response delays a pre-start of the ECU.

5. The method of claim 3, the detecting a weight change of a seat of the vehicle comprising detecting whether a current weight exceeds a predetermined threshold.

6. The method of claim 3, the using the current day and time polling behavior model comprising continuously updating a time-based prediction model based on historical start times of the vehicle, and pre-starting the at least one ECU upon determining that a current time is predicted by the time-based prediction model to correspond to a start time of the vehicle.

7. The method of claim 1, further comprising storing and updating a set of pre-start timing characteristics that control the timing of pre-starting the at least one ECU.

8. An apparatus, comprising:

a processor; and

a storage medium for tangibly storing program logic thereon for execution by the processor, the stored program logic causing the processor to perform the steps of:

detecting a trigger of a pre-start condition based on one or more interactions with the vehicle;

transmitting an energizing signal to at least one Electronic Control Unit (ECU) in the vehicle, the at least one ECU operating in a low power state; and

fully activating the at least one ECU upon determining that the vehicle has been started.

9. The device of claim 8, the stored program logic further causing the processor to perform the step of powering off the at least one ECU upon determining that the vehicle has not started.

10. The device of claim 8, the trigger to detect a pre-boot condition comprising one or more of:

detecting a door unlock signal;

detecting a change in weight of a seat of the vehicle;

detecting a person in proximity to the vehicle;

detecting an airborne command received by an ECU of the vehicle; or

The behavioral model is polled using the current day and time.

11. The apparatus of claim 10, the detecting a door unlock signal comprising:

detecting whether a driver side door receives the door unlocking signal or not, and pre-starting a key driver ECU as a response;

detecting whether the passenger door receives the door unlock signal, and in response pre-starting an additional ECU; or

It is detected whether the trunk receives the door unlock signal and in response delays a pre-start of the ECU.

12. The apparatus of claim 10, the detecting a change in weight of a seat of the vehicle comprising detecting whether a current weight exceeds a predetermined threshold.

13. The device of claim 10, the using the current day and time polling behavior model comprising continuously updating a time-based prediction model based on historical start times of the vehicle, and pre-starting the at least one ECU upon determining that a current time is predicted by the time-based prediction model to correspond to a start time of the vehicle.

14. The apparatus of claim 8, further comprising storing and updating a set of pre-start timing characteristics that control timing of pre-starting the at least one ECU.

15. A non-transitory computer readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the steps of:

detecting a trigger of a pre-start condition based on one or more interactions with the vehicle;

transmitting an energizing signal to at least one Electronic Control Unit (ECU) in the vehicle, the at least one ECU operating in a low power state; and

fully activating the at least one ECU upon determining that the vehicle has been started.

16. The non-transitory computer readable storage medium of claim 15, the computer program instructions further defining the step of powering down the at least one ECU upon determining that the vehicle has not started.

17. The non-transitory computer-readable storage medium of claim 15, the detecting a trigger for a pre-boot condition comprising one or more of:

detecting a door unlock signal;

detecting a change in weight of a seat of the vehicle;

detecting a person in proximity to the vehicle;

detecting an airborne command received by an ECU of the vehicle; or

The behavioral model is polled using the current day and time.

18. The non-transitory computer-readable storage medium of claim 17, the detecting a door unlock signal comprising:

detecting whether a driver side door receives the door unlocking signal or not, and pre-starting a key driver ECU as a response;

detecting whether the passenger door receives the door unlock signal, and in response pre-starting an additional ECU; or

It is detected whether the trunk receives the door unlock signal and in response delays a pre-start of the ECU.

19. The non-transitory computer-readable storage medium of claim 17, the detecting a weight change of a seat of the vehicle comprising detecting whether a current weight exceeds a predetermined threshold.

20. The non-transitory computer-readable storage medium of claim 17, the using the current day and time polling behavior model comprising continuously updating a time-based prediction model based on historical start times of the vehicle, and pre-starting the at least one ECU upon determining that a current time is predicted by the time-based prediction model to correspond to a start time of the vehicle.

21. The non-transitory computer-readable storage medium of claim 15, further comprising storing and updating a set of pre-start timing characteristics that control timing of pre-starting the at least one ECU.

Background

The disclosed embodiments are directed to an in-vehicle computing system, and in particular, to an apparatus and method for pre-starting an Electronic Control Unit (ECU) in a vehicle.

Modern automobiles contain dozens of ECUs. These ECUs may be used in infotainment systems or may be used as critical systems in, for example, autonomous vehicles. The software in the ECU generally includes a composite operating system and an application layer software stack. Starting this software can typically take many seconds, even for the simplest ECU devices. However, many ECUs on modern vehicles need to be started as quickly as possible, and typically within one second of starting the vehicle. For example, automotive radios, rear view cameras, instrument clusters, network devices, etc. often need to be started upon starting the vehicle. However, existing architectures for vehicles require such ECUs to be started from a powered-off state only in response to vehicle startup. Therefore, these ECUs are not capable of providing near instantaneous startup.

The disclosed embodiments remedy these and other technical problems by providing a pre-start procedure to speculatively start an ECU in a vehicle based on one or more detected conditions, thereby improving the operation of the ECU.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be apparent from the following description of embodiments as illustrated in the accompanying drawings in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the disclosure.

FIG. 1 is a flow chart illustrating a method for pre-starting an ECU according to some embodiments of the present disclosure.

Fig. 2A is a flow chart illustrating a method for detecting a pre-boot condition according to some embodiments of the present disclosure.

Fig. 2B is a flow chart illustrating a method for detecting a pre-boot condition according to some embodiments of the present disclosure.

Fig. 3A is a flow chart illustrating a method for pre-starting an ECU based on monitoring a door unlock signal, according to some embodiments of the present disclosure.

Fig. 3B is a flow chart illustrating a method for pre-starting an ECU based on a change in weight on a vehicle seat according to some embodiments of the present disclosure.

FIG. 3C is a flow chart illustrating a method for updating and using a predictive model for pre-starting an ECU, according to some embodiments of the present disclosure.

Fig. 3D is a flow diagram illustrating a method for using and updating pre-start timing characteristics, according to some embodiments of the present disclosure.

FIG. 4 is a block diagram illustrating a system for pre-starting an ECU according to some embodiments of the present disclosure.

Fig. 5 is a block diagram of an ECU according to some embodiments of the present disclosure.

Fig. 6 is a block diagram of a boot process according to some embodiments of the present disclosure.

Detailed Description

The disclosed embodiments describe systems, devices, methods, and computer readable media for pre-starting a vehicle ECU in response to detecting a pre-start condition. In addition, specific details regarding the types of pre-boot conditions and how these conditions are analyzed are provided in other embodiments. Finally, the disclosed embodiments describe how to pre-start the ECU device using a predictive model and optimize the timing of the pre-start in response to the pre-start condition detection. The disclosed embodiments improve the start-to-start latency (time-to-start) of the ECU device, resulting in a perceived "immediate" effect of the ECU output.

FIG. 1 is a flow chart illustrating a method for pre-starting an ECU according to some embodiments of the present disclosure.

In block 102, one or more ECUs operate in a low power mode, such as a standby, sleep, hibernate, or power-off mode.

In the illustrated embodiment, the low power mode refers to an operating mode of an electronic device (e.g., an ECU) in which some or all of the functions of the device are unavailable or are not performed. In a sleep or standby mode, the device state is typically stored in Random Access Memory (RAM) while unnecessary subsystems (e.g., displays, peripherals, etc.) are powered down. In addition, power to the RAM is reduced to its lowest possible state, only maintaining the integrity of the device state stored therein. In some modes, such as hibernation, the state of the device may additionally be saved to non-volatile storage. In this way, if power to the RAM is lost completely, the device can be restarted to the existing state. In the power down mode, all components of the device are powered down.

The particular state in which a given ECU is located may vary depending on the type of ECU and the operating conditions when the vehicle housing the ECU is shut down. In some cases, the ECU may be completely powered off, may be placed in a standby mode, or may be stepped from powered on to standby to powered off, depending on the requirements of the ECU. Typically, the ECU of the automobile will transition to a low power state primarily when the vehicle stops and removes the automobile or otherwise signals that the vehicle is no longer in use (e.g., removes the key fob from within detection range of the vehicle). The particular mechanism by which the ECU is placed in the low power state is not intended to limit the disclosed embodiments.

In block 104, the method determines whether a pre-boot condition is satisfied. The details of the particular pre-start conditions are more fully described in the description of fig. 2 and 3A-3E, and are not repeated in detail herein.

Briefly, a vehicle may be equipped with a pre-start ECU configured to perform the methods described herein. In one embodiment, this pre-start ECU is an "always on" ECU configured to constantly monitor the status of various other ECUs in the vehicle. In one embodiment, the pre-boot ECU monitors a vehicle bus (e.g., a car area network bus) for signals transmitted to and from the ECU or other component. As one example, an ECU controlling the locking of a door may broadcast or transmit a signal that it senses to unlock the door. The pre-start ECU monitors the bus to detect this signal and determines whether a pre-start condition has occurred, in addition to the other conditions discussed in fig. 2. Not all signals detected on the bus satisfy the pre-boot condition. For example, data from the crash sensors will not trigger a pre-start of the ECU. Thus, the primary role of the pre-start ECU is to monitor and screen the signals to determine when to pre-start other ECUs. In addition, as described in fig. 3D and 3E, the pre-start ECUs may include data storage and a model for predictively pre-starting the device and adjusting the timing of the pre-start for each ECU. If the pre-start condition is not detected, the ECU in the low power mode continues to operate in the low power mode (block 102).

In block 106, the method pre-activates one or more ECUs in response to determining that a pre-activation condition is satisfied.

In one embodiment, pre-starting the ECUs includes transmitting an energizing signal to the respective ECU. In some embodiments, pre-starting the ECU includes issuing a wake-up signal to the ECU. In some embodiments, the pre-boot signal may include (or be followed by) data regarding the pre-boot condition.

In some embodiments, the method pre-activates all ECUs connected to a shared bus in a vehicle. In some embodiments, each of these ECUs may be pre-activated simultaneously. In other embodiments, the method may selectively pre-activate only a subset of the ECUs. For example, the method may determine that in response to a driver door unlock signal, only those ECUs (e.g., navigation, instrumentation) that the driver uses immediately need to be pre-activated, while other ECUs (e.g., entertainment) may be normally activated. Further description of this type of selective pre-actuation is more fully described in fig. 3D and elsewhere.

In block 108, the method determines whether a timeout has expired.

In some embodiments, the timeout comprises a fixed time interval in which the system causes the ECU to pre-start. In other cases, the timeout may be dynamic based on the operation of the ECU (i.e., updated based on the average time to pre-start). In other embodiments, the method may alternatively wait for a signal from the ECU indicating that the pre-start has been completed. Thus, blocks 108, 110, and 112 may be performed simultaneously for all ECUs or selectively for each ECU.

Generally, block 108 includes failsafe to prevent unnecessarily fully activating the ECU. For example, if a pre-start condition is triggered (block 104) but a full start condition is not detected, the method then powers down the ECU and updates the predictive pre-start model (as described herein). In one embodiment, the start condition includes the operator starting the vehicle (e.g., turning a key or pushing an ignition button). In general, the starting conditions may include any determinative signal (e.g., a remote start command) that may warrant that the vehicle is about to be operated.

In block 110, if the method fails to detect a start condition within the allotted time (or fails to receive a signal indicating that pre-start is complete within the allotted time), the method powers down the ECU. In some embodiments, powering down the ECU includes transmitting a power down signal (or alternatively, a sleep, hibernate, or other low power signal) to the currently pre-activated ECU. The method then continues to operate the ECU in the low power mode (block 102) until the next pre-start condition is detected.

In some embodiments, the pre-start ECU (block 106) may comprise a full start ECU. In this embodiment, if the method determines that a start condition has been detected in block 108, the method ends when all ECUs have been fully activated.

However, in some embodiments, the pre-start ECU does not fully start the ECU. In this embodiment, the ECU may be configured with a basic input/output system (BIOS) that includes a first pre-boot stage. An exemplary startup process is depicted in fig. 6. In this process, a start condition (602) triggers an initial BIOS (604) routine that performs hardware initialization for device boot. After the hardware is verified, the BIOS (604) transfers control to a boot loader (606) stored on a designated sector of the boot device. The boot loader (606) loads the OS (608) into RAM and transfers control to the OS (608).

In the illustrated embodiment, the boot loader (606) is configured to participate in the above operations. That is, the boot loader (606) may be initialized during the pre-boot process, but is configured to wait until a second signal is received indicating that control should be transferred to the OS (608). Alternatively, in block 110), the OS (608) may be modified to halt execution immediately after loading after detecting the boot condition, and wait for instructions to complete the boot process.

In these cases, once the start condition is detected in block 110, the method fully starts the pre-started ECU in block 112. As described above, this process may include instructing each pre-activated ECU to continue activation by transmitting a signal to the pre-activated ECU over the bus.

Fig. 2A is a flow chart illustrating a method (200a) for detecting a pre-boot condition according to some embodiments of the present disclosure.

The illustrated example describes six conditions: (1) door unlocking (202, 204); (2) an operator's seat weight change (206, 208); (3) the vehicle charger is disconnected (210, 212); (4) nearby driver detection (214, 216); (5) an over-the-air start (218, 220); and (6) predictive startup (222, 224). Although illustrated as a series of conditions, the six conditions may be performed in any order. Moreover, not all conditions are required, and less than all conditions can be implemented in any order. Furthermore, the conditions may be performed in parallel rather than sequentially.

In blocks 202 and 204, the method (200a) monitors the locking subsystem (202) of the vehicle and determines whether one or more doors (204) have been unlocked. If so, the method (200a) initiates a pre-boot (206). If not, the method (200a) continues to block 206.

Specific details regarding monitoring the lock subsystem are described in greater detail in FIG. 3A. In general, the particular ECUs participating in door locking and unlocking may vary, but the commands to lock or unlock the doors are transmitted via the vehicle CAN (or similar) bus. In block 202, the method (200a) snoops the bus to determine when an unlock command has been broadcast. The method (200a) may further determine whether the driver side doors are unlocked, all doors are unlocked, or the trunk is unlocked (or a combination thereof). If the method (200a) detects that the doors are unlocked (block 204), the method (200a) transmits a signal to each ECU that requires pre-activation (block 226). If no signal is sniffed, the method (200a) continues.

In blocks 206 and 208, the method (200a) monitors the weight of the seat (206) and, if the weight changes (208), initiates pre-activation (226) of one or more ECUs.

In the illustrated embodiment, one or more seats of the vehicle are equipped with a pressure sensor, a silicon balloon (optional) and an ECU for each seat. When a passenger sits on the seat, the pressure sensor transmits the weight of the passenger to the in-seat ECU, and the in-seat ECU broadcasts the weight to the other ECUs via a CAN (or similar) bus. Generally, an in-seat ECU broadcasts a weight to activate or deactivate a passenger airbag based on the sensed weight of a passenger (adult-to-child), and turns on or off a seat belt indicator light.

In one embodiment, the method (200a) monitors only the CAN bus to detect a change in weight placed on the driver's seat. Details of this operation are described in fig. 3B. In other embodiments, the method (200a) monitors the weight of all seats and selectively pre-activates the ECU based on the weight in each seat and based on which seat signals a change in weight. For example, if the driver seat does not change weight, but the rear seats change weight, the system may selectively pre-activate the infotainment ECU that controls the rear headset display. Alternatively or in combination with the foregoing, the method (200a) may pre-activate a driver center ECU, such as a navigation, dashboard, etc., when a change in driver seat weight is detected. Additionally, the method (200a) may be configured to not pre-start the ECU based on the weight change until the weight threshold is exceeded. In some embodiments, this threshold may be dynamically updated using a predictive model based on sensing weight and correlating seat and weight to known starting conditions.

In blocks 210 and 212, the method (200a) monitors a charger (210) of the vehicle and determines whether the charging cable is disconnected from the charging port (212); if so, the method (200a) initiates a pre-start (226) of one or more ECUs.

In some embodiments where the vehicle comprises an electric or hybrid vehicle, the charging port of the vehicle is equipped with its own ECU that controls charging of the vehicle battery. This ECU transmits various signals indicating the state of charge and whether the charger has been disconnected from the vehicle. The illustrated method (200a) monitors the CAN bus for these messages indicating a disconnection, and begins pre-starting one or more ECUs upon detecting a charger disconnection.

In blocks 214 and 216, the method (200a) monitors nearby drivers or other entities (214), and in response to detecting nearby personnel (216), initiates pre-activation of one or more ECUs (226).

In one embodiment, the method (200a) monitors nearby drivers by determining whether a known wireless signal is in range of the vehicle. In a first embodiment, this may include detecting a radio signal from an electronic key or key fob of the vehicle. In a second embodiment, this may include detecting (via Near Field Communication (NFC) or bluetooth signaling) whether a mobile phone (or other type of portable device) of a known user is nearby.

In some embodiments, the method (200a) triggers the pre-start only when the detected signal is within a preset distance from the vehicle. The method (200a) may estimate the range of the signal by analyzing the signal strength of the received signal using known rules. In other embodiments, the method (200a) may detect the signal and utilize one or more onboard devices to determine the distance. For example, a sonar, lidar, or radar transceiver may be used to determine the range of the user in response to detecting the signal.

In some embodiments, the method (200a) may also determine a direction of movement of the signal. In these embodiments, the method (200a) may sample the signal strength over a window of time to determine whether the signals are approaching, departing, or moving in parallel. If the signal is approaching, the method (200a) may then trigger block 216. If the method (200a) is moving away or in parallel, the method (200a) may ignore the signal until it begins to approach.

In blocks 218 and 202, the method (200a) monitors the bus (218) for an over-the-air (OTA) command, and upon receiving the command (220), initiates a pre-boot (226) of one or more ECUs.

In some embodiments, an operator of a vehicle may operate a mobile device equipped with an application connected to one or more subsystems of the vehicle. These commands may be received by a dedicated ECU (e.g., including a cellular transceiver) that then instructs other ECUs to perform functions based on the received OTA commands.

In the illustrated embodiment, the method (200a) monitors the CAN (or similar) bus of the vehicle to determine if any such OTA commands have been received. In some embodiments, the method (200a) further analyzes the type of OTA command to determine whether to pre-start the ECU. For example, if the OTA command comprises a command to lock a door of the vehicle, the method (200a) may forego pre-starting the ECU. However, if the OTA command includes an unlock door command or a command to start the climate control system, the method (200a) may determine to pre-start the ECU.

In blocks 222 and 224, the method (200a) polls the behavior model (222) and determines whether the current time matches a predicted time at which the user will start the vehicle (224). If so, the method (200a) initiates a pre-start (226) of one or more ECUs.

As more fully described in fig. 3C, the method (200a) may continuously update the model of vehicle launch times and trends. For example, the models may be integrated to conclude that a user typically starts a vehicle between 8:00 and 8:30 a.m. on weekdays, and starts the same vehicle on an irregular basis on weekends. Various algorithms can be used to perform this type of sequence prediction (i.e., predict the next n events given a multi-day event), such as DG (dependency graph), full k-order Markov (All-k-order Markov), TDAG (transition directed acyclic graph), PPM (prediction by partial matching), CPT (compact prediction tree), and CPT + model. In some embodiments, these models (discussed in fig. 3C) may be continuously optimized based on the predicted results.

The embodiment illustrated in fig. 2A illustrates a set of conditions examined by the method (200 a). Alternatively, as described above, FIG. 2B illustrates the same six conditions being performed in parallel. For fig. 2B, the details of the individual blocks (202-226) will not be repeated, and reference is made to the description of those corresponding block presentations in fig. 2A. Notably, in fig. 2B, each condition is tested independently of the other conditions. If all conditions fail, the method (200b) ends. However, if at least one passes, the method (200b) pre-activates the ECU (block 226). As can be seen, more or fewer conditions may be added to the method (200b) depending on the needs of the system.

Fig. 3A is a flow chart illustrating a method for pre-starting an ECU based on monitoring a door unlock signal, according to some embodiments of the present disclosure. Various architectural details of the ECU relating to door locking and unlocking are described in the description of blocks 202 and 204 of fig. 2A and are not repeated herein.

In block 302a, the method (300a) receives a door unlock signal. As described above, in some embodiments, this signal may comprise a message broadcast over a CAN bus or similar bus. Theoretical CAN messages for door unlocking may include:

command	Door 0	Door 1	Door 2	Door 3	Trunk
						Unlocking of	1	0	0	0	0

Where "command" is lock/unlock, and doors 0-3 and the trunk are bit fields indicating whether the command should be applied to the corresponding door/trunk. The precise details of the CAN message for unlocking/locking the door are not intended to be limiting and are provided as examples only. As part of block 302a, the method (300a) screens out any command indicating that the door or trunk should be unlocked.

In block 304a, the method (300a) then classifies the command based on which of the door or the trunk is to be unlocked. As indicated above, this may include checking the unlock command to determine which doors or trunks will be unlocked. In other embodiments, the unlock message may be directed to a particular ECU in the door or trunk. In this embodiment, the method (300a) may extract an identifier of the ECU and map the ECU to a door or trunk.

In block 306a, the method (300a) pre-activates all ECUs if an unlock signal is directed to both the driver door and the passenger door or doors. In operation, generally, this covers the user unlocking all doors of the vehicle. In some embodiments, block 304a includes a short delay before being performed to compensate for the operator first unlocking their doors and then unlocking the other doors or the trunk. As illustrated, if more than one door is open, the method (300a) pre-activates all ECUs in the vehicle.

In block 308a, the method (300a) pre-activates the critical driver ECU only if the driver side door is unlocked only. In this case, the method (300a) selectively pre-activates only those ECUs used by the driver. For example, navigation and dashboard ECUs, as well as climate control and operability ECUs, may be pre-activated. In contrast, the rear seat entertainment ECU may not be pre-activated.

In block 310a, the method (300a) delays pre-starting any ECU upon determining that the user has unlocked the trunk. In this case, the user unlocks the trunk without unlocking any doors, so it can be assumed that the user does not enter the vehicle immediately. In this case, the method (300a) delays pre-boot (310a) and waits in block 312A to determine whether another unlock signal (or other condition discussed in fig. 2A) is received. If another signal is received (e.g., to unlock the driver-side door), the method (300a) performs the previous block. If another signal is not received, the method (300a) ends. In some embodiments, the method (300a) may further detect a signal from a trunk ECU: the trunk is closed, thereby instructing the user to use only the trunk without entering the vehicle.

Fig. 3B is a flow chart illustrating a method for pre-starting an ECU based on a change in weight on a vehicle seat according to some embodiments of the present disclosure. Various architectural details of the ECU relating to weight detection are described in the description of blocks 206 and 208 of fig. 2A and are not repeated herein.

In block 302b, the method (300b) detects a seat weight change.

As discussed above, the in-seat ECU detects the change in weight and broadcasts the detected weight over the CAN (or similar) bus. In block 302b, the method (300b) detects this message, including the weight and the seat identifier, by sniffing the bus.

In block 304b, the method (300b) makes two determinations. First, the method (300b) determines whether the recorded weight is above a predetermined threshold. Next, the method (300b) determines whether the weight is increasing or decreasing.

In the illustrated embodiment, the predetermined threshold may comprise a static value based on an average human weight. In other embodiments, the threshold may be set to an initial value and dynamically adjusted based on the measured weight of the passenger. In a first determination, the method (300b) determines whether the sensed weight is below this threshold (indicating that the weight change may not be due to a person) or above this threshold (indicating that a person is likely to be sitting in the seat).

The second determination includes determining whether the weight is increasing or decreasing. In one embodiment, the method (300b) makes this determination by quickly sampling the weight to determine whether the value is increasing or decreasing.

If the weight exceeds the predefined threshold, the method (300a) pre-activates the ECU (block 306b) as this indicates that a human occupant is seated in the seat. Alternatively, if the weight is below the threshold but increasing, the method (300b) re-executes blocks 302b and 304b until the weight exceeds the threshold or stops changing. This situation, although rare, indicates that the user may be in the process of sitting down, or alternatively, placing a lightweight object on the seat. Finally, if the weight is below the threshold and is not increasing (i.e., decreasing or remaining constant), the method (300b) ends.

FIG. 3C is a flow chart illustrating a method for updating and using a predictive model for pre-starting an ECU, according to some embodiments of the present disclosure.

In block 302c, the method (300c) records a vehicle start time.

In one embodiment, the vehicle start time corresponds to the start time when the start condition is detected (FIG. 1, block 108). In one embodiment, the start time includes a day and a time. In one embodiment, the start time is stored as a record of the start time and is identified by sniffing the CAN bus for ignition start commands.

In block 304c, the method (300c) updates the timing model using the vehicle start time.

As described above, the timing model includes a time-based predictive model that accepts a day and/or time as input parameters and outputs a classification as to whether the current time corresponds to a pre-start condition. Alternatively, the model may output the next expected time at which the pre-start condition will occur. In some embodiments, the model may comprise a DG (dependency graph), a full k-order markov, TDAG (transition directed acyclic graph), PPM (prediction by partial matching), CPT (compact prediction tree), CPT +, or similar model.

In block 306c, the method (300c) waits for the next predicted start time.

As a first example, if a user starts their vehicle between 8:00 and 8:30 on a weekday and inputs a time of 5:00 on the weekday, the model will output a negative result. Alternatively, the model may output the number of minutes (180) until the next predicted start time.

In some implementationsIn an example, the method (300c) periodically polls the model to retrieve the next start time. Thus, the method (300c) at time t₀Time-polling model, and updating the predicted start time t_p0. Whether or not the vehicle is at t_p0Where the method (300c) will all follow at t_p0+ c re-polls the model, where c includes a fixed amount of positive time (e.g., 30 seconds or 2 minutes).

In other embodiments, the method (300c) may poll the model less frequently and schedule one or more times when the model predicts that the vehicle will be started. After a misprediction, the method (300c) may then re-query the model to obtain a new set of scheduled start times.

In step 308c, once the predicted start time occurs, the method (300c) pre-activates the ECU as previously described. The method (300c) then determines whether a start has occurred (310 c). If so, the method (300c) records the start time (302c) and updates the timing model (304c), and loops through the remaining method steps indefinitely.

Alternatively, if the vehicle is not started all the time, the method (300c) powers down the ECU (312c) and records false starts and updates the model (302c, 304c) accordingly to improve the prediction of the model.

Fig. 3D is a flow diagram illustrating a method for using and updating pre-start timing characteristics, according to some embodiments of the present disclosure.

The illustrated method (300d) references the various blocks (106, 108, 110, and 112) of fig. 1, and in fact illustrates various modifications to the method described in fig. 1. The details of the correspondingly numbered blocks are not repeated herein. In the illustrated embodiment, the pre-start of the ECU is modified (block 106), and new blocks (306d-1, 306d-2, 306d-3) are inserted (108) before and after the timeout detection.

During the pre-start process (106), the method (300d) retrieves pre-start timing characteristics (302d) and pre-starts the ECU (304d) based on these timing characteristics.

As used herein, the pre-start timing characteristic refers to the amount of time required to pre-start a given ECU. The amount of time required to achieve the pre-start condition may vary between ECU devices. A low complexity ECU with minimal hardware will necessarily bypass the BIOS level (fig. 6, element 604) faster than more complex ECUs (e.g., infotainment devices, navigation devices). This is illustrated in the pre-start timing graph (306e), where the infotainment ECU (306f) has a 12 second pre-start timing, the meter ECU (306g) has a five second timing, and the navigation ECU (306h) has a nine second timing. In the graph (306e), the start condition may occur at nine seconds, where the infotainment ECU (306f) is not fully pre-started. However, the pre-start phase indicates that all ECUs are in the final pre-start phase at the same time. Since the underlying BIOS phase typically cannot be shortened, changing the pre-boot start time may be implemented to ensure that all ECUs reach the final state at the same time.

Initially, the pre-start timing feature is empty or set to a manufacturer default setting. Gradually, as will be discussed, the timing characteristics of the ECU pre-start phase are recorded and the timing characteristics are updated. In this way, pre-start of certain ECUs (e.g., infotainment) may be initiated immediately, while another device may be delayed slightly. In some cases, if an erroneous start is detected, it may be desirable to delay ECU pre-start to prevent unnecessary operations.

As illustrated, in block 304d, the method uses a pre-boot timing characteristic to selectively defer pre-booting some devices. For example, as illustrated in graph (306j), the infotainment ECU (306f) is pre-started immediately, while the meter ECU (306g) is deferred for seven seconds, and the navigation ECU (306h) is deferred for three seconds. All ECUs are then pre-activated simultaneously.

To generate the timing characteristic, the method (300d) updates the pre-start timing characteristic using one or more probe points (306d-1, 306d-2, 306 d-3). Some or all of the probe points (306d-1, 306d-2, 306d-3) may be implemented in operation. The first point (306d-1) periodically updates the timing before determining the timing or detecting a start command. This ensures that the fast pre-boot device can be identified. For each probe point, the pre-start timing CAN be identified by monitoring the CAN bus for a ready signal from each pre-start ECU. In the second detection point (306d-2), a start condition is triggered and the ECUs should all be pre-activated. However, the probe point (306d-2) may be used to detect any ECU that is not fully pre-started, thus capturing a slow-starting ECU. A third probe point (306d-3) is inserted after a timeout is detected and operates similar to probe point (306 d-2).

In some embodiments, the pre-start phase does not risk lasting longer than the time before start-up. In this case, the timing characteristics may still be used to determine when to start the pre-start-up process. For example, if one or more ECUs take a significant amount of time to pre-start, the method (300d) may use a timing characteristic to increase the range of whether a human being is approaching the vehicle.

Fig. 4 is a block diagram illustrating a system (400) for pre-starting an ECU according to some embodiments of the present disclosure.

In fig. 4, the vehicle (400) may include any type of vehicle (e.g., an automobile, a watercraft, etc.). In general, the vehicle may include any superstructure housing various discrete computing systems, and providing a vehicle as an example, the vehicle (400) includes one or more ECUs (402 a-402 n). Examples of ECUs include a Door Control Unit (DCU), an engine control unit, a Power Steering Control Unit (PSCU), a Human Machine Interface (HMI), a Powertrain Control Module (PCM), a seat control unit, a Speed Control Unit (SCU), a Telematics Control Unit (TCU), a launch control unit (TCU), a brake control module (BCM; ABS or ESC), or a Battery Management System (BMS) device. Although described primarily in the context of an ECU device, any type of embedded computing system may be used with the embodiments disclosed herein, and is provided as an example with reference to embodiments of an ECU device. An exemplary configuration of the EUC is provided in fig. 5 and is not repeated herein.

The ECUs (402a to 402n) are each connected to a bus (404). In some embodiments, the bus (404) comprises a CAN bus, a FlexRay MOST bus, or any other type of bi-directional communication bus.

The processing side of the system includes one or more processors (406), short-term memory (408), an RF system (412), a Graphics Processing Unit (GPU) (414), long-term storage (410), and one or more interfaces (418).

The one or more processors (406) may include a central processing unit, FPGA, or any range of processing devices needed to support operation of the autonomous vehicle. The memory (408) includes DRAM or other suitable volatile RAM for temporarily storing data needed by the processor (406). The RF system (412) may include a cellular transceiver and/or a satellite transceiver. The long-term storage device 410 may include one or more large-capacity solid-state drives (SSDs). In general, long term storage (410) may be used to store, for example, high definition maps, routing data, and any other data that requires permanent or semi-permanent storage. The GPU (414) may comprise one higher-throughput GPU device for processing data received from other vehicle subsystems. Finally, the interface (418) may include various display units (e.g., built-in screens) positioned within the vehicle. In the illustrated embodiment, the memory (408) and/or storage (410) includes pre-boot software configured to perform the previously described methods.

Fig. 5 is a block diagram of an ECU according to some embodiments of the present disclosure.

In the illustrated embodiment, the ECU (500) is communicatively coupled to a bus (508) via an interface (506). As discussed above, the bus (508) may comprise a CAN, FlexRay, MOST bus, or similar type of bus. Correspondingly, the interface (506) may comprise a similar interface for accessing the particular type of bus used.

The ECU (500) additionally includes a microcontroller (502), an R/F subsystem (510), an Application Specific Component (ASC) (512), and a memory system (504). In the illustrated embodiment, the microcontroller (502) may include a processor or smaller microcontroller configured to control the operation of the ECU (500). In some embodiments, the microcontroller (502) accesses program instructions stored in the memory system (504) and drives the ASC (512) according to those instructions. Examples of ASCs (512) include actuators for door control, display units for infotainment ECUs, launch control devices for TCUs, and various other controls. The type of ASC employed by the ECU (500) is not limiting, and any type of ASC may be employed by the ECU (500).

The ECU (500) additionally includes an R/F system (510). In the illustrated embodiment, the R/F system (510) may include one or more radios or transceivers for communicating with a wireless network. The R/F system (510) may include a Bluetooth, Wi-Fi, or cellular radio or satellite transceiver. In some embodiments, the R/F system (510) includes a combination of radios or transceivers. In some embodiments, the ECU (500) may not include the R/F system (510), and may instead utilize a vehicle wide R/F system, as previously described.

The microcontroller (502) manages the memory system (504). In the illustrated embodiment, the memory system (504) includes SRAM (504a), EEPROM (504b), and flash storage (504 c). In the illustrated embodiment, the SRAM (504a) may be used as an L1 or L2 cache for the microcontroller (502). Similarly, the EEPROM (504b) can be used as a firmware storage device of the ECU (500). The specific details (or presence) of SRAM (504a) and EERPOM (504b) are not limiting.

The memory system 504 additionally includes a flash storage device 504 c. In the illustrated embodiment, the flash memory device (504c) comprises a NAND flash memory device that is soldered to a PCB and connected (via the PCB) to the other components depicted in fig. 5. The flash memory device (504c) is used to store operating codes and data used by the ECU (500) as previously described.

The present disclosure now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific example embodiments. However, the subject matter may be embodied in many different forms and, thus, it is intended that the subject matter covered or claimed is not to be construed as limited to any example embodiment set forth herein; the example embodiments are provided for illustration only. Also, it is intended to provide a reasonably broad scope for claimed or covered subject matter. The subject matter may be embodied as, for example, a method, apparatus, component, or system, among others. Thus, an embodiment may take the form of hardware, software, firmware, or any combination thereof (other than software itself), for example. The following detailed description is, therefore, not to be taken in a limiting sense.

Throughout the specification and claims, terms may have any nuances referred to or implied by their context, other than those expressly set forth. Likewise, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment. For example, claimed subject matter is intended to encompass combinations of all or portions of the exemplary embodiments.

In general, terms may be at least partially understood in light of the use in context. For example, terms such as "and," "or," or "and/or" as used above may include a variety of meanings that may depend at least in part on the context in which such terms are used. Generally, "or" if used in conjunction with a list (e.g., A, B or C) is intended to mean A, B and C, used herein in an inclusive sense, and A, B or C, used herein in an exclusive sense. In addition, the term "one or more" as used herein may be used in the singular to describe any feature, structure, or characteristic, or may be used in the plural to describe a combination of features, structures, or characteristics, depending, at least in part, on the context. Similarly, terms such as "a" or "the" may also be understood to convey a singular use or to convey a plural use, depending at least in part on the context. Additionally, the term "based on" may be understood as not necessarily intended to convey an exclusive set of factors, and instead may allow for the presence of additional factors that are not necessarily explicitly described, depending at least in part on context.

The present disclosure has been described with reference to block diagrams and operational illustrations of methods and apparatus. It will be understood that each block of the block diagrams or operational illustrations, and combinations of blocks in the block diagrams or operational illustrations, can be implemented by means of analog or digital hardware and computer program instructions. These computer program instructions may be provided to a general purpose processor, a special purpose computer, an ASIC, or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the functions/acts specified in the block diagrams or operational block or blocks. In some alternative implementations, the functions/acts noted in the blocks may occur out of the order noted in the operational illustrations. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

For purposes of this disclosure, a computer-readable medium (or computer-readable storage medium) stores computer data, which may include computer program code (or computer-executable instructions) that may be executed by a computer in a machine-readable form. By way of example, and not limitation, computer-readable media may comprise computer-readable storage media for tangible or fixed storage of data or communication media for temporary interpretation of a signal containing code. Computer-readable storage media, as used herein, refers to physical or tangible storage devices (as opposed to signals), and includes, but is not limited to, volatile and nonvolatile, removable and non-removable media implemented in any method or technology for the tangible storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical or physical medium which can be used to tangibly store the desired information or data or instructions and which can be accessed by a computer or processor.