[Moims-ipr] CESG- MOIMS (1) Resolution for the SM&C WG
Nestor.Peccia at esa.int
Nestor.Peccia at esa.int
Tue Oct 25 09:51:44 EDT 2005
CESG Chair
The following resolution has been approved by MOIMS and should be transmitted
to the CESG via a poll to seek its approval
NP
*******************************************************************
MOIMS-SMC WG-R-2005-10-006, Resolution recommending the approval of the new
roadmap for the SM&C GB
The MOIMS Area,
CONSIDERING that at the last CCSDS Workshop the SM&C WG took the action to
respond and take on board all relevant criticisms that were raised by some US
representatives on the SM&C Green Book on 10th Sep 2005 (see attached
e-mail). The matter was seriously discussed in Atlanta within the WG and with
a selected group of people including the CESG Chair, the MOIMS AD, P. Shames,
T. Yamada, R. Thompson and M. Merri. The agreed way forward was to re-work
the [already published] Green Book in order to accommodate the relevant
comments received.
The re-work strategy is:
o Limit GB size to 30-40 pages
> Move Use Cases to RBs
> Remove technical details (should not be prescriptive)
o Scope
> Explicitly address interoperability and cross-support
> More emphasis on approach (e.g. derivation of services)
> Clarify philosophy (e.g. handling of legacy systems, service/layering
approach, modularity)
and the work plan is (see also updated schedule in the SM&C Charter):
o Response to comments received:
> Internal draft 3rd Oct 05 (done)
> Teleconf: 12th Oct 05 (done)
> Back to CESG: 24th Oct 05 (done)
o Rework GB:
> Draft 2.1: 28th Nov 05 (distributed for wide internal review)
> Comments due 12th Dec 05
> Teleconf 20th Dec 05 to discuss comments
> GB to CESG: 30 Jan 06.
and RECOGNIZING that MOIMS needs confirmation that this is the right
direction, we would kindly request that the CESG provides the SM&C WG with
the "green light for the GB". This is to make sure that the already scarce
resources available are used in an effective manner and with little waste.
RECOMMENDS that the CCSDS Engineering Steering Group initiates a poll
addressing this Area request.
*******************************************************************
In order for the CESG to do this, please find enclosed:
- the SM&C WG response to the US comments
- the agreed preliminary ToC of the re-worked SM&C GB including highlights on
the content of each section.
(See attached file: SMC GB draft 2.0 ToC.doc)(See attached file: Response to
US Comments on Mission Ops Concept Green Book v2.doc)
"Adrian J. Hooke"
<adrian.j.hooke at jp To: Nestor Peccia <nestor.peccia at esa.int>
l.nasa.gov> cc: peter.shames at jpl.nasa.gov, Takahiro Yamada <tyamada at pub.isas.ac.jp>,
adrian.j.hooke at jpl.nasa.gov, "Jane K. Marquart" <Jane.K.Marquart at nasa.gov>,
10/09/2005 01:06 Mario.Merri at esa.int, Roger Thompson <Roger.Thompson at scisys.co.uk>
Subject: NEED A SUMMIT MEETING: Mission Ops Concept Green Book
Nestor: you asked for more specific comments on the Mission Operations
Services Concept Green Book. Attached is a set of "stream of consciousness"
comments that came out of a US-wide review of the document. As the NASA
Rapporteur for the SM&C Working Group, Jane Marquart will be representing
these views at next week's meeting in Atlanta. However, as time is so short I
can see no alternative other than to share these comments with you right
away, since clearly they represent a widespread discomfort within the US
community that the Green Book may not map well into their requirements. I
hope that Jane will forgive the "short circuit" here.
I have a dual concern:
1. As manager of the NASA Standards Program, it worries me that this Green
Book does not appear to be mapping well into the "way of doing business" in
the USA.
2. As chairman of the CESG, I want to see this work succeed and to satisfy
the requirements of many agencies. This work was exactly the reason that we
started the MOIMS Area, and it is critical that we proceed on the right
track.
Since the document is a mix of broad mission operations architecture, quite
detailed services definition and even the beginnings of several specific
technical specifications, I would like to propose that we schedule a "summit
meeting" between MOIMS (you, Roger, Mario, Jane) and SEA (Peter, Takahiro) to
figure out how to proceed.
I would suggest that we do this between 10:00 and 13:00 on Monday morning.
Could you folks support that?
Best regards
Adrian
US COMMENTS ON MISSION OPS CONCEPT GREEN BOOK
_____________________________________________
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.
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).
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.
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.
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.
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.
_____________________________________________
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
- we're already doing our own interoperability interface
- we would not adopt these because of that
- we would not adopt the internal functional component interfaces in
any event
- we would probably adopt any interoperability interfaces that were
standardized if they were generally useful
SPECIFIC:
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.
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?
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.
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.
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.
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.
__________________________________________________________
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
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
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)
e) missions plan for comm passes weeks to months in advance (SLE SM/SR
coming)
f) missions develop command sequences or various kinds months in
advance to the day before a command uplink is to be done
g) S/C and payload commands are integrated, translated into a command
load file, and readied for radiation
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
h) software uploads are used, but these typically use either a patch of
a file load and the mechanisms tend to be mission specific
i) missions request services of ground assets prior to pass (SLE SM/SR
coming)
j) SLE CTU is used to send the command from the file to be radiated
k) the commands are radiated 'in the blind", with no expectation of
closed loop retransmission (COP-1) nor any immediate acknowledgment
l) once command loads are correctly received and validated they are
loaded for execution
m) most S/C operate in a more or less unattended mode with no
possibility of interactive commanding or immediate ground response to
anomalies
n) many S/C operate for 24 hours without a ground contact, some operate
for longer than that, some do highly autonomous operations
o) downlink telemetry if usually sent via CCSDS packets, though
missions are increasingly opting to use files and CFDP for both
downlink and uplink
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
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.
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.
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:
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).
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.
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.
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.
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.
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.
9. Automation & Interaction: not clear how any of this could be
standardized. Workflow approaches are being considered internally, but
these are really internal matters.
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.
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.
______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: =?UTF-8?B?U01DIEdCIGRyYWZ0IDIuMCBUb0MuZG9j?=
Type: application/msword
Size: 33280 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/moims-ipr/attachments/20051025/00b707d6/UTF-8BU01DIEdCIGRyYWZ0IDIuMCBUb0MuZG9j-0001.dot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: =?UTF-8?B?UmVzcG9uc2UgdG8gVVMgQ29tbWVudHMgb24gTWlzc2lvbiBPcHMgQ29uY2VwdCBHcmVlbiBCb29rIHYyLmRvYw==?=
Type: application/msword
Size: 65536 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/moims-ipr/attachments/20051025/00b707d6/UTF-8BUmVzcG9uc2UgdG8gVVMgQ29tbWVudHMgb24gTWlzc2lvbiBPcHMgQ29uY2VwdCBHcmVlbiBCb29rIHYyLmRvYw-0001.dot
More information about the Moims-ipr
mailing list