System Engineering Area Fall 2003 Meeting Reports

1. System Engineering AreaFall 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 AreaOverview • 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. Business Concerns Organizational perspective Enterprise Physical Concerns Node & Link perspective Connectivity Computational Concerns Functional composition Functional Data Concerns Relationships and transformations Information Protocol Concerns Communications stack perspective Communications Space Data System Several Architectural Viewpoints Derived from: RM-ODP

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

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 • Define a reference architecture that provides a framework for generation of space data systems standards and development of space data systems. • Document the reference architecture identifying basic elements. • Develop a document that provides to the other Working Groups and BoFs guidelines on how to apply the reference architecture. • Develop formal methods for representing space data systems architectures that will enable sharing of architectural information among engineers. • 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

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

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 • Complete update/revision of the Security Green Book. • Provide inputs for Security elements in RASDS. • Develop Security Architecture. • Develop Information Security Threat Statement based on PowerPoint threat presentation. • Develop an Information Security Guide for Mission Planners to include threat/risk analysis, security planning, and contingency and disaster recovery. • 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. • Recommend a CCSDS encryption standard. • Recommend a CCSDS authentication standard. • Recommend a CCSDS key management standard. • 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

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 1st 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 BOFFall 2003 Meeting October 28, 2003 Dan Crichton, NASA/JPL

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

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 • 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 • standards in defining information processes • Define and leverage common methods for representing information architectural views; and • 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 • 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 • Define how component and interface information standards within CCSDS fit into the Reference Architecture for Space Data Systems (RASDS); • Identify formal representation methods, tools and approaches that will permit design, modeling, and simulation of information architectural designs including collaboration with SAWG. • 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

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 AreaSpecial 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. Space Applications DRAFT Applications SOIF C&DA Service SOIF Time Dist Service SOIF Plug & Play Service Network Management Application Layer Message Transfer File Transfer Transport Layer Confirmed or Unconfirmed Data Transport Network Layer Sub-Network Independent Convergence Sub-Layer Sub-Network Dependent Convergence Sub-Layer Data Link Layer Physical Layer DRAFT Reference Model

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

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 AreaSummary 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: • Applications (onboard and ground) • General services to support applications (incl end-to-end) • 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