Speeding on device

Abstract

Methods and systems for scheduling a query to an external server to retrieve data are provided where the query is transmitted from a device installed in a vehicle. The methods and systems include scheduling a query to a remote database based on a previously received at the requesting device, and more specifically, a comparison of the previously retrieved data and a measurement of the vehicle. Methods further include predicting and retrieving speed limit data along a probable path of travel, monitoring whether the vehicle is traveling along the probable path, and assessing speeding behavior against speed limit data for validly predicted paths.

Description

SPEEDING ON DEVICECROSS-REFERENCE TO RELATED APPLICATION[1] The present application claims the benefit of U.S. Provisional Patent Application No. 63 / 521,570 filed on 16thof June 2023, and titled, “SPEEDING ON DEVICE”, and U.S. Provisional Patent Application No. 63 / 554,005, filed on the 15thof February 2024, and titled, “SPEEDING ON DEVICE”, the disclosures of which are each expressly incorporated by reference in its entirety.TECHNICAL FIELD[2] The present disclosure relates to systems and methods for monitoring driving behavior, particularly, determining speeding alerts and optimizing data resources for generating speeding alerts.BACKGROUND[3] Speeding is a common traffic violation. A road accident that involves speeding tends to be more severe. Speeding violations may arise if drivers do not see the speed limit road signs that are placed adjacent to the road, deliberately ignore them, or are otherwise unaware that they are speeding. There is a need to determine and provide speeding alerts to the driver to ensure safety. Existing methods for determining and providing speeding alerts include maintenance of a local map of speed limit data within a vehicle memory, or alternatively querying a remote database at high frequencies. Certain methods and systems disclosed herein enable less frequent queries to a remote database, while still providing the benefits of high frequency query systems.SUMMARY[4] Certain aspects of the present disclosure provide methods and systems for scheduling a query to an external server to retrieve data. The method includes determining, by at least one processor of a device installed in a vehicle, a location and a measurement of the vehicle based on data from at least one sensor in the vehicle; sending, by the at least one processor, a first query to a database to retrieve at least one threshold associated with the location; comparing, by the at least one processor, the measurement with the at least one threshold associated with the location; and scheduling, by the at least oneprocessor, sending of a second query to the database at a second time instance based on the comparison.[5] Certain aspects of the present disclosure provide methods and systems for scheduling a query to an external server to retrieve data. The method includes determining, by at least one processor of a device installed in a vehicle, a location of the vehicle and the speed of the vehicle at a first time instance based on a data received from one or more sensors; determining, by the at least one processor, a first set of location estimates (predicted locations) of the vehicle at a first plurality of time instances posterior to the first time instance; sending, by the at least one processor, a first query to an external server, the first query comprising the location and the first set of location estimates; receiving, by the at least one processor, a response from the external server, the response including speed limit information corresponding to the location and the first set of location estimates, wherein the response further comprises heading information corresponding to the location and the first set of location estimates; for each of the first set of location estimates: validating a location estimate based on the heading information; on successful validation of the location estimate: comparing speed of the vehicle at the location estimate with respective speed limit value; and determining that the vehicle is speeding at the location estimate if the difference between the speed at the location estimate and respective speed limit value is greater than a threshold; and sending a second query to the external server at a second time instance, if it is determined that the vehicle is speeding at the second time instance and a first timer is lapsed.[6] Certain aspects of the present disclosure provide methods and systems for detecting speeding by a vehicle. The method includes transmitting at least one GPS point to an external server, wherein the at least one GPS point is collected by a device in the vehicle; receiving, a name of a road associated with the at least one GPS point from the external server, sending a query to the external server to retrieve a first set of links associated with the name of the road within a radius of the at least one GPS point, the query comprising the name of the road, at least one GPS point of the vehicle, the radius of the circle within which the one or more links are to be retrieved; receiving link data related to the one or more links associated with the road in the direction of the vehicle, wherein each link comprises a start GPS point and an end GPS point, wherein the link data comprises a link identifier, speed limit associated with each link, start and end GPS points of each link; determining a probable path of the vehicle by assembling the oneor more links in sequential order based on start and end GPS points of each link; determining whether the vehicle is speeding based on the speed of the vehicle and at least one speed limit associated with the probable path; Upon determining that the vehicle is speeding, generating a speeding alert for the driver.[7] Certain aspects of the present disclosure provide methods and systems for delivering speed limit information. The method includes sending a series of recent GPS points from a device to a snap-to-route engine; receiving the device's current road location from the snap-to-route engine, along with road information including speed limits, links, and road structure for the same road extending from the vehicle's location; using the extended road information to update the device's speeding state for as long as the device detects that it is still on the same road; and repeating the process if the device makes an intersection turn or advances on the road beyond the limit of the information provided by the snap-to-route engine.BRIEF DESCRIPTION OF DRAWINGS[8] FIG. 1 illustrates an example environment showing one or more edge devices for detecting speeding, according to an embodiment.[9] FIG. 2 illustrates a block diagram of an edge device, according to an embodiment.

[0010] FIG. 3 illustrates an example scenario depicting scheduling of queries to an external server, according to an embodiment.

[0011] FIG. 4 illustrates an example scenario depicting scheduling of queries to the external server, according to an embodiment.

[0012] FIG. 5 illustrates an example scenario depicting scheduling of queries to the external server, according to an embodiment.

[0013] FIG. 6 A illustrates a first example scenario depicting scheduling of queries to the external server, according to an embodiment.

[0014] FIG. 6B illustrates a second example scenario depicting dynamic scheduling of queries, according to an embodiment.

[0015] FIG. 6C illustrates a third example scenario depicting speeding alert generation, according to an embodiment.

[0016] FIG. 6D illustrates a fourth example scenario depicting suppression of an alert, according to an embodiment.

[0017] FIG. 7 illustrates a process flow for detection of speeding by an edge device with the help of an external server, according to an embodiment.DETAILED DESCRIPTION

[0018] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0019] Based on the teachings, one skilled in the art should appreciate that the scope of the disclosure is intended to cover any aspect of the disclosure, whether implemented independently of or combined with any other aspect of the disclosure. For example, an apparatus may be implemented, or a method may be practiced using any number of the aspects set forth. In addition, the scope of the disclosure is intended to cover such an apparatus or method practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the disclosure set forth. Any aspect of the disclosure disclosed may be embodied by one or more elements of a claim.

[0020] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

[0021] Although particular aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to particular benefits, uses or objectives. Rather, aspects of the disclosure are intended to be broadly applicable to different technologies, and system configurations, some of which are illustrated by way of example in the figures and in the following description of the preferred aspects. The detailed description and drawings are merely illustrative of the disclosure rather than limiting, the scope of the disclosure being defined by the appended claims and equivalents thereof.

[0022] Detection of speeding helps in improving the safe operation of a vehicle through immediate, real-time, or near-real-time feedback, which may facilitate correctionand / or impact habitual patterns of driving behavior of a driver. For immediate feedback and correction, the driver has to be notified in case of speeding, to alert the driver to the speed limits on a particular route, and in particular, that the driver is presently speeding. Delivering feedback while the driver is still driving may also improve the safe operation of the vehicle by impacting a driver’s habitual behavior with regards to speeding. In addition, habitual behaviors may be impacted by generating remote alerts regarding the driver’s speeding and then presenting statistics and / or video records of the same back to the driver at a later time.

[0023] In order to detect speeding on the vehicle, a computing device is installed on the vehicle that includes one or more sensors, a processing module, and a communication module. The computing device will be referred to as an “edge device” hereafter and the edge device communicates with a cloud computing system (which may be a cloud server) for additional information and processing.

[0024] Speeding is a traffic violation of driving the vehicle above the speed limit associated with roads or road segments. All the segments of a road may not have the same speed limits and may vary based on various factors. The drivers / users of a vehicle may not be aware of the speed limits on a road they are driving. In accordance with certain aspects of the present disclosure, the drivers may be alerted when they are Speeding.

[0025] FIG. 1 depicts an illustration of an environment 100 in which one or more embodiments of the present disclosure may be implemented. The environment 100 includes a cloud server 102, vehicles 104, 106, 108 and a network 110 for communication between the cloud computing system and edge devices 104a, 106a, 108a installed in the vehicles 104, 106, 108, and an external server 112.

[0026] The network 110 can be radio access networks such as GSM, LTE, 5G or the like. In one embodiment, the network 110 can be or include Wi-Fi or other wireless broadband networks.

[0027] The cloud server 102 may provide configuration settings and software related services to the edge devices. The cloud server may store the data received from the edge devices. Further, the cloud server may provide alerts to a fleet operator’s device (which may be a laptop, smartphone, or the like) and / or the driver’s device upon detection of speeding by an edge device.

[0028] In one embodiment, each edge device 104a, 106a, 108a may be an advanced driver assistance system (ADAS) that includes one or more cameras and sensors.Further, each edge device 104a, 106a, 108a may include a processor and communication circuitry that includes radio interfaces and antennas. The radio interfaces may correspond to a plurality of radio access technologies including one or more of GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, radio frequency identifier (RFID), ultra-wideband (UWB), and the like. Each edge device 104a, 106a, 108a is installed in a vehicle 104, 106, 108 respectively, to monitor driver behavior, which may include capturing and / or processing video of a cabin of the vehicle with a driver-facing camera and may include capturing a driving path of the vehicle with other sensors and / or a forward-facing camera. Further, each edge device 104a, 106a, 108a may include an audio speaker or other output devices to provide notifications and alerts to the driver. Each edge device 104a, 106a, 108a may be a standalone device or a combination of devices. In one embodiment, the edge device installed in the vehicle may include a sensor device and a computing device, where the sensor device may include cameras and other inertial sensors or positional sensors, but not a processor. The computing device on the other hand may include one or more processors to process the information captured by the sensor device. The sensor device may relay the captured data to the computing device via a wired or wireless connection. The distribution of functionalities among devices may be implemented to reduce the size of devices that are installed near the windshield. The various components of an exemplary edge device are explained next with reference to FIG. 2.

[0029] The external server 112 may be a mapping service provider that hosts application program interfaces (API) to provide requested data related to maps and GPS points. The external server 112 may include a database to store location related data, such as speed limits, heading direction, road names, road segment identifiers, and the like.

[0030] FIG. 2 depicts a block diagram of the edge device 200 (similar to edge devices 104a, 106a) including various components. The edge device 200 includes a processor 202, a communication module 204, input / output (I / O) module 206, memory 208, a camera module 210 and a sensor module 212. In one embodiment, the edge device 200 may not include a camera module 210 and in those scenarios, the camera module 210 may be connected to edge device 200 through wired or wireless connection. The edge device 200 may include input sensors (which may include a forward-facing camera, a driver facing camera, connections to other cameras that are not physically mounted to the device, inertial sensors, car OBD-II port sensor data (which may be obtainedthrough a Bluetooth connection), and the like) and compute capability. The compute capability may be a CPU or an integrated System-on-a-chip (SOC), which may include a CPU and other specialized compute cores, such as a graphics processor (GPU), gesture recognition processor, and the like. In some embodiments, the edge device 200 for determining, transmitting, and / or providing alerts to an operator of a vehicle and / or a device of a remote driver monitoring system may include wireless communication to cloud services, such as with Long Term Evolution (LTE) or Bluetooth communication to other devices nearby. For example, the cloud server 102 may provide real-time analytics assistance. In an embodiment involving cloud services, the cloud server 102 may facilitate aggregation and processing of data for offline analytics. The edge device 200 may also include a global positioning system (GPS) either as a separate module or integrated within a system-on-a-chip (e.g., included in sensor module 212).

[0031] The edge device 200 is configured to monitor the driving behavior of the driver. The one or more sensors included in the edge device can be one or more cameras and one or more inertial measurement sensors. The edge device 200 communicates with the cloud server 102 via the communication module 204. In one embodiment, the edge device 200 may communicate with cloud server 102 via a cellular network. The cellular resources (i.e., time slots, carrier frequencies, bandwidth) are utilized whenever the edge device 200 communicates with the cloud server 102. Cellular resources are limited, and effective utilization of the resources is required to keep the data usage low.

[0032] The edge device 200 determines whether the vehicle is speeding or not based on the vehicle’s speed and speed limits associated with the road on which the vehicle is travelling. The edge device 200 receives the speed of the vehicle from one or more positional sensors, such as GPS, and / or inertial measurement sensors. However, the speed limits of the road may not be readily available with the edge device 200. The edge device 200 may communicate with an external server 112 (such as API servers of HERE maps, Open-Source Maps (OSM), or to a custom speed limit sign database and / or map service) to provide the edge device 200 with speed limit related information of the road. The edge device 200 may use the cellular resources to query the external server 112 regarding the speed limit related information.

[0033] In one embodiment, the edge device 200 may determine a location of the vehicle based on data received from one or more positional sensors, such as GPS, and / or inertial sensors. The query to the external server 112 may include the location (i.e., a GPS point) of the vehicle when the query is raised. In one embodiment, the query may include aroad segment identifier of the road on which the vehicle is travelling. The query may request the external server to provide speed limit information associated with at least the location and the road segment identifier.

[0034] In another embodiment, the query may include one or more location estimates of the vehicle. The edge device may be configured to predict one or more future locations of the vehicle in time based on the previous locations of the vehicle in the current route. In some embodiments, the predicted future location may be further based on the current road segment identifier. The one or more future locations are referred as location estimates. For example, the vehicle may be at a location at time ‘f , the edge device predicts one or more location estimates at time instances ti, t2,. . .tnbased on the location at time ‘f and prior location data and / or speeding and / or heading of the vehicle before time ‘f on a current driving session. In some embodiments, the value of the time interval ‘d’ may be determined to increase the prediction accuracy, and each predicted location may be predicted at a time tn, where tn=t+nd, ‘n’ is a natural number that indicates number of location estimates and ‘d’ is the determined time interval.

[0035] In one embodiment, the location estimates may be part of a probable path of the vehicle. The probable path may be determined by querying the external server 112. To that effect, the edge device 200 may query the external server 112 to determine a road on which the vehicle is travelling. Upon receiving the name of the road, the edge device may query the external server 112 to retrieve one or more links associated with the same name of road. The edge device 200 may query for the one or more links within a predefined radius from the current location of the vehicle. The radius may be determined at least based on at least one of the speed of the vehicle, road type, and traffic conditions, and the like. Each link may include a start GPS point and an end GPS point. The edge device 200 may receive information related to the one or more links from the external server 112. The information may include a start GPS point and an end GPS point of each link, speed limit associated with each link, heading direction of each link, link identifier, and the like. Each link may further include a number of GPS points other than the start and end GPS points of the link. In another embodiment, the edge device 200 may send a single query to the external server 112, the single query including a GPS point and a radius for identifying one or more links. The edge device may sort the one or more links to form a sequential / ordered list of links. For example, the ordering of the list may be based on the start and end GPS points of links. The one or more links may be ordered by placing one link after the other leading to formationof a probable path of the vehicle, where one link having an end GPS point that is the same as or similar to the start GPS point of the other link are placed adjacent to each other.

[0036] Upon receiving the speed limit information associated with the location and the probable path, the edge device 200 may determine whether the vehicle is speeding by comparing the speed of the vehicle with the speed limit information associated with the probable path.

[0037] The driver monitoring systems (DMS) installed in the vehicle may be configured to query an API server for speed limit information in a periodic manner. For example, the DMS may be configured to query the external server every 5 seconds. However, this static manner of raising calls may not be efficient in terms of resource utilization. In order to improve the utilization of resources, methods for dynamic scheduling of queries are disclosed.

[0038] In order to generate and provide a timely speeding alert, the edge device 200 should possess the speed limit information ahead of time. To this effect, the edge device may include the predicted location estimates in the query to fetch speed limit information associated with the predicted location estimates. In this example, the location estimates are determined from the probable path. The probable path is constructed by edge device 200 when the edge device 200 has the road related information associated with the current GPS point of the vehicle. The visual data from camera sensors of the edge device may be used to trigger the generation of a query. For example, the edge device may start querying the external server upon detection of a highway (i.e., road that has 2 or more lanes) because highway / interstate freeway usually has defined speed limits. The visual data may be processed by the edge device 200 to determine whether the vehicle is moving on a highway or in city traffic. In one embodiment, the edge device 200 may include machine learning models to identify speed limit signs that are captured in the visual data. The edge device 200 may send a query to the upon identification of the highway or speed limit signs. Prior to sending the query, the edge device may predict one or more location estimates based on the current location and prior locations of the vehicle on the current route and / or the speed and heading of the vehicle. The current location and precited location estimates are included in the query.

[0039] In another embodiment, the edge device 200 may be configured to schedule a first query to the external server 112 at a location when the vehicle starts moving afterignition. For example, the driver might have taken a stop on the highway and therefore, the edge device 200 may send a query after a minute of driving. However, the subsequent queries can be scheduled to the external server based on a visual trigger. In one embodiment, the trigger for scheduling subsequent queries can be possible detection of speeding based on the speed limit sign captured in the visual data. In another embodiment, the trigger can be detection of road signs and buildings, etc. in the visual data captured by the one or more cameras of the edge device 200.

[0040] Upon raising the first query, the edge device 200 receives speed limit related information associated with the location from the external server. The edge device compares the speed of the vehicle with the speed limit associated at that location. The edge device determines that the vehicle may be speeding if the speed is greater than the speed limit by a margin and the margin is greater than a margin threshold. The margin threshold is a parameter value that may be defined by a fleet safety manager to exclude alerts that are raised by driving faster than the speed limit but not violating the speed limit by a margin. For example, the vehicle may be considered speeding if the speed of the vehicle is 40 mph, the speed limit is 30 mph, and the margin threshold is 3 mph. The edge device may detect speeding if the difference between the speed and the speed limit is a positive number. That is, the speed limit itself may be the threshold used for the comparison with the vehicle’s measured speed at a given location. Upon detection of speeding, the edge device 200 is configured to generate an alert and provide the alert to the driver through the use of a speaker or display device associated with the edge device. The alerts may not be sent at every detection of speeding, if the speeding is detected at one or more consecutive queries. In one embodiment, the alert can be transmitted to the cloud server 102 via the communication module 204 for recording the alert in association with the driver.

[0041] In addition to generating the alert, the edge device 200 may schedule a subsequent query to the external server based on the comparison of the speed with the speed limit. The scheduling of the queries / calls can be tracked by a timer in the processor 202 of the edge device 200. The subsequent query can be scheduled nearer to the prior query when the difference between the speed and the speed limit is greater than the margin threshold and the subsequent query can be scheduled farther to the prior query when the difference between the speed and the speed limit is less than the margin threshold. This scenario is shown in the top of FIG. 3, where the first query is raised at time ti, and it was detected that the vehicle may be speeding after time ti. The secondquery was scheduled at t2 which is nearer to ti, and it was determined that the vehicle may not be speeding at t2. Thereafter, a third query is scheduled at t3, which is farther in time from t2. This dynamic scheduling of calls based on speeding state may lessen the resources utilized for detection of speeding.

[0042] Further, upon scheduling the second query at t2, the driver may increase the speed of the vehicle abruptly, which may not be detected as speeding until the check is made at t2. In order to improve responsivity (detection of speeding close in time to when the speeding first occurs), the edge device 200 may be configured to monitor the speed of the vehicle in real-time and detect a speed change if the difference between the instantaneous speed of the vehicle and the speed of the vehicle at ti is greater than a speed change threshold. Upon detecting the speed change after ti, the edge device may reschedule the second query to a time instant nearer to ti. For example, if the vehicle speed at ti was 15 mph and the speed of the vehicle is suddenly increased to 25 mph, the edge device may detect the speed change since difference in speeds (i.e., 10 mph) is greater than the change threshold of 8 mph and move the query at t2 nearer to ti, as illustrated at the bottom of FIG. 3.

[0043] In one embodiment, the edge device 200 may be configured to raise a number of queries in a predefined time period. The frequency of the queries may be defined as the number of queries scheduled to the external server 112 in the predefined time period. For example, the predefined time period can be 1 minute, and the frequency can be 5 queries, which means that 5 queries are scheduled uniformly in time for every 1 minute. This scenario is shown at the top of FIG. 4, where six queries are scheduled at ti, t2, t3, t4, ts, and te for the predefined time period Ti for the edge device. The frequency is six, and this frequency can be dynamically varied. For example, the frequency can be dynamically varied based on the comparison of the speed of the vehicle with the speed limit associated with the location at certain queries. In one embodiment, the first query in the first time period is used to calculate the frequency for the first time period. However, the frequency of queries for the next time period is determined based on the comparison of the speed and the speed limit at the last query in the prior time period. The frequency for a time period can be increased if the vehicle is found to approach the speed limit at the first query in the time period. The frequency can be decreased if the vehicle is not speeding. For example, in FIG. 4, the initial frequency of 6 (shown in top portion of FIG. 4) is changed to 3 for time period Ti (shown in bottom portion of FIG. 4), and then the frequency of queries for T2 is increased to 5 upon detection of speedingafter a query raised at t3. Similarly, the frequency of queries for subsequent time periods is determined based on subsequent comparisons of speed and speed limit at the last query in the prior time period.

[0044] In one embodiment, the edge device 200 may be configured to raise a predefined number of queries for each time period Ti. This predefined number of queries are equally distributed in the time period. For example, six queries are equally distributed for time period Ti and scheduled to be raised at time instances ti, t2, t3, , ts, and te as shown in FIG. 5. However, upon a comparison of speed and speed limit after a query at ti, an intermediate query can be scheduled at taif the vehicle is detected to be speeding at ti. Further, the number of queries for the time period Ti may be different for different vehicles and the number of queries in Ti for each device may be determined based on the driving behavior of the driver.

[0045] In some embodiments the edge device may be configured to predict the future path of travel of the vehicle based on the path travelled. In particular, the edge device may determine at least one location estimate for the vehicle based on the route covered by the vehicle. The predicted location estimates may be verified by performing one or more actions on the location estimates. The one or more actions may include determining whether the heading of vehicle at the location estimate is greater than 45 degrees of prior heading, then either ignore or consider the location estimate. In addition, or alternatively, the one or more actions may include determining whether road class identifier at the location estimate is different than the road class identifier at the current location, then either ignore or consider the location estimate.

[0046] In one embodiment, the edge device is configured to send a query to the external server at regular intervals. Prior to sending the query, the edge device may predict a set of location estimates 1-10 (shown in FIG. 6A) at one or more time instances ahead of the current time. The prediction may be based on the current location of the vehicle, road segment identifier, and location history of the vehicle in the current driving session using machine learning models. The prediction may alternatively or additionally utilize the speed of the vehicle and / or heading. In one embodiment, the predicted location estimates may include heading data and GPS coordinates. The location estimates and the current location are included in the query to the external server so that speed limit data at each predicted location may be retrieved.

[0047] In one embodiment, the edge device may include one or more timers for synchronization and for tracking schedule of queries. The one or more timers mayinclude a first timer and a second timer. The edge device may reset the first and second timers whenever a query is sent to the external server. First and second timers may be configurable based on the accuracy of predictions by the machine learning models. In one embodiment, the value of the first timer is lower than the value of the second timer. In one embodiment, the edge device may be configured to send a query whenever the second timer expires. The number of location estimates predicted can be changed to increase the accuracy of the prediction and the location estimates are predicted through the time duration that is same as the value of the second timer.

[0048] The edge device receives a response from the external server in response to sending the query. The response includes speed limit values, and may include one or more of heading information and corresponding mapped location estimates. The predicted location estimates may be mapped to the nearest GPS points on a nearby road by the external server leading to generation of mapped location estimates. The edge device is configured to monitor the speed of the vehicle at the location and each of the location estimates. The edge device may compare the difference between speed of the vehicle and speed limit value with a marginal threshold, where the comparison is performed at each time instance or predicted location (location estimate) for which the speed limit was queried. The marginal threshold may be predefined or can be modified and set to a value to decrease the instances where alerts are raised when the speed of the vehicle merely crossed the speed limit but not an additional speed buffer and to identify instances where the speed of the vehicle is greater than the speed limit for a predefined time interval. The edge device is configured to determine that the vehicle is speeding if the difference is greater than the marginal threshold. The edge device is configured to determine whether the vehicle is speeding or not at every predicted location (location estimate) based on the speed limit data received in the response from the external server.

[0049] Upon determining speeding at a location estimate associated with a time instance, the edge device may check whether the first timer is expired or not. If the first timer is expired, then the edge device sends another query at the time instance at which speeding is detected. The first and second timers are reset upon sending the subsequent query. Further, a second set of location estimates are determined by the edge device and are included in the subsequent query. If the first timer is not expired, then the edge device may check whether the vehicle is speeding or not for the next location estimate at the next time instance. In this scenario, because the first timer has not expired, thedetermination that the vehicle is speeding may be more confident, and therefore an additional query to confirm the observation may be avoided.

[0050] Prior to determining speeding, the edge device may verify or validate the accuracy of the mapped location estimates based on the actual location coordinates of the vehicle at the time instances of predicted location estimates. For example, the edge device may check the accuracy of each predicted location estimate by comparing the respective mapped location estimate with the corresponding actual location coordinate of the vehicle (as measured by a GPS sensor associated with the device or the vehicle). If a predicted location estimate is determined to be invalid, then the edge device may suppress a determination that the vehicle is speeding even if the difference is greater than the marginal threshold because the speed limit data that was used in the determination may be considered invalid or unreliable.

[0051] In some embodiments, edge device is configured to generate and send an alert to the driver and / or the cloud server, if it is determined that the vehicle is speeding for at least two consecutive time instances. The edge device may also be configured to check whether any of the timers are expired, simultaneously, such that if timer 1 is expired and the vehicle is found to be speeding, then a new query will be sent. However, if it is determined that the vehicle is speeding at a time instance, but the location estimate for the time instance is not valid, the edge device may send a new query. In one embodiment, the edge device may not send a new query at the time instance but may wait for the expiry of the second timer to send the new query.

[0052] In a detailed example, the edge device predicts ten location estimates for time instances ti-tio before sending a first query at ‘to’ and time gap between each time instance is taken as one second for exemplary purposes. In this example, the value of first timer is 5 seconds and value of second timer is 10 seconds. The edge device is configured to send a second query upon expiration of the second timer (i.e., timer 2) if no speeding is detected when the second timer is active. In this example, speeding is detected at the time instance te (shown in FIG. 6B), then the location estimate for te is validated and after successful validation, the edge device checks whether the first timer (i.e., timer 1) is active or lapsed. It is determined that the first timer lapsed because 5 seconds have passed from the first query at time ‘to’ to te, therefore the edge device sends another query at te and resets the timers. Prior to sending the other query at te, the edge device determines another set of ten location estimates (1-10) for time instances t?-ti6 (shown in FIG. 6B). The edge device will send an alert to the driver if speeding isdetected at two or more consecutive time instances (shown in FIG. 6C). The edge device may suppress the alert if it is determined that a consecutive location estimate is invalid after detection of speeding at the prior location estimate (shown in FIG. 6D).

[0053] The above one or more actions are example purposes, however, there can be other actions that can be performed to verify the accuracy of the location estimate. Further, the edge device is configured to raise queries including the location estimate to prefetch the speed limits associated with the location estimates and alert the driver regarding the speed limits before time.

[0054] The edge device may include one or more machine learning models that are trained to implement one or more methods described above.Extended probable route predictions

[0055] The above provides various efficient methods for predicting a vehicle's path and updating its speeding state, by including short-term predictions of the vehicle's path and the speed limits at those locations. That approach, while accurate, may result in numerous API calls to the remote server, potentially overloading the server and using significant bandwidth. To mitigate these issues, it may be beneficial to extend the prediction of the vehicle's path (thus resulting in less frequent API calls), even though the accuracy of such predictions may decrease as the prediction gets longer (stretched farther down the road and / or further into the future).

[0056] For methods and systems that consider longer path predictions, there may be need to select an appropriate balance between reliable vehicle path prediction and the processing burden of continuous monitoring of the vehicles location (relative to the predicted path) to confirm whether the vehicle remains on the predicted path and therefore the queried speed limit data remain accurate.

[0057] In some scenarios, actual destination data could be utilized to predict the vehicle's most probable path. However, the method should be designed to work efficiently even for devices in vehicles that do not have access to an explicit destination of the driver. Predicted paths may make the system versatile and useful in a wide range of scenarios, regardless of whether the driver’s actual path is known to the device processors.

[0058] According to certain aspects of the present disclosure, the scope of the vehicle's path prediction may be extended, focusing on a longer timeframe. By doing so, the system may reduce the number of API calls made to the remote server, thus enhancingthe overall efficiency. While there may be a potential decrease in accuracy associated with longer predictions, the system may mitigate this risk by incorporating monitoring mechanisms, such as periodic verification of the predicted path locations.

[0059] In certain embodiments, as the vehicle progresses along its route, the system continuously compares the vehicle's actual GPS location with the predicted path. This allows the system to detect any deviations from the predicted path promptly. If the vehicle deviates from the expected path, the system triggers a new query to the remote server to receive updated speed limit information for the new most probable path.

[0060] A benefit of an extended prediction system may be a reduction in server load and bandwidth usage. Fewer API calls mean less data traffic between the device and the server, resulting in reduced latency and faster response times, so that the device can provide real-time updates to the driver, enhancing overall road safety. The system as described above can predict the vehicle's most probable path by analyzing the vehicle's current direction, speed, and past route data. An extended prediction system, as described in more detail below, offers a more comprehensive solution for real-time speed limit information delivery. By combining long-term path prediction with continuous monitoring, the system ensures accurate speeding state updates, efficient server communication, and adaptability to various driving scenarios.

[0061] In the following paragraphs, the workings of this extended prediction and monitoring system are explained, highlighting its innovative features and how they contribute to enhancing driving safety, particularly safe speed maintenance.

[0062] In one embodiment, the device is configured to detect a turn onto a new road followed by stable, cruise driving. Upon detecting the turn, the device sends a series of the most recent GPS points, which could be the most recent 10 or 20 points, to a snap- to-route engine. In response to the query, the snap-to-route engine returns the link ID or segment ID of the road link / segment that the vehicle is currently on. The device then queries a map layer or database such as HERE or OSM / OSRM or a custom mapping server using the received link ID or segment ID to retrieve the name of the street associated with the received link ID or segment ID.

[0063] In another embodiment, the device may further query the map layer or database for all links within a radius around the current vehicle position which have a street name attribute matching or similar to the queried street name. Along with this, the device also queries for speed limits and nodes / locations of these links. Upon receiving the response from the map layer or database, the device assembles the links into an ordered linkedlist that models the current road the vehicle is on. This list that is received by the device in the vehicle may be dynamically updated as new GPS data is received at the device, new queries are made to the external server, and new link or segment data is returned.

[0064] The device may be configured to incrementally determine the node of the ordered linked list that the vehicle is closest to, based on the new GPS data. This determination is used to access the speed limit for the vehicle's current location. In one embodiment, the device updates the speeding state based on the determined node location. The vehicle's speeding state is updated in real-time as the vehicle moves along the predicted route and as new speed limit data is received.

[0065] It should be noted that the radius around the current vehicle position may be dynamically adjusted based on vehicle speed, traffic conditions, and road conditions to improve the accuracy and relevance of the queried data.

[0066] In another embodiment, the vehicle's most likely route of travel could be determined using a machine learning model that takes into account historical route data, current traffic conditions, and driver behavior. This may help in predicting the vehicle's future course and in providing timely speeding alerts.

[0067] In an alternative embodiment, the external server rather than the device is configured to assemble the links in an ordered linked list. This is achieved by enabling the external server to handle the task of organizing and prioritizing the links based on the likelihood of the vehicle's route. Upon receiving the query from the device, the external server uses the link ID or segment ID to not only identify the name of the current street the vehicle is on but also to generate the most probable path the vehicle will take from the queried location.

[0068] The most probable path may be determined by identifying all linked waypoints having a portion of the street name in its name. For instance, if the current road is identified as "Hwy 101", the most probable path would include all linked waypoints having "Hwy 101" or "Highway 101" in their names.

[0069] The external server then assembles these waypoints into an ordered linked list. The ordered linked list is structured such that the waypoints are arranged in the sequence that the vehicle is most likely to follow.

[0070] This ordered linked list is then automatically returned to the device in response to the query. This not only optimizes the use of resources but also reduces the computational load on the device, enabling it to focus more on real-time operations such as updating the speed limit data and the vehicle's speeding state.

[0071] In this embodiment, the external server plays a more active role in predicting the vehicle's future course, thereby enhancing the overall accuracy and efficiency of the speeding detection system.

[0072] In another alternative embodiment, the system does not rely on the names of the streets but instead maintains a list of the most probable paths taken from one waypoint to the next. This list is generated using a crowd-sourcing algorithm that factors in the routes chosen by a majority of travellers. For instance, if there is only one node connected to the current waypoint in the same direction of travel, then that one node would be automatically followed in the linked list maintained in the server.

[0073] However, in situations where there are multiple paths of travel, such as at an intersection or a highway exit lane, the path to be followed is determined based on the choices made by a majority of travellers. If more than 50% of travellers tend to pick one path over the other paths, then that path is followed in the linked list.

[0074] This crowd-sourcing algorithm may enable the system to make more accurate predictions about the vehicle's future course, as it factors in the actual choices made by travellers under real-world conditions.

[0075] The remote server maintains a list with configurable parameters to optimize the functioning of the crowd-sourcing algorithm. For example, there might be a limit to only associate waypoints together for 10 km or less since shorter path predictions may be more likely to be accurate and therefore the data returned more likely to be relevant.

[0076] The threshold for continuing to add linked nodes can also be adjusted as per other factors. Nodes might only be added if the crowd-sourcing data indicates that more than 75% of travellers tend to take that path. A higher threshold increases the likelihood that the linked list accurately represents the most probable path that the vehicle will take from the queried location, although the returned linked list may be shorter than it would be with a lower crowd-sourcing threshold.

[0077] In another embodiment, the device is configured to deliver in-front-of-vehicle information. This is achieved by sending a series of recent GPS points from the device to a snap-to-route engine. The series of recent GPS points sent to the snap-to-route engine is dynamically updated based on the vehicle's movement. The snap-to-route engine, upon receiving the GPS points, returns the device's current road location, along with road information. This road information includes various data such as speed limits, links, and road structure for the same road extending from the vehicle's location. In certain embodiments, the extended road information received from the snap-to-routeengine may also include real-time traffic data. Upon receiving this extended road information, the device uses the extended road information to update the device’s speeding state for as long as the device detects that the vehicle is still on the same road. The device's speeding state is updated in real-time as the vehicle moves along the road and as new speed limit data is received.

[0078] This process repeats if the device makes an intersection turn or advances on the road beyond the limit of the information provided by the API. This ensures that the device has access to up-to-date information about the road the vehicle is currently on and the road the vehicle is likely to take, enabling the device to provide timely speeding alerts.

[0079] In certain embodiments, the vehicle is equipped with a device that uses GPS location information, inertial sensor data, and processing capability to determine whether the vehicle is still on the road for which it has queried speed limit information. In this example, the device may receive about one position estimate per second.

[0080] The inertial sensor data and / or positional data which may include heading, coupled with the device’s processing capabilities, can detect when the driver is turning or making other maneuvers. This information, when used in conjunction with the GPS location data, enables the device to track the vehicle’s movements and position on the road. When the device queries the snap-to-route engine for speed limit information, the returned data includes a series of GPS positions and associated speed limits. These positions correspond to waypoints along the most probable path of the vehicle.

[0081] In one embodiment, it may be assumed that the actual travel distances between waypoints are straight. The device can then continuously monitor its own position against an interpolated path of travel between these waypoints. This monitoring process allows the device to check whether the vehicle is deviating from the expected path (the predicted most probable path).

[0082] A deviation from the interpolated path, such as when the vehicle makes an unexpected turn, is interpreted as an event that triggers a new query to the remote server. The device then queries for a new set of speed limits along a new most probable path. In this way, the device may have access to relevant speed limit information, thus enabling it to accurately update the vehicle’s speeding state.

[0083] FIG. 7 illustrates an embodiment of the present disclosure in which a GPS point is received 702 from a positional sensor, and which may be refined with data from an inertial sensor, to the edge device, and the edge device generates a query including theGPS point and a boundary parameter (e.g., radius of a circle). The boundary parameter may be determined based on speed of the vehicle, traffic conditions, and road conditions. The query is then transmitted to an external server at step 704. The external server can be a mapping service provider that hosts application program interfaces (API) to request queries. The external server receives the query at step 732 and processes the query. The external server may map the original GPS point of the vehicle in the query to a mapped GPS point on the nearest road. The external server may query a database to retrieve the name of the road and a plurality of link IDs in the radius of the mapped GPS point at step 734. The external server may receive the plurality of link IDs with the radius of the mapped GPS point from the database at step 736. The external server may filter the plurality of link IDs to obtain one or more link IDs associated with the name of the road at step 738. The external server may transmit link data related to the one or more link IDs associated with the name of the road at step 740.

[0084] In an alternative embodiment, the external server may transmit link data related to the plurality of link IDs with the radius of the mapped GPS point to the edge device. In that case, the edge device may filter the plurality of link IDs to obtain one or more link IDs associated with the name of the road.

[0085] In one embodiment, the radius or the distance within which the edge device queries for information from the external server can depend on the speed of the vehicle. The faster the vehicle is moving, the larger the radius might be. This is because a vehicle moving at a high speed will cover more distance in a shorter time. To ensure that the system has all the necessary data to monitor the vehicle effectively, the query radius should be large enough to cover the distance the vehicle is expected to travel in the time between queries.

[0086] For instance, if the vehicle is moving very fast on a highway, the radius used for the query should be larger to include more segments of the road ahead. Conversely, if the vehicle is moving slowly in a city, the radius can be smaller as the vehicle won't cover as much distance between queries. This ensures the system operates efficiently, using server resources to gather data only for the relevant areas that the vehicle is expected to traverse in the near future.

[0087] The edge device 200 may receive the link data related to the one or more link IDs from the external server at step 706. The link data includes link identifiers, a plurality of GPS points associated with each link, heading direction of each link, speed limit information of each link, and the like. The plurality of GPS points of each linkmay include a start GPS point and an end GPS point of that link. The edge device may determine a probable path of the vehicle by assembling one or more links in sequential order based on start and end GPS points of each link at step 708. The edge device may determine whether the vehicle is speeding based on the speed of the vehicle and speed limit information associated with the probable path at step 710. The edge device may generate a speeding alert for the driver upon determining that the vehicle is speeding.

[0088] In one embodiment, the edge device 200 may not query the external server 112 for speed limit information if the vehicle is moving in the probable path. The edge device may have the speed limit information for the probable path from an earlier query to the external server. The edge device may send a subsequent call / query to the external server if the edge device detects that the vehicle deviated from the probable path or the vehicle is no longer travelling on the probable path. In one example, the edge device may detect that the vehicle is no longer travelling on the probable path by comparing heading direction of the vehicle with the heading direction of the link of the probable path, the link nearest to the current GPS point of the vehicle. In another example, the edge device may detect that the vehicle is not travelling on the probable path by the use of visual data from the camera. If the vehicle was travelling on an interstate highway, the newly captured visual data may indicate that the number of lanes of the path reduced indicating that the vehicle is no longer on the interstate highway. These examples are non-limiting, however, the edge device may use either sensor data or road data received from external server to detect that the vehicle deviated from the probable path, thereby triggering the subsequent query to the external server and determination of another probable path. By dynamically scheduling queries to external server, the above methods result in effective utilization of cellular resources and reduction in average number of queries made to the external server.

[0089] In one embodiment, the subsequent queries / calls scheduled to the external server can be made using the dynamic scheduling methods as described above along with the determination of probable path. The probable path can be verified and updated at regular intervals based on the calls / queries scheduled dynamically based on detection of speeding of the vehicle.

[0090] In one embodiment, the cloud server may create a map database equivalent to the database of an external server based on GPS data collected by a plurality of edge devices installed in a plurality of vehicles. The cloud server may update the map database based on the visual data inferences and inertial data inferences determined bythe edge device. The edge device may detect speed limit signs from the visual data captured by a camera and send the inferences to the cloud server for map database creation. The cloud server may generate probable paths for different fleets based on the historical data provided by the devices associated with different fleets. The map database creation by the cloud server may reduce the dependency on the external server to provide speed limit information or may be considered a custom map server.

[0091] As used herein, the term “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Additionally, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Furthermore, “determining” may include resolving, selecting, choosing, establishing and the like.

[0092] As used herein, a phrase referring to “at least one of’ a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

[0093] The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0094] The processing system may be configured as a general-purpose processing system with one or more microprocessors providing the processor functionality and external memory providing at least a portion of the machine-readable media, all linked together with other supporting circuitry through an external bus architecture. Alternatively, the processing system may comprise one or more specialized processors for implementing the neural networks, for example, as well as for other processing systems described herein.

[0095] Thus, certain aspects may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may comprise a computer-readable medium having instructions stored (and / or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. For certain aspects, the computer program product may include packaging material.

[0096] Further, it should be appreciated that modules and / or other appropriate means for performing the methods and techniques described herein can be downloaded and / or otherwise obtained by a user terminal and / or base station as applicable. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can be provided via storage means (e.g., RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.), such that a user terminal and / or base station can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

[0097] It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes and variations may be made in the arrangement, operation and details of the methods and apparatus described above without departing from the scope of the claims.

Claims

CLAIMSWhat is claimed1. A computer-implemented method, comprising: determining, by at least one processor of a device installed in a vehicle, a location and a measurement of the vehicle based on data from at least one sensor in the vehicle; sending, by the at least one processor, a first query to a database at a first time instance to retrieve at least one threshold associated with the location; comparing, by the at least one processor, the measurement with the at least one threshold associated with the location; and scheduling, by the at least one processor, sending of a second query to the database at a second time instance based on the comparison.

2. The computer-implemented method of claim 1, further comprising: scheduling, by the at least one processor, a set of queries to be sent in a predetermined first time duration, wherein the first query to the database is one of the set of queries scheduled to be sent in the first predetermined time duration.

3. The computer-implemented method of claim 2, further comprising: modifying a number of queries in the set of queries based on the comparison, wherein modifying comprises: increasing the number of queries when the measurement is greater than the at least one threshold; or decreasing the number of queries when the measurement is lower than the at least one threshold.

4. The computer-implemented method of claim 1, further comprising: modifying a number of queries scheduled in a second predetermined time duration based on a comparison of a second measurement and a second threshold received from the last query sent in the first predetermined time duration.

5. The computer-implemented method of claim 1, wherein the second query is scheduled to be sent at a predetermined time within the first predetermined time duration.

6. The computer-implemented method of claim 1, further comprising:generating, by the at least one processor, an alert when the measurement is greater than the at least one threshold.

7. The computer-implemented method of claim 1, further comprising: determining, by the at least one processor, at least one location estimate based on the location and the measurement; and verifying, by the at least on processor, the at least location estimate based on a subsequent measurement at a location corresponding to the at least one location estimate.

8. A computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors configured to carry out the method of any preceding claim.

9. A computer-implemented method for detecting speeding by a vehicle, the method comprising: transmitting at least one GPS point to an external server, wherein the at least one GPS point is collected by a device in the vehicle; receiving, a name of a road associated with the at least one GPS point from the external server, sending a query to the external server to retrieve a first set of links associated with the name of the road within a radius of the at least one GPS point, the query comprising the name of the road, at least one GPS point of the vehicle, the radius of the circle within which the one or more links are to be retrieved; receiving link data related to the one or more links associated with the road in the direction of the vehicle, wherein each link data comprises a start GPS point and an end GPS point, a link identifier, and a speed limit associated with each link; determining a probable path of the vehicle by assembling the one or more links in sequential order based on start and end GPS points of each link; determining whether the vehicle is speeding based on the speed of the vehicle and at least one speed limit associated with the probable path; and upon determining that the vehicle is speeding, generating a speeding alert for the driver.

10. The computer-implemented method of claim 9, further comprising upon detecting a deviation from the probable path, transmitting a new query with a new GPS point to retrieve a name of a new road.

11. The computer-implemented method of claim 9, further comprising upon detecting that the vehicle is travelling in the probable path and the vehicle is in proximity to an end GPS point of a last link in the probable path, transmitting a new query with a new GPS to retrieve a second set of links associated with the road.

12. The computer-implemented method of claim 9, wherein the radius around the current vehicle position is dynamically adjusted based on at least one of a vehicle speed, a traffic condition, or a road condition.

13. The computer-implemented method of claim 9, wherein the vehicle’s position on the probable path is updated dynamically as new GPS data is received.

14. The computer-implemented method of claim 9, wherein the vehicle's speeding state is updated as the vehicle moves along the probable path and as new speed limit data is received.

15. The computer-implemented method of claim 9, wherein the vehicle's probable path is determined using a machine learning model that takes into account historical route data, current traffic conditions, and driver behavior.

16. A computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors configured to carry out the method of any of claims 9 to 15.

17. A computer-implemented method for delivering speed limit information, comprising: sending a series of recent GPS points from a device to a snap-to-route engine; receiving the device's current road location from the snap-to-route engine, along with road information including speed limits, links, and road structure for the same road extending from the vehicle's location; using the extended road information to update the device's speeding state for as long as the device detects that it is still on the same road; andrepeating the process if the device makes an intersection turn or advances on the road beyond the limit of the information provided by the snap-to-route engine.

18. The computer-implemented method of claim 17, wherein the device's speeding state is updated in real-time as the vehicle moves along the road and as new speed limit data is received.

19. A computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors configured to carry out the method of any of claims 17 to 18.

20. A computer-implemented method, comprising: determining, by at least one processor of a device installed in a vehicle, a location of the vehicle and a speed of the vehicle at a first time instance based on a data received from one or more sensors; determining, by the at least one processor, a first set of location estimates of the vehicle at a first plurality of time instances posterior to the first time instance; sending, by the at least one processor, a first query to an external server, the first query comprising the location and the first set of location estimates; receiving, by the at least one processor, a response from the external server, the response including speed limit information corresponding to the location and the first set of location estimates, wherein the response further comprises heading information corresponding to the location and the first set of location estimates; for each of the first set of location estimates: validating a location estimate based on the heading information; on successful validation of the location estimate: comparing the speed of the vehicle at the location estimate with respective speed limit value; and determining that the vehicle is speeding at the location estimate if the difference between the speed at the location estimate and respective speed limit value is greater than a threshold; and sending a second query to the external server at a second time instance, if it is determined that the vehicle is speeding at the second time instance and a first timer is lapsed.T121. The computer-implemented method of claim 20, further comprising prior to sending the second query, determining a second set of location estimates of the vehicle at a second plurality of time instances, wherein the second plurality of time instances are posterior to the second time instance.

22. The computer-implemented method of claim 21, further comprising initiating the first timer and a second timer upon sending the first query; and reinitiating the first timer and the second timer upon sending the second query.

23. The computer-implemented method of claim 22, further comprising scheduling a third query to be sent to the external server upon expiration of the second timer.

24. The computer-implemented method of claim 23, further comprising sending the third query upon the expiration of the second timer if it is determined that the vehicle is not speeding at the second set of location estimates.

25. The computer-implemented method of claim 20, upon an unsuccessful validation of a location estimate from the first set of location estimates, modify the output of the comparison to not speeding irrespective of determined output of comparison.

26. The computer-implemented method of claim 20, further comprising generating an alert in response to determining that the vehicle is speeding at a plurality of consecutive time instances.

27. A computer program product comprising a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors configured to carry out the method of any of claims 20 to 26.

Images