TM Space Data Link (ECSS)

Conformance Statement for pkg/tmdl, ECSS-E-ST-50-03C

A1 GENERAL INFORMATION

A1.1 Identification

A1.2 Identification of Implementation Under Test

A1.3 Identification of Supplier

A1.4 Identification of Specification

A note on the version. Plan 024 called for "ECSS-E-ST-50-03C Rev.1". No such revision is published: the active document on ecss.nl is ECSS-E-ST-50-03C dated 31 July 2008, whose own change log records the 2008 issue as editorial renumbering of the 6 November 2007 text. This audit is against that document.

A2 REQUIREMENTS MATRIX

Every numbered clause of the normative sections (clause 5.1 to clause 5.6) appears below, one row each. Section 4 is the informative overview and contains no numbered requirements.

Inventory total: 135 clauses. Matrix rows: 135.

Verdicts use four values:

Requirement text is paraphrased. ECSS documents are copyrighted; clause identifiers plus a paraphrase are enough to find the original.

5.1 General

5.2 Transfer Frame Primary Header

5.3 Transfer Frame Secondary Header

5.4 Transfer Frame Data Field

5.5 Operational Control Field

5.6 Frame Error Control Field

A3 GAPS, ALL CLOSED

The audit of 23/08/2026 found five gaps, fixed the same day in fix(tmdl): correct four ECSS-E-ST-50-03C conformance defects. A second pass on 25/08/2026 found that the first pass had itself overstated two rows, and the underlying defect was fixed then. This section records all of them, since the reasoning is worth keeping and several describe a failure mode this codebase has now hit repeatedly.

5.4.3.3b / 5.4.3.4g, raw 0xFF fill sold as "idle packets" (second pass)

The first pass marked both rows conforms with padDataField's raw 0xFF fill as evidence. That was wrong twice over: 0xFF fill is not an idle packet, and a conformant receiver parses the fill as a packet header (0x7FF in the first two octets reads as the idle APID, but the length field is garbage) and loses packet sync. The in-repo receiver survived only through a nonstandard all-0xFF heuristic no other implementation shares.

Now: Flush fills spare data field space with a real SPP idle packet (APID 0x7FF) built by idleFillPacket, spanning into following frames when the spare space is under the seven-octet minimum packet size, and Receive discards extracted idle packets by APID per 5.4.3.5d. The raw-0xFF heuristic remains only as decode-side leniency for streams from older versions of this package.

Alongside that fix, three rows the first pass graded conforms were re-graded configurable, because the property holds only under caller wiring: 5.2.5c and 5.2.6c (counts are sequential only when one shared FrameCounter feeds every service and the idle-frame path) and 5.1c (length constancy holds only under a set FrameLength, which the codec now enforces on encode and decode).

5.3.2.3c. The secondary header length field was one too small

Clause 5.3.2.3c requires the six-bit field to hold the total secondary header length in octets minus one, the total being the identification octet plus the data field. So for an N-octet data field the field reads N.

The code required it to equal len(DataField)-1 and decoded with the same offset. A four-octet header went out saying 2 where the standard wants 3.

Encoder and decoder agreed, so every round trip passed and the package's own tests were silent, one of them asserted the wrong value outright, which is how the defect looked deliberate. A conforming receiver reading 2 computes a three-octet total and starts the Transfer Frame Data Field an octet early, corrupting every frame with a secondary header.

The same wording is in CCSDS 132.0-B-3 clause 4.1.3.2.2.3, so this was never an ECSS-only defect.

Now: the field equals the data field length, SetDataField derives it, and the test asserts the octet on the wire plus the offset a receiver would compute from it.

5.3.4.2a, the extended virtual channel frame count inherited it

Clause 5.3.4.2a fixes the secondary header at 32 bits when it carries the extended count: four octets, so the field must read 3. Closed by the fix above.

5.2.7.6g, idle frames used the wrong First Header Pointer

Clause 5.2.7.6 gives two codes to two conditions: 11111111111 (0x7FF) when no packet starts in the data field, 11111111110 (0x7FE) when the field holds only idle data. NewIdleFrame filled with idle and then set 0x7FF, and IsIdleFrame matched on 0x7FF, so OID frames were mislabelled and conformant ones from other senders went unrecognised.

Fixing this exposed a second defect the audit had not found: the packet service had the two codes swapped on both paths at once. It discarded continuation frames as idle (losing payload) and appended idle fill into the reassembly buffer. Consistent on both sides, so round trips passed here too.

Now: both codes are named constants, FHPNoPacketStart and FHPOnlyIdleData, and the service uses each for its own condition.

5.3.1c. The secondary header could exceed 64 octets

Clause 5.3.1c caps the whole secondary header at 64 octets. A 63-value length field with a 64-octet data field encoded to 65, and nothing rejected it.

Now: MaxSecondaryHeaderSize is enforced by Validate.

5.6.1c. The Frame Error Control Field could not be omitted

Clause 5.6.1b makes the field mandatory when the frame is not Reed-Solomon encoded, and its NOTE makes it optional inside a code block, which already protects the frame. Clause 5.6.1c requires the choice to hold across the physical channel.

Only "always present" was supported: Encode always appended the field, DecodeTMTransferFrame always verified it, and ChannelConfig.HasFEC was never consulted by the frame codec. A Reed-Solomon mission omitting the field ( a normal configuration) could not use the package.

Now: EncodeWithConfig and DecodeTMTransferFrameWithConfig honour HasFEC. The original entry points keep the field, so existing callers are unaffected, and VirtualChannelFrameService.SetChannelConfig carries the choice through the pass-through path.

And one that was recorded as configurable

Clause 5.1b caps the frame at 2048 octets and nothing enforced it. It is still configurable rather than a gap (the caller sets FrameLength, and a CCSDS-only mission may legitimately exceed the European ceiling) but ChannelConfig.Validate now checks it for missions that care.

A4 SUMMARY

Inventory total 135, matrix rows 135. The two numbers are stated here so the check is self-contained.

Reading the result

pkg/tmdl conforms to the European TM transfer frame profile. Every mandatory clause is either satisfied outright or satisfiable by configuration, and the rows that say configurable name the configuration.

The five gaps the first pass of this audit found were all closed on the same day, and the idle-packet fill defect the second pass found was closed on 25/08/2026. Three of them had been putting wrong bytes on the wire, and all were the kind that hide: the secondary header length was self-consistent within the library, the idle-frame pointer sat in a field most tests do not assert, and the raw fill was survivable only by this package's own receiver. Fixing the pointer exposed a further defect of the same shape in the packet service.

That is the pattern worth carrying forward. Three separate defects in this codebase (the PN randomizer, this length field, and the swapped pointer codes ) were each perfectly symmetric and perfectly wrong. A round trip cannot catch any of them. Assert the octet.

On the 24% "configurable" share

Plan 024 set a threshold: if configurable rows exceed 20% of the matrix, the audit is a hedge and should be reported rather than shipped. This matrix is at 24%, so the threshold is crossed and the reasoning belongs here rather than buried.

The threshold guards against guessing. These rows are not guesses. They fall into three groups, and every one names its exact configuration:

• Operational constancy (14 rows). Clauses of the form "shall be static in the associated master channel throughout a mission phase", 5.2.2.3d, 5.2.4d, 5.2.7.2d, 5.2.7.2e, 5.2.7.3d, 5.3.1d, 5.3.1e, 5.3.2.3d, 5.3.4.2d, 5.3.4.2e and their neighbours. A stateless frame codec cannot be static across a mission phase; only the system operating it can. Marking these "conforms" would be the dishonest answer.
• Opaque fields the caller fills (9 rows). The Operational Control Field is four octets pkg/tmdl carries without interpreting (frame.go TMTransferFrame.OperationalControl), so the Type Flag clauses 5.5.1e through 5.5.4b are satisfied by whatever the caller puts there. The CLCW content itself belongs to pkg/cop.
• Caller-supplied values and policies (10 rows). The 2048-octet frame limit (5.1b), frame-length constancy (5.1c), the shared frame counters (5.2.5c, 5.2.6c), playback handling (5.4.4.2), and the extended count's placement in the secondary header data.

None of these needed mission context I did not have. Had any been genuinely ambiguous it would appear as a gap with the ambiguity stated, not as a hedge.

Coverage boundary

Seven clauses are out-of-scope, and all seven point somewhere real:

None was silently dropped.

A5 METHOD

• The standard was read in full; every numbered clause under clause 5 was extracted mechanically, giving 135. Section 4 is informative and contributes none.
• Each clause was mapped by reading frame.go, service.go, channel.go, physical.go and errors.go. Every verdict but out-of-scope carries a pkg/tmdl file and symbol; the first pass cited line numbers, which drifted within a day of the audit, so the second pass replaced them with symbols.
• Four clauses were checked by building frames in a temporary probe rather than by reading: 5.3.2.3c, 5.3.1c, 5.2.7.6g and 5.1b. All four findings above come from what the probe actually produced. The probe was deleted; this audit changed no code.
• Evidence is as of the working tree on 25/08/2026, which carries the uncommitted idle-packet fill, counter-threading, and frame-length enforcement changes.