1 / 21

CESG FALL 2009: items brought to attention of the CMC

CESG FALL 2009: items brought to attention of the CMC. IOAG-13 Communiqués to CCSDS. IOAG Communiqué of 01 October 2009. CESG Analysis of IOAG-13 Communiqué [1].

gordy
Download Presentation

CESG FALL 2009: items brought to attention of the CMC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CESG FALL 2009: items brought to attention of the CMC

  2. IOAG-13 Communiqués to CCSDS

  3. IOAG Communiqué of 01 October 2009

  4. CESG Analysis of IOAG-13 Communiqué [1] • The CESG has formed a BOF which has the task of identifying the charter and program of work for a Working Group to develop a top-level CCSDS reference/service architecture • The CESG will transmit the MOIMS “Mission Operations Services Concept” Green Book to IOAG as soon as it has been updated to reflect recent RIDs. • The LDPC codes have been sent for Agency Red-1 review • The CESG is studying how to create the SSI Architecture in time for IOP-3. The CESG understands the intention of the IOAG to produce a layered set of service catalogs and asks the IOAG to confirm that the context of the SSI Architecture is the architecture for Service Catalog-2, as indicated below: IOAG Service Catalog 3 • CCSDS Mission Operations Service Architecture IOAG Service Catalog 2 • CCSDS Solar System Internetwork Architecture IOAG Service Catalog 1 CCSDS Cross Support Service Architecture

  5. CESG Analysis of IOAG-13 Communiqué [2] • With respect to the CSTS Space Link Monitoring Service requested by the IOAG (end CY 2011), this is already in the CCSDS program of work. • With respect to the four data relay standards requested by the IOAG, the CESG has concerns that this could result in a very heavy standardization effort for a relatively small (Mars relay) market: • A data relay standard for: a) requesting the acquisition of; and, b) transferring remote orbiter-derived Doppler observables and orbiter trajectory and clock information to support landed vehicle position determination (end CY 2012) • A data relay standard for: a) requesting the acquisition of; and, b) transferring remote orbiter-derived open-loop recording and digitization of Entry, Descent and Landing (EDL) signals (end CY 2012) • A space-based data relay cross-support transfer service standard for monitoring the performance of remote space-space links (end CY 2012) • A data relay standard for: a) requesting the acquisition of; and, b) transferring remote orbiter-derived orbiter clock calibration and proximity time correlation data to support landed vehicle time correlation (end CY 2014) The initial CESG thought is to standardize just the containers (e.g., the mechanisms for formatting the information) and the transfer mechanisms for passing the information between ground and space (e.g., CFDP, AMS, etc.) but not the semantics of the information being transferred. The semantics might be standardized later by MOIMS as part of Service Catalog-3. The CESG seeks more IOAG guidance on this point. • With respect to the time correlation and clock synchronization standard requested by the IOAG (end CY 2014) , CCSDS has created a BOF to study this topic. • With respect to the data relay pass planning standard requested by the IOAG (end CY 2014), CCSDS proposes to defer this item until the scope of Service Catalog-3 is better understood.

  6. Untransmitted IOAG Communiqué re: Service Catalog 1 “gap fillers” IOAG Service Catalog-1 • IOAG has adopted the notion of a phased set of services that Agencies will be asked to cross support: • Catalog-1: consolidation of space link services (now -2015) • Catalog-2: addition of Internetworking services (2015 – 2020) • Catalog-3: (possible) addition of Mission Operations services (2020+?) • Catalog-1 was agreed at IOAG-13 • “Core” (shaded) and “Extended” • Standards gaps exist; IOAG is still voting on priorities to send to CCSDS

  7. IOAG Service Catalog-1: Forward

  8. IOAG Service Catalog-1: Return

  9. IOAG Service Catalog-1: Radio Metric

  10. IOAG Service Catalog-1: Gap Analysis CSTS File Transfer Service CSTS Forward File Service CSTS Return File Service CSTS Offline Radio Metric Service CSTS Real Time Radio Metric Service CSTS Delta DOR Service CSTS Engineering Data Monitoring Service SLE Forward AOS Frame Service SLE Return Unframed Telemetry Service • CESG understands that IOAG is still not in agreement on the priorities to assign for CCSDS to develop these standards. • CESG interprets the “CSTS File Transfer Service” as some sort of secure terrestrial file transfer which then gateways into CFDP-based “CSTS Forward File Service” and “CSTS Return File Service” as Extended Services for single space/ground link transmission. This appears to be related to IOAG R12.9.1 and subsequent discussions. We request confirmation from the IOAG Service Catalog-2 and SISG activities on this point.

  11. Considering that: The CCSDS received the Liaison Statement from IOAG-12, dated 10 September 2008. The CCSDS did not respond to this Liaison Statement at its October 2008 meeting in view of the upcoming IOP-2. CCSDS needed to analyze the intent of Resolution R12.9.1 after IOP-2. And recognizing that: Accordingly, CCSDS convened an ad-hoc technical group from 21-23 April in Colorado Springs in order to analyze and clarify the intent of R12.9.1 Technical consensus was reached by that group and was reported to the CCSDS Management Council The CCSDS Management Council resolves that it interprets the intent of R12.9.1 as follows: For missions that may need to conduct file transfer over a single space/space link, CCSDS is requested to develop a Recommended Practice that defines the profile of CCSDS standards required to operate CFDP over Space Packet over a single Proximity-1 link. For missions that may need to conduct file transfer over a single ground/space link, CCSDS is requested to develop: a Recommended Practice that defines the profile of CCSDS standards required to operate CFDP over Space Packet over a single TM/TC/AOS link; a cross-support standard for transferring files between ground communications complexes and ground users to support a variety of applications, including emergency commanding CCSDS is requested to initiate the development of an end-to-end networked communications architecture: by developing Recommended Standards for the DTN suite and Recommended Practices for its deployment by developing a Recommended Practice for the deployment of the IP suite by evaluating the potential need for CSTS ground/ground specifications for [forward and return Space Packet] and [forward and return Encapsulation Packet] in the context of this work The CCSDS Management Council further notes that R12.9.1 also defines a need for a space link monitoring cross-support transfer service standard (which has been accepted into the CCSDS Program of work) and for an interagency routine file transfer service (which is addressed above). However, the Resolution also asks for a standard for “time synchronization services” and this is not well-understood by CCSDS. The IOAG is therefore asked to clarify its needs for ancillary data standards. IOAG R12.9.1[1] – CCSDS Request for Clarification “IOAG 12 Liaison Statement to CCSDS” (dated 10 September 2008) also contained a Resolution R12.9.1 that was unclear to CCSDS. In May 2009 the CCSDS Management Council responded to the IOAG as follows:

  12. Illustrative scope of proposed R12.9.1 developments CFDP over Proximity Link Magenta Book CFDP CFDP A Space Packet Prox-1 B CFDP over Space Link Magenta Book CFDP Cross-Support Ground File Transfer Blue Book CFDP A Space Packet TM/TC/AOS B • Plus existing CSTS Services • Return All Frames • Return Channel Frames • Forward CLTU ( Forward AOS) A

  13. R12.9.1[2] – IOAG clarification back to CCSDS In June 2009 the IOAG responded to the CCSDS as follows: The IOAG also confirms its acceptance of the proposed standardization activities, i.e., 1) Best Practice for CFDP over a single space to space link (Prox-1); 2) Best Practice for CFDP over a single ground to space link (TM/TC/AOS); and, 3) Standard for bidirectional ground File Transfer for a variety of applications. However, IOAG understanding of the proposed CCSDS standard on file transfers is that it shall cover all types of file transfers, i.e., for the single ground/space link and for the single space/space link. It shall also cover the file transfers for the single space/space link for the purpose of Emergency Commanding and Essential Telemetry. This understanding is to be confirmed in the CCSDS resolution. The IOAG acknowledges that CCSDS plans to initiate the evaluation and/or the development of best practices and standards for an end-to-end networked communications architecture. Finally, the IOAG agrees to revisit and clarify its requirements for standards on ancillary data and will conduct some inventory and definition work to be presented, tentatively for endorsement, at the upcoming IOAG-13, which is planned for 22-24 September, 2009. CCSDS advises the IOAG that the status of this resolution is shown in Table 2.

  14. R12.9.1[3] – current CCSDS status Table 2

  15. IOAG R12.9.1[4] – Current Status • CESG notes that the strategies for evolving from IOAG Service Catalog-1 to IOAG Service Catalog-2 are still under discussion in the IOAG Space Internetworking Strategy Group (SISG) • A SISG work plan has been developed which corresponds to a bilateral ESA/NASA management recommendation • The SISG has agreed in principle on the envisioned Solar System Internetwork (SSI) for 2020 • Issues concern the evolution and the implementation/operation of the final SSI • Work plan to resolve the issues is established to accomplish: • SSI Operations Concept by 15 May 2010 • Draft IOAG Service Catalog #2 (Draft 0 by 15 Dec 2009) • SSI Requirements Draft 0 by 23 Oct 2009 (discussed at DTN Working Group meeting) • IOAG plans to hand over an agreed SSI Operations Concept to CCSDS in May 2009 for CCSDS to take over the SSI Architecture development Recommendation: allow these evolutionary issues to play-out in the SISG forum until Spring 2010

  16. Other Issues and Concerns from the Fall 2009 CESG meeting

  17. CESG General Issues/Concerns [1] • CESG would appreciate early publication of the updated CCSDS Procedures Manual. • CESG notes that the PAIMAS and OIAS models were originally published as Recommended Standards (Blue Books) but advises the CMC that in view of their technical content they should be moved to the Recommended Practice (Magenta) branch of the Standards Track now that they are being reconfirmed and updated. • CESG notes that the “Requirements for Bodies Providing Audit and Certification of Digital Repositories” Red Book is ready for Agency review. The working group wants to get a parallel ISO review in order to get a wider set of comments. This creates a problem because the asynchronous ISO/CCSDS review schedules will hold up the CCSDS work. One possibility is to do one or more CCSDS reviews and then circulate the mature CCSDS Red Book to ISO as an FDIS. • CESG notes that the SANA Working Group is almost ready to disband and that NASA has secured initial funding to implement the SANA Operator. However, it is not clear where the permanent SANA organizational and funding home will be: IOAG? CCSDS? • This is a very important operational function fore future international cross support and it needs a permanent and stable parent.

  18. CESG General Issues/Concerns [2] • CESG notes the US patent question concerning the SCCC channel code and believes that until this is resolved the “fair and non-discriminatory” requirement is not met and that this therefore prevents the document from moving forward: • ESA believes that the Agency review should go ahead even though there is an unresolved legal taint • CESG notes the BOF proposal to move the ECSS “PUS” standards into CCSDS: • The PUS standards need updating to reflect the overall updating of the underlying Packet books that has taken place in recent years • The proposal is for CCSDS to undertake that updating • The CESG notes that a possible eventual end-state of the PUS will be to separate the mission operations services embodied by them from the underlying Space Packet Protocol, in which case those mission operations services may become part of the SM&C suite • Elements of the CESG advocate that the ECSS should first update the PUS, then separate the mission operations services and then introduce those services to CCSDS via proposed extension of the SM&C services. Other international agencies should also be encouraged to bring forward their spacecraft monitor and control approaches for potential standardization. This strategy would also allow time for the overall CCSDS service framework to be clarified. • Such a move would also have impact on SOIS services, which would require updating.

  19. CESG General Issues/Concerns [3] • CESG strongly advocates that CCSDS needs an overall reference architectural framework into which all of its work can be aligned in terms of services and standards, and that it also needs a consistent way to express how those services should be defined and specified. CESG recommends that the CMC should endorse the “way forward” proposal made by the CSS Area: • CESG notes that this activity is likely to need temporary redirection of resources from several information architecture-related activities in MOIMS and SEA, including SM&C • Current work cannot totally stop • Question of where eventual WG would be located? • CESG Chair files a “friend of court” brief that – as the major stakeholder in the outcome – SM&C should be given this job Team-1: Services, Scenarios, Framework WG Formed May 09 WG Concept Team-2: Service Definition Technology 28 Feb 10

More Related