We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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


Table of Contents


(tick) DONE or at least completed to a usable state - in some cases still ongoing for further improvement

(warning) Notice of blocker/issue.  Improvement necessary

(error) Notice of problem. Improvement necessary

(green star) Ongoing and no problems are anticipated

(star) Very early stage, no major problem anticipated

(red star) Not started, but no problem anticipated

(question) To be defined


General / initiative organization

AREAShort NameDescriptionExpectationsSub-project org.
INFORMATION / MARKETING / DISSMEMINATION
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)

Vehicle Data



AREAShort NameDescriptionExpectations

Sub-project org.

(tick) = state of project organization

Results
CATALOGDevelop main Standard Data CatalogAdd 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 (tick)

Weekly calls:
Tuesdays, 1930 CET.

Chat on W3C slack server in #vss channel

(tick) - good status but continuous improvement expected
(META)MODELDefine 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 (tick)

details above

(tick) - good status but continuous improvement expected
ALIGNMENTAlign 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.(warning) Separate continuation meeting needs to be booked

(green star) CVII introduction made

Short analysis was also performed.
(recorded slide presentation) 

ALIGNMENTAlign with JASPARsame as described for SENSORISAll companies that are involved in JASPAR development are expected to have their representatives join into this discussion to drive towards the common goal.(warning) Separate startup meeting needs to be booked(star) Short analysis was performed.
(recorded slide presentation) 
Alignment discussions not yet started.
ALIGNMENTAlign with ISO Extended Vehicle
  • Discuss if data definitions are within scope for ExVe specifications
  • See if a standard model like VSS shall be referenced

(warning) Separate startup meeting needs to be booked(star) 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 (tick)

details above


(red star) Not started
TECHNOLOGY STACKVISS v2Complete the development of Vehicle Information Service Specification (The Web protocol for VSS data).

W3C Automotive Working Group (tick)

Weekly calls: Tuesdays 1300 EST.

Chat on W3C slack server in #gen2 channel

(green star) Ongoing, relatively complete.  Approaching usable state.
TECHNOLOGY STACKOther 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 (tick) project could be used for this



(question)
ALIGNMENTVSS in AUTOSARPromote the use of VSS data model within AUTOSAR

(red star) Need to start shared conversations













Vehicle Data


AREAShort NameDescriptionExpectations

Sub-project org.

(tick) = state of project organization

Completion of results
(META)MODELDefine 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.


CATALOGDevelop main Standard Service CatalogAdd 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 (tick)

Bi-weekly calls:
Mondays, 0900 PST

(star) 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

(green star) Early stages
TECHNOLOGY STACK
Define "remote procedure call" protocol(s)Define the web protocol for securely invoking functions from a cloud to a vehicle
W3C "RPC" meeting (tick)
TECHNOLOGY STACKDefine in-vehicle standards and bindings

Figure out the 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













  • No labels

Privacy Policy | Cookie Policy