System Engineering Area SANA BoF Kick-Off 12 May 2004 Peter Shames NASA/JPL

Agenda SANA Overview Open Issues Proposed Approach Discussion S/C IDs Object IDs Other global identifiers Central or agency local approach, need for federation Proposed Approach Discussion

Space Assigned Number Authority (SANA) Overview 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.

SANA Drivers Current mechanisms only accommodate a limited class of information, primarily spacecraft Ids Other information needs to be globally accessible Existing identification systems are deeply engrained in member agency software, hardware and practices Information is hard to locate and there is no central clearing house for it Re-assignment of numeric identifications is becoming a problem where current and archived data products “collide.” We are challenged to improve upon existing mechanisms for managing spacecraft IDs and other objects involved in mission planning, operations, and tracking and navigation activities

Other global identifiers Open Issues S/C IDs 8 & 10 bit GSCID Object IDs Other global identifiers Central or agency local approach, need for federation

Object Identifiers “Object” is defined as any known or imagined participant in mission communications, planning, and operations or trajectory propagation, tracking, attitude determination and orbit determination 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

Other Global Identifiers 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.

Central or Agency Local Approach Requirement for central point for access Assume some identifiers managed centrally Assume desire for some identifiers to be managed locally But widely accessible Some identifiers (planetary objects) are defined and managed by other organizations Requirement for minimum impact on any existing data sources Assume requirement to access all federated data sources thru common interface

Proposed Approach Gather requirements from willing participants Leverage work that is being done in: Web Services and Global Information Grid communities CCSDS Information Architecture Working Group Utilize current developments in information infrastructure and web based systems Use XML tools and approaches where applicable Integrate existing CCSDS ID Control Authority, but supplement or revise as needed Leave detailed discussion of data elements to responsible organizations, e.g Nav, SLS, SMWG, etc Prototype one or two initial databases using agreed framework

Space Link Identifiers, CCSDS 135.0-B-1 Source Materials Space Link Identifiers, CCSDS 135.0-B-1 Object ID Requirements, Chuck Acton IAWG White Book OODT Implementation & Framework To be updated to IAWG agreed standard interfaces

Questions / Issues (from BoF Meeting) What are detailed requirements? Which parameters, update & access patterns, which orgs own them Which ops domains are involved How to handle domain specific global IDs? And to handle collisions across domains Which technology to use? What are the SCID problems, in detail? What is a BoF, why was it created, who asked for it, what are we trying to do? Who will operate and manage this central registry? Is everything to be in one registry or in separate ones? Do we need a federated approach (last item pg 8) or just to have one big database w/ ops domain data?