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)


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

Fundamental components of an artifact design

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.

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.

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