VSS or HIM?

[doganulus]

When I read the description and goal of the VSS project,

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

I have the following question: Should we understand the common language as a concrete set of signal names used collectively for their systems? Or current specifications in the repo are a proof-of-concept of the more general mechanism?

If we are more interested in the mechanism and semantics, should we go deeper with the HIM project rather than VSS?

[erikbosch]

I would say that VSS as of today consist of three parts:

• Semantics of how to define signals in "vspec-format",as defined in the documentation in this repo and visible in generated form [here]https://covesa.github.io/vehicle_signal_specification/).
• The catalog of pre-defined signals like Vehicle.Speed that exist in this repository.
• The tooling in vss-tools that implicitly defines how VSS-signals shall or can be represented in other formats

I think the phrase on "common language" in the README of this repository is quite old, but in my view it covers at least the two first points above. An App developer should be able to say that he needs Vehicle.Speed for his app and others should then know what is needed. That does not mean that all vehicles or systems must have Vehicle.Speed. There have been discussion on making some signals mandatory or recommended but no alignment on that yet.

HIM as of today intends to take a broader scope than VSS. The HIM syntax/semantics for resource data practically reuse the VSS syntax/semantics, but in addition to that it also intends to specify syntax/semantics for services. As of now the HIM documentation/specification of syntax/semantics is practically a copy of corresponding VSS documentation. In the long term my view is that one of them shall be the "master", but it does not change much from a practical perspective.

[doganulus]

Thank you @erikbosch. Now, I see the scope better.

I also feel mandatory names would be too restrictive with all the different organizations, programming languages, and their naming styles in existence. It may be better to separate a signal/attribute name from its specification for that. I think the project will need a mechanism for reusable specifications as well.

Briefly, we would be interested in discussing various language constructs over the course. :)

[UlfBj]

One of the goals of HIM is to separate the syntax/semantics of how to define signals in VSS from the catalog of pre-defined signals.
So the VSS rule set should be identical to the corresponding rule set in HIM.
Long term my view is that the VSS project refers to HIM regarding the rule set for its signal catalog. The governance of HIM would then also ideally be driven by the VSS community.
HIM does not only provide this separation of concerns, but it also provides syntax/semantics rule sets for services, and for how a server manages a set of trees.
The idea is that new (or existing) open source projects will use HIM to define signal or service catalogs that are fit for their needs (domains). Using the same rule set will make interoperability easier.

[doganulus]

It may be nice to make a comparative analysis between HIM's objectives and JSON Schema's existing feature set. I expect a considerable overlap, but I think an automotive or publisher-subscriber network focus would differentiate.

Are there more specific requirements for automotive applications, or can HIM directly target signals in any pub-sub network?

[UlfBj]

Are there more specific requirements for automotive applications, or can HIM directly target signals in any pub-sub network?

HIM is equivalent to the VSS rule set when it comes to signals. It should be possible to use in any pub-sub network.
However, it does not contain a specification of an pub-sub protocol.