1. System Engineering Area Fall 2003 Meeting Reports 30 October 2003 Peter Shames NASA/JPL

2. Agenda Overview Technical Reports –System Architecture WG –Security WG –Information Architecture BoF –SOIS / SEA SIG Cross Area Technical Issues Draft Resolutions for CMC

3. System Engineering Area Overview Brand new Area in CCSDS –System Architecture & Security Working Groups –Information Architecture BoF and Internetworking SIG 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. Current Work Activities There are currently two WGs, a BoF and a SIG 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 BoF –Developing a high level Information Architecture reference model and a set of active and passive information objects. This BoF is proposed for promotion to a WG. SOIS / SEA SIG –Evaluating a common approach for handling internetworking issues within spacecraft onboard, space - space and space - ground environments.

5. Systems Architecture WG: Report of the Fall 2003 Meeting October 28, 2003 Takahiro Yamada, JAXA/ISAS

6. Space Data System Several Architectural Viewpoints Enterprise Business Concerns Organizational perspective Connectivity Physical Concerns Node & Link perspective Functional Computational Concerns Functional composition Information Data Concerns Relationships and transformations Communications Protocol Concerns Communications stack perspective Derived from: RM-ODP

7. Mission BFD Development & Operations Domain Enterprise View Federated Enterprises with Enterprise Objects Planning Phase Mars Exploration Program Federation Mission A Proj X Prog C Service Z GTN Y GTN B Mission AX Agency ABC Company XYZ Mission Q Instr S Proj R Agency QRS Mission BFD Organization PDQ Enterprise Objects Cross- Support Agreement Operations Contract Instrument Integration Domain Concerns: Objectives Roles Policies Activities Configuration Contracts Lifecycle / Phases

8. SAWG Executive Summary The Charter of the WG was reviewed and approved. The draft on the Reference Architecture for Space Data Systems (RASDS) was reviewed and it was agreed that its technical contents are almost complete. Some languages for formally representing architectures were reviewed and a tentative agreement to use UML 2.0 and SysML was reached.

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

10. Progress Achieved With regard to items 1 and 2 (see the previous page), it was agreed that the reference architecture is almost complete and the RASDS document should be published as a Red Book for Agency review when the revisions agreed to at the meeting are made. With regard to item 4, it was agreed to study UML 2.0 and SysML to determine whether they are the best languages to be used for formally representing our architecture. If the result of the study is positive, a Space Data System Modeling Language will be developed based on SysML.

11. Near-Term Schedule DeliverableMilestoneDate Reference Architecture (Standard) Develop a Reference Architecture Publish a revised draft (RB) Almost complete 12/03 -> 04/04? Report (Informational) Publish a draft document (draft GB) 10/03 -> 12/03? Representation Methods (Standard) with Software Tools Selection of languages and tools Prototyping (phase 1) 07/03 -> 12/03 07/03-10/03 -> 01/04-06/04

12. SAWG Open Issues There are a few technical issues concerning RASDS. The most important one is how to formally specify relationships between elements in different Views. Requirements for the formal language and tools developed by this WG should be clearly stated. It should be discussed at CESG how to respond to the RID submitted against the Charter that requested to “provide a consistent set of views and terminology across all of the other Areas and Working Groups.” It was agreed that UML 2.0 and SysML appear to be the best languages, but these languages are yet to be finalized and we may need to extend the period of the existence of this WG.

13. SAWG Action Items Edit the RASDS document according to the agreements reached at the meeting. –To: Shames, Weiss, and Yamada –Due: End of November 2003 Discuss at CESG how to respond to the RID that requested to “provide a consistent set of views and terminology across all of the other Areas and Working groups.” –To: Shames –Due: At the next CESG meeting Study whether UML 2.0/SysML is the best language to use. –To: all –Due: End of December 2003. Prepare a resolution for establishing a liaison relationship with the SysML Partners. –To: Shames –Due: At the next CESG meeting

14. SAWG Resource Problems There may not be enough resources from key agencies to perform items 3 through 5 of the Goals and Deliverables.

15. Risk Management Update Risk: It is still unclear if enough resources are available from the Agencies to perform the necessary jobs. –Mitigation: Acquire adequate resources from CMC –Descoping is possible, but will affect progress in other SEA WGs which have dependencies

16. Security WG: Report of the Fall 2003 Meeting October 28, 2003 Howard Weiss, NASA/JPL/SPARTA

17. Security WG Views Functional Allocations Monitor & Control Data Acquisition Tracking Radiometric Data Collect Data Management Directive Execution Attitude Control Comm Mgmt Connectivity & Communications Mission A Spacecraft Mission A Instrument Control Center Spacecraft Control Center C Ground Tracking Network B Science Spacecraft Science Institute Tracking Station S/C Control Center Trust relationships Policies Privacy / proprietary issues Access control Authentication Firewalls Encryption Boundary access points Enterprise Security Domains

18. SecWG Executive Summary The Charter of the WG was reviewed in depth –The needs for each of the existing work items –Changes made to accommodate additional work items Specifications for authentication, encryption, key management/distribution Use of Common Criteria for Information Technology Security Evaluation (ISO 15408) “Protection Profiles” to describe security requirements for use cases. Discussed the approaches and stages for developing the threat statement. –Convert existing PowerPoint threat presentation into a Green Book. Discussed approaches and first drafts of the Security Architecture –Security portions of the RASDS –Security-specific architecture based on RASDS views Discussed comments on the revised Security Green Book –Discussed enhancements to the Green Book that can easily be incorporated into existing revision.

19. SecWG Summary of Goals and Deliverables 1.Complete update/revision of the Security Green Book. 2.Provide inputs for Security elements in RASDS. 3.Develop Security Architecture. 4.Develop Information Security Threat Statement based on PowerPoint threat presentation. 5.Develop an Information Security Guide for Mission Planners to include threat/risk analysis, security planning, and contingency and disaster recovery. 6.Formulate a security policy framework for developing trust agreements, rules for operational engagement, ensuring security compliance of legacy systems, and standard, secure interfaces between systems and across security domains. 7.Recommend a CCSDS encryption standard. 8.Recommend a CCSDS authentication standard. 9.Recommend a CCSDS key management standard. 10.Work with other WGs with respect to security.

20. Progress Achieved Revised the WG charter based on detailed discussions of needed work items, what is achievable, and what is (has been) needed by CCSDS. It was agreed that a threat statement is a high priority work item and that the mission planners guide would prove to be very useful and is needed. It was agreed that despite the potential problems in adoption because of widely varying policies in individual countries, CCSDS recommendations for interoperability are needed for encryption, authentication, and key management. These have been added to the list of work items. It was agreed that the security architecture work, which has just begun, is progressing along the correct path. The revisions to the Security Green Book were agreed upon based on the received comments and discussions which provided other additions to the book’s contents (e.g., enhanced threat discussion, interconnection rules between networks, trust relationships).

21. Near-Term Schedule DeliverableMilestoneDate Green Book revisions Comments received from WG Publish a revised book for CCSDS approval Complete 12/03 CCSDS Security Architecture (1 st Draft) Publish a draft document (White Book) 12/03 Security Threat Statement Update and convert PowerPoint presentation into Green Book 02/04

22. Open Issues Do the “pure” science missions care about security? Should they be forced to care? Cost/benefit analyses need to be performed to determine whether security is necessary or not in such cases. Can the threat statement document be meaningful without specific illustrations of the threat (which will run into classification issues)? –We think so given example use cases with open source exploits illustrated. “Transparent Security” vs. “Simple to Use Security” –If security is transparent it will always be used because the user does not see it, –However, if it breaks, the user may not know (or care) which may make “simple to use” security better. Architecture issues: –How specific should the architecture be – specific mechanisms, specific algorithms, etc? How does the Security WG work with other WGs and BOFs? –Do we go to them, or do they come to us? –General feeling is that the Security WG has to go to the other WGs.

23. SecWG Action Items Complete revision of the Security Green Book –To: Weiss –Due: November 2003 Security updates for RASDS –To: Weiss –Due: November 2003 Continue development of the Security Architecture –To: Kenny –Due: Issue 1 st draft December 2003 Develop threat document –To: Weiss –Due: February 2004. Check on status of “security statement” required in each CCSDS document as previously recommended and draft another resolution if not already required (see later slide). –To: Shames, Weiss –Due: At the next CESG meeting

24. SecWG Resource Problems Resources are adequate to perform the initial tasks. It has not yet been determined if resources are adequate to accomplish all the work currently on the schedule. There was no ESA representation at this meeting which means that a significant CCSDS member was not represented. This should be fixed.

25. SecWG Risk Management Update Risk: It is still unclear if enough resources are available from the Agencies to perform the necessary jobs. –Mitigation: Evaluate progress at the time of the next set of deliverables –Mitigation: Seek active involvement from ESA

26. Information Architecture BOF Fall 2003 Meeting October 28, 2003 Dan Crichton, NASA/JPL

27. Directive Generation Command Execution Directive Execution Command Schema & Structure Definition Operations Plan Schema & Structure Definition Information Architecture Objects Relationship to Functional View Instantiation Observation Plans Instrument Commands S/C Commands S/C Event Plans Information Objects are exchanged among Functional Objects Abstract Data Architecture Meta-models Data Models Actual Data Objects Information Object Data Object Representation Information Semantic Information Structure Information 1..n Instantiation Information Object Data Object Representation Information Semantic Information Structure Information 1..n Operation Plans Commands Realization

28. IA BoF Executive Summary The Charter of the BoF was reviewed, revised and is being submitted to the CESG for WG consideration. The Storybook on the Reference Architecture for Space Information Architecture was presented and reviewed and there was general agreement on the conceptual architecture presented. The MOIMS Packaging and Registries WG presented the packaging standard along with a set of class libraries, APIs and sample GUI. JPL presented work on developing a prototype product service within the Deep Space Mission System.

29. Summary of Goals 1.Define a reference end-to-end space information architecture for interoperability and cross-support that encompasses both flight and ground data system operations and provides a common framework for use by standards and systems developers including a. standard functional components for information management b.definition of standard interfaces for information management c.standards in information representation d.standards in defining information processes 2.Define and leverage common methods for representing information architectural views; and 3.Address application layer information management issues including application protocols and data handling and ensure that they are dealt with in a clear and consistent way throughout the end-to-end system; and 4.Work with the SEA System Architecture WG to provide the Information Architecture elements for the Reference Architecture for Space Data Systems (RASDS) and with the MOIMS WGs to develop the specific standard interfaces & protocols. Make recommendations to the other Working Groups and BoFs about architectural choices and options.

30. Summary of Deliverables 1.Define how component and interface information standards within CCSDS fit into the Reference Architecture for Space Data Systems (RASDS); 2.Identify formal representation methods, tools and approaches that will permit design, modeling, and simulation of information architectural designs including collaboration with SAWG. 3.Write a CCSDS space information architecture recommendation that includes: a.a set of functional information infrastructure components; b.a set of information infrastructure interfaces for information management; c.a set of information descriptors that are capable of representing data across the mission lifecycle; d.a set of interfaces for cross support services, application program interfaces, and information management & access protocols.

31. Progress Achieved A charter for the Space Information Architecture BoF was finalized. It was agreed that the Storybook presented a good foundation for a preliminary reference space information architecture and that a white book should be started based on the work. 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.

32. Near-Term Schedule DeliverableMilestoneDate Create WGDevelop a charterOctober 2003 Reference Information Architecture (Standard) Distribute a reference Information Architecture White Book for general review April 2004 Best Practices Document Develop a best practices document for instantiation of the architecture October 2004

33. IA BoF Open Issues There are few technical issues concerning the Space Information Architecture presented. –Most issues relate to terminology and chartsmanship. –Comments were captured and will be incorporated into an updated version. –It was agreed that more issues may arise once the white book is developed. The packaging work that was presented needs to be validated by a prototype.

34. IA BoF Action Items Submit charter to CESG for creation of WG –To: Shames, CESG –Due: End of October 2003 Develop White Book based on Space Information Architecture Storybook –To: Info Arch BoF Members –Due: Preliminary version by December 2003 Validate packaging approach via JPL DSMS prototype –To: Shames –Due: March 2004

35. IA BoF Resource Problems There may not be adequate resource commitments from member agencies to achieve deliverables. ESA and CNES considered important stakeholders, but have not yet made formal commitments.

36. IA BoF Risk Management Update Risk: Agencies and projects implement information architectures without coordinating or adopting interoperable standards or reference architectures for managing and sharing information. –Mitigation: Develop these standards are rapidly as is practical Risk: Standards for interfaces and protocols for distributed services are still under development. –Mitigation: Identify and adopt or adapt for space use the best of breed of current distributed frameworks Risk: Languages and tools to be used in our work are still under development. –Mitigation: Work with SAWG to identify and adopt common approach, or use other common information modeling approaches in interim

37. Summary of the Joint Systems Engineering Area and Spacecraft Onboard Interface Services Area Special Interest Group Meeting October 29, 2003 Takahiro Yamada, JAXA/ISAS

38. Requirements for Onboard Communications Applications –Time distribution, Message transfer, Control and data acquisition QoS –Isochronous and asynchronous Reliability –Reliable and Error tolerant (handling of errors is up to the application) Routing and relay capability –Onboard and End-to-end Addressing –Onboard, End-to-end, (End points independent of the location) –Name to address mapping in a global context Underlining Links –Onboard buses and Space links

39. Solutions The requirements described in the previous slide are met by the protocol configuration shown in the next two pages. Basic SOIS Reference Architecture and Implementation approach have been vetted. Assumption is that IP (or SCPS) on-board networking is feasible, but support for CCSDS Packet based systems must be retained. A “thin transport layer” approach also appears interesting as does use of the Message Transfer Service. Static routing and naming are believed to be adequate for the near term.

40. Reference Model Physical Layer Data Link Layer Network Layer Sub-Network Dependent Convergence Sub-Layer Transport Layer Confirmed or Unconfirmed Data Transport Application Layer Message Transfer Applications Space Applications File Transfer Network Management SOIF C&DA Service SOIF Time Dist Service SOIF Plug & Play Service Sub-Network Independent Convergence Sub-Layer DRAFT

41. Implementation Model Physical Layer Physical Layer: IEEE-1394, SpaceWire, MIL-STD-1553B, OBDH, etc. Data Link Layer Data Link Layer: IEEE-1394, SpaceWire, MIL-STD-1553B, OBDH, etc. Network Layer Sub-Network Dependent Convergence Sub-Layer Network Layer: IP or SCPS-NP Transport Layer Transport Layer TCP/UDP or SCPS-TP Application Layer Message Transfer SOIF C&DA Service Applications SOIF Time Dist Service Space Applications Intra Processor Communication (Provided by OS) Inter Processor Communication Services File Transfer Network Management Communication Services SCPS-SP (as required) SOIF Plug & Play Service Sub-Network Independent Convergence Sub-Layer DRAFT

42. Sub-Network Independent Convergence Sub-Layer Resides at the bottom of the Network Layer Functions –Scheduling and bandwidth management –Flow control (usually a transport function) –Protocol multiplexing –Time signaling Three service types –Isochronous –Asynchronous connection-based, i.e. reliable –Asynchronous connectionless

43. Sub-Network Dependent Convergence Sub- Layer Resides at the top of the Data Link Layer Functions –Datagram Fragmentation / assembly –Network to MAC address translation –Functionality mapping, e.g. LAN-like behavior from 1553 master/slave bus –Fault tolerance (for isochronous service)

44. Next Steps for SOIS Specify the services (Subnet Ind/Dep Convergence Sub-Layers) Validation of the model and assumptions by prototyping services over common datalink layers Develop Use Cases (including space-to-space and space-to-ground links) Define profiles (combinations of options to support particular applications environments) Revisit internetworking approach with expert team once prototyping results are available

45. System Engineering Area Summary and Resolutions 30 October 2003 Peter Shames NASA/JPL

46. SEA Document Summary SAWG –RASDS Draft 0.7 available for internal review –Open review of RB V1 expected by Apr 04 –Draft Green Book expected Dec 03 SecWG –Updated Security GB out for internal review –Open review expected Spring 04 InfoArch BoF –Charter ready for approval by CESG / CMC –Draft Info Arch presentation available now –Draft WB available for open review by Apr 04

47. SEA Cross Area Coordination CSS: –Transport security –Use of SecWG authentication & access control MOIMS: –Coordination between Packaging and Registries & Information Architecture –Language expert support of SAWG modeling language –Alignment w/ SOIS Time Critical Applications and MOIMS S/C Mon & Con –Use of SecWG authentication and security framework –Nav inputs to Time Services Arch SIS: –Inputs to Time Services Arch –Uplink & downlink network layer security SLS: –Inputs to Time Services Arch –Uplink & downlink link & physical layer security SOIS: –On-board and proximate networking alignment w/ SIS –Relationships among C&DA, MTS, MOIMS Mon & Con –Uplink, downlink & on-board security

48. New Working Items, New BOFs, etc. SAWG: –None identified. SecWG –Encryption recommendation. –Authentication recommendation. –Key Management recommendation. –Security policy framework document IAWG –A best practices document on deploying a space information architecture will be developed. SOIS/SEA SIG –New work items for SOIS identified.

49. Other Proto - BoFs 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 input for this BOF –Need to examine current Control Authority documents, processes and data structures to determine utility –Suggestion to leverage distributed information management infrastructure being defined by IA BoF ? –Needs input from SEA - IA BoF, MOIMS (IPR & Nav), CSS, SLS, Secretariat CMC must determine how it wishes to handle this and to identify resources to define and operate it

50. Other Proto - BoFs, contd 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 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

51. Resolutions for CMC Approval SEA-03-10-1: The Systems Engineering Area resolves to publish a Red Book on the Reference Architecture for Space Data Systems (RASDS) for Agency review, based on updates to the current White Book. SEA-03-10-2: The Systems Engineering Area resolves to establish a liaison relationship between CCSDS and the SysML Partners for cooperating in development of a language for describing space data systems and to appoint the Systems Architecture Working Group as the point of contact within CCSDS. SEA-03-10-3: The Systems Engineering Area resolves to request updating the SecWG charter to include additional explicit deliverables.

52. Resolutions for CMC Approval, contd SEA-03-10-4: The Systems Engineering Area resolves to request that the CMC mandate that all CCSDS Recommendations shall include a section with a credible review of security issues and implications detailing the security analysis performed with respect to the work area. If security mechanisms/features are not included in the document, a section must provide detailed rationale as to why. SEA-03-10-5: The Systems Engineering Area resolves to request establishment of an Information Architecture WG. The charter developed by the Information Architecture BoF is being provided to the CESG.

53. Resolutions for CMC Approval, contd SEA-03-10-6: Re SAWG Goal 6 and CSS RID. The Systems Engineering Area resolves to request the Secretariat to take responsibility for updating the existing Glossary (A30x0g3, 1997), defining a consistent set of terms, and ask the CESG to identify a process to ensure this and a group to curate this. SAWG will develop a self consistent set of terms that may be used to develop individual architectures, but will not define nor reconcile domain specific terms.

54. Resolutions for CMC Approval, contd SEA-03-10-7: The Systems Engineering Area notes that Cross Area coordination is much more difficult if meetings are held at different times and in disjoint locations. Therefore the Systems Engineering Area requests that the ADs and host agencies for future meetings schedule Area meetings so that they are in physical proximity if they are in temporal proximity.

55. BACKUP SLIDES

56. IP in Space

57. SEA Internal Issues Concern re getting adequate agency participation for this new Area and WGs How do we best get involvement of other Areas & WGs? (Area/WG liaison members, joint mtgs, collaboration on BCP, roadshow) Develop Use Cases for SecWG and InfoArchWG Work SOIS & CSS cases as a test for RASDS approach Ensure that we integrate the different WG viewpoints into SEA / RASDS approach –Integrate Information and Security architectures –Coordinate sub-architectures among SEA groups (i.e. security architecture).

58. 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 proposal pending a positive response from Peter, and recommends that Jim act as the SysML liaison to CCSDS, and that Peter identify a CCSDS liaison.

59. Cross Area WG / BOF Issues Security is a cross-cutting discipline that needs to be included in many other Areas and WGs. We discussed how this would be best performed – by having other WGs come to the Security WG for help or by having the Security WG go to the other groups to provide support. –It was felt that the proactive approach would work best but resource constraints will be an issue.