Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

Techniques and software for optimum and efficient mission science sequence development

Highly successful mission operations require efficient and cost-effective science sequence development. Of key importance is the Science Planning and Operations Team's (SPOT's) ability to complete science observation design and integration early in the sequence development process (i.e., before the sequence enters into a formal change control process). Once under formal change control, careful change paper documentation, Flight Team checks, and mission software checks make sequence changes more labor-intensive. This paper discusses team organization, strategies, scheduling, and software employed by the Voyager and Galileo SPOT's to complete science observation design and integration early in the sequence development process.

Bliss, David A.↗
NASA NTRSDate not supplied

MPATH (Measuring Performance for Autonomy Teaming with Humans) Ground Control Station: Design Approach and Initial Usability Results

Envisioned future Advanced Air Mobility (AAM) operations will require a transition of aircraft command and control from onboard pilots to remote operators. The National Aeronautics and Space Administration (NASA) has developed a research ground control station (GCS) software called MPATH (Measuring Performance for Autonomy Teaming with Humans) to study the human factors of remote operators in a representative AAM environment, where small uncrewed aerial systems (sUAS; simulated or real) act as surrogates for larger AAM aircraft. A primary focus of the research being conducted with the MPATH GCS is scalability (i.e., one human managing multiple vehicles). MPATH has demonstrated to be a useful capability for human factors research and remote operations. Two initial usability studies and a multi-vehicle control assessment were recently conducted, and usability data and operator feedback were collected. Generally, participants rated MPATH high on usability and interface quality, whereas information quality was rated slightly lower. These results were supported by specific feedback. Several generalized GCS design recommendations are proposed based on the results and feedback from these flight activities. Future updates to MPATH will incorporate the proposed recommendations. In practice, these recommendations could be used by any GCS software designer or developer to promote usability and safety.

Advanced Air Mobility↗
NASA NTRS2002

Participation in the Mars Orbiting Laser Altimeter Experiment

This NASA Grant, 5-4434, has covered the active participation of the Principal Investigator, Prof. Gordon Pettengill, and his Co-Investigator, Peter Ford, in the Mars Orbiting Laser Altimeter (MOLA) Experiment, over a period of five years. This participation has included attending team meetings, planning observing operations, developing data-reduction software algorithms, and processing data, as well as presenting a number of oral reports at scientific meetings and published papers in refereed journals. This research has concentrated on the various types of Martian clouds that were detected by the laser altimeter.

Pettengill, Gordon H.↗
NASA NTRS2018

Astrobee Robot Software: A Modern Software System for Space

Astrobee is a new free-flyer robot designed to operate inside the International Space Station (ISS). Astrobee capabilities include markerless navigation, autonomous docking for recharge, perching on handrails to minimize power and modular payloads. Astrobee will operate without crew support, controlled by teleoperation, plan execution, or on-board third parties software. This paper presents the Astrobee Robot Software, a NASA Open-Source project, powering the Astrobee robot. The Astrobee Robot Software relies on a distributed architecture based on the Robot Operating System (ROS). The software runs on three interconnected smart phone class processors. We present the software approach, infrastructure required, and main software components. The Astrobee Robot Software embrace modern software practices while respecting flight constraints. The paper concludes with the lessons learned, including examples usage of the software. Several research teams are already using the Astrobee Robot Software to develop novel projects that will fly on Astrobee.

Astrobee↗
NASA NTRS1996

Planetary Atmosphere Dynamics and Radiative Transfer

This research program has dealt with two projects in the field of planetary atmosphere dynamics and radiative energy transfer, one theoretical and one experimental. The first project, in radiative energy transfer, incorporated the capability to isolate and quantify the contribution of individual atmospheric components to the Venus radiative balance and thermal structure to greatly improve the current understanding of the radiative processes occurring within the Venus atmosphere. This is possible by varying the mixing ratios of each gas species, and the location, number density and aerosol size distributions of the clouds. This project was a continuation of the work initiated under a 1992 University Consortium Agreement. Under the just completed grant, work has continued on the use of a convolution-based algorithm that provided the capability to calculate the k coefficients of a gas mixture at different temperatures, pressures and spectral intervals from the separate k-distributions of the individual gas species. The second primary goal of this research dealt with the Doppler wind retrieval for the Successful Galileo Jupiter probe mission in December, 1995. In anticipation of the arrival of Galileo at Jupiter, software development continued to read the radioscience and probe/orbiter trajectory data provided by the Galileo project and required for Jupiter zonal wind measurements. Sample experiment radioscience data records and probe/orbiter trajectory data files provided by the Galileo Radioscience and Navigation teams at the Jet Propulsion Laboratory, respectively, were used for the first phase of the software development. The software to read the necessary data records was completed in 1995. The procedure by which the wind retrieval takes place begins with initial consistency checks of the raw data, preliminary data reductions, wind recoveries, iterative reconstruction of the probe descent profile, and refined wind recoveries. At each stage of the wind recovery consistency is checked and maintained between the orbiter navigational data, the radioscience data, and the probe descent profile derived by the Atmospheric Instrument Team. Preliminary results show that the zonal winds at Jupiter increase with depth to approximately 150 m/s.

Atkinson, David H.↗
NASA NTRS1993

The application of automated operations at the Institutional Processing Center

The JPL Institutional and Mission Computing Division, Communications, Computing and Network Services Section, with its mission contractor, OAO Corporation, have for some time been applying automation to the operation of JPL's Information Processing Center (IPC). Automation does not come in one easy to use package. Automation for a data processing center is made up of many different software and hardware products supported by trained personnel. The IPC automation effort formally began with console automation, and has since spiraled out to include production scheduling, data entry, report distribution, online reporting, failure reporting and resolution, documentation, library storage, and operator and user education, while requiring the interaction of multi-vendor and locally developed software. To begin the process, automation goals are determined. Then a team including operations personnel is formed to research and evaluate available options. By acquiring knowledge of current products and those in development, taking an active role in industry organizations, and learning of other data center's experiences, a forecast can be developed as to what direction technology is moving. With IPC management's approval, an implementation plan is developed and resources identified to test or implement new systems. As an example, IPC's new automated data entry system was researched by Data Entry, Production Control, and Advance Planning personnel. A proposal was then submitted to management for review. A determination to implement the new system was made and elements/personnel involved with the initial planning performed the implementation. The final steps of the implementation were educating data entry personnel in the areas effected and procedural changes necessary to the successful operation of the new system.

Barr, Thomas H.↗
NASA NTRSDate not supplied

Candidate Formulary Development for Exploration Missions

An interdisciplinary team of clinician, pharmacist, and system engineer subject matter experts (SMEs) collaborated to match pharmaceutical resources to the medical conditions anticipated to occur during exploration class missions. This effort began by using a SME generated Exploration Medical Conditions List and the associated medical system capabilities necessary to treat them. Using the systems engineering software MagicDraw™ and knowledge of pharmaceutical use and efficacy in spaceflight, the team traced appropriate medications to the medical conditions. These traces were used to pilot the process for generating a candidate formulary for level of care 4 and level of care 5 medical systems. This presentation will discuss the collaborative efforts of the team as they developed the content, detail the challenges of utilizing systems engineering software to describe clinical resources, and provide an overview of how the candidate medication formulary for exploration class missions was developed. It will also discuss how the lessons learned from this pilot effort can be applied to streamline future work.

S. Kurian↗
NASA NTRS1998

Antiterrorist Software

In light of the escalation of terrorism, the Department of Defense spearheaded the development of new antiterrorist software for all Government agencies by issuing a Broad Agency Announcement to solicit proposals. This Government-wide competition resulted in a team that includes NASA Lewis Research Center's Computer Services Division, who will develop the graphical user interface (GUI) and test it in their usability lab. The team launched a program entitled Joint Sphere of Security (JSOS), crafted a design architecture (see the following figure), and is testing the interface. This software system has a state-ofthe- art, object-oriented architecture, with a main kernel composed of the Dynamic Information Architecture System (DIAS) developed by Argonne National Laboratory. DIAS will be used as the software "breadboard" for assembling the components of explosions, such as blast and collapse simulations.

Clark, David A.↗
NASA NTRS1994

Taking advantage of ground data systems attributes to achieve quality results in testing software

During the software development life cycle process, basic testing starts with the development team. At the end of the development process, an acceptance test is performed for the user to ensure that the deliverable is acceptable. Ideally, the delivery is an operational product with zero defects. However, the goal of zero defects is normally not achieved but is successful to various degrees. With the emphasis on building low cost ground support systems while maintaining a quality product, a key element in the test process is simulator capability. This paper reviews the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) test tool that is used in the acceptance test process for unmanned satellite operations control centers. The TASS is designed to support the development, test and operational environments of the Goddard Space Flight Center (GSFC) operations control centers. The TASS uses the same basic architecture as the operations control center. This architecture is characterized by its use of distributed processing, industry standards, commercial off-the-shelf (COTS) hardware and software components, and reusable software. The TASS uses much of the same TPOCC architecture and reusable software that the operations control center developer uses. The TASS also makes use of reusable simulator software in the mission specific versions of the TASS. Very little new software needs to be developed, mainly mission specific telemetry communication and command processing software. By taking advantage of the ground data system attributes, successful software reuse for operational systems provides the opportunity to extend the reuse concept into the test area. Consistency in test approach is a major step in achieving quality results.

Sigman, Clayton B.↗
NASA NTRS2008

SDO FlatSat Facility

The goal of the Solar Dynamics Observatory (SDO) is to understand and, ideally, predict the solar variations that influence life and society. It's instruments will measure the properties of the Sun and will take hifh definition images of the Sun every few seconds, all day every day. The FlatSat is a high fidelity electrical and functional representation of the SDO spacecraft bus. It is a high fidelity test bed for Integration & Test (I & T), flight software, and flight operations. For I & T purposes FlatSat will be a driver to development and dry run electrical integration procedures, STOL test procedures, page displays, and the command and telemetry database. FlatSat will also serve as a platform for flight software acceptance and systems testing for the flight software system component including the spacecraft main processors, power supply electronics, attitude control electronic, gimbal control electrons and the S-band communications card. FlatSat will also benefit the flight operations team through post-launch flight software code and table update development and verification and verification of new and updated flight operations products. This document highlights the benefits of FlatSat; describes the building of FlatSat; provides FlatSat facility requirements, access roles and responsibilities; and, and discusses FlatSat mechanical and electrical integration and functional testing.

Amason, David L.↗
NASA NTRS1999

Spacecraft Software Maintenance: An Effective Approach to Reducing Costs and Increasing Science Return

Flight software is a mission critical element of spacecraft functionality and performance. When ground operations personnel interface to a spacecraft, they are typically dealing almost entirely with the capabilities of onboard software. This software, even more than critical ground/flight communications systems, is expected to perform perfectly during all phases of spacecraft life. Due to the fact that it can be reprogrammed on-orbit to accommodate degradations or failures in flight hardware, new insights into spacecraft characteristics, new control options which permit enhanced science options, etc., the on- orbit flight software maintenance team is usually significantly responsible for the long term success of a science mission. Failure of flight software to perform as needed can result in very expensive operations work-around costs and lost science opportunities. There are three basic approaches to maintaining spacecraft software--namely using the original developers, using the mission operations personnel, or assembling a center of excellence for multi-spacecraft software maintenance. Not planning properly for flight software maintenance can lead to unnecessarily high on-orbit costs and/or unacceptably long delays, or errors, in patch installations. A common approach for flight software maintenance is to access the original development staff. The argument for utilizing the development staff is that the people who developed the software will be the best people to modify the software on-orbit. However, it can quickly becomes a challenge to obtain the services of these key people. They may no longer be available to the organization. They may have a more urgent job to perform, quite likely on another project under different project management. If they havn't worked on the software for a long time, they may need precious time for refamiliarization to the software, testbeds and tools. Further, a lack of insight into issues related to flight software in its on-orbit environment, may find the developer unprepared for the challenges. The second approach is to train a member of the flight operations team to maintain the spacecraft software. This can prove to be a costly and inflexible solution. The person assigned to this duty may not have enough work to do during a problem free period and may have too much to do when a problem arises. If the person is a talented software engineer, he/she may not enjoy the limited software opportunities available in this position; and may eventually leave for newer technology computer science opportunities. Training replacement flight software personnel can be a difficult and lengthy process. The third approach is to assemble a center of excellence for on-orbit spacecraft software maintenance. Personnel in this specialty center can be managed to support flight software of multiple missions at once. The variety of challenges among a set of on-orbit missions, can result in a dedicated, talented staff which is fully trained and available to support each mission's needs. Such staff are not software developers but are rather spacecraft software systems engineers. The cost to any one mission is extremely low because the software staff works and charges, minimally on missions with no current operations issues; and their professional insight into on-orbit software troubleshooting and maintenance methods ensures low risk, effective and minimal-cost solutions to on-orbit issues.

Shell, Elaine M.↗
NASA NTRS1998

[MODIS Investigation]

The objective of the last six months were: (1) Continue analysis of Hawaii Ocean Time-series (HOT) bio-optical mooring data, and Southern Ocean bio-optical drifter data; (2) Complete development of documentation of MOCEAN algorithms and software for use by MOCEAN team and GLI team; (3) Deploy instrumentation during JGOFS cruises in the Southern Ocean; (4) Participate in test cruise for Fast Repetition Rate (FRR) fluorometer; (5) Continue chemostat experiments on the relationship of fluorescence quantum yield to environmental factors; and (6) Continue to develop and expand browser-based information system for in situ bio-optical data. We are continuing to analyze bio-optical data collected at the Hawaii Ocean Time Series mooring as well as data from bio-optical drifters that were deployed in the Southern Ocean. A draft manuscript has now been prepared and is being revised. A second manuscript is also in preparation that explores the vector wind fields derived from NSCAT measurements. The HOT bio-optical mooring was recovered in December 1997. After retrieving the data, the sensor package was serviced and redeployed. We have begun preliminary analysis of these data, but we have only had the data for 3 weeks. However, all of the data were recovered, and there were no obvious anomalies. We will add second sensor package to the mooring when it is serviced next spring. In addition, Ricardo Letelier is funded as part of the SeaWiFS calibration/validation effort (through a subcontract from the University of Hawaii, Dr. John Porter), and he will be collecting bio-optical and fluorescence data as part of the HOT activity. This will provide additional in situ measurements for MODIS validation. As noted in the previous quarterly report, we have been analyzing data from three bio-optical drifters that were deployed in the Southern Ocean in September 1996. We presented results on chlorophyll and drifter speed. For the 1998 Ocean Sciences meeting, a paper will be presented on this data set, focusing on the diel variations in fluorescence quantum yield. Briefly, there are systematic patterns in the apparent quantum yield of fluorescence (defined as the slope of the line relating fluorescence/chlorophyll and incoming solar radiation). These systematic variations appear to be related to changes in the circulation of the Antarctic Polar Front which force nutrients into the upper ocean. A more complete analysis will be provided in the next Quarterly report.

Abbott, Mark R.↗
NASA NTRS2017

Collaborative Data Publication Utilizing the Open Data Repository's (ODR) Data Publisher

Introduction: For small communities in diverse fields such as astrobiology, publishing and sharing data can be a difficult challenge. While large, homogenous fields often have repositories and existing data standards, small groups of independent researchers have few options for publishing standards and data that can be utilized within their community. In conjunction with teams at NASA Ames and the University of Arizona, the Open Data Repository's (ODR) Data Publisher has been conducting ongoing pilots to assess the needs of diverse research groups and to develop software to allow them to publish and share their data collaboratively. Objectives: The ODR's Data Publisher aims to provide an easy-to-use and implement software tool that will allow researchers to create and publish database templates and related data. The end product will facilitate both human-readable interfaces (web-based with embedded images, files, and charts) and machine-readable interfaces utilizing semantic standards. Characteristics: The Data Publisher software runs on the standard LAMP (Linux, Apache, MySQL, PHP) stack to provide the widest server base available. The software is based on Symfony (www.symfony.com) which provides a robust framework for creating extensible, object-oriented software in PHP. The software interface consists of a template designer where individual or master database templates can be created. A master database template can be shared by many researchers to provide a common metadata standard that will set a compatibility standard for all derivative databases. Individual researchers can then extend their instance of the template with custom fields, file storage, or visualizations that may be unique to their studies. This allows groups to create compatible databases for data discovery and sharing purposes while still providing the flexibility needed to meet the needs of scientists in rapidly evolving areas of research. Research: As part of this effort, a number of ongoing pilot and test projects are currently in progress. The Astrobiology Habitable Environments Database Working Group is developing a shared database standard using the ODR's Data Publisher and has a number of example databases where astrobiology data are shared. Soon these databases will be integrated via the template-based standard. Work with this group helps determine what data researchers in these diverse fields need to share and archive. Additionally, this pilot helps determine what standards are viable for sharing these types of data from internally developed standards to existing open standards such as the Dublin Core (http://dublincore.org) and Darwin Core (http://rs.twdg.org) metadata standards. Further studies are ongoing with the University of Arizona Department of Geosciences where a number of mineralogy databases are being constructed within the ODR Data Publisher system. Conclusions: Through the ongoing pilots and discussions with individual researchers and small research teams, a definition of the tools desired by these groups is coming into focus. As the software development moves forward, the goal is to meet the publication and collaboration needs of these scientists in an unobtrusive and functional way.

easy to use and implement software tool↗
NASA NTRS1985

A view of software management issues

The Software Development Environment (SDE) Panel addressed key programmatic, scope, and structural issues raised by its members and the general audience regarding the proposed software development environment for the Space Station program. The general team approach taken by this group led to a consensus on 18 recommendations to NASA mangament regarding the acquisition and definition of the SDE. This approach was keyed by the initial issues presentation given to the general audience. Additional issues (for a total of 23) were developed by the panelists in their first closed session from which key areas were selected and discussed in open session. These discussions led to key recommendations which are summarized and described.

Manley, J. H.↗
NASA NTRS2006

EOS MLS Science Data Processing System: A Description of Architecture and Capabilities

This paper describes the architecture and capabilities of the Science Data Processing System (SDPS) for the EOS MLS. The SDPS consists of two major components--the Science Computing Facility and the Science Investigator-led Processing System. The Science Computing Facility provides the facilities for the EOS MLS Science Team to perform the functions of scientific algorithm development, processing software development, quality control of data products, and scientific analyses. The Science Investigator-led Processing System processes and reprocesses the science data for the entire mission and delivers the data products to the Science Computing Facility and to the Goddard Space Flight Center Earth Science Distributed Active Archive Center, which archives and distributes the standard science products.

Microwave Limb Sounder (MLS)↗
NASA NTRS2007

Payload Operations Support Team Tools

Payload Operations Support Team Tools is a software system that assists in (1) development and testing of software for payloads to be flown aboard the space shuttles and (2) training of payload customers, flight controllers, and flight crews in payload operations

Askew, Bill↗
NASA NTRS2011

An Update on the VAMOS Extremes Working Group Activities

We review here the progress of the Variability of the American MOnsoon Systems (VAMOS) extremes working group since it was formed in February of 2010. The goals of the working group are to 1) develop an atlas of warm-season extremes over the Americas, 2) evaluate existing and planned simulations, and 3) suggest new model runs to address mechanisms and predictability of extremes. Substantial progress has been made in the development of an extremes atlas based on gridded observations and several reanalysis products including Modern Era Retrospective-Analysis for Research and Applications (MERRA) and Climate Forecast System Reanalysis (CFSR). The status of the atlas, remaining issues and plans for its expansion to include model data will be discussed. This includes the possibility of adding a companion atlas based on station observations based on the software developed under the World Climate Research Programme (WCRP) Expert Team on Climate Change. Detection and Indices (ETCCDI) activity. We will also review progress on relevant research and plans for the use and validation of the atlas results.

Schubert, Siegfried↗
NASA NTRS1993

Telemetry Monitoring and Display Using LabVIEW

The Measurement Technology Center of the Instrumentation Section configures automated data acquisition systems to meet the diverse needs of JPL's experimental research community. These systems are based on personal computers or workstations (Apple, IBM/Compatible, Hewlett-Packard, and Sun Microsystems) and often include integrated data analysis, visualization and experiment control functions in addition to data acquisition capabilities. These integrated systems may include sensors, signal conditioning, data acquisition interface cards, software, and a user interface. Graphical programming is used to simplify configuration of such systems. Employment of a graphical programming language is the most important factor in enabling the implementation of data acquisition, analysis, display and visualization systems at low cost. Other important factors are the use of commercial software packages and off-the-shelf data acquisition hardware where possible. Understanding the experimenter's needs is also critical. An interactive approach to user interface construction and training of operators is also important. One application was created as a result of a competative effort between a graphical programming language team and a text-based C language programming team to verify the advantages of using a graphical programming language approach. With approximately eight weeks of funding over a period of three months, the text-based programming team accomplished about 10% of the basic requirements, while the Macintosh/LabVIEW team accomplished about 150%, having gone beyond the original requirements to simulate a telemetry stream and provide utility programs. This application verified that using graphical programming can significantly reduce software development time. As a result of this initial effort, additional follow-on work was awarded to the graphical programming team.

graphical user interface LabVIEW graphical program↗