[Css-rasg] Notes from Telecon today (10 Dec 2009)

[Roger Thompson]

Erik,

 

Apologies for not being able to attend the telecon on 10th December.

I've had a look through the inputs to the telecom, and the inputs
provided since by DLR and CSA, and have additional inputs on the Mission
Scenarios (below) plus some general observations/queries on the intended
approach.  On the latter, I apologise in advance if these cover issues
already addressed in the telecon.  I will attempt to keep 20th January
free so I can join the next meeting.

 

Given the proximity to the festive break, I've not had a chance to
coordinate this response with other members of the SM&C WG.  They may
wish to add some additional points in due course.

 

Best regards and Merry Christmas,

 

Roger

 

Mission Scenario Identification

 

Others have already noted the lack of coverage of non Deep Space
missions, but this is largely addressed in CSA and DLR inputs.  I would
suggest there are two distinct dimensions to unmanned mission
classification: orbital characteristics (which affect space-ground
communications) and mission type (which affects the data to be
exchanged).

 

On the orbital characteristics side we have:

-          Deep Space

o        General

o        Mars Orbit

o        Lunar Orbit

-          Earth Orbit

o        Geostationary

o        LEO Polar

o        LEO Equatorial or Inclined

o        MEO

o        HEO

-          Lagrange Point

 

On the mission type side we have:

-          Communications

o        Earth-to-Earth

o        Space-to-Earth

o        Space-to-Space

-          Navigation

-          Earth Observation

-          Astronomical Observation (Telescopes)

-          Science

-          Exploration (planetary missions)

 

I would note the increasing need for coordinated flight - constellations
or formation flying for some mission types.

 

The Operational Scenarios currently identified seem to focus on mission
phases, but it is also useful to identify the characteristics of
different mission types during their nominal operations phases.
Particularly for Earth Orbiting missions this can have a significant
impact on the ground segment:

-          Some missions (EO and Science) are conducting a repetitive or
systematic survey, such that operations are largely driven from overall
mission objectives rather than individual requests from end-users.

-          Others (EO, Science and Exploration) may have a much more
interactive operations planning cycle that involves the user community
directly.  For this group, open planning request and data delivery
interfaces are important.  Depending on the type of mission, the user
community may consist of science Principal Investigators (academic
institutions); international, national and local government
departments/agencies; NGOs; and commercial entities.

-          The data processing systems for many EO missions requires
ancillary data to augment/calibrate the data acquired from the
spacecraft.  This data may be provided by external agencies or sensor
networks and includes meteorological data, ionospheric modelling and
other space weather data.

 

Another key issue for the mission scenarios is who owns what.  Many
missions are collaborative ventures and make use of existing
infrastructure and services offered by other agencies and commercial
entities, as well as other space missions.  I'm not sure how we capture
this, but examples include:

-          Ground Station networks (other Agency, or commercial entity -
e.g. Norwegian KSAT that operates high-latitude ground stations on
Svalbard and in Antarctica used by many EO missions)

-          Launch Providers

-          Communications Relays (e.g. Mars orbiters)

-          Ancillary/Auxiliary Data - Orbit Tracking, Met Data, Space
Weather Data

-          Spacecraft Manufacturer (provides operational configuration
data to Operating Agency and may require TM history to support anomaly
investigation)

-          Experiments, Payloads, Probes, Landers, Penetrators etc.,
which may be provided by one agency but flown on a spacecraft operated
by another.

-          Derived Product Generation (and Distribution) - in the
Meteorological and EO communities it is common for there to be multiple
organisations (international, national and commercial) involved in the
development of products and services based on core mission data.  In the
humanitarian aid / disaster response area this includes both agencies
and NGOs with deployed in-field assets, where there is a need for
international collaboration.

-          Data Centres that provide restricted or open access to data
provided from multiple sources.

 

Another area of data communications that does not seem to be covered by
the existing scenarios is Voice and Video data.  CCSDS has had several
requests to consider how Voice and Video can be incorporated into
standards.  Clearly we should identify services to support
communications interfaces of this type, but it is not immediately
apparent how this will fall out of the mission scenarios or use cases
currently identified.

 

Another mission scenario is that of Space Situational Awareness,
concerned with monitoring of potential hazards in the near-Earth space
environment.  This includes tracking of operational spacecraft and space
debris in Earth orbit; monitoring and prediction of space weather;
monitoring of Near Earth Objects.  This requires federation of national
and international assets, including terrestrial sensor networks and
space-based missions to provide coherent data sets as a service to space
(and non-space) users.  Existing services are offered by organisations
such as NORAD and NOAA/SWPC.  In the future there may be increased
international collaboration in this area (c.f. ESA SSA programme).

 

 

 

 

General Observations

 

I apologise that I was unable to participate in the first telecon of the
BOF, and so may have missed the full intention of what it is we are
trying to achieve.  If we succeed in developing a comprehensive set of
mission scenarios, I am not sure how we intend to move from this to
identify the set of "services" we are aiming to define.  We should be
very careful not to explode the number of services based on minor
variations between different types of mission and different mission
phases.

 

We should also be careful to consider where the boundaries are between
distributable functions, so as to focus on those services which are
likely to be exposed at key deployment boundaries.  This probably also
requires us to model the enterprise structure of space missions to
understand where "open" interfaces are needed.  We should also not
forget data persistence in this consideration - if data is to be held
long-term and accessed/interpreted by systems other than that which
stored it, there may also be a need for "open" interfaces.

 

We also need to identify the difference between protocol layers, as
clearly CCSDS standards operate at different levels.  We should
recognise that full interoperability is not achieved simply by data
exchange, and that for key information exchanges, the semantics of that
exchange must also be standardised.  The latter is mostly relevant to
the SM&C and CSS Service Management standards at present.

 

If I look at the current set of mission scenario inputs, I lack a clear
vision of what the communicating functions are and where they may be
deployed.  Conversely there is a lot of repetition - similar topics
appearing in different scenarios.  I do not see how we can go directly
from this list of mission scenarios and their operational phases to
service identification.  At the level we currently have, the use cases
are essentially too high-level and non-specific to identify the actual
information exchanges that are required.  The derived use cases that
have been identified are closer to the mark, but it is not entirely
evident how we have identified these from the mission scenarios - a
criticism that was levelled at SM&C for making much the same leap of
faith.  It is not that I disagree with the use cases identified (there
is a reasonable match to SM&C), but I don't see that the derivation is
properly justified, or that some of the use cases identified will
necessarily lead to the identification of specific interface standards.
Many operations can be normalised down to planning, scheduling of a
defined operation and subsequent execution of that defined operation (by
issuing control directives and monitoring status)

 

My suggestion is that we should be using the mission scenarios to derive
a generic reference architecture of (very high-level) distributed space
system components that recognises the distribution boundaries enforced
by a) the physical reality of mission centres / ground stations /
spacecraft / relays / landers / rovers and b) the organisational
(enterprise) reality of multiple agencies / manufacturers / operators /
users.  To some extent, I think this may be an extension of Adrian's
famous slides that show some of these entities already.  The reference
architecture then becomes a generic "worst case" system that has every
possible element within it.  It should be possible to map all the
identified mission scenarios to this.

 

We are really concerned with standards exposed at the boundaries between
the elements identified in the above reference architecture.  This can
be addressed in two ways:

 

-          considering the data communications standards applicable
across a boundary (protocol level) - the focus here is on space domain
specific communications links

-          considering the application level information exchange
standards applicable across a boundary (semantic / service level) - the
focus here is on a space domain specific information model

 

>From the distributed reference model, we should map where the providers
and consumers of different types of information could potentially
reside.  This will show across which boundaries that information
exchange may be exposed.

 

We should seek to identify the different types of information exchange
exposed at these distribution boundaries and seek to reduce the number
of these to a manageable set for which standards could be defined.  This
should recognise that the same type of information exchange may be used
to support different interfaces and minimise specialisation for specific
interfaces, while at the same time not reducing these to totally
generic, semantic-free data structures.  That is not to say that data
(or message) exchange protocols, such as packet, messaging or file
exchange, don't have their place - but they only apply at the
appropriate layer of the protocol stack.

 

Once we have identified this in our reference model, if we also include
protocol layering, I think we will then be able to map CCSDS standards
to particular interfaces or end-to-end information exchanges on such a
model.

 

One area which I am not sure will really be addressed by this point is
SOIS, as this applies within a single space-based node.

 

At a first stab, I would say the reference architecture distributed
elements would need to include:

 

Ground elements:

 

[Mission or Platform] Operations Centre

Payload Operations Centre (or other subordinate operational entity -
typically a different agency/organisation to the former)

Operations Team (people within Operations Centres)

Ground Station [TT&C and Payload Data Acquisition - may be separate for
some mission types]

[Ground Station] Network Operator [possibly a separate service provider,
responsible for Ground Station utilisation planning - may be used to
support specific mission Phases, e.g. LEOP, or to support multiple
missions - such as high-latitude ground station services for LEO/EO
missions]

[Operations] Data Archive

[Science] Data Processing Centre

[Science] Data Archive

[Science] Data Distribution System (may be terrestrial or use a separate
satellite service - e.g. world-wide Meteorological Product distribution)

User Organisation (ultimate recipient of Science Data/Products - and
potential source of user requests)

Spacecraft [or Payload] Manufacturer

Launch Provider

Ancillary Data Provider - many EO systems require ancillary/auxiliary
data input from external sources (e.g. terrestrial meteorological or
space weather data) to support their data processing and operations

In-field/Transportable Stations - applicable for data/product
reception/provision for some classes of mission - e.g. Disaster Response
(also Military, but assumed outside of scope)

Sensor Networks/Stations - may be applicable for some mission classes
(satellite navigation, space situational awareness, meteorology)

Complementary Network Provider - for some mission classes may be
possible to support some space-ground communication via a complementary
satellite network, such as Iridium or Globalstar

 

Space elements:

 

Spacecraft - may need to consider classification in terms of orbital
characteristics as this will affect space-ground communications:

            Earth Orbit:  LEO, MEO, HEO, GEO

            Deep Space

Constellations / Multi-spacecraft missions / Collaborative missions -
there may be special cases of communication to be considered between
spacecraft in certain scenarios.  This includes - transfer vehicles and
docking [space station, manned exploration];  formation flying /
multi-part observatories;  inter-satellite links (within plane,
inter-plane); and orbiter-lander communications.

Payload on Spacecraft

Astronauts

Communications Relay (Earth Orbit, Mars/Lunar/Other Orbit, Surface
Deployed)

[Communications Relay] Network Operator - as for Ground element, but for
space-based assets

Lander (fixed surface asset)

Rover (mobile surface asset - could also include aerobots/balloons)

Positioning System - currently for Earth orbit only

 

Interfaces / Services:

 

When the communications between these entities is considered, this
should help us identify:

-          Data Communications needed across space links

-          Information Classes exchanged

 

For the latter, I would expect this to be rationalised to a relatively
small set of "services", probably including:

-          Status Monitoring and Commanding/Control of any other element

-          Schedule/Timeline/Activity List  Update and Reporting of
autonomous elements

-          Automated Process/Procedure Invocation/Execution Reporting
(Automation Service)

-          Planning Requests (end User and Operations)

-          Contact Planning / Service Management

-          Position/Navigation related information (Position, Tracking,
Ranging, Orbit, Attitude) between different elements - note this may
apply to both controlled spacecraft and non-cooperative targets, and
that the sources of such information could come from multiple sources,
including spacecraft, ground station, payload data processing functions,
sensor networks

-          Time Synchronisation

-          Payload Data (maybe specialisations for Image data, etc.) -
unprocessed (Raw/Level 0)

-          Payload Data Products - processed (Levels 1b, 2, 3)

-          Observation Reports (short time-stamped measurement datasets)

-          Video

-          Voice

-          Asynchronous Human Interaction (Messaging and Response)

-          M&C Definitions (Spacecraft Database/MIB)

-          Spacecraft Dynamics Definitions (Flight Dynamics Static Data)

-          Operations Procedure Definitions

-          On-board Configuration Data Distribution/Management (e.g.
On-board Procedures)

-          On-board Software Distribution/Management

-          Security Device and Key Management

 

This in turn will require a smaller set of interaction patterns deployed
over data transfer technologies supporting:

-          Data Streaming

-          Video/Voice Streaming

-          Asynchronous Messaging

-          File Transfer

-          Store and Forward

 

 

________________________________

From: css-rasg-bounces at mailman.ccsds.org
[mailto:css-rasg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J
(317H)
Sent: 11 December 2009 01:45
To: CCSDS RA BOF
Subject: [Css-rasg] Notes from Telecon today (10 Dec 2009)

 

CCSDS RA BOF Colleagues,

 

Thank you all very much for attending the initial telecon today. Below
are the notes and action items that I captured at the telecon. Please
provide any corrections, indication of omissions, etc. that you think
are appropriate.  The action items have also been captured in a
spreadsheet and uploaded to the CWE (CWE Private --> Action Items).  

 

With regard to the native Mindjet file and the XML version both of those
have been uploaded to the CWE under the Agency Inputs folder, NASA
inputs.  Also, I have initiated contact with Dan who is leading the
effort for the SOA for space concept paper and plan to speak with him
more about this in the near future.

 

In closing, a quick request: please let me know if you see any issues
with advertising to CESG/CMC that the scenario identification and
recommendations list will be available by late January; I hope we can
finalize this at the 20 January 2010 telecon.

 

Best regards,

 

-Erik

 

 

----Telecon Notes---

 

Attendees:

 

E. Barkley

N. Champsavoir

Y. Doat

S. Gully

L. Hartman

P. Melanson 

 

Agenda:

 

*         Brief review of BOF formation material

*         Plan re near-term deliverables

*         Brief review of various internal agency efforts re CCSDS RA to
date

*         Tools/techniques re development of the concept paper

*         Concerns/issues that BOF members may have

 

Review of Agency Inputs

 

*         NASA Scenario Inputs: Low Earth Orbit/Earth Observation
robotic need to be better represented

*         Some summary information re classification/taxonomic indices
should be stated

*         All agency participants agreed to provide inputs re agency
scenarios by end of year

 

Recommendations List

*         Agreed to develop a sample diagram showing a
relationship/overlaps among a representative set of the recommendations
as part of the concept paper

 

 

Enterprise Model/View

*         Agreed to develop a sample enterprise diagram/sketch from a
CNES perspective

 

Concept Paper Development

*         Agreed to develop draft table of contents for concept paper

*         C.P. development needs to be coordinated with SOA for Space
activity that D. Crichton is leading; concept papers need to complement
each other with Ref Arch, indicating where "SOA for Space" fits

 

Comments/Concerns Discussion

*         Lack of extensibility re CCSDS recommendations noted;
presumably the reference architecture will help to inform recommendation
developments in this regard

*         Scope of concept paper re adjustment and fit of WGs:  agreed
that this effort would focus on concept re development of a CCSDS-wide
reference architecture and leave the question of working group
(re-)organization/re-programming as a subsequent matter for CESG + CMC. 

 

 

Next Telecon 

20 January 2010

 

 

Actions Items:

 

AI #

Status

AI

Assignee

Assigned Date

Due Date

AI Response (if applicable)

001

Open

Supply a couple of summary sentences re taxonomic/major branches in NASA
scenarios inputs

E. Barkley

10-Dec-09

18-Dec-09

 

002

Open

Provide CNES agency scenario inputs

N. Champsavoir

10-Dec-09

18-Dec-09

 

003

Open

Provide CSA agency scenario inputs

L. Hartman

10-Dec-09

18-Dec-09

 

004

Open

Provide DLR agency scenario inputs

S. Gully

10-Dec-09

18-Dec-09

 

005

Open

Provide ESA agency scenario inputs

Y. Doat

10-Dec-09

18-Dec-09

 

006

Open

Provide updates on NASA agency scenario inputs

E. Barkley

10-Dec-09

18-Dec-09

 

007

Open

Produce an example UML (probably class diagram) showing a sample of
relationships between CCSDS recommendations

E. Barkley

10-Dec-09

13-Jan-10

 

008

Closed

Send out "native" .mmap + xml file for use in capturing  scenario
identification information

E. Barkley

10-Dec-09

10-Dec-09

Uploaded to CWE (under ActionItems folder)

009

Open

Develop and circulate preliminary draft enterprise model sketch for CNES

N. Champsavoir

10-Dec-09

18-Dec-09

 

010

Open

Develop draft TOC for concept paper

E. Barkley

10-Dec-09

18-Dec-09

 

011

Open

Contact D. Crichton re coordination of SOA-for-space concept paper
development

E. Barkley

10-Dec-09

14-Dec-09

Contact initiated; more information will be supplied.

 

 

 

 

 


SciSys UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
 
* Before printing, please think about the environment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-rasg/attachments/20091223/dfabb843/attachment-0001.htm