Draft Technical Corrigendum and Errata Sheet for SCCS-SM Blue-1 EC 2

This is a list of the technical corrigendum and errata for EC-2 as of 31 December 2012. It is an intermediate list. Once the final agreements and decisions regarding the XML Navigation Data Messages have been made, this document will be updated to reflect those decisions and the result will be submitted to the CCSDS Secretariat.

A.TECHNICAL CORRIGENDUM

1. Section 5.3.4.2, table 5-23, definition of storedChannels, change

“vcid (virtual channel identifier) = Integer in the range of [0..63] for vn = 0 and in the range of [0..255] for vn = 1”
to
“vcid (virtual channel identifier) = Integer in the range of [0..7] for vn = 0 and in the range of [0..63] for vn = 1”

2. Section 5.9.4.2, table 5-82, definition of permittedGlobalVcidSet, change

3. Section 7.3.5.2, table 7-36, definition of reportingChannelId, change

CORRESPONDING CHANGES TO XML SCHEMA

Corresponding changes will be required in the XML schemas.

B. ERRATA

This errata sheet contains corrections for typographical and editorial errors that appear in the version 1, Editorial Change (EC) 2 SCCS-SM Service Specification Recommended Standard (CCSDS 910.11-B-1, August 2009).

1. Section 1.9, change reference [13] from
“Orbit Data Messages. Recommendation for Space Data System Standards, CCSDS 502.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2004”
to “
“Orbit Data Messages. Recommendation for Space Data System Standards, CCSDS 502.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, November 2009”.

2. Section 1.9, change reference [15] from
“XML Specification for Navigation Data Messages. Draft Recommendation for Space Data System Standards, CCSDS 505.0-R-1. Red Book. Issue 1. Washington, D.C.: CCSDS, November 2005”
to
“XML Specification for Navigation Data Messages. Recommended Standard, CCSDS 505.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, December 2010”.

3. Section 4.2.1, 4th paragraph (begins “Once a service package has been created…”), replace
“shown in figures 4-3 and 4-4”
with
“shown in figures 4-3

4. Replace figure 4-3 with the following figure:

5. Delete figure 4-4.

6. Section 4.3.7.2, table 4-19: hyphenate “servicePackageDefinitionThresholdTime” between “Threshold” and “Time”.

7. Section 4.5.3.2, table 4-52, DSPC-9: Change the NOTE from:

“If the performance of the CSP operation to create (or a RSP operation to replace) the referenced Service Package has been acknowledged but the Service Package has not yet been scheduled, CM will also fail the CSP/RSP operation and return a CSP-SR (see CSPC-22, table 4-3).”

“If the performance of the CSP operation to create the referenced Service Package has been acknowledged but the Service Package has not yet been scheduled, CM will also fail the CSP operation and return a CSP-FR (see CSPC-21, table 4-3).”

Rationale:

a) The behavior with respect to RSP is not supported by any normative requirements. Returning an RSP-FR is one conformant behavior, but others (e.g., returning an RSP-SR before the Service Package is ultimately deleted) are also possible.

b) The correct behavior is to return a CSP-FR.

c) The correct cross-reference is CSPC-21.

Section 4.10.5.3, Table 4-89: change the text for QSPD-2 from
“The QueryServicePackageSuccessfulReturn message shall contain one ServicePackageReference data set.”

8. Section 4.10.5.3, Table 4-89: change the text for QSPD-2 from
“The QueryServicePackageSuccessfulReturn message shall contain one ServicePackageReference data set.”

“The QueryServicePackageSuccessfulReturn message shall contain:

a) one ServicePackageReference data set; and

b) one CompleteServicePackageResult data set.”

Rationale: The class diagram clearly represents the containment stated above. Furthermore, most of the remaining requirements in table 4-89 reference components of the CompleteServicePackageResult data set, and would be meaningless unless the QueryServicePackageSuccessfulReturn message contains that data set.

9. Section 4.12.5.1, figure 4-38: change the composition multiplicity for the ServicePackageReference class from blank to “1”. (Also, the “diamond” should be blacked in instead of empty/clear: in UML, an empty/clear diamond means aggregation, a filled-in diamond means composition, and the diagram should show composition. This is a problem that occurs numerous times in EC2).

Corrected figure 4-38:

10. Section 5.3.5.2, table 5-26: hyphenate “spaceCommunicationServiceProfileId” between “Communication” and “Service”.

11. Section 5.3.6.2, table 5-28: hyphenate “spaceCommunicationServiceProfileRef” between “Communication” and “Service”.

12. Section 5.6.4.2, table 5-51: hyphenate “eventTimeWindowLead” between “Window” and “Lead”.

13. Section 5.9.4.1, Figure 5-24:

a. Change “allowedFrameQuality” to “permittedFrameQualities”

b. Change “allowedChannelFrameGvcids” to “permittedGlobalVcidSet”

Rationale: these are the names of the parameters in the corresponding data set tables. They were changed in the SCCS-SM to match the managed parameter names in the RAF and RCF Transfer Service specifications. The changes had been made in the data set tables but had not been made in the diagram.

Corrected figure 5-24:

14. Section 5.9.4.2, table 5-82: change the second “lowerBoundReportingPeriod” to “upperBoundReportingPeriod”.

15. Section 5.10.4.1, Figure 5-29:

a. Change “allowedFrameQuality” to “permittedFrameQualities”

b. Change “channelFrameGvcids” to “permittedGlobalVcidSet”

Corrected figure 5-29:

16. Section 5.10.4.2, table 5-94: change the reference for the definition of the functionalGroupId parameter from table 5-23 to table 5-94

Rationale: the definition in table 5-94 is the proper one for offline SLE transfer services.

17. Section 6.3.4.1, Figure 6-2: delete the {data sets defined in reference [14]} comment box.

Corrected figure 6-2:

18. Section 6.5.5.2, Figure 6-9: delete the {data sets defined in reference [14]} comment box.

Corrected figure 6-9:

19. Section 6.6.4.1, Figure 6-11: delete the {data sets defined in reference [14]} comment box.

Corrected figure 6-11:

20. Section 6.6.5.3, table 6-35, ETPD-4: change “ExtendTrajectoryPredctionSuccessfulReturn” to “ExtendTrajectoryPredictionSuccessfulReturn”.

21. Section 7.3.5.1, figure 7-2: In the ServiceAgreement data set, change “handoversPermitted” to “handoversPermittedAgreement”.

Corrected figure 7-2:

22. Section 7.3.5.1, figure 7-3: change the composition multiplicity for the AddSpaceLinkEventsProfileOperationConstraints, QuerySpaceLinkEventsProfileOperationConstraints,and DeleteSpaceLinkEventsProfileOperationConstraints classes from “1” to “0..1”.

Corrected figure 7-3:

23. Section 7.3.5.2, table 7-32: in the definition of the carrierUse parameter, change the definition from ”Service Agreement period t” to “Service Agreement period”.

24. Annex B, table B-1, Note 3 (“Return messages only; query invocations have very minimal content definitions. “) is not showing at the bottom of the page. It is present in the embedded Excel spreadsheet, but does not show in the Word document or the PDF.

25. In annex D, table D-2, .the “Comm” in “scheduledSpaceCommServiceStartTime” and “scheduledSpaceCommServiceStopTime” should be un-bolded.

26. In annex D, table D-3, .the “CommunicationService” in “spaceCommunicationServiceProfileId” and “spaceCommunicationServiceProfileRef” should be un-bolded.

27. Annex F, table F-1, spaceCommServiceStartTimeLead parameter definition: change “earliest time that the space link session may begin” to “earliest time that the space communication service may begin”.

28. Annex F, table F-1, startTimeOffset parameter: for the data sets that use this parameter, “table 5-79” should be “table 5-81” for RafTransferServiceProfile and “table 5-80” should be “table 5-82” for RcfTransferServiceProfile.

31 December 2012