VEHICLE-BASED AIR QUALITY AND NOISE LEVEL SAMPLING FOR USE WITH OFFBOARD MAPPING SOFTWARE

Abstract

A host vehicle for use with a remote processing station (RPS) configured to generate a pollution report from a global set of pollution data includes a vehicle body, a vehicle telematics unit (VTU), a sensor suite, and an electronic control unit (ECU). The sensor suite includes acoustic and/or an air quality sensors respectively configured for collecting pollution data samples. The pollution data samples include ambient noise and/or air quality levels as part of the global set of pollution data. The ECU selectively transmits the pollution data sample(s) to the RPS in response to predetermined conditions, via the, receives the pollution report descriptive of noise and/or air quality levels at a current location or destination of the host vehicle, and executes a control action of the host vehicle or another receiving device in response to the pollution report.

Claims

1. A host vehicle for use with a remote processing station (RPS) configured to generate a pollution report from a global set of pollution data, the host vehicle comprising: a vehicle body; a vehicle telematics unit (VTU) in wireless communication with the RPS, and connected to the vehicle body; a sensor suite, including an acoustic sensor and/or an air quality sensor respectively configured for collecting a pollution data sample at a current location of the host vehicle, the pollution data sample including an ambient noise level and/or an ambient air quality level, wherein the global set of pollution data includes the pollution data sample and additional pollution data samples from one or more additional host vehicles; and an electronic control unit (ECU) in communication with the VTU and the sensor suite, wherein the ECU is configured to selectively transmit the pollution data sample to the RPS in response to a predetermined set of conditions, via operation of the VTU.

2. The host vehicle of claim 1, wherein the sensor suite includes the acoustic sensor and the air quality sensor, and the ECU is configured to receive the pollution report from the RPS, the pollution report being descriptive of a noise level and an air pollution level at the current location or a destination of the host vehicle.

3. The host vehicle of claim 1, further comprising road wheels connected to the vehicle body, wherein the host vehicle is a motor vehicle and the predetermined set of conditions includes the motor vehicle being parked, stationary, or in an off state.

4. The host vehicle of claim 1, further comprising a display screen, wherein the pollution report includes mapping data indicative of the ambient noise level and the ambient air quality level, and wherein the ECU is configured for transmitting the pollution report to the display screen for presentation of the mapping data thereon.

5. The host vehicle of claim 1, wherein the vehicle body defines a vehicle interior, and wherein the acoustic sensor includes at least one microphone positioned within the vehicle interior.

6. The host vehicle of claim 1, wherein the air quality sensor includes a particle counter.

7. The host vehicle of claim 1, wherein the air quality sensor includes a gas sensor.

8. The host vehicle of claim 1, wherein the ECU is configured to limit activation of the sensor suite to less than five minutes per hour.

9. The host vehicle of claim 1, wherein the ECU is configured to prompt an operator of the host vehicle with an alternative travel route option based on the pollution report.

10. A method for use with a host vehicle in communication with a remote processing station (RPS), the RPS being configured to generate a pollution report from a global set of pollution data, the method comprising: in response to a predetermined set of conditions, using a sensor suite of the host vehicle to collect a pollution data sample at a current location of the host vehicle, via an electronic control unit (ECU) of the host vehicle, wherein the sensor suite includes an acoustic sensor and/or an air quality sensor respectively configured to measure an ambient noise level and an ambient air quality level; transmitting the pollution data sample to the RPS a vehicle telematics unit (VTU) of the host vehicle, the VTU being in communication with the ECU, wherein the pollution data sample is a constituent part of the global set of pollution data; receiving the pollution report from the RPS, the pollution report being based on prior data samples from a plurality of host vehicles; and in response to the pollution report, displaying the ambient noise level and/or the ambient air quality level on a display screen.

11. The method of claim 10, wherein the RPS is programmed to store a history of the pollution reports for a given region of operation on a computer-readable storage medium, as historic data, and to generate a model of noise pollution and air pollution for the given region using the historic data, wherein receiving the pollution report from the RPS includes receiving the historic data.

12. The method of claim 10, wherein the predetermined set of conditions includes the host vehicle being parked, stationary, or in an off state.

13. The method of claim 10, wherein the host vehicle includes a vehicle body defining a vehicle interior, and wherein using the sensor suite of the host vehicle includes using, as the acoustic sensor, at least one microphone positioned within the vehicle interior.

14. The method of claim 10, wherein using the sensor suite of the host vehicle for collecting the pollution data sample includes using a particle counter as the air quality sensor.

15. The method of claim 10, wherein using the sensor suite of the host vehicle for collecting the pollution data sample includes using a gas sensor as the air quality sensor.

16. The method of claim 10, further comprising limiting activation of the sensor suite to less than five minutes per hour via the ECU.

17. The method of claim 10, further comprising prompting an operator of the host vehicle via the ECU with an alternative travel route option based on the pollution report.

18. A computer-readable storage medium on which is recorded instructions, the instructions being executable by a processor of a remote processing station (RPS) to cause the processor to: receive a global set of pollution data from a plurality of host vehicles in communication with the RPS, each respective host vehicle having a corresponding sensor suite operable for collecting a pollution data sample at a current location of the respective host vehicle, via an electronic control unit (ECU) of the host vehicle, wherein the sensor suite includes an acoustic sensor and/or an air quality sensor respectively configured to measure an ambient noise level and an ambient air quality level, and wherein the pollution data sample is a constituent part of the global set of pollution data; calculate an uncertainty level in the global set of pollution data for the current location via the processor; generate, via the processor using the global set of pollution data, at least one color-coded map that is indicative of the ambient noise level and an ambient air quality level at the current location and/or a destination of the host vehicle, the at least one color-coded map being based in part on the uncertainty level; and transmitting a pollution report to a receiving device for display thereon, the pollution report including the at least one color-coded map.

19. The computer-readable storage medium of claim 18, wherein the processor has access to a history of the pollution reports for a given region of operation as historic data, the instructions being executable to by the processor to cause the processor to generate a model of the ambient noise level and an ambient air quality level for a region inclusive of the current location and/or the destination, using the historic data, and to generate the pollution report using the historic data.

20. The computer-readable storage medium of claim 18, the instructions being executable to by the processor to cause the processor to selectively request activation of the sensor suite for one or more of the host vehicles based on predetermined collection criteria.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate implementations of the disclosure and together with the description, serve to explain the principles of the disclosure.

[0019] FIG. 1 is a schematic illustration of a representative vehicle network, each respective host vehicle of which is equipped with a corresponding sensor suite operated in accordance with the present application.

[0020] FIG. 2 is a schematic circuit diagram for an environmental system for use aboard the various host vehicles shown in FIG. 1.

[0021] FIG. 3 illustrates representative air quality and noise level maps generated by a remote processor and displayed via a display screen as part of the present strategy.

[0022] FIG. 4 is a flow chart describing an exemplary embodiment of the present method.

[0023] The appended drawings are not necessarily to scale, and may present a somewhat simplified representation of various features of the present disclosure as disclosed herein, including, for example, specific dimensions, orientations, locations, and shapes. Details associated with such features will be determined in part by the particular intended application and use environment.

DETAILED DESCRIPTION

[0024] The present disclosure may be embodied in many different forms. Representative examples are shown in the various drawings and described herein in detail as non-limiting representations of the disclosed principles. To that end, elements and limitations described in the Abstract, Introduction, Summary, and Detailed Description sections, but not explicitly set forth in the appended claims, should not be incorporated into the claims, singly or collectively, by implication, inference, or otherwise. Moreover, unless specifically disclaimed, use of the singular includes the plural and vice versa, the terms “and” and “or” shall be both conjunctive and disjunctive, “any” and “all” shall both mean “any and all”, and the words “including”, “containing”, “comprising”, “having”, and the like shall mean “including without limitation”.

[0025] Words of approximation such as “about”, “almost”, “substantially”, “generally”, “approximately”, etc., may be used herein in the sense of “at, near, or nearly at”, or “within 0-5% of”, or “within acceptable manufacturing tolerances”, or logical combinations thereof. Also as used herein, a component that is “configured to” perform a specified function is capable of performing the specified function without alteration, rather than merely having potential to perform the specified function after further modification. In other words, the described hardware, when expressly configured to perform the specified function, is specifically selected, created, implemented, utilized, programmed, and/or designed for the purpose of performing the specified function.

[0026] As used herein, a component that is “configured to” perform a specified function is capable of performing the specified function without alteration, rather than merely having potential to perform the specified function after further modification. In other words, the described hardware, when expressly configured to perform the specified function, is specifically selected, created, implemented, utilized, programmed, and/or designed for the purpose of performing the specified function.

[0027] Referring now to the drawings, wherein like reference numbers refer to like features throughout the several views, FIG. 1 illustrates a vehicle network 10 having a remote processing station (RPS) 12 that is in wireless cellular and/or satellite-based communication with a plurality of host vehicles 14, and operable for measuring and quantifying air quality and noise levels. Within the scope of the present disclosure, the term “host” is used in the context of the vehicles 14 each serving as a respective local platform to which is attached the described sensors and other hardware systems set forth herein. For simplicity and clarity, air quality levels and ambient noise levels are sometimes referred to herein collectively as “pollution”, in the colloquial context of air pollution and noise pollution. The RPS 12 is embodied as a collection of cloud-based servers or other networked computer devices, and is configured to generate a pollution report 13 (arrow PR) from a global set of pollution data 15 (arrow PD). The global set of pollution data 15 is communicated or offloaded to the RPS 12 by individual host vehicles 140 of the plurality of host vehicles 14. Each respective host vehicle 140 in turn locally collects a pollution data sample, referred to herein as 150 for clarity but individually labeled as 150a, 150b, 150c, 150d, 150e, 150f, and 150g in the simplified example shown in FIG. 1, for a total plurality (n) of such pollution data samples 150. The plurality (n) may be on the order of thousands, hundreds of thousands, or millions of host vehicles 140 depending on the covered geographical area. Each pollution data same 150 forms a constituent part or data set portion of the global set of pollution data 15 provided to the RPS 12 via the cloud 11. Various offboard functions of the RPS 12, equipped with a processor 12P and resident memory 12M, are specified in further detail below with particular reference to FIGS. 3 and 4.

[0028] Each respective pollution data sample 150 from a given host vehicle 140 includes a local ambient air quality level and an ambient noise level, both of which are collected at a current location of the respective host vehicle 140. Each host vehicle 140 is ideally parked, stationary, or otherwise in an ignition-off state at the time of data collection and dissemination. That is, a given host vehicle 140 in the non-limiting exemplary form of a motor vehicle when in motion would tend to detect powertrain, wind, and road noise, as well as tailpipe emissions from other vehicles traveling in close proximity to the host vehicle 140. Such noise will not be generated when the same host vehicle 140 is parked/off, which facilitates detection of ambient noise levels that are representative of true ambient noise.

[0029] An overarching goal of the automated solutions described in detail herein is a reduction in individualized risk of exposure to air pollution, noise pollution, or both. This goal may be achieved by providing users of the individual host vehicles 140, as well as users of other suitably equipped receiving devices such as smart phones, portable or stationary computers, wearables, etc., with detailed time-specific and location-specific pollution and noise level data in the form of the pollution reports 13. The pollution reports 13 as contemplated herein are generated offline by the RPS 12 using crowd-sourced environmental data, with cloud-based computing functions and remote connectivity to the host vehicles 140 represented in FIG. 1 by the cloud 11. The host vehicles 140 thus effectively function herein as distributed sensor platforms for cooperation with the RPS 12 when performing the present methodology, an embodiment of which is described below with reference to FIG. 4.

[0030] The present teachings leverage the wide ranging availability of the vehicle network 10 of FIG. 1, specifically by equipping and operating the individual host vehicles 140 to function as environmental sensor platforms. While the host vehicles 140 are not necessarily limited to the various motor vehicles shown in FIGS. 1 and 2, the nearly ubiquitous use of motor vehicles on roadways of the modern world helps ensure widespread data collection, and thus a higher confidence level in the relevance and accuracy of the collected data. This in turn facilitates dissemination of forward-looking location and time-specific data. Armed with such information, such users may choose to avoid travel to or prolonged presence in regions falling outside of the user's own personal tolerance for exposure to air pollution and/or noise. Additional automated solution options as described below including prompting an operator of the host vehicle 140 with an alternative travel route, a suggested alternative venue or lodging location, or other possible recommendations to enable a given user to avoid or reduce such exposure.

[0031] Referring to FIG. 2, a representative host vehicle 140 is configured for use as part of the vehicle network 10 of FIG. 1. The host vehicle 140 in the illustrated embodiment is a motor vehicle equipped with road wheels 17, a vehicle body 142 connected to the road wheels 17, and a vehicle interior 144, i.e., a passenger compartment or cabin, which is defined by the vehicle body 142. The host vehicle 140 may be variously embodied as a crossover vehicle as shown, or as a sport utility vehicle, sedan, coupe, truck, farm equipment, or other mobile platform within the scope of the disclosure. Once again as noted above, other types of vehicles may be used in the scope of the present disclosure, including boats or other watercraft, aircraft, rail vehicles, motorcycles, electric bicycles, etc., and therefore the representative crossover vehicle of FIG. 2 is illustrative of the present teachings and non-limiting thereof. Likewise, the collection capabilities of the vehicle network 10 may be augmented by data collected from similarly equipped stationary platforms, such as by residential, commercial, academic, or government buildings, bridges, cell towers, etc.

[0032] The host vehicle 140 exemplified in FIG. 2 includes an environmental data system 16, which in turn is in wireless/remote communication with the RPS 12 of FIG. 1. In an exemplary embodiment, the environmental data system 16 includes a vehicle telematics unit (VTU) 18, an electronic control unit (ECU) 22, and a sensor suite 20. The ECU 22 is in wired and/or wireless communication with the VTU 18 and the sensor suite 20, e.g., via a controller area network (CAN) bus, Wi-Fi, or BLUETOOTH® connection as appreciated in the art. The VTU 18 as contemplated herein is an onboard telematic control unit operable for connecting to external devices via the cloud 11 of FIG. 1 using relevant Vehicle-to-Everything (V2X) standards and protocols. In this manner, the VTU 18 is able to communicate wirelessly with the RPS 12, which for its part may act in a capacity as a subscription host service such as ONSTAR®, and possibly with other host vehicles 140 or other external devices, e.g., via cell towers, base stations, mobile switching centers, satellite services, etc. Long-range vehicle communication capabilities with remote, off-board devices such as the RPS 12 may be provided via one or more of a cellular chipset/component, a navigation and location chipset/component, and/or a wireless modem, which are collectively well understood in the art.

[0033] The VTU 18 of FIG. 2 as part of its ordinary programmed functionality is able to collect vehicle telemetry data in real-time, including but not limited to speed, position, temperature, and a wide range of onboard systems diagnostic information using available in-vehicle wireless communication technologies, principally BLUETOOTH®, Wi-Fi, NFC, etc. As part of its relevant hardware configuration, the VTU 18 includes or is connected to a Global Positioning System (GPS) receiver 180 and a cellular antenna 200. Telemetry data may be collected via an onboard satellite navigation unit, e.g., a Global Navigation Satellite System (GNSS) module 19, which in turn is connected to the GPS receiver 180, and thus to an orbiting constellation of GPS satellites (not shown).

[0034] The sensor suite 20 as contemplated herein includes at least one acoustic sensor 20A and at least one air quality sensor 20B. The respective acoustic and air quality sensors 20A and 20B are configured for measuring corresponding data of the pollution data sample 150 shown in FIG. 1. That is, each acoustic sensor 20A is operable for measuring an ambient noise level, e.g., using one or more unidirectional or arrayed/directional microphones arranged within the vehicle interior 144 of FIG. 1, and for outputting a corresponding measured ambient noise level signal (arrow 55), e.g., in decibels. As the host vehicle 140 may be stationary when the acoustic sensor 20A is activated, as set forth herein, the positioning of at least some of the acoustic sensors 20A within the vehicle interior 144 eliminates inadvertent detection of engine noise, traction motor rotation, or other drivetrain or road noise that could otherwise be confused with ambient noise. However, one or more acoustic sensors 20A may be positioned outside of the vehicle interior 144 in some embodiments, and possibly operated alone or in conjunction with in-vehicle microphones. Automated approaches could be used to minimize detection of in-cabin noise, such as from a radio or passenger conversations, including possibly detecting whether passengers or pets are present within the vehicle interior 144, an open/closed state of windows of the host vehicle 140, etc. Data collection could be triggered locally by the ECU 22, e.g., based on a predetermined sampling interval, or the sensor suite 20 could be activated in response to a request by the RPS 12. For instance, the RPS 12 may selectively request activation of the sensor suite 20 for one or more of the host vehicles 140 based on predetermined collection criteria, such as a relative lack of data for a given region or area of interest.

[0035] The air quality sensor(s) 20B measure and quantify ambient air quality/pollution levels, and output a corresponding measured air quality signal (arrow 65) indicative thereof. The air quality sensor 20B may be connected to the vehicle body 142 of FIG. 1 on an exterior thereof, so as to be properly positioned to measure air quality outside of the vehicle interior 144. The air quality sensor 20B may be variously embodied as, e.g., a commercially available particulate matter (PM) sensor, a laser or optical particle counter, or a nephelometer operable for detecting particulate matter based on light scattering. Additionally, the air quality sensor 20B may include one or more gas sensors configured, e.g., via infrared light absorption or other operating principles, to detect the presence and levels of specific gasses, such as but not necessarily limited to ozone, sulfur dioxide, nitrogen oxides (NOx), or other gasses.

[0036] The VTU 18 and the ECU 22 may be embodied as one or more digital computer devices equipped with respective memory (M1) 18M and (M) 24, and one or more corresponding processors (P1) 18P and (P) 26. The ECU 22 is also equipped with a timer or clock 27 operable for time-stamping each collected sample, such that the RPS 12 of FIG. 1 is aware of the time and date of collection of each transmitted pollution data sample 150, along with the location of collection as noted above. Algorithms, software, control logic, protocols, and/or methods disclosed hereinbelow, including the representative method 100 of FIG. 4, may be embodied at least in part as computer-executable software stored in the memory 18M and/or 24, e.g., a tangible non-transitory computer-readable storage medium such as flash memory, solid-state drive (SSD) memory, hard-disk drive (HDD) memory, CD-ROM, digital versatile disk (DVD), or other suitable memory devices. Each host vehicle 140 may be equipped with an embedded voice-processing unit utilizing audio filtering, editing, and analysis modules.

[0037] Operation of the processors 18P and 26 may entail the use of an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc. Thus, instructions embodying the method 100 of FIG. 4 as described below, or alternative embodiments thereof, may be recorded on non-transitory, computer-readable storage medium, with such a medium or media represented for simplicity in FIG. 1 as memory 24. Such instructions, when executed by the processor 26, cause the ECU 22 to perform the environmental sensing and communication functions described herein, with the processor 18P likewise performing functions requested of the VTU 18.

[0038] During operation of the ECU 22, the ECU 22 is configured to selectively transmit the collected pollution data samples 150 to the RPS 12 via cooperation with and operation of the VTU 18. Such an action occurs in response to a predetermined set of conditions. Although other conditions may be envisioned within the scope of the disclosure, the predetermined set of conditions according to an exemplary embodiment include the host vehicle 140 being parked or otherwise stationary in an ignition-off state for a calibrated amount of time, e.g., at least about five seconds. The predetermined set of conditions may also or alternatively include other conditions, such as the host vehicle 140 being unoccupied, and/or the method 100 may be enabled by the owner/operator or other user of the host vehicle 140 in an “opt-in” use scenario.

[0039] The ECU 22 of FIG. 2 is configured to receive the pollution report 13 from the RPS 12 of FIG. 1, and to ultimately execute a control action in response to the pollution report. For instance, the ECU 22 may execute an onboard control action, i.e., a control action aboard the host vehicle 140, by controlling a display screen 25 in response to the pollution report 13 using display control signals (arrow CC.sub.25). Likewise, the ECU 22 may calculate and display alternative travel route options, suggest alternative destinations, etc., based on the content of the pollution report 13 as described below. The pollution report 13 possibly includes digital noise and pollution maps or other descriptive information descriptive of the ambient noise level and an air pollution level at a current location or a destination of the host vehicle 140.

[0040] The RPS 12 for its part ultimately combines the pollution data samples 150 with pollution data samples 150 provided by other participating host vehicles 140, models the ambient noise and air pollution levels at a current location or a destination of the host vehicle 140, and outputs the pollution report 13 in a customized/region-specific manner to the various host vehicles 140 and/or other users or subscribers of the RPS 12 based on the present or expected locations thereof. Other control actions may be performed external to the host vehicle 140, and thus as offboard control actions, e.g., by displaying similar information on portable electronic devices, wearables, etc., and thus the present teachings do not necessarily culminate in onboard control actions.

[0041] As the host vehicle 140 of FIG. 2 as a predetermined condition may be stationary/turned off when the acoustic sensor 20A is activated, the acoustic sensor 20A is strategically positioned within the vehicle interior 144, e.g., as an in-cabin microphone array. This placement helps eliminate detection of engine, traction motor, wind, road, or other drivetrain sounds that could otherwise be confused with the ambient noise of concern herein. Moreover, as modern vehicles tend to be equipped with such in-cabin microphones, implementation of the present teachings may include repurposing existing microphones to function in the disclosed manner. Automated approaches could also be used to minimize detection of in-cabin noise from a radio or passenger conversations. For instance, one possible solution includes detecting occupant presence using seat-based weight sensors, infrared sensors, motion sensors, door lock/seatbelt latch sensors, and the like, and then activating the acoustic sensors 20A when the vehicle interior 144 is verified in some manner as being unoccupied.

[0042] Referring to FIG. 3, the remote processing station (RPS) 12 in the course of its ongoing operation receives the global set of pollution data 15, which as noted above includes the various pollution data samples 150 each transmitted by the individual host vehicles 140 of FIG. 1 over a period of time. The RPS 12 may be configured to generate two intuitive graphical maps as part of the pollution report 13: (1) an air quality map (AQM) 29, and (2) a noise level map (NLM) 28. When the pollution report 13 is ultimately received by a receiving device such as the host vehicle 140 of FIG. 2 or another suitable device equipped with the above-noted display screen 25, the AQM 29 and/or the NLM 28 are displayed via the display screen 25, for example as a color-coded overlay to a displayed road map, or a plain text message announcing the pollution level and/or noise level. As part of this capability, the RPS 12 is programmed to store a history of the pollution reports 13 for a given region of operation on a computer-readable storage medium, as historic data, and to generate a model of noise and pollution for the given region using the historic data. Thus, the pollution report 13 may include the historic data, either in whole or in part, as set forth below.

[0043] In an in-vehicle use scenario, the receiving device includes the VTU 18 and the ECU 22 of the host vehicle 140 shown in FIG. 2, in which case the display screen 25 may be embodied as a touchscreen of a center console, e.g., a navigation or infotainment system. Such an implementation may facilitate route planning options, for instance by informing an operator of the host vehicle 140 of high noise and/or air pollution levels in or around one or more locations along a planned travel route, or a destination thereof. Alternatively, the receiving device may be a smartphone, in which case the display screen 25 may be implemented as a touchscreen of the smartphone used onboard/aboard or apart from/external to the host vehicle 140. Other fixed or portable electronic devices may be envisioned as possible receiving devices within the scope of the disclosure, such as desktop computers, laptop computers, tablet computers, or smartwatches or other wearable devices, and therefore the configuration of the display screen 25 may vary.

[0044] Referring now to FIG. 4, an exemplary embodiment of the present method 100 commences with block B101 (“(140)=OFF?”), with the term “block” as used herein referring to programmed logical steps as performed by one or more hardware components of the vehicle network 10 shown in FIG. 1. Block B101 for a given host vehicle 140 within the vehicle network 10 may entail detecting a set of predetermined conditions, with the conditions possibly being a single predetermined condition or multiple predetermined conditions in different embodiments. As noted above, a suitable predetermined condition for executing the method 100 may be a parked, stationary, or “off” or quiet state of the host vehicle 140, with other conditions possibly including the absence of passengers or pets in the vehicle interior, a user's “opt-in” status being active, etc. The method 100 proceeds to block B102 when such predetermined conditions have been satisfied.

[0045] Block B102 (“Activate Sensors (20)”) includes activating the sensor suite 20 of FIG. 2. While embodiments contemplate use of the acoustic sensor(s) 20A and the air quality sensor(s) 20B, those skilled in the art will appreciate that the method 100 may use either or both types of sensors 20A and/or 20B, either at various times or exclusively for the given host vehicle 140. That is, based on user preference or instructions from the remote processing station (RPS) 12 of FIG. 1, the respective acoustic and/or air quality sensors 20A and/or 20B may be activated at the same time or at separate times, e.g., based on availability of sufficient data or a lack thereof for a given region. The method 100 proceeds to block B104 once the sensor suite 20 has been activated.

[0046] Block B104 (“Upload (150) to RPS (12)”) includes sampling the relevant information, in this case ambient air quality and noise levels, for a calibrated sampling interval, and thereafter uploading the pollution data sample(s) 150 to the cloud 11 of FIG. 1, for ultimate communication to the RPS 12. In order to limit power drain on a battery or other power supply operable for energizing the sensor suite 20, the ECU 22 may be configured to limit activation of the sensor suite 20 to less than, e.g., five minutes per hour. That is, the sampling interval should be kept at a minimum, e.g., 30 seconds to one minute per hour, or three to five minutes per hour in different implementations. Once the pollution data sample 150 has been collected and time-stamped via the clock 27 of FIG. 2, the VTU 18 wirelessly communicates the pollution data sample 150 to the RPS 12 using the cellular antenna 200 of FIG. 2. The method 100 then proceeds to block B106.

[0047] At block B106 (“Calc. Uncertainty Level (UL)”), which is performed by the RPS 12 of FIG. 1, the RPS 12 may calculate, for a given region, a numeric uncertainty level or confidence level, e.g., based on a number of collected samples or a number of host vehicles 140 collecting measurements for a particular region of interest. As an illustrative example, a collection density of, e.g., 500 samples per day covering several consecutive weeks in a few square blocks of territory, might correspond to a high confidence level, while 50 samples collected per day for the same territory over non-consecutive days, perhaps with large data gaps during weekends, might correspond to a low confidence level. Thus, a threshold collection density may be used by the RPS 12 to help classify the global set of pollution data 15 and/or the constituent pollution data samples 150 into low, medium, and high levels of confidence for a given region. The RPS 12 may perform the same uncertainty analysis for both noise and pollution levels.

[0048] As part of the envisioned approach, current and historic data may be selectively blended or combined according to the level of uncertainty. When uncertainty of current data is high, for example, the RPS 12 of FIG. 1 may rely more heavily or even exclusively on historic data for the region of interest. In the alternative, the RPS 12 may elect to blend current data with historic data, e.g., using data weighting or a predetermined formula-based approach, to fill in gaps in the data samples 150, i.e., with more reliance on the historic data when confidence levels are low, and with more reliance on current data when confidence levels are high. Data weighting is thus performed based on confidence level, either in a fixed manner or on a sliding or variable scale, in accordance with this optional implementation of the present teachings. The method 100 proceeds to block B107 when the confidence level of the data samples 150 has been determined for a given region of interest.

[0049] At block B107 (“UL<CAL?”), the RPS 12 next compares the calculated uncertainty level to a calibrated threshold, and proceeds to block B108 when the uncertainty level is less than the threshold. In the alternative, block B107 proceeds to block B110 when the uncertainty level is greater than the threshold.

[0050] Block B108 (“Use Historic Data”) may entail retrieving the historic data, i.e., previously determined noise and pollution levels for a given region of interest, in whole or in part. Such historic data is recorded over time with ongoing operation of the RPS 12. That is, the RPS 12 maintains a running history of noise and pollution levels for multiple regions of interest on a digital map, i.e., a geospatial mapping database. When up-to-date data is not available, or the available data is uncertain due to the low number of reporting sensors, the RPS 12 may pull the historic data from its resident memory and feed the historic data into block B112, to which the method 100 proceeds. While use of historic data is not ideal, being collected at potentially different times of day, week, or year relative to the times of day, week, or year of interest to a user, the historic data is preferable to reporting low confidence data, or not reporting noise or pollution data.

[0051] Block B110 (“Use Current Data”) may entail using current data noise and pollution levels for the given region of interest, predominantly or exclusively in lieu of historic data. The RPS 12 thus relays the current data to block B112, with the method 100 thereafter proceeding to block B112.

[0052] At block B112 (“Generate Maps”), the RPS 12 of FIG. 1 generates the AQM 29 and NLM 28 as represented in FIG. 3. Block B112 may include using processing spatially distinct data samples 150 from the various host vehicles 140 via the RPS 12, and then building or updating a model from the data samples 150, including the reported position, time of day, day of week, etc. Data modeling or model fitting may be used to generate the AQM 29 and NLM 28. The generated maps may be used to update the aforementioned historic data, which in turn may be optionally sold or provided to third parties of interest, e.g., on an application (“app”)-based subscription basis or as an added service. The method 100 then proceeds to block B114.

[0053] Block B114 (“Transmit (13) to User”) entails transmitting the pollution report 13 via the RPS 12 to the receiving device, which in a non-limiting embodiment includes one of the various host vehicles 140 of FIG. 1 as noted above. In a possible implementation, the pollution report 13 includes the AQM 29 or NLM 28, or both, or the pollution report 13 may communicate the relevant information in another way, e.g., as an SMS text message. Once received by the VTU 18 of FIG. 1, or comparable receiving hardware of an alternatively constructed receiving device, the AQM 29 and NLM 28 may be displayed via the display screen 25 of FIG. 3.

[0054] As part of block B114 or another logical block, a user of the host vehicle 140 may enter a route destination into available route planning software, which in turn may be operated on or through cooperation with the ECU 22, possibly in conjunction with the user's smartphone and applications accessible thereon. The ECU 22 may overlay the AQM 29 and NLM 28 onto a route map displayed via the display screen 25. In this manner, the user is able to view intuitive representations of the noise and pollution levels on or along the displayed travel route, e.g., as color coded shading, perhaps using the typical green, orange/yellow, red scale for progressively increasing noise or pollution levels.

[0055] Optionally, the route planning system may suggest alternative travel route options that would bypass the more polluted or noisy locations along the route. A similar approach may also be used outside of the context of route planning. For example, one planning an outdoor event or a hotel reservation could access a software application (“app”) on their smartphone to view the AQM 29 and/or the NLM 28 for a given location. The user could possibly enter desired thresholds for pollution or noise, with the noted app thereafter displaying alternative venues or hotel locations meeting the user's specific noise/pollution requirements.

[0056] As will be appreciated by those skilled in the relevant art, some aspects of the present disclosure may be implemented at the level of the RPS 12 of FIG. 1. For instance, the RPS 12 may include a computer-readable storage medium, e.g., the processor(s) 12P, on which is recorded instructions executable by a processor 12P from resident memory 12M. Execution of such instructions may cause the processor 12P to receive the global set of pollution data 15 from the plurality of host vehicles 14, each respective host vehicle 140 having a corresponding sensor suite 20 operable for collecting the pollution data sample 150 at a current location of the respective host vehicle 140. Instruction execution also causes the processor 12P to calculate the above-described uncertainty level in the global set of pollution data 15 for the current location, as well as to generate, via the processor 12P using the global set of pollution data 15, at least one color-coded map exemplified at 28 and 29 of FIG. 3. Such maps 28 and 29 of the ambient noise level and an ambient air quality level, respectively, are based in part on the uncertainty level. Execution of the instructions ultimately results in the pollution report 13 being transmitted to a receiving device, e.g., the host vehicle(s) 140 or another user device, with the pollution report 13 being inclusive of the at least one color-coded map.

[0057] The processor 12P in this instance may have access to a history of the pollution reports for a given region of operation, with such a history described above as historic data. The instructions are thus executable by the processor 12P to cause the processor 12P to generate a model of the ambient noise level and an ambient air quality level for a region inclusive of the current location and/or destination using the historic data, and to generate the pollution report 13 using the historic data. Among other possible actions, instruction execution may also cause the processor 12P to selectively request activation of the sensor suite 20 for one or more of the host vehicles 140 based on predetermined collection criteria, including but not limited to a gap or lack of sufficient data coverage for a particular region of interest.

[0058] The foregoing teachings therefore enable the host vehicles 140 represented in FIG. 1 to be used as sensor platforms for detecting air pollution and noise levels, and to thereby improve upon the current state of the art with respect to in-vehicle data collection, dissemination, and possible end use. Pollution data samples 150 provided by a large number of such host vehicles 140, spread across a wide range of territory, which in the modern world is essentially global. Time- and location-dependent models of air quality and noise levels may be generated based on current and historic measurements at a given location or destination. The outputs of such maps may be intuitively displayed to a consumer of the pollution reports 13, e.g., as color-coded digital maps, road map overlays, or simple SMS text messages or other suitable alerts. The present teachings likewise contemplate possible data fusion with other air quality-monitoring systems or networks to obtain higher spatial resolution. The disclosure is therefore not necessarily limited solely to the vehicular use context detailed herein.

[0059] The detailed description and the drawings or figures are supportive and descriptive of the present teachings, but the scope of the present teachings is defined solely by the claims. While some of the best modes and other embodiments for carrying out the present teachings have been described in detail, various alternative designs and embodiments exist for practicing the present teachings defined in the appended claims. Moreover, this disclosure expressly includes combinations and sub-combinations of the elements and features presented above and below.