Intelligent vehicle navigation system and control logic for driving event detection in low / no connectivity areas

Abstract

A method for controlling operation of an intelligent vehicle navigation (IVN) system includes a system controller receiving path planning data for a desired route of a vehicle and using the path planning data to identify a low / no connectivity (LNC) area within the desired route having limited / no wireless service. The IVN system retrieves historical trip data containing durations of traversing the LNC area for a statistically significant number of previous trips that traversed the LNC area; the IVN system constructs a probability distribution of the trip durations. The IVN system tracks a time interval during which no wireless signals are received from the vehicle after the vehicle outputs a last wireless signal before entering the LNC area. In response to the no-signal time interval exceeding a predetermined threshold within the probability distribution, a predicted driving event is predicted. The system controller responds to the predicted driving event by transmitting an alert to a third-party entity.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to navigation systems for motor vehicles. More particularly, aspects of the present disclosure relate to intelligent vehicle navigation systems and control logic for detecting emergency issues in low / no connectivity areas. BACKGROUND

[0002] Currently produced motor vehicles, such as modern automobiles, can be equipped with in-vehicle electronics networks and wireless communication capabilities that provide for automated driving capabilities and navigation assistance. As vehicle processing, communication, and sensing capabilities improve, manufacturers are pushing to provide more automated driving capabilities, with a desire to produce fully autonomous “self-driving” vehicles that are competent to navigate in a variety of vehicle types in both urban and rural scenarios. Original equipment manufacturers (OEMs) are moving toward automobiles with higher levels of driving automation that have vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) “conversations” that employ autonomous control systems to implement vehicle route planning with steering, lane shifting, scenario planning, etc. For example, automated path planning systems utilize vehicle state and dynamic sensors, geolocation information, map and road condition data, and path prediction algorithms to provide route derivations with automated lane centering and lane shift predictions.

[0003] Many automobiles now come equipped with in-vehicle computer navigation systems that utilize global positioning system (GPS) transceivers in cooperation with navigation software and geolocation map services to obtain road topography, traffic, and speed limit data related to the vehicle’s current location. For example, ad-hoc network-based driver assistance systems can use GPS and map data in conjunction with multi-hop geocast V2V and V2I data exchanges to facilitate automated vehicle maneuvering and powertrain control. During vehicle operation, a resident navigation system can identify a recommended travel route based on an estimated shortest travel time or an estimated shortest travel distance between a route origin and a route destination for a given trip. This recommended travel route can then be displayed as a map trace on a geocoded and annotated map or as turn-by-turn driving directions with optional voice commands output through the vehicle’s onboard audio system. SUMMARY

[0004] Intelligent vehicle navigation systems with accompanying control logic for driving event detection and remediation in low / no connectivity (LNC) areas, methods of manufacturing such systems and methods of operating such systems, and motor vehicles networked with such systems are set forth herein. For example, a controller can execute an algorithm that uses the mobile connectivity behavior of a host vehicle and historical driving data for the LNC area to detect off-road emergency issues. A driving event can be predicted by identifying a remote off-road track that a driver plans to traverse, utilizing data about mobile network coverage along the track, and tracking mobile signals output from the host vehicle as it enters / exits the track. Based on historical data accumulated during previous trips on the track, the system derives an expected duration of time that the vehicle should take to traverse each LNC segment along the track. From this expected duration of time, the system projects a timeframe in which the vehicle’s mobile signals should resume, indicating that the vehicle has exited the LNC area. If the vehicle does not return signals within a first predetermined threshold (e.g., within two standard deviations of the mean exit time on a Gaussian distribution) of the expected timeframe, the system generates an alert to a designated contact person. If the vehicle does not return signals within a second predetermined threshold (e.g., within three standard deviations of the mean exit time), an automated emergency message can also be sent to local authorities. These thresholds for notification can be based on real-time or predicted battery state data at the time of entry into the LNC area.

[0005] At least some of the attendant benefits of the disclosed concepts include intelligent vehicle navigation systems that accurately detect driving events in LNC areas, such as breakdown or rollover events on off-road tracks or remote roads. The disclosed technology can also take into account the time of day, weather, user-defined activities, user driving history, vehicle make / model, etc. to more accurately estimate the predicted time of traversal through the LNC area. Furthermore, the intelligent navigation systems described herein allow the vehicle battery state to determine the size of a time delay interval for notifying a contact person / local authorities to more fully assess a potential vehicle driving event. To avoid false reporting, the system can continuously monitor, aggregate, and evaluate historical trip data for off-road and low connectivity paths to predict an accurate expected exit time of traversal through the LNC area.

[0006] Aspects of the present disclosure relate to system control logic, closed loop feedback control techniques, and computer readable media (CRM) for manufacturing and / or using a navigation system for host vehicles. In an example, a method for controlling operation of an intelligent vehicle navigation system is presented. The representative method includes, in any order and in any combination with any of the options and features disclosed above and below: receiving path planning data from an on-board telematics unit, a smartphone, a navigation transceiver, or a GPS-based satellite service, e.g., via a resident or remote system controller, the path planning data indicating a desired route (e.g., a starting point, a destination, and / or a predicted path) for a motor vehicle; identifying one or more LNC areas having limited / no wireless connectivity within the desired route, e.g., via the system controller from a map database stored in memory; receiving historical trip data containing a duration of time to traverse each LNC area for a statistically significant number of previous trips that traversed the LNC area; determining a probability distribution of trip duration for each LNC area; tracking a signal-free time lapse (or time shift interval) - a period of time in which no signal is received from the host vehicle after the last wireless signal is output by the motor vehicle before / during the vehicle enters the LNC area; predicting an occurrence of a driving event, e.g., a mechanical or electrical failure, in response to the signal-free time lapse exceeding a predetermined threshold within the probability distribution of trip duration; and transmitting an alert to a remote computing node of a third party entity, e.g., via the system controller, in response to predicting the occurrence of the driving event.

[0007] Additional aspects of the present disclosure relate to an intelligent vehicle navigation system that provides navigation and emergency services to motor vehicles. As used herein, the terms "vehicle" and "motor vehicle" can be used interchangeably and synonymously to include any relevant vehicle platform, e.g., passenger vehicles (e.g., internal combustion, hybrid, all-electric, fully and partially autonomous, etc.), commercial vehicles, industrial vehicles, tracked vehicles, motorcycles, off-road and all-terrain vehicles (ATVs), watercraft, aircraft, etc. In an example, the intelligent vehicle navigation system includes an in-house or outsourced database or other tangible memory device for storing map data, trip data, vehicle data, driver data, etc. Wireless communication devices wirelessly connect one or more motor vehicles with one or more system servers, server-level computers, cloud resources, or other suitable electronic controller devices.

[0008] Continuing the discussion of the foregoing example, the system controller is programmed to receive path planning data indicative of a desired route for the motor vehicle and identify from a map database stored in memory each region along the desired route having a limitation / no wireless connectivity. The system controller collects, looks up, or otherwise identifies (collectively "receives") historical trip data indicative of a duration of travel through each LNC region for a statistically significant number of prior trips through the LNC region; generates a probability distribution for each set of trip durations. The system controller tracks a signal-less time interval during which no wireless signal is received from the motor vehicle after the last time a wireless signal was output by the vehicle at the same time as the vehicle enters the LNC region. If the signal-less time interval exceeds a predetermined threshold within the probability distribution, a possible driving event is flagged; in response to a possible occurrence of the driving event, the controller transmits one or more alerts to a remote computing node of one or more third-party entities.

[0009] For any of the disclosed systems, vehicles, and methods, determining a probability distribution of trip durations can include constructing a normal-type continuous probability distribution using a probability density function of trip durations, including a central expected value and a predetermined number of standard deviations; setting the central expected value as an arithmetic mean of trip durations; and setting the predetermined threshold as one of the standard deviations from the central expected value. A second predetermined threshold can be set as another of the standard deviations; if the signal-less time interval exceeds the second predetermined threshold, the system controller can transmit an emergency message to a first responder entity proximate the LNC region.

[0010] For any of the disclosed systems, vehicles, and methods, a user can select one or more user-defined preferences for the desired route via an in-vehicle user input device. In this case, the system controller can receive the user-defined preferences from a vehicle controller of the motor vehicle and expand, contract, or otherwise modify the probability distribution of trip durations based on the preferences. For the desired route, the system controller can determine a current time of day, current weather conditions, and / or historical driving behavior of a driver of the motor vehicle. In this case, the probability distribution can be modified based on the current time of day, current weather conditions, historical driving behavior, etc.

[0011] For any of the disclosed systems, vehicles, and methods, the system can receive battery data indicative of a battery status of a battery pack of the motor vehicle and quantify a risk of a battery issue (e.g., loss of charge, TPIM failure, etc.) in the LNC region using the battery data. The predetermined threshold can be modified based on the quantified risk of the battery issue within the LNC region. The system can predict an energy consumption of the motor vehicle from the battery pack while traversing the LNC region; the quantifying of the risk of the battery issue over the LNC region can be further based on the predicted energy consumption. The battery status can include a state of charge (SOC), a state of health (SOH), and / or a battery capacity of the battery pack (e.g., the entire pack, a module in the pack, a cell in a module in the pack, etc.). As another option, the historical trip data can include crowd-sourced data of a duration of a third-party vehicle traversing the LNC region, primary vehicle data of a duration of the motor vehicle traversing the LNC region, and / or open street map data of a duration of traversing the LNC region recorded by a third-party map service.

[0012] For any of the disclosed systems, vehicles, and methods, the system controller can respond to the signal-free time interval exceeding a second predetermined threshold within the distribution of trip durations by transmitting an emergency message to first responder entities proximate the LNC. Identifying the LNC region can include receiving mobile network coverage data indicative of wireless connectivity for a plurality of trackway segments on the desired route; determining which, if any, of the trackway segments have limited / no wireless connectivity; and designating each trackway segment on the desired route having limited / no wireless connectivity as an LNC region.

[0013] For any of the disclosed systems, vehicles, and methods, the path planning data can be received via the system controller from a vehicle controller of the motor vehicle in response to a desired route (selecting an origin, a destination, a route, etc.) being selected by a user via a user input device (e.g., a touchscreen display, voice commands, a button panel, a smartphone, etc.). Upon receiving the selected desired route, an activation prompt can be transmitted to the user to enable the drive event detection protocol; the system controller can then receive confirmation from the user to enable the drive event detection protocol. In this case, transmitting the alert to the remote computing node of the third-party entity is further in response to the user enabling the drive event detection protocol. Prior to sending the alert to the remote computing node, a no-event confirmation prompt can be sent to the user to verify that no drive event occurred; to avoid false reporting, the alert is not transmitted to the third-party further in response to the system receiving the verification that no event occurred within a predetermined time window.

[0014] Scheme 1. A method for controlling operation of an intelligent vehicle navigation system in communication with a motor vehicle, the method comprising:

[0015] receiving, via the system controller, path planning data indicative of a desired route for the motor vehicle via a wireless communication device;

[0016] identifying, via the system controller, a low / no connection (LNC) area having limited / no wireless connectivity within the desired route from a map database stored in memory;

[0017] receiving historical trip data indicative of a trip duration for a statistically significant number of previous trips through the LNC area;

[0018] determining a probability distribution of the trip duration;

[0019] tracking a signal-free time interval after a last wireless signal is output by the motor vehicle at a same time as the motor vehicle enters the LNC area;

[0020] predicting an occurrence of a driving event in response to the signal-free time interval exceeding a predetermined threshold within the probability distribution of the trip duration; and

[0021] transmitting, via the system controller, an alert to a remote computing node of a third party entity in response to predicting the occurrence of the driving event.

[0022] Scheme 2. The method of Scheme 1, wherein determining the probability distribution of the trip duration comprises:

[0023] constructing a normal distribution using a probability density function of the trip duration, including a central expected value and a predetermined number of standard deviations;

[0024] setting the central expected value as an arithmetic mean of the trip duration; and

[0025] setting the predetermined threshold as a first one of the standard deviations.

[0026] Scheme 3. The method of Scheme 2, further comprising:

[0027] setting a second predetermined threshold as a second one of the standard deviations; and

[0028] transmitting, via the system controller, an emergency message to a first responder entity proximate to the LNC area in response to the signal-free time interval exceeding the second predetermined threshold.

[0029] Scheme 4. The method of Scheme 1, further comprising:

[0030] receiving, via the system controller from a vehicle controller of the motor vehicle, a user-defined preference for the desired route selected by a user via an in-vehicle user input device; and

[0031] modify the probability distribution of the trip duration based on the user-defined preferences.

[0032] Scheme 5. The method according to Scheme 4, further comprising:

[0033] for the desired route, determining a current time of day, current weather conditions, and / or historical driving behavior of a driver of the motor vehicle; and

[0034] modify the probability distribution of the trip duration based on the current time of day, the current weather conditions, and / or the historical driving behavior of the driver.

[0035] Scheme 6. The method according to Scheme 1, further comprising:

[0036] receiving battery data indicative of a battery status of a battery pack of the motor vehicle;

[0037] quantifying a risk of a battery issue on the LNC area based on the battery data; and

[0038] modify the predetermined threshold based on the quantified risk of the battery issue on the LNC area.

[0039] Scheme 7. The method according to Scheme 6, further comprising predicting an energy consumption of the motor vehicle from the battery pack while traversing the LNC area, wherein quantifying the risk of the battery issue on the LNC area is further based on the predicted energy consumption.

[0040] Scheme 8. The method according to Scheme 6, wherein the battery status comprises a state of charge (SOC), a state of health (SOH), and / or a battery capacity of the battery pack.

[0041] Scheme 9. The method according to Scheme 1, further comprising transmitting, via the system controller, an emergency message to a first responder entity proximate to the LNC area in response to the signal-free time interval exceeding a second predetermined threshold within the distribution of the trip duration.

[0042] Scheme 10. The method according to Scheme 1, wherein identifying the LNC area comprises:

[0043] receiving mobile network coverage data indicative of wireless connectivity for a plurality of track segments on the desired route;

[0044] determining which, if any, of the track segments on the desired route has limited / no wireless connectivity; and

[0045] designating at least one of the track segments on the desired route having limited / no wireless connectivity as the LNC area.

[0046] Scheme 11. The method according to Scheme 1, wherein in response to a desired route being selected by a user via a user input device connected to a vehicle controller, the path planning data is received from the vehicle controller of the motor vehicle via the system controller.

[0047] Scheme 12. The method according to Scheme 11, further comprising:

[0048] in response to receiving the selection of the desired route by the user, transmitting an activation prompt to the user to enable the driving event detection protocol; and

[0049] receiving confirmation from the vehicle controller of the motor vehicle via the system controller that the driving event detection protocol was enabled by the user input,

[0050] wherein transmitting the alert to the remote computing node of the third party entity is further in response to the user enabling the driving event detection protocol.

[0051] Scheme 13. The method according to Scheme 1, further comprising:

[0052] transmitting a no event confirmation prompt to the user to verify that no driving event occurred in the LNC area prior to sending the alert to the remote computing node,

[0053] wherein transmitting the alert to the remote computing node of the third party entity is further in response to verification that the no event confirmation prompt was not received within a predetermined time window.

[0054] Scheme 14. The method according to Scheme 1, wherein the historical trip data comprises crowd sourced data of durations of third party vehicles traversing the LNC area, host vehicle data of durations of the motor vehicle traversing the LNC area, and / or open street map data of durations of traversing the LNC area recorded by a third party map service.

[0055] Scheme 15. An intelligent vehicle navigation system, comprising:

[0056] a memory device storing trip data;

[0057] a wireless communication device operable to wirelessly communicate with the motor vehicle; and

[0058] a system controller operatively connected to the memory device and the wireless communication device, the system controller programmed to:

[0059] receive path planning data, the path planning data indicative of a desired route for the motor vehicle;

[0060] identify from a map database stored in the memory a low / no connection (LNC) area having limited / no wireless connectivity within the desired route;

[0061] receiving historical travel data from a memory device, the historical travel data indicative of a travel duration through the LNC region for a statistically significant number of previous travels through the LNC region;

[0062] determining a probability distribution of the travel duration;

[0063] tracking a signal-free time interval during which no wireless signals are received from the motor vehicle after a last wireless signal is output by the motor vehicle at the same time as the motor vehicle enters the LNC region;

[0064] in response to the signal-free time interval exceeding a predetermined threshold within the probability distribution, predicting an occurrence of a driving event; and

[0065] in response to predicting the occurrence of the driving event, transmitting an alert to a remote computing node of a third party entity.

[0066] Scheme 16. The intelligent vehicle navigation system of Scheme 15, wherein determining the probability distribution of the travel duration comprises:

[0067] constructing a normal distribution using a probability density function of the travel duration, including a central expected value and a predetermined number of standard deviations;

[0068] setting the central expected value as an arithmetic mean of the travel duration; and

[0069] setting the predetermined threshold as a first one of the standard deviations.

[0070] Scheme 17. The intelligent vehicle navigation system of Scheme 16, the system controller further programmed to:

[0071] setting a second predetermined threshold as a second one of the standard deviations; and

[0072] in response to the signal-free time interval exceeding the second predetermined threshold, transmitting an emergency message via the system controller to a first responder entity proximate the LNC region.

[0073] Scheme 18. The intelligent vehicle navigation system of Scheme 15, the system controller further programmed to:

[0074] receiving a user-defined preference for the desired route selected by a user via an in-vehicle user input device; and

[0075] modifying the probability distribution of the travel duration based on the user-defined preference.

[0076] Scheme 19. The intelligent vehicle navigation system of Scheme 15, the system controller further programmed to:

[0077] for the desired route, determine a current time of day, current weather conditions, and / or historical driving behavior of a driver of the motor vehicle; and

[0078] modify the probability distribution of the trip duration based on the current time of day, the current weather conditions, and / or the historical driving behavior of the driver.

[0079] Scheme 20. The intelligent vehicle navigation system of Scheme 15, the system controller further programmed to:

[0080] determine a battery state of a battery pack of the motor vehicle;

[0081] quantify a risk of a battery problem on the LNC region based on the battery state; and

[0082] modify the predetermined threshold based on the quantified risk of the battery problem on the LNC region.

[0083] The foregoing summary is not representive of every embodiment or aspect of the present disclosure. To the contrary, the above features and advantages, and other features and attendant advantages of the present disclosure, will be more readily apparent as the same becomes better understood by reference to the following detailed description, when considered in connection with the accompanying drawings described below, wherein like numerals designate like elements in the various figures. Moreover, the present disclosure expressly contemplates that one or more of the elements and features of the foregoing summary or the following detailed description can be combined with one or more of the other elements and features to create an embodiment of the present disclosure that is not expressly stated in the foregoing summary or the following detailed description. Furthermore, the present disclosure expressly contemplates that one or more of the foregoing summary or the following detailed description elements or features can be combined with an element or feature not expressly listed herein to create an embodiment of the present disclosure that is not expressly stated in the foregoing summary or the following detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0084] Figure 1 is a partial schematic side view of a representative motor vehicle according to aspects of the disclosed concept, with a network of on-board controllers, sensing devices, and communication devices for networking with an intelligent vehicle navigation system for driving event detection in low / no connectivity regions.

[0085] Figure 2 is a schematic view of a representative intelligent vehicle navigation system according to aspects of the disclosed concept with driving event detection capability for low / no connectivity regions.

[0086] Figure 3 is a flowchart diagram illustrating a representative driving event detection protocol for operating a vehicle navigation system according to aspects of the disclosed concept, which protocol can correspond to memory-stored instructions executable by a resident or remote controller, control logic circuit, programmable control unit, or other integrated circuit (IC) device or network of devices.

[0087] Representative embodiments of the present disclosure are illustrated in the accompanying drawings and described in additional detail herein below. It should be understood, however, that the novel aspects of the present disclosure are not limited to the particular forms illustrated in the above-listed drawings. Rather, the present disclosure is to cover all modifications, equivalents, combinations, sub-combinations, permutations, groupings, and alternatives falling within the scope of the present disclosure as encompassed by the appended claims. DETAILED DESCRIPTION

[0088] The present disclosure is susceptible to embodiments in many different forms. Representative examples of the present disclosure are shown in the accompanying drawings and described in detail herein, it being understood that the examples provided are as illustrative only and are not intended to be limiting on the broad aspects of the present disclosure. For this reason, elements and limitations that are described in, for example, the abstract, summary, and / or metatag sections, but not explicitly set forth in the claims, should not be read into the claims. Further, the drawings are not necessarily drawn to scale and are only provided as is illustrative and for purposes of conceptual presentation. As such, the specific and relative dimensions shown in the drawings are not to be interpreted as limiting.

[0089] For purposes of the detailed description, unless specifically stated otherwise, the singular includes the plural, and vice versa; the words "and" and "or" shall be both conjunctive and disjunctive; the words "any" and "all" shall mean "any and all"; and the words "including," "containing," "comprising," "having," and the like shall mean "including, without limitation." Further, approximating language, such as "about," "substantially," "approximately," "generally," and "close" where ever used herein, can be understood to allow for a degree of variability in a given measurement, value, or other dimension. Finally, directional adjectives, such as front, back, inside, outside, right, left, vertical, horizontal, up, down, forward, rearward, left, right, and the like, can be relative to a motor vehicle, such as a forward travel direction of the motor vehicle when the vehicle is oriented operatively on a horizontal travel surface.

[0090] Reference is now made to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, in Figure 1A representative automobile is shown in FIG. 1 and is generally designated 10 and is depicted herein for discussion purposes as a sedan-type electrically-driven passenger vehicle. The illustrated automobile 10 (also referred to herein as a "motor vehicle" or simply a "vehicle") is merely an exemplary application in which the novel aspects of the present disclosure can be practiced. Likewise, the incorporation of the present concepts into an all-electric vehicle powertrain should also be understood as a non-limiting implementation of the disclosed features. As such, it will be understood that aspects and features of the present disclosure can be applied to other powertrain architectures, can be implemented for any logically relevant type of vehicle, and can be provided by other system architectures. Moreover, only selected components of the motor vehicle and vehicle control systems are shown and described herein in additional detail. However, the vehicles and vehicle systems discussed below can include many additional and alternative features as well as other available peripheral components to perform the various methods and functions of the present disclosure.

[0091] Figure 1 The representative vehicle 10 is initially equipped with a vehicle telematics and information ("telematics") unit 14 that is in wireless communication (e.g., via cell towers, base stations, mobile switching centers, satellite services, etc.) with a remotely-located or "off-board" cloud computing host service 24 (e.g., ONSTAR®). As a non-limiting example, Figure 1 Some of the other vehicle hardware components 16 generally shown in FIG. 1 include an electronic video display device 18, a microphone 28, an audio speaker 30, and various input controls 32 (e.g., buttons, knobs, pedals, switches, touchpads, joysticks, touchscreens, etc.). These hardware components 16 serve in part as a human / machine interface (HMI) to enable a user to communicate with the telematics unit 14 as well as other system components within the vehicle 10. The microphone 28 provides a means for a vehicle occupant to input oral or other audible commands; the vehicle 10 can be equipped with an embedded speech processing unit that utilizes audio filtering, editing, and analysis modules. Conversely, the speaker 30 provides audible output to a vehicle occupant and can be a separate speaker dedicated to the telematics unit 14 or can be part of the audio system 22. The audio system 22 is operatively connected to the network connectivity interface 34 and the audio bus 20 to receive analog information and present it as sound via one or more speaker components.

[0092] Communicatively coupled to the telematics unit 14 is a network connection interface 34, suitable examples of which include twisted pair / fiber optic Ethernet switches, parallel / serial communication buses, local area network (LAN) interfaces, controller area network (CAN) interfaces, media oriented system transfer (MOST) interfaces, local interconnect network (LIN) interfaces, etc. Other suitable communication interfaces can include interfaces compliant with ISO, SAE, and / or IEEE standards and specifications. The network connection interface 34 enables the vehicle hardware 16 to send and receive signals between each other and with various systems and subsystems that are within the vehicle body 12 or "resident" to the vehicle body 12 as well as outside of the vehicle body 12 or "remote" from the vehicle body 12. This allows the vehicle 10 to perform various vehicle functions such as regulating powertrain output, controlling operation of the vehicle transmission, selectively engaging friction and regenerative braking systems, controlling vehicle steering, regulating charging and discharging of the vehicle battery module, and other autonomous driving functions. For example, the telematics unit 14 receives signals and data from and transmits signals and data to a powertrain control module (PCM) 52, an advanced driver assistance system (ADAS) module 54, an electronic battery control module (EBCM) 56, a steering control module (SCM) 58, a brake system control module (BSCM) 60, and various other various vehicle ECUs such as a transmission control module (TCM), an engine control module (ECM), a sensor system interface module (SSIM), etc.

[0093] With continued reference to Figure 1 , the telematics unit 14 is an on-board computing device that provides a mix of services both individually and through its communications with other networked devices. The telematics unit 14 is generally comprised of one or more processors 40, each of which can be implemented as a discrete microprocessor, an application specific integrated circuit (ASIC), or a dedicated control module. The vehicle 10 can provide centralized vehicle control via a central processing unit (CPU) 36 that is operatively coupled to a real time clock (RTC) 42 and one or more electronic memory devices 38, each of which can take the form of a CD-ROM, a disk, an IC device, a flash memory, a semiconductor memory (e.g., various types of RAM or ROM), etc.

[0094] Long-range vehicle communication functionality with remote, non-vehicle mounted networking devices can be provided via one or more or all of a cellular chipset / component, a navigation and positioning chipset / component (e.g., a global positioning system (GPS) transceiver), or a wireless modem, all of which are denoted generally as 44. Short-range wireless connectivity can be provided via a short-range wireless communication device 46 (e.g., a BLUETOOTH® unit or near field communication (NFC) transceiver), a dedicated short-range communication (DSRC) component 48, and / or dual antennas 50. It will be appreciated that the vehicle 10 can be implemented without one or more of the above-listed components, or alternatively, can include additional components and functionality as needed for a particular end use. The various communication devices described above can be configured to exchange data as part of a regular broadcast in a vehicle-to-vehicle (V2V) communication system or a vehicle-to-anything (V2X) communication system (e.g., vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), vehicle-to-device (V2D), etc.).

[0095] The CPU 36 receives sensor data from one or more sensing devices that perform autonomous driving operations using, for example, light detection, radar, laser, ultrasound, optical, infrared, or other suitable technologies, including short-range communication technologies such as DSRC or ultra-wideband (UWB). According to the illustrated example, the vehicle 10 can be equipped with one or more digital cameras 62, one or more ranging sensors 64, one or more vehicle speed sensors 66, one or more vehicle dynamics sensors 68, and any required filtering, classification, fusion, and analysis hardware and software for processing raw sensor data. The type, arrangement, number, and inter-operability of the distributed array of on-board sensors can be individually or collectively adjusted for a given vehicle platform to achieve a desired level of autonomous vehicle operation.

[0096] The digital camera 62 can use a charge-coupled device (CCD) sensor or other suitable optical sensor to generate images indicative of the field of view of the vehicle 10, and can be configured for continuous image generation, e.g., at least about 35+ images per second. In comparison, the ranging sensor 64 can emit and detect reflected radio, infrared, light-based, or other electromagnetic signals (e.g., short-range radar, long-range radar, EM induction sensing, light detection and ranging (LIDAR), etc.) to detect, e.g., the presence, geometric dimensions, and / or proximity of target objects. The vehicle speed sensor 66 can take various forms, including a wheel speed sensor that measures wheel speed, which is then used to determine real-time vehicle speed. Further, the vehicle dynamics sensor 68 can be a single- or tri-axial accelerometer, angular rate sensor, inclinometer, etc., in nature, for detecting longitudinal and lateral acceleration, yaw, roll, and / or pitch rates, or other dynamic-related parameters. Using data from the sensing devices 62, 64, 66, 68, the CPU 36 identifies the surrounding driving conditions, determines road features and surface conditions, identifies target objects within the vehicle's detectable range, determines attributes of the target objects, e.g., size, relative position, distance, approach angle, relative velocity, etc., and performs automatic control strategies based on these performed operations.

[0097] To propel the electrically driven vehicle 10, the electrified powertrain is operable to generate and deliver traction torque to one or more of the vehicle's wheels 26. The powertrain is generally represented in Figure 1 by a rechargeable energy storage system (RESS), which can be a chassis-mounted traction battery pack 70 operatively connected to an electric traction motor 78 in nature. The traction battery pack 70 is generally composed of one or more battery modules 72, each having a stack of battery cells 74, e.g., pouch-, can-, or prismatic-type lithium-ion, lithium-polymer, or nickel-metal-hydride battery cells. One or more electric machines, e.g., traction motor / generator (M) units 78, draw electrical power from, and optionally deliver electrical power to, the battery pack 70 of the RESS. A dedicated power inverter module (PIM) 80 electrically connects the battery pack 70 to the motor / generator (M) units 78 and regulates the flow of electrical current therebetween.

[0098] The battery pack 70 can be configured such that module management, cell sensing, and module-to-module or module-to-main vehicle communication functions are integrated directly into each battery module 72 and performed wirelessly via a wireless-enabled cell monitoring unit (CMU) 76. The CMU 76 can be microcontroller-based, with a printed circuit board (PCB)-mounted sensor array. Each CMU 76 can have GPS transceiver and RF capabilities and can be packaged on or in the battery module housing. The battery module cells 74, CMU 76, housing, coolant lines, busbars, etc. collectively define a cell module assembly.

[0099] Figure 2 A schematic diagram of an exemplary intelligent vehicle navigation (IVN) system 100 is presented for providing navigation and emergency services for a vehicle distributed network, among other features. While a single cloud computing host service 124 is illustrated in communication with a single motor vehicle 110 and a single third-party entity 150, it is contemplated that any number of host computing services (e.g., cloud, edge, distributed, serverless, etc.) can be in communication with any number of vehicles and any number of third-party entities and their associated computing nodes, which are suitably equipped for wireless exchange of information and data. Although outwardly different, it is contemplated that any of the features and options described above with respect to the automobile 10 and host service 24 of Figure 1 may be incorporated individually or in any combination into the motor vehicle 110 and cloud computing host service 124 of Figure 2 respectively, and vice versa.

[0100] Figure 2 The cloud computing host service 124 is communicatively connected to each motor vehicle 110 and each third-party entity 140 via a wireless communication network 38 (e.g., as discussed above with respect to the telematics unit 14 of Figure 1 ). Wireless exchange of data between the vehicles 110 and the host service 124 can occur directly (in configurations where the vehicles 110 are equipped as standalone wireless devices) or indirectly (by pairing and piggybacking the vehicles 110 onto wireless-enabled devices (e.g., smartphones, smartwatches, handheld GPS transceivers, laptop computers, etc.). It is also contemplated that the host service 124 can be in direct communication with a personal computing device of a driver or occupant of the vehicle 110, thus forgoing or supplementing direct communication with the vehicle 110. As yet another option, many of the services provided by the host service 124 can be onboarded to the motor vehicle 110.

[0101] With continued reference to Figure 2The host system 124 can be implemented by way of a high-speed, server-level computing device 154 or mainframe computer capable of handling batch data processing, resource planning, and transaction processing. For example, the host system 124 can operate as a host in a client-server interface for any necessary data exchange and communication with one or more “third-party” servers or devices to complete a particular transaction. Alternatively, the cloud computing host system 124 can operate as middleware for IoT (Internet of Things), WoT (Web of Things), vehicle-to-all (V2X), and / or M2M (machine-to-machine) services, e.g., connecting various heterogeneous devices with a service-oriented architecture (SOA) via a data network. As an example, the cloud computing host system 124 can be implemented as a middleware node to provide different functionalities for dynamically loading heterogeneous devices, multiplexing data from each of these devices, and routing data through reconfigurable processing logic for processing and transmission to one or more destination applications. The network 152 can be any available type of network, including a combination of public distributed computing networks (e.g., the Internet) and secure private networks (e.g., local area networks, wide area networks, virtual private networks). It can also include wireless and wired transmission systems (e.g., satellite, cellular tower networks, terrestrial networks, etc.). In at least some aspects, most if not all data transaction functions performed by the system 100 can be conducted via a wireless network (e.g., a cellular data network in conjunction with a wireless local area network (WLAN)) to ensure the freedom of movement of the vehicle 110.

[0102] According to the illustrated example, the occupant 111 of the vehicle 124 selects a desired route for navigation during an upcoming or future trip. This can include the driver selecting an off-road track or a route on a remote road via a personal smartphone, a vehicle-mounted telematics unit, or a center console input control. Route selection can only require the driver to select a desired destination; a predicted path planning data can then be generated from geographic location data of the selected destination and the vehicle’s current location by navigation software embedded in a vehicle-mounted vehicle navigation system. For autonomous vehicles, e.g., SAE Level 3, 4, or 5 vehicles, the desired route information can only originate from the vehicle’s advanced driver assistance system (ADAS) module or automatic vehicle control (AVC) module.

[0103] The routing data is then wirelessly transmitted over the network 152 to the cloud computing host service 124. According to the illustrated example, a server-level computer 154 of the IVN system 100 processes the path planning data to evaluate the route planning information contained therein for a desired route, or, if only the vehicle origin and destination information is provided, to generate or retrieve a desired route having relevant route planning information for the vehicle 110. The server-level computer 154 can access a map database stored in memory, e.g., retrieved from an external open street map service 158 or from a database (DB) 156 using specialized database management system (BDMS) software, to extract map data and identify which, if any, road segments on the desired route are low / no connectivity (LNC) areas having limited or no wireless connectivity. The wireless connectivity data for the desired route can be sourced from third party vendors (as described above), or can be collected by the IVN system 100 (as described below).

[0104] To pinpoint the LNC areas, the navigation system 100 can collect mobile network coverage data 159 containing wireless connectivity information for a plurality of track road segments on the selected route. The mobile network coverage data 159 can be retrieved directly from one or more local cell towers, sourced from responsible mobile operators in the area, and / or aggregated from crowd-sourced participating vehicles. From this information, the IVN system computer 154 learns which, if any, track road segments on the desired route have limited or no wireless connectivity. For at least some embodiments, wireless service having a signal strength of less than -90 decibel-milliwatts (dBm) can be considered limited / no connectivity. As non-limiting examples, a signal strength of -30 can be designated as a "perfect signal", -50 dBm is a strong signal, and -95 dBm is a very weak signal, and -110 dBm is considered no signal). Each route track road segment having limited / no connectivity can be designated as an LNC area.

[0105] After identifying which road segment or road segments of the desired route have limited / no connectivity, the IVN system 100 derives an expected "no signal" duration 161 for each LNC area. As shown, track trip history data (described below in Figure 3accumulated by the database 156 to determine respective durations or times (also referred to herein as "trip durations") of traversing the particular LNC region. As non-limiting examples, the historical trip data can include crowd-sourced data including durations of third-party vehicles traversing the LNC region during past trips, host vehicle data of durations of the host vehicle traversing the LNC region during past trips, and / or open street map data of durations of traversing the LNC region recorded by third-party map services. For some embodiments, the IVN system 100 can monitor and record wireless signals output from a set of random vehicles or a set of selected vehicles as those vehicles enter and exit the LNC region and optionally as they traverse the LNC region. From this data, the system 100 determines the duration of time each vehicle did not receive signals while traversing the signal-free section (between the last "end" signal upon entry and the next "start" signal upon exit). After completing the initial learning phase, i.e., when the system 100 has accumulated a sufficiently large data set for a meaningful distribution, a mathematical probability distribution is generated over most or all of the monitored vehicles driving through the section. This information is used to determine whether and when to alert third-party entities of possible driving events, such as Figure 2 as shown in FIG. 150 of

[0106] Referring next to the flowchart of Figure 3 in accordance with aspects of the present disclosure, an improved method or control strategy for driving event detection of a host vehicle (e.g., vehicle 10 of Figure 1 is generally described at 200, using an intelligent navigation system (e.g., IVN system 100 of Figure 2 ). Figure 3 Some or all of the operations shown in FIG. 200 and described in greater detail below can represent algorithms corresponding to processor-executable instructions, for example, stored in a main memory or secondary memory or remote memory (e.g., memory device 38 of Figure 1 and / or database 156 of Figure 2 and executed, for example, by an electronic controller, processing unit, logic circuit, or other module or device or network of modules / devices (e.g., CPU 36 and / or cloud computing service 124 of Figure 2 to perform any or all of the above and below described functions associated with the disclosed concepts. It will be recognized that the order of execution of the operational blocks shown can be altered, additional operational blocks can be added, and some of the described operations can be modified, combined, or omitted.

[0107] Figure 3The method 200 begins at start terminal block 201 by virtue of processor-executable instructions stored in memory for a programmable controller or control module or similar suitable processor to invoke an initialization routine for the off-road emergency detection protocol. This routine can be executed in real-time, near real-time, continuously, systematically, sporadically, and / or at regular intervals (e.g., every 10 or 100 milliseconds) during normal and ongoing operation of the motor vehicle 10. As another option, the terminal block 101 is initialized in response to a user command prompt, a resident vehicle controller prompt, or a broadcast prompt signal received from a "non-vehicle-mounted" centralized vehicle service system (e.g., the host cloud computing service 24). Upon completion of the control operations shown in the method 200, the method 200 can proceed to end terminal block 215 and terminate temporarily, or alternatively, can loop back to terminal block 201 and operate in a continuous loop fashion. Figure 3

[0108] From terminal block 201, the method 200 executes a continuous data collection data input block 203 to collect journey data for the off-road emergency detection protocol. As noted above, the track journey history database 156 can aggregate, filter, analyze, and classify crowd-sourced journey information, host vehicle journey information, vehicle-specific journey information (e.g., for vehicles having the same make, model, trim package, etc. as the host vehicle), journey information provided by subscription-based map platforms, and the like. Figure 2 The IVN system 100, for example, can employ a learning system approach that continuously collects data for each segment of a given route, monitoring the following elements: location of signal loss; location of signal restoration; duration between each signal loss / restoration; time of day associated with each loss / restoration / duration set; weather associated with each loss / restoration / duration set; and the like. When available, the IVN system 100 can also identify user-defined preferences and / or user-specific driving behavior for each journey or journey segment. Journey-specific data, such as user-defined preferences, weather, time of day, driver behavior, vehicle make / model, signal presence, and the like, can be used to categorize the associated journey data in order to organize the data for retrieval in order to more accurately reflect the actual conditions of the expected route to which they are matched. For example, if an expected route is to occur in the middle of the day, in the rain, with an SUV driven by a driver known to be aggressive, the system will attempt to focus its assessment on comparable prior journeys that are also in the middle of the day / rain / SUV / aggressive driver.

[0109] ​After retrieving relevant journey data for a selected LNC region on a desired route, the method 200 performs a signal duration distribution predetermination process block 205 to determine a probability distribution of historical journey durations for the selected LNC region. The probability distribution can be constructed as a normal-type continuous (Gaussian) distribution, using a probability density function, with journey duration as a real-valued random variable. The resulting distribution will have a central expected value (µ) and a predetermined number of standard deviations (σ), typically two or three standard deviations. The central expected value (µ) can be defined as the arithmetic mean of journey durations from the relevant data set. A first predetermined threshold for the probability distribution of journey durations can be set to the absolute value of the first of the standard deviations (e.g., about 2σ in Figure 3 the middle). Similarly, a second predetermined threshold can be set to the absolute value of the second of the standard deviations (e.g., about 3σ). It will be appreciated that the expressions “first” or “second” of the standard deviations do not mean one SD and two SDs, respectively, but rather one threshold related to one of the available SDs and another threshold related to the other SD.

[0110] To help ensure a meaningful distribution, the probability distribution can require a statistically significant number of previous journeys through each LNC region. Statistical significance can be expressed in terms of a data set of sufficient size to ensure that the results of determining the data set cannot be explained by random factors or chance alone or reasonably attributed to random factors or chance. Statistical hypothesis testing can be used to make this determination; if the null hypothesis is true (i.e., there is no significant relationship between the variables), the test produces a critical p-value, representing the probability of obtaining the observed data results. A data set with a p-value of 5% or less (i.e., <0.05) is generally considered statistically significant, as it indicates strong evidence against the null hypothesis, as the probability that the results are random is less than 5%. For example, the “significance test” can be made more stringent by moving the p-value threshold to 0.02 (2%), or less stringent by moving the p-value threshold to 0.08 (8%), but generally not less than 0.10 (10%).

[0111] With continuing reference to Figure 3user-defined preference data input box 207 retrieves user-defined preferences of the driver of the host vehicle; these user-defined driver preferences can be fed to the predetermined process block 205 to more accurately estimate the time to traverse a particular LNC region. The user-defined driver preferences can include the following activities, individually or in any combination: picnic at stop; overnight at stop; walk at stop; rest at stop; at stop for [other activity]; slow vehicle speed [for specific or non-specific reason]; increase vehicle speed [for specific or non-specific reason]; etc. The user can be prompted to select one or more predetermined activities for one or more locations on the desired route prior to starting the route and / or entering the LNC region. For example, prior to starting the desired route, the user can input a selection that informs the IVN system 100 of an intent to picnic at a location on a signal-less road segment. Based on the collected historical data, the IVN system 100 can generate a duration distribution in that signal-less road segment using only the data where the user informed them of a similar picnic. Alternatively, if the driver intends to stop and walk, the IVN system 100 can add a predetermined buffer to the estimated trip duration (e.g., add a 2 hour delay to shift the distribution). As yet another option, if the driver intends to camp overnight in a specified LNC region, the IVN system 100 can generate a duration distribution using only similar trip historical data with a corresponding delay, or add a large predetermined buffer (e.g., add an 18 hour delay to shift the distribution) if there are limited / no previous trips with a corresponding delay.

[0112] After generating the probability distribution (block 205) and any related modification thereof based on user-selected preferences (block 207), the method 200 proceeds to an emergency duration threshold predetermined process block 209 to determine one or more predetermined thresholds for predicting the occurrence of a driving event. As described above, each predetermined threshold of the probability distribution of trip duration can be associated with a respective one standard deviation. In the example of FIG. 2, the first contact person threshold is approximately equal to the second standard deviation (e.g., approximately 22 minutes) and the second contact authorities threshold is approximately equal to the third standard deviation (e.g., approximately 33 minutes). These thresholds can be calibrated for the make / model / trim of the host vehicle, e.g., based on vehicle testing / simulation data. For at least some embodiments, these thresholds can vary based on a user-defined risk tolerance (e.g., lower thresholds for risk-averse drivers), which can be input by any of the above-described user input devices. Figure 3

[0113] ​The IVN system 100 can also take into account the vehicle battery state at the time of entering the LNC area in order to modify the size of each time delay interval for notifying the contact person / local authorities. In the illustrated example, the method 200 performs a battery state input block 211 to retrieve battery state data indicative of the battery state of the host vehicle. This battery state can include, individually or in any combination, real-time or near real-time state of charge (SoC), state of health (SoH), operating temperature, capacity, etc. of the battery pack, modules in the pack, and / or cells in the modules in the pack. Using this information, the IVN system 100 can modify one or more of the predetermined thresholds within the probability distribution based on the predicted risk of battery problems while traversing the low / no connectivity road segment. For example, a first driver can enter an LNC road segment with 30% SOC, while a second driver enters the same LNC road segment with 80% SOC. Based on historical trip data, the IVN system 100 can predict that the energy consumption for this road segment is a distribution centered around 25% of the battery. Accordingly, the system 100 can determine that the first driver with low SOC will likely have battery problems (high probability of power drain (e.g., >90%)), while the second driver with high SOC will likely not have battery problems (e.g., <15%). In this case, both predetermined thresholds within the probability distribution can be lowered by the predetermined threshold for the first driver; the predetermined threshold for the second driver can remain unaffected. The predicted energy consumption along a given low / no connectivity area can be based on the length of the LNC area, road conditions along the LNC area, historical data of energy consumption for the host vehicle, historical data of energy consumption for similar make / model / trims, etc.

[0114] Once the threshold is set, the method 200 can proceed from the predetermined process block 209 to a predetermined process block 213 of notifying the contact person or authorities. For this operation, the IVN system can track the "no signal" time interval for the host vehicle, i.e., the period of time without receiving a signal from the host vehicle after the last wireless signal was output by the host vehicle before / during entry into the LNC area. For example, the IVN system 100 can systematically ping the cellular signal of the host vehicle after a predetermined time interval without receiving a signal from the host vehicle in conjunction with the host vehicle approaching / entering the LNC area. Alternatively, the IVN system 100 can communicate with a local mobile operator (e.g., 4G / LTE / 5G) to determine the connectivity status of the host vehicle.

[0115] The IVN system 100 can predict the occurrence of a driving event in response to determining that the signal-free time interval has exceeded at least one predetermined threshold within the trip duration probability distribution. Referring again to the illustrated example, if the signal-free time interval for the host vehicle has exceeded the first (22 minute) threshold, the IVN computing device 154 can responsively transmit an electronic alert to a remote computing node of a third party entity. This can include sending a system-automatically-generated text, email, phone call, etc. to a designated contact person for the driver of the host vehicle. If the signal-free time interval for the host vehicle has exceeded the second (33 minute) threshold, the IVN computing device 154 can responsively transmit an electronic alert to a remote computing node of another third party entity. This can include sending a system-automatically-generated emergency message to first responders in the vicinity of the LNC region, such as a local 911 dispatch, fire department, police department, etc. Prior to sending either of the above alerts / messages, the IVN system 100 can first attempt to contact the driver of the host vehicle to determine whether a driving event has indeed occurred. To prevent false reporting, it is also contemplated that the driver can proactively disable the driving event detection protocol, thereby preventing any corresponding transmission of alerts / messages.

[0116] For at least some embodiments, the user can be prompted to define a designated contact person who will be automatically alerted and / or periodically updated by the system during the poor connectivity road segment of the desired route. For example, the designated contact person can receive a report on his / her smartphone operating a dedicated mobile app containing current signal quality information, where and when the system estimates the user will have the lowest level of signal quality, where and when the last signal was received from the user / vehicle, battery status prior to entering the LNC region, etc. The report can also contain "richer" information including a series of images or video clips of the track or LNC region, vehicle dynamics report (e.g., speed, acceleration, etc.), dangerous driving score, etc. The report containing some or all of the above information can also be submitted to emergency personnel for situation tracking. As the delay in the user's signal response compared to the expected time is greater (or less), the frequency of the report / message to the contact person / emergency personnel can increase (or decrease). The system can also work offline, e.g., by downloading the relevant information prior to the host vehicle entering the LNC region. The user can decide whether the system is in active state according to the corresponding map of the desired route.

[0117] In some embodiments, aspects of the present disclosure can be implemented by computer-executable instruction programs, such as program modules, generally referred to as software applications or application programs, executed by any of the controllers or controller variations described herein. In non-limiting examples, the software can include routines, programs, objects, components, and data structures that perform particular tasks or implement particular data types. The software can form an interface to allow a computer to react to a source of input. The software can also cooperate with other code segments in the execution of methodologies according to the present disclosure. The software can be stored on any of a variety of memory media, such as CD-ROM, diskette, and semiconductor memory (e.g., various types of RAM or ROM).

[0118] Further, aspects of the present disclosure can be practiced with various computer system configurations, including multi-processor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Additionally, aspects of the present disclosure can be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination thereof) through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices. As such, aspects of the present disclosure can be implemented in a computer system or other processing system that includes a variety of hardware, software, or a combination thereof.

[0119] Any of the methods described herein can include machine-readable instructions for execution by: (a) a processor; (b) a controller; and / or (c) any other suitable processing device. Any algorithm, software, control logic, protocol, or method disclosed herein can be embodied in software stored on a tangible medium, such as, for example, flash memory, solid state memory (SSD), hard disk drive (HDD) memory, CD-ROM, digital versatile disk (DVD), or other memory device. The entire algorithm, control logic, protocol, or method and / or portions thereof can alternatively be embodied in devices other than controllers and / or in firmware or hard-wired logic, for example, as opposed to software specific to at least one general purpose or special purpose computing device. Further, although specific algorithms can be described herein with reference to flow charts and / or work flow diagrams, many other methods of implementing example machine readable instructions can be used.

[0120] Aspects of the disclosure have been described in detail with reference to the illustrated embodiments. However, it will be appreciated that various modifications can be made without departing from the scope of the disclosure. The disclosure is not limited to the precise construction and composition disclosed herein; any and all modifications, changes, and variations that are evident from the foregoing description and that are within the scope of the disclosure are included within the scope of the disclosure as defined by the appended claims. Furthermore, the foregoing description is not intended to limit the concepts disclosed herein to the particular form set forth; rather, any and all combinations of the foregoing elements and features are contemplated and are within the scope of the disclosure.

Claims

1. A method for controlling the operation of an intelligent vehicle navigation system in communication with a motor vehicle, the method comprising: receiving, via the system controller via the wireless communication device, path planning data indicating a desired route for the motor vehicle; identifying, via the system controller, from a map database stored in memory, a low / no connectivity area (i.e., an LNC area) within a desired route having limited / no wireless connectivity; receiving historical trip data indicating a duration of travel through the LNC area for a statistically significant number of previous trips through the LNC area; Determine the probability distribution of trip durations; tracking a no-signal time interval following a last wireless signal output by the motor vehicle concurrently with the motor vehicle entering the LNC area; In response to the no-signal time interval exceeding a predetermined threshold within the probability distribution of the trip duration, predicting an occurrence of a driving event; and transmitting, in response to the occurrence of the predicted driving event, an alert to a remote computing node of a third-party entity via the system controller; receiving, via the system controller, from a vehicle controller of the motor vehicle, a user-defined preference for a desired route selected by a user via an onboard user input device; as well as Modify the probability distribution of trip duration based on user-defined preferences; receiving battery data indicative of a battery status of a battery pack of a motor vehicle; Quantify the risk of battery problems in LNC areas based on battery data; as well as modifying the predetermined threshold based on the quantified risk of battery problems in the LNC region; wherein the path planning data is received from a vehicle controller of the motor vehicle via the system controller in response to selection of a desired route by a user via a user input device connected to the vehicle controller; The method further comprises: In response to receiving a selection of a desired route by a user, transmitting an activation prompt to the user to enable a driving event detection protocol; and receiving, via the system controller, from a vehicle controller of the motor vehicle, confirmation input by a user to enable a driving event detection protocol, wherein transmitting the alert to the remote computing node of the third party entity is further responsive to user enabling a driving event detection protocol; The method further comprises: Before sending the alert to the remote computing node, a no-event confirmation prompt is transmitted to the user to verify that no driving events have occurred in the LNC area. wherein transmitting the alert to the remote computing node of the third party entity is further responsive to verification that a no-event confirmation prompt is not received within a predetermined time window; The user defined preferences include the following activities, alone or in any combination: parking for a picnic; parking overnight; parking for a walk; parking for a rest; parking for other activities; slowing down the vehicle speed; increasing the vehicle speed; The predetermined threshold value varies based on a risk tolerance defined by a user, and the risk tolerance is input by any of the above-mentioned user input devices.

2. The method according to claim 1, wherein Determining the probability distribution for trip duration involves: Construct a normal distribution using the probability density function of trip duration, including a central expected value and a predetermined number of standard deviations; Set the central expected value to the arithmetic mean of the trip durations; and The predetermined threshold is set to the first of the standard deviations.

3. The method according to claim 2, further comprising: setting a second predetermined threshold value to be a second of the standard deviations; as well as In response to the no-signal time interval exceeding the second predetermined threshold, an emergency message is transmitted via the system controller to a first responder entity in a neighboring LNC area.

4. The method according to claim 1, further comprising: For a desired route, determining the current time of day, current weather conditions, and / or historical driving behavior of the driver of the motor vehicle; as well as The probability distribution of the trip duration is modified based on the current time of day, current weather conditions, and / or the driver's historical driving behavior.

5. The method according to claim 1, further comprising: Energy consumption from the battery pack of the motor vehicle is predicted while traversing the LNC area, wherein quantifying the risk of a battery problem over the LNC area is further based on the predicted energy consumption.

6. The method according to claim 1, wherein The battery status includes the state of charge (SOC), state of health (SOH) and / or battery capacity of the battery pack.

7. The method according to claim 1, further comprising: In response to the no-signal time interval exceeding a second predetermined threshold within the distribution of trip durations, an emergency message is transmitted via the system controller to a first responder entity of a neighboring LNC zone.

8. The method according to claim 1, wherein Identifying LNC areas includes: receiving mobile network coverage data indicating wireless connectivity for a plurality of track segments along a desired route; determining which, if any, of the track segments on the desired route have limited / no wireless connectivity; and At least one of the track segments on the desired route that has limited / no wireless connectivity is designated as an LNC area.

9. The method according to claim 1, wherein The historical trip data includes crowdsourced data of the duration of third-party vehicles traversing LNC areas, host vehicle data of the duration of motor vehicles traversing LNC areas, and / or Open Street Map data of the duration of traversing LNC areas recorded by third-party mapping services.

10. An intelligent vehicle navigation system comprising: a memory device for storing trip data; a wireless communication device capable of operating wireless communication with a motor vehicle; as well as A system controller operatively connected to the memory device and the wireless communication device, the system controller being programmed to: receiving path planning data indicating a desired route for a motor vehicle; identifying, from a map database stored in a memory, low / no connectivity areas (LNC areas) within a desired route having limited / no wireless connectivity; receiving historical trip data from a memory device, the historical trip data indicating a duration of travel through the LNC area for a statistically significant number of previous trips through the LNC area; Determine the probability distribution of trip durations; tracking a no-signal time interval during which no wireless signal is received from the motor vehicle after a last wireless signal output by the motor vehicle concurrently with the motor vehicle entering the LNC zone; In response to the no-signal time interval exceeding a predetermined threshold within the probability distribution, predicting an occurrence of a driving event; as well as transmitting an alert to a remote computing node of a third-party entity in response to the predicted occurrence of the driving event; receiving user-defined preferences for a desired route selected by a user via an onboard user input device; as well as Modify the probability distribution of trip duration based on user-defined preferences; determining a battery state of a battery pack of a motor vehicle; Quantify the risk of battery problems on LNC areas based on battery status; as well as modifying the predetermined threshold based on the quantified risk of battery problems in the LNC region; wherein the path planning data is received from a vehicle controller of the motor vehicle via the system controller in response to selection of a desired route by a user via a user input device connected to the vehicle controller; The system further comprises: In response to receiving a selection of a desired route by a user, transmitting an activation prompt to the user to enable a driving event detection protocol; and receiving, via the system controller, from a vehicle controller of the motor vehicle, confirmation input by a user to enable a driving event detection protocol, wherein transmitting the alert to the remote computing node of the third party entity is further responsive to user enabling a driving event detection protocol; The system further comprises: Before sending the alert to the remote computing node, a no-event confirmation prompt is transmitted to the user to verify that no driving events have occurred in the LNC area. wherein transmitting the alert to the remote computing node of the third party entity is further responsive to verification that a no-event confirmation prompt is not received within a predetermined time window; The user defined preferences include the following activities, alone or in any combination: parking for a picnic; parking overnight; parking for a walk; parking for a rest; parking for other activities; slowing down the vehicle speed; increasing the vehicle speed; The predetermined threshold value varies based on a risk tolerance defined by a user, and the risk tolerance is input by any of the above-mentioned user input devices.

11. The intelligent vehicle navigation system according to claim 10, wherein: Determining the probability distribution for trip duration involves: Construct a normal distribution using the probability density function of trip duration, including a central expected value and a predetermined number of standard deviations; Set the central expected value to the arithmetic mean of the trip durations; and The predetermined threshold is set to the first of the standard deviations.

12. The intelligent vehicle navigation system of claim 11, wherein the system controller is further programmed to: setting a second predetermined threshold value to a second of the standard deviations; and In response to the no-signal time interval exceeding the second predetermined threshold, an emergency message is transmitted via the system controller to a first responder entity in a neighboring LNC area.

13. The intelligent vehicle navigation system of claim 10, wherein the system controller is further programmed to: For the desired route, determining the current time of day, current weather conditions, and / or historical driving behavior of the driver of the motor vehicle; and The probability distribution of the trip duration is modified based on the current time of day, current weather conditions, and / or the driver's historical driving behavior.

Images