Vehicle communication and monitoring

Abstract

Systems and methods for vehicle communication are provided for providing various connections and functions according to hardware availability, power constraints, and environmental conditions.SOLUTION: The system includes a prime mover, a battery, and a controller, wherein the controller receives an indication of an operating mode and configures the vehicle according to one of a shipping operating mode, an operator connected operating mode, an off-season storage operating mode, a startup assurance operating mode, an over-the-air (OTA) operating mode, and a warehouse operating mode.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] [Background technology]

[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 recreational purposes. Such vehicles may be used on both roads and trails, or on trails only, and may be equipped with warning systems to monitor the recreational vehicles.

[0003] It is with respect to this and other general considerations that the embodiments are described. Also, while relatively specific problems are discussed, it should be understood that the embodiments should not be limited to solving the specific problems identified in the background. Related Applications

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

[0005]

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

[0006] In one aspect, an intercept circuit for a vehicle is provided, the intercept circuit comprising: a first connector connectable to a key switch connector of the vehicle; a second connector connectable to a key switch harness of the vehicle; and a controller connected to the first and second connectors, the controller configured to pass signals from the first connector to the second connector in a first mode of operation and to interrupt the signals, thereby preventing transmission of signals from the first connector to the second connector, in a second mode of operation.

[0007] In another aspect, a vehicle is provided, the vehicle including a frame, a prime mover supported by the frame, a battery supported by the frame, and a controller, the controller configured to receive an instruction of an operating mode, the operating mode being at least one of a shipping operating mode, a driver connected operating mode, an off-season storage operating mode, a guaranteed start operating mode, an over-the-air (OTA) operating mode, and a warehouse operating mode, and to configure the vehicle according to the indicated operating mode.

[0008] In a further aspect, a method for configuring a vehicle based on a state of charge of a battery is provided, the method including the steps of: evaluating the state of charge based on a first predetermined threshold; configuring a connection circuit for the vehicle to periodically activate based on a determination that the state of charge is below the first predetermined threshold; communicating with a vehicle platform when the connection circuit is activated; evaluating the state of charge based on a second predetermined threshold that is below the first predetermined threshold; and disabling the connection circuit for the vehicle based on a determination that the state of charge is below the second predetermined threshold.

[0009] In one aspect, a vehicle telematics control unit is provided. The telematics control unit includes: a set of shared modem resources including a first cellular modem, a second cellular modem, and 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 to establish a first connection with a cellular network using the first modem and to configure the switch to the second state to establish a second connection with the cellular network using the second modem.

[0010] In another aspect, another telematics control unit for a vehicle is provided. The telematics control unit includes a cellular modem, a switch in electrical communication with the cellular modem, an expansion interface that enables communication with the cellular modem through the switch when the switch is in a first state, and a processor that communicates with the cellular modem through the switch when the switch is in a second state. The processor is configured to configure the switch to be in the first state based on a determination to perform processing in a high-power domain and to configure the switch to be in the second state based on a determination to perform processing in a low-power domain associated with the processor.

[0011] In a further aspect, a method for managing high power states and low power states of a telematics control unit is provided, the method including: 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 to transition to a high power state based on the received data, booting a high power domain of a second processor of the telematics control unit based on the determination to transition to the high power state, and providing at least a portion of the received data to the second processor for processing in response to receiving an instruction from the high power domain.

[0012] While multiple embodiments are disclosed, still other embodiments of the presently disclosed subject matter will become apparent to those skilled in the art from the following detailed description, which shows and describes illustrative embodiments of the presently disclosed subject matter. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

[0013]

[0012] The above and other features and advantages of the present disclosure, as well as the manner in which they are achieved, will become more apparent and be better understood by referring to the following description of an embodiment of the present invention in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates an exemplary recreational vehicle according to aspects of the present disclosure. [Figure 2] FIG. 1 illustrates an exemplary recreational vehicle according to aspects of the present disclosure. [Figure 3] FIG. 1 illustrates an exemplary recreational vehicle according to aspects of the present disclosure. [Figure 4] FIG. 1 illustrates an exemplary recreational vehicle according to aspects of the present disclosure. [Figure 5A]5 illustrates an exemplary processing sequence and additional details for each of the embodiments of vehicle 100 shown in FIGS. 1-4. FIG. [Figure 5B] 5 illustrates an exemplary processing sequence and additional details for each of the embodiments of vehicle 100 shown in FIGS. 1-4. FIG. [Figure 5C] 5 illustrates an exemplary processing sequence and additional details for each of the embodiments of vehicle 100 shown in FIGS. 1-4. FIG. [Figure 6] FIG. 1 illustrates an exemplary processing sequence of a vehicle 100 for communicating vehicle health status. [Figure 7] FIG. 1 illustrates an exemplary user interface displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. [Figure 8] FIG. 1 illustrates an exemplary user interface displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. [Figure 9] FIG. 1 illustrates an exemplary user interface displaying exemplary vehicle health status information on an app or website for a personal computing device such as a mobile phone. [Figure 10] 10A-10C provide various graphical representations of tire pressure status information. [Figure 11] FIG. 1 illustrates an exemplary processing sequence of a vehicle 100 for diagnosing a problem. [Figure 12] FIG. 1 illustrates an exemplary user interface for communicating problem diagnosis information. [Figure 13] FIG. 1 illustrates an exemplary user interface for communicating problem diagnosis information. [Figure 14] FIG. 1 illustrates an exemplary user interface for communicating problem diagnosis information. [Figure 15] FIG. 1 illustrates an exemplary processing sequence for a vehicle 100 regarding predictive maintenance. [Figure 16]FIG. 1 illustrates an exemplary user interface for communicating predictive maintenance information. [Figure 17] FIG. 1 illustrates an exemplary user interface for communicating predictive maintenance information. [Figure 18] FIG. 1 illustrates an exemplary user interface for communicating predictive maintenance information. [Figure 19] FIG. 1 illustrates an exemplary user interface for communicating predictive maintenance information. [Figure 20] FIG. 1 illustrates an exemplary processing sequence of a vehicle 100 for remote vehicle positioning. [Figure 21] FIG. 1 illustrates an exemplary user interface for communicating remote vehicle positioning information. [Figure 22] FIG. 1 illustrates an exemplary user interface for communicating remote vehicle positioning information. [Figure 23] FIG. 1 illustrates an exemplary user interface for communicating remote vehicle positioning information. [Figure 24] FIG. 1 illustrates an exemplary user interface for communicating remote vehicle positioning information. [Figure 25] FIG. 1 illustrates an exemplary user interface for communicating remote vehicle positioning information. [Figure 26] FIG. 10 is a diagram showing an exemplary processing sequence of the vehicle 100 regarding vehicle theft warning. [Figure 27] FIG. 1 illustrates an exemplary user interface for communicating vehicle positioning information. [Figure 28] FIG. 1 illustrates an exemplary user interface for communicating vehicle positioning information. [Figure 29] FIG. 1 illustrates an exemplary user interface for communicating vehicle positioning information. [Figure 30] FIG. 1 illustrates an exemplary user interface for communicating vehicle positioning information. [Figure 31] FIG. 1 illustrates an exemplary user interface for communicating vehicle positioning information. [Figure 32] FIG. 1 provides a representation of a vehicle 100 being towed. [Figure 33] FIG. 1 illustrates an overview of power management according to aspects of the present disclosure. [Figure 34] FIG. 1 illustrates an exemplary system in which vehicle connectivity functionality may be used according to aspects of the present disclosure. [Figure 35A] FIG. 1 illustrates an overview of an example method for processing condition information from a vehicle platform for vehicle theft alert according to aspects described herein. [Figure 35B] FIG. 1 illustrates an overview of an example method for aggregating information for vehicle condition processing according to aspects described herein. [Figure 36A] FIG. 1 illustrates an overview of an exemplary method for utilizing available storage space in a vehicle's electronic control unit. [Figure 36B] FIG. 1 shows an overview of an exemplary method for accessing data stored by an electronic control unit of a vehicle. [Figure 37A] FIG. 1 illustrates an overview of an exemplary method for controlling a vehicle state according to the vehicle's state of charge. [Figure 37B] FIG. 10 illustrates an overview of another exemplary method for controlling a vehicle state according to the vehicle's state of charge. [Figure 37C] FIG. 1 illustrates an overview of an exemplary set of vehicle states and associated transitions according to aspects of the present disclosure. [Figure 38] FIG. 1 illustrates an overview of a schematic in which an intercept circuit according to an aspect of the present disclosure may be used. [Figure 39] FIG. 1 illustrates an overview of an exemplary method for controlling a vehicle using an intercept circuit according to aspects of the present disclosure. [Figure 40] FIG. 2 illustrates an overview of exemplary vehicle conditions associated with an intercept circuit. [Figure 41] FIG. 1 illustrates an overview of an exemplary vehicle state and associated transition logic of an intercept circuit. [Figure 42] FIG. 1 shows a schematic overview of an intercept circuit according to an aspect of the present disclosure. [Figure 43]FIG. 1 illustrates an example system in which a driver interface and an add-on telematics control unit operate to provide vehicle connectivity functionality, according to aspects described herein. [Figure 44] FIG. 44 illustrates an exemplary system in which the telematics control unit incorporates the aspects described above with respect to FIG. 43. [Figure 45A] FIG. 1 illustrates an overview of an example method for configuring high and low power connections of a vehicle according to aspects described herein. [Figure 45B] FIG. 1 illustrates an overview of an exemplary method for configuring a high-power or low-power modem of a vehicle. [Figure 46A] FIG. 1 illustrates an overview of an exemplary method for implementing low power processing according to aspects described herein. [Figure 46B] FIG. 1 illustrates an overview of an exemplary method for implementing high power processing according to aspects described herein. [Figure 47A] FIG. 1 illustrates an overview of an example method for handling a warning condition in a low power domain according to aspects of the present disclosure. [Figure 47B] FIG. 1 illustrates an overview of an example method for addressing a warning condition in a high power domain according to aspects of the present disclosure. [Figure 48] FIG. 10 illustrates an exemplary processing sequence of the vehicle 100 for providing post-board reporting functionality. [Figure 49] FIG. 10 illustrates an exemplary user interface for communicating boarding report information. [Figure 50] FIG. 10 illustrates an exemplary user interface for communicating boarding report information. [Figure 51] FIG. 10 illustrates an exemplary user interface for communicating boarding report information. [Figure 52] FIG. 10 illustrates an exemplary user interface for group boarding tracking. [Figure 53] FIG. 10 illustrates an exemplary user interface for group boarding tracking. [Figure 54]FIG. 10 illustrates an exemplary user interface for group boarding tracking. [Figure 55] FIG. 10 illustrates an exemplary user interface for group boarding tracking. [Figure 56] FIG. 10 illustrates an exemplary user interface associated with an SOS alert feature. [Figure 57] FIG. 10 illustrates an exemplary user interface associated with an SOS alert feature. [Figure 58] FIG. 1 illustrates an exemplary user interface associated with personal route planning. [Figure 59] FIG. 1 illustrates an exemplary user interface associated with personal route planning. [Figure 60] FIG. 1 illustrates an exemplary user interface associated with personal route planning. [Figure 61] FIG. 1 illustrates an exemplary user interface associated with personal route planning. DETAILED DESCRIPTION OF THE INVENTION

[0015]

[0054] Corresponding reference characters indicate corresponding parts throughout the several views. While the drawings represent embodiments of the present disclosure, the drawings are not necessarily to scale and certain features may be exaggerated to better illustrate and explain the present disclosure. The examples described herein illustrate embodiments of the present disclosure, and such examples should not be construed as limiting the scope of the present disclosure in any way.

[0016]

[0055] Various embodiments of the present disclosure will now be described in detail with reference to the drawings, in which like reference numerals represent like parts and assemblies throughout the several views. Additionally, any examples described herein are not intended to be limiting and merely describe some of the many possible embodiments.

[0017]

[0056] Referring to FIG. 1 , vehicle 100 is depicted. Vehicle 100 is an exemplary recreational vehicle, particularly a side-by-side off-road vehicle. Additional details regarding an exemplary embodiment of vehicle 100 are disclosed in vehicle 200, as described herein, and may be further 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 entire disclosures of which 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 vehicles 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 entire disclosures of which are expressly incorporated herein by reference.

[0018]

[0057] Recreational vehicle 100 includes a plurality of ground engaging members 102. Exemplary ground engaging members include skis, tracks, wheels, and other suitable devices for supporting vehicle 100 relative to the ground. Recreational vehicle 100 further includes a frame 104 supported by the plurality of ground engaging members 102. In one embodiment, frame 104 includes a casting, a weldment, a tubular component, or a combination thereof. In one embodiment, frame 104 is a rigid frame. In one embodiment, frame 104 has at least two sections that are movable relative to each other.

[0019]

[0058] A driver support is supported by the frame 104. Exemplary driver supports include 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. Exemplary passenger supports include a saddle seat, a bench seat, a bucket seat, and other suitable support members.

[0020]

[0059] A powertrain is supported by frame 104 and illustratively includes a prime mover 112 and a transmission 116. The powertrain provides motive power and transfers the motive power to at least one of ground engaging members 102 to power movement of 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 mover sources. To start prime mover 112, a vehicle starting system 114 is provided. The type of vehicle starting system 114 depends on the type of prime mover 112 used. In one embodiment, prime mover 112 is an internal combustion engine, and vehicle starting system 114 is one of a pull-start system and an electric start system. In one embodiment, prime mover 112 is an electric motor, and vehicle starting system 114 is a switch system that electrically couples one or more batteries to the electric motor. In an embodiment, the vehicle starting system includes a key (or key fob).

[0022]

[0061] Transmission 116 is coupled to prime mover 112. In an embodiment, transmission 116 includes a shiftable transmission and a continuously variable transmission ("CVT"). In one configuration, the CVT is coupled to prime mover 112 and the shiftable transmission is coupled to the CVT. In one embodiment, the shiftable transmission includes a high-forward setting, a low-forward setting, a neutral setting, a park setting, and a reverse setting. Exemplary CVTs are disclosed in U.S. Pat. Nos. 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. Transmission 116 is further coupled to at least one differential (not shown), which is coupled to at least one ground engaging member 102.

[0023]

[0062] Recreational vehicle 100 further includes a plurality of suspension systems 120 coupling ground engaging members 102 to frame 104 . Exemplary suspension systems include U.S. patent application Ser. No. 16 / 013,210, filed June 20, 2018, entitled "VEHICLE HAVING SUSPENSION WITH CONTINUOUS DAMPING CONTROL," U.S. patent application Ser. No. 16 / 529,001, filed August 1, 2019, entitled "ADJUSTABLE VEHICLE SUSPENSION SYSTEM," U.S. patent application Ser. No. 15 / 816,368, filed November 17, 2017, entitled "ADJUSTABLE VEHICLE SUSPENSION SYSTEM," and U.S. patent application Ser. No. 16 / 198,280, filed November 21, 2018, entitled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING," and U.S. patent application Ser. No. 16 / 198,280, filed November 21, 2018, entitled "SYSTEMS AND METHODS OF ADJUSTABLE SUSPENSIONS FOR OFF-ROAD RECREATIONAL No. 63 / 027,833, filed May 20, 2020, with Docket No. PLR-01-29147.01P-US, entitled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING," and U.S. Provisional Patent Application No. 63 / 053,278, filed July 17, 2020, with Docket No. PLR-15-29249.01P-US, entitled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING," the entire disclosures of which are expressly incorporated herein by reference.

[0024]

[0063] Recreational vehicle 100 further includes a braking system 122. In one embodiment, braking system 122 includes anti-lock brakes.

[0025]

[0064] Recreational vehicle 100 further includes a steering system 124. Steering system 124 is coupled to at least one of ground engaging members 102 to direct recreational vehicle 100.

[0026]

[0065] Recreational vehicle 100 further includes a number of sensors 126 that monitor various characteristics of vehicle 100 and a battery 128 that provides power to various components of vehicle 100. Exemplary sensors include, but are not limited to, a global positioning system (GPS) sensor, an accelerometer, a conductive ball and socket, an ambient temperature sensor, an image sensor, a microphone, or a light detection and ranging (LIDAR) sensor, among other examples.

[0027]

[0066] Additionally, recreational vehicle 100 includes a vehicle controller 140 having at least one processor 142 and at least one associated memory 144. Vehicle controller 140 provides electronic control of various components of recreational vehicle 100. Additionally, vehicle controller 140 is operatively coupled to a plurality of sensors 126 that monitor various parameters of recreational vehicle 100 or the environment surrounding vehicle 100. Vehicle controller 140 performs specific operations for one or more subsystems of other vehicle components, such as one or more of the fuel system, air handling system, CVT, shiftable transmission, prime mover 112, suspension 120, and other systems. In certain embodiments, 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-transitory computer-readable storage medium, such as memory 144.

[0028]

[0067] Vehicle controller 140 also interacts with 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 suitable input devices. Exemplary output devices include lights, displays, audio devices, haptic devices, and other suitable output devices. The driver can signal vehicle controller 140 to modify the operation of one or more systems of vehicle 100 through input device 152. Additional aspects of vehicle controller 140 are described below with respect to Figures 5A-5C.

[0029]

[0068] Additionally, vehicle 100 includes a wireless plug-in dongle 170 operably coupled to controller 140. Dongle 170 provides a communications link between vehicle controller 140 and remote storage, illustratively a cloud 180. The dongle can receive information and / or instructions from the cloud for use by vehicle controller 140 and can provide information and / or instructions to remote devices 182 or other vehicles 200 via cloud 180. Additionally, information stored in cloud 180 can be retrieved through a web interface associated with vehicle 100. In an embodiment, dongle 170, also referred to as connection circuitry, is powered by battery 128 of vehicle 100. A processing sequence for controlling drain on battery 128 is provided herein.

[0030]

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

[0031]

[0070] Referring to FIG. 3, a further exemplary embodiment of vehicle 100 is shown. Vehicle 100 of FIG. 3 is the same as vehicle 100 of FIG. 1, except that dongle 170 has been replaced with telematics control unit (“TCU”) 250. Telematics control unit 250 differs from dongle 170 in that telematics control unit 250 can be periodically activated while vehicle 100 is not in operation to communicate with cloud 180, remote devices 182, and / or other vehicles 200. Both TCU 250 and dongle 170 have security features in effect for remote notification of theft alerts when the vehicle is not in operation. In an embodiment, telematics control unit 250, also referred to as connection circuitry, is powered by battery 128 of vehicle 100. A processing sequence for controlling drain on battery 128 is provided herein.

[0032]

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

[0033]

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

[0034]

[0073] 5A-5C, exemplary processing sequences and additional details are shown for each of the embodiments of vehicle 100 shown in FIGS. 1-4. In examples, the aspects of FIG. 5A are utilized in the context of FIG. 1, e.g., using wireless plug-in dongle 170. In some cases, the aspects of FIG. 5B are utilized in the context of FIG. 2, e.g., using wireless plug-in dongle 170 and driver interface 150. In other cases, the aspects of FIG. 5C are utilized in the context of FIG. 3 and / or FIG. 4, e.g., using telematics control unit 250 and / or driver interface 150.

[0035]

[0074] In an embodiment, dongle 170 or TCU 250 includes a location determining means, such as a GPS, for providing an indication of the location of vehicle 100. In an embodiment, a location determining means is provided on vehicle 100 separate from dongle 170 or TCU 250 for providing an indication of the location of vehicle 100.

[0036]

[0075] In an embodiment, vehicle 100 includes a separate communication system in addition to, or instead of, 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 vehicle 100. In an embodiment, the exemplary communication system provides cellular communication devices, RF antennas for direct vehicle 100-to-vehicle 200 communication, satellite communication devices, 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 is described in U.S. Patent Application No. 16 / 234,162, filed December 27, 2018, with Docket No. PLR-15-25635.04P-02-US, entitled "RECREATIONAL VEHICLE INTERACTIVE TELEMETRY, MAPPING AND TRIP PLANNING SYSTEM," and in U.S. Patent Application No. 16 / 234,162, filed December 27, 2018, with Docket No. PLR-09-27870, entitled "VEHICLE TO VEHICLE COMMUNICATIONS DEVICE AND METHODS FOR RECREATIONAL VEHICLES."U.S. Patent Application No. 15 / 262,113, filed September 12, 2016, entitled "COMMUNICATION SYSTEM USING VEHICLE TO VEHICLE RADIO AS AN ALTERNATE COMMUNICATION MEANS," U.S. Patent Application No. 10,764,729, filed December 12, 2018, entitled "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, entitled "METHOD AND SYSTEM FOR FORMING A DISTANCED-BASED GROUP IN A VEHICLE TO VEHICLE COMMUNICATION" U.S. Patent Application Publication No. 20190200173, filed December 12, 2018, entitled "VEHICLE-TO-VEHICLE COMMUNICATION SYSTEM," U.S. Patent Application Publication No. 20190200188, filed December 12, 2018, entitled "RECREATIONAL VEHICLE GROUP MANAGEMENT SYSTEM," U.S. Patent Application No. 16 / 811,865, filed March 6, 2020, Docket No. PLR-15-27455.02P-03-US, entitled "RECREATIONAL VEHICLE GROUP MANAGEMENT SYSTEM," U.S. Patent Application No. 63 / 016,684, filed April 28, 2020, Docket No. PLR-00TC-27721.01P-US, entitled "SYSTEM AND METHOD FOR DYNAMIC ROUTING," and U.S. Patent Application No. No. 16 / 013,210, filed June 20, 2018, with docket number PLR-15-25091.04P-03-US, entitled "DAMPING CONTROL," and U.S. patent application Ser. No. 16 / 013,210, filed June 20, 2018, with docket number PLR-15-25091.04P-03-US, entitled "VEHICLE HAVING ADJUSTABLE SUSPENSION."No. 15 / 816,368, filed November 17, 2017, under the trademark No. 08P-US, the entire disclosure of which is expressly incorporated herein by reference.

[0037]

[0076] Various processing sequences and systems that may be performed by vehicle 100 are further provided and discussed herein with reference to Figures 6-33 and 48-61. For example, such aspects may be implemented using a dongle, a telematics control unit, and / or a driver interface according to aspects described herein, among other examples.

[0038]

[0077] Vehicle Health Status (see Figures 6 to 10)

[0039]

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

[0040]

[0079] 7-10 illustrate exemplary user interfaces displaying exemplary vehicle health status information on an app or website for a personal computing device, such as a mobile phone. FIG. 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, for example, in the context of having target values ​​(or OK / Not OK status) to provide vehicle health status, among other indicators. In examples, notifications can be generated when one or more trigger conditions are met. For example, push notifications can be sent based on vehicle mileage, in accordance with recommended service intervals. Additional notifications may include, but are not limited to, oil change needed, low tire pressure, low battery, and scheduled maintenance. In examples, notifications 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] The vehicle communication systems disclosed or referenced herein can provide vehicle health data to a remote device or the cloud for storage. Exemplary information is provided by one or more of the vehicle systems or sensors carried on the vehicle 100. Exemplary information includes: Ambient temperature Battery voltage fuel level Fuel range Odometer time Front tire pressure (if equipped with TPMS) Rear tire pressure (if equipped with TPMS) When driving VIN - Vehicle Identification Number Miles / hours to next service Software Update Availability VIN-Specific Recalls Days since last use Oil change required Scheduled maintenance reminders with easy follow-up actions to schedule service or read / view instructions on how to self-check Driving history Diagnostic Code Full recall announcement History codes with the ability to clear codes and explain what the code is, such as "misfire - check x, y, z" Based on the last date the fuel was at maximum, a fuel stabilizer or refined oil is recommended if the threshold duration is exceeded. Seasonal reminders, i.e. it's fall - please consider doing x, y, and z with your unit.

[0042]

[0081] In some cases, a data analysis campaign can be defined at the remote computing device to operate on a particular vehicle or set of vehicles. For example, a data analysis campaign can cause specific vehicle data to be collected according to predetermined intervals or in response to a specified event, among other examples (e.g., "Collect oil pressure vs. engine temperature over the first 10 minutes of driving time for all vehicles with stored part number XXX in locations where the ambient temperature is below 10°C for the next two weeks").

[0043]

[0082] As an example, a service department may see multiple reports of a problem, at which point the technical department may desire more specific data and actual cases. Therefore, a dynamic data analysis / collection campaign can be used to identify specific vehicles in the field that have specific conditions, so that in-vehicle telematics collection and analysis can be performed accordingly. Over-the-air (OTA) communications can deliver a data analysis campaign package to selected vehicles in the field, and an in-field data analysis campaign can be launched, deployed, and activated. Telematics data can then be collected and returned (e.g., as shown in FIG. 6 ). Finally, notifications or other information associated with service advisories or OTA updates to resolve the identified problems can be sent to the vehicles and / or associated drivers (e.g., at least some of which may be within the group for which the data analysis campaign aspects described herein were implemented).

[0044]

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

[0045]

[0084] Beyond the health summary, the problem diagnosis processing sequence includes 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 inform the driver of the best course of action. FIG. 11 shows an example processing sequence for vehicle 100 for problem diagnosis. As shown, diagnostic trouble codes (DTCs) can be issued by the vehicle, which can then be obtained (e.g., via a dongle or TCU via a CAN bus) and transmitted to a remote computing device, such as the cloud or the vehicle platform, among other examples. The DTCs are mapped to descriptors and / or recommended actions. Accordingly, notifications (e.g., to an application on the driver's mobile phone) can be generated, and information available to the driver (e.g., via such a mobile application or website) can be updated to reflect the DTCs, descriptors, and / or recommended actions, among other information. The driver can then view such problem diagnosis information and take appropriate action.

[0046]

[0085] Examples include a simple DTC code based on collected data and subsequent analysis and communication steps to the driver to trigger recommended actions or mitigate the problem itself. Exemplary user interfaces for communicating problem diagnosis information are provided in FIGS. 12-14. Additionally, the driver may be provided with a link to service scheduling (see FIG. 14). In embodiments, error codes are stored for later retrieval during a key-off event. For example, error code history and associated problem diagnosis information may be provided, for example, on vehicle 100 and / or via a mobile application / website, among other examples. In other examples, DTC indications and / or other associated information may be provided to a dealer or other service provider (e.g., in response to which live help may be provided to the driver), an automated system for returning on-screen help / tutorials loaded from the internet, or a call center.

[0047]

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

[0048]

[0087] Referring to FIG. 15 , an exemplary processing sequence of vehicle 100 for predictive maintenance is shown. As shown, vehicle data can be collected (e.g., by a dongle or TCU) in response to an event or according to a predetermined interval, and the resulting vehicle data can be transmitted to a remote computing device, such as the cloud or a vehicle platform, among other examples. The vehicle data can be processed according to a set of rules, such as those associated with a particular vehicle model, geographic region, season, and / or usage pattern (e.g., high or low speed, extended use in dusty or adverse conditions, or daily operation in sub-freezing weather) associated with the vehicle. If a rule is met, a notification can be provided to the user for display, for example, using a mobile phone or a website. Thus, the user can view a notification and a description of which rule was met. In examples, recommended actions are provided to the user, such as, for example, contacting a dealer or other service provider, purchasing a replacement part or other product, or advice on how to operate the vehicle in a particular situation. Exemplary user interfaces for communicating predictive maintenance information are provided in FIGS. 16-19 .

[0049]

[0088] The disclosed system can detect vehicle anomalies (failure modes) and recommend early mitigation steps to the occupant based on usage patterns in a particular geographic region with specific riding characteristics, etc. For example, X number of rapid acceleration / deceleration events in a desert sand region will cause disproportionate wear on the belt, detect this condition, and recommend early belt replacement or advise on proper 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 a vehicle display, a remote device, storage for later retrieval on the remote device, and / or sent via known communication methods such as email, text message, push notification, etc. In embodiments, reminders and recommendations are provided. Exemplary reminders or recommendations include: Recommended follow-up by error code Recalls and Service Alerts Countdown to the next service Fuel age recommendations Terrain-specific riding or vehicle care recommendations Seasonal reminders, i.e. it's fall - please consider doing x, y, and z with your unit. Reminders to board based on days since last use Links to video / tutorial content or options to schedule services

[0051]

[0090] With the vehicle reporting telematics to the cloud, the vehicle (shown on the display), app (shown on the remote cell phone) and website garage (web data for the browser to retrieve) would all have vehicle specific maintenance schedules with miles / engine hours remaining to the next service and oil change or perceived belt life remaining indicators, upcoming service notifications with links to do-it-yourself tutorials or schedule service, service bulletins and recall notifications with links to schedule service, and early service recommendations based on DTC codes.

[0052]

[0091] In some cases, an indication of the anomaly may be provided to a vendor or other vehicle service provider. For example, a preferred service provider may be identified from the driver profile or based on the service provider's proximity to the vehicle, the driver's device, and / or an address associated with the driver profile. The indication 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 another example, the driver may receive a suggestion or reminder (e.g., via the vehicle, the driver's device, electronic communications, or a website associated with the vehicle manufacturer) to schedule an appointment with the service provider.

[0053]

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

[0054]

[0093] Additional examples of such aspects are 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 to 25)

[0056]

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

[0057]

[0096] The disclosed system can provide an indication of where the vehicle is currently located or where the vehicle was last detected (based on telematics data and timestamps of available connectivity hardware). In embodiments, based on sensor data (such as an accelerometer or conductive ball-and-socket), a collision warning may be provided when the vehicle is hit, which may include an indication of where the collision warning occurred and / or where the vehicle was last powered on. Additionally, the disclosed system can track the vehicle's location and report when the vehicle exits a geofenced area or otherwise travels a predetermined distance from where a security protocol or parking function was performed. It is also contemplated that a user may have the ability to remotely cause the vehicle to sound an audible noise in response to a user input signaling a security event or otherwise attempting to locate the vehicle. An exemplary sound system is described in U.S. Patent Application No. 16 / 522,957, filed July 26, 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 to 32)

[0059]

[0098] Referring to FIG. 26, an exemplary processing sequence of a vehicle 100 for vehicle theft alert is shown. As shown, user instructions to set a geofence or point / radius are received by a remote computing device, such as the cloud or vehicle platform. The vehicle location is also received (e.g., from a dongle or TCU), and the resulting vehicle location is analyzed with respect to the geofence or point / radius. Thus, if the vehicle is determined to have breached the geofence, a notification is generated so that the user can view its location on a map. Exemplary user interfaces for communicating remote vehicle positioning information are provided in FIGS. 27-31. FIG. 32 provides a representation of a vehicle 100 being towed.

[0060]

[0099] The disclosed system includes setting a parking trigger (manual or automatic) that places the vehicle in a safe mode to watch for collisions and / or movement. This parking trigger may include activating a parking function in the transmission with a pawl, activating a set of brakes to prevent the wheels from turning, or a mode the ECU enters based on a signal from a mobile device, input on the vehicle, key fob, or other representative signal-providing device. This may also include engine disable, power limitation, etc.

[0061]

[0100] Parking Security: Lock the vehicle using the vehicle display, mobile app, or key fob. If the vehicle is hit while locked, or if an unauthorized start or start attempt is detected, the vehicle will send an alert to the user.

[0062]

[0101] Parking security via mobile phone proximity such as a key: When a rider moves away from their motorcycle or off-road vehicle, the app will detect the user and notify them to activate parking security. Similarly, when a rider moves away from their motorcycle or off-road vehicle, the key fob can provide some kind of notification, whether audio, tactile, visual, or other, to remind the user to activate parking security.

[0063]

[0102] Geofence Location Security The geofence feature allows owners to define geographic areas on a map to control vehicle behavior. When the vehicle passes through the geofence boundary, a notification is sent to the mobile phone. In addition, the mobile phone has the opportunity to communicate a message to the occupant via text, visual, or audio via the display or another mobile phone, or even restrict vehicle functionality.

[0064]

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

[0065]

[0104] In examples, at least some of the above-described aspects may also be implemented in cases where collision warning is not enabled. For example, if collision warning is disabled, the vehicle (e.g., dongle or TCU) may wake up as a result of detecting a collision, but no warning may be sent. Thus, if movement is detected (e.g., according to the location determination means) within a predetermined time after a collision is detected, location updates may instead be sent more frequently than if no collision was detected. Such aspects may be implemented in addition to the geofence warning described above. Once movement is no longer determined, the vehicle may return to a state of less frequent location updates. In cases where the vehicle is driving, 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 connected circuitry (such as a telematics control unit) relative to the battery state of charge and / or voltage. The need to manage power draw for powersports vehicles arises from the relatively limited battery capacity of the vehicle compared to other vehicles, and also from the relatively low duty cycle of powersports vehicles (used once every few weeks).

[0068]

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

[0069] Fully Connected: The cell modem in 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 will remain in fully connected mode when the battery voltage or battery SOC remains above a predetermined set point for a predetermined period of time. This is intended to cover use cases where the user has their vehicle plugged into a battery tender or is otherwise powered on by the vehicle.

[0070] Low-power connected: The cell modem is generally off but is woken up periodically (e.g., once a day, twice a day, etc.) to provide heart rate or status updates, and then returned to a default off state to conserve battery energy. The vehicle transitions from fully connected mode to low-power connected mode when the battery voltage or battery SOC reaches a second predetermined threshold a predetermined time after the connection circuitry transitions to low-power mode. The transition from fully connected mode to low-power connected may include a notification to the user's app / web / cloud announcing the change. It is recalled that in embodiments, low-power connected mode may simply be used when the vehicle is off and not connected to the battery tender.

[0071] Disconnected: The connection circuitry is off, thus not draining the battery further. After a predetermined time, a lower, predetermined voltage or SOC charge threshold, the device transitions to Disconnected with notification to the user. The transitions between states (fully connected, low power connected, and disconnected) are not unidirectional; if the battery voltage increases (such as when a user plugs the vehicle into the battery tender), the state (i.e., level of connection) may increase and return.

[0072]

[0108] In an embodiment, if a Battery Tender is not detected by the vehicle or there is insufficient battery power to send an update wirelessly to the vehicle, a notification can be sent to the customer on the app through the cloud informing the customer that there is an update available for the vehicle but there is insufficient battery power and that they should connect a Battery Tender.

[0073]

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

[0074]

[0110] Referring to FIG. 48 , an exemplary processing sequence of vehicle 100 for post-board reporting information is shown. As shown, vehicle 100 can record information associated with the tracked boarding (e.g., on-road and / or off-road), which can then be provided to a remote computing device, such as the cloud or the vehicle platform (e.g., by a dongle or TCU). The user can then view the recorded boarding information in real time or upon completion of the boarding, for example, via a mobile application or website (e.g., as shown in FIGS. 49 and 50 ). For example, once the vehicle is started and boarded, a cloud connection can display a live version of the boarding as it occurs. In examples, photos taken during the 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 photos, or, as 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 ride and present options for pausing the ride record, saving the current ride, and / or starting a new ride. In some cases, an on-vehicle ride summary may be generated, or, as another example, a distance meter may be presented. Accordingly, on-vehicle and cloud-generated ride reports may include ride markers for photos, stops, and / or vehicle-reported events such as stops and jumps, among other examples. An example on-vehicle display is shown in FIG. 51.

[0076]

[0112] The recorded trip may be shared with the community and / or used to generate a post-trip report, which may in some instances have a 3D flyover representation. Furthermore, such aspects may be applicable even in cases where the vehicle does not have an IVI. As another example, the trip may be viewed from the Trip / Location tab in addition to being viewed directly from the map. In some instances, the trip may have a layout that includes a 3D trajectory (e.g., which may be automatically loaded and / or played when the page loads). Similarly, a map of the trip may be viewed by clicking the map segment of the 3D Trajectory / Map toggle.

[0077]

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

[0078]

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

[0079]

[0115] Sending the trip plan to the vehicle

[0080]

[0116] In examples, a trip plan is communicated to a vehicle, e.g., via the cloud or a vehicle platform. As one example, the trip plan can be associated with a vehicle platform profile, so that the trip plan can be synchronized with the vehicle accordingly (e.g., as a result of a similar association with the vehicle platform profile). In other examples, the trip plan may be communicated more directly to the vehicle, e.g., via Bluetooth tethering (Bluetooth is a registered trademark) to a user's mobile device. In some examples, the trip plan may be communicated to multiple vehicles associated with a predetermined boarding group, such as two or more vehicles to facilitate group boarding. The trip plan may be created using a mobile application or via a website, among other examples. The trip plan may be presented on the vehicle's display, so that the driver can view turn instructions along the planned route. For example, a master trip plan may include a point-to-point trajectory along the desired route. As a result, the route is presented on the vehicle's display as a trajectory on a map. The driver may also obtain navigation guidance (e.g., distance and bearing) to a single waypoint destination. Although examples are described with respect to trip planning, it will be appreciated that similar techniques may be used for routes, boarding, and waypoints, among other examples.

[0081]

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

[0082]

[0118] The disclosed system may provide the ability to send an SOS alert to a boarding group, a specific device associated with a predetermined emergency contact (e.g., one or more people located near a group boarding point or return point), and / or emergency services, possibly up to and including Helicopter Life Flight. The SOS alert may be triggered manually or automatically by vehicle sensors. For example, the vehicle may detect that it has rolled over, fallen over, or experienced a thermal event. As another example, a user input may be received to generate an SOS alert.

[0083]

[0119] The alert may be sent to members of the same group as the vehicle needing assistance, to vehicles within a given proximity of the vehicle needing assistance, or to other identified devices that are not members of the boarding group, such as contacts or friends. For example, the alert 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 examples, a help alert message may be pre-entered and stored on the vehicle platform. Instructions to send the help alert message can be received from the vehicle, causing the vehicle platform to send the help alert message in response. In some cases, the instructions include a recipient, or as another example, the intended recipient is also pre-stored in association with the help alert message. In some cases, an acknowledgement can be provided to the vehicle indicating successful transmission of the help alert message.

[0085]

[0121] Exemplary user interfaces for communicating vehicle location information and assistance alerts are provided in Figures 56 and 57. While exemplary SOS alerts are described, it will be appreciated that similar functionality may be provided using any of a variety of other techniques, such as, for example, through integration with third-party services or devices. Additionally, while examples are described in the context of alerts or messages, it will be appreciated that SOS alerts may be enabled using similar techniques using voice and / or video communications.

[0086]

[0122] Personal Route Planning (see Figures 58 to 61)

[0087]

[0123] Community content can be leveraged to alert passengers of nearby recommended rides based on 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. The community shared rides and / or other suggested rides may be displayed on the home screen in the vehicle or on a map on the mobile device, allowing the passenger to browse nearby routes, select the route they wish to ride / drive, and the display or mobile device then creates the route. Possible categories of rides for recommendations include: Nearby boarding Where the vehicle has been driven in the past Community Boarding Personal Preferences / Ratings High community rating Preferences set in the app or in the vehicle Ride Type - Possible categories include Rock Crawling, Mudding, Dune, Desert, Mountain, and Trail. Road Type - Curvy / Turbid, Scenic, Long Route, Shortest Route, Speed ​​Based, Fuel Efficiency Based, Least Turns, Road Type (Gravel, Paved, etc.)

[0088]

[0124] Exemplary user interfaces for communicating available boarding and boarding type selections are provided in FIGS.

[0089]

[0125] Remote vehicle lock

[0090]

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

[0091]

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

[0092]

[0128] 34 illustrates an example system 500 that can employ vehicle connectivity functionality according to aspects of the present disclosure. As illustrated, system 500 includes 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 examples, vehicle 502, vehicle platform 504, and / or driver device 506 communicate over network 508, which may include a local area network, a peer-to-peer network, the Internet, or any of a variety of other networks. In examples, communication between vehicle 502, vehicle platform 504, and / or driver device 506 may occur using packets, via an application programming interface (API), and / or using any of a variety of electronic communications (e.g., as short message service (SMS) messages or email messages), among other examples, or any combination thereof. For example, the connection circuitry 512 may have an associated phone number so that the vehicle platform 504 and / or driver device 506 can send SMS messages to the vehicle 502 or vice versa.

[0093]

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

[0094]

[0130] The connectivity circuitry 512 may receive commands for remote vehicle control over the network 508 (e.g., from the vehicle platform 504 and / or the driver device 506), so that the connectivity circuitry 512 can process such commands or relay commands over the high-speed connection 538 and / or the low-speed connection 540. For example, the connectivity circuitry 512 may issue CAN commands to lock or unlock the vehicle 502, sound the horn of the vehicle 502, and / or turn on or off the lights of the vehicle 502, among other examples. In some cases, the connectivity circuitry 512 may queue commands so that one or more commands are processed after the vehicle enters a given operational mode.

[0095]

[0131] In some examples, the driver interface 510 and the connectivity circuitry 512 can use the low-speed connection 540 for low-speed functions and / or controller reprogramming, including controlling and / or obtaining vehicle control system information (e.g., engine speed, coolant temperature, and / or other vehicle health data), among other examples. For example, the connectivity circuitry 512 can obtain diagnostic fault codes associated with components of the vehicle 502 via the low-speed connection 540. In examples, the diagnostic fault codes may be obtained synchronously and / or asynchronously. For example, the connectivity circuitry 512 can determine the number of components of the vehicle 502 that are accessible via the low-speed connection 540. Accordingly, the connectivity circuitry 512 can request an associated diagnostic fault code for each identified component, which can be provided to the vehicle platform 504 in accordance with aspects described herein (e.g., the problem diagnosis aspects described above with respect to FIGS. 11-14 and Appendix A). In a further example, connection circuitry 512 can monitor changes (e.g., new active, historical, or deleted diagnostic fault codes) via low-speed connection 540 and, accordingly, provide instructions to vehicle platform 504. In some cases, connection circuitry 512 can receive instructions (e.g., via network 508) to clear active and / or historical fault codes and, consequently, connection circuitry 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 obtaining live traffic data, streaming music, obtaining album artwork, and / or other cloud communications. For example, the connectivity circuitry 512 can act as a modem or gateway for the driver interface 510, such that the connectivity circuitry 512's connection to the network 508 is shared with the driver interface 510 via the high-speed connection 538. In an example, the driver interface 510 can be configured with a passcode, for example, to restrict certain functions of the driver interface 510. Thus, the connectivity circuitry 512 can obtain the driver interface 510's passcode, which can then be stored by the connectivity circuitry 512 and / or provided to the vehicle platform 504 (e.g., the vehicle platform can associate the passcode with a driver profile). Thus, the connectivity circuitry 512 can synchronize the driver interface 510's passcode with the vehicle platform 504.

[0097]

[0133] For example, the driver interface 510 can access the network 508 for map functions (e.g., to look up addresses, provide turn directions, or access traffic data) or to synchronize boarding or trajectory information, among other examples. In other cases, the high-speed connection 538 may be used for low-speed functions, for example, if the driver device 506 can act as a bridge or repeater to enable access of a low-speed connection via the high-speed connection 538. The connection circuitry 512 can provide an indication of wireless network information (e.g., modem transceiver status, type of service, 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 circuitry 512 may include a location determination means, such as a GPS, such that location information of the vehicle 502 may similarly be provided to other components of the vehicle 502 via the high-speed connection 538 and / or the low-speed connection 540. In an example, the frequency at which the location of the vehicle 502 is determined and / or provided (e.g., to the vehicle platform 504 and / or the 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 capabilities of the vehicle 502 and / or the vehicle platform 504. For example, more frequent location updates (referred to herein as “GPS redundancy mode”) may be used in instances where the location of the vehicle 502 is being monitored (e.g., according to remote vehicle locator aspects described herein) or shared with other drivers, or when a theft alert is being generated, among other examples. Additionally, the connection circuitry 512 can maintain a set of geofences associated with the vehicle 502, where it can provide (e.g., to the vehicle platform 504) an indication of whether a given geofence is activated, whether the vehicle 502 has entered the geofence, and whether the vehicle 502 has exited the geofence, among other examples.

[0099]

[0135] While system 500 is shown as including a high-speed connection 538 and a low-speed connection 540 between driver interface 510 and connection circuitry 512, it will be appreciated that various alternative or additional components may communicate using similar high-speed and / or low-speed connections. Additionally, connection circuitry 512 may monitor utilization of high-speed connection 538 and / or low-speed connection 540 such that connection circuitry may accordingly throttle or otherwise reduce utilization of the connection circuitry and / or utilization of other components of vehicle 502 if utilization is determined to exceed a predetermined threshold. The predetermined threshold may be configurable by vehicle platform 504.

[0100]

[0136] Vehicle 502 is further shown as including an electronic control unit (ECU) 514 that includes a data store 524. The ECU as provided as an example component of vehicle 502, and any of the various ECUs, may include a data store similar to data store 524. For example, while ECU 514 is shown as a separate component of vehicle 502, it will be appreciated that aspects described herein with respect to ECU 514 may be similarly applicable to driver interface 510 or connecting circuitry 512, among other examples. For example, driver interface 510 may include a data store for storing maps, streaming media, vehicle- and / or driver-provided media, among other examples.

[0101]

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

[0102]

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

[0103]

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

[0104]

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

[0105]

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

[0106]

[0142] For example, storage manager 520 can receive an indication of data to be stored and, in response to receiving the indication, can determine whether there is available space in data store 524. As used herein, available space need not be unused space but 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 data store 524 available for storing additional data. For example, cached data in data store 524 may be removed, or map data in data store 524 may be compressed (e.g., based on a determination that vehicle 502 is not in proximity to a geographic 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, storage manager 520 can cause the data to be stored by data store 524.

[0107]

[0143] As another example, data store 524 may include a rolling buffer in which a predetermined amount of data is stored (e.g., having a predetermined size or associated with a predetermined amount of time). Thus, the rolling buffer may be determined to have available storage so that, for example, the oldest data may be overwritten or otherwise deleted and replaced with more recent data. As a further example, data may be stored using a variable amount of granularity so that, in instances where available storage space falls below a predetermined threshold, redundant or highly redundant information is omitted (e.g., from new data or already stored data).

[0108]

[0144] However, if there is no space available in data store 524, the data may be stored elsewhere. For example, connectivity circuit 512 may prefer to store the data in data store 524, but may use a data store (not shown) in connectivity circuit 512 if storage is not available in data store 524. In other examples, the data may not be stored. For example, connectivity circuit 512 may obtain vehicle control system information if storage is available and store the vehicle control system information as diagnostic information in data store 524. If storage is not available, none or only some of such diagnostic information may be available.

[0109]

[0145] As another example, a driver profile may be obtained (e.g., from the vehicle platform 504 or the driver device 506) and stored according to aspects described herein. Accordingly, at least a portion of the driver profile may be purged as needed to make additional space available. For example, at least a portion of the driver profile may be replaced with a reference to remotely stored data. In instances where the driver profile is not in use (e.g., another driver profile is being used), the driver profile may be deleted so that the driver profile may be re-downloaded at a later point in time as needed.

[0110]

[0146] While system 500 is described in an example where storage manager 520 is part of vehicle controller 516, it will be appreciated that similar aspects may additionally or alternatively be implemented by any of various other components of vehicle 502. For example, connection circuitry 512 may implement such aspects to utilize available storage of driver interface 510. Additionally, while examples herein are described with respect to a single data store, any number of data stores may be used, and the data store in which to store data may be selected according to any of a variety of criteria (e.g., based on available space, latency, and / or usage patterns).

[0111]

[0147] Vehicle controller 516 is shown as further comprising a theft detection engine 518. In examples, the theft detection engine 518 evaluates any of a variety of information to determine whether a theft of vehicle 502 has occurred. For example, the theft detection engine 518 may process data from one or more sensors of vehicle 502 (e.g., sensors 126 described above with respect to FIGS. 1-4 ), data associated with driver device 506 (e.g., the proximity of driver device 506 to vehicle 502 or whether the operator of driver device 506 is authorized to use or tow vehicle 502), and / or data associated with vehicle platform 504. In some instances, the theft detection engine 518 may determine whether driver device 506 is connected to vehicle 502 and / or signal strength associated with the connection (e.g., communication controller 534 and connection circuitry 512 may be directly or indirectly connected). As another example, the theft detection engine 518 may provide information to the vehicle platform 504 (e.g., via the connecting circuitry 512) and, in response, may receive condition information to configure the sensitivity of the theft detection engine 518 or suppress theft alerts that would otherwise be false positives. Such aspects are described in more detail below 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 vehicle break-in, vehicle component theft (e.g., removal of connecting circuitry 512), an instance of vehicle tampering (e.g., wheel removal, keying for repair, someone sitting in the vehicle seat), an accident, or a fire. For example, the above-described embodiment may be similar to that shown in FIG. 26, in which the location of the vehicle is analyzed with respect to a geofence to determine if the vehicle has breached the geofence, so that a notification can be generated and provided to the driver device accordingly.

[0113]

[0149] For example, if the theft detection engine 518 identifies a condition, alerts are disabled, vehicle location monitoring is enabled, and the vehicle 502 is located within a geofence, an updated location of the vehicle 502 can be provided to the vehicle platform 504. In instances where the theft detection engine 518 identifies a condition, alerts are enabled, vehicle location monitoring is enabled, and the vehicle 502 is located outside the geofence, an alert can be generated as described herein, an updated location can be provided to the vehicle platform 504, and the location of the vehicle 502 can be updated in accordance with the GPS redundancy mode described above. Finally, while in GPS redundancy mode, if it is determined that the location of the vehicle 502 is within a geofence and / or alerts are disabled, location updates can revert to normal (e.g., rather than GPS redundancy mode). It will be appreciated that the above conditions and associated actions are provided by way of example, and that additional, fewer, or alternative conditions and / or actions may be used in other examples.

[0114]

[0150] A vehicle state manager 522 of the vehicle controller 516 monitors the state of the vehicle 502 and may thereby provide various modes of operation. Example modes of operation include, but are not limited to, a fully connected mode of operation, a limited connectivity mode of operation, and a no connectivity mode of operation. For example, in a fully connected mode of operation, the vehicle state manager 522 may configure the vehicle 502 to maintain a connection to the network 508 (e.g., via the connection circuitry 512) and communicate with the vehicle platform 504. Thus, the vehicle 502 may be reachable ad hoc by the driver device 506 and / or any of a variety of other remote devices.

[0115]

[0151] In contrast, in a limited connectivity mode of operation, vehicle 502 may be configured to periodically operate its connection with 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 a disconnected mode of operation, vehicle 502 may be configured to remain disconnected (e.g., connection circuitry 512 may be disabled), and one or more other components of vehicle 502 may be similarly disabled.

[0116]

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

[0117]

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

[0118]

[0154] Transitions may also occur based on any of a variety of other events or conditions. For example, vehicle 502 may transition to a different operational state in response to an instruction received from vehicle platform 504. As another example, a condition identified by the theft detection engine 518 may configure vehicle 502 from a no-connectivity mode of operation to a limited-connectivity mode of operation or a fully-connected mode of operation, thereby enabling communication with vehicle platform 504 and / or driver device 506. When vehicle 502 transitions between operational modes, a notification may be presented to the driver of vehicle 502 (e.g., via driver interface 510 and / or driver device 5060). In such cases, vehicle 502 may cease connectivity if a subsequent condition is not determined within a predetermined time. As another example, connectivity may be re-established after a predetermined time in the limited-connectivity or no-connectivity state, such that the sensitivity of the theft detection engine 518 may be periodically reconfigured by vehicle platform 504 or other condition information may be received, among other examples.

[0119]

[0155] Thus, vehicle state manager 522 can configure vehicle 502 to balance functionality and state of charge. For example, vehicle 502 may have a minimum threshold below which a prime mover (e.g., prime mover 112 of FIGS. 1-4 ) becomes inoperable (e.g., the battery cannot have enough current to crank the engine or the electric motor to generate sufficient torque). Such an operating mode can conserve the battery's state of charge, resulting in vehicle 502 not reaching the threshold or reaching a lower speed due to the threshold. Such transition points may be vehicle-specific based on battery capacity and / or alternator capabilities, among other examples. The above operating modes and associated functionality are provided by way of example, and it will be appreciated that in other examples, any of a variety of additional and / or alternative functionality may be associated with such operating modes. As a further example, conservation need not be limited to state of charge; various alternative or additional resources may be conserved in accordance with aspects described herein. For example, a fully connected mode of operation, a limited connection mode of operation, and a no connection mode of operation may be used according to the signal strength of the connection circuit 512 .

[0120]

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

[0121]

[0157] An over-the-air (OTA) mode of operation 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 connectivity circuitry 512, the electronic control unit 514, or the vehicle controller 516). As another example, the OTA mode of operation can be used to repair software of the vehicle 502, for example, when the vehicle controller 516 experiences a software issue. In examples, software updates to the components of the vehicle 502 can be made using a cellular communication device or a Wi-Fi connection (e.g., as may be provided by the connectivity circuitry) or via a wired connection (e.g., via a CAN bus connection, a serial connection, or an Ethernet connection). Furthermore, updates to some components (e.g., to the IVI or driver interface) may be made via a high-speed connection, while updates to other components (e.g., to the engine control module or the vehicle control module) may be made via a slower connection. The connection circuitry 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 indicate that only important updates shall be installed automatically, or the update 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 mode of operation may, for example, configure the vehicle 502 to operate in a reduced functionality state that allows the vehicle 502 to start and operate. The speed and / or energy output of the prime mover may be limited (e.g., below a predetermined RPM threshold or a predetermined torque threshold). In the warehouse mode of operation, accessories (e.g., IVI or media playback associated therewith) may be disabled. As another example, one or more lights on the vehicle 502 may be disabled or may operate at reduced brightness.

[0123]

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

[0124]

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

[0125]

[0161] The operational modes of the vehicle 502 may be pre-configured and / or configured by the vehicle platform 504, among other examples. For example, the vehicle platform 504 may add, remove, or update the operational modes of the vehicle 502 based on historical state-of-charge data of the vehicle 502 and / or a set of other vehicles, based on make or model, or based on geographic location, among other information. In some cases, the driver device 506 may be used to configure the operational mode of the vehicle 502 (e.g., via the vehicle platform 504 or based on communication with the vehicle 502). For example, configuring the operational mode may include specifying thresholds or alternative or additional conditions (e.g., related to any of various health data) under which the vehicle state manager 522 can configure the vehicle 502 according to the operational mode. As another example, configuring the operational mode may include specifying the functionality available under the operational mode, such as which components are active or the frequency at which such components are active, among other examples. It will be appreciated that the operational modes need not be mutually exclusive. For example, the vehicle may be in both a driver connected mode and an assured start mode of operation.

[0126]

[0162] As shown, vehicle platform 504 includes a vehicle data aggregation engine 526, a vehicle condition identifier 528, a vehicle state manager 530, and a driver communication manager 532. In an example, vehicle data aggregation engine 526 obtains sensor data from vehicle 502 (e.g., as may be generated by the theft detection engine 518 based on sensors in vehicle 502). As another example, vehicle data aggregation engine 526 obtains state-of-charge data from vehicle 502 (e.g., as may be generated by vehicle state manager 522). Such data may be communicated by vehicle 502 using connection circuitry 512 and stored by any of the various components of vehicle 502, e.g., using the techniques described above with respect to storage manager 520 and data store 524. Vehicle data aggregation engine 526 may obtain and aggregate data from any number of vehicles. For example, vehicle data aggregation engine 526 may categorize the obtained data according to vehicle make or model or based on geographic location, among other examples.

[0127]

[0163] In an example, the vehicle condition identifier 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 identifier 528 can process sensor data from a set of vehicles with similar geographic locations or 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. As another example, a predetermined threshold (e.g., number or percentage of affected vehicles) may be used, and conditions above the predetermined threshold are determined to be group conditions, while conditions below the predetermined threshold are determined to be individual conditions. The processing can incorporate additional data in addition to the aggregated vehicle data, for example, based on weather data, map data (e.g., proximity to geographic and / or man-made features), traffic data, or new data.

[0128]

[0164] The vehicle condition identifier 528 can implement one or more actions based on the identified condition. For example, the vehicle condition identifier 528 can provide instructions to the vehicle 502 (e.g., for processing by the theft detection engine 518) and / or the driver device 506 (e.g., via the driver communications manager 532 to cause the vehicle application 536 to present a notification to the driver accordingly). As one example, the vehicle condition identifier 528 can configure the sensitivity of the theft detection engine 518 to reduce the likelihood of a false positive theft alert. As another example, the vehicle condition identifier 528 can instruct the theft detection engine 518 that a theft alert should be generated.

[0129]

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

[0130]

[0166] In an example, the vehicle condition identifier 528 may process data associated with the driver device 506 when identifying a condition (e.g., as may be obtained by the driver communications manager 532). For example, the geographic location of the driver device 506 may be obtained from the driver device 506. The geographic location may be compared to the geographic location of the vehicle 502 to determine whether the driver device 506 is in proximity to the vehicle 502. If the vehicle 502 is determined to be moving while the driver device 506 is not in proximity, the theft detection engine 518 may generate a theft alert accordingly. In some cases, the vehicle condition identifier 528 may process the geographic location (e.g., of the vehicle 502 and / or the driver device 506) to determine whether the geographic location is associated with a road, highway, or trail. As 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, such as may be the case when the driver of driver 502 designates another driver (and associated driver device, not shown) as an authorized driver. Accordingly, it will be appreciated that any of a variety of information associated with vehicle 502 and / or driver device 506 may be used to identify conditions and generate actions accordingly.

[0131]

[0167] Vehicle platform 504 further includes a vehicle state manager 530 that can manage the operating modes of vehicle 502 (e.g., as described above with respect to vehicle state manager 522). In an example, vehicle state manager 530 can process state-of-charge data from vehicle 502 and / or other vehicles and configure one or more operating modes accordingly. For example, vehicle state manager 530 can modify one or more thresholds for the guaranteed start operating mode according to the make or model of vehicle 502 or based on an analysis of the vehicle's state of charge in relation to an aggregated state of charge (e.g., as may be aggregated by vehicle data aggregation engine 526). For example, a model can be used to determine that the battery of vehicle 502 has aged or is degrading, and as a result, one or more different thresholds can be set to compensate accordingly.

[0132]

[0168] As another example, vehicle state manager 530 may receive an indication from vehicle 502 that vehicle 502 has transitioned from one state to another, and may consequently generate an instruction for presentation to the driver by vehicle application 536 (e.g., via driver communications manager 532). Accordingly, driver communications manager 532 of vehicle platform 504 may communicate with vehicle application 536 of driver device 506 and / or relay communications between vehicle 502 and driver device 506 accordingly.

[0133]

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

[0134]

[0170] Vehicle application 536 may generate notifications (e.g., associated with vehicle state changes and / or theft alerts) and may provide geographic location indications (e.g., based on GPS and / or A-GPS) to vehicle 502 and / or vehicle platform 504. As another example, vehicle application 536 may be used to indicate other drivers and associated driver devices that are authorized drivers of vehicle 502. In some cases, vehicle application 536 may be used by the driver of vehicle 502 to, for example, configure one or more predetermined thresholds, conditions, and / or associated features to configure the operational mode of vehicle 502, among other examples.

[0135]

[0171] 35A shows an overview of an example method 600 for processing condition information from a vehicle platform for vehicle theft alerts according to aspects described herein. In an example, aspects of method 600 may be performed by a vehicle theft detection engine, such as vehicle theft detection engine 518 of vehicle 502 described above with respect to FIG.

[0136]

[0172] Method 600 begins at operation 602, where sensor data is acquired. For example, the sensor data may be acquired from one or more sensors of the vehicle, such as sensors 126 described above with respect to Figures 1-4.

[0137]

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

[0138]

[0174] Flow proceeds to operation 606 where condition information is obtained from the vehicle platform. In examples, the condition information may include an indication of a group or individual condition that has been identified, a configuration of the sensitivity of a vehicle theft detection engine, and / or an indication of an action (e.g., as may be generated by a vehicle condition identifying means, such as vehicle condition identifying means 528 of FIG. 34 ). In examples where proximity information is obtained from the vehicle platform, as discussed above 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 appreciated that any of a variety of condition information may be obtained from the vehicle platform in operation 606.

[0139]

[0175] Flow proceeds to operation 608, where the condition is evaluated. For example, the sensor data may be evaluated against one or more thresholds (e.g., the sensitivity of the sensor data may be configured based on the condition information received in operation 606). In other examples, the evaluation may include evaluating a condition indicated by the vehicle platform in association with the sensor data to determine whether the sensor data indicates the condition or should be ignored as a result of the condition, or whether an alert should be generated in consideration of the condition. In some cases, operation 608 includes evaluating device proximity information, such as the geographic location of the device relative to the geographic location of the vehicle, or determining whether signal strength associated with the device indicates that a driver associated with the device is operating the vehicle. Operation 608 may alternatively or additionally include evaluating the geographic location of the vehicle with respect to map and / or terrain information to determine whether the vehicle is on a road or highway.

[0140]

[0176] Thus, the evaluation in operation 608 may determine, among other examples, that the sensor data indicates vehicle theft or trespassing; that the sensor data is associated with a geographic location, an individual condition, and / or a group condition (which may then be ignored or actioned upon); whether a device (e.g., associated with an owner or authorized driver) is in proximity; and whether the vehicle is on a road or highway. In some cases, the conditions evaluated in operation 608 may be weighted. For example, driver device proximity based on signal strength or received from the vehicle platform may receive a higher ranking, while a determination that the vehicle is on a road or highway may receive a lower ranking depending on GPS positioning accuracy. Thus, additional system inputs may be utilized to further increase the certainty that an alert should not be generated (e.g., as may be the case when the vehicle is being towed, as shown in FIG. 32 ). Other such system inputs include assessing the speed of the vehicle and / or user (to determine if the vehicle is in use), determining if a driver device is connected to the car's driver interface (to determine if the vehicle is in use), and assessing if the vehicle and user's phone are on a track that is a road or highway.

[0141]

[0177] It will be appreciated 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 aspects are described in U.S. Patent Application No. 16 / 668,980, filed October 30, 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 conjunction with or supplemented by the systems and methods of 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 U.S. Patent Application No. 16 / 234,162, entitled "SYSTEMS AND METHODS OF ADJUSTABLE SUSPENSIONS FOR OFF-ROAD RECREATIONAL U.S. patent application Ser. No. 17 / 325,062 entitled "OPERATING MODES USING A BRAKING SYSTEM FOR AN ALL-TERRAIN VEHICLE," U.S. patent application Ser. No. 16 / 401,933 entitled "SYSTEMS AND METHODS FOR OPERATING AN ALL-TERRAIN VEHICLE," U.S. patent application Ser. No. 17 / 235,322 entitled "DIAGNOSTIC SYSTEMS AND METHODS OF A CONTINUOUSLY VARIABLE TRANSMISSION," U.S. patent application Ser. No. 16 / 838,602 entitled "DIAGNOSTIC SYSTEMS AND METHODS OF A CONTINUOUSLY VARIABLE TRANSMISSION," and U.S. patent application Ser. No. 17 / 241,559 entitled "SYSTEM AND METHOD FOR DYNAMIC ROUTING," and "DEVICE AND METHOD FOR SUPERVISING AND MODIFYING VEHICLE." U.S. patent application Ser. No. 15 / 836,223 entitled "A VEHICLE OPERATION" and U.S. patent application Ser. No. 17 / 158 entitled "ADJUSTABLE PERFORMANCE FOR A VEHICLE."539, U.S. Patent Application No. 17 / 175,888 entitled "VEHICLE HAVING ADJUSTABLE COMPRESSION AND REBOUND DAMPING," U.S. Patent Application No. 17 / 100,451 entitled "VEHICLE HAVING SUSPENSION WITH CONTINUOUS DAMPING CONTROL," U.S. Patent Application No. 17 / 176,110 entitled "ADJUSTABLE VEHICLE SUSPENSION SYSTEM," and U.S. Patent Application No. 15 / 816,368 entitled "VEHICLE HAVING ADJUSTABLE SUSPENSION."

[0143]

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

[0144]

[0180] While method 600 is described in the context of a vehicle theft warning, it will be appreciated that similar techniques may be used to provide any of a variety of additional or alternative warnings, including trespass warnings or fire warnings, among other examples. Likewise, it will be appreciated that one or more operations may be omitted in some cases. For example, operation 606 need not be performed in each iteration of method 600; thus, operation 606 may be performed periodically to configure vehicle sensitivity, or may be performed in response to acquired sensor data, such that a determination is made as to whether a group condition is presented when the sensor data indicates a condition at the vehicle. Method 600 ends at operation 612. Furthermore, a vehicle platform need not be used in other examples. For example, the above aspects are performed by the vehicle based on information received from a driver device and / or information received from one or more other vehicles.

[0145]

[0181] 35B illustrates an overview of an example method 650 for aggregating information for vehicle condition processing according to aspects described herein. In an example, aspects of the method 650 may be performed by a vehicle condition identifier of a vehicle platform, such as the vehicle condition identifier 528 of the vehicle platform 504 of FIG.

[0146]

[0182] Method 650 may begin at operation 652, where device location information is obtained. For example, the device information may be received from a vehicle application of a driver device, such as vehicle application 536 of driver device 506. The device location information may include a geographic location of the device. While examples are described herein with respect to geographic locations (e.g., of the device and vehicle), other device location information, such as Wi-Fi or cellular signal strength, among other examples, may be used to determine such geographic location or relative proximity. Operation 652 is depicted using a dashed box to indicate that in some examples, operation 652 may be omitted, with the result that method 650 begins at operation 654. For example, the vehicle may determine the device location information or may obtain the device location information by communicating with the device, such that 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, as may be generated by one or more vibration sensors, temperature sensors, and / or microphones in the vehicle (e.g., vehicle 100 or 200 of FIGS. 1-4 or vehicle 502 of FIG. 34). The information may be received by a vehicle data aggregation engine, such as vehicle data aggregation engine 526.

[0148]

[0184] Flow proceeds to operation 656, where the received vehicle information is processed based on the aggregated data to generate condition information. For example, the aggregated data may have been received by the vehicle data aggregation engine simultaneously or at a prior time. In some cases, the aggregated data may be obtained from a vehicle platform data store. The vehicle information may be processed using one or more models associated with the aggregated data, such as, for example, statistical models and / or machine learning models. In examples, the aggregated data or a 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 was received. For example, aggregated data of make, model, or geographic location may be used to generate a model by which the received vehicle information is processed. 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 geographic and / or man-made features), traffic data, or new data. Furthermore, a set of rules or any of a variety of other processing techniques may be used in addition to or as an alternative to the models described above.

[0149]

[0185] In examples where a statistical model is used, the vehicle information and / or model processing results may be evaluated according to any of a variety of descriptive statistics, such as the mean or standard deviation associated with the vehicle information compared to that of the aggregated data. If the vehicle information differs from the aggregated data with respect to a predetermined threshold or is outside a predetermined range, a condition may be identified. As another example, a trained classifier (e.g., as may have been trained according to the aggregated data) may be used to process the vehicle information and classify conditions associated with the vehicle information.

[0150]

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

[0151]

[0187] Flow proceeds to decision 660, where it is determined whether an action should be generated based on the condition information generated in operation 656. For example, it may be determined that an action should be generated if a descriptive statistic is determined to exceed a predetermined threshold or fall outside a predetermined range. As another example, an action may be generated if a trained classifier identifies the condition. In examples, aspects of decision 660 may be driver configurable or similarly associated with make, model, or geographic location, among other examples.

[0152]

[0188] If it is determined that no action should be generated, the flow branches "NO" and ends at operation 664. On the other hand, if it is determined that an action should be generated, the flow instead branches "YES" to operation 662 and a vehicle theft alert is generated. For example, an instruction may be provided to the driver device, which may then generate a notification for presentation to the driver. In other examples, an authority may be notified, or another vehicle associated with the vehicle from which the vehicle information was received, may receive an indication of the identified condition. Method 650 ends at operation 662.

[0153]

[0189] 36A shows an overview of an example method 700 for utilizing available storage space in a vehicle's electronic control unit. In an example, aspects of the method 700 are performed by a storage manager, such as storage manager 520 described above with respect to FIG.

[0154]

[0190] Method 700 begins at operation 702, where an instruction for data to be stored is received. In examples, the instruction may include the data to be stored, or may include the amount and / or type of data (e.g., driver data or diagnostic data), among other examples. The instruction may be received from another ECU (e.g., connection circuitry 512), or such aspects may be implemented by the control unit itself (e.g., vehicle controller 516).

[0155]

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

[0156]

[0192] At decision 706, it is determined whether the ECU has sufficient free capacity to store the data. Thus, if it is determined that the ECU has sufficient capacity, flow branches "yes" to operation 708, where the data is provided for storage by the ECU. In examples where the instruction received at operation 702 includes data to store, operation 708 may include storing the data in the ECU. As another example, operation 708 may include providing an instruction in response to the instruction received at operation 702, such that the ECU receiving the instruction can transmit the data for storage to the ECU whose storage was identified. Thus, it will be appreciated that any of a variety of techniques may be used to store data in an ECU having free or otherwise available storage.

[0157]

[0193] On the other hand, if it is determined that the ECU does not have sufficient free capacity to store the data, flow proceeds to operation 710, where it is determined whether the ECU has available storage, such as whether data is moved, compressed, purged, or otherwise processed to make at least a portion of the capacity available to store additional data. In examples, the utilization determined in operation 704 may indicate storage utilization according to various types of utilization (e.g., non-purgeable, purgeable, and / or compressible). In other examples, determination 710 may include, among other examples, evaluating the data store or requesting additional information from the ECU associated with the data store.

[0158]

[0194] If it is determined that there is storage available for purging (or other manner of processing according to aspects described herein), flow branches "YES" to operation 712, where storage is freed on the ECU, e.g., by performing one or more of the processing operations described herein. Thus, flow proceeds to operation 708, where the data is stored by the ECU as described above, and flow ends.

[0159]

[0195] On the other hand, if it is determined that there is no storage available for purging, flow branches "NO" to operation 714, where an indication that storage is not available is provided. In some cases, another iteration of method 700 may be performed with another ECU and / or another data store (e.g., in cases where an ECU has multiple data stores), thereby identifying a different location for storing the data. In some cases, as may be the case for diagnostic information, for example, an indication may prevent the data from being stored, as described above. Method 700 ends at operation 714.

[0160]

[0196] 36B shows an overview of an example method 750 for accessing data stored by a vehicle's electronic control unit. In an example, aspects of the method 750 are performed by a storage manager, such as storage manager 520 described above with respect to FIG.

[0161]

[0197] Method 750 begins at operation 752, where a request for data is received. The request may include an identifier, such as a file name, a path, and / or a 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 the ECU attempting to access data stored in accordance with aspects of the present disclosure.

[0162]

[0198] In operation 754, the location of the stored data is determined. For example, there may be a mapping between an identifier in the received request and either local storage or a data store in a remote ECU. As another example, the identifier may be associated with either a placeholder (e.g., containing a reference to remotely stored data) or the data itself (e.g., as may be stored locally).

[0163]

[0199] Flow proceeds to decision 756, where it is determined whether the data is stored locally. In the case where the data is stored locally, flow branches "yes" to operation 758, where the data is accessed from local storage. Although method 750 is shown as accessing data from local storage or a remote ECU's data store, it will be appreciated that in other examples, at least a portion of the data may be cached locally, such that data is accessed from both local storage and a remote data store. Method 750 ends at operation 758.

[0164]

[0200] On the other hand, if it is determined that the data is not stored locally, flow branches "NO" to operation 760, where the data is requested from the ECU. In some cases, operation 760 includes providing an indication of the 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 appreciated that different ECUs may store the data differently. As a further example, the request may be made over a high-speed connection (e.g., high-speed connection 538 of FIG. 34) or a low-speed connection (e.g., low-speed connection 540).

[0165]

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

[0166]

[0202] 37A shows an overview of an example method 800 for controlling a vehicle state according to the vehicle's state of charge. In an example, aspects of the method 800 are performed by a vehicle state manager, such as the vehicle state manager 522 described above with respect to FIG.

[0167]

[0203] Method 800 may begin at operation 802, where an indication of vehicle information is provided, for example, to a vehicle platform (e.g., vehicle platform 504 of FIG. 34). Example vehicle information includes, but is not limited to, a vehicle make, a vehicle model, a vehicle identification number (VIN), and / or any of a variety of vehicle control system information.

[0168]

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

[0169]

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

[0170]

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

[0171]

[0207] Each of the security rules may have an associated operating mode (e.g., a fully connected operating mode, a limited connected operating mode, and a no-connection operating mode, respectively). Any of a variety of rules may be used, and as another example, the rules may evaluate external information. For example, the vehicle's ambient temperature sensor may be used, or if the vehicle is not equipped with an ambient temperature sensor, weather data may be obtained (e.g., via a connected circuit).

[0172]

[0208] 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 mode of operation, flow branches to operation 812, where a connectivity unit (e.g., dongle 170 of FIGS. 1-2, TCU 250 of FIGS. 3-4, or connectivity circuitry 512 of FIG. 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 operational mode may enable a full set of connectivity features of the vehicle to be available, thereby enabling communication with the vehicle platform and / or for 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] If it is instead determined that the vehicle should be configured according to a limited connectivity mode, flow branches to operation 816, where the connectivity unit is configured to wake up periodically, non-critical components are disabled in operation 818, and a reduced data set is communicated in operation 820. Thus, compared to a fully connected mode of operation, a reduced set of functional features is available. Additionally, certain components of the vehicle may be disabled or polled at a reduced rate, thereby conserving the vehicle's state of charge.

[0174]

[0210] Finally, if it is determined that the vehicle should be configured according to a non-connected mode, flow branches to operation 822, where the connectivity unit is disabled, and critical components are disabled at operation 824. In examples, operational modes may be implemented sequentially, such that non-critical components may already be disabled as a result of performing aspects of operation 818 that places the vehicle in the limited-connected mode of operation described above. Thus, in other examples (e.g., when transitioning from a fully connected mode of operation to a non-connected mode of operation), configuring the vehicle according to a non-connected mode of operation may further include disabling non-critical components.

[0175]

[0211] Additionally, method 800 is described as an example in which the vehicle's state of charge is reduced, resulting in reduced vehicle functionality and vehicle components being disabled. It will be appreciated that similar techniques may be utilized in instances in which the vehicle's state of charge is increased (e.g., as a result of changes in battery charge or environmental conditions). In such instances, critical components may be enabled as a result of shifting from a disconnected mode of operation to a limited connected mode of operation, and similarly, non-critical components may be enabled when shifting from a limited connected mode of operation to a fully connected mode of operation. Method 800 ends at operation 814, 820, or 824.

[0176]

[0212] 37B shows an overview of another example method 850 for controlling a vehicle state according to the vehicle's state of charge. In an example, aspects of the method 850 are performed by a vehicle platform, such as vehicle platform 504 of FIG. 34 (e.g., vehicle state manager 530).

[0177]

[0213] Method 850 begins at operation 852, where vehicle information is received. For example, the vehicle information may be received from a vehicle performing aspects of operation 802 described above with respect to FIG. 37A. Example vehicle information includes, but is not limited to, a vehicle make, a vehicle model, a vehicle identification number (VIN), and / or any of a variety of vehicle control system information.

[0178]

[0214] At operation 854, driver interaction information is evaluated. For example, a driver communications manager (e.g., driver communications manager 532 of FIG. 34 ) can maintain interaction information (e.g., in cases where the driver has opted in), such as whether a particular feature has been used by the driver device and / or the frequency with which such feature is used. In some cases, a geographic location (e.g., as may be 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 heading. As another example, an indication may be received from the vehicle application that the driver device has crossed a geofence (e.g., a geographic area surrounding the vehicle). Thus, at operation 854, such interaction information can be evaluated to determine a set of features to be used by the driver or to predict feature use by the driver, among other examples.

[0179]

[0215] Flow proceeds to operation 856, where a set of maintenance rules is generated based on the vehicle information and the interaction information. For example, the maintenance rules (e.g., thresholds, information evaluated by the rules, and / or aspects of the associated operating mode) may be based on information associated with the make, model, or VIN of the vehicle. As another example, the maintenance rules may be adapted according to the driver's use of the associated features. For example, in instances where the driver does not utilize the vehicle's connected features, the vehicle may communicate with the vehicle platform at a reduced frequency compared to instances where the driver utilizes the connected features. As another example, a vehicle component may be determined to be non-critical or may be disabled before other vehicle components based on a determination that features utilized by the driver do not typically utilize the component.

[0180]

[0216] In some cases, it may be determined that the driver is likely to use the vehicle soon, and the vehicle's operating mode may be adapted accordingly. As one example, security rules may cause the vehicle to be configured into a fully connected mode of operation based on such a determination, even though the vehicle may have otherwise been placed into a limited-connected mode of operation. Such security rules may eventually time out if it is determined that the driver has not actually used the vehicle within a predetermined time, or as another example, instructions to return to a limited-connected mode of operation may be received from the driver device.

[0181]

[0217] Flow proceeds to operation 858, where the maintenance rules are provided to the vehicle. In some cases, instructions are provided to update the set of maintenance rules, for example, to reconfigure a maintenance rule, delete a maintenance rule, or add a maintenance rule. In an example, an indication of the vehicle state may be communicated to a driver device, for example, to indicate to the driver that the vehicle has transitioned between states. For example, an instruction may be provided to the driver device, such that the driver device generates a notification that the vehicle has transitioned to a fully connected mode of operation, a limited connected mode of operation, or a disconnected mode of operation. The instruction may include the state of charge 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 that the vehicle has changed to a different operational mode as a result. In some cases, the warning may instruct the driver to plug in, start, or otherwise charge the battery, or may instruct the vehicle to be configured according to a subsequent operational mode if the state of charge decreases to another predetermined threshold. As another example, the warning may indicate that the battery has risen above a predetermined threshold, resulting in additional vehicle functions being enabled. In a further example, an indication may be provided that the vehicle has been placed in an operational mode based on a determination that the driver is likely to use the vehicle (e.g., according to the geographic 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 ends at operation 860 or, in other examples, at operation 858.

[0183]

[0219] 37C shows an overview of an example set 880 of vehicle states and associated transitions according to aspects of the disclosure. As described above, the vehicle may be configured according to a fully connected mode of operation 882, a limited connection mode of operation 884, and a disconnected mode of operation 886. Arrows are shown between states 882, 884, and 886 indicating that the vehicle may transition between states 882, 884, and 886 according to any of a variety of conditions, as described above. For example, when the state of charge decreases, the vehicle may start in state 882, transition to state 884 at a predetermined threshold, and eventually reach state 886 after reaching another predetermined threshold. However, at any point during such progression, the vehicle may return to state 882 as a result of being powered on, as a result of being connected to a charging device, or based on a determination that the driver is in proximity to the vehicle, among other examples.

[0184]

[0220] Operations 888, 890, and 892 are shown to provide example actions that may be taken when the vehicle transitions between states. As shown, instructions may be generated that can be provided to the vehicle platform and / or the driver device. For example, the vehicle platform may take any of a variety of actions in response to the instructions, such as 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] FIG. 38 shows an overview of a diagram 900 in which an intercept circuit according to an embodiment of the present disclosure may be used. As shown, diagram 900 includes a key switch connector 902, a key switch harness 904, and an intercept circuit 906. In examples, intercept circuit 906 may include hardware, software, or any combination thereof. Intercept circuit 906 is connected to the ACCY and RUN connections from key switch connector 902 and also to the ACCY and RUN connections to key switch harness 904. In some instances, intercept circuit 906 passes the ACCY and / or RUN signals from key switch connector 902 to key switch harness 904, thereby enabling expected behavior in a first mode of operation. For example, when driver input is received via key switch connector 902 (thereby providing a signal via the ACCY and / or RUN connections), vehicle accessories may be enabled and the vehicle may be started. However, the intercept circuit 906 can interrupt or otherwise disconnect such signals provided by the key switch connector 902 in the second mode of operation, thereby affecting the operation of the vehicle accordingly.

[0186]

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

[0187]

[0223] The intercept circuit 906 may determine that the vehicle has been operating for a predetermined period of time, at which point the ACCY signal may be disconnected, thereby disabling the vehicle accessories. In some cases, the intercept circuit 906 may evaluate or otherwise obtain data via connection 908 to determine, for example, whether the driver is interacting with the vehicle. If an interaction is determined to have been received, a timer may be reset or the ACCY signal may not be disconnected. As another example, an instruction to turn the vehicle off may be received (e.g., from the vehicle platform or a driver device), resulting in both the ACCY and RUN signals no longer being provided to the key switch harness 904 via the intercept circuit 906. In some cases, the intercept circuit 906 may include or communicate with (e.g., via connection 908) a connection circuit to receive such an instruction.

[0188]

[0224] As another example, an alert may be generated by the intercept circuit 906 prior to such action. For example, an instruction may be provided via the vehicle's driver interface (e.g., driver interface 150 of FIGS. 1-4 or driver interface 510 of FIG. 34). In some cases, an instruction may be provided to a driver device (e.g., via a connecting circuit). The instruction may include a counter after which the ACCY and / or RUN signals may be interrupted. Driver input may be received so that the driver can override such behavior or provide input to accelerate such behavior, among other examples.

[0189]

[0225] While exemplary behavior of the intercept circuit 906 has been described, it will be appreciated that the intercept circuit 906 may implement any of a variety of other operational states, e.g., similar to those described above with respect to the vehicle state manager 522 of FIG. 34 . For example, the intercept circuit 906 may provide a signal to a module associated with a given operational mode. In other examples, a single module may configure the vehicle according to multiple operational modes. In some instances, the key switch connector 902 may include associated connections to enable the driver to similarly select such operational modes using a key switch accordingly.

[0190]

[0226] In addition to disconnecting or interrupting the ACCY and / or RUN signals, the intercept circuit 906 may provide such a signal so that accessories are enabled and / or the vehicle is turned on (e.g., without driver input via the key switch connector 902). For example, an instruction may be received via a connection circuit (e.g., from a driver device or the vehicle platform). As another example, an instruction may be received from the vehicle's ECU via connection 908. The intercept circuit 906 may evaluate the vehicle's state of charge (e.g., via VBATT as shown in diagram 900) to determine whether to provide such a signal or conserve vehicle resources. In instances where it is determined to conserve vehicle resources, an indication of such a decision may be provided in response.

[0191]

[0227] While the intercept circuit 906 is shown as interrupting the ACCY and RUN connections, it will be appreciated 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 a critical accessory and a second accessory connection associated with a non-critical accessory. Thus, a critical accessory may be enabled by providing a signal via the first accessory connection, and a non-critical accessory may be enabled by providing a signal via the second accessory connection. Such accessory connections may be operated independently, such that critical and / or non-critical accessories may be controlled as a result of driver input at the key switch connector 902 according to aspects described herein and / or by the intercept circuit 906. Exemplary critical accessories may include a GPS, vehicle-to-vehicle communication functionality, and at least some functionality provided by the IVI (e.g., maps and vehicle control). Exemplary non-critical accessories may include a pulse bar, off-road lights, an amplifier, and / or media playback functionality of the IVI.

[0192]

[0228] The behavior of the intercept circuitry may be configurable by the driver. For example, the driver may disable or specify a timeout after which the above-described aspects are implemented. Such configurability may be based on a key cycle, such that the configuration is reset between uses of the vehicle or may be a permanent setting, among other examples. Thus, the intercept circuitry 906 may enable the driver to remotely control aspects of the vehicle and / or access vehicle control system information (e.g., via connection 908), for example, using a driver device or via the vehicle platform.

[0193]

[0229] 39 shows an overview of an example method 1000 for controlling a vehicle using an intercept circuit according to aspects of the present disclosure. In an example, aspects of method 1000 are implemented by an intercept circuit, such as intercept circuit 906 of FIG. 38. Method 1000 begins at operation 1002, where a battery saver is enabled. For example, the battery saver may be automatically enabled during operation of the vehicle or may be manually enabled by the driver, among other examples.

[0194]

[0230] In operation 1004, a timer is incremented. As described above, the inactivity timer may be used to control aspects of the vehicle independently or in addition to, among other examples, the vehicle's state of charge. In decision 1006, it may be determined whether the state of charge is below a predetermined threshold. For example, the state of charge may be determined based on the battery voltage detected via the VBATT connection, as described above with respect to intercept circuit 906 of FIG. 38. In another example, vehicle control system information may be obtained via a connection to one or more ECUs, such as connection 908.

[0195]

[0231] If it is determined that the charge is not below the predetermined threshold, flow branches "NO" to decision 1008 to determine whether a timeout has been reached. As mentioned above, the timeout may be driver configurable in some cases. If the timeout has not been reached, flow branches "NO" to decision 1010 to determine whether a vehicle condition has changed. As mentioned above, driver interaction can terminate the timeout countdown, in which case flow branches "YES" to terminate at operation 1012, exiting battery saver mode and entering the appropriate state. Exemplary conditions are described below with respect to Figures 40 and 41. In contrast, if the vehicle condition has not changed, flow branches "NO" back to operation 1004, resulting in the flow looping as described above.

[0196]

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

[0197]

[0233] At decision 1016, it is determined whether input has been received to ignore the alert. Thus, if it is determined that input has been received, flow branches "yes" and terminates at operation 1018, the battery saver mode is disabled, and the vehicle can enter state 2 (e.g., accessory mode, as described in more detail below 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 disconnect one or more signals to the key switch harness, thereby disabling access and / or turning the vehicle off. In operation 1022, the countdown timer is stopped, and in operation 1024, the vehicle enters State 4 (e.g., resulting in the vehicle being turned off, as described in more detail with respect to FIG. 40). 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, in a manner similar to that 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 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] FIG. 42 shows an overview of another diagram 1300 of an intercept circuit according to an embodiment of the present disclosure. Aspects of diagram 1300 are similar to those described above with respect to diagram 900 of FIG. 38. For example, a signal from a key switch 1302 (e.g., via the ON and ACC connections) is received by an ORVCM 1306 (which is similar in aspect to intercept circuit 906). Thus, the ORVCM 1306 can provide a signal to an engine control module (ECM) 1304 or can 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 embodiments described herein. It will be appreciated that the circuits, resistance values, voltages, and other aspects of diagram 900 of FIG. 38 and diagram 1300 of FIG. 42 are provided as examples, and that in other examples, such aspects may differ.

[0202]

[0238] FIG. 43 illustrates an exemplary system 1400 in which a driver interface 1402 and a telematics control unit 1404 operate to provide vehicle connectivity functionality, according to aspects described herein. In an example, aspects of the driver interface 1402 and the telematics control unit 1404 may be similar to the driver interface 510 and the connection circuit 512, respectively, described above with respect to FIG. 34 . As another example, aspects of the driver interface 1402 may be similar to the driver interface 150 described above with respect to FIGS. 1-4 . Similarly, aspects of the telematics control unit 1404 may be similar to the wireless plug-in dongle 170, the telematics control unit 250, the intercept circuit 906, or the ORVCM 1306 described above with respect to FIGS. 1-4 , 38 , and 42 . Accordingly, such aspects are not necessarily described again below.

[0203]

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

[0204]

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

[0205]

[0241] In examples, communications controller 1414 enables communication (e.g., by processor 1406) with another vehicle (not shown), a driver device (e.g., driver device 506 of FIG. 5 ), or a vehicle platform (e.g., vehicle platform 504), among other examples, using one or more wired and / or wireless communications technologies. For example, communications controller 1414 may include Bluetooth and / or Wi-Fi radios that communicate directly with corresponding radios of remote devices. It will be appreciated that communications controller 1414 may implement any of a variety of additional or alternative communications technologies, including, but not limited to, UWB or NFC, among other examples. In some cases, communications 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 or other internet connections.

[0206]

[0242] The telematics control unit 1404 is shown as including a power circuit 1418, a power supply 1420, an expansion interface 1422, a low power modem 1424, a high power modem 1426, shared modem resources 1428, a CAN interface 1430, and a low power domain processor 1432. In the example, the power circuit 1418 provides power to 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, power circuit 1418 can source power from power source 1420 and / or another power source in the vehicle. As one example, power circuit 1418 may source power from the vehicle power source (e.g., from the battery or alternator of vehicle 100 or vehicle 502) when the vehicle is operating, while power circuit 1418 may instead source power from power source 1420 when the vehicle is powered off or the state of charge of the vehicle power source is below a predetermined threshold. It will be appreciated that the power sources need not be mutually exclusive, and thus power circuit 1418 may, in some examples, source power from more than one such power source. As another example, power source 1420 can enable telematics control unit 1404 to operate even when the vehicle power source is disconnected, such as may be the case if the vehicle is stolen.

[0208]

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

[0209]

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

[0210]

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

[0211]

[0247] In a further example, power source 1420 may utilize a different battery chemistry compared to the vehicle power source. For example, the chemistry of power source 1420 may be selected according to the intended environment in which the vehicle may operate, thereby enabling telematics control unit 1404 to operate in extremes that may otherwise be difficult or impossible using the vehicle power source.

[0212]

[0248] Similarly, the telematics control unit 1404 may operate at a lower voltage than the range of the power source 1420, thereby simplifying aspects of the power circuitry 1418. Because the voltage of the power source 1420 may vary according to temperature, state of charge, and / or whether the power source 1420 is charging, among other examples, utilizing a lower voltage can reduce or eliminate the need to step up or down the voltage provided from the power source 1420 to the telematics control unit 1404.

[0213]

[0249] In an example, the state of charge of power source 1420 may be made available to other components of the vehicle. For example, low power domain processor 1432 may provide an indication of the state of charge via CAN interface 1430 so that other functions of the vehicle may be configured accordingly. As another example, the indication may be provided to driver interface 1402 (e.g., via expansion interface 1422) so that the state of charge can be presented to an operator of the vehicle. As a further example, the indication may be provided to the vehicle platform and / or driver devices (e.g., via low power modem 1424 and / or high power modem 1426).

[0214]

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

[0215]

[0251] The functionality provided by low-power domain processor 1432 may be similar to processor 1406. Thus, low-power domain processor 1432 can be used to perform processing as an alternative to processing by processor 1406 (e.g., in high-power domain 1408 and / or real-time domain 1410). In another example, low-power domain processor 1432 can perform processing concurrently and / or cooperatively with processor 1406, for example, to provide access to a vehicle's CAN bus (e.g., via CAN interface 1430). Thus, compared to instances where processor 1406 is powered off, placed in a suspended state, or utilized at a reduced functionality (e.g., with a reduced load or at a lower clock speed), low-power domain processor 1432 can provide similar functionality but consume less power. In an example, processor 1406 and low-power domain processor 1432 can share storage, memory, and / or an event bus that can be used for such cooperative processing.

[0216]

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

[0217]

[0253] The low power domain processor 1432 can have a sleep state such that 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 a wake-up source.

[0218]

[0254] As another example, the low power domain processor 1432 may provide telemetry data to the vehicle platform (e.g., using the low power modem 1424). Accordingly, 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 (e.g., as may be obtained from the processor 1406 using a hardware mailbox and / or from secure storage). In an example, a valid authentication token may be received from the vehicle platform in response, after which 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 may then return to a sleep state until it is time for a subsequent check-in.

[0219]

[0255] It will be appreciated that any of a variety of responses may be received from the vehicle platform, including, but not limited to, an indication that an over-the-air update is available (e.g., in response to the indication, processor 1406 may be woken up to handle the update in accordance with aspects described herein), a request for fault codes or telemetry data (e.g., in response to the request, low power domain processor 1432 may obtain the requested information, e.g., via CAN interface 1430 and / or expansion interface 1422), an instruction to change the state of vehicle theft monitoring (resulting in, e.g., low power domain processor 1432 may configure its theft alerts accordingly), an instruction to update the vehicle's geofence (resulting in, e.g., location determiner 1412 may be used to monitor the vehicle's status with respect to the geofence), and / or an instruction to not take action (which may in some examples include an instruction for the next scheduled check-in).

[0220]

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

[0221]

[0257] In an 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 "tap on the shoulder" function. Thus, the operation of the low power domain processor 1432 may be controlled using, for example, an SMS message containing a command associated with a specified behavior. As 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, the low power domain processor 1432 may exhibit similar startup behavior when CAN traffic is detected (e.g., via the CAN interface 1430), when the vehicle power source is detected to be disconnected (e.g., via the power circuit 1418), when the charge state of the power source 1420 is determined to be below a predetermined threshold, when an interrupt or other indication is received from the processor 1406, when an accelerometer event is detected and a theft alarm is enabled (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).

[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 determine to utilize the high power modem 1426 and / or have the processor 1406 perform processing (e.g., in the high power domain 1408) in accordance with aspects described herein.

[0224]

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

[0225]

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

[0226]

[0262] As one example, an indication of an over-the-air update may be received, resulting in low power domain processor 1432 performing at least a portion of the processing associated with the update (e.g., downloading and staging a set of files associated with the update). Once low power domain processor 1432 completes its processing, processor 1406 may be activated (and, in some examples, low power domain processor 1432 may be powered off), resulting in processor 1406 completing application of the over-the-air update. For example, processor 1406 may generate checksums to verify downloaded data and perform differential processing associated with applying the differential update. In other examples, at least a portion of the processing by processor 1406 may be performed simultaneously with processing by low power domain processor 1432. While example operations are described as being performed by either processor 1406 or low power domain processor 1432, it will be appreciated that any of the various processes may be performed according to similar or different divisions of tasks.

[0227]

[0263] The telematics control unit 1404 is further shown as comprising a low-power modem 1424, a high-power modem 1426, and shared modem resources 1428. In examples, the low-power modem 1424 and the high-power modem 1426 may each have an associated set of modem characteristics, at least some of which may differ. For example, the low-power modem 1424 may implement features associated with reduced power consumption, such as those of Category M defined by the Long Term Evolution (LTE) standard (e.g., power save mode (PSM) and / or enhanced discontinuous reception (eDRX)). Similarly, the high-power modem 1426 may include features that result in relatively higher power consumption, such as those of LTE Category 1. Each of the cellular modems 1424 and 1426 may, in some examples, implement a different cellular technology standard.

[0228]

[0264] Thus, the low-power modem 1424 may consume less power (e.g., on average or at peak load) than the high-power modem 1426, while the high-power modem 1426 may provide a relatively higher data rate than the low-power modem 1424. In an example, the low-power modem 1424 may have increased range and / or radio sensitivity compared to the high-power modem 1426. While example modem characteristics and trade-offs have been described, it will be appreciated that the set of cellular modems may exhibit or be otherwise selected according to any of 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 (e.g., a dual modem low power modem 1424 and a high power modem 1426 in this example), it may be possible to take advantage of the scenario-specific advantages of each modem. For example, the low power modem 1424 may be used to provide a low power connection (e.g., as may be used when the vehicle is off or when the charge state of the power source 1420 is below a predetermined threshold). In contrast, the high power modem 1426 may be used for a high bandwidth connection, such as may be the case when downloading software or map updates for the vehicle's ECU or when downloading content for the driver interface 1402, among other examples. As another example, the high power modem 1426 may be used when power does not need to be conserved, such as when the vehicle is charging or in operation. In some cases, the low-power modem 1424 may implement a cellular technology that has greater range or signal sensitivity than the high-power modem 1426, such that 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, the high-power modem 1426 provides increased range or sensitivity and acts as a fallback when the low-power modem 1424 is unavailable to establish a connection).

[0230]

[0266] The telematics control unit 1404 is further shown as comprising shared modem resources 1428 that are used by both the low power modem 1424 and the high power modem 1426. For example, the shared modem resources 1428 may include an antenna and a subscriber identity module (SIM). Thus, the antenna and SIM may be selectively connected (e.g., using a physical or electrical switch, among other examples) to the low power modem 1424 or the high power modem 1426 depending on which modem is being used. For example, the switch may have a first state and a second state, where in the first state the resources of the shared modem resources 1428 are electrically coupled to the low power modem 1424 and in the second state the resources are electrically coupled to the high power modem 1426. In some cases, the transition of the shared modem resource 1428 from one modem to another may have an associated process (e.g., to deregister one modem from the cellular network, transition the shared modem resource 1428 from the low power modem 1424 to the high power modem 1426 (or vice versa), and re-register the other modem with the cellular network), aspects of which are described below with respect to FIG. 45B.

[0231]

[0267] It will be appreciated that antennas and SIMs are given as examples of shared modem resources 1428, and that in other examples, fewer, additional, or alternative resources and / or resource types may be used. In examples, multiple antennas may be used, such as, for example, one antenna external to telematics control unit 1404 (thus improving range) and another antenna internal to telematics control unit 1404 that serves as a backup antenna. The backup antenna may be used in scenarios where the external antenna is damaged or unavailable, such as may be the case in instances where the external antenna is intentionally disconnected during vehicle theft.

[0232]

[0268] Additionally, while this example is described in a scenario where multiple cellular modems are used, it will be appreciated that similar techniques may be used for any of a variety of other wireless communication radios, including satellite communication, Bluetooth, or Wi-Fi. Additionally, while cellular modems may have overlapping capabilities, each modem need not implement the same set of communication technologies.

[0233]

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

[0234]

[0270] Thus, processor 1406 and low power domain processor 1432 may communicate via expansion interfaces 1416 and 1422, respectively, as described above. In other examples, processor 1406 may be able to utilize elements of telematics control unit 1404 without active involvement by low power domain processor 1432 (e.g., when low power domain processor 1432 is powered off or suspended), while low power domain processor 1432 may be able to utilize elements of driver interface 1402 without active involvement by processor 1406 (e.g., when 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 allowing control of the high-power modem 1426 by the low-power domain processor 1432 and the processor 1406 (e.g., via the expansion interface 1422). For example, a USB switch may be used to allow USB communication with the high-power modem 1426 from one of the processors 1406 or 1432. The low-power modem 1424 may likewise be connected to both the low-power domain processor 1432 and the expansion interface 1422, or, as another example, may utilize a communication protocol (e.g., Universal Asynchronous Receiver Transmitter (UART), Inter-Integrated Circuit (I2C), or Serial Peripheral Interface (SPI)) for communication only with the low-power domain processor 1432.

[0236]

[0272] As another example, the location determiner 1412 may be switchably connected to the processor 1406 and the expansion interface 1416, thereby allowing control of the location determiner 1412 by either the processor 1406 or the low power domain processor 1432 (e.g., via the expansion interface 1416). Thus, the low power domain processor 1432 can utilize the location determiner 1412 even when the processor 1406 is powered off.

[0237]

[0273] It will be appreciated that any of a variety of communication protocols may be used. For example, the expansion interfaces 1416 and 1422 may utilize USB in this example because the high-power modem 1426 and / or the location determining means 1412 may each implement USB and therefore communicate with the driver interface 1402 and the telematics control unit 1404, respectively, with little or no additional processing. In other examples, the expansion interfaces 1416 and 1422 may implement additional or alternative protocols, such as may be the case in which the high-power modem 1426 and / or the location determining means 1412 implement one or more different protocols. In other cases, the expansion interfaces need not implement the same protocol, such that conversion circuitry (e.g., as part of the processor 1406 or 1432, the expansion interface 1416 or 1422, or as a separate circuit) may be used to convert communications over the expansion interface for use by the high-power modem 1426, the location determining means 1412, or any of various other elements.

[0238]

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

[0239]

[0275] Furthermore, the extent of component overlap can be reduced as a result of communications enabled by expansion interfaces 1416 and 1422. As shown, processor 1406 can utilize elements of telematics control unit 1404, so telematics control unit 1404 need not include a processor similar to processor 1406. Similarly, low power domain processor 1432 can utilize location determination means 1412, so telematics control unit 1404 need not include location determination means. Shared modem resources 1428 further reduce component overlap. Additionally, power consumption can also be reduced as a result of shifting processing between processor 1406 and low power domain processor 1432 and dynamic utilization of low power modem 1424 or high power modem 1426 according to aspects described herein.

[0240]

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

[0241]

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

[0242]

[0278] As shown, 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, shared modem resources 1428, a CAN interface 1430, an expansion interface 1422, a location determination means 1412, and a communication controller 1414.

[0243]

[0279] Thus, compared to Figure 43, the telematics control unit 1452 may incorporate the above-described functionality into a single device. Similar to Figure 43, the processor 1406 and the low power domain processor 1432 may be in switchable communication 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 with a set of physical and / or virtual resources allocated to each of the high power domain 1408, the real time domain 1410, and the low power domain, for example, where processing similar to that described above with respect to the low power domain processor 1432 is performed.

[0244]

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

[0245]

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

[0246]

[0282] 45A illustrates an overview of an example method 1500 for configuring high and low power connections of a vehicle according to aspects described herein. In an example, aspects of method 1500 are performed by a telematics control unit, such as telematics control unit 1404 of FIG. 43 or telematics control unit 1452 of FIG. 44.

[0247]

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

[0248]

[0284] Flow proceeds to operation 1504, where the vehicle is configured for a high-power connection. In an example, operation 1504 includes deregistering the 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 resources for use by the 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, a 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 a high-power modem. For example, operation 1506 may include registering with a network using a SIM. Thus, high-power communications may occur using the high-power modem, as may be the case in instances where a vehicle is powered on or charging, among other examples. As one example, a high-power modem may be used to perform activities where use of higher bandwidth or other modem features offered by a high-power modem (e.g., compared to that of a low-power modem) is beneficial.

[0250]

[0286] The flow ultimately proceeds to decision 1508, where it is determined whether conditions exist for changing the modem used. For example, decision 1508 may include determining that the vehicle is powered off, has not been used for a predetermined time, or is not charging. As another example, decision 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 time. In some cases, the evaluation of signal strength may use an average over a period of time because geographic or other features may temporarily affect the detected signal strength. In some cases, decision 1508 may include evaluating the location from the location determination means compared to a coverage map to determine whether the high-power modem is likely to have coverage at the location. While example decisions and associated techniques are described, it will be appreciated that any of a variety of decisions may be implemented in decision 1508 in other examples. Additionally, such determinations may be made within the high power domain or the 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 a condition does not exist as to whether the modem should be changed, the flow branches "No," so that the high-power modem continues to be used until such a determination is made again. Alternatively, if it is determined that a condition does exist as to whether the modem should be changed, the flow branches "Yes," so that the vehicle is configured for a low-power connection. Aspects of operation 1510 may be similar to operation 1504, except that aspects of operation 1510 relate to a low-power modem rather than a high-power modem.

[0252]

[0288] For example, operation 1510 may include deregistering the 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 as a result, operation 1510 may include configuring the shared modem resources for use by the low-power modem. For example, an antenna connection may be transitioned from the high-power modem to the low-power modem. Similarly, a SIM may be transitioned to the low-power modem. Additional examples of such aspects are described below with respect to method 1550 of FIG. 45B. In one example, aspects of operation 1510 are performed by a low-power domain processor, such as 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 a network using a SIM. Thus, low-power communication may occur using a low-power modem, as may be the case in instances where the vehicle has been powered off or has not been used for a predetermined period of time, among other examples. As another example, low-power communication may be used in instances where a low-power modem allows for greater range or increased signal sensitivity compared to a high-power modem.

[0254]

[0290] Flow ultimately proceeds to decision 1514, where it is determined whether conditions exist for changing the modem used. For example, decision 1514 may include determining that the vehicle is powered on, has been resumed in use by the driver, or is charging. As 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 a coverage map indicates that the high-power modem may have coverage. As mentioned above, the evaluation of signal strength may use an average over a period of time. In another example, decision 1514 may include determining that a predetermined amount of time has passed since switching to the low-power modem, such that a decision may be made to retry connecting with the high-power modem. While example decisions and associated techniques are described, it will be appreciated that any of a variety of decisions may be implemented in decision 1514 in other examples. Additionally, such determinations may be made within the high power domain or the 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 a condition does not exist as to whether the modem should be changed, the flow branches "No" so that the low power modem continues to be used until such a determination is made again. However, if it is instead determined that a condition does exist as to whether the modem should be changed, the flow branches "Yes" back to operation 1504 and the vehicle is configured for a high power connection.

[0256]

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

[0257]

[0293] Additionally, method 1500 is provided in an example where a shared modem resource supports 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 in different locations in the vehicle) and / or SIMs, such that both high-power and low-power modems 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 the high-power modem is determined to have no connection, and eventually resume using the high-power modem once it is determined that the high-power modem has re-established a connection.

[0258]

[0294] 45B shows an overview of an example method 1550 for configuring a vehicle's high-power or low-power modem. In an example, aspects of method 1550 are 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 of FIG.

[0259]

[0295] Method 1550 begins at operation 1552, where a first modem is disconnected from the network. In an example, operation 1552 includes powering down the first modem. As another example, the first modem may be used to provide instructions to the network to deregister 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 deregister the modem or may not require such behavior. As another example, the first modem may remain powered on, as may be the case in cases where data is received or buffered during the transition process.

[0260]

[0296] Flow proceeds to operation 1554, where the antenna is configured for use by the second modem. For example, a physical or electronic switch may be used to transition the antenna from the first modem to the second modem. The antenna may be part of a shared modem resource (e.g., shared modem resource 1428 described above with respect to Figures 43 and 44). While exemplary configuration techniques are described, it will be appreciated that any of a variety of other techniques may be used to configure an antenna used by a first modem for subsequent use by a second modem.

[0261]

[0297] In operation 1556, the SIM is configured for use by the second modem. Similar to operation 1554, a physical or electronic switch may be used to transition 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 appreciated that any of a variety of other techniques may be used to configure a SIM used by a first modem for subsequent use by a second modem.

[0262]

[0298] Moving to operation 1558, a connection is established with the network using the second modem. In examples, 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 deregister the first modem as well. In other cases, the first modem and the second modem may not be deregistered or registered, respectively, if the first modem and the second modem can connect to different networks or if the network may allow multiple devices per SIM. Method 1550 ends at operation 1558.

[0263]

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

[0264]

[0300] 46A illustrates an overview of an example method 1600 for performing low-power processing according to aspects described herein. In an example, aspects of the method 1600 are performed by a low-power domain processor, such as the low-power domain processor 1432 described above with respect to FIGS. 43 and 44.

[0265]

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

[0266]

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

[0267]

[0303] Additionally, as noted 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, power source charge state, whether the telematics control unit has a power source (e.g., power source 1420), whether an accelerometer event is detected (as may be the case during vehicle theft or other external activity), whether a driver device is in proximity, and / or in response to user configuration. The behavior of the low-power modem may similarly be configured, for example, to adjust the eDRX interval. It will be appreciated that operation 1604 may be performed using a low-power modem or a high-power modem, such as may be configured according to aspects of methods 1500 and 1550 described above with respect to FIGs. 45A and 45B.

[0268]

[0304] Finally, flow proceeds to operation 1606 where a condition associated with the high power domain is identified. Example conditions include, but are not limited to, the vehicle being powered on, an indication received from the vehicle platform, or identifying the possibility that the vehicle has been stolen, among other examples.

[0269]

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

[0270]

[0306] 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 at operation 1610. In an example, the data is buffered in storage and / or memory so that it can be shared with the high power domain.

[0271]

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

[0272]

[0308] At decision 1614, it is determined whether low-power processing should continue. As described above, the low-power domain processor may continue performing processing simultaneously or in coordination with processing performed in the high-power domain. For example, the low-power processing domain may continue processing accelerometer events and / or location data received from the location determination means, and 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 a portion 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 power consumption associated with such processing. As another example, the high-power domain or the low-power domain may be selected over other domains for reasons of code stability / maturity or computing resource availability, among other examples. Thus, aspects described herein can similarly reduce code complexity and provide stability improvements.

[0273]

[0309] Thus, if it is determined to continue low power processing, flow branches "yes" to operation 1618, where the low power domain processor continues processing in accordance with aspects described herein. In another example, if it is instead determined that low power processing should not continue, flow branches "no" to operation 1616, where processing in the low power domain is terminated, e.g., by suspending or powering down the low power domain processor accordingly. Method 1600 ends at either operation 1616 or operation 1618.

[0274]

[0310] 46B illustrates an overview of an example method 1650 for performing high power processing according to aspects described herein. In an example, aspects of the method 1650 are performed in a high power domain, such as the high power domain 1408 of the processor 1406 described above with respect to FIGS. 43 and 44.

[0275]

[0311] Method 1650 begins at 1652, where a telematics control unit (e.g., telematics control unit 1404 or 1452) is in a high power state. For example, the vehicle may be operating or charging, among other examples. As another example, the vehicle may be in a high power state as a result of aspects of method 1600 described above with respect to FIG. 46A.

[0276]

[0312] Thus, processing is performed in the high power domain at operation 1654. Example processing includes, but is not limited to, processing associated with providing more frequent and / or higher fidelity location updates (compared to the low power domain), media playback, applying over-the-air updates, and / or providing a user interface, among other examples. In some cases, operation 1654 may include performing processing in cooperation with the low power domain processor, as described above, certain processing can be offloaded to the low power domain processor.

[0277]

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

[0278]

[0314] Finally, flow proceeds to operation 1656 where a condition associated with the low power domain is identified. Example conditions include, but are not limited to, the vehicle being powered off, an instruction 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, among other examples.

[0279]

[0315] Accordingly, in operation 1658, instructions to perform low power processing are provided. 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 which high power domain processing is performed simultaneously with low power domain processing. Thus, operation 1658 may be omitted in some examples.

[0280]

[0316] Flow continues 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 at operation 1660. In an example, the data is buffered in storage and / or memory so that it can be shared with the low power domain.

[0281]

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

[0282]

[0318] At decision 1664, it is determined whether high-power processing should continue. As described above, the high-power domain processor may continue performing processing simultaneously 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 communications controller (e.g., communications controller 1414), thereby providing instructions for such processing to the low-power domain. Thus, the high-power domain may perform at least a portion 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, the high-power domain or the low-power domain may be selected over the other domain for reasons of code stability / maturity or computing resource availability, among other examples. Thus, aspects described herein can similarly reduce code complexity and provide stability improvements.

[0283]

[0319] Thus, if it is determined to continue high power processing, flow branches "yes" to operation 1668, where the high power domain processor continues processing in accordance with aspects described herein. In another example, if it is instead determined that high power processing should not continue, flow branches "no" to operation 1666, where processing in the high power domain is terminated, e.g., by suspending or powering down the high power domain processor accordingly. Method 1650 ends at either operation 1666 or operation 1668.

[0284]

[0320] 47A illustrates an overview of an example method 1700 for handling a warning condition in a low power domain according to aspects of the present disclosure. In an example, aspects of the method 1700 are performed by a low power domain processor, such as the low power domain processor 1432 described above with respect to FIGS.

[0285]

[0321] Method 1700 begins at operation 1702, where an alert condition is identified. For example, the alert condition may be identified based on accelerometer data, location data, and / or any of a variety of other information. In an example, the alert condition may be identified as a result of aspects of methods 600 and 650 described above with respect to Figures 35A and 35B. Accordingly, it will be appreciated that any of a variety of alerts may be identified in accordance with aspects described herein.

[0286]

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

[0287]

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

[0288]

[0324] If it is determined that the device to communicate with is nearby, flow branches "YES" to operation 1708, where an indication of the alert condition is provided. For example, the indication may be provided to a driver device, so that the driver is notified of the alert condition. As another example, the indication may be provided to a nearby vehicle (e.g., as 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, as may be determined by a location determining means. Flow proceeds to operation 1710, discussed below.

[0289]

[0325] Method 1700 is described in an example where a paired or otherwise associated device is available to receive the indication provided in operation 1708. In other examples, decision 1706 and operation 1708 may be omitted, and a beacon may be generated instead. For example, a Bluetooth low energy beacon may be transmitted, and the beacon may be detected by one or more other devices. An indication of the detected beacon may then be provided to the 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, thereby enabling the driver to potentially identify the location of the vehicle or telematics control unit even in cases where Internet connectivity is unavailable.

[0290]

[0326] Returning to decision 1706, if it is instead determined that no devices are in proximity, flow branches “NO” to operation 1710, where an indication of the identified alert condition is provided (e.g., to the vehicle platform). In an example, the indication may include a type of alert condition and a location from a location determination means. Method 1700 is described in an example where a low-power modem (e.g., low-power modem 1424) is used to reduce power consumption associated with method 1700. In this example, the indication may be relatively small in size, so that 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 indication 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 in accordance with aspects described herein.

[0291]

[0327] In an example, operations 1708 and / or 1710 are performed multiple times, resulting in the indication being provided while the higher-power domain is booting. Thus, such indication may be provided more quickly compared to instances where the higher-power domain must first finish booting (or, in other examples, resume from a sleep state). Furthermore, while method 1700 is described in an example where the indication is provided to the device and / or vehicle platform while the higher-power domain is booting, it will be appreciated that any of a variety of additional or alternative actions may similarly be 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 depending on whether the device was detected in decision 1706 and / or based on the proximity of the device, among other examples.

[0292]

[0328] At operation 1712, an indication of high power processing is received, thereby indicating that the high power processor has completed booting. Accordingly, at operation 1714, data is provided to the high power domain, allowing the high power domain to continue processing associated with the identified warning condition. In another example, such data may be stored in a shared location, thereby allowing the high power domain to access the data.

[0293]

[0329] In some examples, the low power domain processor may power down 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 example processes. Method 1700 ends at operation 1714.

[0294]

[0330] 47B illustrates an overview of an example method 1750 for addressing a warning condition in a high power domain according to aspects of the present disclosure. In an example, aspects of the method 1750 are performed by a processor having a high power domain, such as the processor 1406 described above with respect to FIGS.

[0295]

[0331] The method 1750 begins at 1752, where an indication of a high power state is received. For example, the indication may be received as a result of the low power domain processor performing aspects of operation 1704 described above with respect to FIG.

[0296]

[0332] Thus, once the high-power domain is booted, operation 1754 is performed to generate an instruction for high-power processing. The instruction may be provided to the low-power domain processor, such that the instruction is received by the low-power domain processor in operation 1712 described above with respect to FIG.

[0297]

[0333] Flow continues to operation 1756 where data is received from the low power domain processor. For example, the received data may include, among other data, a location from a location determining means, an indication as to the type of alert 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] At operation 1758, an instruction is provided via the low-power modem. The instruction may be provided to the vehicle platform and / or another device (similar to operations 1708 and / or 1710 described above). The provided instruction may include at least a portion 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 a low-power domain processor (e.g., performing aspects of operations 1708 and / or 1710), the instruction provided at operation 1758 may be provided more frequently, may be of higher fidelity, and / or may have more information, among other examples. Thus, the combined processing performed by the low-power domain processor performing aspects of method 1700 and the high-power domain processor performing aspects of method 1750 allows for both instructions that are closer in time to when the alert condition is first identified and instructions that are more frequent / fidelity or require additional processing on the part of the telematics control unit.

[0299]

[0335] Flow proceeds to decision 1760, where it is determined whether high power operation should continue. In examples, it may be determined whether a warning condition still exists and / or whether the power source is above a predetermined threshold, among other examples. As another example, if it is determined that the driver device is no longer within range of the vehicle (e.g., according to a communications controller or within a predetermined distance), it may be decided not to continue high power operation because less frequent updates may be sufficient (e.g., at least until the driver is again in proximity to the vehicle).

[0300]

[0336] Thus, if it is determined to continue high power processing, flow returns to operations 1756 and 1758, resulting in continued provision of instructions (e.g., while the warning condition exists). Furthermore, while method 1750 is described in examples where instructions are provided to a device and / or vehicle platform, it will be appreciated that any of a variety of additional or alternative actions may similarly be 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. For example, a driver interface may be disabled or configured to display information, among other examples. As with method 1700, the frequency with which information is provided to a device and / or vehicle platform may be adjusted depending on the state of charge and / or whether the device is within range of a communications controller or in proximity to the vehicle, among other examples.

[0301]

[0337] Returning to decision 1760, if instead it is determined not to continue high power processing, flow branches "NO" and ends at operation 1762, and processing in the high power domain ends. For example, the processor may enter a sleep state or be powered down, among other examples.

[0302]

[0338] 47A and 47B are provided as an example of simultaneous or cooperative processing that may be performed by a processor having a high power domain and a low power domain processor. While this example is discussed in the context of identifying and handling warning conditions, it will be appreciated that similar techniques may be used in any of a variety of other scenarios, for example, to reduce power consumption while improving the availability of a vehicle to provide aspects of the connected functionality described herein.

[0303]

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

[0304]

[0340] 1. An intercept circuit for a vehicle, comprising: a first connector connectable to a key switch connector of the vehicle; a second connector connectable to a key switch harness of the vehicle; and a controller connected to the first and second connectors, the controller configured to pass signals from the first connector to the second connector in a first mode of operation and to interrupt the signals in a second mode of operation, thereby preventing the signals from being transmitted from the first connector to the second connector.

[0305]

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

[0306]

[0342] 3. The intercept circuit of claim 2, wherein switching from the first operating mode to the second operating mode includes generating a timeout alarm.

[0307]

[0343] 4. The intercept circuit of claim 2 or 3, wherein the intercept circuit further comprises a connection to a controller area network, and the predetermined period of inactivity 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 the second connector, thereby operating a function of the vehicle via the key switch harness.

[0309]

[0345] 6. The intercept circuit of clause 5, wherein the controller is further configured to receive instructions to operate a function of the vehicle, evaluate a state of charge of the vehicle based on a predetermined threshold, and generate a signal to operate the function of the vehicle when the state of charge of the vehicle exceeds the predetermined threshold.

[0310]

[0346] 7. The intercept circuit of claim 6, wherein the instruction is received via a connection circuit of the vehicle.

[0311]

[0347] 8. An intercept circuit as described in any one of items 1 to 7, further comprising a third connector that can be connected to a vehicle key switch harness, the second connector being a non-critical accessory connector and the third connector being a critical accessory connector.

[0312]

[0348] 9. The intercept circuit of claim 8, wherein a signal is provided via the third connector in a second mode of operation, whereby non-critical accessories of the vehicle are disabled and power is maintained to critical accessories of the vehicle.

[0313]

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

[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 an instruction of an operating mode, the operating mode being at least one of a shipping operating mode, a driver connected operating mode, an off-season storage operating mode, a guaranteed start operating mode, an over-the-air (OTA) operating mode, and a warehouse operating mode; and to configure the vehicle according to the indicated operating mode.

[0315]

[0351] 12. The vehicle of claim 11, wherein the instruction is received via a connection of the controller to the key switch connector, the connection being associated with the operating mode being indicated.

[0316]

[0352] 13. A vehicle as described in paragraph 11, wherein the instructions are received via a connection circuit of the vehicle.

[0317]

[0353] 14. The vehicle of claim 11, wherein the instruction is received via a controller area network of the vehicle.

[0318]

[0354] 15. The vehicle of any one of clauses 11 to 14, wherein the controller is further configured to evaluate a state of charge associated with the battery and configure the vehicle according to a prescribed mode of operation based on the state of charge of the battery.

[0319]

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

[0320]

[0356] 17. Configuring the vehicle according to a storage mode of operation includes limiting the power output of the prime mover;

[0321]

[0357] 17. The vehicle of any one of paragraphs 11 to 16, comprising restricting functionality of the driver interface and configuring lighting of the vehicle to operate at reduced brightness.

[0322]

[0358] 18. A vehicle as described in any one of clauses 11 to 17, wherein configuring the vehicle includes providing instructions to a vehicle control module of the vehicle to configure vehicle functionality according to the indicated operating mode.

[0323]

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

[0324]

[0360] 20. The method of clause 19, further comprising: evaluating a state of charge based on a first predetermined threshold; configuring a connection circuit of the vehicle to an enabled state based on a determination that the state of charge is above the first predetermined threshold; and maintaining a communication session with the vehicle platform.

[0325]

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

[0326]

[0362] 22. The method of claim 21, wherein the first notification and the second notification are provided to a driver device.

[0327]

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

[0328]

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

[0329]

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

[0330]

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

[0331]

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

[0332]

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

[0333]

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

[0334]

[0370] 30. A telematics control unit for a vehicle, the telematics control unit 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, the controller configured to configure the switch to the first state and establish a first connection with a cellular network using the first modem, and to configure the switch to the second state and establish a second connection with the cellular network using the second modem.

[0335]

[0371] 31. The telematics control unit of clause 30, wherein the controller determines to configure the switch to the second state based on a geographic location of the telematics control unit relative to a coverage map associated with the cellular network.

[0336]

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

[0337]

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

[0338]

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

[0339]

[0375] 35. A telematics control unit as described in any one of clauses 30 to 34, wherein the set of shared modem resources further includes at least a second antenna usable by a first modem internal to the telematics control unit.

[0340]

[0376] 36. A telematics control unit as described in any one of clauses 30 to 35, wherein the switch is a first switch, the set of shared modem resources further includes a subscriber identity module (SIM), and the telematics control unit further includes a second switch having a first state in which the first modem is coupled to the SIM and a second state in which the second modem is coupled to the SIM, and wherein the first state of the first switch is associated with the first state of the second switch, and the second state of the first switch is associated with the second state of the second switch.

[0341]

[0377] 37. The telematics control unit of any one of clauses 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 the first state to the second state when a charge state associated with the power source falls below a predetermined threshold.

[0342]

[0378] 38. The telematics control unit of any one of clauses 30 to 37, wherein the first cellular modem implements Category 1 of the LTE standard.

[0343]

[0379] 39. A telematics control unit as described in any one of clauses 30 to 38, wherein the controller is further configured to configure the switch from the second state to the first state in response to an instruction received from the cellular network using the second cellular modem.

[0344]

[0380] 40. A telematics control unit for a vehicle, comprising: a cellular modem; a switch in electrical communication with the cellular modem; an expansion interface that enables communication with the cellular modem through the switch when the switch is in a first state; and a processor that communicates with the cellular modem through 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 determination to perform processing in a high power domain;

[0345]

[0381] The telematics control unit is configured to configure the switch to be in a second state based on a determination to perform processing in a low power domain associated with the processor.

[0346]

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

[0347]

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

[0348]

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

[0349]

[0385] 44. The telematics control unit of claim 43, wherein the processor operates at a voltage below the voltage range of the power supply.

[0350]

[0386] 45. The telematics control unit of any one of clauses 40 to 44, wherein the switch is a universal serial bus (USB) switch and the expansion interface enables access to the USB switch by the driver interface.

[0351]

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

[0352]

[0388] 47. A telematics control unit as described in any one of clauses 40 to 46, wherein the cellular modem is a first cellular modem and the telematics control unit further comprises a second cellular modem in electrical communication with the 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 of clause 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 states and low power states of a telematics control unit, the method comprising: 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 to transition to a high power state based on the received data; boosting a high power domain of a second processor of the telematics control unit based on the decision to transition to the high power state; and providing at least a portion of the received data to the second processor for processing in response to receiving an instruction from the high power domain.

[0355]

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

[0356]

[0392] 51. The method of clause 49 or 50, further comprising placing the first processor of the telematics control unit in a sleep mode in response to receiving an instruction from the high power domain.

[0357]

[0393] 52. The method of clause 51, further comprising the steps of receiving an indication that processing in the high power domain has been completed, and activating the first processor of the telematics control unit in response to the indication that processing in the high power domain has been completed.

[0358]

[0394] 53. The method of any one of clauses 49 to 52, wherein the first processor buffers data from a controller area network (CAN) bus and provides at least a portion of the buffered data to the second processor in response to receiving an instruction from the high power domain.

[0359]

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

[0360]

[0396] 55. The method of clause 54, wherein the data received from the vehicle platform is an over-the-air update, and processing the data being received while the high-power domain of the second processor is booting includes staging at least a portion of the over-the-air update, and the over-the-air update is processed in the high-power domain to apply the update.

[0361]

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

[0362]

[0398] 57. The method of any one of clauses 49-56, wherein the first processor provides an indication of telemetry data obtained from a controller area network (CAN) bus.

[0363]

[0399] While this invention has been described as having an exemplary design, the invention may be further modified within the spirit and scope of this disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the invention using its general principles. Further, this application is intended to cover such departures from the disclosure as come within known or customary practice in the art to which this invention pertains.

Claims

1. A vehicle, The frame and a prime mover supported by the frame; and a battery supported by the frame; a controller; The controller: receiving an indication of an operational mode, the operational mode comprising: Shipping operation mode, Driver connection operation mode, Off-season storage operation mode, Start-guaranteed operation mode, Over-the-air (OTA) mode of operation; and receiving instructions to at least one of a warehouse operating mode; configuring the vehicle according to the indicated mode of operation; a vehicle configured to:

2. the instruction is received via a connection of the controller to a key switch connector; the connection is associated with the indicated mode of operation; The vehicle of claim 1 .

3. 12. The vehicle of claim 11, wherein the instructions are received via connection circuitry in the vehicle.

4. the instruction is received via a controller area network of the vehicle; The vehicle of claim 1 .

5. The controller: assessing a state of charge associated with the battery; and further configured to configure the vehicle according to the indicated mode of operation based on the state of charge of the battery. A vehicle according to any one of claims 1 to 4.

6. The start-guaranteed operation mode is associated with the state of charge of the battery; including a fully connected mode of operation, a limited connection mode of operation, and a connectionless mode of operation; A vehicle according to any one of claims 1 to 5.

7. configuring the vehicle according to the warehouse mode of operation; limiting the power output of the prime mover; Constraining the functionality of the driver interface; and configuring the vehicle's lighting to operate at a reduced brightness. A vehicle according to any one of claims 1 to 6.

8. Configuring the vehicle includes: providing instructions to a vehicle control module of the vehicle to configure vehicle functionality in accordance with the indicated operational mode; A vehicle according to any one of claims 1 to 7.

9. 1. A method for configuring a vehicle based on a state of charge of a battery, comprising: assessing the state of charge based on a first predetermined threshold; based on a determination that the state of charge is below the first predetermined threshold; configuring said vehicle's connectivity circuitry to periodically activate; communicating with a vehicle platform when the connection circuitry is active; assessing the state of charge based on a second predetermined threshold that is less than the first predetermined threshold; based on a determination that the state of charge is below the second predetermined threshold; and disabling the connection circuitry of the vehicle.

10. assessing the state of charge based on the first predetermined threshold; based on a determination that the state of charge is above the first predetermined threshold; configuring the connection circuit of the vehicle to an enabled state; and maintaining a communication session with the vehicle platform.

11. The method of claim 9 or 10, wherein a set of non-critical components is disabled based on a determination that the state of charge is below the first predetermined threshold.

12. The method of any one of claims 9 to 11, wherein a set of critical components is disabled based on a determination that the state of charge is below the second predetermined threshold.

13. 13. The method of any one of claims 9 to 12, wherein a set of non-critical components and a set of critical components are enabled based on a determination that the state of charge is above the first predetermined threshold.

14. 1. A telematics control unit for a vehicle, comprising: a first cellular modem; a second cellular modem; and a set of shared modem resources including an antenna; a switch having a first state in which the first cellular modem is coupled to the antenna and a second state in which the second cellular modem is coupled to the antenna; a controller connected to the switch; The controller: configuring the switch to the first state; establishing a first connection with a cellular network using the first cellular modem; configuring the switch to the second state; establishing a second connection with the cellular network using the second cellular modem; Telematics control unit.

15. 1. A telematics control unit for a vehicle, comprising: A cellular modem, a switch in electrical communication with the cellular modem; an expansion interface that enables communication with the cellular modem through the switch when the switch is in a first state; a processor for communicating with the cellular modem through the switch when the switch is in a second state; the processor: configuring the switch to be in the first state based on a determination to perform processing in a high power domain; A telematics control unit configured to configure the switch to be in the second state based on a determination to perform processing in a low power domain associated with the processor.

16. 1. A method for managing high power and low power states of a telematics control unit, comprising: using a low power domain of a first processor of the telematics control unit to process data received from a vehicle platform using a first cellular modem; determining to transition to the higher power state based on the received data; booting a high power domain of a second processor of the telematics control unit based on the determination to transition to the high power state; and in response to receiving an indication from the higher power domain, providing at least a portion of the received data to the second processor for processing.

Images