Orbit Data Messages

Conformance Statement for pkg/odm, CCSDS 502.0-B-3

CCSDS 502.0-B-3 annex A ships an Implementation Conformance Statement proforma. This fills in all four requirements lists: the Orbit Parameter Message of A2.5.1, the Orbit Mean Elements Message of A2.5.2, the Orbit Ephemeris Message of A2.5.3 and the Orbit Comprehensive Message of A2.5.4.

A2.1 IDENTIFICATION OF ICS

A2.2 IDENTIFICATION OF IMPLEMENTATION UNDER TEST

A2.3 IDENTIFICATION OF SUPPLIER

A2.4 DOCUMENT VERSIONS

A2.5 XML FORM

A2.5.1 Orbit Parameter Message Requirements List

Status is the standard's own: M mandatory, O optional, C conditional.

A2.5.2 Orbit Mean Elements Message Requirements List

The three paired slots of table 4-3 are the part of this list worth reading. Each accepts two keyword names, which name applies is decided by MEAN_ELEMENT_THEORY, and the two halves carry different units.

The four conventions clause 4.2.4.6 fixes for a TLE-based OMM — EARTH, TEME, UTC and MEAN_MOTION — are enforced, and clause 4.2.4.9's converse rule that TEME may be used for nothing else is enforced too.

A2.5.3 Orbit Ephemeris Message Requirements List

A2.5.4 Orbit Comprehensive Message Requirements List

The OCM's eight sections hold something over two hundred keywords, so this lists them by section rather than one row apiece. The full tables are in pkg/odm/ocm_keywords.go, in the order the Blue Book prints them, which is also the order clause 6.2.2.1 requires them to arrive in.

A2.6 EXCEPTIONS AND UNSUPPORTED FEATURES

Both notations are implemented for all four messages: the key-value form of section 7 and the XML form of section 8, with the structure of CCSDS 505.0-B-3. Clause 1.1 leaves the choice to the exchanging parties, so both are needed.

An OCM row's width is not checked, except for a manoeuvre. A trajectory row's columns come from TRAJ_TYPE and a covariance row's from COV_TYPE, and clauses 6.2.5.11 and 6.2.7.12.1 draw both from the SANA registry rather than from the Blue Book. Nothing here says how many numbers a CARTPV row holds, so the rows are carried as text fields and the caller reads the columns. The exception is MAN_COMPOSITION, whose field names are printed in tables 6-8 and 6-9: those are checked, and a manoeuvre row whose width disagrees with its composition is refused.

The Blue Book's own figure G-15 shows why this cannot be tightened. It leaves TRAJ_TYPE out, so the default CARTPV applies, and then prints rows of nine values — a position, a velocity and an acceleration, which is CARTPVA. A reader that trusted the registry would have to refuse a published example.

The LTMWCC and UTMWCC covariance matrices are not made symmetric. Clauses 6.2.7.12.3.4 and 6.2.7.12.3.5 put correlations rather than covariances in one triangle of each, so the matrix is not symmetric. CovMatrix returns those two as they were written. Mirroring them the way an LTM is mirrored would silently scale half the entries by the product of two standard deviations.

An OCM's keywords are not typed. Its sections are held as ordered keyword lists with typed accessors for the keywords that change how the data must be read. There are over two hundred keywords, most optional and most drawn from the SANA registry, so there is nothing to parse a value into and no way for a caller to see an unfamiliar keyword if it were dropped. Get reaches anything; the values are carried as text.

Interpolation is not performed. INTERPOLATION and INTERPOLATION_DEGREE are read, preserved and reported, and nothing here acts on them. Interpolating an ephemeris is orbital mechanics, and clause 5.2.4.6 attaches a rule to it this package cannot enforce on a caller's behalf: a consumer must not interpolate across a metadata group boundary. OEM.Blocks keeps the groups separate so that a caller can respect that; whether it does is the caller's business.

The useable span is not applied. USEABLE_START_TIME and USEABLE_STOP_TIME are read and preserved. Records outside them are not dropped, because table 5-3 makes those bounds advice to the consumer about where a producer padded the data with fictitious interpolation nodes, and silently discarding records would change what the file says.

Enumerated values are not enforced. Clauses 3.2.3.2, 3.2.3.3 and 3.2.4.11 list the expected values for TIME_SYSTEM, REF_FRAME and the manoeuvre and covariance frames, and each says values outside the set "should be documented in an ICD". Refusing them would refuse conforming messages, so an unrecognised value is carried through unchanged and the caller decides.

Registry values are not checked. ORIGINATOR, OBJECT_NAME, OBJECT_ID and CENTER_NAME point at the SANA registries and the UN Office of Outer Space Affairs designator index. Checking them would mean shipping a copy of a registry that changes without this package, and the tables recommend rather than require those sources.

The TLE derivative scaling is not applied. Note 2 under clause 4.2.4.7 says that if MEAN_MOTION_DOT and MEAN_MOTION_DDOT came from a TLE, or are intended to be used as one, they must be divided by 2 and 6 respectively to match the SGP Taylor series terms. Nothing in a message records whether that has been done, so this package carries the values as written and leaves the question to the interface control document.

Nothing is validated against physics. Clause 1.2 puts orbit accuracy outside the standard. A message whose eccentricity exceeds one, or whose position is inside the central body, is structurally valid and is read without complaint.

Clause 7.5.7(b) is not enforced on read. The sub-clause requires a floating-point mantissa to carry its decimal point in the second position, so 1.5E+03 conforms and 15.0E+02 does not. Real messages break this constantly. Reading is lenient; writing produces the conforming form.

Re-encoding does not reproduce the input octets. Clause 7.5.6 makes trailing zeroes optional and clauses 7.4.5 to 7.4.7 make the surrounding white space insignificant, so one message has many spellings. Values round-trip; spelling does not.

A2.7 IMPLEMENTATION LIMITS

Wire test vectors

The files backing this statement live in the vector corpus — 11 decode vectors and 11 corpus files.

Both are published text rather than derived values: annex G of the Blue Book prints them, so a second working group wrote them.

The vectors assert the text and integer content — version, originator, object identifiers, frames, epoch, and the counts. For the OEM and the OCM the counts carry most of the weight: how many metadata groups, how many records, whether a record has acceleration, and how many covariance matrices are what a consumer must read correctly before any single number matters. The same goes for an OCM, whose section shape is what says how to read its rows at all, and whose vectors also assert the defaults clause 6.2.1.3 lets a producer leave out. The numeric state vector is not asserted there, because a vector field has no float accessor and pinning floats as formatted strings would test this package's number formatting rather than the standard. Those values are checked in pkg/odm against the same published text.

See CONTRACT.md for how to consume these, and how this is verified for what rests on a published vector versus a reading of the clause.