Common Vehicle Interface Initiative - Activity Matrix

Common Vehicle Interface Initiative - Activity Matrix

Proposals and description of concrete work activities to meet the goals of CVII, and the (sub)-project organization for each individual topic.

Virtual All Member Meeting 2020 - Slides and Recordings can be found here
Community slide deck can be found on the parent page.

Table of Contents

 

Completed to a usable state - in many cases still ongoing for further improvement (continuous improvement)

Notice of blocker/issue. Improvement necessary

Notice of serious problem or to indicate a cancelled activity.

Ongoing and no major problems are anticipated

Early stages and no major problem anticipated

Not started, but no problem anticipated

To be defined

 


Topic overview

(a more detailed version follows below)

General

AREA

SHORT NAME

SUB-PROJECT

DETAILS

AREA

SHORT NAME

SUB-PROJECT

DETAILS

INFORMATION / MARKETING / DISSEMINATION

All-hands information & sync. meeting

TBD

HIGH-LEVEL ORGANIZATION

Steering committee (?)

TBD

INFORMATION / MARKETING / DISSEMINATION

Informational webinars

Webinar done at Automotive World.

Additional - please propose.

ALIGNMENT

Company-specific alignments
(see details below)

Need individual one-on-one between GENIVI-W3C and companies

HIGH-LEVEL ORGANIZATION

 

(NEW) Which other companies (e.g. OEM, Tier1, or other) and Organizations should we talk to, according to you?

(E.g. Which others are you already working with, or comfortable to collaborate with in this area?)

 

(META)MODEL

Specify relationship and cooperation between VSC and VSS models

Currently discussed in two separate meetings:

VSS & VSSo development project 
Weekly calls: Tuesdays 11 AM PST, 1 PM EST, 20:00 CET.
Chat on W3C slack server in #vss channel

W3C "RPC" meeting
Bi-weekly Mondays
10 AM PST, 1 PM EST, 19:00 CET

 (note, no separate meeting for the VSC exists at this time.  Both VSC and protocol are developed in the "RPC" meeting as a start)

 

Vehicle Data

 

AREA

SHORT NAME

SUB-PROJECT
DETAILS

AREA

SHORT NAME

SUB-PROJECT
DETAILS

CATALOG

Develop main Standard Data Catalog

VSS & VSSo development project  (details above)

(META)MODEL

Define standard Data model Rule Set / meta-model

VSS & VSSo development project  (details above)

(META)MODEL

Specify relationship and cooperation between VSC and VSS models

  e.g:  VSC can refer to VSS signal definitions

          VSS has limited datatype expressiveness –> recommend use of VSC for arbitrarily complex data structures.

VSS & VSSo development project  (details above)

W3C "RPC" meeting  (details above)

ALIGNMENT

Align with SENSORIS

Some initial discussions have started between SENSORiS companies.  Further organization of this work follows.

ALIGNMENT

Align with JASPAR

Separate startup meeting needs to be booked

ALIGNMENT

Align with ISO Extended Vehicle

Separate startup meeting needs to be booked

ALIGNMENT

other orgs.  VDA?  ASAM? MONET? ...

ISO smart city, ISO intelligent transport systems, ISO open geospatial consortium,

 

TECHNOLOGY STACK

VSS to AUTOSAR translator

CVII Technology Stack track

Weekly calls: Wednesday 8 AM PST, 11 AM EST, 1700 CET.

Zoom link

 

 

TECHNOLOGY STACK

VISS v2

W3C Automotive Working Group

Weekly calls: Tuesdays 11 AM PST, 1 PM EST, 20:00 CET.
Chat on W3C slack server in #gen2 channel

TECHNOLOGY STACK

Other alternatives for data transfer protocol

GENIVI CCS Project project is one existing project available to develop the technology stack.  Others may be needed.

ALIGNMENT

VSS in AUTOSAR

TODO

ALIGNMENT

Company-specific alignments
(see details below)

Need individual one-on-one between GENIVI-W3C and companies

Vehicle Services (a.k.a. Function Interfaces, a.k.a. APIs)

 

AREA

Short Name

Sub-project org.

= state of project organization

AREA

Short Name

Sub-project org.

= state of project organization

(META)MODEL

Define standard Data model Rule Set / meta-model

W3C "RPC" meeting  (details above)

CATALOG

Develop main Standard Service Catalog

W3C "RPC" meeting  
(note, no separate meeting for VSC, see above)

TECHNOLOGY STACK (Development)

Define "remote procedure call" web protocol(s)

W3C "RPC" meeting (details above)

TECHNOLOGY STACK (Analysis)

Define in-vehicle standards for service/procedure invocation.

Set up a general Technology-Stack meeting series?

TECHNOLOGY STACK (Development)

Develop code library X

TBD

TECHNOLOGY STACK (Development)

Develop translator Y

TBD

 

 

 

 

 

Detailed view:

Expand the following view to see the detailed matrix:

 

(Same as above but with more details)

 

General organization

AREA

Short Name

Description

Expectations

Sub-project org.

AREA

Short Name

Description

Expectations

Sub-project org.

INFORMATION / MARKETING / DISSEMINATION

All-hands

Monthly (?) information to disseminate progress from each separate part, and to align high-level issues among stakeholders.

 

 

Avoid a meeting where companies join "just to listen in".  CVII activity should be active for those that choose to participate.

(NEW)

HIGH-LEVEL ORGANIZATION

Steering committee (?)

Do the stakeholders wish to have a separate steering committee of some sort?

 

TODO

INFORMATION / MARKETING / DISSEMINATION

Informational webinars

Webinars, recordings, "marketing" etc.
Simply informational

  • GENIVI & W3C main conferences

  • Present at additional industry conferences

  • Some webinars in between main conferences

TODO

ALIGNMENT

Company-specific alignments
(see details below)

Individual one-on-one discussions between GENIVI-W3C and companies, to align on actual feasibility of the stated CVII goal, in each detail of their particular development environment.

It is expected that companies have a lot of internal methods of working that are affected by CVII goals.  It may be legacy systems, or intentional future strategies.

To support each company best, we expect it is required to have one-on-one conversations about where the standards fit in, what technologies are already preferred, what is most important, where (in the in-vehicle and the cloud system) the translations from proprietary to standard is likely to occur, and so on.

It is expected that such detailed conversations are preferred to have in a non-public setting first, but they are critically important for the project to be able to provide the best value.

Set up individual meetings between GENIVI-W3C and stakeholder companies.

HIGH-LEVEL ORGANIZATION

 

(NEW) Which other companies (e.g. OEM, Tier1, or other) and Organizations should we talk to, according to you?

(E.g. Which others are you already working with, or comfortable to collaborate with in this area?)

It is important for each involved company to identify relevant/overlapping organizations so that we do not miss including anyone in the movement towards aligned model.

 

At minimum, each company identifies the collaboration/standards organizations they are actively involved in.

If possible, point out others that you may be aware of.

 

(META)MODEL

Specify relationship and cooperation between VSC and VSS models

  • Are the (meta)models consistent>

  • Are the (meta)models interoperable?

  • When to use which model, or a combination?

  • Outcome:  Document the relationship, clarify guidelines for use.

This is being discussed.  Ideas heard so far are roughly as follows:

  • VSC can refer to VSS signal definitions

  • VSS signals have (by design) a limited set of simple datatypes –> recommend using VSC modelling when there is a need to define arbitrarily complex data structures.

(the above should still be agreed by all and documented)

Discussed in these meetings in combination.  Perhaps primarily in the RPC/VSC meeting.

VSS & VSSo development project  (details above)

W3C "RPC"/VSC meeting (details above)

Vehicle Data

 

AREA

SHORT NAME

DESCRIPTION

EXPECTATIONS

SUB-PROJECT
DETAILS

STATUS (RESULTS)

AREA

SHORT NAME

DESCRIPTION

EXPECTATIONS

SUB-PROJECT
DETAILS

STATUS (RESULTS)

CATALOG

Develop main Standard Data Catalog

Add and improve to the set of signals described in the VSS Standard tree of signals

Growing the list is fairly straight forward in theory.

OEMs may have a challenge since their internal data models are often incompatible.

Those who provide input early may get advantages.

→ VSS on GitHub

 

VSS & VSSo development project 
(details above)

- usable status but continuous improvement expected

(META)MODEL

Define standard Data model Rule Set / meta-model

Take part in discussions to improving the VSS "meta-model", i.e. the rules for modelling data, a.k.a. the VSS way to describe data.

  • Is the limited set of datatypes provided by VSS enough - have we found the "sweet spot" between simplicity and expressiveness?

  • Example: We recently added Array support

  • Enums are still not perfectly defined, need some tweaking

→ VSS documentation on GitHub

VSS & VSSo development project  (details above)

 

- usable status but continuous improvement expected

ALIGNMENT

Align with SENSORIS

  • Organizational agreement/alignment

  • Understand intended scope of project

  • Technical comparison of model/rule set

  • Technical comparison of data items (catalog)

  • Set plan for how the content plays a part in one-or-several standard catalogs

All companies that are involved in SENSORiS development are expected to have their representatives join into this discussion to drive towards the common goal.

Separate continuation meeting needs to be booked

CVII introduction made

Short analysis was also performed.
(recorded slide presentation

ALIGNMENT

Align with JASPAR

same as described for SENSORIS

All companies that are involved in JASPAR development are expected to have their representatives join into this discussion to drive towards the common goal.

Separate startup meeting needs to be booked

Short analysis was performed.
(recorded slide presentation
Alignment discussions not yet started.

ALIGNMENT

Align with ISO Extended Vehicle

  • Discuss if data definitions are within scope for ExVe specifications

  • See if a standard model like VSS shall be referenced

 

Separate startup meeting needs to be booked

Contacts established. Meeting pending

TECHNOLOGY STACK

VSS to AUTOSAR translator

Develop translators from VSS data description to AUTOSAR technology.  Specifically: A translator with VSS as input, AUTOSAR-XML as output.

There is already an indirect way by doing VSS→Franca IDL (WIP) and then using Franca IDL → AUTOSAR XML converter, but this should aim to develop a direct converter.

The vss-tools repository can host such translators (but companies are free to provide their own public repository).

vss-tools are discussed in:

VSS & VSSo development project 

(details above)

 

Not started

TECHNOLOGY STACK

VISS v2

Complete the development of Vehicle Information Service Specification (The Web protocol for VSS data).

 

W3C Automotive Working Group

(details above)

 Ongoing, relatively complete.  Approaching usable state.

TECHNOLOGY STACK

Other alternatives for data transfer protocol

Companies may prefer/propose other protocols and data transfer methods if there is a clear need for them – remember to avoid fragmentation.

  • In GENIVI CCS project we have had some early look at Apache NiFi and related technologies

  • VSS to MQTT mapping - there is a brief high-level analysis done

  • GraphQL has been demonstrated in both CCS and Android Automotive SIG (VHAL) projects.

  • WAMP has been discussed as one possible solution for W3C "RPC" (working name) protocol

  • ...other?

 

GENIVI CCS Project project could be used for this

 

 

ALIGNMENT

VSS in AUTOSAR

Promote the use of VSS data model within AUTOSAR

 

TODO

Need to start shared conversations

 

 

 

 

 

 

 

Vehicle Services (a.k.a. Function Interfaces, a.k.a. APIs)

 

AREA

Short Name

Description

Expectations

Sub-project org.

= state of project organization

Completion of results

AREA

Short Name

Description

Expectations

Sub-project org.

= state of project organization

Completion of results

(META)MODEL

Define standard Data model Rule Set / meta-model

 

  • Alignment with Franca IDL still needs a bit more work both in terms of model/content and in terms of the exact names of concepts (Interface, Method, Parameter, etc.)

  • Related to the above, defining all needed parts of the service model rule set is still a work in progress, while a few examples are also provided.