Future Multi-Mission Satellite Operations Centers Based on an Open System Architecture and Compatible Framework

Transcription

1 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 & Integration The Aerospace Corporation The Aerospace Corporation 2013

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? 2

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 Program 1 Program 2 Group A P3 P4 P5 P6 P7 P8 P9 Group B Group C P10 Mission-Specific Frameworks Common Services Common Tools Standard Communications Infrastructure (Standard C&C Interfaces, Messaging, Data Formats) Enterprise Framework 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. 3

4 Objectives of Compatible Framework Supporting 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! 4

5 Typical Legacy Ground Systems Spacecraft C2 Processing Flight Dynamics Processing Mission Planning & Scheduling Ground Equipment Control Mission Specific Processing Database(s) Application/ Services(s) Ground System Contractor proprietary applications built on COTS SW Development Frameworks Domain Application Contractor Proprietary SW Dev Application(s) Framework COTS SW Dev Framework (.NET, CORBA) Windows LINUX Solaris Animated Chart Serial Data IF cards, FPGA cards in standard servers Front End Processing (FEP) Crypto logic Equipment Wideband Data Distribution & Processing Storage Special Processing Hardware Network Infrastructure (Routers, Switches, Firewalls, etc) Facility Infrastructure (Space, Power, Cooling) COTS Database with local or attached storage Integrated CPU, Storage, RAM, Network Cards, Graphics Ex: HP DL-360; IMB x3550, Dell Poweredge 2950 Circa 1990 s through

6 Transitioning to an Open Architecture Leveraging a Compatible Framework Compatible / GMSEC API (Standard Message Formats) Ground System Loosely coupled application layer communication COTS Middleware Ex: ActiveMQ, IBM MQ Animated Chart Virtual CPU, RAM, Storage Virtual Network Cards Also called Virtual Machines Service(s) Application(s) Middleware Application(s) Application(s) Application(s) Node(s) API API Virtual Virtual Virtual Infrastructure Management Layer Virtual & Storage Infrastructure Storage Virtual Special Processing Hardware Network Infrastructure (Routers, Switches, Firewalls, etc) Facility Infrastructure (Space, Power, Cooling) Blade Systems for s 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 Many Ground Systems are already implementing portions of the Virtual Infrastructure in Major Upgrades 6

7 Scaling to an Enterprise Ground Architecture Animated Chart Ground System Application(s) Application(s) Middleware Application(s) Application(s) Application(s) Node(s) API API Virtual Virtual Virtual Infrastructure Management Layer Virtual Infrastructure Virtual Special Processing Hardware TCP/IP Network Facility Infrastructure (Space, Power, Cooling) Many Ground Systems are already implementing portions of the Virtual Infrastructure in Major Upgrades 7

8 Scaling to an Enterprise Ground Architecture Animated Chart Enterprise Services Enterprise Data Center(s) Enterprise Management Enterprise Middleware Enterprise Network 8

9 An Open System Architecture End State Leveraging a Compatible Framework Animated Chart Open Ground System Architecture Standard Application Communication Interface Mission A Application Specific s Applications Storage Mission Common Mission Z Application Specific Service Specific s s Applications Applications Virtual Infrastructure Management Layer Virtual Processing & Storage Middleware Mission Specific Applications s Infrastructure Special Processing Hardware Network Infrastructure (Routers, Switches, Firewalls, etc) Facility 1 Facility 2 Facility N End State Architecture is Built to Evolve to Support New Missions 9

10 Animated Chart Architecture Evolution Enabled by Compatible Framework 10 OPERATIONAL TRANSFORMATION 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 Today 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 Build Infrastructure (Enable Evolution) Expose Legacy Interfaces In Standard Messages Automate Build Common Services ARCHITECTURE EVOLUTION Improve Situational Awareness Share Data Enhance Ops Concept Consolidate Functions 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

11 System Operational Paradigm Shifts Legacy to Modern Framework Transformation Operations Concepts Personnel Skills Needed to Support 24hr Ops Backup Operations Ground System Situational Awareness 11 Legacy Systems (heritage in 1990 s) Mission Specific Satellite Operations C2 Application Software O&M 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) Duplicate infrastructure, processing hardware and software in a separate location 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 ) Modern Frameworks (e.g. Compatible Framework) Mission Specific Satellite Operations C2 Application Software O&M 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) Separate location with minimal special hardware (e.g. Crypto) Virtual s representing all SOC processing capabilities stored in generic IT infrastructure ready to activate Multiple-levels of situational awareness 1. Physical Infrastructure (i.e. SAN, Blades, Network) 2. Dynamic Virtual Deployment 3. Middleware traffic 4. Software processes and threads\ COTS management systems provide status of each level Other software needed to pull together a complete system view.

12 Transformation in System O&M Characteristics Legacy to Modern Framework Transformation Operations Concepts Ground System Maintenance Ground System Redundancy & Failover CONOPS Scaling for Simultaneous, Multiple Satellite Contacts Legacy Systems (heritage in 1990 s) 1:1 relationship between hardware and SW functions (e.g. LRU) Maintenance of HW & SW tied together A set of physical servers provides redundancy (i.e. spare strings of HW) Failover to physical hardware stings Multiple physical servers forming processing threads Thick Client-server architecture enables sharing of workstations across processing threads. Modern Frameworks (e.g. Compatible Framework) 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) 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) 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 12

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 13

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 14