Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It is recognised that additional features, such as synchronisation are absolutely desirable and have been a part of discussions in the Data Architecture group. For this proposal a base feature set is described to help readers quickly grasp the concept. If the proposal proceeds then additional details will be created collectively based on interest and participation.

Of course the Service has connections southbound to data feeders integrating it into lower level parts of the vehicle. As well as northbound to

...

The Service in context

The logical architecture for VSS and the Data Expert Group is Zonal ECUs and above as shown in the following diagram:

Image Added

It is assumed that the service would likely be deployed on a Zone, Domain or Central controller, with corresponding h/w capabilities.

In the Data Architecture group it is recognised that zone/domain specific data services will need to synchronise and cooperate between themselves and/or with a central vehicle computer, e.g. Inter-controller sync/cooperation:

    • Image Added

The service will integrate southbound to connections to data f

Southbound: connections to feeders, Autosar etc.

  • Northbound: connections to clients, mobile, cloud, in-vehicle Android/Apple, etc.
  • Logical: prove out connections between data layer and other logical data domains. For example, to knowledge generating concepts as suggested in the knowledge layer proposal made in the Data Architecture Group

Implementation Concepts

  • 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.