Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Requirements”

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 1,801 records · Page 100

Software reengineering

Programs in use today generally have all of the function and information processing capabilities required to do their specified job. However, older programs usually use obsolete technology, are not integrated properly with other programs, and are difficult to maintain. Reengineering is becoming a prominent discipline as organizations try to move their systems to more modern and maintainable technologies. The Johnson Space Center (JSC) Software Technology Branch (STB) is researching and developing a system to support reengineering older FORTRAN programs into more maintainable forms that can also be more readily translated to a modern languages such as FORTRAN 8x, Ada, or C. This activity has led to the development of maintenance strategies for design recovery and reengineering. These strategies include a set of standards, methodologies, and the concepts for a software environment to support design recovery and reengineering. A brief description of the problem being addressed and the approach that is being taken by the STB toward providing an economic solution to the problem is provided. A statement of the maintenance problems, the benefits and drawbacks of three alternative solutions, and a brief history of the STB experience in software reengineering are followed by the STB new FORTRAN standards, methodology, and the concepts for a software environment.

Fridge, Ernest M., III↗

Development and Demonstration of an Ada Test Generation System

In this project we have built a prototype system that performs Feasible Path Analysis on Ada programs: given a description of a set of control flow paths through a procedure, and a predicate at a program point feasible path analysis determines if there is input data which causes execution to flow down some path in the collection reaching the point so that tile predicate is true. Feasible path analysis can be applied to program testing, program slicing, array bounds checking, and other forms of anomaly checking. FPA is central to most applications of program analysis. But, because this problem is formally unsolvable, syntactic-based approximations are used in its place. For example, in dead-code analysis the problem is to determine if there are any input values which cause execution to reach a specified program point. Instead an approximation to this problem is computed: determine whether there is a control flow path from the start of the program to the point. This syntactic approximation is efficiently computable and conservative: if there is no such path the program point is clearly unreachable, but if there is such a path, the analysis is inconclusive, and the code is assumed to be live. Such conservative analysis too often yields unsatisfactory results because the approximation is too weak. As another example, consider data flow analysis. A du-pair is a pair of program points such that the first point is a definition of a variable and the second point a use and for which there exists a definition-free path from the definition to the use. The sharper, semantic definition of a du-pair requires that there be a feasible definition-free path from the definition to the use. A compiler using du-pairs for detecting dead variables may miss optimizations by not considering feasibility. Similarly, a program analyzer computing program slices to merge parallel versions may report conflicts where none exist. In the context of software testing, feasibility analysis plays an important role in identifying testing requirements which are infeasible. This is especially true for data flow testing and modified condition/decision coverage. Our system uses in an essential way symbolic analysis and theorem proving technology, and we believe this work represents one of the few successful uses of a theorem prover working in a completely automatic fashion to solve a problem of practical interest. We believe this work anticipates an important trend away from purely syntactic-based methods for program analysis to semantic methods based on symbolic processing and inference technology. Other results demonstrating the practical use of automatic inference is being reported in hardware verification, although there are significant differences between the hardware work and ours. However, what is common and important is that general purpose theorem provers are being integrated with more special-purpose decision procedures to solve problems in analysis and verification. We are pursuina commercial opportunities for this work, and will use and extend the work in other projects we are engaged in. Ultimately we would like to rework the system to analyze C, C++, or Java as a key step toward commercialization.

Source record↗

GOES-I/M ascent maneuvers from transfer orbit to station

The Geostationary Operational Environmental Satellite (GOES)-I/M station acquisition sequence consists nominally of three in-plane/out-of-plane maneuvers at apogee on the line of relative nodes and a small in-plane maneuver at perigee. Existing software to determine maneuver attitude, ignition time, and burn duration required modification to optimize the out-of-plane parts and admit the noninertial, three-axis stabilized attitude. The Modified Multiple Impulse Station Acquisition Maneuver Planning Program (SENARIO2) was developed from its predecessor, SCENARIO, to optimize the out-of-plane components of the impulsive delta-V vectors. Additional new features include commputation of short term J sub 2 perturbations and output of all premaneuver and postmaneuver orbit elements, coarse maneuver attitudes, propellant usage, spacecraft antenna aspect angles, and ground station coverage. The output data are intended to be used in the launch window computation and by the maneuver targeting computation (General Maneuver (GMAN) Program) software. The maneuver targeting computation in GMAN was modified to admit the GOES-I/M maneuver attitude. Appropriate combinations of ignition time, burn duration, and attitude enable any reasonable target orbit to be achieved.

Abeyagunawardene, S.↗

Towards real-time simulation of large space structures: Stabilization of fluid/thermal/structure interactions and implementation on high performance supercomputers

Within the Center for Space Construction, the SIMSTRUC project's objectives center around the development of simulation tools for the realistic analysis of large space structures. The word 'tools' is the broad sense; it designates mathematical models, finite element/finite difference formulations, computational algorithms, implementations on advanced computer architectures, and visualization capabilities. The results of our activities during the first year within the SIMSTRUC project are reported. On the modeling side, an alternative approach to fluid/thermal/structure interaction analysis that is a departure from the 'loosely coupled' and 'unified' approaches that are being currently practiced are described. The advantages of our approach both in terms of accuracy and computational efficiency were demonstrated. On the computational side, a software architecture for parallel/vector and massively parallel supercomputers that speeds up finite element and finite difference computations by several orders of magnitude is presented. As an example, the simulation of the deployment of a space structure that used to require over six hours of a workstation using a conventional finite element software, now runs on a multiprocessor using a parallel computation strategy in less than three seconds. In order to promote the physical understanding of the simulation behavior, a real-time visualization capability on the Connection Machine, which allows the analyst to watch the graphical animation of the results at the same time these are generated, was also developed. It is believed that by combining efficient analytical formulations with the state-of-the-art high performance computer implementations and superfast visualization capabilities, SIMSTRUC is moving fast towards the real-time simulation of large space structures. The designers as well as the researchers will certainly benefit from this technology.

Farhat, C.↗

Autonomous Medical Officer Support (AMOS) Software Technology Demonstrations on the International Space Station (ISS)

Performance of medical procedures in spaceflight beyond low Earth orbit (LEO) requires novel solutions to replace real-time ground support because as distance from Earth increases, communication latencies increase, hampering remote guidance. The Autonomous Medical Officer Support Software (AMOS) Technology Demonstrations on the International Space Station (ISS) trialed a novel software tool that shifts the emphasis from preflight training and real-time remote guidance (current ISS paradigm) to a new standard of multi-dimensional in-flight just-in-time (JIT) instruction. The AMOS platform is a skill management tool for all mission phases and currently features comprehensive training and guidance modules for urinary bladder and renal ultrasound examinations. Variability in Subject anatomy, Operator experience, and Operator receptiveness to instruction during autonomous exams are persistent but manageable limitations. Here we report the first successful demonstrations of autonomous imaging activities in the operational setting of spaceflight, validating this autonomous guidance proof of concept.

Douglas Ebert↗

Monitoring ICAROUS: From Requirements to Autonomous Flight

The Independent Configurable Architecture for Reliable Operations of Unmanned Systems (ICAROUS) is a software architecture incorporating a set of algorithms to enable autonomous operations of unmanned aircraft applications. This paper provides an overview of Monitoring ICAROUS, a project whose objective is to provide a formal approach to generating runtime monitors for autonomous systems from requirements written in a structured natural language. This approach integrates FRET, a formal requirement elicitation and authoring tool, and Copilot, a runtime verification framework. FRET is used to specify formal requirements in structured natural language. These requirements are translated into temporal logic formulae. Copilot is then used to generate executable runtime monitors from these temporal logic specifications. The generated monitors are directly integrated into ICAROUS to perform runtime verification during flight.

Formal Methods↗

Usable Translational Hand Controllers for NASA's Habitability Design Center

This summer I was given the opportunity to work at the Habitability Design Center (HDC). NASA Johnson Space Center's HDC is currently developing Cislunar and Mars spacecraft mockups. I contributed to this effort by designing from scratch low cost, functional translational hand controllers (THCs) that will be used in spacecraft mission simulation in low to medium fidelity exploration spacecraft mockups. This project fell under the category of mechatronics, a combination of mechanical, electrical, and computer engineering. Being an aerospace engineering student, I was out of my comfort zone. And that was a wonderful thing. The autonomy that my mentor, Dr. Robert Howard, allowed me gave me the opportunity to learn by trying, failing, and trying again. This project was not only a professional success for me, but a significant learning experience. I appreciated the freedom that I had to take the time to learn new things for myself rather than blindly follow instructions. I was the sole person working on this project, and was required to work independently to solve the many hardware and software challenges that the project entailed. I researched THCs that have been used on the ISS, the Space Shuttle, and the Orion MPVC and based my design off of these. I worked through many redesigns before finding an optimal configuration of the necessary mechanisms and electrical components for the THC. Once I had a functional hardware design, I dove into the challenge of getting an Arduino Uno, an extremely low cost and easily programmable microcontroller, to behave as a human interface device. The THCs I built needed to be able to integrate to a mission simulation designed by NASA's Graphics and Visualization Lab. This proved to be the most challenging aspect of the project. To accomplish this I learned how to change the firmware of the USB serial converter microcontroller. The process was very complicated as it involved multiple software programs and manual flashing of pins on the Arduino itself. When I successfully achieved the goal I wrote an instructions manual for the process so that the HDC will be able to do this easily in the future for any human interface device they may want to create. I also created a detailed CAD model of my THC design with construction instructions. My THC utilizes three ultrasonic sensors, one for each axis of motion. I wrote a code that stimulates these sensors continuously and feeds back values from each axis ranging from -%100 to %100 of the min/max position in relation to the neutral position of each axis. This was the data that the Graphics and Visualization Lab required to interface with their simulation. I truly enjoyed working in the HDC surrounded by passionate, proactive, and brilliantly creative people. I felt valued and respected as a part of their team. I was given the time and support of my mentor whenever I asked for it. Beyond my positive project experience, I was fortunate enough to be able to take advantage of many of the extra activities that JSC has to offer. I took Russian Phase One during my lunch break every day and can now read Russian and accomplish basic verbal communication. I was heavily involved with the co-tern music video, which led to numerous incredible experiences and friendships. I saw every facility, attended every lecture, and met everyone that I could. I had coffee with Lauri Hansen. I played on an intern volleyball team at the Gilruth. I traveled to Michoud, Stennis, NOLA, and Big Bend National Park. I had the time of my life and I fell in love with JSC. In the next month I will return to Maryland and start my senior year of my undergraduate degree. As I work through it I will remember that all of the studying I do, all of the concentration I give, and all of the sacrifices that I make for school are so that I can work at a place like JSC where I am proud and excited to go into work every day. This internship was an invaluable experience for me, both professionally and personally.

Westbrook, Kimberly↗

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗

Composite Analysis Solid Waste Release Data Reduction of Activity Flux from Waste Sites to the Vadose Zone for Baseline Assessment

This environmental calculation file (ECF) describes the data reduction methodology for the solid waste release datasets generated by the Composite Analysis Solid Waste Release (CASWR) model (CP-62766, Model Package Report: Composite Analysis Solid Waste Release Model [CASWR Model]) and documents the resulting reduced datasets for the updated Composite Analysis (CA) baseline assessment. This ECF is in support of the updated Hanford Site CA. The purpose of the updated Hanford Site CA is to provide an estimate of the cumulative radiological impacts from active and planned low-level radioactive waste disposals and other potentially interacting radioactive waste disposal sources that will remain following Hanford Site closure. The vadose zone modeling activities associated with the CA includes solid waste forms as contaminant sources. To support the modeling of solid waste transport from the vadose zone to the groundwater at the Hanford Site, the CASWR model was designed to generate deterministic radionuclide release rates for the Hanford Site Central Plateau solid waste disposal sites. The complete CASWR model-generated dataset for the CA Baseline Assessment consists of 2,378,831 sets of time and release rates (1,073,869 sets for the 200 East Area and 1,304,962 sets for the 200 West Area), representing a course of the simulation from year 1953 to year 12,069, 16 radiological contaminants of potential concern (COPCs), and 237 solid waste sources as documented in ECFHANFORD- 19-0112, Solid Waste Release Calculations for the Composite Analysis Baseline Assessment. For several of the STOMP vadose zone models, the number of release rate data pairs required for release at all waste sites would exceed the limitations imposed by the STOMP modelling software package used to simulate contaminant transport through the vadose zone. As a result, a data reduction of the CASWR dataset is required prior to its use as a source input for the CA vadose zone modeling activities.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

Leading Edge Software Support

The purpose of this paper is an attempt to get the reader to recognize that different requirements that are surfacing and to be proactive in achieving successful support of these systems. This paper will identify areas of concern and present some areas of focus applicable to the development and support of software intensive systems.

Baylis, William T.↗

Development and use of the computer software package for planning the 12 GHz broadcasting-satellite service at RARC '83

The 1983 Regional Administrative Radio Conference (RARC '83) had mainly the objective to draw up a plan of detailed frequency assignments and orbital positions for the 12 GHz broadcasting-satellite service (BSS) in ITU Region 2 (the Western Hemisphere) and associated feeder links (earth-to-space) in the 17 GHz band. It was found that for RARC '83 new planning methods and procedures would be needed. The new requirements made it necessary to develop a new generation of planning software. Attention is given to the development of the computer programs to be used at the conference, the package of computer programs, and the use of the computer programs.

Bowen, R. R.↗

Leveraging object-oriented development at Ames

This paper presents lessons learned by the Software Engineering Process Group (SEPG) from results of supporting two projects at NASA Ames using an Object Oriented Rapid Prototyping (OORP) approach supported by a full featured visual development environment. Supplemental lessons learned from a large project in progress and a requirements definition are also incorporated. The paper demonstrates how productivity gains can be made by leveraging the developer with a rich development environment, correct and early requirements definition using rapid prototyping, and earlier and better effort estimation and software sizing through object-oriented methods and metrics. Although the individual elements of OO methods, RP approach and OO metrics had been used on other separate projects, the reported projects were the first integrated usage supported by a rich development environment. Overall the approach used was twice as productive (measured by hours per OO Unit) as a C++ development.

Wenneson, Greg↗

MARVEL 90% Final Design Report

This document provides documentation of the Microreactor Applications Research Validation and Evaluation Project’s (MARVEL) 90% Final Design, as required by U.S. Department of Energy (DOE) Standard-1189, “Integration of Safety into the Design Process." Per DOE-STD-1189-2016, the 90% Final Design documentation focuses on design completion, at a level capable of supporting procurement, construction, testing, and operation. At this phase, the design organization finalizes the hazards and accident analyses, Fire Hazard Analysis (FHA), security vulnerability assessments, and other supporting analyses for design completion. The objective of this report is to provide a high-level summary of the design thus far and provide references including, but not limited to, the following design deliverables: • Complete final drawings, specifications and commercial grade dedications that may be released for bid and/or construction. • Clearly defined testing plans for the safety and functionality of all subsystems. • Quality Assurance Program for Design, Testing and Procurement. • Software Quality Assurance Plan. • Code of Record (COR), applicable design requirements including codes and standards. • Final design that meets all the requirements stipulated in the COR. • Final design review, consisting of final validation of comment resolution from previous reviews, and a review of any additional developments since the last review. • Updated Safety Design Strategy. • Hazard Analysis. • Fire Hazard Analysis. • Accident analysis. • Security vulnerability assessment. • Current and detailed cost estimate. • Current construction schedule, and • Risk & Opportunities Assessment.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

Commonality Study of the Pressure-Volume-Temperature Based Propellant Gaging Software Modules for the Auxiliary Power Unit, Reaction Control System, and Orbital Maneuvering System

Computer storage requirements can be reduced if areas of commonality exist in two or more programs placed in the same computer and identical code can be used by more than one program. The pressure-volume-temperature (P-V-T) relationship for the propellant tank pressurant agent is utilized as the basis for either a primary of a backup propellant gaging program for the auxiliary power unit (APU), the reaction control system (RCS), and the orbital maneuvering system (OMS). These three propellant gaging programs were investigated. It was revealed that a very limited degree of software commonality exits among them. An examination of this common software indicated that only the computation of the helium compressibility factor in an external function subprogram accessible to both the RCS and OMS propellant gaging programs appears to offer a savings in computer storage requirements.

Duhon, D. D.↗

Introduction to LANMAS and LAMCAS, Course #50061 [Slides]

This course is designed to offer a detailed introduction to the LAMCAS program, and the software tools used to support the Nuclear Material Control and Accountability (NMC&A) mission. The course covers the importance of NMC&A in LANL's operations, as well as its significance on a national and global scale. Completion of this course is required before an employee can access the inquiry features of the LAMCAS software.

97 MATHEMATICS AND COMPUTING↗

Viking Navigation: Introduction

The design, control, and reconstruction of the flight paths of all four Viking vehicles is presented. The specification of requirements on the flight hardware is described along with the navigation strategies, procedures, operational software, and the inflight navigation. Features of the Viking navigation discussed include the precise determination of the spacecraft trajectories, prediction of the trajectories, design of the propulsive maneuvers required to effect the necessary trajectory changes, and calculation of the Lander descent guidance parameters.

Oneil, W. J.↗

R2U2 in Space: System and Software Health Management for Small Satellites

In order for small but complex systems like rovers, SmallSats, or Unmanned Aircraft (UAS) to operate autonomously, they must have a real-time solution for assessing their own system health. System and Software Health Management (SHM) enables better detection of faulty sensors and software problems, and enables better fault management including mitigation of unpredicted fault scenarios in the absence of a human on-board. In recent work, we have developed a Responsive, Realizable, Unobtrusive Unit (R2U2) for on-board SHM of autonomous UAS and demonstrated its ability to detect faults during flight time. These faults, from sensor failures, to software problems, to malicious security attacks, can present as transient temporal faults that even humans are challenged to find. An R2U2 congfiuration is a modular combination of multiple types of temporal logic runtime observers with fault-specic Bayesian Nets and sensor filters. R2U2 reasons about both on-board hardware and software components; R2U2 itself can be instantiated as an independent FPGA (Field-Programmable Gate Array)-based conguration or as a software component running independently from other software on-board. Small satellites, such as CubeSats, also require on-board SHM and failure mitigation, as limited telemetry bandwidth does not allow the transmission of the entire system state for ground-based health management. However, the autonomous operation of satellites brings a set of challenges different from UAS, including the effects of radiation on non-rad-hard, low-cost components, and the harsher environment of space. We surmise that a new extension of R2U2 could be adapted to help better detect, for example, radiation errors in cheaper COTS (Commercial Off the Shelf) (not rad-hard) components often used in small space systems. Since small satellites often operate in coordination, we will also examine new ways of distributed monitoring of their communication and cooperation and real-time detection of off-nominal situations utilizing multiple satellites. This talk will discuss preliminary work and ideas for building on terrestrial success of system and software health management for the harsher, and differently challenging, environment of space.

Runtime Verification & Validation↗

Thermal balance testing of the Anik-E spacecraft

Spar Aerospace, Ltd. of Canada has recently completed the first of two infrared thermal balance/thermal vacuum tests on Canada's next generation of telecommunication satellites: Anik-E. Anik-E is a two spacecraft program using a three axis stabilized GE 5000 series bus as the vehicle for its payload. The infrared test setup consists of the mechanical hardware required to support the spacecraft within the thermal vacuum chamber and the infrared rig which supports the spacecraft. Spar developed a software package which calculated the lamp positions to provide the necessary uniform heat flux, based on the required heat inputs on the various isothermal zones of the spacecraft for the different phases of the tests. Infrared heat sensors, radiometers, were installed on the spacecraft surfaces. These were connected to the facility data processing system and continually monitored the flux absorbed by the various spacecraft surfaces. The test set up had distinct advantages. It enabled testing to progress directly from the thermal balance to thermal vacuum. Waveguide runs were installed for the communications portion of the testing prior to pumpdown. This precluded the requirement to return to ambient to reconfigure the setup.

Golob, Alex↗

Refine your search to explore more results.