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.

SourceResearch connectionFrom yearThrough year

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

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Training Artemis Astronauts to Explore the Moon

To prepare for human exploration of the Moon in the mid-2020s, NASA is developing a program to provide geoscience and planetary science classroom training and geologic eld training to astronauts and other mission personnel. The Artemis geoscience training plan builds on a long legacy: NASA has trained astronauts in geology, planetary science, and geological eld work for more than 50 years. From ~1965-1972, the geology focus for astronauts included orbital Earth observations during the early NASA missions, but the endgame was preparation for the Apollo missions to the Lunar surface [see Phinney (2015), NASA-SP-2015-626; Lofgren et al.(2011);Schmitt, et al. (2011); and El Baz (2011), all from GSA SP483]. From the mid 1970s through2017, the primary purpose for geoscience training was to prepare astronauts to observe theEarth and document a wide variety of Earth processes from orbital platforms (Skylab, SpaceShuttle and International Space Station). Astronaut observations of Earth from the InternationalSpace Station remain an important activity today, but the prospect of exploration of the lunar surface through the Artemis Program lends additional purpose to the geoscience content and eld experiences that we provide the astronauts. We recently completed the geology and eld training with Astronaut Class 22 and are now planning both focused eld exercises and simulations for future Artemis crews, as well as the accompanying classroom lessons on lunar and planetary sciences. The training we offer extends beyond the astronaut office – we partner across operational and engineering organizations at NASA and provide eld work exercises and opportunities to personnel in the Flight Operations Directorate (responsible for the overall training and certification), as well as the exploration Extravehicular Activity Oce (developing spacewalk suits and tools). These partnerships contribute to building a common language and sense of purpose, and also help to ensure that NASA’s geoscience training and science operations are fully integrated with the teams and systems responsible for getting the next generation of astronauts to the surface of the Moon.

Artemis↗

NASA NTRS2021

EOSDIS STAC Briefing

The Spatio-Temporal Asset Catalog (STAC) specification provides a common language to describe a range of geospatial information, so it can more easily be indexed and discovered. A 'spatiotemporal asset' is any file that represents information about the earth captured in a certain space and time. STAC provides a standards-based, web and cloud friendly cataloging specification that has seen a large amount of adoption in the cloud geospatial information system space. This presentation will demonstrate how NASA EOSDIS leverages STAC technology to provide value-added features to both our data discovery and transformation services. Finally, we will propose a way to improve our federated discovery capabilities using STAC.

NASA EOSDIS STAC Cloud catalog metadata↗

NASA NTRSDate not supplied

STAC: an EOSDIS standard

‘The Spatio Temporal Asset Catalogs (STAC) specification is a common language to describe geospatial information, so spatiotemporal assets can more easily be leveraged, indexed, and discovered.’*

Doug Newman↗

NASA NTRSDate not supplied

WGISS-56 STAC Best practices

‘The Spatio Temporal Asset Catalogs (STAC) specification is a common language to describe geospatial information, so spatiotemporal assets can more easily be leveraged, indexed, and discovered. This presentation describes how this specification can be successfully applied to federated discovery.

Doug Newman↗

NASA NTRS2026

Integrated Computational Materials Engineering (ICME) Capability Maturity Levels for Ecosystems Enabling Digital Transformation

Digital engineering (DE) and integrated computational materials engineering (ICME) are widely recognized as critical enablers of faster, more affordable, and more reliable aerospace systems. However, many organizations have struggled to realize the promised return on investment (ROI) from digital initiatives. A primary reason is the absence of a shared, decision-focused framework that distinguishes simple digitization of existing workflows from true digital transformation that fundamentally changes how engineering decisions are made. This paper introduces an ICME capability maturity framework that fills this gap. The framework defines six cumulative ICME capability maturity levels (CMLs), explicitly tied to decision authority, engineering integration, optimization, and uncertainty management across material, process, structure, and performance scales. It is designed to complement established readiness metrics such as technology readiness levels (TRLs), manufacturing readiness levels (MRLs), and integration readiness levels (IRLs), by addressing a missing dimension: the conditions required for model-informed decision authority across scales. A unifying figure and capability table illustrate the six-level ICME Capability Maturity Framework, showing how organizations progress from digitization—with limited or negative ROI—to true digital transformation, where ICME-enabled workflows deliver measurable improvements in decision quality, cycle time, risk reduction, and reuse. The framework is intended for both technical practitioners and executive leadership, providing a common language to assess current state, guide roadmaps, align software ecosystem investments, and set realistic expectations for digital transformation outcomes. A regulatory-relevant statement clarifying the relationship between ICME capability and existing certification frameworks is provided.

ICME↗

NASA NTRS1995

Primate Language and Cognition: Common Ground

Research of the past decade has served to underscore the close psychological relationship between humans, chimpanzees, and the other great apes. In his evolutionary theory, Darwin (1860, 1871) posited both psychological and biological continuities between animals and humans. Although the evidence for biological continuity has been strong for decades, the evidence necessary for affirmation of psychological continuity is recent.

Rumbaugh, Duane↗

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 NTRS1978

A survey of electric and hybrid vehicle simulation programs

Results of a survey conducted within the United States to determine the extent of development and capabilities of automotive performance simulation programs suitable for electric and hybrid vehicle studies are summarized. Altogether, 111 programs were identified as being in a usable state. The complexity of the existing programs spans a range from a page of simple desktop calculator instructions to 300,000 lines of a high-level programming language. The capability to simulate electric vehicles was most common, heat-engines second, and hybrid vehicles least common. Batch-operated programs are slightly more common than interactive ones, and one-third can be operated in either mode. The most commonly used language was FORTRAN, the language typically used by engineers. The higher-level simulation languages (e.g. SIMSCRIPT, GPSS, SIMULA) used by "model builders" were conspicuously lacking.

Bevan, J.↗

NASA NTRS2011

SPASE: The Connection Among Solar and Space Physics Data Centers

The Space Physics Archive Search and Extract (SPASE) project is an international collaboration among Heliophysics (solar and space physics) groups concerned with data acquisition and archiving. Within this community there are a variety of old and new data centers, resident archives, "virtual observatories", etc. acquiring, holding, and distributing data. A researcher interested in finding data of value for his or her study faces a complex data environment. The SPASE group has simplified the search for data through the development of the SPASE Data Model as a common method to describe data sets in the various archives. The data model is an XML-based schema and is now in operational use. There are both positives and negatives to this approach. The advantage is the common metadata language enabling wide-ranging searches across the archives, but it is difficult to inspire the data holders to spend the time necessary to describe their data using the Model. Software tools have helped, but the main motivational factor is wide-ranging use of the standard by the community. The use is expanding, but there are still other groups who could benefit from adopting SPASE. The SPASE Data Model is also being expanded in the sense of providing the means for more detailed description of data sets with the aim of enabling more automated ingestion and use of the data through detailed format descriptions. We will discuss the present state of SPASE usage and how we foresee development in the future. The evolution is based on a number of lessons learned - some unique to Heliophysics, but many common to the various data disciplines.

Thieman, James R.↗

NASA NTRS1999

Configuration Management of an Optimization Application in a Research Environment

Multidisciplinary design optimization (MDO) research aims to increase interdisciplinary communication and reduce design cycle time by combining system analyses (simulations) with design space search and decision making. The High Performance Computing and Communication Program's current High Speed Civil Transport application, HSCT4.0, at NASA Langley Research Center involves a highly complex analysis process with high-fidelity analyses that are more realistic than previous efforts at the Center. The multidisciplinary processes have been integrated to form a distributed application by using the Java language and Common Object Request Broker Architecture (CORBA) software techniques. HSCT4.0 is a research project in which both the application problem and the implementation strategy have evolved as the MDO and integration issues became better understood. Whereas earlier versions of the application and integrated system were developed with a simple, manual software configuration management (SCM) process, it was evident that this larger project required a more formal SCM procedure. This report briefly describes the HSCT4.0 analysis and its CORBA implementation and then discusses some SCM concepts and their application to this project. In anticipation that SCM will prove beneficial for other large research projects, the report concludes with some lessons learned in overcoming SCM implementation problems for HSCT4.0.

Townsend, James C.↗

NASA NTRS1999

Advanced Design and Implementation of a Control Architecture for Long Range Autonomous Planetary Rovers

An advanced design and implementation of a Control Architecture for Long Range Autonomous Planetary Rovers is presented using a hierarchical top-down task decomposition, and the common structure of each design is presented based on feedback control theory. Graphical programming is presented as a common intuitive language for the design when a large design team is composed of managers, architecture designers, engineers, programmers, and maintenance personnel. The whole design of the control architecture consists in the classic control concepts of cyclic data processing and event-driven reaction to achieve all the reasoning and behaviors needed. For this purpose, a commercial graphical tool is presented that includes the mentioned control capabilities. Messages queues are used for inter-communication among control functions, allowing Artificial Intelligence (AI) reasoning techniques based on queue manipulation. Experimental results show a highly autonomous control system running in real time on top the JPL micro-rover Rocky 7 controlling simultaneously several robotic devices. This paper validates the sinergy between Artificial Intelligence and classic control concepts in having in advanced Control Architecture for Long Range Autonomous Planetary Rovers.

Martin-Alvarez, A.↗

NASA NTRS2005

Science Communication versus Science Education: The Graduate Student Scientist as a K-12 Classroom Resource

Science literacy is a major goal of science educational reform (NRC, 1996; AAAS, 1998; NCLB Act, 2001). Some believe that teaching science only requires pedagogical content knowledge (PCK). Others believe doing science requires knowledge of the methodologies of scientific inquiry (NRC, 1996). With these two mindsets, the challenge for science educators is to create models that bring the two together. The common ground between those who teach science and those who do science is science communication, an interactive process that galvanizes dialogue among scientists, teachers, and learners in a rich ambience of mutual respect and a common, inclusive language of discourse . The dialogue between science and non-science is reflected in the polarization that separates those who do science and those who teach science, especially as it plays out everyday in the science classroom. You may be thinking, why is this important? It is vital because, although not all science learners become scientists, all K-12 students are expected to acquire science literacy, especially with the implementation of the No Child Left Behind Act of 2001 (NCLB). Students are expected to acquire the ability to follow the discourse of science as well as connect the world of science to the context of their everyday life if they plan on moving to the next grade level, and in some states, to graduate from high school. This paper posits that science communication is highly effective in providing the missing link for K-12 students cognition in science and their attainment of science literacy. This paper will focus on the "Science For Our Schools" (SFOS) model implemented at California State Univetsity, Los Angeles (CSULA) as a project of the National Science Foundation s GK-12 program, (NSF 2001) which has been a huge success in bridging the gap between those who "know" science and those who "teach" science. The SFOS model makes clear the distinctions that identify science, science communication, science education, and science literacy in the midst of science learning by bringing together graduate student scientists and science teachers to engage students in the two world s dialogue in the midst of the school science classroom. The graduate student scientists and the science teachers worked as a team throughout the school year and became effective science Communicators as they narrowed the gulf between the two worlds. 1

communications↗

NASA NTRS2017

End-to-End Trade-Space Analysis for Designing Constellation

Multipoint measurement missions can provide a significant advancement in science return and this science interest coupled with as many recent technological advances are driving a growing trend in exploring distributed architectures for future NASA missions. Distributed Spacecraft Missions (DSMs) leverage multiple spacecraft to achieve one or more common goals. In particular, a constellation is the most general form of DSM with two or more spacecraft placed into specific orbit(s) for the purpose of serving a common objective (e.g., CYGNSS). Because a DSM architectural trade-space includes both monolithic and distributed design variables, DSM optimization is a large and complex problem with multiple conflicting objectives. Over the last two years, our team has been developing a Trade-space Analysis Tool for Constellations (TAT-C), implemented in common programming languages for pre-Phase A constellation mission analysis. By evaluating alternative mission architectures, TAT-C seeks to minimize cost and maximize performance for pre-defined science goals. This presentation will describe the overall architecture of TAT-C including: a User Interface (UI) at several levels of details and user expertise; Trade-space Search Requests that are created from the Science requirements gathered by the UI and validated by a Knowledge Base; a Knowledge Base to compare the current requests to prior mission concepts to potentially prune the trade-space; a Trade-space Search Iterator which, with inputs from the Knowledge Base, and, in collaboration with the Orbit & Coverage, Reduction & Metrics, and Cost& Risk modules, generates multiple potential architectures and their associated characteristics. TAT-C leverages the use of the Goddard Mission Analysis Tool (GMAT) to compute coverage and ancillary data, modeling orbits to balance accuracy and performance. The current version includes uniform and non-uniform Walker constellations as well as Ad-Hoc and precessing constellations, and its cost model represents an aggregate model consisting of Cost Estimating Relationships (CERs) from widely accepted models. The current GUI automatically generates graphics representing metrics such as average revisit time or coverage as a function of cost. The end-to-end system will be demonstrated as part of the presentation.

Mission Desig↗

NASA NTRSDate not supplied

Developing and Testing a Common Space Systems Ontology using the Ontological Modeling Language

This paper describes the development and testing of the initial version of a common space systems ontology (CoSSO) for use by the Advanced Concepts Office (ACO) at NASA's Marshall Space Flight Center. The ontology provides a shared conceptualization of concepts of interest to the ACO for modeling aerospace systems concepts in a pre-phase A context to aid with the transition to a more model-based paradigm. The ontological concepts and relations, as well as the anticipated use cases, were developed through interactions with the relevant subject matter experts at the ACO and implemented in the Ontological Modeling Language (OML). The ontology builds on the Basic Formal Ontology (BFO) and the Common Core Ontologies (CCO). While most of the ontology is still in the initial stages, an Environmental Control and Life Support System (ECLSS) ontology is being built on top of the main CoSSO and heavily developed as a proof of concept. The ECLSS ontology is designed with different use cases in mind, namely predicting and diagnosing errors in ECLS systems on long-duration missions, with a focus on the Four-Bed CO$_2$ carbon dioxide scrubber currently on board the ISS. The ECLSS ontology is being developed in a similar manner to the CoSSO, and designed to be compatible with it. The current state of both ontologies is presented and discussed, along with plans for future development and testing.

Conceptual Design↗

NASA NTRS1986

A study of the very high order natural user language (with AI capabilities) for the NASA space station common module

The requirements are identified for a very high order natural language to be used by crew members on board the Space Station. The hardware facilities, databases, realtime processes, and software support are discussed. The operations and capabilities that will be required in both normal (routine) and abnormal (nonroutine) situations are evaluated. A structure and syntax for an interface (front-end) language to satisfy the above requirements are recommended.

Gill, E. N.↗

NASA NTRS1986

Integration of an expert system into a user interface language demonstration

The need for a User Interface Language (UIL) has been recognized by the Space Station Program Office as a necessary tool to aid in minimizing the cost of software generation by multiple users. Previous history in the Space Shuttle Program has shown that many different areas of software generation, such as operations, integration, testing, etc., have each used a different user command language although the types of operations being performed were similar in many respects. Since the Space Station represents a much more complex software task, a common user command language--a user interface language--is required to support the large spectrum of space station software developers and users. To assist in the selection of an appropriate set of definitions for a UIL, a series of demonstration programs was generated with which to test UIL concepts against specific Space Station scenarios using operators for the astronaut and scientific community. Because of the importance of expert system in the space station, it was decided that an expert system should be embedded in the UIL. This would not only provide insight into the UIL components required but would indicate the effectiveness with which an expert system could function in such an environment.

Stclair, D. C.↗

NASA NTRS1990

IDEF4 technical report, version 1.0

A language for the representation of object oriented software designs is described. IDEF4, a methodology for object-oriented design, is being developed as a design tool for software designers who use such object-oriented languages. Such languages include the Common LISP Object System, Flavors, C++, Smalltalk, Objective C, and others. Since effective usage of the object-oriented paradigm requires a different thought process than that used with conventional procedural or database languages, standard methodologies such as structure charts, data flow diagrams, and traditional data design models (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide the necessary facilities to support the object-oriented design decision making process. Specifically, the two primary design goals of IDEF4 are: (1) to provide support for creating object oriented designs whose implementations will exhibit desirable life cycle qualities and reduce total implementation development time; and (2) to make it easy to evaluate object oriented code to determine whether or not the delivered product both conforms to the design and exhibits the desired life cycle qualities. The application of IDEF4 in the life cycle of a software development project is intended to be focused on those activities after a decision has been made to employ object oriented programming technology, but prior to detailed code specification.

Mayer, Richard J.↗

NASA NTRS1972

A brief description and comparison of programming languages FORTRAN, ALGOL, COBOL, PL/1, and LISP 1.5 from a critical standpoint

Several common higher level program languages are described. FORTRAN, ALGOL, COBOL, PL/1, and LISP 1.5 are summarized and compared. FORTRAN is the most widely used scientific programming language. ALGOL is a more powerful language for scientific programming. COBOL is used for most commercial programming applications. LISP 1.5 is primarily a list-processing language. PL/1 attempts to combine the desirable features of FORTRAN, ALGOL, and COBOL into a single language.

Mathur, F. P.↗