High Performance Collaboration – The Jump to Light Speed
How to Architect Family of Complex Space Systems and Networks?
1. Architecting Families of Complex
Space Systems and Networks
NASA Goddard Space Flight Center
Systems Engineering Seminar
10.07.08
Kul Bhasin
NASA Glenn Research Center
Phone: 216.433.3676
Email: Kul.B.Bhasin@nasa.gov
2. SCaN “As-Is” Architecture
Development Team
Architecture Team Lead Network Technical Points of Contact
Kul Bhasin Cont.
T. Pham DSN
Network Architecture Leads Stan Rubin NISN
Abhijit Biswas DSN Peter Shames DSN
James Bowen DSN Chris Spinolo NISN
Wesley Eddy NISN Wallace Tai DSN
Eric Knoblock GN
Mike Phillips SN DoDAF and RASDS Architecture
Jeffrey Gilbert
Network Technical Points of Contact Chuck Putt
C. Chang DSN
Angela Culley NISN IT Support
Larry Kiser SN Lee A. Jackson
Stephen Levitski GN Sherry L. Peck-Breen
A. Operchuck NISN NASA Glenn Logistics and Technical
Information Division (LTID) Support
2
3. Lunar Communication and Navigation Systems
(LCNS) Development Team
Team Lead Navigation Space Segment
Kul Bhasin / Ron Miller Mike Mesarch Mark Flanegan
Mike Moreau
Operational View Brian Kennedy Lunar Surface Segment
Kul Bhasin Joe Connolly Mike Cauley
Kar-Ming Cheung Doug Hoder
David Irimies Networking Views Chuck Sheehe
Tony Hackenberg Loren Clare Alan Downey
John Hudiburg Rich Slywczak Afroz Zaman
David Lassiter Kul Bhasin Kue Chun
Tom Sartwell Steve Gnepp Joe Warner
Jonathon Gal-Edd Chuck Putt
Jeff Hayden Document Development
Technical View Ruth Scina
Systems View Loren Clare Paulette Ziegfeld
Kul Bhasin Steve Gnepp
Charles Putt SCWAG Participants
Chuck Sheehe Ground Segment Jim Shier
Joe Connolly Jonathan Gal-Edd Erica Lieb
Jonathon Gal-Edd Tom Sartwell
Jeff Hayden
3
4. SCaN Cx-Orion Architecture
Development Team
Architecture Team Lead Operational Views Special Contributors
Kul Bhasin Chuck Putt Tony Hackenberg
Mike Phillips Karen Richon
Communications Architecture Tom Sartwell William Walsh
David Miller Jeff Hayden
IT Support
Network Architecture Systems Views Paulette Ziegfeld,
Loren Clare Abi Biswas Editorial
Alan Jeffries Jeff Hayden Jeffrey Gilbert, Graphics
Esther Jennings Jeff Hayden, Graphics
Steve Gnepp Technical Views
Harry Shaw David Miller
Chris Spinolo
Shirley Tseng Traceability
David Miller
Navigation Architecture Ajithamol Painumkal
Brian Kennedy
Mike Maher
4
5. Presentation Overview
• Families of Systems and Networks:
Evolutions and Trends
• Systems and Networks Architecting
• Systems Architecture Approach
• Systems Architecture Products
5
7. Evolution of Space Communications Systems
• Clear objectives, • Increased complexity; Unproven • Increase in inter-dependent interfaces;
• Central owner / stakeholder, technologies, • Increase in number and types of systems,
• Requirements-driven • High cost of service, • Protocols,
approach, • Undefined users and customers; • Software use and operational and
• Standard system • Inability to integrate multiple Managerial Independence;
engineering processes . space and ground systems. • Increase in system and operational
complexity.
7
8. Space Communications NoN Evolution
Single Links Multiple Distinct Networks
Supplementing with Manual Management
Terrestrial Networks and Little Interoperability Integrated, Interoperable
Networks With Automated
Management
8
9. Customers:
• Constellation Lunar Surface Systems
GEO Optical • Constellation Orion / Altair
Relay • Lunar Science Missions
Lunar Earth-Based
Relay Ground
Satellite Station
Link from
Relay to
Science on
Farside
Cx Orion
Science EVA Crew
Site
LCT 2
Pressurized
Rover Science
EVA Crew
Cx Altair Site
Pressurized Robotic
Rover Rover
Robotic
LCT 1 Rover
Habitat
10. Customers:
SCaN µwave
• Constellation Lunar Surface Systems
SCaN Optical • Constellation Orion / Altair
GEO Optical
Relay • Lunar Science Missions
Lunar Earth-Based
Relay Ground
Satellite Station
Link from
Relay to
Science on
Farside
Cx Orion
Science EVA Crew
Site
LCT 2
Pressurized
Rover Science
EVA Crew
Cx Altair Site
Pressurized Robotic
Rover Rover
Robotic
LCT 1 Rover
Habitat
11. Customers:
SCaN µwave
• Constellation Lunar Surface Systems
SCaN Optical • Constellation Orion / Altair
GEO Optical
Relay • Lunar Science Missions
Lunar Earth-Based
Relay Ground
Satellite Station
Link from
Relay to
Science on
Farside
Cx Orion
Science EVA Crew
Site
LCT 2
Pressurized
Rover Science
EVA Crew
Cx Altair Site
Pressurized Robotic
Rover Rover
Robotic
LCT 1 Rover
Habitat
12. Customers:
SCaN µwave
• Constellation Lunar Surface Systems
SCaN Optical • Constellation Orion / Altair
GEO Optical
Relay • Lunar Science Missions
Lunar Earth-Based
Relay Ground
Satellite Station
Link from
Relay to
Science on
Farside
Cx Orion
Science EVA Crew
Site
LCT 2
Pressurized
Rover Science
EVA Crew
Cx Altair Site
Pressurized Robotic
Rover Rover
Robotic
LCT 1 Rover
Habitat
13. SCaN µwave Protocol stacks and common standards enable the network
SCaN Optical IP
LNK LNK
DTN PHY PHY DTN
CONV CONV CONV CONV
IP IP IP IP
LINK LINK LINK LINK
PHY PHY PHY PHY
APP APP
TRAN TRAN
IP IP
LNK LNK IP
LINK LINK
PHY PHY PHY
APP PHY
IP DTN
APP LNK LNK LNK
TRAN PHY PHY PHY APP
IP IP DTN
LINK LNK LNK LNK
PHY PHY PHY PHY
DTN IP
CONV CONV DTN LNK LNK
CONV CONV
IP IP PHY PHY
IP IP APP
LINK LINK
LINK LINK DTN
PHY PHY
IP PHY PHY CONV
LNK LNK IP
PHY PHY LNK
PHY
15. Autonomous Space Communications
Technology (ASCoT) Architecture
Application
Data/Query Reserve Publish, Subscribe,
Receive Fail/OK Reserve
Compute Path
QoS based Reservation
Path PLS Routing
Management/Scheduling
Reservation Link
Data/Query Information Make Reservation Information
Receive Forwarding Reservation
Link Database
Buffers Queues Database
Reservation Updates
Data/Query Receive Data/Query Send PLS Send/Receive
Transport (UDP, TCP) MAC Layer
TCeMA, Tx Power,
Network (IP)
Antenna Point/Track,
Node Discovery,
Data Link Framing and Coding (CCSDS, HDLC, DVB, ATM) Node Direction/Range,
Data Synchronization,
Physical Layer (Modulated S and Ka-Band) Data Multiplexing
16. Challenges
• System Engineering processes increasingly demand
architecture when complex systems are being
interfaced in a space environment. However,
architecting remains misunderstood.
• Academic/normative approaches are still emerging,
as a result, the arch for complex systems is being
developed “on the fly” (during program development
process)
• Base systems are becoming more complex in terms
of their numbers (System of Systems, Network of
Networks). 2 levels of complexity.
16
18. Characteristics of Families of Systems and Networks*
• Large Scale Programs and Systems
– As a result, many times, single integrated architecture is infeasible
• Diverse Ownership/Management
– Individual systems might be owned by different agencies/organizations
• Interfaces with Legacy and Future Systems
– Evolutionary development
– New systems must work with legacy systems, and be designed to integrate
with future systems
• Changing Operations Concepts
– Families of systems and networks configuration must be flexible to
accommodate changes
– System and network management capabilities must support adaptability
– Emergent, non-linear properties create changes from original goals
• Criticality of Software
– Systems are integrated via cooperative and distributed software
– Software is used to implement much of the system behavior and functionality
• Networks are Enablers and Serve as Infrastructure
– Development phase
– Operations phase
– Support self-organization of systems and reduce operational burden
*Some of this material is adapted from Anna Warner’s INCOSE Los Angeles Chapter Meeting
Presentation, September 2008 18
19. Why Architecting for Families of Systems and Networks?
• Who uses it?
– Large projects/programs and organizations: military, aerospace,
government, enterprises, etc.
• Who needs it?
– Managers – understand overall system, requirements, operations
concepts, acquisition needs
– Engineers – understand how systems interact, provide common language
and understanding of architecture across diverse teams tackling different
focus areas
• What is it?
– Top-down, comprehensive, collaborative, multidisciplinary, iterative, and
concurrent technical processes
• When is it used in the overall systems engineering process?
– Concept Studies / Concept & Technology Development (Pre-Phase A / Phase A) –
Develop CONOPS and identify key relationships, capabilities, and needs for
acquisition and development; establish baseline for cooperation
– Preliminary Design & Technology Completion through System Assembly (Phase B
through Phase D) – Maintain common baseline for interoperability and provide
common concepts across individual system projects
– Operations & Sustainment (Phase E) – Determine state of SoS and evaluate
acquisition plans, capability gaps, etc.; serve as baseline for building future
architectures
19
20. Systems of Systems Engineering Framework
For Each Increment
Demonstrate
Assess Capabilities
Capabilities in
and Requirements
Operation
Define Architectures With Validate
Needed Capabilities Capabilities
Identify Trade Studies
Integrate SoS
and Alternatives
Determine System
Systems of Assess System
Performance Parameters
Performance
Systems and Verification Plans
Engineering
Identify Important System Integrate and
Specifications Verify Systems
Coordinate development, production, and testing
Services / Project
Systems
Engineering
SYSTEM 1
(Requiring SYSTEM 2
V diagrams
Modification) (New or Early in SYSTEM 3
20
Development) (In Production)
21. Systems Architecture Approach
Architecture Development Process
Architecture Framework
Architecture Development Methods
21
22. Six-Step Static Architecture Development Process
(DoDAF 1.5)
1
Determine
Intended
Use of the
Architecture
2 3 4 5 6
Determine Collect, organize, Conduct Document
Determine data analysis in
scope of correlate, Results IAW
required to and store support of Architecture
Architecture support Architecture
Architecture data Framework
Architecture objectives
22
23. Dynamic Architecture Process
Used By the NASA Architecture Team
Infrastructure Drivers (New Capabilities) and Mission Customers
Subject Matter Experts
Subject Matter Experts
Concepts of
Concepts of
Operations Generate and Integrate
Generate and Integrate
Operations
Architecture Products
Architecture Products Architecture
Initialize Architecture
Initialize Architecture Description
Development Task,
Development Task, Document
Define Objectives,
Define Objectives,
Continuous Re-evaluation
Continuous Re-evaluation
Requirements
Requirements Issues and
Gaps
Assumptions
Assumptions
Trade Data
Data Communications
Communications Navigation
Navigation Network
Network
Trade Architecture
Architecture Architecture
Architecture Architecture
Architecture
Studies
Studies
23
24. SCaN System Architecture Engineering
SCaN Program System/Operation
Services Architecture
Levels Architecture
Level 1: “Should-Be” Architectures Service Oriented
SCaN Office Architecture
Transition Process
(SOA)
Models,
“To Be” Architectures
• Network Integration
Simulation, &
Level 2: • Orion • Lunar Emulation
• More (?)
SCaN
Program NoN and SoS
Capabilities
“As-Is” Architectures
Level 3: Testbeds including:
SCaN • Real Systems
• Modules Service Catalog
Networks • Components
Network System • Services
Architectures • Simulations
(SN,DSN,GN)
24
25. Architecture Roadmapping for the
Transition Process
• Process
– Collects strategic levels of information; examples include Program’s
Customer Drivers and Plans
– Concern with longer timeframes than short-term project plans
– Divide up the timeframe into segments based on budgetary and
visionary goals
– Develop multi-layered approach which shows the inter-dependencies
among Drivers, Program/Project Milestones, Operational and
Development Capability Plans, and Enablers
– Clearly show the “Pull” of the program goals and customer
requirements to technology developers
– Clearly show the “Push” of the emerging and relevant technology
capabilities
25
26. Architecture Frameworks
A Systems Architecture Framework specifies how to organize
and present the fundamental organization of a system.
– By analogy, a Framework is the drawings or blueprints you
would have to produce for a building.
Some Examples:
The Department of Defense Architecture
Framework (DoDAF) Ver 1.5.
The Zachman Framework.
Reference Architecture for Space Data
Systems (RASDS) from CCSDS.
26
27. Architecture Views/Viewpoints: Definition
• Architecture Views
– A view is a representation of a whole system from the perspective
of a related set of concerns
– [alternate definition… Representations of the overall architecture
that are meaningful to one or more stakeholders in the system]
– Each view corresponds to exactly one viewpoint
• Architecture Viewpoints
– A viewpoint defines the perspective from which a view is taken
• A view is what you see. A viewpoint is the vantage point or perspective
that determines what you see
– A viewpoint provides a framework or pattern for constructing views
– Each viewpoint is specified by:
• Viewpoint name
• The stakeholders addressed by the viewpoint
• The stakeholder concerns to be addressed by the viewpoint
• The viewpoint language, modeling techniques, or analytical methods
used
• The source, if any, of the viewpoint (e.g., author, literature citation)
27
29. Reference Architecture for Space Data Systems*
• RASDS (Reference Architecture for Space Data Systems)
is described by the CCSDS Systems Architecture Working
Group specifically for space systems.
Viewpoints
Business Concerns
Enterprise Organizational perspective
Computational Concerns
Functional Functional composition
Data Concerns
Information Relationships and
transformations
Physical Concerns
Connectivity Node & Link perspective
Protocol Concerns
Communications Communications stack
perspective
*Peter Shames, Jet Propulsion Laboratory 29
31. Architecture Frameworks Used by
NASA Architecture Teams
Frameworks Views Systems
—
Department Operational
of Defense —
Architecture Technical
—
Framework All View
Reference Communications
—
Architecture Enterprise
for Space Data —
Systems Service
Zachman Business
Framework
NASA Network and
Architecture Navigation
Teams
Combined View/Viewpoints Used 31
33. Systems Architecture Engineering Components*
Architecture Work perform Architecture Workers
Units
Architecture Architecture
Teams
Architecture Work Products
Engineering membership
Tasks Architecture
create Representations Architecture
and produce Engineers
update Diagrams, ADDs,
Models Communications,
use
Networking, SCaN
describe Network SMEs
use
Architecture Architectures
Engineering
Techniques As-Is, To-Be, Tools
Should-Be
Architecture CORE, Cradle, etc.
Frameworks
*adapted from: Donald Firesmith (CMU Software Engineering Institute) Method Framework for
Engineering System Architectures (MFESA)
34. Relationships Among Perspectives With the
Model Architecture *
Enterprise Schedule ConOps
View Capability
View View
Roadmaps
& Gaps
Architecture Model
Operational System Technical
All Views
Views Views Views
Business
View Navigation
Views
Networking
Mission Plans Views
Service Communication
Views Views
* Varies from program to program
34