Embed Size (px)
Citation preview
System Engineering AreaFall 2003 Meeting Reports
30 October 2003
Peter ShamesNASA/JPL
Agenda
• Overview
• Technical Reports– System Architecture WG– Security WG– Information Architecture BoF– SOIS / SEA SIG
• Cross Area Technical Issues
• Draft Resolutions for CMC
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
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 s
pacecraft onboard, space - space and space - ground environments.
Systems Architecture WG:Report of the Fall 2003
Meeting
October 28, 2003
Takahiro Yamada, JAXA/ISAS
Space Data System Several Architectural Viewpoints
EnterpriseBusiness ConcernsOrganizational perspective
ConnectivityPhysical ConcernsNode & Link perspective
FunctionalComputational ConcernsFunctional composition
InformationData ConcernsRelationships and transformations
CommunicationsProtocol ConcernsCommunications stack perspective
Derived from: RM-ODP
Mission BFD
Development &
Operations
Domain
Enterprise ViewFederated Enterprises with Enterprise Objects
Planning Phase
Mars Exploration
Program FederationMission 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
EnterpriseObjects
Cross- SupportAgreement
OperationsContract
InstrumentIntegration
Domain Concerns:ObjectivesRolesPoliciesActivitiesConfigurationContractsLifecycle / Phases
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.
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.
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.
Near-Term Schedule
Deliverable Milestone Date
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
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.
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
SAWG Resource Problems
• There may not be enough resources from key agencies to perform items 3 through 5 of the Goals and Deliverables.
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 othe
r SEA WGs which have dependencies
Security WG:Report of the Fall 2003
Meeting
October 28, 2003
Howard Weiss, NASA/JPL/SPARTA
Security WG Views
Functional Allocations
Monitor &Control
DataAcquisition
Tracking
RadiometricData Collect
DataManagement
DirectiveExecution
AttitudeControl
CommMgmt
Connectivity &Communications
Mission ASpacecraft
Mission AInstrument
ControlCenter
SpacecraftControl
Center C
GroundTracking Network
B
ScienceSpacecraft
ScienceInstitute
TrackingStation
S/C ControlCenter
Trust relationshipsPoliciesPrivacy / proprietary issues
Access controlAuthentication
FirewallsEncryptionBoundary access points
Enterprise Security Domains
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.
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 t
hreat 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.
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).
Near-Term Schedule
Deliverable Milestone Date
Green Book revisions
• Comments received from WG
• Publish a revised book for CCSDS approval
Complete
12/03
CCSDS Security Architecture (1st Draft)
• Publish a draft document (White Book)
12/03
Security Threat Statement
• Update and convert PowerPoint presentation into Green Book
02/04
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 illustr
ated.• “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, specifi
c 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.
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
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.
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
Information Architecture BOF
Fall 2003 Meeting
October 28, 2003
Dan Crichton, NASA/JPL
DirectiveGeneration
CommandExecution
DirectiveExecution
CommandSchema & StructureDefinition
Operations PlanSchema & StructureDefinition
Information Architecture ObjectsRelationship to Functional View
Instantiation
ObservationPlans
InstrumentCommands
S/C Commands
S/C Event Plans
Information Objects are exchanged among
Functional Objects
AbstractData Architecture
Meta-models
Data Models
Actual DataObjects
InformationObject
DataObject
RepresentationInformation
SemanticInformation
StructureInformation
1..n
Instantiation
InformationObject
DataObject
RepresentationInformation
SemanticInformation
StructureInformation
1..n
OperationPlans Commands
Realization Realization
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.
Summary of Goals 1. Define a reference end-to-end space information architecture for interoperability and c
ross-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 managementb. definition of standard interfaces for information management c. standards in information representationd. 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.
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.
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.
Near-Term Schedule
Deliverable Milestone Date
Create WG • Develop a charter October 2003
Reference InformationArchitecture (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
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 in
to an updated version. – It was agreed that more issues may arise once the w
hite book is developed.
• The packaging work that was presented needs to be validated by a prototype.
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
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.
IA BoF Risk Management Update
• Risk: Agencies and projects implement information architectures wi
thout 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
Summary of the Joint Systems Engineering Area and Spacecraft Onboard Interface Services AreaSpecial Interest Group
Meeting
October 29, 2003
Takahiro Yamada, JAXA/ISAS
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
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.
Reference Model
PhysicalLayer
Data LinkLayer
NetworkLayer
Sub-Network Dependent Convergence Sub-Layer
Transport Layer
Confirmed or Unconfirmed Data Transport
Application Layer
Message Transfer
Applications
Space Applications
File TransferNetwork Management
SOIF C&DAService
SOIF TimeDist Service
SOIF Plug &Play Service
Sub-Network Independent Convergence Sub-Layer
DRAFT
DRAFT
Implementation Model
PhysicalLayer
Physical Layer:IEEE-1394, SpaceWire, MIL-STD-1553B, OBDH, etc.
Data LinkLayer Data Link Layer:
IEEE-1394, SpaceWire, MIL-STD-1553B, OBDH, etc.
NetworkLayer
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&DAService
ApplicationsSOIF TimeDist Service
Space Applications
Intra ProcessorCommunication
(Provided by OS)Inter ProcessorCommunicationServices
File TransferNetwork ManagementCommunicationServices
SCPS-SP (as required)
SOIF Plug &Play Service
Sub-Network Independent Convergence Sub-Layer
DRAFT
DRAFT
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
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)
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
System Engineering AreaSummary and Resolutions
30 October 2003
Peter ShamesNASA/JPL
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
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
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 ar
chitecture will be developed.
• SOIS/SEA SIG– New work items for SOIS identified.
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
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 Oper
ations, 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
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.
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.
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.
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.
BACKUP SLIDES
IP in Space
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).
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.
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 be
st but resource constraints will be an issue.
