Study of application of space telescope science operations software for SIRTF use

The design and development of the Space Telescope Science Operations Ground System (ST SOGS) was evaluated to compile a history of lessons learned that would benefit NASA's Space Infrared Telescope Facility (SIRTF). Forty-nine specific recommendations resulted and were categorized as follows: (1) requirements: a discussion of the content, timeliness and proper allocation of the system and segment requirements and the resulting impact on SOGS development; (2) science instruments: a consideration of the impact of the Science Instrument design and data streams on SOGS software; and (3) contract phasing: an analysis of the impact of beginning the various ST program segments at different times. Approximately half of the software design and source code might be useable for SIRTF. Transportability of this software requires, at minimum, a compatible DEC VAX-based architecture and VMS operating system, system support software similar to that developed for SOGS, and continued evolution of the SIRTF operations concept and requirements such that they remain compatible with ST SOGS operation

Tools for producing formal specifications : a view of current architectures and future directions

During the last decade, one important contribution towards requirements engineering has been the advent of formal specification languages. They offer a well-defined notation that can improve consistency and avoid ambiguity in specifications. However, the process of obtaining formal specifications that are consistent with the requirements is itself a difficult activity. Hence various researchers are developing systems that aid the transition from informal to formal specifications. The kind of problems tackled and the contributions made by these proposed systems are very diverse. This paper brings these studies together to provide a vision for future architectures that aim to aid the transition from informal to formal specifications. The new architecture, which is based on the strengths of existing studies, tackles a number of key issues in requirements engineering such as identifying ambiguities, incompleteness, and reusability. The paper concludes with a discussion of the research problems that need to be addressed in order to realise the proposed architecture

Flight deck automation: Promises and realities

Issues of flight deck automation are multifaceted and complex. The rapid introduction of advanced computer-based technology onto the flight deck of transport category aircraft has had considerable impact both on aircraft operations and on the flight crew. As part of NASA's responsibility to facilitate an active exchange of ideas and information among members of the aviation community, a NASA/FAA/Industry workshop devoted to flight deck automation, organized by the Aerospace Human Factors Research Division of NASA Ames Research Center. Participants were invited from industry and from government organizations responsible for design, certification, operation, and accident investigation of transport category, automated aircraft. The goal of the workshop was to clarify the implications of automation, both positive and negative. Workshop panels and working groups identified issues regarding the design, training, and procedural aspects of flight deck automation, as well as the crew's ability to interact and perform effectively with the new technology. The proceedings include the invited papers and the panel and working group reports, as well as the summary and conclusions of the conference

Man-machine interface analysis of the flight design system

The objective of the current effort was to perform a broad analysis of the human factors issues involved in the design of the Flight Design System (FDS). The analysis was intended to include characteristics of the system itself, such as: (1) basic structure and functional capabilities of FDS; (2) user backgrounds, capabilities, and possible modes of use; (3) FDS interactive dialogue, problem solving aids; (4) system data management capabilities; and to include, as well, such system related matters as: (1) flight design team structure; (2) roles of technicians; (3) user training; and (4) methods of evaluating system performance. Wherever possible, specific recommendations are made. In other cases, the issues which seem most important are identified. In some cases, additional analyses or experiments which might provide resolution are suggested

A requirements specification for a software design support system

Most existing software design systems (SDSS) support the use of only a single design methodology. A good SDSS should support a wide variety of design methods and languages including structured design, object-oriented design, and finite state machines. It might seem that a multiparadigm SDSS would be expensive in both time and money to construct. However, it is proposed that instead an extensible SDSS that directly implements only minimal database and graphical facilities be constructed. In particular, it should not directly implement tools to faciliate language definition and analysis. It is believed that such a system could be rapidly developed and put into limited production use, with the experience gained used to refine and evolve the systems over time

Production of Reliable Flight Crucial Software: Validation Methods Research for Fault Tolerant Avionics and Control Systems Sub-Working Group Meeting

The state of the art in the production of crucial software for flight control applications was addressed. The association between reliability metrics and software is considered. Thirteen software development projects are discussed. A short term need for research in the areas of tool development and software fault tolerance was indicated. For the long term, research in format verification or proof methods was recommended. Formal specification and software reliability modeling, were recommended as topics for both short and long term research

On the engineering of crucial software

The various aspects of the conventional software development cycle are examined. This cycle was the basis of the augmented approach contained in the original grant proposal. This cycle was found inadequate for crucial software development, and the justification for this opinion is presented. Several possible enhancements to the conventional software cycle are discussed. Software fault tolerance, a possible enhancement of major importance, is discussed separately. Formal verification using mathematical proof is considered. Automatic programming is a radical alternative to the conventional cycle and is discussed. Recommendations for a comprehensive approach are presented, and various experiments which could be conducted in AIRLAB are described