Vehicle communications and surveillance

Abstract

For example, among other examples, systems and methods for vehicle communications are provided to provide various connections and capabilities according to hardware availability, power constraints, and environmental conditions.

Description

Technical Field

[0001]

Background Art

[0002]

[0002] Recreational vehicles such as motorcycles, or off-road vehicles such as all-terrain vehicles (ATVs), utility vehicles (UVs), side-by-side vehicles, and snowmobiles are widely used for entertainment purposes. The vehicle can be equipped with a warning system for monitoring the recreational vehicle on both roads and trails, or on trails only.

[0003]

[0003] Embodiments are described in relation to such considerations and other general considerations. Also, relatively specific problems are discussed, but it should be understood that the embodiments should not be limited to solving the specific problems identified in the background. Related Applications

[0004]

[0001] This disclosure is related to U.S. Provisional Patent Application No. 63 / 093,819, Serial No. PLR-00TC-29463.01P-US, entitled "VEHICLE COMMUNICATION AND MONITORING SYSTEMS AND METHODS", filed on October 20, 2020, U.S. Provisional Application No. 63 / 165,920, Serial No. PLR-00TC-29341.01P-US, entitled "SYSTEMS AND METHODS FOR VEHICLE HAZARDOUS CONDITION DETECTION", filed on March 25, 2021, and U.S. Provisional Application No. 63 / 192,407, Serial No. PLR-886-29463.02P-US, entitled "VEHICLE COMMUNICATION AND MONITORING", filed on May 24, 2021, the entire disclosures of which are hereby expressly incorporated herein by reference.

Summary of the Invention

[0005]

[0004] As described above, the embodiments provided herein relate to recreational vehicles. Exemplary embodiments include, but are not limited to, the following examples.

[0006]

[0005] In one embodiment, a vehicle intercept circuit is provided. The intercept circuit comprises a first connector which can be connected to the vehicle's key switch connector, a second connector which can be connected to the vehicle's key switch harness, and a controller connected to the first and second connectors, wherein the controller is configured to pass a signal from the first connector to the second connector in a first operating mode, and to interrupt the signal in a second operating mode, thereby preventing the transmission of a signal from the first connector to the second connector.

[0007]

[0006] In another embodiment, a vehicle is provided. The vehicle comprises a frame, a prime mover supported by the frame, a battery supported by the frame, and a controller, the controller being configured to receive an instruction for an operating mode, wherein the operating mode is at least one of a shipping operating mode, a driver connection operating mode, an off-season storage operating mode, a start guarantee operating mode, an over-the-air (OTA) operating mode, and a warehouse operating mode, and to configure the vehicle according to the instructed operating mode.

[0008]

[0007] In a further embodiment, a method is provided for configuring a vehicle based on the charge state of a battery. The method includes the steps of: evaluating the charge state based on a first predetermined threshold; configuring a vehicle connection circuit to be activated periodically based on the determination that the charge state is below the first predetermined threshold; communicating with a vehicle platform when the connection circuit is activated; evaluating the charge state based on a second predetermined threshold that is below the first predetermined threshold; and deactivating the vehicle connection circuit based on the determination that the charge state is below the second predetermined threshold.

[0009]

[0008] In one embodiment, a telematics control unit for a vehicle is provided. The telematics control unit comprises a first cellular modem, a second cellular modem, a set of shared modem resources including an antenna, a switch having a first state in which the first modem is coupled to the antenna, and a second state in which the second modem is coupled to the antenna, and a controller connected to the switch. The controller is configured to configure the switch to the first state and establish a first connection to a cellular network using the first modem, and to configure the switch to the second state and establish a second connection to a cellular network using the second modem.

[0010]

[0009] In another embodiment, another telematics control unit for a vehicle is provided. The telematics control unit comprises a cellular modem, a switch that electrically communicates with the cellular modem, an extension interface that enables communication with the cellular modem via the switch when the switch is in a first state, and a processor that communicates with the cellular modem via the switch when the switch is in a second state. The processor is configured to configure the switch to be in a first state based on a decision to perform processing in a high-power domain, and to configure the switch to be in a second state based on a decision to perform processing in a low-power domain associated with the processor.

[0011]

[0010] In a further embodiment, a method is provided for managing high-power and low-power states of a telematics control unit. The method includes the steps of: processing data received from a vehicle platform using a first cellular modem using a low-power domain of a first processor of the telematics control unit; determining, based on the received data, to transition to a high-power state; booting up a high-power domain of a second processor of the telematics control unit based on the decision to transition to a high-power state; and providing at least a portion of the received data to the second processor for processing in response to receiving instructions from the high-power domain.

[0012]

[0011] Although several embodiments are disclosed, other embodiments of the subject matter of this disclosure will become apparent to those skilled in the art from the following detailed description illustrating and describing exemplary embodiments of the subject matter of this disclosure. Accordingly, the drawings and detailed description should be considered illustrative and not restrictive.

[0013]

[0012] The above-mentioned and other features and advantages of this disclosure, and the manner in which they are achieved, will become more apparent and better understood by referring to the following description of embodiments of the present invention in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0014] [Figure 1] This figure shows an exemplary recreational vehicle according to the embodiments of this disclosure. [Figure 2] This figure shows an exemplary recreational vehicle according to the embodiments of this disclosure. [Figure 3] This figure shows an exemplary recreational vehicle according to the embodiments of this disclosure. [Figure 4] This figure shows an exemplary recreational vehicle according to the embodiments of this disclosure. [Figure 5A]Figures 1 to 4 show exemplary processing sequences and additional details for each embodiment of the vehicle 100. [Figure 5B] Figures 1 to 4 show exemplary processing sequences and additional details for each embodiment of the vehicle 100. [Figure 5C] Figures 1 to 4 show exemplary processing sequences and additional details for each embodiment of the vehicle 100. [Figure 6] This figure shows an exemplary processing sequence for vehicle 100 regarding communication of vehicle health status. [Figure 7] This figure shows an exemplary user interface for displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. [Figure 8] This figure shows an exemplary user interface for displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. [Figure 9] This figure shows an exemplary user interface for displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. [Figure 10] This diagram provides various graphical representations of tire pressure status information. [Figure 11] This figure shows an exemplary processing sequence for vehicle 100 related to problem diagnosis. [Figure 12] This diagram shows an example user interface for communicating problem diagnosis information. [Figure 13] This diagram shows an example user interface for communicating problem diagnosis information. [Figure 14] This diagram shows an example user interface for communicating problem diagnosis information. [Figure 15] This figure shows an exemplary processing sequence for vehicle 100 related to predictive maintenance. [Figure 16]It is a diagram showing an exemplary user interface for communicating predictive maintenance information. [Figure 17] It is a diagram showing an exemplary user interface for communicating predictive maintenance information. [Figure 18] It is a diagram showing an exemplary user interface for communicating predictive maintenance information. [Figure 19] It is a diagram showing an exemplary user interface for communicating predictive maintenance information. [Figure 20] It is a diagram showing an exemplary processing sequence of vehicle 100 regarding remote vehicle positioning. [Figure 21] It is a diagram showing an exemplary user interface for communicating remote vehicle positioning information. [Figure 22] It is a diagram showing an exemplary user interface for communicating remote vehicle positioning information. [Figure 23] It is a diagram showing an exemplary user interface for communicating remote vehicle positioning information. [Figure 24] It is a diagram showing an exemplary user interface for communicating remote vehicle positioning information. [Figure 25] It is a diagram showing an exemplary user interface for communicating remote vehicle positioning information. [Figure 26] It is a diagram showing an exemplary processing sequence of vehicle 100 regarding vehicle theft warning. [Figure 27] It is a diagram showing an exemplary user interface for communicating vehicle positioning information. [Figure 28] It is a diagram showing an exemplary user interface for communicating vehicle positioning information. [Figure 29] It is a diagram showing an exemplary user interface for communicating vehicle positioning information. [Figure 30] It is a diagram showing an exemplary user interface for communicating vehicle positioning information. [Figure 31] It is a diagram showing an exemplary user interface for communicating vehicle positioning information. [Figure 32] It is a diagram providing a representation of towed vehicle 100. [Figure 33] This figure shows an overview of power management according to the aspects of this disclosure. [Figure 34] This figure shows an exemplary system that can use the vehicle connection function according to the embodiments of this disclosure. [Figure 35A] This figure provides an overview of an exemplary method for processing condition information from a vehicle platform for vehicle theft warnings according to the embodiments described herein. [Figure 35B] This figure shows an overview of an exemplary method for aggregating information for vehicle condition processing according to the embodiments described herein. [Figure 36A] This figure provides an overview of exemplary methods for utilizing the available memory space of a vehicle's electronic control unit. [Figure 36B] This figure provides an overview of an exemplary method for accessing data stored by a vehicle's electronic control unit. [Figure 37A] This figure shows an overview of an exemplary method for controlling the vehicle state according to the vehicle's charge status. [Figure 37B] This figure provides an overview of another exemplary method for controlling the vehicle state according to the vehicle's charge status. [Figure 37C] This figure shows an overview of an exemplary set of vehicle states and associated transitions according to the embodiments of this disclosure. [Figure 38] This figure shows an illustrative overview of how an intercept circuit according to an aspect of this disclosure can be used. [Figure 39] This figure shows an overview of an exemplary method for controlling a vehicle using an intercept circuit according to an aspect of the present disclosure. [Figure 40] This figure shows an overview of an exemplary vehicle state associated with an intercept circuit. [Figure 41] This figure shows an overview of the transition logic associated with exemplary vehicle states and intercept circuits. [Figure 42] This figure shows an overview of an illustrated intercept circuit according to the embodiments of this disclosure. [Figure 43]This figure shows an exemplary system, according to embodiments described herein, in which a driver interface and an add-on telematics control unit operate to provide vehicle connectivity functions. [Figure 44] This figure shows an exemplary system in which the telematics control unit incorporates the embodiments described above with respect to Figure 43. [Figure 45A] This figure shows an overview of exemplary methods for configuring high-power and low-power connections in a vehicle according to embodiments described herein. [Figure 45B] This figure shows an overview of exemplary methods for configuring a vehicle's high-power or low-power modem. [Figure 46A] This figure shows an overview of an exemplary method for performing low-power processing according to the embodiments described herein. [Figure 46B] This figure shows an overview of an exemplary method for carrying out high-power processing according to the embodiments described herein. [Figure 47A] This figure provides an overview of exemplary methods for addressing warning conditions in the low-power domain according to the aspects of this disclosure. [Figure 47B] This figure provides an overview of exemplary methods for addressing warning conditions in high-power domains according to aspects of this disclosure. [Figure 48] This figure shows an exemplary processing sequence for vehicle 100 regarding the provision of a post-boarding reporting function. [Figure 49] This diagram shows an example user interface for communicating boarding report information. [Figure 50] This diagram shows an example user interface for communicating boarding report information. [Figure 51] This diagram shows an example user interface for communicating boarding report information. [Figure 52] This figure shows an example user interface for group boarding tracking. [Figure 53] This figure shows an example user interface for group boarding tracking. [Figure 54]This figure shows an example user interface for group boarding tracking. [Figure 55] This figure shows an example user interface for group boarding tracking. [Figure 56] This figure shows an example user interface associated with the SOS warning function. [Figure 57] This figure shows an example user interface associated with the SOS warning function. [Figure 58] This diagram shows an exemplary user interface associated with a personal routing plan. [Figure 59] This diagram shows an exemplary user interface associated with a personal routing plan. [Figure 60] This diagram shows an exemplary user interface associated with a personal routing plan. [Figure 61] This diagram shows an exemplary user interface associated with a personal routing plan. [Modes for carrying out the invention]

[0015]

[0054] Throughout some of the figures, corresponding reference numerals indicate corresponding parts. While the drawings represent embodiments of the present disclosure, they are not necessarily to scale, and certain features may be exaggerated to better illustrate and illustrate the present disclosure. The examples described herein illustrate embodiments of the present disclosure and should not be construed as limiting the scope of the present disclosure in any way.

[0016]

[0055] Various embodiments of this disclosure will be described in detail with reference to the drawings. In the drawings, similar reference numerals represent similar parts and assemblies in several figures. In addition, any examples described herein are not intended to be limiting and only describe a selection of many possible embodiments.

[0017]

[0056] Referring to Figure 1, Vehicle 100 is represented. Vehicle 100 is an exemplary recreational vehicle, in particular a side-by-side off-road vehicle. Additional details relating to exemplary embodiments of Vehicle 100 are disclosed in Vehicle 200 as described herein and may further be configured as shown in U.S. Patent No. 8,827,028, U.S. Patent Application No. 16 / 458,797 published as U.S. Patent Application Publication No. 20200164742, U.S. Patent Application No. 16 / 244,462 published as U.S. Patent Application Publication No. 20190210668, and / or U.S. Patent Application No. 16 / 861,859, the entirety of which disclosures are expressly incorporated herein by reference. Other exemplary recreational vehicles include snowmobiles, boats, motorcycles, ATVs, utility vehicles, golf carts, and other suitable vehicles. Additional exemplary vehicle and display systems are disclosed in U.S. Patent Application Publication No. 20180257726, filed March 5, 2018, entitled "TWO-WHEELED VEHICLE," U.S. Patent Application No. 16 / 723,754, filed December 20, 2019, entitled "SNOWMOBILE STORAGE COMPARTMENT, DISPLAY, ANTENNA, AND BODY TRIM SYSTEM," and U.S. Patent Application Publication No. 20170334500, filed May 23, 2016, entitled "DISPLAY SYSTEMS AND METHODS FOR A RECREATIONAL VEHICLE," the entirety of which is expressly incorporated herein by reference.

[0018]

[0057] The recreational vehicle 100 includes a plurality of ground engagement members 102. Exemplary ground engagement members include skis, tracks, wheels, and other suitable devices for supporting the vehicle 100 against the ground. The recreational vehicle 100 further includes a frame 104 supported by the plurality of ground engagement members 102. In one embodiment, the frame 104 includes cast parts, welds, tubular components, or a combination thereof. In one embodiment, the frame 104 is a rigid frame. In one embodiment, the frame 104 has at least two sections that are movable relative to each other.

[0019]

[0058] The driver support is supported by the frame 104. An exemplary driver support includes a saddle seat, a bench seat, a bucket seat, and other suitable support members. In addition to the driver support, the recreational vehicle 100 may further include a passenger support. An exemplary passenger support includes a saddle seat, a bench seat, a bucket seat, and other suitable support members.

[0020]

[0059] The powertrain is supported by the frame 104 and includes, exemplary, a prime mover 112 and a transmission 116. The powertrain provides prime mover power and transmits it to at least one of the ground engagement members 102 to power the movement of the recreational vehicle 100.

[0021]

[0060] Exemplary prime movers 112 include internal combustion engines, two-stroke internal combustion engines, four-stroke internal combustion engines, diesel engines, electric motors, hybrid engines, and other suitable prime movers. A vehicle starting system 114 is provided for starting the prime mover 112. The type of vehicle starting system 114 depends on the type of prime mover 112 used. In one embodiment, the prime mover 112 is an internal combustion engine, and the vehicle starting system 114 is one of a pull-start system and an electric starting system. In one embodiment, the prime mover 112 is an electric motor, and the vehicle starting system 114 is a switch system that electrically connects one or more batteries to the electric motor. In embodiments, the vehicle starting system includes a key (or key fob).

[0022]

[0061] The transmission 116 is coupled to the prime mover 112. In embodiments, the transmission 116 includes a shiftable transmission and a continuously variable transmission ("CVT"). In one configuration, the CVT is coupled to the prime mover 112, and the shiftable transmission is coupled to the CVT. In one embodiment, the shiftable transmission includes forward high-speed setting, forward low-speed setting, neutral setting, parking setting, and reverse setting. Exemplary CVTs are disclosed in U.S. Patents 3,861,229, 6,176,796, 6,120,399, 6,860,826, and 6,938,508, the disclosures of which are expressly incorporated herein by reference. The transmission 116 is further coupled to at least one differential (not shown), the differential is coupled to at least one ground engagement member 102.

[0023]

[0062] The recreational vehicle 100 further includes a plurality of suspension systems 120 that connect ground engagement members 102 to a frame 104. Exemplary suspension systems include U.S. Patent Application No. 16 / 013,210, filed June 20, 2018, entitled "VEHICLE HAVING SUSPENSION WITH CONTINUOUS DAMPING CONTROL", U.S. Patent Application No. 16 / 529,001, filed August 1, 2019, entitled "ADJUSTABLE VEHICLE SUSPENSION SYSTEM", U.S. Patent Application No. 15 / 816,368, filed November 17, 2017, entitled "ADJUSTABLE VEHICLE SUSPENSION SYSTEM", and U.S. Patent Application No. 16 / 198,280, filed November 21, 2018, entitled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING", entitled "SYSTEMS AND METHODS OF ADJUSTABLE SUSPENSIONS FOR OFF-ROAD RECREATIONAL This is disclosed in U.S. Provisional Patent Application No. 63 / 027,833, filed on 20 May 2020, under the reference number PLR-01-29147.01P-US, entitled "VEHICLES," and in U.S. Provisional Patent Application No. 63 / 053,278, filed on 17 July 2020, under the reference number PLR-15-29249.01P-US, entitled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING," the entirety of which is expressly incorporated herein by reference.

[0024]

[0063] The recreational vehicle 100 further includes a braking system 122. In one embodiment, the braking system 122 includes an anti-lock brake.

[0025]

[0064] The recreational vehicle 100 further includes a steering system 124. The steering system 124 is coupled to at least one of the ground engagement members 102 to orient the recreational vehicle 100.

[0026]

[0065] The recreational vehicle 100 further includes a plurality of sensors 126 that monitor various characteristics of the vehicle 100, and a battery 128 that provides power to various components of the vehicle 100. Exemplary sensors include, but are not limited to, a Global Positioning System (GPS) sensor, an accelerometer, a conductive ball socket, an ambient temperature sensor, an image sensor, a microphone, or a LiDAR sensor.

[0027]

[0066] Furthermore, the recreational vehicle 100 includes a vehicle controller 140 having at least one processor 142 and at least one associated memory 144. The vehicle controller 140 provides electronic control of various components of the recreational vehicle 100. In addition, the vehicle controller 140 is operably coupled to a plurality of sensors 126 that monitor various parameters of the recreational vehicle 100 or the environment surrounding the vehicle 100. The vehicle controller 140 performs specific operations on one or more subsystems of other vehicle components, such as one or more of the fuel system, air treatment system, CVT, shiftable transmission, prime mover 112, suspension system 120, and other systems. In certain embodiments, the controller 140 forms part of a processing subsystem that includes one or more computing devices having memory, processing, and communication hardware. The controller 140 may be a single device or a distributed device, and the functions of the controller 140 may be implemented by hardware and / or as computer instructions on a non-temporary computer-readable storage medium such as memory 144.

[0028]

[0067] The vehicle controller 140 also interacts with a driver interface 150 which includes at least one input device 152 and at least one output device 154. Exemplary input devices 152 include levers, buttons, switches, soft keys, and other appropriate input devices. Exemplary output devices include lighting, displays, sound devices, haptic devices, and other appropriate output devices. The driver can signal the vehicle controller 140 to change the operation of one or more systems of the vehicle 100 through the input devices 152. Additional embodiments of the vehicle controller 140 are described below with reference to Figures 5A to 5C.

[0029]

[0068] Furthermore, the vehicle 100 includes a wireless plug-in dongle 170 operably coupled to the controller 140. The dongle 170 provides a communication link between the vehicle controller 140 and remote storage, exemplary, a cloud 180. The dongle can receive information and / or commands from the cloud for use by the vehicle controller 140 and can provide information and / or commands to a remote device 182 or another vehicle 200 through the cloud 180. Furthermore, information stored in the cloud 180 can be retrieved through a web interface associated with the vehicle 100. In embodiments, the dongle 170, also referred to as a connection circuit, is powered by the vehicle 100's battery 128. A processing sequence for controlling the depletion of the battery 128 is provided herein.

[0030]

[0069] Referring to Figure 2, another exemplary embodiment of the vehicle 100 is shown. As shown in Figure 2, the vehicle 100 includes a display 220 as part of a driver interface 150. The display 220 includes a processor 222 and associated memory 224. In an embodiment, the driver interface 150 having the display 220 is an in-vehicle infotainment ("IVI") system. In one example, the display 220 is a touchscreen display, and the driver interface interprets various types of touches to the touchscreen display as input and controls what is displayed on the touchscreen display.

[0031]

[0070] Referring to Figure 3, a further exemplary embodiment of the vehicle 100 is shown. The vehicle 100 in Figure 3 is the same as the vehicle 100 in Figure 1, except that the dongle 170 is replaced by a telematics control unit ("TCU") 250. The telematics control unit 250 differs from the dongle 170 in that it can be periodically activated while the vehicle 100 is not operating to communicate with the cloud 180, remote devices 182, and / or other vehicles 200. Both the TCU 250 and the dongle 170 have security features that are effective for remote notification of theft warnings when the vehicle is not operating. In embodiments, the telematics control unit 250, also referred to as a connection circuit, is powered by the battery 128 of the vehicle 100. A processing sequence for controlling the depletion of the battery 128 is provided herein.

[0032]

[0071] The telematics control unit 250 is further shown to have a high-speed connection 252 (for example, to the driver interface 150) and a low-speed connection 254 (for example, to the vehicle controller 140). Similar to the embodiments discussed in more detail below with respect to the high-speed connection 538 and low-speed connection 540 in Figure 34, the telematics control unit 250 can utilize the high-speed connection 252 in association with various high-speed functions of the driver interface 150. Similarly, the telematics control unit 250 can utilize the low-speed connection 254 for various low-speed functions, such as communication with the vehicle controller 140. In the example, the low-speed connection 254 is a CAN bus connection, and as a result, a line is shown from the telematics control unit 250 to the vehicle controller 140, but it will be understood that the telematics control unit 250 can use the low-speed connection 254 to communicate with any of the various other components of the vehicle 100. For example, the telematics control unit 250 can communicate with the driver interface 150 via its connection 256, which may also be a low-speed connection (e.g., to a CAN bus). Similarly, the high-speed connection 252 does not have to be limited to the telematics control unit 250 and the driver interface 150, but may include, for example, a packet-switched network between additional vehicle components and / or alternative vehicle components.

[0033]

[0072] Referring to Figure 4, a further exemplary embodiment of the vehicle 100 is shown. The vehicle 100 in Figure 4 is the same as the vehicle 100 in Figure 2, except that the dongle 170 is replaced by a telematics control unit ("TCU") 250. The telematics control unit 250 differs from the dongle 170 in that it can be periodically activated while the vehicle 100 is not operating to communicate with the cloud 180, remote devices 182, and / or other vehicles 200. In embodiments, the telematics control unit 250, also referred to as a connection circuit, is powered by the vehicle 100's battery 128. A processing sequence for controlling the depletion of the battery 128 is provided herein.

[0034]

[0073] Referring to Figures 5A to 5C, exemplary processing sequences and additional details for each of the embodiments of the vehicle 100 shown in Figures 1 to 4 are illustrated. For example, the embodiment of Figure 5A is used in the context of Figure 1, for example, using the wireless plug-in dongle 170. In some cases, the embodiment of Figure 5B is used in the context of Figure 2, for example, using the wireless plug-in dongle 170 and the driver interface 150. In other cases, the embodiment of Figure 5C is used in the context of Figures 3 and / or Figure 4, for example, using the telematics control unit 250 and / or the driver interface 150.

[0035]

[0074] In an embodiment, the dongle 170 or TCU 250 includes location determination means, such as GPS, for providing location information for the vehicle 100. In an embodiment, the location determination means is provided on the vehicle 100 separately from the dongle 170 or TCU 250 for providing location information for the vehicle 100.

[0036]

[0075] In an embodiment, the vehicle 100 includes a separate communication system in addition to, or instead of, the dongle 170 or TCU 250. In an embodiment, the exemplary communication system provides wireless connectivity to a personal computing device, such as a mobile phone, carried by the driver of the vehicle 100. In an embodiment, the exemplary communication system provides a cellular communication device, an RF antenna for direct vehicle 100-vehicle 200 communication, a satellite communication device, and other suitable devices that can connect vehicle 100 to one or more of vehicle 200, remote device 182, and cloud 180. An exemplary vehicle communication system and associated processing sequence are described in U.S. Patent Application No. 16 / 234,162, filed December 27, 2018, titled "RECREATIONAL VEHICLE INTERACTIVE TELEMETRY, MAPPING AND TRIP PLANNING SYSTEM" (PLR-15-25635.04P-02-US) and "VEHICLE TO VEHICLE COMMUNICATIONS DEVICE AND METHODS FOR RECREATIONAL VEHICLES" (PLR-09-27870).U.S. Patent Application No. 15 / 262,113, filed September 12, 2016, under the name 01P-US, titled "COMMUNICATION SYSTEM USING VEHICLE TO VEHICLE RADIO AS AN ALTERNATE COMMUNICATION MEANS," U.S. Patent No. 10,764,729, filed December 12, 2018, titled "COMMUNICATION SYSTEM USING CELLULAR SYSTEM AS AN ALTERNATE TO A VEHICLE TO VEHICLE RADIO," and U.S. Patent Application Publication No. 20190200189, filed December 12, 2018, titled "METHOD AND SYSTEM FOR FORMING A DISTANCED-BASED GROUP IN A VEHICLE TO VEHICLE COMMUNICATION U.S. Patent Application Publication No. 20190200173, filed on December 12, 2018, titled "SYSTEM", U.S. Patent Application Publication No. 20190200188, filed on December 12, 2018, titled "VEHICLE-TO-VEHICLE COMMUNICATION SYSTEM", U.S. Patent Application No. 16 / 811,865, filed on March 6, 2020, with reference number PLR-15-27455.02P-03-US, titled "RECREATIONAL VEHICLE GROUP MANAGEMENT SYSTEM", U.S. Patent Application No. 63 / 016,684, filed on April 28, 2020, with reference number PLR-00TC-27721.01P-US, titled "SYSTEM AND METHOD FOR DYNAMIC ROUTING", "VEHICLE HAVING SUSPENSION WITH CONTINUOUS U.S. Patent Application No. 16 / 013,210, filed on June 20, 2018, with reference number PLR-15-25091.04P-03-US, titled "DAMPING CONTROL," and another application with reference number PLR-15-25091, titled "VEHICLE HAVING ADJUSTABLE SUSPENSION."This is disclosed in U.S. Patent Application No. 15 / 816,368, filed November 17, 2017, under 08P-US, and the entirety of those disclosures is expressly incorporated herein by reference.

[0037]

[0076] Referring to Figures 6 to 33 and 48 to 61, various processing sequences and systems that can be performed by the vehicle 100 are further provided and discussed herein. For example, such embodiments may be implemented using dongles, telematics control units, and / or driver interfaces according to embodiments described herein, among other examples.

[0038]

[0077] Vehicle health status (see Figures 6-10)

[0039]

[0078] Referring to Figure 6, an exemplary processing sequence of vehicle 100 for vehicle health status communication is shown. As illustrated, vehicle data can be collected (e.g., by a dongle or TCU) in response to an event or according to predetermined intervals, and as a result, the vehicle data can be transmitted to a remote computing device such as a cloud or vehicle platform, among other examples. The vehicle data and / or associated processing (e.g., related to vehicle health status information) can be provided to the user for display, for example, using a mobile phone or a website.

[0040]

[0079] Figures 7-10 show exemplary user interfaces for displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. Figure 10 provides various graphical representations of tire pressure status information. Thus, vehicle health status information can be displayed on a vehicle display and / or mobile application in a context that has, for example, a target value (or OK / Not OK status) to provide the status of vehicle health, among other indicators. In the example, a notification can be generated when one or more trigger conditions are met. For example, a push notification can be sent based on vehicle mileage according to a recommended service interval. Additional notifications may include, but are not limited to, oil change required, low tire pressure, low battery, and scheduled maintenance. In the example, a notification may include one or more follow-up actions for scheduling service, or a link to read / view instructions on how to self-check.

[0041]

[0080] Vehicle communication systems disclosed or referenced herein can provide vehicle health data to a remote device or cloud for storage. Exemplary information is provided by one or more sensors supported on the vehicle system or vehicle 100. Exemplary information includes: Humidity temperature Battery voltage fuel level Fuel range Odometer time Front tire pressure (if equipped with TPMS) Rear tire pressure (if equipped with TPMS) Car time VIN - Vehicle Identification Number Miles / hour to the next service Software update availability VIN-specific recalls Number of days since last use Oil change is needed. A regular maintenance reminder with easy follow-up measures for scheduling services or reading / viewing instructions on how to perform a self-check. Driving history Diagnostic code Full recall announcement History codes have the ability to clear the code and the ability to explain what the code is, such as "Failure to ignite - check x, y, z". Based on the last date the fuel level was at its maximum, a fuel stabilizer or refined oil is recommended if the threshold duration is exceeded. A seasonal reminder: it's autumn—please consider doing x, y, and z on your units.

[0042]

[0081] In some cases, data analysis campaigns that operate on specific vehicles or sets of vehicles can be defined on a remote computing device. For example, a data analysis campaign can collect specific vehicle data according to predetermined intervals or in response to specified events (for example, "collect oil pressure versus engine temperature for the first 10 minutes of driving time for all vehicles using part number XXX stored in a location where the ambient temperature is below 10°C for the next two weeks").

[0043]

[0082] For example, the service department may see multiple reports of a problem, at which point the technical department may desire more specific data and actual case examples. Therefore, a dynamic data analysis / collection campaign can be used to identify specific vehicles in the field that meet certain conditions, and consequently, in-vehicle telematics collection and analysis can be performed accordingly. OTA communication allows the data analysis campaign package to be delivered to selected vehicles in the field, enabling the launch, deployment, and operation of an in-field data analysis campaign. Telematics data can then be collected and returned (for example, as shown in Figure 6). Finally, service advice or notifications or other information associated with OTA updates to resolve the identified problem can be sent to the vehicle and / or associated driver (for example, at least some of which may be within the group where the data analysis campaign configuration described herein was implemented).

[0044]

[0083] Problem diagnosis (see Figures 11-14)

[0045]

[0084] Beyond the health summary, the problem diagnosis processing sequence includes the analysis of telematics data to trigger actions that are communicated to the driver or other party on a remote device such as a computer or mobile phone, on the vehicle's display, to notify them of the best course of action. Figure 11 shows an exemplary processing sequence for vehicle 100 regarding problem diagnosis. As illustrated, the vehicle may issue a diagnostic fault code (DTC), which can be obtained (e.g., via a CAN bus by a dongle or TCU) and, among other examples, transmitted to a remote computing device such as a cloud or vehicle platform. The DTC is mapped to descriptors and / or recommended actions. Thus, notifications can be generated (e.g., to an application on the driver's mobile phone), and information available to the driver (e.g., via such a mobile application or website) can be updated to reflect the DTC, descriptors, and / or recommended actions, among other information. Thus, the driver can view such problem diagnosis information and take appropriate action.

[0046]

[0085] An example includes a simple DTC code that triggers a recommended action or is based on collected data, and a subsequent analytical communication step to the driver to mitigate the problem itself. Exemplary user interfaces for communicating problem diagnostic information are given in Figures 12–14. Furthermore, the driver may be provided with a link to service scheduling (see Figure 14). In embodiments, error codes are stored for later retrieval during key-off events. For example, the history of error codes and associated problem diagnostic information may be provided, for example, on the vehicle 100 and / or via a mobile application / website, among other examples. In other examples, the DTC instructions and / or other associated information may be provided to the vendor or other service provider, an automated system for returning on-screen help / tutorials loaded from the internet, or a call center (for example, in response to which live help may be provided to the driver).

[0047]

[0086] Predictive maintenance (see Figures 15-19)

[0048]

[0087] Referring to Figure 15, an exemplary processing sequence for vehicle 100 related to predictive maintenance is shown. As illustrated, vehicle data can be collected (e.g., by a dongle or TCU) in response to an event or according to predetermined intervals, and as a result, the vehicle data can be transmitted to a remote computing device such as a cloud or vehicle platform, among other examples. The vehicle data may be processed according to a set of rules, such as those associated with a specific vehicle model, geographical area, season, and / or usage (e.g., high or low speed, prolonged use in dusty or adverse conditions, or daily operation in sub-zero weather). If the rules are met, a notification can be provided to the user for display, for example, using a mobile phone or website. Thus, the user can see the notification and description regarding which rules have been met. In the example, recommended actions are provided to the user, such as contacting the vendor or other service provider, purchasing replacement parts or other products, or receiving advice on how to operate the vehicle in a particular situation. Exemplary user interfaces for communicating predictive maintenance information are given in Figures 16 to 19.

[0049]

[0088] The disclosed system can detect vehicle abnormalities (failure modes) and recommend early mitigation steps to the occupant based on usage patterns in specific geographical areas with specific riding characteristics. For example, X rapid acceleration / deceleration events in a desert sand area may cause uneven belt wear; the system can detect this condition and recommend early belt replacement or advise on appropriate throttle control while airborne.

[0050]

[0089] The disclosed system can analyze telematics information to provide recommendations regarding vehicle maintenance and use. Notifications can be delivered to the vehicle's display, a remote device, a storage device for later retrieval on the remote device, and / or transmitted by known communication methods such as email, text message, or push notification. In embodiments, reminders and recommendations are provided. Exemplary reminders or recommendations include: Recommended follow-up based on the error code Recall and service warnings Countdown to the next service Recommended fuel age Terrain-specific boarding or vehicle care recommended. A seasonal reminder: it's autumn—please consider doing x, y, and z on your units. A reminder for your flight based on the number of days since your last use. Links to video / tutorial content, or options for scheduling services.

[0051]

[0090] By reporting telematics to the cloud, the vehicle (shown on the display), app (shown on the remote mobile phone), and website garage (web data for the browser to retrieve) should all have vehicle-specific maintenance schedules with remaining miles / engine hours or perceived remaining belt life indicators for the next service and oil change, notifications for the next service with a Do It Yourself tutorial or link to scheduling service, service announcements and recall notices with links to schedule service, and early service recommendations based on DTC codes.

[0052]

[0091] In some cases, the notification of an anomaly may be provided to the dealer or other vehicle service provider. For example, a preferred service provider may be identified from the driver profile, or based on the proximity of the service provider to the vehicle, the driver's device, and / or the address associated with the driver profile. The notification may include vehicle history, driver information, and / or information associated with the anomaly. Thus, the service provider may contact the driver to schedule an appointment or follow up regarding the anomaly, or, as an alternative example, the driver may receive a suggestion or reminder to schedule an appointment with the service provider (for example, via the vehicle, driver device, electronic communications, or a website associated with the vehicle manufacturer).

[0053]

[0092] As another example, recommendations for parts to be purchased may be provided as a result of triggered warnings, fault diagnostic codes, or other information associated with the vehicle. The recommendations may allow the driver to purchase the parts through the vehicle (e.g., using an IVI), through a driver computing device, or through the vehicle manufacturer's website, among other examples.

[0054]

[0093] An example of such additional embodiments is described in U.S. Patent Application No. 16 / 689,212, filed November 20, 2019, entitled "VEHICLE SERVICE SCHEDULING," the entire disclosure of which is expressly incorporated herein by reference.

[0055]

[0094] Remote vehicle locator (see Figures 20-25)

[0056]

[0095] Referring to Figure 20, an exemplary processing sequence for vehicle 100 relating to remote vehicle positioning is shown. As illustrated, geographic location information is transmitted to a remote computing device (e.g., by a dongle or TCU), such as a cloud or vehicle platform, among other examples. The geographic location may be presented via an application or website on the driver's mobile phone. In the example, the geographic location is transmitted according to predetermined intervals (e.g., by battery voltage or vehicle model), or, in another example, a request to update the vehicle's location may be received from the driver, at which point a command to transmit the updated geographic location may be provided (e.g., to the dongle or TCU). Thus, the driver may be able to see the vehicle's current or most recently known location. Exemplary user interfaces for communicating remote vehicle positioning information are given in Figures 21 to 25.

[0057]

[0096] The disclosed system can provide indications of the vehicle's current location or where it was last detected (based on telematics data and timestamps of available connected hardware). In embodiments, collision warnings may be provided when the vehicle is hit, based on sensor data (such as an accelerometer or conductive ball socket), which may include indications of where the collision warning occurred and / or where the vehicle was last powered on. Furthermore, the disclosed system can track the vehicle's location and report when the vehicle left a geographically fenced area or, in other ways, when it moved a predetermined distance from the location where a security protocol or parking function was performed. It is also intended that the vehicle may have the ability to remotely emit an audible noise in response to user input in which a user attempts to signal a security event or otherwise locate the vehicle. An exemplary sound system is described in U.S. Patent Application No. 16 / 522,957, filed on 26 July 2019, entitled "AUDIO SYSTEM FOR A UTILITY VEHICLE," the entire disclosure of which is expressly incorporated herein by reference.

[0058]

[0097] Theft warning (see Figures 26-32)

[0059]

[0098] Referring to Figure 26, an exemplary processing sequence for vehicle 100 regarding vehicle theft warning is shown. As illustrated, user instructions for setting a geofence or point / radius are received by a remote computing device, such as a cloud or vehicle platform. The vehicle location is also received (e.g., from a dongle or TCU), and as a result, the vehicle location is analyzed in relation to the geofence or point / radius. Thus, if it is determined that the vehicle has violated the geofence, a notification is generated, and as a result, the user can see its location on a map. Exemplary user interfaces for communicating remote vehicle positioning information are given in Figures 27 to 31. Figure 32 gives a representation of a towed vehicle 100.

[0060]

[0099] The disclosed system includes setting a parking trigger (manual or automatic) that puts the vehicle into a safety mode for attention to collision and / or movement. This parking trigger may include a mode in which the transmission's parking function is activated by a chock, a set of brakes is activated to prevent the wheels from turning, or a mode in which the ECU enters based on a signal from a mobile device, the vehicle, a key fob, or an input on another representative signaling device. This may also include engine deactivation, power limiting, etc.

[0061]

[0100] The vehicle is locked using the parking security vehicle display, mobile app, or key fob. When the vehicle is locked, if it is hit or an unauthorized start or attempt to start is detected, the vehicle will send a warning to the user.

[0062]

[0101] Parking security activated by proximity of a mobile phone, such as a key fob: When the rider moves away from the motorcycle or off-road vehicle, the app detects the user and prompts them to activate the parking security via a notification. Similarly, when the rider moves away from the motorcycle or off-road vehicle, the key fob can provide some form of notification—auditory, tactile, visual, or otherwise—to remind the user to activate the parking security.

[0063]

[0102] Geofencing Location Security: The geofencing feature allows owners to define geographical areas on a map and control vehicle behavior. When a vehicle crosses a geofence boundary, a notification is sent to the mobile phone. In addition, the mobile phone can communicate with occupants via text, visual, or auditory messages through the display or another mobile phone, or even have the opportunity to restrict vehicle functions.

[0064]

[0103] Automatic Trailer Theft Detection Warning Mute - In embodiments, if theft detection is activated for a vehicle, the disclosed system ignores the movement of the vehicle if it determines that the connected vehicle is being towed by the owner or other authorized user (Figure 32). The system uses the location of the connected vehicle and compares it to the location of the owner's (or other authorized user's) telephone. If they are within a first threshold distance of each other, any triggered theft warning based on the location of the vehicle or detected collision is ignored or the warning is muted. In embodiments, additional system inputs can be used to further increase the certainty that the vehicle is being towed. Exemplary additional system inputs include evaluating the speed of the vehicle and / or user (to determine whether the vehicle is being used), evaluating whether the user's telephone is connected to the vehicle's IVI (to determine whether the vehicle is being used), and evaluating whether the vehicle and the user's telephone are on a track that is a road or highway.

[0065]

[0104] In the example, at least some of the embodiments described above can also be implemented in cases where collision warnings are not enabled. For example, if collision warnings are disabled, the vehicle (e.g., dongle or TCU) may be activated as a result of detecting a collision, but no warning may be sent. Therefore, if movement is detected within a predetermined time after a collision is detected (e.g., according to a location determination means), location updates may be sent more frequently than otherwise, when no collision is detected. Such embodiments may be implemented in addition to the geofencing warnings described above. When movement is no longer determined, the vehicle may revert to a state of less frequent location updates. In cases where the vehicle is in motion, location updates may be provided more frequently (e.g., compared to when the vehicle is off and / or when a collision is detected).

[0066]

[0105] Power management (see Figure 33)

[0067]

[0106] In embodiments, the disclosed system controls the state of a connecting circuit (such as a telematics control unit) in relation to the battery charge state and / or voltage. The need to manage power draw for powersport vehicles stems from the fact that the vehicle's battery is relatively limited compared to other vehicles, and also from the relatively low duty cycle of powersport vehicles (used once every few weeks).

[0068]

[0107] In this embodiment, the battery voltage and / or SOC (from the battery SOC health module) are used to control the state of the connected circuit. Referring to Figure 33, three connection levels of the connected circuit based on the monitored battery voltage and / or SOC are shown.

[0069] Fully Connected: The cell modem of the connection circuit is active, providing full connectivity to the cloud and the user. In this mode, the cell modem is active, and remote devices can reach it ad-hoc. The vehicle remains in fully connected mode when the battery voltage or battery SOC exceeds a predetermined setpoint for a predetermined period of time. This is intended to cover use cases where the user plugs those vehicles into a battery tender or is otherwise powered on by the vehicle.

[0070] Low-power connection: The cell modem is generally off but is activated periodically (e.g., once or twice a day) to provide heart rate or status updates, and then returned to its default off state to conserve battery energy. After a predetermined time has passed since the connection circuit entered low-power mode, the vehicle transitions from full connection mode to low-power connection mode when the battery voltage or battery SOC reaches a second predetermined threshold. The transition from full connection mode to low-power connection may include a notification to the user's app / web / cloud informing them of this change. In embodiments, it is conceivable that low-power connection mode may simply be used when the vehicle is off and not connected to the battery tender.

[0071] Disconnected: The connection circuit is off and therefore does not further drain the battery. After a predetermined time and a lower, predetermined voltage or SOC charge threshold, the device will transition to disconnected mode with notification to the user. The transitions between states (fully connected, low-power connected, and disconnected) are not unidirectional; if the battery voltage increases (for example, when the user plugs the vehicle into the battery tender), the state (i.e., the level of connection) can rise and fall.

[0072]

[0108] In one embodiment, if the battery tender is not detected by the vehicle, or if the battery power is insufficient to wirelessly transmit an update to the vehicle, a notification can be sent to the customer via the cloud on the app informing them that there is an available update for the vehicle, but the battery power is insufficient and the battery tender should be connected.

[0073]

[0109] Post-boarding report (see Figures 48-51)

[0074]

[0110] Referring to Figure 48, an exemplary processing sequence for vehicle 100 regarding post-boarding reporting information is shown. As illustrated, vehicle 100 can record information associated with the tracked boarding (e.g., on and / or off the road), which can then be provided to a remote computing device (e.g., by a dongle or TCU) such as the cloud or vehicle platform. The user can then view the recorded boarding information in real time or upon completion of boarding, for example, via a mobile application or website (e.g., as shown in Figures 49 and 50). For example, once the vehicle is started and boarding begins, a cloud connection can display a live version of the boarding as it takes place. In the example, photographs taken during boarding can be added to the context. Thus, the user does not need to manually initiate tracking in some cases. In some examples, one or more built-in cameras can be used to capture photographs, or, in another example, a post-boarding highlight video (which may further include vehicle performance data, for example) can be automatically created.

[0075]

[0111] Additionally, the vehicle may display information about the current passenger and present options for pausing the passenger log, saving the current passenger, and / or starting a new passenger. In some cases, an on-vehicle passenger summary may be generated, or, as another example, a odometer may be presented. Thus, on-vehicle and cloud-generated passenger reports may include, among other examples, passenger markers for photos, stops, and / or vehicle reporting events such as stops and jumps. An example of an on-vehicle display is shown in Figure 51.

[0076]

[0112] Recorded rides may be shared with the community and / or used to generate post-ride reports, which in some cases may have a 3D flyover representation. Furthermore, such embodiments may be applicable even in cases where the vehicle does not have an IVI. As another example, rides can be viewed from the Ride / Location tab, in addition to being viewed directly from the map. In some cases, there may be a layout that includes a 3D trajectory (which may, for example, be automatically loaded and / or played when the page loads). Similarly, the map of a ride can be viewed by clicking the map segment of the 3D trajectory / map toggle.

[0077]

[0113] Group boarding tracking (Figures 52-55)

[0078]

[0114] Similar to the remote vehicle locator and / or post-boarding reporting methods described above, vehicle locations can be shared with a set of other vehicles (which together may form a vehicle group as shown in Figure 52) using, for example, cellular or vehicle-to-vehicle connectivity. In one example, a vehicle may display its own location and the locations of other vehicles on a map (see Figure 53). In another example, a similar display may be presented by the driver's mobile device, as shown in Figure 55 (for example, if the driver's vehicle does not have the software and / or hardware capabilities to provide such a display). In some cases, notifications can be generated when the group becomes too spread out (for example, according to a predetermined distance threshold and / or distance from a particular vehicle, as in other examples). In another example, route information, spots, waypoints, and / or other sets of map data can be distributed among the group, for example, to provide the driver with directions accordingly. Members of the group can exchange messages with each other, for example, as text messages, voice messages, and / or video messages, examples of which are shown in Figure 54. Such group boarding functionality may be initiated manually (for example, remotely using a mobile device or by providing instructions via the vehicle's driver interface) or automatically, among other examples.

[0079]

[0115] Send the travel plan to the vehicle.

[0080]

[0116] In some examples, the travel plan is communicated to the vehicle, for example, via the cloud or a vehicle platform. For example, the travel plan can be associated with a profile on the vehicle platform, and as a result, the travel plan can be synchronized with the vehicle accordingly (for example, as a result of a similar association with a profile on the vehicle platform). In other examples, the travel plan may be communicated to the vehicle more directly, for example, via Bluetooth tethering (Bluetooth is a registered trademark) to the user's mobile device. In some examples, the travel plan may be communicated to multiple vehicles associated with a predetermined passenger group, such as two or more vehicles to facilitate group boarding. Among other examples, the travel plan can be created using a mobile application or via a website. The travel plan can be displayed on the vehicle's display, and as a result, the driver can see instructions on where to turn along the planned route. For example, a basic travel plan may include a two-point trajectory along a desired route. As a result, the route is presented on the vehicle's display as a trajectory on a map. The driver can also obtain navigation guidance to a single waypoint destination (e.g., distance and direction). While the example illustrates a travel plan, it should be understood that similar techniques may be used in other examples, such as routes, boarding, and waypoints.

[0081]

[0117] SOS warning (see Figures 56-57)

[0082]

[0118] The disclosed system may provide the ability to transmit an SOS alert to a specific device associated with the passenger group, a predetermined emergency contact (e.g., one or more people located near the group boarding or return point), and / or, in some cases, to and including emergency services up to a helicopter life flight. The SOS alert may be manually triggered or automatically triggered by vehicle sensors. For example, it may detect that the vehicle has overturned, rolled over, or experienced a thermal event. In another example, user input may be received to generate an SOS alert.

[0083]

[0119] The warning may be sent to a member of the same group as the vehicle in need of assistance, to a vehicle within a given proximity to the vehicle in need of assistance, or to another identifiable device such as a contact or friend, even if they are not a member of the passenger group. For example, the warning may be sent using an internet connection (e.g., via a cellular network) and / or a local connection (e.g., via Bluetooth, Wi-Fi, and / or vehicle-to-vehicle communication).

[0084]

[0120] In some cases, a help warning message may be pre-entered and stored on the vehicle platform. Instructions for sending a help warning message can be received from the vehicle, causing the vehicle platform to send the help warning message in response. In some cases, the instructions include a recipient, or, in another example, the intended recipient is also pre-stored in association with the help warning message. In some cases, an acknowledgment can be provided to the vehicle indicating that the help warning message was successfully sent.

[0085]

[0121] Exemplary user interfaces for communicating vehicle location information and assistance warnings are given in Figures 56 and 57. While an exemplary SOS warning is described, it should be understood that similar functionality may be provided using any of various other techniques, such as integration with a third-party service or device. Furthermore, while the example is described in the context of a warning or message, it should be understood that SOS warnings may be enabled using similar techniques involving voice and / or video communication.

[0086]

[0122] Individual routing plans (see Figures 58-61)

[0087]

[0123] By leveraging community content, passengers can be alerted to nearby recommended rides based on their riding style and preferences. The disclosed system may suggest community-shared rides based on riding style and other preferences. The suggested rides may originate from community-shared rides. Such community-shared rides and / or other suggested rides may be displayed on the home screen in the vehicle or on a map on a mobile device. This allows passengers to view nearby routes, select a route they wish to ride / drive, and the display or mobile device then creates that route. Possible classifications of rides for recommendation include: Nearby boarding Places where vehicles have been driven in the past Personal preferences / ratings for community boarding High community rating Preferences set on the app or in the vehicle Riding types - Possible categories include rock crawling, mudding, dunes, desert, mountains, and trails. Road type - curved / winding, scenic, long distance, shortest distance, based on speed, based on fuel efficiency, minimum turns, road type (gravel, paved, etc.)

[0088]

[0124] Exemplary user interfaces for communicating possible boarding and boarding type selections are given in Figures 58 to 61.

[0089]

[0125] Remote vehicle lock

[0090]

[0126] In the example, vehicle 100 may have a setting to prompt the driver for a passcode before driving the vehicle, or, in another example, before granting access to higher-power operations of the vehicle. The driver may set the vehicle's passcode using a mobile application on the driver's mobile device, via the vehicle platform, or on the vehicle itself. Similarly, the driver may provide a passcode to unlock the vehicle using a mobile application on the driver's mobile device, via the vehicle platform, or on the vehicle itself.

[0091]

[0127] In such cases, an indication of the current lock / unlock status can be provided, allowing the driver to enable, update, or disable the remote vehicle lock accordingly, for example, to restrict the engine control module and / or other functions of the vehicle. In cases where a lock or unlock command is provided to the vehicle remotely (for example, via a vehicle platform or mobile device), an indication of success or failure can be received in response to the above indication. Thus, an indication can be provided regarding whether the vehicle was successfully locked or unlocked. In some cases, among others, for example, passcode recovery can be enabled by storing the passcode in association with an account on the vehicle platform, or by requesting the passcode from the vehicle.

[0092]

[0128] Figure 34 shows an exemplary system 500 that can use vehicle connectivity functionality according to an aspect of the present disclosure. As shown, the system 500 comprises a vehicle 502 (e.g., vehicle 100 and / or 200), a vehicle platform 504 (e.g., cloud 180), a driver device 506 (e.g., remote device 182), and a network 508. In the example, the vehicle 502, the vehicle platform 504, and / or the driver device 506 communicate over the network 508, which may include a local area network, a peer-to-peer network, the Internet, or various other networks. In the example, communication between the vehicle 502, the vehicle platform 504, and / or the driver device 506 may, in other examples, be done using packets, via an application programming interface (API), and / or using any or any combination of various electronic communications (e.g., as short message service (SMS) messages or email messages). For example, the connection circuit 512 may have an associated telephone number, and as a result, the vehicle platform 504 and / or the driver device 506 can send SMS messages to the vehicle 502, or vice versa.

[0093]

[0129] For example, vehicle 502 can communicate via network 508 using a connection circuit 512, which may be a dongle (e.g., dongle 170) or a TCU (e.g., TCU 250), among other examples. It will be understood that the connection circuit 512 may be implemented as hardware, software, or any combination of the above. As shown in the illustration, the connection circuit 512 is connected to the driver interface 510 using both a high-speed connection 538 and a low-speed connection 540. For example, the high-speed connection 538 may be, but is not limited to, Ethernet® or BroadR-Reach connection, fiber connection, Universal Serial Bus (USB) connection, and / or wireless connection. The low-speed connection 540 may be, among other examples, a connection via a Controller Area Network (CAN) bus and / or Local Interconnection Network (LIN). In the example, connections 538 and / or 540 may utilize any of various communication techniques, such as IP-based network connections.

[0094]

[0130] The connection circuit 512 can receive commands for remote vehicle control via the network 508 (for example, from the vehicle platform 504 and / or the driver device 506), and as a result, the connection circuit 512 can process such commands or relay them via the high-speed connection 538 and / or the low-speed connection 540. For example, the connection circuit 512 can issue CAN commands to lock or unlock the vehicle 502, sound the vehicle 502's horn, and / or turn the vehicle 502's lights on or off. In some cases, the connection circuit 512 can queue commands so that one or more commands are processed after the vehicle enters a given operating mode.

[0095]

[0131] In some examples, the driver interface 510 and the connection circuit 512 may use the slow connection 540 for slow functions and / or controller reprogramming, which may include controlling and / or acquiring vehicle control system information (e.g., engine speed, refrigerant temperature, and / or other vehicle health data). For example, the connection circuit 512 may acquire fault diagnostic codes associated with components of the vehicle 502 via the slow connection 540. In this example, the fault diagnostic codes may be acquired synchronously and / or asynchronously. For example, the connection circuit 512 may determine the number of components of the vehicle 502 that are accessible via the slow connection 540. Thus, the connection circuit 512 may request associated fault diagnostic codes for each identified component, which may be provided to the vehicle platform 504 according to the embodiments described herein (e.g., the problem diagnostic embodiments described above with respect to Figures 11-14 and Annex A). In a further example, connection circuit 512 can monitor changes via slow connection 540 (e.g., new active, historical, or deleted fault diagnostic codes) and consequently provide instructions to vehicle platform 504. In some cases, connection circuit 512 can receive instructions (e.g., via network 508) to clear active and / or historical fault codes, and consequently, connection circuit 512 can take action via connections 538 and / or 540 in response to the received instructions.

[0096]

[0132] The high-speed connection 538 can be used for high-speed functions, including acquiring live traffic data, streaming music, retrieving album artwork, and / or other cloud communications. For example, the connection circuit 512 can act as a modem or gateway for the driver interface 510, so that the connection of the connection circuit 512 to the network 508 is shared with the driver interface 510 via the high-speed connection 538. In this example, the driver interface 510 may be configured with a passcode to restrict certain functions of the driver interface 510, for example. Thus, the connection circuit 512 can acquire the passcode of the driver interface 510, and as a result, the passcode can be stored by the connection circuit 512 and / or provided to the vehicle platform 504 (for example, the passcode can be associated with a driver profile on the vehicle platform). Thus, the connection circuit 512 can synchronize the passcode of the driver interface 510 with the vehicle platform 504.

[0097]

[0133] For example, the driver interface 510 may access the network 508 for mapping functions (e.g., searching for an address, providing directions to turn, or accessing traffic data) or for synchronizing boarding or track information. In other cases, for example, if the driver device 506 can act as a bridge or repeater to enable access to the low-speed connection via the high-speed connection 538, the high-speed connection 538 may be used for low-speed functions. The connection circuit 512 may provide instructions for wireless network information (e.g., modem transceiver status, service type, antenna status, and / or calculated signal strength) via the high-speed connection 538 and / or the low-speed connection 540, so that other components of the vehicle 502 can determine the connection status of the vehicle 502.

[0098]

[0134] As a further example, the connection circuit 512 may include location determination means such as GPS, and as a result, location information of the vehicle 502 can also be provided to other components of the vehicle 502 via the high-speed connection 538 and / or the low-speed connection 540. In this example, the frequency at which the location of the vehicle 502 is determined and / or provided (for example, to the vehicle platform 504 and / or driver device 506 via the connections 538 and / or 540) may be manually configurable via the vehicle 502, the vehicle platform 504, and / or the driver device 506. As another example, the frequency may be configurable according to other functions of the vehicle 502 and / or the vehicle platform 504. For example, among other examples, a higher frequency of location updates (referred to herein as "GPS redundancy mode") may be used in cases where the location of the vehicle 502 is being monitored (for example, according to the remote vehicle locator configuration described herein) or shared with other drivers, or when a theft alert is being generated. Furthermore, the connection circuit 512 can maintain a set of geofences associated with the vehicle 502, where, among other examples, it can provide instructions (to, for example, the vehicle platform 504) on whether a given geofence is enabled, whether the vehicle 502 has entered the geofence, and whether the vehicle 502 has left the geofence.

[0099]

[0135] Although the system 500 is shown to have a high-speed connection 538 and a low-speed connection 540 between the driver interface 510 and the connection circuit 512, it will be understood that various alternative or additional components may communicate using similar high-speed and / or low-speed connections. Furthermore, the connection circuit 512 can monitor the use of the high-speed connection 538 and / or the low-speed connection 540, and as a result, the connection circuit may restrict or otherwise reduce the use of the connection circuit and / or the use of other components of the vehicle 502 if it determines that the use exceeds a predetermined threshold. The predetermined threshold may be configurable by the vehicle platform 504.

[0100]

[0136] Vehicle 502 is further shown to include an electronic control unit (ECU) 514, which includes a data store 524. Any of the ECUs and various ECUs provided as exemplary components of vehicle 502 may include a data store similar to the data store 524. For example, although ECU 514 is shown as a separate component of vehicle 502, it will be understood that the embodiments described herein with respect to ECU 514 may be similarly applicable to the driver interface 510 or the connection circuit 512, among other examples. For example, the driver interface 510 may include a data store for storing maps, streaming media, and media provided by the vehicle and / or the driver, among other examples.

[0101]

[0137] The ECU 514 uses the data store 524 to store any of a variety of data, including, but not limited to, vehicle control system information, maps, cloud information (such as that which may be received from the vehicle platform 504), and / or data provided by the driver (such as photos and music). The vehicle control system information acquired and / or stored may be configurable. For example, the vehicle platform 504 may provide instructions on what information should be collected, how often the information should be collected, and / or what processing should be performed in the vehicle 502 before the information is transmitted to the vehicle platform 504 (for example, as diagnostic information). For example, telematics data may be acquired, or the vehicle platform 504 may request specific vehicle control system information to perform analysis of a particular vehicle, among other examples. Exemplary information that can be provided to the vehicle platform 504 includes, but is not limited to, ambient temperature, battery voltage, fuel level, VIN, predictive maintenance schedule, theft warning or SOS status, cell signal strength, GPS accuracy, total key-on time, and / or total key-on events, among other vehicle health data. In some cases, vehicle control system information can be obtained by putting one or more components of the vehicle 502 into diagnostic mode and acquiring information accordingly.

[0102]

[0138] In the example, at least a portion of the datastore 524 may be in the form of a removable storage device, such as a flash drive or a microSD card, as in other examples. In some cases, at least a portion of the datastore 524 may be unused. For example, the manufacturer may select a storage medium with a capacity exceeding the software requirements of the ECU 514 and / or other components of the vehicle 502, or, as another example, the driver may connect a storage device with unused capacity.

[0103]

[0139] Therefore, other components of the vehicle 502 can utilize the available space of the data store 524, thereby reducing or eliminating the need for such components to include the data store. For example, the connection circuit 512 can use the data store 524 to store data before transmitting it to the vehicle platform 504, or to cache data received from the vehicle platform 504. As an example, data can be batched in the data store 524 (for example, in a rolling buffer or as one or more log files) and then transmitted to the vehicle platform 504. Data can be transmitted in response to a trigger (for example, one that can be identified by the connection circuit 512), which may be configurable remotely by the vehicle platform 504. For example, when a trigger is identified, a predetermined amount of data prior to trigger identification and / or a predetermined amount of data after trigger identification may be transmitted to the vehicle platform 504.

[0104]

[0140] In some cases, at least a portion of the data may be processed before transmission to the vehicle platform 504, for example using compression techniques, to generate a histogram or to perform any of the various statistical analyses (e.g., determining the last value, first value, counter value, minimum value, maximum value, mean value, or median). In the example, the trigger may rely on such analysis, for example, based on signal values, minimum values, maximum values, mean values, the presence of fault diagnostic codes, and / or identification of a particular SPN / FMI / SA combination of faults, among other examples.

[0105]

[0141] With respect to Figures 1 to 5, the vehicle controller 516, which may be similar to the vehicle controller 140 described above, is shown to include a storage manager 520 that can identify the available space of the data store 524 and enable other components of the vehicle 502 to use the available space of the data store 524 to store data accordingly.

[0106]

[0142] For example, the storage manager 520 can receive instructions for data to be stored and, in response to receiving such instructions, can determine whether there is available space in the data store 524. As used herein, available space does not have to be unused capacity and may include capacity currently used by data that can be moved, compressed, purged, or otherwise processed to make at least a portion of the capacity of the data store 524 available for storing additional data. For example, cached data in the data store 524 may be removed, or map data in the data store 524 may be compressed (for example, based on a determination that the vehicle 502 is not close to a geographical location associated with the map data, or based on a determination that the map data has not been used recently). Thus, if there is available space, the storage manager 520 can allow the data to be stored in the data store 524.

[0107]

[0143] As another example, datastore 524 may include a rolling buffer that stores a predetermined amount of data (for example, having a predetermined size or being associated with a predetermined amount of time). The rolling buffer can then determine that it has available storage and, as a result, can, for example, overwrite the oldest data or delete it in other ways and replace it with more recent data. As yet another example, data can be stored using a variable granularity, and as a result, in cases where the available storage space falls below a predetermined threshold, redundant or highly redundant information is omitted (for example, from new data or already stored data).

[0108]

[0144] However, if there is no available space in datastore 524, the data may be stored elsewhere. For example, connection circuit 512 may prefer to store data in datastore 524, but if storage is unavailable in datastore 524, it may use the datastore of connection circuit 512 (not shown). In other examples, data may not be stored at all. For example, connection circuit 512 may acquire vehicle control system information if storage is available, and store the vehicle control system information in datastore 524 as diagnostic information. If storage is unavailable, such diagnostic information may be unavailable at all, or only partially available.

[0109]

[0145] As another example, a driver profile may be acquired (for example, from a vehicle platform 504 or a driver device 506) and stored according to the embodiments described herein. Thus, at least a portion of the driver profile may be purged as necessary to make additional space available. For example, at least a portion of the driver profile may be replaced with a reference to data stored remotely. In cases where a driver profile is not in use (for example, another driver profile is in use), the driver profile may be deleted, and as a result, the driver profile may be re-downloaded at a later time as necessary.

[0110]

[0146] System 500 is described in an example where the storage manager 520 is part of the vehicle controller 516, but it will be understood that similar embodiments may be implemented additionally or alternatively by any of the various other components of the vehicle 502. For example, a connection circuit 512 may implement such an embodiment to utilize the available storage of the driver interface 510. Furthermore, although the examples herein describe a single datastore, any number of datastores may be used, and the datastores to store data may be selected according to any of the various criteria (e.g., based on available space, latency, and / or usage patterns).

[0111]

[0147] The vehicle controller 516 is shown to further include a theft detection engine 518. In the example, the theft detection engine 518 evaluates any of a variety of information to determine whether the vehicle 502 has been stolen. For example, the theft detection engine 518 may process data from one or more sensors on the vehicle 502 (e.g., sensor 126 as described above with respect to Figures 1 to 4), data associated with the driver device 506 (e.g., the proximity of the driver device 506 to the vehicle 502, or whether the operator of the driver device 506 is authorized to use or tow the vehicle 502), and / or data associated with the vehicle platform 504. In some cases, the theft detection engine 518 may determine whether the driver device 506 is connected to a signal strength associated with the vehicle 502 and / or a connection (e.g., the communication controller 534 and the connection circuit 512 may be connected directly or indirectly). As another example, the theft detection engine 518 may provide information to the vehicle platform 504 (for example, via the connection circuit 512) to receive conditional information in response to configure the sensitivity of the theft detection engine 518 or to suppress theft warnings that would otherwise be false positives. Such embodiments will be described in more detail with respect to the vehicle platform 504.

[0112]

[0148] Although the theft detection engine 518 is described in the context of vehicle theft, in other examples the theft detection engine 518 may identify any of a variety of additional or alternative conditions, such as illegal vehicle entry, theft of vehicle components (e.g., removal of connection circuit 512), instances of vehicle tampering (e.g., wheel removal, key operation for repair, someone sitting in a vehicle seat), accident, or fire. For example, the embodiments described above may be similar to those shown in Figure 26, in which the vehicle's location is analyzed with respect to a geofence to determine whether the vehicle has broken the geofence, and as a result a notification can be generated and provided to the driver device.

[0113]

[0149] For example, when the theft detection engine 518 identifies the conditions, the warning can be deactivated, vehicle location monitoring can be enabled, vehicle 502 can be positioned within the geofence, and the updated location of vehicle 502 can be provided to the vehicle platform 504. In the case where the theft detection engine 518 identifies the conditions, the warning can be enabled, vehicle location monitoring can be enabled, vehicle 502 can be positioned outside the geofence, a warning can be generated as described herein, an updated location can be provided to the vehicle platform 504, and the location of vehicle 502 can be updated according to the GPS redundancy mode described above. Finally, if, while in GPS redundancy mode, it is determined that the location of vehicle 502 is within the geofence and / or the warning is deactivated, the location update can revert to normal (e.g., instead of GPS redundancy mode). The conditions and associated measures described above are given as examples, and it will be understood that additional, fewer, or alternative conditions and / or measures may be used in other examples.

[0114]

[0150] The vehicle state manager 522 of the vehicle controller 516 monitors the status of the vehicle 502 and can provide various operating modes. Exemplary operating modes, but not limited to, include a fully connected operating mode, a connection-limited operating mode, and a disconnected operating mode. For example, in the fully connected operating mode, the vehicle state manager 522 can configure the vehicle 502 to maintain a connection to the network 508 (e.g., via the connection circuit 512) and to communicate with the vehicle platform 504. Thus, the vehicle 502 may be ad-hoc reachable by the driver device 506 and / or various other remote devices.

[0115]

[0151] In contrast, in connection restriction mode, vehicle 502 may be configured to periodically operate its connection to network 508, for example, according to a predetermined schedule or based on current and / or historical interactions between vehicle 502 and driver device 506. Finally, in disconnection mode, vehicle 502 may be configured to remain disconnected (for example, connection circuit 512 may be disabled), and one or more other components of vehicle 502 may be disabled as well.

[0116]

[0152] In the example, vehicle 502 transitions between operating modes depending on the charge state of one or more of its batteries (for example, battery 128 in Figures 1 to 4). For example, battery power draw for a powersports vehicle may need to be managed due to the vehicle's battery being relatively limited compared to other vehicles. Furthermore, the duty cycle of a powersports vehicle may be relatively low (for example, the vehicle may be used only once every few weeks).

[0117]

[0153] The vehicle state manager 522 may determine the charge state according to the battery voltage, or any of various other techniques may be used alternatively or additionally. In some cases, the determined charge state may be made available to any of various vehicle components via connections similar to those described above, for example, connections 538 and / or 540. Thus, if the charge state falls below a first predetermined threshold, the vehicle 502 may transition from a fully connected operating mode to a connection-limited operating mode. Similarly, if the charge state falls below a second predetermined threshold, the vehicle 502 may transition from a connection-limited operating mode to a disconnected operating mode. Such transitions may also occur in reverse as a result of an increase in the battery charge state, or, as another example, the first threshold set may be used for battery discharge, while the second threshold set may be used for battery charge. An example of such operating modes and associated thresholds based on the vehicle's charge state is shown in Figure 33.

[0118]

[0154] The transition may be based on any of various other events or conditions. For example, vehicle 502 may transition to a different operating state in response to instructions received from vehicle platform 504. In another example, based on conditions identified by the theft detection engine 518, vehicle 502 may be configured from a disconnected operating mode to a connection-limited operating mode or a fully connected operating mode, thereby enabling communication with vehicle platform 504 and / or driver device 506. When vehicle 502 transitions between operating modes, a notification may be presented to the driver of vehicle 502 (for example, via driver interface 510 and / or driver device 5060). In such cases, vehicle 502 may terminate the connection if the subsequent conditions are not determined within a predetermined time. In another example, the connection may be re-established after a predetermined time in the connection-limited or disconnected operating state, and as a result, among other examples, the sensitivity of the theft detection engine 518 can be periodically reconfigured by vehicle platform 504 or other condition information can be received.

[0119]

[0155] Therefore, the vehicle state manager 522 can configure the vehicle 502 to balance function and charge state. For example, the vehicle 502 may have a minimum threshold below which the prime mover (e.g., prime mover 112 in Figures 1-4) becomes inoperable (e.g., the battery cannot crank the engine or the electric motor cannot have enough current to generate sufficient torque). Such an operating mode can conserve the battery charge state, resulting in the vehicle 502 not reaching the threshold or reaching a low speed due to the threshold. Such transition points may be vehicle-specific, based on battery capacity and / or alternator capacity, among other examples. The above operating modes and associated functions are given as examples, and it will be understood that in other examples, any of various additional and / or alternative functions may be associated with such operating modes. As a further example, the conservation does not have to be limited to the charge state, and various alternative or additional resources may be conserved according to the embodiments described herein. For example, the fully connected operation mode, the connection-limited operation mode, and the unconnected operation mode may be used according to the signal strength of the connection circuit 512.

[0120]

[0156] Furthermore, the vehicle state manager 522 may configure the vehicle 502 according to additional or alternative operating modes. For example, a fully connected operating mode, a connection-limited operating mode, and a disconnected operating mode can form a start-guaranteed operating mode, thereby conserving the resources of the vehicle 502 to ensure that the vehicle 502 is able to start at a later time. As another example, a shipping operating mode may enable periodic connections via the connection circuit 512 and communication with the vehicle platform 504 to provide, for example, location updates and other shipping information. A driver connection mode may configure the vehicle 502 to enable communication with driver devices such as a fob or driver device 506 (for example, for locking doors or opening the trunk). The driver connection mode may further enable visual or audible feedback from the vehicle 502, for example, by flashing lights and / or via the horn. An off-season storage mode may configure the vehicle 502 to conserve charge (similar to, for example, a low-connection operating mode or a disconnected operating mode) and / or to operate various components according to weather or other conditions. The accessory operating mode can, for example, allow the use of various accessories (not shown) of the vehicle 502, which may be built-in or connected to the vehicle 502.

[0121]

[0157] The over-the-air (OTA) mode can configure the vehicle 502 to periodically contact the vehicle platform 504 to check for updates associated with one or more components of the vehicle 502 (e.g., the driver interface 510, the connection circuit 512, the electronic control unit 514, or the vehicle controller 516). As another example, the OTA mode can be used to repair the software of the vehicle 502, for example, when the vehicle controller 516 encounters a software problem. In this example, software updates to the components of the vehicle 502 can be performed using a cellular communication device or a Wi-Fi connection (e.g., one that can be provided by the connection circuit) or via a wired connection (e.g., via a CAN bus connection, serial connection, or Ethernet connection). Furthermore, updates to some components (e.g., the IVI or the driver interface) may be performed via a high-speed connection, while updates to other components (e.g., the engine control module or the vehicle control module) may be performed via a low-speed connection. The connection circuit 512 can receive update files and / or other information from the vehicle platform 504, which can be stored and used to flash components of the vehicle 502 according to update urgency and / or driver permission, among other examples. For example, the driver may instruct that only critical updates be installed automatically, or updates may have an urgency indicating that the update should be installed as soon as possible or within a given time period, among other examples.

[0122]

[0158] The warehouse operating mode can, for example, configure vehicle 502 to operate in a reduced-function state in which it can be started and driven. The speed and / or energy output of the prime mover can be limited (for example, below a predetermined RPM threshold or a predetermined torque threshold). In warehouse operating mode, accessories (for example, IVI or media playback associated with it) can be disabled. As another example, one or more lights in vehicle 502 may be disabled or operated at reduced brightness.

[0123]

[0159] The vehicle state manager 522 can configure the vehicle 502 according to the lockout operation mode. For example, the vehicle state manager 522 can enable an anti-theft function (such as the one described herein with respect to the anti-theft detection engine 518) when the lockout operation mode is in the “enabled” state. The lockout operation mode may further have an “disabled” state in which such anti-theft functions are disabled. As a further example, the lockout operation mode may have an “unlocked” state in which anti-theft functions are temporarily unlocked (for example, for a predetermined period of time or until a key-off event).

[0124]

[0160] While exemplary modes and associated functions are described herein, it will be understood that any of various other operating modes may be implemented by the vehicle state manager 522, and alternative or additional functions may be associated therewith. Other exemplary functions include, but are not limited to, control of heating, ventilation and air conditioning (HVAC) systems, heated seats, and / or various functions of other vehicle components. In some cases, the vehicle state manager 522 may receive an enrollment status instruction from the vehicle platform 504, and as a result configure the operating modes and / or associated functions of the vehicle 502 accordingly. For example, the set of available operating modes may change based on the driver's enrollment status (e.g., enrollment tier and / or whether enrollment has been accepted).

[0125]

[0161] The operating modes of vehicle 502 may be pre-configured and / or configured by vehicle platform 504, among other examples. For example, vehicle platform 504 may add, delete, or update the operating modes of vehicle 502 based on type or model, or geographic location, among other information, based on historical charge status data of vehicle 502 and / or a set of other vehicles. In some cases, the operating modes of vehicle 502 can be configured using a driver device 506 (for example, via vehicle platform 504 or based on communication with vehicle 502). For example, configuring an operating mode may include specifying thresholds or alternative or additional conditions (for example, relating to any of various health data) that allow vehicle state manager 522 to configure vehicle 502 according to the operating mode. In another example, configuring an operating mode may include specifying which components are active or how often such components are active, or the functions available under the operating mode. It will be understood that the operating modes do not need to be mutually exclusive. For example, a vehicle may be in both driver-connected mode and start-guaranteed operation mode.

[0126]

[0162] As illustrated, the vehicle platform 504 comprises a vehicle data aggregation engine 526, a vehicle condition identification means 528, a vehicle state manager 530, and a driver communication manager 532. In one example, the vehicle data aggregation engine 526 acquires sensor data from the vehicle 502 (for example, such as that which may be generated by the theft detection engine 518 based on the sensors of the vehicle 502). In another example, the vehicle data aggregation engine 526 acquires charge status data from the vehicle 502 (for example, such as that which may be generated by the vehicle state manager 522). Such data can be communicated by the vehicle 502 using the connection circuit 512 and can be stored by any of the various components of the vehicle 502, for example, using the techniques described above with respect to the storage manager 520 and the data store 524. The vehicle data aggregation engine 526 can acquire and aggregate data from any number of vehicles. For example, the vehicle data aggregation engine 526 can categorize the acquired data according to the type or model of the vehicle, or based on geographical location, among other examples.

[0127]

[0163] In the example, the vehicle condition identification means 528 processes sensor data acquired by the vehicle data aggregation engine 526 to identify one or more conditions associated with a set of vehicles. For example, the vehicle condition identification means 528 can process sensor data from a set of vehicles that are similar in geographical location or have the same driver to determine whether the set of vehicles is experiencing a condition or whether the condition is limited to only individual vehicles in the set of vehicles. In another example, a predetermined threshold (e.g., the number or percentage of affected vehicles) may be used, where conditions exceeding the predetermined threshold are determined to be group conditions, while conditions below the predetermined threshold are determined to be individual conditions. The processing may incorporate additional data in addition to the aggregated vehicle data, for example, based on weather data, map data (e.g., proximity to geographical and / or artificial features), traffic data, or new data.

[0128]

[0164] The vehicle condition identification means 528 can take one or more actions based on the identified conditions. For example, the vehicle condition identification means 528 can provide instructions to the vehicle 502 (for example, to be processed by the theft detection engine 518) and / or the driver device 506 (for example, via the driver communication manager 532 to cause the vehicle application 536 to present a notification to the driver accordingly). As an example, the vehicle condition identification means 528 can configure the sensitivity of the theft detection engine 518 to suggest the possibility of a false positive theft warning. As another example, the vehicle condition identification means 528 can instruct the theft detection engine 518 that a theft warning should be generated.

[0129]

[0165] In some cases, when a group condition is identified (e.g., increased sensor data from multiple vehicles that could indicate a fire) or when an individual condition is identified (e.g., based on ambient noise and / or ambient temperature, only one vehicle is moving or experiencing vibration), measures may be taken. As a further example, a group condition indicating vibration (e.g., as a result of proximity to a train track or arising from weather conditions) can be used to reduce, at least temporarily, the sensitivity of the theft detection engines for multiple vehicles (e.g., exhibiting a group condition and / or associated with a geographical location).

[0130]

[0166] In some cases, the vehicle condition identification means 528 can process data associated with the driver device 506 when identifying conditions (for example, as can be obtained by the driver communication manager 532). For example, the geographical location of the driver device 506 can be obtained from the driver device 506. This geographical location can be compared with the geographical location of the vehicle 502 to determine whether the driver device 506 is in proximity to the vehicle 502. If it is determined that the vehicle 502 is moving while the driver device 506 is not in proximity, the theft detection engine 518 can generate a theft warning accordingly. In some cases, the vehicle condition identification means 528 can process geographical locations (for example, of the vehicle 502 and / or the driver device 506) to determine whether the geographical locations are associated with a road, highway, or trail. In another example, the speed of the vehicle 502 and / or the driver device 506 may be determined. In some cases, another driver device may be evaluated, as may be the case when the driver of driver 502 designates another driver (and associated driver device, not shown) as an authorized driver. It will be understood that any of the various pieces of information associated with vehicle 502 and / or driver device 506 can be used to identify conditions and generate actions accordingly.

[0131]

[0167] The vehicle platform 504 further comprises a vehicle state manager 530 capable of managing the operating modes of the vehicle 502 (for example, as described above with respect to the vehicle state manager 522). In an example, the vehicle state manager 530 may process charge state data from the vehicle 502 and / or other vehicles to configure one or more operating modes accordingly. For example, the vehicle state manager 530 may change one or more thresholds for the start-up guarantee operating modes according to the type or model of the vehicle 502, or based on an analysis of the vehicle's charge state related to the aggregated charge state (for example, as aggregated by the vehicle data aggregation engine 526). For example, a model may be used to determine whether the battery of the vehicle 502 is degraded or has degraded performance, and as a result, one or more different thresholds may be set to compensate accordingly.

[0132]

[0168] As another example, the vehicle state manager 530 can receive an instruction from vehicle 502 that vehicle 502 has transitioned from one state to another, and as a result can generate an instruction for the vehicle application 536 to present to the driver (for example, via the driver communication manager 532). Accordingly, the driver communication manager 532 of the vehicle platform 504 can communicate with the vehicle application 536 of the driver device 506 and / or relay communication between vehicle 502 and the driver device 506.

[0133]

[0169] The driver device 506 is shown comprising a communication controller 534 and a vehicle application 536. In the example, the communication controller 534 communicates with the vehicle 502 and / or vehicle platform 504 via the network 508, for example, using one or more wired and / or wireless communication technologies. In another example, the communication does not need to be via the network 508 and may instead be direct. For example, the communication controller 534 may include a Bluetooth® and / or Wi-Fi radio that communicates directly with the corresponding radio in the vehicle 502 (e.g., a connection circuit 512). Rather than using the driver device 506's connection to the network 508 in the example, the embodiments described herein allow components of the vehicle 502 to use the connection circuit 512 and communicate accordingly via the network 508. Thus, the driver device 506 does not need to act as a modem or gateway for the vehicle 502. Furthermore, the connection of the connection circuit 512 to the network 508 can be shared with the driver device 506. As another example, a Wi-Fi network provided by the connection circuit 512 can enable inter-device communication between sets of driver devices. It should be understood that the communication controller 534 and the connection circuit 512 may each implement any of a variety of additional or alternative communication technologies, including, but not limited to, ultra-wideband (UWB) or near-field communication (NFC), among other examples.

[0134]

[0170] The vehicle application 536 can generate notifications (e.g., associated with changes in vehicle status and / or theft warnings) and provide instructions regarding geographical location (e.g., based on GPS and / or A-GPS) to the vehicle 502 and / or vehicle platform 504. In another example, the vehicle application 536 can be used to instruct another driver who is an authorized driver of the vehicle 502 and associated driver devices. In some cases, the vehicle application 536 can be used by the driver of the vehicle 502 to configure one or more predetermined thresholds, conditions, and / or associated functions to configure the operating modes of the vehicle 502, among other examples.

[0135]

[0171] Figure 35A provides an overview of an exemplary method 600 for processing condition information from a vehicle platform for vehicle theft warning according to the embodiments described herein. In the example, embodiments of method 600 may be implemented by a vehicle theft detection engine, such as the vehicle theft detection engine 518 of the vehicle 502 described with respect to Figure 34.

[0136]

[0172] Method 600 is initiated in operation 602, and sensor data is acquired. For example, the sensor data may be acquired from one or more sensors of the vehicle, such as the sensor 126 described in relation to Figures 1 to 4.

[0137]

[0173] In operation 604, device proximity information is acquired. The device proximity information can be associated with a driver device, such as the driver device 506 described above with respect to Figure 34. For example, the device proximity information may include one or more signal strengths associated with the device, such as signal strength associated with Wi-Fi and / or Bluetooth connections. As another example, the device proximity information may include the location of the device. In some cases, the device proximity information may be acquired from the device, or, as another example, from a vehicle platform such as the vehicle platform 504.

[0138]

[0174] The flow proceeds to operation 606, in which condition information is obtained from the vehicle platform. In this example, the condition information may include instructions for identified group conditions or individual conditions, configuration of the sensitivity of the vehicle theft detection engine, and / or instructions for action (for example, as may be generated by a vehicle condition identification means such as the vehicle condition identification means 528 in Figure 34). In the example in which proximity information is obtained from the vehicle platform with respect to operation 604, the proximity information may be obtained as part of the condition information obtained in operation 606. Thus, it will be understood that any of the various condition information may be obtained from the vehicle platform in operation 606.

[0139]

[0175] The flow proceeds to operation 608, where conditions are evaluated. For example, sensor data may be evaluated considering one or more thresholds (for example, the sensitivity of the sensor data may be configured based on condition information received in operation 606). In other examples, the evaluation may include evaluating conditions indicated by the vehicle platform in relation to the sensor data to determine whether the sensor data indicates a condition, should be ignored as a result of a condition, or whether a warning should be generated considering further conditions. In some cases, operation 608 includes evaluating device proximity information, such as the geographic location of a device related to the geographic location of the vehicle, or determining whether the signal strength associated with a device indicates that the driver associated with the device is driving the vehicle. Operation 608 may also optionally or additionally include evaluating the geographic location of the vehicle with respect to map and / or topographic information to determine whether the vehicle is on a road or highway.

[0140]

[0176] Therefore, the evaluation in operation 608 can determine, among other examples, whether the sensor data indicates vehicle theft or illegal entry, whether the sensor data is associated with geographical location, individual conditions, and / or group conditions (which can consequently be ignored or taken action against), whether a device (e.g., associated with the owner or authorized driver) is nearby, and whether the vehicle is on a road or highway. In some cases, the conditions evaluated in operation 608 may be weighted. For example, proximity of a driver device based on signal strength or received from the vehicle platform may be given a higher ranking, while the determination that the vehicle is on a road or highway may be given a lower ranking depending on the GPS positioning accuracy. Therefore, additional system inputs can be used to further increase the certainty that a warning should not be generated (e.g., as may be the case when the vehicle is being towed, as shown in Figure 32). Other such system inputs include evaluating the speed of the vehicle and / or user (to determine whether the vehicle is in use), determining whether a driver device is connected to the vehicle's driver interface (to determine whether the vehicle is in use), and evaluating whether the vehicle and the user's phone are on a track that is a road or highway.

[0141]

[0177] It will be understood that the driver device may be any of a variety of devices, such as a mobile computing device or a wearable computing device including a smartwatch or helmet. Additional examples of such embodiments are described in U.S. Patent Application No. 16 / 668,980, filed on 30 October 2019, entitled "CONNECTED HELMET SYSTEM AND METHOD OF OPERATING THE SAME," the entire disclosure of which is expressly incorporated herein by reference.

[0142]

[0178] The systems and methods disclosed herein may be embodied in or complemented by any one of the following patent applications or patents: U.S. Patent Application Publication No. 20200198467 entitled "MANAGING RECREATIONAL VEHICLES AND ACCESSORIES", U.S. Patent Application Publication No. 20200145815 entitled "CONNECTED HELMET SYSTEM AND METHOD OF OPERATING THE SAME", U.S. Patent Application No. 17 / 234,501 entitled "SYSTEMS AND METHODS FOR COMMUNICATING INFORMATION", U.S. Patent Application No. 16 / 234,162 entitled "RECREATIONAL VEHICLE INTERACTIVE TELEMETRY, MAPPING AND TRIP PLANNING SYSTEM", and "SYSTEMS AND METHODS OF ADJUSTABLE SUSPENSIONS FOR OFF-ROAD RECREATIONAL U.S. Patent Application No. 17 / 325,062, titled "VEHICLES", U.S. Patent Application No. 16 / 401,933, titled "OPERATING MODES USING A BRAKING SYSTEM FOR AN ALL-TERRAIN VEHICLE", U.S. Patent Application No. 17 / 235,322, titled "SYSTEMS AND METHODS FOR OPERATING AN ALL-TERRAIN VEHICLE", U.S. Patent Application No. 16 / 838,602, titled "DIAGNOSTIC SYSTEMS AND METHODS OF A CONTINUOUSLY VARIABLE TRANSMISSION", U.S. Patent Application No. 17 / 241,559, titled "SYSTEM AND METHOD FOR DYNAMIC ROUTING", and "DEVICE AND METHOD FOR SUPERVISING AND MODIFYING VEHICLE U.S. Patent Application No. 15 / 836,223, titled "OPERATION", and U.S. Patent Application No. 17 / 158, titled "ADJUSTABLE PERFORMANCE FOR A VEHICLE",U.S. Patent Application No. 539, titled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING" (No. 17 / 175,888), U.S. Patent Application No. 17 / 100,451, titled "VEHICLE HAVING SUSPENSION WITH CONTINUOUS DAMPING CONTROL", U.S. Patent Application No. 17 / 176,110, titled "ADJUSTABLE VEHICLE SUSPENSION SYSTEM", and U.S. Patent Application No. 15 / 816,368, titled "VEHICLE HAVING ADJUSTABLE SUSPENSION".

[0143]

[0179] In determination 610, it is determined whether an action should be generated based on the evaluation performed in action 608. If it is determined that an action should not be taken, the flow branches to "no" and terminates in action 614. On the other hand, if it is determined that an action should be taken, the flow instead branches to "yes" and proceeds to action 612, where a vehicle theft warning is triggered. In the example, action 612 includes, among other examples, activating the vehicle lights and / or horn, providing instructions to the vehicle platform, and / or providing instructions to the driver device.

[0144]

[0180] Although Method 600 is described in the context of vehicle theft warning, it will be understood that similar techniques may be used to provide any of a variety of additional or alternative warnings, including intrusion warnings or fire warnings, among other examples. Similarly, it will be understood that one or more actions may be omitted depending on the circumstances. For example, action 606 does not need to be performed in each iteration of Method 600, and as a result, action 606 may be performed to periodically configure vehicle sensitivity, or in response to acquired sensor data, and as a result, it is determined whether a group condition is presented when the sensor data indicates a condition in the vehicle. Method 600 ends with action 612. Furthermore, the vehicle platform does not need to be used in other examples. For example, the above embodiments may be performed by the vehicle based on information received from a driver device and / or information received from one or more other vehicles.

[0145]

[0181] Figure 35B provides an overview of an exemplary method 650 for aggregating information for vehicle condition processing according to the embodiments described herein. In the example, embodiments of method 650 may be implemented by vehicle condition identification means on a vehicle platform, such as the vehicle condition identification means 528 on the vehicle platform 504 in Figure 34.

[0146]

[0182] Method 650 can be initiated in operation 652, in which device location information is obtained. For example, device information may be received from a vehicle application of a driver device, such as the vehicle application 536 of the driver device 506. Device location information may include the geographical location of the device. While examples are given herein with respect to geographical location (e.g., of a device and a vehicle), in other examples, other device location information, such as Wi-Fi or cellular signal strength, may be used to determine such geographical location or relative proximity. In some examples, operation 652 may be omitted, and as a result, a dashed box is used to indicate that Method 650 is initiated in operation 654. For example, a vehicle may determine the device location information or obtain the device location information by communicating with the device, and as a result, the device location information does not need to be obtained by the vehicle platform.

[0147]

[0183] In operation 654, information is received from the vehicle. For example, the information includes sensor data and / or vehicle control system information, which may be generated by one or more vibration sensors, temperature sensors, and / or microphones of the vehicle (for example, vehicle 100 or 200 in Figures 1 to 4 or vehicle 502 in Figure 34). The information may also be received by a vehicle data aggregation engine, such as a vehicle data aggregation engine 526.

[0148]

[0184] The flow proceeds to operation 656, where the received vehicle information is processed based on aggregated data to generate conditional information. For example, the aggregated data may be received simultaneously or at a preceding time by the vehicle data aggregation engine. In some cases, the aggregated data may be obtained from a data store on the vehicle platform. The vehicle information may be processed using one or more models associated with the aggregated data, such as statistical models and / or machine learning models. In the example, the aggregated data or the model based on the aggregated data may be associated with one or more characteristics that are the same as or similar to the vehicle from which the vehicle information is received. For example, aggregated data of type, model, or geographic location may be used to generate a model through which the received vehicle information is processed. The processing may incorporate additional data in addition to the aggregated vehicle data, such as weather data, map data (e.g., proximity to geographical features and / or artificial features), traffic data, or new data. Furthermore, in addition to or as an alternative to the models described above, a set of rules or various other processing techniques may be used.

[0149]

[0185] In examples where statistical models are used, vehicle information and / or model processing results may be evaluated according to one of various descriptive statistics, such as the mean or standard deviation associated with the vehicle information compared to aggregated data. Conditions may be identified when vehicle information differs from or falls outside a predetermined range with respect to a predetermined threshold. As another example, a trained classifier (for example, one that may be trained on aggregated data) can be used to process vehicle information and classify conditions associated with the vehicle information.

[0150]

[0186] Therefore, in operation 658, instructions for generated condition information can be provided to the vehicle. In the example, the instructions include, among other examples, instructions for individual conditions, instructions for group conditions, or instructions for configuring the sensitivity of the vehicle theft detection engine.

[0151]

[0187] The flow proceeds to decision 660, where it is determined whether an action should be generated based on the condition information generated in action 656. For example, if it is determined that the descriptive statistics exceed a predetermined threshold or fall outside a predetermined range, it may be determined that an action should be generated. In another example, an action may be generated if a trained classifier identifies a condition. In the example, the aspect of decision 660 may be configurable by the driver, or similarly, in other examples, it may be associated with type, model, or geographical location.

[0152]

[0188] If it is determined that no action should be generated, the flow branches to "No" and terminates in operation 664. On the other hand, if it is determined that an action should be generated, the flow branches to "Yes" instead and proceeds to operation 662, where a vehicle theft warning is generated. For example, the instruction may be provided to a driver device, which can then generate a notification for the driver to present. In other examples, an authorization may be notified, or another vehicle associated with the vehicle from which the vehicle information is received may receive the instruction for the identified condition. Method 650 terminates in operation 662.

[0153]

[0189] Figure 36A provides an overview of an exemplary method 700 for utilizing the available memory space of a vehicle's electronic control unit. In this example, an aspect of method 700 is carried out by a storage manager, such as the storage manager 520 described with respect to Figure 34.

[0154]

[0190] Method 700 is initiated in operation 702, in which an instruction is received for data to be stored. In one example, the instruction may include the data to be stored, or, in other examples, the amount and / or type of data to be stored (e.g., driver data or diagnostic data). The instruction may be received from another ECU (e.g., connection circuit 512), or such an embodiment may be performed by the control unit itself (e.g., vehicle controller 516).

[0155]

[0191] In operation 704, the storage utilization of the ECU is determined. For example, operation 704 may also include, among other examples, accessing the ECU's datastore (e.g., datastore 524) to determine storage utilization, or requesting available capacity from the ECU. In some cases, operation 704 includes selecting an ECU from a set of available ECUs in the vehicle. For example, the available ECUs may be ranked according to available storage, latency, or variability of storage availability, or the ECUs may be selected based on the type of data to be stored, among other examples.

[0156]

[0192] In determination 706, it is determined whether the ECU has sufficient free capacity to store the data. Therefore, if it is determined that the ECU has sufficient capacity, the flow branches to "yes" and proceeds to operation 708, where the data is provided to be stored by the ECU. In an example where the instruction received in operation 702 contains data to be stored, operation 708 may include storing the data in the ECU. In another example, operation 708 may include providing an instruction in response to the instruction received in operation 702, so that the ECU that received the instruction can transmit the data to be stored in the ECU whose storage has been identified. Thus, it will be understood that data can be stored in an ECU that has free or otherwise available storage using any of the various techniques.

[0157]

[0193] On the other hand, if it is determined that the ECU does not have sufficient free capacity to store data, the flow proceeds to operation 710, which determines whether the ECU has available storage, for example, whether the data can be moved, compressed, purged, or otherwise processed so that at least a portion of the capacity is available for storing additional data. In the example, the usage determined in operation 704 may indicate storage usage according to various types of usage (e.g., non-purgable, purgable, and / or compressible). In other examples, determination 710 may also include evaluating the datastore or requesting additional information from the ECU associated with the datastore.

[0158]

[0194] If it is determined that there is storage available for purging (or other forms of processing as described herein), the flow branches to "yes" and proceeds to operation 712, where, for example, one or more of the processing operations described herein are performed to free the storage on the ECU. Thus, the flow proceeds to operation 708, the data is stored by the ECU as described above, and the flow terminates.

[0159]

[0195] On the other hand, if it is determined that no storage is available for purging, the flow branches to "no" and proceeds to operation 714, where an instruction is provided that storage is unavailable. In some cases, another iteration of method 700 may be performed with respect to a different ECU and / or a different datastore (for example, in cases where the ECU has multiple datastores), as a result of identifying different locations for storing data. In some cases, such as in the case of diagnostic information, the instruction may be to prevent data from being stored as described above. Method 700 terminates in operation 714.

[0160]

[0196] Figure 36B provides an overview of an exemplary method 750 for accessing data stored by the vehicle's electronic control unit. In this example, an aspect of method 750 is carried out by a storage manager, such as the storage manager 520 described with respect to Figure 34.

[0161]

[0197] Method 750 is initiated in operation 752, in which a request for data is received. The request may include identifiers such as a file name, path, and / or unique identifier, among other examples. For example, the request may be received from an ECU (e.g., an ECU implementing a storage manager or another ECU) as a result of an attempt by the ECU to access data stored in accordance with an aspect of this disclosure.

[0162]

[0198] In operation 754, the location of the stored data is determined. For example, a mapping may exist between the identifier of the received request and either local storage or the datastore of the remote ECU. Alternatively, the identifier may be associated with either a placeholder (e.g., a reference to remotely stored data) or the data itself (e.g., as something that can be stored locally).

[0163]

[0199] The flow proceeds to decision 756, where it is determined whether the data is stored locally. If the data is stored locally, the flow branches to "yes" and proceeds to action 758, where the data is accessed from local storage. Although method 750 is shown as accessing data from local storage or a remote ECU datastore, in other examples, at least a portion of the data may be cached locally, and as a result, the data may be accessed from both local storage and a remote datastore. Method 750 terminates in action 758.

[0164]

[0200] On the other hand, if it is determined that the data is not stored locally, the flow branches to "no" and proceeds to operation 760, in which case the data is requested from the ECU. In some cases, operation 760 includes providing an instruction for an identifier received in operation 752. In other cases, the request may be specific to the ECU determined to store the data. Thus, it will be understood that different ECUs may store the data differently. As a further example, the request may be made via a high-speed connection (e.g., high-speed connection 538 in Figure 34) or a low-speed connection (e.g., low-speed connection 540).

[0165]

[0201] Therefore, in operation 762, data is received, and as a result, the data is provided in response to a request for data received in operation 752. Although method 750 is shown as an example in which data is retrieved from the ECU and provided accordingly, it will be understood that other techniques may be used. For example, a reference may be provided instead, and as a result, the requester can access the data from the ECU itself. Method 750 terminates in operation 764.

[0166]

[0202] Figure 37A provides an overview of an exemplary method 800 for controlling vehicle states according to the vehicle's charge status. In this example, an aspect of method 800 is implemented by a vehicle state manager, such as the vehicle state manager 522 described with respect to Figure 34.

[0167]

[0203] Method 800 can be initiated in operation 802, in which vehicle information is provided, for example, to a vehicle platform (for example, vehicle platform 504 in Figure 34). Exemplary vehicle information includes, but is not limited to, vehicle type, vehicle model, vehicle identification number (VIN), and / or various vehicle control system information.

[0168]

[0204] Therefore, in operation 804, a set of maintenance rules can be received. For example, the set of maintenance rules may be generated at least in part based on the vehicle information provided in operation 802. As described above, the vehicle platform (e.g., the vehicle state manager 530 of vehicle platform 504) can generate maintenance rules based on information associated with the vehicle. In some examples, updates to the maintenance rules can be received, for example, to change the conditions under which the vehicle is configured for a given operating mode, or to change the functionality of the operating mode. Operations 802 and 804 may be omitted in other examples, and as a result, dashed boxes are used to indicate that method 800 begins in operation 806. For example, the vehicle may have a pre-configured set of maintenance rules that can be periodically updated by the vehicle platform as a result of operations 802 and 804.

[0169]

[0205] In operation 806, the vehicle's charge state is determined. For example, the charge state may be determined according to the voltage of the vehicle's battery (e.g., battery 128), or any of various other techniques may be used alternatively or additionally. Although method 800 is described in an example in which the charge state is evaluated to configure the vehicle according to an operating mode associated with the vehicle based on a set of maintenance rules, it will be understood that similar techniques may be used to process any of various other vehicle control system information and associated operating modes.

[0170]

[0206] The flow proceeds to operation 808, where the maintenance rules are processed. In some cases, the maintenance rules may be interdependent or hierarchical, and as a result, the rules may be evaluated sequentially and / or based on the processing results of one or more previous maintenance rules. For example, a first maintenance rule may be satisfied when the charge state is greater than or equal to a first predetermined threshold. On the other hand, if the charge state falls below the first predetermined threshold, a second maintenance rule may be evaluated, associated with a second predetermined threshold that is less than the first predetermined threshold. Similarly, if the second maintenance rule is not satisfied, a third maintenance rule may be evaluated, having a third predetermined threshold that is less than both the first and second predetermined thresholds.

[0171]

[0207] Each maintenance rule may have associated operating modes (for example, a fully connected operating mode, a limited connection operating mode, and a disconnected operating mode, respectively). Any of the various rules may be used, and as another example, the rules may evaluate external information. For example, a vehicle ambient temperature sensor may be used, or if the vehicle is not equipped with an ambient temperature sensor, weather data may be acquired (for example, via a connection circuit).

[0172]

[0208] The flow branches to decision 810 according to the processing result of operation 808. For example, if it is determined that the vehicle should be configured according to a fully connected operating mode, the flow branches to operation 812, in which the connection unit (e.g., dongle 170 in Figures 1-2, TCU 250 in Figures 3-4, or connection circuit 512 in Figure 34) is configured to be enabled in operation 812, and the vehicle is configured to maintain communication with the vehicle platform in operation 814. For example, such an operating mode may allow the entire set of vehicle connectivity functions to be available, thereby enabling communication with the vehicle platform and / or allowing the driver to interact with the vehicle using a driver device (e.g., driver device 506). Thus, an ongoing communication session with the vehicle platform can be maintained.

[0173]

[0209] Alternatively, if it is determined that the vehicle should be configured according to the connection-restricted mode, the flow branches to operation 816, in which the connection unit is configured to start periodically, non-essential components are disabled in operation 818, and a reduced dataset is communicated in operation 820. Thus, the set of functional features available is reduced compared to the fully connected operation mode. Furthermore, certain components of the vehicle may be disabled or polled at a reduced rate, thereby conserving the vehicle's charge state.

[0174]

[0210] Finally, if it is determined that the vehicle should be configured according to the disconnected mode, the flow branches to operation 822, in which the connection unit is disabled, and in operation 824, critical components are disabled. In the example, the operation modes may be implemented sequentially, and as a result, non-critical components may already be disabled as a result of performing the aspect of operation 818 that puts the vehicle into the connection-restricted operation mode described above. Thus, in other examples (for example, when transitioning from a fully connected operation mode to a disconnected operation mode), configuring the vehicle according to the disconnected operation mode may further include disabling non-critical components.

[0175]

[0211] Furthermore, Method 800 is described as an example in which the vehicle's charge state is reduced, resulting in reduced vehicle functionality and disabled vehicle components. It will be understood that a similar technique may be used in cases where the vehicle's charge state is increasing (for example, as a result of battery charging or changes in environmental conditions). In such cases, critical components may be enabled as a result of shifting from a disconnected operating mode to a connected-limited operating mode, and similarly, non-critical components may be enabled when shifting from a connected-limited operating mode to a fully connected operating mode. Method 800 terminates in operation 814, 820, or 824.

[0176]

[0212] Figure 37B provides an overview of another exemplary method 850 for controlling vehicle state according to the vehicle's charge state. In this example, an aspect of method 850 is implemented by a vehicle platform, such as the vehicle platform 504 in Figure 34 (e.g., a vehicle state manager 530).

[0177]

[0213] Method 850 is initiated in operation 852, and vehicle information is received. For example, vehicle information may be received from a vehicle performing the embodiment of operation 802 described above with respect to Figure 37A. Exemplary vehicle information includes, but is not limited to, vehicle type, vehicle model, vehicle identification number (VIN), and / or various vehicle control system information.

[0178]

[0214] In operation 854, driver interaction information is evaluated. For example, a driver communication manager (e.g., driver communication manager 532 in Figure 34) can maintain interaction information (e.g., in cases where the driver has opted in) such as whether a particular function has been used by the driver device and / or how often such functions are used. In some cases, a geographical location (e.g., one provided by a vehicle application such as vehicle application 536) may be received from the driver device, which can be used to determine whether the driver is likely to use the vehicle. For example, the determination may be based on proximity or on direction of travel. In another example, an instruction may be received from a vehicle application that the driver device has crossed a geofence (e.g., a geographical area surrounding the vehicle). Thus, in operation 854, such interaction information can be evaluated to determine, among other examples, a set of functions used by the driver or to predict the driver's use of functions.

[0179]

[0215] The flow proceeds to operation 856, where a set of maintenance rules is generated based on vehicle and interaction information. For example, the maintenance rules (e.g., thresholds, information evaluated by the rules, and / or the modes of operation associated with them) may be based on information associated with the vehicle type, model, or VIN. As another example, the maintenance rules may be adapted according to the driver's use of the associated function. For example, in cases where the driver does not use the vehicle's connected function, the vehicle may communicate with the vehicle platform at a reduced frequency compared to cases where the driver does use the connected function. As yet another example, a vehicle component may be determined to be unimportant or may be disabled before other vehicle components based on the determination that the function used by the driver does not normally use that component.

[0180]

[0216] In some cases, it can be determined that the driver is likely to use the vehicle immediately, and as a result, the vehicle's operating mode can be adapted accordingly. For example, even if the vehicle may have been put into a connection-restricted operating mode in other ways, the maintenance rule may cause the vehicle to be configured into a fully connected operating mode based on such determination. If it is determined that the driver has not actually used the vehicle within a predetermined time, such a maintenance rule may ultimately time out, or, as an alternative, an instruction to return to connection-restricted operating mode may be received from the driver's device.

[0181]

[0217] The flow proceeds to operation 858, and maintenance rules are provided to the vehicle. In some cases, instructions are provided to update the set of maintenance rules, for example, to reconfigure, delete, or add maintenance rules. In an example, for example, vehicle status instructions may be communicated to a driver device to inform the driver that the vehicle has transitioned between states. For example, instructions may be provided to a driver device, as a result the driver device generates a notification that the vehicle has transitioned to fully connected operation mode, limited connection operation mode, or disconnected operation mode. Instructions may include charge status or other vehicle control system information that can be presented to the user.

[0182]

[0218] For example, the driver device may generate a warning that the vehicle's battery has dropped below a predetermined threshold and, as a result, the vehicle has changed to a different operating mode. In some cases, the warning may instruct the driver to plug in the battery, start the vehicle, or otherwise charge it, and that the vehicle will be configured according to a subsequent operating mode when the charge level drops to another predetermined threshold. In another example, the warning may instruct the driver that the battery has risen above a predetermined threshold and, as a result, additional vehicle functions will be activated. In a further example, an instruction may be provided that the vehicle has been placed into an operating mode based on a determination that the driver is likely to use the vehicle (for example, according to the geographical location of the driver device). Operation 860 is shown using a dashed box to indicate that it may be omitted in some examples. Thus, method 850 terminates in operation 860, or in other examples, in operation 858.

[0183]

[0219] Figure 37C provides an overview of an exemplary set 880 of vehicle states and associated transitions according to aspects of the present disclosure. As described above, the vehicle may be configured according to a fully connected operating mode 882, a limited connection operating mode 884, and a disconnected operating mode 886. Arrows are shown between states 882, 884, and 886 to indicate that the vehicle may transition between states 882, 884, and 886 according to any of the various conditions described above. For example, when the charge state is reduced, the vehicle may start in state 882, transition to state 884 at a predetermined threshold, and after reaching another predetermined threshold, finally reach state 886. However, at any point in such a process, the vehicle may return to state 882 as a result of being powered on, as a result of being connected to a charger, or based on a determination that the driver is in close proximity to the vehicle, among other examples.

[0184]

[0220] Operations 888, 890, and 892 are provided to offer exemplary actions that may be taken when the vehicle transitions between states. Instructions may be generated that can be provided to the vehicle platform and / or driver device, as illustrated. For example, the vehicle platform may take any of the following actions in response to the instructions: updating data about the vehicle, relaying instructions to the driver device, etc. As another example, the driver device may generate a warning to the driver.

[0185]

[0221] Figure 38 provides an overview of Illustration 900, which may use an intercept circuit according to an aspect of the present disclosure. As shown, Illustration 900 comprises a key switch connector 902, a key switch harness 904, and an intercept circuit 906. In the example, the intercept circuit 906 may include hardware, software, or any combination thereof. The intercept circuit 906 is connected to the ACCY and RUN connections from the key switch connector 902 and is also connected to the ACCY and RUN connections to the key switch harness 904. In some examples, the intercept circuit 906 allows the ACCY and / or RUN signals to pass from the key switch connector 902 to the key switch harness 904, thereby enabling the expected behavior in a first operating mode. For example, when driver input is received via the key switch connector 902 (and thus signals are provided via the ACCY and / or RUN connections), the vehicle's accessories can be activated and the vehicle can be started. However, the intercept circuit 906 can interrupt such signals provided by the key switch connector 902 in a second operating mode, or otherwise connect or disconnect the signals, thereby affecting the operation of the vehicle.

[0186]

[0222] The intercept circuit 906 is further shown having a connection 908 to the vehicle's CAN bus. It will be understood that various alternative or additional connections may be used, for example, one or more low-speed and / or high-speed connections as described above.

[0187]

[0223] The intercept circuit 906 can determine that the vehicle has been operating for a predetermined period of time, and at that time, it can connect or disconnect the ACCY signal, thereby disabling the vehicle's accessories. In some cases, the intercept circuit 906 may evaluate or otherwise acquire data via connection 908 to determine, for example, whether the driver is interacting with the vehicle. If it is determined that interaction has been received, the timer may be reset, or the ACCY signal may not be connected or disconnected. In another example, an instruction to turn off the vehicle may be received (for example, from the vehicle platform or driver device), and as a result, both the ACCY signal and the RUN signal are no longer provided to the key switch harness 904 via the intercept circuit 906. In some cases, the intercept circuit 906 may include a connection circuit, or communicate with a connection circuit (for example, via connection 908), in order to receive such an instruction.

[0188]

[0224] As another example, an alarm may be generated before such action by an intercept circuit 906. Instructions may be provided, for example, via the vehicle's driver interface (e.g., driver interface 150 in Figures 1-4 or driver interface 510 in Figure 34). In some cases, instructions may be provided to a driver device (e.g., via a connection circuit). The instructions may include a counter, after which ACCY and / or RUN signals may be interrupted. Driver input may be received, and as a result, the driver may override such behavior or provide input to accelerate such behavior, among other examples.

[0189]

[0225] While exemplary behavior of the intercept circuit 906 is described, it will be understood that the intercept circuit 906 may implement any of the various other operating states, similar to those described above with respect to the vehicle state manager 522 in Figure 34. For example, the intercept circuit 906 may provide signals to a module associated with a given operating mode. In other examples, a single module may configure the vehicle according to multiple operating modes. In some cases, the key switch connector 902 may include associated connections, thereby enabling the driver to select such operating modes using the key switch accordingly.

[0190]

[0226] In addition to disconnecting or interrupting the ACCY and / or RUN signals, the intercept circuit 906 may also provide such signals so that accessories are activated and / or the vehicle is turned on (for example, without driver input via the key switch connector 902). Instructions may be received, for example, via the connection circuit (for example, from a driver device or vehicle platform). As another example, instructions may be received from the vehicle's ECU via connection 908. The intercept circuit 906 may evaluate the vehicle's charge state (for example, via a VBATT as shown in Figure 900) to decide whether to provide such signals or conserve vehicle resources. In cases where it is decided to conserve vehicle resources, instructions of such decision may be provided in response.

[0191]

[0227] Although the intercept circuit 906 is shown as intercepting the ACCY and RUN connections, it will be understood that any number of additional or alternative connections may be used. For example, multiple accessory connections may be implemented, with a first accessory connection associated with critical accessories and a second accessory connection associated with non-critical accessories. Thus, critical accessories can be activated by providing a signal through the first accessory connection, and non-critical accessories can be activated by providing a signal through the second accessory connection. Such accessory connections may be operated independently, and as a result, critical and / or non-critical accessories can be controlled as a result of driver input in the key switch connector 902 according to the embodiments described herein, and / or by the intercept circuit 906. Exemplary critical accessories may include GPS, vehicle-to-vehicle communication functions, and at least some functions provided by the IVI (e.g., maps and vehicle control). Exemplary non-critical accessories may include pulse bars, off-road lights, amplifiers, and / or media playback functions of the IVI.

[0192]

[0228] The behavior of the intercept circuit may be configurable by the driver. For example, the driver may disable or specify a timeout that subsequently implements the mode described above. Such configurability may be based on a key cycle, and as a result, the configuration may be reset between vehicle uses or be a permanent setting, among other examples. Thus, the intercept circuit 906 can enable the driver to remotely control the mode of the vehicle and / or access vehicle control system information (for example, via connection 908), for example, using a driver device or via the vehicle platform.

[0193]

[0229] Figure 39 provides an overview of an exemplary method 1000 for controlling a vehicle using an intercept circuit according to an aspect of the present disclosure. In the example, an aspect of method 1000 is carried out by an intercept circuit, such as the intercept circuit 906 in Figure 38. Method 1000 is initiated in operation 1002, in which the battery saver is activated. For example, the battery saver may be activated automatically during vehicle operation, or it may be activated manually by the driver, in other examples.

[0194]

[0230] In operation 1004, the timer is incremented. As described above, an inactive timer may be used to control the vehicle's behavior, in other examples, independently or further with respect to the vehicle's charge state. In determination 1006, it may be determined whether the charge state falls below a predetermined threshold. For example, the charge state may be determined based on the battery voltage detected via the VBATT connection, as described above with respect to the intercept circuit 906 in Figure 38. In other examples, vehicle control system information may be obtained via connections to one or more ECUs, such as connection 908.

[0195]

[0231] If it is determined that the charge level is not below a predetermined threshold, the flow branches to "No" and proceeds to decision 1008, where it is determined whether the timeout has been reached. As described above, the timeout may be configurable by the driver in some cases. If the timeout has not been reached, the flow branches to "No" and proceeds to decision 1010, where it is determined whether the vehicle state has changed. As described above, driver interaction can terminate the timeout countdown, in which case the flow branches to "Yes" and terminates in operation 1012, exiting battery saver mode and returning to an appropriate state. Exemplary states are described below with respect to Figures 40 and 41. In contrast, if the vehicle state has not changed, the flow branches to "No" and returns to operation 1004, and as a result, the flow loops as described above.

[0196]

[0232] Returning to decisions 1006 and 1008, if the charging threshold is reached or the timeout is met, respectively, the flow branches to "yes" instead and proceeds to action 1014, where an alarm message is presented. For example, the alarm message may be presented via a driver interface or driver device, among other examples. For example, the alarm may be a visual alarm (e.g., via a screen or using one or more lights or light patterns) and / or an auditory alarm.

[0197]

[0233] In determination 1016, it is determined whether an input to ignore the alarm has been received. Therefore, if it is determined that an input has been received, the flow branches to "yes" and terminates in operation 1018, the battery saver mode is disabled, and the vehicle can enter state 2 (for example, accessory mode, as will be described in more detail later with respect to Figures 40 and 41).

[0198]

[0234] In contrast, if no input is received, the vehicle state may be changed in operation 1020. For example, the intercept circuit may connect or disconnect one or more signals to the key switch harness, thereby disabling access and / or turning off the vehicle. In operation 1022, the countdown timer is stopped, and in operation 1024, the vehicle enters state 4 (for example, as a result, the vehicle is turned off, as will be described in more detail with respect to Figure 40). The flow ends in operation 1024.

[0199]

[0235] FIG. 40 shows an overview of an exemplary vehicle state 1100 associated with an intercept circuit. For example, the illustrated state may be implemented by an intercept circuit such as the intercept circuit 906 of FIG. 38. Thus, the illustrated state represents signals that can be provided via ACCY and / or RUN connections, such as those described above with respect to FIG. 38. Additionally, the state indicates whether the battery saver function is enabled, similar to the manner described above with respect to FIG. 39. Finally, a particular state can enable the “wake on CAN” function, similar to that described above with respect to the intercept circuit 906 via the connection 908 of FIG. 38. The state 1100 further shows an exemplary key position as that which can be received by a key switch, such as the key switch connected to the key switch connector 902 of FIG. 38.

[0200]

[0236] FIG. 41 shows another overview 1200 of the transition logic associated with an exemplary vehicle state and an intercept circuit. The states shown in the overview 1200 are similar to the state 1100 discussed with respect to FIG. 40 and are further shown as including exemplary transition logic between the illustrated states. For example, multiple thresholds may be used with respect to the vehicle charge state (e.g., “SOC>X” or “SOC<Y”). Similarly, engine RPM (or other information associated with a prime mover such as the prime mover 112 of FIGS. 1 - 4) may be evaluated as part of the transition logic (e.g., as obtained via a CAN bus or other connection similar to the connection 908 of FIG. 38). “Accessory input” and “Run Input” are provided as exemplary inputs that can be received via a key switch in the manner described herein.

[0201]

[0237] Figure 42 provides an overview of another diagram 1300 of an intercept circuit according to an aspect of this disclosure. The aspect of diagram 1300 is similar to that described above with respect to diagram 900 in Figure 38. For example, a signal from the key switch 1302 (e.g., via the ON and ACC connections) is received by the ORVCM 1306 (whose aspect is similar to that of the intercept circuit 906). Thus, the ORVCM 1306 can provide a signal to the engine control module (ECM) 1304 or control one or more sets of accessories (e.g., via ACC1 OUT and ACC2 OUT). Thus, although only one accessory connection is shown between the key switch 1302 and the ORVCM 1306, the ORVCM 1306 can still manage multiple accessory connections and associated accessories according to the aspects described herein. The circuits, resistance values, voltages, and other embodiments in Figure 38, Diagram 900 and Figure 42, Diagram 1300 are provided as examples, and it should be understood that such embodiments may differ in other examples.

[0202]

[0238] Figure 43 shows an exemplary system 1400 in which the driver interface 1402 and telematics control unit 1404 operate to provide vehicle connectivity functions, according to embodiments described herein. In this example, embodiments of the driver interface 1402 and telematics control unit 1404 may be the same as the driver interface 510 and connection circuit 512 described above with respect to Figure 34, respectively. In another example, embodiments of the driver interface 1402 may be the same as the driver interface 150 described above with respect to Figures 1 to 4. Similarly, embodiments of the telematics control unit 1404 may be the same as the wireless plug-in dongle 170, telematics control unit 250, intercept circuit 906, or ORVCM 1306 described above with respect to Figures 1 to 4, Figure 38, and Figure 42. Thus, such embodiments are not necessarily described again below.

[0203]

[0239] The driver interface 1402 is shown to comprise a processor 1406, a location determination means 1412 (e.g., GPS), a communication controller 1414, and an expansion interface 1416. The processor 1406 includes a high-power domain 1408 and a real-time domain 1410. In the example, the high-power domain 1408 and the real-time domain 1410 may each have associated physical and / or virtual resources of the processor 1406. For example, processes in the real-time domain 1410 may have a higher priority than processes in the high-power domain 1408. In some examples, each domain may have an associated set of physical and / or virtual resources. For example, the real-time domain 1410 may have one or more dedicated processor cores that are not shared with the high-power domain 1408. The real-time domain 1410 can handle functions associated with the operation of the vehicle (for example, as associated with the prime mover 142, transmission 146, suspension system 120, braking system 122, and / or steering system 124 as described above in Figures 1 to 4), while the high-power domain 1408 can handle tasks that are relatively less sensitive to processing delays and stability considerations (for example, associated with IVI functions).

[0204]

[0240] While exemplary processing and resource allocation are described herein, it will be understood that various other processing and / or allocations may be implemented or used. For example, the high-power domain 1408 and the real-time domain 1410 do not need to be implemented using a single processor 1406. As another example, the high-power domain 1408 may be responsible for at least some functions associated with vehicle operation, such as when the driver interface 1402 displays information associated with vehicle functions to the driver. In such an example, such embodiments can instead be handled by the real-time domain 1410 or another electronic control unit, so that the high-power domain 1408 can acquire and / or present such information without affecting the operation of the vehicle (e.g., vehicle 100 or vehicle 502).

[0205]

[0241] In some examples, the communication controller 1414 enables communication (e.g., by the processor 1406) with another vehicle (not shown), a driver device (e.g., driver device 506 in Figure 5), or a vehicle platform (e.g., vehicle platform 504) using one or more wired and / or wireless communication technologies, among other examples. For example, the communication controller 1414 may include a Bluetooth and / or Wi-Fi radio that communicates directly with a corresponding radio of a remote device. It will be understood that the communication controller 1414 may implement any of a variety of additional or alternative communication technologies, including UWB or NFC, among other examples, but not limited to these. In some cases, the communication controller 1414 may communicate with other vehicles and / or emit beacons (e.g., using Wi-Fi or Bluetooth Low Energy) that can be used by other vehicles and / or vehicle platforms to locate the vehicle without or in addition to communication via cellular communication or other internet connectivity.

[0206]

[0242] The telematics control unit 1404 is shown to comprise a power circuit 1418, a power supply 1420, an expansion interface 1422, a low-power modem 1424, a high-power modem 1426, a shared modem resource 1428, a CAN interface 1430, and a low-power domain processor 1432. In the example, the power circuit 1418 supplies power to the elements of the telematics control unit 1404 (e.g., the low-power domain processor 1432, the low-power modem 1424, and the high-power modem 1426).

[0207]

[0243] For example, the power circuit 1418 may be powered by power supply 1420 and / or another power supply in the vehicle. As an example, the power circuit 1418 may be powered by the vehicle power supply (for example, from the battery or alternator of vehicle 100 or vehicle 502) when the vehicle is operating, while the power circuit 1418 may instead be powered by power supply 1420 when the vehicle is powered off or the charge state of the vehicle power supply falls below a predetermined threshold. The power supplies do not need to be mutually exclusive, and as a result, it will be understood that in some examples the power circuit 1418 may be powered by multiple such power supplies. As another example, power supply 1420 may allow the telematics control unit 1404 to operate even when the vehicle power supply is disconnected, as may be the case if the vehicle is stolen.

[0208]

[0244] The telematics control unit 1404 may operate in a reduced state or be powered off when the vehicle is powered off or the vehicle's power supply falls below a predetermined range. Similarly, the telematics control unit 1404 may operate in a reduced state or be powered off depending on the charge state of the power supply 1420. The behavior of the telematics control unit 1404 in such scenarios may be the same as described above with respect to, for example, Figures 33, 37A to 37C, 39, and 40.

[0209]

[0245] Power supply 1420 is indicated by a dashed box to show that, in some examples, power supply 1420 may be omitted. Power supply 1420 may be pre-installed, or, in another example, may be serviceable by the user so that the user can adaptively install or replace power supply 1420. In examples where power supply 1420 is present, power circuit 1418 can recharge power supply 1420 using the vehicle power supply (for example, when the vehicle is charging or powered on). Additionally, the behavior of telematics control unit 1404 may differ depending on whether power supply 1420 is present or not. For example, connections via low-power modem 1424 and / or high-power modem 1426 may be available while the vehicle is powered off in examples where power supply 1420 is present. In other examples, information may be provided to the vehicle platform at a higher frequency or with higher fidelity (as pre-configured or user-configurable in other examples).

[0210]

[0246] As another example, power supply 1420 can enable the telematics control unit 1404 to operate at a lower voltage than when the vehicle power supply is used. For example, the telematics control unit 1404 may be capable of operating over a wide range of voltages, at least part of which may be below the threshold at which the vehicle can operate. Therefore, in the absence of power supply 1420, the telematics control unit 1404 can reduce its output to conserve the vehicle power supply, thereby ensuring that the vehicle can start.

[0211]

[0247] In further examples, power supply 1420 may utilize a different battery chemistry compared to the vehicle power supply. For example, the chemistry of power supply 1420 may be selected according to the intended environment in which the vehicle can operate, thereby enabling the telematics control unit 1404 to operate in extreme cases where it would be difficult or impossible to operate using the vehicle power supply in other ways.

[0212]

[0248] Similarly, the telematics control unit 1404 may operate at a voltage lower than the range of the power supply 1420, thereby simplifying the configuration of the power circuit 1418. Since the voltage of the power supply 1420 can vary, among other things, depending on temperature, charge state, and / or whether the power supply 1420 is charged, utilizing a lower voltage can reduce or eliminate the need to step up or down the voltage supplied from the power supply 1420 to the telematics control unit 1404.

[0213]

[0249] In the example, the charge status of power supply 1420 may be made available to other components of the vehicle. For example, the low-power domain processor 1432 may provide an indication of the charge status via the CAN interface 1430, and as a result, other functions of the vehicle may be configured accordingly. In another example, the indication may be provided to the driver interface 1402 (for example, via the expansion interface 1422), and as a result, the charge status can be presented to the driver of the vehicle. In yet another example, the indication may be provided to the vehicle platform and / or driver devices (for example, via the low-power modem 1424 and / or the high-power modem 1426).

[0214]

[0250] The telematics control unit 1404 is further shown to include a low-power domain processor 1432. Compared to processor 1406, the low-power domain processor 1432 can consume less power. Therefore, the low-power domain processor 1432 can perform processing more efficiently than processor 1406, at least in some scenarios. Thus, in cases where the vehicle is powered off, the low-power domain processor 1432 can enable connectivity for a longer period of time (e.g., via low-power modem 1424 and / or high-power modem 1426) than processor 1406 might otherwise be used.

[0215]

[0251] The functions provided by the low-power domain processor 1432 may be the same as those of the processor 1406. Therefore, the low-power domain processor 1432 can be used to perform processing as an alternative to processing by the processor 1406 (for example, in the high-power domain 1408 and / or the real-time domain 1410). In other examples, the low-power domain processor 1432 can perform processing simultaneously with and / or in cooperation with the processor 1406, for example, to provide access to the vehicle's CAN bus (for example, via the CAN interface 1430). Therefore, compared to cases where the processor 1406 is powered off, suspended, or used in reduced functionality (for example, with reduced load or at a lower clock speed), the low-power domain processor 1432 can provide similar functionality but with reduced power consumption. In examples, the processor 1406 and the low-power domain processor 1432 can share storage, memory, and / or event buses that can be used for such collaborative processing.

[0216]

[0252] For example, the low-power domain processor 1432 can control the low-power modem 1424 to provide an anti-theft function, to provide location tracking, to provide other vehicle information or telemetry, and / or to communicate with a vehicle platform or driver device to provide any of the various functions.

[0217]

[0253] The low-power domain processor 1432 can have a sleep state, and as a result, various wake sources can wake the low-power domain processor 1432 from the sleep state and perform processing. For example, the low-power domain processor 1432 may determine whether theft monitoring is enabled, and if so, an accelerometer (not shown) may be set as the wake-up source.

[0218]

[0254] As another example, the low-power domain processor 1432 may provide telemetry data to the vehicle platform (for example, using the low-power modem 1424). Thus, the low-power domain processor 1432 may determine whether a check-in interval should be scheduled, and if so, may make an authentication request to the vehicle platform. For example, the low-power domain processor 1432 may authenticate with the vehicle platform using authentication data (for example, which may be obtained from processor 1406 using a hardware mailbox and / or from secure storage). In the example, the low-power domain processor 1432 may receive a valid authentication token in response from the vehicle platform, and then the low-power domain processor 1432 may issue a check-in request and process the response for further action instructions. The low-power domain processor 1432 can then return to a sleep state until it is time for the next check-in.

[0219]

[0255] It will be understood that any of the following responses may be received from the vehicle platform, but are not limited to, an instruction that a wireless update is available (for example, in response to such instruction, the processor 1406 may be invoked to handle the update in accordance with the embodiments described herein), a request for fault codes or telemetry data (for example, in response to such request, the low-power domain processor 1432 may obtain the requested information, for example, via the CAN interface 1430 and / or the extended interface 1422), an instruction to change the status of vehicle theft monitoring (as a result, for example, the low-power domain processor 1432 may configure its theft alert accordingly), an instruction to update the vehicle geofence (as a result, for example, the location determination means 1412 may be used to monitor the vehicle status with respect to the geofence), and / or a non-operation instruction (in some examples, this may include an instruction for the next scheduled check-in).

[0220]

[0256] In some examples, the interval and / or wake source set may be user-configurable, for example, by providing user input to the vehicle platform and / or the driver interface 1402 via an application on a driver device. In some examples, the interval and / or wake source set may be configured dynamically. For example, the low-power domain processor 1432 can be activated in response to accelerometer activity and, in that respect, can be configured to be activated more frequently and / or to provide location information to the vehicle platform (at such an updated frequency). The low-power domain processor 1432 may remain in this configuration until no accelerometer activity is detected for a predetermined period of time, at which point it may revert to its initial configuration.

[0221]

[0257] In one example, when the low-power domain processor 1432 is in a sleep state, a message received from the low-power modem 1424 may wake up the low-power domain processor 1432, thereby providing a "wake-up" function. Thus, the operation of the low-power domain processor 1432 may be controlled, for example, using SMS messages containing commands associated with a specified behavior. In another example, the low-power domain processor 1432 may request additional instructions from the vehicle platform in response to such a message.

[0222]

[0258] In other examples, such as when CAN traffic is detected (e.g., via CAN interface 1430), when it is detected that the vehicle power supply is disconnected (e.g., via power circuit 1418), when it is determined that the charge state of power supply 1420 falls below a predetermined threshold, when an interrupt or other instruction is received from processor 1406, when an accelerometer event is detected and the theft warning is activated (as described above), and / or after a predetermined time has elapsed (e.g., as may be the case in the case of a real-time clock alarm), the low-power domain processor 1432 may exhibit similar startup behavior.

[0223]

[0259] In some cases, the low-power domain processor 1432 can identify scenarios in which additional computing resources should be used. For example, the low-power domain processor 1432 may decide to utilize the high-power modem 1426 and / or have the processor 1406 perform processing (for example, in the high-power domain 1408) according to the embodiments described herein.

[0224]

[0260] Therefore, the low-power domain processor 1432 may configure the low-power modem 1424 and the high-power modem 1426 accordingly, or, as an alternative example, may provide instructions to the processor 1406 to perform such processing. For example, among other examples, the low-power domain processor 1432 may cause the processor 1406 to boot, or other hardware in the vehicle may cause the processor 1406 to boot. In the example, the low-power domain processor 1432 may provide data to the processor 1406, as a result the processor 1406 may resume or otherwise continue the processing being performed by the low-power domain processor 1432 in the high-power domain 1410. As an example, the low-power domain processor 1432 may buffer data from the CAN interface 1430, the low-power modem 1424, and / or the high-power modem 1426 while the processor 1406 is booting.

[0225]

[0261] In another example, the processor 1406 can identify scenarios where the computing resources to be used should be reduced. For example, among other examples, the processor 1406 may determine that the vehicle is no longer operating, that the utilization of the processor 1406 is such that the low-power domain processor 1432 can handle similar processing at a reduced power consumption rate, or that the driver interface 1402 is no longer being used. Thus, the low-power domain processor 1432 may be used to perform processing instead of or in addition to the processor 1406. For example, among other examples, the processor 1406 may boot the low-power domain processor 1432, or other hardware of the vehicle may boot the low-power domain processor 1432. In an example, the processor 1406 may provide data to the low-power domain processor 1432, and as a result, the low-power domain processor 1432 may resume or continue in another manner the processing being performed by the processor 1406. As an example, the processor 1406 may provide information such as an authentication token or other authentication information that can be used by the low-power domain processor 1432 to communicate with the vehicle platform while the low-power domain processor 1432 is in use, for communicating with the vehicle platform.

[0226]

[0262] As an example, an indication of a wireless update may be received, and as a result, the low-power domain processor 1432 may perform at least a portion of the processing associated with the update (e.g., download and stage a set of files associated with the update). When the low-power domain processor 1432 completes its processing, the processor 1406 may be activated (and in some examples, the low-power domain processor 1432 may be powered off), and as a result, the application of the wireless update by the processor 1406 is completed. For example, the processor 1406 may generate a checksum for verifying the downloaded data and perform a delta processing associated with the application of the delta update. In other examples, at least a portion of the processing by the processor 1406 may be performed concurrently with the processing by the low-power domain processor 1432. The exemplary operations are described as being performed by either the processor 1406 or the low-power domain processor 1432, but it will be understood that any of the various processes may be performed according to a similar or different partitioning of tasks.

[0227]

[0263] The telematics control unit 1404 is further shown as including a low-power modem 1424, a high-power modem 1426, and a shared modem resource 1428. In an example, the low-power modem 1424 and the high-power modem 1426 may each have an associated set of modem characteristics, and at least some of the characteristics may be different. For example, the low-power modem 1424 may implement features associated with reduced power consumption, such as those defined by Category M of the Long Term Evolution (LTE) standard (e.g., Power Saving Mode (PSM) and / or Extended Discontinuous Reception (eDRX)). Similarly, the high-power modem 1426 may include features that relatively increase power consumption, such as those of LTE Category 1. Each of the cellular modems 1424 and 1426 may implement different cellular technology standards in some examples.

[0228]

[0264] Therefore, the low-power modem 1424 can consume less power (e.g., on average or at peak load) than the high-power modem 1426, while the high-power modem 1426 can provide a relatively higher data rate than the low-power modem 1424. In the example, the low-power modem 1424 may have increased range and / or wireless sensitivity compared to the high-power modem 1426. While exemplary modem characteristics and trade-offs have been described, it will be understood that a set of cellular modems may exhibit, or be selected according to, a variety of additional, alternative, or fewer criteria, including, but not limited to, cost, size, operating voltage, and / or operating temperature.

[0229]

[0265] As a result of including multiple cellular modems (in this example, for example, a dual modem with a low-power modem 1424 and a high-power modem 1426), it may be possible to take advantage of the scenario-specific benefits of each modem. For example, the low-power modem 1424 may be used to provide a low-power connection (for example, when the vehicle is off or when the charge state of the power supply 1420 is below a predetermined threshold). In contrast, the high-power modem 1426 may be used for a high-bandwidth connection, as in other examples, such as when downloading software or map updates for the vehicle's ECU or when downloading content for the driver interface 1402. In another example, the high-power modem 1426 may be used when power saving is not necessary, such as when the vehicle is charging or operating. In some cases, the low-power modem 1424 may implement cellular technology with greater range or signal sensitivity than the high-power modem 1426, and as a result, the low-power modem 1424 can be used as a "fallback" when the high-power modem 1426 is unavailable to establish a connection (or conversely, when the low-power modem 1424 is unavailable to establish a connection, the high-power modem 1426 can act as a fallback by improving its range or sensitivity).

[0230]

[0266] The telematics control unit 1404 is further shown to include a shared modem resource 1428 used by both the low-power modem 1424 and the high-power modem 1426. For example, the shared modem resource 1428 may include an antenna and a subscriber identification module (SIM). The antenna and SIM may be selectively connected to the low-power modem 1424 or the high-power modem 1426 depending on which modem is being used (for example, using a physical switch or an electrical switch, among other examples). For example, the switch may have a first state and a second state, and the resources of the shared modem resource 1428 are electrically coupled to the low-power modem 1424 in the first state and electrically coupled to the high-power modem 1426 in the second state. In some cases, the transition of a shared modem resource 1428 from one modem to the other may involve associated processes (for example, unregistering one modem from the cellular network, transitioning the shared modem resource 1428 from a low-power modem 1424 to a high-power modem 1426 (or vice versa), and re-registering the other modem to the cellular network), the manifestations of which are described below with reference to Figure 45B.

[0231]

[0267] The antenna and SIM are given as examples of shared modem resources 1428, and it will be understood that in other examples fewer, additional, or alternative resources and / or resource types may be used. In the examples, multiple antennas may be used, for example, one antenna located outside the telematics control unit 1404 (and thus with improved range), and another antenna located inside the telematics control unit 1404 and serving as a backup antenna. The backup antenna may be used in scenarios where the external antenna is unavailable, such as in cases where it is damaged or intentionally disconnected during vehicle theft.

[0232]

[0268] Furthermore, although this example describes a scenario in which multiple cellular modems are used, it should be understood that similar techniques may be used for any of the various other wireless communication radios, including satellite communications, Bluetooth, or Wi-Fi. In addition, while cellular modems may have overlapping functions, each modem does not need to implement the same set of communication technologies.

[0233]

[0269] As illustrated, the driver interface 1402 and the telematics control unit 1404 are communicatively coupled via, for example, expansion interfaces 1416 and 1422, respectively. For example, the driver interface 1402 and the telematics control unit 1404 may communicate using, among other examples, USB connections, Ethernet connections, and / or BroadR-Reach connections.

[0234]

[0270] Therefore, as described above, the processor 1406 and the low-power domain processor 1432 may communicate via the extension interfaces 1416 and 1422, respectively. In another example, the processor 1406 may be able to utilize elements of the telematics control unit 1404 without active involvement from the low-power domain processor 1432 (for example, when the low-power domain processor 1432 is powered off or suspended), while the low-power domain processor 1432 may be able to utilize elements of the driver interface 1402 without active involvement from the processor 1406 (for example, when the processor 1406 is powered off or suspended).

[0235]

[0271] For example, the high-power modem 1426 may be switchably connected to the low-power domain processor 1432 and the expansion interface 1422, thereby enabling control of the high-power modem 1426 by the low-power domain processor 1432 and processor 1406 (for example, via the expansion interface 1422). For example, a USB switch may be used to enable USB communication between the high-power modem 1426 and either processor 1406 or 1432. Similarly, the low-power modem 1424 may be connected to both the low-power domain processor 1432 and the expansion interface 1422, or, as an alternative example, a communication protocol for communication with only the low-power domain processor 1432 (e.g., a general-purpose asynchronous transceiver (UART), inter-integrated circuit (I2C), or serial peripheral interface (SPI)) may be used.

[0236]

[0272] As another example, the location determination means 1412 may be switchably connected to the processor 1406 and the expansion interface 1416, thereby enabling control of the location determination means 1412 by the processor 1406 or the low-power domain processor 1432 (for example, via the expansion interface 1416). Therefore, the low-power domain processor 1432 can utilize the location determination means 1412 even when the processor 1406 is powered off.

[0237]

[0273] It will be understood that any of the various communication protocols may be used. For example, the extension interfaces 1416 and 1422 can utilize USB in this example, since the high-power modem 1426 and / or location determination means 1412 can each implement USB and thus communicate with the driver interface 1402 and the telematics control unit 1404, respectively, with little or no additional processing. In other examples, the extension interfaces 1416 and 1422 may implement additional or alternative protocols, as may be the case in which the high-power modem 1426 and / or location determination means 1412 implement one or more different protocols. In other examples, the extension interfaces do not need to implement the same protocols, and as a result, a conversion circuit (for example, as part of the processor 1406 or 1432, or as a separate circuit) may be used to convert the communication via the extension interfaces for use by the high-power modem 1426, the location determination means 1412, or any of the various other elements.

[0238]

[0274] Therefore, the telematics control unit 1404 provides additional functions and / or low-power functions in addition to the functions provided by the driver interface 1402. In some examples, the telematics control unit 1404 may be an add-on device, and as a result, the vehicle may have only the functions provided by the driver interface 1402 in some examples, while another vehicle may have the functions provided by both the driver interface 1402 and the telematics control unit 1404. For example, the vehicle may be equipped with the telematics control unit 1404 during or after manufacture (e.g., by the driver or at a service center).

[0239]

[0275] Furthermore, as a result of the communication enabled by the extension interfaces 1416 and 1422, the extent of overlap between these components can be reduced. As illustrated, since the processor 1406 can utilize elements of the telematics control unit 1404, the telematics control unit 1404 does not need to include a processor similar to the processor 1406. Similarly, since the low-power domain processor 1432 may be able to utilize the location determination means 1412, the telematics control unit 1404 does not need to include the location determination means. The shared modem resource 1428 further reduces component overlap. In addition, as a result of the shifting of processing between the processor 1406 and the low-power domain processor 1432 and the dynamic utilization of the low-power modem 1424 or high-power modem 1426 as described herein, power consumption can also be reduced.

[0240]

[0276] The driver interface 1402 and telematics control unit 1404 shown in system 1400 are provided as examples, and it will be understood that in other examples, the driver interface 1402 and / or the telematics control unit 1404 may include additional, alternative, or fewer elements. For example, the driver interface 1402 may include a CAN interface in addition to or as an alternative to the CAN interface 1430 of the telematics control unit 1404. In another example, the telematics control unit 1404 may include location determination means in addition to or as an alternative to the location determination means 1412 of the driver interface 1402. Similarly, the telematics control unit 1404 may include a communication controller similar to the communication controller 1414, or the driver interface 1402 may include a modem (for example, a low-power modem 1424 or a high-power modem 1426).

[0241]

[0277] Figure 44 shows an exemplary system 1450 in which the telematics control unit 1452 incorporates the embodiments of the driver interface 1402 and the telematics control unit 1404 described above with respect to Figure 43. Thus, embodiments of the telematics control unit 1452 may be the same as those described above and are therefore not necessarily described again in detail below.

[0242]

[0278] As shown in the figure, the telematics control unit 1452 includes a power circuit 1418, a power supply 1420, a processor 1406, a low-power domain processor 1432, a low-power modem 1424, a high-power modem 1426, a shared modem resource 1428, a CAN interface 1430, an expansion interface 1422, a location determination means 1412, and a communication controller 1414.

[0243]

[0279] Therefore, compared to Figure 43, the telematics control unit 1452 can incorporate the functions described above into a single device. Similar to Figure 43, the processor 1406 and the low-power domain processor 1432 may communicate switchably with the high-power modem 1426 via the expansion interface 1422, for example, using a USB switch. In another example, the processor 1406 and the low-power domain processor 1432 may be a single processor having a set of physical and / or virtual resources allocated to each of the low-power domains, for example, the high-power domain 1408, the real-time domain 1410, and the low-power domains, where processing similar to the processing described above is performed with respect to the low-power domain processor 1432.

[0244]

[0280] In the example, processor 1406 and low-power domain processor 1432 may each utilize the CAN interface 1430, for example, depending on which processor is active. A switch (not shown) may be used to enable communication via the CAN interface 1430 by either processor 1406 or low-power domain processor 1432. Furthermore, in the case where both processors are active, a preference may be given to either processor 1406 or low-power domain processor 1432, so that the other processor can access the CAN bus via the processor to which the CAN interface 1430 is accessible. In another example, in the case where the telematics control unit 1452 is transitioning from the first processor to the second processor, the first processor may buffer CAN data in memory until the CAN interface 1430 is switched to be operable by the second processor, and at the time of the switch, the buffered CAN data may be made available for use by the second processor, thereby reducing the degree to which access to the CAN bus is interrupted.

[0245]

[0281] Figures 43 and 44 are given as exemplary configurations that should provide the vehicle connectivity functions described herein. In some cases, the telematics control unit 1404 may be used, such as when a driver interface similar to the driver interface 1402 already exists or when it becomes possible to install such a telematics control unit after manufacture. Thus, as mentioned above, the telematics control unit 1404 reduces component duplication in such scenarios. In other cases, the telematics control unit 1452 may be used, such as when the vehicle does not have a driver interface (for example, when the telematics control unit 1452 may be used in a headless configuration without a display) or when the driver interface is provided by the telematics control unit 1452 itself. Thus, any of the various alternative configurations of the elements described may be used in other examples, for example, depending on existing hardware availability and intended use cases.

[0246]

[0282] Figure 45A provides an overview of an exemplary method 1500 for configuring high-power and low-power connections in a vehicle according to the embodiments described herein. In the example, embodiments of method 1500 are carried out by a telematics control unit, such as the telematics control unit 1404 in Figure 43 or the telematics control unit 1452 in Figure 44.

[0247]

[0283] Method 1500 is initiated in operation 1502 when a vehicle start instruction is received. For example, the instruction may be received as a result of user input received by the vehicle, or as a result of user input received by an application on a driver device, among other examples.

[0248]

[0284] The flow proceeds to operation 1504, where the vehicle is configured for high-power connectivity. In an example, operation 1504 includes deregistering a low-power modem (e.g., low-power modem 1424 of FIGS. 43 and 44) from the network and / or shutting down the low-power modem. In some cases, the low-power modem may utilize one or more shared modem resources (e.g., shared modem resource 1428), and as a result, operation 1504 may include configuring the shared modem resource for use by a high-power modem (e.g., high-power modem 1426). For example, an antenna connection may be transitioned from the low-power modem to the high-power modem. Similarly, the SIM may be transitioned to the high-power modem. Additional examples of such aspects are described below with respect to method 1550 of FIG. 45B. In one example, aspects of operation 1504 are performed by a low-power domain processor such as low-power domain processor 1432.

[0249]

[0285] In operation 1506, a connection is established using the high-power modem. For example, operation 1506 may include registering with the network using the SIM. Thus, high-power communication may be performed using the high-power modem, as may be possible in cases where the vehicle is powered on or charging, among other examples. As an example, the high-power modem may be used to perform activities where the use of a higher bandwidth or other modem characteristics provided by the high-power modem is beneficial (e.g., as compared to those of the low-power modem).

[0250]

[0286] The flow ultimately proceeds to determination 1508, which determines whether conditions exist for changing the modem being used. For example, determination 1508 may include determining that the vehicle is powered off, has not been used for a predetermined period of time, or is not charging. Alternatively, determination 1508 may include determining that the high-power modem has a signal strength below a predetermined threshold or has not been able to (re)establish a network connection for a predetermined period of time. In some cases, the signal strength evaluation may use an average over a time period, as geographical features or other features may temporarily affect the signal strength at which it is detected. In some cases, determination 1508 may include evaluating the location from a location determination means against a coverage map to determine whether the high-power modem may have coverage at that location. While exemplary determinations and associated techniques are described, it should be understood that any of the various determinations may be performed in determination 1508 in other examples. Additionally, such determinations may be made within a high-power domain or a low-power domain, as described above with respect to processor 1406 and low-power domain processor 1432, respectively.

[0251]

[0287] If it is determined that there are no conditions regarding whether the modem should be changed, the flow branches to "no," and as a result, the high-power modem continues to be used until such a determination is made again. On the other hand, if it is determined that there are conditions regarding whether the modem should be changed, the flow branches to "yes," and the vehicle is configured for a low-power connection. The aspect of operation 1510 may be the same as that of operation 1504, but the aspect of operation 1510 relates to a low-power modem rather than a high-power modem.

[0252]

[0288] For example, operation 1510 may include unregistering a high-power modem from the network and / or shutting down the high-power modem. In some cases, the high-power modem may utilize one or more shared modem resources, and consequently, operation 1510 may include configuring the shared modem resources for use by a low-power modem. For example, an antenna connection may transition from a high-power modem to a low-power modem. Similarly, a SIM may transition to a low-power modem. Additional examples of such embodiments are described below with respect to method 1550 in Figure 45B. In one example, an embodiment of operation 1510 is carried out by a low-power domain processor, such as a low-power domain processor 1432.

[0253]

[0289] In operation 1512, a connection is established using a low-power modem. For example, operation 1512 may include registering with the network using a SIM. Thus, low-power communication may be performed using a low-power modem, as may be the case in other examples where the vehicle is powered off or has not been used for a predetermined period of time. In another example, low-power communication may be used in cases where a low-power modem enables a greater distance or increases signal sensitivity compared to a high-power modem.

[0254]

[0290] The flow ultimately proceeds to decision 1514, which determines whether conditions exist for changing the modem being used. For example, decision 1514 may include determining that the vehicle is powered on, has been resumed by the driver, or is charging. In another example, decision 1508 may include determining that the low-power modem has a signal strength above a predetermined threshold, or that the location from the location determination means, compared to the coverage map, indicates that the high-power modem may have coverage. As mentioned above, the signal strength evaluation may use an average over a time period. In another example, decision 1514 may include determining that a predetermined amount of time has elapsed since the switch to the low-power modem, and as a result, it may be decided to retry the connection with the high-power modem. While exemplary decisions and associated techniques are described, it should be understood that any of the various decisions may be performed in decision 1514 in other examples. Additionally, such determinations may be made within a high-power domain or a low-power domain, as described above with respect to processor 1406 and low-power domain processor 1432, respectively.

[0255]

[0291] If it is determined that there are no conditions for changing the modem, the flow branches to "no," and as a result, the low-power modem continues to be used until such a determination is made again. On the other hand, if it is determined that there are conditions for changing the modem, the flow branches to "yes," returning to operation 1504, and the vehicle is configured for a high-power connection.

[0256]

[0292] Therefore, the flow may loop between operations 1504 and 1514 to control the vehicle connection using either a low-power modem or a high-power modem depending on various criteria. In some examples, and among others, an additional determination may be made to power off both modems, as may be the case in which the associated power source (e.g., vehicle power or telematics control unit power) has a charge state below a predetermined threshold.

[0257]

[0293] Additionally, method 1500 is provided in an example where the shared modem resource supports the operation of one modem at a time. However, in some cases, the shared modem resource may include multiple antennas (e.g., supporting the same or different frequencies, or located in different locations on the vehicle) and / or SIMs, and as a result, both the high-power modem and the low-power modem may remain powered and / or in use. In such cases, a method similar to method 1500 may be used to determine which modem should be used for communication. For example, such a method may be used to fall back to the low-power modem when it is determined that the high-power modem has no connection, and then resume using the high-power modem when it is determined that the high-power modem has re-established a connection.

[0258]

[0294] Figure 45B provides an overview of exemplary method 1550 for configuring a vehicle high-power or low-power modem. In this example, an aspect of method 1550 is performed when transitioning from a first modem to a second modem, for example, as described above with respect to operations 1504 and 1510 of method 1500 in Figure 45A.

[0259]

[0295] Method 1550 is initiated in operation 1552, in which the first modem is disconnected from the network. In one example, operation 1552 includes turning off the power to the first modem. In another example, the first modem may be used to provide the network with instructions to unregister the modem accordingly. Operation 1552 is shown using a dashed box to indicate that operation 1552 may be omitted in other examples. For example, the network may automatically unregister the modem or may not require such behavior. In another example, the first modem may remain powered on, as may be the case in which data is received or buffered during the transition process.

[0260]

[0296] The flow proceeds to operation 1554, in which the antenna is configured for use by the second modem. For example, a physical or electronic switch may be used to transfer the antenna from the first modem to the second modem. The antenna may also be part of a shared modem resource (for example, the shared modem resource 1428 described above with respect to Figures 43 and 44). While exemplary configuration techniques are described, it will be understood that any of various other techniques may be used to configure the antenna used by the first modem for subsequent use by the second modem.

[0261]

[0297] In operation 1556, the SIM is configured for use by the second modem. As in operation 1554, a physical or electronic switch may be used to transfer the SIM from the first modem to the second modem. The SIM may be part of a shared modem resource. While exemplary configuration techniques are described, it will be understood that any of various other techniques may be used to configure a SIM used by the first modem for subsequent use by the second modem.

[0262]

[0298] Proceeding to operation 1558, a connection to the network is established using the second modem. In the example, operation 1558 includes registering the second modem with the network to establish the connection. In some cases, the network may automatically register the second modem and, as a result, automatically unregister the first modem. In other cases, the first and second modems may be unregistered or not registered, respectively, if the first and second modems can connect to different networks, or if the network may allow multiple devices per SIM. Method 1550 terminates in operation 1558.

[0263]

[0299] In some examples, operations 1554 and / or 1556 may be omitted, as may be the case in which each modem has an associated antenna or SIM. In other examples, method 1550 may include additional operations, as may be the case in which additional resources are transitioned for use by a second modem. Thus, it will be understood that a similar technique may be used in cases where different sets of shared modem resources are used with multiple modems.

[0264]

[0300] Figure 46A provides an overview of an exemplary method 1600 for performing low-power processing according to the embodiments described herein. In this example, embodiments of method 1600 are performed by a low-power domain processor, such as the low-power domain processor 1432 described with respect to Figures 43 and 44.

[0265]

[0301] Method 1600 begins in 1602, with the telematics control unit (e.g., telematics control unit 1404 or 1452) in a low-power state. For example, among other examples, the vehicle may be off, not in use for a predetermined period of time, or the power supply charge level may be below a predetermined threshold.

[0266]

[0302] Therefore, in operation 1604, processing is performed in a low-power domain (for example, as can be done using a low-power domain processor). Exemplary processing includes, but is not limited to, periodic check-ins by the vehicle platform (for example, to provide vehicle information, telemetry data, and / or location from location determination means), processing of accelerometer events, processing associated with a CAN bus (for example, via a CAN interface such as CAN interface 1430), and management of network connectivity for modems (for example, low-power modem 1424 and / or high-power modem 1426). Thus, such low-power processing may enable the vehicle connectivity configurations described herein while prolonging or conserving power available from one or more power sources.

[0267]

[0303] Furthermore, as described above, the processing performed in operation 1604 may be adapted as described herein according to any of a variety of conditions, including, but not limited to, the power supply charge state, whether the telematics control unit has power (e.g., power supply 1420), whether an accelerometer event has been detected (as may be during vehicle theft or other external activity), and whether a driver device is in proximity, and / or according to the user configuration. The behavior of the low-power modem may be similarly configured, for example, to adjust the eDRX interval. It will be understood that operation 1604 may be performed using a low-power modem or a high-power modem, such that it may be configured according to the aspects of methods 1500 and 1550 described above with respect to Figures 45A and 45B.

[0268]

[0304] Ultimately, the flow proceeds to operation 1606, where conditions associated with the high-power domain are identified. Exemplary conditions, but not limited to, include, among other examples, the identification of whether the vehicle is powered on, instructions received from the vehicle platform, or the possibility that the vehicle is stolen.

[0269]

[0305] Therefore, in operation 1608, instructions are provided to perform high-power processing. For example, the instructions may be provided to a processor (e.g., processor 1406) to boot a high-power domain (e.g., high-power domain 1408).

[0270]

[0306] The flow proceeds to operation 1610, where data for the high-power domain is stored. For example, CAN messages, accelerometer data, and / or data received from a modem may be buffered in operation 1610. In this example, the data is buffered in a storage device and / or memory so that it can be shared with the high-power domain.

[0271]

[0307] In operation 1612, a high-power processing instruction is received, indicating that the high-power processor has completed booting. For example, operation 1612 may include providing data stored in operation 1610 in response, or, in another example, the data may be stored in a shared location so that it is accessible to the high-power domain.

[0272]

[0308] Decision 1614 determines whether low-power processing should be continued. As described above, the low-power domain processor may continue to perform processing simultaneously with or in coordination with processing performed in the high-power domain. For example, the low-power processing domain may continue to process location data received from accelerometer events and / or location determination means, and as a result, instructions for such processing may be provided to the high-power domain. Thus, the low-power domain processor may be used to offload at least some of the processing that would otherwise be performed by the high-power domain, thereby freeing up computing resources in the high-power domain and, in some examples, reducing the power consumption associated with such processing. In another example, a high-power domain or a low-power domain may be selected across other domains for reasons of code stability / maturity or computing resource availability, among other examples. Thus, the embodiments described herein can similarly reduce code complexity and improve stability.

[0273]

[0309] Therefore, if it is decided to continue low-power processing, the flow branches to "yes" and proceeds to operation 1618, in which case the low-power domain processor continues processing in accordance with the embodiments described herein. In other examples, if it is determined that low-power processing should not be continued instead, the flow branches to "no" and proceeds to operation 1616, in which case processing in the low-power domain is terminated, for example, by suspending or powering off the low-power domain processor. Method 1600 terminates in either operation 1616 or operation 1618.

[0274]

[0310] Figure 46B provides an overview of an exemplary method 1650 for performing high-power processing according to the embodiments described herein. In this example, embodiments of method 1650 are performed in a high-power domain, such as the high-power domain 1408 of the processor 1406 described with respect to Figures 43 and 44.

[0275]

[0311] Method 1650 begins in 1652, with the telematics control unit (e.g., telematics control unit 1404 or 1452) in a high-power state. For example, in other examples, the vehicle may be operating or charging. In another example, the vehicle may be in a high-power state as a result of an embodiment of Method 1600 described with respect to Figure 46A.

[0276]

[0312] Therefore, in operation 1654, processing is performed in the high-power domain. Exemplary processing includes, but is not limited to, processing associated with higher frequency and / or higher fidelity location updates (compared to the low-power domain), media playback, application of wireless updates, and / or providing a user interface. In some cases, as described above, certain processing can be offloaded to the low-power domain processor, so operation 1654 may also include performing processing in cooperation with the low-power domain processor.

[0277]

[0313] Furthermore, as described above, the processing performed in operation 1654 may be adapted according to any of a variety of conditions, including, but not limited to, the power supply charge status, whether the telematics control unit has power (e.g., power supply 1420), whether an accelerometer event has been detected (as may be during vehicle theft or other external activity), and whether a driver device is in proximity, and / or according to the user configuration. It will be understood that operation 1654 may be performed using a low-power modem or a high-power modem, as can be configured according to the embodiments of methods 1500 and 1550 described above with respect to Figures 45A and 45B.

[0278]

[0314] Ultimately, the flow proceeds to operation 1656, in which conditions associated with the low-power domain are identified. Exemplary conditions, but not limited to, include, among other examples, that the vehicle is powered off, instructions received from the vehicle platform, a determination that processing in the high-power domain is complete, or a determination that the driver has not engaged with the vehicle after a predetermined time.

[0279]

[0315] Therefore, in operation 1658, instructions are provided to perform low-power processing. For example, the instructions may be provided to a low-power domain processor (e.g., low-power domain processor 1432) to boot the low-power domain processor. In some examples, the low-power domain processor may already be active, as may be the case in instances where high-power domain processing is performed concurrently with low-power domain processing. Therefore, operation 1658 may be omitted in some examples.

[0280]

[0316] The flow proceeds to operation 1660, where data for the low-power domain is stored. For example, CAN messages, accelerometer data, and / or data received from a modem may be buffered in operation 1660. In this example, the data is buffered in a storage device and / or memory so that it can be shared with the low-power domain.

[0281]

[0317] In operation 1662, a low-power processing instruction is received, indicating that the low-power processor has completed booting. In an example where the low-power processing domain is already active, such an instruction may not be received. Operation 1662 may also include providing the data stored in operation 1660 to the low-power domain, or, in another example, the data may be stored in a shared location so that it is accessible to the low-power domain.

[0282]

[0318] Decision 1664 determines whether high-power processing should be continued. As described above, the high-power domain processor may continue to perform processing simultaneously with or in coordination with processing performed in the low-power domain. For example, the high-power processing domain may continue to provide a user interface, process CAN data, and / or operate a communication controller (e.g., communication controller 1414), and as a result, instructions for such processing may be provided to the low-power domain. Thus, the high-power domain may perform at least some of the processing that would otherwise be performed by the low-power domain, thereby freeing up computing resources in the low-power domain. As another example, high-power or low-power domains may be selected across other domains for reasons of code stability / maturity or computing resource availability, among other examples. Thus, the embodiments described herein can similarly reduce code complexity and improve stability.

[0283]

[0319] Therefore, if it is determined that high-power processing should be continued, the flow branches to "yes" and proceeds to operation 1668, in which case the high-power domain processor continues processing in accordance with the embodiments described herein. In other examples, if it is determined that high-power processing should not be continued instead, the flow branches to "no" and proceeds to operation 1666, in which case processing in the high-power domain is terminated, for example, by suspending or powering off the high-power domain processor. Method 1650 terminates in either operation 1666 or operation 1668.

[0284]

[0320] Figure 47A provides an overview of an exemplary method 1700 for addressing warning conditions in a low-power domain according to an aspect of the present disclosure. In the example, an aspect of method 1700 is implemented by a low-power domain processor, such as the low-power domain processor 1432 described with respect to Figures 43 and 44.

[0285]

[0321] Method 1700 is initiated in operation 1702, and a warning condition is identified. For example, the warning condition may be identified based on any of accelerometer data, location data, and / or various other pieces of information. In the example, the warning condition may be identified as a result of embodiments of Methods 600 and 650 described above with respect to Figures 35A and 35B. It will be understood that any of the various warnings may be identified according to the embodiments described herein.

[0286]

[0322] The flow proceeds to operation 1704, where instructions are provided to perform high-power processing. For example, the instructions may be provided to a processor (e.g., processor 1406) to boot a high-power domain (e.g., high-power domain 1408).

[0287]

[0323] In operation 1706, it is determined whether the device to communicate is nearby. For example, a communication controller (e.g., communication controller 1414) may communicate with the driver device (e.g., via Bluetooth or Wi-Fi), and as a result, it may be determined whether the device is within range. As another example, it may be determined whether communication with another vehicle to communicate is within range.

[0288]

[0324] If it is determined that a device to communicate with is nearby, the flow branches to "yes" and proceeds to action 1708, where an alert condition instruction is provided. For example, the instruction may be provided to a driver device, and as a result the driver is notified of the alert condition. Alternatively, the instruction may be provided to a nearby vehicle (for example, one that may be part of the same fleet) or may be associated with the same driver. In cases where the alert condition is associated with vehicle theft, the alert may include a location, which may be determined by a location determination means. The flow then proceeds to action 1710, which is discussed below.

[0289]

[0325] Method 1700 is described in an example in which paired or otherwise related devices are available to receive instructions provided in operation 1708. In other examples, determination 1706 and operation 1708 may be omitted, and instead a beacon may be generated. For example, a Bluetooth low-energy beacon may be transmitted, and the beacon may be detected by one or more other devices. Thus, instructions from a detected beacon may be provided to a vehicle platform or other beacon aggregation service. In such an example, the beacon may be provided in association with the location of the device that detected the beacon, so that the driver may be able to identify the location of the vehicle or telematics control unit, even in cases where internet connectivity is unavailable.

[0290]

[0326] Returning to determination 1706, if it is determined that no nearby devices exist, the flow branches to “No” and proceeds to operation 1710, where an instruction for the identified warning condition is provided (e.g., to the vehicle platform). In the example, the instruction may include the type of warning condition and the location from the location determination means. Method 1700 is described in an example in which a low-power modem (e.g., low-power modem 1424) is used to reduce the power consumption associated with method 1700. In this example, the instruction may be relatively small in size, and as a result, the higher bandwidth associated with a high-power modem does not need to be used. Furthermore, it may be beneficial to manage power consumption in such a scenario so that the instruction can be provided to the vehicle platform for as long as possible, thereby increasing the likelihood that the vehicle and / or telematics control unit will be recovered. In other examples, operation 1710 may further include transitioning to a high-power modem according to the embodiments described herein.

[0291]

[0327] In the example, operations 1708 and / or 1710 are performed multiple times, resulting in instructions being provided while the high-power domain is booting. Such instructions can therefore be provided more quickly than in cases where the high-power domain must first complete booting (or, in other examples, resume from sleep). Furthermore, although method 1700 is described in an example where instructions are provided to the device and / or vehicle platform while the high-power domain is booting, it will be understood that any of various additional or alternative measures may be similarly implemented. For example, a CAN interface may be used to control one or more vehicle components via a CAN bus, thereby disabling such components and / or placing the vehicle in a lockout state. Similarly, the frequency with which information is provided to the device and / or vehicle platform may be adjusted, among other examples, depending on whether the device is detected in determination 1706 and / or based on the proximity of the device.

[0292]

[0328] In operation 1712, a high-power processing instruction is received, indicating that the high-power processor has completed booting. Therefore, in operation 1714, data is provided to the high-power domain, enabling the high-power domain to continue processing associated with the identified warning conditions. In other examples, such data may be stored in a shared location, allowing the high-power domain to access it.

[0293]

[0329] In some examples, the low-power domain processor may be powered off or enter a sleep state. In other examples, the low-power processing domain processor may continue processing location information from the location determination means, which may be provided to the high-power domain for processing, among other exemplary processing. Method 1700 terminates in operation 1714.

[0294]

[0330] Figure 47B provides an overview of an exemplary method 1750 for addressing warning conditions in a high-power domain according to an aspect of the present disclosure. In the example, an aspect of method 1750 is carried out by a processor having a high-power domain, such as the processor 1406 described with respect to Figures 43 and 44.

[0295]

[0331] Method 1750 is initiated in 1752, and a high-power state instruction is received. For example, the instruction may be received as a result of a low-power domain processor performing an action of operation 1704 described with respect to Figure 47A.

[0296]

[0332] Therefore, when the high-power domain is booted, operation 1754 is performed and an instruction for high-power processing is generated. The instruction may also be provided to the low-power domain processor, which as a result receives the instruction in operation 1712 described above with respect to Figure 47A.

[0297]

[0333] The flow proceeds to operation 1756, in which data is received from the low-power domain processor. For example, the received data may include, among other data, a location from the location determination means, instructions regarding the type of warning condition, and / or information from the vehicle's CAN bus. In other examples, such data may instead be accessed from a shared location.

[0298]

[0334] In operation 1758, instructions are provided via a low-power modem. Instructions may also be provided to the vehicle platform and / or another device (similar to operations 1708 and / or 1710 described above). The instructions provided may include at least some of the data received from the low-power domain processor and additional information that may be generated by high-power domain processing. Compared to instructions that may be provided by the low-power domain processor (e.g., implementing aspects of operations 1708 and / or 1710), the instructions provided in operation 1758 may be provided more frequently, have higher fidelity, and / or contain more information, among other examples. Thus, the combined processing implemented by a low-power domain processor implementing aspects of method 1700 and a high-power domain implementing aspects of method 1750 allows for both instructions to be temporally close when the warning condition is first identified, and instructions that are more frequent / higher fidelity or require additional processing on the telematics control unit side.

[0299]

[0335] The flow proceeds to decision 1760, where it is determined whether high-power processing should continue. In the example, among other examples, it may also be determined whether warning conditions still exist and / or whether the power supply exceeds a predetermined threshold. In another example, if it is determined that the driver device is no longer within the vehicle's range (e.g., according to the communication controller or within a predetermined distance), it may be decided not to continue high-power processing, as a less frequent update may suffice (e.g., at least until the driver approaches the vehicle again).

[0300]

[0336] Therefore, if it is decided to continue high-power processing, the flow returns to operations 1756 and 1758, and as a result, instructions continue to be provided (e.g., while a warning condition exists). Furthermore, although method 1750 is described in an example in which instructions are provided to a device and / or vehicle platform, it will be understood that any of a variety of additional or alternative measures may be implemented in a similar manner. For example, a CAN interface may be used to control one or more vehicle components via a CAN bus so that such components are disabled and / or the vehicle is locked out. For example, a driver interface may be disabled or configured to display information, among other examples. Similar to method 1700, the frequency in which information is provided to the device and / or vehicle platform may be adjusted, among other examples, depending on the charging status and / or whether the device is within range of a communication controller or in close proximity to a vehicle.

[0301]

[0337] Returning to decision 1760, if it is decided not to continue high-power processing, the flow branches to "no" and terminates in operation 1762, ending processing in the high-power domain. For example, the processor may enter sleep mode or be powered off, among other examples.

[0302]

[0338] Figures 47A and 47B are given as examples of simultaneous or coordinated processing that may be performed by a processor having a high-power domain and a processor having a low-power domain. Although this example is discussed in the context of identifying and handling warning conditions, it will be understood that similar techniques may be used in any of the various other scenarios, for example, to reduce power consumption while improving vehicle availability to provide the connected functionalities described herein.

[0303]

[0339] The following sections are given as exemplary embodiments of the subject matter of this disclosure.

[0304]

[0340] 1. An intercept circuit for a vehicle, comprising: a first connector that can be connected to the vehicle's key switch connector; a second connector that can be connected to the vehicle's key switch harness; and a controller connected to the first and second connectors, wherein the controller is configured to pass a signal from the first connector to the second connector in a first operating mode, and to interrupt the signal in a second operating mode, thereby preventing the transmission of a signal from the first connector to the second connector.

[0305]

[0341] 2. The intercept circuit described in item 1, wherein the controller is further configured to switch from a first operating mode to a second operating mode after a predetermined inactivity period.

[0306]

[0342] 3. The intercept circuit described in Section 2, which includes generating a timeout alarm when switching from a first operating mode to a second operating mode.

[0307]

[0343] 4. The intercept circuit according to item 2 or 3, further comprising a connection to a controller area network, wherein a predetermined inactivity period is identified based on the connection to the controller area network.

[0308]

[0344] 5. An intercept circuit as described in any one of paragraphs 1 to 4, wherein the controller is further configured to generate a signal via a second connector, thereby operating a vehicle function via a key switch harness.

[0309]

[0345] 6. The intercept circuit described in Section 5, further configured to receive instructions to operate a vehicle function, evaluate the vehicle's charge state based on a predetermined threshold, and generate a signal to operate a vehicle function when the vehicle's charge state exceeds a predetermined threshold.

[0310]

[0346] 7. An intercept circuit as described in Section 6, which receives instructions via the vehicle's connection circuit.

[0311]

[0347] 8. The intercept circuit according to any one of paragraphs 1 to 7, further comprising a third connector which can be connected to the vehicle's key switch harness, wherein the second connector is a non-critical accessory connector and the third connector is a critical accessory connector.

[0312]

[0348] 9. The intercept circuit described in Section 8, wherein a signal is provided via a third connector in a second operating mode, thereby disabling non-essential accessories of the vehicle and maintaining power to essential accessories of the vehicle.

[0313]

[0349] 10. The intercept circuit according to paragraph 8 or 9, wherein the controller is further configured to evaluate the vehicle's charge state based on a predetermined threshold and to provide a signal via at least one of a second or third connector based on the vehicle's charge state.

[0314]

[0350] 11. A vehicle comprising a frame, a prime mover supported by the frame, a battery supported by the frame, and a controller, wherein the controller is configured to receive instructions for an operating mode, wherein the operating mode is at least one of the following: a shipping operating mode, a driver connection operating mode, an off-season storage operating mode, a start-up guarantee operating mode, an over-the-air (OTA) operating mode, and a warehouse operating mode, and to configure the vehicle according to the instructed operating mode.

[0315]

[0351] 12. The vehicle described in Section 11, in which instructions are received via the connection of the controller to the key switch connector, and the connection is associated with the indicated operating mode.

[0316]

[0352] 13. The vehicle described in paragraph 11, wherein instructions are received via the vehicle's connection circuit.

[0317]

[0353] 14. A vehicle as described in paragraph 11, in which instructions are received via the vehicle's controller area network.

[0318]

[0354] 15. A vehicle according to any one of paragraphs 11 to 14, wherein the controller is further configured to evaluate the charge state associated with the battery and to configure the vehicle according to an indicated operating mode based on the charge state of the battery.

[0319]

[0355] 16. A vehicle as described in any one of paragraphs 11 to 15, in which the guaranteed starting operating mode is associated with the battery charge state and includes a fully connected operating mode, a limited connection operating mode, and a no-connection operating mode.

[0320]

[0356] 17. Configuring the vehicle according to the warehouse operating mode limits the power output of the prime mover,

[0321]

[0357] A vehicle as described in any one of paragraphs 11 to 16, which includes restricting the functionality of the driver interface and configuring the vehicle's lighting to operate at reduced brightness.

[0322]

[0358] 18. A vehicle according to any one of paragraphs 11 to 17, wherein configuring the vehicle includes providing instructions to the vehicle's vehicle control module for configuring vehicle functions in accordance with an indicated operating mode.

[0323]

[0359] 19. A method for configuring a vehicle based on the charge state of a battery, comprising: evaluating the charge state based on a first predetermined threshold; configuring a vehicle connection circuit to be activated periodically based on the determination that the charge state is below the first predetermined threshold; communicating with a vehicle platform when the connection circuit is activated; evaluating the charge state based on a second predetermined threshold that is below the first predetermined threshold; and disabling the vehicle connection circuit based on the determination that the charge state is below the second predetermined threshold.

[0324]

[0360] 20. The method according to paragraph 19, further comprising the steps of evaluating the charging state based on a first predetermined threshold, configuring the vehicle's connection circuit to an enabled state based on the determination that the charging state exceeds the first predetermined threshold, and maintaining a communication session with the vehicle platform.

[0325]

[0361] 21. The method according to paragraph 19 or 20, wherein a first notification is generated based on a determination that the charge state falls below a first predetermined threshold, and a second notification is generated based on a determination that the charge state falls below a second predetermined threshold.

[0326]

[0362] 22. The method according to paragraph 21, wherein the first and second notices are provided to the driver's device.

[0327]

[0363] 23. The method according to any one of paragraphs 19 to 22, wherein a second predetermined threshold represents a charge state that exceeds the minimum charge state for the operation of the vehicle's engine.

[0328]

[0364] 24. The method according to any one of paragraphs 19 to 23, further comprising the steps of receiving a threshold update from a vehicle platform for at least one of a first predetermined threshold or a second predetermined threshold, and storing the threshold update.

[0329]

[0365] 25. The method according to any one of paragraphs 19 to 24, wherein a set of non-essential components is disabled based on the determination that the charge state falls below a first predetermined threshold.

[0330]

[0366] 26. The method of paragraph 25, wherein the step of communicating with a vehicle platform includes the step of transmitting data from a set of critical components of the vehicle.

[0331]

[0367] 27. The method according to any one of paragraphs 19 to 26, wherein a set of critical components is disabled based on the determination that the charge state falls below a second predetermined threshold.

[0332]

[0368] 28. The method according to any one of paragraphs 19 to 27, wherein a set of non-essential components and a set of essential components are activated based on the determination that the charge state exceeds a first predetermined threshold.

[0333]

[0369] 29. The method described in any one of items 19 to 28, wherein the charge state is based on the battery voltage.

[0334]

[0370] 30. Telematics control unit for a vehicle, comprising: a first cellular modem; a second cellular modem; a set of shared modem resources including an antenna; a switch having a first state in which the first modem is coupled to the antenna and a second state in which the second modem is coupled to the antenna; and a controller connected to the switch, wherein the controller is configured to configure the switch to the first state and establish a first connection to a cellular network using the first modem, and to configure the switch to the second state and establish a second connection to a cellular network using the second modem.

[0335]

[0371] 31. The telematics control unit as described in Section 30, wherein the controller determines to configure the switch to a second state based on the geographical location of the telematics control unit associated with a coverage map associated with a cellular network.

[0336]

[0372] 32. The telematics control unit according to paragraph 30 or 31, wherein the controller determines to configure the switch from a first state to a second state when the signal strength of the first modem falls below a first predetermined threshold.

[0337]

[0373] 33. A telematics control unit according to any one of paragraphs 30 to 32, wherein the controller is further configured to configure the switch from a second state to a first state and to establish a third connection with a cellular network using a first modem.

[0338]

[0374] 34. The telematics control unit according to paragraph 33, wherein the controller determines to configure the switch from a second state to a first state when the signal strength of the second modem exceeds a second predetermined threshold.

[0339]

[0375] 35. A telematics control unit according to any one of paragraphs 30 to 34, wherein the set of shared modem resources further includes at least a second antenna available by a first modem located inside the telematics control unit.

[0340]

[0376] 36. The telematics control unit according to any one of paragraphs 30 to 35, wherein the switch is a first switch, and the set of shared modem resources further includes subscriber identification modules (SIMs), and the telematics control unit further comprises a second switch having a first state in which the first modem is coupled to a SIM and a second state in which a second modem is coupled to a SIM, the first state of the first switch being associated with the first state of the second switch, and the second state of the first switch being associated with the second state of the second switch.

[0341]

[0377] 37. A telematics control unit as described in any one of paragraphs 30 to 36, wherein the second cellular modem implements Category M of the Long-Term Evolution (LTE) standard, and the controller determines to configure the switch from a first state to a second state when the charge state associated with the power supply falls below a predetermined threshold.

[0342]

[0378] 38. A telematics control unit as described in any one of paragraphs 30 to 37, wherein the first cellular modem implements Category 1 of the LTE standard.

[0343]

[0379] 39. A telematics control unit according to any one of sections 30 to 38, wherein the controller is further configured to configure the switch from a second state to a first state in response to instructions received from a cellular network using a second cellular modem.

[0344]

[0380] 40. A telematics control unit for a vehicle, comprising a cellular modem, a switch that electrically communicates with the cellular modem, an extension interface that enables communication with the cellular modem via the switch when the switch is in a first state, and a processor that communicates with the cellular modem via the switch when the switch is in a second state, wherein the processor configures the switch to be in the first state based on a decision to perform processing in a high-power domain.

[0345]

[0381] A telematics control unit configured to set a switch to a second state based on the decision to perform processing in a low-power domain associated with a processor.

[0346]

[0382] 41. The telematics control unit as described in Section 40, wherein the processor is further configured to provide data associated with a cellular modem via an expansion interface when the switch is configured from a second state to a first state.

[0347]

[0383] 42. The telematics control unit according to any one of paragraphs 40 to 41, wherein the processor is further configured to receive data from the driver interface via an extension interface when the switch is configured from a first state to a second state.

[0348]

[0384] 43. The telematics control unit according to any one of the claims 40 to 42, wherein the telematics control unit further comprises a power supply, and the processor is configured to switch between a first state and a second state, at least in part, based on the charge state of the power supply.

[0349]

[0385] 44. A telematics control unit as described in Section 43, wherein the processor operates at a voltage below the power supply voltage range.

[0350]

[0386] 45. A telematics control unit as described in any one of sections 40 to 44, wherein the switch is a Universal Serial Bus (USB) switch and the expansion interface allows access to the USB switch via the driver interface.

[0351]

[0387] 46. ​​A telematics control unit according to any one of paragraphs 40 to 46, wherein a high-power domain is associated with a processor of the driver interface, and an extension interface enables communication between the processor of the driver interface and a cellular modem for processing in the high-power domain.

[0352]

[0388] 47. The telematics control unit according to any one of paragraphs 40 to 46, wherein the cellular modem is a first cellular modem, and the telematics control unit further comprises a second cellular modem that communicates electrically with a processor, and a set of shared modem resources associated with the first cellular modem and the second cellular modem.

[0353]

[0389] 48. The telematics control unit as described in Section 47, wherein the processor configures a set of shared modem resources for use by a first cellular modem for processing in a high-power domain, and the processor configures a set of shared modem resources for use by a second cellular modem for processing in a low-power domain.

[0354]

[0390] 49. A method for managing high-power and low-power states of a telematics control unit, comprising the steps of: processing data received from a vehicle platform using a first cellular modem using a low-power domain of a first processor of the telematics control unit; determining, based on the received data, to transition to a high-power state; boosting the high-power domain of a second processor of the telematics control unit based on the decision to transition to a high-power state; and providing at least a portion of the received data to the second processor for processing in response to the receipt of instructions from the high-power domain.

[0355]

[0391] 50. The method according to paragraph 49, further comprising the step of configuring a set of shared modem resources of a telematics control unit for use by a second cellular modem, based on a decision to transition to a high-power state, wherein the second processor of the telematics control unit communicates with the second cellular modem.

[0356]

[0392] 51. The method according to paragraph 49 or 50, further comprising the step of putting the first processor of the telematics control unit into sleep mode in response to receiving instructions from a high-power domain.

[0357]

[0393] 52. The method according to paragraph 51, further comprising the steps of receiving an instruction that processing in a high-power domain is complete, and in response to the instruction that processing in a high-power domain is complete, invoking a first processor of a telematics control unit.

[0358]

[0394] 53. The method according to any one of paragraphs 49 to 52, wherein the first processor buffers data from a Controller Area Network (CAN) bus and, in response to receiving instructions from a high-power domain, provides at least a portion of the buffered data to the second processor.

[0359]

[0395] 54. The method according to any one of paragraphs 49 to 53, wherein the first processor processes the received data while the high-power domain of the second processor is booting.

[0360]

[0396] 55. The method according to paragraph 54, wherein data received from a vehicle platform is a radio update, and processing the data received while a high-power domain of a second processor is booting includes staging at least a portion of the radio update, the radio update being processed in the high-power domain for application of the update.

[0361]

[0397] 56. The method according to any one of paragraphs 49 to 55, wherein while the high-power domain of the second processor is booting, the first processor provides location instructions obtained from the location determination means.

[0362]

[0398] 57. The method according to any one of paragraphs 49 to 56, wherein a first processor provides instructions for telemetry data to be obtained from a Controller Area Network (CAN) bus.

[0363]

[0399] Although the present invention has been described above with exemplary designs, the present invention can be further modified within the spirit and scope of this disclosure. Accordingly, this application aims to encompass all modifications, uses, or applications of the present invention utilizing the general principles of the present invention. Furthermore, this application aims to encompass any such deviations from this disclosure within the scope of practices that are well known or customary in the art to which the present invention relates.

Claims

1. A vehicle intercept circuit, A first connector that can be connected to the key switch connector of the vehicle, A second connector that can be connected to the key switch harness of the aforementioned vehicle, The system comprises a controller connected to the first connector and the second connector, The aforementioned controller In the first operating mode, a signal is passed from the first connector to the second connector. In the second operating mode, the signal is interrupted, thereby preventing the signal from being transmitted from the first connector to the second connector. It is configured in such a way, The controller is further configured to switch from the first operating mode to the second operating mode after a predetermined inactivity period. The intercept circuit further includes a connection to the controller area network, The predetermined inactivity period is identified based on the connection to the controller area network. Intercept circuit.

2. Switching from the first operating mode to the second operating mode includes generating a timeout alarm. The intercept circuit according to claim 1.

3. The controller is further configured to generate a signal via the second connector, thereby activating the vehicle's functions via the key switch harness. An intercept circuit according to any one of claims 1 to 2.

4. The aforementioned controller The vehicle receives an instruction to operate the aforementioned function, The charging status of the vehicle is evaluated based on a predetermined threshold, The system is further configured to generate the signal for operating the vehicle's function when the vehicle's charge state exceeds a predetermined threshold. The intercept circuit according to claim 3.

5. The intercept circuit according to claim 4, wherein the instruction is received via the vehicle's connection circuit.

6. The intercept circuit further includes a third connector that can be connected to the vehicle's key switch harness. The second connector is a non-critical accessory connector, and the third connector is a critical accessory connector. An intercept circuit according to any one of claims 1 to 5.

7. A signal is provided through the third connector in the second operating mode, thereby disabling the non-essential accessories of the vehicle and maintaining power to the essential accessories of the vehicle. The intercept circuit according to claim 6.

8. The aforementioned controller The charging status of the vehicle is evaluated based on a predetermined threshold, Based on the charging state of the vehicle, the system is further configured to provide a signal via at least one of the second connector or the third connector. The intercept circuit according to claim 6 or 7.

Images