CN108725352B

CN108725352B - Vehicle control module activation to determine driving route in ignition off state

Info

Publication number: CN108725352B
Application number: CN201810326436.8A
Authority: CN
Inventors: 阿伦·杜塔; 贾斯丁·卡特莱特; 农西奥·德西亚; 大卫·A·赫尔曼; 比尔·C·迪克
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-04-19
Filing date: 2018-04-12
Publication date: 2023-04-07
Anticipated expiration: 2038-04-12
Also published as: US10378919B2; US20180306598A1; GB2564193A; GB201806176D0; RU2018114068A; DE102018109110A1; CN108725352A

Abstract

Methods and apparatus for vehicle control module activation for determining driving routes in an ignition off state are disclosed. An example system includes a vehicle in a position with an ignition switch off state. The vehicle includes a communication module for receiving an activation signal and a telematics control unit. The telematics control unit activates and determines and presents a route from the location upon receiving the activation signal. The example system also includes a remote processor that determines a location, identifies an event and an end time based on the location, and transmits an activation signal based on the end time.

Description

Vehicle control module activation to determine driving route in ignition off state

Technical Field

The present invention relates generally to control modules, and more particularly to vehicle control module activation to determine a driving route in an ignition off state.

Background

Vehicles typically include a plurality of electronic control units. Typically, each electronic control unit monitors and controls various subsystems throughout the vehicle. For example, some vehicles include electronic control units for monitoring and controlling the engine, battery, door functions, human-machine interface, suspension, cruise control, telematics, brakes, seats, and the like. The electronic control unit may include hardware, firmware, circuitry, input devices, and/or output devices for monitoring and controlling the respective subsystems.

Disclosure of Invention

The appended claims define the application. This disclosure summarizes aspects of the embodiments and should not be used to limit the claims. Other embodiments are contemplated in accordance with the techniques described herein, as will be apparent to one of ordinary skill in the art upon studying the following figures and detailed description, and are intended to be within the scope of the application.

An example embodiment of a vehicle control module activation for determining a travel route in an ignition off state is shown. An example disclosed system includes a vehicle in a position with an ignition switch off state. The vehicle includes a communication module for receiving an activation signal and a telematics control unit. The telematics control unit activates and determines and presents a route from the location upon receiving the activation signal. The disclosed example system also includes a remote processor to determine a location, identify an event and an end time based on the location, and transmit an activation signal based on the end time.

An example disclosed method for activating a vehicle control module includes: a location of the vehicle in an ignition off state is determined via the GPS receiver and an event and end time corresponding to the location is identified via the processor. The example disclosed method also includes activating the telematics control unit upon receiving an activation signal corresponding to the end time, and determining and presenting, via the telematics control unit, a route from the location.

An example disclosed tangible computer-readable medium includes instructions that, when executed, cause a machine to determine, via a GPS receiver, a location of a vehicle in an ignition-off state and identify, via a processor, an event and an end time corresponding to the location. The instructions, when executed, further cause the machine to activate the telematics control unit upon receiving an activation signal corresponding to the end time, and determine and present a route from the location via the telematics control unit.

According to the present invention, there is provided a system comprising:

a vehicle in an ignition off state at a position, the vehicle comprising:

a communication module for receiving an activation signal; and

a telematics control unit to perform the following operations:

activate upon receiving the activation signal; and

determining and presenting a route from the location; and

a remote processor to perform the following operations:

determining the location;

identifying an event and an end time based on the location; and

an activation signal is transmitted based on the end time.

According to one embodiment of the invention, the vehicle comprises an ignition switch having an on position corresponding to an on state of the vehicle and an off position corresponding to an off state of the ignition switch of the vehicle.

According to one embodiment of the invention, wherein the communication module of the vehicle sends a vehicle status signal to the remote processor before the vehicle is in the ignition off state, the vehicle status signal comprising the location and a charge level of a battery.

According to one embodiment of the invention, wherein the vehicle comprises a GPS receiver for determining the position.

According to one embodiment of the invention, the vehicle comprises a battery and a battery sensor for detecting a charge level of the battery.

According to one embodiment of the invention, wherein the vehicle includes a battery control module that activates the telematics control unit upon the communication module receiving the activation signal from the remote processor.

According to one embodiment of the invention, the battery control module activates the body control module after the communication module receives the activation signal.

According to one embodiment of the present invention, wherein the remote processor determines the current charge level of the battery of the vehicle based on the charge level before the vehicle is in the ignition-off state and the duration of time the vehicle is in the ignition-off state.

According to one embodiment of the invention, wherein the remote processor further determines the current charge level based on a make, model, body type, and option pack of the vehicle.

According to one embodiment of the invention, wherein the remote processor activates the telematics control unit in response to determining that the current charge level is greater than a predetermined charge threshold.

According to one embodiment of the invention, wherein the remote processor determines an activation duration for which the telematics control unit is activated based on the current charge level to prevent the battery from discharging.

According to one embodiment of the invention, wherein the telematics control unit returns to a sleep mode once the activation duration is over and the vehicle remains in the ignition off state.

According to one embodiment of the invention, wherein the remote processor sends the activation signal to the communication module a predetermined time period after the end time.

According to one embodiment of the invention, the telematics control unit determines the route as the fastest driving route between the location and the destination based on traffic data and weather condition data.

According to the present invention, there is provided a method for activating a vehicle control module, the method comprising:

determining, via a GPS receiver, a location of a vehicle in an ignition off state;

identifying, via a processor, an event and an end time corresponding to the location;

activating a telematics control unit upon receiving an activation signal corresponding to the end time; and

determining and presenting, via the telematics control unit, a route from the location.

According to one embodiment of the invention, further comprising detecting a charge level of a battery of the vehicle via a battery sensor.

According to one embodiment of the invention, further comprising determining, via the processor, a current charge level of the battery based on the charge level detected before the vehicle is in the ignition-off state and a duration of time the vehicle is in the ignition-off state.

According to one embodiment of the present invention, wherein the telematics control unit is activated upon determining, via the processor, that the current charge level is greater than a predetermined threshold.

According to an embodiment of the present invention, further comprising:

determining an activation duration for which the telematics control unit is activated based on the current charge level and the predetermined threshold; and

returning the telematics control unit to a sleep mode once the activation duration is over.

According to the present invention, there is provided a tangible computer readable medium comprising instructions that, when executed, cause a machine to:

determining, via a GPS receiver, a location of a vehicle in an ignition switch off state;

Drawings

For a better understanding of the invention, reference may be made to the embodiments illustrated in the following drawings. The components in the figures are not necessarily to scale, and related elements may be omitted, or in some cases the scale may have been exaggerated, in order to emphasize and clearly illustrate the novel features described herein. In addition, the system components may be arranged differently as is known in the art. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 illustrates an example vehicle in an ignition switch off state in accordance with the teachings disclosed herein;

FIG. 2 is a block diagram of electronic components of the vehicle of FIG. 1;

FIG. 3 is a flow chart for setting the control module to an active state when the vehicle of FIG. 1 is in an ignition off state, in accordance with the teachings herein;

FIG. 4 is a flow chart for setting the control module(s) of FIG. 3 to an active state to determine a driving route from an event;

FIG. 5 is a flow chart for setting the control module(s) of FIG. 3 to an active state to detect and collect data relating to damage sustained by the vehicle of FIG. 1;

FIG. 6 is a flow chart for setting the control module(s) of FIG. 3 to an active state based on the parking position and expected parking duration of the vehicle of FIG. 1.

Detailed Description

While the present invention may be embodied in various forms, there is shown in the drawings and will hereinafter be described some exemplary and non-limiting embodiments with the understanding that the present disclosure is to be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiments illustrated.

Vehicles typically include a plurality of electronic control units. Typically, each electronic control unit monitors and controls various subsystems throughout the vehicle. For example, some vehicles include electronic control units for monitoring and controlling the engine, battery, door functions, human-machine interface, suspension, cruise control, telematics, brakes, seats, and the like. The electronic control unit may include hardware, firmware, circuitry, input devices, and/or output devices for monitoring and controlling the respective subsystems. Typically, the electronic control unit requires energy to control the respective subsystems of the vehicle. For example, a vehicle door control unit consumes energy to perform the electronic functions of the vehicle door. In the event that the vehicle engine is shut off, the electronic control unit may draw energy from the vehicle's battery (e.g., a starter battery). In this case, the battery may discharge or run out if too many electronic control units draw energy from the battery and/or the electronic control units draw energy from the battery for a long time.

Example systems, apparatus, methods, and computer readable media disclosed herein sequence electronic control units of a vehicle to enable one or more electronic control units to operate while the vehicle is in an ignition off state without causing a battery of the vehicle to discharge or drain.

Some example vehicles disclosed herein include a communication module that receives an activation signal when the vehicle is in a sleep mode and parked at a location associated with an event (e.g., a work shift, a sporting event, a show at a movie theater, etc.). The telematics control unit of the example vehicle activates when the communication module receives an activation signal from the remote processor. For example, the remote processor determines a location of the vehicle, identifies an event and an end time of the event based on the location, and transmits an activation signal to the vehicle based on the end time. The communication module receives an activation signal from the remote processor, and the telematics control unit activates when the communication module receives the activation signal to determine and present a route (e.g., a preferred route to a target destination) from the location prior to or while the driver arrives at the vehicle.

Some example vehicles disclosed herein include a communication module that receives an activation signal when the vehicle is in an ignition off state and the vehicle has been damaged. The vehicle of these examples includes one or more sensors that collect damage detection data for a predetermined amount of time while the vehicle is in an ignition off state. The communication module transmits the damage detection data to the remote processor, and the remote processor detects whether the vehicle has been damaged based on the damage detection data. Upon detecting that the vehicle has been damaged, the remote processor sends an activation signal to the communication module to activate the camera module of the vehicle. The camera module includes a camera that collects damage identification data to identify the type, location, severity, and/or source of damage to the vehicle.

Some example vehicles disclosed herein include a communication module that receives an activation signal when the vehicle is in an ignition off state. The activation signal will be received from a remote processor that determines the charge level of the vehicle's battery and identifies the duration of the vehicle's stop at that location. If the charge level is greater than a threshold associated with the duration of the parking, the remote processor sends an activation signal to the communication module to activate the electronic control unit of the vehicle. For example, the remote processor sends an activation signal to activate the infotainment unit to present the media while the vehicle remains parked at a fueling station, post office, and/or any location associated with a short parking duration.

As used herein, "sleep mode" refers to a setting of the vehicle in which the energy consumption of the electronic control unit of the vehicle is reduced to a minimum operating level to reduce energy consumption when the vehicle is not operated. As used herein, "active mode" refers to a vehicle setting in a fully operational electronic control unit. As used herein, the "charge level" and "state of charge" of a battery refer to measurements of the amount of energy stored within the battery.

Turning to the drawings, FIG. 1 illustrates an example vehicle 100 according to the teachings disclosed herein. The vehicle 100 may be a standard gasoline powered vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, and/or any other motor vehicle type of vehicle. Vehicle 100 includes mobility-related components such as a powertrain having an engine, transmission, suspension, drive shafts, and/or wheels, among others. The vehicle 100 may be non-autonomous, semi-autonomous (e.g., some conventional power functions are controlled by the vehicle 100), or autonomous (e.g., power functions are controlled by the vehicle 100 without direct driver input). The vehicle 100 of the illustrated example includes an engine 102, a battery 104, an ignition switch 106, a communication module 108 (e.g., a first communication module), a Global Positioning Server (GPS) receiver 110, and another communication module 112 (e.g., a second communication module).

The engine 102 includes an internal combustion engine, an electric motor, and/or any other power source that propels the motion of the vehicle 100. In some examples, the battery 104 is a starter battery that provides energy to an internal combustion engine of the engine 102 to start the internal combustion engine. Once activated, the internal combustion engine is powered via the alternator. In some examples, the battery 104 is electrically connected to an electric motor of the engine 102 and provides electrical power to the electric motor to enable the electric motor to propel the vehicle 100. In such examples, battery 104 may include a single battery cell and/or a battery pack including multiple battery cells connected together.

The ignition switch 106 is utilized by a driver and/or another user of the vehicle 100 to operate the engine 102, the battery 104, and/or electronic accessories of the vehicle 100. For example, the ignition switch 106 includes an on position corresponding to a start state of the vehicle 100 during which the engine 102 and the electronic accessories are activated, an accessory position corresponding to an accessory state during which the electronic accessories of the vehicle 100 are activated while the engine 102 is not activated, and an ignition switch off position corresponding to an ignition switch off state during which the engine 102 is inactive and one or more electronic components are in a sleep mode and/or inactive.

The communication module 108 includes a wired or wireless network interface to enable communication with an external network. The communication module 108 also includes hardware (e.g., processor, memory, storage, antenna, etc.) and software for controlling wired or wireless network interfaces. In the illustrated example, the communication module 108 includes one or more communication controllers for standard-based networks such as global system for mobile communications (GSM), universal Mobile Telecommunications System (UMTS), long Term Evolution (LTE), code Division Multiple Access (CDMA), wiMAX (worldwide interoperability for microwave access) (IEEE 802.16 m), wireless giga (IEEE 802.11 ad), and the like. The communication module 108 communicates with an external network, such as the network 216 of fig. 2. The external network may be a public network, such as the internet; private networks, such as intranets; or a combination thereof and may utilize a variety of networking protocols now available or later developed including, but not limited to, TCP/IP based networking protocols.

The GPS receiver 110 of the illustrated example receives signals from a Global Positioning System (GPS) to determine the location of the vehicle 100. For example, the GPS receiver 110 determines longitude and latitude coordinates of the vehicle 100, a location of the vehicle 100 on a map, a location of the vehicle 100 relative to a landmark (e.g., a gym, a restaurant, a fueling station), and so forth.

The communication module 112 is a short-range wireless module that communicates with a key fob or mobile device (e.g., a smart phone) functioning as a phone, i.e., a key (PaaK), to unlock the door(s) of the vehicle 100, remotely start the vehicle, activate settings of the vehicle 100, and so forth. The communication module 112 includes hardware and firmware for establishing a connection with a key fob and/or a mobile device. In some examples, the communication module 112 implements bluetooth and/or Bluetooth Low Energy (BLE) protocols. The Bluetooth and BLE protocols are set forth in volume 6 of the Bluetooth specification 4.0 (and subsequent revisions) maintained by the Bluetooth Special Interest Group.

The vehicle 100 of the illustrated example also includes one or more proximity sensors 114, one or more cameras 116, a tilt sensor 118, an accelerometer 120, and a battery sensor 121.

The proximity sensor 114 detects when an object (e.g., another vehicle, a person, etc.) is located near the vehicle 100 and determines the proximity of the detected object to the vehicle 100. The proximity sensors 114 include radar sensors, lidar sensors, ultrasonic sensors, and/or any other type of sensor capable of detecting objects and determining proximity to detected objects. The laser radar sensor detects and determines a distance to an object via laser, the radar sensor detects and determines a distance to an object via radio waves, and the ultrasonic sensor detects and determines a distance to an object via ultrasonic waves. In the illustrated example, one of the proximity sensors 114 is located on each side (e.g., front, rear, driver, passenger) of the vehicle 100 to facilitate detecting objects throughout the surrounding area of the vehicle 100. In other examples, the vehicle may include more or fewer proximity sensors 114 and/or the proximity sensors 114 may be located at different locations throughout the vehicle 100.

A camera 116 is located on the vehicle 100 to collect images and/or video of the surrounding area of the vehicle 100. The images and/or video are analyzed (e.g., by the camera module 228 and/or the body control module 230 of fig. 2) to detect when an object is located near the vehicle 100 and to determine the proximity of the detected object to the vehicle 100. In the illustrated example, one of the cameras 116 is located on a front side of the vehicle 100 to facilitate detection of objects located forward of the vehicle 100, and another camera 116 is located on a rear side of the vehicle 100 to facilitate detection of objects located rearward of the vehicle 100. In other examples, the vehicle may include more or fewer proximity sensors 114 and/or the proximity sensors 114 may be located at different locations throughout the vehicle 100 (e.g., driver side, passenger side, etc.).

The tilt sensor 118 of the illustrated example detects when the vehicle 100 is tilted and/or when a portion of the vehicle 100 has been lifted from the ground. The accelerometer 120 detects acceleration of the movement of the vehicle 100. In some examples, the tilt sensor 118 and/or the accelerometer 120 are included in an inertial measurement unit (e.g., the inertial measurement unit 224 of fig. 2) and/or an anti-lock braking system module. In addition, the battery sensor 121 monitors characteristics of the battery 104. The battery sensor 121 detects and/or otherwise determines the current, voltage, charge level, and/or temperature of the battery 104. For example, the battery sensor 121 detects that the current of the battery 104 is greater than 0 amps when the battery 104 is being recharged, and detects that the current of the battery 104 is less than 0 amps when the battery 104 is being discharged. In some examples, the battery sensor 121 is attached to a lead of the battery 104 to enable the battery sensor 121 to monitor a characteristic of the battery 104.

In the illustrated example, the vehicle 100 also includes another communication module 122 (e.g., a third communication module), an infotainment host unit 124 that includes a display 126 and one or more speakers 128, and an HVAC unit 130.

The communication module 122 is a Dedicated Short Range Communication (DSRC) module that includes an antenna, radio, and software to broadcast messages and establish connections with modules of mobile devices (e.g., smart phones, smart watches, wearable devices, tablets, etc.), other vehicles (e.g., vehicle-to-vehicle (V2V) communication), and infrastructure (e.g., vehicle-to-infrastructure (V2X) communication). For information on how a DSRC network communicates with vehicle hardware and software, see united states department of transportation 2011 6-month core system requirements specification (SyRS) report (https:// www.its.dot.gov/meetings/pdf/CoreSystem _ SE _ SyRS _ RevA%20 (2011-06-13). Pdf), the entire contents of which, as well as all documents cited on pages 11-14 of the SyRS report, are incorporated herein by reference. DSRC systems may be installed on vehicles or on roadside infrastructure. DSRC systems incorporating infrastructure information are referred to as "roadside" systems. DSRC may be combined with other technologies such as Global Positioning System (GPS), visible Light Communication (VLC), cellular communication, and short-range radar, to facilitate a vehicle communicating its position, speed, heading, relative position with other objects, and exchanging information with other vehicles or external computing systems. The DSRC system may be integrated with other systems (e.g., mobile phones). Currently, DSRC networks are identified by DSRC abbreviations or names. However, other names are sometimes used, often in connection with networked vehicle programs and the like. Most of these systems are purely DSRC or variations of the IEEE802.11 wireless standard. However, in addition to pure DSRC systems, it is also meant to cover dedicated wireless communication systems between automobiles and roadside infrastructure systems that are integrated with GPS and are based on IEEE802.11 protocols (e.g., 802.11p, etc.) for wireless local area networks.

The infotainment host unit 124 provides an interface between the vehicle 100 and a user. The infotainment host unit 124 includes digital and/or analog interfaces (e.g., input devices and output devices) to receive input from a user and display information to the user. Input devices include, for example, control knobs, a dashboard, a digital camera for image capture and/or visual command recognition, a touch screen, an audio input device (e.g., a car microphone), buttons, or a touch pad. The output devices may include an instrument cluster output (e.g., dials, lighting), a driver, a heads-up display, a display 126 (e.g., a center console display such as a Liquid Crystal Display (LCD), an organic light emitting diode (e.g., OLED) display, a flat panel display, a solid state display, etc.), and/or speakers 128. In the illustrated example, the infotainment host unit 124 is included for an infotainment system (e.g., by

(Ford) in>

And MyFord @>

(toyota)>

(general purpose) is>

Etc.) hardware (e.g., processors or controllers, memory, storage, etc.) and software (e.g., operating systems, etc.). In addition, the infotainment host unit 124 may display the infotainment system on, for example, a display 126.

The HVAC unit 130 of the illustrated example conditions, maintains, and/or otherwise affects the environment within the cabin of the vehicle 100. The HVAC unit 130 includes vents, heaters, and/or air conditioners to control the temperature and/or humidity level within the cabin of the vehicle 100. For example, settings of the HVAC unit 130 may be adjusted to improve occupant comfort (e.g., adjust heating and/or air conditioning) and/or increase visibility through windows of the vehicle 100 (e.g., defrost of a windshield).

Further, the vehicle 100 of the illustrated example is an electric and/or hybrid vehicle that includes a solar panel 132 and an Electric Vehicle (EV) receptacle 134 to recharge the battery 104. In other examples, where the vehicle 100 is a standard gasoline-powered vehicle, the vehicle 100 may include a solar panel 132 to recharge the battery 104 and/or provide electrical energy to components of the vehicle 100. The solar panel 132 captures solar energy (e.g., via sunlight), converts the solar energy to electrical power, and recharges the battery 104 by providing the electrical power to the battery 104. The EV receptacle 134 receives a power plug (e.g., an EV plug) of the charging station for recharging the battery 104 by causing the charging station to provide power to the battery 104.

Fig. 2 is a block diagram of electronic components 200 of vehicle 100. As shown in FIG. 2, the electronic components 200 include a battery control module 202, the infotainment host unit 124, the GPS receiver 110, the communication module 108, sensors 204, a control module or Electronic Control Unit (ECU) 206, and a vehicle data bus 208.

The battery control module 202 monitors and controls the battery 104 of the vehicle 100. For example, the battery control module 202 monitors characteristics of the battery 104 (e.g., voltage, current, state of charge, temperature, etc.), calculates other characteristics of the battery 104 (e.g., internal impedance, charge delivered and stored, energy delivered since last charge, etc.), communicates with the sensors 204 and/or the ECU206, controls the discharge and/or recharge of the battery 104, and so forth.

The battery control module 202 includes a microcontroller unit, controller or processor 210; a memory 212; and a database 214. For example, the database 214 stores data collected by one or more of the sensors 204, the GPS receiver 110, the communication module 122, and/or any other device of the vehicle 100. Processor 210 may be any suitable processing device or group of processing devices, such as, but not limited to, a microprocessor, a microcontroller-based platform, an integrated circuit, one or more Field Programmable Gate Arrays (FPGAs), and/or one or more application specific integrated circuit circuits (ASICs). The memory 212 may be volatile memory (e.g., RAM including non-volatile RAM, magnetic RAM, ferroelectric RAM, etc.), non-volatile memory (e.g., disk memory, flash memory, EPROM (electrically programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), memristor-based non-volatile solid-state memory, etc.), non-alterable memory (e.g., EPROM), read-only memory, and/or a mass storage device (e.g., hard disk drive, solid-state drive, etc.). In some examples, the memory 212 includes a variety of memories, particularly volatile and non-volatile memories.

The memory 212 is a computer-readable medium on which one or more sets of instructions, such as software for operating the methods of the present disclosure, may be embedded. The instructions may embody one or more of the methods or logic described herein. For example, the instructions may reside, completely or at least partially, within any one or more of the memory 212, the computer-readable medium, and/or within the processor 210 during execution thereof.

As shown in fig. 2, the communication module 108 communicates wirelessly with a network 216. For example, the network 216 is a public network, such as the Internet; private networks, such as intranets; or a combination thereof and may utilize various network protocols now available or later developed including, but not limited to, TCP/IP based network protocols. The network 216 of the illustrated example includes a remote processor 218 (e.g., a server) that collects, stores, analyzes, determines, and/or communicates information related to the battery 104 of the vehicle 100. For example, the remote processor 218 collects the charge level of the battery 104 and/or the parking location of the vehicle 100 via the communication module 108, stores the last measured charge level of the battery 104, analyzes the collected data to determine or estimate the current charge level of the vehicle 100 in the ignition off state, sequences the activation of the ECUs 206, and sends instructions to activate one or more ECUs 206 when the vehicle 100 is in the ignition off state.

The remote processor 218 of the illustrated example includes a wired or wireless network interface to enable communication with the communication module 108 of the vehicle 100. Remote processor 218 also includes hardware (e.g., processor, memory, storage, antenna, etc.) and software to control the wired or wireless network interface. For example, remote processor 218 includes one or more communication controllers for standard-based networks (e.g., global System for Mobile communications (GSM), universal Mobile Telecommunications System (UMTS), long Term Evolution (LTE), code Division Multiple Access (CDMA), wiMAX (IEEE 802.16 m), near Field Communications (NFC), local area wireless networks (including IEEE802.11 a/b/g/n/ac or others), dedicated Short Range Communications (DSRC), and wireless giga (IEEE 802.11 ad), among others).

Sensors 204 are disposed within vehicle 100 and around vehicle 100 to monitor attributes of vehicle 100 and/or the environment in which vehicle 100 is located. One or more sensors 204 may be installed to measure properties around the exterior of the vehicle 100. Additionally or alternatively, one or more sensors 204 may be mounted inside the cabin of the vehicle 100 or on the body of the vehicle 100 (e.g., engine compartment, wheel arches, etc.) to measure properties of the interior of the vehicle 100. For example, sensors 204 include accelerometers, odometers, tachometers, pitch and yaw sensors, wheel speed sensors, microphones, tire pressure sensors, biosensors, and/or any other suitable type of sensor. In the illustrated example, the sensors 204 include the proximity sensor 114, the camera 116, the tilt sensor 118, the accelerometer 120, and the battery sensor 121.

The ECU206 monitors and controls the subsystems of the vehicle 100. For example, the ECU206 is a discrete set of electronics including its own circuitry (e.g., integrated circuits, microprocessors, memory, storage, etc.) and firmware, sensors, drivers, and/or mounting hardware. The ECU206 communicates and exchanges information via a vehicle data bus, such as the vehicle data bus 208. Additionally, the ECUs 206 may communicate attributes (e.g., status of the ECUs 206, sensor readings, control status, errors, diagnostic codes, etc.) to each other and/or receive requests from each other. For example, the vehicle 100 may have seventy or more ECUs 206 located at various locations around the vehicle 100 and communicatively coupled via a vehicle data bus 208.

In the illustrated example, the ECU206 includes a gateway module 220, a Telematics Control Unit (TCU) 222, a communication module 112, an Inertial Measurement Unit (IMU) 224, a central timing module 226, a camera module 228 including one or more cameras 116, a communication module 122, a body control module 230, and an HVAC module 232. For example, the gateway module 220 facilitates communication between different communication protocols of the vehicle 100. Additionally or alternatively, the gateway module 220 facilitates communication between the communication module 108 and the network 416, for example, via a cellular data link. A Telematics Control Unit (TCU) 222 controls tracking of the location of the vehicle 100. For example, the telematics control unit 222 includes and/or communicates with a GPS receiver 110 that receives the location of the vehicle 100. The inertial measurement unit 224 monitors longitudinal acceleration, lateral acceleration, yaw rate, pitch rate, roll rate, and/or any other characteristic associated with the current state of motion of the vehicle 100. For example, the inertial measurement unit 224 includes a tilt sensor 118 and an accelerometer 120, the tilt sensor 118 detecting when the vehicle 100 is tilted and/or when a portion of the vehicle 100 is lifted, the accelerometer 120 detecting acceleration (e.g., longitudinal, lateral) of the vehicle 100. In addition, central timing module 226 includes and/or communicates with a clock 234 to determine a monitoring time. The communication module 122 (e.g., DSRC module) communicates wirelessly with other nearby communication modules. For example, the communication module 122 collects data from communication modules of nearby vehicles via vehicle-to-vehicle communication and/or from communication modules of infrastructure units via vehicle-to-infrastructure communication. The body control module 230 controls one or more subsystems of the overall vehicle 100, such as power windows, power locks, anti-theft systems, power mirrors, etc. For example, the body control module 230 includes circuitry to drive one or more relays (e.g., to control wiper fluid, etc.), brushed Direct Current (DC) motors (e.g., to control power seats, power locks, power windows, wipers, etc.), stepper motors, LEDs, etc. For example, the body control module 230 is communicatively coupled to the window controller 236 to electronically control operation (e.g., open, ignition off) of one or more windows of the vehicle 100. Additionally, the HVAC module 232 is communicatively coupled to the HVAC unit 130 to control and/or adjust settings of the HVAC unit 130 (e.g., air conditioning settings, heating settings, flow settings, defrost settings, etc.). In some examples, the ECU206 also includes an anti-lock braking system (ABS) module that includes an accelerometer (e.g., a multi-axis accelerometer) and/or a wheel speed sensor that detects wheel rotation (e.g., upon impact of a collision).

The vehicle data bus 208 communicatively couples the communication module 108, the GPS receiver 110, the infotainment host unit 124, the battery control module 202, the sensors 204, and the ECU206. In some examples, the vehicle data bus 208 includes one or more data buses. Vehicle data bus 208 may be in accordance with a Controller Area Network (CAN) bus protocol, a Media Oriented System Transport (MOST) bus protocol, a CAN flexible data (CAN-FD) bus protocol (ISO 11898-7), and/or a K-wire bus protocol (ISO 9141 and ISO 14230-1) and/or an Ethernet protocol as defined by International organization for standardization (ISO) 11898-1 ^TM Bus protocol IEEE 802.3 (2002 ago), etc.

FIG. 3 is a flow chart of an example method 300 for setting one or more control modules of a vehicle in an ignition off state to be in an active state. The flowchart of fig. 3 represents machine readable instructions stored in a memory (such as the memory 212 of fig. 2) and including one or more programs that, when executed by a processor (such as the processor 210 of fig. 2), cause the example vehicle 100 of fig. 1 to activate one or more of the example ECUs 206 of fig. 2 when the example vehicle 100 is in an ignition off state. Although the example routine is described with reference to the flowchart shown in FIG. 3, many other methods for activating a control module of a vehicle in an ignition off state may alternatively be used. For example, the order of execution of the blocks may be rearranged, changed, eliminated, and/or combined to perform the method 300. Further, because the method 300 is disclosed in conjunction with the components of fig. 1-2, some of the functionality of these components will not be described in detail below.

First, at block 302, the battery sensor 121 detects the charge level of the battery 104 of the vehicle 100, and the remote processor 218 collects or determines the charge level of the battery 104 via the communication module 108 of the vehicle 100. At block 304, the GPS receiver 110 (e.g., of the telematics unit 222) determines the location of the vehicle 100, and the remote processor 218 collects or determines the location of the vehicle 100 via the communication module 108. For example, the communication module 108 sends a vehicle status signal including the charge level and position of the vehicle 100 to the remote processor 218 before the vehicle 100 is in the ignition-off state.

At block 306, the remote processor 218 determines whether the vehicle 100 is in an ignition off state. For example, the remote processor 218 determines that the vehicle 100 is in the ignition off state in response to the vehicle 100 not receiving a signal from the communication module 108 of the vehicle 100 for a predetermined amount of time. In other examples, the communication module 108 sends the ignition-off signal to the remote processor 218 immediately prior to the vehicle transitioning to the ignition-off state. Once remote processor 218 determines that the vehicle is not in an ignition off state (e.g., enabled, accessory state), method 300 returns to block 302 such that vehicle 100 receives an updated charge level of battery 104, an updated position of vehicle 100.

Blocks

302, 304, 306 are repeated until remote processor 218 determines that the vehicle is in an ignition off state. Once remote processor 218 determines that the vehicle is in the ignition off state, method 300 proceeds to block 308. At block 308, the processor 210 of the vehicle 100 causes one or more ECUs 206 (e.g., control modules) to transition from an active mode to a sleep mode to conserve the charge level of the battery 104 while the vehicle 100 is in the ignition off state.

At block 310, remote processor 218 detects the activation event and determines whether to place the corresponding one or more ECUs 206 in an active mode. For example, if the remote processor 218 determines that the event in which the vehicle 100 is parked is over, the remote processor 218 determines whether to activate the telematics control unit 422 to determine a route from the location where the vehicle 100 is parked. If the remote processor 218 determines that damage to the vehicle 100 has been caused during parking of the vehicle 100, the remote processor 218 determines whether to activate one or more of the ECUs 206 (e.g., communication module 122, inertial measurement unit 224, central timing module 226) to collect data related to the damage sustained by the vehicle 100. Further, if the remote processor 218 determines that the vehicle 100 is parked at a location associated with a short parking duration, the remote processor 218 determines whether one or more ECUs 206 (e.g., communication module 122, body control module 230, HVAC module 232) are activated for the driver of the vehicle 100.

At block 312, the remote processor 218 determines whether the vehicle 100 is in a start-up state. For example, the remote processor 218 determines that the vehicle 100 is in the start state upon receiving a signal from the communication module 112 of the vehicle 100 indicating that the vehicle 100 is in the start state. In response to the vehicle 100 remaining in the ignition off state and not in the activated state, the method 300 returns to block 308.

Blocks

308, 310, 312 are repeated until remote processor 218 determines that vehicle 100 is in the activated state. Otherwise, in response to remote processor 218 determining that vehicle 100 is in the ignition off state, method 300 ends.

FIG. 4 is a flow diagram of an example method 400 for implementing block 310 of FIG. 3 to determine a driving route from an event. The flowchart of fig. 4 represents machine readable instructions stored in a memory (such as the memory 212 of fig. 2) and including one or more programs that, when executed by a processor (such as the processor 210 of fig. 2), cause the example vehicle 100 of fig. 1 to activate one or more of the example ECUs 206 of fig. 2 to determine a direction of travel from an event when the example vehicle 100 is in an ignition-off state. Although the example program is described with reference to the flowchart shown in FIG. 4, many other methods for determining a driving route from an event may alternatively be used. For example, the order of execution of the blocks may be rearranged, changed, eliminated, and/or combined to perform the method 400. Furthermore, because the method 400 is disclosed in conjunction with the components of fig. 1-2, some of the functions of these components will not be described in detail below.

Initially, at block 402, remote processor 218 determines whether the location of vehicle 100 is associated with an event (e.g., a sporting event, work, movie, etc.). In some examples, remote processor 218 accesses the driver's personal calendar (e.g., via communication with vehicle 100 and/or the driver's mobile device) to identify whether the location is associated with an event. In response to determining that the location of the vehicle 100 is not associated with an event, the method 400 ends. In response to determining that the location of the vehicle 100 is associated with an event, the method 400 proceeds to block 404 where the remote processor 218 identifies the event at block 404. For example, if remote processor 218 identifies that vehicle 100 is parked in a parking lot associated with a sporting event (e.g., a baseball game), remote processor 218 identifies that the event is a sporting event. If remote processor 218 identifies that vehicle 100 is parked at a location near the driver's work office (e.g., based on information provided by the driver, based on an analysis of the driver's and/or vehicle 100 drive history, etc.), remote processor 218 identifies that the event is a work shift.

At block 406, the remote processor 218 sequences the activation of the ECU206 (e.g., control module) of the vehicle 100. For example, the remote processor 218 determines which ECU206 is to be activated while the vehicle 100 remains in the ignition off state and in what order to prevent activation of one or more ECUs 206 from causing the battery 104 to discharge. Remote processor 218 sequences activation ECU206 based on the location of vehicle 100. For example, remote processor 218 prioritizes gateway module 220, battery control module 202, and/or telematics control unit 222 when vehicle 100 is parked in a location associated with a sporting event or a driver's employment location.

At block 408, remote processor 218 determines an end time of the event identified at block 404 based on the location of vehicle 100. For example, remote processor 218 may communicate with a public network to determine when an event (e.g., a show at a movie theater) is scheduled to end to determine the end time of the event (e.g., a movie scheduled to end at night 9. In other examples, remote processor 218 may communicate with the public network to track events (e.g., sporting events) in real-time to determine the end time of the event (e.g., the public network identifies that the event has ended at night 8. Additionally or alternatively, remote processor 218 may evaluate previous occurrences of the event (e.g., work shifts) to predict the end time of the event (e.g., the driver typically leaves the office on thursday afternoon at 5. For example, based on previous parking data provided by vehicle 100 and/or other vehicles, remote processor 218 utilizes cloud-based learning to determine a typical parking duration or end time for a geo-fenced area that includes a location where vehicle 100 was parked for the event. Further, in some examples, remote processor 218 identifies an end time of the event based on the driver's personal calendar.

Further, remote processor 218 determines when to activate one or more ECUs 206 of vehicle 100 based on the end time of the event. In some examples, remote processor 218 determines to activate one or more ECUs 206 of vehicle 100 at the end of the event. For example, if the vehicle 100 is parked outside the office in close proximity to the driver, the remote processor 218 may activate one or more of the ECUs 206 at the predicted end time of the driver's work shift. In other examples, remote processor 218 determines to activate one or more ECUs 206 of vehicle 100 at a predetermined amount of time after the event end time. For example, if remote processor 218 identifies a vehicle that typically requires someone to arrive at a parking location of vehicle 100 20 minutes after the end of the sporting event, remote processor 218 may activate one or more ECUs 206 20 minutes after the end time of the sporting event.

At block 410, remote processor 218 determines whether it is time to activate telematics control unit 222 to determine a travel route from the location of vehicle 100. In response to determining that it is not time to activate the telematics control unit 222, the method 400 returns to block 410. In response to determining that it is time to activate the telematics control unit 222, the method 400 continues to block 412.

At block 412, the remote processor 218 determines the current charge level of the battery 104 of the vehicle 100. When the battery control module 202 is set to the sleep mode at block 308 of the method 300 of fig. 3, the remote processor 218 is unable to collect the current charge level of the battery 104 via the battery sensor 121. To determine the current charge level, remote processor 218 calculates the current charge level of battery 104 based on the charge level of battery 104 and the duration of time vehicle 100 was in the ignition-off state before vehicle 100 was in the ignition-off state (e.g., a vehicle status signal sent from communication module 108 of vehicle 100 received before block 306 of method 300 of fig. 3). For example, when the vehicle 100 is in the ignition off state, the charge level of the battery 104 decreases with time. Thus, the longer the vehicle 100 is in the ignition off state, the more charge remote processor 218 reduces from the last measured charge level, thereby determining the current charge level of battery 104. In some examples, remote processor 218 identifies a reduced charge level discharge rate of battery 104 based on the make, model, body type, option pack (options package), and/or any other characteristic of vehicle 100. Further, in some examples, remote processor 218 determines the current charge level of battery 104 based on whether and to what extent the battery 104 battery has been recharged via solar panel 132, EV receptacle 134, and/or any other charging source. For example, the solar panel 132 may reduce and/or counteract the discharge rate of the cell 104 over time.

At block 414, remote processor 218 determines whether the current charge level of battery 104 is greater than a predetermined charge threshold. For example, the predetermined charge threshold corresponds to a minimum charge level that enables the telematics control unit 222 to be activated for a predetermined amount of time (e.g., a minimum activation duration) without causing the battery 104 of the vehicle 100 to discharge. In response to remote processor 218 determining that the current charge level of battery 104 is not greater than the predetermined charge threshold, method 400 ends. In some examples, the battery control module 202 (e.g., via the communication module 108) and/or the remote processor 218 notifies the driver via the mobile device that the battery 104 has a low charge level. Additionally or alternatively, when the vehicle 100 is outdoors (e.g., as determined via the GPS receiver 110), the battery control module 202 may autonomously start the vehicle 100 for a period of time to enable the battery 104 to recharge over time. In such an example, the battery control module 202 may not autonomously start the vehicle 100 when the vehicle is indoors to avoid carbon monoxide build-up within indoor facilities. Otherwise, in response to remote processor 218 determining that the current charge level of battery 104 is greater than the predetermined charge threshold, method 400 proceeds to block 416. At block 416, remote processor 218 determines an activation duration that the telematics control unit will not cause battery 104 to discharge based on the current charge level. That is, the remote processor 218 determines an activation duration for activating the telematics control unit to prevent the battery 104 of the vehicle 100 from discharging.

At block 418, the remote processor 218 sends an activation signal to the communication module 108 of the vehicle 100, and the communication module 108 receives the activation signal to activate the telematics control unit 222. For example, remote processor 218 sends an activation signal based on an end time (e.g., a predetermined time period after the end time), communication module 108 receives the activation signal, gateway module 220 causes battery control module 202 to activate once communication module 108 receives the activation signal, and battery control module 202 subsequently activates telematics control unit 222. That is, in response to determining that the current charge level of battery 104 is greater than the predetermined charge level, remote processor 218 activates telematics control unit 222.

At block 420, the telematics control unit 222 determines a target destination for the vehicle 100. In some examples, the telematics control unit 222 predicts and/or otherwise determines a target destination for the vehicle 100 based on the drive history of the vehicle 100 and/or the driver. For example, if the location of the vehicle 100 is associated with the driver's workplace, the telematics control unit 222 determines that the target destination of the vehicle 100 is the driver's home. In some examples, the telematics control unit 222 determines the target destination based on the driver's personal calendar. At block 422, the telematics control unit 222 collects traffic data, map data, and/or weather condition data. For example, the telematics control unit 222 collects map data, traffic data, and/or weather condition data from an external server via the communication module 108.

At block 424, the telematics control unit 222 determines a route from the location where the vehicle 100 is parked to the target destination. In some examples, the telematics control unit 222 determines the fastest driving route from the location of the vehicle 100 to the target destination. For example, the telematics control unit 222 determines the fastest driving route from the location of the vehicle 100 to the target destination based on map data, traffic data, driver history data, weather condition data, and the like. In some examples, once the route is determined, the telematics control unit 222 presents the route via the display 126 starting from the location of the vehicle 100. In other examples, the telematics control unit 222 presents a route from the location of the vehicle 100 via the display 126 once the driver enters the vehicle 100. Additionally or alternatively, the battery control module 202 sets a driving mode (e.g., snowfall mode, sport mode, etc.) by adjusting powertrain and/or suspension settings and/or presenting corresponding recommended tire pressures based on a target destination, route, time of day, weather conditions, etc.

At block 426, remote processor 218 determines whether the activation duration has been completed. In response to determining that the activation duration has been completed while the vehicle 100 remains in the ignition-off state, the method 400 ends such that at block 308 of the method 300 of fig. 3, the telematics control unit 222 and/or the one or more ECUs 206 will return to the sleep mode. Further, in some examples, if the ECU remains in an active state, upon detecting that the battery 104 will soon be discharged, the battery control module 202 ends the method 400 and the ECU206 returns to the sleep mode.

Otherwise, at block 428, the method 400 proceeds to block 428, where the communication module 112 determines whether a user (e.g., driver) is near the vehicle 100 at block 428. For example, the communication module 112 remains in the active mode when the vehicle 100 is in the ignition off state to enable the communication module 112 to detect the presence of the user. In response to the communication module 112 not detecting a user, the method 400 returns to block 422. Otherwise, in response to the communication module 112 detecting the user, the method 400 proceeds to block 430. At block 430, the battery control module 202 determines (e.g., via measurement of the battery sensor 121) whether the charge level of the battery 104 is greater than another predetermined charge threshold (e.g., a second charge threshold). For example, the predetermined charge threshold corresponds to a charge level of the battery 104 that is capable of activating the body control module 230 of the vehicle 100 without causing the battery 104 to discharge. In response to the battery control module 202 determining that the charge level is not greater than the predetermined charge threshold, the method 400 ends. Otherwise, in response to the battery control module 202 determining that the charge level is greater than the predetermined charge threshold, the method 400 proceeds to block 432 where the body control module 230 activates the lighting of the vehicle 100 when the user approaches the vehicle 100 at block 432. For example, the battery control module 202 activates the body control module 230 (e.g., after the communication module 108 receives the activation signal) to cause the body control module 230 to activate the lighting. After completion of block 432, method 400 ends.

FIG. 5 is a flow diagram of an example method 500 for implementing block 310 of FIG. 3 to detect and collect data related to damage to a vehicle. The flowchart of FIG. 5 represents machine readable instructions stored in a memory (e.g., memory 212 of FIG. 2) and including one or more programs that, when executed by a processor (e.g., processor 210 of FIG. 2), cause the example vehicle 100 of FIG. 1 to activate one or more of the example ECUs 206 of FIG. 2 to detect and collect data related to damage sustained by the example vehicle 100. Although the example process is described with reference to the flowchart shown in FIG. 5, many other methods for detecting and collecting data related to vehicle damage may alternatively be used. For example, the order of execution of the blocks may be rearranged, changed, eliminated, and/or combined in order to perform the method 500. Further, because method 500 is disclosed in conjunction with the components of fig. 1-2, some of the functionality of these components will not be described in detail below.

Initially, at block 502, the remote processor 218 identifies characteristics of the location where the vehicle 100 is parked. Remote processor 218 determines, based on characteristics of the location, a likelihood that vehicle 100 will be damaged (e.g., collided, broken, etc.) while parked at the location. For example, if the vehicle 100 is parked in parallel beside a busy intersection, the remote processor 218 potentially may determine that the vehicle 100 is more likely to be damaged. If the vehicle 100 is parked in a private or protected garage, the remote processor 218 potentially may determine that the vehicle 100 is unlikely to be damaged. Additionally or alternatively, remote processor 218 identifies an expected parking duration based on the location of vehicle 100. For example, if the vehicle 100 is located at an airport parking lot, the remote processor 218 determines that the vehicle 100 will remain in that location for a long period of time. In some examples, remote processor 218 utilizes cloud-based learning to determine an expected parking duration for a geo-fenced area that includes the location of vehicle 100 based on previous parking data provided by vehicle 100 and/or other vehicles.

At block 504, the remote processor 218 determines whether to monitor the vehicle 100 to confirm damage to the vehicle 100 while the vehicle 100 is parked at the location. Remote processor 218 determines whether to monitor vehicle 100 based on the location characteristics of vehicle 100 and/or the expected parking duration. For example, if the characteristics of the location are associated with potential damage to the vehicle 100, the remote processor 218 is more likely to monitor the vehicle 100 for damage. If the remote processor 218 determines that the vehicle 100 is likely to be parked in the location for a longer period of time, the remote processor 218 is less likely to monitor the vehicle 100. In response to remote processor 218 determining not to monitor vehicle 100 for damage, method 500 ends. Otherwise, in response to remote processor 218 determining to monitor vehicle 100 for damage, method 500 proceeds to block 506.

At block 506, remote processor 218 determines whether the current charge level of battery 104 is greater than a predetermined charge threshold. For example, remote processor 218 determines the current charge level of battery 104 and compares it to a predetermined charge threshold. To determine the current charge level, remote processor 218 calculates the current charge level of battery 104 based on the charge level of battery 104 before vehicle 100 is in the ignition-off state and the duration of time vehicle 100 is in the ignition-off state. For example, when the vehicle 100 is in the ignition off state, the charge level of the battery 104 decreases over time. Remote processor 218 may identify a reduced charge level discharge rate of battery 104 based on the make, model, body type, option pack, and/or any other characteristic of vehicle 100. Further, in some examples, remote processor 218 determines the current charge level of battery 104 based on whether and to what extent the battery 104 battery has been recharged via solar panel 132, EV receptacle 134, and/or any other charging source. Further, the predetermined charge threshold corresponds to a minimum charge level that enables the one or more sensors 204 to be activated for a predetermined amount of time (e.g., a minimum activation duration) to detect damage caused to the vehicle 100 without causing the battery 104 of the vehicle 100 to discharge.

In response to remote processor 218 determining that the current charge level of battery 104 is not greater than the predetermined charge threshold, method 500 ends. In some examples, the battery control module 202 (e.g., via the communication module 108) and/or the remote processor 218 notifies the driver via the mobile device that the battery 104 has a low charge level. Additionally or alternatively, when the vehicle 100 is outdoors (e.g., as determined via the GPS receiver 110), the battery control module 202 may autonomously start the vehicle 100 for a period of time to enable the battery 104 to recharge over time. In such an example, the battery control module 202 may not autonomously start the vehicle 100 when the vehicle is indoors to avoid carbon monoxide build-up within indoor facilities. Otherwise, in response to remote processor 218 determining that the current charge level of battery 104 is greater than the predetermined charge threshold, method 500 proceeds to block 508.

At block 508, the remote processor 218 sequences activation of one or more sensors 204 (e.g., one or more proximity sensors 114 of the body control module 230, one or more cameras 116 of the camera module, the tilt sensor 118 and/or accelerometer 120 of the inertial measurement unit 224, one or more vehicle speed sensors of the ABS module). At block 510, one of the sensors 204 is activated to collect damage detection data. Damage detection data is collected by one or more sensors 204 to identify if and when the vehicle 100 is damaged in the ignition-off state. For example, to activate one of the sensors 204, the remote processor 218 sends an activation signal to the communication module 108, upon receipt of the activation signal by the communication module 108, the gateway module 220 causes the battery control module 202 to activate, and the battery control module 202 subsequently activates one of the ECUs 206 (e.g., the inertial measurement unit 224) for the corresponding one of the sensors 204 (the tilt sensor 118). In some such examples, the battery control module 202 may return to the sleep mode upon activation of one or more ECUs 206 (e.g., control modules). At block 512, remote processor 218 and/or battery control module 202 determines a monitoring duration during which one of sensors 204 will monitor damage detection data based on the current charge level. The monitoring duration is determined to prevent discharging the battery 104 of the vehicle 100 due to collecting damage detection data.

At block 514, remote processor 218 determines whether to activate another one of sensors 204 to monitor damage detection data while vehicle 100 is in the ignition off state. For example, remote processor 218 determines whether to activate another one of sensors 204 based on the current charge level of battery 104. In response to remote processor 218 determining to activate another sensor 204, method 500 returns to block 510. Otherwise, in response to remote processor 218 determining not to activate another sensor 204, method 500 proceeds to block 516, at which block 516 remote processor 218 determines whether the monitoring duration has been reached. In response to remote processor 218 determining that the monitoring duration has been reached, method 500 ends. Otherwise, in response to remote processor 218 determining that the monitoring duration has not been reached, the method proceeds to block 518.

At block 518, remote processor 218 detects whether vehicle 100 has been damaged based on damage detection data collected by the one or more sensors 204 activated at block 508. For example, one or more sensors 204 collect damage detection data and send the damage detection data to remote processor 218 via communication module 108. Remote processor 218 receives the damage detection data from communication module 108 and analyzes the damage detection data to detect whether vehicle 100 in the ignition off state has caused damage. For example, if the damage detection data collected by the one or more proximity sensors 114 and/or the one or more cameras 116 indicates that an object (e.g., another vehicle) and/or a person has contacted the vehicle 100, the remote processor 218 determines that the vehicle 100 has been damaged. Additionally or alternatively, remote processor 218 determines that vehicle 100 has been damaged if the damage detection data collected by tilt sensor 118 indicates that vehicle 100 has been tilted or lifted and/or if the damage detection data collected by tilt sensor 118 indicates that vehicle 100 has been suddenly displaced (e.g., due to a collision). In response to remote processor 218 not detecting damage to vehicle 100, method 500 returns to block 518. Further, in some examples, once remote processor 218 does not detect damage to vehicle 100, method 500 returns to block 516 to determine whether the monitoring duration has been reached. Otherwise, in response to remote processor 218 detecting that damage has been made to vehicle 100, method 500 proceeds to block 520.

At block 520, remote processor 218 determines the current charge level of battery 104. In some examples, remote processor 218 determines the current charge level of battery 104 based on the charge level of battery 104 before vehicle 100 is in the ignition-off state, the duration vehicle 100 is in the ignition-off state, and/or the extent to which the battery 104 is recharged via the charging source in the ignition-off state. In other examples, remote processor 218 activates battery control module 202 (e.g., via gateway module 220), battery sensor 121 detects the charge level of battery 104, and remote processor 218 receives the charge level of battery 104 via communication module 108.

At block 522, remote processor 218 determines a data collection duration for collecting the damage-identifying data to identify the type, location, severity, and/or source (e.g., person, vehicle, etc.) of damage to vehicle 100. For example, when collecting damage identification data, remote processor 218 determines a data collection duration based on the current charge level of battery 104 to prevent battery 104 of vehicle 100 from draining or discharging. At block 524, remote processor 218 sequences the activation of sensors 204 and/or ECU206, which sensors 204 and/or ECU206 enable collection of damage identification data. For example, the remote processor 218 preferentially activates the proximity sensor 114, the camera 116, the communication module 122, the central timing module 226, the camera module 228, the body control module 230, and the like. In some examples, remote processor 218 orders sensors 204 and/or ECU206 from those that consume the least amount of charge to collect damage identification data to those that consume the most amount of charge to collect damage identification data.

At block 526, remote processor 218 activates one of sensors 204 and/or one of ECUs 206 based on how remote processor 218 sorts sensors 204 and/or ECUs 206 at block 524. For example, in response to remote processor 218 detecting that damage has been caused to vehicle 100 at block 518 and determining that the current charge level is greater than the predetermined charge level, an activation signal is sent by remote processor 218 to communication module 108 to activate one or more cameras 116 to collect damage identification data. In some such examples, the remote processor 218 sends an activation signal to the communication module 108, the communication module 108 receives the activation signal, the gateway module 220 causes the battery control module 202 to activate once the communication module 108 receives the activation signal, and the battery control module 202 subsequently activates the camera module 228 to activate one or more cameras 116.

At block 528, the one or more sensors 204 and/or the one or more ECUs 206 activated at block 526 collect damage identification data. In some examples, the damage-identification data is collected to identify the type, location on the vehicle, severity, and/or source (e.g., person, vehicle, etc.) of damage caused to the vehicle 100. For example, the camera 116 collects damage identification data (e.g., images and/or video) to facilitate identifying a source of damage to the vehicle 100. Accordingly, the one or more sensors 204 activated at block 510 may collect damage detection data when the camera module 228 is in a sleep mode to conserve a charge level of the battery 104, and the one or more cameras 116 collect damage identification data when the camera module 228 is in an active mode.

At block 530, remote processor 218 determines whether the data collection duration has been reached. In response to remote processor 218 determining that the data collection duration has been reached, method 500 proceeds to block 534. Otherwise, in response to remote processor 218 determining that the data collection duration has not been reached, method 500 proceeds to block 532, at which block 532 remote processor 218 determines whether to activate another of sensor 204 and/or ECU206 to collect additional damage identification data. In response to remote processor 218 determining not to activate the other of sensor 204 and/or ECU206, the method proceeds to block 534. Otherwise, in response to the remote processor 218 determining to activate the other of the sensor 204 and/or the ECU206, the method 500 returns to block 526. In some examples, one or more sensors 204 (e.g., proximity sensors 114) that are activated to collect damage detection data to also collect damage identification data. Further, in some examples, remote processor 218 activates (e.g., via an activation signal) clock 234 of central timing module 226 to detect when damage to vehicle 100 is caused. Additionally or alternatively, remote processor 218 activates (e.g., via an activation signal) communication module 122 (e.g., a dedicated short-range communication module) to communicate with a nearby vehicle (e.g., via vehicle-to-vehicle communication) and/or a nearby infrastructure (e.g., via vehicle-to-infrastructure communication) to collect damage identification data from the nearby vehicle and/or the nearby infrastructure. For example, the communication module 122 obtains damage identification data via vehicle-to-vehicle communication, the damage identification data being collected from a camera of a vehicle located near the vehicle 100 when the damage occurs.

At block 534, the vehicle 100 transmits and/or stores vehicle identification data that is to be accessed at a later time to determine the type, location, severity, and/or source (e.g., person, vehicle, etc.) of damage to the vehicle 100. For example, the vehicle 100 stores the vehicle identification data in the database 214 of the battery control module 202 of the vehicle 100 and/or transmits the vehicle identification data to the remote processor 218 via the communication module 108. Further, at block 536, upon detecting damage to the vehicle, the communication module 112 of the vehicle 100 notifies (e.g., via a text message) a user (e.g., a driver) of the vehicle 100.

FIG. 6 is a flow diagram of an example method 600 implementing block 310 of FIG. 3 for activating one or more control modules of a vehicle based on a parking location and an expected parking duration. The flowchart of fig. 6 represents machine readable instructions stored in a memory (such as the memory 212 of fig. 2) and including one or more programs that, when executed by a processor (such as the processor 210 of fig. 2), cause the example vehicle 100 of fig. 1 to activate one or more of the example ECUs 206 of fig. 2 based on a parking location and an expected parking duration. Although the example program is described with reference to the flowchart shown in FIG. 6, many other methods for activating the control module based on the parking location and expected parking duration may alternatively be used. For example, the order of execution of the blocks may be rearranged, changed, eliminated, and/or combined to perform the method 600. Further, because the method 600 is disclosed in conjunction with the components of fig. 1-2, some of the functionality of these components will not be described in detail below.

Initially, at block 602, the remote processor 218 determines the type of position at which the vehicle 100 is in the ignition off state. For example, remote processor 218 may identify that vehicle 100 is at a gas station, post office, parallel parking along a side of a street, and so forth. At block 604, the remote processor determines an expected parking duration based on the type of location where the vehicle 100 is parked. That is, remote processor 218 identifies the duration of the stop of vehicle 100 at the location based on the historical data. In some examples, remote processor 218 utilizes cloud-based learning to determine a parking duration for a geo-fenced area that includes the location of vehicle 100 based on previous parking data provided by vehicle 100 and/or other vehicles. For example, if remote processor 218 determines that the vehicle is parked at a fueling station, remote processor 218 identifies a parking duration associated with the fueling station. If remote processor 218 determines that the vehicle is parked at a store (e.g., a post office), remote processor 218 identifies a parking duration associated with the store. If remote processor 218 determines that the vehicle is parked parallel along the street, remote processor 218 identifies a parking duration associated with the vehicle parked on the street.

At block 606, the remote processor 218 determines the current charge level of the battery 104 of the vehicle 100. For example, to determine the current charge level of the vehicle while the battery control module 202 is in the sleep mode, the remote processor 218 calculates the current charge level of the battery 104 based on the charge level of the battery 104 before the vehicle 100 is in the ignition-off state and the duration of time the vehicle 100 is in the ignition-off state. In some examples, remote processor 218 identifies a rate of discharge of the battery 104 at which the charge level is reduced based on the make, model, body type, option pack, and/or any other characteristic of the vehicle 100. Further, in some examples, remote processor 218 determines the current charge level of battery 104 based on whether and to what extent the battery 104 has been recharged via solar panel 132, EV receptacle 134, and/or any other recharging source. For example, the solar panel 132 may reduce and/or counteract the discharge rate of the cell 104 over time.

At block 608, remote processor 218 determines whether the current charge level of battery 104 is greater than a predetermined charge threshold. For example, the predetermined charge threshold corresponds to a minimum charge level that enables one or more ECUs 206 (e.g., control modules) to be activated for a predetermined amount of time (e.g., a minimum activation duration) without causing the battery 104 of the vehicle 100 to drain or discharge. In response to remote processor 218 determining that the current charge level of battery 104 is not greater than the predetermined charge threshold, method 600 ends. In some examples, the battery control module 202 (e.g., via the communication module 108) and/or the remote processor 218 notifies the driver via the mobile device that the battery 104 has a low charge level. Additionally or alternatively, when the vehicle 100 is outdoors (e.g., as determined via the GPS receiver 110), the battery control module 202 may autonomously start the vehicle 100 for a period of time to enable the battery 104 to recharge over time. In such an example, when the vehicle is indoors, the battery control module 202 may not autonomously start the vehicle 100 to avoid carbon monoxide build-up within the indoor facility. Otherwise, in response to remote processor 218 determining that the current charge level of battery 104 is greater than the predetermined charge threshold, method 600 proceeds to block 610.

At block 610, the remote processor 218 identifies one or more ECUs 206 that facilitate user interaction. For example, the remote processor 218 identifies an infotainment host unit 124 that presents media and/or other information to a user of the vehicle 100, a telematics control unit 222 that enables the user to identify their location, a central timing module 226 that enables the user to identify time, a camera module 228 that enables one or more cameras 116 to collect images and/or video presented to the user, a communication module 122 that facilitates communication between the vehicle 100 and the user's mobile device, a body control module 230 that enables the user to control windows, seat positions, and/or other settings of the vehicle 100, an HVAC module 232 that enables the user to control settings of the HVAC unit 130, and so forth.

At block 612, the remote processor 218 sequences the activation of the ECU206 identified at block 610. For example, the remote processor 218 determines which ECUs 206 are to be activated and in what order while the vehicle 100 remains in the ignition off state to prevent activation of one or more ECUs 206 from causing the battery 104 to discharge. Remote processor 218 sequences ECU206 based on the charge level of battery 104, the location of vehicle 100, and/or the corresponding parking duration. For example, if the vehicle 100 is parked at a fueling station, the remote processor 218 prioritizes the infotainment host unit 124 to cause media (e.g., music) to continue to be presented to the user while the vehicle 100 is being refilled at the fueling station. If the vehicle 100 is parked at a post office, the remote processor 218 may prioritize the HVAC module 232 to enable the HVAC unit 130 to maintain a comfortable cabin environment for the user to return. If the vehicle 100 is parked parallel along one side of the street, the remote processor 218 may prioritize the camera module 228 and the communication module 122 so that one or more cameras 116 can obtain images and/or video of the vehicle 100, and the communication module 122 sends the images and/or video to the user's mobile device to enable the user to monitor the vehicle 100. In other examples where the vehicle 100 is parked along one side of a street in parallel, the remote processor 218 may prioritize the central timing module 226 and the communication module 122 in order to alert the user via the mobile device when the parking meter will be paid for.

At block 614, the remote processor 218 sends an activation signal to the communication module 108 of the vehicle 100 to activate one of the ECUs 206 of the vehicle 100. That is, the remote processor 218 sends an activation signal to the vehicle 100 in response to determining that the charge level of the battery 104 is greater than the predetermined threshold associated with the location where the vehicle 100 is parked. Additionally or alternatively, remote processor 218 sends an activation signal to vehicle 100 in response to determining that the charge level of battery 104 is greater than the predetermined threshold associated with the parking duration identified at block 604.

For example, if the vehicle 100 is parked at a fueling station, the remote processor 218 sends an activation signal to the communication module 108 to activate the infotainment host unit 124 so that the display 126 and/or the speaker 128 present media to the user of the vehicle 100 during fueling of the vehicle 100. For example, after the vehicle 10 has transitioned from the startup state to the ignition-off state, the remote processor 218 sends an activation signal, the communication module 108 receives the activation signal, the gateway module 220 causes the battery control module 202 to activate upon the communication module 108 receiving the activation signal, and the battery control module 202 subsequently activates the infotainment host unit 124.

In other examples, if the vehicle 100 is parked at a post office, the remote processor 218 sends an activation signal to activate the HVAC module 232 to enable the HVAC unit 130 to maintain a comfortable cabin environment of the vehicle 100. If the vehicle 100 is parked parallel along a side of a street, the remote processor 218 sends an activation signal to activate the camera module 228 and the communication module 122 (e.g., a dedicated short-range communication module) to enable a user to monitor the vehicle 100 via images and/or videos obtained by the one or more cameras 116. In other examples where the vehicle 100 is parked along one side of a street in parallel, the remote processor 218 sends an activation signal to activate the central timing module 226 and the communication module 122 in order to alert the user that the parking meter is about to expire.

At block 616, the remote processor 218 and/or the battery control module 202 determines the activation duration of the one ECU206 that is activated based on the current charge level and/or which ECU206 is activated. For example, the activation duration is determined to prevent the battery 104 of the vehicle 100 from being discharged due to activation of the infotainment host unit 124 and/or any other ECU while the vehicle 100 remains in the ignition-off state.

At block 618, remote processor 218 determines whether the activation duration has been reached. In response to remote processor 218 determining that the activation duration has been reached, the activated one or more ECUs 206 return to the sleep mode and method 600 ends. Otherwise, in response to remote processor 218 determining that the activation duration has not been reached, method 600 proceeds to block 620, at which block 620 remote processor 218 determines whether to set another ECU206 to the active mode. In response to remote processor 218 determining to place another ECU206 in the active mode, method 600 returns to block 614. For example, if the vehicle 100 is at a fueling station and the infotainment host unit 124 is activated, the remote processor 218 may also activate the HVAC module 232 if the charge level of the battery 104 is sufficiently high. Otherwise, in response to remote processor 218 determining not to set another ECU206 to the active mode, method 600 proceeds to block 622 where remote processor 218 determines whether the activation duration has been reached. In response to remote processor 218 determining that the activation duration has been reached, the activated one or more ECUs 206 return to the sleep mode and method 600 ends. Otherwise, in response to remote processor 218 determining that the activation duration has not been reached, method 600 returns to block 622.

In this application, the use of the conjunction of the contrary intention is intended to include the conjunction. The use of the definite or indefinite article is not intended to indicate cardinality. In particular, references to "the" object or "an" and "an" object are intended to mean possibly one of more such objects. Furthermore, the conjunction "or" may be used to convey simultaneous features, rather than mutually exclusive schemes. In other words, the conjunction "or" should be understood to include "and/or". The term "comprising" is inclusive and has the same scope as "comprising".

The above-described embodiments, particularly any "preferred" embodiments, are possible examples of implementations, and are presented merely for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiments without departing substantially from the spirit and principles of the technology described herein. All such modifications are intended to be included within the scope of this disclosure and protected by the following claims.

Claims

1. A system for activating a vehicle control module, comprising:

a vehicle in an ignition off state at a position, the vehicle comprising:

a communication module for receiving an activation signal; and

a telematics control unit to perform the following operations:

activate upon receiving the activation signal; and

determining and presenting a route from the location; and

a remote processor to perform the following operations:

determining the location;

identifying an event and an end time based on the location;

determining a current charge level of a battery of the vehicle at a charge level before the vehicle is in the ignition-off state and a duration of time the vehicle is in the ignition-off state;

activating the telematics control unit in response to determining that the current charge level is greater than a predetermined charge threshold; and

transmitting the activation signal based on the end time.

2. The system of claim 1, wherein the vehicle includes an ignition switch having an on position corresponding to an on state of the vehicle and an off position corresponding to an off state of the ignition switch of the vehicle.

3. The system of claim 2, wherein the communication module of the vehicle sends a vehicle status signal to the remote processor before the vehicle is in the ignition off state, the vehicle status signal including the location and a charge level of a battery.

4. The system of claim 1, wherein the vehicle includes a battery, a battery sensor for detecting a charge level of the battery, and a battery control module that activates the telematics control unit upon the communication module receiving the activation signal from the remote processor.

5. The system of claim 4, wherein the battery control module activates a body control module after the communication module receives the activation signal.

6. The system of claim 1, wherein the remote processor determines an activation duration for which the telematics control unit is activated based on the current charge level, and the telematics control unit returns to a sleep mode once the activation duration ends and the vehicle remains in the ignition switch off state, thereby preventing the battery from discharging.

7. The system of claim 1, wherein the remote processor sends the activation signal to the communication module a predetermined time period after the end time.

8. The system of claim 1, wherein the telematics control unit determines the route as a fastest driving route between the location and a destination based on traffic data and weather condition data.

9. A method for activating a vehicle control module, the method comprising:

activating a telematics control unit upon receiving an activation signal corresponding to the end time;

determining and presenting, via the telematics control unit, a route from the location;

detecting, via a battery sensor, a charge level of a battery of the vehicle;

determining, via the processor, a current charge level of the battery based on the charge level detected before the vehicle is in the ignition-off state and a duration of time the vehicle is in the ignition-off state; and

upon determining, via the processor, that the current charge level is greater than a predetermined threshold, the telematics control unit is activated.

10. The method of claim 9, further comprising:

11. A tangible computer readable medium comprising instructions that, when executed, cause a machine to:

detecting, via a battery sensor, a charge level of a battery of the vehicle;