Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “abstraction layers”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

A new template for developing C++ applications in NASA's Core Flight System

In this presentation, we will demonstrate an example Core Flight System (cFS) application written in C++, compatible with the Draco releases of the Core Flight Executive (cFE) and NASA Operating System Abstraction Layer (OSAL). The application boilerplate, supporting library, and associated generation script were recently developed and licensed under the permissive Apache License 2.0 with the goal of easing the cFS app development with C++. The design and features of this application will be presented, including a higher-level interface for interactions with the cFE software bus pipes, tables, and event services. Data structures are provided for centralized telecommand and telemetry parsing which isolates bookkeeping of message components from the calling code in an application's core logic. Specific advantages of writing a cFS application in C++ will be shown, including easier avoidance of symbol collisions via namespaces, expanded compile-time checks via constant expressions, default initialization for data structures, null safety via references, improved syntax for operating on multi-dimensional arrays, and reliable serialization of enumerations via enumeration classes. Special considerations needed for integrating a C++ application will be identified, including function linkage, exceptions, and stack unwinding. Evidence for the usefulness of this template will be discussed in the context of development of a flight software application used for interfacing with a solid-state data recorder.

Dominick Allen↗
NASA NTRS1982

Portable design rules for bulk CMOS

It is pointed out that for the past several years, one school of IC designers has used a simplified set of nMOS geometric design rules (GDR) which is 'portable', in that it can be used by many different nMOS manufacturers. The present investigation is concerned with a preliminary set of design rules for bulk CMOS which has been verified for simple test structures. The GDR are defined in terms of Caltech Intermediate Form (CIF), which is a geometry-description language that defines simple geometrical objects in layers. The layers are abstractions of physical mask layers. The design rules do not presume the existence of any particular design methodology. Attention is given to p-well and n-well CMOS processes, bulk CMOS and CMOS-SOS, CMOS geometric rules, and a description of the advantages of CMOS technology.

Griswold, T. W.↗
NASA NTRS1999

Cellular Decomposition Based Hybrid-Hierarchical Control Systems with Applications to Flight Management Systems

The work in this research project has been focused on the construction of a hierarchical hybrid control theory which is applicable to flight management systems. The motivation and underlying philosophical position for this work has been that the scale, inherent complexity and the large number of agents (aircraft) involved in an air traffic system imply that a hierarchical modelling and control methodology is required for its management and real time control. In the current work the complex discrete or continuous state space of a system with a small number of agents is aggregated in such a way that discrete (finite state machine or supervisory automaton) controlled dynamics are abstracted from the system's behaviour. High level control may then be either directly applied at this abstracted level, or, if this is in itself of significant complexity, further layers of abstractions may be created to produce a system with an acceptable degree of complexity at each level. By the nature of this construction, high level commands are necessarily realizable at lower levels in the system.

Caines, P. E.↗
NASA NTRS1985

An integrated modular environment for SAGA

A key component of the 'SAGA' metatool system for software development support is an integrated modular environment that furnishes a uniform view of software components and can be adapted for different programming languages and development methodologies. Attention is presently given to the model/representation of the entities thus used in software development; programs are structured on the basis of modules whose relationships form layers of abstraction. Different views of the program under development are provided for different development phases. The implementation of the modular environment based on the model of a UNIX system is presented.

Kirslis, Peter A.↗
NASA NTRS1990

Advanced software integration: The case for ITV facilities

The array of technologies and methodologies involved in the development and integration of avionics software has moved almost as rapidly as computer technology itself. Future avionics systems involve major advances and risks in the following areas: (1) Complexity; (2) Connectivity; (3) Security; (4) Duration; and (5) Software engineering. From an architectural standpoint, the systems will be much more distributed, involve session-based user interfaces, and have the layered architectures typified in the layers of abstraction concepts popular in networking. Typified in the NASA Space Station Freedom will be the highly distributed nature of software development itself. Systems composed of independent components developed in parallel must be bound by rigid standards and interfaces, the clean requirements and specifications. Avionics software provides a challenge in that it can not be flight tested until the first time it literally flies. It is the binding of requirements for such an integration environment into the advances and risks of future avionics systems that form the basis of the presented concept and the basic Integration, Test, and Verification concept within the development and integration life cycle of Space Station Mission and Avionics systems.

Garman, John R.↗
NASA NTRS2017

Generating Real-Time Robotics Control Software from SysML

In this paper, we outline an approach for autogenerating real-time robotics control code from hierarchical state machines and hardware configurations encoded in Systems Modeling Language (SysML). We propose a software architecture that provides an abstract SysML layer with access to device state information and a set of primitive device commands, such as move actuator and release brake, allowing a user to build up a complete functional state machine directly in SysML. The SysML diagram is then exported to a standard SCXML file format and subsequently used to auto-generate hardware control code. Once this architecture is in place, the only explicit code elements that need to be written are the primitive device commands, which can be easily unit tested and reused across different systems. The motivation for this work was the need for a test bed that enables the rapid prototyping of mechanisms and control algorithms for a spacecraft that could ultimately be used for preparing Martian rock samples for their return to Earth. To this end, our software system was also designed to allow for the run-time specification of the hardware layout in SysML, with the hardware-level control functions kept agnostic to the specific parameters or communication bus of any particular device. Further, we outline a system for specifying both the state machine and hardware configuration in the MagicDraw IDE in such a way that the system can be simulated before any code is generated. The resultant software system is easy to debug, understand, and allows users to choose how much information is encoded as a visual or text-based representation.

Godart, Peter↗
NASA NTRS1994

(abstract) Experimental Evaluation of Russian Anode Layer Thruster

This paper describes the results of a preliminary evaluation of a 1.35 kW anode layer thruster. Data on performance and plume characteristics will be presented. Data on thruster characteristics such as thrust, plume current densities, discharge voltage, discharge current, and mass flow rate along with the results of a 500-hour endurance test wear will be presented.

anode layer thrusters SPT thrusters propulsion end↗
NASA NTRS2015

A Modeling Pattern for Layered System Interfaces

Communications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi-layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end-to-end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes. This architectural model pattern uses methods described in ISO 42010, Recommended Practice for Architectural Description of Software-intensive Systems and CCSDS 311.0-M-1, Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.

Shames, Peter M.↗
NASA NTRS1986

High-Level Data-Abstraction System

Communication with data-base processor flexible and efficient. High Level Data Abstraction (HILDA) system is three-layer system supporting data-abstraction features of Intel data-base processor (DBP). Purpose of HILDA establishment of flexible method of efficiently communicating with DBP. Power of HILDA lies in its extensibility with regard to syntax and semantic changes. HILDA's high-level query language readily modified. Offers powerful potential to computer sites where DBP attached to DEC VAX-series computer. HILDA system written in Pascal and FORTRAN 77 for interactive execution.

Fishwick, P. A.↗
NASA NTRS2003

CLARAty Functional-Layer Software

Functional-layer software for the Coupled Layer Architecture for Robotics Autonomy (CLARAty) is being developed. [CLARAty was described in Coupled-Layer Architecture for Advanced Software for Robots (NPO-21218), NASA Tech Briefs, Vol. 26, No. 12 (December 2002), page 48. To recapitulate: CLARAty was proposed to improve the modularity of robotic software while tightening the coupling between planning/execution and control subsystems. Whereas prior robotic software architectures have typically contained three levels, the CLARAty architecture contains two layers: a decision layer and a functional layer.] Just as an operating system provides abstraction from computational hardware, the CLARAty functional-layer software provides for abstraction for the different robotic systems. The functional-layer software establishes interrelated, object-oriented hierarchies that contain active and passive objects that represent the different levels of system abstrations and components. The functional-layer software is decomposed into a set of reusable core components and a set of extended components that adapt the reusable set to specific hardware implementations. The reusable components (a) provide behavior and interface definitions and implementations of basic functionality, (b) provide local executive capabilities, (c) manage local resources, and (d) support state and resource queries by the decision layer. Software for robotic systems can be built by use of these components.

Nesnas, Issa↗