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.

SourceResearch connectionFrom yearThrough year

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

At least 649 records · Page 36

All sources NASA NTRS DOE OSTI

NASA NTRS2013

Unique Challenges Testing SDRs for Space

This paper describes the approach used by the Space Communication and Navigation (SCaN) Testbed team to qualify three Software Defined Radios (SDR) for operation in space and the characterization of the platform to enable upgrades on-orbit. The three SDRs represent a significant portion of the new technologies being studied on board the SCAN Testbed, which is operating on an external truss on the International Space Station (ISS). The SCaN Testbed provides experimenters an opportunity to develop and demonstrate experimental waveforms and applications for communication, networking, and navigation concepts and advance the understanding of developing and operating SDRs in space. Qualifying a Software Defined Radio for the space environment requires additional consideration versus a hardware radio. Tests that incorporate characterization of the platform to provide information necessary for future waveforms, which might exercise extended capabilities of the hardware, are needed. The development life cycle for the radio follows the software development life cycle, where changes can be incorporated at various stages of development and test. It also enables flexibility to be added with minor additional effort. Although this provides tremendous advantages, managing the complexity inherent in a software implementation requires a testing beyond the traditional hardware radio test plan. Due to schedule and resource limitations and parallel development activities, the subsystem testing of the SDRs at the vendor sites was primarily limited to typical fixed transceiver type of testing. NASA's Glenn Research Center (GRC) was responsible for the integration and testing of the SDRs into the SCaN Testbed system and conducting the investigation of the SDR to advance the technology to be accepted by missions. This paper will describe the unique tests that were conducted at both the subsystem and system level, including environmental testing, and present results. For example, test waveforms were developed to measure the gain of the transmit system across the tunable frequency band. These were used during thermal vacuum testing to enable characterization of the integrated system in the wide operational temperature range of space. Receive power indicators were used for Electromagnetic Interference tests (EMI) to understand the platform's susceptibility to external interferers independent of the waveform. Additional approaches and lessons learned during the SCaN Testbed subsystem and system level testing will be discussed that may help future SDR integrators.

transmitters receivers↗

NASA NTRS2010

A Flight-Calibrated Methodology for Determination of Cassini Thruster On-Times for Reaction Wheel Biases

The Cassini spacecraft, the largest and most complex interplanetary spacecraft ever built, continues to undertake unique scientific observations of planet Saturn, Titan, Enceladus, and other moons of the ring world. In order to maintain a stable attitude during the course of its mission, this three-axis stabilized spacecraft uses two different control systems: the Reaction Control System (or RCS) and the Reaction Wheel Assembly (RWA) control system. In the course of its mission, Cassini performs numerous reaction wheel momentum biases (or unloads) using its reaction control thrusters. The use of the RCS thrusters often imparts undesired velocity changes (delta Vs) on the spacecraft and it is crucial for Cassini navigation and attitude control teams to be able to, quickly but accurately, predict the hydrazine usage and delta V vector in Earth Mean Equatorial (J2000) inertial coordinates for reaction wheel bias events, without actually having to spend time and resources simulating the event in a dynamic or hardware-in-the-loop simulation environments. The flight-calibrated methodology described in this paper, and the ground software developed thereof, are designed to provide the RCS thruster on-times, with acceptable accuracy and without any form of dynamic simulation, for reaction wheel biases, along with the hydrazine usage and the delta V in EME-2000 inertial frame.

Reaction Control System↗

NASA NTRS1985

NASA's Pilot Land Data System development program

The NASA Pilot Land Data System (PLDS) project is intended to enhance the effectiveness of data processing capabilities used by researchers applying remote sensing data in land science research. Two sites in the centerminous U.S. have been selected as study areas scanned by Landsat, Nimbus and GOES instruments. The data will be analyzed by teams of researchers representing different fields of expertise. The PLDS program will explore data management, networking and communications, system access capabilities, land analysis software, special processes and overall systems engineerng. The data will be processed by researchers working interactively through remote supermicrocomputer workstations using a variety of operating systems and on-site software capabilities.

Price, R. D.↗

NASA NTRS1990

National plan to enhance aviation safety through human factors improvements

The purpose of this section of the plan is to establish a development and implementation strategy plan for improving safety and efficiency in the Air Traffic Control (ATC) system. These improvements will be achieved through the proper applications of human factors considerations to the present and future systems. The program will have four basic goals: (1) prepare for the future system through proper hiring and training; (2) develop a controller work station team concept (managing human errors); (3) understand and address the human factors implications of negative system results; and (4) define the proper division of responsibilities and interactions between the human and the machine in ATC systems. This plan addresses six program elements which together address the overall purpose. The six program elements are: (1) determine principles of human-centered automation that will enhance aviation safety and the efficiency of the air traffic controller; (2) provide new and/or enhanced methods and techniques to measure, assess, and improve human performance in the ATC environment; (3) determine system needs and methods for information transfer between and within controller teams and between controller teams and the cockpit; (4) determine how new controller work station technology can optimally be applied and integrated to enhance safety and efficiency; (5) assess training needs and develop improved techniques and strategies for selection, training, and evaluation of controllers; and (6) develop standards, methods, and procedures for the certification and validation of human engineering in the design, testing, and implementation of any hardware or software system element which affects information flow to or from the human.

Foushee, Clay↗

NASA NTRS1989

Assessment team report on flight-critical systems research at NASA Langley Research Center

The quality, coverage, and distribution of effort of the flight-critical systems research program at NASA Langley Research Center was assessed. Within the scope of the Assessment Team's review, the research program was found to be very sound. All tasks under the current research program were at least partially addressing the industry needs. General recommendations made were to expand the program resources to provide additional coverage of high priority industry needs, including operations and maintenance, and to focus the program on an actual hardware and software system that is under development.

Siewiorek, Daniel P.↗

NASA NTRS2017

Introduction to the Navigation Team: Johnson Space Center EG6 Internship

The EG6 navigation team at NASA Johnson Space Center, like any team of engineers, interacts with the engineering process from beginning to end; from exploring solutions to a problem, to prototyping and studying the implementations, all the way to polishing and verifying a final flight-ready design. This summer, I was privileged enough to gain exposure to each of these processes, while also getting to truly experience working within a team of engineers. My summer can be broken up into three projects: i) Initial study and prototyping: investigating a manual navigation method that can be utilized onboard Orion in the event of catastrophic failure of navigation systems; ii) Finalizing and verifying code: altering a software routine to improve its robustness and reliability, as well as designing unit tests to verify its performance; and iii) Development of testing equipment: assisting in developing and integrating of a high-fidelity testbed to verify the performance of software and hardware.

Gualdoni, Matthew↗

NASA NTRS2011

ISS Operations Cost Reductions Through Automation of Real-Time Planning Tasks

In 2008 the Johnson Space Center s Mission Operations Directorate (MOD) management team challenged their organization to find ways to reduce the costs of International Space station (ISS) console operations in the Mission Control Center (MCC). Each MOD organization was asked to identify projects that would help them attain a goal of a 30% reduction in operating costs by 2012. The MOD Operations and Planning organization responded to this challenge by launching several software automation projects that would allow them to greatly improve ISS console operations and reduce staffing and operating costs. These projects to date have allowed the MOD Operations organization to remove one full time (7 x 24 x 365) ISS console position in 2010; with the plan of eliminating two full time ISS console support positions by 2012. This will account for an overall 10 EP reduction in staffing for the Operations and Planning organization. These automation projects focused on utilizing software to automate many administrative and often repetitive tasks involved with processing ISS planning and daily operations information. This information was exchanged between the ground flight control teams in Houston and around the globe, as well as with the ISS astronaut crew. These tasks ranged from managing mission plan changes from around the globe, to uploading and downloading information to and from the ISS crew, to even more complex tasks that required multiple decision points to process the data, track approvals and deliver it to the correct recipient across network and security boundaries. The software solutions leveraged several different technologies including customized web applications and implementation of industry standard web services architecture between several planning tools; as well as a engaging a previously research level technology (TRL 2-3) developed by Ames Research Center (ARC) that utilized an intelligent agent based system to manage and automate file traffic flow, archiving f data, and generating console logs. This technology called OCAMS (OCA (Orbital Communication System) Management System), is now considered TRL level 9 and is in daily use in the Mission Control Center in support of ISS operations. These solutions have not only allowed for improved efficiency on console; but since many of the previously manual data transfers are now automated, many of the human error prone steps have been removed, and the quality of the planning products has improved tremendously. This has also allowed our Planning Flight Controllers more time to focus on the abstract areas of the job, (like the complexities of planning a mission for 6 international crew members with a global planning team), instead of being burdened with the administrative tasks that took significant time each console shift to process. The resulting automation solutions have allowed the Operations and Planning organization to realize significant cost savings for the ISS program through 2020 and many of these solutions could be a viable

Hall, Timothy A.↗

NASA NTRS1993

Operator Performance Support System (OPSS)

In the complex and fast reaction world of military operations, present technologies, combined with tactical situations, have flooded the operator with assorted information that he is expected to process instantly. As technologies progress, this flow of data and information have both guided and overwhelmed the operator. However, the technologies that have confounded many operators today can be used to assist him -- thus the Operator Performance Support Team. In this paper we propose an operator support station that incorporates the elements of Video and Image Databases, productivity Software, Interactive Computer Based Training, Hypertext/Hypermedia Databases, Expert Programs, and Human Factors Engineering. The Operator Performance Support System will provide the operator with an integrating on-line information/knowledge system that will guide expert or novice to correct systems operations. Although the OPSS is being developed for the Navy, the performance of the workforce in today's competitive industry is of major concern. The concepts presented in this paper which address ASW systems software design issues are also directly applicable to industry. the OPSS will propose practical applications in how to more closely align the relationships between technical knowledge and equipment operator performance.

Conklin, Marlen Z.↗

NASA NTRS1995

Client/server study

The goal of this project is to find cost-effective and efficient strategies/solutions to integrate existing databases, manage network, and improve productivity of users in a move towards client/server and Integrated Desktop Environment (IDE) at NASA LeRC. The project consisted of two tasks as follows: (1) Data collection, and (2) Database Development/Integration. Under task 1, survey questionnaires and a database were developed. Also, an investigation on commercially available tools for automated data-collection and net-management was performed. As requirements evolved, the main focus has been task 2 which involved the following subtasks: (1) Data gathering/analysis of database user requirements, (2) Database analysis and design, making recommendations for modification of existing data structures into relational database or proposing a common interface to access heterogeneous databases(INFOMAN system, CCNS equipment list, CCNS software list, USERMAN, and other databases), (3) Establishment of a client/server test bed at Central State University (CSU), (4) Investigation of multi-database integration technologies/ products for IDE at NASA LeRC, and (5) Development of prototypes using CASE tools (Object/View) for representative scenarios accessing multi-databases and tables in a client/server environment. Both CSU and NASA LeRC have benefited from this project. CSU team investigated and prototyped cost-effective/practical solutions to facilitate NASA LeRC move to a more productive environment. CSU students utilized new products and gained skills that could be a great resource for future needs of NASA.

Dezhgosha, Kamyar↗

NASA NTRS1996

The Empirical Investigation of Perspective-Based Reading

We consider reading techniques a fundamental means of achieving high quality software. Due to the lack of research in this area, we are experimenting with the application and comparison of various reading techniques. This paper deals with our experiences with Perspective-Based Reading (PBR), a particular reading technique for requirements documents. The goal of PBR is to provide operational scenarios where members of a review team read a document from a particular perspective (e.g., tester, developer, user). Our assumption is that the combination of different perspectives provides better coverage of the document than the same number of readers using their usual technique.

Basili, Victor R.↗

NASA NTRS2013

Robotic Technology Development at Ames: The Intelligent Robotics Group and Surface Telerobotics

Future human missions to the Moon, Mars, and other destinations offer many new opportunities for exploration. But, astronaut time will always be limited and some work will not be feasible for humans to do manually. Robots, however, can complement human explorers, performing work autonomously or under remote supervision from Earth. Since 2004, the Intelligent Robotics Group has been working to make human-robot interaction efficient and effective for space exploration. A central focus of our research has been to develop and field test robots that benefit human exploration. Our approach is inspired by lessons learned from the Mars Exploration Rovers, as well as human spaceflight programs, including Apollo, the Space Shuttle, and the International Space Station. We conduct applied research in computer vision, geospatial data systems, human-robot interaction, planetary mapping and robot software. In planning for future exploration missions, architecture and study teams have made numerous assumptions about how crew can be telepresent on a planetary surface by remotely operating surface robots from space (i.e. from a flight vehicle or deep space habitat). These assumptions include estimates of technology maturity, existing technology gaps, and likely operational and functional risks. These assumptions, however, are not grounded by actual experimental data. Moreover, no crew-controlled surface telerobotic system has yet been fully tested, or rigorously validated, through flight testing. During Summer 2013, we conducted a series of tests to examine how astronauts in the International Space Station (ISS) can remotely operate a planetary rover across short time delays. The tests simulated portions of a proposed human-robotic Lunar Waypoint mission, in which astronauts in lunar orbit remotely operate a planetary rover on the lunar Farside to deploy a radio telescope array. We used these tests to obtain baseline-engineering data.

robotics↗

NASA NTRS2017

Lessons Learned from OSIRIS-Rex Autonomous Navigation Using Natural Feature Tracking

The Origins, Spectral Interpretation, Resource Identification, Security-Regolith Explorer (Osiris-REx) spacecraft is scheduled to launch in September, 2016 to embark on an asteroid sample return mission. It is expected to rendezvous with the asteroid, Bennu, navigate to the surface, collect a sample (July 20), and return the sample to Earth (September 23). The original mission design called for using one of two Flash Lidar units to provide autonomous navigation to the surface. Following Preliminary design and initial development of the Lidars, reliability issues with the hardware and test program prompted the project to begin development of an alternative navigation technique to be used as a backup to the Lidar. At the critical design review, Natural Feature Tracking (NFT) was added to the mission. NFT is an onboard optical navigation system that compares observed images to a set of asteroid terrain models which are rendered in real-time from a catalog stored in memory on the flight computer. Onboard knowledge of the spacecraft state is then updated by a Kalman filter using the measured residuals between the rendered reference images and the actual observed images. The asteroid terrain models used by NFT are built from a shape model generated from observations collected during earlier phases of the mission and include both terrain shape and albedo information about the asteroid surface. As a result, the success of NFT is highly dependent on selecting a set of topographic features that can be both identified during descent as well as reliably rendered using the shape model data available. During development, the OSIRIS-REx team faced significant challenges in developing a process conducive to robust operation. This was especially true for terrain models to be used as the spacecraft gets close to the asteroid and higher fidelity models are required for reliable image correlation. This paper will present some of the challenges and lessons learned from the development of the NFT system which includes not just the flight hardware and software but the development of the terrain models used to generate the onboard rendered images.

Navigation↗

NASA NTRS2021

Commanding Curiosity from the Couch: MSL Remote Operations, Challenges, and Path Ahead

This paper describes how the Mars ScienceLaboratory (MSL) project prepared for and successfully beganCuriosity rover Mars operations from their homes in responseto the COVID-19 work-from-home orders. In a very shortperiod, the team developed procedures and executed a remoteoperations readiness test in parallel with the team's support fornominal operations. Continuing regular rover operations withan entirely remote team had not previously been consideredfeasible due to a variety of factors. These included both thehuman factors, such as multiple concurrent person-to-personinteractions of the uplink planning team, as well as technicalfactors, such as reliance on powerful workstations dedicated tographically intensive software tools used for planning. The testwas conducted on March 12th, with both the downlink anduplink teams successfully simulating a near full planning day.The JPL administration announced the transition to mandatorytelework on Monday, March 16th. MSL stood down the uplinkplanning originally scheduled for the next day while downlinkcontinued monitoring the rover. Full operations then resumedper schedule with nearly the entire operations team teleworkingon Friday, March 20th, during which the team planned roveractivities for three Martian days (sols). These activities includedthe successful drilling of the "Edinburgh" rock target, a highlycomplex contact science activity.As of October 1st, 2020, the Mars Science Laboratory missionoperations team has conducted 88 remote tactical uplink shiftsfor a total of 190 sols of planned rover activity, which accountsfor more than 6% of the mission to date. In this period the roverhas completed four drilling campaigns and driven over 1150meters towards its next major science target – a sulfate bearinggeologic unit at the foot of Mount Sharp. Success has not beenwithout its challenges. Many of these have been addressed whileothers will remain in some form until the team can safely returnto JPL, which in turn is the largest challenge for the future.

Stroupe, Ashley↗

NASA NTRS2018

GMI-IPS: Python Processing Software for Aircraft Campaigns

NASA's Atmospheric Tomography Mission (ATom) seeks to understand the impact of anthropogenic air pollution on gases in the Earth's atmosphere. Four flight campaigns are being deployed on a seasonal basis to establish a continuous global-scale data set intended to improve the representation of chemically reactive gases in global atmospheric chemistry models. The Global Modeling Initiative (GMI), is creating chemical transport simulations on a global scale for each of the ATom flight campaigns. To meet the computational demands required to translate the GMI simulation data to grids associated with the flights from the ATom campaigns, the GMI ICARTT Processing Software (GMI-IPS) has been developed and is providing key functionality for data processing and analysis in this ongoing effort. The GMI-IPS is written in Python and provides computational kernels for data interpolation and visualization tasks on GMI simulation data. A key feature of the GMI-IPS, is its ability to read ICARTT files, a text-based file format for airborne instrument data, and extract the required flight information that defines regional and temporal grid parameters associated with an ATom flight. Perhaps most importantly, the GMI-IPS creates ICARTT files containing GMI simulated data, which are used in collaboration with ATom instrument teams and other modeling groups. The initial main task of the GMI-IPS is to interpolate GMI model data to the finer temporal resolution (1-10 seconds) of a given flight. The model data includes basic fields such as temperature and pressure, but the main focus of this effort is to provide species concentrations of chemical gases for ATom flights. The software, which uses parallel computation techniques for data intensive tasks, linearly interpolates each of the model fields to the time resolution of the flight. The temporally interpolated data is then saved to disk, and is used to create additional derived quantities. In order to translate the GMI model data to the spatial grid of the flight path as defined by the pressure, latitude, and longitude points at each flight time record, a weighted average is then calculated from the nearest neighbors in two dimensions (latitude, longitude). Using SciPya's Regular Grid Interpolator, interpolation functions are generated for the GMI model grid and the calculated weighted averages. The flight path points are then extracted from the ATom ICARTT instrument file, and are sent to the multi-dimensional interpolating functions to generate GMI field quantities along the spatial path of the flight. The interpolated field quantities are then written to a ICARTT data file, which is stored for further manipulation. The GMI-IPS is aware of a generic ATom ICARTT header format, containing basic information for all flight campaigns. The GMI-IPS includes logic to edit metadata for the derived field quantities, as well as modify the generic header data such as processing dates and associated instrument files. The ICARTT interpolated data is then appended to the modified header data, and the ICARTT processing is complete for the given flight and ready for collaboration. The output ICARTT data adheres to the ICARTT file format standards V1.1. The visualization component of the GMI-IPS uses Matplotlib extensively and has several functions ranging in complexity. First, it creates a model background curtain for the flight (time versus model eta levels) with the interpolated flight data superimposed on the curtain. Secondly, it creates a time-series plot of the interpolated flight data. Lastly, the visualization component creates averaged 2D model slices (longitude versus latitude) with overlaid flight track circles at key pressure levels. The GMI-IPS consists of a handful of classes and supporting functionality that have been generalized to be compatible with any ICARTT file that adheres to the base class definition. The base class represents a generic ICARTT entry, only defining a single time entry and 3D spatial positioning parameters. Other classes inherit from this base class; several classes for input ICARTT instrument files, which contain the necessary flight positioning information as a basis for data processing, as well as other classes for output ICARTT files, which contain the interpolated model data. Utility classes provide functionality for routine procedures such as: comparing field names among ICARTT files, reading ICARTT entries from a data file and storing them in data structures, and returning a reduced spatial grid based on a collection of ICARTT entries. Although the GMI-IPS is compatible with GMI model data, it can be adapted with reasonable effort for any simulation that creates Hierarchical Data Format (HDF) files. The same can be said of its adaptability to ICARTT files outside of the context of the ATom mission. The GMI-IPS contains just under 30,000 lines of code, eight classes, and a dozen drivers and utility programs. It is maintained with GIT source code management and has been used to deliver processed GMI model data for the ATom campaigns that have taken place to date.

Damon, M. R.↗

NASA NTRS1992

Collaborative research on V/STOL control system/cockpit display tradeoffs under the NASA/MOD joint aeronautical program

Summarized here are activities that have taken place from 1979 to the present in a collaborative program between NASA Ames Research Center and the Royal Aerospace Establishment (now Defence Research Agency), Bedford on flight control system and cockpit display tradeoffs for low-speed and hover operations of future V/STOL aircraft. This program was created as Task 8A of the Joint Aeronautical Program between NASA in the United States and the Ministry of Defence (Procurement Executive) in the United Kingdom. The program was initiated based on a recognition by both parties of the strengths of the efforts of their counterparts and a desire to participate jointly in future simulation and flight experiments. In the ensuing years, teams of NASA and RAE engineers and pilots have participated in each other's simulation experiments to evaluate control and display concepts and define design requirements for research aircraft. Both organizations possess Harrier airframes that have undergone extensive modification to provide in-flight research capabilities in the subject areas. Both NASA and RAE have profited by exchanges of control/display concepts, design criteria, fabrication techniques, software development and validation, installation details, and ground and flight clearance techniques for their respective aircraft. This collaboration has permitted the two organizations to achieve jointly substantially more during the period than if they had worked independently. The two organizations are now entering the phase of flight research for the collaborative program as currently defined.

Franklin, J. A.↗

NASA NTRS1997

NURBS-Based Geometry for Integrated Structural Analysis

This grant was initiated in April 1993 and completed in September 1996. The primary goal of the project was to exploit the emerging defacto CAD standard of Non- Uniform Rational B-spline (NURBS) based curve and surface geometry to integrate and streamline the process of turbomachinery structural analysis. We focused our efforts on critical geometric modeling challenges typically posed by the requirements of structural analysts. We developed a suite of software tools that facilitate pre- and post-processing of NURBS-based turbomachinery blade models for finite element structural analyses. We also developed tools to facilitate the modeling of blades in their manufactured (or cold) state based on nominal operating shape and conditions. All of the software developed in the course of this research is written in the C++ language using the Iris Inventor 3D graphical interface tool-kit from Silicon Graphics. In addition to enhanced modularity, improved maintainability, and efficient prototype development, this design facilitates the re-use of code developed for other NASA projects and provides a uniform and professional 'look and feel' for all applications developed by the Iowa State Team.

Oliver, James H.↗

NASA NTRS2023

Trades, Architecture, and Design of the Joint Augmented Reality Visual Informatics System (Joint AR) Product

Future expeditions will enable exploration and study of the planetary surfaces of the Moon and Mars by performing extravehicular activity (EVA) operations. Present-day International Space Station (ISS) EVA operations require an intricate choreography of crew, space suits, tools, systems, and flight teams to plan, train, and execute with limited advanced informatics. In this paper, the Joint Augmented Reality Visual Informatics System (Joint AR) project team at NASA Johnson Space Center (JSC) characterizes the design space for developing a modular augmented reality (AR) device for a spacesuit form factor that can support crew decision-making for EVA. The Joint AR product was defined via trade studies and market analysis of previous EVA display efforts, various AR components such as optics, commercial AR systems, light engines, data interfaces, and graphics engine software. This paper outlines the defining architectural design decisions, including safety criticality considerations, interfaces, and computer architectures. The outcomes of these studies result in a prototype design which is defined here as the Joint AR product. This work aims to enable a community-wide discussion toward realizing necessary suit-compatible AR features and capabilities for future missions.

Paromita Mitra↗

NASA NTRS2023

Trades, Architecture, and Design of the Joint Augmented Reality Visual Informatics System (Joint AR) Product

Paromita Mitra↗