Playground design artifact outline

Tip: Specific issue or challenge that requires a solution or improvement.

• A neutral playground to investigate internals of data services. In the context of data-centric architectures for example.
• A neutral playground to investigate, illustrate and disseminate combining data services and the Covesa eco-system with other parts of the vehicle and off-board. For example, to demonstrate how VSS data can be used with VISS for newcomers.
• 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' for example.

Tip: Ultimate objective(s) that a solution aims to achieve, typically formed by the stakeholders' desires. In the context of COVESA, the goal of an artifact is inherit from the general COVESA goals defined as an alliance. In other words, each artifact will represent (minor or major) steps towards an ultimate goal.

1. The Covesa strategy calls for creation of Playgrounds, Blueprints

2. <logical / implementation>

3. <examples/touchpoints/patterns>

Tip: Criteria and specifications that the artifact must meet to address the identified problem and achieve the set goals. Typically presented as functional and non-functional.

• Functional: Specific functions, tasks, or actions that the designed artifact must perform to proof utility. 
• Non-functional: Specific qualities or characteristics that the artifact must have. They represent the constraints under which the design must operate.

• Loose coupling between components to make it easier to reroute flows and introduce new components

Functional:

• At its core the service has requirements in three key areas:

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

• It is recognised that additional features, such as synchronisation are absolutely desirable and have been a part of discussions in the Data Architecture group. A base feature set is described for the initial phases and to help readers quickly grasp the concept. Additional features will be created collectively based on interest and participation.

Non-functional:

• "Examples" can be used to show how to connect the Playground 'lego' to other components/lego.

Tip: Represents the tangible outcome of a design that aims to solve the problem and fulfils the specified requirements and goals.