Architecting Families of Complex Space Systems and Networks
Kul BhasinNASA Glenn Research Center
Phone: 216.433.3676Email: [email protected]
NASA Goddard Space Flight CenterSystems Engineering Seminar
10.07.08
2
Architecture Team LeadKul Bhasin
Network Architecture LeadsAbhijit Biswas DSNJames Bowen DSNWesley Eddy NISNEric Knoblock GNMike Phillips SN
Network Technical Points of ContactC. Chang DSNAngela Culley NISNLarry Kiser SNStephen Levitski GNA. Operchuck NISN
SCaN “As-Is” Architecture Development Team
Network Technical Points of Contact Cont.T. Pham DSNStan Rubin NISNPeter Shames DSNChris Spinolo NISNWallace Tai DSN
DoDAF and RASDS ArchitectureJeffrey GilbertChuck Putt
IT SupportLee A. JacksonSherry L. Peck-BreenNASA Glenn Logistics and TechnicalInformation Division (LTID) Support
3
Team LeadKul Bhasin / Ron Miller
Operational ViewKul BhasinKar-Ming CheungDavid IrimiesTony HackenbergJohn HudiburgDavid LassiterTom SartwellJonathon Gal-EddJeff Hayden
Systems ViewKul BhasinCharles PuttChuck SheeheJoe ConnollyJonathon Gal-EddJeff Hayden
Space SegmentMark Flanegan
Lunar Surface SegmentMike CauleyDoug HoderChuck SheeheAlan DowneyAfroz ZamanKue ChunJoe Warner
Document DevelopmentRuth ScinaPaulette Ziegfeld
SCWAG ParticipantsJim ShierErica Lieb
Lunar Communication and Navigation Systems (LCNS) Development Team
NavigationMike MesarchMike MoreauBrian KennedyJoe Connolly
Networking ViewsLoren ClareRich SlywczakKul BhasinSteve GneppChuck Putt
Technical ViewLoren ClareSteve Gnepp
Ground SegmentJonathan Gal-EddTom Sartwell
4
SCaN Cx-Orion Architecture Development Team
Architecture Team LeadKul Bhasin
Communications ArchitectureDavid Miller
Network ArchitectureLoren ClareAlan JeffriesEsther JenningsSteve GneppHarry ShawChris SpinoloShirley Tseng
Navigation ArchitectureBrian KennedyMike Maher
Operational ViewsChuck PuttMike PhillipsTom SartwellJeff Hayden
Systems ViewsAbi BiswasJeff Hayden
Technical ViewsDavid Miller
TraceabilityDavid MillerAjithamol Painumkal
Special ContributorsTony HackenbergKaren RichonWilliam Walsh
IT SupportPaulette Ziegfeld, EditorialJeffrey Gilbert, GraphicsJeff Hayden, Graphics
5
Presentation Overview
• Families of Systems and Networks: Evolutions and Trends
• Systems and Networks Architecting
• Systems Architecture Approach
• Systems Architecture Products
6
Families of Systems and Networks: Evolutions and Trends
Evolution of Space Communications Systems
7
• Clear objectives, • Central owner / stakeholder, • Requirements-driven
approach, • Standard system
engineering processes .
• Increase in inter-dependent interfaces; • Increase in number and types of systems, • Protocols, • Software use and operational and
Managerial Independence; • Increase in system and operational
complexity.
• Increased complexity; Unproven technologies,
• High cost of service, • Undefined users and customers; • Inability to integrate multiple
space and ground systems.
8
Space Communications NoN Evolution
Single Links Supplementing
Terrestrial Networks
Multiple Distinct Networks with Manual Management and Little Interoperability Integrated, Interoperable
Networks With Automated Management
LCT 1Habitat
Link from Relay to
Science on Farside
Cx Orion
Pressurized Rover Science
SiteCx Altair
ScienceSite LCT 2
LunarRelay
Satellite
Customers:• Constellation Lunar Surface Systems• Constellation Orion / Altair• Lunar Science Missions
GEO Optical RelayEarth-Based
Ground Station
Pressurized Rover
RoboticRover
RoboticRover
EVA Crew
EVA Crew
LCT 1Habitat
Link from Relay to
Science on Farside
Cx Orion
Pressurized Rover Science
SiteCx Altair
ScienceSite LCT 2
LunarRelay
Satellite
Customers:• Constellation Lunar Surface Systems• Constellation Orion / Altair• Lunar Science Missions
GEO Optical Relay
SCaN µwaveSCaN Optical
Earth-Based Ground Station
Pressurized Rover
RoboticRover
RoboticRover
EVA Crew
EVA Crew
LCT 1Habitat
Link from Relay to
Science on Farside
Cx Orion
Pressurized Rover Science
SiteCx Altair
ScienceSite LCT 2
LunarRelay
Satellite
Customers:• Constellation Lunar Surface Systems• Constellation Orion / Altair• Lunar Science Missions
GEO Optical Relay
SCaN µwaveSCaN Optical
Earth-Based Ground Station
Pressurized Rover
RoboticRover
RoboticRover
EVA Crew
EVA Crew
LCT 1Habitat
Link from Relay to
Science on Farside
Cx Orion
Pressurized Rover Science
SiteCx Altair
ScienceSite LCT 2
LunarRelay
Satellite
Customers:• Constellation Lunar Surface Systems• Constellation Orion / Altair• Lunar Science Missions
GEO Optical Relay
SCaN µwaveSCaN Optical
Earth-Based Ground Station
Pressurized Rover
RoboticRover
RoboticRover
EVA Crew
EVA Crew
SCaN µwaveSCaN Optical
Protocol stacks and common standards enable the network
IPLINKPHY
TRANAPP
IPLINKPHY
TRANAPP
IPLNKPHY
LNKPHY
IPLNKPHY
LNKPHY
IPLNKPHY
LNKPHY
IPLNKPHY
LNKPHY
IPLINKPHY
DTN
IPLINKPHY
CONVCONV
IPLINKPHY
DTN
IPLINKPHY
CONVCONVIP
LINKPHY
DTN
IPLINKPHY
CONVCONV
IPLNKPHY
LNKPHY
IPLINKPHY
DTN
IPLINKPHY
CONVCONV
IPLNKPHY
LNKPHY
IPLNKPHY
CONVDTNAPP
IPLINKPHY
TRANAPP
LNKPHY
DTNAPP
LNKPHY
DTNAPP
Autonomous Earth Observing System of Systems and Network of Networks
14
PLS Routing
Autonomous Space Communications Technology (ASCoT) Architecture
ApplicationData/Query Receive
Reserve Fail/OK
Publish, Subscribe, Reserve
Data/QueryReservation Information Make Reservation
LinkInformation
Reservation Updates
Compute PathPath
Data/Query SendData/Query Receive PLS Send/Receive
Data Link Framing and Coding (CCSDS, HDLC, DVB, ATM)
Physical Layer (Modulated S and Ka-Band)
MAC LayerTCeMA, Tx Power,
Antenna Point/Track, Node Discovery,
Node Direction/Range,Data Synchronization,
Data Multiplexing
Network (IP)
Transport (UDP, TCP)
Link Database
QoS based Reservation Management/Scheduling
Reservation Database
Forwarding Queues
ReceiveBuffers
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.
17
Introduction to Systems and Networks Architecting
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
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
20
SYSTEM 2(New or Early in
Development)
SYSTEM 1(Requiring
Modification) SYSTEM 3(In Production)
Systems of Systems Engineering Framework
Services / Project Systems
Engineering
Systems of Systems
Engineering
For Each Increment
Assess Capabilities and Requirements
Define Architectures With Needed Capabilities
Identify Trade Studies and Alternatives
Determine System Performance Parameters
and Verification Plans
Identify Important System Specifications
Integrate and Verify Systems
Assess System Performance
Integrate SoS
Validate Capabilities
Demonstrate Capabilities in
Operation
Coordinate development, production, and testing
V diagrams
21
Systems Architecture ApproachArchitecture Development Process
Architecture Framework
Architecture Development Methods
22
Determine Intended
Use of the Architecture
1
Determine scope of
Architecture
Determine data
required to support
Architecture
Collect, organize, correlate, and store
Architecture data
Conduct analysis in support of
Architecture objectives
Document Results IAW Architecture Framework
Six-Step Static Architecture Development Process(DoDAF 1.5)
2 3 4 5 6
23
Dynamic Architecture ProcessUsed By the NASA Architecture Team
AssumptionsAssumptions
Trade StudiesTrade
Studies
Generate and Integrate Architecture Products
Generate and Integrate Architecture Products
Communications Architecture
Communications Architecture
Navigation ArchitectureNavigation Architecture
Network Architecture
Network Architecture
Infrastructure Drivers (New Capabilities) and Mission Customers
Architecture Description Document
Issues and Gaps
DataData
Concepts of Operations
Concepts of Operations
RequirementsRequirements
Initialize Architecture Development Task, Define Objectives,
Continuous Re-evaluation
Initialize Architecture Development Task, Define Objectives,
Continuous Re-evaluation
Subject Matter ExpertsSubject Matter Experts
24
SCaN System Architecture Engineering
Level 3: SCaN Networks
Level 2: SCaN Program
Level 1: SCaN Office
“As-Is” Architectures
“Should-Be” Architectures
Network System Architectures(SN,DSN,GN)
Models, Simulation, &
Emulation
Service Catalog
NoN and SoSCapabilities
Service Oriented Architecture
(SOA)
Testbeds including: • Real Systems • Modules • Components • Services • Simulations
SCaN ProgramLevels Services ArchitectureSystem/Operation
Architecture
Tran
sitio
n P
roce
ss
“To Be” Architectures• Network Integration• Orion• More (?)
• Lunar
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
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.
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)
28
DoDAF 1.5 Overview – Views
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.
Enterprise Business ConcernsOrganizational perspective
Connectivity Physical ConcernsNode & Link perspective
Functional Computational ConcernsFunctional composition
InformationData ConcernsRelationships and transformations
CommunicationsProtocol ConcernsCommunications stack perspective
*Peter Shames, Jet Propulsion Laboratory
Viewpoints
30
Zachman Framework Views and Viewpoints
31
Architecture Frameworks Used byNASA Architecture Teams
Department of Defense
Architecture Framework
Reference Architecture
for Space Data Systems
ZachmanFramework
NASA Architecture
Teams
Business
Frameworks Views
Combined View/Viewpoints Used
Network and Navigation
Communications—
Enterprise—
Service
Systems—
Operational —
Technical—
All View
32
Architecture Development Method
Architecture Work Products
produce
Architecture Work Units
Architecture Workers
createand
update
perform
Architectures
As-Is, To-Be, Should-Be
Architecture Representations
Diagrams, ADDs, Models
describe
Architecture Teams
membership
Architecture Engineers
Communications, Networking, SCaN
Network SMEs
Architecture Engineering
Tasks
Architecture Engineering Techniques
Architecture Frameworks
use
Tools
CORE, Cradle, etc.
use
Systems Architecture Engineering Components*
*adapted from: Donald Firesmith (CMU Software Engineering Institute) Method Framework for Engineering System Architectures (MFESA)
34
Enterprise View Capability
Roadmaps & Gaps
All Views Operational Views
System Views
* Varies from program to program
ScheduleView
ConOpsView
BusinessView
Mission Plans Service Views
CommunicationViews
NetworkingViews
NavigationViews
TechnicalViews
Relationships Among Perspectives With the Model Architecture *
Architecture Model
35
View Diagram Representation
SCaN Architecture Representation Method
