Search NASA⌕ Search

SEARCH · Search NASA

Results for “software effort estimations”

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 109 records · Page 6

In-Situ Resource Utilization Modeling of a Lunar Water Processing System

A key element of achieving a sustained surface presence, such as defined in NASA’s Artemis plan, is In-Situ Resource Utilization (ISRU). ISRU is the practice of using local resources to provide mission consumables that reduce system launch mass requirements, and regenerate resources (chiefly, water and oxygen) for propulsion and life support supporting both Lunar and Martian missions. ISRU systems require multiple complex processes, such as excavation, chemical reactors, and electrolysis subsystems that must operate in harmony to optimize the overall system process from beginning to end. The Mission Analysis and Integration Tool (MAIT) was previously developed with MATLAB in FY22 to connect individual subsystem models into a customized, flexible framework for the purpose of technology downselect, optimization, and end-to-end process planning. Beginning in FY24, MAIT was updated and became the capital program in the Systems Engineering and Integration (SE&I) ISRU Modeling and Analysis (SIMA) project. Prior work was leveraged and evolved using MATLAB/Simulink due to its ability to communicate with a vast number of other programming languages and makes up the backbone of data flow between inputs and outputs to the subsystem models. MAIT initially evaluated a suite of ISRU-related technologies, including the water processing Lunar Auger Dryer for ISRU (LADI) system with integrated upstream excavation and downstream electrolysis subsystems. With individual models consolidated, the MAIT tool generated over 5,000 cases during its first round of parametric sweeps on the water processing architecture at multiple production targets; the system analysis produced valuable insight into the optimal LADI geometry that minimized energy demands, estimated effects to cold trap size and radiator requirements, and calculated the power dynamics of the electrolysis unit and liquid oxygen storage volume. Additional efforts are being made to demonstrate the ability to scale ISRU technologies supporting the Space Technology Mission Directorate’s (STMD) commercialization strategy and increase the MAIT software capability. Work is ongoing to handle a wide array of ISRU system models beyond the Lunar environment, e.g. production of propellant for a Martian lander.

Avery Carlson↗

In-Situ Resource Utilization Modeling of a Lunar Water Processing System

A key element of achieving a sustained surface presence, such as defined in NASA’s Artemis plan, is In-Situ Resource Utilization (ISRU). ISRU is the practice of using local resources to provide mission consumables that reduce system launch mass requirements, and regenerate resources (chiefly, water and oxygen) for propulsion and life support supporting both Lunar and Martian missions. ISRU systems require multiple complex processes, such as excavation, chemical reactors, and electrolysis subsystems that must operate in harmony to optimize the overall system process from beginning to end. The Mission Analysis and Integration Tool (MAIT) was previously developed with MATLAB in FY22 to connect individual subsystem models into a customized, flexible framework for the purpose of technology downselect, optimization, and end-to-end process planning. Beginning in FY24, MAIT was updated and became the capital program in the Systems Engineering and Integration (SE&I) ISRU Modeling and Analysis (SIMA) project. Prior work was leveraged and evolved using MATLAB/Simulink due to its ability to communicate with a vast number of other programming languages and makes up the backbone of data flow between inputs and outputs to the subsystem models. MAIT initially evaluated a suite of ISRU-related technologies, including the water processing Lunar Auger Dryer for ISRU (LADI) system with integrated upstream excavation and downstream electrolysis subsystems. With individual models consolidated, the MAIT tool generated over 5,000 cases during its first round of parametric sweeps on the water processing architecture at multiple production targets; the system analysis produced valuable insight into the optimal LADI geometry that minimized energy demands, estimated effects to cold trap size and radiator requirements, and calculated the power dynamics of the electrolysis unit and liquid oxygen storage volume. Additional efforts are being made to demonstrate the ability to scale ISRU technologies supporting the Space Technology Mission Directorate’s (STMD) commercialization strategy and increase the MAIT software capability. Work is ongoing to handle a wide array of ISRU system models beyond the Lunar environment, e.g. production of propellant for a Martian lander.

Avery Carlson↗

Scientific Open-Source Software Is Less Likely to Become Abandoned Than One Might Think! Lessons from Curating a Catalog of Maintained Scientific Software

Scientific software is essential to scientific innovation and in many ways it is distinct from other types of software. Abandoned (or unmaintained), buggy, and hard to use software, a perception often associated with scientific software can hinder scientific progress, yet, in contrast to other types of software, its longevity is poorly understood. Existing data curation efforts are fragmented by science domain and/or are small in scale and lack key attributes. We use large language models to classify public software repositories in World of Code into distinct scientific domains and layers of the software stack, curating a large and diverse collection of over 18,000 scientific software projects. Using this data, we estimate survival models to understand how the domain, infrastructural layer, and other attributes of scientific software affect its longevity. We further obtain a matched sample of non-scientific software repositories and investigate the differences. We find that infrastructural layers, downstream dependencies, mentions of publications, and participants from government are associated with a longer lifespan, while newer projects with participants from academia had shorter lifespan. Against common expectations, scientific projects have a longer lifetime than matched non-scientific open-source software projects. We expect our curated attribute-rich collection to support future research on scientific software and provide insights that may help extend longevity of both scientific and other projects.

Malviya Thakur, Addi [ORNL] (ORCID:000000022681999↗

Design of a modular digital computer system DRL 4 and 5

Design and development efforts for a spaceborne modular computer system are reported. An initial baseline description is followed by an interface design that includes definition of the overall system response to all classes of failure. Final versions for the register level designs for all module types were completed. Packaging, support and control executive software, including memory utilization estimates and design verification plan, were formalized to insure a soundly integrated design of the digital computer system.

Source record↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

Technology Estimating 2: A Process to Determine the Cost and Schedule of Space Technology Research and Development

As a leader in space technology research and development, NASA is continuing in the development of the Technology Estimating process, initiated in 2012, for estimating the cost and schedule of low maturity technology research and development, where the Technology Readiness Level is less than TRL 6. NASA' s Technology Roadmap areas consist of 14 technology areas. The focus of this continuing Technology Estimating effort included four Technology Areas (TA): TA3 Space Power and Energy Storage, TA4 Robotics, TA8 Instruments, and TA12 Materials, to confine the research to the most abundant data pool. This research report continues the development of technology estimating efforts completed during 2013-2014, and addresses the refinement of parameters selected and recommended for use in the estimating process, where the parameters developed are applicable to Cost Estimating Relationships (CERs) used in the parametric cost estimating analysis. This research addresses the architecture for administration of the Technology Cost and Scheduling Estimating tool, the parameters suggested for computer software adjunct to any technology area, and the identification of gaps in the Technology Estimating process.

Cole, Stuart K.↗

Understanding and Predicting the Process of Software Maintenance Releases

One of the major concerns of any maintenance organization is to understand and estimate the cost of maintenance releases of software systems. Planning the next release so as to maximize the increase in functionality and the improvement in quality are vital to successful maintenance management. The objective of this paper is to present the results of a case study in which an incremental approach was used to better understand the effort distribution of releases and build a predictive effort model for software maintenance releases. This study was conducted in the Flight Dynamics Division (FDD) of NASA Goddard Space Flight Center(GSFC). This paper presents three main results: 1) a predictive effort model developed for the FDD's software maintenance release process; 2) measurement-based lessons learned about the maintenance process in the FDD; and 3) a set of lessons learned about the establishment of a measurement-based software maintenance improvement program. In addition, this study provides insights and guidelines for obtaining similar results in other maintenance organizations.

Basili, Victor↗

Space Debris Modeling at NASA

Since the Second European Conference on Space Debris in 1997, the Orbital Debris Program Office at the NASA Johnson Space Center has undertaken a major effort to update and improve the principal software tools employed to model the space debris environment and to evaluate mission risks. NASA's orbital debris engineering model, ORDEM, represents the current and near-term Earth orbital debris population from the largest spacecraft to the smallest debris in a manner which permits spacecraft engineers and experimenters to estimate the frequency and velocity with which a satellite may be struck by debris of different sizes. Using expanded databases and a new program design, ORDEM2000 provides a more accurate environment definition combined with a much broader array of output products in comparison with its predecessor, ORDEM96. Studies of the potential long-term space debris environment are now conducted with EVOLVE 4.0, which incorporates significant advances in debris characterization and breakup modeling. An adjunct to EVOLVE 4.0, GEO EVOLVE has been created to examine debris issues near the geosynchronous orbital regime. In support of NASA Safety Standard 1740.14, which establishes debris mitigation guidelines for all NASA space programs, a set of evaluation tools called the Debris Assessment Software (DAS) is specifically designed for program offices to determine whether they are in compliance with NASA debris mitigation guidelines. DAS 1.5 has recently been released with improved WINDOWS compatibility and graphics functions. DAS 2.0 will incorporate guideline changes in a forthcoming revision to NASA Safety Standard 1740.14. Whereas DAS contains a simplified model to calculate possible risks associated with satellite reentries, NASA's higher fidelity Object Reentry Survival Analysis Tool (ORSAT) has been upgraded to Version 5.0. With the growing awareness of the potential risks posed by uncontrolled satellite reentries to people and property on Earth, the application of both DAS and ORSAT has increased markedly in the past two years.

Johnson, Nicholas L.↗

Advanced Statistical Methods in Spacecraft Flight Software Cost Estimation: Bayesian Regression and Nonlinear Principal Components Analysis to Support System Engineering in the Early Project Lifecycle

This paper provides an overview of the new features and model updates in the upcoming release of the NASA Analogy Software Cost Tool (ASCoT). ASCoT, hosted within the Online NASA Space Estimation Tools (ONSET) on the One NASA Cost Engineering (ONCE) Database, is a web-based tool that provides a suite of estimation tools to support early lifecycle NASA flight software cost analysis. In addition to the traditional parametric flight software costing method COCOMO II, ASCoT contains a Bayesian linear regression to predict total flight software development cost as a function of total spacecraft cost, as well as four analogic methods: k-Nearest Neighbors (kNN) and Clustering models to predict Effort (in work-months) and total source lines of code (SLOC). These methods are designed to work primarily with system-level inputs such as mission type (orbiter, lander, etc.), mission destination (Earth, Inner Planetary, etc.), and the number of instruments and deployables. Nonlinear principal components analysis (NLPCA) is performed to find the principal features of the data composed of both categorical and numerical variables and is necessary prior to defining our analogic methods. Sensitivity analyses and in- and out-of-sample model performance results are presented for the Bayesian CER and the analogic models.

Johnson, James K.↗

Advancing Autonomy in Distributed Space Systems: Insights From on-Orbit Testing with the Starling 1.0 Mission

Autonomous decision-making is crucial for enhancing mission effectiveness in Distributed Space Systems (DSS), particularly in multi-spacecraft operations where communication constraints and mission complexity pose challenges. The Distributed Spacecraft Autonomy (DSA) team at NASA’s Ames Research Center is advancing autonomy in DSS through five key technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. The DSA experiment onboard the Starling 1.0 Mission showcases collaborative resource allocation for multi-point science data collection with four small spacecraft. Autonomy in decision-making is highlighted as a crucial factor for multi-spacecraft missions, enabling spacecraft to operate independently, reducing reliance on ground control. This capability is particularly significant for future deep-space missions, where communication delays and limited data transmission capacity make traditional command and control approaches impractical. This demonstration focuses on a GPS Channel Selection Experiment, leveraging emergent capabilities like "shared sampling" and "simultaneous sampling" to optimize channel selection across the spacecraft swarm. The experiment aims to capture ionospheric phenomena such as the Equatorial Ionization Anomaly and Polar Patches. The DSA system's autonomous reconfiguration ability is showcased, emphasizing its adaptability to natural phenomena without significant integration efforts. The GPS Channel Selection Experiment utilizes a dual-band GPS receiver to estimate plasma density in the ionosphere. Explorative and exploitative channel selections are employed based on the nature of observed phenomena. The performance of DSA algorithms is evaluated in terms of optimal channel allocations and responsiveness to changes in observed features. The DSA Flight Software utilizes the Core Flight System (cFS) framework, ensuring compatibility with the Starling 1.0 flight mission software. DSA showcases results from RTI’s Connext DDS Micro communication middleware, enabling message routing over the Ad-Hoc Network of Starling 1.0. This paper provides a comprehensive overview of the DSA experiment's initial results, emphasizing the advancements in autonomy for Distributed Space Systems and the successful collaboration with the Starling 1.0 mission.

Caleb Ashmore Adams↗

The Database Query Support Processor (QSP)

The number and diversity of databases available to users continues to increase dramatically. Currently, the trend is towards decentralized, client server architectures that (on the surface) are less expensive to acquire, operate, and maintain than information architectures based on centralized, monolithic mainframes. The database query support processor (QSP) effort evaluates the performance of a network level, heterogeneous database access capability. Air Force Material Command's Rome Laboratory has developed an approach, based on ANSI standard X3.138 - 1988, 'The Information Resource Dictionary System (IRDS)' to seamless access to heterogeneous databases based on extensions to data dictionary technology. To successfully query a decentralized information system, users must know what data are available from which source, or have the knowledge and system privileges necessary to find out this information. Privacy and security considerations prohibit free and open access to every information system in every network. Even in completely open systems, time required to locate relevant data (in systems of any appreciable size) would be better spent analyzing the data, assuming the original question was not forgotten. Extensions to data dictionary technology have the potential to more fully automate the search and retrieval for relevant data in a decentralized environment. Substantial amounts of time and money could be saved by not having to teach users what data resides in which systems and how to access each of those systems. Information describing data and how to get it could be removed from the application and placed in a dedicated repository where it belongs. The result simplified applications that are less brittle and less expensive to build and maintain. Software technology providing the required functionality is off the shelf. The key difficulty is in defining the metadata required to support the process. The database query support processor effort will provide quantitative data on the amount of effort required to implement an extended data dictionary at the network level, add new systems, adapt to changing user needs, and provide sound estimates on operations and maintenance costs and savings.

Source record↗

Comparison of Aircraft Conceptual Design Weight Estimation Methods to the Flight Optimization System

Weight estimation is critical in the aircraft conceptual design process. The Flight Optimization System (FLOPS) is an aircraft conceptual design tool that has been the primary aircraft synthesis software used by the Systems Analysis and Concepts Directorate at NASA Langley Research Center. FLOPS includes multiple modules that represent aircraft design disciplines. The FLOPS weight module includes estimation methods that are similar in nature to other regression based aircraft preliminary weight estimation methods, however the FLOPS methods were created to use a minimum number of input parameters to limit the effort required by the designer to apply it. As FLOPS has recently been made publically available, this work compares the FLOPS weight estimation methods with several similar methods with the goal of explaining the differences in FLOPS, providing conceptual designers with a brief introduction to the method before attempting to apply it, and providing a reference to inform the development of future weight estimating relationships. In this paper, the Boeing 737-200 is used as a test case to highlight to differences and similarities in the methods.

Horvath, Bryce L.↗

Bayesian Analysis for Risk Assessment of Selected Medical Events in Support of the Integrated Medical Model Effort

The Exploration Medical Capability project is creating a catalog of risk assessments using the Integrated Medical Model (IMM). The IMM is a software-based system intended to assist mission planners in preparing for spaceflight missions by helping them to make informed decisions about medical preparations and supplies needed for combating and treating various medical events using Probabilistic Risk Assessment. The objective is to use statistical analyses to inform the IMM decision tool with estimated probabilities of medical events occurring during an exploration mission. Because data regarding astronaut health are limited, Bayesian statistical analysis is used. Bayesian inference combines prior knowledge, such as data from the general U.S. population, the U.S. Submarine Force, or the analog astronaut population located at the NASA Johnson Space Center, with observed data for the medical condition of interest. The posterior results reflect the best evidence for specific medical events occurring in flight. Bayes theorem provides a formal mechanism for combining available observed data with data from similar studies to support the quantification process. The IMM team performed Bayesian updates on the following medical events: angina, appendicitis, atrial fibrillation, atrial flutter, dental abscess, dental caries, dental periodontal disease, gallstone disease, herpes zoster, renal stones, seizure, and stroke.

Gilkey, Kelly M.↗

Adaptive Thresholding and Parameter Estimation for PPM

A method of adaptive setting of a threshold level for the detection of pulses in a pulse-position modulation (PPM) free-space optical communication system has been developed. In simplified terms, it is desirable to set a threshold value high enough to greatly reduce the probability (PFA as defined below) of erroneously detecting noise as signal pulses but not so high as to greatly reduce the probability (PD as defined below) of detecting any signal pulses that may be present along with noise. In the present method, the threshold level is varied with time, in response to changing conditions in the optical-communication channel, in an effort to maintain a balance between the aforesaid competing requirements. An integral part of this adaptation scheme is a scheme for estimating key parameters of the optical-communication channel in particular, parameters that describe the fading and total attenuation in the channel, and parameters that characterize spreading of pulses by atmospheric and other effects. The method can be implemented by software processing of digitized optoelectronic-detector output, and has been tested by computational simulation. In the first stage of processing by this method, the digitized values of the detector output during noise-only time slots of received PPM symbols are averaged to obtain a background level. This background level is subtracted from the detector output in the hope of reducing or eliminating the noise component in the remaining signal. (This background level should not be confused with the detection threshold, which is computed in the last stage of processing.) Next, the remaining signal - in effect, a vector of pulse samples - is normalized by dividing it by its L1 norm (in general, the L1 norm of a vector is defined as the sum of absolute magnitudes of its orthogonal components).

Arabshahi, Payman↗

Meteor44 Video Meteor Photometry

Meteor44 is a software system developed at MSFC for the calibration and analysis of video meteor data. The dynamic range of the (8bit) video data is extended by approximately 4 magnitudes for both meteors and stellar images using saturation compensation. Camera and lens specific saturation compensation coefficients are derived from artificial variable star laboratory measurements. Saturation compensation significantly increases the number of meteors with measured intensity and improves the estimation of meteoroid mass distribution. Astrometry is automated to determine each image's plate coefficient using appropriate star catalogs. The images are simultaneously intensity calibrated from the contained stars to determine the photon sensitivity and the saturation level referenced above the atmosphere. The camera s spectral response is used to compensate for stellar color index and typical meteor spectra in order to report meteor light curves in traditional visual magnitude units. Recent efforts include improved camera calibration procedures, long focal length 'streak' meteor photometry and two-station track determination. Meteor44 has been used to analyze data from the 2001, 2002 and 2003 MSFC Leonid observational campaigns as well as several lesser showers. The software is interactive and can be demonstrated using data from recent Leonid campaigns.

Swift, Wesley R.↗

Meteor44 Video Meteor Photometry

Meteor44 is a software system developed at MSFC for the calibration and analysis of video meteor data. The dynamic range of the (8bit) video data is extended by approximately 4 magnitudes for both meteors and stellar images using saturation compensation. Camera and lens specific saturation compensation coefficients are derived from artificial variable star laboratory measurements. Saturation compensation significantly increases the number of meteors with measured intensity and improves the estimation of meteoroid mass distribution. Astrometry is automated to determine each image s plate coefficient using appropriate star catalogs. The images are simultaneously intensity calibrated from the contained stars to determine the photon sensitivity and the saturation level referenced above the atmosphere. The camera s spectral response is used to compensate for stellar color index and typical meteor spectra in order to report meteor light curves in traditional visual magnitude units. Recent efforts include improved camera calibration procedures, long focal length "streak" meteor photome&y and two-station track determination. Meteor44 has been used to analyze data from the 2001.2002 and 2003 MSFC Leonid observational campaigns as well as several lesser showers. The software is interactive and can be demonstrated using data from recent Leonid campaigns.

Swift, Wesley R.↗

Object-oriented productivity metrics

Software productivity metrics are useful for sizing and costing proposed software and for measuring development productivity. Estimating and measuring source lines of code (SLOC) has proven to be a bad idea because it encourages writing more lines of code and using lower level languages. Function Point Analysis is an improved software metric system, but it is not compatible with newer rapid prototyping and object-oriented approaches to software development. A process is presented here for counting object-oriented effort points, based on a preliminary object-oriented analysis. It is proposed that this approach is compatible with object-oriented analysis, design, programming, and rapid prototyping. Statistics gathered on actual projects are presented to validate the approach.

Connell, John L.↗

Recent Progress Towards Predicting Aircraft Ground Handling Performance

The significant progress which has been achieved in development of aircraft ground handling simulation capability is reviewed and additional improvements in software modeling identified. The problem associated with providing necessary simulator input data for adequate modeling of aircraft tire/runway friction behavior is discussed and efforts to improve this complex model, and hence simulator fidelity, are described. Aircraft braking performance data obtained on several wet runway surfaces is compared to ground vehicle friction measurements and, by use of empirically derived methods, good agreement between actual and estimated aircraft braking friction from ground vehilce data is shown. The performance of a relatively new friction measuring device, the friction tester, showed great promise in providing data applicable to aircraft friction performance. Additional research efforts to improve methods of predicting tire friction performance are discussed including use of an instrumented tire test vehicle to expand the tire friction data bank and a study of surface texture measurement techniques.

Yager, T. J.↗