Method and apparatus for weather modeling and vehicle tuning

Abstract

The present disclosure provides a method and apparatus for weather modeling and vehicle adjustment. A system includes a processor configured to receive weather data including a plurality of measured data points in an area around a vehicle from a remote weather server. The processor is also configured to receive a path from a vehicle subsystem. The processor is further configured to combine the data points and the path to form a prediction model reflecting expected weather conditions along the path at a future time, the model being based on predefined parameters defining expected weather behavior, and sending the model to a requesting vehicle subsystem.

Description

Technical Field

[0001] The present illustrative embodiments generally relate to methods and apparatus for weather modeling and vehicle tuning. Background Art

[0002] Weather and traffic are constant annoyances for travelers, as they can cause delays, route changes, and even dangerous situations. In addition, users traveling to outdoor destinations, for example, may have a great interest in ensuring that the destination will have pleasant weather.

[0003] Weather reporting services and models have improved over the years, but they still typically rely on limited data points collected at fixed locations, and infer weather data based on data points collected at fixed locations. While weather data is available and can be customized for the vehicle, it is often unavailable due to intermittent vehicle cloud connectivity. Vehicles may include some sensors that allow data collection, but including comprehensive sensors in a vehicle may significantly increase the cost of the vehicle, and because the collected data is as useful to others as it is to the driver (in the case where the driver is already at the destination and is therefore affected by the weather), paying a premium for a vehicle that includes advanced sensor capabilities is of little interest to consumers. Summary of the invention

[0004] In a first illustrative embodiment, a system includes a processor configured to receive weather data including a plurality of measured data points in an area surrounding a vehicle from a remote weather server. The processor is also configured to receive a path from a vehicle subsystem. The processor is further configured to combine the data points and the path to form a prediction model reflecting expected weather conditions along the path at a future time, the model being based on predefined parameters defining expected weather behavior, and to send the model to a requesting vehicle subsystem.

[0005] In a second illustrative embodiment, a computer-implemented method includes modeling a plurality of expected values ​​of a weather aspect based on measured data points received from a remote server and predefined modeling parameters, including varying the predefined parameters to produce the plurality of expected values. The method also includes comparing a real-time measured aspect value with the modeled expected aspect value for each of the plurality of expected values, and selecting a modified parameter set corresponding to the expected value that exhibits a minimum difference from the real-time value.

[0006] In a third illustrative embodiment, a system includes a processor configured to model a plurality of weather aspects on a vehicle path received from a vehicle subsystem based on measured data points received from a remote server and predefined modeling parameters. The processor is further configured to adjust onboard weather model parameters as the vehicle travels on the path for maintaining a weather model in which periodic real-time measurements compared to expected values ​​obtained from the weather model are maintained below a threshold deviation. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An illustrative vehicle computing system is shown;

[0008] Figure 2 A schematic process of sharing vehicle sensor data is shown;

[0009] Figure 3 An illustrative vehicle including on-board modeling and sensing capabilities is shown;

[0010] Figure 4 A schematic process of weather model update is shown;

[0011] Figure 5 shows another illustrative relationship between weather modeling and weather usage modules; and

[0012] Figure 6 A schematic process of reducing a weather model to a 2.5 dimensional model is shown. DETAILED DESCRIPTION

[0013] As required, detailed embodiments are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the invention that may be embodied in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously apply the claimed subject matter.

[0014] Figure 1 An exemplary block layout of a vehicle-based computing system 1 (VCS) for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle-based computing system enabled vehicle may include a visual front end interface 4 located in the vehicle. If the interface is provided with, for example, a touch screen display, a user may also be able to interact with the interface. In another exemplary embodiment, the interaction is performed through button presses, a spoken dialogue system with automatic speech recognition, and speech synthesis.

[0015] exist Figure 1 In the illustrated exemplary embodiment 1, a processor 3 controls at least some of the operations of a vehicle-based computing system. The processor allows on-board processing of commands and routines to be provided within the vehicle. In addition, the processor is connected to both a non-permanent memory 5 and a permanent memory 7. In this exemplary embodiment, the non-permanent memory is a random access memory (RAM), and the permanent memory is a hard disk drive (HDD) or flash memory. In general, permanent (non-temporary) memory may include all forms of memory that maintain data when a computer or other device is powered off. These memories include, but are not limited to, HDDs, CDs, DVDs, tapes, solid-state drives, portable USB drives, and any other suitable forms of permanent memory.

[0016] The processor is also provided with a plurality of different inputs that allow the user to interact with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which may be a touch screen display), and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow the user to switch between the various inputs. The inputs of the microphone and the auxiliary connector are converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, many vehicle components and auxiliary components that communicate with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to pass data back and forth with the VCS (or its components).

[0017] Outputs to the system may include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives a signal from the amplifier 11 via a digital-to-analog converter (D / A) 9 from the processor 3. Outputs may also be sent to a remote BLUETOOTH device (such as PND 54) or a USB device 62 (such as a vehicle navigation device 60) along bi-directional data streams shown at 19 and 21, respectively.

[0018] In one illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate 17 with a user's nomadic device 53 (e.g., a cell phone, smart phone, PDA, or any other device with a wireless remote network connection). The nomadic device (hereinafter ND) 53 may then be used to communicate 59 with a network 61 outside the vehicle 31 through, for example, communication 55 with a cellular tower 57. In some embodiments, the tower 57 may be a Wi-Fi access point.

[0019] Exemplary communications between the ND 53 and the BLUETOOTH transceiver 15 are represented by signals 14 .

[0020] The instruction to pair the ND 53 and the BLUETOOTH transceiver (BTT) 15 may be given by a button 52 or similar input. Thus, the CPU is instructed to pair the onboard BLUETOOTH transceiver with the BLUETOOTH transceiver in the nomadic device.

[0021] Data may be communicated between the CPU 3 and the network 61 using, for example, a data plan, data over voice, or DTMF tones associated with the ND 53. Alternatively, it may be desirable to include an onboard modem 63 having an antenna 18 to communicate 16 data between the CPU 3 and the network 61 over the voice band. The ND 53 may then be used to communicate 59 with the network 61 outside the vehicle 31 through, for example, communication 55 with a cellular tower 57. In some embodiments, the modem 63 may establish communication 20 with the tower 57 for communicating with the network 61. As a non-limiting example, the modem (MDM) 63 may be a USB cellular modem, and the communication 20 may be a cellular communication.

[0022] In one illustrative embodiment, the processor is provided with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (such as a Bluetooth transceiver present in a nomadic device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within the vehicle. Another communication means that can be used in this field is free space optical communication (such as IrDA) and non-standardized consumer IR protocols (IR communication, Figure 1 not shown).

[0023] In another embodiment, the ND 53 includes a modem for voice band or broadband data communications. In the data-over-voice embodiment, a technique called frequency division multiplexing can be implemented when the owner of the nomadic device is able to talk over the device while data is being transferred. At other times, when the owner is not using the device, data transfers can use the entire bandwidth (300 Hz to 3.4 kHz in one example). While frequency division multiplexing may be common for analog cellular communications between vehicles and the Internet, and is still used, it has been largely replaced by a mix of code domain multiple access (CDMA), time domain multiple access (TDMA), and space domain multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the nomadic device, the data plan allows broadband transmission, and it is possible that the system can use a wider bandwidth (thereby speeding up data transfers). In yet another embodiment, the ND 53 is replaced by a cellular communication device (not shown) mounted to the vehicle 31. In yet another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communicating via, for example, but not limited to, an 802.11g network (ie, Wi-Fi) or a Wi-Max network.

[0024] In one embodiment, incoming data may be passed through the nomadic device via data-over-voice or data-plan transmission, through the onboard BLUETOOTH transceiver, to the vehicle's internal processor 3. For some temporary data, for example, the data may be stored on a HDD or other storage medium 7 until the data is no longer needed.

[0025] Additional sources that may be interfaced with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) having a connection to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire TM (Apple), i.LINK TM (Sony Corporation) and Lynx TM (Texas Instruments), EIA (Electronic Industries Association) serial protocol, IEEE1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format) and USB-IF (USB Implementers Forum) form the backbone of serial standards between devices. Most protocols can be implemented as electrical communication or optical communication.

[0026] Additionally, the CPU may communicate with a variety of other auxiliary devices 65. These devices may be connected via a wireless 67 connection or a wired 69 connection. The auxiliary devices 65 may include, but are not limited to, personal media players, wireless health devices, portable computers, and the like.

[0027] Additionally, or alternatively, the CPU may connect to a vehicle-based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) 71 transceiver. This may allow the CPU to connect to a remote network within range of the local router 73.

[0028] In addition to having the exemplary process performed by a vehicle computing system located in a vehicle, in certain embodiments, the exemplary process may also be performed by a computing system in communication with the vehicle computing system. Such a system may include, but is not limited to, a wireless device (such as, but not limited to, a mobile phone) or a remote computing system (such as, but not limited to, a server) connected via a wireless device. Such systems may be collectively referred to as a vehicle associated computing system (VACS). In certain embodiments, specific components of the VACS may perform specific portions of the process depending on the specific implementation of the system. As an example and not limitation, if a process has a step of sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform that portion of the process because the wireless device does not "send and receive" information by itself. One of ordinary skill in the art will understand when it is not appropriate to apply a particular computing system to a given solution.

[0029] In each of the illustrative embodiments discussed herein, exemplary non-limiting examples of processes that may be performed by a computing system are shown. With respect to each process, it is possible that the computing system performing the process may be configured as a dedicated processor to perform the process for the limited purpose of performing the process. All processes do not need to be performed in their entirety and are to be understood as examples of the types of processes that may be performed to implement elements of the present invention. Other steps may be added or removed from the illustrative processes as desired.

[0030] With respect to the illustrative embodiments depicted in the accompanying drawings showing illustrative process flows, it should be noted that a general purpose processor may be temporarily enabled as a special purpose processor in order to perform some or all of the exemplary methods depicted in these drawings. When executing code providing instructions to perform some or all of the steps of the method, the processor may be temporarily re-used as a special purpose processor until the method is completed. In another example, to the extent appropriate, firmware acting according to a pre-configured processor may cause the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variant thereof.

[0031] In an illustrative embodiment, a vehicle system may receive weather data representing a predicted weather model having synoptic weather features modeled in both space and time. In traditional weather forecasting, data points are collected at different locations and altitudes and plotted on a three-dimensional map. The synoptic features may be manually plotted on the map by an expert meteorologist. Over a period of hours, the process is repeated and the meteorologist observes the changes in the synoptic features. The rate at which the synoptic feature moves can be used to predict where it will be in the future.

[0032] In modern meteorology, this modeling process can be automated in computers using macroscopic meteorological models that consider not only the movement of features, but also the forces that control the movement. For example, the eye of a hurricane would be a synoptic feature. A simple model would plot the location, intensity, etc. of the feature over a number of time steps, and then extrapolate its future location, intensity, etc. Prior art modeling would consider the effects of synaptic features on each other, i.e., the effect of the jet stream on the eye of a hurricane and vice versa. This weather data is expressed as a high dimensional model (4D) and can be downloaded to the vehicle in advance when needed.

[0033] In an illustrative embodiment, the processor may expose a request-response interface to other vehicle modules, where the request includes a curve or surface of the estimated weather in space-time. Typically, the estimate is expressed as a random variable (a probability distribution function, such as a beta distribution) that expresses the loss of accuracy due to the distance from the fixed measurement location and the time since the last measurement. Because the channel to the cloud is intermittent, more recent measurements may have been made but their effect lost due to the lack of communication with the cloud. In addition, there is a natural time delay between when a measurement is made and when the measurement is processed and made available for the intermittent channel.

[0034] In an exemplary embodiment, the synaptic features can be mathematically expressed as a time-varying surface or volume with attributes (such as intensity) and transmitted to the vehicle in this form through intermittent connections. The AI ​​module on the vehicle can process this model to predict how the model will evolve and how accurate the prediction will be. The weather measurements at specific points, lines, areas, etc. in the future can then be predicted based on the model in the vehicle.

[0035] Weather servers can access weather measurements from various devices that are spatially distributed around the world. This allows them to abstract the measurements into synoptic weather models that can be represented by a four-dimensional mathematical model. These models are often too complex to be used by vehicle system components, so this article describes a method for simplifying synoptic models into weather information that can be used for vehicle feature structures. In many cases, vehicle system components may be concerned with one or two aspects of the weather and may request or utilize input in the form of parameters associated with these aspects (e.g., temperature at location X (or time X) and humidity at location X (or time X)).

[0036] Synoptic models can provide the basis for good predictions over a considerable period of time, which helps eliminate the time lag issues caused by measurement delays and model building, as well as delays caused by the intermittent nature of the connection from the weather server to the vehicle. The described model can be a learning model trained using low-cost weather data from vehicle sensors. For example, the weather model is able to predict 10 types of weather information, one of which is temperature. The temperature can also be measured on the vehicle and compared to the temperature from the model. The difference between the model results and the measured results is used as a penalty function. The detection features in the model change the model parameters and observe the impact of the changes on the penalty function. The optimization algorithm uses these observations to minimize the penalty function.

[0037] At the same time, the currently modeled data can be used to (using the system example above) predict the temperature and humidity at a point in the future. This can allow pre-processing or avoiding areas if necessary, or any other appropriate action taken in response to a specific predicted weather condition or aspect.

[0038] Figure 2 A schematic process for sharing vehicle sensor data is shown. This example demonstrates how one vehicle can share data with another vehicle (by sharing GPS coordinates) in order to effectively provide the receiving vehicle with a "virtual" sensor that is equivalent (or nearly equivalent) to the sharing vehicle's onboard sensors. The reason the sensors are described as "nearly" equivalent is because the shared sensor data is collected at the sharing vehicle rather than the receiving vehicle, so the data is slightly off-axis. Nonetheless, receiving data from a relatively close vehicle is often sufficient to provide the receiving vehicle with the data it needs, thereby avoiding the cost of having to deploy sensors in every vehicle.

[0039] In this illustrative embodiment, a vehicle lacking a sensor (receiving vehicle) is able to detect a signal broadcast from one or more nearby vehicles 201. This signal can be any number of types of shared sensor data, and a sharing vehicle can broadcast the availability of sensor data and / or actual sensor data. In this example, the process detects a broadcast from a nearby vehicle and determines whether the signal received from that vehicle is above a certain threshold 203, which tends to indicate that the sharing vehicle is within a certain distance from the receiving vehicle (higher signal strength generally indicates closer). If the signal strength indicates that the vehicle is not nearby, the process can exit 200.

[0040] In this example, the process tends to consider signals from vehicles that are relatively close (e.g., within 20 feet) because the vehicles will be sharing GPS coordinates, the utility of which tends to diminish (particularly for navigation purposes) if the receiving vehicle is too far from the sharing vehicle. In other examples, such as sharing weather-related data, the process may consider signals from vehicles that are farther away because weather data in reasonable locations (at least a few hundred feet) is unlikely to exhibit significant deviations. Thus, the proximity threshold for sensor data sharing may be tied to a certain type or category of data being shared between vehicles.

[0041] Additionally, in this example, the process determines if the nearby signals include GPS sharing 205. In this example, the sharing vehicle broadcasts a signal indicating sharing capabilities. Other local vehicles can detect this signal and request certain types of shared data indicated in the broadcast. Therefore, if the sharing vehicle is capable of sharing GPS coordinates, then in this example, the process in the receiving vehicle connects to the sharing vehicle 209. Otherwise, the receiving vehicle (which is seeking GPS coordinates in this example) excludes the shared vehicle ID 207 so that it does not have to reconsider the shared vehicle broadcast at a later time if the two vehicles continue to travel in close proximity (assuming that the sharing vehicle continues to broadcast some shared data availability). For some signals with limited transmission range, the exclusion process 207 may assume the same coordinates as the receiving vehicle for the transmitted weather signal ( Figure 3 305), or if the receiving vehicle does not have a position sensor (e.g., GPS, dead reckoning system, etc.), the coordinates of the transmitting object may be used directly. Thus, the range of the signal may be used in the decision to determine whether to exclude 207, and thus bypass the comparison 213 and enter the proximity determination 215.

[0042] Once the receiving vehicle is connected to the shared vehicle, the process on the receiving vehicle receives GPS coordinates from the shared vehicle 211. In other examples where sensor data is included in the broadcast, the receiving vehicle can simply extract the relevant data. In this example, the process then compares the received coordinates to estimated coordinates, called "dead reckoning" coordinates, which can be guessed based on previously identified vehicle locations and driving characteristics since then (e.g., speed and heading).

[0043] Since the shared vehicle has accurate coordinates and is very close to the receiving vehicle, the process may treat the received coordinates as the "corrected" coordinates of the vehicle, plus or minus some error correction. The process determines whether the received coordinates are close (numerically) to the extrapolated coordinates 215. If not, that is, if the "true" position reveals that the extrapolated position is a bad estimate, the process may notify the server that the extrapolated model is out of date 217, and an updated model may be requested from the server 219. The model may not be updated immediately, but the server may use the observed errors to improve the model, and once the server has received sufficient data to improve the model, the improved model may be released to the requesting vehicle. The vehicle uses the received coordinates to perform navigation or other coordinate-related actions 221.

[0044] Although the foregoing is described with respect to sharing GPS data, any kind of sensor data may be shared in a similar manner. Similarly, a model predicting data corresponding to the shared data may be updated in a similar manner based on a version of the received forecast data. With respect to, for example, weather forecasts discussed herein, sharing may include sharing specific sensor data (e.g., temperature, humidity, pressure, etc.) representing elements of a weather model, and feedback to the server may help correct the weather model to more accurately reflect the data. If a portion of the vehicle has sharable sensors, a greater number of vehicles may also report data regularly through sharing. In addition, a variety of sharable sensors may be provided for different vehicles, so that any vehicle sample may include vehicles with different types of sensors, wherein these vehicles (not specifically or necessarily, the sensors themselves) are able to share information collected directly from these sensors.

[0045] Figure 3An illustrative vehicle including on-board modeling and sensing capabilities is shown. In this example, vehicle 300 is able to periodically connect to weather server 301. The weather forecast server can respond to an on-board weather model with synoptic weather information, but the channel / connection may not always be available. The request from the vehicle may include one or more time and location parameters for the current location and / or points along the route and estimated arrival times for those points. The response from the forecast server may include synaptic data within the requested area and during the requested time. This will include forecast data for any future time requested.

[0046] The vehicle includes an onboard weather model 303 that can provide local responses (to the vehicle and potentially to other receiving vehicles) to specific requests for forecast information. The weather model can map the weather to the system, but so that the system can extract and provide location-specific parameters and parameter values ​​in response to a specific electronic control unit (ECU) request (or other onboard request). So, for example, if an adaptive heating, ventilation, and air conditioning (HVAC) module is trying to keep the cabin temperature consistent, this module may want to know the estimated temperature model for the next fifteen minutes or several miles of the route. Because weather data is modeled in time and space, the model can satisfy either request.

[0047] The HVAC ECU may request data for a path over land, and the path is parameterized by the model with an estimated arrival time at any given area. The response from the model may include a spline equation (e.g., a cubic equation) representing, for example, an estimate of the time it will take for the vehicle to advance through locations to reach a final destination. Or the response may include discrete values ​​extracted based on the spline in case the ECU is unable to receive a spline as a response. The ECU (an example of an information consumer 309) may use the data to adaptively adjust to changing weather patterns and, in such cases, keep the cabin temperature as consistent as possible (or, for example, pre-treat the cabin or windows to avoid condensation / frost formation).

[0048] The path along which the data is provided need not be the path traveled by the vehicle 300. For example, a wireless communication device may modify its channel model based on weather conditions on the path between the vehicle and the device it is communicating with. Since the vehicle 300 is moving (and potentially, the remote vehicle is moving), the communication module may request weather information for a surface parameterized in space and time. Similarly, the navigation module may want to estimate the weather along several paths, where the travel time is affected by the weather itself. In this case, the weather parameters may be conveniently represented as a surface to simplify the nonlinear computational cost on each route.

[0049] The vehicle also includes a virtual weather sensor 307. This "sensor" receives data from the weather model and presents the data to the occupant 309 and / or another vehicle system 309. This sensor can also provide navigation (path) data to the weather model (so the model knows what data to infer). This model receives current position and time data from a position and time sensor 305 that also provides position and time data to the weather model. A map server / database 311 can provide two-dimensional or three-dimensional map data for modeling weather, which can include a three-dimensional spatial model of weather modeled in four dimensions (changing over time on a 3D path). Actual on-board sensors 313 can detect various aspects of the weather that can be detected at that particular vehicle (and / or various aspects of the weather received from other vehicles, although the reception can also occur through weather virtual sensors). Conceptually, short-range communication modules that can collect information from nearby vehicles and infrastructure devices can also be considered sensors.

[0050] As previously mentioned, vehicle occupants and onboard systems may be some consumers of weather data or onboard ECUs 309. As illustrative examples, ECUs may include navigation systems (weather-based routing), vehicle emergency systems, vehicle notification systems, HVAC, powertrain controls, concierge services, automatic suspension controls, etc. Other consumers may include, but are not limited to, first responders (real-world weather at the incident) and other neighboring vehicles.

[0051] In an illustrative example, a weather server may provide synoptic weather information that is converted by a weather model into weather information along the path. Based on continuous modeling following the parameters and spline data provided by the weather server, the weather model may provide this information (with some loss of accuracy) while disconnected from the weather server.

[0052] The front face (an example of a synoptic feature) is a surface that can be modeled onto a land surface, and the front face also moves over time. Mathematical surfaces (such as four-dimensional splines) can describe the surface in three spatial dimensions and time. An error function that varies in three dimensions can describe the increasing error over time. Other synoptic objects can be described in a similar manner in the weather forecast server and transmitted to the weather model in the vehicle by sending spline parameters.

[0053] The path through space sent from the virtual weather sensor to the weather model in the request can be defined by a cubic spline parameterized by time t. Both ends of the communication channel agree on the equations for longitude, latitude, and altitude. The transmission path is then a matter of sending all the coefficients A, B, C, and D. In addition, there may be some constraints on the coefficients to ensure that the two ends converge, and the slope is continuous, the path length is correct, etc.

[0054] One use of the method is to estimate the weather conditions that a vehicle may encounter along a route. The route is parameterized in time, but in the virtual weather sensor it is assumed that the vehicle will arrive at a specific location at a specific time (i.e., the estimated speed of the vehicle is an input into the route. If the vehicle is traveling at a different speed, or if the driver changes the driving route, the virtual sensor can request a new route that reflects the speed change calculated by the weather model).

[0055] Representative and schematic spline calculations can be as follows:

[0056] Spline n (t) = {longitude n (t), latitude n (t), height n (t)}

[0057] warp n (t) = A m，n t 3 +B m，n t 2 +C m，n t+D m，n

[0058] latitude n (t) = A l，n t 3 +B l，n t 2 +C l，n t+D l，n

[0059] high n (t) = A a，n t 3 +B a，n t 2 +C a，n t+D a，n

[0060] The foregoing may represent a path through space sent from a virtual sensor to a weather model. The weather model may respond with a spline representing a weather parameter that varies over time (perhaps along the path received from the virtual sensor). For example:

[0061] Atmospheric pressure n (t) = A b，n t 3 +B b，n t 2 +C b，n t+D b，n

[0062] Figure 4Schematic process of weather model update of meteorological model 303 is shown. Since real-time data may reflect actual values ​​different from estimated values, real-time values ​​may be used to improve the estimation model so that future estimates are hopefully more accurate.

[0063] In this example, the process in the weather model requests an updated version of data 401 from the off-board weather model 301, and checks to see if the version is new and available 403. If the off-board server data is not available, the process may continue to use the previously acquired on-board model. In that case, the "acquired data" may simply be estimated data for the current point in space and time where real data is collected.

[0064] If the process is able to obtain new data from the remote weather model 405, the process can provide the updated remote server model to the onboard weather model 407. Since weather patterns can change rapidly, regularly obtaining updated data from the remote server helps keep the onboard prediction model on track 405. While weather patterns can remain somewhat predictive for a period of time, this predictability can also disappear unexpectedly. As can be seen from this process, if the onboard model appears to deviate significantly from the actual data 423, the process can simply attempt to obtain an updated data set from the remote server.

[0065] Regardless of whether the process can use new data from the server, the on-board process can adaptively adjust the parameters associated with the modeling to produce a minimized penalty function. The penalty function is based on the difference between the actual (measured) data and the predicted data, and the system can continuously adapt the on-board parameters to minimize the function. When attempting to "update", the process can model multiple sets of different parameters, which can produce multiple predicted data sets for one or more currently measurable data points (for example, set A prediction-temperature 35 degrees, humidity 67%, pressure 29Hg, set B prediction-temperature 33 degrees, humidity 69%, pressure 30Hg, etc.). For any data element that can be measured on the vehicle (or can be obtained from measurements of neighboring vehicles), the process can collect real data points 409 and compare them with various predicted data points to minimize the penalty function. The resulting minimum penalty function can define which parameter modifications are currently used, that is, which parameter modifications appear to provide the most realistic results 411 most accurately.

[0066] If the penalty function is low enough 413, the process can use the defined parameters and proceed with data element modeling 417. If the penalty function is not low enough, the process can set the selected parameters as a baseline and try a new set of parameter modifications 415, which will hopefully refine the penalty function to an acceptable point.

[0067] While the process is modeling weather element values ​​using a given set of parameter modifications, the process may also continue to collect actual data 419. Data may be collected at discrete points or at any available time, and "at any available time" may be a better approach if the vehicle has few or no onboard sensors but relies on passing vehicles to obtain data points. The collected data is compared to the estimated value at the time and location of the collection 421 (the collected data may be time and location stamped so the process can continue without the vehicle actually having to stop, except for elements like "wind speed and heading" that may be affected by vehicle motion being collected). If the comparison results in an excessive penalty 423, the process may request another update.

[0068] The excessive penalty may be the result of weather patterns changing rapidly in unexpected ways, and thus new data may provide a better model. Even if new data is not available, at 407, the request may result in parameter modification updates from modeling, so that a better set of modified parameters may be obtained to make the forecast closer to accurate based on the changing weather patterns. The excessive penalty may be a larger penalty function associated with a small number of measurements, may be a penalty function that increases with successive measurements, may be an aggregate penalty value that exceeds a threshold indicating that the current model may be deviating from accuracy, or any other suitable benchmark.

[0069] Figure 5 Another schematic relationship between weather modeling and weather usage modules is shown. In this example, a remote cloud-based process 501 creates weather models and sends them to an onboard storage device 505. Unfortunately, there is a delay in when these models are available from when they were created, and further, the connection 503 is often intermittent. The weather is constantly changing, but the models on the vehicle may still be based on old and less relevant data.

[0070] The onboard storage is connected to the local synoptic model 509, and the model is connected to the storage via a high quality service channel 507. The local model receives data from the onboard vehicle sensors 511 and uses this data along with the cloud provided synoptic model 501 to update and maintain the local synoptic model 509. When a request comes from the vehicle module 515, the process is used to reduce the dimensionality of the 4D local model 513. This output (typically a 2.5 dimensional output) is sent to the request module 517.

[0071] Figure 6An illustrative process is shown for reducing a weather model to a 2.5 dimensional model 503. The onboard modeling process may continuously update the 4D model and flatten the model along the channel of interest as requests are received from the vehicle module. This is a waiting period 601. When the process receives a request 603 from another vehicle module, this request is typically for specific synoptic data for a specific volume defined in space and time.

[0072] The process receives the synoptic model in its most recently updated form from local storage 605 and initializes the temporal and spatial free parameters associated with the model 607. These parameters define where the flattening will occur, and the expected arrival time, so that the predicted weather is related to when the vehicle should actually arrive at a location. These parameters allow the process to calculate the spatiotemporal location with the synoptic model coordinates corresponding to the free parameters 609. The process can also determine the possible impact of synoptic features on the location in space and time 611.

[0073] The process continues by computing the probability distribution of the requested meteorological value (e.g., temperature, pressure, etc.) at the spatiotemporal location 613. The process then increments the spatial and temporal free parameters to define the new location at the new time. If the entire free parameter space defined by the request has been sampled 617, the process may return parameters (such as a spline curve) that define the estimated meteorological value within the spatial and temporal range defined by the request 619.

[0074] In this example, the consumption (request) module may include a mathematical model with explicit dimensions and a free parameter range. When the response is a spline curve, it is on the free parameter space of the free parameters of the calculation distribution function. For example, the response can be two spline curves in the spatiotemporal free parameter space, one curve for the α parameter of the beta distribution and one curve for the β parameter of the beta distribution. Therefore, for any point in the spatiotemporal free parameter range, there is a result (α, β) that can be used to calculate the beta distribution of that point.

[0075] Using the illustrative embodiments, a vehicle may periodically receive updated weather patterns from a remote server and use this data to model predicted weather parameters along a given route. The model is able to adapt to changing conditions and responsively change and / or request updated data when weather deviates from the estimated values. Using sensor sharing, a vehicle generally does not need a full set of onboard sensors to collect enough real data to continue to adapt the model.

[0076] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the present invention. On the contrary, the words used in this specification are descriptive rather than restrictive, and it should be understood that various changes can be made without departing from the spirit and scope of the present invention. In addition, the features of various implementation embodiments can be combined in a logical manner to produce contextually appropriate variations of the embodiments described herein.

[0077] According to the present invention, a system is provided, which has a processor configured to: receive weather data including a plurality of measured data points in an area surrounding a vehicle from a remote weather server; receive a path from a vehicle subsystem; combine the data points and the path to form a prediction model reflecting expected weather conditions along the path at a future time, the model being based on predefined parameters defining expected weather behavior; and send the model to a requesting vehicle subsystem.

[0078] According to one embodiment, the processor is configured to form the prediction model in the form of a cubic spline, which represents latitude, longitude, altitude and time.

[0079] According to one embodiment, the cubic spline represents aspects of weather.

[0080] According to one embodiment, the aspect of weather comprises temperature.

[0081] According to one embodiment, the aspect of the weather comprises atmospheric pressure.

[0082] According to one embodiment, said aspect of weather comprises visibility.

[0083] According to one embodiment, said aspect of weather comprises humidity.

[0084] According to one embodiment, said weather aspects include an estimated road friction coefficient.

[0085] According to one embodiment, the aspect of weather includes precipitation.

[0086] According to one embodiment, the aspects of weather include wind speed and heading.

[0087] According to one embodiment, the processor is further configured to: obtain real-time values ​​of one or more aspects of the expected weather conditions; compare the real-time values ​​with expected values ​​derived from the model; specify a penalty function based on the deviation between the real-time values ​​and the expected values; and adjust the predefined parameters to adjust the expected values ​​until the penalty function resulting from the comparison is below a predetermined threshold.

[0088] According to one embodiment, the processor is configured to obtain the real-time value from an on-board vehicle sensor.

[0089] According to one embodiment, the processor is configured to obtain the real-time value wirelessly from neighboring vehicles.

[0090] According to one embodiment, the processor is configured to determine whether the neighboring vehicle is within a predefined proximity determined by received signal strength prior to wirelessly obtaining the real-time value.

[0091] According to one embodiment, the predefined proximity varies based on the aspect of the weather to which the real-time value applies.

[0092] According to the present invention, a computer-implemented method is provided, comprising: modeling multiple expected values ​​of weather aspects based on measurement data points received from a remote server and predefined modeling parameters, including changing the predefined parameters to produce multiple expected values; comparing real-time measured aspect values ​​with the modeled expected aspect values ​​of each of the multiple expected values; and selecting a modified parameter set corresponding to the expected values, the expected values ​​showing the minimum difference from the real-time values.

[0093] According to one embodiment, the method is further characterized by modeling weather along the vehicle path using the selected set of parameters; and providing the modeled weather along the vehicle path to a requesting vehicle subsystem.

[0094] According to one embodiment, the method is further characterized by collecting real-time aspect values ​​as the vehicle travels on the vehicle path; comparing the collected real-time aspect values ​​with expected values ​​from the modeled weather along the vehicle path; and repeating the steps of modeling, comparing the real-time measured aspect values ​​with the modeled expected aspect values ​​for each of the multiple expected values, and selecting in response to a deviation above a threshold between the collected real-time aspect values ​​and the expected values ​​generated from the modeled weather along the vehicle path.

[0095] According to one embodiment, the real-time values ​​are collected wirelessly from neighboring vehicles, and the method further includes determining whether the neighboring vehicles are within a predefined proximity determined by received signal strength or particular coordinates of a transmission prior to wirelessly obtaining the real-time values, wherein the predefined proximity varies based on an aspect of the weather to which the real-time values ​​apply.

[0096] According to the present invention, a system is provided, which has a processor configured to: model multiple weather aspects on a vehicle path received from a vehicle subsystem based on measurement data points and predefined modeling parameters received from a remote server; and adjust on-board weather model parameters as the vehicle travels on the path to maintain a weather model in which periodic real-time measurement values ​​compared to expected values ​​obtained from the weather model are kept below a threshold deviation.

Claims

1. A system for weather modeling, comprising: A processor, the processor being configured to: receiving weather data including a plurality of measured data points in an area surrounding the vehicle from a remote weather server; receiving a path from a vehicle subsystem; combining the data points and the path to form a prediction model reflecting expected weather conditions along the path at future times, the prediction model being based on predefined parameters defining expected weather behavior; obtaining real-time values ​​of one or more aspects of the expected weather conditions; comparing the real-time value to an expected value derived from the predictive model; specifying a penalty function based on a deviation between the real-time value and the expected value; adjusting the predefined parameter to adjust the expected value until the penalty function resulting from the comparison is below a predefined threshold; as well as The prediction model based on the adjusted predefined parameters is sent to a requesting vehicle subsystem.

2. The system of claim 1, wherein the processor is configured to form the prediction model in the form of a cubic spline, the cubic spline representing latitude, longitude, altitude and time.

3. The system of claim 2, wherein the cubic splines represent aspects of weather.

4. The system of claim 3, wherein the aspect of weather includes temperature.

5. The system of claim 3, wherein the aspect of weather includes atmospheric pressure.

6. The system of claim 3, wherein the aspect of weather includes humidity.

7. The system of claim 3, wherein the aspect of weather includes precipitation.

8. The system of claim 1, wherein the processor is configured to obtain the real-time value from an onboard vehicle sensor.

9. The system of claim 1, wherein the processor is configured to obtain the real-time value wirelessly from a neighboring vehicle.

10. The system of claim 9, wherein the processor is configured to determine whether the neighboring vehicle is within a predefined proximity determined by received signal strength prior to wirelessly obtaining the real-time value.

11. The system of claim 9, wherein the predefined proximity varies based on an aspect of the weather to which the real-time value applies.

12. A method for weather modeling, comprising: modeling a plurality of expected values ​​for the weather aspect based on measured data points received from a remote server and predefined modeling parameters, including varying the predefined modeling parameters to produce the plurality of expected values; comparing the real-time measured aspect value to a modeled expected aspect value for each of the plurality of expected values; selecting a modified parameter set corresponding to the expected value, the expected value exhibiting a minimum difference from the real-time value; collecting real-time aspect values ​​as the vehicle travels on the vehicle path; comparing the collected real-time aspect values ​​to expected values ​​from modeled weather along the vehicle's path; Repeat the following steps: modeling, comparing the real-time measured aspect value to the modeled expected aspect value for each of the plurality of expected values, and selecting in response to a deviation above a threshold between the collected real-time aspect value and the expected value generated from the modeled weather along the vehicle path until there is no deviation above the threshold between any of the collected real-time aspect values ​​and the expected value; modeling weather along the vehicle path using the selected set of parameters; as well as The modeled weather along the vehicle path is provided to a requesting vehicle subsystem.

Images