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

Vehicle Data

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
(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:

 Expand Here

(Same as above but with more details)

General organization

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)
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
(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.
CATALOG	Develop main Standard Service Catalog	Add and improve to the set of services described in the VSC Standard catalog of services.	Organization into multiple catalogs seems likely (e.g. outside/inside vehicle). There are many separate API standards that already exist.  Every system that has an open API of some sort, has them published.  Therefore there is a lot to discuss about organizing this into separate catalogs, and separate sub-trees, and also setting limits on the intended scope. OEMs and Tier1s and most other developers of technology are potential stakeholders in this.  Currently, almost each component/ECU/system has different APIs.  Bring some of those into standardization.	W3C "RPC" meeting  (details above) Note: here is not yet a separate meeting organization for the development of the VSC itself (like exists for VSS).   Both model/catalog and protocol is discussed in W3C meeting at the moment. Chat on W3C slack server in #rpc channel	Early stages
TECHNOLOGY STACK	Define "remote procedure call" web protocol(s)	Define the preferred web protocol for securely invoking functions from a cloud to a vehicle.  The W3C uses the working name "RPC" (Remote Procedure Call) for the moment.  Over time another final name will be defined.	Reusing existing technologies/standards seems likely.  Evaluation of choices ongoing (gRPC, WAMP, JSON-RPC, Web-of-things...)	W3C "RPC" meeting  (details above)
TECHNOLOGY STACK (Analysis)	Define in-vehicle standards for service/procedure invocation.	Identify the preferred technologies needed to bind together the service/interface descriptions with the software technologies that execute them inside the vehicle: Identify code implementations to map the interface descriptions to SOME/IP and DDS as proposed by AUTOSAR Discuss VSC ↔ standard Franca IDL translation (because Franca IDL to AUTOSAR XML translation already exists, both directions) other methodologies?	For procedure calls betwen ECUs inside vehicles - if technologies other than SOME/IP and DDS (or the upcoming W3C "RPC" standard) are used, these are expected to be brought forward for discussion by participants
TECHNOLOGY STACK	Develop code library X	(details decided based on analysis above)	TBD	TBD
TECHNOLOGY STACK	Develop translator Y	(details decided based on analysis above)	TBD	TBD

General Questions

• Which topic in the matrix will you provide resources to?
• Which topics are still missing?
• Are the already existing proposed (sub) projects appropriate for you?
  • Is there any hindrance for you to participate in those existing proposed projects (GENIVI, W3C participation)
• Which (new) sub-project meeting will your company start and lead?
• Which parts (sub-trees in the hierarchy) of the standard data / services catalog will you provide input to?
• Which technologies would you like to propose in the "agreed-upon" technology stack?
• How can we start discussing your internal structure (organizational/technical) to understand how the CVII best supports it?  
  • E.g.:  Which standards do you use today?
  •         Where is it realistic to introduce the new standards?
  •         Where (in your particular system) shall there be translation between legacy/proprietary and the new standards?
• Will your company further support the development of these types of activities by joining GENIVI and/or W3C?

Partial Reply RB GmbH (Bosch)

• Which topic in the matrix will you provide resources to?

  CATALOG	Develop main Standard Data Catalog
  (META)MODEL	Define standard Data model Rule Set / meta-model
  ALIGNMENT	Align with SENSORIS

• Which topics are still missing?
  • Not completely "missing", but "Services/RPC" are an important point, Currently (VSC) almost nothing, and not clear how it will "tie into" VSS without reinventing the wheel
    • Gunnar: Good point.  There are already discussions (in VSS call and RPC/VSC meeting) and some proposed strategy for this.  But I think it's important enough to add, so I created a line in the table.
  • In terms of ARA:: Com there are two perfectly matching mechanisms => Events and Methods => IMHO VSS is the perfect base for that discussion
    • Gunnar: +1.  To each company: please help us identify who (involved in AUTOSAR) can be part of driving that discussion.
  • Kind of reference implementation (partly covered by kuksa.val) but whole stack is missing
    • Gunnar:  The key is to identify which parts are promoted as either "reference" or simply "good" implementation of each technology.  What already exists vs. what is missing from a complete stack ought to be described (use a diagram), and then broken down into development project for the missing parts.
  • Would a CVI Dev Kit help?
    • Gunnar: One way we often do this is develop the components, then produce a demo that integrates them all.  The demo should be placed in a combined repository (using appropriate technology such as references/git-submodules etc.)  
    • But if we can create a "dev kit" (with components, and documentations for how to integrate them) this is even more flexible.  
• Are the already existing proposed (sub) projects appropriate for you?
  • VSS & VSSo development project, W3C VISSv2
    
    • Working on VSS standard
    • Working on, invite participation in C++ kuksa.val VISS server https://github.com/eclipse/kuksa.val , hopefully VISSv2 in future
  • Is there any hindrance for you to participate in those existing proposed projects (GENIVI, W3C participation)
    • not a W3C member yet
• Which technologies would you like to propose in the "agreed-upon" technology stack?
  • a more "binary" representation of requests in transport protocols instead of JSON (e.g CBOR, protobuf...)
    • Gunnar: +1.  This is a clear technology stack subproject.
  • best practice how to extend/widen/leverage VSS data model to a fully semantic digital twin for knowledge engineering in backend
  • DDS, MQTT, D-BUS, DAPR.IO, ...
    • Gunnar: Indeed these are additional  useful technologies.  Other stakeholders may also give their view on priorities.

 [ ] Ted Guild Can you help out to link to W3C meeting information.  In particular I could only write "bi-weekly" but that does not specify exactly when.  A link to wiki or mailing list where invites are sent, will help.

Comments

• Scope does not include to define who has access data
• Might be impacted by work by The Automotive Alliance?