1 / 59

GSAW 2007 Break-Out Session 4D:

Dr. Craig A. Lee, Senior Scientist Computer Systems Research Department. GSAW 2007 Break-Out Session 4D:. A Notional, Network-Centric Ground System and Emerging Standards. Goal: A Notional Architecture of Netcentric Ground Systems Review existing work for candidate architectures

jennis
Download Presentation

GSAW 2007 Break-Out Session 4D:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dr. Craig A. Lee, Senior Scientist Computer Systems Research Department GSAW 2007 Break-Out Session 4D: A Notional, Network-Centric Ground System and Emerging Standards

  2. Goal: A Notional Architecture of Netcentric Ground Systems Review existing work for candidate architectures Identify fundamental functional areas/capabilities Describe overall service categories Describe specific services and data models within those categories Drill down in each Identify technologies that can instantiate all of the above Existing and Emerging Best Practices and Standards Drill down in each Example of How All This Might Work Earth Observation Metadata Model, Catalogue and Ordering Services from the ESA Heterogeneous Mission Accessibility project In Summary Tactical (Programmatic) Issues Strategic (Organizational) Issues Goal & Approach

  3. This GSAW effort is not intended to change or redirect any current programs The goal of this GSAW effort is to identify specific, yet generic, services and service classes that could be applied across future programs to facilitate the development of netcentric ground systems The results of this work will be disseminated through the NCOIC Ground Systems Working Group to have the widest possible impact in the NCO community Net-Centric Operations Industry Consortium www.ncoic.org Ground Rules

  4. Netcentric systems will be service-oriented architectures Or simply service architectures Service architectures will be built on the basic web services stack XML, HTTP, SOAP, WSDL, UDDI (maybe) Widespread adoption of at least these standards in marketplace Capabilities beyond this are still open Service architectures must be vendor-neutral and based on open standards Anything else will result in closed, proprietary (stovepiped!) systems Givens

  5. All data, machines, system functions (both new and legacy) are considered to be resources All resources are exposed as services in a common, well-defined architecture All services have a common “look and feel” for how they interact Loosely coupled services through standard interfaces and open standards Benefits: A service is not necessarily “hard-wired” to a particular machine Separates definition from implementation (object orientation) Combines services from existing systems into composite applications Promotes reuse, rapid integration, and interoperability SOA can be deployed incrementally Language-, platform-, and object model-neutral Challenges: The Information Architecture for all data and services must be well-defined, i.e., metadata schemas Open standards must be observed to prevent vendor-dependence Service-Oriented Architectures

  6. 2. Request 5. Results 1. Register (Publish) 4. Invoke 3. Discover The Basic Service Architecture Concept Messaging Framework Challenge: How to apply this approach to a large-scale, distributed ground system with many services and users?

  7. February 2003, DoD Chief Information Officer directed the development of the Net-Centric Operations and Warfare Reference Model (NCOW RM) Provide a model to guide development of net-centric architectures throughout DoD Support identification of required IT capabilities Provide a means to comply with the NCOW RM Support the transformation of DoD to a net-centric organization November 2004, Version 1.1 (Draft) is available The Starting Point:The NCOW Reference Model

  8. The GIG Enterprise Information Environment COI = Community Of Interest NCOW Ref. Model, Sec. 4.1

  9. The Nine Core Enterprise Service Areas

  10. Messaging Discovery Mediation Collaboration Storage Info. Assurance Application User Assistance Enterprise Svc Mgmt NCOW Reference Model, v1.1, Appendix D Target Technical View, Sec. 2.2.4 Net-Centric Enterprise Services Key Issue Key Issue: Mapping Core Enterprise Services to Target Technologies for NSS

  11. Goddard Mission Services Evolution Center (GMSEC) CCSDS Mission Operations Concept GMES and Heterogeneous Mission Accessibility DISA Net-Centric Enterprise Services Overview of Four Relevant Projects

  12. A Software Message Bus framework to connect GSFC mission services Integrates ~30 COTS/GOTS products Increase reuse -- Reduce cost and risk http://gmsec.gsfc.nasa.gov GMSEC

  13. GMSEC “Reference Architecture”

  14. GMSEC Extended to S/C Bus--Onboard Integrated Message Bus Demonstration (December 2005) Dan Mandl @ OGF-18 Ground System Testbed Core Flight Executive (cFE) on CHIPS DC ASIST Primary Command Ingest Telemetry Output UDP cFE Bus GMSEC Bus model Livingstone Adaptor ASIST Secondary script result DC – Data Center ASIST – Advanced Spacecraft Integration and System Test

  15. Plug-and-Play Components Telemetry & Command Assessment & Archive Planning & Scheduling Guidance Navigation & Control Simulation & Modeling New stand-alone functions Standard Messages & Software Information Bus Components publish/subscribe to Standard Messages with defined contents Standard Messages are used as to request a service, to share data, or to provide status GMSEC Applications Programming Interface (API) Shields components from dependencies on communication protocols, operating systems, and hardware platforms Interfaces with the middleware to route the messages over the Software Information Bus and also to pack/unpack the message contents. GMSEC Features

  16. GMSEC Component Catalog (2005) Choices are available for many subsystems. The TRMM mission selected catalog components to best meet their reengineering needs.

  17. Consultative Committee on Space Data Systems CCSDS 520.0-G-2, Green Book, Aug 06, defines: Classes of Services Service Layers Information Model for Service Objects Incremental Standardization Approach Priority is given to services that are currently exposed at interoperability boundaries. Services exposed at key internal interfaces within the infrastructure of multiple agencies will be standardized to encourage the development of re-usable infrastructure components. Finally, services are identified to allow future evolution of interoperable interfaces with increased complexity of missions and on-board autonomy. CCSDS Mission Operations Services Concept

  18. Automation Service Facilitates the automation of ground equipment command, control and statusing Scheduling Service Facilitates the scheduling of ground and satellite resources as well as schedule execution Planning Service Facilitates the planning of mission operations as well as “housekeeping” functions Location Service Facilitates ephemeris generation/tracking functions Flight Dynamics Service Facilitates orbit and attitude determination as well as maneuvering Potential List of Services* * As defined in the Mission Operations Services Concept, Informational Report, CCSDS, Aug 2006

  19. Time Service Facilitates coordination and synchronization of spacecraft and ground time Data Product Management Service Facilitates control, management and transfer of satellite data to analyst systems Core Monitoring & Control Service Facilitates control of core functions including commanding, status monitoring, and alarm notification Operator Interaction Service Facilitates the generation and handling of alarms, messages and operator queries Software Management Service Facilitates the management of spacecraft or remote software Potential List of Services (Cont.)* * As defined in the Mission Operations Services Concept, Informational Report, CCSDS, Aug 2006

  20. CCSDS Mission Operations Services Key to cost savings and interoperability is to adopt high pay-off, reusable services *Taken from Mission Operations Services Concept, Informational Report, CCSDS, Aug 2006

  21. CCSDS Spacecraft Monitoring & Control Framework (TT&C) Area For Development *Taken from Mission Operations (MO) Services Concept, Informational Report, CCSDS, Aug 2006

  22. Global Monitoring for Environment and Security (GMES) Large European Space Agency (ESA) program Heterogeneous Mission Accessibility (HMA) Project started in 2005 and is now being executed within the ESA GMES Programme Phase-1, Segment-1 The GMES ground segment provides the necessary interfaces for requesting and accessing data from national and Eumetsat missions forming part of GMES The component publishing these interfaces is named Data Access Integration Layer – DAIL HMA permits integration of EO products and space data of all kinds with other data and information ESA GMES and HMA Courtesy P. G. Marchetti, HMA Project Manager

  23. GMES HMA Architecture –Enterprise View - Context Courtesy P. G. Marchetti, HMA Project Manager

  24. GMES HMA Architecture –Engineering View Courtesy P. G. Marchetti, HMA Project Manager

  25. GMES HMA Architecture – Service View Courtesy P. G. Marchetti, HMA Project Manager

  26. Selected technologies & protocols: Service Oriented Architecture (SOA) XML Schema Message-based SOAP (Simple Object Access Protocol) over HTTP or HTTPS for secure communication WSDL (Web Services Description Language) Business Process Execution Language (BPEL) UDDI service registry Ws-addressing Security/Identity management Security Assertion Markup Language (SAML) Lightweight Directory Access Protocol (LDAP) WS-Security WS-Policy Inspire Open Geospatial Consortium GML,WMS, WFS,WCS OGC CSW2.0 Application Profile ISO19115/19119 GMES HMA Architecture –Technology view Courtesy P. G. Marchetti, HMA Project Manager

  27. HMA prototype Based on ESA Service Support Environment infrastructure: Courtesy P. G. Marchetti, HMA Project Manager

  28. Future Combat Systems (Army) Enterprise Resource Planning (Navy) Multi-mission Maritime Aircraft (Navy) Net-Centric Enterprise Solutions for Interoperability (NESI) (joint Navy/Air Force) Business Mgmt Modernization Prgm (DoD) Business Enterprise Architecture GIG-BE (Bandwidth Expansion, DISA) GIG-EF (End-to-End Evaluation Facilities, NRL) GIG-IA (Information Assurance, NSA) Network-Centric Enterprise Services (NCES) (DISA) DOD Enterprise Collaboration GIG-ES Enterprise Developer's Network Content Discovery and Delivery DOD’s Service-Oriented Architecture Foundation Netcentric Government Programs

  29. NCES Program Capabilities Core EnterpriseServices Major Capabilities Needed by NCES Increment I Four Product Lines • Enterprise Collaboration: • Web Conferencing • Instant Messaging • Enterprise Portal: • - Single Sign-On • Content Discovery & Delivery: • Federated Search Service • Enterprise Catalog Service • Data Source Integration • Content Delivery • SOA Foundation: • DoD Web Services Profile • Web Service Profile Update • Service Discovery • Service & Metadata Registry Integration • Service Security • Attribute-based access control • Service Management • Alerts • Automated Failover & Recovery • Identity Management • Metadata Services • Service Mediation • Machine-to-Machine • Messaging Collaboration Mediation Enterprise Collaboration IA / Security Discovery Enterprise Portal Service Management Content Discovery & Delivery Storage Application SOA Foundation Messaging User Assistant Source: Edward M. Siomacco, Deputy PEO GIG Enterprise Services

  30. Pilot Environment – To Get Involved • DoD community can get involved with the NCES program through multiple channels: • Become a Pilot Participant – • By being a Service Provider • By being a Service Consumer • By being a Data Provider • By being an End User • Being designated as an Early Adopter • Attending WIPT / Working Group meetings • Details are in NCES Pilot Participants Guide This and next three slides from

  31. C2 SSA COI Pilot GPS ThreadProvide Navigational Accuracy Prediction Alert Service NCES Pilot Environment ServiceDiscoveryService ContentDiscoveryService Messaging Services Shows service execution; not discovery SecurityService GPS Status Service DSCS Portlet SISP 0.1 NavAcc Prediction Web Service GPS Status Website (NANU) NavAcc Prediction Alert Service NavAcc Portlet SBMCS-NANU Interface GPS Mission Control Station Pilot UDOP NavAcc Data GPS-SBMCS Interface PredictionRepository AlertProfiles 2 SOPS Space C2 Pilot Server • GPS Thread Advantages • Strong user advocacy for capability (14th AF) • Provides risk reduction on use of NCES Core Enterprise Services • Demonstrates value of leveraging existing services to create needed mission capability • Risk reduction for Program of Record as a Service Provider NCES Service COI COI Service

  32. Gateway Server C2 SSA COI Pilot DSCS ThreadProvide Machine-to-machine exchange of DSCS link status data SISP 1.0 PAFB Bldg 1470 GSSC PAFB Bldg 1471 DSCS Link StatusWeb Service Closed Network (ODOCS) Pilot UDOP NavAcc Portlet Publish DSCS Link Status SATCOM Server DSCS Portlet Shows service execution; not discovery NCES Pilot Environment ContentDiscoveryService ServiceDiscoveryService Messaging Services SecurityService NCES Service • DSCS Thread Advantages • Exposes DSCS link status from authoritative source in accordance with DoD Data Strategy • Provides risk reduction on use of NCES Core Enterprise Services • Cross-service initiative Army COI COI Service USSTRATCOM

  33. Navy Afloat Volpe FS FS FS FS FS FS FS FS MDA DS COI High-Level Pilot Architecture -- Discovery NAIS Aggregation Navy Organic AIS Aggregation Infrastructure: COI MDA DS CoI – Data Producers ONI - AMRS Aggregation NCES SOA Foundation Content Discovery NAIS VOLPE Aggregation DHS Consumers AMRS 4 Federated Search Requests DOD Consumers Interfaces: 3 NCES SS authenticates HSIN portal & authorizes DHS user Federated Search Web Service FS Federated Search Aggregator 2 5 User initiates Fed Search query Aggregated Search Results Returned in DDMS format NCES Security Service DOD DHS 1 DHS user logs into HSIN portal Fed Search WebPart Fed Search WebPart Defense Online Portal HSIN Portal HSIN Identity Store (Portal Authentication) NCES Service Discovery Data Sharing SOA Foundation Pilot – Notional Use Case # 1: Discovery Metadata Discovery - Federated Search (FS)

  34. Side-by-Side Comparison of Service Categories

  35. Domain Service Categories Mission Planning Scheduling Catalogue Telemetry & Commanding Monitor & Control Flight Dynamics Location Time Front-end Processing Automation/Scripting Control Data Product Request/Ordering Archiving Assessment Mediation Collaboration User Assistance/Operation Interaction Coalescing Service Categories • Infrastructure Service Categories • Catalogues & Registries • Discovery • Applications • Job Submission/Execution Svcs • Workflow Management • Data Product Management • Storage & Archiving • Messaging • Event Notification • User Management • Information Assurance/Security • Monitor & Control • Enterprise Svc Mgmt/Software Mgmt • APIs/Ops Systems • Financial Accounting

  36. A Proposed Netcentric Ground System Reference Architecture Domain Services Asset Data Processing Command & Control Flight Dynamics Time & Location Asset Plan. & Sched. Telemetry & Monitor. Ordering Services User Env. & Portals Policies Framework Services Catalogues Storage & Archives User & VO Mgmt Exec. Scvs Workflow Event Notification Enterprise Mgmt Metadata Schemas & Ontologies Security, Reliable Messaging, Monitoring, and Accounting Services Low-level Infrastructure: Operating Systems/Machines/Storage/Networks

  37. Key distributed system requirements called out Policy management, system management, open messaging Explicitly considers satellite ground systems Considers the spectrum of capabilities required for satellite ground systems Makes a clear distinction, yet firm connection, between domain and infrastructure services What Is Needed Now: Map this abstract reference architecture to concrete specs/tools/systems that can be used to implement/deploy netcentric ground systems Comments

  38. Infrastructure Service Categories Catalogues & Registries Discovery Applications Job Submission/Execution Svcs Workflow Management Data Product Management Storage & Archiving Messaging Event Notification User Management Information Assurance/Security Monitor & Control Enterprise Svc Mgmt/Software Mgmt APIs/Ops Systems Financial Accounting Coalescing Service Categories to Specification Areas • Specification Areas • Catalogues & Registries • Discovery • Applications • Execution Services • Workflow/Transactions • Data Management • State Management • Messaging, Routing, Addressing • Event Notification • Metadata Schemas & Ontologies • Portals and User Interfaces • Security • Policy & Agreement • System Management

  39. Populating the Specification Areas Derived from Fox, Ho, Pierce – U. Indiana Green: On DISR Baseline 07-1.0

  40. By Comparison:OGC Services Interoperability Stack

  41. Some standards are a moving target IBM, MS, HP, Intel intend to merge standards they were backing WSDM & WS-Management, WS-Notification & WS-Eventing, WS-ReliableMessaging & WS-Reliability Execution services does not explicitly address HPC High-Performance Computing (Clusters & other parallel machines) Could be built on top of it State management not explicitly addressed Standards appearing on the DISR Baseline imply state management by non-state-management (see following slide) Oddly IETF RFC 2965, HTTP State Management, appears but this is doing state mgmt at the transport layer, not the service layer Gaps: (Issues not addressed, probably reflecting general maturity) Workflow – Virtual Organization Mgmt Delegation of Trust – Co-Scheduling Policy Mgmt & Enforcement – Advanced Reservations Service Level Agreements Issues & Gaps

  42. Many applications require services to maintain client information across multiple invocations Issue: How to manage this state over multiple invocations? There are (at least) four approaches to specifying state OGSI use factories to generate separate services for each session in standard distributed object fashion (obsoleted by WSRF) Globus GT-4 and WSRF use metadata of a resource to identify state associated with particular session WS-GAF uses WS-Context to provide abstract context defining state. Has strength and weakness that reveals less about nature of session WS-I+ “Pure Web Service” leaves state specification to the application – e.g. put a context in the SOAP body Managing Stateful Web Service Interactions Derived from Fox, Ho, Pierce – U. Indiana

  43. Open Geospatial Consortium (OGC), in conjunction with the ESA Heterogeneous Mission Accessibility (HMA) project, have produced metadata extensions and ordering services for Earth Observation data products OGC 05-057r4, Best Practices for Earth Observation Products OGC 06-141, Ordering Services for EO products OGC 06-080, GML 3.2.1 App schema for EO products OGC 06-131, EO Products Extension Package for ebRIM (ISO/TS 15000-3) Profile of CSW 2.0 Metadata Type Model Registry Extensions Ordering Services An Example of What This Would Look Like

  44. The Metadata Type Model (1/5) G R A P H I C E Y E C H A R T V E R S I O N

  45. The Metadata Type Model (2/5)

  46. The Metadata Type Model (3/5)

  47. The Metadata Type Model (4/5)

  48. The Metadata Type Model (5/5)

  49. Registry Extensions:EO Product Instances

  50. Registry Extensions:EO Product Types Taxonomy

More Related