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 577 records · Page 32

Ground Processing of Data From the Mars Exploration Rovers

A computer program implements the Earth side of the protocol that governs the transfer of data files generated by the Mars Exploration Rovers. It also provides tools for viewing data in these files and integrating data-product files into automated and manual processes. It reconstitutes files from telemetry data packets. Even if only one packet is received, metadata provide enough information to enable this program to identify and use partial data products. This software can generate commands to acknowledge received files and retransmit missed parts of files, or it can feed a manual process to make decisions about retransmission. The software uses an Extensible Markup Language (XML) data dictionary to provide a generic capability for displaying files of basic types, and uses external "plug-in" application programs to provide more sophisticated displays. This program makes data products available with very low latency, and can trigger automated actions when complete or partial products are received. The software is easy to install and use. The only system requirement for installing the software is a Java J2SE 1.4 platform. Several instances of the software can be executed simultaneously on the same machine.

Wright, Jesse↗

Advanced Diagnostic and Prognostic Testbed (ADAPT) Testability Analysis Report

As system designs become more complex, determining the best locations to add sensors and test points for the purpose of testing and monitoring these designs becomes more difficult. Not only must the designer take into consideration all real and potential faults of the system, he or she must also find efficient ways of detecting and isolating those faults. Because sensors and cabling take up valuable space and weight on a system, and given constraints on bandwidth and power, it is even more difficult to add sensors into these complex designs after the design has been completed. As a result, a number of software tools have been developed to assist the system designer in proper placement of these sensors during the system design phase of a project. One of the key functions provided by many of these software programs is a testability analysis of the system essentially an evaluation of how observable the system behavior is using available tests. During the design phase, testability metrics can help guide the designer in improving the inherent testability of the design. This may include adding, removing, or modifying tests; breaking up feedback loops, or changing the system to reduce fault propagation. Given a set of test requirements, the analysis can also help to verify that the system will meet those requirements. Of course, a testability analysis requires that a software model of the physical system is available. For the analysis to be most effective in guiding system design, this model should ideally be constructed in parallel with these efforts. The purpose of this paper is to present the final testability results of the Advanced Diagnostic and Prognostic Testbed (ADAPT) after the system model was completed. The tool chosen to build the model and to perform the testability analysis with is the Testability Engineering and Maintenance System Designer (TEAMS-Designer). The TEAMS toolset is intended to be a solution to span all phases of the system, from design and development through health management and maintenance. TEAMS-Designer is the model-building and testability analysis software in that suite.

Ossenfort, John↗

Formal methods and their role in digital systems validation for airborne systems

This report is based on one prepared as a chapter for the FAA Digital Systems Validation Handbook (a guide to assist FAA certification specialists with advanced technology issues). Its purpose is to explain the use of formal methods in the specification and verification of software and hardware requirements, designs, and implementations; to identify the benefits, weaknesses, and difficulties in applying these methods to digital systems used in critical applications; and to suggest factors for consideration when formal methods are offered in support of certification. The presentation concentrates on the rationale for formal methods and on their contribution to assurance for critical applications within a context such as that provided by DO-178B (the guidelines for software used on board civil aircraft); it is intended as an introduction for those to whom these topics are new.

Rushby, John↗

Blackbird: Object-Oriented Planning, Simulation, and Sequencing Framework Used by Multiple Missions

Every JPL flight mission relies on activity planningand sequence generation software to perform operations. Mostsuch tools in use at JPL and elsewhere use attribute-basedschemas or domain-specific languages (DSLs) to defineactivities. This reliance poses user training, softwaremaintenance, performance, and other challenges. To solve thisproblem for future missions, a new software called Blackbirdwas developed which allows engineers to specify behavior instandard Java. The new code base has over an order ofmagnitude fewer lines of code than other JPL planningsoftware, since no DSL or schema interpreter is needed. Theuse of Java for defining activities also allows mission adaptersto debug their code in an integrated development environment,seamlessly call external libraries, and set up truly multimissionmodels. These efficiency gains have significantlyreduced the amount of development effort required to supportthe software. This paper discusses Blackbird’s design,principles, and use cases.

Rothstein-Dowden, Ansel↗

International Low Impact Docking System (iLIDS) Project Technical Requirements Specification, Revision F

The NASA Docking System (NDS) is NASA's implementation for the emerging International Docking System Standard (IDSS) using low impact docking technology. The NASA Docking System Project (NDSP) is the International Space Station (ISS) Program's project to produce the NDS, Common Docking Adapter (CDA) and Docking Hub. The NDS design evolved from the Low Impact Docking System (LIDS). The acronym international Low Impact Docking System (iLIDS) is also used to describe this system as well as the Government Furnished Equipment (GFE) project designing the NDS for the NDSP. NDS and iLIDS may be used interchangeability. This document will use the acronym iLIDS. Some of the heritage documentation and implementations (e.g., software command names, requirement identification (ID), figures, etc.) used on NDS will continue to use the LIDS acronym. This specification defines the technical requirements for the iLIDS GFE delivered to the NDSP by the iLIDS project. This document contains requirements for two iLIDS configurations, SEZ29101800-301 and SEZ29101800-302. Requirements with the statement, iLIDS shall, are for all configurations. Examples of requirements that are unique to a single configuration may be identified as iLIDS (-301) shall or iLIDS (-302) shall. Furthermore, to allow a requirement to encompass all configurations with an exception, the requirement may be designated as iLIDS (excluding -302) shall. Verification requirements for the iLIDS project are identified in the Verification Matrix (VM) provided in the iLIDS Verification and Validation Document, JSC-63966. The following definitions differentiate between requirements and other statements: Shall: This is the only verb used for the binding requirements. Should/May: These verbs are used for stating non-mandatory goals. Will: This verb is used for stating facts or declaration of purpose. A Definition of Terms table is provided in Appendix B to define those terms with specific tailored uses in this document.

Lewis, James L.↗

Web Based Tool for Mission Operations Scenarios

A conventional practice for spaceflight projects is to document scenarios in a monolithic Operations Concept document. Such documents can be hundreds of pages long and may require laborious updates. Software development practice utilizes scenarios in the form of smaller, individual use cases, which are often structured and managed using UML. We have developed a process and a web-based scenario tool that utilizes a similar philosophy of smaller, more compact scenarios (but avoids the formality of UML). The need for a scenario process and tool became apparent during the authors' work on a large astrophysics mission. It was noted that every phase of the Mission (e.g., formulation, design, verification and validation, and operations) looked back to scenarios to assess completeness of requirements and design. It was also noted that terminology needed to be clarified and structured to assure communication across all levels of the project. Attempts to manage, communicate, and evolve scenarios at all levels of a project using conventional tools (e.g., Excel) and methods (Scenario Working Group meetings) were not effective given limitations on budget and staffing. The objective of this paper is to document the scenario process and tool created to offer projects a low-cost capability to create, communicate, manage, and evolve scenarios throughout project development. The process and tool have the further benefit of allowing the association of requirements with particular scenarios, establishing and viewing relationships between higher- and lower-level scenarios, and the ability to place all scenarios in a shared context. The resulting structured set of scenarios is widely visible (using a web browser), easily updated, and can be searched according to various criteria including the level (e.g., Project, System, and Team) and Mission Phase. Scenarios are maintained in a web-accessible environment that provides a structured set of scenario fields and allows for maximum visibility across the project. One key aspect is that the tool was built for a scenario process that accounts for stakeholder input, review, comment, and concurrence. By creating well-designed opportunities for stakeholder input and concurrence and by making the scenario content easily accessible to all project personnel, we maximize the opportunities for stakeholders to both understand and agree on the concepts for how their mission is to be carried out.

Boyles, Carole A.↗

Formalizing and Analyzing Requirements with FRET

Formal verification and simulation are powerful tools to validate requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically written in ambiguous natural language. There is a gap between such requirements and formal notations that can be used by verification tools, and lack of support for proper association of requirements with software artifacts for verification. We propose to write requirements in an intuitive, structured natural language with formal semantics, and to support formalization and model/code verification as a smooth, well-integrated process. To this end, we have developed an end-to-end, open source requirements analysis framework that checks Simulink models against requirements written structured natural language.

Mavridou, Anastasia↗

Communication Problems in Requirements Engineering: A Field Study

The requirements engineering phase of software development projects is characterized by the intensity and importance of communication activities. During this phase, the various stakeholders must be able to communicate their requirements to the analysts, and the analysts need to be able to communicate the specifications they generate back to the stakeholders for validation. This paper describes a field investigation into the problems of communication between disparate communities involved in the requirements specification activities. The results of this study are discussed in terms of their relation to three major communication barriers: (1) ineffectiveness of the current communication channels; (2) restrictions on expressiveness imposed by notations; and (3) social and organizational barriers. The results confirm that organizational and social issues have great influence on the effectiveness of communication. They also show that in general, end-users find the notations used by software practitioners to model their requirements difficult to understand and validate.

Al-Rawas, Amer↗

Orion Touchdown Heading Control

At touchdown Orion must be aligned so that the crew person's feet are forward in the direction of the horizontal velocity. To ensure that this requirement is met active heading control is being implemented on the Orion crew module. This technique reduces probability of roll-over during splashdown, assures axial loads on the crew at touchdown, and alleviates structural requirements on impact allowing for a light-weight structural design. On-board sensors are used to measure current vehicle orientation and horizontal velocity used in generation of the heading error signal. Linear velocity measured by the IMU drifts while under parachutes due to wind gusts and has to be corrected by GPS; this makes GPS critical for successful landing. Jet fire logic is achieved by use of a phase-plane and commands are realized by using roll jets from the reaction control system (RCS); using pre existing hardware eliminates additional hardware and structural requirements. Touchdown performance is measured by an orientation envelope that was co-developed with structures so that the performance requirements overlap adding system redundancy. Heading control also introduces new difficulties to be addressed such as parachute line twist torque as well as increasing vehicle sensitivity to wind shifts and sea states. Solving these difficulties requires added complexity to flight software as well as increasing the propellant required to achieve successful touchdown. while offering promising results, the criticality of GPS along with a significant propellant cost raises questions on the effectiveness of using touchdown heading control.

Kane, Mark A.↗

Partial Automation of Requirements Tracing

Requirements Tracing on Target (RETRO) is software for after-the-fact tracing of textual requirements to support independent verification and validation of software. RETRO applies one of three user-selectable information-retrieval techniques: (1) term frequency/inverse document frequency (TF/IDF) vector retrieval, (2) TF/IDF vector retrieval with simple thesaurus, or (3) keyword extraction. One component of RETRO is the graphical user interface (GUI) for use in initiating a requirements-tracing project (a pair of artifacts to be traced to each other, such as a requirements spec and a design spec). Once the artifacts have been specified and the IR technique chosen, another component constructs a representation of the artifact elements and stores it on disk. Next, the IR technique is used to produce a first list of candidate links (potential matches between the two artifact levels). This list, encoded in Extensible Markup Language (XML), is optionally processed by a filtering component designed to make the list somewhat smaller without sacrificing accuracy. Through the GUI, the user examines a number of links and returns decisions (yes, these are links; no, these are not links). Coded in XML, these decisions are provided to a "feedback processor" component that prepares the data for the next application of the IR technique. The feedback reduces the incidence of erroneous candidate links. Unlike related prior software, RETRO does not require the user to assign keywords, and automatically builds a document index.

Hayes, Jane↗

Automatic Synthesis of UML Designs from Requirements in an Iterative Process

The Unified Modeling Language (UML) is gaining wide popularity for the design of object-oriented systems. UML combines various object-oriented graphical design notations under one common framework. A major factor for the broad acceptance of UML is that it can be conveniently used in a highly iterative, Use Case (or scenario-based) process (although the process is not a part of UML). Here, the (pre-) requirements for the software are specified rather informally as Use Cases and a set of scenarios. A scenario can be seen as an individual trace of a software artifact. Besides first sketches of a class diagram to illustrate the static system breakdown, scenarios are a favorite way of communication with the customer, because scenarios describe concrete interactions between entities and are thus easy to understand. Scenarios with a high level of detail are often expressed as sequence diagrams. Later in the design and implementation stage (elaboration and implementation phases), a design of the system's behavior is often developed as a set of statecharts. From there (and the full-fledged class diagram), actual code development is started. Current commercial UML tools support this phase by providing code generators for class diagrams and statecharts. In practice, it can be observed that the transition from requirements to design to code is a highly iterative process. In this talk, a set of algorithms is presented which perform reasonable synthesis and transformations between different UML notations (sequence diagrams, Object Constraint Language (OCL) constraints, statecharts). More specifically, we will discuss the following transformations: Statechart synthesis, introduction of hierarchy, consistency of modifications, and "design-debugging".

Schumann, Johann↗

An Architecture to Enable Autonomous Control of Spacecraft

Autonomy is required for manned spacecraft missions distant enough that light-time communication delays make ground-based mission control infeasible. Presently, ground controllers develop a complete schedule of power modes for all spacecraft components based on a large number of factors. The proposed architecture is an early attempt to formalize and automate this process using on-vehicle computation resources. In order to demonstrate this architecture, an autonomous electrical power system controller and vehicle Mission Manager are constructed. These two components are designed to work together in order to plan upcoming load use as well as respond to unanticipated deviations from the plan. The communication protocol was developed using "paper" simulations prior to formally encoding the messages and developing software to implement the required functionality. These software routines exchange data via TCP/IP sockets with the Mission Manager operating at NASA Ames Research Center and the autonomous power controller running at NASA Glenn Research Center. The interconnected systems are tested and shown to be effective at planning the operation of a simulated quasi-steady state spacecraft power system and responding to unexpected disturbances.

space power systems↗

Technology requirements for advanced earth orbital transportation system. Volume 1: Executive summary

Normal technology requirements applicable to Single Stage to Orbit (SSTO) systems were projected to the 1985 time period. These technology projections were then incorporated in a vehicle design analysis of three different operational concepts resulting in four configurations of a Single Stage to Orbit system. The resultant performance, weights and costs of each concept were then compared and a system concept selected. A figure of merit was developed for advanced technology programs based on a cost/performance basis. The selected advanced technology programs were then used to reassess the vehicle to determine the impact on performance, weight and cost. Based on study results, recommendations are provided in technology areas associated with earth orbit transportation systems. The recommendations address advanced space transportation system design considerations, both hardware and software technolgoy program requirements.

Hepler, A. K.↗

Feasibility study of an Integrated Program for Aerospace-vehicle Design (IPAD) system. Volume 5: Design of the IPAD system. Part 2: System design. Part 3: General purpose utilities, phase 1, task 2

Viable designs are presented of various elements of the IPAD framework software, data base management system, and required new languages in relation to the capabilities of operating systems software. A thorough evaluation was made of the basic systems functions to be provide by each software element, its requirements defined in the conceptual design, the operating systems features affecting its design, and the engineering/design functions which it was intended to enhance.

Garrocq, C. A.↗

Computers for symbolic processing

A detailed survey on the motivations, design, applications, current status, and limitations of computers designed for symbolic processing is provided. Symbolic processing computations are performed at the word, relation, or meaning levels, and the knowledge used in symbolic applications may be fuzzy, uncertain, indeterminate, and ill represented. Various techniques for knowledge representation and processing are discussed from both the designers' and users' points of view. The design and choice of a suitable language for symbolic processing and the mapping of applications into a software architecture are then considered. The process of refining the application requirements into hardware and software architectures is treated, and state-of-the-art sequential and parallel computers designed for symbolic processing are discussed.

Wah, Benjamin W.↗

Scheduling System Assessment, and Development and Enhancement of Re-engineered Version of GPSS

The objective of this project is two-fold. First to provide an evaluation of a commercially developed version of the ground processing scheduling system (GPSS) for its applicability to the Kennedy Space Center (KSC) ground processing problem. Second, to work with the KSC GPSS development team and provide enhancement to the existing software. Systems reengineering is required to provide a sustainable system for the users and the software maintenance group. Using the LISP profile prototype code developed by the GPSS reverse reengineering groups as a building block, we have implemented the resource deconfliction portion of GPSS in common LISP using its object oriented features. The prototype corrects and extends some of the deficiencies of the current production version, plus it uses and builds on the classes from the development team's profile prototype.

Loganantharaj, Rasiah↗

In-Situ Reaction Monitoring for Lunar Applications Utilizing a Single Quadrupole Residual Gas Analyzer

With a revived focus to create a permeant presence on the moon and in preparation for future Mars exploration, it is imperative that all re-sources are utilized to their fullest potential. In-Situ Resource Utilization (ISRU) will be critical for future mission success as it would enable independent operation of missions while minimally relying on the complex supply chain created between the Earth, moon and Mars. One of the most critical resources that have been identified for ISRU is the creation of liquid oxygen (O2) for not only breathable air, but also for rocket fuel. On the moon and potentially Mars, one of the most O2 rich resources is in the presence of regolith. Although there are numerous minerals within regolith and various processes to extract O2, this is not the scope of this paper. Since the O2 extraction method can vary, a critical standardized analytical method is needed to verify O2 (or oxygenated precursor compounds) for extraction efficiency and purity. Our group utilizes a modified consumer off-the-shelf (COTS), Residual Gas Analyzer (RGA) Single Quadrupole Mass Spectrometer (QMS). Due to the current field mission requirements, the gas analysis module will need to rely only on mass-to-charge ratios (m/z) and peak intensities to differentiate and quantitate targeted gas-phase reactants or products, i.e. carbon monoxide (CO), carbon dioxide (CO2), methane (CH4) and hydrogen (H2). However, due to solar wind implanted volatiles and various other compounds present in lunar regolith, such as nitrogen (N2), helium (He), and deuterium (D2), deconvolution and quantification of isobaric compounds becomes quite difficult. Specifically, the presence of N2 makes quantification of CO, an oxygenated precursor, difficult due to both compounds having a peak at m/z 28. Approaches to differentiate isobaric components: Initially, the solution to overcome isobaric overlap was to use isotopic ratios, particularly be-tween carbon-13 and nitrogen-15. Although limited literature discuss isotopic composition and attempt to quantify the ratios, variation is particularly high and limited to a few lunar regolith samples. The following were identified as potential approaches to quantify isobaric species, N2 and CO, using our RGA. Threshold Ionization. CO and N2 both have peaks at m/z 28, but only N2 is capable of producing a peak at m/z 7. While a N2 peak at m/z 7 is generally rare, instrument parameters can be optimized in order to maximize the peak intensity. Typically a standard ionization energy of 70 eV is used to monitor a batch process and would produce reliable results for a majority of the reactants or products that we are interested in quantifying. However, to analyze the rare molecular fragment of N2 (N2+ at m/z 7), a different ionization energy may be beneficial. Threshold Ionization Mass Spectrometry (TIMS) will be explored to optimize the N2+ peak at m/z 7 by varying parameters such as ionization energy and pressure. Therefore, a quantitative value at m/z 7 will be used to determine the product gas concentration of N2, which will be subtracted from the total concentration determined at m/z 28 enabling us to approximate the amount of CO. Secondary Detector (infrared gas detector, IR). Another approach to quantitate and differentiate be-tween isobaric components is to leverage alternative modes of detection. Unlike mass spectrometry, which generally uses a separation step prior to analysis (i.e. gas chromatography), IR produces energy that is specifically absorbed depending on the bond and configuration of the molecule. This technique could be leveraged since it is generally only active on non-symmetric molecules, i.e. CO. Utilizing concentrations of CO determined from another detector could help correct concentrations of CO obtained from the QMS. However, the inclusion of another detector adds additional mission requirements, such as power, software changes and avionics updates that add additional cost and schedule requirements.

mass spectrometry↗