SEARCH · Search NASA

Results for “software architecture design subsystem”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRS1992

Interim Service ISDN Satellite (ISIS) simulator development for advanced satellite designs and experiments

The simulation development associated with the network models of both the Interim Service Integrated Services Digital Network (ISDN) Satellite (ISIS) and the Full Service ISDN Satellite (FSIS) architectures is documented. The ISIS Network Model design represents satellite systems like the Advanced Communications Technology Satellite (ACTS) orbiting switch. The FSIS architecture, the ultimate aim of this element of the Satellite Communications Applications Research (SCAR) Program, moves all control and switching functions on-board the next generation ISDN communications satellite. The technical and operational parameters for the advanced ISDN communications satellite design will be obtained from the simulation of ISIS and FSIS engineering software models for their major subsystems. Discrete event simulation experiments will be performed with these models using various traffic scenarios, design parameters, and operational procedures. The data from these simulations will be used to determine the engineering parameters for the advanced ISDN communications satellite.

Pepin, Gerard R.↗

NASA NTRS1986

A computer modeling methodology and tool for assessing design concepts for the Space Station Data Management System

A computer modeling tool is being developed to assess candidate designs for the Space Station Data Management System (DMS). The DMS is to be a complex distributed computer system including the processor, storage devices, local area networks, and software that will support all processing functions onboard the Space Station. The modeling tool will allow a candidate design for the DMS, or for other subsystems that use the DMS, to be evaluated in terms of parameters. The tool and its associated modeling methodology are intended for use by DMS and subsystem designers to perform tradeoff analyses between design concepts using varied architectures and technologies.

Jones, W. R.↗

NASA NTRSDate not supplied

Risk Reduction through Early Software Prototyping for the Mars Ascent Vehicle

Despite the critical nature flight software plays in the development of spacecraft, software development teams are often brought on to the project after initial requirements definition and design efforts have started, and well after the conceptual design phase has completed. The flight software development team for the Mars Ascent Vehicle has supported the project from project formulation and conceptual design into the formal design and development. This approach has allowed for the development of a robust software prototype that supported risk reduction in numerous areas for the project. Early software prototyping supported decision making in the areas of hardware selection and considerations, software architecture, and simulation requirements. The prototype software actively supported ongoing trade studies and analyses for the project and enable valuable collaboration across multiple subsystems as well as between MSFC and the Jet Propulsion Laboratory. This early development also allowed the team to leverage past projects’ lessons learned to make valuable process improvements.

Stefanie Justice↗

NASA NTRS2001

Team Expo: A State-of-the-Art JSC Advanced Design Team

In concert with the NASA-wide Intelligent Synthesis Environment Program, the Exploration Office at the Johnson Space Center has assembled an Advanced Design Team. The purpose of this team is two-fold. The first is to identify, use, and develop software applications, tools, and design processes that streamline and enhance a collaborative engineering environment. The second is to use this collaborative engineering environment to produce conceptual, system-level-of-detail designs in a relatively short turnaround time, using a standing team of systems and integration experts. This includes running rapid trade studies on varying mission architectures, as well as producing vehicle and/or subsystem designs. The standing core team is made up of experts from all of the relevant engineering divisions (e.g. Power, Thermal, Structures, etc.) as well as representatives from Risk and Safety, Mission Operations, and Crew Life Sciences among others. The Team works together during 2- hour sessions in the same specially enhanced room to ensure real-time integration/identification of cross-disciplinary issues and solutions. All subsystem designs are collectively reviewed and approved during these same sessions. In addition there is an Information sub-team that captures and formats all data and makes it accessible for use by the following day. The result is Team Expo: an Advanced Design Team that is leading the change from a philosophy of "over the fence" design to one of collaborative engineering that pushes the envelope to achieve the next-generation analysis and design environment.

Tripathi, Abhishek↗

NASA NTRS1999

BIO-Plex Information System Concept

This paper describes a suggested design for an integrated information system for the proposed BIO-Plex (Bioregenerative Planetary Life Support Systems Test Complex) at Johnson Space Center (JSC), including distributed control systems, central control, networks, database servers, personal computers and workstations, applications software, and external communications. The system will have an open commercial computing and networking, architecture. The network will provide automatic real-time transfer of information to database server computers which perform data collection and validation. This information system will support integrated, data sharing applications for everything, from system alarms to management summaries. Most existing complex process control systems have information gaps between the different real time subsystems, between these subsystems and central controller, between the central controller and system level planning and analysis application software, and between the system level applications and management overview reporting. An integrated information system is vitally necessary as the basis for the integration of planning, scheduling, modeling, monitoring, and control, which will allow improved monitoring and control based on timely, accurate and complete data. Data describing the system configuration and the real time processes can be collected, checked and reconciled, analyzed and stored in database servers that can be accessed by all applications. The required technology is available. The only opportunity to design a distributed, nonredundant, integrated system is before it is built. Retrofit is extremely difficult and costly.

Jones, Harry↗

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 NTRS2016

Serious Gaming for Test & Evaluation of Clean-Slate (Ab Initio) National Airspace System (NAS) Designs

Incremental approaches to air transportation system development inherit current architectural constraints, which, in turn, place hard bounds on system capacity, efficiency of performance, and complexity. To enable airspace operations of the future, a clean-slate (ab initio) airspace design(s) must be considered. This ab initio National Airspace System (NAS) must be capable of accommodating increased traffic density, a broader diversity of aircraft, and on-demand mobility. System and subsystem designs should scale to accommodate the inevitable demand for airspace services that include large numbers of autonomous Unmanned Aerial Vehicles and a paradigm shift in general aviation (e.g., personal air vehicles) in addition to more traditional aerial vehicles such as commercial jetliners and weather balloons. The complex and adaptive nature of ab initio designs for the future NAS requires new approaches to validation, adding a significant physical experimentation component to analytical and simulation tools. In addition to software modeling and simulation, the ability to exercise system solutions in a flight environment will be an essential aspect of validation. The NASA Langley Research Center (LaRC) Autonomy Incubator seeks to develop a flight simulation infrastructure for ab initio modeling and simulation that assumes no specific NAS architecture and models vehicle-to-vehicle behavior to examine interactions and emergent behaviors among hundreds of intelligent aerial agents exhibiting collaborative, cooperative, coordinative, selfish, and malicious behaviors. The air transportation system of the future will be a complex adaptive system (CAS) characterized by complex and sometimes unpredictable (or unpredicted) behaviors that result from temporal and spatial interactions among large numbers of participants. A CAS not only evolves with a changing environment and adapts to it, it is closely coupled to all systems that constitute the environment. Thus, the ecosystem that contains the system and other systems evolves with the CAS as well. The effects of the emerging adaptation and co-evolution are difficult to capture with only combined mathematical and computational experimentation. Therefore, an ab initio flight simulation environment must accommodate individual vehicles, groups of self-organizing vehicles, and large-scale infrastructure behavior. Inspired by Massively Multiplayer Online Role Playing Games (MMORPG) and Serious Gaming, the proposed ab initio simulation environment is similar to online gaming environments in which player participants interact with each other, affect their environment, and expect the simulation to persist and change regardless of any individual player's active participation.

Allen, B. Danette↗

NASA NTRS2020

Goal-Oriented Architecture for Telescope Control Software

Modern telescope control systems control a multitude of sensors and actuators physically distributed across subsystems. Traditionally, control systems are specified to compute system outputs based on reference setpoints despite environmental or internal disturbances. The control strategies are typically tightly coupled and very prescriptive, defining how exactly the control is to be achieved. In a goal-oriented approach, the control system architecture emphasizes the operational aspect, specifying the behavior at a higher level in terms of operational goals, considering several aspects such as environmental conditions and required wavefront quality. The result is an architecture that can more autonomously handle different control strategies, taking into account systematically the physical states of the system which are relevant for control. This paper demonstrates the feasibility of a goal-oriented approach by analyzing four fundamental functions: pointing, tracking, offsetting, and dome vignetting. The resulting SysML analysis and design models are used to develop a software prototype for distributed telescope control. Typical operational scenarios are discussed and compared to the ESO Very Large Telescope control software architecture.

Karban, R.↗

NASA NTRS2006

AERCam Autonomy: Intelligent Software Architecture for Robotic Free Flying Nanosatellite Inspection Vehicles

The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.

Fredrickson, Steven E.↗

NASA NTRS1985

SSME digital control design characteristics

To protect against a latent programming error (software fault) existing in an untried branch combination that would render the space shuttle out of control in a critical flight phase, the Backup Flight System (BFS) was chartered to provide a safety alternative. The BFS is designed to operate in critical flight phases (ascent and descent) by monitoring the activities of the space shuttle flight subsystems that are under control of the primary flight software (PFS) (e.g., navigation, crew interface, propulsion), then, upon manual command by the flightcrew, to assume control of the space shuttle and deliver it to a noncritical flight condition (safe orbit or touchdown). The problems associated with the selection of the PFS/BFS system architecture, the internal BFS architecture, the fault tolerant software mechanisms, and the long term BFS utility are discussed.

Mitchell, W. T.↗

NASA NTRS2012

Principles to Products: Toward Realizing MOS 2.0

This is a report on the Operations Revitalization Initiative, part of the ongoing NASA-funded Advanced Multi-Mission Operations Systems (AMMOS) program. We are implementing products that significantly improve efficiency and effectiveness of Mission Operations Systems (MOS) for deep-space missions. We take a multi-mission approach, in keeping with our organization's charter to "provide multi-mission tools and services that enable mission customers to operate at a lower total cost to NASA." Focusing first on architectural fundamentals of the MOS, we review the effort's progress. In particular, we note the use of stakeholder interactions and consideration of past lessons learned to motivate a set of Principles that guide the evolution of the AMMOS. Thus guided, we have created essential patterns and connections (detailed in companion papers) that are explicitly modeled and support elaboration at multiple levels of detail (system, sub-system, element...) throughout a MOS. This architecture is realized in design and implementation products that provide lifecycle support to a Mission at the system and subsystem level. The products include adaptable multi-mission engineering documentation that describes essentials such as operational concepts and scenarios, requirements, interfaces and agreements, information models, and mission operations processes. Because we have adopted a model-based system engineering method, these documents and their contents are meaningfully related to one another and to the system model. This means they are both more rigorous and reusable (from mission to mission) than standard system engineering products. The use of models also enables detailed, early (e.g., formulation phase) insight into the impact of changes (e.g., to interfaces or to software) that is rigorous and complete, allowing better decisions on cost or technical trades. Finally, our work provides clear and rigorous specification of operations needs to software developers, further enabling significant gains in productivity.

AMMOS↗

NASA NTRS2019

Electrified Aircraft Propulsion Systems: Potential Failure Modes and Failure Mitigation Strategies

Electrified aircraft propulsion (EAP) systems hold great potential for the reduction of aircraft fuel burn, emissions, and noise. Currently, NASA and other organizations are actively working to identify and mature technologies necessary to bring EAP designs to reality. A requirement for the development of any civil aircraft and its systems is to ensure that potential hazards in the design are identified and appropriately mitigated to ensure that the system is safe. During aircraft development, a system safety assessment that consists of a functional hazard assessment is conducted to identify all potential failure conditions of each function, and classify those failures according to the severity of their effects on the aircraft or its occupants. The more severe a function's failure condition classification, the greater the development assurance level required for the function to ensure that the probability of the hazard is acceptably low. Today, aircraft engines and their control systems receive type certificate approval as a stand-alone system to signify their airworthiness. However, the complex coupling and distributed nature of EAP designs are expected to place added challenges on the certification of these systems. This presentation will provide an initial high-level review of the potential failure modes and hazards posed by a generic EAP system along with potential mitigation strategies for those failures. The EAP system is assumed to be a hybrid design consisting of gas turbine engines, mechanical drives, electric machines, power electronics and distribution systems, energy storage devices, and motor driven propulsors. The functionality provided by each of these EAP subsystems will be discussed along with the potential failure modes they may encounter. This will include a discussion of coupled failure effects, where a fault in one EAP subsystem effects the operation of other subsystems in the architecture. Next, potential failure mitigation strategies are discussed including both software-based and hardware-based mitigation strategies. The presentation will conclude with an example evaluation of the potential failure modes and mitigation strategies for a concept EAP system proposed by NASA.

Simon, Donald L.↗

NASA NTRS1991

A mission executor for an autonomous underwater vehicle

The Naval Postgraduate School has been conducting research into the design and testing of an Autonomous Underwater Vehicle (AUV). One facet of this research is to incrementally design a software architecture and implement it in an advanced testbed, the AUV II. As part of the high level architecture, a Mission Executor is being constructed using CLIPS (C Language Integrated Production System) version 5.0. The Mission Executor is an expert system designed to oversee progress from the AUV launch point to a goal area and back to the origin. It is expected that the executor will make informed decisions about the mission, taking into account the navigational path, the vehicle subsystem health, and the sea environment, as well as the specific mission profile which is downloaded from an offboard mission planner. Heuristics for maneuvering, avoidance of uncharted obstacles, waypoint navigation, and reaction to emergencies (essentially the expert knowledge of a submarine captain) are required. Many of the vehicle subsystems are modeled as objects using the CLIPS Object Oriented Language (COOL) embedded in CLIPS 5.0. Also, truth maintenance is applied to the knowledge base to keep configurations updated.

Lee, Yuh-Jeng↗

NASA NTRS2019

Lessons Learned from the Flight Unit Testing of the Near Earth Asteroid Scout Flight System

The Near Earth Asteroid Scout flight mission is set to launch on the maiden voyage of the Space Launch System as a secondary payload. The spacecraft will be jettisoned in cis-lunar space and embark on an ambitious 2.5 year mission to image an asteroid. The spacecraft is uniquely equipped with an 85m2 solar sail as the main propulsion system. The monolithic sail system is designed to package within a 6U volume for launch and then deploy during flight. The NEA Scout team has presented in the past to the International Symposium on Solar Sailing topics related to the engineering development unit and design efforts to achieve flight hardware build. This paper will focus on the lessons learned from building and testing the NEA Scout flight system. Focus will be on the mechanical, software, and electrical interfaces as well as preparation for subsystem environmental tests, including thermal vacuum. Due to the unique design of the spacecraft, the solar sail subsystem was required to be located in the center of the spacecraft. This requirement lead to design challenges such as designing and accommodating critical cable harnesses to run through the center of the sail subsystem, packaging and deployment design of the sail subsystem, and integrated testing efforts through an avionics test bed to verify and validate a complete system architecture.

Lockett, Tiffany Russell↗

NASA NTRS1998

An Adaptable Power System with Software Control Algorithm

A low cost, flexible and modular spacecraft power system design was developed in response to a call for an architecture that could accommodate multiple missions in the small to medium load range. Three upcoming satellites will use this design, with one launch date in 1999 and two in the year 2000. The design consists of modular hardware that can be scaled up or down, without additional cost, to suit missions in the 200 to 600 Watt orbital average load range. The design will be applied to satellite orbits that are circular, polar elliptical and a libration point orbit. Mission unique adaptations are accomplished in software and firmware. In designing this advanced, adaptable power system, the major goals were reduction in weight volume and cost. This power system design represents reductions in weight of 78 percent, volume of 86 percent and cost of 65 percent from previous comparable systems. The efforts to miniaturize the electronics without sacrificing performance has created streamlined power electronics with control functions residing in the system microprocessor. The power system design can handle any battery size up to 50 Amp-hour and any battery technology. The three current implementations will use both nickel cadmium and nickel hydrogen batteries ranging in size from 21 to 50 Amp-hours. Multiple batteries can be used by adding another battery module. Any solar cell technology can be used and various array layouts can be incorporated with no change in Power System Electronics (PSE) hardware. Other features of the design are the standardized interfaces between cards and subsystems and immunity to radiation effects up to 30 krad Total Ionizing Dose (TID) and 35 Mev/cm(exp 2)-kg for Single Event Effects (SEE). The control algorithm for the power system resides in a radiation-hardened microprocessor. A table driven software design allows for flexibility in mission specific requirements. By storing critical power system constants in memory, modifying the system code for other programs is simple. These constants can be altered also by ground command, or in response to an anomolous event. All critical power system functions have backup hardware functions to prevent a software or computer glitch from propagating. A number of battery charge control schemes can be implemented by selecting the proper control terms in the code. The architecture allows the design engineer to tune the system response to various system components and anticipated load profiles without costly alterations. A design trade was made with the size, weight and power dissipation of the electronics versus the performance of the power bus to load variations. Linear, fine control is maintained with a streamlined electronics design. This paper describes the hardware design as well as the software control algorithm. The challenges of closing the system control loop digitally is discussed. Control loop margin and power system performance is presented. Lab measurements are shown and compared to the system response of a hardware model running actual flight software.

Castell, Karen↗

NASA NTRS2018

Software and Human-Machine Interface Development for Environmental Controls Subsystem Support

The Space Launch System (SLS) is the next premier launch vehicle for NASA. It is the next stage of manned space exploration from American soil, and will be the platform in which we push further beyond Earth orbit. In preparation of the SLS maiden voyage on Exploration Mission 1 (EM-1), the existing ground support architecture at Kennedy Space Center required significant overhaul and updating. A comprehensive upgrade of controls systems was necessary, including programmable logic controller software, as well as Launch Control Center (LCC) firing room and local launch pad displays for technician use. Environmental control acts as an integral component in these systems, being the foremost system for conditioning the pad and extremely sensitive launch vehicle until T-0. The Environmental Controls Subsystem (ECS) required testing and modification to meet the requirements of the designed system, as well as the human factors requirements of NASA software for Validation and Verification (V&V). This term saw significant strides in the progress and functionality of the human-machine interfaces used at the launch pad, and improved integration with the controller code.

Dobson, Matthew↗

NASA NTRS2009

The Integrated Hazard Analysis Integrator

Hazard analysis addresses hazards that arise in the design, development, manufacturing, construction, facilities, transportation, operations and disposal activities associated with hardware, software, maintenance, operations and environments. An integrated hazard is an event or condition that is caused by or controlled by multiple systems, elements, or subsystems. Integrated hazard analysis (IHA) is especially daunting and ambitious for large, complex systems such as NASA s Constellation program which incorporates program, systems and element components that impact others (International Space Station, public, International Partners, etc.). An appropriate IHA should identify all hazards, causes, controls and verifications used to mitigate the risk of catastrophic loss of crew, vehicle and/or mission. Unfortunately, in the current age of increased technology dependence, there is the tendency to sometimes overlook the necessary and sufficient qualifications of the integrator, that is, the person/team that identifies the parts, analyzes the architectural structure, aligns the analysis with the program plan and then communicates/coordinates with large and small components, each contributing necessary hardware, software and/or information to prevent catastrophic loss. As viewed from both Challenger and Columbia accidents, lack of appropriate communication, management errors and lack of resources dedicated to safety were cited as major contributors to these fatalities. From the accident reports, it would appear that the organizational impact of managers, integrators and safety personnel contributes more significantly to mission success and mission failure than purely technological components. If this is so, then organizations who sincerely desire mission success must put as much effort in selecting managers and integrators as they do when designing the hardware, writing the software code and analyzing competitive proposals. This paper will discuss the necessary and sufficient requirements of one of the significant contributors to mission success, the IHA integrator. Discussions will be provided to describe both the mindset required as well as deleterious assumptions/behaviors to avoid when integrating within a large scale system.

Morris, A. Terry↗

NASA NTRS1993

Implementing the space shuttle data processing system with the space generic open avionics architecture

This paper presents an overview of the application of the Space Generic Open Avionics Architecture (SGOAA) to the Space Shuttle Data Processing System (DPS) architecture design. This application has been performed to validate the SGOAA, and its potential use in flight critical systems. The paper summarizes key elements of the Space Shuttle avionics architecture, data processing system requirements and software architecture as currently implemented. It then summarizes the SGOAA architecture and describes a tailoring of the SGOAA to the Space Shuttle. The SGOAA consists of a generic system architecture for the entities in spacecraft avionics, a generic processing external and internal hardware architecture, a six class model of interfaces and functional subsystem architectures for data services and operations control capabilities. It has been proposed as an avionics architecture standard with the National Aeronautics and Space Administration (NASA), through its Strategic Avionics Technology Working Group, and is being considered by the Society of Aeronautic Engineers (SAE) as an SAE Avionics Standard. This architecture was developed for the Flight Data Systems Division of JSC by the Lockheed Engineering and Sciences Company, Houston, Texas.

Wray, Richard B.↗