DE102022101597A1 - METHOD AND INSTALLATION FOR BROADCASTING AND EDITING AN ADAPTIVE ROUTE GUIDANCE - Google Patents

Abstract

A server can determine a variety of recommended exit paths for vehicles leaving a location. The server may also correlate a plurality of existing geofencing locations within the location with exit routes such that each location has one or more exit routes correlated with it, thereby allowing vehicles within a given location to be routed via the one or more exit routes designated for that location Place to be recommended, to be informed. Further, the server may instruct an ATSC transmitter to broadcast map data for the location, the map data including designations of geofences around the locations and the correlations between the geofencing locations and the exit routes.

Description

FIELD OF TECHNOLOGY

The illustrative embodiments relate generally to methods and apparatus for broadcasting and processing adaptive routing.

BACKGROUND ART

Connected vehicles have the ability to both send and receive data. In many cases this is achieved via a direct 1:1 connection, where a vehicle connects to a remote access server and receives or sends useful data (map update, software update, etc.). In cases where the connection is supported using cellular services, for example, this can lead to high overall data costs if a distributor of the data (e.g. an original equipment manufacturer (OEM)) distributes the data to a large number must send from vehicles.

Advanced Television System Committee (ATSC) 3.0 technology allows one broadcast frequency to be used to broadcast data, and then different vehicles or other entities can receive the data as part of a broadcast. This provides a 1:n possibility, but typically does not involve any intended direct communication with a single entity. That is, the information is part of a broadcast and the receiving entities must then receive and process the data contained in the broadcast when the data may not have been intended for a given receiving entity or is not applicable to that entity.

EXECUTIVE SUMMARY

In a first illustrative embodiment, a system includes a processor configured to determine a plurality of recommended exit paths for vehicles exiting a location. The processor is also configured to correlate a plurality of existing geofencing locations within the location with exit routes such that each location has one or more exit routes correlated with it, thereby allowing vehicles within a given location via the one or more exit routes , which are recommended for this place, will be informed. The processor is further configured to instruct an ATSC transmitter to broadcast map data for the location, the map data including designations of geofences around the locations and the correlations between the geofencing locations and the exit routes.

In a second illustrative embodiment, a system includes a processor configured to receive map data for a location from an ATSC broadcast. The processor is also configured to determine relevant data from the map data based on vehicle parameters compared to parameters associated with one or more subsets of the map data. Further, the processor is configured to derive an exit strategy for a vehicle incorporating the processor exiting the location en route to an entered destination using a recommended exit path associated with the relevant data.

In a third illustrative embodiment, a system includes a processor configured to determine a plurality of recommended exit paths for vehicles exiting a location. The processor is also configured to correlate a plurality of existing geofencing locations within the location with exit routes such that each location has one or more exit routes correlated with it, thereby allowing vehicles within a given location via the one or more exit routes , which are recommended for this place, will be informed. The processor is further configured to instruct an ATSC transmitter to broadcast map data for the location, the map data including designations of geofences around the locations and the correlations between the geofencing locations and the exit routes. Additionally, the processor is configured to receive feedback from a plurality of vehicles indicating those vehicles' intent to use exit paths, as indicated by feedback from a given vehicle indicating an exit path chosen by that vehicle, and at least determine unexpected use of at least one exit path as indicated by feedback from the plurality of vehicles. In response to the unexpected usage, the processor is configured to discontinue at least one exit route affected by the unexpected change and to instruct the ATSC transmitter to broadcast updated map data for the location, the map data being designations of geofences around the Locations around and the correlations between the geofencing locations and the exit routes and include the set at least one exit route.

character list

• 1 12 shows an illustrative ATSC system in communication with a cloud server and multiple vehicles;
• 2 shows an illustrative process for detecting and reporting an anomaly;
• 3 shows an illustrative process for handling reported irregularities;
• 4 Figure 12 shows an illustrative process for sending an ATSC broadcast;
• 5A and 5B show illustrative processes for preparing broadcasts about different illustrative anomalies;
• 6 Figure 12 shows an illustrative example of a process for handling received broadcasts;
• 7 shows an illustrative example of autonomous vehicles serving multiple zones;
• 8th Figure 12 shows an illustrative process for deploying an autonomous vehicle using broadcasts;
• 9 Figure 12 shows an illustrative process for editing a mission;
• 10 Figure 12 shows an illustrative process for delivering an insert for another purpose;
• 11 shows an illustrative process for provisioning a wireless service provider using broadcasts;
• 12 Figure 12 shows an illustrative process for processing a cellular provider's provisioning;
• 13A and 13B show illustrative processes for collecting data using broadcasts and responses;
• 14 shows an illustrative process for selective traffic routing;
• 15 Figure 12 shows an illustrative process for editing selective traffic routing;
• 16 12 shows an illustrative process for adjusting an adaptive model for selective traffic routing;
• 17 Figure 12 shows an illustrative process for editing map data from a selective routing broadcast;
• 18A and 18B show illustrative processes for handling selective alerts;
• 19 Figure 12 shows an illustrative process for periodically updating load data;
• 20 shows an illustrative process for handling loading warnings;
• 21 Figure 12 shows an illustrative process for broadcasting software updates;
• 22 Figure 12 shows an illustrative process for editing the update broadcast; and
• 23 Figure 12 shows an illustrative process for customizing the broadcasting of software updates.

DETAILED DESCRIPTION

As required, detailed embodiments are disclosed throughout this document; however, it should be understood that the disclosed embodiments are exemplary only and may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be enlarged or reduced to show details of particular components. Therefore, specific structural and functional details disclosed in this specification are not to be construed as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the claimed subject matter.

In addition to example processes being executed by a vehicle computing system located in a vehicle, in certain embodiments, the example processes may be executed by a computing system in communication with a vehicle computing system. Such a system may include, among other things, a wireless device (e.g., but not limited to a cellular phone) or a remote computing system (e.g., but not limited to, a server) connected via the wireless device. Collectively, such systems may be referred to as Vehicle Associated Computing Systems (VACS). In certain embodiments, certain components of the VACS may perform certain portions of a process depending on the specific implementation of the system. For example and without limitation, if a process includes a step of sending or receiving information with a paired wireless device, then the wireless device is likely not to perform that portion of the process performs since the wireless device would not "send and receive" information to itself or from itself. Those of ordinary skill in the art will understand when it is inappropriate to apply a particular calculation system to a given solution.

In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of a process that may be performed by a computing system is presented. With respect to each process, it is possible that the computing system executing the process may be configured as a special purpose processor to perform the process for the limited purpose of executing the process. Not all processes need be performed in their entirety and are intended to be exemplary of the types of processes that can be performed to achieve elements of the invention. Additional steps may be added or removed from the example processes as desired.

With respect to the illustrative embodiments described in the figures and showing illustrative process flows, it should be noted that a general purpose processor may be temporarily enabled as a special purpose processor for the purpose of performing some or all of the example methods shown by those figures. When code is executed that provides instructions for performing some or all of the steps of the method, the processor may temporarily become a special purpose processor until the method is complete. In another example, to the appropriate extent, firmware acting according to a preconfigured processor may cause the processor to act as a special purpose processor provided for the purpose of performing the method or a reasonable variant thereof.

Using a server in conjunction with ATSC broadcast stations, a broadcast entity (e.g., an OEM) can prepare and send targeted data designed to target multiple vehicles within a station's broadcast range in a 1:n fashion to reach. That is, instead of delivering the data to each vehicle individually via a direct connection to a specific vehicle, the entity can prepare data useful for a specific group of vehicles and send the data and instructions to be broadcast to an ATSC station transfer. The station can then broadcast the ATSC broadcast and a large number of vehicles can receive the data simultaneously.

Because the data may only be applicable or relevant to a subset of receiving vehicles, the server may also prepare information identifying the vehicles to which the data applies. For example, if the data relates to a road irregularity, the server can specify a coordinate range around the irregularity or a time of day when the irregularity is applicable, etc. If the data relates to a software update, the server can specify a software version or even a set of specific items Vehicle Identification Number (VIN) or Electronic Serial Number (ESN).

When a vehicle receives the broadcast, it can examine parameter data associated with the broadcast to determine the applicability of the data contained in the broadcast. If the parameter data indicates that the vehicle can use the broadcast data, then the vehicle can process the broadcast or send it to the appropriate internal system (update process, navigation system, etc.) for processing. Significant cost savings in communicating data to a large group of vehicles, as well as expediting delivery via broadcast to all vehicles simultaneously, may be achieved through the illustrative embodiments and the like. The broadcast can also persist so that vehicles entering a broadcast area while the broadcast is in progress can continue to receive and benefit from the broadcast.

1 12 shows an illustrative ATSC broadcast system 101 in communication with a cloud 111 server 113 and multiple vehicles 121, 131, 141. In this example, the ATSC system 101 is an ATSC broadcast station capable of ATSC broadcasts to a known broadcast area. The station includes some form of process 105 for receiving updates, which is typically connected to a wide area network (e.g., the Internet), but which may also use a cellular or other connection. Through process 105, station 101 receives instructions from cloud 111 server 113 and processes those instructions to craft a broadcast at a station computer equipped with processor 103. Once the broadcast is ready, the processor 103 can direct the ATSC transmitter 107 to send the broadcast to any vehicles 121, 131 within range.

In the example shown, one of the vehicles 121, 131, 141 has an irregularity report to the server 113 of the cloud 111 via a cellular connection or another connection. In some cases, such as vehicle 141 , the vehicle may include a sensor unit 147 . These units may be more common in autonomous vehicles 141, which may include a variety of sensing systems not provided to other vehicles 121,131.

In other cases, the vehicle may be a human driven vehicle 121, 131 and may include a processor 123, an ATSC transceiver 125, a navigation process or processors 127 and other in-vehicle processes or processors and a Telematics Control Unit (TCU). 129 include. If and when the vehicle 121 detects an anomaly, such as an in-vehicle software error, the vehicle 121 may report the anomaly to the server 113 using the TCU 129 and a cellular or other direct connection (e.g., Wi-Fi). 1 Figure 12 shows vehicle 141 communicating cellular data through TCU 149 to cloud server 113 via a cellular tower. This vehicle 141 could report irregularities detected by the sensors 147, traffic, software bugs, and so on. Each vehicle can potentially communicate an anomaly to the cloud 111 .

The vehicle 131 has similar components to the vehicle 121, but is shown as a single vehicle 131 for the purpose of demonstrating that the broadcast from the ATSC transmitter 107 of the station 101 is 1:n. The antenna shown in the example is an ATSC receiver 135.

The vehicle 141 is an autonomous vehicle or other vehicle with enhanced sensors 147 and can also detect a variety of road-based irregularities (e.g., potholes). Other vehicles 121, 131 can also detect traffic and road irregularities (e.g. traffic, construction site) but may not be as well equipped to detect things like potholes. When the vehicle 141 detects a road condition that should be shared with other vehicles 121, 131 (e.g. based on a predefined set of which detected conditions should be shared), the vehicle 141, which also has a TCU 149 and a central processor 143 that uses the TCU 149 to report the condition to the server 113 over a cellular connection. This vehicle 141 also has an ATSC receiver 145 for receiving ATSC broadcasts from the ATSC transmitter 107 or the like.

The server 113 receives all reported anomalies and, if the anomaly is something that can be fixed (e.g., a software update), determines which vehicles may be affected by the anomalies and/or how the anomalies can be remedied. The server 113 then creates a packet of delivery instructions, along with any parameters that can be used by the vehicles 121, 131, 141 to determine if a received broadcast is applicable, and then the server 113 presents the data packet to the station 101 to. The station 101 can then send the data packet to the different vehicles 121, 131, 141, which can individually determine the applicability of the data.

For example, since the data may include an update to the software, even a reporting vehicle 121 may benefit from the data. In other cases, the receiving vehicle 141 may receive the data and confirm that a road or traffic irregularity was successfully reported based on the fact that the data/solution was received.

2 shows an illustrative process for detecting and reporting an irregularity. In this example, the process executing on a processor 143 of the vehicle 141 at 201 detects a reportable event. This may include, for example, a road irregularity, a traffic irregularity, a change in a road (new road, road closure, etc.), a software error, or any other predefined reportable event.

If there are parameters associated with the anomaly, the vehicle 141 may adjust the parameters at 203 . For example, the road irregularity may have geographic coordinates associated with it, such as a direction of travel or time of day. A software anomaly may include parameters such as a software type or version associated therewith, as well as parameters corresponding to particular vehicle systems that use or incorporate the software. The vehicle 141 then sends 205 the anomaly and parameters to the server 113. The server 113 can also report this to the OEM, which can then prepare a software fix to fix the reported problem. If the software fix is not already forthcoming, it may take the OEM some time to clarify and publish the solution to the reported issue.

Since sending the parameters may result in an ATSC update being sent, the vehicle 141 in this example determines at 207 whether an ATSC update has been received via the ATSC receiver 145. This could be a road irregularity notification or a software update to correct an identified problem. Since the update or notification might take some time to process, the vehicle 141 may wait at 209 and continue to check for the ATSC update. Or the vehicle 141 can simply receive the ATSC update as soon as it is available without repeated checking.

If the prescribed time period elapses, it is possible that an error has occurred that prevents the ATSC update, or the software fix is not yet available. Accordingly, in this example, the vehicle 141 communicates directly with the update server 113 at 211 . When the server 113 notifies the vehicle 141 at 213 that the update has been processed, the vehicle 141 may delete the local anomaly reporting data at 217 . The same deletion may occur when the vehicle 141 receives the ATSC update it expects based on the data sent. In other examples, if the vehicle reports an anomaly, it can simply delete the data and the server will fix the anomaly in due course. In such an example, the vehicle need not receive an update directly from the server and/or report back to the server.

If there was a problem with the update or the server 113 needs the data again, the vehicle 141 can resend the data at 215 and repeat the process. In this example, since the server 113 may require time to process the update and may require additional time to send the update via the station 101, the vehicle 141 disconnects without necessarily receiving an initial acknowledgment of the update processing since the vehicle 141 can still receive the ATSC broadcast as an acknowledgment once the update has been processed.

3 12 shows an illustrative process for handling reported anomalies, performed by server 113, for example. In this example, the server 113 receives 301 the notification of the anomaly. Since more than one vehicle 121, 131, 141 may report the same anomaly, particularly with respect to road and traffic anomalies, the server 113 determines at 303 whether the anomaly has already been processed (ie previously received). If the anomaly has already been processed, the server 113 stores 309 a report for the reporting vehicle if the vehicle 141 communicates with the server to determine whether the report has been processed.

If the notification has not already been processed, the server 113 processes the notification and sets 305 parameters corresponding to the vehicles to which the update/broadcast applies. This may also include obtaining a software update for distribution, identifying vehicle parameters for a software update, defining a geofence around a road irregularity, etc. The server 113 may further include a duration for the broadcast and/or applicable times of day and days of the week for the broadcast, and then the server 113 sends the instructions and data at 307 to the ATSC station 101.

4 FIG. 10 shows an illustrative process for sending an ATSC broadcast that may be performed by station 101, for example. In this example, the station 101 receives at 401 the broadcast data and any applicable parameters from the server 113. Because the data may need to be converted for broadcast, such as including a broadcast header, the station 101 at 303 can choose any receive parameters set that should be included in the header file. This may include, for example, geographic parameters, driving direction parameters, or vehicle VIN or ESN parameters.

The station then transmits the data at 405 as part of an ATSC broadcast. If the broadcast has a defined period of time at 407 that has not expired, the station 101 may wait at 409 a predefined period of time and then resend the broadcast. Because station 101 may be required to broadcast a large number of records, station 101 may require a wait time between broadcasts, which may also be defined in terms of a type of broadcast - e.g. eg, an emergency broadcast will run until the emergency subsides, but a pothole notification may only be broadcast every X minutes unless there are no other broadcasts pending. Once the predefined period of time expires or once the anomaly subsides, the station 101 may remove the broadcast at 411 from a broadcast queue.

the 5A and 5B 12 show illustrative processes for preparing broadcasts about various illustrative anomalies that may be performed by server 113, for example. If the server 113 receives a certain anomaly, the server 113 can parameterize the anomaly in order to define which vehicles 121, 131, 141 should actually process a data broadcast sent by the station 101. While illustrative road irregularities and software irregularities in the 5A or. 5B are shown, it should be understood that any type of anomaly that could be detected, defined for reporting and for which reporting to multiple vehicles might be appropriate could be handled in a similar manner.

In 5A at 501, the server 113 receives a notification of a road irregularity. This can include, for example, a road hazard (pothole), a new road, a road closure, a roadworks area, a hazardous condition, weather conditions, etc. In this example, the server 113 determines 503 an applicable geofence radius (or perimeter). For example, a pothole may have a limited one mile radius and associated directionality (given the likely limited impact on most traffic), while a massive construction detour might have a 5-10 mile radius associated therewith, giving drivers time to change of a route before reaching a traffic jam.

The server 113 then sets 505 any geographic parameters to be associated with the anomaly. This may include, for example, specificity, processing limits and any other relevant information. For example, not only can a pothole have its radius set to 0.5 miles, but the server 113 can also set a specific road parameter so that only vehicles within half a mile of the pothole traveling in a given direction and on the given road that will process data related to the pothole. Server 113 may also set 507 a type-flag that defines a type of anomaly (which is then included in the broadcast). Certain vehicle owners may wish to ignore certain messages to avoid flooding, for example if the anomaly is weather and rain type, some vehicle owners may ignore that anomaly (they don't care if they drive through rain) while others may not do this.

The server 113 then prepares 309 a data packet that may include the identification of the anomaly, as well as any processing parameters and any proposed action to avoid the anomaly. This can be a detailed plan, or it can be as simple as "Avoid driving in the left-most lane between 11 and 12 Mile Road on Telegraph Road to avoid a pothole". If the anomaly is large, navigation systems may be able to guide around it, but if the anomaly is highly localized, GPS coordinates may be insufficient to determine a vehicle's location relative to the anomaly, and thus the Server provide additional instructions to avoid the localized anomaly.

In 5B at 511, the server 113 receives a notification of a software anomaly. This may include, for example, a software malfunction, an error in a display, or any other reported software error. The error message may also include a software version and/or vehicle system to which the software applies (e.g., software error in version 1.02 of heater control software for a vehicle heated seat module).

The server 113 then determines 513 whether a patch or update is available. Even in the absence of a patch, the server 113 may report the error to vehicle owners who have the affected software version installed via email or other method, which the server 113 may also determine at 513 . The server 113 may then set 515 vehicle parameters, such as vehicles having the particular module and/or software version. This could also include a VIN or an ESN parameter indicating a set of vehicles if the vehicles to which the update was applicable were identifiable through such identification usage.

The server 113 may include 517 a software patch or other data that may be used to obtain software update or patch software. For example, if the software cannot be corrected via an over-the-air update, the correction could include instructions (which may be delivered to a vehicle occupant) to schedule a visit to the dealership. Finally, server 113 prepares the software package for delivery along with broadcast instructions at 519 and then sends the data to station 101.

6 12 shows an illustrative example of a process for handling received broadcasts, which may be performed by the vehicle 121, for example. In this example at 601, the vehicle 121 receives the ATSC broadcast. Because a vehicle 121 receives all ATSC broadcasts while within a broadcast region, the vehicle 121 may need to have a process for handling the broadcasts to avoid wasting processing cycles and energy in handling non-applicable broadcasts.

If the broadcast at 603 includes geographic parameters, the vehicle 121 treats the data as a traffic irregularity incident. If the broadcast at 605 includes vehicle identification parameters or system or software parameters, the vehicle 121 treats the data as a software problem notification. Other parameters could also be used to identify other types of broadcasts as appropriate.

If the data is a traffic anomaly, the vehicle 121 determines whether the present GPS coordinates for the vehicle 121 match a coordinate set defined for the traffic broadcast at 607 . In other cases, a vehicle direction of travel or a street may be used to match or a determination of whether any applicable coordinates are along a route of the vehicle. If there is a recent match (i.e., the broadcast applies to the vehicle immediately), the vehicle 121 sends 615 the updated data to the vehicle navigation system.

Not having a current match does not guarantee that the data will never apply to that particular vehicle as the data relates to a nearby road condition and the vehicle is driving. Accordingly, the vehicle 121 determines whether a current route (or direction of travel and road) will place the vehicle 121 in the relevant coordinate set. If there is a route match at 609, the vehicle 121 may queue the data at 613 for use if the current GPS data matches, or the vehicle 121 may ignore the data at 611 otherwise.

If the data relates to a software update, the vehicle 121 determines at 617 whether the vehicle 121 includes the relevant identified software version or the relevant identified software module. If not, the vehicle 121 ignores the data at 619, but if there is a match, the vehicle 121 sends the data at 621 to a software update process for editing if necessary. If no software is present, the vehicle 121 can send the data to a notification process, for example to notify the driver that a fix is needed but is not available over the air.

In addition to the preceding illustrative examples, there are myriad other functions that can be achieved based on the 1:n model of ATSC broadcast delivery. While this model presents certain challenges as there is no direct two-way communication with a receiving entity (although that entity can report back later), the model also allows for some unique ways to inexpensively bulk transfer information, collect data, and adaptively manage specific situations , where direct 1:1 communication can consume too much bandwidth and/or be prohibitively expensive.

For example, with the advent of autonomous vehicles, thousands of unmanned vehicles will be deployed on the roads. 7 12 shows an illustrative example of autonomous vehicles 701 serving multiple zones 703, 705, 707 at a time when cellular networks 709, 711, and 713 are down (e.g., due to natural phenomena). Because autonomous vehicles 701 receive information and instructions from the cloud, and this transmission often occurs over a cellular communication medium, the loss of these networks 709, 711 and 713 means a total or partial loss of control over the vehicles 701.

At the same time, since they are unmanned vehicles, in such a situation they are both very useful for transport purposes and they can also be exposed to greater dangers since, at least if they have no passengers, there will be no people on board. Thus, a loss of cellular communication may provide a loss of communication with a fleet of useful vehicles 701 at a time when those vehicles 701 would be among the most useful vehicles 701 on the roads. And in a situation where most or all vehicles 701 are autonomous, this can mean a near loss of an entire fleet of almost all or all vehicles 701 on the roads.

Transmitting ATSC broadcasts can be used to assist in such a situation, since these vehicles 701 can be instructed via a direct broadcast from an ATSC transmitter 715 to go to a specific on-demand destination. This will often have the effect of mass deployment of vehicles 701 since the cellular networks in this scenario go down, the Vehicles 701 may not have the ability to report arrivals or the receipt of instructions, but it is also the case that many Vehicles 701 will have their location known shortly before a cellular disruption, based on either an intended destination or a current one location at rest.

Then affected areas can be divided into zones 701, 703, 705. These vehicles 701 in each zone can be assigned a specific task. Furthermore, it is possible to determine zones based on current GPS coordinates, which may still be known to vehicles. In either case, or using both concepts, for example, a subset of vehicles 701 near an evacuation site may be tasked with traveling to the evacuation site to evacuate people. While this may result in sending additional vehicles 701 to a given location out of the utmost caution and with the expectation that not all vehicles 701 may arrive, the outcome of over-provisioning vehicles 701 for evacuation is certainly better than leaving these vehicles 701 idling without instructions.

As vehicles 701 leave a given location, messages (e.g., from a human over a radio) may be sent back to feed a coordination process running on a government server 721 or other suitable coordination server that controls all vehicles 701 that are traveling to or located at the now evacuated location and can send these vehicles 701 to one or more locations. In this way, the autonomous vehicles 701 can continue to support evacuation and transportation, although direct communication with these vehicles 701 is not currently available. Because the vehicle 701 may be able to, based on onboard computing and vehicle-to-vehicle (Car2Car) and vehicle-to-infrastructure (V2I) communications, or a portion of those communications when portions thereof are unavailable, To drive and navigate to a destination, the lack of cellular communication need not be a total impediment to autonomous vehicle commissioning and driving.

8th shows an illustrative process for deploying an autonomous vehicle using broadcasts. In this illustrative example, a coordination process is executable by city server 721, for example. The server 721 detects or receives 801 an indication of a cellular outage for some or all of the area for which the server 721 is responsible. The server 721 may not normally have control or rights to commission vehicles 701 except in an emergency situation; however, if a cellular network fails and/or if an emergency broadcast is received from a vehicle 701, the vehicle 701 may enter a mode that allows commands from the city server 721 to direct destinations of the vehicle.

For example, if the power failure was due to a temporary outage, or if the distress signal was a test, the vehicle 701 would not have a problem accepting such commands, since no commands would be received. Furthermore, vehicles 701 may wait until a current route is completed or until no passengers remain before changing states to accept such commands, so that there may be additional assurances that a currently occupied vehicle 701 will not be assigned a new task. while it already serves as a transport.

If the server 721 is an OEM server or a server that already has control privileges, the coordination of which vehicles 701 to assign a new task to can be done based on a knowledge of which vehicles 701 have already been used or have one Collection has been requested. The city server 721 could also have access to such a feed if desired, and so could further ensure that no vehicles 701 are fed using a different purpose until an appropriate time (e.g., no passengers present).

The server 721 can then formulate a deployment strategy based on known evacuation areas, for example. This may involve any type of appropriate prioritization that would typically be reserved for evacuation scenario planners. Formulating the deployment at 803 may include, for example, defining geofences around known evacuation points to ensure that an appropriate number of known vehicles 701 receive a given assistance command. In some cases this may be based on overall vehicle locations (e.g., setting the geofence at a perimeter based on encompassing the 50 vehicles 701 closest to the location requiring 40 vehicles) and in other cases this may be a Assumption based on a typical vehicle density when the exact locations of all vehicles 701 are not known or cannot be known (e.g. typically 10 vehicles 701 per block in a city, setting the fence at a 2x2 block grid with the evacuation point in the center and assuming about 40 vehicles 701 are available).

Fence formulation is a dynamic process that can be repeated as different points are evacuated. Certain vehicles 701 may be dispatched to additional points, and that request may even come from a zone or geofence that is not within the fence for those points. For example, a subset of vehicles 701 may be instructed to begin traveling to another point that might otherwise lack vehicles.

Although all vehicles 701 within a fence receive the same message based on being within the fence, these reassignments could be accomplished through a relatively simple process. For example, vehicles 701 with certain characteristics (e.g., high capacity, high fuel range, off-road capability) could be sent to remote regions and would receive that other command based on the vehicle's 701 characteristic as well as the geographic characteristic of being within a geofence. receive.

In another example, it could be extrapolated or known that there are 200 vehicles 701 in an area that only needs 100 vehicles 701 at evacuation point A, and there would be some remote areas that only had 20 vehicles 701 but 30 vehicles 701 each needed at evacuation points B and C.

One option could be to send all 200 vehicles 701 to evacuation point A, and then to repurpose the vehicles 701 that were not used after the evacuation at point A was completed. However, this would involve sending far more vehicles 701 to Evacuation Point A than required. By way of example only, an alternative solution would be to send an instruction set to the 200 vehicles, the instruction would include two alternative locations B and C and an instruction for a given vehicle 701 to run a randomizer.

It is assumed that it was deemed acceptable to send 150 vehicles 701 to the larger evacuation point A (in case some vehicles 701 fail) and 25 each to the outer points B and C. This would give each point 150% of the required vehicles 701 heading towards each location.

In this example, each vehicle 701 could randomize between 1 and 4. If vehicle 701 produces a 1 or 2 it would follow the primary directions to the large evacuation point A, if vehicle 701 produces a 3 it would go to point B and if it produces a 4 it would go to point C . This would generally lead to a rough approximation of the correct number of vehicles 701 going to each point. The randomization would likely lead to some deviations (e.g. 154 vehicles 701 to A, 52 vehicles 701 to B, 44 vehicles 701 to C), but with a larger number of vehicles 701 this would flatten out and each location will already be 150% of actual demand sent, so some variance should still have the correct minimum number of vehicles 701 going to a given location.

This allows for some granularity of control, although direct control of the vehicles 701 cannot be achieved. Further, if the large zone (200 vehicle zone) has vehicles 701 distributed over the entire area, vehicles 701 located closer to B or closer to C could be exempted from achieving the further result. This would be accomplished, for example, by instructing a vehicle 701 that if it generates C as the target based on randomization but is in a "non-C-choice" fence, it instead re-randomizes or specifically A or B would be assigned. B may be a better choice since the probability of a false positive for B or C would be equal (25%) and thus an equal percentage of vehicles 701 in each region would generate false positives but their targets without direct control or knowledge of the other vehicles would exchange.

Weighting or other constraints could be used to vary the randomness so that vehicles 701 in the large zone that would also be closest to B would have the highest probability of being randomized to B, and the same is true with C. The ATSC Instructions don't even need to know where vehicles 701 actually are to accomplish this; a weight can be assigned simply based on current GPS coordinates so that a given vehicle 701 can determine the correct weight for that vehicle 701 .

More accurate control can be achieved when more information about vehicle locations is known precisely, but in certain weather-related situations or even urban urban canyons, it may have been difficult to know exactly where each vehicle 701 was before contact was lost, and thus, simply knowing that there are 200 vehicles 701 in Zone A might constitute sufficient information to use some of the techniques provided herein and the like.

If the exact location of each vehicle 701 was known, the server 721 could simply redraw the zones to place the correct number of vehicles 701 in the zones serving B and C (e.g., expand the zones to include B and C to enclose those specific vehicles).

After formulating a planned deployment, including any variations such as the foregoing and the like, the server 721 may direct the ATSC transmitter 715 (or the station serving the transmitter) to broadcast vehicle instructions 701 . Using the previous example for evacuation points A, B and C and the corresponding zones A, B and C, the instructions for all zones could be included in the transmission. Since the instructions can be addressed based on a given vehicle's 701 GPS coordinates, each vehicle 701 receives all of the instructions and simply discards the irrelevant instructions (or queues them for review after a current instruction set is completed). The selection of which instructions to follow may be based on parameters such as GPS coordinates, characteristics of the vehicle 701 (capacity, off-road capability, fuel range, body color, etc.), or other appropriate parameters provided by the server 721 with a given set of instructions are linked. If a vehicle's state set (previous parameters and the like) matches those assigned to a set of instructions, these are the instructions that vehicle 701 will execute.

The ATSC transmission may continue periodically and when a site (e.g., A) has completed 807 the evacuation, the server 721 may formulate a new mission based on all vehicles 701 that are now available and that are not serving either A had to or have completed the delivery of evacuees. The feedback may need to come from someone at Site A or via some other indicator, but the server 721 can incorporate that feedback and send a new set of instructions, which may include reallocation of zones as needed. Any vehicle 701 to which the new instructions apply and which is not currently evacuating people (i.e., has passengers on board) may execute the new instructions based on the parameter match as above. This can provide a level of fleet management even though direct contact with the fleet may have been lost. If it is indicated at 809 that all evacuations are complete, the server 721 may formulate and send a set of instructions directing the vehicles 701 to appropriate cover for the duration of the lost contact. Certain coverage locations, such as designated covered parking lots, can provide localized direct communication with vehicles 701 sheltering there, and this can allow server 721 to re-evaluate resource allocation within an area if those vehicles 701 are needed again , before the 709, 711, 713 cellular networks come back online. Because the localized communication provides direct communication, the server 721 can first send each vehicle 701 a specific instruction set (when the vehicles 701 are deployed again) and then ATSC transmissions can continue until the vehicles 701 are sent back to cover will.

It is also possible that multiple ATSC transmitters may cover different regions and the selection of which instructions to transmit via which transmitters may be based on a correlation of geographic perimeters associated with instructions compared to known coverage areas of a given ATSC transmitter. based. This could lead to some overlap in transmission, but vehicles 701 ultimately decide which instructions to follow, and so receiving duplicate instructions should not pose a significant challenge. This can be mitigated by having each vehicle 701 with an already assigned task ignore other instructions until either that task is completed or an instruction is received with, for example, an override parameter indicating that the vehicle 701 should abort a current task and die should execute override instruction.

9 FIG. 7 shows an illustrative process for processing a mission, executable by a vehicle 701, for example. As previously described, a given vehicle 701 may receive 901 an ATSC broadcast that includes more instructions than those provided for the given vehicle 701 . The server 721 may have a parameter set (one or more) assigned to each instruction set and the vehicle 701 may consider different parameter sets compared to its own state set (e.g., location, properties, even fuel or other dynamic properties) to decide which statements to execute based on matching parameters.

Directions may even have parameters based on remaining driveable distance, for example. Using the example of points A, B, C, if a vehicle 701 were in zone A and was instructed to go to point C but did not have sufficient remaining travel distance, the vehicle 701 could ignore that instruction and issue an instruction new select which, apart from C, is the closest match (B or A).

The server 721 may not associate parameters such as travel distance with the initial selection of an order set since the server 721 does not know how far a given vehicle 701 is from an evacuation point. But once the vehicle 701 has selected the phrase, the vehicle 701 can make that determination by knowing the evacuation point, its current location, and a recent destination. In another option, the selection parameter could take this into account by providing the vehicle 701 with evacuation and destination coordinates (where the evacuees will be dropped off), and the vehicle 701 having instructions to use this pair of coordinates to determine whether the vehicle 701 is a such a trip prior to selecting this instruction set.

The vehicle 701 may discard or queue instructions that are not currently being executed at 903 . If the currently accepted instruction includes one or more routes to be executed by the vehicle 701 at 905 , the vehicle 701 executes those routes at 907 . For example, some vehicles 701 may receive an order to remain in place, leaving them as a resource for whatever local needs arise without exhausting their fuel supply by moving (from that vehicle's perspective) to a far away location for remote evacuation points.

10 Figure 12 shows an illustrative process for feeding an insert to another purpose. As previously noted, when the evacuation of a given evacuation point is complete, some form of feedback can be used to inform the server 721 that the evacuation at 1001 is complete. This can be, for example, radio communication between two people, one of whom enters the data into a server, radio communication with the server 721 indicating that the evacuation is complete (e.g. voice recognition, coded transmission, etc.), or even an or multiple vehicles 701 reporting success when those vehicles 701 enter a zone where cellular communication still exists and direct communication with a vehicle 701 can be achieved again.

At this point, the server 721 may need to formulate a new evacuation plan to account for remaining evacuation points. Since the server 721 may have sent a number of additional vehicles 721 to the evacuation site, the server 721 may send a brief termination instruction to the vehicles 701 in a given zone, which may result in those vehicles 701 waiting on the spot instead to let them all continue to the evacuation point. Whether or not this can be done can be determined, for example, based on whether it is easier to redeploy these vehicles 701 based on assumptions about their current location or knowing that they all start at the known location of the evacuation zone .

In such a case, the vehicles 701 may be programmed to ignore new orders while a present order is being executed (since the vehicle 701 is unaware that the evacuation is complete). In this case, the command may be an override command that is received by all vehicles, accepted by vehicles 701 in a given zone, and then executed (instead of being queued or discarded) based on the override parameter, and that at absence of the override parameter would not have occurred, otherwise the instruction would have been queued or discarded.

While the vehicles 701 wait (if necessary), the server 721 identifies at 1005 new or different evacuation zones or points to which the vehicles 701 can travel, and then at 803 (similar to 803) formulates a new evacuation plan and transmits that plan at 805 .

11 shows an illustrative process for provisioning a wireless service provider using broadcasts. This process could be performed by a server 721, although in that case the process would more often be performed by an OEM server 721 than a city government server. However, for purposes of illustration, it is not necessarily important who provides the server, but simply that a server 721 in communication with an ATSC transmitter 715 (or a controller of the transmitter) can direct the transmission of the various instructions and requests discussed herein.

In this example, server 721 distributes instructions for reprogramming cellular profiles in response to a detected error in one or more cellular networks. For example, in the previous example of a weather-related incident that disables one or more cellular networks, prior to using ATSC technology to send instructions to vehicles 701, server 721 (or another server) may attempt a process such as this example or the like to maintain direct control over the vehicles 701 when possible. Although not a necessary step prior to sending ATSC evacuation instructions, direct control over the vehicles 701 may facilitate the steering of those vehicles 701; so if a simple attempt to reconfigure lost cellular connections can be made while the server 721 is formulating an evacuation plan, for example, it may be worth sending in some cases.

Certain failures can occur in cellular networks, involving for example routing from a network A to a backend server, a complete failure of network A requiring the use of another network B, etc. This problem has been recognized before, and suggestions for solving the problem typically involve using a decreasing signal at A to receive new information about B, allowing a vehicle 701 to transition when the signal at A becomes unusable. The problem with such a solution is that if network A is suddenly and unexpectedly lost (e.g. a tower is knocked down or disabled), no planning has taken place and therefore the vehicle 701 is simply left without a connection.

Because the vehicle 701 lacks an active connection, the vehicle 701 has no way to request reprogramming or any other communication, or even to notify the network that it has lost connection (instead of simply having been parked and powered off, for example). ). Thus, for example, in unexpected disconnect and network disruption situations, the previous systems for planning ahead for a disconnect based on a decreasing signal or even an impending known signal loss do not provide much useful support.

In this example, if the server 721 detects or is notified of a network failure at 1101, the server 721 may also determine or be notified of what type of failure has occurred. For example, the server 721 can be notified if the error is due to a disabled network or to a routing malfunction between the wireless network and the backend. In the first example, the server 721 determines a new bearer, and in the latter example, the server 721 determines a new access point name (APN) for the same network, allowing different routing if the previous connection between the wireless network and the backend does not work. These are determined at 1103 and may include all vehicles and not just AV.

For example, in order not to overload a new network, the server 721 can determine a variety of alternatives for a lost network so that all network traffic is not immediately moved to a new network. In such a case, the server 721 shares the new network profiles as before based on a parameter at 1105. This may be based, for example, on coverage areas that have better or worse different networks (e.g., network D spans coverage areas of networks E and F , network D fails, server 721 can instruct vehicles 701 in areas better served by E to use E, and the same is true for F). The parameters may also include, for example, a parameter that the vehicle 701 primarily used in, or was previously connected to, network D (or whichever network was faulted). This may include, for example, the server 721 broadcasting new network profiles to vehicles in geofencing areas to switch to a new network assigned to an area. Each geofence can have a new network and a profile assigned to it, and this can accommodate vehicles that are otherwise unaware of a given alternative network and otherwise lack a profile for that network.

Server 721 may provide alternate networks in any reasonable manner, which does not preclude all vehicles 701 being instructed to move to a single new network. The server 721 instructs the sender 715 at 1107 to send the reprogramming instructions.

In this example, since vehicles 701 that lost communication with server 721 now regain communication, server 721 may actually receive feedback at 1109 once vehicles 701 connect to the new network. This allows the server 721 to at least partially ensure that the reprogramming instructions were successful, as well as to determine if a particular reprogramming instruction is not working or a new proposed network does not appear to be working.

The server 721 can know how many vehicles 701 it lost connection to when a network went down, which allows the server 721 to determine to some extent the success of any reprogramming instruction. In this example, the server 721 checks 1111 whether a certain percentage of lost vehicles 701 are back online via a new network. That is, using the example of the D, E, F networks, the server 721 may lose communication with 5000 vehicles 701 if the network D fails. Based on geographical capacity, network capacity, etc., the server 721 can send instructions to 2000 vehicles 701 to switch to network E and to 3000 vehicles 701 to switch to network F. Since the server may not have control over how many vehicles it sends a message to via ATSC since it is broadcast, geofencing or randomization may be included in reprogramming instructions, as previously discussed. For example, the server can assign profiles based on geofences that should cover more or less 2000 or 3000 vehicles respectively and/or could send instructions to each vehicle to randomize between 1 and 5, where 1 and 2 go to network E and 3 -5 go to network F.

When they connect to the network, the vehicles 701 reestablish communication with the server, and so the server 721 can determine a percentage of the vehicles 701 that have reconnected. In this example, at a certain number, the percentage may be predefined as acceptable, which may account for the likelihood that certain vehicles 701 were simply turned off or otherwise intentionally disconnected. For example, when the percentage at 1111 reaches 90 percent for network E, server 721 may stop broadcasting instructions to network E for delivery to other purposes.

At the same time, the reconnection percentage for network F can currently be as low as 30 percent. In such a case, the server 721 may wait 1113 for a timeout delay and then either resend a broadcast and/or reallocate some percentage of the vehicles 701 instructed to connect to F to E. Thus, if E can handle the further increased load and the server 721 knows that the change to E was largely successful, the server 721 can at 1115 transfer the vehicles 701 that have not yet successfully connected to F to E. Additionally or alternatively, the server 721 may rebroadcast the initial instruction to connect to F because a number of vehicles 701 received the instruction for some other reason (e.g., interference caused by urban canyons, being underground, etc.). caused) cannot have received. Once an appropriate percentage of all vehicles 701 are reconnected, the server 721 may stop broadcasting 1117 instructions for any new networks or access point names.

12 Figure 12 shows an illustrative process for editing a cellular provider's provisioning. This example process may be performed by a vehicle 701 receiving instructions from a remote server 721, for example.

In this illustrative example, the vehicle 701 receives an ATSC message specifying a new cellular network or access point name that the vehicle 701 could use. Since the server 721 coordinating the message delivery can send this information to all vehicles 701 that might be affected by a separation but might not have been affected, the message may include one or more parameters (e.g. GPS location, identifications of a previous connection now broken etc.) for application of the message and the vehicle 701 may determine at 1203 whether the relevant parameter applies.

Since the parameter can simply be a set GPS location, such as a geofence, the ATSC transmitter 715 can cover an area larger than an affected area and thus the message as only applicable to vehicles 701 in the affected area can mark an additional consideration by driving tool 701 is whether the vehicle 701 at 1205 currently has a broken connection. That is, even if the server 721 does not identify the broken links in the message, the vehicle 701 may be in the affected area (and thus receive and process the message) but may not have a broken link, which the vehicle 701 would cause to discard the message at 1207. In other examples, the server 721 may include an identification of the broken connection in the message so that only vehicles 701 previously connected to the broken connection process the message in the first place without discarding it. If the message at 1209 includes a new access point name, the vehicle 701 receiving and processing the message can switch a communication profile of that vehicle 701 to use the new access point name at 1211 . Alternatively, if the message includes a new cellular profile that defines a new carrier to be used at 1213, the vehicle 701 can use the information to reprogram the telematics control unit (TCU) at 1215 to use the newly identified network . This may include using an identified new access point name (APN) at 1217 . Other communication alternatives may also be instructed and these are merely examples of multiple alternatives and their use.

13A and 13B show illustrative processes for collecting data using broadcasts and responses. This is a general concept that illustrates how ATSC technology can be used to collect a variety of data from vehicles 701 within a broadcast area of the ATSC transmitter.

For many reasons, an OEM or other authorized party may wish to collect a specific item or items of data from multiple vehicles 701 at once. For example, if it has started snowing, the interested party may want to know how many vehicles 701 have reduced speed below 25 miles per hour. To exclude results from Vehicles 701 traveling on low speed limited roads, these roads could serve as an additional parameter and by broadcasting the request to all Vehicles 701 in a broadcast area and receiving responses, virtually any subset of vehicle data for a region, or for certain types of vehicles 701 within the broadcast radius, can be obtained quickly.

The preceding requirement could be formulated in a variety of ways. Several non-limiting examples are provided of how a vehicle 701 would discard or accept and respond to the message. One choice would be to set assumption parameters of Speed <25 mph and Location = any street with a speed limit >25 mph. Then only vehicles 701 with the right speeds and locations would accept the message at all, and those vehicles 701 could report their speeds or the simple fact of driving under 25 mph without further consideration. Reporting could be done via the vehicles' telematics control unit 701 back to the OEM or authorized party.

Another example would be to request the speed of vehicle 701 in the report, but only on roads with speed limits >25 mph. Then all vehicles 701 traveling on roads with speed limits over 25 mph would report their speed. A third example could be to set assumption parameters for "driving more than 10 mph below the known speed limit" which would avoid having to determine which particular roads have lower speed limits below 25 mph and the vehicles 701 could determine (under (assuming they have navigation systems that report the current speed limit or have other access to such data) whether they were driving more than 10 mph below a posted speed limit. This could result in some vehicles reporting 701 driving 15 mph on a 25 mph road, but this can also be useful information. In addition, the message itself could include reporting restrictions that restricted those vehicles 701 from reporting.

Vehicles 701 do not necessarily discard messages that do not apply; you can also queue specific messages based on applicable parameters. For example, if the parameter is dynamic and could be satisfied by the vehicle, the message can be queued for a predetermined period of time or for a message-defined period of time. If the parameter is static (e.g. vehicle type = SUV) and vehicle 701 could not possibly ever satisfy the parameter (e.g. vehicle 701 is not an SUV is and never would be), the message can be discarded.

In the example shown, at 1301 a server 721 receives a data request. This could be from another remote server (e.g., a city service server requests the previous data from an OEM server 721 to measure traffic response to a snow storm) or from another OEM internal system. For example, engineers may be working on a project and need a data point to understand how a current system is being used. The engineers could develop relevant parameters (e.g., vehicles 701 driving in temperature conditions above 90 degrees, vehicles 701 equipped with cooled seats to determine how many of those vehicles 701 used cooled seats at those temperatures) and request them that the server 721 broadcasts such notification requests to vehicles 701 over a large area (such as nationwide) via a plurality of ATSC transmitters 715 .

The server 721 could assign 1303 the relevant parameters for accepting the message and/or relevant parameters for queuing and/or relevant parameters for the vehicle 701 to consider when reporting. The server 721 then directs the plurality of ATSC transmitters 715 to transmit the broadcast, and vehicles 701 receiving the broadcast to which the broadcast applies may report themselves as eligible and as defined by the broadcast.

When a vehicle 701 receives the broadcast at 1307, the vehicle 701 determines at 1309 whether the message or request applies to that vehicle 701 based on the acceptance parameters. Again, this may include, for example, environmental parameters, geographic parameters, vehicle 701 characteristics, and so on. If the parameters are not met, the vehicle 701 may determine at 1311 whether there are queue parameters associated with the message. In some examples, there may be no queuing parameters, but instead, as previously noted, the vehicle 701 may or may not queue a message based on whether the vehicle 701 could meet the acceptance parameters at a later time (e.g., weather or speed could be adverse). (e.g. be achieved, changing the body type of the vehicle 701 could not be achieved).

If the vehicle 701 determines that queuing is not needed, the vehicle 701 may discard the message at 1315 . Otherwise, the vehicle 701 may queue the message at 1317, which may result in the message being processed at a time when the parameter at 1309 is satisfied. Once the message has been processed by the vehicle, at 1313 the vehicle 701 responds to the query in the message, again according to any instructions and/or restrictions specified in the message.

In yet another example use case of ATSC technology, dynamic routing of vehicles 701 from a location may be accomplished in a manner that does not overwhelm networks that may already be suffering from increased traffic. It is common for cellular networks to become overloaded during certain events that require high capacity, such as sporting events. Tens of thousands or hundreds of thousands of additional devices may be attempting to use a network, which can be extremely taxing on network responsiveness.

While all of these people tend to arrive over a longer period of time, they all tend to leave around the same time when the event is over. This means that a network may need to support 100x or 1000x as many data requests for navigation information as it is used to supporting. One solution is to simply let vehicles 701 use their own internal navigation computers, which can provide route guidance even in the absence of an active cellular network, but certain vehicles 701 lack such computers and many other users prefer route guidance that also reflects current traffic conditions indicates, especially when the traffic will be very heavy as in the above scenario. When all of these requests are sent to the network in roughly the same time frame, especially when the requests are not yet completed for reasons such as traffic updates, the network is often unable to respond to the majority of these requests, causing even more slowdowns of vehicle traffic.

Using ATSC technology, it is possible to strategically direct vehicles 701 from one location, provide near real-time traffic reports, and adapt to changing traffic conditions while limiting the load on cellular networks. In some cases, the illustrative embodiments impose very limited or possibly no load on the networks (when vehicles 701 do not report back), in others In those cases, those with some feedback aspects place a limited load on the networks, but far less than if all users were to rely on cellular data for all traffic-related decisions.

For example, if 50,000 vehicles 701 depart from an infrastructure location that does not typically carry as much vehicle traffic, the illustrative embodiments allow for selective routing of those vehicles 701 based on current locations, optimal routes relative to current locations, and even consideration of certain alternative routes that are suitable for some vehicles 701 and not for others (e.g. low bridges).

Even if a single entity unified traffic control in such situations, access to that entity through cellular networks could be extremely restricted. However, in the illustrative embodiments, a unified routing system, such as a city or OEM server 721, may develop exit routes for vehicles 701 based on where those vehicles 701 are currently located. That is, instead of all vehicles 701 being assigned a general preferred route or primary routes to particular major exit thoroughfares (e.g., highways), the server 721 can segment instructions and provide the instructions with geofencing so that a vehicle 701 within a given geofence can provide instructions may receive that are relevant to that vehicle 701 based on that vehicle's location, even if the server 721 does not specifically know that the vehicle 701 is there.

The instructions can be sent for individual geofences or as a large set of map data, where vehicles 701 can selectively receive or use data based on their own determined location data. The solution is described in terms of a formulated coordinated map, where vehicles 701 follow instructions from the map relevant to the vehicle's current coordinate set, although it is understood that single blocks of instructions correlated to coordinate sets are also sent or smaller blocks of map data correlated to sets of coordinates, where a given vehicle 701 would accept, queue, or discard a message based on its current coordinates and/or characteristics.

Since the transmission of the data does not rely on the cellular networks but on a broadcast medium that can reach any number of vehicles 701 at once, the server 721 can also update and rebroadcast map data or instructions as appropriate, provided they are in a communication range of a broadcast. For example, if an accident occurs, the server 721 can quickly reroute vehicles 701 in specific geofences with limited or full map update, providing reactive, coordinated traffic guidance with reasonable assurances that the guidance will include all or most vehicles 701 carrying an ATSC receiver include, will achieve and may be used by them.

Map data may further include guidance based on a type of vehicle 701 or even based on a possible vehicle 701 destination. For example, a major road leading out of the city may lead to two freeways, N and M. When a vehicle 701 enters the N freeway, there may be a better route than when a vehicle 701 enters the M freeway. The data for the exit strategy (subset of the map) would be accepted by all vehicles 701 in geofence X, although some vehicles 701 are heading to M and some vehicles 701 are heading to N.

One option is simply to have vehicles 701 derive their own best route based on the applicable map data (e.g., server 721 recommends roads or roads to avoid to reach M or N). However, a potential problem with this solution would be that if each vehicle 701 chooses the same sub-route, this sub-route would become sub-optimal since, for example, all M traffic would go to sub-route M_1. One way to address any concerns about this question would be to use some of the randomization suggestions set out herein before, where the server 721 calculates, for example, 3 reasonable alternatives and then randomizes a given vehicle 701 on board to select a route. This would have a reasonable expectation of splitting traffic equally between the alternatives and if, for example, one road has twice the capacity of two others, ½ the randomization could be assigned to that road and ¼ to each of the other two roads to account for the differences in the equalize capacity.

It may also make sense to delay some vehicles 701 so that all vehicles 701 do not arrive at M or N at the same time, so that some of the alternative routes may be designed to delay the arrival of vehicles 701 thereon, but this could have the ultimate effect of keeping all traffic moving. Because of solutions like this, drivers can choose not to follow a recommended route (knowing they are on the "slower" route). When vehicles 701 deviate from a planned path, a notification can be made to the server 721 to allow the server 721 to adjust the modeling and provide new solutions to keep traffic as smooth as possible.

Thus, although initially all vehicles 701 in region X are on the same road leading to M and N, based on which highway is needed and based on an appropriate mapping between route alternatives, these vehicles 701 could take directions leading in the sub-routes M_1, M_2, M_3, N_1 and N_2, receive and process. Road indicators that provide the usefulness (or in some cases impossibility) of a given road could also be included, which can help avoid drivers navigating roads that result in a significant increase in traffic and/or an impassable situation. And, when traffic shifts and vehicles 701 become congested or congested in an area, full or partial new routing and new recommendations can be generated by the server 721 and delivered to the vehicles 701 without having to be considered Whether the cellular networks are congested as a barrier to providing guidance.

Also, in many cities, certain roads are simply temporarily closed and navigation data may not reflect this. To avoid many vehicles 701 taking what appears to be a clever route only to encounter a blocked and impassable road, then having to backtrack and be added to the general flow of traffic again, the map can include such blockages so that navigation systems can take them into account.

14 12 shows an illustrative process for selective traffic routing, executable by server 721, for example. In this example, server 721 plans exit strategies for a variety of exit routes leaving a city based on vehicle type 701, vehicle location, expected traffic, current traffic, ultimate destinations, etc. Ultimate destinations need not be a vehicle's actual destination , but for example a main exit artery where the vehicle 701 prefers to arrive. Given that an ultimate destination is outside of the city, virtually every route out of the city will include such a vein, even if there are a few dozen such veins in all.

Server 721 may determine preferred discharge volumes, for example at 1401, based on road capacity and an expectation or knowledge of where vehicles 701 are generally currently located. Based on appropriate routes for out-of-town traffic, the server 721 may then divide the routes at 1403 in a manner that appropriately accounts for expected traffic flows.

This may include, for example, assigning geographic and/or random parameters to each route at 1405 (e.g., parameters dictating which vehicles 701 should use which route based on where those vehicles 701 are currently located). The server 721 can then send the map data to an ATSC transmitter 715 and instruct 1407 to broadcast the map data.

15 12 shows an illustrative process for handling selective traffic routing, executable by a given vehicle 701, for example. In this example, the vehicle 701 receives the ATSC broadcast while within an ATSC broadcast coverage area. The map data can be received and processed by all vehicles 701 or it can be assumed for the processing of the map data, for example, that the vehicle 701 is located within a geographic boundary that is defined by the broadcast (e.g. a boundary spanning the entire site for which exit routes are designated). If the processing parameter matches at 1503, the vehicle 701 processes the map data, which may include temporarily integrating the map data into the vehicle's onboard navigation set.

If there is no match, the vehicle 701 can discard the data at 1513 or, for example, if the vehicle route includes coordinates that will place the vehicle 701 in the parametric coordinates (making the data applicable), the vehicle 701 can store the data therefor , if and when this occurs.

If the data is for vehicle 701 (eg, vehicle 701 is within parameter limits for processing the data in this example), vehicle 701 may at 1504 access a local record within the map data. That is, if the map data is divided into geofencing locations within the location, the vehicle 701 may be within one of those geofencing locations. If vehicle 701 is within the location, but not at any geofence location within the location for which an exit path is defined (e.g., vehicle 701 is just a local resident conducting local business), it can the vehicle 701 decide to use previous on-board navigation data.

Another way to distinguish between residents and exiting traffic is to associate one or more major exit thoroughfares with exit routes that the server 721 schedules within a given geofence location within the community. These would typically be intermediate destinations for a vehicle 701 leaving the city (e.g., a freeway en route to a home), but most traffic actually leaving the city would likely use one of these thoroughfares. Thus, if a given vehicle 701 receiving the data has a set navigation path that includes one of these thoroughfares, the vehicle 701 is considered to be exiting the city and can know that it is using the data based on the association of the waypoint destination with the exit route used. If a vehicle 701 lacks such a waypoint (or has no defined route), the vehicle 701 may be considered engaged in local travel and may rely on informational data, such as road closures, contained in the map data, but may avoid exit route strategies , to easily get to where the local driver drives within the location.

Other vehicles 701 may not have a specified destination, but may have a "home location" that is out of town, for example. In order to determine the applicability of the exit path strategies to these vehicles 701, the vehicles 701 that do not have an exit path but have a home location outside the city can use the home location for the purpose of determining the applicability of exit path strategies and for selecting a particular stopover ( intended main thoroughfare) as a current target.

Once a vehicle 701 has determined the applicability of a given exit path or exit path set corresponding to the vehicle's current coordinates within the location, the vehicle 701 may at 1505 set a current route according to server-recommended exit paths correlated with that location . This can include, for example, a single recommended route, multiple routes to multiple different waypoints, or even multiple routes to a single waypoint. In the latter case, the vehicle 701 may choose randomly or semi-randomly (or according to some other reasonable strategy) between the plurality of routes, all terminating at the same intermediate location (main thoroughfare).

The vehicle 701 also returns a message to the server 721 at 1507 in some cases. This may or may not be possible depending on the level of cellular traffic, but the vehicle 701 could also send a simple text message or other basic piece of data indicating an intended route that could keep the server 721 informed without using the network Data overload, report. For example, each exit route could simply be assigned a number and the vehicle 701 could report the number of the selected route, so a simple text message of a few characters could be used to report the vehicle's intent and allow the server 721 to update the exit route strategy based on how many vehicles have reported intended use of a given path. Other feedback could come from camera video from cameras installed on the roadside or from helicopter surveillance.

If the server 721 can get feedback, it can quickly determine whether a given path is or will be congested and can take immediate action and rebroadcast to mitigate a situation before it has fully developed. For example, if 100 vehicles 701 intend to use a path that server 721 intended only for 50 vehicles, server 721 could redraw one or more geofences around subsets of roads leading to that path (and thus presumably a subset of these vehicles) and recommend different exit routes via ATSC broadcast. Updated and adaptive recommendations can thus be delivered in bulk and on demand without relying on cellular network delivery.

While the vehicle 701 is traveling along a path, the driver may choose to deviate from the path for whatever reason. If the vehicle 701 stays on the route, there may be nothing to report in order to keep cell phone traffic low and since the server 721 already knows which route for this vehicle 701 was selected. However, if the driver deviates from the path at 1509, the vehicle 701 may report the deviation at 1511 so that the server 721 can take this into account, particularly if there is a mass deviation from a path, which may also tend to indicate that the path is bad or is overcrowded.

16 FIG. 12 shows an illustrative process for tuning an adaptive traffic selective routing model. This is an example of server 721 adjusting the exit path for geofencing locations within a location in response to vehicles 701 reporting various changes in position, lane usage, deviations, etc.

Because the server 721 may not know exactly how many vehicles 701 are at a given geofence location when initial data and exit routes are sent, or how many vehicles 701 choose to use a given route, it may be useful if the server 721 can adapt to report and accommodate any expected traffic overflows. Accordingly, when vehicles 701 report locations or route selection, the server 721 may discontinue exit route modeling, which may involve providing additional exit routes for a geofenced location or reallocating underused exit routes for one location to another location (e.g., a neighboring location) or simply redrawing geofence boundaries as needed for reasons as mentioned herein and the like. The model setting may include vehicle 701 designation for selected exit paths or predictions of whether vehicles 701 will simply report current locations, and if an apparent overflow condition occurs or will occur at 1605, the server 721 may detect the overflow at 1607 by splitting the exit paths set up some manner that suggests alternative exit routing for at least a subset of vehicles 701 likely to result in an overflow.

For example, the server could even detect that a given intersection was predicted to have a 30-vehicle congestion in a single direction when the initial strategy was to reduce that congestion to at most 20 vehicles. The selective rerouting may redraw a boundary such that the last 10 vehicles 701 in line (if and when the line forms, based on where those vehicles 701 are expected to be) are instructed to take a new or different exit path , which prevents these vehicles 701 from having to wait at the intersection. The first 20 vehicles 701 fit the original strategy, but the other (approximately) 10 vehicles 701 can immediately choose a new exit path that will prevent the 30-vehicle congestion from occurring or continuing. While the first 20 vehicles 701 are waiting, even new vehicles 701 entering the boundary for the last 10 vehicles 701 will be included in the new routing, so this should effectively help prevent the traffic congestion continuously until and when the alternatives roads are also congested. The relevant parameters for using the new ways are then set at 1405 (e.g. if the vehicle 701 is at a position where there is an expected traffic jam with 20 cars in front of this vehicle 701 at a traffic light) and the server 721 can instruct the delivery of the updated map data via ATSC at 1407.

17 FIG. 12 shows an illustrative process for editing map data from a selective routing broadcast. Again, this example uses the concept of an overall map that includes specified exit routes for given geofencing locations within the map's location or a location within the map, but a similar concept could extend to a set of instructions, each correlating acceptance parameters for a given one Geofence area in which a receiving vehicle 701 is currently located.

In this example, vehicle 701 receives the overall map at 1701 and determines at 1703 a set of parameters applicable to the vehicle, such as current location, characteristics of vehicle 701 (height, width, etc.), waypoint (main thoroughfare), etc. Below Using the map data and the exit routes assigned to vehicles 701 having the characteristics and location of the object vehicle 701, the vehicle 701 may show one or more recommended exit routes based on the vehicle's current location and the intended waypoint at 1705 .

In this example, as long as the vehicle 701 is following one of the recommended routes, no notification is used, although in either case an initial notification of an intended or existing exit route may be sent. If the vehicle 701 deviates from a recommended exit path at 1707, the vehicle 701 may intend the current location of the vehicle 701 and/or any desired location Report required new exit route at 1709 if an exit route is used. The driver's choice of deviation may also result in a new parameter being applicable at 1711, which may include, for example, entering a new geofencing boundary with different exit routes. If no new parameter is applicable, the vehicle 701 may revert to using standard navigation at 1713, which may still account for road closures or other data indicated by the map data, but which may not rely on any particular server-defined exit path.

In this example, if at any time the navigation system brings the vehicle 701 into a situation where a new parameter applies and/or returns within an applicable parameter of previous data at 1715, the vehicle 701 may provide an updated recommended route based on of the parameter.

For example, a user in geofence X may initially choose to use exit route M_1. This can be reported and the vehicle 701 can start traveling on the exit route M_1. Then the user can decide to make a detour to a grocery store that is not on any exit route but exists within X. The user leaves M_1 and the vehicle 701 reports leaving. Since the user is still within X, the path for X can still be shown, but vehicle 701 uses onboard navigation to navigate to the grocery store, which does not conform to any strategy set by the server.

If the grocery store is within geofence Y, adjacent to X, when the vehicle 701 has entered region Y, the exit route recommendations may be updated (showing recommended routes leading out of town) but the vehicle 701 would still navigate to the grocery store using onboard navigation data. When the user has completed driving to the store, the user can then re-enter a recommended exit route R 1 corresponding to region Y where vehicle 701 is now located and this data could be reported and vehicle 701 could begin relying on the exit strategies for Y and R_1 based on where vehicle 701 is now and based on the path that vehicle 701 is now driving. All of this can be accommodated by the illustrative embodiments with little to no communication between the server 721 and the vehicle 701 and thus the load on the cellular network is very low, although the vehicle 701 (from the driver's point of view) highly relevant and specific information necessary for relevant to its current location and apparent intentions.

18A and 18B show illustrative processes for handling selective alerts. This is a concept that allows vehicle alerts to be broadcast to all vehicles 701 within a broadcast region, but only vehicles 701 that have an alert that needs to process messages. A basic example of this might involve a recall notification, where the server 721 would receive the notification at 1801 and determine that vehicles 701 having certain characteristics (make, model) or certain parts (XYZ braking systems) must accept the message, and so this parameter (property) could be set at 1803 as the acceptance and processing parameter for the message. The server 721 could then instruct the ATSC transceiver to broadcast the message.

A vehicle 701 may then receive the broadcast at 1811 and determine at 1813 whether the vehicle 701 includes the necessary attribute (e.g., make, model, XYZ braking system, etc.) to process the message. If there is no match, the vehicle 701 may discard the message at 1815 . Unless the parameter is a condition that might eventually be met (e.g., current engine temperature plus make and model, where vehicle 701 meets make and model but not current engine temperature), there may be little reason to convert the message into a to queue up.

Also, in this example, it is contemplated that a given occupant (e.g., an owner) may be a condition for delivery of the message, such as all vehicles 701 with the property can edit the message, but then those vehicles can 701 further determine at 1817 whether an owner or other designated recipient (typically identified by a property that the vehicle 701 can determine, e.g., not "Bob Smith" but rather "predefined primary user") in the vehicle 701 is present when the message is received. A user's presence may be determined based on a currently paired or present device corresponding to an owner or primary user, through the use of a camera or other biometric device, or any number of similar methods.

If the user is present, the vehicle 701 may display the message at 1819 on an in-vehicle display. If the user is not present, at 1821 the vehicle 701 may attempt to forward the message to a known user device (e.g., phone). This may also result in the message being queued at 1823 in the vehicle 701 . When a message is queued, if and when a user is later present at 1825 and assuming the message has not expired at 1827, the message may be delivered in the vehicle. Some messages may only be relevant in time and therefore may have an associated timeout so that later delivery of a now irrelevant message does not confuse a user.

19 Figure 12 shows an illustrative process for periodically updating load data. This is another example of using ATSC technology to provide real-time updates on electric vehicle (EV) charging availability. There are a limited number of places in the world where EVs can be charged relative to the number of places where gasoline-powered vehicles 701 can be refueled. Also, EVs take significantly longer to refuel than gasoline vehicles. The combination of these factors may make it desirable to be aware of EV charging availability, which may be limited at any given time, as well as any wait times associated with charging, which may be significant relative to other refueling times.

One possibility is for vehicles 701 to request EV charging updates over a direct connection. This is a periodic solution for real-time updates and also requires a lot of bandwidth overall. Even if this information were transmitted to vehicles individually, the amount of bandwidth consumed by such information worldwide would be persistent and massive. Furthermore, the vehicles 701 would either require too much information or would need to report their locations in order to receive useful information, and either solution consumes additional bandwidth and incurs additional costs.

Using ATSC, the availability of local EV charging can be broadcast to all vehicles 701 in real time at limited cost using no cellular bandwidth. Because only vehicles 701 within the broadcast area receive the information, there is no need for vehicles 701 to report coordinates. In addition, since all availability can be mapped to relevant geographical parameters, a given vehicle 701 can ignore most information that is not geographically relevant. Thus, a single broadcast of all available EV stations for a given broadcast area can be presented, representing the current availability, and the vehicles 701 can decide which information is relevant and which information should be ignored.

Further, this information can be updated as spaces become available and/or reserved, and thus a reasonable near-continuous inventory of locally available charging can be provided on demand with little financial and bandwidth overhead. This can further reduce the load on cellular networks and the vehicles 701 do not have to continually search for and request station information while driving unless they are out of range of any ATSC transmissions and require recharge information.

On the broadcast side of things shows 19 several illustrative processes that can be used to provide EV availability updates. A server 721 can run both processes, where one path is a request path and one path is a push path. In this example, the server 721 may request updated charge/reservation information at 1901 at 1903 every particular time interval. Reservation information can be counted as usage information because the reservation can represent both a holding period and a usage period. Reservations that are not fulfilled are addressed on the other path, but when information is requested in this example, the server 721 treats reserved bays as used bays.

Once the server 721 receives updates from the various EV stations within a broadcast region of a given ATSC transmitter 715 at 1905, the server 721 may adjust parameters at 1907, as discussed below. A single server 721 can handle receiving data from a variety of ATSC broadcast regions, so the server 721 could receive state or even nationwide data, for example, and sort the data at 1906 based on which reporting locations have which ATSC broadcast region. correspond to regions. Since the server 721 can obtain this information over wired network connections in most, if not all, cases, there is less Cost and bandwidth limitations than vehicles 701 requesting this information. And since the server 721 can transmit this information via ATSC, the cellular network can remain largely unloaded.

In the push model, the server 721 may receive 1911 information about a state change at a given station. This may correspond to a completed loading, a nearly completed loading, a completed reservation, a nearly completed reservation, or a cancellation of a reservation. What data is received by the server 721 may depend on how detailed the server 721 is tracking the availability information.

In response to receiving a notification from a station at 1911, the server 721 may set its own internal data at 1913, which may cause a new ATSC notification to be sent or which may modify an upcoming ATSC notification. For example, server 721 may send updates every 5 minutes, 10 minutes, and so on. If the server 721 is not continuously collecting live data until notification, then certain state changes could occur from the time data was collected relative to the time the notification was sent. By having stations report status changes as described above, the accuracy of the reported information may be improved in some cases, depending on data collection and reporting strategies.

Once appropriate data has been collected and when server 721 is about to send a report, server 721 can set acceptance or applicability parameters for the report and/or subsets of data in the report. For example, acceptance parameters can define relative geofences within the data around the various charging stations, and a vehicle 701 can only accept the data if it is within range of one of those stations.

In other cases, the vehicles 701 may have owner-defined acceptance parameters, knowing that the data is only loading data, and the vehicles 701 may only accept and process the data when the vehicle 701 is, for example, within a X distance from a station or at Y% charge. In other cases, all EVs can be notified when a charging station is available within a certain area, in case an owner wants to increase a charge, even if charging is not required immediately, since the owner at least knows that a bay is available at that immediate time and near a vehicle 701 likely to be available for use.

Once any relevant parameters have been set, the server 721 can direct a given ATSC transmitter 715 or a station controlling the transmitter 715 to broadcast the update at 1909 .

20 shows an illustrative process for handling load warnings. A vehicle 701 can receive the ATSC broadcast at 2001 and then choose whether the data is relevant or not. Vehicles 701 that lack EV capability can still receive the message and discard the message since those vehicles 701 do not need the information. Other vehicles 701 in the broadcast area may be too far from a station or not in need of charging and therefore may discard the message at 2005 as well. The message can be queued, but since this information represents real-time data and is constantly changing, queuing for a significant period of time may not be too useful. Nonetheless, queuing is possible under certain circumstances or when needed (e.g., when a vehicle 701 is about to exceed a charging threshold, or when a vehicle 701 is approaching an applicable area but is not yet in the area). .

If at 2003 there is a match of parameters indicating that the vehicle 701 should perform an action, at 2007 the vehicle 701 may present a recommendation or information about local available charging stations. Which data is considered and presented by the vehicle 701 may also depend on the state of charge; for example, vehicles 701 that are only increase candidates, e.g., over 50 percent charge, may only see very close stations, but vehicles 701 that are below 10 percent, for example, may display data for a wider region since those vehicles 701 charge more critically Need to become.

Also in this example, a vehicle 701 may reserve a charging station at 2009 . This may include sending a message to the charging station requesting a reservation. If the vehicle 701 does not want to reserve a station bay at 2009, the vehicle 701 can discard the current record and wait for an update from the next message. Otherwise, the vehicle 701 can enter the station Contact 2011 and try to reserve a bay. If the request is unsuccessful, the vehicle 701 can remove this data from the display (since the bay has been reserved or used) and redisplay the information with the modification.

If the vehicle 701 successfully reserves the charging station at 2013, the vehicle 701 can also report this information directly to the server 721 so that the server 721 can treat this as a state change for that station and update the next data to be sent accordingly. Similar updates can be sent when a vehicle 701 uses a charging station, arrives at a station, finishes charging, etc., so that the server 721 does not necessarily rely on the stations themselves to update states of charge for different stations.

Yet another potential use for ATSC transmission is to broadcast software updates to reach multiple vehicles 701 simultaneously while reducing transmission costs. Vehicles 701 that are powered when an update is broadcast may receive the update, but this could only be a subset of vehicles 701 in a given area. The challenge for broadcast scheduling the update is to determine when an appropriate number of vehicles 701 have received the broadcast update, and then possibly use direct transmission to get the update on vehicles 701 that do not have have the update. Furthermore, while the cost of using ATSC may be much less than communicating directly with the same number of vehicles 701 that a single broadcast would reach, the cost is likely non-zero and therefore there is a desire to have data transmitted only through a tiny percentage of vehicles 701 within a transmission range are needed, especially if it is not known whether these vehicles 701 are online or not.

To balance sending updates as well as measure the success of a transmission, this illustrative example includes a feedback component where vehicles 701 can report success, partial success, failure, installation completion, and so on. The system may not correct errors on the fly, but knowing that a large subset of vehicles 701 in a transmission area did not receive an update could be a good reason to resend the update immediately or consider what the problem might be to fix the perceived problem and then resend the update.

Furthermore, there may be a number of channels associated with ATSC and only a subset of these channels may be used for an update. Broadcasts may use increased channels and increased frequency or decreased amounts of both to accommodate reported updates and issues. The criticality of an update can also dictate usage levels.

For example, if the incomplete download percentage of a broadcast file image is above a first threshold, the server 721 may, without limitation, request increased channel usage for the broadcast and/or increased frequency. Percentages above a lower threshold (indicating more success) can result in a simple increase in frequency. Percentages below a certain threshold (indicating overall success) may result in the server 721 deciding to use direct communication to transmit a file image for vehicles 701 that still do not have the complete file image to complete.

21 12 shows an illustrative process for broadcasting software updates, executable, for example, by a server 721. In this example, the server 721 receives at 2102 an update to go to one or more vehicles 701 within an ATSC broadcast region. If the total number of vehicles 701 known or planned to be within the broadcast region is below a predefined threshold, which depends on the projected cost of the broadcast and the likelihood of reception versus the cost of simply contacting them directly Vehicles 701 may be dependent, the server 721 may set 2103 acceptance and/or execution parameters. As before, these parameters may include characteristics of the vehicle 701 (e.g., make, model, software version, software package, applicable component, etc.) or any other suitable parameter.

The server 721 can then direct the transmission of a file image of the update along with the parameters from an ATSC transmitter. When vehicles 701 receive and process the update, those vehicles 701 may report 2107 to the server, causing the Server 721 can determine how many vehicles 701 received part of the update, how many received the entire update, how many were able to process the update, etc. Since many updates cannot be processed until a vehicle 701 stopped and/or shut down, information about a successful installation may be delayed. Accordingly, although the server 721 may at least be able to measure relatively quickly how many vehicles 701 successfully received an entire file image, the feedback may not be instantaneous in some cases.

When the server 721 receives feedback at 2107, the server 721 can determine reported apparent errors and/or predict error causes based on reported levels of full or partial receipt of the file image. For example, a first error threshold (e.g., 30% + failure to receive a full file image) at 2109 may cause the server 721 to increase channel usage requirements at 2111 and increase broadcast frequency to a first level at 2117 . A second error threshold (e.g., 20%-30% failure to receive a complete file image) at 2113 may cause the server 721 to increase a response rate at 2117, but may not require the use of an additional channel or more. A third threshold (e.g., 10%-20% non-receipt of a full file image) at 2115 may result in an even lower number of repeated requests being set at 2117. If the error rate is below the last threshold, meaning that a predefined acceptable percentage or number of vehicles 701 have reported that they have received the update in full, the server 721 can choose to simply send the remaining vehicles 721 directly instead of at 2119 to contact.

While a server 721 may not know exactly which vehicles 701 are in an ATSC broadcast region at any given time or which vehicles 701 are active, it may have a list of all vehicles 701 scheduled for an update (e.g. a VIN list). When vehicles 701 report, the server 721 can remove those vehicles 701 from the list, and when a low enough percentage or number of vehicles 701 remain, the server 721 can begin contacting those vehicles 701 selectively.

22 shows an illustrative process for editing the update broadcast. In this example, the vehicle 701 receives 2201 an update or patch notification from the server 721. Based on parameters associated with the broadcast (e.g., vehicle make, model, software version, component, etc.), the vehicle determines 701 at 2203 whether any required characteristics of the vehicle 701 match the parameters for acceptance and processing. If not, the vehicle 701 can discard the message at 2205 . Otherwise, the vehicle 701 may record 2207 statistics about the download, such as which channel was used, how long the download took, completeness, etc.

After the vehicle 701 saves the file at 2209 , the vehicle 701 may also report the recorded statistics to the server 721 at 2211 . This may allow the server 721 to make the determined adjustments, as well as to determine whether certain channels provide adequate coverage and whether any channels with problems determinable by the vehicle feedback 701 using a given channel perform worse than reflect other channels. This can also result in changing a broadcast channel. This may also reveal performance issues for a vehicle 701, such as a vehicle 701 receiving poor performance from a channel that is working well for other vehicles 701, which may reveal issues with a vehicle's 701 receiver and provide an opportunity to resolve them fix problems.

23 12 shows an illustrative process for customizing the broadcasting of software updates and addressing identified issues, executable, for example, by a server 721. In this example, the server 721 receives at 2301 feedback from the vehicle 701. This may be, for example, that used by the vehicle Channel 701, which includes download completeness, download time, download speed, etc.

If one or more vehicles 701 using a particular channel are all reporting poor performance statistics for that channel (e.g., below threshold expectations or relative to other channels), the server 721 may attempt to determine at 2303 whether a problem with the given channel. If the channel has a problem, the server 721 can branch 2109 to an error evaluation process.

In other cases, the error may appear on the vehicle side. If a single vehicle or vehicles 701 that do not share a particular connecting characteristic (e.g. same geographic cal area or location near other vehicles, specific hardware, common software versions or firmware versions, etc.) report the problem, the server 721 may determine at 2305 that the problem is with the vehicles 701 themselves (e.g., partial or software failure) and the server 721 may contact 2307 the individual vehicles 701 to attempt to diagnose and fix the problem.

If the server 721 observes that there is a consistent feature among the vehicles 701 experiencing the error, but that other vehicles 701 on the same channel are not experiencing the error (confirm that the error is not related to the channel itself), the server can 721 determine that the problem is with a software version, for example. In such cases, the ATSC transmitter 715 can be used to notify the owners of the vehicles 701 that the vehicles 701 need repairs. The server 721 can contact the manufacturer of the vehicle 701 or part and determine if there is a warning that should be issued at 2309 and then branch at 1801 to warn the owners of the vehicle 701 . If possible, the server 721 can also arrange for the patch for the problem (and/or the current update that the vehicles 701 cannot receive) to be sent directly to those vehicles 701 . If the communication problem can be resolved in time, these vehicles 701 may benefit from another ATSC transmission of the patch that they previously failed to receive.

While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the terms used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, the features of different embodiments can be combined in a logical manner for implementation in order to produce situation-specific variations of embodiments described herein.

According to the present invention, there is provided a system, comprising: a processor configured to: determine a plurality of recommended exit paths for vehicles exiting a location; correlating a plurality of existing geofencing locations within the location with exit routes such that each location has one or more exit routes correlated with it, thereby directing vehicles within a given location via the one or more exit routes recommended for that location be informed; and instructing an ATSC transmitter to broadcast map data for the location, the map data including designations of geofences around the locations and the correlations between the geofencing locations and the exit routes.

According to one embodiment, the processor is further configured to define a parameter for at least one exit route, the parameter indicating the usability of the exit route for vehicles having a particular characteristic corresponding to the parameter, and the map data including the parameter that associated with the exit route for which the parameter is defined.

According to one embodiment, the parameter includes a vehicle height.

According to one embodiment, the parameter includes a vehicle width.

According to one embodiment, the processor is further configured to correlate an intermediate destination with one or more exit routes, the intermediate destination being a predetermined main exit thoroughfare to which a given exit route leads, and the map data including the intermediate destination correlated with a given exit route .

According to one embodiment, the processor is further configured to assign a variable to each of two or more exit routes correlated to a single geofencing location, wherein the two or more exit routes are also correlated to the same waypoint and the map data includes the variable.

According to one embodiment, the processor is configured to assign the variable such that a vehicle randomly choosing between the two or more exit lanes based on randomly generating a number corresponding to the variable statistically selects a given one of the two or more exit lanes selects before other routes of the two or more exit routes, a number of times relative to the predicted throughput of the selected given exit route compared to the other non-selected exit routes.

According to the present invention there is provided a system comprising: a processor configured to: Emp capturing map data for a location from an ATSC broadcast; determining relevant data from the map data based on vehicle parameters compared to parameters associated with one or more subsets of the map data; and deriving an exit strategy for a vehicle including the processor exiting the location en route to an entered destination using a recommended exit path associated with the relevant data. According to one embodiment, the vehicle parameters include vehicle location data. According to one embodiment, the vehicle parameters include vehicle waypoint data indicative of a predefined main exit thoroughfare on which the vehicle will travel, as well as route guidance data to the entered destination.

According to one embodiment, the vehicle parameters include vehicle characteristics. According to one embodiment, the processor is further configured to report use of the recommended exit path to a server responsible for providing the map data.

According to one embodiment, the processor is further configured to derive the exit strategy considering a plurality of exit routes associated with the relevant data based on at least one exit route having associated data indicating that the at least one exit route for a intermediate destination of the vehicle is appropriate, the intermediate destination indicating a predefined main exit thoroughfare on which the vehicle will travel, as indicated by route guidance data to the entered destination.

According to one embodiment, the processor is further configured to derive the exit strategy considering a plurality of exit paths associated with the relevant data based on at least one exit path having associated data indicating that the at least one exit path is based on a vehicle characteristic is suitable for a vehicle.

According to one embodiment, the processor is further configured to derive the exit strategy considering a plurality of exit paths associated with the relevant data based on at least two exit paths having associated data indicating that the at least two exit paths for a suitable waypoint of the vehicle, the waypoint indicating a predefined main exit thoroughfare on which the vehicle will travel, as indicated by route guidance data to the entered destination, the processor being configured to randomly select between the at least two exit routes. According to the present invention, there is provided a system, comprising: a processor configured to: determine a plurality of recommended exit paths for vehicles exiting a location; correlating a plurality of existing geofencing locations within the location with exit routes such that each location has one or more exit routes correlated with it, thereby directing vehicles within a given location via the one or more exit routes recommended for that location to be informed; instructing an ATSC transmitter to broadcast map data for the location, the map data including designations of geofences around the locations and the correlations between the geofencing locations and the exit routes; receiving feedback from a plurality of vehicles indicating those vehicles' intent to use exit paths as indicated by feedback from a given vehicle indicating an exit path selected by that vehicle; determining at least one unexpected use of at least one exit path as indicated by the feedback from the plurality of vehicles; in response to the unexpected usage, discontinuing at least one exit path affected by the unexpected change; and instructing the ATSC transmitter to broadcast updated map data for the location, the map data including designations of geofences around the locations and the correlations between the geofencing locations and the exit routes and including the adjusted at least one exit route.

According to one embodiment, the unexpected usage includes over-usage of an exit path beyond a predefined expected usage determined when the processor previously determined the plurality of exit paths at a point prior to receiving the feedback used to determine the unexpected usage. According to one embodiment, adjusting the exit path includes determining an additional exit path that may be used by a subset of the vehicles reporting an intended use of the exit path determined to be overused and the processor is further configured to do so is to create at least one additional geofence designed to share a portion of the vehicles reporting the intended use of the exit route determined to be overused, the shared Vehicles are advised to use the additional exit route based on a correlation between the additional exit route and the at least one additional geofence, the correlation being defined by the processor and included in the updated map data.

According to one embodiment, the processor is further configured to repeat receipt of feedback, determine unexpected usage, adjust exit routes, and direct transmission of updated map data via broadcast until the processor determines that an appropriate number of vehicles have left the site . According to one embodiment, the processor is configured to determine that the appropriate number of vehicles have left the location based on feedback from vehicles leaving the location.

Claims (15)

System comprising: a processor configured to: determining a plurality of recommended exit paths for vehicles leaving a location; correlating a plurality of existing geofencing locations within the location with exit routes such that each location has one or more exit routes correlated with it, thereby directing vehicles within a given location via the one or more exit routes recommended for that location to be informed; and Directing an ATSC transmitter to broadcast map data for the location, where the map data includes designations of geofences around the locations and the correlations between the geofencing locations and the exit routes. system after claim 1 , the processor being further configured to define a parameter for at least one exit route, the parameter indicating the usability of the exit route for vehicles having a particular characteristic corresponding to the parameter, and the map data including the parameter corresponding to the associated with the exit route for which the parameter is defined. system after claim 2 , where the parameter includes a vehicle height. system after claim 2 , where the parameter includes a vehicle width. system after claim 1 , wherein the processor is further configured to correlate an intermediate destination with one or more exit routes, the intermediate destination being a predetermined main exit thoroughfare to which a given exit route leads, and the map data including the intermediate destination correlated with a given exit route. system after claim 5 wherein the processor is further configured to assign a variable to each of two or more exit routes correlated to a single geofencing location, wherein the two or more exit routes are also correlated to the same waypoint and the map data includes the variable. system after claim 6 wherein the processor is configured to assign the variable such that a vehicle randomly choosing between the two or more exit lanes based on randomly generating a number corresponding to the variable statistically proposes a given one of the two or more exit lanes selects other routes of the two or more exit routes over a number of times relative to the predicted throughput of the selected given exit route compared to the other non-selected exit routes. System comprising: a processor configured to: receiving map data for a location from an ATSC transmission; determining relevant data from the map data based on vehicle parameters compared to parameters associated with one or more subsets of the map data; and deriving an exit strategy for a vehicle including the processor exiting the location en route to an entered destination using a recommended exit path associated with the relevant data. system after claim 8 , wherein the vehicle parameters include vehicle location data. system after claim 8 wherein the vehicle parameters include vehicle waypoint data indicative of a predefined main exit thoroughfare on which the vehicle will travel, such as route guidance data to the entered destination. system after claim 8 , where the vehicle parameters include vehicle characteristics. system after claim 8 , wherein the processor is further configured to enable use of the recommended exit route to a server that is responsible for providing the map data. system after claim 8 , wherein the processor is further configured to derive the exit strategy considering a plurality of exit paths associated with the relevant data based on at least one exit path having associated data indicating that the at least one exit path is for an intermediate destination of the vehicle, the intermediate destination indicating a predefined main exit thoroughfare on which the vehicle will travel, as indicated by route guidance data to the entered destination. system after claim 8 , wherein the processor is further configured to derive the exit strategy considering a plurality of exit paths associated with the relevant data based on at least one exit path having associated data indicating that the at least one exit path based on a Vehicle property is suitable for a vehicle. system after claim 8 , wherein the processor is further configured to derive the exit strategy considering a plurality of exit paths associated with the relevant data based on at least two exit paths having associated data indicating that the at least two exit paths are for an intermediate destination of the vehicle, the intermediate destination indicating a predefined main exit thoroughfare on which the vehicle will travel, as indicated by route guidance data to the entered destination, the processor being configured to randomly select between the at least two exit routes.

Images