Constellation Program Command, Control, Communications and Information (C3I) Overview of the Preliminary Concepts - PowerPoint PPT Presentation

Loading...

PPT – Constellation Program Command, Control, Communications and Information (C3I) Overview of the Preliminary Concepts PowerPoint presentation | free to download - id: 3b387d-ZmMxM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Constellation Program Command, Control, Communications and Information (C3I) Overview of the Preliminary Concepts

Description:

Constellation Program Command, Control, Communications and Information (C3I) Overview of the Preliminary Concepts Summarized by Will Ivancic NASA GRC – PowerPoint PPT presentation

Number of Views:97
Avg rating:3.0/5.0

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Constellation Program Command, Control, Communications and Information (C3I) Overview of the Preliminary Concepts


1
Constellation ProgramCommand, Control,
Communications and Information (C3I) Overview of
the Preliminary Concepts
  • Summarized by Will Ivancic
  • NASA GRC

2
C3I Team Background
  • C3I Architecture evaluation team formulated as
    CEV tasker in July 2004.
  • Multi-center team assembled to assess
    interoperability and architecture approaches to
    address Cx needs.
  • Participation from JSC, KSC, MSFC, GSFC, JPL
    (including operations and engineering
    communities). Detailed supporting white papers
    were generated drawing on over 50 of NASA
    experts on various architecture areas (see
    attached list).
  • Assessment results documented in C3I
    Architecture Report, Nov. 2004.
  • In 2005, C3I team worked as part of the
    Exploration Communications Navigation Systems
    (ECANS)
  • Supported SEI Integrated Discipline Teams (IDT)
    analysis and trades.
  • Supported ERTT assessments requirements
    development efforts
  • Directed to begin development of
    interoperability specification
  • Worked with Space Communications Architecture
    Working Group (SCAWG) on selection of RF link
    definitions.
  • In 2006, C3I team moved to CxPO and became the
    C3I Systems Integration Group (SIG).
  • SIG includes membership from all level 3
    projects, ECANS, ISS, APO, Ops Integration,
    SRQA, TV, Mission Operations.
  • From May-Sept 06, included 100 engineers from
    around NASA. Currently, 60 engineers.
  • C3I SIG leadership/team staffed heavily with
    matrix engineers from engineering and operations
    organizations (from almost all NASA centers).
  • C3I SIG is working to develop the correct set of
    requirements and architecture based on
    trades/analysis and continual technical exchange
    w/ L3 (as systems become more defined).

3
Needs/Trends/Challenges
  • Systems engineering needs and trends
  • Increasing focus on capability-based acquisition
  • Increasing focus on maximizing user value
  • Increasing reliance on systems of systems
  • Disproportional increase in complexity and
    interdependency
  • Disproportional increase in needs for
    interoperability
  • Increasing COTS, open source, reuse, and legacy
    integration
  • New challenges in systems engineering and program
    management
  • Integrated end-to-end emphasis, rather than
    individual System
  • Long term evolutionary development, rather than
    short term, revolutionary
  • Capability (ability to perform many, loosely
    coupled tasks), rather than functionality
    (ability to perform a few, very specific tasks)
  • Lifecycle perspective, rather than acquisition
    focused
  • Negotiation, rather than mandate

C3I architecture is intended to address these
trends
4
C3I Overview
  • Network-Centric Architecture
  • IP based network throughout.
  • Leverage wide range of tools, software, hardware,
    protocols.
  • Open standards established interfaces.
  • Very flexible extensible.
  • Enables open architecture that can evolve.
  • Requires architecture be established across all
    Cx elements.
  • C3I Approach
  • C3I fundamentally cuts across all elements and
    must function as a single system (different
    from most systems which partition more along
    physical lines).
  • Historically, communications, networks, command
    and control, security, and information systems
    were designed and developed separately.
  • Legacy systems optimized for given
    vehicle/mission vs. Cx systems which must
    accommodate multiple elements/vehicles AND be
    flexible to exploration style operations.

Wide area network connections can be via
terrestrial infrastructure, umbilical hard-lines,
or wireless (RF) links. Elements act as network
nodes that route and relay traffic (as in a mesh
network).
5
C3I Overview
  • Layered approach
  • Isolates change impacts (enabling evolution)
  • Based on industry standards.
  • Includes publish subscribe messaging framework
    (enabling plug-n-play applications by
    establishing well defined data interfaces).
  • Interoperability
  • Focus on standards and approaches that enable
    interoperability between elements.
  • Establish small set of interface standards
    reduce possible number of interface combinations.
  • Requires interoperability at all layers
    communications, networks, security, C2, and
    information.

Publish subscribe based framework abstracts
communications and inter-application interfaces.
It also enforces a consistent data model, any
required security, and limited application
interfaces.
6
C3I Interoperability Specification Scope
  • Interoperability Specification only deals with
    the interfaces and protocols at the element
    interface, NOT the internal (application, API)
    interfaces.

Note For future Cx configurations, the C3I
architecture will evolve to include increased C2
interoperability.
7
State-of-the-Art Comparison
  • Future
  • Autonomous link negotiation
  • Autonomous configuration
  • Flexible resource allocations
  • Seamless interoperability between ground and
    space networks
  • Dynamic configurations
  • Delay tolerant networking
  • NASA missions as National Assets
  • Network layer encryption and mix of open and
    closed networks
  • Data protection in motion and at rest
  • Multiple, survivable, frameworks with common APIs
  • Dynamic operations models
  • Dynamic, cross-linked knowledge repositories
  • Current
  • Communications
  • Link planning and scheduling
  • Manual configuration
  • Fixed resources allocations
  • Networks
  • Non-routable systems in space requiring gateway
    functions
  • Fully routable ground networks
  • Static configurations
  • Security
  • NASA Missions as civilian assets
  • Link layer encryption and closed networks
  • Data protection from point to point
  • Command and Control
  • Large, complex, single purpose facilities
  • Static operations models
  • Information Model
  • Ad hoc data repositories

8
Current Architecture
9
NASA Network Architecture Evolution
  • From SCAWG Architecture Report (3/06)
  • DSN complexes will be replaced with large arrays
    of small aperture antennas (12m)
  • Multi-mission support will be provided to
    near-Earth and deep-space users
  • Lunar is in between these cases
  • S, X and Ka-band support
  • Low-Density Parity Check (LDPC) FEC codes will be
    standard
  • Automated, integrated scheduling systems
  • CCSDS compliant data interfaces (AOS, SLE)
  • Non-CCSDS implementations will require additional
    upgrades but this is a new system
  • Near Earth Relay (TDRSS) will be replenished with
    advanced capability space segment
  • Ku-band will be discontinued
  • IP-based users (MA-DAS) and IP/SLE connections
    will comprise the bulk of the S-band community
  • LDPC FEC codes will be added to the standard
    ground processing
  • Integrated scheduling and service management
    across networks (integrated with GN, DSN)

10
Conceptual Lunar Communications Architecture
11
Structure of Communication Protocols
  • Point-to-Point Links
  • Operational provides highly available command /
    telemetry path for normal operational voice,
    data, situational awareness. Provides
    radiometrics for orbit / trajectory determination
    and rendezvous / docking operations.
  • High Rate provides high volume data transfer
    for video, science, recorder dumps, large file
    transfer.
  • Contingency Voice provides high availability,
    low complexity voice communications to protect
    options in the event that the prime communication
    systems are unavailable.
  • Recovery RF provides communication and location
    capability to permit recovery of crew and vehicle
    post-landing.
  • Multipoint
  • Provides multiple user, simultaneous
    communications capability for EVA, proximity
    operations, and surface area networks.
  • Internal Wireless
  • Provides communication between systems and
    portable equipment (laptops, PDAs)
  • Provides communication between sensors and
    wireless devices for location, inventory, crew
    biomedical data, headsets, etc

12
Constellation Communications Urban Legends
  • C3Is communications are not compatible with
    international partners.
  • All layers of the C3I communications stack are
    mapped to CCSDS standards.
  • SNUG references provide complete specifications
    for use of TDRSS.
  • SN compatible flight hardware is readily
    available from European manufacturers
  • C3Is data link uses international standards (RFC
    2427 and ITU-T Q.922)
  • C3Is implementation of IP communications follows
    IP over CCSDS Space Links recommendation (CCSDS
    702.0-R-1).
  • C3I Comm team is working with CCSDS groups to
    ensure future CCSDS standards and recommendations
    meet Constellation communication needs
  • C3Is modulations are not compatible with
    existing ground stations.
  • Space Network modulations are BPSK and QPSK.
  • PN direct-sequence spread spectrum is used to
    provide ranging data and spectrum re-use.
  • Data Group 2 modulations are un-spread, BPSK
    uplink, QPSK downlink.
  • Commercial and international ground stations
    support BPSK and QPSK
  • CCSDS RF standards call for BPSK and QPSK
    suppressed carrier modes
  • Note C3Is FEC code will require addition of new
    decoders at ground stations. White Sands and DSN
    are implementing the selected code in their
    baselines.
  • Ranging will require addition of SN PN ranging
    systems commercially available INSNEC receiver
    Made in France

13
Point-to-Point Communication Protocols
  • Supports current and planned NASA networks
  • Follows CCSDS recommendation for IP over CCSDS
    Space Links
  • Space Network (TDRSS) Signal Formats
  • S-Band DG1 (Modes 1-3), DG2 (SSAF/R, SMAF/R)
    modulations
  • Ka-Band (KaSAR/F) modulation
  • SN signal formats are supported by US,
    international and commercial
  • CCSDS compliant in non-Spread modes
  • Link Layer Formatting CCSDS
  • CCSDS symbol randomization frame synch
  • CCSDS FEC (Rate ½ LDPC)
  • CCSDS AOS Transfer Frame w/ VCA service
  • Data Link Layer Provide support to IPv4 and
    extensibility to IPv6
  • Multiprotocol Interconnect over Frame Relay
    (MPoFR)
  • Permits native use of both IPv4 and IPv6
  • Use of Q.922 framing per RFC 2427 allows bridging
    between MPoFR and CCSDS AOS in a manner compliant
    with CCSDS recommendations

14
Network Discipline Requirements Highlights
  • C3I Interoperability Standards Book Vol. 1,
    Interoperability Standards
  • Section 3.3.1 IP Connectivity Describes basic
    requirements for a System to be connected to a Cx
    IP network Network (IPv4, IPv6) and transport
    Protocols (udp, tcp), addressing, routing,
    multicast, manipulation of network tables and
    configuration, basic device management
  • Other subsections of 3.3.1 add additional
    capability and as such are not necessarily
    required by all systems, for example
  • 3.3.2 Dynamic Routing Between Systems The use
    of routing protocols
  • 3.3.4 Domain Name Service Automation of name to
    address resolution
  • 3.3.5 DTN (Disruption Tolerance Networking)
  • 3.3.6 and 3.3.7 DHCP (automated addressing)
    support for small System
  • 3.3.10 Network Management Increased information
    and management capability
  • Other Vol. 1 sections of concern
  • 3.2 Hardline requirements for deterministic and
    high volume intersystem connectivity
  • 1394b has been selected for both
  • 3.5.1 Voice Exchange Sets codec, operations, and
    voice quality standards
  • 3.5.2 Motion Imagery Exchange Sets codec and
    operations standards
  • 3.5.4 Time Exchange Currently NTP is specified

Custom Interface
CEV2
Legacy
10.2.0.0/16
Element
CEV1
LAN
WAN
10.1.0.22
Net
L1/L2
Relay
Relay
10.1.0.1
GS1
GS2
GSN
10.0.0.1
Ground
Network
MOC
15
Space Routing PROPOSED Network Architecture
  • Equipment
  • Routers
  • Cisco 2501
  • Cisco 2505
  • 2 Cisco 2621
  • Cisco 3640
  • Ethernet interfaces
  • Issues
  • Can hosts communicate if they are not on the same
    subnet?
  • If hosts are on the same subnet, is dynamic
    routing possible?
  • Can IPv6 solve these problems?
  • Cannot configure Net_relay interfaces w/ IPs
    addresses in same subnet

Preliminary Work Need Validation
16
Space Routing Testbed Setup
  • Findings
  • In IPv4 hosts in different subnets cannot route.
  • In IPv6, routing is valid across different
    subnets due to link local addressing. As shown in
    the GS_1 to GS_2 link.

Preliminary Work Need Validation
17
Link Layer Protocol IP over HDLC or AOS
  • Two studies were conducted in order to try to
    determine the best method of encapsulating IP for
    transmission over Cx RF links
  • First study There is insufficient technical
    discriminator between the FR/HDLC and FR/HDLC/AOS
    options.
  • Second study Supports Frame Relay, based upon
    the availability of commercial products and
    commercial code and the separation of the link
    layer from the error correction code. The Frame
    Relay specification includes a modified form of
    HDLC. AOS octet stream service is included to
    provide regular blocks for the error correction
    code without the need for additional development.

18
IP Routing in Space
  • Concerns with the expected time required to
    propogate and age out a dynamic routes
  • Evaluate the suitability of the dynamic routing
    protocols for the first two phases of the
    program.
  • Current C3I Spec calls for three interior routing
    protocols RIP (C3I-82), OSPF (C3I-83), OLSR
    (C3I-295).
  • Conclusions
  • The goal of lt 20 seconds appears achievable for
    both the LEO and lunar scenario. for both RIP
    and OSPF
  • OLSR was not sufficiently developed to be
    evaluated, but is designed to converge faster
    than OSPF
  • RIP appears weak, but was not eliminated
  • Recommendations
  • Recommended follow-on work is to develop an
    end-to-end concept for telemetry and command
    flows. This concept will weave a path through a
    large swath of Cx and C3I and will likely expose
    a number of areas that dont quite mesh today.
  • Recommended additional study to specifically
    include contingency routing

19
Networking Challenges
  • Develop Ops Concepts Stakeholders do not
    understand how IP will be used for Cx
    communications.
  • Solidify Bandwidth and Data System Requirements
    Work with Systems to identify and further refine
    resource requirements
  • Allay fears
  • VoIP fears Much skepticism about voice
    communications over IP.
  • Service quality fears Were developing a
    traffic prioritization model, proof of concept.
  • Routing fears Alter the vision of widely used
    routing and mobility protocols as advanced via
    education and demonstration.
  • Current thinking is to use static routes
    initially
  • Many believe static routing is easier than
    dynamic routing!
  • Time Synchronization Time reference used for
    networking and navigation have dramatically
    different requirements

20
Networking Issues
  • Address assignment and management
  • Name to address resolution
  • Multicast name and address assignment
  • Network device management
  • Security
  • Key Management
  • Policy Management

21
C3I Security Architecture Traffic Partitioning
  • IPsec gateways (e.g., edge routers) ensure
    separation of traffic
  • Traffic flow rules allow only authorized traffic
    between nodes

C2
C2
IPsec Security Gateway
IPsec Security Gateway
Payload
Payload
IPsec Security Gateway
Separate VPNs ensure no payload traffic enters C2
function (just one example of concept)
Note Additional separation at
application layer, where appropriate
C2
Payload
22
Secure Internal-External Network Connectivity
CLV
CEV
  • Downlinked data
  • Science data for public release
  • Video for public release
  • Medical data NOT for public release
  • Private email or voice conversations NOT for
    public release

Flow allowed
Ground Station
Data Archive
Recon. Data
Ground Station
WAN
High assurance controlled interface (CI)
Flow prohibited to external network by CI
X
23
C3I Security vs. Shuttle/ISS Security
  • Complex information distribution patterns
  • C3I solution supports automated/electronic mgmt
    of info distribution
  • Support for partnering long-term exploration
    objectives
  • C3I security architecture enables
  • Secure use of partner-owned, networking-capable,
    DTN-capable relays
  • Secure use of partner-owned vehicles (e.g., for
    refueling)
  • Secure interaction with partner facilities,
    including those in orbit on the Moon
  • Current manned space systems mainly secured at
    communications layer
  • Lack of routable security solutions for space
    will hamper ability to network space assets,
    particularly with external partners
  • Lack of application layer security prevents
    fine-grained control
  • Key management
  • C3I solution supports electronic mgmt and
    updating of keys

24
C3I Security CONOPS - Cryptography
  • Authentication and encryption capabilities at
    network layer for all IP based inter-System data
    exchanges (when not directly attached)
  • Double authentication/encryption is avoided
    through policy mgmt

25
Cx will be a Paradigm Shift
  • NASA missions have developed their own IT
    infrastructures to support communications,
    command, control and information management,
    which proved to be a satisfactory solution in
    many cases
  • The Constellation presents a different challenge
    by its increased complexity induced by the large
    number of simultaneously inter-operating elements
  • The highly distributed environment of the
    Constellation requires co-operation of many
    different parties, including NASA and its
    contractors. The accurate dissemination of
    information among these players will enable them
    to interact more effectively
  • Numerous NASA C3I-enabled systems with different
    functionality, handling different kinds of
    information and made by different manufacturers
    should be able to take part in an overall
    information network and seamlessly interchange
    operational information

26
C3I External Interactions
  • Overall
  • Efforts to date have been very limited due to the
    SBU nature of most C3I work
  • Standards Organizations
  • Have had an ongoing awareness-level interaction
    with numerous standards groups for communications
    and information system standards. Now working to
    be more involved
  • CCSDS multiple working groups
  • ESA is pushing the development of a new set of
    interoperability and commonality standards. NASA
    has not been engaged in the effort for the past
    two years
  • NASA, with support from C3I and Level III (MCC),
    will participate in the week-long technical
    meetings in January in Colorado Springs and we
    plan to seriously evaluate their efforts and look
    for areas of common need and continued
    interaction
  • Object Management Group (OMG) Space Domain Task
    Force
  • XTCE is the master telemetry and command list
    standard now being widely accepted in industry
  • One of the XTCE authors now on the C3I Info team
    and will present the OMG with any recommended
    changes, if needed, to accommodate Cx
  • XTCE will be the first joint OMG-CCSDS standard
  • NCOIC Net-Centric Operations Industry
    Consortium Satellite Ground Systems Working
    Group
  • C3I has periodic discussions, but C3I and other
    NASA initiatives are somewhat ahead of where the
    NCOIC working group is currently

27
C3I General Outreach Vendor Interaction
  • There is a lot of interest throughout the
    commercial products industry to either be
    directly involved with NASAs Cx work or to
    follow the leads of Cx, as any new ideas will
    probably spread beyond Exploration
  • C3I has had limited meetings and demonstrations
    from vendors, but generally only to understand
    their products not to discuss C3I
  • Ready to now expand to discuss C3I concepts with
    both space-domain-specific companies and general
    product organizations (Google?, Business Process
    companies, framework companies, etc.)
  • GSFC operates a lab of commercial vendor products
    and has regular interaction with most of the
    command and control COTS vendors
  • C3I is planning a command and control COTS vendor
    day
  • About 10 COTS vendors to be invited to a tailored
    industry interaction day
  • Not related to any ongoing procurements
  • Will be repeated at up to 5 NASA Centers
  • Chance for Centers to better understand state of
    the industry and for industry to see where we are
    headed and to establish contacts
  • February-March 2007 timeframe
About PowerShow.com