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:

   /VSS/Vehicle/Powertrain/Electric/Battery/AccumulatedConsumedEnergy

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

Since the broker-based model of MQTT is set up to handle many devices at once, it is appropriate to connect several data sources (e.g. individual vehicles) to one broker instance.  Scaling limitations, and fault-tolerance, might  of course make it undesirable to connect all vehicles to one broker instance, but at least it seems appropriate to create appropriately sized groups/clusters of vehicles that connect to each MQTT broker instance.  With that in mind, the vehicle identity is required to distinguish between the data sources.   The topic tree should then be something like:

   /VSS/<VehicleID>/Powertrain/Electric/Battery/AccumulatedConsumedEnergy

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 readability/writability 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 data (writers) and subscribing to data (readers) and the broker function that implements all of it.  For example, the broker distributes information among actors, such that a single value update being duplicating 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 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 protocol definition 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.    In comparison, the W3C VISS and “Gen2” REST protocol already specifies 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.  In others, a JSON based payload is a more reasonable choice.   
JSON 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.
It seems likely that if the above points are not applicable, then a more optimized binary format is going to be appropriate.  An existing binary encoding standards such as that from protobuf or other similar choice ought to be reused.
Access control
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.  Some useful references exist: [1], [2].

Gunnar Andersson
Technical Lead, GENIVI Alliance

References
[1] https://internetofthingsagenda.techtarget.com/definition/MQTT-MQ-Telemetry-Transport
[2] https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices