Introduction to MDS Architecture
Explore the source record for details and available documents.
software engineering systems software architecture↗
SEARCH · Engineering Papers
Results for “engineering software”
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.
A software measurement and fault modeling technique
Explore the source record for details and available documents.
fault detection software engineering technology so↗
Prospective Architectures for Onboard vs Cloud-Based Decision Making for Unmanned Aerial Systems
This paper investigates propsective architectures for decision-making in unmanned aerial systems. When these unmanned vehicles operate in urban environments, there are several sources of uncertainty that affect their behavior, and decision-making algorithms need to be robust to account for these different sources of uncertainty. It is important to account for several risk-factors that affect the flight of these unmanned systems, and facilitate decision-making by taking into consideration these various risk-factors. In addition, there are several technical challenges related to autonomous flight of unmanned aerial systems; these challenges include sensing, obstacle detection, path planning and navigation, trajectory generation and selection, etc. Many of these activities require significant computational power and in many situations, all of these activities need to be performed in real-time. In order to efficiently integrate these activities, it is important to develop a systematic architecture that can facilitate real-time decision-making. Four prospective architectures are discussed in this paper; on one end of the spectrum, the first architecture considers all activities/computations being performed onboard the vehicle whereas on the other end of the spectrum, the fourth and final architecture considers all activities/computations being performed in the cloud, using a new service known as Prognostics as a Service that is being developed at NASA Ames Research Center. The four different architectures are compared, their advantages and disadvantages are explained and conclusions are presented.
Software engineering↗
ASTEC and MODEL: Controls software development at Goddard Space Flight Center
The ASTEC (Analysis and Simulation Tools for Engineering Controls) software is under development at the Goddard Space Flight Center (GSFC). The design goal is to provide a wide selection of controls analysis tools at the personal computer level, as well as the capability to upload compute-intensive jobs to a mainframe or supercomputer. In the last three years the ASTEC (Analysis and Simulation Tools for Engineering Controls) software has been under development. ASTEC is meant to be an integrated collection of controls analysis tools for use at the desktop level. MODEL (Multi-Optimal Differential Equation Language) is a translator that converts programs written in the MODEL language to FORTRAN. An upgraded version of the MODEL program will be merged into ASTEC. MODEL has not been modified since 1981 and has not kept with changes in computers or user interface techniques. This paper describes the changes made to MODEL in order to make it useful in the 90's and how it relates to ASTEC.
Downing, John P.↗
Product Engineering Class in the Software Safety Risk Taxonomy for Building Safety-Critical Systems
When software safety requirements are imposed on legacy safety-critical systems, retrospective safety cases need to be formulated as part of recertifying the systems for further use and risks must be documented and managed to give confidence for reusing the systems. The SEJ Software Development Risk Taxonomy [4] focuses on general software development issues. It does not, however, cover all the safety risks. The Software Safety Risk Taxonomy [8] was developed which provides a construct for eliciting and categorizing software safety risks in a straightforward manner. In this paper, we present extended work on the taxonomy for safety that incorporates the additional issues inherent in the development and maintenance of safety-critical systems with software. An instrument called a Software Safety Risk Taxonomy Based Questionnaire (TBQ) is generated containing questions addressing each safety attribute in the Software Safety Risk Taxonomy. Software safety risks are surfaced using the new TBQ and then analyzed. In this paper we give the definitions for the specialized Product Engineering Class within the Software Safety Risk Taxonomy. At the end of the paper, we present the tool known as the 'Legacy Systems Risk Database Tool' that is used to collect and analyze the data required to show traceability to a particular safety standard
Hill, Janice↗
Autonomous Cryogenics Loading Operations Simulation Software: Knowledgebase Autonomous Test Engineer
Working on the ACLO (Autonomous Cryogenics Loading Operations) project I have had the opportunity to add functionality to the physics simulation software known as KATE (Knowledgebase Autonomous Test Engineer), create a new application allowing WYSIWYG (what-you-see-is-what-you-get) creation of KATE schematic files and begin a preliminary design and implementation of a new subsystem that will provide vision services on the IHM (Integrated Health Management) bus. The functionality I added to KATE over the past few months includes a dynamic visual representation of the fluid height in a pipe based on number of gallons of fluid in the pipe and implementing the IHM bus connection within KATE. I also fixed a broken feature in the system called the Browser Display, implemented many bug fixes and made changes to the GUI (Graphical User Interface).
Wehner, Walter S., Jr.↗
Heat Analysis Manager (HAM), a Thermal Desktop API Based Heat Map Generation Software
Thermal engineers often create custom heat maps to analyze their thermal model. However, generating a heat map is difficult because thermal simulation only readily provide attributes of simulated nodes such as temperature, capacitance, heat generation, and a network of conductances. Heat flow values are a derived quantity from the nodal attributes, and the data processing and management of heat flow between nodes quickly become difficult for large models. Deriving a network of heat flow values requires vast amount of calculations and data handling, heat map generation process generally suffers from processing speed, loss of accuracy, and/or presentation of data in a useful format. Heat Analysis Manager (HAM) is a Thermal Desktop (TD) based free multi-purpose tool developed to aid thermal engineers in analyzing their thermal model, including a heat map generation functionality. HAM’s heat map generator retains accuracy and fast processing speed by utilizing TD’s application programming interface (API) and built-in TD’s “Qflow from Results.” Furthermore, HAM’s heat map output is presented in an easily customizable format in Excel, allowing users to create various custom visual heat maps. A full description of how HAM utilizes TD’s API to create a customizable heat map is provided. A simple model demonstration is included along with step-by-step procedures on creating custom heat maps. HAM’s heat map result has been verified against TD’s and other heat map generation software, and verification methods are also included.
Thermal desktop↗
An RL10A-3-3A rocket engine model using the rocket engine transient simulator (ROCETS) software
Steady-state and transient computer models of the RL10A-3-3A rocket engine have been created using the Rocket Engine Transient Simulation (ROCETS) code. These models were created for several purposes. The RL10 engine is a critical component of past, present, and future space missions; the model will give NASA an in-house capability to simulate the performance of the engine under various operating conditions and mission profiles. The RL10 simulation activity is also an opportunity to further validate the ROCETS program. The ROCETS code is an important tool for modeling rocket engine systems at NASA Lewis. ROCETS provides a modular and general framework for simulating the steady-state and transient behavior of any desired propulsion system. Although the ROCETS code is being used in a number of different analysis and design projects within NASA, it has not been extensively validated for any system using actual test data. The RL10A-3-3A has a ten year history of test and flight applications; it should provide sufficient data to validate the ROCETS program capability. The ROCETS models of the RL10 system were created using design information provided by Pratt & Whitney, the engine manufacturer. These models are in the process of being validated using test-stand and flight data. This paper includes a brief description of the models and comparison of preliminary simulation output against flight and test-stand data.
Binder, Michael↗
The software-cycle model for re-engineering and reuse
This paper reports on the progress of a study which will contribute to our ability to perform high-level, component-based programming by describing means to obtain useful components, methods for the configuration and integration of those components, and an underlying economic model of the costs and benefits associated with this approach to reuse. One goal of the study is to develop and demonstrate methods to recover reusable components from domain-specific software through a combination of tools, to perform the identification, extraction, and re-engineering of components, and domain experts, to direct the applications of those tools. A second goal of the study is to enable the reuse of those components by identifying techniques for configuring and recombining the re-engineered software. This component-recovery or software-cycle model addresses not only the selection and re-engineering of components, but also their recombination into new programs. Once a model of reuse activities has been developed, the quantification of the costs and benefits of various reuse options will enable the development of an adaptable economic model of reuse, which is the principal goal of the overall study. This paper reports on the conception of the software-cycle model and on several supporting techniques of software recovery, measurement, and reuse which will lead to the development of the desired economic model.
Bailey, John W.↗
Flight evaluation of modifications to a digital electronic engine control system in an F-15 airplane
The third phase of a flight evaluation of a digital electronic engine control system in an F-15 has recently been completed. It was found that digital electronic engine control software logic changes and augmentor hardware improvements resulted in significant improvements in engine operation. For intermediate to maximum power throttle transients, an increase in altitude capability of up to 8000 ft was found, and for idle to maximum transients, an increase of up to 4000 ft was found. A nozzle instability noted in earlier flight testing was investigated on a test engine at NASA Lewis Research Center, a digital electronic engine control software logic change was developed and evaluated, and no instability occurred in the Phase 3 flight evaluation. The backup control airstart modification was evaluated, and gave an improvement of airstart capability by reducing the minimum airspeed for successful airstarts by 50 to 75 knots.
Burcham, F. W., Jr.↗
Flight evaluation of modifications to a digital electronic engine control system in an F-15 airplane
The third phase of a flight evaluation of a digital electronic engine control system in an F-15 has recently been completed. It was found that digital electronic engine control software logic changes and augmentor hardware improvements resulted in significant improvements in engine operation. For intermediate to maximum power throttle transients, an increase in altitude capability of up to 8000 ft was found, and for idle to maximum transients, an increase of up to 4000 ft was found. A nozzle instability noted in earlier flight testing was investigated on a test engine at NASA Lewis Research Center, a digital electronic engine control software logic change was developed and evaluated, and no instability occurred in the Phase 3 flight evaluation. The backup control airstart modification was evaluated, and gave an improvement of airstart capability by reducing the minimum airspeed for successful airstarts by 50 to 75 knots.
Burcham, F. W., Jr.↗
Igniter Simulator
Report describes electronic circuitry that simulates electrical properties of igniter of Space Shuttle main engine. Circuit used to test software of engine controller, without having to fire real igniter or turn on engine. Circuit used in all igniter simulations and mimics operation of igniter more realistically than did previous versions.
Simon, Richard A.↗
Statistical modelling of software reliability
During the six-month period from 1 April 1991 to 30 September 1991 the following research papers in statistical modeling of software reliability appeared: (1) A Nonparametric Software Reliability Growth Model; (2) On the Use and the Performance of Software Reliability Growth Models; (3) Research and Development Issues in Software Reliability Engineering; (4) Special Issues on Software; and (5) Software Reliability and Safety.
Miller, Douglas R.↗
Towards a State Based Control Architecture for Large Telescopes: Laying a Foundation at the VLT
Large telescopes are characterized by a high level of distribution of control-related tasks and will feature diverse data flow patterns and large ranges of sampling frequencies; there will often be no single, fixed server-client relationship between the control tasks. the architecture is also challenged by the task of integrating heterogeneous subsystems which will be delivered by multiple different contractors. Due to the high number of distributed components, the control system needs to effectively detect errors and faults, impede their propagation, and accurately mitigate them in the shortest time possible, enabling the service to be restored. The presented Data-Driven Architecture is based on a decentralized approach with an end-to-end integration of disparate, independently developed software components. These components employ a high-performance standards-based communication middle-ware infrastructure, based on the Data Distribution Service. A set of rules and principles, based on JPL's State Analysis method and architecture, are use to constrain component-to component interactions, where the Control System and System Under Control are clearly separated. State Analysis provide a model-based process for capturing system and software requirements and design, greatly reducing the gap between the requirements on software specified by systems engineers and the implementation by software engineers. The method and architecture has been field tested at the Very Large Telescope, where it has been integrated into an operational system.
European Extremely Large Telescope (E-ELT)↗
Training, Quality Assurance Factors, and Tools Investigation: a Work Report and Suggestions on Software Quality Assurance
Previously, several research tasks have been conducted, some observations were obtained, and several possible suggestions have been contemplated involving software quality assurance engineering at NASA Johnson. These research tasks are briefly described. Also, a brief discussion is given on the role of software quality assurance in software engineering along with some observations and suggestions. A brief discussion on a training program for software quality assurance engineers is provided. A list of assurance factors as well as quality factors are also included. Finally, a process model which can be used for searching and collecting software quality assurance tools is presented.
Lee, Pen-Nan↗
Marshall Space Flight Center Ground Systems Development and Integration
Ground Systems Development and Integration performs a variety of tasks in support of the Mission Operations Laboratory (MOL) and other Center and Agency projects. These tasks include various systems engineering processes such as performing system requirements development, system architecture design, integration, verification and validation, software development, and sustaining engineering of mission operations systems that has evolved the Huntsville Operations Support Center (HOSC) into a leader in remote operations for current and future NASA space projects. The group is also responsible for developing and managing telemetry and command configuration and calibration databases. Personnel are responsible for maintaining and enhancing their disciplinary skills in the areas of project management, software engineering, software development, software process improvement, telecommunications, networking, and systems management. Domain expertise in the ground systems area is also maintained and includes detailed proficiency in the areas of real-time telemetry systems, command systems, voice, video, data networks, and mission planning systems.
Wade, Gina↗
Implementing Software Safety in the NASA Environment
Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system.
Wetherholt, Martha S.↗
Myths and realities: Defining re-engineering for a large organization
This paper describes the background and results of three studies concerning software reverse engineering, re-engineering, and reuse (R3) hosted by the Internal Revenue Service in 1991 and 1992. The situation at the Internal Revenue--aging, piecemeal computer systems and outdated technology maintained by a large staff--is familiar to many institutions, especially among management information systems. The IRS is distinctive for the sheer magnitude and diversity of its problems; the country's tax records are processed using assembly language and COBOL and spread across tape and network DBMS files. How do we proceed with replacing legacy systems? The three software re-engineering studies looked at methods, CASE tool support, and performed a prototype project using re-engineering methods and tools. During the course of these projects, we discovered critical issues broader than the mechanical definitions of methods and tool technology.
Yin, Sandra↗