# BSM-Data Reuse Model Based on In-Vehicular Computing
## 5 Study Case: In-Vehicle BSM Data Services Platform
### Data Delivery
#### 5.3.2 Data Delivery Methods  
Diverse data consumer use cases may require different data delivery types. For example, an emergency car service may require a real-time event when an accident takes place. On the other hand, Usage-Based Insurance may pull a car's odometer once a week. Lastly, a data analytics company might opt for historical car data in order to understand traffic trends. Our data platform provides different data delivery methods to cater to these different use case requirements. Table 10 summarizes data delivery methods, where Table 11 summarizes all available historical data APIs.  
* Streaming: a 'push' mechanism that continuously streams Hot data to a Data Consumer. Streaming uses HTTP POST requests and can send both aggregate and simple data elements. A stream is created by subscribing to a stream. Stream subscription defines one or more data filters such as desired vehicle area (i.e., city), maximal point latency, etc. Streaming is optimal for applications that require real-time, rich, vehicles data.
* Historical data reports: multiple format reports, which contain Cold data. Historical data reports are triggered by a RESTful API call with parameters that define a region (e.g. city) and time span for the report. Report generation may take minutes up to hours to complete. Several historical reports exist for different data elements (e.g., speed, break...).  
\begin{table}
\begin{tabular}{l l l l l l l l l l} \hline \hline
**A** & **B** & **C** & **D** & **E** & **F** & **G** & **H** & **I** & **J** & **K** \\ \hline
10106 & 297 & 4/11/2013 & 7:27:49 & 4/11/2013 & 7:36:33 & 5.12 & 4.39 & 524.288 & 35.18 & 17.78 \\ \hline
10106 & 300 & 4/11/2013 & 16:33:57 & 4/11/2013 & 16:42:41 & 5.83 & 4.61 & 524.288 & 40.07 & 20.32 \\ \hline
10116 & 716 & 4/11/2013 & 8:57:23 & 4/11/2013 & 9:08:18 & 12.99 & 12.19 & 655.36 & 71.37 & 34.94 \\ \hline
10116 & 718 & 4/11/2013 & 12:40:12 & 4/11/2013 & 12:42:23 & 6.43 & 6.43 & 131.072 & 76.68 & 32.36 \\ \hline
10116 & 719 & 4/11/2013 & 14:01:02 & 4/11/2013 & 14:03:13 & 0.64 & 0.60 & 131.072 & 17.77 & 19.83 \\ \hline
10116 & 720 & 4/11/2013 & 22:51:52 & 4/11/2013 & 23:02:48 & 10.48 & 9.91 & 655.36 & 57.60 & 22.45 \\ \hline
10118 & 771 & 4/11/2013 & 8:00:35 & 4/11/2013 & 8:15:52 & 7.42 & 6.16 & 917.504 & 29.12 & 20.85 \\ \hline
10118 & 772 & 4/11/2013 & 14:44:43 & 4/11/2013 & 14:49:05 & 3.31 & 2.60 & 262.144 & 45.48 & 20.98 \\ \hline
10118 & 773 & 4/11/2013 & 17:00:10 & 4/11/2013 & 17:06:43 & 3.98 & 3.35 & 393.216 & 36.44 & 20.73 \\ \hline
10120 & 671 & 4/11/2013 & 7:32:11 & 4/11/2013 & 7:51:51 & 26.37 & 24.05 & 1179.648 & 80.48 & 35.38 \\ \hline \hline \end{tabular}  
* A: TemporaryID; B: TripID; C: Start Date; D: Start Time; E: End Date; F: End Time; G: Total Trip Distance (miles); H: Distance Travelled w/Speed \(>=\) 25 mph; I: Trip Duration (seconds); J: Average Speed (m/s); K: Maximum Speed (m/s).  
\end{table}
Table 8: Summary Measures for Data Elements of the trips table.  
* Events: an event is defined by a logical rule on one or more data elements. When a rule is set to true, an event message is launched and sent to the data consumer. The system \"remembers\" that an event has been sent according to a specific rule and will only send it once. Using a Braking pressure data element, an example event maybe a maintenance application which gets an event whenever a vehicle traveling at a certain radius from a maintenance station, crosses a 200-bar braking pressure level (knowing that Higher pressures are not likely. The maximum pressure that the caliper can withstand before breakage is in the range of 250-300 bar. Events are a great way for applications to save processing power and network bandwidth and only get the data they need in real-time.