1 / 11

System Engineering Area SANA BoF Kick-Off

System Engineering Area SANA BoF Kick-Off. 12 May 2004 Peter Shames NASA/JPL. Agenda. SANA Overview Open Issues S/C IDs Object IDs Other global identifiers Central or agency local approach, need for federation Proposed Approach Discussion.

eliza
Download Presentation

System Engineering Area SANA BoF Kick-Off

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. System Engineering AreaSANA BoF Kick-Off 12 May 2004 Peter Shames NASA/JPL

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

  3. 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.

  4. 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

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

  6. 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

  7. 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.

  8. 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

  9. 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

  10. 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

  11. 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?

More Related