Proposed Review Items Disposition Resolutions at CSSMWG Workshop
Summary of the CSSMWG workshop held in Mountain View, CA, USA, discussing the acceptance of 9 RIDs, including technical and editorial changes submitted by ESA/ESOC and NASA/JPL. Final resolution of one ESA RID pending progress in defining codes for fixed-length frames. The workshop concluded that the Forward Frame book can proceed to Blue-1 without needing a second Red Book.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Forward Frame CSTS Red Book Issue 1 Proposed Review Item Disposition (RID) Resolutions CSSMWG Workshop Mountain View, CA, USA 6-9 May, 2019 John Pietras Global Science and Technology, Inc.
Summary 9 RIDs submitted 6 from ESA/ESOC 2 Technical Fact 4 Editorial 3 from NASA/JPL All 3 are Technical Fact All RIDs accepted (at least in principle) Final resolution of one ESA RID depends on progress (or lack thereof) of the CCSDS SLS Coding and Synchronization (C&S) WG in defining the codes to be used for fixed-length frames on forward links Five pseudo-RIDs (WG-internally-generated RIDs resulting from further discovery after review period) Methods for setting dynamically-modifiable configuration parameters Repetition of TC frames when the FF service is used Eliminate Directives on other procedures within the service instance Change all cross-references to F4.n of the SFW to F3.n Ensure that Annex M (Cross References to CSTS SFW) is consistent with CSTS SFW B-2 Summary assessment: The FF book should be able to proceed to Blue-1 without requiring a second Red Book 2 www.ccsds.org
Editorial [#1] - Rid [ESA] FF-1 Reviewer: Felix Flentge (ESA/ESOC) Page #: 1-11 Paragraph #: 1.6.1.7.1 Description From: (nominally al or part of the Attached Synchronization Marker). To: (nominally all 1 or part of the Attached Synchronization Marker). Category of Requested Change: Editorial Supporting Analysis: none Proposed Disposition: Accepted in principle, but the suggested change itself has a typo it should be simply all (instead of al ) but not all 1 (Typo confirmed by the RID author). Actual change TO: (nominally all or part of the Attached Synchronization Marker) 3 www.ccsds.org
Editorial [#2] - Rid [ESA] FF-2 Reviewer: Felix Flentge (ESA/ESOC) Page #: 2-3 Paragraph #: 2.2.2.1 Description From: functional resources (see annex L of reference [1) To: functional resources (see annex L of reference [1]) Category of Requested Change: Editorial Supporting Analysis: none Proposed Disposition: Accepted. 4 www.ccsds.org
Editorial [#3] - Rid [ESA] FF-3 Reviewer: Felix Flentge (ESA/ESOC) Page #: 2-15 Paragraph #: 2.5.1 Description From: [In the last sentence of the first paragraph:] The first scenario illustrates To: The third scenario illustrates Category of Requested Change: Editorial Supporting Analysis: none Proposed Disposition: Accepted. 5 www.ccsds.org
5 Bytes Bit Mask / Pattern in Example - Rid [ESA] FF-4 Reviewer: Felix Flentge (ESA/ESOC) Page #: 2-16 Paragraph #: 2.5.5.2. c) Description The bit mask and bit pattern for FFr2 are 5 bytes instead of 4 bytes. Remove 5th byte. Category of Requested Change: Technical Fact Supporting Analysis Bit mask / bit pattern should be 4 bytes only as described before Proposed Disposition: Accepted The affected line in 2.5.5.2.c) 1) will now read: 11000011 11111111 11111100 00000000 00000000 (C3 FF FC 00 00 Hex) The affected line in 2.5.5.2.c) 2) will now read 00000000 00010100 00001000 00000000 00000000 (00 14 08 00 00 Hex); and 6 www.ccsds.org
[Sync and Channel Coding Reference Needs Updating] - Rid [ESA] FF-5 (1 of 3) Reviewer: Felix Flentge (ESA/ESOC) Page #: 2-21, 2-28 Paragraph #: 2.5.3.1, Note 1; 2.5.4.3, Note Description It is stated: For the purposes of this Draft Recommended Standard, all of the synchronization and channel coding functions of reference [K15] are assumed to be available for the processing of fixed-length frames. This section will be updated prior to publication as a Recommended Standard with the identification of the synchronization and channel coding functions as they are specified as of that time. I would assume that this update should be done now if possible. Otherwise the note should be re-phrased. (same for 2.5.4.3, Note) Category of Requested Change: Technical Fact Supporting Analysis: none 7 www.ccsds.org
[Sync and Channel Coding Reference Needs Updating] - Rid [ESA] FF-5 (2 of 3) Proposed Disposition: Accepted in principle the FF-CSTS book needs to reflect the current status in the C&SWG as of publication of the FF book Final resolution depends on SLS C&SWG As of the end of April 2019, the CCSDS Space Link Services (SLS) Coding and Synchronization (C&S) Working Group has not yet arrived at a consensus on either (a) the specific synchronization and coding functions that will be recommended or (b) what Recommended Standard will be used to document these functions. NASA is the primary proponent of using fixed-length frames on the forward link: the ISS uses AOS over Reed-Solomon, and use of AOS (or USLP?) is envisioned for the Lunar Gateway The NASA proposal going into the Spring 2019 Workshop is to modify the existing TM Sync and Channel Coding Blue Book to recommend the use of the Reed-Solomon and LDPC codes (but not Turbo or convolutional) on the forward link, and to similarly update the SCCC or DVB-S2 Blue Books if either or both of those are desired for use on the forward link NASA is proposing a work plan that, if accepted, would see the updated TN S&CC book be published in October 2020 well beyond when we hope to be able to have published the FF-CSTS book 8 www.ccsds.org
[Sync and Channel Coding Reference Needs Updating] - Rid [ESA] FF-5 (3 of 3) Proposed Disposition (concluded): Final resolution depends on SLS C&SWG So the FF Blue Book will have to address this matter as a work in progress reference. How it will be phrased will depend on how the NASA proposal is received by the C&SWG at the Spring meeting: If the C&SWG accepts the full NASA proposal in principal, the relevant sections of the FF book can be rewritten along the lines of The TM Sync and Channel Coding Book is in the process of being extended to add the use of R-S and LDPC coding on the forward link . In this case the example Annex I3 will be rewritten to exclude Turbo If the C&SWG accepts the NASA proposal to update the TM S&CC book but does not (yet) agree on the specific down-selection to R-S and LDPC, the relevant sections of the FF book can be modified accordingly If the C&SWG accepts the NASA proposal on the specific down-selection to R-S and LDPC but does not (yet) agree to document it as an update the TM S&CC book, the relevant sections of the FF book can be modified accordingly If the C&SWG neither accepts the NASA proposal on the specific down-selection to R-S and LDPC nor agrees to document it as an update the TM S&CC book, the relevant sections of the FF book can be modified to simply remove the statements that the examples represent the final decision a. b. c. d. 9 www.ccsds.org
Status of Individual SL-PDUs in BFDP - Rid [ESA] FF-6 (1 of 2) Reviewer: Felix Flentge (ESA/ESOC) Page #: various Paragraph #: various Description Several places (1.6.1.7.3.2, 2.1 b), 2.2.3.2.3.1, maybe others) contain formulation like: The status of individual SL-PDUs is reported back to the service user on a negative-only basis; that is, the service user is notified only if the SL-PDU is invalid (wrong VC, frame too long, or frame too short), but no feedback is given for valid SL-PDUs. I have found this formulation misleading as this applies to the PROCESS-DATA as an unconfirmed operation only. By setting the process-completion-report parameter to produce-report feedback is actually given also for valid SL-PDU for BFDP I would suggest to reformulate to something like The acceptance of individual SL- PDUs is reported back to the service user on a negative-only basis via events (wrong VC, frame too long, or frame too short); that is, data is provided via an unconfirmed operation and no notification of the acceptance of valid SL-PDU is provided. Category of Requested Change: Editorial 10 www.ccsds.org
Status of Individual SL-PDUs in BFDP - Rid [ESA] FF-6 (2 of 2) Supporting Analysis: none Proposed Disposition: Accepted in principle. However, the proposed wording goes into more Framework-level details (e.g., unconfirmed operation ) than is intended for the general-concept-level descriptions that are the target of this RID The RID also indirectly points out the lack of parallelism with the analogous descriptions of the sequence-controlled frame data processing procedure, which do not address whether the validity status of an SL-PDU is reported back to the service user. Therefore, the appropriate descriptions of the SCFDP will state that the validity status for every SL- PDU (valid, or invalid with the reason for invalidity) is reported, whereas for the BFDP procedure the validity status is reported back for invalid SL- PDUs, with the implication being that if an invalid notification is not received for an SL-PDU then it is valid The affected subsections that this proposed resolution would affect are: 1.6.1.7.3.1, 1.6.1.7.3.2, 2.2.3.2.2.1, and 2.2.3.2.3.1 11 www.ccsds.org
FF Service-specific classifiers for service-generic Published Identifiers - Rid FF-JPL-1 (1 of 2) Reviewer: John Pietras (NASA/JPL) Page #: 8-1 Paragraph #: 8.2, 8.3, 8.4 Description In 8.2, change FROM: The Forward Frame service shall report the production status using the Published Identifier svcProductionStatusVersion1, as specified in the CCSDS-CSTS-GENERIC- SERVICE-OBJECT-IDENTIFIERS module specified in F4.17 of reference [1]. TO: The ffSvcProductionStatus parameter shall report the production status using the Published Identifier svcProductionStatusVersion1, as specified in the CCSDS-CSTS- GENERIC-SERVICE-OBJECT-IDENTIFIERS module specified in F4.17 of reference [1]. In 8.3, change FROM: The Forward Frame service shall notify production status change events using the Published Identifier svcProductionStatusChangeVersion1, as specified in the CCSDS- CSTS-GENERIC-SERVICE-OBJECT-IDENTIFIERS module in F4.17 of reference [1]. TO: The ffSvcProductionStatusChange parameter shall notify production status change events using the Published Identifier svcProductionStatusChangeVersion1, as specified in the CCSDS-CSTS-GENERIC-SERVICE-OBJECT-IDENTIFIERS module in F4.17 of reference [1]. 12 www.ccsds.org
FF Service-specific classifiers for service-generic Published Identifiers - Rid FF-JPL-1 (2 of 2) Description (concluded) In 8.4, change FROM: The Forward Frame service shall notify production configuration change events using the Published Identifier svcProductionConfigurationChangeVersion1, as specified in the CCSDS-CSTS-GENERIC-SERVICE-OBJECT-IDENTIFIERS module in F4.17 of reference [1]. TO: The ffSvcProductionConfigurationChange parameter shall notify production configuration change events using the Published Identifier svcProductionConfigurationChangeVersion1, as specified in the CCSDS-CSTS- GENERIC-SERVICE-OBJECT-IDENTIFIERS module in F4.17 of reference [1]. Category of Requested Change: Technical Fact Supporting Analysis According to the CSTS Guidelines, the paragraphs are supposed to define the service-specific classifiers that are to be used to identify the service-generic svcProductionStatusVersion1, svcProductionStatusChangeVersion1, and svcProductionConfigurationChangeVersion1 Published Identifiers (OIDs) Proposed Disposition: Accepted. Note that the recommended changes are also consistent with how these parameters are specified in the MD-CSTS Blue Book and TD-CSTS Red Book 13 www.ccsds.org
Align EXECUTE-DIRECTIVE parameter names with SFW Pink Book- Rid FF-JPL-2 (1 of 2) Reviewer: John Pietras (NASA/JPL) Page #: A-11 Paragraph #: Table A-12 Description In Table A-12 (EXECUTE-DIRECTIVE invocation): For Item execDir-3: FROM procedureInstanceId TO procedureName For Item execDir-6: FROM procedureInstanceId TO targetProcedureName a) b) Category of Requested Change: Technical Fact Supporting Analysis The names of these parameters changed between the Blue-1 and Pink-1 versions of the CSTS SFW. The proposed changes make the FF book consistent with the Pink Book 14 www.ccsds.org
Align EXECUTE-DIRECTIVE parameter names with SFW Pink Book- Rid FF-JPL-2 (2 of 2) Proposed Disposition: Accepted NOTE execDir should be execDirInv in both cases in the requested changes Also, FROM procedureInstanceId TO procedureName : Table A-7, bindInv-3 Table A-10, unbindInv-3 Table A-15, getInv-3 Table A-17, procDataInv-3 Table A-19, startInv-3 Table A-21, stopInv-3 Table A-23, notifyInv-3 Table A-24, transferDataInv-3 a. b. c. d. e. f. g. h. 15 www.ccsds.org
Use EMBEDDED PDVs Instead of CSTS SFW B-1 TypeAndValue-based Values - Rid FF-JPL-3 (1 of 4) Reviewer: John Pietras (NASA/JPL) Page #: 5-8, 5-9, and A-11 Paragraph #: 5.6.7.2.1, Annex A AV7 Description In 5.6.7.2, change the specification of the data types of the extension events to be defined in terms of EMBEDDED PDVs rather than in terms of the CSTS SFW B-1 TypeAndValue data type In Annex A, AV7, change the specification of the data type for the localProcDirQualifier to be in terms of EMBEDDED PDVs rather than in terms of the CSTS SFW B-1 TypeAndValue data type Category of Requested Change: Technical Fact Supporting Analysis The FF Red Book defines certain parameters in terms of the TypeAndValue data type that was defined in CSTS SFW Blue-1. The SFW TypeAndValue data type has been recast in SFW Pink-1 as an EMBEDDED PDV, which affects the way that the event and parameter types are expressed Proposed Disposition: Accepted. ALSO QualifiedValues must become QualifiedValue and SequenceOfQualifiedValues must become SequenceOfQualifiedValue to conform to changes in SFW P-1. 16 www.ccsds.org
Use EMBEDDED PDVs Instead of CSTS SFW B-1 TypeAndValue-based Values - Rid FF-JPL-3 (2 of 4) 5.6.7.2.1.2 FROM: The data type of the event-nameparameter for the invalid GVCID , frame too short , and frame too long events uses the following path Missing single quote missing FROM: The data type of the event-valueparameter for the invalid GVCID , frame too short , and frame too long events uses the following path Missing single quote missing 5.6.7.2.1.2 a) the first part of the path is NotifyInvocation : eventValue : EventValue : qualifiedValues : SequenceOfQualifiedValues : SEQUENCE OF QualifiedValues , where this sequence has the length 1; 17 www.ccsds.org
Use EMBEDDED PDVs Instead of CSTS SFW B-1 TypeAndValue-based Values - Rid FF-JPL-3 (3 of 4) 5.6.7.2.1.2 b) FROM: the second part of the path is QualifiedValues : valid : TypeAndValueComplexQualified : typeAndValue : integerPositive : SEQUENCE OF IntPos , where this sequence has the length 1. TO: the second part of the path is QualifiedValue : valid : TypeAndValue : Embedded : EMBEDDED PDV , where the Object Identifier and the type of the data-unit-id parameter are xxxx and XXXX data-unit-id is of type DataUnitId, which is already as specified in F3.3 of the SFW Should we add an OID for the type in the SFW and just reference that, e.g., where the Object Identifier and the type of the data-unit-id parameter are dataUnitId and DataUnitId, as specified in F3.3 of reference [1] ? Doing so for all SFW types would make them all usable by CSTSes Under which node would these OIDs be registered? Or should we create BFDP-specific OID and type (where PBFDPdataUnitId is cast as the SFW s DataUnitId), e.g., where the Object Identifier and the type of the data-unit-id parameter are pBFDPdataUnitId and PBFDdataUnitId, as specified in Annex D [BFPD PDUs] The OID would be registered under the bfdpEventsId node? Substructure under this node? o o o 18 www.ccsds.org
Use EMBEDDED PDVs Instead of CSTS SFW B-1 TypeAndValue-based Values - Rid FF-JPL-3 (4 of 4) Table A-12, AV7 FROM: The parameter execDirInv-5 will be: directiveQualifier : localProcDirQualifier : DirectiveQualifierValues : parameterlessValues : TypeAndValueComplexQualified : typeAndValue : TypeAndValue : intUnsigned : SEQUENCE OF IntUnsigned where this SEQUENCE has the length 1 TO: The parameter execDirInv-5 will be: directiveQualifier : localProcDirQualifier : DirectiveQualifierValues : parameterlessValues : TypeAndValue : Embedded : EMBEDDED PDV , where the Object Identifier and the type of the directive- qualifier parameter are pSCDPresetDirectiveDirQual and pSCDPresetDirectiveDirQual, as specified in F3.16 of reference [1]. OR The parameter execDirInv-5 will be: directiveQualifier : localProcDirQualifier : DirectiveQualifierValues : parameterlessValues : TypeAndValue : Embedded : EMBEDDED PDV , where the Object Identifier and the type of the directive- qualifier parameter are as specified in 4.8.4.4.3.2 of reference [1]. 19 www.ccsds.org
Methods for Setting Dynamically-Modifiable Config Parameters pRID JP-1 (1 of 2) input-queue-size (SCFDP & BFDP), maximum-forward-buffer- size (BFDP), and processing-latency-limit (BFDP) are the only dynamically-modifiable configuration parameters of the FF procedures All inherited from their SFW parent procedure The Forward Frame service made all of these parameters of the START invocation Consensus at the time was to restrict the conditions under which the changes could be made 1.6.1.7.37 of the SFW Pink Book states Unless explicitly specified otherwise in the Framework definition of a procedure type, the method(s) by which the values of dynamically modifiable procedure configuration parameters are modified is (are) delegated to the service using the procedure or to a derived procedure The method chosen for the FF service is via additional START invocation parameters: this should be more explicitly stated in the FF book 20 www.ccsds.org
Methods for Setting Dynamically-Modifiable Config Parameters pRID JP-1 (2 of 2) HOWEVER, the NOTE following 1.6.1.7.37 goes on to say: The method a service may use to set the value of dynamically modifiable procedure configuration parameters is the THROW-EVENT procedure (see 4.12). A derived procedure may comprise the EXECUTE-DIRECTIVE operation (see 3.13) as the method to set dynamically modifiable procedure configuration parameter values. [emphasis mine] As currently phrased, if a service is going to support dynamic modification, it must be done either through the EXECUTE-DIRECTIVE (either in the Throw Event procedure or an EXECUTE-DIRECTIVE operation dedicated to a procedure) Recommend that the NOTE following 1.6.1.7.37 in the SFW be rephrased along the lines of: A method that a service may use to set the value of dynamically modifiable procedure configuration parameters is the THROW- EVENT procedure (see 4.12). A derived procedure may comprise the EXECUTE-DIRECTIVE operation (see 3.13) as another method to set dynamically modifiable procedure configuration parameter values. Other methods may be used by services to set dynamically modifiable configuration parameter values. 21 www.ccsds.org
Repetition of TC Frames When the FF Service is Used pRID JP-2 (1 of 4) The Telecommand (TC) Space Data Link Protocol and TC Synchronization and Channel Coding Blue Books support repetition of frame transmission Formally defined in the Blue Books as a group of frames being submitted by the All Frames Generation Function (TC SDLP) to the TC Sync and Channel Coding layer , accompanied by a Repetitions parameter The group of frames is transformed into a single CLTU and transmitted Repetitions times SLE F-CLTU and FSP deviate from this formal definition but the result on the wire is the same In F-CLTU, the user transmits each CLTU the number of times desired Whether CLTUs are being repeated or not is not visible to the ESLT In FSP, the repetitions for AD Frames and BC Frames are managed parameters for each TC VC, and the repetition is performed by the production processes that create and multiplex the VC frames into the forward link Both the F-CLTU and FSP approaches have been approved by Ops personnel Frame repetition should be recognized and addressed by the FF-CSTS book 22 www.ccsds.org
Repetition of TC Frames When the FF Service is Used pRID JP-2 (2 of 4) 3 options (at least) for accommodating repetition Adopt something like the F-CLTU approach: user would send groups of frames the repeated number of times Would entail changes to FF book, which is currently oriented toward a single frame per PROCESS-DATA invocation Theoretically wasteful of LAN bandwidth Redefine FF service to perform the repetition of frames submitted to service production Even larger impact on the FF book Adopt the FSP approach: repetition performed by service production based on configuration parameters J. Pietras and W. Hell recommend that the FSP approach be adopted Changes to FF book: Add requirements to repeat frames based on configuration parameter values for AD and BC frames for the TC VC Multiplexing and TC MC Multiplexing functions in Annex G (Forward Frame Service Production Requirements) Add description of repetition behavior to the Annex I2 (Transfer Frame Configuration for Telecommand Frames) Update the descriptions of the FwdTcVcMux and FwdTcMcMux FRs and add the appropriate configuration parameters (SANA Registry, FR Reference Model Tech Note) 23 www.ccsds.org
Repetition of TC Frames When the FF Service is Used pRID JP-2 (3 of 4) Frames from other VC sources FF-CSTS Provider (frames) FF-CSTS Provider (frames) VC Frames Represented by one FwdTcVcMux FR instance per MC - AD Frame Repetition Table - BC Frame Repetition Table VCF Service Frames from other Master Channels Virtual Channel Multiplexing Function Functions as defined in TC Space Data Link Profile (CCSDS 232.1) Data Link Protocol Sublayer MC Frames Master Channel Multiplexing Function All Frames All Frames Generation Function Represented by one FwdTcMcMux FR instance per Physical Channel - Max # of Frames per CLTU - BC Frame Repetition Table Transfer Frames Random Sequence Generation (optional with BCH, mandatory with LDPC) Synchronization and Coding Sublayer (Randomized) Transfer Frames Functions as defined in TC Synchronization and Channel Coding (CCSDS 231.0) BCH or LDPC Encoding Represented by one FwdTcPlopSyncAndChnlEncode FR instance per Physical Channel - Max # of Frames per CLTU - Max CLTU Length Codewords CLTU Generation CLTUs Phyiscal Layer Operations Procedure PLOP Channel Symbols Physical Layer redundant Functions as defined in Radio Frequency and Modulation Systems Part 1: Earth Stations and Spacecraft (CCSDS 401.0) move to FwdTcMcMux? RF Modulation functions 24 www.ccsds.org Modulated Radio Waveforms Antenna
Repetition of TC Frames When the FF Service is Used pRID JP-2 (4 of 4) FwdTcVcMux Receives frame from FwdFrameCstsProvider Looks up repetition number for frame based on VC and frame type in AD Frame Table or BC Frame Table BD frames are not repeated Provides repetition number of that frame to FwdTcMcMux Order of release of (possibly repeated) frames is determined by VC multiplexing scheme FwdTcVcMux Frames are enqueued behind previously-enqueued frames Order of enqueuing is determined by MC multiplexing scheme Frame Set is formed of the next n frames that satisfy both max number of frames per CLTU and max CLTU length Implementations may prohibit mixing of different frames in the same Frame Set Existing tagging of frames for radiation-complete reporting allows FwdTcMcMux to differentiated repeated from non-repeated frames Releases Frame Set to FwdTcPlopSyncAndChnlEncode o FwdTcPlopSyncAndChnlEncode Creates CLTU from Frame Set (any frame repetitions are opaque) 25 www.ccsds.org
Eliminate Directives on other Procedures within the Service Instance pRID JP-3 (1of 2) Table A-12, parameters execDirInv-6 (targetProcedureName) and execDir-7 (ServiceProcDirQualifierValues) are only used if the directive is targeted for a procedure of the service other than the procedure that contains the EXECUTE-DIRECTIVE operation through which the directive was received It is not possible in the FF service to receive such a directive The EXECUTE-DIRECTIVE operation of the Sequence-Controlled Frame DP procedure is constrained to transfer only the reset directive, which is targeted on the SCFDP itself (execDir-5) The EXECUTE-DIRECTIVE operation of the Master Throw Event procedure is constrained to transfer only directives for functional resources that comprise the underlying service production ((execDir-8 and execDir-9) Solution Change the Status column values for rows execDirInv-6 and execDir-7 from C12 to X Delete condition C12 and move up all following conditions 26 www.ccsds.org
Eliminate Directives on other Procedures within the Service Instance pRID JP-3 (2 of 2) Parameters of the ExecuteDirectiveInvocation PDU Values Support Status Supported Allowed Parameter Ref. Item invokerCredentials F4.3 of reference [1] M execDirInv-1 invokeId F4.3 of reference [1] M execDirInv-2 procedureName F4.3 of reference [1] M AV5 execDirInv-3 directiveIdentifier F4.4 of reference [1] M AV6 execDirInv-4 localProcDirQualifier F4.4 of reference [1] C11 AV7 execDirInv-5 targetProcedureInstanceName F4.4 of reference [1] C12 X execDirInv-6 serviceProcDirQualifierValues F4.4 of reference [1] C12 X execDirInv-7 functionalResourceInstanceNumber F4.4 of reference [1] C13 C12 execDirInv-8 functionalResourceQualifiers F4.4 of reference [1] C13 C12 AV8 execDirInv-9 directiveQualifierExtension F4.4 of reference [1] X execDirInv-10 executeDirectiveInvocationExtension F4.4 of reference [1] M notUsed execDirInv-11 27 www.ccsds.org
Change all Cross-References to F4.n of the SFW to F3.n pRID JP-4 SFW Pink Book eliminated section F3 (integer representation of enumerated types), causing all F4.n sections (ASN.1 modules) to become F3.n All references in the FF book to F4.n must be changed to F3.n 28 www.ccsds.org
Ensure that Annex M is Consistent with CSTS SFW B-2 pRID JP-5 Annex M (Cross References to CSTS SFW) entries must be checked and updated as necessary Including, but not limited to, F4 -> F3 changes Updating will be deferred until SFW Pink Book is ready to go Blue 29 www.ccsds.org
