VISS-RSI-convergence-framework

From Auto

Goals of Specification

The ongoing common goal of the W3C Automotive WG (and BG) is to enable access to vehicle information and functionality via web bases protocols and technologies. Here is the abstract from VISS:

This specification defines a WebSocket based API for a Vehicle Information Service (VIS) to enable client applications to get, set, subscribe and unsubscribe to vehicle signals and data attributes.

The purpose of the specification is to promote a Server API that enables application development in a consistent manner across participating automotive manufacturers.}


Here is a list of common goals:

  • Common Data Model
  • Common/Consistent Access Protocol
  • Support known paradigms
  • Support exposing signals
  • Support exposing vehicle functionality such as Nav, Media
  • Access vehicle data (data from the vehicle) inside and outside of the vehicle



Framework is agnostic to transport however recommends http and websockets Support fast streams of data for situations where needed speed, rpm, etc..

Multiple views of information in the vehicle - low latency published info important

Feature Discussion Topics

This is a list of features we would like to see in the new framework. Additionally topics which have to be decided are listet here as well.

  • Versioning
    • having version clusters of version clusters
  • addressing data
    • what should be addressable
    • how should an address look like
  • registry / list of resources / list of services
    • extensible at run time?
  • payload encoding (JSON, JSON-LD, . . .)

Feature Descriptions

These are the descriptions of features which were discussed and most likely have been on the feature discussion topics list before.

  • element handling
    • object oriented
    • interlinking the objects
  • introduction of clusters
    • to reduce "complexity"
    • handle a bunch of objects as a "collection" with a certain version
  • Target Group
    • Discussion: https://lists.w3.org/Archives/Member/member-automotive/2018May/0031.html
    • internal functions main focus for the framework
    • make information from the vehicle available to developers
      • These developers might be 3rd party developers
    • framework primarily for developers as they should have it as easy as possible to interact with the vehicle.
      • It would be cool if 3rd party apps could offer something in the same manner as internal functions are offering information (extensibel)
  • distributed Implementation of vehicle interfaces
    • Discussion: WG Call 2018-05-22
    • created from discussion topic "micro services"
    • distributed implementation of services implementing the APIs should be possible
    • distributed implementation could have an impact on the possibilities of queries
  • grouping (signals and resources)
    • Discussion: WG Call 2018-05-22, still not finished as group asked for an example
    • Data values shall not be buried for developers, it shall be logical from a developers point of view (Data Value)
    • Data values shall be easily structure into a rough object like approach (Object)
    • Similar objects shall be grouped by a context (Cluster)
    • Example:
      • Cluster: Body
        • Object: Window (or List of windows)
          • data value: position
          • data value: dirty
        • Object: Doors (or list of doors)
          • data value: locked
          • data value: closed
          • data value: window
  • queries
    • Discussion: https://www.w3.org/2018/05/29-auto-minutes
    • it is part addressing the data in question, part filtering for a certain set of data
    • filtering
      • we want to be able to ask for "all doors which are open"
      • problem: to much work for source implementation possible if to much possibilities to structure a query
      • use of resources on service side might be limited
      • idea: service can "tell" what kind of filter/query possibilities are offered. Client may solve the rest
      • capabilities for filtering might be depending on implementation. expected data amount vs. complicated implementation
      • filtering shall be possible on every value which is "easily describable" (e.g. binary blobs might not be filterable)
      • Other solutions
        • xpath
        • SQL


When to use VISS (WebSockets)/When to use VIWI(REST/HTTP)

From this blog, below is a table of key differences between HTTP/REST and WebSockets. On the links page, there is a good list of when to use which one. It would be good to have such a list here.

HTTP (REST) WebSockets
Duplex
Half Half
Messaging Pattern
Request Response Bi-directional
Service Push
Not natively supported. Client polling or streaming download techniques used. Core feature
Overhead
Moderate overhead per request/connection. Moderate overhead to establish & maintain the connection, then minimal overhead per message
Intermediary/Edge Caching
Core feature Not possible
Supported Clients
Broad support Modern languages & clients
Load Balance
Commonly used Usually does not fit

Information Models VSS/VIWI

VSS

  • Defines a tree structure (restricted graph).
  • A tree structure "can define anything".
  • Optimized for vehicle signals (strive for easy/direct translation to CAN database and similar)
  • Defines a private branch for proprietary signals
  • Primarily aimed at vehicle signals, but also includes domains for media and navigation (Signals.Cabin.Infotainment .Media and .Navigation)
  • Creates a clear divide between static (Attributes.*) and dynamic data (Signals.*)
  • Allows the client to access data from a specific branch (complex types) or a leaf (primitive type)
  • Extensible to allow new zones, for example a new row of seats, which can still be accessed with wildcard, Signal.Cabin.Seat.Row1.Pos4.IsBelted, Signal.Cabin.Seat.*.*.IsBelted

VIWI

  • Defines a tree structure, with 3 levels and additional source selector capability for some APIs
  • A tree structure "can define anything".
  • Same organization for vehicle signals and other APIs
  • Returns objects containing multiple data points, rather than single primitive types
  • Zoning still to be fully explored, but at the moment is embedded in primitive types name which could potentially be difficult to deal with (extensibility for new zones), for example torqueDistributionFrontLeft

VSS turns into RSI example:

Attribute.Chassis.Axle.Row1.WheelCount 11 UInt8 Number of wheels on the first axle <TODO VIWI>

Some examples for comparison:

VIWI GET /car/drivingstates/ receives a list of drivingStateObject VSS (signal name used to get/set/subscribe primitive type)
drivingStateObject.yawRate Signal.Vehicle.Acceleration.Yaw
drivingStateObject.acceleratorPosition Signal.Chassis.Accelerator.PedalPosition
drivingStateObject.longitudinalAcceleration Signal.Vehicle.Acceleration.X
drivingStateObject.lateralAcceleration Signal.Vehicle.Acceleration.Y

Understanding on VIWI

  • VIWI uses WebSockets as well as REST.
  • In VIWI, REST is used for get(HTTP GET method) and set(HTTP POST/PUT/DELETE methods), while WebSockets is used for subscription model.
  • HTTP and WebSockets have pros and cons for each. REST could be useful in terms of a simple and flexible design for several connections.
  • You can see the table for the comparison of five methods in the following link. (The table needs a horizontal scrolling for WebSockets.)
 * Comparison of five methods for VIWI: https://www.w3.org/Submission/2016/SUBM-viwi-protocol-20161213#application-to-viwi
  • Also, you can see a VIWI demo video that makes you easily understand the VIWI basic operations (when to use REST and WebSockets)
 * VIWI demo video: https://youtu.be/b2U8B9Dfg7k


TO DO

  • Define data elements/use existing data elements. Create definition.
  • Define data structures using the data elements. Use VSS and VIWI (exemplar)

Definitions

  • VIWI - Volkswagen Submission
  • RSI - Rest Services Interfaces - Spec to be created by Automotive WG per charter

Task Forces? - Work Packages? Note: This is exemplar for now.

  • Data Model
    • VSS Improvement
    • Define data elements - come up with flat data element definitions - Start with VSS and RSI
    • Ontology Taxonomy -
  • Framework/Access
    • RESTful services added
    • Registry
    • API Versioning
    • Status Codes
    • Queries
    • Addressing
    • CORS
    • Paging
    • Filtering
    • Introspection Interface
    • User Authorization/Authentication
      • Tokens
      • OAuth

Concerns

Retrieved from "https://www.w3.org/auto/wg/wiki/index.php?title=VISS-RSI-convergence-framework&oldid=540"