US COMMENTS ON MISSION OPS CONCEPT GREEN BOOK
Original comments are shown in black; responses in blue italics.

It is noted that following the receipt of these comments, discussions were held at the CCSDS Workshop in Atlanta, and it has been agreed that there will be a major revision of the Green Book to make it more succinct, more accessible and also to remove detail which should only appear in blue books. A draft TOC for the revised document is also provided with these responses.

Within the working group, it has also been agreed that the current naming of the SM&C Common Layer does not adequately present its intended role. An alternative name will be adopted in the revised Green Book – suggestions include Mission Operations [Service] Bus and Mission Operations Framework.

_____________________________________________
US REVIEWER 1:
I couldn't get through the entire 155 pages in detail, however, I think I've read enough to say that I find it too prescriptive. One would have to "standardize" a whole heck of a lot of the s/c flight and ground segment to be compatible and I'm not sure the trade for inter-operability would be worth it. I do agree with the consumer/producer concept, but I can't really say that they've covered every function needed in mission ops.

It was never the intention to come across as so prescriptive, it was always intended that an agency/vendor should be able to pick and choose which interfaces to adopt based on mission requirements and legacy systems. Also, it was never expected that all interfaces would have to be adopted at once: evolution rather than revolution.

A given agency or vendor may well have existing solutions that encompass several of the functions identified. Adaptors can be built for such legacy solutions at those service interfaces which are exposed at interoperable boundaries or to allow flexible re-use in conjunction with other components.

With respect to completeness of the service set identified, it is also the intention that the framework should be extensible. The addition of services is made easier by the layered approach, as new services can build upon the common service infrastructure.

The revised document will make efforts to ensure that this is clearly demonstrated.
You are probably familiar with our "plug and play" approach... basically a pub/sub middleware bus which any component can "plug" into either directly (if architected to use the bus from the get-go), or via an adapter. Any component on the bus can exchange information, products, etc. with another component. We're currently looking at integrating the flight segment/software bus via a gateway (since flight constraints don't allow all the functionality available to the ground). Anyway, I think this approach is better suited to interoperability because it gives engineers the freedom to build the most efficient components for their mission and still be able to communicate. (Of course there are other technologies/standards that would go along with this...i.e. XML-type databases, etc).

This approach is exactly what was supposed to be outlined in the green book, but obviously that is not the case. The layered approach provides basic communications patterns at the common layer, isolated from the underlying implementation. The higher level mission operations services offer standardisation of some of the most common operational interactions – as an enabler to interoperability and re-use. It is recognised that the current book is too focused on these higher level services.

The update will ensure that the layered architecture is clearly presented.
I can't say CCSDS should reject this, I can only say I doubt it would appeal to my organization.
_____________________________________________
US REVIEWER 2:
Though the basic premise of this concept is sound, the examples provided for the functional and informational views are represented in such a way as to force the direction of this effort in a prescriptive way. My comments come from my experience primarily in these two areas.
1. Initially a set of proposed services are identified, and then a set of functional and information objects are exhibited that try to fit into the mold of the predetermined set of services. But the initial set of proposed services all violate the initial premise that a service is an operation, or set of operations, and does not depend on the state or context of another service. The context of the proposed services are so broad that they are all interdependent on one another.

While the current document may not present this well, the actual approach adopted was:

to identify the major functions of a mission operations system (space or ground), paying particular attention to potential distribution boundaries (space/ground; geographical site; server/client)

identify the information exchanged and operations performed across inter-functional interfaces and identify commonality across multiple interfaces

identify services based on common information types and operations patterns

A given pair of functions may use multiple services in their interface.

Some services are hierarchical in the sense that a function can be a consumer of one [lower level] service and provider of another [higher level] service

2. Going on to the functional viewpoint, the example mixes various what I call *macro* and *micro* functional items. What I know from experience is that when you mix these two types of functional items, you begin to prescribe a specific architectural view whether or not that is your intent. That’s why that even though I consider myself well versed in understanding mission operations functions, writing functional requirements is still a very difficult task for me. I have preconceived notions of how things should be and that biases my view. What this has let me to determine is that the only way to come to some consensus on *standard services”* meeting the going in definition of such, is to break operations down into it’s component *minor* functions and then see what services may apply.

The point is taken. However, we also note that the service framework should not be overly prescriptive. We have sought to identify a relatively loose framework that is pitched at a level of granularity of some 10-20 services. If standardisation is too fine-grained, then it both imposes an architectural solution on the implementation of functions, and offers too many possible standard interfaces – defeating its objective.

3. So what do I mean by this. Let’s take the example from the document’s Figure 3-6 regarding a Flight Dynamics Planning Request. First question I have, based on the example functional view on page 3-6, is if this is a Flight Dynamics function or a Planning function? The example in Figure 3-6 assumes it’s a Flight Dynamics function. However, here this is a Planning function. That’s why looking at functions at the macro level causes problems. In our approach, Planning (in this case payload planning) would send the maneuver request to Flight Dynamics (in this case navigation planning), who would forward the request (a quaternion) to Schedule Execution (which actually crosses many functional boundaries) to Automation (I don’t even know why this is included - this is implementation detail, not functional) and M&C (mission control), which interact. What instead I see is a micro function which is Maneuver Planning which takes a maneuver request (regardless of what function generates it) and fulfills it. Now you can speak of services, however I find that now services become hardware specific. I.e.: I could have a maneuver request service for a three-axis stabilized craft with a certain stable of hardware components. However, this service is usually a flight software function specific to a certain spacecraft design, the request function being handled by the scheduling of the quaternion that was generated based on the request.

The specific point on Flight Dynamics is well made. This represents an area which has not been high on the priority list for standardisation, and as a result the “Flight Dynamics” service is currently more of a placeholder.

The approach to Manoeuvre planning you describe seems to be an implementation fully in line with the set of services proposed. Your FD function accepts [manoeuvre] planning requests and fulfils it (through M&C or Schedule service presumably). An alternative implementation is that an FD function initiates and plans a manoeuvre, but then integrates this into the mission timeline by raising a planning request to a Mission Planning function. The system architectures are different, but common service definitions can be used.

4. So I think that to take on the task of defining a set of Standard Mission Operations Services will require a breakdown of mission operations functions into a set of generic micro functions. Once that task has been completed, then a look at them to come up with specific Services that might be able to be standardized could be attempted. Until that is done, I think any attempt, and especially a top down approach, will result in a prescriptive implementation.

This is a single response to all the points given above:

The new updated book shall make it very clear that the proposed architecture is a plug & play component architecture that must allow deployments in configurations to suit a particular mission/agency. The interfaces are designed to be generic which may require minor changes to a particular work flow, but will not require major changes.

_____________________________________________
US REVIEWER 3:
GENERAL:
- liked the general idea of a layered architecture and thought that the concepts aligned with what we are doing in our new architecture

Good

- we're already doing our own interoperability interface
- we would not adopt these because of that

This is understandable, but we hope that a standard would be more interoperable than a bespoke interface. Furthermore if your system uses a similar approach, it should be relatively simple to build an adapter to the standard interoperable interface should you need this at a later date.

- we would not adopt the internal functional component interfaces in any event

There is no intention to prescribe internal interfaces – merely to offer a standard where such an interface is exposed (for re-use or interoperability).

- we would probably adopt any interoperability interfaces that were standardized if they were generally useful

That is the goal of the work

SPECIFIC:

These specific issues will be taken into account during revision of the Green Book.
Section 2.3 Figure 2-2 seems to be missing the ground component (ground nodes) of the data management. But, in general, I do not see a coherent data management approach throughout the document. See my comments below for section 4. It is also difficult to tell if figure 2-2 portrays the role of analysis in planning spacecraft activities and its role in analysis after the fact to perform actual vs. plan and feedback to planning process.

Data Management: we agree that the Green Book is confused here, the role of history and temporary buffers ought to be separated. This will be clarified in the revised book.

Analysis and Planning: the interaction portrayed is that of operations being initiated (via planning) as a result of post-hoc analysis. Feedback to Planning of the execution status of planned operations is foreseen as part of the Schedule service.
Section 2.3 speaks of spacecraft monitor and control as if it is a set of totally generic functions and capabilities to be advertised, then discovered and used over a common protocol layer. As an example is there a real need for an information base that defines the capabilities of various devices?

This approach allows software to be made generic and configuration (the information base) determines the specifics at run time.

Page 2-7 Migration of services from ground to space needs to consider the timeliness requirements. Not considering this aspect greatly impacts client functions especially for longer one-way light time missions.
Section 3 and in particular page 3-15 seems to describe a well-known layering of communication protocol (stack) that has been in use for many years (decades).
Section 4 page 4-9 Description of service objects are not clear defined/explained.
Section 4.2.2 (M&C domains) is a great idea, but I am not sure of its practicality in terms of the bandwidth requirement especially for uplink. Requirements to qualify even simple commands with agency identifier, mission identifier, satellite identifier, etc. could drive the requirements for bandwith.

This is indeed an issue that must be taken into account. This may be addressed if part of the information context can be implied by the connection.
Section 4.4.2 describes invocation of an action, but is not clear as to the interface with the planning and scheduling and how the invocation of an immediate action would impact the remote system especially in the middle of a pre-planned plan/schedule.

The point is that it may be the Schedule Execution function that is the consumer of the Action service. Whether other functions may also be Action sources in parallel with the schedule is an issue for mission specific deployment and configuration – the concern is understood, but we are aware of systems that allow multiple command sources.
Section 4.4.4 talks about buffered data, section 4.4.5 talks about historical data and section 4.10 talks about data product management, but I do not see a common model of data management that spans the ground and space asset.

This is confused. We have concluded since the Green Book was published that History and Data Buffers are two distinct issues. Two distinct Operations Patterns have been identified – one Event-based and one Product (File) based. This aspect will be addressed in the revised Green Book.
Section 4..9 remote s/w management has a lot of parallels with local or ground s/w management system and should be managed by the same process. I did not see this mentioned.

The current service is focused on the specific issue of managing remote [on-board] software, which at least in current systems is dissimilar to that of ground software management. The point is noted, however, and should be considered, maybe as a future extension?
__________________________________________________________
US REVIEWER 4:
GENERAL:
We have a top level concern that if the work that is proposed in the SM&C WG goes forward that little of it will be of use to our community because it just does not align with the way we do business and also that it attempts to standardize interfaces that are internal to our systems. At the same time it fails to address interoperability and cross support interfaces that we and our external mission clients would find of use, both in our current and future mission set. If the focus of this work were changed to one that better supported such interoperability and cross support interfaces it would find more ready support within our organization. As it stands it is very difficult to provide much in the way of support because the product lacks relevance for us and appears to be draining resources from other standardization activities that would appear to have benefits for interoperability and cross support.
1. At the very highest level one concern that we have is that this document reads like a Reference Architecture and framework specification rather than a mission operations and services concept. Right at the outset the documents states this. Sec 1.1 "presents a set of concepts, reference architecture, and service framework for spacecraft monitoring and control". As such the document probably should not have been processed as a Green Book.
2. The document contains far too much detail and at a variety of different levels. It also reads in a very prescriptive way, i.e. define these service elements, with these interfaces, that carry out these actions, interact with these other functions, and provide these results.
3. The document describes both services that are appropriate for inter-agency interoperability and services that are designed to support software interoperability, i.e. interfaces between software components in a single deployment. The bulk of CCSDS activities are designed to develop interfaces and protocols at various layers of the stack that support inter-agency interoperability and cross support. This is the case with all of the lower level communications standards (rf, coding , modulation, link layer, networking, file delivery) and it is also the case with the SLE services and the bulk of the data exchange specifications (Nav, SFDU, packaging). This is not to say that these specs cannot be used for intra-agency purposes, but that they were specifically designed to allow agency facilities to interoperate.
SOIS was the first of the significant attempts to define specifications that had a more intra-agency application, within a single spacecraft. Here too, these specs can be relevant for inter-agency support (your instrument, my spacecraft), but this does not really seem to be a strong driver. SOIS has had a very tough time coming to closure on any of its specifications. To date, after more than five (5) years of meetings they have yet to publish a single document. I believe that one of the reasons for this difficulty lies in the fact that they are trying to define cross-cutting standards for what are essentially agency internal design and engineering issues. Any standard that emerges is likely to be implemented as a local matter and any interoperability of the type mentioned is still likely to be governed by a specific MOU and ICD for the specific interfaces.
4. While it is easy to identify elements of the territory encompassed by the SM&C concept that might be good candidates for standardization I am highly skeptical about the likelihood of much of it being adopted by many agencies. The primary reasons for this are these:
- it tries to standardize interfaces that are normally defined as internal to specific implementations
- it defines processes that do not align with our space operations
- we already have a strong, existing, multi-mission software system that defines its own internal interfaces and has a different functional decomposition
- it fails to define useful specifications for interoperable services and data exchanges that are likely to be adopted
For background, consider our current practice and functional breakdown:
a) many missions are contracted out to primes, for cost saving reasons they typically specify their own flight S/W, command processes, and file management processes

If there are specific standards that commercial companies can align to they will. It is in their interests to support these standards as it allows them to sell to a wider market.
b) some missions are built in-house, these are usually one of a kind, never been done before, sorts of missions and they typically specify their own flight S/W, command processes, and file management processes

It is the mission that is bespoke, why does all the software have to be? The answer is that it doesn’t. Large cost savings can be made due to software reuse, less training, etc with standard ‘internal’ interfaces. The approach is nevertheless open to extension, allowing more novel concepts to be integrated within the same overall approach.
c) standardization is required at the CCSDS link level and below, and missions are directed to use CFDP if they are doing file transfers, no other command or telemetry standards are imposed
d) missions contract for and plan for ground comm assets months to years in advance (no planning standards yet)

Ok.
e) missions plan for comm passes weeks to months in advance (SLE SM/SR coming)

Ok. The MO Service Framework does not conflict with SLE – SLE SM could be considered a high-level MO Service; but the transfer services exist at a lower protocol level.
f) missions develop command sequences or various kinds months in advance to the day before a command uplink is to be done

Ok. Other agencies and operators may also perform adaptive commanding in real-time. The service framework should be able to accommodate all of these ways of working.
g) S/C and payload commands are integrated, translated into a command load file, and readied for radiation

The service interfaces are transport independent, your encoding policy would not affect them in any way.
h) command load files typically contain BCH coded binary command sequences, may contain hardware commands, often contain the same command sequence twice for reliability, CCSDS packets are not used on the uplink

The service interfaces are transport independent, your encoding policy would not affect them in any way.
h) software uploads are used, but these typically use either a patch of a file load and the mechanisms tend to be mission specific

The approach to software loads generally seem to be mission or at least or spacecraft bus specific. The lack of standardisation means there is always a mission specific configuration cost associated with this.
i) missions request services of ground assets prior to pass (SLE SM/SR coming)

Ok.

j) SLE CTU is used to send the command from the file to be radiated

Ok.

k) the commands are radiated 'in the blind", with no expectation of closed loop retransmission (COP-1) nor any immediate acknowledgment

This does not affect the relevant interface.
l) once command loads are correctly received and validated they are loaded for execution

Ok.
m) most S/C operate in a more or less unattended mode with no possibility of interactive commanding or immediate ground response to anomalies

This is also supported.
n) many S/C operate for 24 hours without a ground contact, some operate for longer than that, some do highly autonomous operations

Ok. The Planning, Schedule and Automation services are designed to support standardisation of interfaces at higher levels of abstraction which may be more appropriate for missions with a higher degree of autonomy. The Schedule service is appropriate for those executing a pre-defined mission timeline. The Automation service is appropriate for those executing on-board procedures or software functions.
o) downlink telemetry if usually sent via CCSDS packets, though missions are increasingly opting to use files and CFDP for both downlink and uplink

Ok.
p) - the functions of monitor and control, automation, command (schedule) execution, planning, software management, navigation (flight dynamics), time correlation, ranging and tracking (location), analysis, and data product management are all internal to our systems

They are internal to most agencies systems, but this closed architecture makes it more difficult to re-use components or share functions between cooperating agencies. A gradual move to the proposed standard interfaces would give much more flexibility in software reuse, i.e. internal interoperability, in the future. You do not have to adopt all at once. Initially, it makes sense to wrap legacy systems and consider adapting to the new standards at interoperable boundaries or where re-use is advantageous.
As you can see from this list there is little in the current way that we do business that aligns in any sense with what has been described within the SM&C spec. Even the legacy approach in Fig 2-6 does not map. You could say that we align with the layered model shown in Fig 2-6, but all of the service elements on the left hand side would be our multi-missions S/W, with adapters for whatever command and control requirements are imposed by the S/C developing organization and with a mission specific architecture on the S/C side.

We disagree, we think it aligns well it’s just that the current interfaces are bespoke. Your list is far too low level and detail specific, but if you compare the higher operations that are being performed then they match.

It is obvious that you would gain no benefit from changing your systems to these interfaces just for the sake of it, the benefit comes through gradual adoption over time giving much more software reuse and saving money on operator training.

However, these benefits seem to have been obscured in the details of the green book.
There are elements of this overall SM&C approach, as it is described, that might possibly be adopted here if the benefits were clearer to the missions. Those elements that might be adopted include the lowest level of SM&C protocol and possibly the core services. I believe that this has some merits and that it might be salable, but only if the case for that is made really clear. The case for defining the higher level services and interfaces is really weak from our perspective, largely because we already have our own multi-mission software that can be adapted for each new mission and that represents a major institutional investment over the years. This is now undergoing a re-engineering process to utilize current web based approaches, but it will still be focused upon the realities of our deep space operational paradigm.

It is for this reason that it has been agreed to re-work the Green Book to provide a better showcase for the Mission Operations service framework, and its layered architecture. It will also highlight the potential benefits of the approach.
Upon reflection I can also identify aspects of the proposed approach, which if the focus were changed, would likely have appeal our missions, our partners and the agencies which we support. The motivation for this analysis is to identify where there might be suitable interoperability interfaces identified that could be used for inter-agency (or even intra-agency) cross support. The following are offered for consideration:
This seems to be what we have been proposing all along – but perhaps not getting our message across clearly.
1. Data Product Management: Standard interfaces for uplink and downlink file delivery and cross support. Could be used for uplink command or S/W load file transfer and for downlink data and ancillary product file transfer. Could leverage standard secure FTP or define some new pub/sub / push interface for product delivery (we have such interfaces now that have been in use for years).

Exactly.

2. End to End Data Management: Define standard means for tracking observations from planning, thought uplink, to on-board execution, to downlink, to product delivery back to scientists. Supports end to end accountability. We have defined such processes on a mission basis, not clear if this can be standardized across missions or agencies, but it is a highly useful function that results in mission cost savings.

A very good suggestion.
3. Location: We already are working to define a CSS service to transport tracking and ranging data, An effort has begun to define Delta-DOR and no-regenerative ranging standards. These, coupled with the new CSS CSTS service to securely transport data seems adequate for our purposes. We also need SLE SM extensions to request these new service types.

But we also note that the Ground Station is not the only source of location data – with on-board GPS for many satellites in Earth Orbit, this information originates from the spacecraft itself.
4. Scheduling: The scheduling interfaces that our missions would value would be extensions to the CSS SM/SR interfaces to be used. These are in development. The primary future cross support interfaces that we believe will be of interest would be extensions of these exchange mechanisms for use in space. i.e. have a landed asset use an SLE SR to request future (or immediate, or next pass) services of an orbiter.

Agreed – this would need to be closely coordinated with SLE.
5. Flight Dynamics: We already have the NavWG efforts to define interoperable data exchange standards (including attitude), not clear that anything further is needed for cross support at this time. We do need the means to transfer these results, but CSS CSTS is expected to provide that.

It is agreed that there should not be multiple CCSDS data formats for the same class of information: it has always been the intention that those being defined by the NavWG should be used in the context of any Mission Operations services that transfer such information. It is also agreed that for transfer of tracking data between MCS and Ground stations or between agencies, CSS-CSTS should provide this.

However, this is not the full scope of information exchanges covered under the heading “Flight Dynamics”. It is accepted that service identification in this area is weaker than in others, as it was not rated as high priority, and this has caused some confusion. The grouping of functions referred to as Flight Dynamics includes: Orbit & Determination, Orbit & Attitude Prediction and Manoeuvre Planning. These sub-functions are providers not only of Orbit and Attitude vectors, but also predicted events; manoeuvre planning has a relationship with Mission Planning that may make use of other services (e.g. Planning Request, Schedule); and FD functions themselves may be subject to control by other functions.

6. Planning: The planning interfaces that our missions would value would be extensions to the CSS SM/SR interfaces to permit clearly formulated Service Level Agreements (SLA) , Detailed Mission requirements (DMR), and S/C comm configurations to be exchanged. These, coupled with extensions to the SLE SM/SR to allow planning requests to be made and future support to be negotiated / arbitrated without a lot of human involvement would be a real mission cost savings. None of this is yet in work. The primary future cross support interfaces that might be of interest would be extensions of these exchange mechanisms for use in space.
7. Software Management: Not clear how this can be standardized, though standard means for loading files and patches could be conceived of within the core services.

We agree, that’s probably as far as it could be standardised currently. Nevertheless even this would reduce the cost of MCS configuration for successive missions.
9. Automation & Interaction: not clear how any of this could be standardized. Workflow approaches are being considered internally, but these are really internal matters.

Workflow would always be a internal issue however the mechanisms for controlling the automation is fairly generic. This is particularly interesting for those agencies (often commercial and military) that operate large heterogeneous fleets.
10. Spacecraft / Mission Information Base: This is not proposed for standardization, but it could be. XTCE is a start at a part of this. perhaps a common information model could be developed, but it is not at all clear what benefit it would have for interoperability. The most important parts of any such model that matter for cross support are already being defined within the SLE SM/SR work.

Point accepted. In principle, each [Application Level] Mission Operations service has an associated element of the MIB, unless all service objects are fully defined within the service specification itself. For the SM&C Core service it is agreed that XTCE could form the basis for this, as it includes the identity and characteristics of parameters and commands [=actions] and we propose to include a reference to XTCE in the revised green book. Other services would require an equivalent, although it is noted that for the SM&C service layer, only information that is exposed to the service interface needs to be defined in the associated service configuration data – other information used for transport layer packetisation or derivation of service level information within the service provider does not need to be visible at the service layer. In principle the MIB should be layered in the same way as the protocol stack.
11. Service Directory: There is no proposal to standardize this within the SM&C work, but it is also a candidate for standardization. A reference architecture that could provide the blueprint for an interoperable framework has been defined in the IAWG Reference Architecture for Space Information Management. This define a way to implement that Registries part of MOIMS IPR along with the rest of the necessary elements. Perhaps MOIMS SM&C should work with the team that will define these specs to make sure that their needs for service (and other) registries and information infrastructure are met.

Directory services are covered in the Common services document.

3

US COMMENTS ON MISSION OPS CONCEPT GREEN BOOK

Sam Cooper

2005-10-03

Mario Merri

IHS