ViWi

ViWi

This page is for the ViWi Task Force to organize thoughts, contrast ViWi and VISS, collect use cases for app development, possible transition and merge plan, etc

This Task Force will send minutes and converse by email over using [ViWi] Subject tag on public-autowebplatform@w3.org

Resources

2016-10-20 and 21 WG F2F where ViWi was introduced

VW Member Submission of ViWi

Participants

• Ted Guild
• Paul Boyes
• Rudolf Streif
• Patrick Lünnemann
• Wonsuk Lee
• Kevin Gavigan

Schedule

Telephone Conference

1st and 3rd Monday of the month

0500JST (Tues) / 1600EDT (Mon) / 1300PDT (Mon) / 2000GMT (Mon) / 2200CET (Mon)

call coordinates

2nd and 4th Monday for PDT in North America, Tuesday in Asia, Europe and EDT North America of the month

0600 CET (Tues) / 0500GMT (Tues) / 1400 JST (Tues) / 2100 PDT (Mon) / 000 EDT (Tues)

call coordinates

Open Discussion Points

• discussion of rest approach as the general, architectural principal [? ViWi is REST + WebSocket, not just REST ?][Should comparison with PSA + IBM, AGL, other approaches also be considered?]
• REST, API, Service, Plugins - Programming, Architectural and Integration paradigms
• necessary scopes for a in-vehicle protocol
• Domains in a vehicle: media, speech, devices, weather, traffic, payments, etc... (See https://www.w3.org/community/autowebplatform/wiki/Potential_Work_Areas)
• Cohesive common access methods and data definition that work across domains. Give the app developer cohesive access
• Common integration layer for application frameworks
• Cross cutting security approaches

Architecture

Notes pertaining to architecture

@@links to previous TAG discussion, internal W3C Staff architectural minutes

Use Cases

Vehicle Information Service (VIS) and Vehicle Information API (VIA) Use Cases

For the discussion of the ViWi use cases it might also be useful to compare them to the VIS/VIA use cases. VIS/VIA is an evolution from an earlier specification draft detailing access to vehicle information from a browser and/or web runtime running on an infotainment unit inside the vehicle. For that purpose the specification treated the vehicle as a platform similar to a smartphone where APIs built into the browser provide access to platform sensors such as GPS, accelerometer etc. Looking at a vehicle as a platform like that makes sense in general, however, it comes with some major differences:

• a modern car has hundreds of sensors and actuators,
• vehicle hardware and software platforms are diverse.

The typical approach for browser APIs models the APIs and data types in WebIDL as part of the specification. Browser implementers then take the specification and build the API into their browser software. If the browser is offered for different underlying hardware and software platforms (OS) then the implementation has to be ported to each of those platforms. That works well if there are only a few platforms that each have a huge proliferation to amortize the cost of the implementation. It also works best for a small number of sensors and actuators that are mostly consistent across all platforms and do not change or grow significantly.

Vehicle platforms are different: hardware and software platforms are the choice of the automakers and their suppliers and vary significantly not just between automakers but also between models of the same automaker. Implementing APIs directly into the browser software would hence hardly be economical. Vehicles also have many hundreds of sensors and actuators and the number is steadily growing with new features being implemented in cars. A specification trying to capture all and model them as APIs and data types would permanently lagging behind. Actual implementations into browsers would be even more behind as the product cycles of the industry are much longer.

Hence the new VIS/VIA specifications aim to tackle these problems by

• separating the sensor and actuator information from the API - there are only the generic APIs get, set, subscribe and unsubscribe, the information to be accessed is passed as arguments;
• splitting the implementation into a service and a library - a websocket server provides the service that is accessed by applications using the library.

This approach allows for simple extension of the sensors and actuators without the need to change the specification. It also avoids native implementation of APIs into browsers as the library can be implemented in JavaScript. Further details can be found in this blog post and the actual specification.

The primary uses cases supported by VIS/VIA are:

• Provide access to vehicle signals such as speed, engine rpm, outside temperature, coolant temperature, battery level, door status, location, etc.
• Provide controls for actuators such as lights, windows, sun/moon roof, etc.

At their inception VIS/VIA did not intend to:

• Provide access and controls for typical infotainment data such as what station is playing, tracks on a media, playlists, etc;
• Provide access and controls for devices outside of the vehicle network boundaries.

However both the ViWi or VISS approaches supports returning object graphs for any domain.

Differences VISS to ViWi

• Filtering for a GET-Request in VISS is not available (VISS Issue #135 has been created to review adding this)
• Wider domain scope within ViWi as in VISS right now (but VISS readily supports returning object graphs for other domains with their own schemas)
• Change multiple elements in one call within VISS

Next comparisons

• Use of Sockets

• VISS: One WebSocket
• ViWi: One HTTP Socket + One WebSocket
• Any Advantages in the HTTP Socket?
  • Why just use sockets and not rest style sockets

• Decision in Summer F2F 2016?

- VISS spec. would progress according to WG charter. Working Group would look for areas of consensus. ViWi will be picked up by Business Group and will be discussed along with possible proposals from other interested parties e.g. PSA+IBM, AGL.

• New Scopes for VISS
• Media? Tracks, Albums, Playlists

Why to REST?

[Suggest this should be in the form of a table to allow side by side comparison]

• REST allows caching of GET requests [WebSocket: results can also be cached]

• routers, proxies etc. make heavy use of it to speed up the access
• controllable via Etag and If-None-Match Headers

• All entities accessible via HTTP GET are be side-effect free, i.e the entity just returns a representation of itself. Invoking the entity does not result in modifying the entity. [WebSocket: Get requests are also side-effect free]
• Modifications (POST requests) are idempotent by design [WebSocket: Set is idempotent by design]

• heavily promotes multi client capabilities

• Use hyperlinks to reference from entity to entity [WebSocket: Object graph could be efficiently searched/navigated using CSS (jQuery) style selectors]

• Designed to reveal data gradually. No need to reveal all data at once, hyperlinks are used to obtain more details. [WebSocket approach supports either revealing data gradually or revealing more/all data at once]
• allows cross domain and cross host linking [WebSocket: No restriction on how client uses or combines object graphs, in that sense approach is purely data driven]

• REST is easy to implement in client and server [WebSockets are very easy to implement in client and server]

• Even implementations on very small (embedded) devices including those which run in fixed cycles (e.g. 100ms) available

• REST verbs well known throughout the industry
• REST is easy to implement, debug and automatically test with readily available tools [WebSocket: Comparison for ViWi is not REST vs WebSocket, it is Hyrid REST + WebSocket vs WebSocket. Hybrid approach forces code to be split between REST and WebSocket, so probably more difficult to implement, debug and more code to automatically test c.f. pure WebSocket approach]

• Browser Tools
• Server tools
• API Test tools

• REST uses well known standardised Headers
• REST uses query parameters to allow filtering

• elements
• lists (even huge lists)

• WebSocket push is just an extension of REST to subscribe to GET urls
• It feels very natural to integrate with other devices (IoT) and Web services => promotes adoption

Pros and Cons

• WebSockets
  • Pros

Simplicity: Pure WebSocket model is simpler to implement and maintain than a Hybrid REST + WebSocket approach. In the pure WebSocket model, client code is interacting with a single interface to Get, Set and Subscribe to data. In the hybrid model, the developer has to write separate code to Get a specific signal (using REST) versus Subscribing to receive notifications for that signal (via WebSocket). Developer then needs to add code to combine results to create a consistent state model, creating the potential for race conditions. If values are different, which is the later, the result from the Get or the data in the subscription notification?

Consistency: Getting data via different routes is also prone to logical and temporal inconsistencies. If different mechanisms are used to get and subscribe to data or to get data separately, then how can a client App be sure that data is logically or temporally connected? For example, if a single mechanism is used to e.g. get number of wheel ticks and speed at the same time as part of the same result set, then the server can take care to ensure that the speed value is ALWAYS the processed result that follows from the number of wheel ticks. If a client of a Hybrid system subscribes to get wheel ticks and separately gets vehicle speed, it will be very much harder for the server to ensure that related or corresponding values are returned (e.g. it might have to implement its own cache that it refreshes periodically to do this).

Flexible: WebSocket approach defines only Get, Set, Subscribe, Unsubscribe, Authorize and a 'getMetaData' method. It is completely general and can easily be re-used across different domains, with different endpoints returning data satisfying the relevant schema for that domain.

DRY: A pure WebSocket approach makes it easy to get all or part of an object graph and/or refresh the SAME graph using a subscription. This DOM style, 'in-memory' object graph can be searched and traversed using a CSS selector (jQuery) like approach. Hybrid approach needs to have separate codebases and to continually combine data sources in order to construct a searchable in memory object graph.

Security: A Hybrid approach increases the security attack surface as both RESTful web services and WebSocket need to be secured. In a pure WebSocket approach, only WebSocket needs to be secured.

• • Cons
• REST + WebSocket
  • Pros
  • Cons

- One of the main advantages of the RESTful web service model is that state is encoded within the RESTful url (reducing or removing the need for client and server to store state information). In a typical RESTful model additional calls are made as client App e.g. obtains a collection, then on next RESTful call requests details for the first item in the collection etc. etc. So in a _typical_ RESTful web service multiple invocations are used to 'walk' the object graph that the web service encapsulates. By design, the RESTFul URL is tightly coupled to the object graph it is exposing (as the URL is the mechanism for representing current state). So if two vehicles have different detailed object graphs, in a truly RESTful model, the set of URLs that a client would use will be different. On a vehicle there are benefits to obtaining all or part of an object graph in one call (or via a single subscription notification). This reduces the number of times that server is invoked, naturally supports the easy creation of an in-memory DOM style object MODEL (cache) that can form the core of the Model component in an MVC style implementation. The client can then easily navigate the model using very familiar and well understood CSS (jQuery) like selector syntax.

• API
  • Pros
  • Cons
• Plugin
  • Pros
  • Cons