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