Distributed computing system for determining road surface traction capability

Abstract

A distributed computing system for determining a distribution of road surface traction capability of roads located in a common spatiotemporal region includes a plurality of vehicles each including a plurality of sensors and systems that collect and analyze a plurality of parameters related to road surface conditions in the common spatiotemporal region. The distributed computing system further includes one or more central computers in wireless communication with each of the plurality of vehicles. The one or more central computers execute instructions to determine a road surface traction capability value for the common spatiotemporal region.

Description

Technical Field

[0001] This disclosure relates to a distributed computing system for determining the road surface traction capacity of a road located in a common spatiotemporal zone based on aggregated vehicle sensor data collected from multiple vehicles, combined with weather and application programming interface data. Background Technology

[0002] Traction is the grip between a vehicle's tires and the road surface, allowing the vehicle to stop, start, and change direction. However, road conditions and adverse weather conditions can reduce a vehicle's traction. Specifically, slippery roads caused by ice and snow can be challenging to drive and maintain traction. Various systems exist to assist drivers on slippery or challenging surfaces. For example, Traction Control System (TCS) prevents wheel spin due to acceleration on slippery surfaces. Anti-lock Braking System (ABS) prevents wheels from locking up during braking, thus maintaining traction contact with the road. Electronic Stability Control (ESC) systems monitor various vehicle sensors, such as, but not limited to, wheel speed sensors, steering angle sensors, and lateral acceleration sensors. If the ESC system detects a loss of steering control—a difference between the driver's expected path and the actual vehicle path—it responds by stabilizing the vehicle through wheel-specific braking intervention and engine torque adjustment.

[0003] Various government agencies and municipal authorities can employ a range of technologies to maintain road traction in adverse weather conditions. For example, chemicals such as sodium chloride, magnesium chloride, and calcium chloride can be used to prevent and remove ice and snow from roads.

[0004] While current de-icing technologies have achieved their intended purpose, there is still a need in the field for an improved system to determine when and where de-icing is required on roads based on the road's traction capacity. Summary of the Invention

[0005] According to several aspects, a distributed computing system for determining the road surface traction capacity of a road located in a common spatiotemporal zone is disclosed. The distributed computing system includes multiple vehicles, each including multiple sensors and systems, which collect and analyze multiple parameters related to road surface conditions in the common spatiotemporal zone, wherein the multiple parameters include the traction level of a selected vehicle. The distributed computing system also includes one or more central computers wirelessly communicating with each of the multiple vehicles, wherein the one or more central computers execute instructions to determine at least one of a complete match value and a partial match value between two contextual data points between two discrete vehicles that are part of the multiple vehicles, wherein the two contextual data points are part of the multiple parameters, and combine the complete match value and the partial match value with the traction level corresponding to the selected vehicle to determine a road surface traction capacity value for the common spatiotemporal zone.

[0006] In one respect, a perfect match value indicates that two context data points between two discrete vehicles have the same context data type, while a partial match value indicates that two context data points between two discrete vehicles have partially similar context data types.

[0007] On the other hand, the perfect match value is determined based on the following formula:

[0008]

[0009] Where, r a It is the traction level of the selected vehicle relative to the scenario data point, r u,i ω is the traction level of adjacent vehicles, sim(a,u) represents the situational similarity between the selected vehicle and its adjacent vehicles, and ω(a) is the participation weight of the selected vehicle.

[0010] On the other hand, partial matching values ​​are determined based on the following formula:

[0011]

[0012] Where, r a It is the traction level of the selected vehicle relative to the scenario data point, r u,i is the traction level of adjacent vehicles, sim(a,u) represents the contextual similarity between the selected vehicle and its adjacent vehicles, ω(a) is the participation weight of the selected vehicle, X and Y represent the two datasets used for comparison and matching to determine the Jaccard weights, and w is a function used to transform the two datasets corresponding to X and Y into real values.

[0013] In one respect, the road traction capacity value for a common spatiotemporal zone is determined based on the following formula:

[0014]

[0015] Among them, P u,i This represents the road surface traction capacity value for a common time and space zone.

[0016] On the other hand, contextual data types include one or more of the following: temporal contextual data, spatial contextual data, weather contextual data including wiper status, temperature, pressure and rain, vehicle type, tire wear, lane context, road surface condition, driver behavior, high-excitation contexts collected from multiple sensors and systems, and low-excitation contexts collected from multiple sensors and systems.

[0017] On the other hand, multiple sensors and systems generate responses indicating conditions that indicate the road traction capacity in a common spatiotemporal area.

[0018] On the other hand, the response is a high-incentive situation, a low-incentive situation, or both.

[0019] On the other hand, each of the multiple vehicles includes one or more controllers, wherein the one or more controllers for each of the vehicles apply enhancement gains to high-stimulation and low-stimulation scenarios.

[0020] On the other hand, one or more controllers determine the traction level of a selected vehicle based on intensity-adjusted high-excitation and intensity-adjusted low-excitation scenarios.

[0021] In one aspect, a high-excitation scenario is the traction level of the anti-lock braking system (ABS) or the traction control system (TCS).

[0022] On the other hand, ABS traction levels and TCS traction levels are classified into several different levels, each indicating a different traction level.

[0023] On the other hand, the ABS traction level is determined based on the deceleration of a particular vehicle, the spatiotemporal region representing the mapping of a particular vehicle to a geographical location and time, and the spatiotemporal ABS strength based on the total number of braking events of interest and the total ABS event score.

[0024] On the other hand, the TCS traction level is determined based on vehicle speed, a spatiotemporal region representing the mapping of a particular vehicle to a geographic location and time, and spatiotemporal TCS intensity based on the total number of acceleration events of interest and the total TCS event score.

[0025] In one aspect, one or more controllers extract vehicle context parameters based on high-excitation scenarios, low-excitation scenarios, external environmental information from multiple environmental context sensors, and vehicle-based context information collected by one or more remaining vehicle controllers.

[0026] On the other hand, each of the multiple vehicles has multiple sensors and systems including one or more of the following: TCS, ABS, electronic stability system (ESC), brake pedal position sensor, brake pressure sensor, brake torque sensor, engine speed sensor, wheel speed sensor, inertial measurement unit sensor, accelerator pedal position sensor, vehicle speed signal, command torque signal, and one or more cameras.

[0027] On the other hand, one or more central computers receive weather and application programming interface data related to a common spatiotemporal zone via a network.

[0028] On the other hand, weather and application programming interface data include one or more of the following: precipitation, humidity, number of lanes in a road, road type, road surface, road age, map data, road slope angle, road curvature, at road segment edges or nodes, and road slope class.

[0029] In one respect, a common spatiotemporal region represents a common geographical area and time step experiencing similar weather conditions, wherein the overall size of the common geographical location and time step is adjustable.

[0030] In one aspect, a method for determining the road surface traction capacity of a road located in a common spatiotemporal zone is disclosed. The method includes receiving multiple parameters from multiple vehicles by one or more central computers as part of a back-end office, wherein the multiple parameters are related to road surface conditions in the common spatiotemporal zone, and the multiple parameters include a normalized intensity value indicating the traction level of a selected vehicle among the multiple vehicles. The method also includes determining, by the one or more central computers, at least one of a fully matched value and a partially matched value between two contextual data points between two discrete vehicles as part of the multiple vehicles, wherein the two contextual data points are part of the multiple parameters. The method further includes combining at least one of the fully matched value and the partially matched value with the traction level corresponding to the selected vehicle to determine a road surface traction capacity value for the common spatiotemporal zone.

[0031] Further areas of application will become apparent from the description provided herein. It should be understood that the descriptions and specific examples are for illustrative purposes only and are not intended to limit the scope of this disclosure. Attached Figure Description

[0032] The accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this disclosure in any way.

[0033] Figure 1 This is a schematic diagram of a distributed computing system for determining road traction capacity disclosed according to an exemplary embodiment, wherein the system includes multiple vehicles, each of which wirelessly communicates with a back-end office.

[0034] Figure 2 This is according to an exemplary embodiment. Figure 1 The diagram shown is of one of the vehicles, which includes one or more controllers that communicate electronically with multiple sensors and systems, multiple environmental situation sensors, and one or more remaining vehicle controllers.

[0035] Figure 3 This is according to an exemplary embodiment. Figure 2 The diagram shows one or more controllers of a vehicle communicating wirelessly with one or more central computers in a back-end office.

[0036] Figure 4A This is a process flow diagram illustrating a method for determining the traction force level of an ABS according to an exemplary embodiment; and

[0037] Figure 4B This is a process flow diagram illustrating a method for determining the traction force level of a TCS according to an exemplary embodiment. Detailed Implementation

[0038] The following description is merely exemplary in nature and is not intended to limit this disclosure, application, or use.

[0039] refer to Figure 1 An exemplary distributed computing system 10 for determining the road surface traction capability of a road located in a common spatiotemporal zone is illustrated. The distributed computing system 10 includes multiple vehicles 12 wirelessly communicating with a back-end office 14. The multiple vehicles 12 can include any type of wirelessly capable vehicle connected to the back-end office 14, such as, but not limited to, cars, trucks, SUVs, vans, or motorhomes. As explained below, each of the multiple vehicles 12 includes multiple sensors and systems 18 that collect and analyze data related to road surface conditions within the common spatiotemporal zone, wherein the road surface condition-related data from each of the multiple vehicles 12 is transmitted to the back-end office 14. In one embodiment, the back-end office 14 also receives weather and application programming interface (API) data 22 related to the common spatiotemporal zone via a network 24; however, it should be understood that the weather and API data 22 may also originate from other sources, such as third-party services, or be collected and aggregated as part of vehicle telemetry. The back-end office 14 includes one or more central computers 20 for aggregating and fusing road condition-related data from multiple vehicles 12, combining weather and application programming interface data 22, to determine the road traction capacity of roads located in a common spatiotemporal zone.

[0040] Road traction capacity associated with a common spatial-temporal zone (CST) can be used in a variety of situations. For example, government agencies and municipalities can use road traction capacity to determine when to salt, sand, plow, or de-ice various roads within a CST. A CST represents a common geographic location and time step experiencing similar weather conditions, where the overall size of the common geographic location and time step is adjustable. For example, in one embodiment, the common geographic location includes a specific area of ​​a state (e.g., southeastern Michigan) or a specific metropolitan area (e.g., the New York metropolitan area), and the time step is approximately 15 minutes. In another embodiment, the common geographic location can instead include a smaller geographic area. For example, the common geographic location can include a specific neighborhood within a city, a specific bounding box within a city or neighborhood, a latitude / longitude grid, or, alternatively, a specific segment or section of a road.

[0041] The distributed computing system 10 executes algorithms distributed among multiple vehicles 12 and a central computer 20, which is part of a back-end office 14. Figure 2 This is a diagram representing a single vehicle 12, one of a plurality of vehicles 12. (See diagram for example.) Figure 2 As shown, each vehicle 12 includes one or more controllers 30 that communicate electronically with multiple sensors and systems 18. Although Figure 2 Only a single controller 30 is shown for vehicle 12; however, it should be understood that more than one controller 30 may also be used. As explained below, one or more controllers 30 for each vehicle 12 perform edge-based processing to determine multiple parameters 36 (see [link to documentation]) based on road condition-related data collected from multiple sensors and systems 18. Figure 3 The following explanation is provided for backend office 14 (see...). Figure 1 The central computer 20, as part of the system, receives multiple parameters 36 associated with a particular vehicle 12 from each of the multiple vehicles 12 located in the common space-time zone, and aggregates and merges the multiple parameters 36 together to determine the road traction capability of the common space-time zone.

[0042] In such Figure 2 In the illustrated embodiment, the vehicle 12 includes multiple sensors and systems 18, including a traction control system (TCS) 38, an anti-lock braking system (ABS) 40, an electronic stability system (ESC) 42, a brake torque sensor 44, an engine speed sensor 46, one or more cameras 48, and wheel speed sensors 50. However, it should be understood that... Figure 2This is illustrative in nature, and other sensors and systems may also be used. For example, in addition to or alternatively, the multiple sensors and systems 18 of vehicle 12 may include a brake pedal position sensor, a brake pressure sensor, or a vehicle speed signal. In addition to the multiple sensors and systems 18, vehicle 12 also includes a system providing external environment information 70 (…). Figure 3 Multiple environmental situation sensors 54 that communicate electronically with one or more controllers 30. In such cases... Figure 2 In the example shown, multiple environmental context sensors 54 include a clock 56 for indicating time, a Global Positioning System (GPS) 58 for determining the location of the vehicle 12, a windshield wiper signal 60 for detecting whether the windshield wipers are activated, a temperature sensor 61 for determining the ambient temperature, a pressure sensor 62 for determining the ambient pressure, and a relative humidity sensor 63 for determining the ambient relative humidity. However, it should be understood that these figures are merely exemplary in nature, and other types of environmental context sensors, such as windshield rain sensors, can also be used.

[0043] Multiple sensors and systems 18 of vehicle 12 each generate responses indicating road traction capability in a common spatiotemporal region. Specifically, the responses include both high-excitation scenario 64 and low-excitation scenario 66 (see...). Figure 3 The high-excitation scenario 64 indicates that the vehicle 12 is experiencing an event or high-energy event that generates a high-energy excitation, such as when the vehicle 12 experiences a sudden stop. The low-excitation scenario 66 indicates that the vehicle 12 is experiencing an event or low-energy event that generates a mild or low-energy excitation, such as steady-state driving. It should be understood that some sensors 18 of the vehicle 12 generate responses indicating both the high-excitation scenario 64 and the low-excitation scenario 66.

[0044] For example, activation of TCS 38, ABS 40, and ESC 42 is a response to high-stimulation situation 64. Figure 3 The activation indications of TCS 38, ABS 40, and / or ESC 42 have exceeded the tire grip capability of road-tire interaction. The higher frequency of TCS 38, ABS 40, and ESC 42 occurrences compared to historical trends may indicate potentially low traction conditions along the road along which vehicle 12 is traveling. Braking torque sensor 44 (or brake pedal position sensor or brake pressure sensor) and engine speed sensor 46 can generate indications of high excitation situation 64 or low excitation situation 66 based on the specific conditions being monitored. Figure 3The braking torque sensor 44, in turn, generates a response indicating a low-excitation situation 66 when monitoring braking torque under normal driving conditions. Normal driving conditions may include soft or moderate braking. However, the braking torque sensor 44 generates a response indicating a high-excitation situation 64 in response to detecting hard braking or sudden braking.

[0045] Similarly, when engine speed sensor 46 monitors engine speed under normal driving conditions, engine speed sensor 46 generates an indication of a low-excitation situation 66. Figure 3 The engine speed sensor 46 responds to a sudden or rapid increase in engine speed or, alternatively, a sudden or rapid decrease in engine speed, by generating a response indicating a high-excitation situation 64. It should be understood that a sudden or rapid increase or decrease in engine speed indicates a high-excitation situation 64 along the road in which the vehicle 12 is traveling.

[0046] One or more cameras 48 generate images showing the environment surrounding vehicle 12. The environment surrounding vehicle 12 indicates environmental conditions affecting the traction conditions of the road on which vehicle 12 is traveling. One or more controllers 30 perform machine learning methods to classify road conditions based on the images generated by the cameras 48 and the outputs generated by multiple environmental situation sensors 54. It should be understood that one or more controllers 30 can also classify road conditions with little or no vehicle dynamic input. Therefore, the images generated by one or more cameras 48 indicate low-excitation situations 66 ( Figure 3 Computer vision-based methods can be used to classify road conditions, such as dry, wet, snowy, icy, or gravelly. The results of these classification methods can be mapped to estimates of road traction.

[0047] Other low-excitation scenarios can be employed, along with other vehicle sensors, to estimate the road traction force of vehicle 12, including scenarios based on lateral vehicle dynamics and scenarios based on longitudinal vehicle dynamics. In each of these scenarios, TCS 38, ABS 40, and ESC 42 are not activated due to the presence of low excitation energy input. In each of these scenarios, the estimation of road traction force can be made by multiple sensors and systems 18 of vehicle 12.

[0048] In addition to multiple sensors and systems 18 and multiple environmental context sensors 54, one or more controllers 30 of vehicle 12 also receive input from one or more residual vehicle controllers 68 that are part of vehicle 12. The one or more residual vehicle controllers 68 send vehicle-based contextual information 72 about vehicle 12 (see...). Figure 3Examples of vehicle-based contextual information 72 include, but are not limited to, vehicle type, tire condition (such as tire wear and tire pressure), and driver behavior. Specifically, vehicle type indicates a particular type of vehicle, such as a sedan, truck, or SUV, and driver behavior indicates the style of the driver's operation of vehicle 12. For example, in one embodiment, driver behavior may be categorized into a conservative, moderate, or aggressive category.

[0049] Figure 3 yes Figure 2 The diagram shows one or more controllers 30 of vehicle 12 communicating wirelessly with one or more central computers 20 in a back-end office 14. The one or more controllers 30 include an enhancement module 76, a context engine submodule 78, and a standardization module 80. Figure 3 As shown, one or more controllers 30 receive high-excitation scenarios 64 and low-excitation scenarios 66 from multiple sensors and systems 18, external environment information 70 from multiple environmental situation sensors 54, and vehicle-based situation information 72 from one or more remaining vehicle controllers 68 as inputs. It should also be noted that, in alternative embodiments, modules 76, 78, and 80 may be wholly or partially included in the central computer 20.

[0050] The enhancement module 76 receives high-excitation scenario 64 and low-excitation scenario 66 as inputs and applies enhancement gain to both. The enhancement gain is applied to both high-excitation scenario 64 and low-excitation scenario 66 to quantify the severity of the corresponding potential low-traction condition. The enhancement gain value is a function of one or more operating parameters of vehicle 12. These operating parameters include, but are not limited to, vehicle speed, brake pedal position, brake pressure, road gradient angle, road gradient level, event duration, or proximity to a critical area (such as a school or hospital). The relationship between the high-excitation enhancement gain value and one or more operating parameters can be expressed in various ways, such as a functional relationship or a lookup table.

[0051] The standardization module 80 receives intensity-adjusted high-excitation scenario 104 and intensity-adjusted low-excitation scenario 106 from the reinforcement module 76 as input, and determines a standardized intensity value, which indicates the traction level of a selected one of the multiple vehicles 12. Figure 3In the illustrated embodiment, the normalized intensity value is either a high-excitation traction level 82 or a low-excitation traction level 84. The high-excitation traction level 82 can be based on ABS or TCS activation. For example, a high-excitation ABS traction level 82 or a high-excitation TCS traction level 82 can be based on activation of ABS 40 or TCS 38, respectively. The low-excitation traction level 84 can be based on visual, lateral, or longitudinal dynamic models or machine learning methods. Specifically, Figure 4A A process flow diagram illustrating a method 200 for determining the ABS traction level 82 based on activated ABS 40 is shown, and Figure 4B A process flow diagram illustrating a method 300 for determining the TCS traction force level 82 based on the activation of TCS 38 is shown.

[0052] It should be understood that, in one embodiment, the ABS traction level 82 and the TCS traction level 82 are classified into multiple different levels, each indicating a different traction level. For example, in one embodiment, the ABS traction level 82 and the TCS traction level 82 include three levels: high traction level, medium traction level, and low traction level. Referring now to... Figure 2 , Figure 3 and Figure 4A Method 200 may begin at block 202. In block 202, one or more controllers 30 determine that vehicle 12 is decelerating. For example, in one embodiment, one or more controllers 30 determine that vehicle 12 is decelerating based on the output from an inertial measurement unit (IMU) sensor; however, other methods may also be used. Method 200 may then proceed to decision block 204.

[0053] In decision block 204, one or more controllers 30 determine whether the deceleration detected in block 202 is greater than a threshold deceleration, and if the deceleration is greater than the threshold deceleration, the one or more controllers 30 determine that a potential braking event has occurred. The threshold deceleration is selected to indicate that deceleration at least greater than a minor braking event has occurred. For example, in one embodiment, the threshold deceleration is approximately 0.4 m / s². 2 If the deceleration is equal to or less than the threshold deceleration, then method 200 returns to box 202. Otherwise, method 200 can proceed to box 206.

[0054] In block 206, one or more controllers 30 continue to monitor for potential braking events of vehicle 12. For example, a potential braking event may be characterized by brake pedal position or brake pressure combined with vehicle speed. Method 200 may then proceed to decision block 208.

[0055] In decision block 208, one or more controllers 30 determine whether the potential braking event identified in block 204 is a braking event of interest by comparing the brake pedal position (or brake pressure) and vehicle speed monitored in block 206 with corresponding threshold braking and vehicle speed values. If the brake pedal position (or brake pressure) and vehicle speed are greater than their respective thresholds, method 200 can proceed to block 210; otherwise, method 200 returns to block 202.

[0056] In block 210, one or more controllers 30 monitor clock 56 to obtain time and monitor GPS 58 to obtain the location of vehicle 12, in conjunction with other contextual information. Method 200 can then proceed to block 212.

[0057] In block 212, one or more controllers 30 determine a spatiotemporal zone based on the time from clock 56 and the location of vehicle 12 from GPS 58. The spatiotemporal zone represents a mapping of vehicle 12 to geographic location and time as a function of time variation and spatial area. For example, in one embodiment, time may be divided based on ten-minute increments, and the spatial area may be a 2500 square meter (50 m × 50 m) zone expressed in longitude and latitude values. Method 200 can then proceed to block 214.

[0058] In block 214, one or more controllers 30 may then increment the Interested Braking Events counter by 1. The Interested Braking Events counter tracks the total number of Interested Braking Events occurring on vehicle 12 within the spatiotemporal region. Method 200 may then proceed to decision block 216.

[0059] In box 216, one or more controllers 30 determine the activity of ABS 40. If ABS 40 is not active, method 200 proceeds to box 222, described below. However, if ABS 40 is active, method 200 proceeds to box 218.

[0060] In box 218, in response to determining that ABS 40 is active, one or more controllers 30 apply a boost gain to the active ABS event to obtain a score for counting the active ABS events. The score for an active ABS event is a number greater than or equal to 1. The boost gain is based on a functional relationship or lookup table with variables such as, but not limited to, vehicle speed, brake pedal position, brake pressure, event duration, road slope angle and gradient, and proximity to a critical area (e.g., a school or hospital). Method 200 can then proceed to box 220.

[0061] In block 220, one or more controllers 30 may increment an active ABS event counter to track the total ABS event score based on the sum of the scores of each active ABS event for vehicle 12 within a given time period. Method 200 may then proceed to block 222.

[0062] In block 222, one or more controllers 30 calculate the spatiotemporal ABS strength based on the total number of braking events of interest from the braking event counter described in block 214 and the total ABS event score from the active ABS event counter described in block 220. Specifically, the spatiotemporal ABS strength is a value determined by dividing the total ABS event score by the total number of braking events of interest. For example, if the total ABS event score is relatively large compared to the number of braking events of interest, the road may be very slippery; however, if the total ABS event score is relatively small compared to the number of braking events of interest, the road may be less slippery. If no braking events of interest are recorded, the spatiotemporal ABS strength is unavailable and no insights can be drawn. The enhancement gain applied in block 218 enhances the total ABS event score based on factors such as vehicle speed, because activating ABS 40 may be more noticeable when the vehicle is traveling at a high speed (e.g., 100 km / h (kph)) compared to a low speed (e.g., 20 km / h). Method 200 can then proceed to block 224.

[0063] In block 224, one or more controllers 30 determine the ABS traction level 82. In one embodiment, the ABS traction level 82 is a high traction level when the current-space ABS strength is less than a first predetermined calibration value. The ABS traction level 82 is a medium traction level when the current-space ABS strength is greater than or equal to the first predetermined calibration value but less than a second predetermined calibration value. Finally, the ABS traction level 82 is a low traction level when the current-space ABS strength is greater than or equal to the second predetermined calibration value. The first and second predetermined calibration values ​​are determined based on specific applications and factors, such as regional considerations and vehicle type. Method 200 may then terminate, or alternatively, return to block 202.

[0064] A method 300 for determining the TCS traction level 82 is now described. (Reference) Figure 2 , Figure 3 and Figure 4B Method 300 can begin at block 302. In block 302, one or more controllers 30 monitor the vehicle speed. Method 300 can then proceed to decision block 304.

[0065] In decision block 304, one or more controllers 30 determine whether the vehicle speed is less than a threshold vehicle speed. The threshold vehicle speed is selected to represent a speed window in which the TCS 38 is more likely to be activated when the vehicle 12 accelerates on a slippery road. In one embodiment, the threshold vehicle speed is approximately 25 kph. If the vehicle speed is equal to or greater than the threshold vehicle speed, method 300 returns to block 302. However, if the vehicle speed is less than the threshold vehicle speed, method 300 may proceed to block 306.

[0066] In box 306, one or more controllers 30 monitor data from engine speed sensor 46 (see...). Figure 2 The engine speed, command torque signal, and accelerator pedal position are then used. Method 300 can then proceed to decision box 308.

[0067] In decision block 308, one or more controllers 30 determine whether the combination of engine speed, command torque signal, and accelerator pedal position monitored in block 306 is greater than their respective thresholds. In other words, one or more controllers 30 determine a triggering event indicating that the driver intends to accelerate above a nominal value. If the combination of engine speed, command torque signal, and accelerator pedal position indicates that the driver's intention is not to accelerate above a nominal value, method 300 returns to block 302. However, if the combination of engine speed, command torque signal, and accelerator pedal position indicates that the driver's intention is to accelerate above a nominal value, method 300 may proceed to block 310.

[0068] In block 310, along with other contextual information, one or more controllers 30 monitor clock 56 to obtain the time and monitor GPS 58 to obtain the location of vehicle 12. Method 300 can then proceed to block 312.

[0069] In block 312, one or more controllers 30 determine the spatiotemporal zone based on the time from clock 56 and the location of vehicle 12 from GPS 58. As mentioned above, the spatiotemporal zone represents the mapping of vehicle 12 to geographic location and time as a function of time variation and spatial region. Method 300 can then proceed to block 314.

[0070] In block 314, one or more controllers 30 may then increment the interest acceleration event counter by 1. The interest acceleration event counter tracks the total number of interest acceleration events occurring for vehicle 12 within the spatiotemporal region. Method 300 may then proceed to decision block 316.

[0071] In decision block 316, one or more controllers 30 determine the activity of TCS 38. If TCS 38 is not active, method 300 proceeds to block 322, described below. However, if TCS 38 is active, method 300 proceeds to block 318.

[0072] In box 318, in response to determining that TCS 38 is active, one or more controllers 30 apply a boost gain to the active TCS event to obtain a score for counting active TCS events. The score for an active TCS event is a number greater than or equal to 1. The boost gain is based on a functional relationship or lookup table with variables such as, but not limited to, accelerator pedal position, command torque, duration of TCS activation, road gradient angle and gradient grade, and proximity to critical areas (e.g., schools or hospitals). Method 300 can then proceed to box 320.

[0073] In block 320, one or more controllers 30 may increment a TCS event counter based on the score of an active TCS event, wherein the TCS event counter tracks the total TCS event score based on the sum of the scores of each of the active TCS events of vehicle 12 within a given time period. Method 300 may then proceed to block 322.

[0074] In block 322, one or more controllers 30 calculate the spatiotemporal TCS intensity based on the total number of acceleration events of interest for vehicle 12 during the spatiotemporal region from the acceleration events of interest counter and the total TCS event score from the TCS event counter. Specifically, the spatiotemporal TCS intensity is a value determined by dividing the total TCS event score by the total number of acceleration events of interest. Method 300 can then proceed to block 324.

[0075] In block 324, one or more controllers 30 determine the TCS traction level 82. In one embodiment, the TCS traction level 82 is a high traction level when the spacetime TCS intensity is less than a first predetermined calibration value. The TCS traction level 82 is a medium traction level when the spacetime TCS intensity is greater than or equal to the first predetermined calibration value but less than a second predetermined calibration value. Finally, the TCS traction level 82 is a low traction level when the spacetime TCS intensity is greater than or equal to the second predetermined calibration value. Method 300 can then terminate or return to block 302.

[0076] refer to Figure 3The context engine submodule 78 of one or more controllers 30 of vehicle 12 is configured to extract vehicle context parameters 98 based on inputs including high-excitation scenarios 64 and low-excitation scenarios 66 from multiple sensors and systems 18, external environment information 70 from multiple environmental context sensors 54, and vehicle-based context information 72 from one or more remaining vehicle controllers 68. The vehicle context parameters 98 indicate the state of the vehicle, driver, road, and environment during potentially low traction conditions along the road in which vehicle 12 is traveling. Some examples of vehicle context parameters 98 include, but are not limited to, vehicle type, vehicle mass estimate, trailer attachment status, tire health, driver behavior (conservative, moderate, or aggressive), road slope angle, road grade, road roughness, road class (highway, rural, etc.), and precipitation level. For example, the context engine submodule 78 is based on windshield wiper signal 60 (… Figure 2 This is used to determine precipitation level scenarios, where high precipitation levels indicate potential low traction conditions along the road.

[0077] Multiple parameters 36 determined by one or more controllers 30 include a high-excitation scenario 64, a low-excitation scenario 66, external environment information 70, vehicle-based scenario information 72, ABS and TCS traction levels 82 determined by the standardization module 80, a low-excitation traction level 84, and vehicle scenario parameters 98 from the scenario engine submodule 78. These multiple parameters 36 are sent to one or more central computers 20 in the back-end office 14. As explained below, the one or more central computers 20 combine weather and application programming interface data 22 from multiple vehicles 12 (… Figure 1 Multiple parameters 36 are aggregated and fused together to determine the road traction capacity value 90 for a common spatiotemporal zone. Some examples of weather and application programming interface data 22 include, but are not limited to, precipitation, humidity, number of road lanes, road type (e.g., highways, etc.), road surface (paved and gravel), road age, map data, road inclination angle, road curvature, at road segment edges or nodes, and road slope class.

[0078] One or more central computers 20 include a vehicle data module 92 and a context-aware aggregation module 94. The vehicle data module 92 includes a full context-matching submodule 100 and a partial context-matching submodule 102. As explained below, the full context-matching submodule 100 determines multiple vehicles 12 ( Figure 1A complete scenario match is a value between two or more scenario data points between two or more discrete vehicles 12, which are part of a plurality of parameters 36. A complete scenario match indicates that the two or more scenario data points between two discrete vehicles 12 have the same scenario data type (e.g., the scenario data points are related to vehicle type, weather scenario, or both). Specifically, refer to... Figure 1 and Figure 3 Two discrete vehicles 12 include a selected vehicle a and an adjacent vehicle u, wherein the adjacent vehicle u is part of a plurality of vehicles 12 located in a common spatiotemporal region. Contextual data types include, but are not limited to, temporal contextual data (such as time of day or season), spatial contextual data (such as latitude and longitude coordinates), weather contextual data (including wiper status, ambient temperature, ambient air pressure, whether it is raining, vehicle type, tire wear), lane contextual data (such as the number of lanes on a road), road surface conditions, driver behavior (conservative, moderate, or aggressive), high-incentive context 64, and low-incentive context 66.

[0079] In one embodiment, a perfect match value from one or more adjacent vehicles is determined based on Equation 1, which is:

[0080]

[0081] Where, r a It is the traction level of vehicle a relative to the scenario data point (82 and / or 84), r u,i Here, sim(a,u) represents the traction level (82 and / or 84) of the adjacent vehicle u, sim(a,u) represents the contextual similarity between the selected vehicle a and the adjacent vehicle u, and ω(a) is the participation weight of the selected vehicle a. The participation weight ω(a) is a calibrated value based on a variety of factors (such as, but not limited to, read confidence and vehicle type). Once the full context matching submodule 100 determines a full match between two discrete vehicles 12 (i.e., the selected vehicle a and the adjacent vehicle u), the corresponding two contextual data points are sent to a collaborative filter, such as a k-nearest neighbor (kNN) filter, to determine a set of fully matched vehicles 12, which includes the fully matched selected vehicle a ( Figure 1 The context value is then determined by Equation 1. The perfect match value is then sent to the context-aware aggregation module 94.

[0082] Partial context matching submodule 102 determines a partial match value between two context data points between two discrete vehicles 12, wherein the two context data points are part of a plurality of parameters 36. Partial context matching indicates that the two context data points between the two discrete vehicles 12 have partially similar context data types (e.g., both vehicles have context data points related to vehicle type, but one vehicle's context data points are related to weather context, while the remaining vehicle's context data points are related to road type). In one embodiment, the partial match value is determined based on Equation 2, which is:

[0083]

[0084] Where, r a It is the traction level of vehicle a relative to the scenario data point (82 and / or 84), r u,i Here, is the traction level of vehicle u relative to the context data point (82 and / or 84), sim(a,u) represents the context similarity between selected vehicle a and vehicle u, ω(a) is the participation weight of selected vehicle a, X and Y represent the two datasets used for comparison and matching to determine Jaccard weights, and w is a function used to transform the datasets corresponding to X and Y into real values. Once the partial context matching submodule 102 determines the partial match value between two discrete vehicles 12 (i.e., selected vehicle a and neighboring vehicle u), the corresponding two context data points are sent to a collaborative filter (e.g., a kNN filter) to determine a set of matching vehicles 12 with context values ​​that partially match selected vehicle a (i.e., traction level of vehicle u relative to the context data point 82 and / or 84), sim(a,u) represents the context similarity between selected vehicle a and vehicle u, ω(a) is the participation weight of selected vehicle a, X and Y represent the two datasets used for comparison and matching to determine the Jaccard weights, and w is a function used to transform the datasets corresponding to X and Y into real values. Figure 1 The partially matched values ​​determined by Equation 2 are then sent to the context-aware aggregation module 94.

[0085] Context-aware aggregation module 94 determines the final traction capacity estimate P based on the traction level (82 and / or 84) corresponding to the selected vehicle a, the fully matched value determined by the fully matched submodule 100, and the partially matched value determined by the partially matched submodule 102. u,i Specifically, the environmental perception aggregation module 94 determines the final traction capacity estimate P based on Equation 3. u,i Equation 3 is as follows:

[0086]

[0087] Among them, the final traction capacity estimate P u,i It is equal to the road traction capacity value of 90 in the common time and space zone.

[0088] Referring generally to the accompanying drawings, the disclosed distributed computing system provides a deployable method for determining the road surface traction capacity of roads located in a common spatiotemporal zone. It should be understood that the algorithm is distributed among a backend office acting as a server and multiple vehicles acting as clients. It should be understood that the vehicles perform edge-based processing to determine various parameters, while the backend office aggregates and merges data from multiple vehicles. Various municipalities and government agencies can use the road surface traction capacity determined by the distributed computing system to determine when to salt or de-ice various roads within the common spatiotemporal zone.

[0089] A controller can refer to electronic circuitry, combinational logic circuitry, a field-programmable gate array (FPGA), a processor (shared, dedicated, or grouped) that executes code, or a combination of some or all of the foregoing, or as part of them, such as in a system-on-a-chip. Furthermore, the controller can be microprocessor-based, such as a computer having at least one processor, memory (RAM and / or ROM), and associated input and output buses. The processor can operate under the control of an operating system residing in memory. The operating system can manage computer resources such that computer program code embodied as one or more computer software applications (such as applications residing in memory) can have instructions that are executed by the processor. In alternative embodiments, the processor can directly execute the application, in which case the operating system can be omitted.

[0090] The description in this disclosure is merely exemplary in nature, and variations thereof without departing from the spirit of this disclosure are intended to be within its scope. Such variations should not be considered as departing from the scheme and scope of this disclosure.

Claims

1. A distributed computing system for determining the road surface traction capacity of a road located in a common spatiotemporal region, the distributed computing system comprising: Multiple vehicles, each including multiple sensors and systems, collect and analyze multiple parameters related to road conditions in the shared spatiotemporal region, wherein the multiple parameters include the traction level of selected vehicles, and wherein the multiple sensors and systems generate responses indicating conditions indicating the road traction capability in the shared spatiotemporal region, the responses being high-excitation conditions, low-excitation conditions, or both; and One or more central computers wirelessly communicate with each of the plurality of vehicles, wherein the one or more central computers execute instructions to: Determine at least one of a complete match value and a partial match value between two contextual data points between two discrete vehicles that are part of the plurality of vehicles, wherein the two contextual data points are part of the plurality of parameters; and At least one of the fully matched value and the partially matched value is combined with the traction level corresponding to the selected vehicle to determine the road traction capacity value of the common spatiotemporal zone, wherein the fully matched value indicates that the two context data points between the two discrete vehicles have the same context data type, and the partially matched value indicates that the two context data points between the two discrete vehicles have partially similar context data types.

2. The distributed computing system according to claim 1, wherein, The perfect match value is determined based on the following formula: in, r a It is the traction level of the selected vehicle relative to the scenario data point. r u, i It is the traction level of adjacent vehicles. sim(a, u) This indicates the situational similarity between the selected vehicle and the adjacent vehicles, and ω (a) This refers to the participation weight of the selected vehicle. u This refers to the adjacent vehicles.

3. The distributed computing system according to claim 2, wherein, The partial matching values ​​are determined based on the following formula: Where X and Y represent two datasets used for comparison and matching to determine Jaccard weights, and w is a function used to transform the two datasets corresponding to X and Y into real values. J(X, Y, w) This represents the Jaccard weight.

4. The distributed computing system according to claim 3, wherein, The road surface traction capacity value of the common spatiotemporal zone is determined based on the following formula: in, P u, i The value representing the road surface traction capacity of the common spatiotemporal region.

5. The distributed computing system according to claim 1, wherein, The context data types include one or more of the following: time context data, spatial context data, weather context data including wiper status, temperature, pressure and rain, vehicle type, tire wear, lane context, road surface condition, driver behavior, high-excitation contexts collected from the plurality of sensors and systems, and low-excitation contexts collected from the plurality of sensors and systems.

6. The distributed computing system according to claim 1, wherein, The application enhances the high-stimulation and low-stimulation scenarios.

7. The distributed computing system according to claim 6, wherein, One or more controllers determine the traction level of the selected vehicle based on intensity-adjusted high-excitation and intensity-adjusted low-excitation scenarios.

Images