Vehicle data exchange protocols

This page collects input requirements for the data-exchange protocols in the context of defining the vehicle-data reference architecture as part of the CCS project.

Purpose(s) of this page

• Define the features needed from any  protocol, however it is realized in the end.  The features may be implemented in protocol but might also be part of the defined semantics of the VSS taxonomy itself.  (Semantics that are built into VSS automatically transfer to any and all access protocols including W3C-Gen2.
• Evaluate W3C "Gen2" protocol to understand its reasonable scope limits and/or add new feature requests to it.
• Understand where other protocols may complement.
• Define the list of protocols that meet the overall needs (and where each of them is to be used).  This is a key piece of defining the reference architecture.

Features (ideas under development, and brainstorm)

• Queries that pre-filter on-demand or subscription data requests

  • See W3C gen 2 filtering proposal – consider additional query parameters to that list.

• A value measurements strategy for keeping more than the instantaneous current value.  I.e. expect vehicles to keep a certain number of historical value measurements.

  • How is this actually defined and limited (since keeping all the history of all signals is an impossible requirement) 

• A buffering mechanism and strategy for the case of temporary connectivity loss?  Throw-away or buffer?

• Pre-processing (edge processing) before data is transferred

  • Statistical functions.  Which ones?
    • e.g. Histogram.
  • Max/Min/Geometric Mean/Median value?
    • how to reset?
    • how to set over which time period?
• Request a sequence of measured values.

• Request a statistical result on a chunk of data.

• Discuss how to actually achieve the requests.  Queries defined per-protocol (as W3C proposal)
  • or can it use VSS "virtual" node name conventions such as:    Tree.Path.SignalX.MAX  ← implies the maximum measured value of SignalX so far?
  • And/or what goes into VSS metadata?
  • Any application of VSS layers?

Requirements (well defined, this is what is required of a protocol)

• ...

Work to do

• Define (or reuse see CVIM, SENSORIS) a data values container format.  I.e. the JSON format (presumably) that stores multiple measured values.  The VSS defines only the entities that can be measured.  W3C-Gen2 and VISSv1 defines a container format for one single value.
• Define (or reuse see SENSORIS) request formats for a "measurement job".  Unlike the real-time request for a current value such as W3C-Gen2/VISSv1 provides, or the continuous delivery of current values (Publish/Subscribe), this is something like  "If the value X is higher than 5, measure value Y for the next 3 hours".
• For each of the feature ideas, consider how it can be met by:
  • protocol query parameters
  • VSS node path addressing
  • VSS node metadata
  • or other protocol feature