Search NASA⌕ Search

SEARCH · Search NASA

Results for “Common 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.

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

At least 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

MBSE Applications for the MSR SRC Mars Ascent Vehicle

The objective of the NASA Mars Sample Return (MSR) Campaign is to collect samples from the surface of Mars and return them to Earth for scientific research. The Mars Ascent Vehicle (MAV) will be integrated into a larger Mars Sample Retrieval Lander (SRL) for transit to and storage on Mars. After all Martian samples have been collected and loaded into the MAV payload assembly, MAV will deliver the samples from the Martian surface to Mars orbit. A separate spacecraft, the Earth Return Orbiter (ERO) will retrieve the samples from Mars orbit and return them to Earth. To address common systems engineering challenges associated with using traditional systems engineering practices on complex projects, the MAV systems engineering team has explored implementation of Model-Based Systems Engineering (MBSE) tools and languages. This paper describes the current state of implementation and development of the MAV MBSE model with the Systems Modeling Language (SysML) within the scope of the MAV Systems Requirement Cycle (SRC) systems engineering workflow. The MAV MBSE model has been developed within Magic Draw – a SysML editor commonly used to implement MBSE. The MAV MBSE model has been used to develop mission phase functional flow diagrams for the Concept of Operations, decompose mission to vehicle subsystem functions, develop a functional decomposition, derive functional requirements, trace requirements up to customer-imposed requirements, trace requirements within MAV requirement space, identify requirements trace gaps, define and map the physical design space architecture, allocate requirements to subsystems, develop validation items, define assembly, integration, and test (AI&T) operations, and trace these items across driving goals to develop an integrated digital thread of systems engineering information used to drive design specifications, decision making, and ultimately design verification and validation. Findings and results associated with implementing MBSE in these ways, alongside traditional methods will be discussed.

MBSE↗
NASA NTRS1981

Pitfalls and guidelines for the numerical evaluation of moderate-order system frequency response

The design and evaluation of a feedback control system via frequency response methods relies heavily upon numerical methods. In application, one can usually develop low order simulation models which for the most part are devoid of numerical problems. However, when complex feedback interactions, for example, between instrument control systems and their flexible mounting structure, must be evaluated, simulation models become moderate to large order and numerical problems become common. A large body of relevant numerical error analysis literature is summarized in a large language understandable to nonspecialists. The intent is to provide engineers using simulation models with an engineering feel for potential numerical problems without getting intertwined in the complexities of the associated mathematical theory. Guidelines are also provided by suggesting alternate state of the art methods which have good numerical evaluation characteristics.

Frisch, H. P.↗
NASA NTRS2007

Master Metadata Repository and Metadata-Management System

A master metadata repository (MMR) software system manages the storage and searching of metadata pertaining to data from national and international satellite sources of the Global Ocean Data Assimilation Experiment (GODAE) High Resolution Sea Surface Temperature Pilot Project [GHRSSTPP]. These sources produce a total of hundreds of data files daily, each file classified as one of more than ten data products representing global sea-surface temperatures. The MMR is a relational database wherein the metadata are divided into granulelevel records [denoted file records (FRs)] for individual satellite files and collection-level records [denoted data set descriptions (DSDs)] that describe metadata common to all the files from a specific data product. FRs and DSDs adhere to the NASA Directory Interchange Format (DIF). The FRs and DSDs are contained in separate subdatabases linked by a common field. The MMR is configured in MySQL database software with custom Practical Extraction and Reporting Language (PERL) programs to validate and ingest the metadata records. The database contents are converted into the Federal Geographic Data Committee (FGDC) standard format by use of the Extensible Markup Language (XML). A Web interface enables users to search for availability of data from all sources.

Armstrong, Edward↗
NASA NTRS1988

Storage management in Ada. Three reports. Volume 1: Storage management in Ada as a risk to the development of reliable software. Volume 2: Relevant aspects of language. Volume 3: Requirements of the language versus manifestations of current implementations

The risk to the development of program reliability is derived from the use of a new language and from the potential use of new storage management techniques. With Ada and associated support software, there is a lack of established guidelines and procedures, drawn from experience and common usage, which assume reliable behavior. The risk is identified and clarified. In order to provide a framework for future consideration of dynamic storage management on Ada, a description of the relevant aspects of the language is presented in two sections: Program data sources, and declaration and allocation in Ada. Storage-management characteristics of the Ada language and storage-management characteristics of Ada implementations are differentiated. Terms that are used are defined in a narrow and precise sense. The storage-management implications of the Ada language are described. The storage-management options available to the Ada implementor and the implications of the implementor's choice for the Ada programmer are also described.

Auty, David↗
NASA NTRS2011

Executable Architecture Research at Old Dominion University

Executable Architectures allow the evaluation of system architectures not only regarding their static, but also their dynamic behavior. However, the systems engineering community do not agree on a common formal specification of executable architectures. To close this gap and identify necessary elements of an executable architecture, a modeling language, and a modeling formalism is topic of ongoing PhD research. In addition, systems are generally defined and applied in an operational context to provide capabilities and enable missions. To maximize the benefits of executable architectures, a second PhD effort introduces the idea of creating an executable context in addition to the executable architecture. The results move the validation of architectures from the current information domain into the knowledge domain and improve the reliability of such validation efforts. The paper presents research and results of both doctoral research efforts and puts them into a common context of state-of-the-art of systems engineering methods supporting more agility.

Tolk, Andreas↗
NASA NTRS2018

PYSAT: Python Satellite Data Analysis Toolkit

A common problem in space science data analysis is combining complementary data sources that are provided and analyzed in different formats and programming languages. The Python Satellite Data Analysis Toolkit (pysat) addresses this issue by providing an open source toolkit that implements the general process of space science data analysis, from beginning to end, in an instrumentindependent manner. This toolkit uses an Instrument object that enables systematic analysis of science data from a variety of platforms within a single interface. Basic functions such as downloading, loading, and cleaning are included for all supported instruments. Common analysis routines are also included, which are instrument and data source independent. A nanokernel is used to provide instrument independence, it is attached to the Instrument object and mediates the systematic and arbitrary modification of loaded data. Pysat uses the nanokernel to improve the rigor of time series analysis, support onthefly orbit determination, and cleanly span file breaks. Pysat's functions and higherlevel scientific analysis features are validated through the use of unit testing. Further adoption by the community provides a set of scientific results produced by a common core, constituting a distributed heritage that supports the validity of the underlying processing and scientific output. These features are used to demonstrate consistency between derived electron density profiles and measured ion drifts, particularly downward ion drifts in the afternoon hours during extreme solar minimum. Pysat builds upon open source Python software that is freely available and encourages communitydriven development.

Stoneback, R.A.↗
NASA NTRS1995

Cross-Cultural Barriers to Effective Communication in Aviation

Recent research on communication and performance in airline flight crews has led to a concept of shared mental models that is associated with effective, efficient team coordination in problem solving and decision making situations. Elements that characterize efficient communication have been identified. This research, however, was based strictly on US crews. More recent studies supported by NASA have identified cultural factors that influence communication among team members who vary in their status and roles. Research is just beginning to identify commonalities and culturally distinct strategies for accomplishing joint tasks. ASRS incident reports have been analyzed to identify language barriers in flight that have safety consequences. Implications of these concepts and findings for multi-cultural command and control will be explored.

Orasanu, Judith↗
NASA NTRS2018

Modeling with Scala

The activities and the associated formalisms for modeling and programming have many commonalities. In this paper we emphasize this point of view by modeling two examples in the programming language Scala, which have previously been modeled in the VDM specification language, and the Promela modeling language of the SPIN model checker respectively. The latter Scala model uses an internal DSL for hierarchical state machines, and a simple randomized testing framework exposing the same errors as found with SPIN. We believe, as the examples illustrate, that this use of a modern programming language for modeling is promising, especially if utilizing internal DSLs.

Joshi, Rajeev↗
NASA NTRS1997

Steady-State Cycle Deck Launcher Developed for Numerical Propulsion System Simulation

One of the objectives of NASA's High Performance Computing and Communications Program's (HPCCP) Numerical Propulsion System Simulation (NPSS) is to reduce the time and cost of generating aerothermal numerical representations of engines, called customer decks. These customer decks, which are delivered to airframe companies by various U.S. engine companies, numerically characterize an engine's performance as defined by the particular U.S. airframe manufacturer. Until recently, all numerical models were provided with a Fortran-compatible interface in compliance with the Society of Automotive Engineers (SAE) document AS681F, and data communication was performed via a standard, labeled common structure in compliance with AS681F. Recently, the SAE committee began to develop a new standard: AS681G. AS681G addresses multiple language requirements for customer decks along with alternative data communication techniques. Along with the SAE committee, the NPSS Steady-State Cycle Deck project team developed a standard Application Program Interface (API) supported by a graphical user interface. This work will result in Aerospace Recommended Practice 4868 (ARP4868). The Steady-State Cycle Deck work was validated against the Energy Efficient Engine customer deck, which is publicly available. The Energy Efficient Engine wrapper was used not only to validate ARP4868 but also to demonstrate how to wrap an existing customer deck. The graphical user interface for the Steady-State Cycle Deck facilitates the use of the new standard and makes it easier to design and analyze a customer deck. This software was developed following I. Jacobson's Object-Oriented Design methodology and is implemented in C++. The AS681G standard will establish a common generic interface for U.S. engine companies and airframe manufacturers. This will lead to more accurate cycle models, quicker model generation, and faster validation leading to specifications. The standard will facilitate cooperative work between industry and NASA. The NPSS Steady-State Cycle Deck team released a batch version of the Steady-State Cycle Deck in March 1996. Version 1.1 was released in June 1996. During fiscal 1997, NPSS accepted enhancements and modifications to the Steady-State Cycle Deck launcher. Consistent with NPSS' commercialization plan, these modifications will be done by a third party that can provide long-term software support.

VanDrei, Donald E.↗
NASA NTRS2002

Information architecture for a planetary 'exploration web'

'Web services' is a common way of deploying distributed applications whose software components and data sources may be in different locations, formats, languages, etc. Although such collaboration is not utilized significantly in planetary exploration, we believe there is significant benefit in developing an architecture in which missions could leverage each others capabilities. We believe that an incremental deployment of such an architecture could significantly contribute to the evolution of increasingly capable, efficient, and even autonomous remote exploration.

middleware messaging IT infrastructure web service↗
NASA NTRS1991

An aircraft model for the AIAA controls design challenge

A generic, state-of-the-art, high-performance aircraft model, including detailed, full-envelope, nonlinear aerodynamics, and full-envelope thrust and first-order engine response data is described. While this model was primarily developed Controls Design Challenge, the availability of such a model provides a common focus for research in aeronautical control theory and methodology. An implementation of this model using the FORTRAN computer language, associated routines furnished with the aircraft model, and techniques for interfacing these routines to external procedures is also described. Figures showing vehicle geometry, surfaces, and sign conventions are included.

Brumbaugh, Randal W.↗
NASA NTRS2005

The M-Integral for Computing Stress Intensity Factors in Generally Anisotropic Materials

The objective of this project is to develop and demonstrate a capability for computing stress intensity factors in generally anisotropic materials. These objectives have been met. The primary deliverable of this project is this report and the information it contains. In addition, we have delivered the source code for a subroutine that will compute stress intensity factors for anisotropic materials encoded in both the C and Python programming languages and made available a version of the FRANC3D program that incorporates this subroutine. Single crystal super alloys are commonly used for components in the hot sections of contemporary jet and rocket engines. Because these components have a uniform atomic lattice orientation throughout, they exhibit anisotropic material behavior. This means that stress intensity solutions developed for isotropic materials are not appropriate for the analysis of crack growth in these materials. Until now, a general numerical technique did not exist for computing stress intensity factors of cracks in anisotropic materials and cubic materials in particular. Such a capability was developed during the project and is described and demonstrated herein.

Warzynek, P. A.↗
NASA NTRS2005

Use of Field Programmable Gate Array Technology in Future Space Avionics

Fulfilling NASA's new vision for space exploration requires the development of sustainable, flexible and fault tolerant spacecraft control systems. The traditional development paradigm consists of the purchase or fabrication of hardware boards with fixed processor and/or Digital Signal Processing (DSP) components interconnected via a standardized bus system. This is followed by the purchase and/or development of software. This paradigm has several disadvantages for the development of systems to support NASA's new vision. Building a system to be fault tolerant increases the complexity and decreases the performance of included software. Standard bus design and conventional implementation produces natural bottlenecks. Configuring hardware components in systems containing common processors and DSPs is difficult initially and expensive or impossible to change later. The existence of Hardware Description Languages (HDLs), the recent increase in performance, density and radiation tolerance of Field Programmable Gate Arrays (FPGAs), and Intellectual Property (IP) Cores provides the technology for reprogrammable Systems on a Chip (SOC). This technology supports a paradigm better suited for NASA's vision. Hardware and software production are melded for more effective development; they can both evolve together over time. Designers incorporating this technology into future avionics can benefit from its flexibility. Systems can be designed with improved fault isolation and tolerance using hardware instead of software. Also, these designs can be protected from obsolescence problems where maintenance is compromised via component and vendor availability.To investigate the flexibility of this technology, the core of the Central Processing Unit and Input/Output Processor of the Space Shuttle AP101S Computer were prototyped in Verilog HDL and synthesized into an Altera Stratix FPGA.

Ferguson, Roscoe C.↗
NASA NTRS2012

Modeling and Analysis of Mixed Synchronous/Asynchronous Systems

Practical safety-critical distributed systems must integrate safety critical and non-critical data in a common platform. Safety critical systems almost always consist of isochronous components that have synchronous or asynchronous interface with other components. Many of these systems also support a mix of synchronous and asynchronous interfaces. This report presents a study on the modeling and analysis of asynchronous, synchronous, and mixed synchronous/asynchronous systems. We build on the SAE Architecture Analysis and Design Language (AADL) to capture architectures for analysis. We present preliminary work targeted to capture mixed low- and high-criticality data, as well as real-time properties in a common Model of Computation (MoC). An abstract, but representative, test specimen system was created as the system to be modeled.

Driscoll, Kevin R.↗
NASA NTRS1988

Dynamic substructuring for shock spectrum analysis using component mode synthesis

Component mode synthesis was used to analyze different types of structures with MSC NASTRAN. The theory and technique of using Multipoint Constraint Equations (MPCs) to connect substructures to each other or to a common foundation is presented. Computation of the dynamic response of the system from shack spectrum inputs was automated using the DMAP programming language of the MSC NASTRAN finite element code.

Mcpheeters, Barton W.↗
NASA NTRS2003

Improved Conflict Detection for Reducing Operational Errors in Air Traffic Control

An operational error is an incident in which an air traffic controller allows the separation between two aircraft to fall below the minimum separation standard. The rates of such errors in the US have increased significantly over the past few years. This paper proposes new detection methods that can help correct this trend by improving on the performance of Conflict Alert, the existing software in the Host Computer System that is intended to detect and warn controllers of imminent conflicts. In addition to the usual trajectory based on the flight plan, a "dead-reckoning" trajectory (current velocity projection) is also generated for each aircraft and checked for conflicts. Filters for reducing common types of false alerts were implemented. The new detection methods were tested in three different ways. First, a simple flightpath command language was developed t o generate precisely controlled encounters for the purpose of testing the detection software. Second, written reports and tracking data were obtained for actual operational errors that occurred in the field, and these were "replayed" to test the new detection algorithms. Finally, the detection methods were used to shadow live traffic, and performance was analysed, particularly with regard to the false-alert rate. The results indicate that the new detection methods can provide timely warnings of imminent conflicts more consistently than Conflict Alert.

Paielli, Russell A.↗
NASA NTRS1971

The programming language HAL: A specification

HAL accomplishes three significant objectives: (1) increased readability, through the use of a natural two-dimensional mathematical format; (2) increased reliability, by providing for selective recognition of common data and subroutines, and by incorporating specific data-protect features; (3) real-time control facility, by including a comprehensive set of real-time control commands and signal conditions. Although HAL is designed primarily for programming on-board computers, it is general enough to meet nearly all the needs in the production, verification and support of aerospace, and other real-time applications.

Source record↗