1. SEA AREA MID-TERM REPORT May 2004PS 1 System Engineering (SEA) AREA REPORT (with CESG Updates) 17 May 2004 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS

2. SEA AREA MID-TERM REPORT May 2004PS 2 CONTENTS LIST OF CURRENTLY ACTIVE WGs AND BOFs SUMMARY TECHNICAL STATUS OF EACH WG & BOF CROSS-AREA TECHNICAL ISSUES OTHER ISSUEs AND CONCERNS PROPOSED RESOLUTIONS/ACTION ITEMS

3. SEA AREA MID-TERM REPORT May 2004PS 3 System Engineering Area Overview SEA Includes: –System Architecture, Information Architecture & Security Working Groups –Internetworking and SM&C SIGs –SANA BoF 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

4. SEA AREA MID-TERM REPORT May 2004PS 4 There are currently three WGs, two SIGs and a BoF active within the System Engineering Area System Architecture WG –Developing high level system architecture reference model, formal methodology and tools. Security WG –Developing Security Architecture, threat assessment, security framework and guidelines for mission designers. Additional deliverables have been identified. Information Architecture WG –Developing a high level Information Architecture reference model and definitions of active and passive information objects. SOIS / SIS / SEA SIG –Evaluating a common approach for handling internetworking issues within spacecraft onboard, space - space and space - ground environments. Met independently. MOIMS / SOIS / SEA SIG –Develop an integrated architectural vision for MOIMS Spacecraft Monitor & Control (SM&C) and SOIS Command and Data Acquisition (C&DA) and Plug and Play approaches SANA BoF –Develop detailed requirements for the Space Assigned Numbers Authority (SANA), an implementation approach and a plan for a rapid prototype to demonstrate functionality Current Work Activities

5. SEA AREA MID-TERM REPORT May 2004PS 5 SAWG SUMMARY TECHNICAL STATUS 1.Systems Architecture WG (SAWG) Goal: Develop a reference architecture and a formal representation method Working Status: Active _X_ Idle ____ Summary progress: Progress since last meeting: Updated the Reference Architecture document, Red Book to be issued in one month Started working on the formal representation method Problems and Issues:None status:OK CAUTIONPROBLEM comment: Ref. Arch: Ready to go Red Formal representation method: Started

6. SEA AREA MID-TERM REPORT May 2004PS 6 SAWG Summary of Goals & Deliverables Update the RASDS WB based on the discussion at the meeting, and provide feedback –To: Shames & SAWG –Due: 25 June 2004 Release the RASDS Red-1 –16 July 2004

7. SEA AREA MID-TERM REPORT May 2004PS 7 SAWG Summary of Goals & Deliverables, contd Draft a White Book that formally specifies the RASDS metamodel (based on UML 1.4). –To: Lindman/Walsh –Due: 1 month prior to Fall 2004 meeting (Issue 0.1) –Due: Spring 2005 meeting (Issue 1.0) –Issue: This work is partly based upon ESA’s XASTRO project, which is their intellectual property. –Action: Nestor Peccia to explore whether ESA can identify a means to release the XASTRO meta-model in response to a CCSDS request, or if all participating agencies will need to make individual requests

8. SEA AREA MID-TERM REPORT May 2004PS 8 SysML Liaison Sandy Freidenthal, SysML co-chair, presented a proposal to establish a liaison between SysML and CCSDS. CCSDS is a standards group that includes an activity to develop standard architecture descriptions for Space Systems (Space Data Systems). This was a follow-up from a briefing by Peter Shames from JPL on Oct 17 to SysML Partners that Jim U’Ren arranged in Pasadena. Sandy presented to the CCSDS Architecture WG the following week on Oct 24 in Columbia MD. As a result of this interchange, it was felt that there is significant synergy between the efforts of both groups. The proposed liaison is similar to the EAST liaison, which opens up a communication channel between the two groups. The intent is to provide the SysML solution to CCSDS for their validation for application to Space Systems. It was also expressed that SysML will need to closely manage its work scope. SysML agreed to the form a liaison w/ CCSDS. SEA, on behalf of CCSDS, has agreed to that liaison and several joint meetings have been held.

9. SEA AREA MID-TERM REPORT May 2004PS 9 IAWG SUMMARY TECHNICAL STATUS 1.Information Architecture WG (IAWG) Goal: Develop Space Information Architecture Working Status: Active _X_ Idle ____ Summary progress: Progress since last meeting: Developed Info Arch White Book, reviewed within WG and by some outside parties Developed an approach to refine IA elements, produce BCP to demonstrate use of elements to develop systems Problems and Issues: Need an agreed process for transition into IPR (or into a new GRID WG) IA WB, Draft out for review comment: PROBLEMCAUTIONOKstatus:

10. SEA AREA MID-TERM REPORT May 2004PS 10 IAWG Progress Achieved The Info Arch White Book is an excellent start, but requires some updates both to the data (chapter 2) and software architecture (chapter 3) sections. This includes updates from CNES, GSFC and JPL. Identification of work areas between MOIMS Information Packaging and Registries and SEA Information Architecture was achieved including definition of a process of how to work together. Discussed the relationship between Grid Computing and Information Architecture, identified overlaps and opportunities between the Global Grid Forum and CCSDS. To be worked jointly w/ IAWG, IPR and GGF.

11. SEA AREA MID-TERM REPORT May 2004PS 11 IAWG Near-Term Schedule Draft Information Architecture (February 2004) Finalize White Book (June 2004) Best Practices Document (June 2004) Reschedule: August 2004 NVO Position Paper (August 2004) Reschedule: October 2004 Red Book (October 2004) Reschedule: February 2005 Blue Book (February 2005) Reschedule: December 2005

12. SEA AREA MID-TERM REPORT May 2004PS 12 SUMMARY TECHNICAL STATUS 1.Security WG (SecWG) Goal: Develop Security Architecture & Tools Working Status: Active __X_ Idle ____ Summary progress: Three documents actively being produced (Security Green Book, Security Architecture, Threat). All docs green. Progress since last meeting: Developed draft Threat and Security Architecture docs, revised Security GB, resolved to propose recommendations for encryption and authentication Problems and Issues: Resources – need to ensure good participation from all member agencies, ESA has been absent Docs OK. New work OK. comment: PROBLEMCAUTIONOKstatus:

13. SEA AREA MID-TERM REPORT May 2004PS 13 SecWG Summary of Goals and Deliverables 1.Complete update/revision of the Security Green Book. Release June 04 2.Complete update/revision of Security Architecture. Release Red-1 Oct 04 3.Complete update/revision of Threat Document. Release June 04 4.Propose a CCSDS encryption standard. 5.Propose a CCSDS authentication standard. 6.Think about proposals for a CCSDS key management standard. 7.Work with other WGs with respect to security.

14. SEA AREA MID-TERM REPORT May 2004PS 14 SecWG Open Issues Key management proposal Policy framework –E.g., NIST document could be leveraged but will take resources to adapt for CCSDS. Resources not available at present. Ground systems –Security for the ground system –Interconnection/policy for cross support across ground systems Future documents – resources to tackle them –Common Criteria Protection Profiles –Security Handbook for Mission Planners

15. SEA AREA MID-TERM REPORT May 2004PS 15 SANA BoF SUMMARY TECHNICAL STATUS 1.Space Assigned Numbers Authority (SANA) BoF Goal: Define contents, framework and process for SANA Working Status: Active _X__ Idle ____ Summary progress: Progress since last meeting: Held BoF meeting (21 people), agreement on high level requirements, several interested members, draft Charter produced. Problems and Issues: Need detailed requirements from members & agencies, need to coordinate prototype approach w/ IAWG, IPR, SMWG, NavWG, and others. Held BoF meeting comment: PROBLEMCAUTIONOKstatus:

16. SEA AREA MID-TERM REPORT May 2004PS 16 SANA BoF Space Assigned Number 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 assignments that were added after the protocol came out. Typical examples of the kinds of registries needed are for Spacecraft IDs and SFDU Control Authorities.” –Define responsibilities of the Space Assigned Numbers Authority (SANA) and determine what functions are required and if resources are necessary to administer –Related issue of standardized approach to define S/C IDs, names, numbers throughout mission lifecycle Space Link Identifiers (CCSDS 135.0-B-1) is one input for this BOF –Needs input from SEA - IA BoF, MOIMS (IPR & Nav), CSS, SLS, Secretariat

17. SEA AREA MID-TERM REPORT May 2004PS 17 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

18. SEA AREA MID-TERM REPORT May 2004PS 18 Central or Agency Local Approach Requirement for central point for access Assume some identifiers managed centrally –Including CCSDS XML Schema 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

19. SEA AREA MID-TERM REPORT May 2004PS 19 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 to define framework for data and access –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

20. SEA AREA MID-TERM REPORT May 2004PS 20 Other Proto - BoFs Time Services Architecture - nascent –Define end to end architecture for clock synchronization, time correlation, time signals and formats. –Requires inputs from SOIS (onboard clock and timing, S/C clock correl), SLS (space link and time signals), SIS (NTP and other time synch protocols), MOIMS (nav requirements and GDS S/C clock correl) –May just define basic time correlation messages Scant resources, no leader identified Standard Application Services - dormant –Define an End to End Operations Model (onboard and ground) –Identify: 1.Applications (onboard and ground) 2.General services to support applications (incl end-to-end) 3.Languages to support applications, Areas include: Systems Engineering, Mission Operations, SOIS, Cross-Support Work being carried out in MOIMS

21. SEA AREA MID-TERM REPORT May 2004PS 21 Monitor & Control SIG SUMMARY TECHNICAL STATUS 1.SEA / MOIMS / SOIS SIG on Monitor & Control Goal: Develop end to end approach for monitor & control Working Status: Active _X__ Idle ____ Summary progress: Progress since last meeting: Created end to end SM&C Architecture Study, reviewed with MOIMS & SOIS, coordinated meetings. MOU drafted by MOIMS & SOIS. Problems and Issues: Need follow up on MOIMS and SOIS conceptual architectures to ensure end to end alignment. Held SIG meeting, MOU. comment: PROBLEMCAUTIONOKstatus:

22. SEA AREA MID-TERM REPORT May 2004PS 22 Joint SEA, MOIMS & SOIS on S/C Monitor & Control (10 & 14 May) Purpose of the joint meetings –Understand the scope and objectives of the Spacecraft Monitor and Control Services being developed by MOIMS. –Understand the scope and objectives of the Command and Data Acquisition Services being developed by SOIS. –Discuss the similarity and difference between these two sets of services. –Agree on an end to end approach and on how these services should be divided into MOIMS and SOIS and agree on an MoU.

23. SEA AREA MID-TERM REPORT May 2004PS 23 Joint SEA, MOIMS & SOIS on S/C Monitor & Control (10 & 14 May) Precursor: –SEA led development of an architecture study for Monitor and Control (Yamada, Shames, Oyake, Smith) –Included MOIMS SM&C and SOIS C&DA elements –Showed integrated end to end view and relationship of elements Discussions –SOIS services are applicable to onboard applications only, while MOIMS services should be applicable regardless of the nature or configuration of the underlying network. –On spacecraft, MOIMS mission operations services should be used on top of SOIS communications services. Therefore, these two service sets are hierarchically located in the protocol stack.

24. SEA AREA MID-TERM REPORT May 2004PS 24 Joint SEA, MOIMS & SOIS on S/C Monitor & Control (10 & 14 May) Results of the joint meetings –Agreed on a general architecture for Spacecraft Monitor and Control. –Agreed on what services should be developed by MOIMS and what services should be developed by SOIS. –Agreed on the contents of the MoU, which will be presented by MOIMS and SOIS at this meeting. –Agreed that these two groups should periodically exchange and review their documents to make sure they are consistent and constitute cleanly integrated elements of the overall CCSDS protocol suite.

25. SEA AREA MID-TERM REPORT May 2004PS 25 A.Issue - IAWG The packaging work occurring in MOIMS IPR needs to be validated by a prototype. JPL is working prototypes for the information architecture and will demonstrate how emerging standards can be tied to together to demonstrate the validity of both the architecture and the standards. This includes packaging. CROSS-AREA TECHNICAL ISSUES

26. SEA AREA MID-TERM REPORT May 2004PS 26 CROSS-AREA TECHNICAL ISSUES B.Issue - IAWG Standards for interfaces and protocols for distributed services are still under development. Many WGs lack consistency in core information architecture concepts. Often technologies are confused as de facto architectures (i.e. web services, etc). C.Issue - IAWG Several efforts in other WGs that are downstream from the architecture are not coordinated, creating inconsistencies among the efforts (Packaging, SANA, Registries, Archives, Cross Support / SMWG).

27. SEA AREA MID-TERM REPORT May 2004PS 27 CROSS-AREA TECHNICAL ISSUES, contd D.Issue - SecWG Security is a cross-cutting discipline that needs to be included in many other Areas and WGs. Agreed that a proactive approach (SecWG working with other WGs) would work best, but resource constraints will be an issue. “Ratify” security architecture via vetting with other working groups CSS, security services for cross support SLS, mapping approaches for link layer security SOIS, discuss integration of security into on-board environment

28. SEA AREA MID-TERM REPORT May 2004PS 28 OTHER ISSUES AND CONCERNS A.Issue 1 - IAWG There may not be enough resource commitments from member agencies to achieve deliverables. ESA and CNES considered important stakeholders. Interest has been expressed by several people to be part of the IAWG but there are no agency commitments to do so. B.Issue 2 - SecWG There are insufficient resources being applied to this WG by the various agencies. ESA was absent from these meetings, though their staff have provided feedback for some documents.

29. SEA AREA MID-TERM REPORT May 2004PS 29 OTHER ISSUES AND CONCERNS C.Issue 3 - SecWG We have no agreed procedure within CCSDS for incorporating standards from other organizations, either in whole or in part, into our documents. SecWG wishes to leverage external, well accepted, standards wherever possible. Discussion: Other standards have done this (SIS, CSS) so it may not be an issue in practice.

30. SEA AREA MID-TERM REPORT May 2004PS 30 PROPOSED RESOLUTIONS AND ACTIONS FOR CESG/CMC APPROVAL RESOLUTION 1 SEA / SAWG Proposes to produce a Reference Architecture Red Book, for distribution to member agency review, by 16 July. Recommendation will be prescriptive on CCSDS Working Groups Recommendation will be accompanied shortly by a Green Book with examples on use A Red Book with a formal meta-model specified in UML will be produced within a year

31. SEA AREA MID-TERM REPORT May 2004PS 31 PROPOSED RESOLUTIONS AND ACTIONS FOR CESG/CMC APPROVAL RESOLUTION 2 SEA / SecWG Proposes to release its update to the Security Green Book, APPLICATION OF CCSDS PROTOCOLS TO SECURE SYSTEMS, with a release date of June 04. Green Book, CCSDS-350.0-G-1v3, incorporates updates from WG review and comments from several agencies

32. SEA AREA MID-TERM REPORT May 2004PS 32 PROPOSED RESOLUTIONS AND ACTIONS FOR CESG/CMC APPROVAL RESOLUTION 3 SEA / SecWG Proposes to ask the CMC to include a security section template in all CCSDS documents with headings and explanatory text to help authors fill in the blanks. This is to be done in parallel with completion of Security standards. Outline of security section: –Provide rationale and explanation as to why or why not security plays a role in this CCSDS document. –Template headings: 1.0 Security Background/Introduction 2.0 Statements of security concerns with respect to the CCSDS document: –data privacy –data integrity –authentication of communicating entities –control of access to resources –availability of resources –auditing of resource usage 3.0 Potential threats and attack scenarios (how could someone break the technology and why) 4.0 Consequences of not applying security to the technology (e.g., loss of life, loss of mission).

33. SEA AREA MID-TERM REPORT May 2004PS 33 PROPOSED RESOLUTIONS AND ACTIONS FOR CESG/CMC APPROVAL RESOLUTION 4 SEA / SecWG resolves to create a CCSDS Security Recommendations Blue Book, with multiple referenced sections as needed. The first proposed standards being: –Proposal for a profile for an encryption standard based on FIPS 197 specification of AES-128 –Proposal for a profile for an authentication/integrity standard based on FIPS 186-2 specification of the Digital Signature Standard.

34. SEA AREA MID-TERM REPORT May 2004PS 34 BACKUP