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.

SourceResearch connectionFrom yearThrough year

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

At least 307 records · Page 17

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Trajectory Software With Upper Atmosphere Model

The Trajectory Software Applications 6.0 for the Dec Alpha platform has an implementation of the Jacchia-Lineberry Upper Atmosphere Density Model used in the Mission Control Center for International Space Station support. Previous trajectory software required an upper atmosphere to support atmosphere drag calculations in the Mission Control Center. The Functional operation will differ depending on the end-use of the module. In general, the calling routine will use function-calling arguments to specify input to the processor. The atmosphere model will then compute and return atmospheric density at the time of interest.

Barrett, Charles↗

NASA NTRS2020

Development of a Supervisory Tool for Fault Detection and Diagnosis of DC Electric Power Systems with the Application of Deep Space Vehicles

This dissertation formulates the problem of fault detection and diagnosis of DC electric power systems for the application of autonomous spacecraft. The ability to accurately identify and isolate failures in the electrical power system is critical to ensure the reliability of a spacecraft. This problem becomes more pronounced during deep space missions that lack the ability to monitor from ground control. The current state of electrical power system fault supervision is insufficient to guarantee highly reliable and robust operation. To solve this issue, a combination of model-based and rules-based techniques are used in a hierarchical framework to improve the diagnostic performance of the spacecraft electrical power system. Noise, disturbances, and modeling errors are considered in the design of the method. Practical considerations related to the hardware and software are discussed for the flight application. A wide array of failure types are simulated in a series of experiments to assess the functionality of the design. The experiments showed that the methods used improved the diagnostic capability of the autonomous system while taking into account the limitations attributed to flight software requirements. The significance of this study is to provide a framework capable of advanced diagnostics of an electrical power system with little to no interaction from a human operator.

Fault Detection and Diagnosis↗

NASA NTRS2003

Setting up a Grid: A Guide for Beginners by a Beginner

A simple compute grid can be constructed for under $ 1,000 with 5 computers on a LAN for the purpose of video compression from captured digital video to MPEG file format. The process for setting up this grid will be covered in detail, including the required operating systems and hardware, the required globus software, and the required video capture and compression software. Pitfalls encountered will be discussed, and the approximate timeline for a motivated but uninformed beginner. The installation, configuration, and operation of additional software that is needed test, measure and otherwise verify that the grid components are functioning as "advertised", will also be presented. This is a true life account for setting up a grid based on instructions in Chapters 9 and 10 of Introduction to Grid Computing with Globus.

Welch, Clara↗

NASA NTRS2007

Software Safety Risk in Legacy Safety-Critical Computer Systems

Safety-critical computer systems must be engineered to meet system and software safety requirements. For legacy safety-critical computer systems, software safety requirements may not have been formally specified during development. When process-oriented software safety requirements are levied on a legacy system after the fact, where software development artifacts don't exist or are incomplete, the question becomes 'how can this be done?' The risks associated with only meeting certain software safety requirements in a legacy safety-critical computer system must be addressed should such systems be selected as candidates for reuse. This paper proposes a method for ascertaining formally, a software safety risk assessment, that provides measurements for software safety for legacy systems which may or may not have a suite of software engineering documentation that is now normally required. It relies upon the NASA Software Safety Standard, risk assessment methods based upon the Taxonomy-Based Questionnaire, and the application of reverse engineering CASE tools to produce original design documents for legacy systems.

Hill, Janice↗

NASA NTRS2018

From Formal Requirements to Highly Assured Software for Unmanned Aircraft Systems

Operational requirements of safety-critical systems are often written in restricted specification logics. These restricted logics are amenable to automated analysis techniques such as model-checking, but are not rich enough to express complex requirements of unmanned systems. This short paper advocates for the use of expressive logics, such as higher-order logic, to specify the complex operational requirements and safety properties of unmanned systems. These rich logics are less amenable to automation and, hence, require the use of interactive theorem proving techniques. However, these logics support the formal verification of complex requirements such as those involving the physical environment. Moreover, these logics enable validation techniques that increase con dence in the correctness of numerically intensive software. These features result in highly-assured software that may be easier to certify. The feasibility of this approach is illustrated with examples drawn for NASA's unmanned aircraft systems.

Munoz, Cesar↗

NASA NTRS1996

Basic Requirements for Systems Software Research and Development

Our success over the past ten years evaluating and developing advanced computing technologies has been due to a simple research and development (R/D) model. Our model has three phases: (a) evaluating the state-of-the-art, (b) identifying problems and creating innovations, and (c) developing solutions, improving the state- of-the-art. This cycle has four basic requirements: a large production testbed with real users, a diverse collection of state-of-the-art hardware, facilities for evalua- tion of emerging technologies and development of innovations, and control over system management on these testbeds. Future research will be irrelevant and future products will not work if any of these requirements is eliminated. In order to retain our effectiveness, the numerical aerospace simulator (NAS) must replace out-of-date production testbeds in as timely a fashion as possible, and cannot afford to ignore innovative designs such as new distributed shared memory machines, clustered commodity-based computers, and multi-threaded architectures.

Kuszmaul, Chris↗

DOE OSTI2020

Requirements Description of the REBUS Software for the Versatile Test Reactor

This report presents the modeling and simulation capabilities of Argonne National Laboratory’s fuel cycle analysis code, the REactor BUrnup System (REBUS), that will be relied on for the VTR project. These capabilities will then be used to establish the set of REBUS verification tasks necessary to verify REBUS for usage on the VTR project. A similar path was followed for the DIF3D software where its’ requirements and verification tasks were established. REBUS has been maintained by Argonne since the early 1960s to support its reactor design mission. That software transitioned from the original REBUS to REBUS-2 in the mid 1970s and to REBUS-3 in the mid 1980s. Since then REBUS has gone through many revisions to the current REBUS-11. Note that this version numbering is consistent with the progression of DIF3D, the base flux solver that REBUS is built upon. The name REBUS refers to a pictorial based puzzle as the original developers were inspired by having to track thousands of unique fuel assemblies as they are inserted into the reactor, depleted, shuffled, discharged, and reprocessed.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

DOE OSTI2023

Energy Northwest — Advanced Grid Interactive Load Efficiency (AGILE) : A Techno-economic Assessment

The Advanced Grid Interactive Load Efficiency project team, led by Energy Northwest, was awarded funding as part of the fourth round of the Clean Energy Fund program to investigate, co-create, and complete a preliminary design for grid-interactive efficient buildings (GEBs) for a number of schools served by Grays Harbor PUD. The project team has evaluated different combinations of systems at selected school buildings and the potential to respond to grid and customer needs, and develop a preliminary system technical design, including specifying desired GEB technology options, determining communication and electrical interface requirements, assessing control software sensor requirements, and interfacing with building management systems. PNNL led the techno-economic assessment efforts, leveraging its advanced modeling and analytical methods and tools developed for building-to-grid integration. This report documents the economic assessment for different GEB design options, encompassing an in-depth examination of use cases and value propositions, assumptions and inputs, models, methods, case studies, as well as key findings.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS2004

Engineering Complex Embedded Systems with State Analysis and the Mission Data System

It has become clear that spacecraft system complexity is reaching a threshold where customary methods of control are no longer affordable or sufficiently reliable. At the heart of this problem are the conventional approaches to systems and software engineering based on subsystem-level functional decomposition, which fail to scale in the tangled web of interactions typically encountered in complex spacecraft designs. Furthermore, there is a fundamental gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers. Software engineers must perform the translation of requirements into software code, hoping to accurately capture the systems engineer's understanding of the system behavior, which is not always explicitly specified. This gap opens up the possibility for misinterpretation of the systems engineer s intent, potentially leading to software errors. This problem is addressed by a systems engineering methodology called State Analysis, which provides a process for capturing system and software requirements in the form of explicit models. This paper describes how requirements for complex aerospace systems can be developed using State Analysis and how these requirements inform the design of the system software, using representative spacecraft examples.

mission data systems↗

NASA NTRS1998

Designing for Change: Minimizing the Impact of Changing Requirements in the Later Stages of a Spaceflight Software Project

In the traditional 'waterfall' model of the software project life cycle, the Requirements Phase ends and flows into the Design Phase, which ends and flows into the Development Phase. Unfortunately, the process rarely, if ever, works so smoothly in practice. Instead, software developers often receive new requirements, or modifications to the original requirements, well after the earlier project phases have been completed. In particular, projects with shorter than ideal schedules are highly susceptible to frequent requirements changes, as the software requirements analysis phase is often forced to begin before the overall system requirements and top-level design are complete. This results in later modifications to the software requirements, even though the software design and development phases may be complete. Requirements changes received in the later stages of a software project inevitably lead to modification of existing developed software. Presented here is a series of software design techniques that can greatly reduce the impact of last-minute requirements changes. These techniques were successfully used to add built-in flexibility to two complex software systems in which the requirements were expected to (and did) change frequently. These large, real-time systems were developed at NASA Langley Research Center (LaRC) to test and control the Lidar In-Space Technology Experiment (LITE) instrument which flew aboard the space shuttle Discovery as the primary payload on the STS-64 mission.

Allen, B. Danette↗

NASA NTRS2002

Software Design Methodology Migration for a Distributed Ground System

The Marshall Space Flight Center's (MSFC) Payload Operations Center (POC) ground system has been developed and has evolved over a period of about 10 years. During this time the software processes have migrated from more traditional to more contemporary development processes. The new Software processes still emphasize requirements capture, software configuration management, design documenting, and making sure the products that have been developed are accountable to initial requirements. This paper will give an overview of how the Software Process have evolved highlighting the positives as well as the negatives. In addition, we will mention the COTS tools that have been integrated into the processes and how the COTS have provided value to the project .

Ritter, George↗

NASA NTRS1994

Experience report: Using formal methods for requirements analysis of critical spacecraft software

Formal specification and analysis of requirements continues to gain support as a method for producing more reliable software. However, the introduction of formal methods to a large software project is difficult, due in part to the unfamiliarity of the specification languages and the lack of graphics. This paper reports results of an investigation into the effectiveness of formal methods as an aid to the requirements analysis of critical, system-level fault-protection software on a spacecraft currently under development. Our experience indicates that formal specification and analysis can enhance the accuracy of the requirements and add assurance prior to design development in this domain. The work described here is part of a larger, NASA-funded research project whose purpose is to use formal-methods techniques to improve the quality of software in space applications. The demonstration project described here is part of the effort to evaluate experimentally the effectiveness of supplementing traditional engineering approaches to requirements specification with the more rigorous specification and analysis available with formal methods.

Lutz, Robyn R.↗

NASA NTRS2003

CCSDS File Delivery Protocol (CFDP): Why it's Useful and How it Works

Reliable delivery of data products is often required across space links. For example, a NASA mission will require reliable delivery of images produced by an on-board detector. Many missions have their own (unique) way of accomplishing this, requiring custom software. Many missions also require manual operations (e.g. the telemetry receiver software keeps track of what data is missing, and a person manually inputs the appropriate commands to request retransmissions). The Consultative Committee for Space Data Systems (CCSDS) developed the CCSDS File Delivery Protocol (CFDP) specifically for this situation. CFDP is an international standard communication protocol that provides reliable delivery of data products. It is designed for use across space links. It will work well if run over the widely used CCSDS Telemetry and Telecommand protocols. However, it can be run over any protocol, and will work well as long as the underlying protocol delivers a reasonable portion of the data. The CFDP receiver will autonomously determine what data is missing, and request retransmissions as needed. The CFDP sender will autonomously perform the requested transmissions. When the entire data product is delivered, the CFDP receiver will let the CFDP sender know that the transaction has completed successfully. The result is that custom software becomes standard, and manual operations become autonomous. This paper will consider various ways of achieving reliable file delivery, explain why CFDP is the optimal choice for use over space links, explain how the core protocol works, and give some guidance on how to best utilize CFDP within various mission scenarios. It will also touch on additional features of CFDP, as well as other uses for CFDP (e.g. the loading of on-board memory and tables).

Ray, Tim↗

NASA NTRS2001

Automatic Debugging Support for UML Designs

Design of large software systems requires rigorous application of software engineering methods covering all phases of the software process. Debugging during the early design phases is extremely important, because late bug-fixes are expensive. In this paper, we describe an approach which facilitates debugging of UML requirements and designs. The Unified Modeling Language (UML) is a set of notations for object-orient design of a software system. We have developed an algorithm which translates requirement specifications in the form of annotated sequence diagrams into structured statecharts. This algorithm detects conflicts between sequence diagrams and inconsistencies in the domain knowledge. After synthesizing statecharts from sequence diagrams, these statecharts usually are subject to manual modification and refinement. By using the "backward" direction of our synthesis algorithm. we are able to map modifications made to the statechart back into the requirements (sequence diagrams) and check for conflicts there. Fed back to the user conflicts detected by our algorithm are the basis for deductive-based debugging of requirements and domain theory in very early development stages. Our approach allows to generate explanations oil why there is a conflict and which parts of the specifications are affected.

Schumann, Johann↗

NASA NTRS1994

Experience Report: Using Formal Methods for Requirements Analysis of Critical Spacecraft Software

Formal↗

NASA NTRS2005

Development of Software for a Lidar-Altimeter Processor

A report describes the development of software for a digital processor that operates in conjunction with a finite-impulse-response (FIR) chip in a spaceborne lidar altimeter. Processing is started by a laser-fire interrupt signal that is repeated at intervals of 25 ms. For the purpose of discriminating between returns from the ground and returns from such things as trees, buildings, and clouds, the software is required to scan digitized lidar-return data in reverse of the acquisition sequence in order to distinguish the last return pulse from within a commanded ground-return range window. The digitized waveform information within this range window is filtered through 6 matched filters, in the hardware electronics, in order to maximize the probability of finding echoes from sloped or rough terrain and minimize the probability of selecting cloud returns. From the data falling past the end of the range window, there is obtained a noise baseline that is used to calculate a threshold value for each filter. The data from each filter is analyzed by a complex weighting scheme and the filter with the greatest weight is selected. A region around the peak of the ground return pulse associated with the selected filter is placed in telemetry, as well as information on its location, height, and other characteristics. The software requires many uplinked parameters as input. Included in the report is a discussion of major software-development problems posed by the design of the FIR chip and the need for the software to complete its process within 20 ms to fit within the overall 25-ms cycle.

Rosenberg, Jacob S.↗

NASA NTRS2006

Three Years of Global Positioning System Experience on International Space Station

The International Space Station global positioning system (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had so many problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities..

Gomez, Susan↗

NASA NTRS2005

Three Years of Global Positioning System Experience on International Space Station

The International Space Station global positioning systems (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually, enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units were upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had numerous problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities.

Gomez, Susan↗