Detecting use of driver assistance system

JP2023174610A5Pending Publication Date: 2026-06-02CAMBRIDGE MOBILE TELEMATICS INC

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
CAMBRIDGE MOBILE TELEMATICS INC
Filing Date
2023-05-26
Publication Date
2026-06-02

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

To provide a system with a mobile device that includes one or more sensors for sensing information during a trip in a vehicle.SOLUTION: A hardware processor can execute operations including: receiving telematics information produced by one or more sensors during a trip in a vehicle; processing, by a hardware processor, the received telematics information to identify vehicle movement information for the vehicle during the trip; determining, by the hardware processor, a probability that an advanced driver assistance system (ADAS) feature of the vehicle is operational during the trip based, at least in part, on the vehicle movement information for the vehicle during the trip; and determining a risk score for the vehicle or a driver of the vehicle based, at least in part, on the probability that the advanced driver assistance system ADAS feature is operational.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the detection of the use of a driver assistance system.

Background Art

[0002] A vehicle can be equipped with an Advanced Driver Assistance System (ADAS). The Advanced Driver Assistance System ADAS is a group of electronic technologies that assist a driver in driving and parking functions. The Advanced Driver Assistance System ADAS can use various technologies to assist the driver. The Advanced Driver Assistance System ADAS has been developed to automate, adapt, and enhance vehicle technology for a safer driving experience. The Advanced Driver Assistance System ADAS can include features such as automatic lighting, adaptive cruise control, collision avoidance systems, satellite navigation and traffic alerts, obstacle identification, lane departure warnings and lane centering, lane change assistance, navigation assistance, and other features.

Prior Art Documents

Patent Documents

[0003] [[ID=2i]]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, there is room for improvement in the detection of the use of a driver assistance system.

Means for Solving the Problems

[0005] One embodiment of the present invention provides a computer implementation method comprising: receiving telematics information generated by one or more sensors in a vehicle during a trip (while driving, while moving); processing the received telematics information using a hardware processor to identify vehicle movement information for the vehicle during the trip; determining the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the trip, at least partially based on the vehicle movement information for the vehicle during the trip, using a hardware processor; and determining a risk score for the vehicle or the vehicle driver, at least partially based on the probability that the advanced driver-assistance system (ADAS) function was operational, using a hardware processor.

[0006] An embodiment of the system comprises a device equipped with a plurality of sensors, a hardware processor for executing commands, and a memory having a non-temporary computer-readable storage medium for storing commands that cause the hardware processor to perform an action (operation) when executed. The operation comprises the steps of: receiving telematics information generated by one or more sensors during a trip in a vehicle; identifying vehicle movement information relating to the vehicle during the trip by processing the received telematics information with the hardware processor; determining the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the trip, at least in part, based on the vehicle movement information relating to the vehicle during the trip, with the hardware processor; and determining a risk score relating to the vehicle or the vehicle driver, at least in part, based on the probability that the advanced driver-assistance system (ADAS) function was operational, with the hardware processor.

[0007] One aspect of the embodiment includes a non-temporary computer-readable storage medium that stores instructions causing a hardware processor to perform an operation when executed. The operation includes the steps of: receiving telematics information generated by one or more sensors during a trip (movement) in a vehicle; having the hardware processor process the received telematics information to identify vehicle movement information about the vehicle during the trip; having the hardware processor determine the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the trip, at least in part, based on the vehicle movement information about the vehicle during the trip; and having the hardware processor determine a risk score for the vehicle or the vehicle driver, at least in part, based on the probability that the advanced driver-assistance system (ADAS) function was operational.

[0008] In some embodiments, the process of processing received telematics information includes comparing vehicle movement information with a known benchmark. The process of determining the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the trip includes determining that the comparison of movement information with a known benchmark indicates the probability that the advanced driver-assistance system (ADAS) function was operational.

[0009] In some embodiments, a known benchmark comprises one or more telematics information values ​​that correlate with telematics information observed when the vehicle's corresponding advanced driver-assistance system (ADAS) was known to be operational.

[0010] The embodiment also includes the steps of: defining a time window for sampling vehicle movement information; grouping a first vehicle movement information subset (first subset of vehicle movement information) into a first cluster for the first time window, wherein the first cluster comprises sampled values ​​of vehicle movement information having a first mean value; and determining the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the first time window based on a comparison between the first and second clusters.

[0011] In some embodiments, the vehicle movement information includes information about the vehicle's speed. Here, the step of determining that there is a high probability that the vehicle's advanced driver-assistance system (ADAS) was operational includes, based on the information about the vehicle's speed, determining that there is a high probability that the vehicle's adaptive cruise control was operational.

[0012] Some embodiments include the steps of: calculating the variance of vehicle speed within a predetermined time period; determining that the variance of vehicle speed within the predetermined time period is less than a threshold variance value S; and determining that it is highly likely that adaptive driving control was enabled based at least in part on the variance of vehicle speed during a predetermined duration in which the threshold variance value S is less.

[0013] Some embodiments may include the steps of: calculating the maximum speed of a vehicle within a predetermined time window; calculating the minimum speed of a vehicle within a predetermined time window; determining the difference between the maximum speed and the minimum speed for all windows for a predetermined number of time windows; determining that the difference between the minimum speed and the maximum speed for all windows is less than a threshold variance value D; determining the variance of the maximum speed for each window; and determining that, at least in part, it is highly likely that adaptive driving control was enabled.

[0014] Some embodiments may include the steps of determining from speed information that the vehicle accelerated to its maximum speed in T seconds (A), and determining that it is highly likely that adaptive driving control was enabled, at least in part, based on the fact that A is greater than a threshold acceleration value and T is within a threshold time value.

[0015] Some embodiments may include the steps of: determining that the vehicle has turned; determining that the vehicle decelerated for less than a predetermined threshold time T before the vehicle turned; and determining that it is highly likely that adaptive driving control was enabled, at least in part, based on the fact that the vehicle decelerated for less than a predetermined threshold time T before the vehicle turned.

[0016] In some embodiments, the step of determining that a vehicle has turned includes determining that a vehicle has turned based on one or more of the following: road network map matching, Global Positioning System (GPS) location data, and gyroscope sensor data.

[0017] In some embodiments, the telematics information includes information about the vehicle's position from either or both map matching and Global Positioning Satellite (GPS) information. The method further includes the step of determining, based on the information about the vehicle's position, that it is highly likely that adaptive driving control of the vehicle was operational.

[0018] Some embodiments may include the steps of determining from one or more of either map matching information or GPS information that the vehicle was on a multi-lane road, and determining that, based on the vehicle being on a large road, it is highly likely that the vehicle's adaptive driving control was enabled.

[0019] In some embodiments, the telematics information includes image information relating to a second vehicle that was present in front of the vehicle. The method further includes the step of determining, at least in part, that it is likely that adaptive driving control was operational.

[0020] Some embodiments include the steps of: determining the relative distance of a second vehicle to a vehicle over a predetermined time period from image information; determining from the determined relative distance that the variance of the relative distance between the second vehicle and the vehicle was below a threshold variance value over a predetermined time period; and determining that adaptive driving control was likely to have been enabled, at least in part, based on the fact that the variance of the relative distance between the second vehicle and the vehicle was below a threshold variance value.

[0021] Some embodiments include the steps of determining the driver of a vehicle based at least in part on identification information of an application running on a mobile device in the vehicle, identifying the driver's driving metrics, and using the driver's driving metrics in a comparison of telematics information with a benchmark.

[0022] Some embodiments include a step of using driver driving metrics, at least in part, to determine a benchmark. Some embodiments include the steps of determining the vehicle manufacturer and model from an application running on a mobile device, and determining whether the vehicle manufacturer and model are equipped with an advanced driver-assistance system (ADAS). [Brief explanation of the drawing]

[0023] [Figure 1] Schematic diagram showing an exemplary system for determining whether one or more advanced driver assistance system (ADAS) functions were operable in a vehicle during a trip, according to an embodiment of the present disclosure. [Figure 2] Schematic diagram showing an exemplary vehicle equipped with one or more advanced driver assistance system ADAS functions, according to an embodiment of the present disclosure. [Figure 3] Schematic diagram showing a system for using sensor information to determine whether an advanced driver assistance system ADAS function was operable, according to an embodiment of the present disclosure. [Figure 4] Schematic diagram of a sensor tag, according to an embodiment of the present disclosure. [Figure 5] Schematic diagram of a system for determining the operability (function operation likelihood, feature operational likelihood) of an advanced driver assistance system ADAS function, according to an embodiment of the present disclosure. [Figure 6] Flowchart for determining the operability of an advanced driver assistance system ADAS function in a server, according to an embodiment of the present disclosure. [Figure 7] Flowchart for determining the operability of an advanced driver assistance system ADAS function in a mobile device, according to an embodiment of the present disclosure. [Figure 8A] Schematic diagram of an exemplary neural network for determining the operability of an advanced driver assistance system ADAS function by using sensor information input, according to an embodiment of the present disclosure. [Figure 8B] Schematic diagram showing an example of a neural network training (learning) system for determining the operability of an advanced driver assistance system ADAS function, according to an embodiment of the present disclosure. [Figure 9] Schematic diagram showing an example of neural network training (learning) for determining the operability of an advanced driver assistance system ADAS function, according to an embodiment of the present disclosure. [Figure 10] Block diagram of an exemplary computer system according to an embodiment of the present disclosure. [Modes for carrying out the invention]

[0024] The drawings are not drawn to scale. Similar reference numbers refer to similar components. Advanced driver-assistance systems (ADAS) can be activated or deactivated by the driver. For example, the driver can choose to switch off the lane departure warning system. Adaptive driving control is typically off until the driver turns it on. Therefore, it is not always clear which advanced driver-assistance system (ADAS) functions are active for a particular driver in a particular vehicle at any given moment.

[0025] Advanced driver-assistance systems (ADAS) functions may affect the driving risk of the vehicle or the driver. Therefore, insurance providers are interested in determining whether a vehicle is actively using ADAS functions and how that ADAS decision affects risk. In many cases, the operating status of ADAS is not information disclosed to mobile devices or to telematics applications running on mobile devices. This disclosure describes a process for determining the probability that an ADAS function was operating in a vehicle during a trip (while moving) by using vehicle telematics information and other information related to the trip (movement). ADAS operation information can be communicated, for example, for the purpose of risk assessment.

[0026] The techniques described herein may use machine learning, such as neural networks, or other artificial intelligence (AI) to probabilistically determine whether advanced driver-assistance system (ADAS) functions were operational. In some embodiments, monitored machine learning is used, for example, by training an algorithm to distinguish between a human driver and the automation in the vehicle. The techniques described herein may also use predictive modeling techniques, physics-based modeling, statistical observations, benchmark comparisons, clustering algorithms, or other analytical models.

[0027] Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof. When implemented by software, firmware, middleware, or microcode, program code or code segments (e.g., a computer program product) for performing the required tasks may be stored in a computer-readable or machine-readable medium. The processor can then perform the required tasks.

[0028] Figure 1 is a schematic diagram showing an exemplary system according to an embodiment of the present disclosure for determining whether one or more advanced driver-assistance system (ADAS) functions were operational in a vehicle during a trip. The system 100 comprises a data processing system 102, a storage system 104, a network 106, a mobile computing device 108, and a vehicle 110. The storage system 104 comprises one or more computer-readable storage media configured to receive and store sensor information and other information for determining whether one or more advanced driver-assistance system (ADAS) functions of a vehicle were operational during a trip. The sensor information in this application may include not only raw sensor data such as the vehicle's speed during a trip, but also processed sensor data such as the maximum speed during a trip or the speed variance within a time window.

[0029] A trip can comprise any instance of travel, for example, from a starting point to a destination. In some cases, travel may comprise an instance of a single mode of transport (e.g., a car), or a single role of the person being transported (e.g., a driver), or both. For example, a trip may be an instance of travel by car from home to a store. The driver of the car may have a mobile device 108 equipped with a telematics application. During the trip (travel), the telematics application may be operating as a telematics application instance 120 on the mobile device 108.

[0030] The mobile device 108 can be a smartphone, tablet, laptop, or other portable electronic device that can receive, process, and transmit sensor data over a network. The mobile device 108 can also run a software application that includes a telematics application. The mobile device 108 can store vehicle telematics information during a trip. By processing the vehicle telematics information, the mobile device 108 can determine whether one or more advanced driver-assistance systems (ADAS) functions were enabled. The mobile device 108 can communicate this determination to the server 102 over the network 106. In some embodiments, the mobile device 108 can transmit vehicle telematics information to the server 102 over the network 106. The mobile device 108 can receive vehicle telematics information while a telematics application instance 120 is running on the mobile device 108. In some embodiments, the mobile device 108 can receive vehicle telematics information from various sources, including sensors associated with the mobile device 108 itself, sensors associated with the vehicle, sensor tags 112, aftermarket sensors, vehicle diagnostic information, vehicle processor register information, satellite receivers, and the like.

[0031] Telematics information may be stored in storage 104. Storage 104 is associated with server 102. Server 102 may comprise one or more hardware processors 114. Storage 104 may comprise a computer-readable medium that stores commands (instructions) that, when executed, cause one or more hardware processors 114 to process the telematics information to determine whether one or more advanced driver-assistance systems (ADAS) functions of vehicle 110 are operational (or were operational during the associated trip).

[0032] Generally, telematics information includes data from vehicle GPS systems, on-board vehicle diagnostics, wireless telematics devices (e.g., tags), on-board sensors, mobile device sensors, as well as information from black-box technologies that record and transmit vehicle data such as speed, location, maintenance requirements, and service, and cross-reference this data with the vehicle's internal behavior.

[0033] Generally, sensor information (or sensor data) broadly refers to information perceived by a sensor. A sensor can be part of a vehicle, such as an in-vehicle camera or LiDAR system. A sensor can be part of a mobile device, such as a magnetometer or satellite receiver. A sensor can be part of a vehicle-mounted sensor tag 112, which may include a gyroscope or accelerometer. In some embodiments, external sensors can be individually mounted to the vehicle and communicatively coupled to the mobile device 108 so that information perceived by the external sensor can be transmitted to the mobile device 108. An example of an external sensor may be an aftermarket dashcam. Sensor information can be stored and processed by the mobile device 108 to determine whether an advanced driver-assistance system (ADAS) function is active.

[0034] Network 106 may comprise any type of data network that facilitates the communication of information between the mobile device 108 and the server 102. For example, network 106 could be a cellular network, a Wi-Fi connection to the internet, or another type of network.

[0035] Vehicle 110 can be any type of vehicle that is operated (driven, operated) by a human driver for at least a certain period of time. Vehicle 110 may have one or more advanced driver-assistance system (ADAS) functions as described herein. In some embodiments, Vehicle 110 may be a connected vehicle. The term connected vehicle refers to applications, services, and technologies that connect the vehicle to its surroundings. A connected vehicle has various communication devices (embedded or portable) present in the vehicle that enable in-vehicle connectivity with other devices present in the vehicle, and enable the vehicle to connect to external devices, networks, applications, and services. Applications range from traffic safety and efficiency, infotainment, parking assistance, roadside assistance (road services), remote diagnostics, to telematics to autonomous vehicles and global positioning systems (GPS devices). Typically, vehicles equipped with interactive advanced driver-assistance systems (ADAS) and cooperative intelligent transportation systems (C-ITS) can be considered connected. Connected vehicle safety applications are designed to enhance situational awareness and mitigate traffic accidents through vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications.

[0036] Advanced driver-assistance systems (ADAS) technology can be based on vision / camera systems, sensor technology, vehicle data networks, and V2V or V2I systems. Features may include adaptive driving control and automated braking, as well as incorporating GPS and traffic warnings, connecting to smartphones, warning drivers of risks, and maintaining driver awareness of blind spots. V2V communication technology can mitigate traffic collisions and improve traffic congestion by exchanging basic safety information such as location, speed, and direction between vehicles within each other's range. It can complement proactive safety features such as forward collision warning and blind spot detection. Connected vehicle technology is also expected to be a fundamental component of autonomous driving by enabling the exchange of sensor and recognition data between vehicles, cooperative localization and map updates, and facilitating cooperative maneuvering between autonomous vehicles.

[0037] Figure 2 is a schematic diagram showing an exemplary vehicle equipped with one or more advanced driver-assistance system (ADAS) functions according to embodiments of the present disclosure. The transport mode can encompass any form, transport, or method of movement, such as, for example, automobiles, buses, trucks, trains, boats, bicycles, motorcycles, walking (walking or running), off-road vehicles, or airplanes. Vehicle 110 can encompass automobiles, buses, trains, motorcycles, mobile homes, trucks, or any such similar machines configured to transport users of mobile computing devices (108).

[0038] Vehicle 110 may be equipped with a vehicle system 200. The vehicle system 200 may be equipped with one or more advanced driver-assistance system (ADAS) functions 202. The advanced driver-assistance system (ADAS) functions 202 may be equipped with one or a combination of, but are not limited to, adaptive driving control, lane change assist, lane departure warning, lane keeping assist, traction control, dynamic power distribution to wheels, blind spot monitoring, collision warning, collision avoidance, automatic or emergency braking, satellite navigation, autonomous driving functions, pedestrian detection / avoidance, traffic sign recognition, surround view camera, automatic parking, night vision, traction control, etc. This list is not exhaustive. Other advanced driver-assistance system (ADAS) functions may be detected by using similar techniques described herein.

[0039] The vehicle system 200 may be equipped with one or more sensors 204. The sensors 204 may include a camera, LiDAR, radar, pressure sensor, odometer, speedometer, global positioning, map data, other location data, tire pressure monitor, power distribution monitor, or other types of sensors.

[0040] The vehicle system 200 also includes an input / output (I / O) 206. The I / O 206 can be used to accommodate aftermarket devices such as aftermarket cameras. For example, a vehicle not equipped with a backup camera can be coupled (via wired or wireless connection) to the vehicle's advanced driver assistance system (ADAS) by using an aftermarket camera. The ADAS function can use image information from the aftermarket camera to provide one or more driver assistance functions, such as parking or maintaining a safe distance between vehicles. The input / output (I / O) 206 can also interface with the vehicle's system to access published system information, which includes whether the ADAS function was available and whether the available ADAS function was active during a period of time (e.g., during a trip). The published system information, if available, can be included in the ADAS function operationality determination.

[0041] The vehicle system 200 also includes a user interface 208. The user interface 208 can allow the driver to turn advanced driver assistance system (ADAS) functions on or off. The user interface 208 can also be used for customized advanced driver assistance system (ADAS) functions, such as setting preferred speed or vehicle separation distance (e.g., as a function of speed), customizing feedback or alerts, or other types of customization.

[0042] The vehicle system 200 may include a control system 210. The control system 210 may include any systems involved in controlling the vehicle. An advanced driver-assistance system (ADAS) 202 may provide inputs or commands to the control system 210 to control the vehicle. For example, automatic parking may steer, accelerate, and brake the vehicle for parking. Lane keeping assist may steer the vehicle to return it to its lane. Adaptive cruise control may control the vehicle's speed, acceleration, and braking. Other examples are contemplated and are within the scope of this disclosure.

[0043] The vehicle system 200 may also be equipped with a satellite transceiver 212. The satellite transceiver 212 can receive Global Positioning Satellite (GPS) or Global Navigation Satellite System (GNSS) information. The memory 214 can store map data, driver information, vehicle information, or other data for advanced driver-assistance systems (ADAS) consumption.

[0044] Figure 3 is a system diagram showing a system 300 for using sensor information to determine whether an advanced driver-assistance system (ADAS) function was operational, according to an embodiment of the present disclosure. The system 300 includes a mobile device 108 having several different components. The mobile device 108 may include a sensor data block 105, a data processing block 150, a data transmission block 130, and optionally a notification block 140. The sensor data block 105 includes data acquisition sensors and data collected from these sensors that is available to the mobile device 108. The sensor data block 105 may include an external device connected via Bluetooth® or a USB cable, etc. The data processing block 150 includes storage 156 and operations (manipulations) performed on the data acquired from the sensor data block 105 by a processor 152. These operations may include, but are not limited to, an analysis step, a characterization step, a subsampling step, a filtering step, a reformatting step, and so on. The data transmission block 130 also includes memory 154, such as a cache or RAM. The data transmission block 130 may include optional transmission of data from the mobile device 108 to an external computing device that can also store and manipulate data acquired from the sensor data block 105. The data transmission block 130 may include a wireless transceiver 132 for transmitting and receiving information via wireless connections such as Wi-Fi, RF, or Bluetooth®. The data transmission block 130 may also include a cellular transceiver 134 for communicating via a cellular network, such as one using the 3GPP® protocol. The data transmission block 130 also includes a direct transmission block 136 that can exchange data using a wired or touch connection.

[0045] The external computing device may be, for example, a server 102. The server 102 may have its own processor 162 and storage 164. The notification block 140 may report the results of the analysis of sensor data performed by the data processing block 150 to the user of the mobile device 108 via a display (not shown). For example, the notification block 140 may display or otherwise report to the user of the mobile device 108 the score for one or more trips. In one embodiment, the mobile device 108 may further include a telematics application 120. The telematics application 120 can not only collect and assemble sensor data by running an instance of the telematics application, but can also perform processing and evaluation on the sensor data.

[0046] Several embodiments are described using examples in which driving data is collected by using a mobile device 108. These examples are not limited to any particular mobile device. Within the scope of the present invention are various mobile devices, for example, that include sensors such as an accelerometer 302, a gyroscope 304, a compass 306, a barometer (pressure meter, rain gauge) 308, a positioning system such as a Global Positioning System (GPS) receiver 310, a microphone 312, a magnetometer 314, communication functions, and the like. Exemplary mobile devices include smartwatches, fitness monitors, Bluetooth® headsets, tablets, laptop computers, smartphones, music players, motion analysis devices, and other suitable devices. Those skilled in the art will recognize, in consideration of the description herein, many variations, modifications, and alternative forms for implementing the embodiments.

[0047] To collect data associated with the driver's driving behavior, one or more sensors on the mobile device 108 (for example, sensors in sensor data block 105) generate sensor data during periods when the mobile device 108 is with the driver while the vehicle is in operation, which is referred to herein as “drive” or “trip.” In many mobile devices 108, the sensors used to collect data are not only components of the mobile device 108, but also utilize available power resources for the components of the mobile device 108, such as the mobile device’s battery power, and / or external data sources for the mobile device 108.

[0048] In some embodiments, certain features of the embodiment can be enabled by using settings on the mobile device. For example, in Apple iOS and / or Android OS, enabling certain settings can enable certain features of the embodiment. In some embodiments, enabling location services allows for the collection of location information from the mobile device (e.g., collected by a Global Positioning System (GPS) sensor). Enabling background app refresh allows, in some embodiments, the collection and analysis of driving data to run in the background even when the application is not running. In some implementations, trip capture may run in the background, and alerts are provided or surfaced using notification block 140 while the app is running in the background. These alerts may facilitate driving behavior modification. Further disclosures relating to scoring and behavior modification can be found in U.S. Patent Application No. 15 / 413005, filed January 23, 2017, which is incorporated herein by reference in its entirety.

[0049] In some embodiments, the sensor tag 112 may also provide sensor information to the mobile device 108, the server 102, or both. The sensor tag 112 may include a transceiver 322. The transceiver 322 may be configured to communicate with the mobile device 108 and / or the server 102 via a wireless network, such as a Bluetooth® network, a Wi-Fi® network, or a cellular network, among other things. The tag 112 also includes a sensor suite 324, which is described below.

[0050] Figure 4 is a schematic diagram of a sensor tag 112 according to an embodiment of the present disclosure. The tag 112 is capable of executing programmed instructions ("firmware") that control the operation of various other components of the tag. It comprises a processor in the form of a microcontroller 402. The components include a low-power wireless communication module 408 for communicating with a mobile communication device 108 in a vehicle or with a server 102.

[0051] The components also include one or more sensors, such as, among others, a three-axis accelerometer 406, a three-axis gyroscope 404, an optical sensor, a pressure sensor, and a magnetometer.

[0052] The accelerometer 406 measures the acceleration of the tag 112 while the vehicle is moving, thereby measuring the acceleration of the vehicle 110, and reports the data to the microcontroller 402. Accelerometers and other sensors generally provide digital outputs via serial interface standards.

[0053] In some embodiments, some or all of the components within the tag are low-power devices, so one or two small coin cell batteries are sufficient for the tag to operate for thousands of hours (operating time, multi-year operation). The firmware of the microcontroller 402 on the tag 112 primarily records telematics data only when the vehicle is moving. When the vehicle is not moving, the components of the tag 112 are powered off or in an ultra-low-power idle state. The "acceleration state machine" controls the different states of the tag 112.

[0054] In the illustrated example, the wireless communication module 408 can use a short-range wireless communication protocol. In some embodiments, the short-range wireless communication protocol is Bluetooth®, but any low-power communication can be used. Bluetooth® Low Energy (BLE) is widely available on general-purpose smartphone devices because it meets the desired power requirements. In an exemplary embodiment, the microcontroller 402 and the wireless communication module 408, which includes an antenna and a crystal, are combined on a single chip.

[0055] The tag 112 records acceleration and other sensor data. The sensor tag 112 may include a wireless communication module 414. The wireless communication module 414 can stream data to the mobile device 108 via a short-range wireless communication link. The wireless communication module 414 then processes the data and transmits at least a portion of the received and processed data to a server 102 having associated database storage 104 via a wireless communication network 106, such as 802.11 (WiFi) or a cellular network. In some embodiments, the wireless communication module 414 may also support long-range communication, such as cellular communication.

[0056] The tag 112 includes memory 416 in the form of flash storage, for example, using serial flash memory. Memory 416 stores data on trip start / end times, acceleration and other sensor data including telematics events detected by the firmware such as sudden braking, acceleration, and turning, as well as data on unexpected movements of the tag, collisions or crashes, and debug logs, along with timestamps. The tag 112 also includes random access memory (RAM) used by the firmware and read-only memory (ROM) used to store configuration data and executable instructions.

[0057] The tag 112 is equipped with a battery 412 for supplying power to the device. The battery may be coin cell form factor, standard AAA or AA, or solar. In a preferred embodiment, it is important to note that the tag 112 is not connected to any wired power source, such as the vehicle's power supply or the vehicle's standard onboard diagnostic (OBD) port. Since the tag 112 does not have an unlimited energy source, the operation of the tag 112 includes methods for careful use while conserving energy, as described below.

[0058] The advantage of not requiring a connected power supply is the absence of complex or cumbersome installation procedures like those for installed black boxes. Plugging tags into a vehicle's OBD port is undesirable, given that these types of devices could potentially interfere with the vehicle's onboard systems. The capital and operating costs of telematics systems with non-tethered tags are considerably lower than those of black boxes and OBD devices, making them more scalable for insurance companies.

[0059] Tag 112 is equipped with hardware and firmware instructions on microcontroller 402 to measure the battery power level and report it to the mobile device via a low-power wireless communication link. The hardware may be implemented using an intermediate circuit (not shown) connected between the battery and microcontroller 402 to measure the battery voltage. If the battery energy reserve is found to be below a threshold, the user is given a warning on the mobile device to alert the user when the battery is low.

[0060] In the illustrated example, the short-range wireless communication protocol is Bluetooth®, but any low-power communication can be used. Bluetooth Low Energy (BLE) is widely available on general-purpose smartphone devices because it meets the desired power requirements. In the exemplary embodiment, the microcontroller 402 and the wireless communication module 408, which includes an antenna and a crystal, are combined on a single chip.

[0061] Tag 112 is equipped with a tamper detection mechanism 410. The tamper prevention mechanism uses one or both of the following two technologies: In the first method, an accelerometer is used, and once the tag 10 is fixed to the vehicle, an orientation algorithm is used that has knowledge of the correction angle relative to the vehicle's direction of travel (x). This algorithm calculates a rotation matrix that transforms the axes of the tag's accelerometers 406 to the axes corresponding to the vehicle's reference frame. If tag 112 experiences a sudden change in this orientation, the most likely reason is the movement of the attached tag, and this is considered tampering. This tampering event is recorded in the tag's flash memory and securely transmitted to a backend server. Detection of such tampering reduces potential fraud.

[0062] The second method uses an optical sensor chip contained in a tag 112, which is covered by a tag housing. When the tag is removed from its intended location, the housing components are destroyed, exposing the optical sensor. This then triggers a tampering event, which is sent to the flash memory 416 and then to the server 102 via the mobile device 108.

[0063] Figure 5 is a schematic diagram of a system 300 for determining the feature operational likelihood (feature operational likelihood) of an advanced driver-assistance system (ADAS) according to an embodiment of the present disclosure. The system 300 may include a server 102 that communicates with a mobile device 108 according to an embodiment of the present disclosure. In some embodiments, the server 102 may provide functionality by using components including, but not limited to, a vector analyzer 552, a vector decisionator 554, an external information receiver 556, a classifier 558, a data acquisition frequency engine 560, a driver detection engine 562, and a scoring engine 564. These components may be executed by a processor (not shown) together with memory (not shown). The server 102 may also include data storage 510. It is important to note that one or more of the components shown to operate within the server 102, although not shown, may operate entirely or partially within the mobile device 108, and vice versa.

[0064] To collect data associated with the driver's driving behavior, one or more sensors on the mobile device 108 (e.g., sensors in sensor data block 105) may generate sensor data during the period when the mobile device 108 is with the driver while operating the vehicle, which is referred to herein as “drive” or “trip.” Once the mobile device sensors collect data (and / or in real time), some embodiments analyze the data to determine the vehicle’s acceleration vector and different driving characteristics. For example, a driver detection engine 562 may apply one or more processes to the data to determine whether the user of the mobile device 108 is the driver of the vehicle. Other examples include processes to detect and classify driving characteristics using a classifier 558 and to determine the acceleration vector using a vector analyzer 552 and a vector determiner 554. In some embodiments, external data (e.g., weather) may be taken out and correlated with the collected driving data.

[0065] As described herein, in some embodiments, collected sensor data (e.g., driving data collected using sensor data block 105) can be transformed into different results comprising, but not limited to, an analysis of braking behavior, an analysis of acceleration behavior, vehicle speed and speed variance ("speed information"), and other trip information obtained from the sensors.

[0066] Server 102 can receive telematics information and other “trip” information (together, sensor data accumulated from the mobile device 108 running the telematics application instance 502). The telematics information and other “trip” information may include sensor data from one or more of the sensors described above. The sensor data may be used by the server for various analyses, including driving score evaluation, driver distraction, risk assessment, and other analyses. Server 102 can also use the sensor information to determine whether advanced driver assistance system (ADAS) functions were likely activated during or part of the trip.

[0067] The server 102 may include a memory 510 having a non-temporary computer-readable storage medium for storing instructions that cause a hardware processor to perform an action when executed. The memory 510 may store an Advanced Driver Assistance System (ADAS) probabilistic engine 512. The ADAS probabilistic engine 512 can determine the probability that an ADAS function was operating in the vehicle during the trip, for example, by using sensor information and other telematics information received from a mobile device 108. In some embodiments, the ADAS probabilistic engine 512 can compare the sensor information of the trip received from the mobile device 108 with a known benchmark 516. The benchmark 516 may not only be associated with an ADAS function but may also include sensor information values ​​observed for one or more representative vehicles while the ADAS function was operating. The benchmark 516 for an ADAS function may be vehicle-specific or may be averaged across multiple vehicles or vehicle types. Simply put, Benchmark 516 represents information that can be used to identify whether advanced driver-assistance systems (ADAS) functions were enabled during the trip.

[0068] Benchmarks can be determined by correlating telematics information and other vehicle movement information with periods during which advanced driver-assistance systems (ADAS) functions were known to be active. Benchmarks can be trained using vehicle movement information from periods during which ADAS functions were known to be inactive. The probability that any particular ADAS function was operational during a trip can be determined by evaluating the frequency of various benchmarks in known periods of ADAS use versus periods during which ADAS was known not to be used (i.e., training data), and by looking at the similarity of the periods driving the values ​​in those benchmarks.

[0069] Benchmark 516 may include speed thresholds, speed dispersion thresholds, maximum speed, maximum speed dispersion thresholds, acceleration thresholds, acceleration dispersion thresholds, braking thresholds, braking timing thresholds, and other information that can be observed by sensors during a trip and may also be correlated with operational advanced driver-assistance system (ADAS) functions. Other examples may include auditory signaling such as noise generated by the vehicle when lane departure warning is active, noise generated from the steering wheel or seat tactile feedback, and noise generated from road humps. Benchmark 516 may include representative image data for determining whether the driver is holding the steering wheel or how close an adjacent vehicle is over a period of time.

[0070] Benchmark 516 can be established and refined through training a machine learning model 514. The machine learning model 514 can be used to determine the likelihood that advanced driver-assistance systems (ADAS) functions were turned on during the trip. The machine learning model 514 may comprise a neural network, decision tree, regression model, filter, or other types of machine learning algorithms. The machine learning model 514 can be trained using training data 524 to establish benchmark 516, which will be used by the machine learning model 514 to perform evaluations of sensor information. Training data 524 can be established using vehicle data 518, driver data 520, historical data 522, or other information from other sources. Training data 524 can be observed from real-world vehicle testing using advanced driver-assistance systems (ADAS) functions, and the observed information can also be correlated with the operation of the advanced driver-assistance systems (ADAS) functions.

[0071] The benchmarks, thresholds, and other aspects of the machine learning model 514 can be improved or refined, among other things, by using vehicle data 518. The vehicle data 518 may include information specific to the vehicle's make, model, and year, along with a vehicle identification number. The vehicle data 518 can not only provide information on whether advanced driver-assistance systems (ADAS) functions were available to the vehicle, but in some cases, it can determine whether a particular vehicle in question has advanced driver-assistance systems (ADAS) functions.

[0072] Benchmarks, thresholds, and other analytical functions can be refined, in particular, by using driver data 520. Driver data 520 may include the driving habits, driving score, and driving performance characteristics of the driver for the trip. The driver may be a person associated with a vehicle or a telematics application instance on a mobile device. Driver performance characteristics can be used to refine the benchmarks and thresholds used by the machine learning model 514. Here again, the machine learning model 514 can distinguish between human behavior and automated behavior, and therefore, the reliability of the machine learning model 514 in distinguishing between human drivers and automation can be increased by using driver-specific information in determining thresholds and benchmarks.

[0073] Similarly, historical data 522 can be used to refine benchmarks and thresholds. Historical data 522 may include information from other drivers or other advanced driver-assistance systems (ADAS) systems, or other historical information that can be used to notify and refine benchmarks and thresholds or to improve the performance of the machine learning model 514. Advanced driver-assistance systems (ADAS) can also improve over time, leading to changes in threshold variance. By comparing new data with historical data, improvements to the machine learning model can be determined, and the benchmarks and thresholds of the machine learning model can be refined.

[0074] The following provides examples of how sensor information from trips can be used to determine the feasibility of advanced driver-assistance systems (ADAS) function operation. Each example can be used individually with algorithms or machine learning models, or multiple examples can be used to improve the overall reliability of results from computational models.

[0075] (a) Adaptive cruise control has smoother speed changes than a human driver. For a sliding window of acceleration in T seconds, values ​​outside the range of speed changes that are above or below a given benchmark or threshold may be discarded. If the speed change exceeds the threshold S, the probability of adaptive cruise control increases as the variance decreases.

[0076] In example (a), the sensor information includes the vehicle's speed during the period in which speed data was collected. This period could be the duration of a trip, an aggregation of speed data across multiple trips in a single day (e.g., a driver-out running eland), or a data collection period for a sensor tag or telematics application running on a mobile device. A sliding window for time T can be selected or predetermined for the specific analysis described above.

[0077] The first benchmark can represent a maximum acceleration threshold for excluding data outside the analysis. The second benchmark can represent a minimum acceleration threshold for excluding data outside the analysis. These first and second benchmarks can be established using real-time statistical analysis of velocity information, or they can be predetermined. The predetermined benchmarks for the maximum and minimum changes in velocity (acceleration) can be based on relativistic values ​​such as the mean or percentage variance from the instantaneous value. Alternatively, the predetermined benchmarks for the maximum and minimum changes in velocity may be absolute values. In this case as well, the predetermined benchmarks can be established from real-world testing and training (learning).

[0078] For example, the third threshold in (a) is the change in the speed threshold S. A vehicle can control its speed by using automation. Automation has more precise control over acceleration, which would otherwise be controlled by a human using the pedals. The acceleration performed by the vehicle when adaptive driving control is active indicates less variance in the change in speed within a time window than, for example, when a human is driving. The threshold S defines how smoothly the vehicle accelerates within a time window. The threshold S can also define the limit of the change in acceleration within a time window. The change in acceleration can represent the variance of the change in speed when the vehicle accelerates. The change in the speed threshold S can be determined by using real-world tests of adaptive driving control and by observing sensor information.

[0079] The speed threshold S can be refined by using aggregated data for different vehicles, drivers, adaptive driving control systems, or other improvements. For example, a first manufacturer (type) and model of vehicle from which vehicle data 518 may be used may have different adaptive driving control systems than a second manufacturer and model of vehicle; therefore, the acceleration observed for each may differ slightly. The accuracy of the machine learning model can be improved by refining the threshold S using vehicle-specific information. Driver data 522 can also be used. Driver-specific driving habits and performance characteristics, as well as score history, can be used to refine the threshold S.

[0080] (b) Adaptive driving control has a specific maximum speed, and beyond this maximum speed, adaptive driving control does not remain (e.g., over a predetermined time period). For humans, peak speed over a time window is more volatile. By using a sliding window (i) of speed over T seconds (e.g., T=5 seconds), the maximum speed Amax(i) and minimum speed Amin(i) can be calculated. Amax(i) and Amin(i) can be evaluated over N windows (e.g., N=20). If maxi(Amax(i))-mini(Amin(i)) is less than a certain threshold D, the variance of Amax(i) is calculated. As the variance of Amax(i) decreases, the likelihood that adaptive driving control is operational increases.

[0081] In example (b), the benchmark time window size and the number of time windows can be predetermined by using statistical analysis or observation of time and windows that provides accurate results for calculating the variance of maximum speed. The threshold D can also be determined statistically and / or through observation. The threshold D can be a benchmark for distinguishing a human driver from automation such as adaptive driving control. The threshold D can be specific to the driver or vehicle, or it can be a more general value based on a broader source of information. The threshold D can be refined over time to improve the accuracy of the machine learning model 514. The threshold D can be refined by using driver-specific data, such as the variance of maximum speed observed for the driver when it is known that the advanced driver assistance system (ADAS) is not active. The threshold D can be refined over time as more information is learned about both driver behavior and the performance of the advanced driver assistance system (ADAS).

[0082] (c) Adaptive driving control accelerates to the maximum speed more rapidly than a human driver, but stops accelerating at that speed. In particular, if the speed change is measured as a speed change A' over T' seconds, where A' > threshold A and T' > threshold T, the possibility of adaptive driving control increases (or does not decrease) with A' and T'. In some embodiments, acceleration to the maximum speed is stopped, and the maximum speed is maintained with less variance in an advanced driver assistance system (ADAS) than in a human driver. A human driver may accelerate slowly or quickly to the maximum speed, but may exhibit a higher variance in the maximum speed after reaching the maximum speed.

[0083] Thresholds A and T represent benchmarks that distinguish between human activity and automation. Each can be identified and refined in a similar manner to that described above. (d) By using other sensor modalities, information can also be collected that can be input into one or more machine learning models. For example, since humans typically slow down before turning, adaptive driving control will slow down during the turn. Speed ​​information (braking) can be used to determine speed changes over a period of time. However, map matching of road networks coupled with GPS location data indicates when the road is turning. Gyroscope sensor data indicates when the vehicle is turning. Accelerometer data indicates when the vehicle has started to brake. If braking precedes the vehicle and road turn by less than time T, the likelihood of adaptive driving control is increased.

[0084] In example (d), additional sensor information other than speed and time is incorporated as input to a machine learning model to determine the likelihood that adaptive driving control will function in the vehicle during the trip (while it is moving). The machine learning model 514 can use information from many different sensor modalities as input when calculating the probability of the advanced driver assistance system (ADAS) function being operational.

[0085] (e) In another example, adaptive driving control is more common on larger roads. In particular, the likelihood is increased on road types 0, 1, and 2, as determined by map matching and GPS location data, but not on road types 3 or 4.

[0086] (f) By using in-vehicle video, it is possible to detect whether the steering wheel has moved even though the driver has taken their hands off it. For example, a sensor tag may be equipped with video surveillance to capture image data. The sensor tag may transmit image data to a mobile device 108 for the storage of sensor data which will ultimately be processed for the operation of an advanced driver assistance system (ADAS) (among other reasons). A forward-facing dashcam may be used to measure the distance to the vehicle ahead. When adaptive driving control is activated, this distance to the vehicle ahead should be constant, not normally, as a function of speed. When a human is driving, this distance to the vehicle ahead has greater variability.

[0087] The above provides examples of how sensor information can be used to determine the probability of an adaptive driving control system operating. The operating states of other advanced driver-assistance systems (ADAS) functions can also be collected from other sensor information. For example, a microphone included in a smart device or sensor tag can be used to detect an audible lane departure warning sound. A machine learning model 514 can be trained to distinguish between lane departure warning sounds and other sounds. Since lane departure warning sounds (alert sounds) can be unique to different vehicle manufacturers and models, the machine learning model 514 for determining audible lane departure warnings may also include vehicle information.

[0088] In some embodiments, the operational feasibility of advanced driver-assistance systems (ADAS) can be assessed using physics-based methods. For example, a vehicle motion metric for the computer (i.e., the ADAS) can be compared with a similar metric for a human operator to assume that it is more stable or that the changes in vehicle motion are more stable. For example, speed fluctuations can be assessed during a trip, for example, using a sliding window. The difference between speed fluctuations across different parts of a trip can indicate that the human driver or adaptive driving control was operational. Other factors can also be used to refine the probabilistic assessment. For example, low-speed variance at higher speeds may indicate a higher probability that adaptive driving control was on, in contrast to low-speed variance at lower speeds. Low-speed variance at low speeds can still indicate that the adaptive driving control function is operational, such as in gridlock situations where the vehicle may be moving slowly with frequent stops and starts. In such cases, speed fluctuations can be used in addition to the smoothness of acceleration and braking. Advanced driver-assistance systems (ADAS) are likely to provide smoother acceleration and braking compared to human drivers.

[0089] Microphones can also pick up noise associated with lane departure, such as road speed bumps. A machine learning model can be trained to use audible information to determine that a lane departure warning alert sound is generated after or during road speed bump noise. Road speed bump noise indicates that the vehicle has deviated from its lane and has been alerted. The machine learning model can also be trained to detect changes in the vehicle's trajectory after the lane departure warning alert sound, as well as to indicate that the driver has returned the vehicle to its lane after hearing the lane departure warning alert sound. Additionally, cameras on the vehicle can be used to visually capture instructions for the operation of advanced driver-assistance systems (ADAS) functions while driving, such as the driver's hand position, traffic signals or indicator lights, or other indications.

[0090] As can be seen from the above example, sensor information can be used by a machine learning model to determine the probability that an advanced driver-assistance system (ADAS) function was operational. Notably, the mobile device 108 can also be equipped with a machine learning model to perform an ADAS function operational probability assessment. The mobile device 108 can use the accumulated telematics information 504 from sensors on the mobile device 108 and the telematics information 508 from sensor tags 112, from the vehicle 110, or from other locations. The mobile device 108 can be equipped with an ADAS probability engine 506 similar to the ADAS probability engine 512. Thus, the mobile device 108 can perform a similar ADAS function probability calculation. The server 102 can update the ADAS probability engine 506 from time to time using training data to ensure the reliability of the machine learning model. The mobile device 108 can then send the probability to the server 102 for consumption, such as for risk assessment.

[0091] Server 102 may be equipped with a risk assessment engine 566. The operational feasibility of one or more advanced driver-assistance system (ADAS) functions is then aggregated across drives by the same driver and used to provide a risk score to the driver and / or insurance company. The risk score may be provided at both the trip and user levels.

[0092] Figure 6 is a processing flow diagram (600) for determining the operational feasibility of an advanced driver-assistance system (ADAS) function on a server according to an embodiment of the present disclosure. First, telematics information (including sensor data) is acquired by a mobile device running a telematics application instance (602). Sensor data can be acquired by the mobile device via internal sensors or directly from external sources such as vehicle sensors, sensor tags, or aftermarket sensors. The mobile device can transmit the telematics information to the server for evaluation of the operational feasibility of the advanced driver-assistance system (ADAS) function (604). For example, the mobile device can transmit the telematics information to the server via a cellular communication protocol using a cellular connection. The mobile device can transmit the telematics information to the server via the internet using a Wi-Fi® connection. Other transmission methods are intended and are within the scope of the present disclosure. The mobile device can stream the telematics information to the server continuously, periodically, at predetermined times or points during a trip, or at the end of a trip. The server can ping the mobile device to prompt it to transmit telematics information.

[0093] By controlling the timing of telematics information transmission, correlations can be created between telematics information and other information related to the driver. For example, by correlating the time of day with the route created during a trip, telematics information can be correlated with a commuting driver. Telematics information can also be correlated with a driver by using personal information associated with the telematics application instance. Timing, route, driver ID, and other information can be used by the server not only when evaluating the feasibility of advanced driver-assistance systems (ADAS) functionality but also when assessing risks.

[0094] The server can receive telematics information (606). The server can process the telematics information using one or more shaping algorithms of the Advanced Driver Assistance System (ADAS) stochastic engine to shape the data for determining the operational feasibility of the Advanced Driver Assistance System (ADAS) function (608). For example, the telematics information may include raw velocity data and the duration of movement. One or more shaping algorithms, by obtaining the raw velocity data, can identify acceleration data, time window duration and number of time windows, jerk, or other information that the Advanced Driver Assistance System (ADAS) stochastic engine and associated algorithms can use to predict the operational feasibility of the Advanced Driver Assistance System (ADAS) function.

[0095] An advanced driver-assistance system (ADAS) stochastic engine can determine the probability that an ADAS function was operational during a given period of time (duration) in a trip by using raw or processed telematics information (610). The period of time may be the entire trip, a segment of the trip, etc. Generally, an ADAS stochastic engine can assess the probability that an ADAS function was operational during that period by comparing the telematics information to known benchmarks. In an exemplary embodiment, an ADAS stochastic engine may utilize a machine learning model, such as a supervised machine learning model trained using training data. An ADAS stochastic engine may take telematics information, period information, driver information, and / or other information as input. An ADAS stochastic engine may output the probability that an ADAS function was operational during that period.

[0096] The server can then determine a driver risk assessment by using (among other things) the operationality of advanced driver-assistance systems (ADAS) functions (612). The operationality may be aggregated across drives by the same driver and may be used to provide a risk score to the driver and / or insurer, or for other reasons. The risk score may be provided at both the trip and driver levels. For example, the ADAS probability engine can determine whether the lane departure warning was turned off during driving (and how many times the lane departure warning was turned off during the trip) to indicate that the vehicle made an unintended change of course that may have crossed a lane boundary. Other telematics information, such as driver image information, can be used to determine whether the driver was distracted during the unintended change of course. Mobile device accelerometer and / or gyroscope information may be used to determine whether the driver was holding or moving the mobile device when the vehicle made an unintended change of course. By using all of these factors, the risk to the driver or the trip can be assessed.

[0097] Figure 7 is a processing flow chart (700) for determining the operational feasibility of an advanced driver assistance system (ADAS) function in a mobile device according to an embodiment of the present disclosure. First, telematics information (including sensor data) is acquired by a mobile device running a telematics application instance (702). The sensor data may be acquired by the mobile device directly via internal sensors or from external sources such as vehicle sensors, sensor tags, or aftermarket sensors. The mobile device can shape the data for determining the operational feasibility of an advanced driver assistance system (ADAS) function by processing the telematics information using one or more shaping algorithms of an advanced driver assistance system (ADAS) stochastic engine (704). For example, the telematics information may include raw velocity data and trip duration. One or more shaping algorithms may take the raw velocity data to identify acceleration data, time window duration and number, jerk, or other information that the advanced driver assistance system (ADAS) stochastic engine and associated algorithms can use to predict the operational feasibility of an advanced driver assistance system (ADAS) function.

[0098] An advanced driver-assistance system (ADAS) stochastic engine on a mobile device can determine the probability that an ADAS function was operational for a given period of time during a trip by using raw or processed telematics information (706). The period of time may be the entire trip, a segment of the trip, etc. Generally, the ADAS stochastic engine can assess the probability that an ADAS function was operational during the period of time by comparing the telematics information to known benchmarks. In an exemplary embodiment, the ADAS stochastic engine may utilize a machine learning model, such as a supervised machine learning model, that has been trained using training data. The ADAS stochastic engine can take telematics information, period information, driver information, and / or other information as input. The ADAS stochastic engine can output the probability that an ADAS function was operational during the period.

[0099] A mobile device can send ADAS functionality status to a server (708). For example, a mobile device can use a cellular connection to send telematics information to a server via a cellular communication protocol. A mobile device can send telematics information to a server via the Internet using a Wi-Fi® connection. Other transmission methods are intended and are within the scope of this disclosure. A mobile device can send ADAS functionality status to a server continuously, periodically, at predetermined times or points during a trip, or at the end of a trip. A server can also ping a mobile device to prompt it to send ADAS functionality status.

[0100] By controlling the timing of transmission of Advanced Driver-Assistance System (ADAS) function feasibility data, correlations can be created between telematics information and other information related to the driver. For example, by correlating the time of day with the route created during a trip, telematics information can be correlated with a commuting driver. Personal information associated with a telematics application instance can also be used to correlate telematics information with a driver. Timing, route, driver ID, and other information can be used by the server not only when evaluating the feasibility of Advanced Driver-Assistance System (ADAS) function feasibility but also when assessing risks.

[0101] The server can receive information on the operational status of advanced driver-assistance systems (ADAS) functions (710). The server can then use (in particular) the operational status of advanced driver-assistance systems (ADAS) functions to determine the driver's risk assessment (712).

[0102] Figure 8A is a schematic diagram of an exemplary neural network 800 for determining the operational feasibility of advanced driver-assistance system (ADAS) functions using sensor information inputs, according to an embodiment of the present disclosure. The ADAS stochastic engine may comprise one or more machine learning models. The machine learning models may be selected based on available inputs. In other words, a given set of input information may support only a subset of ADAS functions. Therefore, a machine learning model for that subset of ADAS functions may be selected to process the input information.

[0103] As an example, a machine learning model may include a trained neural network, such as neural network 800. Neural network 800 may include an input layer 802. The input layer 802 may have one or more inputs 802(a) to 802(k), where k is the index of the last input. Each input 802(a) to 802(k) represents a single piece of telematics information. For example, input 802(a) may contain velocity information, while input 802(b) may contain gyroscope information, input 802(c) may contain acceleration information, while input 802(k) may contain GPS information. Other inputs may be included in the input layer 802.

[0104] The machine learning model may have an output layer 806. The output layer 806 may have one or more outputs 806(a) to 806(k), one for each advanced driver-assistance system (ADAS) function of interest. The output layer may have one or more outputs that represent the probability that the ADAS function of interest was operational during driving. For example, for an input set, the neural network 800 may output a first probability P1 for a first ADAS1, a second probability P2 for a second ADAS2, and so on, up to the nth probability Pn for an nth ADASn. If the input does not support or is not related to an ADAS2, for example, P2 may be 0 or close to 0.

[0105] The neural network 800 may have one or more hidden layers 804. The hidden layer 804 may have one or more trained functions f(1)804(a) to f(m)804(k). The hidden layer functions can process incoming input information to output the probability that an advanced driver-assistance system (ADAS) function was operational. The hidden layer 804 functions can be trained by using training data to obtain the desired result.

[0106] The neural network 800 is merely an example and does not limit the types of machine learning models that may be used herein. Other types of neural networks (or machine learning models) may be used without departing from the scope of this disclosure.

[0107] Figure 8B is a schematic diagram of an example of a neural network training system 850 for determining the operational feasibility of an advanced driver-assistance system (ADAS) function according to an embodiment of the present disclosure. The neural network training system 850 may comprise training data 852. The training data 852 may comprise an input dataset 854 and a desired output 856. The input dataset 854 can be correlated with the desired output 856. Each input set 854 may comprise one or more telematics data that can be received from a mobile device or processed by a server for use in the neural network 850. Each input set 854 can be correlated with a desired output from the neural network 850, thereby allowing evaluation of the accuracy and reliability of the neural network 850.

[0108] The input set 854 is input to the neural network 800. The output of the neural network 800 is compared with a target value of the desired output 856 in the comparator 858. Errors may be reported in the error function 860. The error function 860 can instruct the training algorithm 862 to optimize the loss function and other functions in the hidden layers of the neural network. The error function 860 may provide error information that can be used to adjust the training algorithm to obtain desired results from a particular input dataset, as well as to increase the accuracy and reliability of the neural network 800. For example, the training algorithm 862 may perform weight adjustments on the hidden layer functions. Other training systems may be used without departing from the scope of this disclosure.

[0109] Figure 9 is a schematic diagram (900) showing clustering of vehicle movement information for determining the operational feasibility of an advanced driver-assistance system (ADAS) from telematics information, according to an embodiment of the present disclosure. Vehicle movement information can be determined from received telematics information. Vehicle movement information may include any information that can indicate whether or how the vehicle moved during the trip. Vehicle movement information may include vehicle speed, vehicle speed dispersion, vehicle acceleration, vehicle braking, lateral motion, pitch and yaw, etc. Vehicle movement information may also include sound information indicating that the vehicle has changed lanes, such as sounds from road speed bumps or lane departure warning signals.

[0110] In Figure 9, vehicle speed (vehicle velocity) dispersion information can be clustered. Speed ​​dispersion information from received telematics data can be analyzed over a period such as the trip period or a subset of the trip period. Speed ​​dispersion information can be clustered based on similarity over that period. Various clustering similarity measures such as density, centroid, distribution, and mean can be used. By comparing clusters with each other, it can be determined whether the values ​​within a cluster indicate the probability that the advanced driver-assistance system (ADAS) function was operational during that period. In Figure 9, clustering of speed dispersion over time forms the first cluster 902, the second cluster 904, and the third cluster 906. The first cluster 902 and the third cluster 906 show relatively high speed dispersion over their respective periods. The second cluster 904 shows relatively low speed dispersion over its respective period. The relatively low speed dispersion observed in the second cluster 904 may indicate, for example, that adaptive driving control was active during that period (since relatively low speed dispersion within a time window can indicate the use of adaptive driving control). Other information, such as the speed within that time window, can further indicate the probability. Higher speeds accompanied by lower speed fluctuations can further indicate the use of adaptive driving control.

[0111] Figure 10 is a block diagram of an exemplary computer system (1000) according to an embodiment of the present disclosure. Referring to Figure 1, for example, a mobile device 108, a tagging device 112, and a data processing system 102, as well as a computer system used by any of the users accessing the resources of these components, may be examples of system 1000 described herein. System 1000 comprises a processor 1010, memory 1020, storage device 1030, and one or more input / output interface devices 1040. Each of the components (1010, 1020, 1030, and 1040) may be interconnected, for example, by using a system bus 1050.

[0112] Processor 1010 is capable of processing instructions to be executed within system 1000. As used herein, the term “execution” refers to the technique by which program code causes the processor to execute one or more processor instructions. In some implementations, processor 1010 is a single-threaded processor. In some implementations, processor 1010 is a multi-threaded processor. Processor 1010 is capable of processing instructions stored in memory 1020 or storage device 1030. Processor 1010 can perform operations such as those described with reference to other figures herein.

[0113] Memory 1020 stores information within system 1000. In some implementations, memory 1020 is a computer-readable medium. In some implementations, memory 1020 is a volatile memory unit. In some implementations, memory 1020 is a non-volatile memory unit.

[0114] The storage device 1030 is made capable of providing large-capacity storage for system 1000. In some implementations, the storage device 1030 is a non-temporary computer-readable medium. In various different implementations, the storage device 1030 may comprise, for example, a hard disk drive, an optical disk drive, a solid-state drive, a flash drive, magnetic tape, or some other large-capacity storage device. In some implementations, the storage device 1030 can be a cloud storage device, and therefore may comprise, for example, a logical storage device comprising one or more physical storage devices distributed over a network and accessed using the network. In some examples, the storage device can store long-term data. The input / output interface device 1040 provides input / output operations for system 1000. In some implementations, the input / output interface device 1040 may comprise one or more of the following: network interface devices, such as an Ethernet® interface; serial communication devices, such as an RS-232 interface; and / or wireless interface devices, such as an 802.11 interface, a 3G wireless modem, a 4G wireless modem, a 5G wireless modem, etc. The network interface device enables the system 1000 to communicate, for example, by sending and receiving data. In some implementations, the input / output device may include a driver device configured to receive input data and send output data to other input / output devices, such as a keyboard, printer, and display device 1060. In some implementations, mobile computing devices, mobile communication devices, and other devices may be used.

[0115] The servers may be implemented in a distributed manner across a network, such as a server farm or a set of widely distributed servers. Alternatively, the servers may be implemented within a single virtual device comprising multiple distributed devices that operate in coordination with each other. For example, one of the devices may control other devices. Alternatively, the devices may operate under a coordinated set of rules or protocols. Alternatively, the devices may be coordinated in a different manner. The coordinated operation of multiple distributed devices may appear as if they were operating as a single device.

[0116] In some examples, the system 1000 is contained within a single integrated circuit package. This type of system 1000, in which both the processor 1010 and one or more other components are contained within a single integrated circuit package and / or manufactured as a single integrated circuit, is sometimes called a microcontroller. In some implementations, the integrated circuit package includes pins corresponding to input / output ports, which can be used, for example, to communicate signals with one or more of a plurality of input / output interface devices 1040.

[0117] An exemplary processing system is illustrated in Figure 10. Implementations of the subject matter and functional operations described herein may be implemented in digital electronic circuits, in tangibly embodied computer software or firmware, in computer hardware comprising the structures disclosed herein and their structural equivalents, or in one or more combinations thereof. Software implementations of the subject matter described may be implemented as one or more computer programs. Each computer program may comprise one or more modules of computer program instructions encoded on a tangible, non-temporary, computer-readable computer storage medium for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, program instructions may be encoded in / on artificially generated propagating signals. In one example, the signals may be mechanically generated electrical, optical, or electromagnetic signals generated to encode information for transmission to a suitable receiver device for execution by a data processing device. The computer storage medium may be a machine-readable memory device, a machine-readable memory board, a random-access memory device or a serial-access memory device, or a combination of computer storage media.

[0118] The terms “data processing device,” “computer,” and “computing device” (or equivalents as understood by those skilled in the art) refer to data processing hardware. For example, a data processing device can encompass all kinds of apparatus, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. A device may also include, for example, a central processing unit (CPU), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC), and dedicated logic circuits. In some implementations, a data processing device or dedicated logic circuit (or a combination of data processing devices or dedicated logic circuits) may be hardware-based or software-based (or a combination of both). This disclosure may optionally include code that constitutes execution environments for computer programs, such as processor firmware, protocol stacks, database management systems, operating systems, or combinations of execution environments. This disclosure intends to be used with data processing devices that have or do not have a conventional operating system, such as LINUX®, UNIX®, WINDOWS®, MAC_OS, ANDROID®, or IOS®.

[0119] Computer programs, which may also be referred to or described as programs, software, software applications, modules, software modules, scripts, or code, can be written in any form of programming language. Programming languages ​​may include, for example, compiled languages, interpreted languages, declarative languages, or procedural languages. Programs can be deployed in any form, comprising standalone programs, modules, components, subroutines, or units for use in a computing environment. Computer programs may, but are not required, correspond to files in a file system. A program may store other programs or data, for example, one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple collaborative files containing parts of one or more modules, subprograms, or code. Computer programs can be deployed for execution on one or more computers, for example, located at one site or distributed across multiple sites interconnected by a communication network. While parts of a program shown in various diagrams may be represented as individual modules implementing various features and functions through various objects, methods, or processes, a program can instead comprise several submodules, third-party services, components, and libraries. Conversely, the features and functions of various components can be combined into a single component as needed. Thresholds used to perform computational decisions can be determined statically, dynamically, or both statically and dynamically.

[0120] The methods, processes, or logical flows described herein can be executed by one or more programmable computers running one or more computer programs to perform a function by acting on input data to produce an output. The methods, processes, or logical flows can also be executed by dedicated logic circuits, such as a CPU, FPGA, or ASIC. The apparatus can also be implemented as a dedicated logic circuit, such as a CPU, FPGA, or ASIC.

[0121] A computer suitable for running computer programs can be based on one or more general-purpose and dedicated microprocessors and other types of CPUs. The components of a computer are the CPU for executing or performing instructions, and one or more memory devices for storing instructions and data. Generally, the CPU can receive instructions and data from (and write data to) memory. A computer may also have, or be operably coupled to, one or more mass storage devices for storing data. In some implementations, a computer can receive data from or transfer data to mass storage devices, for example, magnetic, magneto-optical disks, or optical disks. Furthermore, a computer can be incorporated into another device, such as a mobile phone, personal digital assistant (PDA), mobile audio or video player, game console, GNSS sensor or receiver, or portable storage device such as a Universal Serial Bus (USB) flash drive.

[0122] The term “computer-readable media” includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or transporting instructions and / or data. Computer-readable media may include non-temporary media capable of storing data but not containing carrier waves and / or transient electronic signals that propagate wirelessly or via wired connections. Examples of non-temporary media may include, but are not limited to, magnetic disks or tapes, optical storage media such as compact discs (CDs) or digital multipurpose discs (DVDs), flash memory, memory, or memory devices. Examples of computer-readable media may store code and / or machine-executable instructions that can represent procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, or any combination of instructions, data structures, or program statements. Code segments may be coupled to other code segments or hardware circuits by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0123] Computer-readable media (temporary or non-temporary, as appropriate) suitable for storing computer program instructions and data may comprise all forms of persistent / non-persistent and volatile / non-volatile memory, media, and memory devices. Computer-readable media may comprise semiconductor memory devices such as, for example, random access memory (RAM), read-only memory (ROM), phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices. Computer-readable media may also comprise magnetic devices such as, for example, tapes, cartridges, cassettes, and internal / removable disks. Computer-readable media may also comprise magneto-optical disks and optical memory devices and technologies, such as digital video discs (DVD), CD-ROM, DVD+ / -R, DVD-RAM, DVD-ROM, HD-DVD, and Blu-ray. Memory can store a variety of objects or data, including caches, classes, frameworks, applications, modules, backup data, jobs, web pages, web page templates, data structures, database tables, repositories, and dynamic information. The types of objects and data stored in memory can include parameters, variables, algorithms, instructions, rules, constraints, and references. Furthermore, memory can contain logs, policies, security or access data, and report files. The processor and memory can be complemented by or integrated into dedicated logic circuits.

[0124] This specification provides details of many specific implementations, but these should not be interpreted as limitations on the scope of what can be claimed, but rather as descriptions of features that may be specific to a particular implementation. Some features described herein in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may be implemented separately or in any appropriate subcombination in multiple implementations. Furthermore, while the aforementioned features are described as acting in a particular combination and may initially be claimed as such, one or more features from a claimed combination may, in some cases, be removed from the combination, and the claimed combination may cover subcombinations or variations of subcombinations.

[0125] We have described specific implementations of the subject matter. As will be apparent to those skilled in the art, other implementations, modifications, and substitutions of the described implementations exist within the following claims. Although the operations are shown in a specific order in the drawings or claims, this should not be understood as requiring that such operations be performed in a specific order or sequential order shown, or that all illustrated operations be performed (some operations may be considered optional), in order to achieve the desired result. In certain circumstances, multitasking or parallel processing (or a combination of multitasking and parallel processing) may be performed as deemed not only advantageous but appropriate.

[0126] Furthermore, the separation or integration of various system modules and constituent elements in the implementation forms described above should not be understood as requiring such separation or integration in all implementation forms. It should be understood that the described program components and systems can generally be integrated together into a single software product or packaged into multiple software products.

[0127] Therefore, the exemplary implementations described above do not define or limit this disclosure. Other modifications, substitutions, and alterations are also permitted without departing from the intent and scope of this disclosure.

Claims

1. A computer implementation method, wherein the computer implementation method is A hardware processor receives telematics information generated by one or more sensors of a device during a trip in a vehicle, wherein the device is not electrically connected to the vehicle, and the process of receiving the telematics information: The process of processing the received telematics information by the hardware processor in order to identify the road segments on which the vehicle traveled during the trip, wherein the road segments include turns, The process of determining a first point by the hardware processor based on one or more gyroscope measurements included in the telematics information, wherein at the first point the vehicle begins to turn on the road segment, The process of determining a second point by the hardware processor based on one or more acceleration measurements included in the telematics information, wherein at the second point the vehicle starts braking on the road segment, A step of determining the probability that the vehicle's advanced driver assistance system (ADAS) function was operational during the trip, based at least in part on a first point in which the vehicle begins to turn on the road segment and a second point in which the vehicle begins to brake on the road segment, wherein the probability that the vehicle's advanced driver assistance system (ADAS) function was operational is higher if the second point precedes the first point, and A step of determining a risk score for the vehicle or for the driver of the vehicle, based at least in part on the probability that the advanced driver assistance system (ADAS) function was operational by the hardware processor, A computer implementation method that includes the following features.

2. The process of processing the received telematics information includes a step of comparing the received telematics information with a known benchmark, The step of determining the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the trip includes determining that the comparison between the telematics information and the known benchmark indicates that the advanced driver-assistance system (ADAS) function was operational. The computer implementation method according to claim 1.

3. The known benchmark comprises one or more telematics information values ​​that correlate with telematics information observed when the corresponding advanced driver assistance system (ADAS) of the vehicle was known to be operational. The computer implementation method according to claim 2.

4. The aforementioned computer implementation method further, The process involves defining a first time window and a second time window for sampling the aforementioned telematics information, A step of grouping a received subset of first telematics information into first clusters for the first time window, wherein the first clusters comprise sampling values ​​of the telematics information having a first mean value, A step of grouping a received subset of second telematics information into second clusters for the second time window, wherein the second clusters include sampling values ​​of the telematics information having a second mean value, A step of determining the probability that the vehicle's advanced driver assistance system (ADAS) function was operational during the first time window, based on a comparison of the first cluster and the second cluster, The computer implementation method according to claim 1, comprising:

5. The telematics information includes information regarding the speed of the vehicle. The step of determining that there is a high probability that the vehicle's advanced driver-assistance system ADAS was operational is: The system includes a step of determining, based on the information relating to the vehicle's speed, that there is a high probability that the vehicle's adaptive driving control was operational. The computer implementation method according to claim 1.

6. The aforementioned computer implementation method further, A step of calculating the variance of the vehicle's speed within a predetermined time period, A step of determining that the variance of the vehicle's speed within the predetermined time period is less than a threshold variance value S, A step of determining that there is a high probability that the adaptive driving control was operational, at least in part, based on the fact that the variance of the vehicle's speed during a predetermined duration is less than the threshold variance value S, The computer implementation method according to claim 5, comprising:

7. The aforementioned computer implementation method further, A step of calculating the maximum speed of the vehicle within a predetermined time window, A step of calculating the minimum speed of the vehicle within the predetermined time window, A step of determining the difference between the maximum speed for all windows and the minimum speed for all windows for a predetermined number of time windows, A step of determining that the difference between the minimum speed and the maximum speed for all windows is less than the threshold variance value D, A step of determining the distribution of the maximum speed for each window, and A step of determining that it is highly likely that the adaptive driving control was operational, at least in part, based on the fact that the variance of the maximum speed is less than the threshold variance value D, The computer implementation method according to claim 5, comprising:

8. The aforementioned computer implementation method further, A step of determining from speed information that the vehicle accelerated to its maximum speed with acceleration A in T seconds, A step of determining that there is a high probability that the adaptive driving control was operational, at least partially based on the fact that the acceleration A is greater than the threshold acceleration value and that T seconds is within the threshold time value; The computer implementation method according to claim 7, comprising:

9. The aforementioned computer implementation method is The process of determining that the vehicle has turned, A step of determining that the vehicle has decelerated before it turns within a predetermined threshold time amount T, A step of determining that it is highly likely that the adaptive driving control was activated, at least in part, based on the fact that the vehicle decelerated for less than the predetermined threshold time amount T before the vehicle turned, The computer implementation method according to claim 5, comprising:

10. The step of determining whether the vehicle has turned includes a step of determining whether the vehicle has turned based on one or more of the following: road network map matching, Global Positioning System (GPS) location data, and gyroscope sensor data. The computer implementation method according to claim 9.

11. The telematics information includes information regarding the vehicle's position from either or both of the following: map matching and / or GPS information. The computer implementation method further includes a step of determining, based on the information relating to the position of the vehicle, that there is a high probability that the adaptive driving control of the vehicle was operational. The computer implementation method according to claim 5.

12. The aforementioned computer implementation method further, The process of determining that the vehicle was on a multi-lane road based on one or more of the map matching or Global Positioning Satellite (GPS) information, The process of determining that, based on the presence of the vehicle on a major road, there is a high probability that the adaptive driving control of the vehicle was operational, The computer implementation method according to claim 11, comprising:

13. The aforementioned telematics information includes image information relating to a second vehicle that was located in front of the vehicle. The computer implementation method includes a step of determining that there is a high probability that the adaptive driving control was operational, based at least partially on the image information relating to the second vehicle. The computer implementation method according to claim 5.

14. The aforementioned computer implementation method further, A step of determining the relative distance of the second vehicle to the aforementioned vehicle over a predetermined period of time from the aforementioned image information, A step of determining, from the determined relative distance, that the variance of the relative distance between the second vehicle and the vehicle was less than a threshold variance value over the predetermined time period, A step of determining that it is highly likely that the adaptive driving control was operational, at least in part, based on the fact that the variance of the relative distance between the second vehicle and the vehicle is less than the threshold variance value, The computer implementation method according to claim 13, comprising:

15. The aforementioned computer implementation method further, A step of determining the driver of the vehicle based at least partially on identification information of an application running on a mobile device in the vehicle, A step of identifying the driver's driving metrics, The process of using the driver's driving metrics when comparing the aforementioned telematics information with a benchmark, The computer implementation method according to claim 2, comprising:

16. The aforementioned computer implementation method further, The process includes a step of using, at least partially, the driver's driving metrics to determine the benchmark, The computer implementation method according to claim 15.

17. The aforementioned computer implementation method further, A step of determining the manufacturer and model of the vehicle from the application running on the mobile device, A step of determining that the manufacturer and model of the vehicle are equipped with the advanced driver assistance system ADAS, The computer implementation method according to claim 15, comprising:

18. A system, wherein the system is A device equipped with multiple sensors, A hardware processor that executes instructions, A memory comprising a non-temporary computer-readable storage medium for storing the aforementioned instruction, wherein the instruction, when executed, causes the hardware processor to perform an operation; It is equipped with, and the operation is, A hardware processor receives telematics information generated by one or more sensors of a device during a trip in a vehicle, wherein the device is not electrically connected to the vehicle, and the process of receiving the telematics information: The process of processing the received telematics information by the hardware processor in order to identify the road segments on which the vehicle traveled during the trip, wherein the road segments include turns, The process of determining a first point by the hardware processor based on one or more gyroscope measurements included in the telematics information, wherein at the first point the vehicle begins to turn on the road segment, The process of determining a second point by the hardware processor based on one or more acceleration measurements included in the telematics information, wherein at the second point the vehicle starts braking on the road segment, A step of determining the probability that the vehicle's advanced driver assistance system (ADAS) function was operational during the trip, based at least in part on a first point in which the vehicle begins to turn on the road segment and a second point in which the vehicle begins to brake on the road segment, wherein the probability that the vehicle's advanced driver assistance system (ADAS) function was operational is higher if the second point precedes the first point, and A step of determining a risk score for the vehicle or for the driver of the vehicle, based at least in part on the probability that the advanced driver assistance system (ADAS) function was operational by the hardware processor, A system equipped with these features.

19. The process of processing the received telematics information includes a step of comparing the received telematics information with a known benchmark, The step of determining the probability that the vehicle's advanced driver-assistance system (ADAS) function was operational during the trip includes determining that the comparison between the telematics information and the known benchmark indicates that the advanced driver-assistance system (ADAS) function was operational. The system according to claim 18.

20. The known benchmark comprises one or more telematics information values ​​that correlate with telematics information observed when the corresponding advanced driver assistance system (ADAS) of the vehicle was known to be operational. The system according to claim 19.

21. The aforementioned operation further, The process involves defining a first time window and a second time window for sampling the aforementioned telematics information, A step of grouping a received subset of first telematics information into first clusters for the first time window, wherein the first clusters comprise sampling values ​​of the telematics information having a first mean value, A step of grouping a received subset of second telematics information into second clusters for the second time window, wherein the second clusters include sampling values ​​of the telematics information having a second mean value, A step of determining the probability that the vehicle's advanced driver assistance system (ADAS) function was operational during the first time window, based on a comparison of the first cluster and the second cluster, The system according to claim 18, comprising:

22. The device includes either a smartphone or a sensor tag. The system according to claim 18.