[GetHistory Issues] Re: some general spec feedback for consideration

Hi, Paul-san, Adam-san, Andy-san, Kevron-san, Tina-san

It has been a long time since I last got in touch with you, and I 
apologize for the delay 
in replying. I have reviewed your discussion (listed in this mail).
My comments on getHistory are as follows:

As you know, the number of automobile having a data storage capability 
has been increasing 
in the world, mainly for maintenance purpose.
What kind of data, and how much data is stored depend on OEM's design or 
requirements.

So, a enable() or disable() method would not be necessary; data 
availability is necessary.

We would like to utilize such stored data as much as possible,
- to provide various apps (e.g. drive record, automatic diagnosis, 
advice of driving 
  techniques, etc),
- to provide delayed upload of probe data to an external cloud in case 
of IVI overload and 
  mobile network congestion/interruption,
without always running data collection and storage programs of the apps.

In other words, getHistory is a kind of get method.

Transfer speed and access control (including single threaded way) of 
getHistory data, 
specially in the case where retrieval data size is large, would be 
implementation issues.
The spec should not actually get into the implementation.  

Therefore, I fully agree to Paul and Kevron's comments and proposal of 
draft spec.

Regards,

Tatsuhiko Hirabayashi/KDDI


#### LIST of COMMENTS ####

#8 [Adam's comment on the subnote of Tina's report]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intel/Tizen has implemented a similar capability and we have a good 
understanding I believe 
on this one but your comment is fair.  Part of this is the interface but 
part of this is 
implementation detail. 

#7 [Paul's comment on Tina's report]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Per our discussion at the face to face and on the list, what is 
available for history is 
dependent on the implementation, but the mechanism to get history should 
be consistent and 
durable.  
No one has claimed that all data should be available for spec compliance 
or for history.   
This spec can comment on implementation details like performance, but by 
no means should 
address all them.  I encourage members of the group to share their 
implementation experience 
to help make the durable operations as clean as possible in the context 
of my comments.


#6 [Kevron's comment on Tina's report]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I plan on starting an implementation in crosswalk very soon in
parallel with the finalization of the specs.  I'll keep the group
updated on how it's going.


#5 [Tina's report]
~~~~~~~~~~~~~~~~~~
  *   For the get history conversation: This should be an available 
feature, but it should not 
be enabled by default. That excessive amount of logging would be too 
heavy on the system. 
We should be able to enable it on a per sensor basis from the javascript 
API (Ex: sensor.start
Logging(), sensor.stopLogging(), sensor.getLogs()). 
This could also be achieved by the subscribe methods, but the amount of 
callbacks here could 
cause performance issues
     *   As a subnote to this, I would like to see an actual system 
implementation of this 
spec to see its performance. Our system implementation has shown that 
excessive callbacks have 
a significant performance impact due to the single threaded nature of 
javascript. 
It would also flush out any unforeseen issues with the spec.


#4 [Paul's comment on Andy's comment]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.


#3 [Kevron's comment on Andy's comment]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.

[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




#2 [Andy's comment on Kevron's draft]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
 

#1 [Kevron's draft spec]
~~~~~~~~~~~~~~~~~~~~~~~~
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).then( function ( data ) {
   console.log(data.length);
 });
}

####

Received on Tuesday, 6 May 2014 13:03:56 UTC