Search NASA⌕ Search

SEARCH · Search NASA

Results for “Team software development”

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 397 records · Page 22

The Standard Autonomous File Server, a Customized, Off-the-Shelf Success Story

The Standard Autonomous File Server (SAFS), which includes both off-the-shelf hardware and software, uses an improved automated file transfer process to provide a quicker, more reliable, prioritized file distribution for customers of near real-time data without interfering with the assets involved in the acquisition and processing of the data. It operates as a stand-alone solution, monitoring itself, and providing an automated fail-over process to enhance reliability. This paper will describe the unique problems and lessons learned both during the COTS selection and integration into SAFS, and the system's first year of operation in support of NASA's satellite ground network. COTS was the key factor in allowing the two-person development team to deploy systems in less than a year, meeting the required launch schedule. The SAFS system his been so successful, it is becoming a NASA standard resource, leading to its nomination for NASA's Software or the Year Award in 1999.

Semancik, Susan K.↗

Landsat-7 Simulation and Testing Environments

A spacecraft Attitude Control and Determination Subsystem (ACDS) is heavily dependent upon simulation throughout its entire development, implementation and ground test cycle. Engineering simulation tools are typically developed to design and analyze control systems to validate the design and software simulation tools are required to qualify the flight software. However, the need for simulation does not end here. Operating the ACDS of a spacecraft on the ground requires the simulation of spacecraft dynamics, disturbance modeling and celestial body motion. Sensor data must also be simulated and substituted for actual sensor data on the ground so that the spacecraft will respond by sending commands to the actuators as they will on orbit. And finally, the simulators is the primary training tool and test-bed for the Flight Operations Team. In this paper various ACDS simulation, developed for or used by the Landsat 7 project will be described. The paper will include a description of each tool, its unique attributes, and its role in the overall development and testing of the ACDS. Finally, a section is included which discusses how the coordinated use of these simulation tools can maximize the probability of uncovering software, hardware and operations errors during the ground test process.

Holmes, E.↗

Development of a Search and Rescue Simulation to Study the Effects of Prolonged Isolation on Team Decision Making

The goals of this project were to identify and investigate aspects of team and individual decision-making and risk-taking behaviors hypothesized to be most affected by prolonged isolation. A key premise driving our research approach is that effects of stressors that impact individual and team cognitive processes in an isolated, confined, and hazardous environment will be projected onto the performance of a simulation task. To elicit and investigate these team behaviors we developed a search and rescue task concept as a scenario domain that would be relevant for isolated crews. We modified the Distributed Dynamic Decision-making (DDD) simulator, a platform that has been extensively used for empirical research in team processes and taskwork performance, to portray the features of a search and rescue scenario and present the task components incorporated into that scenario. The resulting software is called DD-Search and Rescue (Version 1.0). To support the use of the DDD-Search and Rescue simulator in isolated experiment settings, we wrote a player's manual for teaching team members to operate the simulator and play the scenario. We then developed a research design and experiment plan that would allow quantitative measures of individual and team decision making skills using the DDD-Search and Rescue simulator as the experiment platform. A description of these activities and the associated materials that were produced under this contract are contained in this report.

Entin, Elliot E.↗

New Web Server - the Java Version of Tempest - Produced

A new software design and development effort has produced a Java (Sun Microsystems, Inc.) version of the award-winning Tempest software (refs. 1 and 2). In 1999, the Embedded Web Technology (EWT) team received a prestigious R&D 100 Award for Tempest, Java Version. In this article, "Tempest" will refer to the Java version of Tempest, a World Wide Web server for desktop or embedded systems. Tempest was designed at the NASA Glenn Research Center at Lewis Field to run on any platform for which a Java Virtual Machine (JVM, Sun Microsystems, Inc.) exists. The JVM acts as a translator between the native code of the platform and the byte code of Tempest, which is compiled in Java. These byte code files are Java executables with a ".class" extension. Multiple byte code files can be zipped together as a "*.jar" file for more efficient transmission over the Internet. Today's popular browsers, such as Netscape (Netscape Communications Corporation) and Internet Explorer (Microsoft Corporation) have built-in Virtual Machines to display Java applets.

York, David W.↗

Demonstration of Rapid Development Through Containerization: OSE-SAT

Modern advancements in spacecraft technology have enabled engineers to develop radically smaller and lighter spacecraft, which has drastically reduced the cost of putting spacecraft into space. Despite these advancements and the shrinking cost to get spacecraft into space, space exploration is still prohibitively expensive. So much so that many space missions prefer to err on the side of caution than take on additional risk by trying newer, unproven technologies. This risk-averse mission design, while very reasonable from a program management point of view, significantly impacts engineers’ ability to solve newer, more complicated problems and limits scientists’ ability to develop more complex experiments that rely on newer technology. Often these new technologies remain stuck at lower technology readiness levels for many years due to the space community's reluctance to take on the additional risks of proving out unproven technology. The Distributed Spacecraft Autonomy (DSA) team at NASA Ames Research Center is developing a containerized solution to enable the rapid development of newer space technologies and accelerate their adoption into space missions. The Opportunistic Software Experiments for Spacecraft Autonomy Testbeds (OSE-SAT) is an on-orbit test bed that aims to reduce the amount of risk associated with newer, unproven space technologies by containerizing each experiment in its own isolated environment and providing a safe, robust, and controlled interface to access spacecraft host resources that is monitored in real time by thoroughly tested Trusted Container developed by DSA. This paper will describe DSA’s implementation of OSE-SAT and discuss the benefits, as well as challenges, of on-orbit containerization.

Aaron J Woodard↗

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗

Operation Program for the Spatially Phase-Shifted Digital Speckle Pattern Interferometer - SPS-DSPI

SPS-DSPI software has been revised so that Goddard optical engineers can operate the instrument, instead of data programmers. The user interface has been improved to view the data collected by the SPS-DSPI, with a real-time mode and a play-back mode. The SPS-DSPI has been developed by NASA/GSFC to measure the temperature distortions of the primary-mirror backplane structure for the James Webb Space Telescope. It requires a team of computer specialists to run successfully, because, at the time of this reporting, it just finished the prototype stage. This software improvement will transition the instrument to become available for use by many programs that measure distortion

Blake, Peter N.↗

AWIPS II Application Development, a SPoRT Perspective

The National Weather Service (NWS) is deploying its next‐generation decision support system, called AWIPS II (Advanced Weather Interactive Processing System II). NASA's Short‐term Prediction Research and Transition (SPoRT) Center has developed several software 'plug‐ins' to extend the capabilities of AWIPS II. SPoRT aims to continue its mission of improving short‐term forecasts by providing NASA and NOAA products on the decision support system used at NWS weather forecast offices (WFOs). These products are not included in the standard Satellite Broadcast Network feed provided to WFOs. SPoRT has had success in providing support to WFOs as they have transitioned to AWIPS II. Specific examples of transitioning SPoRT plug‐ins to WFOs with newly deployed AWIPS II systems will be presented. Proving Ground activities (GOES‐R and JPSS) will dominate SPoRT's future AWIPS II activities, including tool development as well as enhancements to existing products. In early 2012 SPoRT initiated the Experimental Product Development Team, a group of AWIPS II developers from several institutions supporting NWS forecasters with innovative products. The results of the team's spring and fall 2013 meeting will be presented. Since AWIPS II developers now include employees at WFOs, as well as many other institutions related to weather forecasting, the NWS has dealt with a multitude of software governance issues related to the difficulties of multiple remotely collaborating software developers. This presentation will provide additional examples of Research‐to‐Operations plugins, as well as an update on how governance issues are being handled in the AWIPS II developer community.

Burks, Jason E.↗

Safety Characteristics in System Application of Software for Human Rated Exploration Missions for the 8th IAASS Conference

NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.

capability↗

CINTEX: International Interoperability Extensions to EOSDIS

A large part of the research under this cooperative agreement involved working with representatives of the DLR, NASDA, EDC, and NOAA-SAA data centers to propose a set of enhancements and additions to the EOSDIS Version 0 Information Management System (V0 IMS) Client/Server Message Protocol. Helen Conover of ITSL led this effort to provide for an additional geographic search specification (WRS Path/Row), data set- and data center-specific search criteria, search by granule ID, specification of data granule subsetting requests, data set-based ordering, and the addition of URLs to result messages. The V0 IMS Server Cookbook is an evolving document, providing resources and information to data centers setting up a VO IMS Server. Under this Cooperative Agreement, Helen Conover revised, reorganized, and expanded this document, and converted it to HTML. Ms. Conover has also worked extensively with the IRE RAS data center, CPSSI, in Russia. She served as the primary IMS contact for IRE-CPSSI and as IRE-CPSSI's liaison to other members of IMS and Web Gateway (WG) development teams. Her documentation of IMS problems in the IRE environment (Sun servers and low network bandwidth) led to a general restructuring of the V0 IMS Client message polling system. to the benefit of all IMS participants. In addition to the IMS server software and documentation. which are generally available to CINTEX sites, Ms. Conover also provided database design documentation and consulting, order tracking software, and hands-on testing and debug assistance to IRE. In the final pre-operational phase of IRE-CPSSI development, she also supplied information on configuration management, including ideas and processes in place at the Global Hydrology Resource Center (GHRC), an EOSDIS data center operated by ITSL.

Graves, Sara J.↗

Intelligent systems for KSC ground processing

The ground processing and launch of Shuttle vehicles and their payloads is the primary task of Kennedy Space Center. It is a process which is largely manual and contains little inherent automation. Business is conducted today much as it was during previous NASA programs such as Apollo. In light of new programs and decreasing budgets, NASA must find more cost effective ways in which to do business while retaining the quality and safety of activities. Advanced technologies including artificial intelligence could cut manpower and processing time. This paper is an overview of the research and development in Al technology at KSC with descriptions of the systems which have been implemented, as well as a few under development which are promising additions to ground processing software. Projects discussed cover many facets of ground processing activities, including computer sustaining engineering, subsystem monitor and diagnosis tools and launch team assistants. The deployed Al applications have proven an effectiveness which has helped to demonstrate the benefits of utilizing intelligent software in the ground processing task.

Heard, Astrid E.↗

Relating MBSE to Spacecraft Development: A NASA Pathfinder

The NASA Engineering and Safety Center (NESC) has sponsored a Pathfinder Study to investigate how Model Based Systems Engineering (MBSE) and Model Based Engineering (MBE) techniques can be applied by NASA spacecraft development projects. The objectives of this Pathfinder Study included analyzing both the products of the modeling activity, as well as the process and tool chain through which the spacecraft design activities are executed. Several aspects of MBSE methodology and process were explored. Adoption and consistent use of the MBSE methodology within an existing development environment can be difficult. The Pathfinder Team evaluated the possibility that an "MBSE Template" could be developed as both a teaching tool as well as a baseline from which future NASA projects could leverage. Elements of this template include spacecraft system component libraries, data dictionaries and ontology specifications, as well as software services that do work on the models themselves. The Pathfinder Study also evaluated the tool chain aspects of development. Two chains were considered: 1. The Development tool chain, through which SysML model development was performed and controlled, and 2. The Analysis tool chain, through which both static and dynamic system analysis is performed. Of particular interest was the ability to exchange data between SysML and other engineering tools such as CAD and Dynamic Simulation tools. For this study, the team selected a Mars Lander vehicle as the element to be designed. The paper will discuss what system models were developed, how data was captured and exchanged, and what analyses were conducted.

Othon, Bill↗

Application Software Cybersecurity Scanning

Scanning software applications for cybersecurity vulnerabilities is a crucial step is assessing the overall health of the application, but how can this kind of scan be performed to give development teams the information they need to make informed design decisions? Two pilot cybersecurity scans were conducted in an attempt to answer this question. A scanning team composed of various subject matter experts was established and worked closely with the development team to perform these scans and capture metrics throughout the process. These interactions and metrics indicate that these scans can be performed in an unobtrusive way and still provide valuable information to development teams regarding the health of their application. This work is not definitive in nature but serves as a foundation for future work.

Barner, Lyle↗

The cleanroom case study in the Software Engineering Laboratory: Project description and early analysis

This case study analyzes the application of the cleanroom software development methodology to the development of production software at the NASA/Goddard Space Flight Center. The cleanroom methodology emphasizes human discipline in program verification to produce reliable software products that are right the first time. Preliminary analysis of the cleanroom case study shows that the method can be applied successfully in the FDD environment and may increase staff productivity and product quality. Compared to typical Software Engineering Laboratory (SEL) activities, there is evidence of lower failure rates, a more complete and consistent set of inline code documentation, a different distribution of phase effort activity, and a different growth profile in terms of lines of code developed. The major goals of the study were to: (1) assess the process used in the SEL cleanroom model with respect to team structure, team activities, and effort distribution; (2) analyze the products of the SEL cleanroom model and determine the impact on measures of interest, including reliability, productivity, overall life-cycle cost, and software quality; and (3) analyze the residual products in the application of the SEL cleanroom model, such as fault distribution, error characteristics, system growth, and computer usage.

Green, Scott↗

Bumper: A Tool for Analyzing Spacecraft Micrometeoroid and Orbital Debris Risk

“Bumper” is NASA’s computer program for analyzing spacecraft micrometeoroid and orbital debris (MMOD) risk. Bumper was developed in the late-1980s and has been continuously used and maintained since. The user base has grown from a few government entities to now include numerous commercial entities as well. The NASA Johnson Space Center (JSC) Hypervelocity Impact Technology (HVIT) Team is responsible for all aspects of the Bumper software. Bumper has been used to characterize MMOD risk on hundreds of spacecraft. All of the International Space Station (ISS) modules, visiting vehicles and numerous external components and systems have been analyzed. Bumper was used to analyze each of the Space Shuttle missions since STS-50. The Orion Multi-Purpose Crew Vehicle (MPCV) MMOD shielding is being developed using Bumper as well. Bumper has also been used on numerous telescopes (Hubble, James Webb, and Fermi Gamma-ray Space Telescopes), scientific probes (Stardust, New Horizons, Parker Solar Probe), and Earth observation satellites (Landsat, Joint Polar Satellite System). Bumper is also being used to analyze the micrometeoroid risk and support design of the Deep Space Gateway (DSG) and Mars Sample Return (MSR) missions. The HVIT Bumper Configuration Control Board (CCB) ensures that all changes to the code are approved, reviewed, and documented. Most of the changes are made to add new MMOD damage “ballistic limit equations” (BLEs). BLEs are typically added in response to completion of a hypervelocity impact (HVI) test series and development of an associated BLE. Other less frequent changes include updates of the debris or meteoroid environment models, feature enhancements, and feature retirement. Some BLEs are commercially sensitive and/or proprietary, so the CCB also manages code user-version control and software distribution. The current version – “Bumper 3” – is a FORTRAN executable that utilizes a 64-bit architecture. Bumper 3 has numerous features that make it a powerful tool for analyzing spacecraft MMOD risk. Bumper uses the latest orbital debris and micrometeoroid environment models. Bumper also easily processes large spacecraft geometry models, recognizes hidden surfaces, permits BLE assignment by name or number, and conducts quality checks of the spacecraft geometry model. Bumper 3 can also be used to estimate the effects of particle penetration through thin, high-standoff distance hardware components such as solar arrays and radiators. This is done using a special HVIT-developed technique know as the “3-Part Analysis.” The paper introduces the Bumper 3 MMOD risk analysis code and provides an example MMOD risk assessment showing Bumper’s role in the overall MMOD protection design process.

Lear, Dana M.↗

A ROS-based Simulator for Testing the Enhanced Autonomous Navigation of the Mars 2020 Rover

In order to achieve the ambitious objectives of the Mars 2020 (M2020) mission, in particular the ability to autonomously traverse more challenging terrains more efficiently, new surface mobility software was developed for Enhanced Navigation (ENav). That decision was made early in the project, before most of the new surface flight software (FSW) existed, which created a need for a separate framework where the new navigation algorithms could be quickly prototyped and tested, before more realistic FSW-based testbeds became available. The JPL robotics team chose the Robot Operating System [1] (ROS) as the environment in which to test the new ENav algorithms. This made it possible to write the algorithms in the C language required by the FSW, so they could be directly ported over to the flight module later on, while leveraging all the C++ libraries and tools provided by ROS for simulation and testing. The ENav algorithms were developed as a separate C library, and stubs were used to replace any FSW-specific code, such as Event Reporting (EVRs) and data products (DPs). A ROS simulator was developed to generate a rich set of varied 3D terrains representative of the candidate Mars landing sites and simulate the physics of the rover motion, the point cloud perceived by the rover’s stereo vision system, and the new thinking-while-driving (TWD) navigation logic which directs the rover to drive autonomously to user-specified waypoints. To simulate the rover motion and perception, a ROS node was developed that uses a software library called HyperDrive Sim (HDSim), which is a wrapper for the Rover Sequencing and Visualization Program [2] (RSVP). That library provides roverterrain settling, realistic slip modelling, and camera rendering capability based on the rover’s NavCam machine vision models. To simulate the navigation logic, a ROS node was created that initializes and runs the ENav algorithms in a way that mimics the FSW execution, while also providing the capability to load and replay data products, including re-running the recorded inputs through the ENav algorithms for testing. An engineering Graphical User Interface (GUI) was also developed to visualize various elements, such as the rover pose during the drive, the simulated and perceived terrain, the selected local and global paths to the goal, the evaluated candidate paths and the reasons why they were rejected, the keep-in and keep-out zones (KIOZs), etc. Finally, an advanced Monte Carlo (MC) framework that can run many simulations in parallel on the Cloud and automatically generate reports that capture the key ENav performance metrics was developed to evaluate the system in a statisticallymeaningful way. This paper provides an overview of the ROSbased simulator used for testing the M2020 ENav algorithms.

Toupet, Olivier↗

Towards Seamless Interoperability of MPI-OpenMP Applications

A chasm exists between mathematical software libraries written for MPI-based applications and those written for OpenMP applications. Recently, however, PETSc enables the simple use of its MPI-based linear solvers from OpenMP applications. Separately, the MPICH MPI development team has started a new project to allow almost seamless MPI use in OpenMP applications. Both proposed approaches would result in a similar user experience. Here, we discuss the reasons for these projects and their potential for providing more numerical library choices for OpenMP applications, including the unlimited assortment of linear solvers available in PETSc. In addition, we present the performance of an application using the first approach, demonstrating its efficacy.

MPI↗