Patent Grant
12223833
Digital alerting is being used to improve roadway safety. Cloud based safety systems are being used to track in real time the overlap of alerting zones and vehicles that may benefit from an alerting of a possible roadway hazard. Such cloud based safety systems typically provide digital alerts according to digital alerting rules and in large-scale deployments with many different types of hazards and many different types of digital alerting rules, it can be difficult to know if the digital alerting rules are in fact improving safety on the roadways.
Systems and methods for use in cloud-based digital vehicle alerting are disclosed. In an example, a computer-implemented method for operating a digital alerting system involves determining a post-alert behavior of a vehicle that was provided a digital alert, the post-alert behavior is determined using 1) a time that the digital alert was provided to the vehicle, and 2) vehicle telemetry data that was received at a digital alerting system from the vehicle, modifying a digital alerting rule based on the post-alert behavior, and updating a rules engine of the digital alerting system with the modified digital alerting rule, wherein the rules engine is configured to implement digital alerting rules.
In an example, determining a post-alert behavior includes 1) identifying, in an alert database of the digital alerting system, a timestamp of the digital alert and a vehicle ID of the vehicle that received the digital alert, 2) identifying, in a vehicle tracking database of the digital alerting system, vehicle telemetry data for the vehicle that is later in time than the time that the digital alert was provided to the vehicle, wherein the vehicle telemetry data for the vehicle that is later in time than the time that the digital alert was provided to the vehicle is identified in the vehicle tracking database using the timestamp of the digital alert and the vehicle ID, and 3) using the vehicle telemetry data for the vehicle that is later in time than the time that the digital alert was provided to the vehicle to determine the post-alert behavior.
In an example, determining a post-alert behavior includes 1) identifying, in an alert database of the digital alerting system, a vehicle ID of the vehicle that received the digital alert, wherein the alert database includes alert entries, with each alert entry including an alert ID, a timestamp, and vehicle IDs of alerted vehicles, 2) identifying, in a vehicle tracking database of the digital alerting system, vehicle telemetry data for the vehicle that is later in time than the time that the digital alert was provided to the vehicle, wherein the vehicle tracking database includes vehicle data entries, with each vehicle data entry including a vehicle ID, a timestamp, and location information, wherein the vehicle telemetry data for the vehicle that is later in time than the time that the digital alert was provided to the vehicle is identified in the vehicle tracking database using the vehicle ID, timestamps of the vehicle data entries, and a timestamp of the digital alert, and 3) using the vehicle telemetry data for the vehicle that has a timestamp later in time than the timestamp of the digital alert to determine the post-alert behavior.
In an example, the post-alert behavior of the vehicle is determined using vehicle telemetry data that is later in time than the time that the digital alert was provided to the vehicle.
In an example, the post-alert behavior includes a time interval between the time that the digital alert was provided to the vehicle and a time that the vehicle encountered a hazard that corresponds to the digital alert.
In an example, the post-alert behavior includes deceleration of the vehicle.
In an example, the post-alert behavior includes a change in direction of the vehicle.
In an example, determining a post-alert behavior includes 1) identifying a vehicle ID of the vehicle that received the digital alert, 2) identifying, using the vehicle ID, vehicle telemetry data for the vehicle that is later in time than the time that the digital alert was provided to the vehicle, and 3) using the vehicle telemetry data for the vehicle that is later in time than the time that the digital alert as provided to the vehicle to determine the post-alert behavior.
In an example, modifying the digital alerting rule based on the post-alert behavior includes comparing the post-alert behavior to a safety principle.
In an example, the safety principle is an alert time buffer, which is a target time interval between the time that the digital alert was provided to the vehicle and a time that the vehicle encountered a hazard corresponding to the digital alert.
In an example, the safety principle is a deceleration threshold.
In an example, the safety principle is a change in direction threshold.
In an example, the post-alert behavior of the vehicle is determined using vehicle telemetry data that is later in time than the time that the digital alert was provided to the vehicle, and modifying the digital alerting rule based on the post-alert behavior includes comparing the post-alert behavior to a safety principle.
In an example, the safety principle is a time interval between the time that the digital alert was provided to the vehicle and a time that the vehicle encountered a hazard that corresponds to the digital alert, and wherein modifying the digital alerting rule includes changing a dimension of an alerting zone when the time interval is not met.
In an example, the post-alert behavior includes deceleration of the vehicle and the safety principle is a deceleration threshold.
In an example, modifying the digital alerting rule includes increasing a dimension of an alerting zone when the deceleration exceeds the deceleration threshold.
In an example, the post-alert behavior includes a change in direction of the vehicle and the safety principle is a change in direction threshold.
In an example, modifying the digital alerting rule includes increasing a dimension of an alerting zone when the change in direction of the vehicle exceeds the change in direction threshold.
In an example, modifying the digital alerting rule includes changing a frequency of digital alerting to a vehicle.
In an example, modifying the digital alerting rule includes changing a characteristic of how a digital alert is presented within a vehicle.
In an example, the method further includes generating a new digital alert in response to application of the modified digital alerting rule.
In an example, the digital alerting rule is modified in view of the post-alert behavior and in view of pre-alert behavior.
In an example, the method further includes determining the pre-alert behavior using the time that the digital alert was provided to the vehicle, and vehicle telemetry data that was received at a digital alerting system from the vehicle.
In an example, the method further includes 1) receiving telemetry data that includes a location of an alerting vehicle and an alert status of the alerting vehicle, 2) receiving telemetry data that includes locations and vehicle IDs corresponding to a plurality of non-alerting vehicles, and 3) generating digital alerts for the non-alerting vehicles that are in an alerting zone of the alerting vehicle using the telemetry data.
Also disclosed, is a non-transitory computer readable medium comprising instructions to be executed in a computer system, the instructions when executed in the computer system perform a method involving determining a post-alert behavior of a vehicle that was provided a digital alert, wherein the post-alert behavior is determined using 1) a time that the digital alert was provided to the vehicle, and 2) vehicle telemetry data that was received at a digital alerting system from the vehicle, modifying a digital alerting rule based on the post-alert behavior, and updating a rules engine of the digital alerting system with the modified digital alerting rule, wherein the rules engine is configured to implement digital alerting rules.
Other aspects in accordance with the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrated by way of example of the principles of the invention.
Throughout the description, similar reference numbers may be used to identify similar elements.
It will be readily understood that the components of the embodiments as generally described herein and illustrated in the appended figures could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of various embodiments, as represented in the figures, is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments. While the various aspects of the embodiments are presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by this detailed description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussions of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.
Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.
Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present invention. Thus, the phrases “in one embodiment”, “in an embodiment”, and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
An “alerting zone” may be characterized as a geographical area near an alerting vehicle, near a route of the alerting vehicle, near a safety hazard (e.g., a construction zone, a car accident, a vehicle stopped along the side of the road, a lane closure, a road closure, etc.), or any combination thereof. Examples of an alerting zone may include, but are not limited to, a geographical area that covers a projected path of an alerting vehicle (plus X miles along each side of the path), a geographical area that surrounds an alerting vehicle (by X miles or X feet) and that changes as the alerting vehicle changes locations (e.g., travels along a projected path), or a geographical area that is within an X (X represents a positive value) mile or feet radius of a safety hazard. In some examples, the geographical area of an alerting zone is defined by a set of geographical coordinates that are within a predetermined range of a particular location. In some embodiments, the geographical area may resemble a circle, an oval, a rectangle, a line, or other shape. In an embodiment, an alerting zone is determined by/in a safety cloud of a safety system. An example of a safety system is described in further detail with reference to
The alert tracking system 104 connects to one or more alerting vehicles (AVs), implemented as alerting vehicles AV1108-1, AV2108-2, and AVn 108-n (where n represents an integer of one or more), via, for example, a wireless service provider network (e.g., 3G, 4G, 5G, etc.). Alerting vehicles AV1108-1, AV2108-2, and AVn 108-n connect to the alert tracking system 104 over wireless connections via a first connection 105-1, a second connection 105-2, and an nth connection 105-n, respectively. Examples of the alerting vehicles include emergency vehicles (e.g., a police car, an ambulance, a firetruck, a military vehicle, or the like), safety vehicles (e.g., a construction vehicle, a towing vehicle, or the like), and/or other vehicles/devices that are capable of sending alerting vehicle data and/or connecting to the alert tracking system 104 over a wireless connection via a wireless service provider network. The alerting vehicles AVs 108-1, 108-2, and 108-n may be included in an emergency vehicle fleet (e.g., a fleet of police cars corresponding to a police department, a fleet of firetrucks corresponding to a fire department, etc.). In an embodiment, the AVs 108-1, 108-2, and 108-n are equipped with radios (e.g., a fixed radio and/or a mobile radio) to implement a wireless connection with a wireless service provider network. Although an alerting vehicle may commonly be a vehicle, the alerting vehicle may alternatively be an object with a radio that is capable of sending telemetry data and/or of connecting to the alert tracking system 104.
In an embodiment, alerting vehicles AV1108-1, AV2108-2, and AVn 108-n transmit alerting vehicle telemetry data to the alert tracking system 104. As an example, the alerting vehicle telemetry data may include a vehicle ID that corresponds to the vehicle (e.g., AV1308-1, AV2308-2, or AVn 308-n), location information (e.g., longitude and latitude coordinates) that corresponds to the location of the vehicle, a speed, acceleration, trajectory, direction, and/or azimuth of the vehicle, and an alert ID that indicates whether emergency lights of an alerting vehicle are on/off. In an example, the alerting vehicles transmit alerting vehicle telemetry data to the alert tracking system on regular intervals, such as 2 second intervals. In some examples, the interval may be different depending on the state of the alerting vehicle, for example, in a range of 1-20 second intervals. For example, an alerting vehicle may transmit vehicle telemetry data at shorter time intervals while the vehicle is in an alerting state (e.g., while its emergency lights are on).
The vehicle tracking system 106 connects to one or more vehicles (V), implemented as vehicles V1110-1, V2110-2, and Vn 110-n (n represents an integer greater than one), via a wireless service provider wireless network. Vehicles V1110-1, V2110-2, and Vn 110-n connect to the vehicle tracking system over wireless connections via a first connection 107-1, a second connection 107-2, and an nth connection 107-n, respectively. As described herein, a “vehicle” may refer to a civilian vehicles, a consumer vehicle, or more generally to a vehicle that is not configured as an alerting vehicle. For example, the vehicles V1110-1, V2110-2, and Vn 110-n are considered as “non-alerting” vehicles because the vehicles are not connected to the alert tracking system 104, the vehicles do not have emergency lights or a siren, and/or the vehicles are not configured to transmit an alert signal that indicates, for example, whether or not emergency lights and/or siren are on. The vehicles V1110-1, V2110-2, and Vn 110-n may be included in a vehicle fleet (e.g., a fleet of cars owned by a company). In an embodiment, the vehicles V1110-1, V2110-2, and Vn 110-n are equipped with radios (e.g., a fixed radio and/or a mobile radio) to implement a wireless connection to a wireless service provider network. In an embodiment, vehicles V1110-1, V2110-2, and Vn 110-n periodically send vehicle telemetry data to the vehicle tracking system 106 via the wireless service provider network. In an example, the vehicles transmit vehicle telemetry data to the vehicle tracking system on regular intervals, such as 2 second intervals. In some examples, the interval may be different depending on different factors, for example in a range of 1-20 second intervals. For example, a vehicle may transmit vehicle telemetry data at shorter time intervals while the vehicle is in an alerting zone. In an example, the vehicle telemetry data may include a vehicle ID that corresponds to the vehicle (e.g., V1110-1, V2110-2, or Vn 110-n), location information (e.g., longitude and latitude coordinates) that corresponds to the location of the vehicle, a speed, acceleration, trajectory, direction, and/or azimuth of the vehicle although the vehicle telemetry data may include other types of information. Although vehicles V1110-1, V2110-2, and Vn 110-n may commonly be vehicles, the vehicles V1, V2, and/or Vn may also be an object such as a radio, a smartphone, or other similar device capable of sending telemetry data and/or of connecting to the vehicle tracking system 106.
In some embodiments, the safety cloud 102 receives alerting vehicle telemetry data from alerting vehicles AV1108-1, AV2108-2, and/or AVn 108-n via the alert tracking system 104, and receives vehicle telemetry data from vehicles V1110-1, V2110-2, and/or Vn 110-n via the vehicle tracking system 106. The safety cloud 102 may use the alerting vehicle telemetry data to determine an alerting zone that is associated with an alerting vehicle. The safety cloud 102 may use the vehicle telemetry data to determine whether any non-alerting vehicles are located in the alerting zone, and to determine whether or not to provide a digital alert to vehicles that are located in the alert zone, where the digital alert may indicate that there is a potential hazard nearby.
Cloud based safety systems, similar to the system described with reference to
Examples of how a cloud-based safety system can be used to alert vehicles of potential hazards is described with reference to
An example that illustrates the flow of data within a safety system, which is similar to the safety system 100 described with reference to
In some embodiments, alerting vehicles AV1308-1, AV2308-2, and/or AVn 308-n share alerting vehicle telemetry data directly with the safety cloud 302 (represented by arrow 320), and/or vehicle V1310-1, V2310-2, and/or Vn 310-n share vehicle telemetry data directly with the safety cloud 302 (represented by arrow 322). In such an embodiment, alerting vehicles AV1308-1, AV2308-2, and/or AVn 308-n share alerting vehicle telemetry data directly with the safety cloud 302 by bypassing the alert tracking system 304, and vehicles V1310-1, V2310-2, and/or Vn 310-n share vehicle telemetry data directly with the safety cloud 302 by bypassing the vehicle tracking system 306.
Although the alert tracking system 304 is described as sharing alerting vehicle telemetry data from alerting vehicles AV1308-1, AV2308-2, and/or AVn 308-n, the alert tracking system may also share vehicle telemetry data from other vehicles or devices (e.g., a roadside vehicle, a roadside sensor, a maintenance vehicle, a construction site device, drawbridge warning lights, railroad crossing gate/lights etc.). Additionally, the alerting vehicle telemetry data may correspond to other alert-related data such as, for example, a weather hazard, a lane closure, a road obstruction, a construction site, traffic, etc. In some embodiments, other parties may have access to the alert tracking system 304, such that the other parties (e.g., construction teams, utility teams, weather tracking teams, etc.) may tap into the alert tracking system and input/send alert-related data to the safety cloud 302 to indicate a safety hazard and/or an alerting zone. In such an embodiment, the other parties may input alert-related data that includes a specific location (e.g., an address or longitude and latitude coordinates) and/or a zone and an alert status (e.g., construction active, drawbridge up, railroad crossing gate down) to indicate the safety hazard and/or the alerting zone.
As described above, the safety system provides digital alerts to vehicles to notify the vehicles of nearby hazards. Although the safety system is described as applying to alerting vehicles such as police cars, fire trucks, ambulances, and tow trucks, the safety system can be extended to provide digital alerting for a wide variety of hazards, including, for example, vehicle hazards such as school buses and mail trucks, and non-vehicle hazards such as construction zones, roadside hazards, and natural phenomena such as wildfires and floods. The safety system typically provides digital alerts according to digital alerting rules and in large-scale deployments with many different types of hazards and many different types of digital alerting rules, it can be difficult to know if the digital alerting rules are in fact improving safety on the roadways.
In conventional digital alerting systems, there may be some reliable information on digital alerting, including when digital alerts were issued and what vehicles received the digital alerts. However, heretofore, there has not been a way to understand the impacts of digital alerting that is reliable and that can be scaled over large cloud-based deployments. The safety system described herein collects a wide range of telemetry data from vehicles that are tracked by the safety system. For example, the safety system collects data about alerting vehicles, data about non-alerting vehicles, and data about digital alerts that have been provided to vehicles in the safety system. It has been realized that such extensive knowledge about vehicles and digital alerts can be used to determine post-alert behaviors of vehicles, which can in turn be used by the safety system to modify digital alerting rules based on the post-alert behaviors of the vehicles to improve safety on the roadways. For example, digital alerting rules of the safety system can be automatically modified by the safety system based on post-alert behavior to drive subsequent vehicle behaviors that meet a predefined safety principle, or set of safety principles. Such an intelligent and automated system can be implemented over large-scale digital alerting systems to improve safety on the roadways. For example, the intelligent and automated system can be implemented to make real-time modifications of thousands of vehicle alerting rules based on the post-alert behaviors of thousands, if not tens or hundreds of thousands of vehicles in real time. It would be impractical if not impossible for such a large scale implementation of intelligent digital alerting rules management to be implemented in a human mind. Thus, the techniques disclosed herein have a practical application to digital vehicle alerting systems that improve roadway safety.
In one example, the modification of a digital alerting rule is influenced by a safety principle that vehicles should receive a digital alert regarding a hazard 15-20 seconds before the hazard is encountered by the vehicle. Given the wealth of information that is collected by the safety system, it is possible for the safety system to continuously monitor post-alert behavior of vehicles and to automatically modify a digital alerting rule so that the safety principle is more likely to be met for subsequent alerting events. For example, one post-alert behavior that can be determined from the data collected by the safety system is the time interval between when a digital alert is provided to a vehicle and when the vehicle actually encounters the corresponding hazard. Specifically, such post-alert behavior can be reliably determined by the safety system from alert data, which includes a timestamp and location of the hazard, and vehicle telemetry data, which includes time stamped location data. In an example, a digital alerting rule implements an alerting zone around a hazard and sends digital alerts to vehicles that are within the alerting zone. For example, the alerting zone may be quantified as a distance of 1,000 feet from the hazard. If the determined post-alert behavior of a vehicle that received a digital alert indicates that the vehicle was alerted too late (e.g., less than 15 seconds before encountering the hazard), then the digital alerting rule can be modified by the system to enlarge the alerting zone around the hazard and if the determined post-alert behavior indicates that the vehicle was alerted too early (e.g., more than 20 seconds before encountering hazard), then the digital alerting rule can be modified by the system to reduce the alerting zone around the hazard. For example, the distance of 1,000 feet specified in the digital alerting rule could be increased beyond 1,000 feet to increase an alert time buffer or the distance of 1,000 feet specified in the digital alerting rule could be reduced below 1,000 feet to decrease the alert time buffer. Because the safety system collects a rich set of data about digital alerts that are provided throughout the safety system and about vehicles that are tracked by the safety system, post-alert behavior can be determined by the safety system with certainty and used by the safety system with confidence to automatically modify digital alerting rules towards a goal of achieving certain predefined safety principles for subsequent alerting events. Thus, a large safety system can automatically and intelligently adjust its digital alerting rules with the goal of achieving certain predefined safety principles.
An example of modifying a digital alerting rule based on post-alert behavior is now described with reference to a school bus scenario. In one implementation, the safety system is configured to provide digital alerts to vehicles that are approaching a school bus that has stopped on the side of a road for loading and/or unloading of passengers. In this case, upon stopping to load/unload passengers, the school bus may send a message to the safety cloud that includes data such as described with reference to
In the example provided above, a digital alerting rule is modified based on post-alert behavior of a single vehicle. In other examples, post-alert behavior can be determined for multiple vehicles and digital alerting rules may be modified based on the post-alert behavior of multiple vehicles. For example, various statistics may be generated (e.g., average time to encounter, mean time to encounter) and decisions on modifying digital alerting rules may be made based on comparing statistical values to safety principles. In another example, machine learning (ML) and/or artificial intelligence (AI) may be used to determine if digital alerting rules should be modified and/or to determine how to modify the digital alerting rules. In an example, ML/AI may be applied to post-alert behavior data and used to predict that certain digital alerting rules should be modified.
Although some examples are provided, there are many ways that post-alert behavior can be accumulated, batched, and/or processed for use in determining whether or not to modify digital alerting rules.
As illustrated in
The rules management module 560 includes safety principles 564, digital alerting rules 566, and a rules modification engine 568. In an example, the rules management module is embodied in computer readable code that is executed on a processor or processors, in, for example, a cloud computing environment such as the safety cloud described herein.
In an example, the safety principles 564 of the rules management module 560 are quantified safety parameters that are desirable to be met in order to enhance the safety of roadways. The safety principles can be met through implementation of digital alerting rules. One example of a safety principle is that vehicles, or some device within a vehicle, should receive a digital alert corresponding to a particular hazard 15-20 seconds before the hazard is encountered by the vehicle, referred to as an alert time buffer. With regard to the alert time buffer of 15-20 seconds, in some cases it is believed that alerting a vehicle less than 15 seconds before encountering a hazard may not provide enough time for an operator of the vehicle to take an appropriate action (e.g., to slow down) and alerting a vehicle more than 20 seconds before encountering a hazard may provide too much time such that the operator of the vehicle may forget about the hazard or may become distracted by something else. In one example, a vehicle is considered to have encountered a hazard when the vehicle is within 60 feet of the hazard although an encounter may be determined by other criteria. In another example, a vehicle is considered to have encountered a hazard when the hazard is visible to an operator of the vehicle or when the hazard is detectable by an on-vehicle sensor (e.g., camera or radar) of the vehicle.
Although an alert time buffer is one example of a safety principle, other safety principles may be considered to determine whether or not a digital alerting rule should be modified. Examples of safety principles that may be maintained within the rules management module include:
More than one safety principle may be applicable to one digital alerting rule. For example, more than one of the above-identified safety principles may be applicable to a digital alerting rule that corresponds to a fleet of school buses. The process of determining whether or not to modify the digital alerting rule may involve determining multiple different post-alert behaviors and doing multiple different comparisons of the post-alert behaviors to the corresponding safety principles. In an example, the digital alerting rule is modified if at least one of the post-alert behaviors does not meet the corresponding safety principle although other modification rules could be implemented.
In an example, the digital alerting rules 566 of the rules management module 560 are computer executable rules that control the generation and distribution of digital alerts within the safety system. The digital alerting rules can be, for example, specific to various different parameters, including specific to certain types of alerting vehicles, specific to certain types of hazards, specific to certain customers, and/or specific to certain non-alerting vehicles. For example, there may be a specific digital alerting rule related to police cars from city A, a specific digital alerting rule related to fire trucks from city A, a specific digital alerting rule related to police cars from city B, and a specific digital alerting rule related to fire trucks from city B. In fact, in a large safety system, it is expected that there may be hundreds or even thousands of specific digital alerting rules that are active throughout the safety system. Such a large number of digital alerting rules can be very difficult to manage manually by humans that oversee operation of the safety system.
The rules modification engine 568 of the rules management module 560 is configured to determine if specific digital alerting rules should be modified in view of post-alert behavior. In one example, the rule modification engine determines a post-alert behavior of a vehicle that was provided a digital alert from a digital alerting system using 1) a time that the digital alert was provided to the vehicle from the digital alerting system, and 2) vehicle telemetry data that was received at the digital alerting system from the vehicle. The rules modification engine then modifies a digital alerting rule based on the post-alert behavior and updates a rules engine of the digital alerting system with the modified digital alerting rule. The rules engine can then implement the modified digital alerting rule for subsequent digital alerting events in the safety system. As described herein, the automated management of the digital alerting rules by the safety system based on post-alert behavior and safety principles enables the safety system to efficiently and intelligently modify digital alerting rules in a dynamic manner that is driven by the safety principles. In an example, the rules modification engine may use ML and/or AI to determine if digital alerting rules should be modified and/or to determine how to modify the digital alerting rules. In an example, ML/AJ may be applied to post-alert behavior data and used to predict that certain digital alerting rules should be modified.
The rules engine 562 of the safety cloud is configured to implement digital alerting rules 570 to provide digital alerts as described herein. In an example, the rules engine is implemented in the safety cloud through computer executable code to provide digital alerting as described herein. In an example, the rules engine applies digital alerting rules to the alert data and to the vehicle telemetry data that is collected by the safety cloud to determine when to provide digital alerts to vehicles and to determine which vehicles will be provided the digital alerts.
Although an example of a rules management module is described with reference to
In the example of
In the example of
In an example, a separation distance is a parameter of a digital alerting rule because a separation distance between a hazard and a vehicle at a particular moment in time can be quickly and definitively calculated in the safety cloud using timestamps and the corresponding location information (e.g., the latitude and longitude coordinates) of the hazard and the vehicle. For example, the distance between two different locations (e.g., as indicated by latitude and longitude coordinates) is easy to calculate given location information about the hazard and location information about an oncoming vehicle that are collected at the same time (e.g., within 1-3 seconds of each other). Thus, separation distance between a hazard and an oncoming vehicle can be a good metric to implement in a digital alerting rule. In contrast, a digital alerting rule that is time-based, such as a digital alerting rule that calls for a digital alert to be provided 15-20 seconds before encountering the hazard, would need to predict a time to encounter between the hazard and the vehicle, e.g., using velocity information. Such a prediction can be more difficult to make in the tight time windows that are needed to alert oncoming vehicles in a timely manner and such predictions can be unreliable. Thus, separation distance is a metric that is beneficial to incorporate into a digital alerting rule at least because the separation distance can be quickly and definitively calculated from the telemetry data that is collected at the safety cloud. As described herein, the time to encounter a hazard can be better achieved as a safety principle that drives modification of the parameter of separation distance, which is incorporated into a digital alerting rule.
Referring back to the example illustrated in
In an example, the digital alerting rule described above with reference to
In an example, the process flow diagram of a technique for intelligently managing digital alerting rules described above with reference to
In some examples, the post-alert behavior of a vehicle is determined from data held in an alert database and from data held in a vehicle tracking database as described with reference to
As described herein, post-alert behavior of a vehicle is determined by the safety system and used by the safety system to determine whether or not to modify a digital alerting rule. An example of post-alert behavior is the time to encountering a corresponding hazard. Other post-alert behaviors can be determined from telemetry data received from vehicles and used to determine whether or not to modify digital alerting rules. Vehicles may include multiple different sensors and/or components that can provide various different types of data to the safety cloud. Examples of sensors and/or components that may provide useful information to the safety cloud include GPS units, accelerometers, speedometer, steering columns, blinkers, hazard lights, headlights, airbags, impact sensors, radar, lidar, cameras, and in-cabin sensors such as temperature sensors, vitals sensors, and gaze detectors. Examples of vehicle telemetry data that may be provided to the safety cloud from vehicles includes GPS data, speed data, braking data, steering column data, blinker data, hazard light data, airbag deployment data, impact data, and driver awareness data (e.g., gaze direction, alertness, vitals). Post-alert behaviors may be determined from any of these types of vehicle telemetry data, either a single type of data or a combination of different types of data.
Separation distance is described herein as an example of a parameter of a digital alerting rule. The separation distance can be modified to influence post-alert behavior of vehicles towards the goal of meeting a safety principle. Other parameters of a digital alerting rule may be modified to influence post-alert behavior of vehicles towards the goal of meeting a safety principle. Examples of other parameters of digital alerting rules that may be modified to influence post-alert behavior of vehicles include the number of digital alerts provided to a vehicle regarding a hazard, the frequency and/or pattern of digital alerts provided to a vehicle regarding a hazard, some characteristic of the digital alert, e.g., the type of presentation/notification (visual, audible, tactile), size of the presentation/notification, color of the presentation/notification, volume of the presentation/notification, mode of presentation/notification (navigation system, dashboard, heads up display). In one example, a digital alerting rule may be modified to provide a louder notification within the vehicle in response to a safety principle not being met. In another example, a rapid fire burst of notifications may be provided within the vehicle in response to a safety principle not being met. In another example, multiple parameters of a digital alerting rule may be modified in response to a safety principle not being met. Thus, there are many different ways that a digital alerting rule can be modified to influence post-alert behavior of vehicles with the goal of meeting a certain safety principle, or set of safety principles. In an example, a characteristic of a digital alert may be communicated to a vehicle as a value in the alert ID field of a digital alert message.
In an example, a parameter of a digital alerting rule may differ depending on different extrinsic conditions. For example, a separation distance parameter of a digital alerting rule may vary depending on time of day, day of week, month of year, weather conditions, special event conditions, etc. In an example, the separation distance in a digital alerting rule may automatically be increased from a current value during low or no light conditions (e.g., nighttime) or during inclement weather conditions (e.g., rain, ice, or snow). Such variations in parameters may be automatically incorporated into the intelligent and automatic modification of digital alerting rules that is implemented by the safety cloud based on post-alert behavior of vehicles.
In an example, a safety principle can be modified within the rules management module. For example, an alert time buffer could be manually or automatically changed, (e.g., increased or decreased), which may cause the safety system to automatically modify corresponding digital alerting rules based on the modified safety principle. Likewise, a new safety principle can be linked to a digital alerting rule. For example, a safety principle about deceleration could be added to a digital alerting rule, which will automatically cause the corresponding digital alerting rule to adapt based on the new safety principle.
In an example, the determination of whether or not to modify a digital alerting rule may be made by the safety cloud based on pre-alert behavior as well post-alert behavior. For example, knowing how fast a vehicle was traveling before receiving a digital alert may be helpful to the safety cloud in deciding whether or not a digital alert should be modified and/or to determine how a digital alert should be modified. For example, vehicles that have higher pre-alert speeds may need larger modifications to a separation distance parameter of a digital alerting rule to help meet a safety principle.
In an example, post-alert behavior may be determined by the safety system from a single piece of post-alert data (e.g., a single entry in a vehicle tracking database) or from multiple pieces of post-alert data (e.g., from multiple entries in a vehicle tracking database). The amount of post-alert data used/desirable to determine post-alert behavior may differ depending on the post-alert behavior that is being determined. In one example, post-alert vehicle telemetry data up until an encounter with the hazard is all that is used to determine post-alert behavior, and in another example, post-alert vehicle telemetry data that extends (in time) beyond an encounter with the hazard may be used to determine post-alert behavior. In an example, post alert data/behavior can be characterized as pre-encounter data/behavior, or post-encounter data/behavior.
In an example, a timestamp includes date and time information as is known in the field. For example, a timestamp may use the format YYYY-MM-DD hh:mm:ss, where YYYY is the year, MM is the month, DD is the day, hh is the hour (on a 24 hour clock), mm is the minutes, and ss is the seconds.
In an example, the vehicles, including the alerting vehicles and the non-alerting vehicles, are equipped with a GPS receiver to generate the vehicle telemetry data (e.g., including location and motion information) and a wireless communications transceiver (e.g., 3G, 4G, 5G transceivers) to transmit the vehicle telemetry data from the vehicle to a base station. The vehicle telemetry data can be then be sent from the base station to the safety cloud via known networking communications technologies.
In an example, telemetry data is data that is generated at a device (e.g., an on-board vehicle sensor or computer and/or a personal computing device, such as a smartphone) and wirelessly transmitted from the vehicle to a collection device for further analysis and/or processing. In an example, devices include at least one sensor, such as a GPS receiver and/or light activation state sensor, that is configured to generate at least some of the telemetry data and a wireless transceiver to transmit the telemetry data. In one example, telemetry data in the form of location data is generated and transmitted at fixed intervals.
It is understood that the scope of the protection for systems and methods disclosed herein is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device.
Although the operations of the method(s) herein are shown and described in a particular order, the order of the operations of each method may be altered so that certain operations may be performed in an inverse order or so that certain operations may be performed, at least in part, concurrently with other operations. In another embodiment, instructions or sub-operations of distinct operations may be implemented in an intermittent and/or alternating manner.
While the above-described techniques are described in a general context, those skilled in the art will recognize that the above-described techniques may be implemented in software, hardware, firmware, or a combination thereof. The above-described embodiments of the invention may also be implemented, for example, by operating a computer system to execute a sequence of machine-readable instructions. The instructions may reside in various types of computer readable media. In this respect, another aspect of the present invention concerns a programmed product, comprising computer readable media tangibly embodying a program of machine-readable instructions executable by a digital data processor to perform the method in accordance with an embodiment of the present invention.
The computer readable media may comprise, for example, random access memory (not shown) contained within the computer. Alternatively, the instructions may be contained in another non-transitory computer readable media such as a magnetic data storage diskette and directly or indirectly accessed by a computer system. Whether contained in the computer system or elsewhere, the instructions may be stored on a variety of non-transitory machine-readable storage media, such as a direct access storage device (DASD) storage (e.g., a conventional “hard drive” or a Redundant Array of Independent Drives (RAID) array), magnetic tape, electronic read-only memory, an optical storage device (e.g., CD ROM, WORM, DVD, digital optical tape), paper “punch” cards. In an illustrative embodiment of the invention, the machine-readable instructions may comprise lines of compiled C, C++, or similar language code commonly used by those skilled in the programming for this type of application arts.
The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 8612131 | Gutierrez et al. | Dec 2013 | B2 |
| 9659496 | Massey et al. | May 2017 | B2 |
| 10008111 | Grant | Jun 2018 | B1 |
| 12033506 | Deyaf | Jul 2024 | B1 |
| 20070159354 | Rosenberg | Jul 2007 | A1 |
| 20080074286 | Gill et al. | Mar 2008 | A1 |
| 20090174572 | Smith | Jul 2009 | A1 |
| 20120313792 | Behm et al. | Dec 2012 | A1 |
| 20140279707 | Joshua | Sep 2014 | A1 |
| 20150254978 | Mawbey et al. | Sep 2015 | A1 |
| 20160210858 | Foster | Jul 2016 | A1 |
| 20180268690 | Gebers | Sep 2018 | A1 |
| 20200074853 | Miller | Mar 2020 | A1 |
| 20230124536 | Chien et al. | Apr 2023 | A1 |
| 20240067087 | Tucker | Feb 2024 | A1 |
