Mapping Vehicle Signal Specification (VSS) onto Message Queuing 
Telemetry Transport (MQTT)

Signals and Topics
VSS signals are described in a hierarchical tree-formed graph.  The format does not strictly require a single root node but the standard catalog of VSS signals has only one.  We refer to the terms nodes, branches (intermediate items) and leaf nodes.   In addition, sub-types such as sensor, attribute and actuator can specify the type of leaf node.

In MQTT, each data item is called a Topic.  These are similarly hierarchical and described with a path using "slash" / as separator.   The topic mapping is therefore trivial and is best shown with an example:

Example, VSS signal:

      Vehicle.Powertrain.Electric.Battery.AccumulatedConsumedEnergy 

should be mapped to MQTT topics using the complete and analogous form:

     /Vehicle/Powertrain/Electric/Battery/AccumulatedConsumedEnergy

This allows the normal MQTT features to be used with full flexibility, such as for example subscriptions using wildcards:   /Vehicle/Powertrain/Electric/*

Notice:

MQTT topics have no formal type definitions and leaf nodes can therefore not be formally sub-typed as sensor, attribute or actuator.  The node types are likely to primarily be handled by convention, i.e. by each actor just being aware of the actual type of the item as specified by VSS.   However, the ability for actors to read/write signals is of course controlled by a policy also in MQTT.  Even if there is no formal typing controlling it, we could envision generating some policies to control the desired behavior, from the node-type information given in the VSS.  See Access control chapter for details.

Value transfer – payload
MQTT is a generically useful framework that covers the concept of generic topics, the message formats (header, not payload) and all the rules for keeping track of actors, publishing [Comment by Klotz, Benjamin, Dr. (CQDS) (KBD(), 2020-07-06: Publishing?] [Comment by Unknown Author, 2020-07-06: Reply to Klotz, Benjamin, Dr. (CQDS) (07/06/2020, 09:28): "..." OK.]data (writers) and subscribing to data (readers) and the broker function that implements all of it.  For example, the broker distributes information among actors, so that a single value update is duplicated into an update message to every one of the relevant subscribers.   In addition to topics, updates, and subscriptions MQTT adds a details around tracking if nodes are active or offline, and the last-will function that defines what shall happen if a data source goes offline.
MQTT is made to be generically applicable and particularly therefore it does not specify the payload data format, so that it can be used in a lot of different contexts.   Defining the payload is however required to make a data protocol for a particular application (in this case the transfer of VSS signal updates) “complete” in the sense that consumers of data can understand the data that is being transferred.    [Comment by Klotz, Benjamin, Dr. (CQDS) (KBD(), 2020-07-06: I am not sure that I understand fully the meaning of “complete data protocol”. Is it a protocol that provides metadata? Some context like the time of transfer? Context about the application?] [Comment by Unknown Author, 2020-07-06: Reply to Klotz, Benjamin, Dr. (CQDS) (07/06/2020, 09:30): "..." I meant only what I wrote it in the sentence: “consumers of the data can understand the data that is being transferred”. Without agreeing on the payload format, this is not possible. (No, I did not imply a self-describing protocol or data format, not necessarily)]In comparison, the W3C VISS and “Gen2” REST protocol already specify not only the way that actors interact but also the exact JSON-document format that is required to be used when describing the values of measured VSS signals.
Therefore, for any case where MQTT is to be deployed, it is required that we specify the Value Transfer format that makes up the payload of topic update messages.  A formal specification of VSS on MQTT would take over to define the payload format in detail and it should not be presupposed at this time until we get a clear picture of what is desired in a certain environment because the best choice depends a lot on the intended usage:
In some environments using a highly-efficient binary payload makes sense. [Comment by Klotz, Benjamin, Dr. (CQDS) (KBD(), 2020-07-06: Note that MQTT is per default unencrypted in its highly-efficient configuration with binary payload, and that it is used with TLS/SSL when security is needed]
In others, a JSON based payload is a more reasonable choice.   The latter could be applicable for example:
 •	If web-programs are expected to consume the data, because JSON often being the fastest way to consume data in this case)
 •	If direct compatibility with W3C VISS or “Gen2” REST protocols is desired, possibly completely avoiding a translation step for the data payload.
Access control [Comment by Klotz, Benjamin, Dr. (CQDS) (KBD(), 2020-07-06: I think it would make sense to include the topic of resource discovery. As far as I understood the spec, there is no discovery mechanism. For instance, if I am looking for a specific sensor signal in the Vehicle.Powertrain.Electric.Battery branch, I can use a wildcard to get all of them but not a list of children topics. This is particularly relevant with the use of identifiers] [Comment by Unknown Author, 2020-07-06: Reply to Klotz, Benjamin, Dr. (CQDS) (07/06/2020, 09:36): "..." Which spec? MQTT spec?I think that’s right – I believe that for MQTT it is basically assumed that all actors have agreed beforehand on the topic hierarchy. That is not so different from VSS, in my opinion. Discovery may be seen as less of a concern in MQTT because in some sense you don’t care which service publishes data, if you are a subscriber. It is probably just assumed that if you subscribe to a topic you get the right values for that topic, no matter who provided them. In an alternative view, the “broker” is the only service you need to care about – at least seen from the view of the subscribers? On the other hand, you can of course build your own service discovery on top – e.g. request the value of /system/service/list or something, and some agreed information will be delivered.Service providers could announce themselves on some predefined topic while a service registry listens to that. The service registry could provide info about what each service does, let’s say: /registry/services/ID/topics = returns all topics that the service named “ID” handles. Anything possible really, but if not built into the core MQTT then it needs to be built on top.] [Comment by Klotz, Benjamin, Dr. (CQDS) (KBD(), 2020-07-06: The general mapping is trivial for a single vehicle, but MQTT is more adapted to many-to-many communication situations, in that case with large fleets. I think it would be relevant to include an example of what it would look like, especially at the level of the broker. In some best practices it is suggested to embed unique identifiers into the topic and at the same time remain extendable in topic building (which is the case of VSS). A solution could be to use topics like “VehicleID/Powertrain/…” or “Vehicle/ID/Powertrain/…”] [Comment by Unknown Author, 2020-07-06: Reply to Klotz, Benjamin, Dr. (CQDS) (07/06/2020, 09:41): "..." Yes, an identification of the vehicle could be worth adding.]
MQTT enables configuration of which nodes are allowed to update certain topic values.  
Not only could this be used to globally make some signals readable by all actors except the publishing actor (for a leaf of type signal), permanently only readable constant values (leaf of type attribute), or writable by multiple “consumers” (actuator).
In addition to using access control to enforce the globally expected behavior of such VSS node types, it is of course possible and desirable to implement policies that limit access to data to only the consumers that are authorized for each data item.  
The details of how to write such access control policies are left out of scope for this document, for now.  Refer to MQTT documentation for details.

Gunnar Andersson
Technical Lead, GENIVI Alliance