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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

NASA Data Acquisition System Software Development for Rocket Propulsion Test Facilities

Current NASA propulsion test facilities include Stennis Space Center in Mississippi, Marshall Space Flight Center in Alabama, Plum Brook Station in Ohio, and White Sands Test Facility in New Mexico. Within and across these centers, a diverse set of data acquisition systems exist with different hardware and software platforms. The NASA Data Acquisition System (NDAS) is a software suite designed to operate and control many critical aspects of rocket engine testing. The software suite combines real-time data visualization, data recording to a variety formats, short-term and long-term acquisition system calibration capabilities, test stand configuration control, and a variety of data post-processing capabilities. Additionally, data stream conversion functions exist to translate test facility data streams to and from downstream systems, including engine customer systems. The primary design goals for NDAS are flexibility, extensibility, and modularity. Providing a common user interface for a variety of hardware platforms helps drive consistency and error reduction during testing. In addition, with an understanding that test facilities have different requirements and setups, the software is designed to be modular. One engine program may require real-time displays and data recording; others may require more complex data stream conversion, measurement filtering, or test stand configuration management. The NDAS suite allows test facilities to choose which components to use based on their specific needs. The NDAS code is primarily written in LabVIEW, a graphical, data-flow driven language. Although LabVIEW is a general-purpose programming language; large-scale software development in the language is relatively rare compared to more commonly used languages. The NDAS software suite also makes extensive use of a new, advanced development framework called the Actor Framework. The Actor Framework provides a level of code reuse and extensibility that has previously been difficult to achieve using LabVIEW. The

Herbert, Phillip W., Sr.↗
NASA NTRS1978

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.↗
NASA NTRS1979

ATLAS, an integrated structural analysis and design system. Volume 3: User's manual, input and execution data

The input data and execution control statements for the ATLAS integrated structural analysis and design system are described. It is operational on the Control Data Corporation (CDC) 6600/CYBER computers in a batch mode or in a time-shared mode via interactive graphic or text terminals. ATLAS is a modular system of computer codes with common executive and data base management components. The system provides an extensive set of general-purpose technical programs with analytical capabilities including stiffness, stress, loads, mass, substructuring, strength design, unsteady aerodynamics, vibration, and flutter analyses. The sequence and mode of execution of selected program modules are controlled via a common user-oriented language.

Dreisbach, R. L.↗
NASA NTRS1990

A conceptual model for megaprogramming

Megaprogramming is component-based software engineering and life-cycle management. Magaprogramming and its relationship to other research initiatives (common prototyping system/common prototyping language, domain specific software architectures, and software understanding) are analyzed. The desirable attributes of megaprogramming software components are identified and a software development model and resulting prototype megaprogramming system (library interconnection language extended by annotated Ada) are described.

Tracz, Will↗
NASA NTRS1993

Probabilistic Scale-Space Filtering Program

Probabilistic Scale-Space Filtering (PSF) computer program implements scale-space technique to describe input signals as collections of nested hills and valleys organized in treelike structure. Helps to construct sparse representations of complicated signals. Calculates probabilities, with extracted features corresponding to physical processes. Written in C language (49 percent) and Common Lisp (51 percent).

Kulkarni, Deepak↗
NASA NTRS2008

Displaying Composite and Archived Soundings in the Advanced Weather Interactive Processing System

In a previous task, the Applied Meteorology Unit (AMU) developed spatial and temporal climatologies of lightning occurrence based on eight atmospheric flow regimes. The AMU created climatological, or composite, soundings of wind speed and direction, temperature, and dew point temperature at four rawinsonde observation stations at Jacksonville, Tampa, Miami, and Cape Canaveral Air Force Station, for each of the eight flow regimes. The composite soundings were delivered to the National Weather Service (NWS) Melbourne (MLB) office for display using the National version of the Skew-T Hodograph analysis and Research Program (NSHARP) software program. The NWS MLB requested the AMU make the composite soundings available for display in the Advanced Weather Interactive Processing System (AWIPS), so they could be overlaid on current observed soundings. This will allow the forecasters to compare the current state of the atmosphere with climatology. This presentation describes how the AMU converted the composite soundings from NSHARP Archive format to Network Common Data Form (NetCDF) format, so that the soundings could be displayed in AWl PS. The NetCDF is a set of data formats, programming interfaces, and software libraries used to read and write scientific data files. In AWIPS, each meteorological data type, such as soundings or surface observations, has a unique NetCDF format. Each format is described by a NetCDF template file. Although NetCDF files are in binary format, they can be converted to a text format called network Common data form Description Language (CDL). A software utility called ncgen is used to create a NetCDF file from a CDL file, while the ncdump utility is used to create a CDL file from a NetCDF file. An AWIPS receives soundings in Binary Universal Form for the Representation of Meteorological data (BUFR) format (http://dss.ucar.edu/docs/formats/bufr/), and then decodes them into NetCDF format. Only two sounding files are generated in AWIPS per day. One file contains all of the soundings received worldwide between 0000 UTC and 1200 UTC, and the other includes all soundings between 1200 UTC and 0000 UTC. In order to add the composite soundings into AWIPS, a procedure was created to configure, or localize, AWIPS. This involved modifying and creating several configuration text files. A unique fourcharacter site identifier was created for each of the 32 soundings so each could be viewed separately. The first three characters were based on the site identifier of the observed sounding, while the last character was based on the flow regime. While researching the localization process for soundings, the AMU discovered a method of archiving soundings so old soundings would not get purged automatically by AWl PS. This method could provide an alternative way of localizing AWl PS for composite soundings. In addition, this would allow forecasters to use archived soundings in AWIPS for case studies. A test sounding file in NetCDF format was written in order to verify the correct format for soundings in AWIPS. After the file was viewed successfully in AWIPS, the AMU wrote a software program in the Tool Command Language/Tool Kit (Tcl/Tk) language to convert the 32 composite soundings from NSHARP Archive to CDL format. The ncgen utility was then used to convert the CDL file to a NetCDF file. The NetCDF file could then be read and displayed in AWIPS.

Barrett, Joe H., III↗
NASA NTRS2014

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↗
NASA NTRS2014

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↗
NASA NTRS1993

Programming Language Software For Graphics Applications

New approach reduces repetitive development of features common to different applications. High-level programming language and interactive environment with access to graphical hardware and software created by adding graphical commands and other constructs to standardized, general-purpose programming language, "Scheme". Designed for use in developing other software incorporating interactive computer-graphics capabilities into application programs. Provides alternative to programming entire applications in C or FORTRAN, specifically ameliorating design and implementation of complex control and data structures typifying applications with interactive graphics. Enables experimental programming and rapid development of prototype software, and yields high-level programs serving as executable versions of software-design documentation.

Beckman, Brian C.↗
NASA NTRS2004

Hard Real-Time: C++ Versus RTSJ

In the domain of hard real-time systems, which language is better: C++ or the Real-Time Specification for Java (RTSJ)? Although ordinary Java provides a more productive programming environment than C++ due to its automatic memory management, that benefit does not apply to RTSJ when using NoHeapRealtimeThread and non-heap memory areas. As a result, RTSJ programmers must manage non-heap memory explicitly. While that's not a deterrent for veteran real-time programmers-where explicit memory management is common-the lack of certain language features in RTSJ (and Java) makes that manual memory management harder to accomplish safely than in C++. This paper illustrates the problem for practitioners in the context of moving data and managing memory in a real-time producer/consumer pattern. The relative ease of implementation and safety of the C++ programming model suggests that RTSJ has a struggle ahead in the domain of hard real-time applications, despite its other attractive features.

programming model↗
NASA NTRS2021

Report on Workshop on Artificial Intelligence in Strategic Planning and Science Prioritization

This report details the observations from a two-day virtual workshop, held May 12-13, 2020, focused on whether, and how, artificial intelligence (AI) could assist humans in strategic planning, specifically in science and technology prioritization. The participants identified several “key challenges” that AI might tackle in this area. To further understand the value of these key challenges the workshop then developed related test cases that would demonstrate specifically how AI/machine learning (ML) could provide assistance to humans. Approximately 40 subject matter experts (SMEs), with backgrounds in AI, strategic planning for science, and scientific data, were gathered for the conference. This report collates the details of the output of the workshop. The “best” test cases include (in no particular order):Use of AI to assist in selecting Decadal Survey priorities. * Use of AI to identify new, or previously unidentified, science topics for prioritization. * Using AI to better label and increase discoverability of scientific literature and proposals. * Use of AI to enhance current observation capabilities for scientific missions. * Using AI to mitigate biases in selection of proposal reviewers and membership of advisory committees. Examination of these test cases indicates that Natural Language Processing (NLP) is a common capability found in most of the ”best” (top-rated) test cases and is a valuable, multi-purpose tool which enables ML in this area.

strategic planning↗
NASA NTRS1984

RAMIS DBMS Update

Highlights of a round table discussion of end-user computing, IBM strategies, fourth generation languages, and directions for software innovation are presented as well as observations from an in-depth study of 271 organizations. The RAMIS data base management system is evaluated according to 10 defining criteria for a fourth-generation language: result-oriented programming; common language/demand level adaptability; application extension; user/machine insulation; work station environment; comprehensive software toolkit; integrating perspective on computing and data resources; end user data base capability; accessible dictionaries; and user assistance/facility coordination.

Head, J.↗
NASA NTRS1995

Statistical properties of DNA sequences

We review evidence supporting the idea that the DNA sequence in genes containing non-coding regions is correlated, and that the correlation is remarkably long range--indeed, nucleotides thousands of base pairs distant are correlated. We do not find such a long-range correlation in the coding regions of the gene. We resolve the problem of the "non-stationarity" feature of the sequence of base pairs by applying a new algorithm called detrended fluctuation analysis (DFA). We address the claim of Voss that there is no difference in the statistical properties of coding and non-coding regions of DNA by systematically applying the DFA algorithm, as well as standard FFT analysis, to every DNA sequence (33301 coding and 29453 non-coding) in the entire GenBank database. Finally, we describe briefly some recent work showing that the non-coding sequences have certain statistical features in common with natural and artificial languages. Specifically, we adapt to DNA the Zipf approach to analyzing linguistic texts. These statistical properties of non-coding sequences support the possibility that non-coding regions of DNA may carry biological information.

Non-NASA Center↗
NASA NTRS2015

Ah, Sweet Mystery of Life, OSIRIS-REx May Find You

The nature of the origin of life is a topic that has engaged people since ancient times. Where did we come from? What was the first life? How are we related? Are we alone? The study of biologic remains and environments preserved in rocks (fossils) and biochemical pathways and structures found across organisms (molecular fossils) can address these questions. Molecular evidence shows that all life on Earth is related fundamentally, biology shares a genetic language, related molecular machinery, and common chemistry By looking at the details of genetic and protein sequences more detailed relationships can be determined for modern organisms.

origin of life↗
NASA NTRS2015

The Use of UML for Software Requirements Expression and Management

It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.

model-based engineering↗
NASA NTRS2020

Ancient Martian aeolian sand dune deposits recorded in the stratigraphy of Valles Marineris and implications for past climates

Aeolian sediment transport, deposition, and erosion have been ongoing throughout Mars’ history. This record of widespread aeolian processes is preserved in landforms and geologic units that retain important clues about past environmental conditions including wind patterns. In this study we describe landforms within Melas Chasma, Valles Marineris, that occur in distinct groups with linear to crescentic shapes, arranged with a characteristic wavelength; some possess slope profiles analogous to modern sand dunes, yet show evidence for lithification. Based on the features’ dimensions, asymmetry, and spatial patterns relative to modern equivalents, we interpret these landforms to be two classes of aeolian bedforms: decameter-scale mega-ripples and sand dunes. The presence of superposed erosional features and depositional units indicates these landforms were cemented and likely ancient. Melas paleo-dunes are found atop Hesperian-aged layered deposits, but we estimate them to be younger, likely lithified in the Amazonian period. Although a range of degradation was observed, some paleo-dunes are >10 m tall and maintain steep lee sides (>25°), an uncommon scenario for terrestrial examples as other geologic processes lead to dune obliteration. The preserved paleo-bedform geometries are largely consistent with those of modern aeolian indicators, suggesting no major shifts in wind regime or contributing boundary conditions. Finally, we propose their appearance and context require sequential periods of dune migration, stabilization following catastrophic burial, cementation, differential erosion, exposure, and burial. The presence of wholly preserved duneforms appears to be more common on Mars compared to the Earth and may signal something important about Martian landscape evolution. Plain Language Summary Wind-driven sand dunes are common on modern Mars and the presence of certain sedimentary rock layers indicates these landforms occurred there in the past. Here, we explore features in the canyons of Valles Marineris which show characteristics frequently attributed to dunes, yet evidence for their lithification and burial is clear. Their horizontal extent, height, shape, slopes, and collective spatial patterns led to our interpretation of them as lithified dune fields. The heavily eroded appearance along with superposed elements such as craters and boulders led to the conclusion that these are relatively ancient landforms. Despite this erosion This level of preservation is rare for terrestrial sand dunes due to erosion and tectonics, thus providing an opportunity to reconstruct the various factors contributing to their history. Understanding the circumstances that led to the preservation of these ancient duneforms will yield crucial information regarding planetary sedimentary processes and the geologic history of the region.

Matthew Chojnacki↗
NASA NTRS2000

Supporting Development of Satellite's Guidance Navigation and Control Software: A Product Line Approach

The NASA Goddard Space Flight Center Flight Software Branch (FSB) is developing a Guidance, Navigation, and Control (GNC) Flight Software (FSW) product line. The demand for increasingly more complex flight software in less time while maintaining the same level of quality has motivated us to look for better FSW development strategies. The GNC FSW product line has been planned to address the core GNC FSW functionality very similar on many recent low/near Earth missions in the last ten years. Unfortunately these missions have not accomplished significant drops in development cost since a systematic approach towards reuse has not been adopted. In addition, new demands are continually being placed upon the FSW which means the FSB must become more adept at providing GNC FSW functionality's core so it can accommodate additional requirements. These domain features together with engineering concepts are influencing the specification, description and evaluation of FSW product line. Domain engineering is the foundation for emerging product line software development approaches. A product line is 'A family of products designed to take advantage of their common aspects and predicted variabilities'. In our product line approach, domain engineering includes the engineering activities needed to produce reusable artifacts for a domain. Application engineering refers to developing an application in the domain starting from reusable artifacts. The focus of this paper is regarding the software process, lessons learned and on how the GNC FSW product line manages variability. Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adapt ability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions. While most domain analysis approaches are functionally oriented, the idea of applying the object-oriented approach in domain analysis is not new. Some authors propose to use UML as the notation underlying domain analysis. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. The extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support. The paper outlines the product line processes and identifies where variability must be addressed. Then it describes the product line products with respect to how they accommodate variability. The Celestial Body subdomain is used as a working example. Our results to date are summarized and plans for the future are described.

McComas, David↗
NASA NTRS2011

RAPID: Collaborative Commanding and Monitoring of Lunar Assets

RAPID (Robot Application Programming Interface Delegate) software utilizes highly robust technology to facilitate commanding and monitoring of lunar assets. RAPID provides the ability for intercenter communication, since these assets are developed in multiple NASA centers. RAPID is targeted at the task of lunar operations; specifically, operations that deal with robotic assets, cranes, and astronaut spacesuits, often developed at different NASA centers. RAPID allows for a uniform way to command and monitor these assets. Commands can be issued to take images, and monitoring is done via telemetry data from the asset. There are two unique features to RAPID: First, it allows any operator from any NASA center to control any NASA lunar asset, regardless of location. Second, by abstracting the native language for specific assets to a common set of messages, an operator may control and monitor any NASA lunar asset by being trained only on the use of RAPID, rather than the specific asset. RAPID is easier to use and more powerful than its predecessor, the Astronaut Interface Device (AID). Utilizing the new robust middleware, DDS (Data Distribution System), developing in RAPID has increased significantly over the old middleware. The API is built upon the Java Eclipse Platform, which combined with DDS, provides platform-independent software architecture, simplifying development of RAPID components. As RAPID continues to evolve and new messages are being designed and implemented, operators for future lunar missions will have a rich environment for commanding and monitoring assets.

Torres, Recaredo J.↗