Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Operating systems”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

NASDA satellite mission operation system and operations

NASDA has recently developed a new tracking and control system as a basis for future satellite mission operation. It is named type-I Space Operations and Data Systems (type-I SODS). The software of this system is separated into three parts: operation and control system, network system, and support and information system. The operation control system treats telemetry and command operations. The network system controls the communication line and ground station equipments to connect the satellite and the operation control system. The support and information system provides to other systems necessary information. JERS-1 which was launched in February of this year is the first satellite operated by type-l SODS. We explain the architecture and operation methods of this system using JERS-1 mission operations.

Yamaya, Kousaku↗
NASA NTRS1985

A new taxonomy for distributed computer systems based upon operating system structure

Characteristics of the resource structure found in the operating system are considered as a mechanism for classifying distributed computer systems. Since the operating system resources, themselves, are too diversified to provide a consistent classification, the structure upon which resources are built and shared are examined. The location and control character of this indivisibility provides the taxonomy for separating uniprocessors, computer networks, network computers (fully distributed processing systems or decentralized computers) and algorithm and/or data control multiprocessors. The taxonomy is important because it divides machines into a classification that is relevant or important to the client and not the hardware architect. It also defines the character of the kernel O/S structure needed for future computer systems. What constitutes an operating system for a fully distributed processor is discussed in detail.

Foudriat, E. C.↗
NASA NTRS1988

Alpha: A real-time decentralized operating system for mission-oriented system integration and operation

Alpha is a new kind of operating system that is unique in two highly significant ways. First, it is decentralized transparently providing reliable resource management across physically dispersed nodes, so that distributed applications programming can be done largely as though it were centralized. And second, it provides comprehensive, high technology support for real-time system integration and operation, an application area which consists predominately of aperiodic activities having critical time constraints such as deadlines. Alpha is extremely adaptable so that it can be easily optimized for a wide range of problem-specific functionality, performance, and cost. Alpha is the first systems effort of the Archons Project, and the prototype was created at Carnegie-Mellon University directly on modified Sun multiprocessor workstation hardware. It has been demonstrated with a real-time C(sup 2) application. Continuing research is leading to a series of enhanced follow-ons to Alpha; these are portable but initially hosted on Concurrent's MASSCOMP line of multiprocessor products.

Jensen, E. Douglas↗
NASA NTRS1985

Effect of system workload on operating system reliability - A study on IBM 3081

This paper presents an analysis of operating system failures on an IBM 3081 running VM/SP. Three broad categories of software failures are found: error handling, program control or logic, and hardware related; it is found that more than 25 percent of software failures occur in the hardware/software interface. Measurements show that results on software reliability cannot be considered representative unless the system workload is taken into account. The overall CPU execution rate, although measured to be close to 100 percent most of the time, is not found to correlate strongly with the occurrence of failures. Possible reasons for the observed workload failure dependency, based on detailed investigations of the failure data, are discussed.

Iyer, R. K.↗
NASA NTRS1985

Analysis of remote operating systems for space-based servicing operations, volume 1

A two phase study was conducted to analyze and develop the requirements for remote operating systems as applied to space based operations for the servicing, maintenance, and repair of satellites. Phase one consisted of the development of servicing requirements to establish design criteria for remote operating systems. Phase two defined preferred system concepts and development plans which met the requirements established in phase one. The specific tasks in phase two were to: (1) identify desirable operational and conceptual approaches for selected mission scenarios; (2) examine the potential impact of remote operating systems incorporated into the design of the space station; (3) address remote operating systems design issues, such as mobility, which are effected by the space station configuration; and (4) define the programmatic approaches for technology development, testing, simulation, and flight demonstration.

Source record↗
NASA NTRS1993

Electronic Performance Support for Operational Systems: A Case Study of the Link Monitor and Control Operator Assistant

For complex operational systems, help needs to come from the inside out. It is often not realistic to call a help desk for problems that need immediate attention, especially for tasks that put a heavy cognitive load on the system operator. This session addresses the issues associated with providing electronic performance support for operational systems, including situations where the system is already fielded and can only change through evolution rather than revolution. We present a case study based on our experiences in developing the Link Monitor and Control Operator Assistant for NASA's Deep Space Network (DSN). The goals of the Operator Assistant are to improve the operability of the system and increase the efficiency of mission operations.

Hill, Randall W., Jr.↗
NASA NTRS1996

UNIX-based operating systems robustness evaluation

Robust operating systems are required for reliable computing. Techniques for robustness evaluation of operating systems not only enhance the understanding of the reliability of computer systems, but also provide valuable feed- back to system designers. This thesis presents results from robustness evaluation experiments on five UNIX-based operating systems, which include Digital Equipment's OSF/l, Hewlett Packard's HP-UX, Sun Microsystems' Solaris and SunOS, and Silicon Graphics' IRIX. Three sets of experiments were performed. The methodology for evaluation tested (1) the exception handling mechanism, (2) system resource management, and (3) system capacity under high workload stress. An exception generator was used to evaluate the exception handling mechanism of the operating systems. Results included exit status of the exception generator and the system state. Resource management techniques used by individual operating systems were tested using programs designed to usurp system resources such as physical memory and process slots. Finally, the workload stress testing evaluated the effect of the workload on system performance by running a synthetic workload and recording the response time of local and remote user requests. Moderate to severe performance degradations were observed on the systems under stress.

Chang, Yu-Ming↗
NASA NTRS2016

A Structured, Model-Based Systems Engineering Methodology for Operations System Design

Two widely accepted techniques for lowering the cost and risk of developing systems are (1) the use of a defined systems engineering (SE) process or methodology and (2) the reuse of existing (previously built) system components. The first technique is represented, for example, in materials published by NASA (e.g., NASA Systems Engineering Handbook) or by professional societies such as INCOSE (International Council on Systems Engineering). Well-formed SE techniques provide value by establishing the proper scope of the system (e.g., requirements), and by identifying and resolving problems relatively early in project lifecycles, when fixes are less expensive. The second technique (reuse) is applied most commonly to hardware and software; it seeks to avoid replicating design and implementation costs while also reducing risk by placing proven capabilities into operational use. In this paper, we outline a methodology combining these two techniques and extending reuse beyond hardware and software to foundational aspects of a Mission Operation System’s (MOS) design. We describe the system design artifacts that result (e.g., requirements, design documentation), as well as the reusable patterns and elements of the design, and their interrelationships. This approach is enabled by model-based systems engineering (MBSE) techniques and tools and is currently available in SysML form as a plug-in to MagicDraw. Additionally, usage of a rigorous MBSE approach allows for training materials and tutorials to be packaged within the overall model itself. The results of such an approach include decreased cost and risk during the design phase, improved ability of the MOS development team to investigate trade spaces and identify impacts to important flight-ground trade studies. Such results extend into decreased costs and risk in later phases due to improved design, decreased need for late fixes or development of "glue-ware" or scripts to fill unanticipated gaps in functionality, and improved ability to identify and plan testing and other validation activities. Finally, lower operational costs can be expected, both due to improved quality of the MOS, increased ease of maintaining updated knowledge of system configuration, and the fact that training and procedural materials are also updated at the same time as accepted system changes.

Bindschadler, Duane L.↗
NASA NTRS2010

MOS 2.0: The Next Generation in Mission Operations Systems

A Mission Operations System (MOS) or Ground System constitutes that portion of an overall space mission Enterprise that resides here on Earth. Over the past two decades, technological innovations in computing and software technologies have allowed an MOS to support ever more complex missions while consuming a decreasing fraction of Project development budgets. Despite (or perhaps, because of) such successes, it is routine to hear concerns about the cost of MOS development. At the same time, demand continues for Ground Systems which will plan more spacecraft activities with fewer commanding errors, provide scientists and engineers with more autonomous functionality, process and manage larger and more complex data more quickly, all while requiring fewer people to develop, deploy, operate and maintain them. One successful approach to such concerns over this period is a multimission approach, based on the reuse of portions (most often software) developed and used in previous missions. The Advanced Multi-Mission Operations System (AMMOS), developed for deep-space science missions, is one successful example of such an approach. Like many computing-intensive systems, it has grown up in a near-organic fashion from a relatively simple set of tools into a complexly interrelated set of capabilities. Such systems, like a city lacking any concept of urban planning, can and will grow in ways that are neither efficient nor particularly easy to sustain. To meet the growing demands and unyielding constraints placed on ground systems, a new approach is necessary. Under the aegis of a multi-year effort to revitalize the AMMOS's multimission operations capabilities, we are utilizing modern practices in systems architecting and model-based engineering to create the next step in Ground Systems: MOS 2.0. In this paper we outline our work (ongoing and planned) to architect and design a multimission MOS 2.0, describe our goals and measureable objectives, and discuss some of the benefits that this top-down, architectural approach holds for creating a more flexible and capable MOS for Missions while holding the line on cost.

ground systems↗
NASA NTRS1985

Analysis of remote operating systems for space-based servicing operations. Volume 2: Study results

The developments in automation and robotics have increased the importance of applications for space based servicing using remotely operated systems. A study on three basic remote operating systems (teleoperation, telepresence and robotics) was performed in two phases. In phase one, requirements development, which consisted of one three-month task, a group of ten missions were selected. These included the servicing of user equipment on the station and the servicing of the station itself. In phase two, concepts development, which consisted of three tasks, overall system concepts were developed for the selected missions. These concepts, which include worksite servicing equipment, a carrier system, and payload handling equipment, were evaluated relative to the configurations of the overall worksite. It is found that the robotic/teleoperator concepts are appropriate for relatively simple structured tasks, while the telepresence/teleoperator concepts are applicable for missions that are complex, unstructured tasks.

Source record↗
NASA NTRS1999

SIRTF Science Operations System Design

SIRTF Science Operations System Design William B. Green Manager, SIRTF Science Center California Institute of Technology M/S 310-6 1200 E. California Blvd., Pasadena CA 91125 (626) 395 8572 Fax (626) 568 0673 bgreen@ipac.caltech.edu. The Space Infrared Telescope Facility (SIRTF) will be launched in December 2001, and perform an extended series of science observations at wavelengths ranging from 20 to 160 microns for five years or more. The California Institute of Technology has been selected as the home for the SIRTF Science Center (SSC). The SSC will be responsible for evaluating and selecting observation proposals, providing technical support to the science community, performing mission planning and science observation scheduling activities, instrument calibration during operations and instrument health monitoring, production of archival quality data products, and management of science research grants. The science payload consists of three instruments delivered by instrument Principal Investigators located at University of Arizona, Cornell, and Harvard Smithsonian Astrophysical Observatory. The SSC is responsible for design, development, and operation of the Science Operations System (SOS) which will support the functions assigned to the SSC by NASA. The SIRTF spacecraft, mission profile, and science instrument design have undergone almost ten years of refinement. SIRTF development and operations activities are highly cost constrained. The cost constraints have impacted the design of the SOS in several ways. The Science Operations System has been designed to incorporate a set of efficient, easy to use tools which will make it possible for scientists to propose observation sequences in a rapid and automated manner. The use of highly automated tools for requesting observations will simplify the long range observatory scheduling process, and the short term scheduling of science observations. Pipeline data processing will be highly automated and data-driven, utilizing a variety of tools developed at JPL, the instrument development teams, and Space Telescope Science Institute to automate processing. An incremental ground data system development approach has been adopted, featuring periodic deliveries that are validated with the flight hardware throughout the various phases of system level development and testing. This approach minimizes development time and decreases operations risk. This paper will describe the top level architecture of the SOS and the basic design concepts. A summary of the incremental development approach will be presented. Examples of the unique science user tools now under final development prior to the first proposal call scheduled for mid-2000 will be shown.

Green, William↗
NASA NTRS1988

Spacelab data processing facility (SLDPF) Quality Assurance (QA)/Data Accounting (DA) expert systems: Transition from prototypes to operational systems

The SLDPF is responsible for the capture, quality monitoring processing, accounting, and shipment of Spacelab and/or Attached Shuttle Payloads (ASP) telemetry data to various user facilities. Expert systems will aid in the performance of the quality assurance and data accounting functions of the two SLDPF functional elements: the Spacelab Input Processing System (SIPS) and the Spacelab Output Processing System (SOPS). Prototypes were developed for each as independent efforts. The SIPS Knowledge System Prototype (KSP) used the commercial shell OPS5+ on an IBM PC/AT; the SOPS Expert System Prototype used the expert system shell CLIPS implemented on a Macintosh personal computer. Both prototypes emulate the duties of the respective QA/DA analysts based upon analyst input and predetermined mission criteria parameters, and recommended instructions and decisions governing the reprocessing, release, or holding for further analysis of data. These prototypes demonstrated feasibility and high potential for operational systems. Increase in productivity, decrease of tedium, consistency, concise historial records, and a training tool for new analyses were the principal advantages. An operational configuration, taking advantage of the SLDPF network capabilities, is under development with the expert systems being installed on SUN workstations. This new configuration in conjunction with the potential of the expert systems will enhance the efficiency, in both time and quality, of the SLDPF's release of Spacelab/AST data products.

Basile, Lisa↗
NASA NTRS1988

Spacelab data processing facility (SLDPF) quality assurance (QA)/data accounting (DA) expert systems - Transition from prototypes to operational systems

The SLDPF is responsible for the capture, quality monitoring processing, accounting, and shipment of Spacelab and/or Attached Shuttle Payloads (ASP) telemetry data to various user facilities. Expert systems will aid in the performance of the quality assurance and data accounting functions of the two SLDPF functional elements: the Spacelab Input Processing System (SIPS) and the Spacelab Output Processing System (SOPS). Prototypes were developed for each as independent efforts. The SIPS Knowledge System Prototype (KSP) used the commercial shell OPS5+ on an IBM PC/AT; the SOPS Expert System Prototype used the expert system shell CLIPS implemented on a Macintosh personal computer. Both prototypes emulate the duties of the respective QA/DA analysts based upon analyst input and predetermined mission criteria parameters, and recommended instructions and decisions governing the reprocessing, release, or holding for further analysis of data. These prototypes demonstrated feasibility and high potential for operational systems. Increase in productivity, decrease of tedium, consistency, concise historical records, and a training tool for new analyses were the principal advantages. An operational configuration, taking advantage of the SLDPF network capabilities, is under development with the expert systems being installed on SUN workstations. This new configuration in conjunction with the potential of the expert systems will enhance the efficiency, in both time and quality, of the SLDPF's release of Spacelab/AST data products.

Basile, Lisa↗
NASA NTRS1988

A Multiprocessor Operating System Simulator

This paper describes a multiprocessor operating system simulator that was developed by the authors in the Fall semester of 1987. The simulator was built in response to the need to provide students with an environment in which to build and test operating system concepts as part of the coursework of a third-year undergraduate operating systems course. Written in C++, the simulator uses the co-routine style task package that is distributed with the AT&T C++ Translator to provide a hierarchy of classes that represents a broad range of operating system software and hardware components. The class hierarchy closely follows that of the 'Choices' family of operating systems for loosely- and tightly-coupled multiprocessors. During an operating system course, these classes are refined and specialized by students in homework assignments to facilitate experimentation with different aspects of operating system design and policy decisions. The current implementation runs on the IBM RT PC under 4.3bsd UNIX.

Johnston, Gary M.↗
NASA NTRS1984

Operating systems

A counter operating system creates a hierarchy of levels of abstraction, so that at a given level all details concerning lower levels can be ignored. This hierarchical structure separates functions according to their complexity, characteristic time scale, and level of abstraction. The lowest levels include the system's hardware; concepts associated explicitly with the coordination of multiple tasks appear at intermediate levels, which conduct 'primitive processes'. Software semaphore is the mechanism controlling primitive processes that must be synchronized. At higher levels lie, in rising order, the access to the secondary storage devices of a particular machine, a 'virtual memory' scheme for managing the main and secondary memories, communication between processes by way of a mechanism called a 'pipe', access to external input and output devices, and a hierarchy of directories cataloguing the hardware and software objects to which access must be controlled.

Denning, P. J.↗