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

« Previous Version 5 Next »

  • GraphQL strategy sharing Sharing of viewpoints for GraphQL integration
  • Interfacing VSS Data Storage to VSS Data Servers
  • CAN integration
  • VSS and VSC cohabitation

GraphQL strategy sharing

Original proposer: Unknown User (alexander.domin) 

Alexander wishes to have a discussion about GraphQL and how he sees its integration in the architecture. Exchange of viewpoints should make it clearer where GraphQL can sit in the tech stack.

Interfacing VSS Data Storage to VSS Data Servers

Original proposer: Stephen Lawrence 

Architecture and strategy discussion on interfacing VSS Data Storage to VSS Data Servers:

  1. Protocols, methods
  2. Requirements
  3. Different architecture configurations, e.g. deployment illustrations in vss-otaku and kuksa.val

CAN integration

Original proposer: Gunnar Andersson Stephen Lawrence others..

This comes up repeatedly. Integration of CAN into VSS data feeders. Various methods and ways to do: socketCAN, via SomeIP, code generators.

From this would ideally come some more concrete plans to improve and fill in gaps in OSS CAN eco-system

VSS and VSC cohabitation

Original proposer: Gunnar Andersson

Sensors/actuators can be manipulated through VSS (VISS). In-vehicle functions, e.g. comfort, may also be controlled through VSC defined APIs that may be higher level than manipulating sensors/actuators. In this way a future vehicle will most likely contain a mix depending on the functionality. Best practices therefore need to be developed for the cohabitation of VSS and VSC so they both maintain a consistent view of the vehicle state.

Coordination note: Where to do this as it affects Tech Stack, VSS and VSC? AMM kick off where all together?

  • No labels