Versions Compared

Old Version 6

changes.mady.by.user Stephen Lawrence

Saved on

compared with

New Version 7

changes.mady.by.user Stephen Lawrence

Saved on

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>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

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.