...

• As a starting point it is suggested that the Service could be realised as a basic building block combining VISS Data Server with highly functional VSS Data Store.
• As well as the mentioned flexibility in implementation, flexibility in use is also intended:
  • With some supporting documentation it could help meet the ongoing request from newcomers to the VSS eco-system as to how VSS can be used.
  • The Data Architecture group for instance has various topics it wishes to investigate related to data-centric architectures.
  • The playground can be used to investigate internals of such a service. For example, connecting VISS to medium and high speed data, or adding a protocol.
  • External connections with other systems may also be a focus. For example, how such a Service may help combining the Service with other components to implement a particular touchpoint such as mobile.
• Further details can be found in the following sections.

...

Connections may also be made to other logical data domains. For example, there is knowledge layer proposal made in the Data Architecture Group that discusses the separation of concerns and interaction between knowledge, information and raw data layers. The Service described here could be used to provide the data layer services in its investigation.

Implementation Concepts

T

• Address two high level implementation needs, keeping in mind a path towards production where possible:
  1. Easy to develop: make it easy to build, modify and trial by providing an instance running on a host, e.g. using Docker container(s).
  2. Closer to production: the same base code should be deployable on automotive hardware (or its simulation), e.g. Yocto, container orchestration, SOA etc.
• Initial idea/sketch for base building block
  
  • Generic code: VISS Data Server with VSS Data Store backend
    • Data Architecture requirements: Add Apache IotDB (Apache eco-system, embedded and UDF) and Realm (embedded, sync) as backends to enable research.
  • Deployment 1 (assumed first target): x86 host Docker containers
  • Deployment 2 (assumed second target): ARM64 using common automotive deployment, e.g. Yocto Linux.
• Investigation sketches:
  • Data Architecture and Infrastructure pillar
    
    • Sync
      • Multi-instance of deployment 1/2
    • Logical
      • knowledge layer proposal
        • e.g. sync up/down between knowledge generator and data layer
    • Data Service Internals (e.g. server, store connections)
      
      • Latency
      • Medium and high speed data
      • etc.
  • Touchpoints, common deployment scenarios, scenarios created by other Covesa groups etc.

...