Versions Compared

Old Version 11

changes.mady.by.user Paul Boyes

Saved on

compared with

New Version 12

changes.mady.by.user Daniel Alvarez

Saved on

Key

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

Table of Contents

Essential Requirements

Essential Requirements should be at a high enough level to be useful, provide shape to and evaluate solutions (Business and/or Product level).  They are not meant to be exhaustive.

Note:  This is just a quick replication of Daniel Alvarez table with a few more columns just to get my thoughts out.  Please contribute, comment, or edit.  

The following table represents a zoomed-out view of the essential requirements that the VSS modeling language should satisfy. They are based on the different stakeholders' desires which have been collected through multiple exchanges. 

Info
If you consider that a particular criterium or aspect is missing, feel free to contribute. Bear in mind that any contribution must be framed in a collaborative way to foster community support and future adoption.
Must Have Requirement NameDescription
Abstract requirement
Business RequirementProduct RequirementVSPECDesiredNotes
Simplicity
  • Must be easy to understand and adopt.
  
  • Must be human-readable.
  • Must be easily understood by
engineers, analysts
  • Must not be so complex that only a handful of data scientists understand it
    • Subject Matter Experts (SMEs), even when they have little to no knowledge of data modelling best practices.
    • Must be useable by new comers
    Must be understandable and useable by engineers
    • within a reasonable period of time (
    < 1 day?)
    • e.g., a few hours).
    • Must be easy to contribute
    /add new (signals, elements)
    • (i.e., to extend the controlled vocabulary).
    		YesThe approach for describing data structures is human-friendly and easy to understand and contribute to.Yes
    Technology Agnosticism
    • Must work with a variety of widely industry adopted tools for adoption and cost.
    • Ease of adoption
    • Ease of contribution
    • Must work with a variety of technologies
    		YesSpecification offers a vocabulary only. It can be exported into multiple formats and could be potentially used in any downstream system, as long as there is a tool for exporting it as desired.Yes
    Modularity
    • Adopt and contribute only the pieces needed.
    • Ease of adoption
    • Ease of contribution
    • Must be able to adopt only parts of the model that matter to the user
    • Must be able to extend and override parts of the model as needed for internal and external use
    		Partly Specification can be split into multiple files that will be read as a whole during the export.Yes
    Scalability & Maintainability
    • Ease of adoption 
    • Ease of contribution
    • Flexibility
    • Cost
    • Must support a wide variety of vehicle domains (e.g. Seating, HVAC, Entertainment, Engine, etc...)
    		PartlyYes in the sense that the vocabulary of vehicle properties can be further extended. However, its expressivity is limited and covering more features requires significant work on the tools.Yes
    Metadata Resource Uniqueness

    		PartlyJust the Fully-Qualified Name (fqn) and the UUID that can be constructed from the metadata are unique. Specification of a concept can appear multiple times.Yes
    Support for Multiple Classification Schemes

    		NoOne tree has one dimension only. Paths of the expanded tree create dependencies and moving a concept to another part in the tree is usually painful.Yes
    Support for Cross Domain References

    		NoVSS tree has one dimension only. One could have multiple trees, but (currently) each tree would continue to be an independent domain.Yes
    Support for the Specification of Capabilities

    		NoVSS focuses on the data structure (e.g., datatypes, units, etc.) But, no possible interactions with the specified data are formally described (e.g., Concept Seat is modeled but not the possible operations on that property).YesThere is the concept of Actuators and Sensors.  Actuators do something when set.
    Community and Tools
    • Must scale across Automotive and adjacent industries
    • Cost
    • Ease of Adoption
    • Ease of Contribution

    		NoLimited to COVESA community and the vss-tools (mainly exporters). Any change in the modeling language requires rework of the tools.Yes
    Support for Automated Reasoning

    		NoNo mechanism for semantic correctness and consistency. (e.g., what distinguishes a Car from a Motorcycle? etc.)Partly






















    Proposed Solutions

    Solution NameDescriptionLinksNotes
    Vehicle Signal SpecificationThe overall goal of the Vehicle Signal Specification (VSS) is to create a common understanding of vehicle signals in order to reach a “common language” independent of the protocol or serialisation format.

    GitHub Repository:  https://github.com/COVESA/vehicle_signal_specification


    Documentation:  https://covesa.github.io/vehicle_signal_specification/


    GraphQLGraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

    https://graphql.org/




    OMG IDLOMG IDL is a descriptive language used to define data types and interfaces in a way that is independent of the programming language or operating system/processor platform. The IDL specifies only the syntax used to define the data types and interfaces. It is normally used in connection with other specifications that further define how these types/interfaces are utilized in specific contexts and platforms.

    https://www.omg.org/spec/IDL/4.2/About-IDL

    https://www.dds-foundation.org/omg-dds-standard/

    https://marketplace.visualstudio.com/items?itemName=RTI.omg-idl

    https://github.com/eProsima/Fast-DDS-Gen


    ...