Support of variables in signal descriptions.

[erikbosch]

Background

We try as much as possible to reuse signals for recurring purposes like IsOpen and Position. That works quite well with the #include concept, but as of today that means that descriptions becomes very generic as they are reused as well. I.e. just reading description does not give the full meaning of the signal, you must consider the path name.

Potential Solution

Support for variables in description in *.vspec, and let tooling replace them during expansion. Some possible alternatives could include

• $path to include full path
• $instance to include instance information for nearest parent with instances (like Row1.Left)
• $branch to include name of closest branch (not instance)

That way a reusable signal description for Position could be something like:

description: Position of $branch $instance. 100 = fully open

and be expanded to something like:

description: Position of Door Row1.PassengerSide. 100 = fully open

Do you think something like this would be a usable feature?

[adobekan]

@jdacoello How do you handle this concept in the ontology project?

[jdacoello]

Your question resulted in another question from my side: what is the ideal representation for both the specification and the parsed?

I will give my opinion below:

VSS

The problem arises from the fact that the fields type, datatype, description, etc. are assigned to individual instances instead of grouping them into an abstract concept and then mentioning that any instance will have that description. What I mean is that in VSS there is no clear definition of a common class. We currently use parent branches for implying the membership of some data points. For example: in Door.Row1.PassengerSide.IsOpen you imply that IsOpen belongs to an instance of a Door identified as Row1.Passenger. However after parsing, you end up with something like:

Door.Row1.PassengerSide.IsOpen
  type: sensor
  datatype: boolean
  description:
  etc.

Door.Row2.PassengerSide.IsOpen
  type: sensor
  datatype: boolean
  description:
  etc.

Door.Row3.PassengerSide.IsOpen
  type: sensor
  datatype: boolean
  description:
  etc.

Door.RowN.PassengerSide.IsOpen
  type: sensor
  datatype: boolean
  description:
  etc.

In other words, you have atomised definitions of IsOpen, one for each instance. However, it would be cleaner to have something like:

# In the Door definition
Door.IsOpen
  type: sensor
  datatype: boolean
  description:
  etc.

# Instances of Door
Door{Row1.PassengerSide}
  instanceOf: Door
Door{Row1.DriverSide}
etc.

Ontology

In the ontology, you define the Class Door only once, together with all its possible properties (aka., attributes, characteristics, signals, sensors, actuators, etc). For example: A generic definition of a Door in VSS might contain the properties:

• IsOpen
• IsLocked
• etc.

Then, you can instantiate the class Door when you need that concept. For example: MyDoorInstance - type -> Door.

One suggestion from my side would be to change the syntax used for the separators before and after the name of an instance. For example, instead of using a dot . as now, we could use ( ) or { } to make the instance name explicit.

NOW

Door.Row1.PassengerSide.IsOpen
Door.Row1.PassengerSide.IsLocked
Door.Row1.DriverSide.IsOpen
Door.Row1.DriverSide.IsLocked

SUGGESTION

Door(Row1-PassengerSide).IsOpen
Door(Row1-PassengerSide).IsLocked
Door(Row1-DriverSide).IsOpen
Door(Row1-DriverSide).IsLocked

In this way, it would be much easier for the tooling to handle the instances at different stages, even after parsing the specification into a particular format.