SEARCH · Search NASA

Results for “C++ (programming language)”

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 199 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS1994

Program Helps Standardize Documentation Of Software

Intelligent Documentation Management System, IDMS, computer program developed to assist project managers in implementing information system documentation standard known as NASA-STD-2100-91, NASA STD, COS-10300, of NASA's Software Management and Assurance Program. Standard consists of data-item descriptions or templates, each of which governs particular component of software documentation. IDMS helps program manager in tailoring documentation standard to project. Written in C language.

Howe, G.↗

NASA NTRS2004

Space Communications Emulation Facility

Establishing space communication between ground facilities and other satellites is a painstaking task that requires many precise calculations dealing with relay time, atmospheric conditions, and satellite positions, to name a few. The Space Communications Emulation Facility (SCEF) team here at NASA is developing a facility that will approximately emulate the conditions in space that impact space communication. The emulation facility is comprised of a 32 node distributed cluster of computers; each node representing a satellite or ground station. The objective of the satellites is to observe the topography of the Earth (water, vegetation, land, and ice) and relay this information back to the ground stations. Software originally designed by the University of Kansas, labeled the Emulation Manager, controls the interaction of the satellites and ground stations, as well as handling the recording of data. The Emulation Manager is installed on a Linux Operating System, employing both Java and C++ programming codes. The emulation scenarios are written in extensible Markup Language, XML. XML documents are designed to store, carry, and exchange data. With XML documents data can be exchanged between incompatible systems, which makes it ideal for this project because Linux, MAC and Windows Operating Systems are all used. Unfortunately, XML documents cannot display data like HTML documents. Therefore, the SCEF team uses XML Schema Definition (XSD) or just schema to describe the structure of an XML document. Schemas are very important because they have the capability to validate the correctness of data, define restrictions on data, define data formats, and convert data between different data types, among other things. At this time, in order for the Emulation Manager to open and run an XML emulation scenario file, the user must first establish a link between the schema file and the directory under which the XML scenario files are saved. This procedure takes place on the command line on the Linux Operating System. Once this link has been established the Emulation manager validates all the XML files in that directory against the schema file, before the actual scenario is run. Using some very sophisticated commercial software called the Satellite Tool Kit (STK) installed on the Linux box, the Emulation Manager is able to display the data and graphics generated by the execution of a XML emulation scenario file. The Emulation Manager software is written in JAVA programming code. Since the SCEF project is in the developmental stage, the source code for this type of software is being modified to better fit the requirements of the SCEF project. Some parameters for the emulation are hard coded, set at fixed values. Members of the SCEF team are altering the code to allow the user to choose the values of these hard coded parameters by inserting a toolbar onto the preexisting GUI.

Hill, Chante A.↗

NASA NTRS2006

Progress Toward a Format Standard for Flight Dynamics Models

In the beginning, there was FORTRAN, and it was... not so good. But it was universal, and all flight simulator equations of motion were coded with it. Then came ACSL, C, Ada, C++, C#, Java, FORTRAN-90, Matlab/Simulink, and a number of other programming languages. Since the halcyon punch card days of 1968, models of aircraft flight dynamics have proliferated in training devices, desktop engineering and development computers, and control design textbooks. With the rise of industry teaming and increased reliance on simulation for procurement decisions, aircraft and missile simulation models are created, updated, and exchanged with increasing frequency. However, there is no real lingua franca to facilitate the exchange of models from one simulation user to another. The current state-of-the-art is such that several staff-months if not staff-years are required to 'rehost' each release of a flight dynamics model from one simulation environment to another one. If a standard data package or exchange format were to be universally adopted, the cost and time of sharing and updating aerodynamics, control laws, mass and inertia, and other flight dynamic components of the equations of motion of an aircraft or spacecraft simulation could be drastically reduced. A 2002 paper estimated over $ 6 million in savings could be realized for one military aircraft type alone. This paper describes the efforts of the American Institute of Aeronautics and Astronautics (AIAA) to develop a standard flight dynamic model exchange standard based on XML and HDF-5 data formats.

Jackson, E. Bruce↗

NASA NTRSDate not supplied

FRET Tutorial

In this tutorial, we present the FRET tool for writing, understanding, formalizing and analyzing requirements. In practice, requirements are typically written in natural language, which is ambiguous and consequently not amenable to formal analysis. Since formal, mathematical notations are unintuitive, requirements in FRET are entered in a restricted, natural language, called FRETish with precise unambiguous meaning. This tutorial explains how requirements can be captured in FRETish and subsequently formalized in temporal logics and in the synchronous data flow language Lustre. We show, through multiple examples, how FRET assists users in understanding FRETish requirements and clarifying subtle semantic issues through English and diagrammatic explanations as well as interactive simulation. FInally, this tutorial describes how FRET can be used to perform realizability checking for identifying conflicting requirements and the connection of FRET with (1) the CoCoSim automated analysis tool for the verification of Simulink and Stateflow models, and (2) the Copilot runtime monitoring tool for the analysis of C programs.

FRET↗

NASA NTRS1979

Viscosity and thermal conductivity of model Jupiter atmospheres

The viscosity and thermal conductivity coefficient are estimated for three models of the atmosphere of Jupiter: a heavy model consisting of 22% helium and 78% hydrogen, a nominal model consisting of 11% helium and 89% hydrogen, and a light model consisting of pure hydrogen. The effect of trace elements is neglected. Linearized approximations are used for the transport coefficients of the mixtures; these are found to be in almost constant ratio to the values for pure hydrogen, independent of temperature. Short Basic language programs for computing the coefficients are listed.

Hansen, C. F.↗

NASA NTRS1989

Engineering the object-relation database model in O-Raid

Raid is a distributed database system based on the relational model. O-raid is an extension of the Raid system and will support complex data objects. The design of O-Raid is evolutionary and retains all features of relational data base systems and those of a general purpose object-oriented programming language. O-Raid has several novel properties. Objects, classes, and inheritance are supported together with a predicate-base relational query language. O-Raid objects are compatible with C++ objects and may be read and manipulated by a C++ program without any 'impedance mismatch'. Relations and columns within relations may themselves be treated as objects with associated variables and methods. Relations may contain heterogeneous objects, that is, objects of more than one class in a certain column, which can individually evolve by being reclassified. Special facilities are provided to reduce the data search in a relation containing complex objects.

Dewan, Prasun↗

NASA NTRS2016

Hexapod Robot

The project I am working on at NASA-Johnson Space Center in Houston, TX is a hexapod robot. This project was started by various engineers at the Trick Lab. The goal of this project is to have the hexapod track a yellow ball or possibly another object from left to right and up/down. The purpose is to have it track an object like a real creature. The project will consist of using software and hardware. This project started with a hexapod robot which uses a senor bar to track a yellow ball but with a limited field of vision. The sensor bar acts as the robots "head." Two servos will be added to the hexapod to create flexion and extension of the head. The neck and head servos will have to be programmed to be added to the original memory map of the existing servos. I will be using preexisting code. The main programming language that will be used to add to the preexisting code is C++. The trick modeling and simulation software will also be used in the process to improve its tracking and movement. This project will use a trial and error approach, basically seeing what works and what does not. The first step is to initially understand how the hexapod works. To get a general understanding of how the hexapod maneuvers and plan on how to had a neck and head servo which works with the rest of the body. The second step would be configuring the head and neck servos with the leg servos. During this step, limits will be programmed specifically for the each servo. By doing this, the servo is limited to how far it can rotate both clockwise and counterclockwise and this is to prevent hardware damage. The hexapod will have two modes in which it works in. The first mode will be if the sensor bar does not detect an object. If the object it is programmed to look for is not in its view it will automatically scan from left to right 3 times then up and down once. The second mode will be if the sensor bar does detect the object. In this mode the hexapod will track the object from left to right or up and down. The hexapod will eventually be able to track the object moving its head and body in sync with on another and being able to rotate its body at 360 degrees. This is the plans and possible end results for the hexapod robot I will be working on during my summer internship at NASA Johnson Space Center. Since working on the hexapod project I have gained an increase interest in robotics. I enjoy the process of critical thinking. Also will working on this project I was challenged in a way that made more passionate to strive even more to become an engineer. I've learned that asking questions is an important part of the learning process. Also I learn that much more is accomplished when teamwork is applied.

Begody, Ericka↗

NASA NTRS1987

Program for Automated Real-Time Monitoring

Process-control decisions made by applying rules to process data streams. Expert System Executive computer program demonstrates feasibility of automated real-time monitoring. Using Executives knowledge of system formally coded as set of rules specifying actions taken under various conditions. Program makes inferences about observed data based on rules. Written in C language.

Goodrum, Glenn R.↗

NASA NTRS1993

COSMIC monthly progress report

Activities of the Computer Software Management and Information Center (COSMIC) are summarized for the month of August, 1993. Tables showing the current inventory of programs available from COSMIC are presented and program processing and evaluation activities are discussed. Ten articles were prepared for publication in the NASA Tech Brief Journal. These articles (included in this report) describe the following software items: (1) MOM3D - A Method of Moments Code for Electromagnetic Scattering (UNIX Version); (2) EM-Animate - Computer Program for Displaying and Animating the Steady-State Time-Harmonic Electromagnetic Near Field and Surface-Current Solutions; (3) MOM3D - A Method of Moments Code for Electromagnetic Scattering (IBM PC Version); (4) M414 - MIL-STD-414 Variable Sampling Procedures Computer Program; (5) MEDOF - Minimum Euclidean Distance Optimal Filter; (6) CLIPS 6.0 - C Language Integrated Production System, Version 6.0 (Macintosh Version); (7) CLIPS 6.0 - C Language Integrated Production System, Version 6.0 (IBM PC Version); (8) CLIPS 6.0 - C Language Integrated Production System, Version 6.0 (UNIX Version); (9) CLIPS 6.0 - C Language Integrated Production System, Version 6.0 (DEC VAX VMS Version); and (10) TFSSRA - Thick Frequency Selective Surface with Rectangular Apertures. Activities in the areas of marketing, customer service, benefits identification, maintenance and support, and dissemination are also described along with a budget summary.

Source record↗

NASA NTRS1994

Third CLIPS Conference Proceedings, volume 2

Expert systems are computer programs which emulate human expertise in well defined problem domains. The C Language Integrated Production System (CLIPS) is an expert system building tool, developed at the Johnson Space Center, which provides a complete environment for the development and delivery of rule and/or object based expert systems. CLIPS was specifically designed to provide a low cost option for developing and deploying expert system applications across a wide range of hardware platforms. The development of CLIPS has helped to improve the ability to deliver expert system technology throughout the public and private sectors for a wide range of applications and diverse computing environments. The Third Conference on CLIPS provided a forum for CLIPS users to present and discuss papers relating to CLIPS applications, uses, and extensions.

Riley, Gary↗

NASA NTRS1993

Airline Operations Aid

C Language Integrated Production System (CLIPS), a NASA-developed expert systems program, is used by American Airlines for three purposes: as a rapid prototyping tool; to develop production prototypes; and to develop production application. An example of the latter is CLIPS' use in "Hub S1AAshing," a knowledge based system that recommends contingency plans when severe schedule reductions must be made. Hub S1AAshing has replaced a manual, labor intensive process. It saves time and allows Operations Control Coordinators to handle more difficult situations. Because the system assimilates much of the information necessary to facilitate educated decision making, it minimizes negative impact in situations where it is impossible to operate all flights.

Source record↗

NASA NTRS1993

Security System Software

C Language Integration Production System (CLIPS), a NASA-developed expert systems program, has enabled a security systems manufacturer to design a new generation of hardware. C.CURESystem 1 Plus, manufactured by Software House, is a software based system that is used with a variety of access control hardware at installations around the world. Users can manage large amounts of information, solve unique security problems and control entry and time scheduling. CLIPS acts as an information management tool when accessed by C.CURESystem 1 Plus. It asks questions about the hardware and when given the answer, recommends possible quick solutions by non-expert persons.

Source record↗

NASA NTRS2020

Julia Programming Language Benchmark Using a Flight Simulation

Julia’s goal to provide scripting language ease-of-coding with compiled language speed is explored. The runtime speed of the relatively new Julia programming language is assessed against other commonly used languages including Python, Java, and C++. An industry-standard missile and rocket simulation, coded in multiple languages, was used as a test bench for runtime speed. All language versions of the simulation, including Julia, were coded to a highly-developed object-oriented simulation architecture tailored specifically for time-domain flight simulation. A “speed-of-coding” second-dimension is plotted against runtime for each language to portray a space that characterizes Julia’s scripting language efficiencies in the context of the other languages. With caveats, Julia runtime speed was found to be in the class of compiled or semi-compiled languages. However, some factors that affect runtime speed at the cost of ease-of-coding are shown. Julia’s built-in functionality for multi-core processing is briefly examined as a means for obtaining even faster runtime speed. The major contribution of this research to the extensive language benchmarking body-of-work is comparing Julia to other mainstream languages using a complex flight simulation as opposed to benchmarking with single algorithms.

Sells, Ray↗

NASA NTRS1991

ECLIPS: An extended CLIPS for backward chaining and goal-directed reasoning

Realistic production systems require an integrated combination of forward and backward reasoning to reflect appropriately the processes of natural human expert reasoning. A control mechanism that consists solely of forward reasoning is not an effective way to promptly focus the system's attention as calculation proceeds. Often, expert system programmers will attempt to compensate for this lack by using data to enforce the desired goal directed control structure. This approach is inherently flawed in that it is attempting to use data to fulfill the role of control. This paper will describe our implementation of backward chaining in C Language Integrated Production System (CLIPS), and show how this has shortened and simplified various CLIPS programs. This work was done at the Aerospace Corporation, and has general applicability.

Homeier, Peter V.↗

NASA NTRS1990

C Language Integrated Production System (CLIPS)

Ideal for developing expert systems, CLIPS language easy to use and called from or make calls to other programs. Advanced features include cross-reference, style, and verification facility catching logic errors in large systems. Program machine independent.

Riley, G.↗

NASA NTRS1992

C Language Integrated Production System, Version 5.0

CLIPS 5.0 provides cohesive software tool for handling wide variety of knowledge with support for three different programming paradigms: rule-based, object-oriented, and procedural. CLIPS 5.0 available in version for IBM Personal Computer (MSC-21916), in one for Macintosh computer (MSC-21927), and in one for DEC VAX computer (MSC-21929). Computer Software Management and Information Center (COSMIC) offers five distribution versions of CLIPS 5.0. Executable files, source code, utilities, and examples included on program medium. All distribution versions include identical source code for command-line version of CLIPS 5.0. Source code compatible with ANSI C and compilable on any computer with ANSI C compiler. Only Macintosh version of CLIPS 5.0 includes window interface.

Riley, Gary↗

NASA NTRS1979

Artificial intelligence programming languages for computer aided manufacturing

Eight Artificial Intelligence programming languages (SAIL, LISP, MICROPLANNER, CONNIVER, MLISP, POP-2, AL, and QLISP) are presented and surveyed, with examples of their use in an automated shop environment. Control structures are compared, and distinctive features of each language are highlighted. A simple programming task is used to illustrate programs in SAIL, LISP, MICROPLANNER, and CONNIVER. The report assumes reader knowledge of programming concepts, but not necessarily of the languages surveyed.

Rieger, C.↗

NASA NTRS1987

A universal six-joint robot controller

A general purpose six-axis robotic manipulator controller was designed and implemented to serve as a research tool for the investigation of the practical and theoretical aspects of various control strategies in robotics. A 80286-based Intel System 310 running the Xenix operating servo software as well as the higher level software (e.g., kinematics and path planning) were employed. A Multibus compatible interface board was designed and constructed to handle I/O signals from the robot manipulator's joint motors. From the design point of view, the universal controller is capable of driving robot manipulators equipped with D.C. joint motors and position optical encoders. To test its functionality, the controller is connected to the joint motor D.C. power amplifier of a PUMA 560 arm bypassing completely the manufacturer-supplied Unimation controller. A controller algorithm consisting of local PD control laws was written and installed into the Xenix operating system. Additional software drivers were implemented to allow application programs access to the interface board. All software was written in the C language.

Bihn, D. G.↗