[CMC] Mission Operations Services Concept

[Hooke, Adrian J (9000)]

RE: SM&C WG: Telecon #57 - Minutes

Ø  GB: MM reported about the outcome of the CESG poll. One AD, Mr. P. Shames, has disapproved the updates to the GB.

Mario: I think that this comment misrepresents the depth of concern about the stated and unstated scope of the proposed "Mission Operations Services Concept". In fact, three Area Directors (out of six) have essentially disapproved this document and two others (SLS and SOIS) have abstained on the grounds that the document does not affect their Areas, when in fact Figures 2-2 and 2-6 in the proposed Green Book clearly shows that it does.

If you read the common essence of these three disapprovals (extracted and highlighted below) it is clear that there are serious unresolved issues about how this proposed Mission Operations Concept interfaces with the rest of the approved program of work of CCSDS. There are also larger overtones about whether this level of Application layer standardization is even operationally appropriate or feasible for international cross support, other than within homogenous local communities.

If you read CCSDS A02.1-Y-2, you will see that that the CESG is specifically responsible for:
a.                Providing the CCSDS-wide forum where the work programs of the Areas may be coordinated and synchronized in the context of an overall architecture for space mission cross support and the needs of individual customers.
b.               Reviewing the proposed composition and program of work of all new WGs in each Area to ensure that they are technically consistent, contribute to a cohesive set of CCSDS architectural concepts, properly respect the need for smooth evolution of the large installed base of CCSDS-compatible systems and are not otherwise disruptive to the needs of customers.

Clearly, major issues still need to be resolved before this concept can be considered technically "approved" by the CESG. I realize that this outcome is disappointing and discouraging to the Working Group, but it may be inevitable given the extreme breadth and ambition of the proposed concept.

I do have suggestion. The Inter-agency Operations Advisory Group (IOAG) "provides a forum for identifying common needs across multiple international agencies for coordinating space communications policy, high-level procedures, technical interfaces, and other matters related to interoperability and space communications". One role of the IOAG is to make recommendations to CCSDS concerning new needs for standardization. Perhaps the proponents of the Mission Operations Services Concept need to present it to the IOAG for their deliberation? The next meeting of the IOAG is in Rome from 22-24 September, so the timing may be right. As the CCSDS Technical Liaison to the IOAG I would be pleased to ask for agenda time for a presentation by you or Nestor, if you feel that this would be useful.

Best regards
Adrian
_____________
Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group
Space Communications and Navigation Office (7L70)
Space Operations Mission Directorate
NASA HEADQUARTERS
Washington, DC 20546-0001

CESG-P-2009-07-001 Approval of update to CCSDS 520.0-G-2, Mission Operations Services Concept

Approve with Conditions:  2 (33.33%) (Barkley, Durst)
Disapprove with Comment:  1 (16.67%) (Shames)
Abstain:  2 (33.33%) (Taylor, Gerner)

Peter Shames (Disapprove with Comment .......- Unresolved overlaps with other WGs (CSS (SM, CSTS), MOIMS (Nav, IPR), SEA (IA, Reg/Rep), SIS (CFDP, AMS), SOIS (message transfer service))  ...... The first issue of overlaps with other CCSDS WGs is a big one, and we keep returning to it over and over.  This is largely because the stated scope of SM&C is so broad, at an applications layer, but that it reaches down into other layers for "interoperability".    This fact, coupled with an on-going disregard for  (or ignorance of) working going on in other working groups, continually  raises problems.  As an example, the earlier SOIS / SM&C MOU failed to acknowledge the existing of CSS, a set of critical CCSDS interagency cross support service interfaces between the MOS and the ground comm system that implements the space links.  SM&C is currently asking why SOIS does not adopt the MAL instead of its own Message Transfer Service (MTS), which has been underway for years and is already aligned with AMS, a truly interoperable specification.  SM&C appears to now be embarking on a path to define their own file transfer service (instead of CFDP), radiometric data transfer service (instead of CSS), and monitor and control services (CSS again), all of which are define CCSDS interfaces.  They state that they are defining a Service Oriented Architecture (SOA), but have not really defined what this means and appear to be ignoring work long underway in MOIMS IPR and SEA IA WGs. ... I would approve this document only after all of these issues are resolved in a way that is consistent with the body of work already in progress in the rest of CCSDS.

Erik Barkley (Approve with Conditions):  ...  This tends to give the reader the impression that this is a direction that CCSDS is considering pursuing. And I think this tends to expose that we (CCSDS) do not quite have this properly factored into our overall program of work....  ...  to more vigorously coordinate the bodies of work involved, and in particular, I would suggest that many of the issues require a systems engineering focus within CCSDS.... presumably, the main output of all this activity is to standardize those very mission services identified in the concept book. But there is very little treatment of the services themselves and how they relate and how they actually furnish the operational capabilities that they are to standardize... With regard to the services themselves, there is no conceptual relationship identified.  For example, presumably there are strong relationships between planning requests, scheduling, and automation. But there is no information model offered in this regard and no discussion of service timelines leading from long-term planning to day to day operations.... there are several areas of overlap with other work areas in CCSDS.  ...  For example, there is discussion of "network zones"; to this reviewer this seems premature and largely dependent on the schemes designed for space internetworking addressing from the SIS area. As another example, there is discussion of directories, etc. as a common services/basis for the framework; I believe this would benefit from coordination with the development of the registry efforts in the SE area.  And similarly, TT+C providers perform planning and scheduling services that have an impact on mission operations and there is no statement of peer or hierarchical relationships of these services, for example, with regard to these services defined by the CSS area....   The concept document needs to read more comprehensively by a) stating conceptual relationships to closely related recommendations and recognizing where peer-to-peer relationships or hierarchical relationships etc. exist,

Bob Durst (Approve with Conditions):  ... This document is at a sufficiently high level of abstraction that it is difficult (for me, at least) to determine just where SM&C (the building) stops and the application layer protocols developed by the other areas within CCSDS begin. So I'd like to see some clarification about just what it is that SM&C feels is in scope and what is external to the SM&C work.  I believe that the relationship between this approach to supporting mission operation interoperability and the (application-layer) protocols and services being developed elsewhere within CCSDS needs to be clarified.  AMS is mentioned, as is CFDP, but only in "may be" terms.  (For file transfers between space and ground, is something other than CFDP seriously being considered?)  In particular, in section 4, Figure 4-4, is the "CCSDS AMS Encoding: Blue Book" the AMS specification being developed within SIS, or a *mapping* to the SIS AMS specification, with that mapping to be developed by SM&C? It seems important that the areas in CCSDS that are developing application layer protocols should both be clearly seen as *sources* of communication services to SM&C in this framework and as *recipients* of requirements from SM&C.  Figure 2-3 lumps two CCSDS Areas, one protocol, and "Other" under "Space Link Services", which makes me think that this piece of it wasn't really thought out much.  Although AMS and CFDP are mentioned in section 2.3.3 (a good thing), they aren't mentioned in the references, and the document really doesn't discuss much about how these protocols, or those of SOIS, might be used to support the concepts being described here. So my condition for approval is to clarify the relationship of the SM&C work described in this document to the activities (both currently ongoing and within the identified scope) of the other areas within CCSDS.












-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cmc/attachments/20090731/800a7b87/attachment.htm