Search NASASearch

SEARCH · Search NASA

Results for “GDS”

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.

At least 19 records

RESTful CFDP: Managing GDS Complexity with Microservices

NASA's Advanced Multi-Mission Operations System (AMMOS) is currently adding capability to support the CCSDS File Delivery Protocol (CFDP). This feature is being added as part of the AMMOS Mission Data Processing and Control System (AMPCS). In order to address the system’s increasing complexity, AMPCS has recently been re-architected to break down its monolithic applications into smaller, individually deployable microservices. The CFDP capability is the first new AMPCS feature to leverage this new architecture. The CFDP microservice provides a web-based Representational State Transfer (REST) application programming interface (API) for complete monitor and control of its operations, and this enables it to be decoupled from other AMPCS microservices. This also results in better scalability for redundancy and load balancing. AMPCS's CFDP microservice is designed to support generic CFDP operations, agnostic to AMPCS's legacy concept of Downlink Products. An optional runtime plug-in allows the CFDP microservice to simulate CFDP artifacts as Downlink Products. Applying the microservices software architecture pattern both in the latest release of AMPCS and in providing the new CFDP capability has resulted in a more flexible system with improved extensibility and maintainability. System complexity has also become more manageable.

Choi, Joshua S.

Renaissance architecture for Ground Data Systems

The Mission Operations and Data Systems Directorate (MO&DSD) has embarked on a new approach for developing and operating Ground Data Systems (GDS) for flight mission support. This approach is driven by the goals of minimizing cost and maximizing customer satisfaction. Achievement of these goals is realized through the use of a standard set of capabilities which can be modified to meet specific user needs. This approach, which is called the Renaissance architecture, stresses the engineering of integrated systems, based upon workstation/local area network (LAN)/fileserver technology and reusable hardware and software components called 'building blocks.' These building blocks are integrated with mission specific capabilities to build the GDS for each individual mission. The building block approach is key to the reduction of development costs and schedules. Also, the Renaissance approach allows the integration of GDS functions that were previously provided via separate multi-mission facilities. With the Renaissance architecture, the GDS can be developed by the MO&DSD or all, or part, of the GDS can be operated by the user at their facility. Flexibility in operation configuration allows both selection of a cost-effective operations approach and the capability for customizing operations to user needs. Thus the focus of the MO&DSD is shifted from operating systems that we have built to building systems and, optionally, operations as separate services. Renaissance is actually a continuous process. Both the building blocks and the system architecture will evolve as user needs and technology change. Providing GDS on a per user basis enables this continuous refinement of the development process and product and allows the MO&DSD to remain a customer-focused organization. This paper will present the activities and results of the MO&DSD initial efforts toward the establishment of the Renaissance approach for the development of GDS, with a particular focus on both the technical and process implications posed by Renaissance to the MO&DSD.

Perkins, Dorothy C.

Joint Test Plan for Gas Dynamic Spray Technology Demonstration

Air Force Space Command (AFSPC) and NASA have similar missions, facilities, and structures located in similar harsh environments. Both are responsible for a number of facilities/structures with metallic structural and non-structural components in highly and moderately corrosive environments. Regardless of the corrosivity of the environment, all metals require periodic maintenance activity to guard against the insidious effects of corrosion and thus ensure that structures meet or exceed design or performance life. The standard practice for protecting metallic substrates in atmospheric environments is the use of an applied coating system. Current coating systems used across AFSPC and NASA contain volatile organic compounds (VOCs) and hazardous air pollutants (HAPs). These coatings are subject to environmental regulations at the Federal and State levels that limit their usage. In addition, these coatings often cannot withstand the high temperatures and exhaust that may be experienced by AFSPC and NASA structures. In response to these concerns, AFSPC and NASA have approved the use of thermal spray coatings (TSCs). Thermal spray coatings are extremely durable and environmentally friendly coating alternatives, but utilize large cumbersome equipment for application that make the coatings difficult and time consuming to repair. Other concerns include difficulties coating complex geometries and the cost of equipment, training, and materials. Gas Dynamic Spray (GDS) technology (also known as Cold Spray) will be evaluated as a smaller, more maneuverable repair method as well as for areas where thermal spray techniques are not as effective. The technology can result in reduced maintenance and thus reduced hazardous materials/wastes associated with current processes. Thermal spray and GDS coatings also have no VOCs and are environmentally preferable coatings. To achieve a condition suitable for the application of a coating system, including GDS coatings, the substrate must undergo some type of surface preparation and/or depainting operation to ensure adhesion of the new coating system. The GDS unit selected for demonstration has a powder feeding system that can be used for surface preparation or coating application. The surface preparation feature will also be examined. The primary objective of this effort is to demonstrate GDS technology as a repair method for TSCs. The project will also determine the optimal GDS coating thickness for acceptable performance. Successful completion of this project will result in approval of GDS technology as a repair method for TSCs at AFSPC and NASA installations and will improve corrosion protection at critical systems, facilitate easier maintenance activity, extend maintenance cycles, eliminate flight hardware contamination, and reduce the amount of hazardous waste generated.

Lewis, Pattie

The Mars 2020 Ground Data System Architecture

The Mars 2020 Mission’s primary objective is to collect 20 geographically unique samples during its prime mission of one and a quarter Martian years, or just over 2 Earth years. Mission planners determined the project needed to develop a system that would enable the operations team to analyze engineering and science data, make science decisions, select viable rover targets at a millimeter resolution and validate an uplink bundle for a car sized rover with more complex science instruments than any previous Mars surface mission. All this had to be done within a five hour time frame. Doing this with a small team would be a challenge, but this had to be accomplished by a large team of engineers and scientists located across North America and Europe. Achieving this level of operational efficiency was unheard of in the prime mission. In addition, the mission had another set of requirements that had nothing to do with surface operations; the Mars 2020 Ground Data System (GDS) was also expected to comply with a new set of security requirements to keep up with the ever changing cybersecurity landscape. The Mars 2020 Ground Data System (GDS) is a re-architected version of the Mars Science Laboratory GDS. The primary goal was to integrate the lessons learned from previous Mars surface missions, accommodate a set of new requirements and capabilities required to ensure mission success, and comply with a new set of cybersecurity controls. The new architecture includes several unique qualities including a data lake, language-agnostic system-wide event-based operations, containerization, automated deployment, network segmentation, infrastructure-as-code, API-driven interfaces, and the first Mars surface GDS to operate primarily in the cloud. The new architecture enabled greater access to the system’s data, tighter integration with the operations team, and a higher level of traceability. The availability of the data also enabled a new set of capabilities previously not possible on surface missions. These new capabilities include an autonomous data to information, pipeline for downlink analysis, horizontal scaling of science data processing capabilities, autonomous round trip data tracking of science and engineering data, integration of flight system state into the tactical planning cycle, high fidelity targeting utilizing kinematic data, and hierarchical image and 3d meshes data representations. This paper will introduce the requirements for the Mars 2020 Mission, the heritage architecture, and the rationale for the changes to achieve the new architecture. The paper will continue to describe the fundamental changes made to the GDS architecture, how these changes enabled a more tightly integrated GDS, and the new capabilities that were enabled by the new architecture. The paper will conclude with the lessons learned from the process of rearchitecting a heritage GDS system and from the first 200 days of operations supporting over 800 users from around the world.

Lopez-Roig, Reynaldo

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014. The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such a comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass, ground operations can still reduce mission costs through smaller staffing of operators and limiting their working hours. The challenge, then, for the SMAP GDS engineering team, is to formulate an automated operations strategy--and corresponding system architecture -- to minimize operator intervention during routine operations, while balancing the development costs associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS -- NASA's AMMOS Mission Data Processing and Control System (AMPCS) -- provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

soil moisture