Re: GetHistory API RFC

I think Andy makes a good point, but I agree with Kevron for this iteration of the spec.  Typical logging scenarios, include:  event occurs (ignition on/off, malfunction indication, etc…), detail in rolling (data) window (only kept for a period of time then rolled off), and aggregate calculations (avg, min, max, etc…).  The primary type of logging the proposed API addresses is detail.  I think for sake of simplicity of this iteration of the spec, we stick with this scenario for now and move to more complex scenarios with the next iteration of the spec.

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes




On Apr 9, 2014, at 1:55 PM, Rees, Kevron <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>> wrote:

Thanks for the feedback, Andy.  My comments inline:


On Wed, Apr 9, 2014 at 1:06 PM, andy@cx3marketing.com<mailto:andy@cx3marketing.com> <andy@cx3marketing.com<mailto:andy@cx3marketing.com>> wrote:
While I’m on a roll :-) ...

I don’t disagree with the value of having history—it can be very useful, especially if there’s a consistent way to provide access to it.

My concern with GetHistory was always that it assumes the system is logging *everything*. That’s an unreasonable load, IMHO, especially since some CAN parameters will require an active request, potentially leading to an implementation flooding the CAN bus to acquire data that may never be used.


If the data is only being read from the bus and then logged by the system there should be no flooding.  In the case where data is logged in an EDR (Event Data Recorder)[1] and then broadcast over the bus on request, there could be a problem with flooding, but system integrators can mitigate that issue with caching and throttling (ie only allowing a certain number of requests within a certain time frame).  This API, IMHO, is more complete and hopefully addresses the concern over the ambiguity of logged data.

What about if the application informs the system layer which bits of history it cares about? The assumption can be that no data will be logged unless you call something like <myclass>.enableHistory() first. And of course you can later .disableHistory(). This addresses the concern of overloading the embedded system and CAN bus with collecting unneeded data.


There is the potential that a system that logs too much can become overloaded.  I think we should include and document the assumption that certain data will already be logged regardless of whether or not an application wants it.  This may because an OEM wants the data, the dealer wants it, or even because of legal reasons[2].  In the latter case, there has even been proposed legislation that requires this data to be accessible by 3rd parties.  This API would fulfill that requirement[3].  Therefore, a enable() or disable() method would not be necessary since the data will be logged regardless.

-Kevron

[1] - https://en.wikipedia.org/wiki/Event_data_recorder
[2] - http://www.wired.com/2012/05/congress-black-box/
[3] - http://www.roadandtrack.com/go/news/new-technology/event-data-recorders


—Andy

<91B9EC47-7BEE-4BBC-A80E-9E9A253C42C8.png>
___________________________________________
Andy Gryc | Co-founder
M: +1 613.618.8730<tel:%2B1%20613.618.8730> | E: andy@cx3marketing.com<mailto:nyoung@cx3marketing.com>
W: www.cx3marketing.com<http://www.cx3marketing.com/>

On Apr 9, 2014, at 3:52 PM, Rees, Kevron <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>> wrote:

The purpose of GetHistory is to allow application to get stored
information from the system without having to perform logging
themselves.  Having the system provide data logging avoids the problem
of having multiple applications logging the same data.

Being able to retrieve logged data allows for some interesting
features.  There are a number of projects that log and do neat things
with vehicle data[1].

This API will come with the assumption that the system will determine
what data is stored, how often and how far back in time data will be
available.

This API may have one flaw however in that it may be processor
intensive to do huge queries and pass that data to web applications.
If we want to avoid that, we may want change the API with that in
mind.

It is also possible we can offer this API as an appendix to our
vehicle data specification.

[1] - http://icculus.org/obdgpslogger/

interface HistoryItem {
 readonly attribute any value;
 readonly attribute DOMTimeStamp timeStamp;
}

callback GetHistoryCallback = void callback(HistoryItem[] items);

partial interface VehicleInterface {
 Promise getHistory(Date begin, Date end, optional Zone zone);
 readonly attribute boolean isLogged;
 readonly attribute Date from;
 readonly attribute Date to;
 readonly attribute short rate; // µHz
}

//check if there is data being logged for vehicleSpeed:
if(vehicle.vehicleSpeed.isLogged)
{
  /// get all vehicleSpeed from the beginning of time
  vehicle.vehicleSpeed.getHistory(new Date(0), new Date).then(
function ( data ) {
   console.log(data.length);
 });

 /// get all vehicleSpeed since it was first logged:

 vehicle.vehicleSpeed.getHistory(vehicle.vehicleSpeed.from,
vehicle.vehicleSpeed.to<http://vehicle.vehiclespeed.to/>).then( function ( data ) {
   console.log(data.length);
 });
}

-Kevron