Pre-start of automotive electronic control unit for improving human-machine interface performance

Abstract

Apparatus and method for improving pre-startup of an electronic control unit device in a vehicle are disclosed. In one embodiment, a method is disclosed that includes: detecting a trigger of a pre-startup condition based on one or more interactions with the vehicle; transmitting a power-on 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 starting the at least one ECU immediately after determining that the vehicle has started.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 374,287, filed on April 3, 2019, and entitled "AUTOMOTIVE ELECTRONIC CONTROL UNIT PRE-BOOTING FOR IMPROVED MAN-MACHINE INTERFACE PERFORMANCE", the entire disclosure of which is hereby incorporated herein by reference.

[0003] Copyright Notice

[0004] This application contains copyrighted material. The copyright owner does not object to the facsimile reproduction by anyone of the patent disclosure as it appears in the Patent and Trademark Office files or records, but reserves all copyrights whatsoever. BACKGROUND OF THE DISCLOSURE

[0005] The disclosed embodiments are directed to in-vehicle computing systems, and more particularly, to apparatus and methods for pre-booting electronic control units (ECUs) in a vehicle.

[0006] Modern vehicles contain a dozen or more ECUs. These ECUs can be used for infotainment systems or can serve as critical systems in, for example, autonomous vehicles. The software in the ECUs generally includes a complex operating system and an application layer software stack. Booting this software can typically take several seconds, even for the simplest ECU devices. However, many ECUs on modern vehicles need to start as quickly as possible, and typically within one second of starting the vehicle. For example, automotive radios, rearview cameras, instrument clusters, network devices, etc. typically need to start immediately when the vehicle is started. However, the existing architecture of the vehicle requires such ECUs to start from a powered-off state only in response to the vehicle starting. Therefore, these ECUs are not able to provide near-instantaneous startup.

[0007] The disclosed embodiments address these and other technical problems by providing a pre-booting procedure to speculatively start ECUs in a vehicle based on one or more detected conditions, thereby improving the operation of the ECUs. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The foregoing and other objects, features, and advantages of the present disclosure will be apparent from the following description of embodiments as illustrated in the accompanying drawings, in which like reference numerals refer to like parts throughout the figures. The drawings are not necessarily to scale; in fact, the emphasis is on illustrating the principles of the present disclosure.

[0009] Figure 1Flowchart for a method for pre - starting an ECU according to some embodiments of the present disclosure.

[0010] Figure 2A Flowchart for a method for detecting pre - start conditions according to some embodiments of the present disclosure.

[0011] Figure 2B Flowchart for a method for detecting pre - start conditions according to some embodiments of the present disclosure.

[0012] Figure 3A Flowchart for a method for pre - starting an ECU based on detecting a door unlock signal according to some embodiments of the present disclosure.

[0013] Figure 3B Flowchart for 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.

[0014] Figure 3C Flowchart for a method for updating and using a prediction model for pre - starting an ECU according to some embodiments of the present disclosure.

[0015] Figure 3D Flowchart for a method for using and updating pre - start timing characteristics according to some embodiments of the present disclosure.

[0016] Figure 4 Block diagram for a system for pre - starting an ECU according to some embodiments of the present disclosure.

[0017] Figure 5 Block diagram for an ECU according to some embodiments of the present disclosure.

[0018] Figure 6 Block diagram for a starting process according to some embodiments of the present disclosure. Detailed Description

[0019] The disclosed embodiments describe systems, devices, methods, and computer - readable media for pre - starting a vehicle ECU in response to detecting pre - start conditions. Additionally, specific details regarding the types of pre - start conditions and how to analyze these conditions are provided in other embodiments. Finally, the disclosed embodiments describe how to utilize a prediction model to pre - start an ECU device and optimize the timing of pre - start in response to pre - start condition detection. The disclosed embodiments improve the time - to - start of the ECU device, resulting in a perceived "instantaneous" effect of the ECU output.

[0020] Figure 1 Flowchart for a method for pre - starting an ECU according to some embodiments of the present disclosure.

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

[0022] 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 not executed. In sleep or standby mode, the device state is typically stored in random access memory (RAM), while unnecessary subsystems (e.g., display, peripherals, etc.) are powered off. Additionally, the 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 hibernate, the state of the device may additionally be saved to a non-volatile storage device. In this way, if power to the RAM is completely lost, the device can be restarted to its existing state. In power-off mode, all components of the device are powered off.

[0023] The specific state that a given ECU is in can vary depending on the type of ECU and the operating scenario when the vehicle housing the ECU is turned off. In some cases, depending on the requirements of the ECU, the ECU may be completely powered off, may be placed in standby mode, or may vary step by step from powered on to standby to powered off. Generally, the ECUs of an automobile will mainly transition to the low power state when the vehicle stops and the vehicle key is removed or otherwise a signal indicating that the vehicle is no longer in use is given (e.g., the remote key is removed from the detection range of the vehicle). The specific mechanism for placing the ECU in the low power state is not intended to limit the disclosed embodiments.

[0024] In block 104, the method determines whether a pre-start condition is met. The details of the specific pre-start condition are more fully described in the descriptions of FIGS. 2 and 3A to 3D and are not repeated in detail herein.

[0025] 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 continuously monitor the states of various other ECUs in the vehicle. In one embodiment, the pre-start ECU monitors a vehicle bus (e.g., a controller area network bus) for signals transmitted to and from ECUs or other components. As an example, an ECU that controls the locking of a door may broadcast or transmit a signal that it senses an unlocked door. The pre-start ECU monitors the bus to detect this signal and, in addition to other conditions discussed in FIG. 2, also determines whether a pre-start condition has occurred. Not all signals detected on the bus meet the pre-start condition. For example, data from a collision sensor will not trigger a pre-start of the ECU. Thus, the main role of the pre-start ECU is to monitor and filter signals to determine when to pre-start other ECUs. Additionally, as Figure 3DAs described in, the pre-start ECU may include a data storage device and a model for predictively pre-starting the device and adjusting the timing of the pre-start for each ECU. If a pre-start condition is not detected, the ECU in the low power mode continues to operate in the low power mode (block 102).

[0026] In block 106, the method pre-starts one or more ECUs in response to determining that a pre-start condition is met.

[0027] In one embodiment, the pre-start ECU includes transmitting a power-on signal to the corresponding ECU. In some embodiments, the pre-start ECU includes issuing a wake-up signal to the ECU. In some embodiments, the pre-start signal may include (or be followed by) data regarding the pre-start condition.

[0028] In some embodiments, the method pre-starts all ECUs in the vehicle connected to a shared bus. In some embodiments, each of these ECUs may be pre-started simultaneously. In other embodiments, the method may selectively pre-start only a subset of the ECUs. For example, the method may determine that in response to a driver door unlock signal, only those ECUs that the driver will immediately use (e.g., navigation, instrument cluster) need to be pre-started, while other ECUs (e.g., entertainment) may be started normally. Further description of this type of selective pre-start is described more fully in Figure 3D and elsewhere.

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

[0030] In some embodiments, the timeout includes a fixed time interval during which the system pre-starts the ECU. 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.

[0031] Generally, block 108 includes a fail-safe to prevent unnecessary full startup of 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 off 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 the key or pressing the ignition button). Generally, the start condition may include any decisive signal that can ensure that the vehicle is about to be operated (e.g., a remote start command).

[0032] 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-startup has been completed 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-started ECU. The method then continues to operate the ECU in a low-power mode (block 102) until the next pre-start condition is detected.

[0033] In some embodiments, pre-starting the ECU (block 106) may include fully starting the 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 started.

[0034] 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-start level. Figure 6 The exemplary startup process is depicted in. In this process, the start condition (602) triggers the initial BIOS (604) routine that performs the hardware initialization for starting the device. After verifying the hardware, the BIOS (604) transfers control to the boot loader (606) stored on the designated sector of the boot device. The boot loader (606) loads the OS (608) into the RAM and transfers control to the OS (608).

[0035] In the illustrated embodiment, the boot loader (606) is configured to participate in the above operations. That is, the boot loader (606) can be initialized during the pre-start process but is configured to wait until it receives a second signal indicating that control should be transferred to the OS (608). Alternatively, in block 110, the OS (608) can be modified to pause execution immediately after loading and wait for an instruction to complete the startup process after detecting the start condition.

[0036] 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 can include indicating to each pre-started ECU to continue starting by transmitting a signal via the bus to the pre-started ECU.

[0037] Figure 2A A flowchart illustrating a method (200a) for detecting a pre-start condition according to some embodiments of the present disclosure.

[0038] The illustrated embodiments describe six conditions: (1) door unlock (202, 204); (2) driver seat weight change (206, 208); (3) vehicle charger disconnect (210, 212); (4) nearby driver detection (214, 216); (5) air start (218, 220); and (6) predictive start (222, 224). Although described as a series of conditions, the six conditions may be performed in any order. Additionally, not all conditions are required, and fewer than all conditions may be implemented in any order. Further, the conditions may be performed in parallel rather than sequentially.

[0039] In blocks 202 and 204, method (200a) monitors the vehicle's locking subsystem (202) and determines whether one or more doors have been unlocked (204). If so, method (200a) triggers a pre-start (206). If not, method (200a) proceeds to block 206.

[0040] Specific details regarding monitoring the locking subsystem are described in more detail in Figure 3A Generally, the specific ECUs involved in door locking and unlocking may vary, but commands to lock or unlock the doors are transmitted via the vehicle CAN (or similar) bus. In block 202, method (200a) sniffs the bus to determine when an unlock command has been broadcast. Method (200a) may further determine whether the driver side door is unlocked, all doors are unlocked, or the trunk is unlocked (or a combination thereof). If method (200a) detects that a door has been unlocked (block 204), method (200a) transmits a signal to each ECU that requires a pre-start (block 226). If no signal is sniffed, method (200a) continues.

[0041] In blocks 206 and 208, method (200a) monitors the weight of the seat (206), and if the weight changes (208), triggers a pre-start (226) of one or more ECUs.

[0042] In the illustrated embodiments, one or more seats of the vehicle are equipped with pressure sensors, silicon balloons (optional), and an ECU for each seat. When a passenger sits on the seat, the pressure sensor transmits the passenger's weight to the in-seat ECU, and the in-seat ECU broadcasts the weight to other ECUs via the CAN (or similar) bus. Generally, the in-seat ECU broadcasts the weight to enable or disable the passenger airbag based on the perceived weight of the passenger (adult vs. child), and to turn on or off the seatbelt indicator.

[0043] In one embodiment, method (200a) only monitors the CAN bus to detect a change in the weight placed on the driver seat. In Figure 3BDetails of this operation are described herein. In other embodiments, method (200a) monitors the weight of all seats and selectively pre-starts the ECU based on the weight in each seat and based on which seat signals a change in weight. For example, if the driver's seat does not change weight but the rear seat changes weight, the system may selectively pre-start the infotainment ECU that controls the rear seat head-mounted display. Alternatively or in combination with the foregoing, when a change in the weight of the driver's seat is detected, method (200a) may pre-start the driver-centric ECU such as navigation, instrument cluster, etc. Additionally, method (200a) may be configured to pre-start the ECU based on a weight change only until a weight threshold is exceeded. In some embodiments, this threshold may be dynamically updated using a predictive model based on sensed weight and associating the seat and weight with known start conditions.

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

[0045] In some embodiments where the vehicle includes an electric vehicle or a hybrid vehicle, the vehicle's charging port is equipped with its own ECU that controls the charging of the vehicle battery. This ECU emits 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 disconnection and begins pre-starting one or more ECUs immediately after detecting the charger disconnection.

[0046] In blocks 214 and 216, method (200a) monitors for nearby drivers or other entities (214) and, in response to detecting a nearby person (216), triggers the pre-start of one or more ECUs (226).

[0047] In one embodiment, method (200a) monitors for nearby drivers by determining whether a known wireless signal is within the range of the vehicle. In a first embodiment, this may include detecting a radio signal from the vehicle's electronic key or fob. 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.

[0048] In some embodiments, the method (200a) triggers pre - start only when the detected signal is within a preset distance from the vehicle. The method (200a) can estimate the distance of the signal by analyzing the signal strength of the received signal using known rules. In other embodiments, the method (200a) can detect the signal and use one or more on - board devices to determine the distance. For example, sonar, lidar, or radar transceivers can be used to determine the user's distance in response to detecting the signal.

[0049] In some embodiments, the method (200a) can also determine the direction of movement of the signal. In these embodiments, the method (200a) can sample the signal strength within a time window to determine whether the signal is approaching, moving away, or moving parallel. If the signal is approaching, the method (200a) can then trigger block 216. If the method (200a) is moving away or parallel, the method (200a) can ignore the signal until it starts to approach.

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

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

[0052] In the illustrated embodiment, the method (200a) monitors the vehicle's CAN (or similar) bus 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 includes a command to lock the vehicle's doors, the method (200a) can 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) can determine to pre - start the ECU.

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

[0054] As in Figure 3CMore fully described in, the method (200a) can sustainably update the model of vehicle start-up time and trend. For example, the model can comprehensively conclude that the user usually starts the vehicle between 8:00 and 8:30 in the morning on weekdays, and starts the same vehicle irregularly on weekends. Various algorithms can be used to perform this type of sequential prediction (i.e., given multi-day events, predict the next n events), such as DG (Dependency Graph), All-k-order Markov, TDAG (Transition Directed Acyclic Graph), PPM (Prediction by Partial Matching), CPT (Compact Prediction Tree), and CPT+ models. In some embodiments, these models can be continuously optimized based on the prediction results (discussed in Figure 3C ).

[0055] In Figure 2A the illustrated embodiment illustrates a set of series conditions checked by the method (200a). Alternatively, as described above, Figure 2B illustrates the same six conditions executed in parallel. For Figure 2B , the details of the individual boxes (202 to 226) will not be repeated, and reference is made to the descriptions presented in the corresponding boxes in Figure 2A . It is worth noting that in Figure 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-starts the ECU (box 226). As can be seen, more or fewer conditions can be added to the method (200b) according to the needs of the system.

[0056] Figure 3A Is a flowchart illustrating a method for pre-starting an ECU based on a monitored door unlock signal according to some embodiments of the present disclosure. Various architectural details of the ECU related to door locking and unlocking are described in the descriptions of boxes 202 and 204 in Figure 2A and will not be repeated here.

[0057] In box 302a, the method (300a) receives a door unlock signal. As described above, in some embodiments, this signal can include a message broadcast on the CAN bus or a similar bus. The theoretical CAN message for door unlocking can include:

[0058] Command Door 0 Door 1 Door 2 Door 3 Trunk Unlock 1 0 0 0 0

[0059] where "command" is lock / unlock, and doors 0 to 3 and the trunk are bit fields indicating whether the command should apply to the corresponding door / trunk. The exact details of the CAN message for unlocking / locking the doors are not intended to be restrictive and are provided only as an example. As part of box 302a, the method (300a) filters out any commands indicating that a door or trunk should be unlocked.

[0060] In block 304a, method (300a) then classifies the command based on which of the door or the trunk is to be unlocked. As indicated above, this can include examining the unlock command to determine which doors or the trunk are to be unlocked. In other embodiments, the unlock message can be directed to a specific ECU in the door or the trunk. In this embodiment, method (300a) can extract the identifier of the ECU and map the ECU to the door or the trunk.

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

[0062] In block 308a, method (300a) pre-starts only the critical driver ECUs only when only the driver side door is unlocked. In this case, method (300a) selectively pre-starts only those ECUs used by the driver. For example, the navigation and instrument cluster ECUs and the climate control and drivability ECUs can be pre-started. In contrast, the rear seat entertainment ECU may not be pre-started.

[0063] In block 310a, method (300a) delays pre-starting any ECUs immediately after 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 immediately enter the vehicle. In this situation, method (300a) delays pre-starting (310a) and waits in block 312a to determine if another unlock signal (or Figure 2A other conditions discussed therein) is received. If another signal is received (e.g., unlocking the driver side door), method (300a) executes the previous blocks. If another signal is not received, method (300a) ends. In some embodiments, method (300a) can further detect a signal from the trunk ECU: closing the trunk, thereby indicating that the user is only using the trunk and not entering the vehicle.

[0064] Figure 3B A flowchart 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 involved in weight detection are described in the descriptions of blocks 206 and 208 in Figure 2A and are not repeated herein.

[0065] In block 302b, method (300b) detects a change in seat weight.

[0066] As discussed above, the ECU within the seat detects the change in weight and broadcasts the detected weight via a CAN (or similar) bus. In block 302b, method (300b) detects this message containing the weight and the seat identifier by sniffing the bus.

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

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

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

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

[0071] Figure 3C A flowchart illustrating a method for updating and using a prediction model for pre-starting an ECU according to some embodiments of the present disclosure.

[0072] In block 302c, method (300c) records the vehicle start time.

[0073] In one embodiment, the vehicle start time corresponds to the start time when a start condition is detected ( Figure 1 , block 108). In one embodiment, the start time includes the date and 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 an ignition start command.

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

[0075] As described above, the timing model includes a time-based prediction model that takes the 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 can output the next expected time at which the pre-start condition will occur. In some embodiments, the model can include a DG (dependency graph), full k-order Markov, TDAG (transition directed acyclic graph), PPM (prediction by partial matching), CPT (compact prediction tree), CPT+, or a similar model.

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

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

[0078] In some embodiments, the method (300c) periodically polls the model to retrieve the next start time. Thus, the method (300c) polls the model at time t0 and updates the predicted start time t p0 . Regardless of whether the vehicle starts at t p0 , the method (300c) will then repoll the model at t p0 +c, where c includes a fixed positive amount of time (e.g., 30 seconds or 2 minutes).

[0079] In other embodiments, the method (300c) can poll the model less frequently and schedule one or more times when the model predicts that the vehicle will start. After a misprediction, the method (300c) can then repoll the model to obtain a new set of scheduled start times.

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

[0081] Alternatively, if the vehicle never starts, the method (300c) powers down the ECU (312c), and accordingly records an error start and updates the model (302c, 304c) to improve the model's prediction.

[0082] Figure 3DFlowchart for illustrating a method for using and updating pre - startup timing characteristics according to some embodiments of the present disclosure.

[0083] The illustrated method (300d) refers to Figure 1 each of the blocks (106, 108, 110, and 112), and actually illustrates various modifications to the Figure 1 method described in. Details of the correspondingly numbered blocks are not repeated herein. In the illustrated embodiment, the pre - startup of the ECU is modified (block 106), and new blocks (306d - 1, 306d - 2, 306d - 3) (108) are inserted before and after the timeout detection.

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

[0085] As used herein, the pre - startup timing characteristics refer to the amount of time required to pre - start a given ECU. The amount of time required to obtain the pre - startup state can vary between ECU devices. A low - complexity ECU with minimal hardware will necessarily bypass the BIOS level ( Figure 6 , element 604), faster than a more complex ECU (e.g., an infotainment device, a navigation device). This is illustrated in the pre - startup timing graph (306e), where the infotainment ECU (306f) has a 12 - second pre - startup timing, the instrument ECU (306g) has a five - second timing, and the navigation ECU (306h) has a nine - second timing. In the graph (306e), the start condition can occur at nine seconds, where the infotainment ECU (306f) is not fully pre - started. However, the pre - startup phase indicates that all ECUs are in the final pre - startup phase simultaneously. Since the underlying BIOS phase generally cannot be shortened, the pre - startup start time can be changed to ensure that all ECUs reach the final state simultaneously.

[0086] Initially, the pre - startup timing characteristics are empty or set to the manufacturer's default settings. Gradually, as will be discussed, the timing characteristics of the ECU pre - startup phase are recorded and the timing characteristics are updated. In this way, the pre - startup of some ECUs (e.g., infotainment) can start immediately, while another device can be slightly delayed. In some cases, if a mis - start is detected, delaying the ECU pre - startup can be desirable to prevent unnecessary operations.

[0087] As illustrated, in block 304d, the method uses the pre - startup timing characteristics to selectively postpone the pre - startup of some devices. For example, as illustrated in the graph (306j), the infotainment ECU (306f) pre - starts immediately, while the instrument ECU (306g) is postponed by seven seconds, and the navigation ECU (306h) is postponed by three seconds. All ECUs are then pre - started simultaneously.

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

[0089] In some embodiments, the pre-start phase does not have a risk of lasting longer than the time before starting. In this case, the timing characteristics can still be used to determine when to start the pre-start process. For example, if one or more ECUs take a relatively long time to pre-start, method (300d) can use the timing characteristics to increase the range for detecting whether a person is approaching the vehicle.

[0090] Figure 4 A block diagram of a system (400) for pre-starting an ECU according to some embodiments of the present disclosure is illustrated.

[0091] In Figure 4 , the vehicle (400) can include any type of vehicle (e.g., an automobile, a ship, etc.). Generally, a vehicle can include any superstructure that houses various discrete computing systems, and by way of example of a vehicle, the vehicle (400) includes one or more ECUs (402a to 402n). 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 transmission control unit (TCU), a brake control module (BCM; ABS or ESC), or a battery management system (BMS) device. Although mainly described in the context of ECU devices, any type of embedded computing system can be used in the embodiments disclosed herein, and the embodiments with reference to ECU devices are provided by way of example. An exemplary configuration of EUC is provided in Figure 5 and is not repeated herein.

[0092] Each ECU (402a to 402n) is connected to a bus (404). In some embodiments, the bus (404) includes a CAN bus, a FlexRay MOST bus, or any other type of bi-directional communication bus.

[0093] The processing side of the system includes one or more processors (406), a short-term memory (408), an RF system (412), a graphics processing unit (GPU) (414), a long-term storage device (410), and one or more interfaces (418).

[0094] The one or more processors (406) may include a central processing unit, an FPGA, or any range of processing devices required to support the operation of an autonomous vehicle. The memory (408) includes DRAM or other suitable volatile RAM for temporarily storing data required 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 high-capacity solid state drives (SSDs). Generally, the long-term storage device (410) can 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 include a 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) located within the vehicle. In the illustrated embodiment, the memory (408) and / or the storage device (410) contains pre-boot software configured to execute the methods described previously.

[0095] Figure 5 It is a block diagram of an ECU according to some embodiments of the present disclosure.

[0096] 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 include a CAN, FlexRay, MOST bus, or a similar type of bus. Correspondingly, the interface (506) may include a similar interface for accessing the particular type of bus being used.

[0097] The ECU (500) further 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 a 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 the ASC (512) include actuators for door control, display units for infotainment ECUs, transmission control devices for TCUs, and various other controls. The type of ASC employed by the ECU (500) is not restrictive, and the ECU (500) may employ any type of ASC.

[0098] The ECU (500) additionally includes an R / F system (510). In the illustrated embodiment, the R / F system (510) may include one or more radio devices or transceivers for communicating with a wireless network. The R / F system (510) may include Bluetooth, Wi-Fi, or cellular radio devices or satellite transceivers. In some embodiments, the R / F system (510) includes a combination of radio devices 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.

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

[0100] The memory system (504) further includes a flash memory device (504c). In the illustrated embodiment, the flash memory device (504c) includes a NAND flash memory device that is soldered to the PCB and connected (via the PCB) to Figure 5 the other components depicted. The flash memory device (504c) is used to store the operating code and data used by the ECU (500) as previously described.

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

[0102] Throughout the specification and claims, the terms may have nuanced meanings that are presented or implied in the context, beyond the explicitly stated meanings. Similarly, as used herein, the phrase "in one embodiment" does not necessarily refer to the same embodiment, and the phrase "in another embodiment" does not necessarily refer to a different embodiment. For example, the claimed subject matter is intended to encompass combinations of whole or partial example embodiments.

[0103] Generally, the terms may be understood, at least in part, according to their use in context. For example, terms such as "and," "or," or "and / or" as used above may have multiple meanings, which may depend, at least in part, on the context in which such terms are used. Generally, "or" when used to combine a list (such as A, B, or C) is intended to mean A, B, and C, here used in an inclusive sense, as well as A, B, or C, here used in an exclusive sense. Additionally, at least in part depending on the context, the term "one or more" as used herein may be used to describe any feature, structure, or characteristic in a singular sense, or may be used to describe a combination of features, structures, or characteristics in a plural sense. Similarly, at least in part depending on the context, terms such as "a / an" or "the" may also be understood to convey a singular use or convey a plural use. Additionally, the term "based on" may be understood to not necessarily convey a set of exclusive factors, and instead may, at least in part, depending on the context, allow for additional factors that are not necessarily explicitly described.

[0104] The present disclosure has been described with reference to block diagrams and operational illustrations of methods and apparatuses. It should 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 can be provided to a general-purpose processor, a special-purpose computer, an ASIC, or other programmable data processing devices, such that the instructions executed via the processor of the computer or other programmable data processing devices implement the functions / actions specified in the block diagrams or operational blocks. In some alternative embodiments, the functions / actions labeled in the blocks may not occur in the order labeled in the operational illustrations. For example, depending on the functionality / action involved, two consecutively presented blocks may actually be executed substantially in parallel or the blocks may sometimes be executed in reverse order.

[0105] For the purposes of the present disclosure, a computer-readable medium (or computer-readable storage medium) stores computer data, which may include computer program code (or computer-executable instructions) that can be executed by a computer in a machine-readable form. By way of example and not limitation, a computer-readable medium may include a computer-readable storage medium for tangible or fixed storage of data, or a communication medium for transient interpretation of signals containing code. As used herein, a computer-readable storage medium refers to a physical or tangible storage device (as opposed to a signal) and includes, but is not limited to, volatile and non-volatile, removable and non-removable media implemented by any method or technology for 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 technologies, CD-ROM, DVD or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical or material medium that can be used to tangibly store the desired information or data or instructions and that can be accessed by a computer or processor.

Claims

1. A method for pre - starting an electronic control unit in a vehicle, comprising: Detecting a trigger of a pre - start condition based on one or more interactions with the vehicle; In response to detecting the trigger of the pre - start condition, selectively transmitting a power - on signal to a subset of electronic control units (ECUs) in the vehicle, the ECUs operating in a low - power state; and Fully starting the subset of ECUs immediately after determining that the vehicle has started.

2. The method according to claim 1, further comprising powering off the subset of ECUs immediately after determining that the vehicle has not started.

3. The method according to claim 1, wherein the detecting a trigger of the pre - start condition includes one or more of the following: Detecting a door unlock signal; Detecting a change in the weight of a seat of the vehicle; Detecting a person near the vehicle; Detecting an over - the - air command received by the ECU of the vehicle; or Polling a behavior model using the current date and time.

4. The method according to claim 3, wherein the detecting a door unlock signal includes: Detecting whether the driver - side door has received the door unlock signal and, in response, pre - starting the key driver ECU; Detecting whether a passenger door has received the door unlock signal and, in response, pre - starting an additional ECU; or Detecting whether a trunk has received the door unlock signal and, in response, pre - starting a delayed ECU.

5. The method according to claim 3, wherein the detecting a change in the weight of a seat of the vehicle includes detecting whether the current weight exceeds a predetermined threshold.

6. The method according to claim 3, wherein the polling a behavior model using the current date and time includes continuously updating a time - based prediction model based on the historical start time of the vehicle and pre - starting the subset of ECUs immediately after determining that the current time is predicted by the time - based prediction model to correspond to the start time of the vehicle.

7. The method according to claim 1, further comprising storing and updating a set of pre - start timing characteristics that control the timing of pre - starting the subset of ECUs.

8. An apparatus for pre - starting an electronic control unit in a vehicle, 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 following steps: Detecting a trigger of a pre - start condition based on one or more interactions with the vehicle; In response to detecting the trigger of the pre - start condition, selectively transmitting a power - on signal to a subset of electronic control units (ECUs) in the vehicle, the ECUs operating in a low - power state; and Fully starting the subset of ECUs immediately after determining that the vehicle has started.

9. The apparatus according to claim 8, wherein the stored program logic further causes the processor to perform the step of powering off the subset of ECUs immediately after determining that the vehicle has not started.

10. The apparatus according to claim 8, wherein the detecting a trigger of the pre - start condition includes one or more of the following: Detecting a door unlock signal; Detecting a change in the weight of a seat of the vehicle; Detect a person near the vehicle; Detect an over-the-air command received by the vehicle's ECU; or Poll a behavior model using the current day and time.

11. The apparatus according to claim 10, wherein the detecting the door unlock signal comprises: Detect whether the driver's side door has received the door unlock signal and, in response, pre-activate the critical driver ECU; Detect whether the passenger door has received the door unlock signal and, in response, pre-activate an additional ECU; or Detect whether the trunk has received the door unlock signal and, in response, delay the pre-activation of the ECU.

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

13. The apparatus according to claim 10, wherein the polling the behavior model using the current day and time comprises continuously updating a time-based prediction model based on a historical start time of the vehicle and, upon determining that the current time is predicted by the time-based prediction model to correspond to a start time of the vehicle, immediately pre-activate a subset of the ECUs.

14. The apparatus according to claim 8, further comprising storing and updating a set of pre-activation timing characteristics that control the timing of pre-activating the subset of the ECUs.

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 following steps: Detect the triggering of a pre-activation condition based on one or more interactions with a vehicle; In response to detecting the triggering of the pre-activation condition, selectively transmit a power-on signal to a subset of electronic control units (ECUs) in the vehicle, the ECUs operating in a low-power state; and Fully activate the subset of the ECUs immediately after determining that the vehicle has started.

16. The non-transitory computer-readable storage medium according to claim 15, wherein the computer program instructions further define the step of powering off the subset of the ECUs immediately after determining that the vehicle has not started.

17. The non-transitory computer-readable storage medium according to claim 15, wherein the detecting the triggering of the pre-activation condition comprises one or more of the following: Detecting a door unlock signal; Detecting a change in weight of a seat of the vehicle; Detecting a person near the vehicle; Detecting an over-the-air command received by the vehicle's ECU; or Polling a behavior model using the current day and time.

18. The non-transitory computer-readable storage medium according to claim 17, wherein the detecting the door unlock signal comprises: Detecting whether the driver's side door has received the door unlock signal and, in response, pre-activating the critical driver ECU; Detecting whether the passenger door has received the door unlock signal and, in response, pre-activating an additional ECU; or Detecting whether the trunk has received the door unlock signal and, in response, delaying the pre-activation of the ECU.

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

20. The non-transitory computer-readable storage medium according to claim 17, wherein said polling the behavior model using the current date and time includes continuously updating a time-based prediction model based on the historical start time of the vehicle, and pre-starting a subset of the ECUs immediately after determining that the current time is predicted by the time-based prediction model to correspond to the start time of the vehicle.

21. The non-transitory computer-readable storage medium according to claim 15, further comprising storing and updating a set of pre-start timing characteristics that control the timing of pre-starting a subset of the ECUs.

Images