[Moims-ipr] SANA BOF

Mon May 10 16:21:00 EDT 2004

Please find below the SANA BOF e-mail

----- Forwarded by Nestor Peccia/esoc/ESA on 04/05/2004 17:43 -----
     Peter Shames <peter.shames at jpl.nasa.gov>
     Sent by: cesg-bounces at mailman.ccsds.org
     30/04/2004 18:26

           To: moims-nav at mailman.ccsds.org, moims-ipr at mailman.ccsds.org, CCSDS
Engineering Steering Group - CESG <cesg at mailman.ccsds.org>,
smwg at mailman.ccsds.org, SEA-IA <sea-ia at mailman.ccsds.org>
           cc: SEA-exec SEA-exec <sea-exec at mailman.ccsds.org>, Peter Shames
<peter.shames at jpl.nasa.gov>, cmc at mailman.ccsds.org
           Subject: [CESG] Call for SANA BoF

Dear Colleagues,

During the recent re-organization a new CCSDS organizational entity was
identified, the Space Assigned Numbers Authority (SANA).  This was
described as follows in CCSDS A02.1-Y-2.  Restructured Organization and
Processes for the Consultative Committee for Space Data Systems. Yellow
Book. Issue 2. April 2004:

> 1.4.6 Space Assigned Numbers Authority (SANA)
> The core registrar for the CMC?s activities is the SANA. Many space
> mission
> protocols require that someone keep track of key protocol numbering
> assignments that were added after the protocol came out. Typical
> examples
> of the kinds of registries needed are for Spacecraft IDs, protocol
> version
> numbers, reserved APIDs and SFDU Control Authorities. The SANA provides
> this key configuration management service for CCSDS. The CMC approves
> the organization that will act as the SANA. Its public interface is
> focused
> through web-based services provided by the Secretariat.

There have been several side discussions in different venues about how
this SANA might work, what it might contain, where it would live, and
how it might be implemented.  We feel it is time for us to formulate an
approach to providing this service and to develop a rapid prototype of
such a service.  The SEA has agreed to act as a system engineering
focal point for this work.  There are several WGs within CCSDS that
either have concepts, content, or are stakeholders in this effort,
including SEA-IA, MOIMS-IPR, CSS-SMWG, and MOIMS-NAV.

Members of these, and other WGs, are invited to participate in this
initial BoF discussion.

Meeting Call

SANA BoF
Wednesday, 12 May 2004

Location TBA (one of the downtown hotels)

Please indicate if you will be able to attend or if this night is not a
good one for you.  We will update the CCSDS meetings web page so that
you can sign up for this on-line.  Send this message along to any of
your colleauges that you believe might be interested.

In order to get these discussions off to a fruitful start I have
drafted a rough Charter for this new BoF.   You will note that this is
somewhat broader than the original description provided in the
Restructuring document.  This is due to the discussions mentioned
earlier, which identified a number of other items that could usefully
be included in any CCSDS core registry of widely referenced objects.

We would like to define this service as broadly as will be useful, but
then scale down any initial prototype effort to something that can be
achieved within a few months.  We also believe that even though this is
intended to be a core CCSDS registry, that it could easily use current
web technologies to allow parts of it to be managed by individual
agencies or even other groups.  You will see all of this reflected in
the proposed Charter, which is below.  I am also attaching two other
documents that are grist for the mill, proposed by Takahiro Yamada and
Chuck Acton.

I look forward to meeting with you in May.

Best regards, Peter Shames

========================================================================
=================

DRAFT SANA BoF Charter

Overview:

The core registrar of information about space communications objects
for the CCSDS activities is the Space Assigned Numbers Authority
(SANA).  Many space mission activities require that someone keep track
of key object name and number assignments so that various spacecraft
operational entities and elements can be unambiguously identified.
Typical examples of the kinds of registries needed are for Spacecraft
IDs, physical elements like antennas and natural bodies, protocol
version numbers, reserved APIDs and SFDU Control Authorities.

Drivers:

The current mechanisms only accommodate a limited class of information,
primarily spacecraft IDs, and existing identification systems are
deeply engrained in member agency software, hardware and practices.
Much of this information is hard to locate and there is no central
clearing house for it.  As a result, missions often develop their own
approaches to creating and managing these data.  We have been
challenged to improve upon existing mechanisms for managing spacecraft
IDs and other objects involved in mission planning, operations, and
tracking and navigation activities.  ?Object? is defined as any known
or imagined participant in mission communications planning and
operations or trajectory propagation, tracking, attitude determination
and orbit determination

Considerations:

The standard must handle an assortment of pertinent objects:
   Protocol entities and assigned numbers
   Radiometric tracking stations (individual antennas; maybe complexes)
   Orbiters, Rovers, landers, balloons, airplanes, small stations
   Multi-part spacecraft that substantially separate sometime during the
mission
   Natural bodies (planets, natural satellites, comets, asteroids, sun),
including satellites of satellites and
      satellites of asteroids (e.g. Dactyl orbiting Gaspra)
The standard must handle a glossary of assigned terms.
The standard must accommodate spacecraft name changes occurring before
or after launch
The standard must accommodate multi-vehicle missions.
The standard must accommodate test and simulation IDs and names, in
addition to flight IDs and names.

Some of this information is best held in a single central repository
for general reference (protocol entities, assigned numbers & names,
glossary).  Agencies have their own naming processes and hold many of
these information sources (S/C names & reassignments, configurations,
test & simulation), which they will probably wish to continue to
control locally .  Other organizations already manage some of these
information sets (various natural body catalogues), so we may just wish
to point to these sources or identify ways to easily integrate them.
Given all of these considerations, a federated system that is minimally
invasive is believed to be the best approach to integrate these various
information sets.

Proposed Approach:

Leverage work that is being done within the Web Services and Global
Information Grid communities and the CCSDS Information Architecture
Working Group.   Utilize current developments in information
infrastructure and web based systems, using XML tools and approaches
where applicable.  Integrate existing CCSDS ID Control Authority, but
supplement or revise it to incorporate new technologies and accommodate
new requirements.

Takahiro Yamada:  Space Link Identifiers (CCSDS 135.0-B-1)

Chuck Acton:  Requirements on Object IDs

________________________________________________________

Peter Shames
CCSDS System Engineering Area Director

Jet Propulsion Laboratory, MS 301-265
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-1333

Internet:  Peter.Shames at jpl.nasa.gov
________________________________________________________

We must recognize the strong and undeniable influence that our language
exerts on our ways of thinking and, in fact, delimits the abstract
space in which we can formulate - give form to - our thoughts.

                     Niklaus
Wirth_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/cesg