C2MS13 — Consolidate Navigation Data Messages

The various Navigation Data Messages are nearly identical. They should be consolidated into a hierarchy that defines a Navigation Data Message base class and then let the others derive from it for better model structure. The Tracking Data Message has a few extra fields. Otherwise, everything is identical across all messages except for some type values.

I thought about doing this when I was updating the model in 1.1, but would have also had to update the chapter text and didn't have time for all that in 1.1.

From C2MS13-33, which was a DUP of this one: "Similar to C2MS12-118, it would be nice to create a model hierarchy for the TDM messages. They are almost all nearly identical, so inheritance would be nice. Of course, this can't break the CONTENT in the tables, but can greatly improve the diagrams."

See C2MS12-177, which defined new common types (Request, Response, and Notification) and had all messages subclass these, for an example of how this should be done.

One note that may make it not possible??? is that some NDMs have DATA as a Binary, others have it as a String. So if we are going to have one superclass, we need to decide which is right or move that DATA field down into each one, which is a bit annoying.

From Discussion in Reston 2026:
The RTF suggested deprecating OBJECT-NAME and OBJECT ID across all NDMs, because we already have SATID.

Add "Other-Participants" to the TDM with OBJECT-NAME and OBJECT-ID to capture the idea of Participants from CCSDS. Participants are the components such as the satellite and other assets (antennas, ground stations, other satellites or any other observing platform that was used in calculating the TDM. In C2MS, the SATID is the satellite and the OTHERS (antennas, grounds stations, etc) are those that were used in calculating the TDM, so need to explicity describe that. Should also note in the documentation that While we just have a SATID, for Other Participatns we have both an ID and a Name (both optional) because we don't know any other information about it, while a SATID should be well known to a C2 System.

One note... in 6.4.1 Identifying C2MS message types either we need to expand this text or put further explanation in the chapter on NDMs because that descriptions is incomplete for NDMs that also must look at NDM-TYPE/SUBTYPE.