CCSDS-OMG Plenary Template

1
SEA CMC/CESG REPORT
Colorado Springs, CO, USA, 24 January 2007
2
System Engineering AreaOverview

• SEA Includes
• System Architecture, Information Architecture
  Security Working Groups
• SANA WG (starting to meet as WG now)
• XML Standards and Guidelines SIG (cross WG
  effort)
• Delta-DOR SIG (cross WG effort, not meeting)
• SGIA BoF (Now has IOAG / agency support, meeting)
• Registry / Repository SIG (new short term joint
  effort)
• Responsibilities
• Overall architecture for space mission
  communications, operations, and cross-support
• Coordinate and collaborate with the other areas
  about architectural choices and options
• Support the CESG in evaluating consistency of all
  area programs of work with the defined
  architecture
• Create such working groups and BoFs as are
  required to progress the work of CCSDS

3
System Engineering Area Current WGs and BOFs

• System Architecture WG - meeting this week
• Develop a high level system architecture
  reference model (and formal methodology and tools
  - deferred as work item)
• Finalize Reference Architecture for Space Data
  Systems (RASDS) V1 Magenta Book, now out for
  review
• Discuss future work on architectural principles
  formalisms
• Information Architecture WG - meeting this week
• Develop a high level Information Architecture
  reference model and definitions of active and
  passive information objects
• Finalize Reference Architecture for Space
  Information Management (RASIM) V1 Green Book
• Define component interfaces and standards w/
  MOIMS IPR, formed new Registries / Repositories
  SIG to develop draft standard interfaces
• Security WG - meeting this week
• Develop security overview threat assessment,
  and security architecture, framework and related
  standards
• Progress Security Architecture and other specific
  security elements (Key management, Crypto and
  Authentication Standards)
• Discussions with other WGs as needed

4
System Engineering Area Current WGs and BOFs

• SANA WG - meeting this week
• Develop detailed requirements for the Space
  Assigned Numbers Authority (SANA)
• Develop requirements and SoW
• New BoFs
• Space Ground Interoperability Architecture BoF -
  meeting this week
• Develop an end to end space / ground cross
  support architecture and services catalog in
  response to IOAG request
• IOAG has now taken lead, has some agency support,
  JAXA action item to produce draft
• Plan to develop cross support architecture and
  service catalog(s)
• CCSDS will support this effort and leverage RASDS
  and other current standards efforts
• Role of this BoF re NASA SCAWG and IOAG Cross
  Support Architecture is TBD

5
System Engineering Area Current Special
Interest Groups (SIGs)

• Delta-DOR SIG - not meeting this week
• Develop detailed requirements for delta
  differential one-way ranging (Delta-DOR) service
  
• Coordinate work in other WGs (SIS/Ranging,
  CSS/CSTS, MOIMS/Nav)
• Develop integrated vision of service and
  interoperability points
• Develop over-arching documents (MB, GB), as
  needed
• XML Standards and Guidelines SIG - meeting this
  week
• Develop a set of common standards and guidelines
  for XML use across CCSDS
• Coordinate work in other WGs (MOIMS/Nav,
  MOIMS/SMC, CSS/SMWG, SEA/IAWG)
• Product will be a set of guidelines for all CCSDS
  WG that use XML to follow
• Considering move to create a new WG

6
Liaisons

• SysML Partners have developed a system
  engineering modeling language based upon UML 2.0.
  A liaison has been agreed to, which opens up a
  communication channel between the SEA and SysML
  groups. The intent is to provide the SysML
  solution to CCSDS for their validation for
  application to Space Systems.  
• SysML agreed to form a liaison w/ CCSDS. SEA, on
  behalf of CCSDS, has agreed to that liaison and
  several joint meetings have been held.
• The SysML spec is currently at version 1.0 in
  Finalization Task Force (equivalent to RB version
  2 validation). At least four UML tool vendors
  have developed SysML 1.0 compliant versions of
  their tools. A summary presentation is available
  from the SysML web site.
• An informal liaison has been developed with
  ISO/IEC JTC 1 / SC7 / WG 19 which is developing
  an UML for RM-ODP approach. This opens up a
  useful communication channel between the two
  groups. Our interest is to validate the RASDS to
  the RM-ODP and to provide feedback to the SC7 WG
  19 on its applicability to Space Systems.  
• The JTC 1 / SC 7 / WG 19 chair is interested in
  an informal liaison w/ CCSDS. It appears,
  however, that the most effective approach may be
  for our interested members to join them in
  developing the UML for ODP spec and future
  revisions to RM-ODP which will follow.

7
SEA Summary Document Status

• System Architecture WG
• RASDS review RB (Agency Review)
• IOAG Cross Support Architecture WB Discussion
• CCSDS Architecture Principles WP Discussion
  plan
• Security WG
• Security Architecture WB Discussion, RB plan
• Encryption Authentication WBs Discussion
  (magenta?)
• Key Management WP Discussion
• Information Architecture WG
• RASIM GB ready for CESG
• RASIM Use Cases patterns WB Discussion
• SANA WG
• Requirements content WP Discussion
• SoW approach WP Discussion
• XSG SIG
• Guidelines document WB Discussion
• BoF / WG Plans Future Work Discussion
• Delta-DOR SIG
• Overview document WP Discussion (no meeting)

8
SAWG Summary Technical Status

• Systems Architecture WG
• Goal Develop a reference architecture and a
  formal representation method
• Working Group Status Active ___ Idle ___ Will be
  terminated _X_
• Working Group Summary Situation
• Working Group Summary progress
• RASDS document released as a Red Book for Agency
  review
• SAWG needs to exist until we process RIDs and
  publish the final MB.
• Problems and Issues
• Ordered by CMC to terminate
• Development of a formal model is important for
  making architectural information available for
  software tools - halted

Status OK CAUTION PROBLEM
Comment Must be terminated
9
SAWG Executive Summary

1. A CESG poll for Approval of RASDS for Agency
   Red-1 review was posted in March 2006, and
   comments were received.
2. The WG revised the RASDS document based on the
   received comments and released it as a Red Book
   for Agency review in January 2007.
3. RIDs are due 9 April 2007, expect them to be
   processed and document updated prior to Fall 2007
   meeting.

10
SAWG Summary of Goals and Deliverables

1. Define a reference architecture that provides a
   framework for generation of space data systems
   standards and development of space data systems.
2. Document the reference architecture identifying
   basic elements.
3. Develop a document (GB) that provides to the
   other Working Groups and BoFs guidelines on how
   to apply the reference architecture.
4. Develop formal methods for representing space
   data systems architectures that will enable
   sharing of architectural information among
   engineers.
5. Develop tools that will facilitate design,
   modeling, and simulation of system architectural
   designs.

11
SAWG Progress Achieved

• Edits and changes to the RASDS RB were reviewed
  and discussed.
• RIDs are due 9 April 2007. Plan for resolving
  RIDs was discussed.
• Nominal plan is to complete and publish MB by the
  Fall 2007 Meeting, assuming there are not major
  issues identified.
• With regard to items 4 and 5, the WG reviewed the
  activities of the ISO/IEC JTC1/SC7/WG19 that is
  defining a UML profile for RM-ODP.

12
SAWG Open Issues

• No Agency resources are available to perform work
  items 3, 4, and 5 defined in the Charter.
• How best to support the development of Cross
  Support Service Architecture by IOAG?
• RASDS Green Book has been deferred, resources are
  supporting IOAG Cross Support Architecture
  effort.
• RASDS is to be used to describe complex space
  data systems but people involved in complex space
  data systems rarely come to CCSDS.
• Some missions have successfully used RASDS as
  part of their mission design process.
• Whether to establish a liaison relationship
  between CCSDS and ISO/IEC JTC1/SC7 or between ISO
  TC20/SC13 and ISO/IEC JTC1/SC7?
• Update RASDS when RM-ODP is updated?
• RM-ODP will be updated by the ISO/IEC WG that
  developed the original RM-ODP spec and the
  revised standard will be published in two years.
• We may need to revise RASDS based on the revised
  RM-ODP.

13
SecWG SUMMARY TECHNICAL STATUS

• Security WG
• Goal
• Working Status Active _X_ Idle ____
• Summary progress Five documents actively being
  produced (Security Architecture, Encryption,
  Authentication, Key Management, Secure
  Interconnection). All docs green.
• Progress since last meeting Completed Threat,
  completed secure interconnection doc, consensus
  on Encryption and Authentication Algorithm
  documents, positive movement on Security
  Architecture doc.
• Problems and Issues Resources need to ensure
  continued participation from all member agencies

status OK CAUTION PROBLEM
Working Group is advancing and producing good products. Docs OK. New work (Key Mngt) OK.
14
SecWG Executive Summary

• Attendees from BNSC, ESA/ESOC, ESA/ESRIN, DLR,
  NASA/GSFC, NASA/MSFC, NASA/JSC and NASA/JPL.
  CNES and ASI were originally going to attend but
  were not able due to illness and programmatic
  issues.
• Major participation by NASA from multiple centers
  including JSC.
• Discussed and revised the SecWG Security
  Architecture. General consensus that this is a
  high priority document that should be issued as a
  Magenta book (a la RASDS). Supports Packet or IP
  networking and allows security services at
  physical/link layer, network layer, and at
  application. Needs mission class use cases (a la
  the threat document) to be added with inputs from
  the SecWG members.
• Discussed the encryption and authentication draft
  documents.
• Agreed to publish as Magenta books after revising
  per ESTEC comments (on encryption book) and
  changes to hash algorithm as discussed (on
  authentication book).
• Joint meeting held with SANA to discuss security
  implications of SANA registries and security
  registries (e.g., identity management).
• Discussed key management document and proposal
  written by ESA

15
SecWG Summary of Goals and Deliverables

1. Secure Interconnection Guideline has been revised
   and submitted to the secretariat for editing and
   publication.
2. Security Architecture document will be revised
   based on meeting discussions.
3. Encryption and Authentication Algorithm documents
   will be revised per ESTEC comments, telecon
   discussions between NASA-ESA-BNSC, and meeting
   discussions. To be published as Magenta books.
4. Early discussions regarding potential
   security-related registries with SANA.
5. Excellent discussion and document on key
   management.
6. Generated a list of new work items/documents to
   be considered for future.
7. Continue to work with other Areas and their WGs
   with respect to security.

16
SecWG Progress Achieved

• General agreement that the Security Architecture
  (as revised) is on the right path. With minor
  revisions and the addition of use cases for
  each of the mission classes (a la the threat
  document), the Security Architecture document
  should be good to go.
• Reviewed the encryption and authentication
  algorithm documents.
• Consensus that these documents should be issued
  as Magenta books.
• Encryption algorithm might be one of a suite of
  algorithms and/or modes
• Agreement that the authentication document should
  not require SHA-1 in light of further work in
  breaking the algorithm and announcements
  Microsoft is moving away from SHA-1 and NIST has
  issued guidance for the US Govt to move away from
  it by 2010. Document will now require SHA-256
  and allow the use of other algorithms.
• Joint meeting with SANA to discuss implications
  of security on registries and the creation of
  security registries (e.g., identity). At a
  minimum, there will need to be user
  identification, authentication, and access
  controls applied to the SANA registries. There
  probably need to be some security registries
  (e.g., algorithm IDs, protocol IDs) but its less
  clear if there should be identity registries
  (e.g., PKI-like functionality, access control
  lists).
• An excellent key management document was written
  and presented by ESA providing a good start on
  the path towards specifying a CCSDS key
  management document (Magenta, Blue, color not
  determined yet).

17
IAWG SUMMARY TECHNICAL STATUS

• IAWG WG
• Goal
• Working Status Active _X_ Idle ____
• Summary progress RASIM GB document is ready for
  submission to CESG review.
• Progress since last meeting Established that
  RASIM is ready for outside review. Co-chaired
  Registry / Repository SIG meeting that
  established near term plan for reference model.
• Problems and Issues Limited resources from
  member agencies. Need support from Gurus in
  other relevant WGs for Reg / Rep SIG use cases.

status OK CAUTION PROBLEM
Good progress. Reg / Rep has good start. Docs OK.
18
IAWG Executive Summary

• Two half day meetings were held with other WGs to
  discuss a plan for developing a registry model.
  It was decided that a 4 month effort will be
  conducted to define a high level architecture. A
  series of telecons and a face-to-face meeting
  will be held during this time. This was a major
  break-through from past meetings. Multiple CCSDS
  WGs and Agencies are onboard.
• The draft Information Architecture Green Book
  RASIM was discussed. No additional comments have
  been provided since being sent out for review in
  2006. The GB will be forwarded to the CESG for
  review and approval.
• The meeting also discussed the importance of
  developing some best practice case examples using
  RASIM modeling and functional components for
  science and mission operations.
• Application to DSMS Information System
  Architecture (DISA)
• Application to Constellation

19
IAWG Progress Achieved

• There was significant progress in forming a CCSDS
  effort for registry definition.
• A Registry / Repository SIG has been formed to
  move this work forward
• Membership is drawn from IAWG and IPR WGs,
  members from other WGs (SMC, SMWG, SANA, NavWG)
  are being solicited
• Use cases and scenarios are to be drawn from
  CCSDS WGs and agency needs for these services
• Near term plan for reference model and interface
  definitions
• Schema registry and service registry are high
  priorities for IPR and IA WGs
• Expect other kinds of compliant registries to be
  developed in other WGs like SANA, SMC, SMWG
• There was minimal additional feedback on the IA
  green book (RASIM) which defines much of the base
  concepts that are needed for the more detailed
  information architectures like registries and
  repositories.
• Reg / Rep SIG is expected to use RASIM as guiding
  document for developing interfaces and service
  definitions

20
IAWG Open Issues

• While there is participation in IAWG, it is still
  minimal across the agencies.
• Many agencies now appear to be discussing
  information architecture concepts identical to
  IAWG proposal and developing systems that
  implement these kinds of architectures (NASA,
  ESA, CNES, BNSC)
• Having a core architecture document that provides
  standard definitions of terminology and interface
  concepts is becoming critical
• Registries and repositories work is critical
  across several CCSDS WGs (SMC, SMWG, SANA,
  NavWG)
• Need participation from members of these WGs
• Expect WGs to do prototyping, refinement and
  validation of reference model developed by Reg /
  Rep SIG
• Cross WG coordination is still difficult
• WGs run different lengths which makes scheduling
  tough
• Several WGs were scheduled concurrently, making
  participation and cross WG efforts very difficult
• Need to consider merging XSG work into IA at some
  point

21
SANA Summary Technical Status

• SANA WG
• Goal Establish a mechanism by which CCSDS can
  develop and operate a top level registry service.
  
• Working Group Status Active _X_ Idle ___ Will be
  terminated __
• Working Group Summary Situation
• Working Group Summary progress
• Used working group time to revise SANA
  requirements and SOW.
• Will be sending this list of revised requirements
  and SOW out to working group members for comment
• Problems and Issues
• Need to revise SANA charter to reflect schedule
  for SANA deliverables

22
SANA WG OVERVIEW

• Charter and objectives of SANA Working Group
• Focus on Engineering data, not science data
• Provide the mechanisms, processes and
  documentation required for a CCSDS registry
  capability
• Provide detailed requirements for a CCSDS
  registry
• Integrate current CCSDS registry processes into a
  unified standardized framework
• Utilize work on registries being done in other
  CCSDS working groups (IAWG IPR)
• Propose a SANA advisory group and develop rules
  and processes including resources required, look
  at IANA for best practices
• Provide an assessment of categories 1 through 4
  information sources for registry requirements in
  a SANA Green Book
• Present findings in an informal requirements
  review prior to further activities
• Document existing identifier spaces that CCSDS
  requires and to identify any special constraints
  imposed by those identifier spaces and that a
  particular registry exists and procedures for
  interaction with it
• Define processes and standards to the numbering
  and identifier requirements
• Define and document a statement of work for the
  ongoing operation of the SANA function
• Present SOW to the CMC
• Develop implementation and operation plans and
  cost
• Goals for the January 2007 CCSDS meeting
• Review and obtain consensus on the SANA
  requirements and SANA SOW

23
SANA Executive Summary

1. Summary from joint meeting with Security Working
   Group
2. Overall consensus was that SANA would use the
   products coming out of the security group.
3. This will include the security guidelines and
   recommendations and any other products that have
   relevance to a SANA registry to provide access
   control within the registries and protect
   information in the registries.
4. Suggested use of common login for CCSDS services,
   SANA and CWE / web site
5. Summary from main SANA WG meeting
6. Agreed that we needed to continue further
   refinement of requirements and submit for comment
   to whole group and CESG
7. Expect to use products and recommendations coming
   out of the Registry/Repository SIG group
8. Agreed to develop a draft implementation plan
9. Evaluating fast-track prototype approach vs
   more formal SoW approach

24
XSG SIG OVERVIEW
CCSDS XML Standards and Guidelines SIG

• Catalyzed by IPR Study on XML Schema Namespaces,
  Specialization and Schema Repository Services
  Best Practices that were presented to the
  CCSDS/OMG Plenary in Atlanta. The SIG includes
  members from the NavWG, SMWG, SMC WG, IPR WG and
  IAWG who are the editors of the draft CCSDS
  recommendations that used XML Schema as a
  normative portion of the specification and an ESA
  and CNES representative.
• Short-term deliverables
• CCSDS XML Schema Namespace and Versioning - NASA
  editor
• Define an IETF RFC to obtain a CCSDS URN domain -
  ESA Editor
• Long-term needs
• Dissolve the XSG after Oct 2007 meeting and
  create a BOF to
• Develop a CCSDS NDR and Best Practices Document
• Look at UBL architecture as a basis for space
  operations information architecture
• Define various levels of XML Schema reusable
  components based on the UBL model
• Investigate commercial tools as a basis for CCSDS
  XML Schema Service (Registry and Repository)
• WG could be formulated under restructured IAWG
  charter or otherwise. Regardless of approach,
  XML guru resources from other WGs will be
  required.

25
XSG SIG Progress and Current Status

• Meeting Summary
• Due to WG schedule collisions conflicts the XSG
  met briefly Saturday morning and final drafts
  were distributed, but examples will be done via
  telecon.
• Lou Reich presented briefing on a new XML Schema
  extension technique which will be used in third
  party extensions
• Status
• Internal drafts of both IETF RFC to obtain a
  CCSDS URN domain and the CCSDS XML Schema
  Namespace and Versioning documents were completed
  in early January
• Developing final drafts for review by the CESG
  has been delayed due to major releases of OASIS,
  UBL and UN/EDIFACT Naming and Design Rule version
  2 documents and lack of resource/priority
• The editors feel that current drafts are final
  except for examples and should be compliant with
  the UBL 2.0 Naming and Design Rules
• Final drafts of the should be sent to the CESG by
  March 31,2007

26
XSG SIG Issues

• Over the next nine months, the XML SIG will be
  responsive to the need of the Registry/Repository
  SIG Architecture efforts and the MOIMS/IPR XML
  Schemas Registry/Repository effort through
  supplying use cases and technical input as
  requested.
• Significant resources will be needed both to
  complete the XML Schema NDR and to supply the
  domain knowledge to enable reusable and
  interoperable XML Schemas
• The XSG recommends the XML SIG be dissolved after
  the Fall 2007 meeting and a BOF be created so
  appropriate levels of resource can be assigned to
  this effort.
• Support from the XML Gurus in other working
  groups is going to be a continuing issue for this
  activity, regardless of how it is chartered.
• The downside of not doing this correctly is that
  we will, as a standards organization, fail to
  present XML standards that are self consistent,
  well integrated and interoperate properly.

27
D-DOR SIG SUMMARY TECHNICAL STATUS

• Delta-DOR SIG
• Goal Standardize cross-support for Delta-DOR
  measurements
• Working Status Active _X_ Idle ____
• Summary progress Did not meet in Colorado One
  document actively being produced (Delta-DOR
  Operations White Book).
• Progress since last meeting Revised White Book
  Developed roadmap to demonstrate inter-agency
  operability Exchange of tracking data.
• Problems and Issues Should White Book evolve
  into Green or Magenta Book ?

status OK CAUTION PROBLEM
Working Group is advancing and producing good products. Docs OK. New work OK.
28
D-DOR SIG Executive Summary

• The Delta-DOR SIG did not meet in Colorado
  Springs
• Work has been done and continues through e-mail
  exchange.
• Delta-DOR Operations White Book reviewed after
  Rome Meeting and updated in November 2006 (SIG
  limited version) to add background information to
  address the issues highlighted at the June 2006
  meeting.
• Additional SIG review finalized by February 2007.
  
• White Book distribution for CCSDS wide review in
  February (main addressees SLS/RNG, CSS/CSTS and
  MOIMS/NAV).
• Validation of inter-operability between the NASA
  Delta-DOR system and the ESA Delta-DOR system has
  begun.
• Finalization and discussions between SIG and
  relevant Working Groups in the Fall 2007 meeting.
• Need decision for either Green or Magenta Book.

29
SEA - Proposed New WG / BoF

• Registries / Repository SIG
• Joint membership from IAWG IPR WG
• Near term plan to develop reference model for
  service interfaces
• Plan that prototyping in several WGs will
  validate and refine reference model and interface
  specifications
• Space Data Systems Standards Reference Model BoF
• Develop a Space Data Systems Standards Reference
  Model utilizing RASDS and IOAG CSSA
• Review the Cross Support Service Architecture
  (CSSA) developed by IOAG, the CSS reference model
  and SMC reference model
• Ensure consistency between the above models,
  define a glossary of terminology
• Use the model to describe the major interfaces
  and interactions of the CCSDS family of space
  data system standards
• Requires expertise from several key WGs

30
SEA Cross Area WG / BOF Issues

• SEA has previously identified need for CCSDS
  Architecture Principles, as called out in
  A02.1-Y-2 A00.0-Y-9.
• SEA will develop draft document, either as MB (or
  YB?), for CESG and CMC approval.
• SEA will need to support the development of Cross
  Support Service Architecture initiated by IOAG.
• No defined relationship to do this now exists.
  Could be SGIA or SAWG, but will need support from
  other WG experts.
• Consider focus workshop of 2-3 days duration,
  with both IOAG and CCSDS reps, to help create the
  document.
• Agreement within SEA about need for ops concepts
  as starting point for architecture development.
• MOIMS SMC WG has defined terms Interaction
  Pattern (IP) and Message Exchange Pattern (MEP)
  which are similar in design and terminology to
  CSS SMWG, but are in no way aligned.
• This appears to be both redundant and confusing.
  Recommend harmonizing these approaches.

31
SEA - Other Issues Concerns

• XML Standards Guidelines adoption process, MB?
  BB? YB?
• Delta-DOR end to end process, document
  development
• NASA / Constellation SCAWG activities
• Interoperability and cross support
• Manned robotic exploration at the Moon and Mars
• Need for unified inputs from CCSDS and member
  agencies for technical feedback, architecture,
  and interoperability
• Need for CCSDS security registry, identity
  management?
• Support at least CCSDS developed operated
  services, web pages SANA
• Color of security encryption / authentication
  docs?
• These should be Blue, but there is some ESA
  member resistance. May make them Magenta as a
  result.
• Color of IAWG Reference Architecture for Space
  Information Management (RASIM)
• Has been proposed as Green Book because of
  individual member objections, Based on contents
  and purpose should be a non-binding Magenta Book.

32
BACKUP SLIDES
33
Space Assigned Number Authority (SANA) Motivation

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

34
Scope of SANA (in green)
Overlap Processes And pointers

• Pointer to all registries
• Process definition for all registries
• (Points to IAWG and IPR books for lower level
  registry requirements)

Others
SpaceCraft ID
ESA PUS IDs
Others
SCPS
Others
IPv6 In space
New external sub-registries
Legacy sub-registries
New CCSDS-run sub-registries