© The Aerospace Corporation 2013
Future Multi-Mission Satellite Operations Centers Based on an Open System Architecture and Compatible Framework
GSAW 2014
Thomas J. Sullivan, Aerospace Ground Systems Lab
Rico Espindola, MMSOC Flight Operations & IntegrationThe Aerospace Corporation
2
DoD Open Systems Architecture
DoD Open Systems Architecture, Contract Guidebook for Program Managers. May 2013
“Background: An open architecture is defined as a technical architecture that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure. The key enabler for open architecture is the adoption of an open business model which requires doing business in a transparent way that leverages the collaborative innovation of numerous participants across the enterprise permitting shared risk, maximized asset reuse and reduced total ownership costs. The combination of open architecture and an open business model permits the acquisition of Open Systems Architectures that yield modular, interoperable systems allowing components to be added, modified, replaced, removed and/or supported by different vendors throughout the life cycle in order to drive opportunities for enhanced competition and innovation.”
Achievement of open architecture principles requires an affirmative answer to a fundamental question:Can one or more qualified third parties add, modify, replace, remove, or provide support for a component of a system, based on open standards and published interfaces for the component of the system?
3
What is Framework?
“Framework: An implementation of the foundation portion of the overall system architecture. It is a structured set of software components and standards, and possibly hardware, upon which to build additional functionality.”
- NASA
The term “Compatible Framework” was coined to combine the NASA GMSEC framework foundations with the information assurance features added by the DOD used in conjunction with
mature virtual processing infrastructures that are the foundation of Cloud Computing “Infrastructure as a Service” (ISP) concepts used in modern data centers.
Standard Communications Infrastructure(Standard C&C Interfaces, Messaging, Data Formats)
Program 1 Program 2
Group A Group B
Common Services Common Tools
Group C
P3 P4 P5 P6 P7 P8 P9
P10
EnterpriseFramework
Mission-Specific Frameworks
4
Objectives of Compatible FrameworkSupporting creation of Open Architectures
• A framework for integration of legacy and future ground systems that if properly implemented could:– Integrate existing stovepipes into a cohesive enterprise– Make available satellite data from various disparate legacy sources to
authorized users– Be the foundation for creating an “open system” that future sensors and
systems can build upon or into– Easily provide enterprise situational awareness– Easily integrate existing sensors and systems with little to no
modification of the original system– Create architectures/systems that protect against cyber attacks– Enable the development of common tools and services that can be
shared across the enterprise
Enabling evolution from proprietary stove pipes is a key goal of the compatible framework approach!
5
Ground System
Facility Infrastructure (Space, Power, Cooling)
Server
OS
Database(s)
Typical Legacy Ground Systems
Circa 1990’s through 2010+
Server
Network Infrastructure (Routers, Switches, Firewalls, etc)
Server
OS OS
Application/ Services(s) Application(s)
Special Processing Hardware
• Integrated CPU, Storage, RAM, Network Cards, Graphics• Ex: HP DL-360; IMB x3550,
Dell Poweredge 2950
• Windows • LINUX• Solaris
• Spacecraft C2 Processing• Flight Dynamics Processing• Mission Planning & Scheduling• Ground Equipment Control• Mission Specific Processing
• Serial Data IF cards, FPGA cards in standard servers• Front End Processing (FEP)• Crypto logic Equipment• Wideband Data Distribution & Processing
COTS SW Dev Framework (.NET, CORBA)
Contractor Proprietary SW Dev Framework
Domain Application
Contractor proprietary applications built on COTS SW Development Frameworks
Storage
COTS Database with local or attached storage
Animated Chart
6
Ground System
Facility Infrastructure (Space, Power, Cooling)
Network Infrastructure (Routers, Switches, Firewalls, etc)
Server
OS
Application(s)
OSVirtual Server
Leveraging a Compatible FrameworkTransitioning to an Open Architecture
Many Ground Systems are already implementing portions of the Virtual Server Infrastructure in Major Upgrades
Server Server
OS OS
Application(s) Application(s)
Special Processing Hardware
OSVirtual Server
OSVirtual Server
MiddlewareNode(s)
API
Application(s)
API
Service(s)
• Virtual CPU, RAM, Storage• Virtual Network Cards• Also called “Virtual Machines”
Compatible / GMSEC API(Standard Message Formats)
• COTS Middleware• Ex: ActiveMQ, IBM MQ
StorageVirtual Server & Storage Infrastructure
Virtual Infrastructure Management Layer
• Blade Systems for Servers• Consolidated Storage Systems replace server hard drives and dedicated storage• Ex: HP Blade System; DELL Poweredge, IBM BladeCenter; SAN
• Virtual/Cloud Management Software• Blade/SAN Management Software• Ex: VMWare Vcenter, vCloud, HP Insight Control
Animated Chart
Loosely coupled application layer communication
7
Ground System
Server
OS
Application(s)
OSVirtual Server
Server
TCP/IP Network
Server
OS OS
Application(s) Application(s)
Special Processing Hardware
Virtual Server Infrastructure
Virtual Infrastructure Management Layer
OSVirtual Server
OSVirtual Server
MiddlewareNode(s)
API
Application(s)
API
Application(s)
Scaling to an Enterprise Ground Architecture
Many Ground Systems are already implementing portions of the Virtual Server Infrastructure in Major Upgrades
Animated Chart
Facility Infrastructure (Space, Power, Cooling)
8
Scaling to an Enterprise Ground Architecture
Enterprise Middleware
Enterprise Services
Enterprise Management
Enterprise Data Center(s)
Enterprise Network
Animated Chart
9
Open Ground System Architecture
Facility 1
Network Infrastructure (Routers, Switches, Firewalls, etc)
Server
Mission Specific
Applications
Leveraging a Compatible FrameworkAn Open System Architecture End State
End State Architecture is Built to Evolve to Support New Missions
Special Processing Hardware
Storage Virtual Processing & Storage
Virtual Infrastructure Management Layer
Facility 2 Facility N
Mission Specific
Applications
Mission A Application
Servers
Mission Specific
Applications
Mission Specific
Applications
Common ServiceServers
Mission Specific
Applications
Mission Specific
Applications
MiddlewareInfrastructure
Servers
Mission Specific
Applications
Mission Specific
Applications
Mission ZApplication
Servers
Standard Application Communication Interface
Animated Chart
10
Architecture Evolution Enabled by Compatible Framework
Today
Build Infrastructure(Enable Evolution)
Share Data
Build Common Services
Automate
Improve SituationalAwareness
Expose Legacy InterfacesIn Standard Messages
Consolidate Functions
Enhance Ops Concept
OPERATIONA
LTRAN
SFOR
MATION
ARCHITECTUREEVOLUTION
• Assess value of change (cost-benefit and mission end-of-life). • Consider value of enabling new capabilities (e.g. SSA)•Define transition plan • Leverage major upgrades to start migration• Identify recapitalization opportunities to insert change• Adapt organization to open architecture acquisition approach
• Acquire infrastructure independent of legacy system• Select initial data to expose & new services to build• Adapt Legacy Contracts to expose interfaces• Begin transition of organizational processes and structure
• Mature open architecture business processes• Delineate roles of infrastructure provider, integrator, developers. • Merge and/or simplify operations concepts • Acquire/Develop common services and tools•Mission contractors deliver on and to the common infrastructure
Animated Chart
11
System Operational Paradigm Shifts
Operations Concepts Legacy Systems(heritage in 1990’s)
Modern Frameworks(e.g. Compatible Framework)
Personnel Skills Needed to Support 24hr Ops
• Mission Specific Satellite Operations• C2 Application Software O&M• OS System Administration• Special Purpose HW O&M (FEP, Crypto)• Complex Physical Network Equipment Configuration• Commodity Hardware/LRU O&M• Simple Middleware System Administration (based on system design)
• Mission Specific Satellite Operations• C2 Application Software O&M• OS System Administration• Special Purpose HW O&M (FEP, Crypto)• Complex Physical and Virtual Networking Configuration• Commodity Hardware/LRU O&M• Virtual Environment System Administration• Blade Center System Administration• More complex Middleware System Administration (based on enterprise infrastructure design)
Backup Operations•Duplicate infrastructure, processing hardware and software in a separate location
• Separate location with minimal special hardware (e.g. Crypto)
• Virtual Servers representing all SOC processing capabilities stored in generic IT infrastructure ready to activate
Ground System Situational Awareness
• Physical heath & status of HW –based functions provides situational awareness for ground system• Network Management Software provided by ground system developer monitors HW & SW (e.g. Telemetry Processing Server)
• Multiple-levels of situational awareness1. Physical Infrastructure (i.e. SAN,
Blades, Network)2. Dynamic Virtual Deployment3. Middleware traffic4. Software processes and threads\
• COTS management systems provide status of each level
• Other software needed to pull together a complete system view.
Legacy to Modern Framework Transformation
12
Transformation in System O&M Characteristics
Operations Concepts Legacy Systems(heritage in 1990’s)
Modern Frameworks(e.g. Compatible Framework)
Ground System Maintenance
• 1:1 relationship between hardware and SW functions (e.g. LRU)• Maintenance of HW & SW tied together
• Hardware maintenance separate from SW maintenance, except for special processing hardware• Multiple levels of maintenance that are loosely coupled (i.e. Physical, Virtual , Network, Middleware, VMs, SW Applications)
Ground System Redundancy & Failover CONOPS
• A set of physical servers provides redundancy (i.e. spare strings of HW)• Failover to physical hardware stings
• HW redundancy separate from SW redundancy• Spare physical servers and storage provide spare capacity in case of HW failures• RAID redundancy for data storage• Logical redundancy of SW functions provided by virtualization high availability and failover concepts• Application level redundancy for infrastructure software (e.g. middleware)
Scaling for Simultaneous, Multiple Satellite Contacts
• Multiple physical servers forming processing threads• Thick Client-server architecture enables sharing of workstations across processing threads.
• On demand activation of logical servers providing processing threads on the fly• Limited only by SW licensing • Any thin client can access a virtual server from anywhere in network
Legacy to Modern Framework Transformation
13
Governance of Compatible Framework Implementations
• Need for Governance– Reduce individual implementation costs– Maintain openness of framework – Prevent proprietary one-off implementations– Share lessons learned and best practices– Enable the sharing of data between missions (i.e. NSS SATOPS Enterprise)
• Status– SMC Space Development and Test Director (SDTD) is blazing the trail for
DOD application of framework in multi-mission environments– NASA GSFC Funded to Maintain GMSEC Spec & API supporting SMC– Joint SATOPS Compatibility Committee (JSCC) Facilitating Creation of
Governance Documentation & Practices– Individual programs can choose to participate
14
Summary
• A Open Architecture based on a Compatible Framework is a good tool for evolving legacy systems or building new systems– Creates common infrastructures & services, open interfaces– Leverages and sustains legacy investments – Promotes competition and innovation– Enables lifecycle cost savings & creation of new capabilities at lower cost
• This approach is mature and is starting to be leveraged by government organizations:– SMC/SDTD MMSOC (transitioning to Operation in 2014)
• Program offices will need to change system architecting and acquisition approach to take full advantage of this approach– “DOD Open System Architecture Program Managers Guide” gives practical
advice and tools for acquisitions