SEARCH · Engineering Papers
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
The purpose of this slide presentation is to show how a message bus architecture facilitates growth and change, and enables opportunities for rapid application development and to show tools developed at NASA Goddard Space Flight Center for the Goddard Mission Services Evolution Center (GMSEC) architecture.
This viewgraph presentation reviews the role of Goddard Mission Services Evolution Center (GMSEC) in reducing development and operation costs in handling the massive data from NASA missions. The goals of GMSEC systems architecture development are to (1) Simplify integration and development, (2)Facilitate technology infusion over time, (3) Support evolving operational concepts, and (4) All for mix of heritage, COTS and new components. First 3 missions (i.e., Tropical Rainforest Measuring Mission (TRMM), Small Explorer (SMEX) missions - SWAS, TRACE, SAMPEX, and ST5 3-Satellite Constellation System) each selected a different telemetry and command system. These results show that GMSEC's message-bus component-based framework architecture is well proven and provides significant benefits over traditional flight and ground data system designs. The missions benefit through increased set of product options, enhanced automation, lower cost and new mission-enabling operations concept options .
NASA's Goddard Mission Services Evolution Center (GMSEC) ground system architecture has been in development since late 2001, has successfully supported eight orbiting satellites and is being applied to many of NASA's future missions. GMSEC can be considered an event-driven service-oriented architecture built around a publish/subscribe message bus middleware. This paper briefly discusses the GMSEC technical approaches which have led to significant cost savings and risk reduction for NASA missions operated at the Goddard Space Flight Center (GSFC). The paper then focuses on the development and operational impacts of extending the architecture across multiple mission operations facilities.
The Tropical Rainfall Measuring Mission (TRMM) spacecraft was launched in November of 1996 in order to obtain unique three dimensional radar cross sectional observations of cloud structures with particular interest in hurricanes. The TRMM mission life was recently extended with current estimates that operations will continue through the 2012-2013 timeframe. Faced with this extended mission profile, the project has embarked on a technology refresh and re-engineering effort. TRMM has recently implemented a re-engineering effort to expand a middleware based messaging architecture to enable fully redundant lights-out of flight operations activities. The middleware approach is based on the Goddard Mission Services Evolution Center (GMSEC) architecture, tools and associated open-source Applications Programming Interface (API). Middleware based messaging systems are useful in spacecraft operations and automation systems because private node based knowledge (such as that within a telemetry and command system) can be broadcast on the middleware messaging bus and hence enable collaborative decisions to be made by multiple subsystems. In this fashion, private data is made public and distributed within the local area network and multiple nodes can remain synchronized with other nodes. This concept is useful in a fully redundant architecture whereby one node is monitoring the processing of the 'prime' node so that in the event of a failure the backup node can assume operations of the prime, without loss of state knowledge. This paper will review and present the experiences, architecture, approach and lessons learned of the TRMM re-engineering effort centered on the GMSEC middleware architecture and tool suite. Relevant information will be presented that relates to the dual redundant parallel nature of the Telemetry and Command (T and C) and Front-End systems and how these systems can interact over a middleware bus to achieve autonomous operations including autonomous commanding to recover missing science data during the same spacecraft contact.
The topics include: 1) Distributed Aerodynamic Sensing and Processing Toolbox; 2) Collaborative Supervised Learning for Sensor Networks; 3) Hazard Detection Software for Lunar Landing; 4) Onboard Nonlinear Engine Sensor and Component Fault Diagnosis and Isolation Scheme; 5) Network-Capable Application Process and Wireless Intelligent Sensors for ISHM; 6) Interface Supports Multiple Broadcast Transceivers for Flight Applications; 7) FPGA Sequencer for Radar Altimeter Applications; 8) Miniature Sapphire Acoustic Resonator - MSAR; 9) Process-Hardened, Multi-Analyte Sensor for Characterizing Rocket Plume Constituents; 10) SAD5 Stereo Correlation Line-Striping in an FPGA; 11) Hybrid Composite Cryogenic Tank Structure; 12) Nanoscale Deformable Optics; 13) Reliability-Based Design Optimization of a Composite Airframe Component; 14) Zinc Oxide Nanowire Interphase for Enhanced Lightweight Polymer Fiber Composites; 15) Plasma Igniter for Reliable Ignition of Combustion in Rocket Engines; 16) Wire Test Grip Fixture; 17) A Sub-Hertz, Low-Frequency Vibration Isolation Platform; 18) Carbon Nanofibers Synthesized on Selective Substrates for Nonvolatile Memory and 3D Electronics; 19) Nanoparticle/Polymer Nanocomposite Bond Coat or Coating; 20) High-Resolution Wind Measurements for Offshore Wind Energy Development; 21) Spring Tire; 22) Marsviewer 2008; 23) Mission Services Evolution Center Message Bus; 24) Major Constituents Analysis for the Vehicle Cabin Atmosphere Monitor; 25) Astronaut Health Participant Summary Application; 26) Adaption of the AMDIS Method to Flight Status on the VCAM Instrument; 27) Natural Language Interface for Safety Certification of Safety-Critical Software; 28) Cryogenic Caging for Science Instrumentation; 29) Wide-Range Neutron Detector for Space Nuclear Applications; 30) In Situ Guided Wave Structural Health Monitoring System; 31) Multiplexed Energy Coupler for Rotating Equipment; 32) Attitude Estimation in Fractionated Spacecraft Cluster Systems; 33) Full Piezoelectric Multilayer-Stacked Hybrid Actuation/Transduction Systems; 34) Active Flow Effectors for Noise and Separation Control; 35) Method and System for Temporal Filtering in Video Compression Systems; 36) Apparatus for Measuring Total Emissivity of Small, Low-Emissivity Samples; 37) Multiple-Zone Diffractive Optic Element for Laser Ranging Applications; 38) Simplified Architecture for Precise Aiming of a Deep-Space Communication Laser Transceiver; 39) Two-Photon-Absorption Scheme for Optical Beam Tracking; 40) High-Sensitivity, Broad-Range Vacuum Gauge Using Nanotubes for Micromachined Cavities; 41) Wide-Field Optic for Autonomous Acquisition of Laser Link; 42) Extracting Zero-Gravity Surface Figure of a Mirror; 43) Modeling Electromagnetic Scattering From Complex Inhomogeneous Objects; 44) Visual Object Recognition and Tracking of Tools; 45) Method for Implementing Optical Phase Adjustment; 46) Visual SLAM Using Variance Grid Maps; 47) Rapid Calculation of Spacecraft Trajectories Using Efficient Taylor Series Integration; 48) Efficient Kriging Algorithms; 49) Predicting Spacecraft Trajectories by the WeavEncke Method; 50) An Augmentation of G-Guidance Algorithms; 51) Comparison of Aircraft Icing Growth Assessment Software; 52) Silicon-Germanium Voltage-Controlled Oscillator at 105 GHz; 53) Estimation of Coriolis Force and Torque Acting on Ares-1; 54) Null Lens Assembly for X-Ray Mirror Segments; and 55) High-Precision Pulse Generator.
Scalable Integrated Multi-Mission Support System (SIMSS) Simulator Release 2.0 software is designed to perform a variety of test activities related to spacecraft simulations and ground segment checks. This innovation uses the existing SIMSS framework, which interfaces with the GMSEC (Goddard Mission Services Evolution Center) Application Programming Interface (API) Version 3.0 message middleware, and allows SIMSS to accept GMSEC standard messages via the GMSEC message bus service. SIMSS is a distributed, component-based, plug-and-play client-server system that is useful for performing real-time monitoring and communications testing. SIMSS runs on one or more workstations, and is designed to be user-configurable, or to use predefined configurations for routine operations. SIMSS consists of more than 100 modules that can be configured to create, receive, process, and/or transmit data. The SIMSS/GMSEC innovation is intended to provide missions with a low-cost solution for implementing their ground systems, as well as to significantly reduce a mission s integration time and risk.
MPISS is an automatic file transfer system that implements a combination of standard and mission-unique transfer protocols required by the Global Precipitation Measurement Mission (GPM) Precipitation Processing System (PPS) to control the flow of data between the MOC and the PPS. The primary features of MPISS are file transfers (both with and without PPS specific protocols), logging of file transfer and system events to local files and a standard messaging bus, short term storage of data files to facilitate retransmissions, and generation of file transfer accounting reports. The system includes a graphical user interface (GUI) to control the system, allow manual operations, and to display events in real time. The PPS specific protocols are an enhanced version of those that were developed for the Tropical Rainfall Measuring Mission (TRMM). All file transfers between the MOC and the PPS use the SSH File Transfer Protocol (SFTP). For reports and data files generated within the MOC, no additional protocols are used when transferring files to the PPS. For observatory data files, an additional handshaking protocol of data notices and data receipts is used. MPISS generates and sends to the PPS data notices containing data start and stop times along with a checksum for the file for each observatory data file transmitted. MPISS retrieves the PPS generated data receipts that indicate the success or failure of the PPS to ingest the data file and/or notice. MPISS retransmits the appropriate files as indicated in the receipt when required. MPISS also automatically retrieves files from the PPS. The unique feature of this software is the use of both standard and PPS specific protocols in parallel. The advantage of this capability is that it supports users that require the PPS protocol as well as those that do not require it. The system is highly configurable to accommodate the needs of future users.
As space mission design trends towards shared, multi-mission platforms and high-performance onboard computing architectures, the number of spacecraft launched into operation is also steadily rising. Through ridesharing, spacecraft miniaturization, and other cost-reduction measures, the barriers to space are lowering, resulting in compounded growth in the amount of flight software being deployed. To meet the needs of both the growing quantity and evolving nature of spacecraft, flight software design must accordingly adapt to support more efficient development, solutions to computational resource-sharing, and software reusability. This paper focuses on a software payload demonstrating several core technologies that improve the state-of-the-art in these identified areas. Launched into low-earth orbit in January 2022, our software payload was conceived, designed, and delivered in a span of merely two months. It was developed on top of the NASA core Flight System (cFS) framework and the Distributed Spacecraft Autonomy (DSA) Comm cFS application, which translates cFS software bus messages across a Data Distribution Service (DDS) network. The flight software, packaged in Linux container images, was deployed as one of 18 flight applications managed through the Unibap SpaceCloud Framework. The applications were run on a Unibap iX5-102 radiation-tolerant payload computer, hosted on the D-Orbit SCV-004 spacecraft as part of an ESA-sponsored in-orbit technology test. Our payload, referred to as the DSA D-Orbit software, demonstrates the reusability of the DSA Comm app in a substantially different context and purpose as its original mission. Comm’s original design goal was to reliably distribute messages between spacecraft swarms of arbitrary size and dynamic network topology. However, we leverage this same functionality to introduce redundancy and opportunistic parallel data processing in the context of a representative onboard image processing workload. This adaptive mission architecture was enabled in part by the SpaceCloud Framework’s use of container virtualization as the payload integration interface. By using a base container image with common high-level language runtimes and libraries, we were able to rapidly design, develop, and validate our image processing application without many of the technological barriers common to flight software development. We present details the goals, approach, results, and lessons learned through this technology demonstration experiment and contextualize those observations against present and future challenges in spacecraft software development.
We describe decentralized reconfigurable implementation of a conference management system based on the low-level Internet Protocol (IP) multicasting protocol. IP multicasting allows low-cost, world-wide, two-way transmission of data between large numbers of conferencing participants through the Multicasting Backbone (MBone). Each conference is structured as a software bus -- a messaging system that provides a run-time interconnection model that acts as a separate agent (i.e., the bus) for routing, queuing, and delivering messages between distributed programs. Unlike the client-server interconnection model, the software bus model provides a level of indirection that enhances the flexibility and reconfigurability of a distributed system. Current software bus implementations like POLYLITH, however, rely on a centralized bus process and point-to-point protocols (i.e., TCP/IP) to route, queue, and deliver messages. We implement a software bus called the MULTIBUS that relies on a separate process only for routing and uses a reliable IP multicasting protocol for delivery of messages. The use of multicasting means that interconnections are independent of IP machine addresses. This approach allows reconfiguration of bus participants during system execution without notifying other participants of new IP addresses. The use of IP multicasting also permits an economy of scale in the number of participants. We describe the MULITIBUS protocol elements and show how our implementation performs better than centralized bus implementations.
The Criteria Action Table (CAT) is an automation tool developed for monitoring real time system messages for specific events and processes in order to take user defined actions based on a set of user-defined rules. CAT was developed by Lockheed Martin Space Operations as a part of a larger NASA effort at the Goddard Space Flight Center (GSFC) to create a component-based, middleware-based, and standard-based general purpose ground system architecture referred as GMSEC - the GSFC Mission Services Evolution Center. CAT has been integrated into the upgraded ground systems for Tropical Rainfall Measuring Mission (TRMM) and Small Explorer (SMEX) satellites and it plays the central role in their automation effort to reduce the cost and increase the reliability for spacecraft operations. The GMSEC architecture provides a standard communication interface and protocol for components to publish/describe messages to an information bus. It also provides a standard message definition so components can send and receive messages to the bus interface rather than each other, thus reducing the component-to-component coupling, interface, protocols, and link (socket) management. With the GMSEC architecture, components can publish standard event messages to the bus for all nominal, significant, and surprising events in regard to satellite, celestial, ground system, or any other activity. In addition to sending standard event messages, each GMSEC compliant component is required to accept and process GMSEC directive request messages.
Explore the source record for details and available documents.
The present invention provides a network device interface and method for digitally connecting a plurality of data channels to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. In one embodiment, the bus controller transmits messages to the network device interface containing a plurality of bits having a value defined by a transition between first and second states in the bits. The network device interface determines timing of the data sequence of the message and uses the determined timing to communicate with the bus controller.
The GMSEC Interface Specification Document contains the standard set of defined messages. Each GMSEC standard message contains a GMSEC Information Bus Header section and a Message Contents section. Each message section identifies required fields, optional fields, data type and recommended use of the fields. Additionally, this document includes the message subjects associated with the standard messages. The system design of the operations center should ensure the components that are selected use both the API and the defined standard messages in order to achieve full interoperability from component to component.
Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The autoNGC flight software is built on the plug-and-play architecture of the core Flight System (cFS) consisting of the standard cFS apps and newly developed autoNGC interface apps and libraries. The various apps cooperate through communication over the message-based software bus. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced to meet the needs of different missions, even after launch. The first flight software release of autoNGC is targeted for Summer 2024 to provide autonomous navigation at the Moon and beyond. It can perform sensor fusion of multiple measurement types including pseudo-range from a Global Navigation Satellite System (GNSS) receiver (including weak signal), 1-way and 2-way range and Doppler from ground stations (i.e., direct to Earth (DTE)), bearing and range from optical camera images, and accelerometer data. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are first extracted from optical images by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app. If the imaged body is far enough away that it appears as a pixel or cluster of pixels, then bearing angles to the body centroid can be provided. If the body is close enough and the shape is known coarsely, then bearing angles and range to the body centroid can be derived from the limb. Bearing angles to individual surface features can also be extracted (i.e., terrain relative navigation (TRN)). Onboard guidance and control capabilities are being developed for a future release to perform autonomous station-keeping and trajectory correction maneuvers in multiple orbital regimes. Capabilities to enable distributed systems missions and constellations, such as crosslink measurements, and onboard time management are being developed as well. The first hardware implementation of autoNGC is a minimal size, weight, and power (SWaP) design allowing for inclusion into CubeSats and SmallSat-size buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z are utilized for low SWaP while maintaining a high level of performance. The current enclosure design is 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. In order to accommodate a wide range of missions, the hardware interfaces are designed for flexibility with a variety of sensor inputs. Through comprehensive testing in the software-in-the-loop, processor-in-the-loop, and hardware-in-the-loop test beds that are concurrently being developed, autoNGC is expected to achieve TRL 6 by late 2024.
Onboard autonomy is a necessity for responsive space operations. Autonomous navigation, guidance, and control (NGC) enables space missions to reduce their dependence on high demand ground assets and costly ground personnel. It also allows for in-situ decision making and higher return on mission data. A flight software and hardware system providing this capability, called “autoNGC,” is currently being developed at NASA Goddard Space Flight Center for infusion into multiple future missions. The first build of autoNGC, providing autonomous navigation for lunar orbiting spacecraft, is targeted for completion by Fall 2024. It provides sensor fusion of multiple measurement types including pseudo-range from a weak signal Global Navigation Satellite Service (GNSS) receiver, 1-way and 2-way direct to Earth (DTE) range and Doppler, bearing and range from optical camera sensed images, and an accelerometer. AutoNGC is also being targeted for future missions that involve small body proximity operations, Sun Earth Libration point orbits, and distributed systems missions (DSMs) including those at outer planets. AutoNGC flight software is being built upon the plug-and-play architecture of the core Flight System (cFS) [Ref. 1]. Figure (Slide 7) shows the message-based software bus layout of various software applications (“apps”) consisting of the standard cFS apps and autoNGC interface apps and libraries. Accurate onboard navigation and timing is obtained through the Goddard Enhanced Onboard Navigation System (GEONS) software library [Ref. 2], which fuses different measurement types through an extended Kalman filter (EKF) framework. Optical measurements that are ingested in GEONS are provided by the cFS Goddard Image Analysis and Navigation Tool (cGIANT) app [Ref. 3]. This app processes optical images to extract the bearing angles of the centroid of the imaged body (near or far), the range to the imaged body, and/or of the features on the surface of a body to perform terrain relative navigation (TRN). Measurement of range to the body’s center of mass can also be derived from the detection of the limb. The first build of autoNGC for a lunar orbiting spacecraft is a minimal size, weight, and power (SWaP) hardware design allowing for inclusion into CubeSats and SmallSat-size class buses. Advancements in miniaturized space processors, such as the SpaceCube 3.0 Mini and the SpaceCube Mini-Z [Ref. 4] are utilized for low SWaP while maintaining a high level of performance. Figure (Slide 11) shows the composition of the first autoNGC build. The current enclosure design has dimensions 12 cm x 17 cm x 13.5 cm. The box mass is expected to be less than 2 kg, and the nominal power is 21 W. The hardware interfaces are designed for flexibility with a variety of sensor inputs. The achievable navigation performance depends on the sensors utilized, including the onboard clock for 1-way pseudo-range measurements. Analysis using a configuration that consists of weak signal GPS, TRN, and 1-way DTE has shown position and velocity accuracies of 10 meters and 2 cm/s (3-σ ) RSS, respectively, with onboard time knowledge estimated to better than 13 ns (3-σ ), for a spacecraft in a representative 12-hour eccentric lunar orbit. Other measurement types such as x-rays from known pulsars (called XNAV) and cross-links can also be processed in GEONS. With the plug-and-play architecture of autoNGC, cFS apps can easily be added and replaced, even after launch. Goddard is actively seeking partners to collaborate in the development of additional capabilities for autoNGC, including industry, academia, and others across the US Government. Plans are being formulated to make the autoNGC software platform available for use by any US government organization to leverage the non-recurring engineering associated with the development of onboard autonomous NGC 3 capabilities. As advancements in space qualified sensors, microprocessors, and algorithms are made, the autoNGC platform provides a ready starting point for inclusion of these technologies.
A communications system and method are provided for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is converted into digital signals and transmitted to the controller. Network device interfaces associated with different data channels can coordinate communications with the other interfaces based on either a transition in a command message sent by the bus controller or a synchronous clock signal.
The present invention provides a network device interface and method for digitally connecting a plurality of data channels, such as sensors, actuators, and subsystems, to a controller using a network bus. The network device interface interprets commands and data received from the controller and polls the data channels in accordance with these commands. Specifically, the network device interface receives digital commands and data from the controller, and based on these commands and data, communicates with the data channels to either retrieve data in the case of a sensor or send data to activate an actuator. Data retrieved from the sensor is converted into digital signals and transmitted to the controller. In some embodiments, network device interfaces associated with different data channels coordinate communications with the other interfaces based on either a transition in a command message sent by the bus controller or a synchronous clock signal.