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.


Skip to end of metadata
Go to start of metadata

Organizing input for which part of technology stack need to be

Existing technology activities

  • VISS v2 protocol development (=web protocol for VSS data)
    Tuesdays 2PM EST / 2000 CET, 1 hour, please see W3C Automotive Working group (contact Ted Guild)
  • Vehicle Service Catalog (VSC) &  RPC protocol development
    Bi-weekly, Mondays 1PM EST / 1900 CET, 1 hour, please see W3C Automotive Working group (contact Ted Guild)
  • VSS / VSSo meeting discusses tool development (vss-tools repository)
  • GENIVI Cloud & Connected Services – see project home page for information – reference architecture diagram
  • Android Automotive SIG - Vehicle HAL topic is somewhat related since it also investigates integration of the same standard data model (VSS) → see project home page for information. – powerpoint diagram.


New technology (software) activities

  • VSS to MQTT – define binary encoding, implement necessary code.   Initial analysis. – Tieto has experience.
  • VSS to VSSo translator (VSS is the source of signal definitions).   Other (non-VSSo) ontologies may link to/from VSSo however.
  • VSS / SENSORiS alignment, does it need some tooling to move between one and the other?  → work on alignment track first.
  • SOME/IP connection and/or DDS.  Data (VSS) and Service (VSC) mapping needed.  Look at AUTOSAR's Signal to Service mapping.  (Status?  Published?)
        ARA:COM is the abstraction.   It might be enough to map to this abstraction.


Specification and/or implementation focus?

Differing viewpoints:

  • Code is most useful
  • Specification is long-term useful for companies to refer to, or make alternative implementations

Priority List



Related information

  • Vehicle Signal Specification (VSS) – GitHub
  • Vehicle Service Catalog (VSC) – GitHub


  • No labels