Page History

...

• 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 such services with other parts of the vehicle.
    • Why Central Data Service?
      • Patterns such as view/controller, out of the box data servers, application stores etc are well known. In can in part be defined by what's not known. More clearly what is identified as open questions, in next-gen architectures such as data-centric architectures, that needs to be
    • 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.
  • What?
  • How?
  • Success factors
• 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

...