WO2017189361A1 - System and method for calibration of vehicle sensors assisted by inter-vehicle communication - Google Patents

Abstract

Systems and methods are described for detecting miscalibration or other error in vehicular sensors. In an exemplary embodiment, different sensors on a vehicle are used to generate different values of a parameter (such as a location of another vehicle or a stationary object). If there is a disparity between these values, locally-generated values may be compared to values of the same parameter received (e.g. using V2V communication) from one or more other vehicles, and any unreliable sensor may be flagged based on the comparison. A sensor may be determined to be unreliable if the values a sensor generates deviates significantly from values generated at other vehicles. Detection of an unreliable sensor may result in an alert to a user, disabling of the unreliable sensor, disabling of a function that relies on that sensor, or other actions.

Description

SYSTEM AND METHOD FOR CALIBRATION OF VEHICLE SENSORS ASSISTED BY

INTER-VEHICLE COMMUNICATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C. §119(e) from, U.S. Provisional Patent Application Serial No. 62/329,375, entitled "System and Method for Inter- Vehicle Assisted Calibration of Vehicle Sensors," filed April 29, 2016, the entirety of which is incorporated herein by reference.

BACKGROUND

[0002] As automated vehicular systems become increasingly reliant on data being collected and shared from a wide variety of sensors, a serious risk exists that automated vehicular processes (such as braking or turning) will act upon data that has not been calibrated or vetted against a ground truth. As a result, the vehicle may engage in actions harmful or contrary to the intent of the vehicle's automated processes. Vehicular sensors may be calibrated at initial deployment, but over time the relationship between a reported sensor reading and the actual, physically-true value becomes degraded. Further, sensors are subject to manufacturing variability and the variability in the operating conditions. Decisions, such as actuation and control of vehicular processes, however, should be based on reliable values with minimal data bias and error.

[0003] Advancements in communication technologies facilitate the possibility that vehicles may share the information associated with their various sensors and control processes. The sharing of sensor information affiliated with functions like electronic stability, cruise control, collision warning systems, anti-lock braking systems, RADAR, LTDAR (light direction and ranging), video cameras, and other physical sensors provide a treasure-trove of data upon which new, active vehicular applications may be built. New forms of advanced vehicular applications may communicate such shared data between vehicles.

[0004] Various vehicular applications rely on accurate data for making vehicular control decisions. Even though vehicular systems may be deployed with many good quality sensors, these sensors may be calibrated periodically. Sensors experience minor variations during manufacturing that cause two sensors from the same production line to yield slightly different measurements. Further, sensors frequently experience sensitivity to variations in temperature, humidity, and other phenomena that affect measurement accuracy or may cause degradation over time. Other factors beyond the sensor itself, such as the placement of the sensor, affect the accuracy of the sensor reading. [0005] Building actuation and control upon sensor readings lacking perfect accuracy and reflection of the true, physical environment may result in dangerous outcomes. As an example, many automated braking systems implicitly estimate road characteristics, such as pavement texture and road slope estimation, in order to facilitate the proper application of braking. Without accurate data to make assessment of road characteristics, too much or too little braking may be applied. Although the consequences are severe for a single vehicle, the severity rapidly compounds for many vehicles jointly coordinated by remote, automated driving applications envisioned in the near future.

SUMMARY

[0006] Some embodiments of methods and systems described herein operate to detect a disparity between two vehicle function parameter estimates derived from two respective sensors in a vehicle, where the two sensors have different sensing modalities. In response to detecting the disparity, the first and second parameter estimates are compared with a third parameter estimate, which is derived from data received from another vehicle, to identify an outlier among the first two estimates that agrees less closely with the third estimate. Use of the outlier sensor, from which the outlier estimate is derived, may be discontinued in operation of vehicle function. Some embodiments of methods and systems described herein operate to recalibrate the outlier sensor. Some embodiments provide an indication to the vehicle operator that the outlier sensor should be serviced. Some embodiments, upon detection of a disparity of the first two estimates, retrieve additional parameter estimates from other vehicles and use those estimates to calculate a further estimate.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 is a schematic illustration of a system showing two vehicle sensors measuring the same parameter, road slope.

[0008] FIG. 2 is a schematic illustration of a system showing vehicle communications of sensor data in a Vehicle Ad-hoc Network (VANET).

[0009] FIG. 3 is a messaging sequence diagram of a request for sensor data.

[0010] FIG. 4 is a schematic illustration of data fusion for three vehicle sensors.

[0011] FIG. 5 illustrates tables representing exemplary types of sensor data defined in the Vehicle Sensor Data Cloud Ingestion Interface Specification (e.g. v2.0.2). [0012] FIG. 6 is a schematic illustration showing the detection of acceleration by an acceleration sensor.

[0013] FIG. 7 is a schematic illustration showing the forces acting on a vehicle running on a slope.

[0014] FIG. 8 is a schematic illustration of three vehicle sensor readings of the location of a building.

[0015] FIG. 9 illustrates an exemplary wireless transmit/receive unit (WTRU) that may be employed as a vehicular computing platform in some embodiments.

[0016] FIG. 10 illustrates an exemplary network entity that may be employed as a VDRM in some embodiments.

DETAILED DESCRIPTION

[0017] It is important to calibrate vehicle sensors, but this task may be challenging to accomplish efficiently. Modern automobiles contain numerous sensors, and the number of sensors in future automobiles will increase substantially. Having an automotive service garage calibrate each sensor is burdensome and costly. Further, such infrequent calibration will not likely alleviate significantly calibration drift. In order to succeed, automated vehicular systems benefit from systems that maintain the calibration of various vehicle sensors.

[0018] In some embodiments, systems and methods described herein maintain the fidelity of vehicle sensors by sharing and proactively fetching sensor measurements made by multiple sensors with a data monitoring service using sensor readings from many vehicles and/or modalities to recalibrate the sensors. A service remote to the sensing process using advanced data analytic methods calculates calibration updates, and these calibration updates are distributed back to the appropriate vehicle to update its sensor systems. This calibration service may take many forms.

[0019] In one exemplary embodiment, the calibration service existing in a vehicle' s computing infrastructure interfaces with the broader vehicular context by leveraging Vehicle-to- Vehicle (V2V) and Vehicle-to-Infrastructure (V2X) communication infrastructure, as well as awareness of the location of other vehicles (such as through sharing GPS position information), to query other vehicles of sensor data and improve the sensor calibrations of the querying vehicle. In some embodiments, the calibration service is provided as a cloud service instead of being provided in the vehicle. In such embodiments, the cloud-based calibration service utilizes the communication infrastructure to collect sensor data readings. [0020] Exemplary embodiments described herein may operate using data collected from many types of sensors within a vehicle and across many vehicles to assess accurately an out of tolerance sensor, to request proactively additional supplemental sensor readings, and/or to arrive at appropriate calibration correction functions that may be installed or used to modify the sensors within the vehicle to correct their calibration and data collection functions.

[0021] Embodiments disclosed herein may improve vehicular systems' use of sensor readings if the sensors have been calibrated prior to engaging in vehicular control processes, such as autonomous vehicle navigation, collision avoidance, lane changing, and velocity adaptation sensors. By leveraging a collection of sensor readings reported to a separate calibration monitoring service from a wide array of vehicles under different operating conditions, the physical relationships between parameters may be used, together with the reported values across different modalities, to calculate corrective calibration functions for each vehicle and its sensors. This calibration service, for example, may take different forms, ranging from a computing process that runs in a vehicle in parallel with automated vehicular applications to an external calibration service that exists remote to the vehicle, such as operating as a cloud service. The calibration service leverages inter-vehicular communication methods, such as V2V or V2X, to share sensor readings, as well as to support proactive fetching of sensor readings. This calibration function may be used to directly process data for the vehicle prior to acting upon it, or a parametric formulation of the calibration function may be relayed to a vehicle's computing components for on-going normalization of measured data.

[0022] Exemplary embodiments operate to combine data from many different vehicles and sensor types and to share this data via appropriate communication interfaces with a monitoring service (residing either in the vehicle or remote to the vehicle) that uses advanced data processing methods to determine how to calibrate sensors. Such embodiments may employ multimodal and multi-vehicle aspects of sensor data reported to a monitoring service (e.g. located in the cloud, or within a vehicle, or at a fleet-leader vehicle) to determine suitable vehicle sensor calibration updates.

[0023] Exemplary embodiments may facilitate calibration of vehicular sensors used by emerging automated driving applications. Prior systems generally use frequent recalibration of sensors by a certified garage to update or replace the sensor. Instead, by having sensors report their data readings to a monitoring service (which may be embodied by a computing service within a vehicle or the cloud), large-scale data analysis may determine if additional data may be used to assess further a calibration, determine potential corrections, and determine recalibration functions to distribute in a software patch to a vehicle's sensors. By leveraging the benefits of large-scale data analytics, the distributed nature of data collection (notably, the multimodal and multi- vehicular aspects of sensor data collection) may be used to estimate calibration parameters without using costly calibration tools. However, for well-calibrated references, such as may arise from a specialized calibration apparatus, embodiments described herein may use this information to significantly enhance recalibration functions. Moreover, embodiments described herein may use data analytics to determine what type of additional data is useful to make an accurate calibration calculation and use information regarding other vehicles to request their sensor readings and to improve the requesting (original) vehicle's sensor calibrations.

[0024] Some embodiments described herein address problems where manufacturers create sensors according to standardized specifications, but their accuracy degrades due to various factors, such as the sensor's age, the placement of the sensor within the vehicle, and environmental factors, such as temperature and humidity. Dangerous situations may arise where actuation and control rely upon inaccurate sensor readings. For example, many automated braking systems estimate road characteristics, such as pavement texture and road slope. Exemplary embodiments provide systems and methods for maintaining the fidelity of vehicle sensors by sharing sensor measurements with a data monitoring service that uses the collection of sensor readings from many vehicles to arrive at appropriate mechanisms to recalibrate each vehicle's sensors.

[0025] Methods for updating a sensor's calibration may include collecting various sensor readings from within a vehicle. These sensor readings may be associated with many different sensing modalities, such as GPS, RADAR, LIDAR, video cameras, electronic management sensors, comfort management sensors (e.g. position of mirrors, entertainment systems, cabin temperature), engine diagnostic sensors, propelling shaft speed, longitudinal acceleration, and vehicle torque sensors. A system tags this data with vehicle identification and position information (such as WGS84-formatted data provided by GPS). Via an appropriate interface, the vehicle relays tagged sensor data to a data monitoring service (such as the Vehicular Data Reliability Monitor or VDRM). The VDRM may be a computing function running within a vehicle or a monitoring service outside the vehicle, such as in the cloud.

[0026] The VDRM collects data from various sensor types and potentially from many different vehicles. The VDRM analyzes the accuracy of the data by leveraging physical models and through correlative analysis. The VDRM uses a broad database of vehicular data (such as positions of other vehicles and the sensors that they have available) to determine the benefit of additional data and to query vehicles for data beneficial for calibration calculations. The VDRM determines the accuracy of data and uses its computing resources and data to ascertain appropriate calibration functions to correct inaccuracies of data measured by a corresponding vehicle's sensor. The VDRM distributes an update to the vehicle's computing system (such as via a software patch), which may be used to upgrade the sensor's software to provide correct data measurements in the future.

[0027] Exemplary embodiments provide a means for the vehicle to maintain its calibration without requiring a visit to an auto mechanic. Numerous examples of new vehicles with factory defects demonstrate an opportunity to significantly improve how automotive companies cope with this problem. A cloud-based service, such as those implemented in some embodiments, that actively monitors the accuracy of sensors within a vehicle and across the broader landscape of vehicles is would result in a safer vehicle. Today, most vehicle sensors merely relay their information to various control processes (e.g., the automatic transmission's gear shifting) and lack the ability to interact through communication protocols, to respond to message queries, and to update their software remotely.

[0028] In an exemplary embodiment, the use of multiple sensor readings originating from different sensing modalities and potentially different vehicles includes the collection of various sensor readings from within a vehicle. A system tags and formats this data with vehicle identification information, position, and timing. The vehicle relays tagged sensor data via an appropriate communication interface to a data monitoring service (such as the VDRM). The VDRM may be a computing function running within a vehicle, or may be a monitoring service that exists outside of the vehicle, such as in the cloud. The VDRM uses a broad database of vehicular data (such as positions of other vehicles and the sensors that they have available) to determine the benefit of additional data and to query those vehicles with data beneficial to calibration calculations. The VDRM verifies the data's accuracy and determines calibration functions to correct the inaccuracies of data measured by a corresponding vehicle's sensor. The VDRM distributes an update to the vehicle's computing system.

[0029] In an exemplary embodiment, a system employs different sensors within or on a vehicle or associated with a vehicular context. These sensors make their measurements, which are relayed through appropriate interfaces internal to a vehicle computing unit, such as through the CAN bus or through interfaces under development by the Automotive Multimedia Interface Collaboration (AMI-C) or by the Open Service Gateway Initiative (OSGi). The vehicle computing unit, which may correspond, for example, to the ECU (engine control unit), appropriately timestamps and attaches vehicle identifiers and position information (such as is provided by GPS) to the data prior to relaying the associated sensor readings to an external data monitoring service. This service, referred to as the VDRM, may be in the cloud or within a vehicle. A VDRM may collect data from many disparate sources, perform advanced data analytics on the sensor data, and use this data to estimate underlying accuracy. The VDRM may use a mechanism to recalibrate associated sensors. In particular, the VDRM leverages its broad database recording the presence of other vehicles and their locations to fetch data used to improve sensor calibrations. The VDRM may distributes recalibration function(s) as software updates for an associated vehicle's computing unit to install the software.

[0030] Numerous embodiments may follow the general structure outlined above with differences related to the communication and computation modalities used to collect and disseminate the data and where decisions are made. For example, vehicular information and sensor data may be shared through a cellular infrastructure, or fully-distributed through another means, such as via V2V communication. Similarly, the computation may be server-directed (as in the case of cloud-computing models for automated driving), or even autonomous (where each vehicle has its own VDRM that makes its own decisions).

[0031] FIG. 1 depicts an exemplary case 100 involving two vehicles 104, 108 that use their sensors to make estimates of the road slope for a specific location. In this scenario, two vehicles (Vehicle A 104 and Vehicle B 108) make, at slightly different times, measurements associated with the road slope at a specific location. Each vehicle has a longitudinal acceleration sensor 102, which may be from different original equipment manufacturers (OEMs), and the associated data is used to arrive at an estimate of the road slope. For one embodiment, a vehicle 104, 108 subtracts an acceleration measurement (measured by differentiating the vehicle's velocity at periodic intervals) from the longitudinal acceleration sensor's 102 reading and divides the result by the gravitational constant g (9.8m/s²) to determine sin(0), where Θ is the road slope.

[0032] A vehicle 104, 108 transmits 106, 110 the data for delivery to a VDRM 116. The vehicle 104, 108 encodes the sensor data for the appropriate format. For example, the Vehicle Sensor Data Cloud Ingestion Interface Specification describes a format that may be used for relaying vehicular sensor data to an analytical processing backend. The framing of the sensor data may include auxiliary information, such as timestamps, vehicle identifiers, and position information. For the example of FIG. 1, the vehicle tags the acceleration and longitudinal acceleration with identifiers associated with the data's origin (Vehicle A or Vehicle B), a time stamp, and a GPS position. The tagged data is provided to the VDRM 116 service via a communications system, link, or protocol, such as a cellular network 1 12 and Internet backbone 114.

[0033] The VDRM 1 16 analyzes the data provided by Vehicle A 104 and Vehicle B 108. For example, the VDRM 1 16 may have contextual information associated with vehicles in the vicinity of Vehicle A 104 and determine that Vehicle B's 108 measurement of the road slope Θ is more accurate (for example, because Vehicle B' s sensor 102 comes from an OEM that manufactures higher-quality sensors or because Vehicle B previously made a sufficiently accurate measurement (within an error threshold) of the road slope at a location where the true slope was measured manually or by other means). If the VDRM 1 16 has the data used for analysis, the VDRM 1 16 may perform calibration calculations and communicate an update 1 18 to Vehicle B 108. If the VDRM 1 16 lacks this data, the VDRM may query Vehicle B 108 to provide the data used to correct Vehicle A's calibration issue. The VDRM 1 16 possesses the data, and may determine, for example, that Vehicle A's 104 estimate of Θ lacks sufficient accuracy because Vehicle A's estimate deviates significantly from Vehicle B' s 108 estimate.

[0034] In this example, the VDRM 1 16 derives a correction to the longitudinal acceleration sensor in Vehicle A 104. Using Vehicle A' s 104 raw acceleration a (which may be derived from vehicle speed and used as an accurate value), the estimate Θ_Β determied by Vehicle B 108 may be used in place of Θ to calculate an updated value for _ion5, which is the acceleration from the longitudinal acceleration sensor. The updated estimation is: al'ong = a + g sin(0 - Θ_Β), and using the small angle approximation for sine (sin θ = Θ for small values of Θ), the amount of improvement directly relates to the difference, | Θ— Θ_Β |. In fact, g sin(0— Θ_Β), which may be approximated by (g) (6— Θ_Β) for small values of Θ— Θ_Β , serves as a one-point calibration offset for Vehicle A' s longitudinal acceleration sensor. The VDRM 1 16 sends the one-point calibration offset as a software patch back to Vehicle A through an appropriate communication interface.

[0035] FIG. 2 illustrates a V2V VANET realization 200, one embodiment of systems and methods disclosed herein. The figure depicts a V2V VANET scenario 200, in which two fleets of vehicles 202, 204, 206, 208, 210, 212 move in formation and are connected to each other via an ad hoc network communication protocol (such as with proposed DSRC communications). Vehicles A 202, B 204, C 206, and D 208 have similar sensors (such as the acceleration sensors described in the previous discussion). Vehicle A' s 202 VDRM determines that more data may be used to verify sensor calibrations. Through contextual update messages shared previously through the V2V VA ET, Vehicle A 202 may determine to issue a query 214 to Vehicle B 204, C 206 and D 208 for their acceleration sensor data. Vehicle B 204, C 206 and D 208 use the VANET to exchange messages (depicted as dotted lines) containing sensor information. In FIG. 2, Vehicle B 204 acts as a relay for data from C 206 and D 208. Vehicle A 202 may use this data to assess the accuracy of its sensors and install an appropriate calibration patch to Vehicle A's 202 sensors. A variation of the peer-to-peer VANET scenario uses designated representatives of a fleet running the VDRM and making calibration decisions for various systems within the fleet. This embodiment uses the V2V network to issue configuration commands within the fleet for sensor updates.

[0036] FIG. 3 shows a messaging sequence diagram 300 for sensor data requests 314. In this example, Vehicle A 302 makes measurements (such as periodic cross-checking of environment parameters 310) associated with road slope (Θ) at a specific location (e.g., using a longitudinal acceleration sensor and vehicle torque sensor). For one embodiment, a plurality of sensors (such as two or more sensors) may be used to measure or estimate a parameter. One example method calculates sin Θ using the longitudinal acceleration sensor. Another example calculates sin Θ using the vehicle's torque sensor readings along with the vehicle's powertrain, engine torque, and torque converter characteristics. For one embodiment, Vehicle A 302 may determine that there is a sensor calibration issue 312. Vehicle A 302 sends a sensor data request 314 to Vehicle B 304, which relays the request to Vehicles C 306 and D 308. Vehicles C 306 and D 308 respond 316, 320 with the requested data. For this example, Vehicle C's 306 response is forwarded 318 on to Vehicle A 302. For one embodiment, Vehicle A 302 initiates a calibration procedure 322, which may use the requested parameters. For one embodiment, a calibration procedure 322 may comprise adjusting sensor readings to be proportional to the requested parameters.

[0037] FIG. 4 illustrates a system 400 of sensor measurements for three different vehicles 402, 404, 406. In this example, the sensor readings relate to humidity readings used to determine current weather conditions. The sensor readings for each vehicle are sent to the other two vehicles. For one embodiment, the sensor data may be fused together by data fusion modules 414, 416, 418 and shared with all three vehicles 402, 404, 406. Using the combination of sensor data measured by vehicle sensors 408, 410, 412 from all three vehicles 402, 404, 406, Vehicle l 's 402 VDRM determines that snow has recently fallen and that the road is currently wet. This determination is sent to Vehicles 2 (404) and 3 (406).

[0038] Various techniques that may be used in the re-calibration process are described in, for example, a journal article by R. C. Luo, Chih-Chen Yih and Kuo Lan Su, Multisensor Fusion and Integration: Approaches, Applications, and Future Research Directions, 2(2) IEEE SENSORS 107- 119 (Apr. 2002).

[0039] FIG. 5 shows an example 500 of types of sensor data that may be shared by VDRMs using the Vehicle Sensor Data Cloud Ingestion Interface Specification (v2.0.2) published by HERE. Such standardized data types may be used for real-time sharing of sensor information between vehicles and the cloud or via V2V communications (such as DSRC or LTE-Direct).

[0040] FIG. 6 shows a system 600 for a sensor' s measurement of vehicle acceleration 602, which the vehicle 610 uses to estimate the slope (0) 614. The equation for longitudinal acceleration holds a direct relationship between road slope angle for an incline 612 and longitudinal acceleration 608. The vehicle 610 uses its acceleration sensor 606, to calculate slope (Θ) 614. The acceleration sensor 606 measures acceleration 608 as: asensor = a + # Sin 0 where a is the vehicle acceleration 602 and g sin Θ is the directional component of the force of gravity 604.

[0041] The vehicle's acceleration 602 (measured, e.g., by differentiating the vehicle' s velocity at periodic intervals) is subtracted from the longitudinal acceleration sensor' s reading 608 and divided by the gravitational constant g (equal to 9.8m/s²) to yield sin(0), where Θ is the road slope 614. Plugging in the trigonometric small angle approximation for sine and solving for Θ produces:

Θ = sin(0) = ^ ≡^ = ^asensor ^

9 9

[0042] FIG. 7 shows a system 700 with the forces acting on vehicle driving on a slope 714. Similar to longitudinal acceleration, the equation for output torque may be used to calculate road slope 716, and the equation uses sensor readings associated with a vehicle's powertrain to estimate output torque, engine torque characteristics, and torque converter characteristics. These values further relate to engine torque characteristics, such as throttle, and engine speed. Starting with F = ma and T = r x F and applying these equations to the vehicle 712 and to one of its wheels, the following relations exists:

(M) {a_sensor) = ( )(a) + (M)(g sin e) ( ) (a) + (M)(0 sin Θ) = ¾^ - F_L where Jis torque; r is the distance from the center of mass to the application point of the force; M is mass of the vehicle 712; F_L is the load force of the road 706; R_wis the radius of the wheel; and T_wo is the total wheel output torque. Therefore, Mg sin Θ is the direction component force of gravity 704, and a is the vehicle acceleration 702. The force due to rotational torque of the rear

T

wheel 710 is— , while vehicle acceleration 708 measured by a vehicle sensor is a_sensor.

[0043] Breaking the forces into parallel and perpendicular directions for the motion of the vehicle, the equation for parallel motion forces becomes:

( ) (a) = ¾≥- F_L - (M) (g

[0044] Solving for Θ (716) produces:

[0045] Hence, FIG. 7 shows another sensor reading and associated equations used to calculate slope.

[0046] Numerous sensors may use embodiments described herein, including but not limited to accelerometers (used in impact detection and motion measurements), pressure sensors (e.g., used in air intake control, monitoring fuel consumption, tire conditions), temperature sensors (e.g., used in monitoring and controlling engine conditions, fuel temperature, passenger compartment temperature), phase sensors (e.g., camshaft/crankshaft phase sensors for motor control, and gear shaft speed for transmission control). Angular rate sensors monitor the roll, pitch, and yaw of a vehicle, which informs dynamic control systems, automatic distance control, and navigation systems. Angular and position sensors monitor, for example, the position of gear levers, steering wheel angle, and mirror positions. RADAR, LIDAR, and camera sensors facilitate new applications, such as blind spot monitoring and lane departure warning. For an exemplary method, these different sensors report their sensor readings within the vehicle through an appropriate in- vehicle network or BUS (e.g. CAN, Local Interconnect Network LIN, Time-triggered Light Weight Protocol TTP, and Bluetooth) to an on-board computer, such as the ECU. This step starts with various sensors, an in-car network, and a central computing unit, and the step generates raw sensor readings associated with different sensing modalities that are relayed to an on-board computer. [0047] The sensor data is formatted and tagged with vehicle identification information, position information (such as GPS data), and timing information. Analogous to a presentation service, raw sensor data is converted into a representation that follows an appropriate schema. Many different schemas may perform this conversion. For example, XML or other markup languages may provide a set of rules for encoding information into machine-readable documents. Other examples include Java Script Object Notation (JSON) and the Vehicle Sensor Data Cloud Ingestion Interface Specification (e.g. version 2.0.2), which is appropriate for relaying vehicle sensor data to a backend server. Additional information may be included with each framed data in order to ensure that various unique contexts (e.g., vehicle identification, position, and time information) associated with that sensor report are provided to the VDRM. This step starts with raw sensor data, timing information, GPS or other position information, and a vehicle identifier and generates formatted data according to an appropriate scheme.

[0048] An appropriate communication interface relays tagged sensor data to an external data monitoring service (the VDRM). This interface uses communication infrastructures, such as cellular, to interface with the VDRM residing in the cloud. For example, MIT's CarTel project uses a distributed mobile computing system developed to collect and visualize data from sensors located on a vehicle and similar systems involving middleware that utilize communication infrastructure to relay data from the car to the cloud may either be implemented by individual car companies, by the cellular industry itself, or by third party vendors. Different types of communication interfaces may be available to middleware. Middleware may be capable of interfacing through appropriate communication interfaces between the onboard computing unit and an external server. The middleware may operate to ensure reliable communication delivery. As a result, a system delivers tagged and formatted data to the VDRM reliably.

[0049] FIG. 8 is a schematic diagram illustrating an example scenario 800 in which two sensors on a vehicle 810 have conflicting results. In an example embodiment shown in FIG. 8, vehicle l 's LIDAR system estimates the location of a building 802 as having GPS coordinates of (Lat. 41.8786491, Long. -87.6429059) 804. Vehicle l 's RADAR system estimates the location of the building as having GPS coordinates of (Lat. 41.8786491, Long. -87.6429427) 806. Vehicle 1 uses its LIDAR system in conjunction with its RADAR system to form a confirmed picture of the landscape around the vehicle. FIG. 8 relates to two or more sensors used in conjunction to produce confirmed readings of a particular parameter. GPS coordinates provide one exemplary method to record the location of buildings, trees, vehicles, people, and other objects, and the LIDAR and RADAR systems may use alternate methods. Vehicle 1 (810) detects a discrepancy between the two sensor readings for the building's location. For example, Vehicle 1 (810) may determine that the two locations as measured by the two different sensor modalities (RADAR and LIDAR) differ from one another by more than a threshold distance. For this example, vehicle l 's LIDAR longitude reading differs from the other readings by about 0.0000368 (approximately 10 feet). In response to detection of the discrepancy, Vehicle 1 (810) contacts another vehicle 812 via short- range vehicle-to-vehicle wireless communication for an estimate of the building's location. Vehicle 2 (812) responds 814 to vehicle l 's general broadcast message requesting sensor readings of the building's location. Vehicle 2 (812) responds 814 by providing its own estimate of the building's location (which may be based on RADAR, LIDAR, a combination of the two, or some other modality). In this example, vehicle 2 (812) reports a LIDAR-based estimate 808 of the building's location is at (Lat. 41.8786491, Long. -87.6429427). Vehicle 1 (810) compares Vehicle 2's estimate 808 of the building's location with the different estimates generated by vehicle l 's own sensor. Vehicle 1 (810) selects the reading of one of its own sensors that is closest to the reading received from vehicle 2 (812). For this example, vehicle 1 (810) determines that the estimate from its LIDAR system regarding the building's location is less reliable than the estimate from the RADAR system. In some embodiments, an alert may be issued indicating the presence of a discrepancy, and the alert may indicate that the LIDAR system is likely the source of the discrepancy. Vehicle 1 (810) may temporarily not use LIDAR readings and may rely on the RADAR system. For one embodiment, a disparity (or discrepancy) may comprise two sensor readings that differ by more than a predetermined threshold.

[0050] In the example of FIG. 8, the issue with the LIDAR system may be addressed using one or more of several techniques. In one exemplary embodiment, a recalibrating vehicle with a quarantined sensor asks other vehicles for sensor measurements of an entire landscape. Vehicles with reliable LIDAR system readings respond with positive acknowledgements. The recalibrating vehicle requests an entire landscape of LIDAR readings from the first vehicle to respond with a positive acknowledgement. The recalibrating vehicle compares the first vehicle's set of LIDAR readings with a new set of LIDAR readings by the recalibrating vehicle to search for a pattern between the two sets of readings.

[0051] If the incorrect estimate appears to be a one-time error (discerned, for example, by determining that all of the recalibrating vehicle's new LIDAR readings fall within a margin of error of the other vehicle's readings), the recalibrating vehicle may take successive LIDAR readings at for example a regular time interval. If the recalibrating vehicle's successive LIDAR readings all match the other vehicle's readings (or fall within a margin of error), the recalibrating vehicle may resume using the LIDAR system.

[0052] If the recalibrating vehicle determines that all of its LIDAR readings differ from the other vehicle's readings, the recalibrating vehicle may attempt to calculate a translation function. This translation function (if found) may correspond to a recalibration of the LIDAR system. If self-recalibration is unsuccessful, a recalibrating vehicle may communicate an error message for a user to seek maintenance of the LIDAR sensor (e.g., to clean the sensor). If the vehicle is capable of self-cleaning of the LIDAR sensor, the recalibrating vehicle may ignore the LIDAR system's readings until a self-cleaning and recalibration procedure completes. After the LIDAR sensor is cleaned (e.g., via a manual, a self-cleaning, or an automated process), the LIDAR system may attempt a recalibration procedure by comparing the recalibrating vehicle's LIDAR readings with readings from other vehicles. If the recalibrating vehicle's readings fall within a margin of error of the other vehicle's readings, the recalibrating vehicle deems the LIDAR system to provide reliable results. The recalibrating vehicle records this assessment in memory.

[0053] If most or all of the recalibrating vehicle's readings differ with the other vehicle's readings, the recalibrating vehicle may attempt to calculate a translation function. If the recalibrating vehicle finds such a translation function, the vehicle records the equation in memory and uses the equation with LIDAR system readings. A recalibrating vehicle deems the LIDAR system reliable and records this determination in memory. If the recalibration procedure is unsuccessful, the recalibrating vehicle may raise an error message (e.g., sent to the vehicle's dashboard display controller to have the error displayed on the dashboard for the vehicle operator or sent to a central database located in the cloud) to have the LIDAR system repaired manually.

[0054] Although FIG. 8 focuses on LIDAR and RADAR sensors and systems, these sensors represent exemplary embodiments. Other sensors, such as accelerometers, temperature sensors, or other vehicle sensors apply to the processes discussed with regard to FIG. 8.

[0055] In exemplary embodiments, the VDRM includes a database and computational resources to conduct deep pattern analysis of the patterns contained within its collection of sensor data. Due to the volume of data associated with many sensors and vehicles subscribing to the VDRM, calibration analysis may be restricted to a subset of the data stored at the VDRM. The VDRM may acquire additional data from other vehicles to improve calibration decisions. One objective may be to determine which data within a VDRM's database may be used to determine if sensor readings are out of calibration for a certain vehicle or sensor. For example, data may be limited to vehicle calibration data originating from vehicles located in close proximity to Vehicle A. Similarly, a VDRM may retrieve data from another vehicle's sensors (for example, Vehicle B in the previous discussion above). Such retrieval may occur through one or more communication interfaces.

[0056] At the VDRM there may be a repository of tagged data from many different sensors and from many different vehicles. The VDRM may also store contextual data regarding other vehicles in order to facilitate the proactive querying of data from those vehicles. Querying other vehicles in order to fetch data uses a connection to an appropriate communication interface. An appropriate subset of relevant data may be determined for deeper calibration analysis. While making this determination, a VDRM may send data requests to other vehicles for sensor data to facilitate calibration decisions.

[0057] In an exemplary embodiment, the VDRM checks the validity and calibration status of whether sensor data involves using one or more data blocks provided to the VDRM. The VDRM analyzes a collection of the received data coming from many different modalities and potentially many different vehicles to populate an N-dimensional vector X. The VDRM may have determined, using a variety of methods such as machine learning or applying physical models, a calibration- valid region that may be used to determine if data associated with X is calibrated properly. The precise specification of this validity region and the amount of allowable error before a sensor and its readings are determined to be out of calibration corresponds to a formally-specified policy that may use other contextual factors, such as risk associated with decisions made using this data.

[0058] An example vehicle has multiple sensors reporting measurements associated with two different phenomena, XI and X2, having a functional relationship ψ, which may be described via a physical law or learned empirically. Based on the observed value of XI, X2 is within a certain confidence region. Measurement XI has an associated confidence region governed by the accuracy of its calibration, such as measurement noise or other factors. Considering measurement errors for X2 and using the function ψ, the VDRM may map the confidence region in XI -space to a corresponding confidence region in X2-space. Taken together, these confidence regions allow the VDRM to determine a calibration-valid region Ω. If the measured value of X2 does not fall within this calibration-valid region, a vehicle may determine that there is a calibration error associated with X2. The VDRM may use the function ψ and the empirical value for XI to determine what X2 may have been, and use this information to determine how X2 may be corrected (for example, where there is only a single measurement of the phenomena associated with X2, the VDRM may deduce a single point recalibration to correct sensor offset errors). [0059] A VDRM may use the multimodal and multi-vehicle nature of a problem to determine which sensors are miscalibrated and to make appropriate corrections. Exemplary embodiments enable other vehicles and other sensor types to help correct a sensor that is out of calibration. Such embodiments may operate by taking a subset of the VDRM data repository suitable for calibration analysis and applying algorithms (such as machine learning or model-based) to the subset of data to determine specific sensors with calibration issues and to pinpoint potential correction functions.

[0060] After determining a correction function, the VDRM may distribute an update to the corresponding vehicle and associated control hardware and software. The software update may be performed using a vehicular system distribution protocol. One exemplary method minimizes impact on the vehicle performance during patching (e.g., a sensor may not be offline during critical times). The delivery of the update from the VDRM to the vehicle may use the same communication interfaces used previously (though not necessarily). The VDRM may reside, for example, within the vehicle, within a specified fleet-leader vehicle, or within the cloud. Some embodiments disclosed herein use a computing service distinct from the sensors to patch the sensors and related calibration data. This update results in improved calibration of a vehicle's sensors and improved sensor readings.

[0061] The VDRM issues a software update to the vehicle that provides updates for performing calibration. Several variations of this step exist that fall within the scope of systems and methods disclosed herein. For one alternative, instead of issuing a software update, the VDRM issues warning messages to the vehicle (and thereby to its driver) that warn of miscalibration of vehicular sensors and determines which sensor(s) to repair. This message may be relayed through the on-board computing unit as a new vehicle warning message.

[0062] In another alternative, the VDRM issues a command to the vehicle requesting enablement of calibration enhancement mode. This mode collects data for the affected sensor(s) more frequently and relays the data to the VDRM for analysis. This variation may occur, for example, if the previous data analysis yielded inconclusive results or lacked proper confidence in the conclusion.

[0063] Yet another alternative has the VDRM relay a recalibration function directly to any autonomous vehicle control software that uses such data. For example, a vehicle may be steered and controlled remotely by a cloud-based service. In such a case, the vehicular control algorithm may correct for miscalibrated data via the recalibration function. Relaying the update to the application directly may eliminate delay. [0064] A further variation accommodates situations in which an owner installs additional features or parts to the vehicle. These after-market additions may change the vehicular ecosystem. They may introduce uncalibrated sensors (or sensors previously unmonitored by the VDRM). Such after-market changes may also alter the calibration of other sensors (e.g., by altering the vehicle's weight or by altering a wheel' s circumference with larger tires). The vehicle may register the after- market changes and associated sensors with the VDRM, which issues calibration test "data run" instructions to the vehicle for the driver to perform. These "data run" instructions enable the vehicle to collect data which a system uses to calibrate the after-market sensors.

[0065] Several exemplary embodiments of systems and methods disclosed herein handle sensor calibration errors. For one embodiment, a time correction may be used. Reported time readings often lack proper calibration. For example, a time reading may correspond to a different time zone. In another example, different clocks may report time under different standards. One manufacturer may report time in Coordinated Universal Time (UTC) mode while another manufacturer uses GPS time (which has a 17-second offset from UTC time). Such an issue may be detected by referencing a ground truth (e.g., by using the local time at the VDRM or by analyzing timestamps from other concurrent sensor reports originating from other vehicles). A recalibration function for a time correction would correspond to an offset correction, such as shifting GPS time by 17 seconds to obtain UTC. Using incorrect time values may lead to incorrect distance estimates and other applications, such as traffic estimation.

[0066] Another exemplary embodiment uses multiple vehicles to automatically detect a fog condition. The automated driving system measures the atmospheric visibility via various cameras mounted on vehicle. Accurate assessment of visibility distance enables a system to inform a driver that a vehicular assistance service is not available or is providing degraded service quality due to fog affecting detection of road lanes and other vehicles. Various approaches for estimating the visibility distance may be used, such as the techniques described in N. Hautiere, J-P Tarel, J. Lavenant, and D. Aubert, "Automatic Fog Detection and Estimation of Visibility Distance through use of an Onboard Camera," in Machine Vision and Applications, pg. 8-20, 2006. In a scenario where many vehicles (with CCD cameras estimating visibility distance) make measurements and report their visibility distance estimates to the VDRM, the VDRM determines vehicles whose visibility distance estimates differ significantly compared to other vehicles. In particular, one may use a collection of vehicles located at the same vicinity within a short period of time to calculate better and more robust estimates of the visibility distance. The VDRM determines which vehicles provide estimates outside an acceptable level of discrepancy. The VDRM communicates to the affected vehicle(s) that one or more of its CCD cameras is faulty. The VDRM may also perform an analysis of the histogram of that vehicle's CCD image and compares that vehicle's CCD image with histograms of other CCD cameras that have acceptable accuracies. Using the histograms of other CCD cameras from other vehicles, the VDRM estimates what the luminance distribution may have been for a faulty camera and corrects the discrepancy with a histogram renormalization algorithm.

[0067] Yet another exemplary embodiment uses a multi-modality temperature sensor to aid computer-vision sensors. For example, estimating the external temperature may inform automated driving applications about road conditions, such as a potential for an icy road. While freezing temperatures may not indicate icy conditions, high temperatures may indicate a lack of such icy conditions. This set of observations provide another scenario to detect improper calibration of cameras and other optical sensors. Computer vision systems are often sensitive to the distribution of light and the associated poor contrast due to the glare, which leads to poor classification decisions. In such situations, the camera has lost its ability to handle sensitivity to light. Renormalizing the histogram of the pixel values reported by the camera enables a system to compensate for this situation. Although blind approaches to histogram normalization may be used, using an algorithm such as Lloyd's histogram normalization algorithm may still lead to incorrect classification decisions. Instead, using temperature information to inform the histogram re- calibration may lead to more accurate results in certain situations. For example, suppose the sensor data from a computer vision algorithm running on camera data relayed to the VDRM classifies the road as icy even though the external temperature is sufficiently high that the road is nearly certain to be free of ice. Normalizing the histogram subject to "non-icy" conditions yields a better calibration than a histogram normalization algorithm that operates without regard to temperature data.

[0068] Use of multi-modality in road slope estimation provides another exemplary embodiment. Road slope estimation is used in many aspects of automated vehicular control. For traditional automatic transmissions, accurate estimation of road slope helps avoid improper gear shifting. In the case of platooned autonomous vehicles, accurate road slope estimations help coordinate braking by multiple vehicles. Information regarding road slope may be used to help predict whether a vehicle will stop faster or slower than the same vehicle on a flat road. Many different sensor modalities, such as longitudinal acceleration sensors, vehicle output torque sensors, and similar sensors may aid in estimating road slope. [0069] For one embodiment, a system has longitudinal acceleration and vehicle output torque sensors. For one embodiment, two methods for calculating road slope (Θ) may be used to provide a multi-parameter means to corroborate sensor readings within each sensor system. FIGs. 6 and 7 detail the calculation of Θ under each approach. For example, if the vehicle has access to a precise road slope value (such as via an official Department of Transportation measurement), the vehicle may validate or correct the reading of the longitudinal acceleration sensor. One method of improving a calibration improves noise rejection capabilities of a differentiator through better tuning of cut-off characteristics of a low-pass filter used to reject high frequency noise, e.g., using techniques described in the journal article H. Ohnishi, J. Ishii, M. Kayano, & H. Katayama, A Study on Road Slope Estimation for Automatic Transmission Control, 21 JSAE REVIEW 235-240 (2000). For example, if the road slope reading from the longitudinal sensor estimation is considered accurate, this reading may be used with the output torque equations estimating road slope, which use torque, vehicle acceleration, and estimated road load. An accurate road slope may be used to calculate improved estimates for torque, acceleration, road load, and the more basic parameters that govern these sensor measurements (e.g., variation in the wheel radii affect accurate estimation of vehicle velocity and acceleration).

[0070] Another exemplary embodiment uses multiple sensor modalities in road friction estimation. Friction estimation supports many functions, such as safety systems, autonomous cruise control, collision avoidance, and road quality assessment. Many different types of data may be used for estimating tire-road friction, such as video data that is processed to determine the materials associated with pavement texture and the presence of water on the road, acoustic sensor data combined with pattern recognition, tire strain sensor data, and/or data regarding the velocity of driven and non-driven wheels. Exemplary techniques that may be used include those described in F. Gustafsson, Estimation and Change Detection of Tire-Road Friction Using the Wheel Slip, PROCEEDINGS OF IEEE SYMPOSIUM ON COMPUTER AIDED CONTROL DESIGN (1996), and in A. Andrieux, P.O. Vandanjon, R. Lengelle, and C. Chabanon, New Results on the Relation between Tire-Road Longitudinal Stiffness and Maximum Available Grip for Motor Car, VEHICLE SYSTEM DYNAMICS, 1 -24 (2010).

[0071] In some embodiments, the types of sensors used to estimate tire-road friction are further used to detect wheel slippage events using techniques such as those described in C. Ward, K. Iagnemma, Model-based Wheel Slip Detection for Outdoor Mobile Robots, PROCEEDINGS OF 2007 ΓΕΕΕ INTERNATIONAL CONFERENCE ON ROBOTICS AND AUTOMATION (2007). Sensor measurements maybe used to help estimate the friction coefficients and tire longitudinal slippage rates through physical models of the dynamics associated with a vehicle's motion. For example, using sensors to measure longitudinal traction force F_x and normal ground reaction force F_z, the road friction coefficient may be estimated as μ =— . Similarly, one example method estimates the slippage σ as the relative difference of a wheel's circumferential velocity and its absolute velocity. Other approaches estimate slippage and friction directly from sensors associated with an active anti-lock braking system (ABS) at varying levels of excitation. Further relationships governing the tradeoffs between friction and slippage depend on vehicle velocity, vehicle weight, and pavement type and condition, and often the relationship between friction and slippage under varying conditions is used to estimate the road type and road conditions (e.g. dry asphalt versus wet asphalt versus icy asphalt). Collectively, many different approaches to estimating friction and slippage exist, ranging from online algorithms that use in-vehicle sensors to estimate these parameters in real-time, to more highly-specialized and calibrated measuring devices that estimate these parameters, such as France's Adhera 2 sensor, a similar Adhera research sensor, Michelin's C 35 vehicle sensor, and the Dynatest trailer. Using various different approaches to estimate the fundamental road parameters associated with tire friction and slippage, embodiments disclosed herein may use a collection of road sensor readings from many sensor modalities and from many vehicles for estimating the accuracy and validity of sensor readings from within each individual vehicle. For example, using optical sensors to recognize that the road conditions correspond to wet asphalt may be used to directly assess the slip slope associated with the μ and σ tradeoff space, as well as the maximal available friction coefficient. The ABS system may validate braking measurements using these values, and sensors may use these values to estimate the ratio of velocities for driven and non-driven wheels. Discrepancies between μ and σ values calculated through different modalities (or validated through multiple vehicle sensor readings) suggests miscalibration of the underlying sensors. These discrepancies may be corrected by using the values of μ and σ associated with the most-correct modality to invert the equations associated with other, less-accurate modalities to arrive at calibration functions that describe how to correct less-accurate sensor readings.

[0072] Exemplary embodiments disclosed herein may be implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity, which may be used to implement, for example, an in-vehicle computing system used to collect and process vehicular sensor data and to communicate with other vehicles and with the VDRM. [0073] FIG. 9 is a system diagram of an exemplary WTRU 902, which may be employed as a vehicle's computing system in embodiments described herein. As shown in FIG. 9, the WTRU 902 may include a processor 918, a communication interface 919 including a transceiver 920, a transmit/receive element 922, a speaker/microphone 924, a keypad 926, a display/touchpad 928, a non-removable memory 930, a removable memory 932, a power source 934, a global positioning system (GPS) chipset 936, and sensors 938. The WTRU 902 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0074] The processor 918 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 918 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 902 to operate in a wireless environment. The processor 918 may be coupled to the transceiver 920, which may be coupled to the transmit/receive element 922. While FIG. 9 depicts the processor 918 and the transceiver 920 as separate components, the processor 918 and the transceiver 920 may be integrated together in an electronic package or chip.

[0075] The transmit/receive element 922 may be configured to transmit signals to, or receive signals from, a base station over the air interface 916. For example, in one embodiment, the transmit/receive element 922 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 922 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 922 may be configured to transmit and receive both RF and light signals. The transmit/receive element 922 may be configured to transmit and/or receive any combination of wireless signals.

[0076] In addition, although the transmit/receive element 922 is depicted in FIG. 9 as a single element, the WTRU 902 may include any number of transmit/receive elements 922. More specifically, the WTRU 902 may employ MTMO technology. Thus, in one embodiment, the WTRU 902 may include two or more transmit/receive elements 922 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 916.

[0077] The transceiver 920 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 922 and to demodulate the signals that are received by the transmit/receive element 922. As noted above, the WTRU 902 may have multi-mode capabilities. Thus, the transceiver 920 may include multiple transceivers for enabling the WTRU 902 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0078] The processor 918 of the WTRU 902 may be coupled to, and may receive user input data from, the speaker/microphone 924, the keypad 926, and/or the display/touchpad 928 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 918 may also output user data to the speaker/microphone 924, the keypad 926, and/or the display/touchpad 928. In addition, the processor 918 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 930 and/or the removable memory 932. The non-removable memory 930 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 932 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 918 may access information from, and store data in, memory that is not physically located on the WTRU 902, such as on a server or a home computer (not shown).

[0079] The processor 918 may receive power from the power source 934, and may be configured to distribute and/or control the power to the other components in the WTRU 902. The power source 934 may be any suitable device for powering the WTRU 902. As examples, the power source 934 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like), solar cells, fuel cells, and the like.

[0080] The processor 918 may also be coupled to the GPS chipset 936, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 902. In addition to, or in lieu of, the information from the GPS chipset 936, the WTRU 902 may receive location information over the air interface 916 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. The WTRU 902 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0081] The processor 918 may further be coupled to other peripherals 938, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 938 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0082] FIG. 10 depicts an exemplary network entity 1090 that may be used in embodiments of systems and methods described herein, such as in a VDRM. As depicted in FIG. 10, network entity 1090 includes a communication interface 1092, a processor 1094, and non-transitory data storage 1096, all of which are communicatively linked by a bus, network, or other communication path 1098.

[0083] Communication interface 1092 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 1092 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 1092 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 1092 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 1092 may include the appropriate equipment and circuitry (including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[0084] Processor 1094 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.

[0085] Data storage 1096 may take the form of any non -transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non- transitory data storage deemed suitable by those of skill in the relevant art may be used. As depicted in FIG. 10, data storage 1096 contains program instructions 1097 executable by processor 1094 for carrying out various combinations of the various network-entity functions described herein.

[0086] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0087] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and those instructions may take the form of or include hardware (hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer-readable medium or media, such as commonly referred to as RAM or ROM.

Claims

1. A method comprising: operating a vehicle function of a first vehicle using a plurality of local estimates of a parameter, each of the plurality of local estimates being derived from at least one corresponding sensor of the first vehicle, each of the corresponding sensors having different sensing modalities; in response to detection of a disparity among the plurality of local estimates: comparing each of the plurality of local estimates of the parameter with an external estimate of the parameter, the external estimate being derived from data received from one or more other vehicles, to identify an outlier estimate from among the local estimates, the outlier estimate being the estimate that is most disparate from the external estimate; and discontinuing use of the outlier sensor, from which the outlier estimate was derived, in the operation of the vehicle function.

2. The method of claim 1, further comprising providing an indication to the operator of the first vehicle that the sensor corresponding to the outlier estimate should be serviced.

3. The method of claim 1 wherein detection of the disparity comprises determining that at least two of the plurality of local estimates differ by more than a predetermined threshold, the method further comprising, in response to detection of the disparity: sending to a plurality of vehicles via short-range vehicle-to- vehicle wireless communication information regarding a request for estimates of the parameter; receiving, from the plurality of vehicles, a plurality of other-vehicle estimates of the parameter; and calculating the external estimate of the parameter based on the received plurality of other- vehicle estimates of the parameter.

4. The method of claim 1, wherein the vehicle function is selected from the group consisting of electronic stability, cruise control, collision warning, collision avoidance, anti-lock braking, road quality assessment, and geographic positioning.

5. The method of claim 1, wherein the vehicle function is selected from the group consisting of vehicle safety, and vehicle sensor reading translation.

6. The method of claim 1, wherein the vehicle function is measurement of a physical contour of an environment surrounding the first vehicle.

7. The method of claim 1, wherein the parameter is selected from the group consisting of road slope angle, propelling shaft speed, longitudinal acceleration, vehicle torque, GPS coordinates, road load, road friction, and ratio of velocities for driven and non-driven vehicle wheels.

8. The method of claim 1, wherein the sensing modality for each sensor corresponding to the plurality of local estimates is selected from the group consisting of GPS, RADAR, LIDAR, video camera, electronic management sensor, comfort management sensor, engine diagnostic sensor, propelling shaft speed sensor, longitudinal acceleration sensor, and vehicle torque sensor.

9. The method of claim 1, wherein the sensing modality for each sensor corresponding to data received from one or more other vehicles is selected from the group consisting of GPS, RADAR, LIDAR, video camera, electronic management sensor, comfort management sensor, engine diagnostic sensor, propelling shaft speed sensor, longitudinal acceleration sensor, and vehicle torque sensor.

10. The method of claim 1, wherein detection of the disparity among the plurality of local estimates comprises detecting that at least two of the plurality of local estimates have a difference greater than a predetermined threshold.

11. The method of claim 1, further comprising requesting the data from one or more other vehicles in response to detecting a disparity among the plurality of local estimates.

12. The method of claim 1, further comprising receiving the data from one or more other vehicles by a vehicle to vehicle communications protocol.

13. The method of claim 1, further comprising providing an indication to the operator of the vehicle that the sensor corresponding to the outlier estimate provides an incorrect estimate of the parameter.

14. The method of claim 1, further comprising, in response to detection of the disparity: sending to a plurality of vehicles information regarding a request for estimates of the parameter; and receiving from at least one other vehicle, an other-vehicle estimate of the parameter.

15. The method of claim 1, wherein one of the plurality of local estimates of the parameter is calculated using sensor data measured by a LiDAR system.

16. The method of claim 15, wherein one of the plurality of local estimates of the parameter is calculated using sensor data measured by a RADAR system.

17. A method comprising: operating a vehicle function of a first vehicle using a plurality of local estimates of a parameter, each of the plurality of local estimates being derived from at least one corresponding sensor of the first vehicle, each of the corresponding sensors having different sensing modalities; in response to detection of a disparity among the plurality of local estimates: comparing each of the plurality of local estimates of the parameter with an external estimate of the parameter, the external estimate being derived from data received from one or more other vehicles, to identify an outlier estimate from among the local estimates, the outlier estimate being the estimate that is most disparate from the external estimate; and calibrating the outliner sensor, from which the outlier estimate was derived.

18. The method of claim 17, wherein calibrating the outlier sensor comprises adjusting data measured by the outlier sensor to be proportional to the external estimate of the parameter.

19. A system comprising: a plurality of sensors having different sensing modalities; a wireless communication interface; at least one processor; and a non-transitory computer storage medium storing instructions operative, when executed on the at least one processor, to perform functions comprising: deriving a plurality of local estimates of a parameter from data obtained using the plurality of sensors; determining, from data received from at least a second vehicle over the interface, an external estimate of the parameter; from among the plurality of sensors, selecting a set of at least one sensor to use in operation of a vehicle function, wherein (i) if there is a discrepancy among the plurality of local estimates, the sensor corresponding to the local estimate closest to the external estimate is selected, and (ii) if there is no discrepancy among the plurality of local estimates, the plurality of sensors are selected; and operating the vehicle function using the selected set.

20. The system of claim 19, wherein the instructions are further operative to perform functions comprising: flagging one of the plurality of sensors as unreliable, wherein one of the plurality of sensors is flagged as unreliable if the local estimate corresponding to the sensor differs more than a threshold from the external estimate, and operating the vehicle function without the use of the flagged estimate.