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

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 organization

Vehicle Data

AREA	SHORT NAME	SUB-PROJECT DETAILS
CATALOG	Develop main Standard Data Catalog	VSS development project
(META)MODEL	Define standard Data model Rule Set / meta-model	VSS development project
ALIGNMENT	Align with SENSORIS	Separate continuation meeting needs to be booked
ALIGNMENT	Align with JASPAR	Separate startup meeting needs to be booked
ALIGNMENT	Align with ISO Extended Vehicle	Separate startup meeting needs to be booked
TECHNOLOGY STACK	VSS to AUTOSAR translator	VSS development project
TECHNOLOGY STACK	VISS v2	W3C Automotive Working Group
TECHNOLOGY STACK	Other alternatives for data transfer protocol	GENIVI CCS Project project could be used for this
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  (note, no separate meeting for the VSC exists at this time.  Both VSC and protocol are in W3C meeting for now)
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
TECHNOLOGY STACK (Analysis)	Define in-vehicle standards for service/procedure invocation.	TODO:  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. 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 will 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. 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 development project  Weekly calls: Tuesdays, 1930 CET. Chat on W3C slack server in #vss channel - 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 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 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 Weekly calls: Tuesdays 1300 EST. Chat on W3C slack server in #gen2 channel  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 Bi-weekly calls: Mondays, 0900 PST 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 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 or W3C?