...

Success Factors

Logical Concepts

From a communication and community perspective it is important to maintain descriptions of the logical concepts. Discussion at a logical level allows different parties to collaborate on common concepts, whilst making different implementation decisions, e.g. in product/technology selection or system architecture for example. That does not mean we need spend months in philosophical discussions before moving to implementation. Instead logical concepts (why, what) can be developed alongside implementation.

It is therefore proposed that the project maintain both logical and implementation concepts.

There is a parallel proposal within the Data Architecture group for documenting Covesa concepts such as design patterns and it proposed that this be used.

Central Data Service Playground

...

• A repeating pattern of discussion in the Data Architecture pillar is the combination of VSS Data Server and VSS Data Store and their connection southbound to feeders/native data and northbound to clients and off-board. Hence Data Service.
• VSS is a mechanism of abstraction. The logical architecture for the Data Expert Group and VSS places operation in the zonal ECUs and above. Discussion of next-gen and data-centric architectures suggests investigation into data services in zone, domain and HPC controller scenarios and the cooperation between them. Hence Central.
• The name Central Data Service is not an attempt to introduce a new category of component. It is used here simply as a useful synonym for what otherwise would be a longer descriptive phrase explaining combinations of VSS centric Data Server and Store and their location in the vehicle.

 Why playground? Why not PoC?

• A PoC is often a snapshot in time and often specific in scope. Playground suggests greater flexibility. The central service, the lego, is intended to be flexible and evolving. Similarly with what it is combined with to illustrate Covesa concepts and technology.
• Patterns such as view/controller, out of the box data servers, application stores etc are well known. The Service could in part be defined by what's not known, by open questions, in next-gen architectures such as data-centric architectures, that needs to be tackled down. The Playground is the means to doing that and illustrating the results.

Image Added

At its core the service has features in three key areas:

1. Data Models: the live data models - VSS as the abstracted view of the vehicle, along with other adjacent data models such as personal data.
2. Persistence: history of the model and signals etc - historical and cached timeseries data.
3. Application logic / APIs: for accessing the data such as VISS or GraphQL.

The Service in context

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.