OARIS11 — Sensor track does not identify the sensor

A sensor track should carry the identity of the sensor it originates from. Forcing out of band mechanisms (e.g. partition names in the DDS PSM) to be used adds to the complexity of solutions, especially for use cases such as logging where we don't neecssarily care where it came from as long as we know. A compound key would allow all present use cases of filtering etc to be supported.
The situation is particularly confusing for bearing tracks, where the standard apparently requires us to define a bearing with no means of defining the origin.

Add subsystem id attribute to DDS PSM Topic types

Making the source (or destination) of the data explicit in the application payload for DDS makes sense, does not put an unreasonable burden on implementations, can be done with minimal change to existing implementations and is clearly beneficial for the purposes of recording and analysis.
OARIS v1.0 continued to define subsystem_id_type (unsigned short) in package Common_Types, although it is unused by the specification. Its semantics remain applicable for this change proposal.
All DDS Topic types should have a key attribute subsystem_id of subsystem_id_type added. The Subsystem sets it to zero in the receive_sub_identification_data topic and is allocated a value to use in the receive_cms_identification_data response. Note that to disambiguate the multiple subsystems case, the CMS response must be published in a subsystem specific partition.
However, the use of partitions is useful for filtering at a data reader and provides a more robust mechanism for ensuring data is from the subsystem that it labelled as belonging to. Therefore, the partition convention employed in some existing implementations should be formalised within the (new) DDS PSM section.