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 Goddard Mission Services Evolution Center (GMSEC) Message Bus is a robust, lightweight, fault-tolerant middleware implementation that supports all messaging capabilities of the GMSEC API. This architecture is a distributed software system that routes messages based on message subject names and knowledge of the locations in the network of the interested software components.
Adapter allows communications among as many as 30 data processors without central bus controller. Adapter improves reliability of multiprocessor system by eliminating point of failure that causes entire system to fail. Scheme prevents data collisions and eliminates nonessential polling, thereby reducing power consumption.
Space Technology 5 (ST-5) is a three-satellite constellation, technology validation mission under the New Millennium Program at NASA to be launched in March 2006. One of the key technologies to be validated is a lights-out, model-based operations approach to be used for one week to control the ST-5 constellation with no manual intervention. The ground architecture features the GSFC Mission Services Evolution Center (GMSEC) middleware, which allows easy plugging in of software components and a standardized messaging protocol over a software bus. A predictive modeling tool built on MatLab's Simulink software package makes use of the GMSEC standard messaging protocol to interface to the Advanced Mission Planning System (AMPS) Scenario Scheduler which controls all activities, resource allocation and real-time re-profiling of constellation resources when non-nominal events occur. The key features of this system, which we refer to as the ST-5 Simulink system, are as follows: Original daily plan is checked to make sure that predicted resources needed are available by comparing the plan against the model. As the plan is run in real-time, the system re-profiles future activities in real-time if planned activities do not occur in the predicted timeframe or fashion. Alert messages are sent out on the GMSEC bus by the system if future predicted problems are detected. This will allow the Scenario Scheduler to correct the situation before the problem happens. The predictive model is evolved automatically over time via telemetry updates thus reducing the cost of implementing and maintaining the models by an order of magnitude from previous efforts at GSFC such as the model-based system built for MAP in the mid-1990's. This paper will describe the key features, lessons learned and implications for future missions once this system is successfully validated on-orbit in 2006.
This course presents technical and programmatic information on the development of message-based architectures for space mission ground and flight software systems. Message-based architecture approaches provide many significant advantages over the more traditional socket-based one-of-a-kind integrated system development approaches. The course provides an overview of publish/subscribe concepts, the use of common isolation layer API's, approaches to message standardization, and other technical topics. Several examples of currently operational systems are discussed and possible changes to the system discussed and time for questions and answers will be provided.
This course presents technical and programmatic information on the development of message-based architectures for space mission ground and flight software systems. Message-based architecture approaches provide many significant advantages over the more traditional socket-based one-of-a-kind integrated system development approaches. The course provides an overview of publish/subscribe concepts, the use of common isolation layer API's, approaches to message standardization, and other technical topics. Several examples of currently operational systems are discussed and possible changes to the system development process are presented. Benefits and lessons learned will be discussed and time for questions and answers will be provided.
There will always be a new latest and greatest architecture for satellite ground systems. This paper discusses the use of a proven message-oriented middleware (MOM) architecture using publish/subscribe functions and the strengths it brings to these mission critical systems. An even newer approach gaining popularity is Service Oriented Architectures (SOAs). SOAs are generally considered more powerful than the MOM approach and address many mission-critical system challenges. A MOM vs SOA discussion can highlight capabilities supported or enabled by the underlying architecture and can identify benefits of MOMs and SOAs when applied to differing sets of mission requirements or evaluation criteria.
The Goddard Mission Services Evolution Center, or GMSEC, was started in 2001 to create a new standard approach for managing GSFC missions. Standardized approaches in the past involved selecting and then integrating the most appropriate set of functional tools. Assumptions were made that "one size fits all" and that tool changes would not be necessary for many years. GMSEC took a very different approach and has proven to be very successful. The core of the GMSEC architecture consists of a publish/subscribe message bus, standardized message formats, and an Applications Programming Interface (API). The API supports multiple operating systems, programming languages and messaging middleware products. We use a GMSEC-developed free middleware for low-cost development. A high capacity, robust middleware is used for operations and a messaging system with a very small memory footprint is used for on-board flight software. Software components can use the standard message formats or develop adapters to convert from their native formats to the GMSEC formats. We do not want vendors to modify their core products. Over 50 software components are now available for use with the GMSEC architecture. Most available commercial telemetry and command systems, including the GMV hifly Satellite Control System, have been adapted to run in the GMSEC labs.
NASA Goddard Space Flight Center's "GMSEC" ground system architecture was presented at GSAW2003 as a concept being studied. GMSEC would utilize a publish/subscribe middleware framework and standardized interfaces to allow custom and COTS ground system components to plug-and-play. This capability, in turn, would reduce integration costs, allow for technology infusion over time, and encourage the development and sharing of common components across missions and organizations. At GSAW2004, GMSEC was presented at a breakout session as a system working well in the NASA lab and being applied as an integral piece of reengineering efforts for several GSFC missions. Today, GMSEC is supporting five satellites at GSFC and has been selected by several future missions. Over 30 plug-and-play components are now available to missions using the GMSEC approach. Other organizations, including Marshall Space Flight Center, Johns Hopkins University's Applied Physic Lab, and the Institute for Scientific Research are each developing GMSEC-compatible components. Based on the success of GMSEC and efforts at other NASA Centers, the message bus approach is now being evaluated as a NASA Agency-wide approach for many future missions involving multiple NASA Centers as we move towards the goals of NASA s new Exploration Initiative. The presentation will explain the basic technical concepts of using a publish/subscribe framework for mission operations support (and its applicability to flight systems as well). Lessons learned on NASA's GMSEC program will allow the audience to better understand the significant benefits of this architecture approach over the traditional "one-off" solution approach. The point of the presentation is to show the long-term benefits of using a ground system architecture which incorporates many of the successful GMSEC concepts - message bus, mix of COTS and custom software, standard interfaces, plug-and-play, etc. The implications for the development process will also be discussed.
Previous NASA laser communication missions have been supported by ground terminals specific to the mission. The Low-Cost Optical Terminal project (LCOT) aims to serve as a commercial off-the-shelf (COTS), reusable, and modular optical ground terminal prototype, provide a blueprint for future optical ground terminals, and enable optical communication experiments with a variety of spacecraft from Low Earth Orbit to lunar orbit. The goal of the internship was the development of LCOT’s Gimbal Monitor and Control (GMC) application, within the LCOT Monitor and Control Subsystem (MCS). Mount control software PWI4 was provided by mount and gimbal vendor Planewave Instruments; developed in Python, GMC integrates and interfaces with PWI4 using third party libraries such as Protobuf and RabbitMQ. As a stand in for the Monitor and Control Subsystem (MCS), a test Graphical User Interface (GUI) was created to send commands to and receive telemetry from the GMC application; these commands and telemetry are sent through the RabbitMQ message bus as Protobuf encoded messages. GMC then interfaces with PWI4 which passes along desired commands and telemetry to and from a vendor provided mount and gimbal simulator. The GMC software developed allows LCOT’s Monitor and Control Subsystem (MCS) to take advantage of the existing mount control software, advancing LCOT’s efforts in the development of the MCS. The MCS and GMC software developed will contribute to LCOT’s goal as a flexible and modular optical ground terminal prototype and blueprint, which supports development towards a potential optical ground terminal network.
With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!
The EVs-at-RISC project was a five-year research, development, and demonstration initiative to create foundational tools for utility-scale fleet aggregation and Smart Charge Management (SCM) of Electric Vehicles (EV), Electric Vehicle Charging Infrastructure (EVCI), and related Distributed Energy Resources (DER). Rather than seeking to develop and demonstrate highly perfected SCM algorithms and control strategies, this project instead focused on creating foundational software solutions that enable unprecedented digital interoperability across the communications technologies and vendor platforms used to manage EV , EVCI, and DER, as well as existing energy management infrastructure operated by utilities, grid operators, and aggregators. This project then extends these novel interoperability capabilities to develop and deploy powerful middleware abstractions across grid edge networks and EVCI/DER fleet aggregations incorporating modern software tools and best practices, such as CI/CD, to bring the immense capabilities of infrastructure-as-code and policy-as-code to modern grid edge network environments. This addresses the foremost systemic issues preventing realization of any net operational benefits from scaled deployment of behind-the-meter EV, EVCI, and DER assets in electric power grids and markets today. The results of this approach and project unlock massive potential for new SCM capabilities to be easily prototyped, evaluated, and deployed at-scale within the existing grid edge network infrastructure and EVCI/DER technology ecosystem. The EVs-at-RISC project achieves this by extending Open Field Message Bus (OpenFMB), a conceptual model for digital interoperability and distributed intelligence in traditional front-of-meter utility SCADA networks, validating our hypothesis that OpenFMB could be similarly used to solve systemic digital interoperability issues in behind-the-meter environments and unlock real-world utility-scale SCM capabilities without requiring any new proprietary vendor solutions or significant infrastructure reconfiguration.
This paper details an architectural description of the Mission Data Processing and Control System (MPCS), an event-driven, multi-mission ground data processing components providing uplink, downlink, and data management capabilities which will support the Mars Science Laboratory (MSL) project as its first target mission. MPCS is developed based on a set of small reusable components, implemented in Java, each designed with a specific function and well-defined interfaces. An industry standard messaging bus is used to transfer information among system components. Components generate standard messages which are used to capture system information, as well as triggers to support the event-driven architecture of the system. Event-driven systems are highly desirable for processing high-rate telemetry (science and engineering) data, and for supporting automation for many mission operations processes.
The NASA Goddard Mission Services Evolution Center (GMSEC) system is a message-based plug-and-play open system architecture used in many of NASA mission operations centers. This presentation will focus on the use of GMSEC standard messages to report and analyze the status of a system and enable the automation of the system's components. In GMSEC systems, each component reports its status using a keep-alive message and also publishes status and activities as log messages. In addition, the components can accept functional directive messages from the GMSEC message bus. Over the past several years, development teams have found ways to utilize these messages to create innovative display pages and increasingly sophisticated approaches to automation. This presentation will show the flexibility and value of the message-based approach to system awareness and automation.
AMS is in early stages of standardization. a) CCSDS "white book" (Proposed Standard) has been published. b) A single implementation has been developed and is being tested. No major obstacles encountered so far. a) Protocol has changed since original concept paper, but not radically. b) Design concepts seem to be sound. AMS capabilities seem to be broadly applicable. a) On-board, proximity, and deep-space communications for spacecraft. b) Suitable underlying messaging protocol for proposed CCSDS Spacecraft Monitor and Control protocols. c) Terrestrial applications designed for operation over a message bus. AMS Working Group within CCSDS is on schedule, so far.
The Alert Notification System Router (ANSR) software provides satellite operators with notifications of key events through pagers, cell phones, and e-mail. Written in Java, this application is specifically designed to meet the mission-critical standards for mission operations while operating on a variety of hardware environments. ANSR is a software component that runs inside the Mission Operations Center (MOC). It connects to the mission's message bus using the GMSEC [Goddard Space Flight Center (GSFC) Mission Services Evolution Center (GMSEC)] standard. Other components, such as automation and monitoring components, can use ANSR to send directives to notify users or groups. The ANSR system, in addition to notifying users, can check for message acknowledgements from a user and escalate the notification to another user if there is no acknowledgement. When a firewall prevents ANSR from accessing the Internet directly, proxies can be run on the other side of the wall. These proxies can be configured to access the Internet, notify users, and poll for their responses. Multiple ANSRs can be run in parallel, providing a seamless failover capability in the event that one ANSR system becomes incapacitated.
Automation has become critical for ground systems, improving efficiency and reliability while reducing costs across mission operations. The Goddard Mission Services Evolution Center (GMSEC) software suite has played a significant role in enabling this automation, leveraging its publish/subscribe paradigm through a message bus architecture to facilitate seamless communication and data flow. Historically, the GMSEC suite, through components like Criteria Action Table (CAT) has been pivotal in automating ground system capabilities. However, as technology advances, limitations in automation with CAT have emerged, creating an opportunity to enhance ground system automation through the introduction of GEMU. This new GMSEC component brings new capabilities and addresses specific automation constraints that CAT could not overcome, allowing for more sophisticated, flexible, and efficient message processing. GEMU, at its core, is designed to accelerate the development of custom GMSEC-compliant applications. It enables users to construct automated message processing pipelines quickly, supporting both drag-and-drop web-based configuration and scripting through a simple domain-specific language. This advancement not only simplifies the process but also reduces the time needed for implementing automated solutions. This presentation will outline GEMU’s potential value in improving mission operations automation. It will highlight the benefits of transitioning from CAT to GEMU and offer insights into how GEMU can drive operational efficiencies. We will also provide an overview of the automation capabilities of GEMU and its potential impact on mission operations centers (MOCs).
Requirement: Improve how NASA develops and maintains ground data systems for dozens of missions, with a couple new missions always in the development phase. Decided in 2001 on enhanced message-bus architecture. Users offered choices for major components. They plug and play because key interfaces are all the same. Can support COTS, heritage, and new software. Even the middleware can be switched. Project name: GMSEC. Goddard Mission Services Evolution Center.
The Formation Flying Test-Bed (FFTB) at NASA Goddard Space Flight Center (GSFC) provides a hardware-in-the-loop test environment for formation navigation and control. The facility is evolving as a modular, hybrid, dynamic simulation facility for end-tc-end guidance, navigation, and control (GN&C) design and analysis of formation flying spacecraft. The core capabilities of the FFTB, as a platform for testing critical hardware and software algorithms in-the-loop, are reviewed with a focus on many recent improvements. Two significant upgrades to the FFTB are a message-oriented middleware (MOM) architecture, and a software crosslink for inter-spacecraft ranging. The MOM architecture provides a common messaging bus for software agents, easing integration, arid supporting the GSFC Mission Services Evolution Center (GMSEC) architecture via software bridge. Additionally, the FFTB s hardware capabilities are expanding. Recently, two Low-Power Transceivers (LPTs) with ranging capability have been introduced into the FFTB. The LPT crosslinks will be connected to a modified Crosslink Channel Simulator (CCS), which applies realistic space-environment effects to the Radio Frequency (RF) signals produced by the LPTs.