Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Technical Languages”

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

A Scalable Analysis Toolkit

The Scalable Analysis Toolkit (SAT) project aimed to demonstrate that it is feasible and useful to statically detect software bugs in very large systems. The technical focus of the project was on a relatively new class of constraint-based techniques for analysis software, where the desired facts about programs (e.g., the presence of a particular bug) are phrased as constraint problems to be solved. At the beginning of this project, the most successful forms of formal software analysis were limited forms of automatic theorem proving (as exemplified by the analyses used in language type systems and optimizing compilers), semi-automatic theorem proving for full verification, and model checking. With a few notable exceptions these approaches had not been demonstrated to scale to software systems of even 50,000 lines of code. Realistic approaches to large-scale software analysis cannot hope to make every conceivable formal method scale. Thus, the SAT approach is to mix different methods in one application by using coarse and fast but still adequate methods at the largest scales, and reserving the use of more precise but also more expensive methods at smaller scales for critical aspects (that is, aspects critical to the analysis problem under consideration) of a software system. The principled method proposed for combining a heterogeneous collection of formal systems with different scalability characteristics is mixed constraints. This idea had been used previously in small-scale applications with encouraging results: using mostly coarse methods and narrowly targeted precise methods, useful information (meaning the discovery of bugs in real programs) was obtained with excellent scalability.

Aiken, Alexander↗

Human factors issues in the use of artificial intelligence in air traffic control. October 1990 Workshop

The objective of the workshop was to explore the role of human factors in facilitating the introduction of artificial intelligence (AI) to advanced air traffic control (ATC) automation concepts. AI is an umbrella term which is continually expanding to cover a variety of techniques where machines are performing actions taken based upon dynamic, external stimuli. AI methods can be implemented using more traditional programming languages such as LISP or PROLOG, or they can be implemented using state-of-the-art techniques such as object-oriented programming, neural nets (hardware or software), and knowledge based expert systems. As this technology advances and as increasingly powerful computing platforms become available, the use of AI to enhance ATC systems can be realized. Substantial efforts along these lines are already being undertaken at the FAA Technical Center, NASA Ames Research Center, academic institutions, industry, and elsewhere. Although it is clear that the technology is ripe for bringing computer automation to ATC systems, the proper scope and role of automation are not at all apparent. The major concern is how to combine human controllers with computer technology. A wide spectrum of options exists, ranging from using automation only to provide extra tools to augment decision making by human controllers to turning over moment-by-moment control to automated systems and using humans as supervisors and system managers. Across this spectrum, it is now obvious that the difficulties that occur when tying human and automated systems together must be resolved so that automation can be introduced safely and effectively. The focus of the workshop was to further explore the role of injecting AI into ATC systems and to identify the human factors that need to be considered for successful application of the technology to present and future ATC systems.

Hockaday, Stephen↗

Controlled flexibility in technical editing - The levels-of-edit concept at JPL

The levels-of-edit concept, which can be used to specify the amount of editorial effort involved in the preparation of a manuscript for publication, is discussed. Nine types of editing are identified and described. These include coordination edit (preparing estimates, gathering cost data, monitoring production processes), policy edit, integrity edit (making sure that parts of a publication match in a physical or numerical sense), screening edit (ensuring that the quality of camera-ready copy is sufficient for external publication), copy clarification edit, format edit, mechanical style edit, language edit, and substantive edit (reviewing the manuscript for content coherence, emphasis, subordination and parallelism). These functions are grouped into five levels of edit. An edit-level number is assigned to each manuscript, providing a quantitative and qualitative indicator of the editing to be done which is clearly understood by authors, managers, and editors alike. In addition, clear boundaries are drawn between normal and extraordinary editing tasks. Individual organizations will group various edits in different ways to reflect their needs and priorities; the essential element of the system is unambiguous definition and coding of the types and amount of work to be done.

Buehler, M. F.↗

The ATLAS integrated structural analysis and design software system

The ATLAS system provides an extensive set of integrated technical computer-program modules for the analysis and design of general structural configurations, as well as capabilities that are particularly suited for the aeroelastic design of flight vehicles. The system is based on the stiffness formulation of the finite element structural analysis method and can be executed in batch and interactive computing environments on CDC 6600/CYBER computers. Problem-definition input data are written in an engineering-oriented language using a free field format. Input-data default values, generation options, and data quality checks provided by the preprocessors minimize the amount of data and flowtime for problem definition/verfication. Postprocessors allow selected input and calculated data to be extracted, manipulated, and displayed via on-line and off-line prints or plots for monitoring and verifying problem solutions. The sequence and mode of execution of selected program modules are controlled by a common user-oriented language.

Dreisbach, R. L.↗

Generic Kalman Filter Software

The Generic Kalman Filter (GKF) software provides a standard basis for the development of application-specific Kalman-filter programs. Historically, Kalman filters have been implemented by customized programs that must be written, coded, and debugged anew for each unique application, then tested and tuned with simulated or actual measurement data. Total development times for typical Kalman-filter application programs have ranged from months to weeks. The GKF software can simplify the development process and reduce the development time by eliminating the need to re-create the fundamental implementation of the Kalman filter for each new application. The GKF software is written in the ANSI C programming language. It contains a generic Kalman-filter-development directory that, in turn, contains a code for a generic Kalman filter function; more specifically, it contains a generically designed and generically coded implementation of linear, linearized, and extended Kalman filtering algorithms, including algorithms for state- and covariance-update and -propagation functions. The mathematical theory that underlies the algorithms is well known and has been reported extensively in the open technical literature. Also contained in the directory are a header file that defines generic Kalman-filter data structures and prototype functions and template versions of application-specific subfunction and calling navigation/estimation routine code and headers. Once the user has provided a calling routine and the required application-specific subfunctions, the application-specific Kalman-filter software can be compiled and executed immediately. During execution, the generic Kalman-filter function is called from a higher-level navigation or estimation routine that preprocesses measurement data and post-processes output data. The generic Kalman-filter function uses the aforementioned data structures and five implementation- specific subfunctions, which have been developed by the user on the basis of the aforementioned templates. The GKF software can be used to develop many different types of unfactorized Kalman filters. A developer can choose to implement either a linearized or an extended Kalman filter algorithm, without having to modify the GKF software. Control dynamics can be taken into account or neglected in the filter-dynamics model. Filter programs developed by use of the GKF software can be made to propagate equations of motion for linear or nonlinear dynamical systems that are deterministic or stochastic. In addition, filter programs can be made to operate in user-selectable "covariance analysis" and "propagation-only" modes that are useful in design and development stages.

Lisano, Michael E., II↗

SeaWiFS technical report series. Volume 10: Modeling of the SeaWiFS solar and lunar observations

Post-launch stability monitoring of the Sea-viewing Wide Field-of-view Sensor (SeaWifs) will include periodic sweeps of both an onboard solar diffuser plate and the moon. The diffuser views will provide short-term checks and the lunar views will monitor long-term trends in the instrument's radiometric stability. Models of the expected sensor response to these observations were created on the SeaWiFS computer at the National Aeronautics and Space Administration's (NASA) Goddard Space Flight Center (GSFC) using the Interactive Data Language (IDL) utility with a graphical user interface (GUI). The solar model uses the area of intersecting circles to simulate the ramping of sensor response while viewing the diffuser. This model is compared with preflight laboratory scans of the solar diffuser. The lunar model reads a high-resolution lunar image as input. The observations of the moon are simulated with a bright target recovery algorithm that includes ramping and ringing functions. Tests using the lunar model indicate that the integrated radiance of the entire lunar surface provides a more stable quantity than the mean of radiances from centralized pixels. The lunar model is compared to ground-based scans by the SeaWiFS instrument of a full moon in December 1992. Quality assurance and trend analyses routines for calibration and for telemetry data are also discussed.

Woodward, Robert H.↗

A decade of telerobotics in rehabilitation: Demonstrated utility blocked by the high cost of manipulation and the complexity of the user interface

The Stanford/VA Interactive Robotics Laboratory set out in 1978 to test the hypothesis that industrial robotics technology could be applied to serve the manipulation needs of severely impaired individuals. Five generations of hardware, three generations of system software, and over 125 experimental subjects later, we believe that genuine utility is achievable. The experience includes development of over 65 task applications using voiced command, joystick control, natural language command and 3D object designation technology. A brief foray into virtual environments, using flight simulator technology, was instructive. If reality and virtuality come for comparable prices, you cannot beat reality. A detailed review of assistive robot anatomy and the performance specifications needed to achieve cost/beneficial utility will be used to support discussion of the future of rehabilitation telerobotics. Poised on the threshold of commercial viability, but constrained by the high cost of technically adequate manipulators, this worthy application domain flounders temporarily. In the long run, it will be the user interface that governs utility.

Leifer, Larry↗

Foundations of the Bandera Abstraction Tools

Current research is demonstrating that model-checking and other forms of automated finite-state verification can be effective for checking properties of software systems. Due to the exponential costs associated with model-checking, multiple forms of abstraction are often necessary to obtain system models that are tractable for automated checking. The Bandera Tool Set provides multiple forms of automated support for compiling concurrent Java software systems to models that can be supplied to several different model-checking tools. In this paper, we describe the foundations of Bandera's data abstraction mechanism which is used to reduce the cardinality (and the program's state-space) of data domains in software to be model-checked. From a technical standpoint, the form of data abstraction used in Bandera is simple, and it is based on classical presentations of abstract interpretation. We describe the mechanisms that Bandera provides for declaring abstractions, for attaching abstractions to programs, and for generating abstracted programs and properties. The contributions of this work are the design and implementation of various forms of tool support required for effective application of data abstraction to software components written in a programming language like Java which has a rich set of linguistic features.

Hatcliff, John↗

Flight Dynamic Model Exchange using XML

The AIAA Modeling and Simulation Technical Committee has worked for several years to develop a standard by which the information needed to develop physics-based models of aircraft can be specified. The purpose of this standard is to provide a well-defined set of information, definitions, data tables and axis systems so that cooperating organizations can transfer a model from one simulation facility to another with maximum efficiency. This paper proposes using an application of the eXtensible Markup Language (XML) to implement the AIAA simulation standard. The motivation and justification for using a standard such as XML is discussed. Necessary data elements to be supported are outlined. An example of an aerodynamic model as an XML file is given. This example includes definition of independent and dependent variables for function tables, definition of key variables used to define the model, and axis systems used. The final steps necessary for implementation of the standard are presented. Software to take an XML-defined model and import/export it to/from a given simulation facility is discussed, but not demonstrated. That would be the next step in final implementation of standards for physics-based aircraft dynamic models.

Jackson, E. Bruce↗

Scientific and technical training in the Soviet Union

Specific features and observations on the Soviet educational system and areas of apparent effectiveness are presented, noting that the literacy rate is over 98 percent in 1982. Educational goals are reoriented every five years to match with other projections of five-year plans. The Soviet constitution established strong educational goals, including schools, correspondence courses, lectures in native tongues, free tuition, and vocational training. The educational pattern from pre-school through graduate school lasts over 28 yr and contains two 2-yr periods of work, confined to specialties after graduate school. Mathematics is emphasized, as are physics, Marxism, and a foreign language. Approximately 300,000 engineers were graduated in the Soviet Union in 1982, compared with the 20-yr U.S. average of 50,000/yr. About 2/3 of Soviet engineers participate in defense work, a number which is four times the total number of U.S. engineers. It is asserted that the continual indoctrination, organization, and practical work experience will guarantee that the Soviet state will remain a dominant force in the world as long as centralized state control can be carried out.

Spearman, M. L.↗

Satellite Data of Atmospheric Pollution for U.S. Air Quality Applications: Examples of Applications, Summary of Data End-user Resources, Answers to Faqs, and Common Mistakes to Avoid

Satellite data of atmospheric pollutants are becoming more widely used in the decision-making and environmental management activities of public, private sector and non-profit organizations. They are employed for estimating emissions, tracking pollutant plumes, supporting air quality forecasting activities, providing evidence for "exceptional event" declarations, monitoring regional long-term trends, and evaluating air quality model output. However, many air quality managers are not taking full advantage of the data for these applications nor has the full potential of satellite data for air quality applications been realized. A key barrier is the inherent difficulties associated with accessing, processing, and properly interpreting observational data. A degree of technical skill is required on the part of the data end-user, which is often problematic for air quality agencies with limited resources. Therefore, we 1) review the primary uses of satellite data for air quality applications, 2) provide some background information on satellite capabilities for measuring pollutants, 3) discuss the many resources available to the end-user for accessing, processing, and visualizing the data, and 4) provide answers to common questions in plain language.

remote sensing↗

Satellite Data of Atmospheric Pollution for U.S. Air Quality Applications: Examples of Applications, Summary of Data End-User Resources, Answers to FAQs, and Common Mistakes to Avoid

Satellite data of atmospheric pollutants are becoming more widely used in the decision-making and environmental management activities of public, private sector and non-profit organizations. They are employed for estimating emissions, tracking pollutant plumes, supporting air quality forecasting activities, providing evidence for "exceptional event" declarations, monitoring regional long-term trends, and evaluating air quality model output. However, many air quality managers are not taking full advantage of the data for these applications nor has the full potential of satellite data for air quality applications been realized. A key barrier is the inherent difficulties associated with accessing, processing, and properly interpreting observational data. A degree of technical skill is required on the part of the data end-user, which is often problematic for air quality agencies with limited resources. Therefore, we 1) review the primary uses of satellite data for air quality applications, 2) provide some background information on satellite capabilities for measuring pollutants, 3) discuss the many resources available to the end-user for accessing, processing, and visualizing the data, and 4) provide answers to common questions in plain language.

Duncan, Bryan↗

Transitioning Autonomous Systems Technology Research to a Flight Software Environment

NASA has developed methods and algorithms for autonomous spacecraft operations,including automated planning and scheduling, fault diagnostics and impact determination,procedure management and display. Making the transition from technology research tooperational flight software requires overcoming significant technical, programmatic andcultural challenges. Technology research is aimed at developing methods that performspecific functions correctly, but the resulting software may not be designed for flightprocessors with limited CPU, memory and network resources, and may not be easilyintegrated into spacecraft flight software. Our objective in the Autonomous Systems andOperations Project is to make significant strides toward the transformation from technologyto operational use. Our focus was twofold: maturing research grade autonomy software intoa flight software environment using broadly accepted languages and tools; and integratingautonomy applications with each other and with representative systems and their data andcommand interfaces. For a target flight software environment, we chose Core FlightSoftware, developed by Goddard Space Flight Center as a common operating systemindependent framework. Our hardware integration environment was provided by theIntegrated Power and Avionics Systems (iPAS) Lab at Johnson Space Center, in whichvarious subsystem development has been conducted to address engineering challenges forthe vehicles and systems required for long-duration missions into the solar system. The iPASand its network of connected facilities provides realistic subsystem hardware or simulationsof spacecraft power, life support, guidance, navigation and control, and command and datahandling subsystems. Interfaces between autonomy applications and the subsystems beingassessed and controlled were developed, assessed and refined. The hardware and softwareenvironment using CFS and the iPAS facility has proven to be a highly flexible and realisticenvironment in which to rapidly integrate applications in an iterative, low cost setting. Usingthe integration environment we have developed, we will turn our focus to performance andsizing analysis to determine the computational requirements for full-scale deployment ofautonomy technology. Scalability of reasoners and the spacecraft models upon which theyoperate, and robustness across the full range of spacecraft conditions and environments willbe explored and improved. We are making significant contributions to the future programsthat will build the spacecraft that will take humans beyond the Earth-Moon system, in whichprogram Systems Engineers will be able to accurately and confidently design in accurate,robust and mature autonomous operations systems.

Flight Software↗

An application of artificial intelligence to automatic telescopes

Automatic Photoelectric Telescopes (APT's) allow an astronomer to be removed form the telescope site in both time and space. APT's 'execute' an observation program (a set of observation requests) expressed in an ASCII-based language (ATIS) and collect observation results expressed in this same language. The observation program is currently constructed by a Principal Astronomer from the requests of multiple users; the execution is currently controlled by a simple heuristic dispatch scheduler. Research aimed at improving the use of APT's is being carried out by the Entropy Reduction Engine (ERE) project at NASA Ames. The overall goal of the ERE project is the study and construction of systems that integrate planning, scheduling, and control. This paper discusses the application of some ERE technical results to the improvement of both the scheduling and the operation of APT's.

Swanson, Keith↗

Report from the MPP Working Group to the NASA Associate Administrator for Space Science and Applications

NASA's Office of Space Science and Applications (OSSA) gave a select group of scientists the opportunity to test and implement their computational algorithms on the Massively Parallel Processor (MPP) located at Goddard Space Flight Center, beginning in late 1985. One year later, the Working Group presented its report, which addressed the following: algorithms, programming languages, architecture, programming environments, the way theory relates, and performance measured. The findings point to a number of demonstrated computational techniques for which the MPP architecture is ideally suited. For example, besides executing much faster on the MPP than on conventional computers, systolic VLSI simulation (where distances are short), lattice simulation, neural network simulation, and image problems were found to be easier to program on the MPP's architecture than on a CYBER 205 or even a VAX. The report also makes technical recommendations covering all aspects of MPP use, and recommendations concerning the future of the MPP and machines based on similar architectures, expansion of the Working Group, and study of the role of future parallel processors for space station, EOS, and the Great Observatories era.

Fischer, James R.↗

Wildfire-fighting Use Case Requirements to Monitor

In this technical report, we provide requirements for a wildfire-fighting use-case, towards the Safety Demonstrator 1. The use case will incorporate ground and airborne assets operating in a coordinated fashion, and will comprise five activities, from detection to the execution of the initial attack. Depending on the activity and the data involved, the requirements identified may be non-probabilistic or probabilistic. In both cases, we first identify some of the requirements we wish to monitor, and then present a formalization using the language of requirements of the NASA requirements elicitation tool FRET. To formalize probabilistic requirements, we use a novel extension to FRET’s requirements language that incorporates notions of probability, and discuss how requirements can be translated into existing probabilistic temporal logics like PCTL. We exemplify how some of the requirements presented can be monitored using the existing tools Ogma and Copilot. We close with a summary and future directions.

Requirements↗

Apollo-Soyuz US-USSR joint mission results

The technical and nontechnical objectives of the Apollo-Soyuz mission are briefly considered. The mission demonstrated that Americans and Russians can work together to perform a very complex operation, including rendezvous in space, docking, and the conduction of joint experiments. Certain difficulties which had to be overcome were partly related to differences concerning the role of the astronaut in the basic alignment and docking procedures for space vehicles. Attention is also given to the experiments conducted during the mission and the approach used to overcome the language barrier.

Bean, A. L.↗

Development of an expert planning system for OSSA

This paper presents concepts related to preliminary work for the development of an expert planning system for NASA's Office for Space Science and Applications (OSSA). The expert system will function as a planner's decision aid in preparing mission plans encompassing sets of proposed OSSA space science initiatives. These plans in turn will be checked against budgetary and technical constraints and tested for constraint violations. Appropriate advice will be generated by the system for making modifications to the plans to bring them in line with the constraints. The OSSA Planning Expert System (OPES) has been designed to function as an integral part of the OSSA mission planning process. It will be able to suggest a best plan, be able to accept and check a user-suggested strawman plan, and should provide a quick response to user request and actions. OPES will be written in the C programming language and have a transparent user interface running under Windows 386 on a Compaq 386/20 machine. The system's sorted knowledge and inference procedures will model the expertise of human planners familiar with the OSSA planning domain. Given mission priorities and budget guidelines, the system first sets the launch dates for each mission. It will check to make sure that planetary launch windows and precursor mission relationships are not violated. Additional levels of constraints will then be considered, checking such things as the availability of a suitable launch vehicle, total mission launch mass required vs. the identified launch mass capability, and the total power required by the payload at its destination vs. the actual power available. System output will be in the form of Gantt charts, spreadsheet hardcopy, and other presentation quality materials detailing the resulting OSSA mission plan.

Groundwater, B.↗