Search NASA⌕ Search

SEARCH · Search NASA

Results for “software architecture evolution”

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.

103 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

Integrated System Health Management: Pilot Operational Implementation in a Rocket Engine Test Stand

This paper describes a credible implementation of integrated system health management (ISHM) capability, as a pilot operational system. Important core elements that make possible fielding and evolution of ISHM capability have been validated in a rocket engine test stand, encompassing all phases of operation: stand-by, pre-test, test, and post-test. The core elements include an architecture (hardware/software) for ISHM, gateways for streaming real-time data from the data acquisition system into the ISHM system, automated configuration management employing transducer electronic data sheets (TEDS?s) adhering to the IEEE 1451.4 Standard for Smart Sensors and Actuators, broadcasting and capture of sensor measurements and health information adhering to the IEEE 1451.1 Standard for Smart Sensors and Actuators, user interfaces for management of redlines/bluelines, and establishment of a health assessment database system (HADS) and browser for extensive post-test analysis. The ISHM system was installed in the Test Control Room, where test operators were exposed to the capability. All functionalities of the pilot implementation were validated during testing and in post-test data streaming through the ISHM system. The implementation enabled significant improvements in awareness about the status of the test stand, and events and their causes/consequences. The architecture and software elements embody a systems engineering, knowledge-based approach; in conjunction with object-oriented environments. These qualities are permitting systematic augmentation of the capability and scaling to encompass other subsystems.

Figueroa, Fernando↗
NASA NTRS1994

A new systems engineering approach to streamlined science and mission operations for the Far Ultraviolet Spectroscopic Explorer (FUSE)

The Mission Operations and Data Systems Directorate (MO&DSD, Code 500), the Space Sciences Directorate (Code 600), and the Flight Projects Directorate (Code 400) have developed a new approach to combine the science and mission operations for the FUSE mission. FUSE, the last of the Delta-class Explorer missions, will obtain high resolution far ultraviolet spectra (910 - 1220 A) of stellar and extragalactic sources to study the evolution of galaxies and conditions in the early universe. FUSE will be launched in 2000 into a 24-hour highly eccentric orbit. Science operations will be conducted in real time for 16-18 hours per day, in a manner similar to the operations performed today for the International Ultraviolet Explorer. In a radical departure from previous missions, the operations concept combines spacecraft and science operations and data processing functions in a single facility to be housed in the Laboratory for Astronomy and Solar Physics (Code 680). A small missions operations team will provide the spacecraft control, telescope operations and data handling functions in a facility designated as the Science and Mission Operations Center (SMOC). This approach will utilize the Transportable Payload Operations Control Center (TPOCC) architecture for both spacecraft and instrument commanding. Other concepts of integrated operations being developed by the Code 500 Renaissance Project will also be employed for the FUSE SMOC. The primary objective of this approach is to reduce development and mission operations costs. The operations concept, integration of mission and science operations, and extensive use of existing hardware and software tools will decrease both development and operations costs extensively. This paper describes the FUSE operations concept, discusses the systems engineering approach used for its development, and the software, hardware and management tools that will make its implementation feasible.

Butler, Madeline J.↗
NASA NTRS2015

A Modeling Pattern for Layered System Interfaces

Communications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi-layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end-to-end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes. This architectural model pattern uses methods described in ISO 42010, Recommended Practice for Architectural Description of Software-intensive Systems and CCSDS 311.0-M-1, Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.

Shames, Peter M.↗
NASA NTRSDate not supplied

NASA and Blue Origin’s Flight Assessment of Precision Landing Algorithms Computing Performance

NASA’s Safe and Precise Landing - Integrated Capabilities Evolution (SPLICE) project continues NASA’s work in the development and testing of technologies for Precision Landing and Hazard Avoidance (PL&HA). This paper presents results characterizing how SPLICE flight software utilizes the shared computing resources of the Descent Landing Computer (DLC), one of the PL&HA technologies under development. The SPLICE technologies are being tested as an integrated payload on Blue Origin’s New Shephard suborbital vehicle. The results presented in this paper are measured by applications running in and with the flight software both in flight, and in a high-fidelity Hardware-in-the-Loop (HWIL) simulation environment. Linux utilities to measure performance are also executed from the command line in the HWIL configuration. Performance measurements of the SPLICE workloads executing on the DLC provide insight on how efficiently the software is utilizing the DLC resources. Examples of how these measurements have guided improvements in the flight code are presented. In addition, the DLC uses a commercial processor as a surrogate for NASA’s High Performance Spaceflight Computing (HPSC) processor. This work provides insight on how an HPSC system may perform delivering PL&HA capabilities on a future mission. The measurements also can be used to infer architectural requirements for PL&HA capabilities, informing the HPSC project and other flight computer development efforts. Examples of the measurements collected include processor utilization, I/O bandwidth, cache and branch misses, and application profiles.

Precision Landing and Hazard Avoidance↗
NASA NTRSDate not supplied

NASA and Blue Origin’s Flight Assessment of Precision Landing Algorithms Computing Performance

NASA’s Safe and Precise Landing - Integrated Capabilities Evolution (SPLICE) project continues NASA’s work in the development and testing of technologies for Precision Landing and Hazard Avoidance (PL&HA). This paper presents results characterizing how SPLICE flight software utilizes the shared computing resources of the Descent Landing Computer (DLC), one of the PL&HA technologies under development. The SPLICE technologies are being tested as an integrated payload on Blue Origin’s New Shepard suborbital vehicle. The results presented in this paper are measured by applications running in and with the flight software both in flight, and in a high-fidelity Hardware-in-the-Loop (HWIL) simulation environment. Linux utilities to measure performance are also executed from the command line in the HWIL configuration. Performance measurements of the SPLICE workloads executing on the DLC provide insight on how efficiently the software is utilizing the DLC resources. Examples of how these measurements have guided improvements in the flight code are presented. In addition, the DLC uses a commercial processor as a surrogate for NASA’s High-Performance Spaceflight Computing (HPSC) processor. This work provides insight on how an HPSC system may perform delivering PL&HA capabilities on a future mission. The measurements also can be used to infer architectural requirements for PL&HA capabilities, informing the HPSC project and other flight computer development efforts. Examples of the measurements collected include processor utilization, I/O bandwidth, cache and branch misses, and application profiles.

Precision Landing↗
NASA NTRS2020

PHALANX: Expendable Projectile Sensor Networks for Planetary Exploration

Technologies enabling long-term, wide-ranging measurement in hard-to-reach areas are a critical need for planetary science inquiry. Phenomena of interest include flows or variations in volatiles, gas composition or concentration, particulate density, or even simply temperature. Improved measurement of these processes enables understanding of exotic geologies and distributions or correlating indicators of trapped water or biological activity. However, such data is often needed in unsafe areas such as caves, lava tubes, or steep ravines not easily reached by current spacecraft and planetary robots. To address this capability gap, we have developed miniaturized, expendable sensors which can be ballistically lobbed from a robotic rover or static lander - or even dropped during a flyover. These projectiles can perform sensing during flight and after anchoring to terrain features. By augmenting exploration systems with these sensors, we can extend situational awareness, perform long-duration monitoring, and reduce utilization of primary mobility resources, all of which are crucial in surface missions. We call the integrated payload that includes a cold gas launcher, smart projectiles, planning software, network discovery, and science sensing: PHALANX. In this paper, we introduce the mission architecture for PHALANX and describe an exploration concept that pairs projectile sensors with a rover “mothership.” Science use cases explored include reconnaissance using ballistic cameras, volatiles detection, and building timelapse maps of temperature and illumination conditions. Strategies to autonomously coordinate constellations of deployed sensors to self-discover and localize with peer ranging (i.e. a “local GPS”) are summarized, thus providing communications infrastructure beyond-line-of-sight (BLOS) of the rover. Capabilities were demonstrated through both simulation and physical testing with a terrestrial prototype. The approach to developing a terrestrial prototype is discussed, including design of the launching mechanism, projectile optimization, micro-electronics fabrication, and sensor selection. Results from early testing and characterization of commercial-off-the-shelf (COTS) components are reported. Nodes were subjected to successful burn-in tests over 48 hours at full logging duty cycle. Integrated field tests were conducted in the Roverscape, a half-acre planetary analog environment at NASA Ames, where we tested up to 10 sensor nodes simultaneously coordinating with an exploration rover. Ranging accuracy has been demonstrated to be within +/-10cm over 20m using commodity radios when compared to high-resolution laser scanner ground truthing. Evolution of the design, including progressive miniaturization of the electronics and iterated modifications of the enclosure housing for streamlining and optimized radio performance are described. Finally, lessons learned to date, gaps toward eventual flight mission implementation, and continuing future development plans are discussed.

Dille, Michael↗
NASA NTRS2014

Evolution of the JPSS Ground Project Calibration and Validation System

The Joint Polar Satellite System (JPSS) is the National Oceanic and Atmospheric Administrations (NOAA) next-generation operational Earth observation Program that acquires and distributes global environmental data from multiple polar-orbiting satellites. The JPSS Program plays a critical role to NOAAs mission to understand and predict changes in weather, climate, oceans, coasts, and space environments, which supports the Nation’s economy and protection of lives and property. The National Aerospace and Atmospheric Administration (NASA) is acquiring and implementing the JPSS, comprised of flight and ground systems on behalf of NOAA. The JPSS satellites are planned to fly in the afternoon orbit and will provide operational continuity of satellite-based observations and products for NOAA Polar-orbiting Operational Environmental Satellites (POES) and the Suomi National Polar-orbiting Partnership (SNPP) satellite. To support the JPSS Calibration and Validation (CalVal) node Government Resource for Algorithm Verification, Independent Test, and Evaluation (GRAVITE) services facilitate: Algorithm Integration and Checkout, Algorithm and Product Operational Tuning, Instrument Calibration, Product Validation, Algorithm Investigation, and Data Quality Support and Monitoring. GRAVITE is a mature, deployed system that currently supports the SNPP Mission and has been in operations since SNPP launch. This paper discusses the major re-architecture for Block 2.0 that incorporates SNPP lessons learned, architecture of the system, and demonstrates how GRAVITE has evolved as a system with increased performance. It is now a robust, stable, reliable, maintainable, scalable, and secure system that supports development, test, and production strings, replaces proprietary and custom software, uses open source software, and is compliant with NASA and NOAA standards.

Data Processing↗
NASA NTRS2016

Evolution of the JPSS Ground Project Calibration and Validation System

The Joint Polar Satellite System (JPSS) is the National Oceanic and Atmospheric Administration's (NOAA) next-generation operational Earth observation Program that acquires and distributes global environmental data from multiple polar-orbiting satellites. The JPSS Program plays a critical role to NOAA's mission to understand and predict changes in weather, climate, oceans, coasts, and space environments, which supports the Nation's economy and protection of lives and property. The National Aeronautics and Space Administration (NASA) is acquiring and implementing the JPSS, comprised of flight and ground systems, on behalf of NOAA. The JPSS satellites are planned to fly in the afternoon orbit and will provide operational continuity of satellite-based observations and products for NOAA Polar-orbiting Operational Environmental Satellites (POES) and the Suomi National Polar-orbiting Partnership (SNPP) satellite. To support the JPSS Calibration and Validation (CalVal) node Government Resource for Algorithm Verification, Independent Test, and Evaluation (GRAVITE) services facilitate: Algorithm Integration and Checkout, Algorithm and Product Operational Tuning, Instrument Calibration, Product Validation, Algorithm Investigation, and Data Quality Support and Monitoring. GRAVITE is a mature, deployed system that currently supports the SNPP Mission and has been in operations since SNPP launch. This paper discusses the major re-architecture for Block 2.0 that incorporates SNPP lessons learned, architecture of the system, and demonstrates how GRAVITE has evolved as a system with increased performance. It is now a robust, stable, reliable, maintainable, scalable, and secure system that supports development, test, and production strings, replaces proprietary and custom software, uses open source software, and is compliant with NASA and NOAA standards.

Next-Generation↗
NASA NTRS2017

On the Development and Application of High Data Rate Architecture (HiDRA) in Future Space Networks

Historically, space missions have been severely constrained by their ability to downlink the data they have collected. These constraints are a result of relatively low link rates on the spacecraft as well as limitations on the time during which data can be sent. As part of a coherent strategy to address existing limitations and get more data to the ground more quickly, the Space Communications and Navigation (SCaN) program has been developing an architecture for a future solar system Internet. The High Data Rate Architecture (HiDRA) project is designed to fit into such a future SCaN network. HiDRA's goal is to describe a general packet-based networking capability which can be used to provide assets with efficient networking capabilities while simultaneously reducing the capital costs and operational costs of developing and flying future space systems.Along these lines, this paper begins by reviewing various characteristics of modern satellite design as well as relevant characteristics of emerging technologies (such as free-space optical links capable of working at 100+ Gbps). Next, the paper describes HiDRA's design, and how the system is able to both integrate and support the operation of not only today's high-rate systems, but also the high-rate systems likely to be found in the future. This section also explores both existing and future networking technologies, such as Delay Tolerant Networking (DTN) protocol (RFC4838 citeRFC:1, RFC5050citeRFC:2), and explains how HiDRA supports them. Additionally, this section explores how HiDRA is used for scheduling data movement through both proactive and reactive link management. After this, the paper moves on to explore a reference implementation of HiDRA. This implementation is currently being realized based on a Field Programmable Gate Array (FPGA) memory and interface controller that is itself controlled by a local computer running DTN software. Next, this paper explores HiDRA's natural evolution, which includes an integration path for software-defined networking (SDN) switches. This section also describes considerations for both near-Earth and deep-space instantiations of HiDRA, describing how differences in latencies between the environments will necessarily influence how the system is configured and the networks operate. Finally, this paper describes future work. This section includes a description of a potential ISS implementation which will allow rapid advancement through the technology readiness levels (TRL). This section also explores work being done to support HiDRA's successful implementation and operation in a heterogeneous network: such a network could include communications equipment spanning many vintages and capabilities, and one significant aspect of HiDRA's future development involves balancing compatibility with capability.

DTN↗
NASA NTRS2013

Applying Model Based Systems Engineering to NASA's Space Communications Networks

System engineering practices for complex systems and networks now require that requirement, architecture, and concept of operations product development teams, simultaneously harmonize their activities to provide timely, useful and cost-effective products. When dealing with complex systems of systems, traditional systems engineering methodology quickly falls short of achieving project objectives. This approach is encumbered by the use of a number of disparate hardware and software tools, spreadsheets and documents to grasp the concept of the network design and operation. In case of NASA's space communication networks, since the networks are geographically distributed, and so are its subject matter experts, the team is challenged to create a common language and tools to produce its products. Using Model Based Systems Engineering methods and tools allows for a unified representation of the system in a model that enables a highly related level of detail. To date, Program System Engineering (PSE) team has been able to model each network from their top-level operational activities and system functions down to the atomic level through relational modeling decomposition. These models allow for a better understanding of the relationships between NASA's stakeholders, internal organizations, and impacts to all related entities due to integration and sustainment of existing systems. Understanding the existing systems is essential to accurate and detailed study of integration options being considered. In this paper, we identify the challenges the PSE team faced in its quest to unify complex legacy space communications networks and their operational processes. We describe the initial approaches undertaken and the evolution toward model based system engineering applied to produce Space Communication and Navigation (SCaN) PSE products. We will demonstrate the practice of Model Based System Engineering applied to integrating space communication networks and the summary of its results and impact. We will highlight the insights gained by applying the Model Based System Engineering and provide recommendations for its applications and improvements.

Bhasin, Kul↗
NASA NTRS2006

Fault Management Techniques in Human Spaceflight Operations

This paper discusses human spaceflight fault management operations. Fault detection and response capabilities available in current US human spaceflight programs Space Shuttle and International Space Station are described while emphasizing system design impacts on operational techniques and constraints. Preflight and inflight processes along with products used to anticipate, mitigate and respond to failures are introduced. Examples of operational products used to support failure responses are presented. Possible improvements in the state of the art, as well as prioritization and success criteria for their implementation are proposed. This paper describes how the architecture of a command and control system impacts operations in areas such as the required fault response times, automated vs. manual fault responses, use of workarounds, etc. The architecture includes the use of redundancy at the system and software function level, software capabilities, use of intelligent or autonomous systems, number and severity of software defects, etc. This in turn drives which Caution and Warning (C&W) events should be annunciated, C&W event classification, operator display designs, crew training, flight control team training, and procedure development. Other factors impacting operations are the complexity of a system, skills needed to understand and operate a system, and the use of commonality vs. optimized solutions for software and responses. Fault detection, annunciation, safing responses, and recovery capabilities are explored using real examples to uncover underlying philosophies and constraints. These factors directly impact operations in that the crew and flight control team need to understand what happened, why it happened, what the system is doing, and what, if any, corrective actions they need to perform. If a fault results in multiple C&W events, or if several faults occur simultaneously, the root cause(s) of the fault(s), as well as their vehicle-wide impacts, must be determined in order to maintain situational awareness. This allows both automated and manual recovery operations to focus on the real cause of the fault(s). An appropriate balance must be struck between correcting the root cause failure and addressing the impacts of that fault on other vehicle components. Lastly, this paper presents a strategy for using lessons learned to improve the software, displays, and procedures in addition to determining what is a candidate for automation. Enabling technologies and techniques are identified to promote system evolution from one that requires manual fault responses to one that uses automation and autonomy where they are most effective. These considerations include the value in correcting software defects in a timely manner, automation of repetitive tasks, making time critical responses autonomous, etc. The paper recommends the appropriate use of intelligent systems to determine the root causes of faults and correctly identify separate unrelated faults.

O'Hagan, Brian↗
NASA NTRS2019

Rising Above the Cloud - Toward High-Rate Delay-Tolerant Networking in Low-Earth Orbit

The High Data Rate Architecture (HiDRA) project is implementing a High-rate Delay Tolerant Networking (HDTN) capability that can support Low Earth Orbit (LEO) applications and environments. The present state of the effort, future work, and other elements of the work to date are described in this paper. This implementation is intended to support applications that run at 1+ Gbps, per the requirements of modern optical and high-frequency RF links. Uniquely, this implementation is also tuned to support relay and data trunking applications, which might require support for large numbers of small bundles per second. The design for this platform is based entirely on commercial-off-the-shelf (COTS) components, and possesses buffering capabilities in the 5 TB range. This document takes results from previous individual tests and integrates them to demonstrate results in the presence of a coherent use-case: consider a network aboard the ISS which intends to utilize an upcoming optical communications capability. For this use-case, orbital analysis software is used to analyze orbital dynamics, from which a list of access times are generated that might take in to account weather, schedule competition, etc. A variant of Contact Graph Routing (CGR) is applied to these windows to determine an optimal schedule. This schedule is then loaded into the HDTN prototype and, in conjunction with various measurement tools, a complete end-to-end analysis of HDTN's performance is conducted. Various bottlenecks (including storage) are identified: these bottlenecks are expected to help us focus our future work on the elements of the system that are most likely to present issues moving forward. Finally, we discuss possible paths for evolution beyond the present rates supported by the system, including (but not limited to) hardware acceleration.

Hylton, Alan↗
NASA NTRS2016

MarCO: Interplanetary Mission Development on a CubeSat Scale

Shortly after JPL’s Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) mission launches, separates, and commences its cruise phase, two CubeSats will deploy from the launch vehicle’s upper stage and begin independent flight to Mars (Fig. 1). During InSight’s entry, descent, and landing (EDL) sequence, these twin Mars Cube One (MarCO) spacecraft will fly 3,500 km above the Martian surface, recording and relaying InSight UHF radio data to the Deep Space Network (DSN) on Earth1. MarCO is a twin CubeSat mission developed by the NASA Jet Propulsion Laboratory (JPL) to accompany the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) Mars mission lander. MarCO's primary mission objective is to launch with InSight and independently fly to Mars to serve as a communications relay during InSight's entry, descent, and landing (EDL) phase. MarCO represents a new type of deep space mission: CubeSats at Mars. Building on the development of JPL's first interplanetary CubeSat project, the Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment (INSPIRE), MarCO further refined the approach to hardware, software, and ground architecture development to solve the challenges of quickly building low-budget spacecraft to fly to Mars. The greatest constraint, beyond others typical of CubeSat missions, was time. The duration between MarCO's conception to completion of spacecraft assembly was less than two years - an unprecedented schedule for any planetary mission to date. Through necessity, MarCO has built on previous experience, procedures, systems, and development methodologies, defining a new niche for supporting larger primary missions. The MarCO spacecraft are poised to write a new chapter in deep space exploration. Originally slated to launch and reach Mars in 2016, the InSight mission schedule subsequently slipped to 2018. During the original landing of InSight, Earth would not be in view, and no orbiter around Mars would have been in position to both receive UHF EDL data and simultaneously relay it back to Earth. It was from this obstacle that MarCO was conceived. Regardless of any changes to InSight’s 2018 EDL configuration geometry, MarCO is still expected to fly and serve in the same capacity as originally designed: the first CubeSat mission to Mars. CubeSats have historically been firmly in the domain of universities and small companies. As first conceived, they served as a platform upon which to teach all aspects of the space mission lifecycle. JPL took on this mission type with Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment2 (INSPIRE), moving the concept into a new domain: deep space. Building from the INSPIRE platform and lessons learned, MarCO addressed new challenges in the domain of planetary missions: independent interplanetary flight and navigation, integration with a large-scale mission, long-distance and long-delay communication, short development time, and a small development team. Of these, the greatest constraint was schedule: only 18 months passed from conception of mission concept until delivery of fully assembled and tested flight hardware. Careful selection of mission team, along with extensive use of off-the-shelf equipment, and streamlining automated processes, was essential. This achievement represents the next step in the evolution of CubeSats beyond low-Earth orbit.

Werne, Thomas↗