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.

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2020

Evolution of the Preliminary Fault Management Architecture and Design for the Psyche Mission

The Psyche Mission presents the first opportunity toexplore the largest metal asteroid in the solar system, (16)Psyche, which is believed to be the exposed core of a largerplanetesimal that was stripped of its rocky mantle throughmultiple collisions during early solar system formation. Themission was selected in January 2017 for a 2022 launch as partof NASA’s Discovery Program and is uniquely enabled by theintegration of a Solar Electric Propulsion (SEP) Chassisdelivered by Maxar Space Solutions with JPL’s core deepspace avionics, flight software, and fault managementarchitectures. One of the key design tasks is the development ofa fault management system capable of being responsive to theunique elements of the combined JPL and Maxar spacecraftarchitecture. This new design leverages the strengths of eachorganization, with Maxar delivering its well-proven highvoltage power bus and low-thrust electric propulsionsubsystem from its GEO communications satellite product line,and JPL delivering its deep space mission expertise and thehardware and software most critical to deep space missiondesign. The development of a robust low-thrust mission andthe integration of design philosophies and hardware from twoorganizations is not without its challenges though.A key challenge in the development of the Psyche faultmanagement architecture and design is in the integration ofdesign philosophies and hardware from JPL and Maxar. Atthe architecture level, Maxar GEO communications satellitesare developed under the premise of highly responsive groundin the loop for the resolution of anomalies, and theimplementation takes a fail-operational approach to minimizedown time for its customers. In contrast, a deep space missionmust be able to maintain safety with long periods of groundcommunication outage. Additionally, with no time-criticalevents after launch, the Psyche spacecraft will generally failsafe in the presence of anomalous conditions; specialconsideration is being given to this approach, however, tominimize the loss of electric propulsion thrust time, which iscritical to low-thrust missions. At the hardware level, thedetailed definition of interfaces between JPL and Maxarhardware presents a unique challenge in the development andflowdown of fault management requirements, the developmentand implementation of fault monitors and responses, and thedevelopment and verification of fault containment boundaries.This paper describes the evolution of the Psyche faultmanagement architecture and design from the concept studyinto the preliminary design phase, with a focus on the uniquechallenges associated with flying GEO communicationssatellite hardware in deep space, implementing a robust lowthrust mission, and the integration of design philosophies andhardware from JPL and Maxar. Details regarding how thesechallenges are addressed in the fault management design inorder to maximize heritage, leverage the strengths of eachorganization, and minimize risk across the design are alsodiscussed.

Marsh, Danielle↗
NASA NTRS1999

The Evolution of the DARWIN System

DARWIN is a web-based system for presenting the results of wind-tunnel testing and computational model analyses to aerospace designers. DARWIN captures the data, maintains the information, and manages derived knowledge (e.g. visualizations, etc.) of large quantities of aerospace data. In addition, it provides tools and an environment for distributed collaborative engineering. We are currently constructing the third version of the DARWIN software system. DARWN's development history has, in some sense, tracked the development of web applications. The 1995 DARWIN reflected the latest web technologies--CGI scripts, Java applets and a three-layer architecture--available at that time. The 1997 version of DARWIN expanded on this base, making extensive use of a plethora of web technologies, including Java/JavaScript and Dynamic HTML. While more powerful, this multiplicity has proven to be a maintenance and development headache. The year 2000 version of DARWIN will provide a more stable and uniform foundation environment, composed primarily of Java mechanisms. In this paper, we discuss this evolution, comparing the strengths and weaknesses of the various architectural approaches and describing the lessons learned about building complex web applications.

Walton, Joan D.↗
NASA NTRS1989

QUICK - An interactive software environment for engineering design

QUICK, an interactive software environment for engineering design, provides a programmable FORTRAN-like calculator interface to a wide range of data structures as well as both built-in and user created functions. QUICK also provides direct access to the operating systems of eight different machine architectures. The evolution of QUICK and a brief overview of the current version are presented.

Skinner, David L.↗
NASA NTRS2006

A Reference Architecture for Space Information Management

We describe a reference architecture for space information management systems that elegantly overcomes the rigid design of common information systems in many domains. The reference architecture consists of a set of flexible, reusable, independent models and software components that function in unison, but remain separately managed entities. The main guiding principle of the reference architecture is to separate the various models of information (e.g., data, metadata, etc.) from implemented system code, allowing each to evolve independently. System modularity, systems interoperability, and dynamic evolution of information system components are the primary benefits of the design of the architecture. The architecture requires the use of information models that are substantially more advanced than those used by the vast majority of information systems. These models are more expressive and can be more easily modularized, distributed and maintained than simpler models e.g., configuration files and data dictionaries. Our current work focuses on formalizing the architecture within a CCSDS Green Book and evaluating the architecture within the context of the C3I initiative.

information systems↗
DOE OSTI2024

An integrated modeling framework with open architecture for phase field simulation of multi-component alloys

An integrated modeling framework (PanPhaseField) has been developed, which enables a direct and fast coupling between CALPHAD calculations and large-scale phase field simulations for multi-component alloys. Further, it adopts an open architecture allowing for integration of user-defined phase field models in a plug-and-play manner by taking full advantage of the user-friendly graphical interface of Pandat software. The developed modeling platform becomes an enabling tool that can be used to simulate the evolution of spatially varying microstructures of industrial complex alloys for various engineering applications.

36 MATERIALS SCIENCE↗
NASA NTRS2023

Trades, Architecture, and Design of the Joint Augmented Reality Visual Informatics (Joint AR) Product

Future expeditions will enable exploration and study of the planetary surfaces of the Moon and Mars by performing extravehicular activity (EVA) operations. Present-day International Space Station (ISS) EVA operations require an intricate and tight choreography of crew, space suits, tools, systems, and flight teams to plan, train, and execute with limited advanced informatics. Additionally, EVA operations, aside from the Apollo Lunar surface missions, have predominately focused on maintenance and construction tasks where success criteria are clearly measurable. However, future exploration missions expect to enable crew to carry out scientific objectives in increasingly Earth-independent ways. In this paper, the Joint Augmented Reality Visual Informatics System (Joint AR) characterizes the design space for developing a modular augmented reality (AR) device for a spacesuit form factor that can support crew decision-making for EVA. This paper highlights the project’s experience with a product-focused management style and use-case centered systems engineering approach to iteratively design, build, and test. The Joint AR product features were defined via trade studies and market analysis of previous EVA display efforts, various AR components such as optics, commercial AR systems, light engines, data interfaces, graphics engine software and analog test beds. We outline the defining architectural design decisions, including safety criticality considerations, suit mounting interfaces, computer architectures, and partnership contracting mechanisms. The outcomes of these studies, architecture decisions, and management requirements result in a recommended design which is the Joint AR product. We discuss the evolution, development of these system components, and what work remains. We hope to share a unified understanding of various design decisions and how they impact the future of crew members’ access to data during Lunar and Martian EVAs. This ongoing effort can enable a community-wide discovery process toward realizing necessary AR features and capabilities for future missions.

Augmented Reality↗
NASA NTRS1991

The evolution of power management architecture for missions to the outer planets

Outer planet spacecraft have unique requirements that differentiate them from inner planet and Earth orbiter spacecraft. To meet these requirements, the Voyager and Galileo Power Management And Distribution (PMAD) architectures employed shunt regulation and carried on the Mariner tradition of AC power distribution to many of the user loads. Also, autonomous fault recovery was achieved by automatic responses in hardware and software recovery routines. Finally, power distribution switching was expanded to allow for removal of the most trivial load element as the nuclear source depleted itself. The design cycle has begun for a third generation spacecraft set named Comet Rendezvous Asteroid Flyby (CRAF) and Cassini (a saturn orbiter). In their power systems, AC power distribution, relay/fuse load switching, and fault protection will give way to the advantages of DC power and solid state load switches.

Detwiler, R. C.↗
NASA NTRS1978

Fault-tolerance - The survival attribute of digital systems

Fault-tolerance is the architectural attribute of a digital system that keeps the logic machine doing its specified tasks when its host, the physical system, suffers various kinds of failures of its components. A more general concept of fault-tolerance also includes human mistakes committed during software and hardware implementation and during man/machine interaction among the causes of faults that are to be tolerated by the logic machine. This paper discusses the concept of fault-tolerance, the reasons for its inclusion in digital system architecture, and the methods of its implementation. A chronological view of the evolution of fault-tolerant systems and an outline of some goals for its further development conclude the presentation.

Avizienis, A.↗
NASA NTRS2006

Integrated System Health Management (ISHM): Systematic Capability Implementation

This paper provides a credible approach for implementation of ISHM capability in any system. The requirements and processes to implement ISHM capability are unique in that a credible capability is initially implemented at a low level, and it evolves to achieve higher levels by incremental augmentation. In contrast, typical capabilities, such as thrust of an engine, are implemented once at full Functional Capability Level (FCL), which is not designed to change during the life of the product. The approach will describe core ingredients (e.g. technologies, architectures, etc.) and when and how ISHM capabilities may be implemented. A specific architecture/taxonomy/ontology will be described, as well as a prototype software environment that supports development of ISHM capability. This paper will address implementation of system-wide ISHM as a core capability, and ISHM for specific subsystems as expansions and evolution, but always focusing on achieving an integrated capability.

Figueroa, Fernando↗
NASA NTRSDate not supplied

Process Modeling of Woven Textiles

Woven polymer matrix composites offer numerous advantages over traditional unidirectional laminates. Processing conditions affect residual stress that builds up during manufacturing. This work proposes the analysis of three curing parameters on the local residual stress distribution of a plain weave textile architecture, including chemical shrinkage, the temperature cool down, and the evolution of matrix properties as a function of curing. Virtual curing is applied to the inter-tow matrix material of the plain weave Repeating Unit Cell (RUC) modeled in TexGen. Curing is implemented through user-written subroutines within the commercial software suite Abaqus. Results from process modeling are compared with a linear-elastic thermal cool down in Abaqus. A boundary conditions study is also conducted to compare the residual stress build up predicted by Flat(FBCs) and Periodic Boundary Conditions (PBCs). Preliminary results indicate that a thermal cool down over-estimates the end-of-cure stresses in the matrix. Process modeling is conducted with and without chemical shrinkage, then compared with a thermal cool down. Results show that 11.32% of the final stress state is due to chemical shrinkage. Material property evolution during curing also has a non-negligible effect on the end stress.

woven composites↗
NASA NTRS1984

Command and telemetry in autonomous spacecraft design

Some major steps are summarized in the evolution of autonomous design features for planetary exploration spacecraft. The control and data architectures for the Viking, Voyager, and Galileo spacecraft are considered. Telemetry and command capabilities are fundamental features of spacecraft design that have been successfully used for autonomous control. Also discussed is the Autonomous Redundancy and Maintenance Management Subsystem (ARMMS) concept. The software approach to autonomous control provides for modifications to the control process or the addition of new operating features during flight operations.

Turner, P. R.↗
NASA NTRS2007

Evolution of the Space Station Robotic Manipulator

The Space Station Remote Manipulator System (SSRMS), Canadarm2, was launched in 2001 and deployed on the International Space Station (ISS). The Canadarm2 has been instrumental in ISS assembly and maintenance. Canadarm2 shares its heritage with the Space Shuttle Arm (Canadarm). This article explores the evolution from the Shuttle Canadarm to the Space Station Canadarm2 design, which incorporates a 7 degree of freedom design, larger joints, and changeable operating base. This article also addresses phased design, redundancy, life and maintainability requirements. The design of Canadarm2 meets unique ISS requirements, including expanded handling capability and the ability to be maintained on orbit. The size of ISS necessitated a mobile manipulator, resulting in the unique capability of Canadarm2 to relocate by performing a walk off to base points located along the Station, and interchanging the tip and base of the manipulator. This provides the manipulator with reach and access to a large part of the Station, enabling on-orbit assembly of the Station and providing support to Extra-Vehicular Activity (EVA). Canadarm2 is evolving based on on-orbit operational experience and new functionality requirements. SSRMS functionality is being developed in phases to support evolving ISS assembly and operation as modules are added and the Station becomes more complex. Changes to sustaining software, hardware architecture, and operations have significantly enhanced SSRMS capability to support ISS mission requirements. As a result of operational experience, SSRMS changes have been implemented for Degraded Joint Operations, Force Moment Sensor Thermal Protection, Enabling Ground Controlled Operations, and Software Commutation. Planned Canadarm2 design modifications include: Force Moment Accommodation, Smart Safing, Separate Safing, and Hot Backup. In summary, Canadarm2 continues to evolve in support of new ISS requirements and improved operations. It is a tribute to the design that this evolution can be accomplished while conducting critical on-orbit operations with minimal hardware changes.

Razvi, Shakeel↗
NASA NTRS2002

Information architecture for a planetary 'exploration web'

'Web services' is a common way of deploying distributed applications whose software components and data sources may be in different locations, formats, languages, etc. Although such collaboration is not utilized significantly in planetary exploration, we believe there is significant benefit in developing an architecture in which missions could leverage each others capabilities. We believe that an incremental deployment of such an architecture could significantly contribute to the evolution of increasingly capable, efficient, and even autonomous remote exploration.

middleware messaging IT infrastructure web service↗
NASA NTRS2014

Evolution of a Reconfigurable Processing Platform for a Next Generation Space Software Defined Radio

The National Aeronautics and Space Administration (NASA)Harris Ka-Band Software Defined Radio (SDR) is the first, fully reprogrammable space-qualified SDR operating in the Ka-Band frequency range. Providing exceptionally higher data communication rates than previously possible, this SDR offers in-orbit reconfiguration, multi-waveform operation, and fast deployment due to its highly modular hardware and software architecture. Currently in operation on the International Space Station (ISS), this new paradigm of reconfigurable technology is enabling experimenters to investigate navigation and networking in the space environment.The modular SDR and the NASA developed Space Telecommunications Radio System (STRS) architecture standard are the basis for Harris reusable, digital signal processing space platform trademarked as AppSTAR. As a result, two new space radio products are a synthetic aperture radar payload and an Automatic Detection Surveillance Broadcast (ADS-B) receiver. In addition, Harris is currently developing many new products similar to the Ka-Band software defined radio for other applications. For NASAs next generation flight Ka-Band radio development, leveraging these advancements could lead to a more robust and more capable software defined radio.The space environment has special considerations different from terrestrial applications that must be considered for any system operated in space. Each space mission has unique requirements that can make these systems unique. These unique requirements can make products that are expensive and limited in reuse. Space systems put a premium on size, weight and power. A key trade is the amount of reconfigurability in a space system. The more reconfigurable the hardware platform, the easier it is to adapt to the platform to the next mission, and this reduces the amount of non-recurring engineering costs. However, the more reconfigurable platforms often use more spacecraft resources. Software has similar considerations to hardware. Having an architecture standard promotes reuse of software and firmware. Space platforms have limited processor capability, which makes the trade on the amount of amount of flexibility paramount.

Telecommunication↗
NASA NTRS1991

Space Station Freedom electric power system evolution analysis status

The ability is examined of the SSF baselined EPS to transition to operate at a greater system capacity beyond the SSF Permanent Manned Capability PMC) milestone. Specifically, a status of a current analysis is discussed concerning additions, modifications, changeout, or combination thereof of baseline EPS hardware and/or software needed to accomplish the power generation, distribution, operation, and use needed to meet evolving SSF mission objectives. This discussion results in several EPS architectural options that facilitate the addition or substitution of new technologies.

Zernic, Michael J.↗
NASA NTRS2003

A Design for Composing and Extending Vehicle Models

The Systems Development Branch (SDB) at NASA Langley Research Center (LaRC) creates simulation software products for research. Each product consists of an aircraft model with experiment extensions. SDB treats its aircraft models as reusable components, upon which experiments can be built. SDB has evolved aircraft model design with the following goals: 1. Avoid polluting the aircraft model with experiment code. 2. Discourage the copy and tailor method of reuse. The current evolution of that architecture accomplishes these goals by reducing experiment creation to extend and compose. The architecture mechanizes the operational concerns of the model's subsystems and encapsulates them in an interface inherited by all subsystems. Generic operational code exercises the subsystems through the shared interface. An experiment is thus defined by the collection of subsystems that it creates ("compose"). Teams can modify the aircraft subsystems for the experiment using inheritance and polymorphism to create variants ("extend").

Madden, Michael M.↗
NASA NTRS2020

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗
NASA NTRS1992

MISSION: Mission and Safety Critical Support Environment. Executive overview

For mission and safety critical systems it is necessary to: improve definition, evolution and sustenance techniques; lower development and maintenance costs; support safe, timely and affordable system modifications; and support fault tolerance and survivability. The goal of the MISSION project is to lay the foundation for a new generation of integrated systems software providing a unified infrastructure for mission and safety critical applications and systems. This will involve the definition of a common, modular target architecture and a supporting infrastructure.

Mckay, Charles↗