Astro~/0.3
** Conformance / Packet Utilization Standard * PAGE 22 / 23
** Astro * Conformance
** /conformance/pus

Packet Utilization Standard

PICS proforma: what this package implements, clause by clause.

Conformance Statement for pkg/pus, ECSS-E-ST-70-41C


A1.1 GENERAL INFORMATION

A1.1.1 Identification of PICS

FieldValue
Date of Statement (DD/MM/YYYY)23/08/2026
PICS Serial NumberASTRO-PUS-PICS-001
System Conformance Statement Cross-ReferenceThis document

A1.1.2 Identification of Implementation Under Test (IUT)

FieldValue
Implementation Nameastro/pkg/pus
Implementation VersionSee go.mod / latest commit on main
Special ConfigurationEvery codec is parameterized by an explicit MissionProfile; there is no package-level default
Other InformationGo library implementing PUS-C secondary headers and seven services. The TC and TM secondary headers implement spp.SecondaryHeader, so they compose with pkg/spp without changes to either package. The TM absolute time field encodes via pkg/tcf CUC.

A1.1.3 Identification of Supplier

FieldValue
SupplierRavi Suhag
Contact Point for QueriesGitHub, github.com/ravisuhag/astro
Implementation Name(s) and Version(s)astro/pkg/pus (Go package)
System Name(s)Astro

A1.1.4 Identification of Specification

FieldValue
SpecificationECSS-E-ST-70-41C (Telemetry and telecommand packet utilization, 15 April 2016)
Have any exceptions been required?Yes [X] No [ ], see A1.5

A1.2 PACKET STRUCTURE

FeatureReferenceStatusSupport
TM packet secondary header7.4.3.1, Figure 7-7MY
TM PUS version number = 27.4.3.1cMY: other versions rejected on decode
Spacecraft time reference status7.4.3.1d, 7.4.3.1eMY: 4 bits, zero when unsupported
TM message type ID7.4.3.1fMY: service and subtype, 8 bits each
TM message type counter7.4.3.1g, 7.4.3.1hMY: 16 bits, fixed by Figure 7-7
TM destination ID7.4.3.1iMY: 16 bits, fixed by Figure 7-7
TM time field7.4.3.1j, 7.4.3.1kMY: CUC, implicit or explicit P-field, or raw
TM spare field7.4.3.1lOY: presence and width declared by the profile
TC packet secondary header7.4.4.1, Figure 7-9MY
TC PUS version number = 27.4.4.1cMY
TC acknowledgement flags7.4.4.1dMY: all four bits, positions as specified
TC message type ID7.4.4.1eMY
TC source ID7.4.4.1fMY: 16 bits, fixed by Figure 7-9
TC spare field7.4.4.1gOY: presence and width declared by the profile
Secondary header within the CCSDS 1-63 octet boundCCSDS 133.0-B-2MY: MissionProfile.Validate enforces it

A1.3 TIME FIELD ENCODING

FeatureReferenceStatusSupport
Absolute time is PTC 97.4.3.1j, Table 7-10MY
PFC 0, explicit format, including the P-fieldTable 7-10OY: TimeCUCExplicit
PFC 3 to 18, CUC, implicit P-fieldTable 7-10OY: TimeCUC, coarse 1-4 and fine 0-3 octets
PFC 19 to 46, CUC, wider fine timeTable 7-10ON: see A1.5
PFC 1, 2, CDS formatTable 7-10ON: see A1.5
CCSDS 1958 epoch7.4.3.1j note 1MY
Agency-defined epoch7.4.3.1j note 1OY: selects CUC time code Level 2

A1.4 SERVICES

ServiceReferenceStatusSupport
ST[01] request verification8.1MY: all nine report subtypes: TM[1,1] to TM[1,8] and TM[1,10]
TM[1,1] successful acceptance8.1.2.1MY
TM[1,2] failed acceptance8.1.2.2MY: with failure notice
TM[1,3] successful start8.1.2.3OY
TM[1,4] failed start8.1.2.4OY
TM[1,5] successful progress8.1.2.5OY: with step ID
TM[1,6] failed progress8.1.2.6OY: with step ID and failure notice
TM[1,7] successful completion8.1.2.7OY
TM[1,8] failed completion8.1.2.8OY
TM[1,10] failed routing8.1.2.10OY: request ID and failure notice
Request ID structureFigure 8-1MY: 32 bits, mirrors the CCSDS primary header
ST[03] housekeeping8.3OP: five message subtypes; see A1.5 for the full list of excluded ones
TC[3,1] create report structure8.3.2.1OY: including super-commutated groups
TC[3,3] delete report structures8.3.2.3OY
TC[3,5] enable periodic generation8.3.2.5OY
TC[3,6] disable periodic generation8.3.2.6OY
TM[3,25] housekeeping parameter report8.3.2.25OY: framing only; values supplied by the caller
ST[05] event reporting8.5OY: all eight message subtypes
TM[5,1] to TM[5,4] event reports8.5.2.1 to 8.5.2.4OY: all four severities
TC[5,5] enable event reporting8.5.2.5OY
TC[5,6] disable event reporting8.5.2.6OY
TC[5,7] report disabled events8.5.2.7OY: empty body
TM[5,8] disabled events list report8.5.2.8OY
ST[08] function management8.8OY: the one message type the service defines
TC[8,1] perform a function8.8.2.1OY: function ID, the optional argument group, and a caller-driven split of the argument block
ST[11] time-based scheduling8.11OY: all twenty-seven message types
TC[11,1] / TC[11,2] enable and disable schedule execution8.11.2.1, 8.11.2.2OY: empty bodies
TC[11,3] reset the schedule8.11.2.3OY: empty body
TC[11,4] insert activities8.11.2.4OY: one sub-schedule per request, then the activity list; each activity carries a whole TC packet
TC[11,5] delete by request identifier8.11.2.5OY
TC[11,6] delete by filter8.11.2.6OY: including the from-greater-than-to rejection of 6.11.10.3d
TC[11,7] time-shift by request identifier8.11.2.7OY: signed offset
TC[11,8] time-shift by filter8.11.2.8OY
TC[11,9] detail-report by request identifier8.11.2.9OY
TM[11,10] schedule detail report8.11.2.10OY: sub-schedule ID per activity, unlike the insert request
TC[11,11] detail-report by filter8.11.2.11OY
TC[11,12] summary-report by request identifier8.11.2.12OY
TM[11,13] schedule summary report8.11.2.13OY
TC[11,14] summary-report by filter8.11.2.14OY
TC[11,15] time-shift all8.11.2.15OY
TC[11,16] / TC[11,17] detail- and summary-report all8.11.2.16, 8.11.2.17OY: empty bodies
TC[11,18] report sub-schedule status8.11.2.18OY: empty body
TM[11,19] sub-schedule status report8.11.2.19OY
TC[11,20] / TC[11,21] enable and disable sub-schedules8.11.2.20, 8.11.2.21OY: including the N-of-zero-means-all rule of 8.11.2.20c and 8.11.2.21c
TC[11,22] create scheduling groups8.11.2.22OY
TC[11,23] to TC[11,25] delete, enable and disable groups8.11.2.23 to 8.11.2.25OY: including N of zero
TC[11,26] report group status8.11.2.26OY: empty body
TM[11,27] scheduling group status report8.11.2.27OY
Sub-schedule and group status enumerationsTables 8-3, 8-4OY: disabled 0, enabled 1
Time window type enumerationTable 8-5OY: all four, and a fifth value is rejected
Time window tag presence6.11.10.3cOY: the from tag for "from" and "from-to", the to tag for "to" and "from-to"
Relative time, PTC 107.3.11, Table 7-11OY: signed, two's complement over the whole field, PFC 3 to 18 widths
ST[12] on-board monitoring8.12OY: all twenty-eight message types
TC[12,1] / TC[12,2] enable and disable PMON definitions8.12.2.1, 8.12.2.2OY
TC[12,3] change the maximum transition reporting delay8.12.2.3OY
TC[12,4] delete all PMON definitions8.12.2.4OY: empty body
TC[12,5] add PMON definitions8.12.2.5OY: all three criteria shapes; needs a ParameterResolver
TC[12,6] delete PMON definitions8.12.2.6OY
TC[12,7] modify PMON definitions8.12.2.7OY: no validity condition and no interval, per 6.12.3.9.4; needs a resolver
TC[12,8] report PMON definitions8.12.2.8OY: including the N-of-zero-means-all rule of 8.12.2.8c
TM[12,9] PMON definition report8.12.2.9OY: leads with the transition delay when 6.12.3.8a applies; needs a resolver
TC[12,10] report the out-of-limits8.12.2.10OY: empty body
TM[12,11] out-of-limits report8.12.2.11OY: needs a resolver
TM[12,12] check transition report8.12.2.12OY: the expected-value mask travels only for expected-value checks, per Figure 8-128 note 1; needs a resolver
TC[12,13] report each PMON status8.12.2.13OY: empty body
TM[12,14] PMON status report8.12.2.14OY
TC[12,15] to TC[12,18] enable and disable the two functions8.12.2.15 to 8.12.2.18OY: empty bodies
TC[12,19] / TC[12,20] enable and disable FMON definitions8.12.2.19, 8.12.2.20OY
TC[12,21] / TC[12,22] protect and unprotect FMON definitions8.12.2.21, 8.12.2.22OY
TC[12,23] add FMON definitions8.12.2.23OY: with the nested PMON ID list; needs a resolver when 6.12.4.2.1c applies
TC[12,24] delete FMON definitions8.12.2.24OY
TC[12,25] report FMON definitions8.12.2.25OY: including N of zero, per 8.12.2.25c
TM[12,26] FMON definition report8.12.2.26OY: needs a resolver when 6.12.4.2.1c applies
TC[12,27] report each FMON status8.12.2.27OY: empty body
TM[12,28] FMON status report8.12.2.28OY
Check type enumerationTable 8-6OY: all three, and a fourth value is rejected
PMON checking status enumerationsTables 8-7, 8-8, 8-9OY: all three tables, and NameFor takes the check type because raw 3 means something different in each
PMON status enumerationTable 8-10OY
FMON protection, status and checking status enumerationsTables 8-11, 8-12, 8-13OY
ST[17] test8.17OY
TC[17,1] / TM[17,2] are-you-alive8.17.2.1, 8.17.2.2OY
TC[17,3] / TM[17,4] on-board connection8.17.2.3, 8.17.2.4OY: APID width declared by APIDBytes, two octets by default

Decoders enforce exact body lengths on fixed-size messages, in line with the PUS acceptance checks: octets beyond the structure a message type declares are rejected with ErrTrailingBytes, not ignored. Messages that end in a variable-length field the receiving end interprets (the ST[01] failure data, the ST[05] auxiliary data, the TM[3,25] parameter values) carry those trailing octets verbatim by design.


A1.5 EXCEPTIONS AND UNSUPPORTED FEATURES

FeatureReferenceSupportRationale
CDS time format, PFC 1 and 2Table 7-10Npkg/tcf implements CDS, but the PUS time field currently wires only CUC. A follow-up.
CUC fine time beyond 3 octets, PFC 19 to 46Table 7-10Npkg/tcf caps fine time at 3 octets.
No time field at all, TimeNone7.4.3.1jExtensionNot a Table 7-10 option: the standard makes the TM time field mandatory. TimeNone exists for ground tooling and tests; a flight profile declares a real format.
Housekeeping parameter sampling8.3N by designOnly the flight software knows what a parameter means. This package frames the values; the caller supplies them.
ST[03] diagnostic subtypes: TC[3,2], TC[3,4], TC[3,7], TC[3,8], TC[3,11], TM[3,12], TM[3,26], TC[3,28], TC[3,30], TC[3,32], TC[3,34], TM[3,36]8.3.2NThe diagnostic twin of every housekeeping message. Structurally identical to the housekeeping side; a mechanical follow-up.
ST[03] structure reporting: TC[3,9], TM[3,10]8.3.2.9, 8.3.2.10NReport-back of stored structure definitions. A follow-up.
ST[03] one-shot, append, and interval modification: TC[3,27], TC[3,29], TC[3,31]8.3.2NA follow-up.
ST[03] periodic generation properties: TC[3,33], TM[3,35]8.3.2NA follow-up.
ST[03] parameter functional reporting, subtypes [3,37] to [3,44]8.3.2NThe whole functional-reporting capability is excluded. A follow-up.
Packet error control field7.4.3.2d to f, 7.4.4.2dNChecksumming is declared per mission; pkg/spp offers the CRC-16 alternative via WithErrorControl. The ISO 16-bit checksum alternative the standard also allows is not implemented anywhere in this stack, so a mission declaring it cannot use these packages unmodified.
User data spare and padding word size7.4.3.2b, 7.4.4.2bNPadding of the user data field to the mission word size is left to the caller. For the secondary headers, a declared WordSizeBytes makes MissionProfile.Validate check word alignment; zero leaves it unchecked.
ST[02], ST[04], ST[06], ST[09], ST[13] to ST[16], ST[18] to ST[23]clauses 6 and 8NDeliberately out of scope for this first pass. Each is a follow-up.
ST[12] deduced field widths8.12.2.5 to 8.12.2.9, Figures 8-114 to 8-129Caller-suppliedThe limits, delta thresholds, expected values and masks are all typed "deduced", derived from the monitored parameter's own definition. That is mission configuration. Unlike ST[03]'s parameter values, these fields sit in the middle of a repeated group, so carrying them raw would leave the list unsplittable. A ParameterResolver supplies the widths; a registry without one decodes twenty-one of the twenty-eight types and returns ErrNoParameterResolver for the seven that need it.
ST[12] monitoring itself6.12N by designThe wire format of all twenty-eight messages is here; evaluating the checks is not. Sampling parameters, applying masks, counting repetitions and raising events are flight software. Clause 8.12.2.7c's rule that a modify request must keep the original check type also needs the original, which only the flight software holds.
ST[11] schedule state and execution6.11N by designThe wire format of all twenty-seven messages is here; the schedule is not. Sub-schedule and group state, the release window, and the interlocks between activities are flight software. Every check the codecs make is one a message can fail on its own.
Absolute time field byte fidelity across a decode and re-encode7.3.10, Table 7-10Ppkg/tcf truncates a CUC fractional second in both directions by design, rounding to nearest can carry the fine field past its width, so a field of two or three fine octets can come back one tick lower. It affects the TM header time and every ST[11] release time and window tag equally. RelativeTime sidesteps it by storing the field rather than a time.Time; the absolute field cannot, because its Go type is a time.Time.
ST[08] argument values8.8.2.1, 6.8.3.1bN by designFigure 8-87 types each argument value as "deduced": its width comes from the function's argument declaration, which is mission configuration. The block is carried verbatim, and FunctionArguments.SplitArguments splits it against a width function the caller supplies.
ST[08] function and argument semantics6.8.1.1, 6.8.4dN by designWhich functions exist, what their arguments mean and what running one does are outside the standard. The three rejection conditions of 6.8.4d all test a request against the mission's declarations, so only the flight software can apply them.
Position-based scheduling semantics6.22NOut of scope.

A1.6 MISSION TAILORING SURFACE

Widths this implementation exposes through MissionProfile, each because the standard leaves it to the mission:

Profile fieldReference
TCSpareBytes7.4.4.1g
TMSpareBytes7.4.3.1l
TimeFormat, CUCCoarseBytes, CUCFineBytes, CUCEpoch, TimeRawBytes7.4.3.1j, Table 7-10
StepIDBytesFigures 8-5, 8-6 (step ID is enumerated, no stated width)
FailureCodeBytesFigure 8-2 and siblings (failure code is enumerated)
EventDefinitionIDBytesFigure 8-59
HousekeepingStructureIDBytes, ParameterIDBytes, CollectionIntervalBytes, CountBytesFigure 8-21
APIDBytes8.17.2.3, 8.17.2.4 (the ST[17] APID is enumerated, no stated width; zero selects the common 2-octet width)
FunctionIDBytesFigure 8-87 (a fixed character-string, no stated width; zero selects 8 octets, this package's choice)
FunctionArgumentCountBytes, FunctionArgumentIDBytesFigure 8-87 (unsigned integer and enumerated, neither with a stated width; zero selects 1 octet)
RelativeTimeCoarseBytes, RelativeTimeFineBytes7.3.11, Table 7-11 (PFC 3 to 18: coarse 1 to 4, fine 0 to 3; zero selects 4 and 0, whole seconds)
SubScheduleIDBytes, GroupIDBytes, ScheduleCountBytes, ScheduleStatusBytes, TimeWindowTypeBytesFigures 8-91 to 8-110 (all enumerated or unsigned integer with no stated width; zero selects 1 octet)
ScheduleSourceIDBytes, ScheduleAPIDBytes, ScheduleSeqCountBytesFigure 8-92 (the three fields of an ST[11] request ID; zero selects 2 octets each)
SupportsSubSchedules, SupportsGroups6.11.4.1 (not widths but capability declarations; they decide whether the sub-schedule ID and group ID fields are present at all)
PMONIDBytes, FMONIDBytes, MonitorCountBytes, CheckTypeBytes, PMONStatusBytes, PMONCheckingStatusBytes, FMONStatusBytes, FMONProtectionStatusBytes, FMONCheckingStatusBytes, MonitoringIntervalBytes, RepetitionNumberBytes, TransitionDelayBytes, MinPMONFailingBytes, DeltaValueCountBytesFigures 8-111 to 8-139 (all enumerated or unsigned integer with no stated width)
SupportsConditionalChecking6.12.3.3c, via 6.12.3.3g item 3 (whether a PMON definition carries a check validity condition)
PerDefinitionMonitoringInterval6.12.3.3d, via 6.12.3.3g item 4 (whether it carries its own monitoring interval)
SupportsTransitionDelayChange6.12.3.8a, via 6.12.3.10i item 1 (whether TM[12,9] leads with the delay)
ExpectedValueSpare8.12.2.5d, 8.12.2.7e, 8.12.2.9d (a spare as wide as an event definition ID, per Figure 8-115 note 2)
SupportsFMONConditionalChecking6.12.4.2.1c, via 6.12.4.2.1f item 2
SupportsMinPMONFailingNumber6.12.4.2.1d, via 6.12.4.2.1f item 4
SupportsFMONProtection6.12.4.6.1a (whether an FMON status carries a protection status)
WordSizeBytes7.4.3.1l, 7.4.4.1g (when non-zero, Validate requires both secondary header sizes to be whole multiples of it)

Widths the standard fixes, and this implementation therefore treats as constants rather than profile fields: TC source ID, TM message type counter, and TM destination ID, all 16 bits (Figures 7-7 and 7-9).