Engineering topics

Auty, David

Publications and source records attributed to Auty, David.

8 records

NASA NTRS1992

Mission and Safety Critical (MASC): An EVACS simulation with nested transactions

The Extra-Vehicular Activity Control System (EVACS) Simulation with Nested Transactions, a recent effort of the MISSION Kernel Team, is documented. The EVACS simulation is a simulation of some aspects of the Extra-Vehicular Activity Control System, in particular, just the selection of communication frequencies. The simulation is a tool to explore mission and safety critical (MASC) applications. For the purpose of this effort, its current definition is quite narrow serving only as a starting point for prototyping purposes. (Note that EVACS itself has been supplanted in a larger scenario of a lunar outpost with astronauts and a lunar rover). The frequency selection scenario was modified to embed its processing in nested transactions. Again as a first step, only two aspects of transaction support were implemented in this prototype: architecture and state recovery. Issues of concurrency and distribution are yet to be addressed.

Auty, David↗

NASA NTRS1992

An EVACS simulation with nested transactions

Documented here is the recent effort of the MISSION Kernel Team on an Extra-Vehicular Activity Control System (EVACS) simulation with nested transactions. The team has implemented the EVACS simulation along with a design for nested transactions. The EVACS simulation is a project wide aid to exploring Mission and Safety Critical (MASC) applications and their support software. For this effort it served as a trial scenario for demonstrating nested transactions and exercising the transaction support design. The EVACS simulation is a simulation of some aspects of the Extra-Vehicular Activity Control System, in particular, just the selection of communication frequencies. Its current definition is quite narrow, serving only as a starting point for prototyping purposes. (EVACS itself may be supplanted in a larger scenario of a lunar outpost with astronauts and a lunar rover.) Initially the simulation of frequency selection was written without consideration of nested transactions. This scenario was then modified to embed its processing in nested transactions. To simplify the prototyping effort, only two aspects of the general design for transaction support have been implemented: the basic architecture and state recovery. The simulation has been implemented in the programming language Smalltalk. It consists of three components: (1) a simulation support code which provides the framework for initiating, interacting and tracing the system; (2) the EVACS application code itself, including its calls upon nested transaction support; and (3) a transaction support code which implements the logic necessary for nested transactions. Each of these components deserves further description, but for now only the transaction support is discussed.

Auty, David↗

NASA NTRS1988

Object Oriented Programming Systems (OOPS) and frame representations: An investigation of programming paradigms

The project was initiated to research Object Oriented Programming Systems (OOPS) and frame representation systems, their significance and applicability, and their implementation in or relationship to Ada. Object orientated is currently a very popular conceptual adjective. Object oriented programming, in particular, is promoted as a particularly productive approach to programming; an approach which maximizes opportunities for code reuse and lends itself to the definition of convenient and well-developed units. Such units are thus expected to be usable in a variety of situations, beyond the typical highly specific unit development of other approaches. Frame represenation systems share a common heritage and similar conceptual foundations. Together they represent a quickly emerging alternative approach to programming. The approach is to first define the terms, starting with relevant concepts and using these to put bounds on what is meant by OOPS and Frames. From this the possibilities were pursued to merge OOPS with Ada which will further elucidate the significant characteristics which make up this programming approach. Finally, some of the merits and demerits of OOPS were briefly considered as a way of addressing the applicability of OOPS to various programming tasks.

Auty, David↗

NASA NTRS1988

Ada programming guidelines for deterministic storage management

Previous reports have established that a program can be written in the Ada language such that the program's storage management requirements are determinable prior to its execution. Specific guidelines for ensuring such deterministic usage of Ada dynamic storage requirements are described. Because requirements may vary from one application to another, guidelines are presented in a most-restrictive to least-restrictive fashion to allow the reader to match appropriate restrictions to the particular application area under investigation.

Auty, David↗

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 NTRS1987

A study of System Interface Sets (SIS) for the host, target and integration environments of the Space Station Program (SSP)

System interface sets (SIS) for large, complex, non-stop, distributed systems are examined. The SIS of the Space Station Program (SSP) was selected as the focus of this study because an appropriate virtual interface specification of the SIS is believed to have the most potential to free the project from four life cycle tyrannies which are rooted in a dependance on either a proprietary or particular instance of: operating systems, data management systems, communications systems, and instruction set architectures. The static perspective of the common Ada programming support environment interface set (CAIS) and the portable common execution environment (PCEE) activities are discussed. Also, the dynamic perspective of the PCEE is addressed.

Mckay, Charles↗

NASA NTRS1986

The testability of Ada programs

Software development for NASA's Space Station poses a significant problem; considered the most difficult by some. The difficulty is the magnitude and complexity of the required software. The concerns raised by consideration of the requirements for testing and checkout procedures for the Space Station software are addressed. In particular, it addresses the use of Ada in the development of widely distributed yet closely coordinated processing.

Auty, David↗

NASA NTRS1986

A study of MAPSE extensions

The technical issues of extending the Minimal Ada Programming Support Environment (MAPSE) to support the life cycle of large, complex distributed systems such as the Space Station Program (SSP) are studied. The work has been divided into two phases, Phase one, covered herein, identifies a list of advanced technical tools needed to extend the MAPSE to meet the needs believed to be inherent in the Software Support Environment (SSE). The description of SSE requirements are given, and a list of the tools are identified. An outline is also given of the principle requirements for a MAPSE, along with a description of the life cycle model and a description of the tools in the context of the life cycle model.

Auty, David↗