Versions Compared

Key

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

This is a preliminary page intended to trial using the Artifact design methodology (simplified) to guide and describe the project. At this stage it is a brainstorming WIP

References:

  1. Central Data Service playground proposal
  2. Artifact design methodology (simplified)


Tip
titleFormulating the design problem

Improve (or solve) a <problem>
by designing an <artifact>
that satisfies <requirements>
in order to achieve <goal(s)>

Fundamental components of an artifact design

Panel
borderColor#B85450
titleBGColor#F8CECC
titleProblem

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.
Panel
borderColor#6C8EBF
titleBGColor#DAE8FC
titleGoal

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>

Panel
borderColor#9673A6
titleBGColor#E1D5E7
titleRequirements

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.
Panel
borderColor#666666
titleBGColorF5F5F5
titleArtifact

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

GPT output with the proposal as input:

Design Elements:

1. Problem:

The current lack of a neutral playground for investigating data services and disseminating knowledge within the Covesa ecosystem is causing limitations and hindering development and collaboration.

2. Goal:

The goal is to create a Central Data Service playground that allows for investigation, illustration, and dissemination of data services and their integration with other components. The aim is to accelerate newcomers' understanding of Covesa technology and facilitate collaboration among internal groups.

3. Requirements:

- Functional Requirement: The playground should provide APIs for accessing the data, such as VISS or GraphQL.

- Non-Functional Requirements: The playground should have good performance, usability, security, scalability, and reliability.

4. Artifact Type:

The project is designing a Central Data Service playground, which combines VISS Data Protocol Server with VSS Data Store to create a basic building block. The playground will include supporting documentation, patterns

diagrams, and cookbooks to facilitate understanding and usage.