Outline

• Intro
  • Why?
    • Covesa needs:
      • Repeated use of shared terminology, patterns and tools leads to quicker understanding in discussions, shared costs in development and can lead to quicker outcomes.
        • Jump from 'what is the box' to 'how are we using the box'
      • A neutral playground is needed to investigate internals of such services. In the context of data-centric architectures for example.
      • A neutral playground is needed to investigate, illustrate and disseminate combining data services and the Covesa eco-system with other parts of the vehicle. To demonstrate how VSS data can be used with VISS for newcomers for example.
    • Why Central Data Service?
      
      • 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.
    •  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.
  • What?
    • As a starting point a basic building block combining VISS Data Server with highly functional VSS Data Store.
    • This piece of lego can then be extended and reused in various ways. The Data Architecture group for instance has various topics it wishes to investigate related to data-centric architectures.
    • Details in following sections.
  • How?
    • Endeavor to provide solutions that allow packaging for flexible deployment in a variety of scenarios.
    • Address two high level 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.
  • Success factors
    • Newcomers to Covesa technology use the playground to accelerate their understanding of how the technology can be used. That could be a looking at a simple instance of how a VSS data server is combined with a VSS data store and queried using VISS. It could also be a more complex instance that combines components to illustrate a longer specific end to end use case, e.g. mobile to vehicle connection.
    • Internal groups within Covesa naturally use the logical concepts and the playground implementation in combination with other components to develop and disseminate ideas.
    • Supporting materials such as patterns, diagrams, cookbooks etc are adopted as useful assets within and outside Covesa, which in turn helps socialisation.
• Logical concepts
  • Central Data Service
    • 
       
  • Service in context
    • Zone/domain/HPC controller sync (system)
      • Logical architecture for VSS - zonal ECU and above:
      • Inter-controller sync/cooperation:
    • Southbound: feeders, Autosar etc.
    • Northbound: clients, mobile, cloud, in-vehicle Android/Apple, etc.
    • Logical: knowledge layer
• Implementation concepts
  • Needs
    • Easy to modify, build and trial: Docker containers on host
    • Real: SOA, Container orchestration, Automotive h/w, Yocto
  • Initial idea/sketch for base building block
    
    • VISS Data Server with VSS Data Store backend
      • Add Apache IotDB (Apache eco-system, embedded and UDF) and Realm (embedded, sync) as backends