Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Organizing discussion from today's CCS architecture break-out meeting

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 limits and/or add new feature requests to it
  • Understand where potentially other protocols can complement
  • Better define the set of protocols that meet the overall needs


Features (ideas under development, and brainstorm)

  • Queries that pre-filter the data

    • See W3C gen 2 filtering proposal – consider additional query parameters to be proposed

  • A value measurements strategy for keeping more than the current instantaneous  Expect vehicles to keep a certain number of historical value measurements?

  • A buffering mechanism for the case of no-connectivity?

  • Statistical pre-processing (edge processing) before data is transferred

    • Histogram?
    • Max/Min/Geometric Mean/Median?
  • Request a sequence of measured values
  • Request a statistical result on a chunk of data

  • Discuss how to request . 
    • Can use VSS "virtual" node names such as:    Tree.Path.SignalX.MAX  ← the maximum measured value of SignalX so far?
    • And/or VSS metadata.


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