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 703 records · Page 39

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↗

The Heavy Photon Search (HPS) Software Environment

The Heavy Photon Search (HPS) is an experiment at the Thomas Jefferson National Accelerator Facility (JLab) designed to search for a hidden sector photon (A’) in fixed-target electro-production. It uses a silicon microstrip tracking and vertexing detector placed inside a dipole magnet to measure charged particle trajectories and a fast lead-tungstate crystal calorimeter located just downstream of the magnet to provide a trigger and to identify electromagnetic showers. The HPS experiment uses both invariant mass and secondary vertex signatures to search for the A’. The experimental collaboration is small and quite heterogeneous: it is composed of members of the nuclear physics as well as particle physics communities, from universities and national labs from around the US and Europe. Enabling such a disparate group to concentrate on the physics aspects of the experiment required that the software be easy to install and use, and having such limited manpower meant that existing solutions had to be exploited. HPS has successfully completed two engineering runs and completed its first physics run in the summer of 2019. We begin with an overview of the physics goals of the experiment followed by a short description of the detector design. We then describe the software tools used to design the detector layout and simulate the expected detector performance. Event reconstruction involving track, cluster and vertex finding and fitting for both simulated and real data was, to first order, adopted from existing software originally developed for Linear Collider studies. Bringing it all together into a cohesive whole involved the use of multiple software solutions with common interfaces.

Graf, Norman↗

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↗

Internship in Augmented and Virtual Reality - Rapid Model Import Tool

The integration of virtual and augmented reality, sometimes called mixed reality, is an emerging technology which will likely skyrocket overnight much in the way smartphones did a decade ago. Kennedy Space Center's Augmented and Virtual Reality (AVR) Lab is developing a Rapid Model Import Tool (RMIT) to create a quick and efficient way to bring NASA's complex engineering 3D models into virtual and augmented environments. The long-term objective is to create a tool that will ultimately benefit KSC engineers. Its various uses within NASA can potentially span from astronaut training, to marketing, to public outreach, to name a few. Unity is a prolific cross-platform game engine that allows users to build high quality 2D and 3D games for desktop, mobile, web, and game console platforms. It is perhaps also the most widely used software for virtual reality game development. At the AVR lab, we are looking at alternative uses of Unity to build tools for NASA engineers to perform design, development, testing, and training on spacecraft, rocket delivery systems, ground support equipment, and facilities at KSC. As an intern for the RMIT project, I am charged with the task of performing research on Unity-compatible file types to develop an efficient, affordable, preservative process to bring models from CATIA 3D engineering software into the Unity environment. With a tool called the NASA Enterprise Visualization Application (NEVA), developed by the Boeing Design Visualization group at KSC, we are able to easily convert CATIA's design models to. DAE (also known as COLLADA) and .OBJ file formats. I first reduce the polygon count of the model within CATIA itself, make any necessary tweaks to reduce the model further, and then export using NEVA. The .OBJ or. DAE files that I am left with are then converted by another intern to a Unity-compatible file format using a custom Python script. I have generated extensive documentation of this process in a NEVA User Guide. By the end of this semester, we will have built a solid framework for RMIT based on a thorough understanding of virtual reality specifications and file requirements, allowing future software development teams to go forward with development on the custom tool.

Leap Motion↗

Study of application of space telescope science operations software for SIRTF use

The design and development of the Space Telescope Science Operations Ground System (ST SOGS) was evaluated to compile a history of lessons learned that would benefit NASA's Space Infrared Telescope Facility (SIRTF). Forty-nine specific recommendations resulted and were categorized as follows: (1) requirements: a discussion of the content, timeliness and proper allocation of the system and segment requirements and the resulting impact on SOGS development; (2) science instruments: a consideration of the impact of the Science Instrument design and data streams on SOGS software; and (3) contract phasing: an analysis of the impact of beginning the various ST program segments at different times. Approximately half of the software design and source code might be useable for SIRTF. Transportability of this software requires, at minimum, a compatible DEC VAX-based architecture and VMS operating system, system support software similar to that developed for SOGS, and continued evolution of the SIRTF operations concept and requirements such that they remain compatible with ST SOGS operation.

Dignam, F.↗