Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.


Communication framework

Image Added

  • Starting from the in-vehicle data capturing, it is assumed that data can be transmitted by ECUs both in VSS2 and proprietary data models.
  • Container processing in the vehicle is the process of encapsulating single data points into packages that can be either directly transmitted to the OEM cloud or buffered. The example data package snippet is derived from the Common Vehicle Information Model (CVIM) project where it was foreseen that a data package has meta information such as capturing frequency, start time, end time, number of samples.

  • For data transmission from the vehicle to the OEM cloud a transport protocol like MQTT would be needed. Although not common in this context, GraphQL is introduced as an example, as the data transmission could potentially be implemented with a component that later can be reused for 3rd party interfaces.
  • The OEM cloud includes components for Resources Management, Access Management and Identity Management in order to comply with the Extended Vehicle standardisation.
  • Both 3rd parties and data marketplaces can access data from the OEM cloud using a REST API/GraphQL or alternatively socket connections. Socket connections are especially useful for marketplace interfaces with heavy traffic, both for personalised and anonymised data use cases.


Image Added

  • "Container processing" as replaced with "State storage" in order to not confuse the term for containerised computing. In addition the vehicle interface was renamed from "Server client" to "Data server" as the vehicle is generating the data and the OEM cloud connects to the vehicle to request data.
  • W3C Gen2 Core and Transport was introduced as the solution for vehicle-OEM cloud communication instead of CVIM/SensorIS and MQTT. Gen2 is designed for this purpose but opened a few requirement questions discussed in this document, especially about offline buffering.
  • OAuth2 was added as the implementation guideline for OEM cloud Access Management.
  • OpenID was added as the implementation guideline for OEM cloud Identity Management.


Features (ideas under development, and brainstorm)

...