Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “System Operations”

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

EOS Operations Systems: EDOS Implemented Changes to Reduce Operations Costs

The authors describe in this paper the progress achieved to-date with the reengineering of the Earth Observing System (EOS) Data and Operations System (EDOS), the experience gained in the process and the ensuing reduction of ground systems operations costs. The reengineering effort included a major methodology change, applying to an existing schedule driven system, a data-driven system approach.

Cordier, Guy R.↗
DOE OSTI2023

Impact of Spatial Variation in Flexibility on System Operations in Electric Power Systems

With the expansion of renewable energy resources in the electric power systems, having flexibility in the setup will allow to maintain the system's reliability and prevailing operations. Such flexibility can be extracted from utility operated and/or consumer owned devices, such as, storage devices, electric vehicles, etc. For the demand side, generally consumer preferences, incentives, etc. enact on the availability of the flexibility; besides, both the spatial and temporal dimension dictates the degree of the flexibility. Consequently, the optimal dispatch of the grid resources might appear intractable as the considerable amount of flexibility are obliquely stemming from the ungovernable consumer devices. Thus characterizing the consequences of diverged feasible flexibility in the system is crucial for operations. In this paper, a procedure is developed to quantify the degree of flexibility of power systems in terms of resource dispatch reconfiguration. Specifically, we develop optimization problems to attain equivalent resource configurations for the power systems to evaluate the spatial volatility of the network and asses the flexibility of the system. The developed process is then validated using numerical simulations for IEEE-30 bus test system.

Sadnan, Rabayet↗
NASA NTRS1994

Using task analysis to understand the Data System Operations Team

The Data Systems Operations Team (DSOT) currently monitors the Multimission Ground Data System (MGDS) at JPL. The MGDS currently supports five spacecraft and within the next five years, it will support ten spacecraft simultaneously. The ground processing element of the MGDS consists of a distributed UNIX-based system of over 40 nodes and 100 processes. The MGDS system provides operators with little or no information about the system's end-to-end processing status or end-to-end configuration. The lack of system visibility has become a critical issue in the daily operation of the MGDS. A task analysis was conducted to determine what kinds of tools were needed to provide DSOT with useful status information and to prioritize the tool development. The analysis provided the formality and structure needed to get the right information exchange between development and operations. How even a small task analysis can improve developer-operator communications is described, and the challenges associated with conducting a task analysis in a real-time mission operations environment are examined.

Holder, Barbara E.↗
NASA NTRS1993

Using Task Analysis to Understand the Data System Operations Team

The Data System Operations Team (DSOT) currently monitors the Multimission Ground Data System (MGDS) at NASAճ Jet Propulsion Laboratory. The MGDS currently supports five spacecraft and within the next five years it will support ten spacecraft simultaneously. The ground processing element of the MGDS consists of a distributed UNIX-based system of over 40 nodes and 100 processes. The MGDS system provides operators with little or no information about the system's end-to-end processing status or end-to-end configuration. The lack of system visibility has become a critical issue in the daily operation of the MGDS. A task analysis was conducted to determine what kinds of tools were needed to provide DSOT with useful status information and to prioritize the tool development. The analysis provided the formality and structure needed to get the right information exchange between development and operations.

Holder, B. E.↗
NASA NTRS1986

Automatic braking system modification for the Advanced Transport Operating Systems (ATOPS) Transportation Systems Research Vehicle (TSRV)

Modifications were designed for the B-737-100 Research Aircraft autobrake system hardware of the Advanced Transport Operating Systems (ATOPS) Program at Langley Research Center. These modifications will allow the on-board flight control computer to control the aircraft deceleration after landing to a continuously variable level for the purpose of executing automatic high speed turn-offs from the runway. A bread board version of the proposed modifications was built and tested in simulated stopping conditions. Test results, for various aircraft weights, turnoff speed, winds, and runway conditions show that the turnoff speeds are achieved generally with errors less than 1 ft/sec.

Coogan, J. J.↗
NASA NTRS1993

Using Task Analysis to Understand the Data System Operations Team

The Data System Operations Team (DSOT) currently monitors and controls the Multimission Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory. The MGDS currently supports five spacecraft and within the next five years it will support ten spacecraft simultaneously. The ground processing element of the MGDS consists of a distributed UNIX-based system of over 40 nodes and 100 processes. The MGDS system provides operators with little or no information about the system's end-to-end processing status or end-to-end configuration. The lack of system visibility has become a critical issue in the daily operation of the MGDS. A task analysis was conducted to determine what kinds of tools were needed to provide DSOT with useful status information and to prioritize the tool development...

Holder, Barbara E.↗
NASA NTRS1985

Network operating system focus technology

An activity structured to provide specific design requirements and specifications for the Space Station Data Management System (DMS) Network Operating System (NOS) is outlined. Examples are given of the types of supporting studies and implementation tasks presently underway to realize a DMS test bed capability to develop hands-on understanding of NOS requirements as driven by actual subsystem test beds participating in the overall Johnson Space Center test bed program. Classical operating system elements and principal NOS functions are listed.

Source record↗
NASA NTRS1992

Time warp operating system version 2.7 internals manual

The Time Warp Operating System (TWOS) is an implementation of the Time Warp synchronization method proposed by David Jefferson. In addition, it serves as an actual platform for running discrete event simulations. The code comprising TWOS can be divided into several different sections. TWOS typically relies on an existing operating system to furnish some very basic services. This existing operating system is referred to as the Base OS. The existing operating system varies depending on the hardware TWOS is running on. It is Unix on the Sun workstations, Chrysalis or Mach on the Butterfly, and Mercury on the Mark 3 Hypercube. The base OS could be an entirely new operating system, written to meet the special needs of TWOS, but, to this point, existing systems have been used instead. The base OS's used for TWOS on various platforms are not discussed in detail in this manual, as they are well covered in their own manuals. Appendix G discusses the interface between one such OS, Mach, and TWOS.

Source record↗
NASA NTRS1987

EOS: A project to investigate the design and construction of real-time distributed Embedded Operating Systems

Project EOS is studying the problems of building adaptable real-time embedded operating systems for the scientific missions of NASA. Choices (A Class Hierarchical Open Interface for Custom Embedded Systems) is an operating system designed and built by Project EOS to address the following specific issues: the software architecture for adaptable embedded parallel operating systems, the achievement of high-performance and real-time operation, the simplification of interprocess communications, the isolation of operating system mechanisms from one another, and the separation of mechanisms from policy decisions. Choices is written in C++ and runs on a ten processor Encore Multimax. The system is intended for use in constructing specialized computer applications and research on advanced operating system features including fault tolerance and parallelism.

Campbell, R. H.↗
DOE OSTI2023

Computing system operational methods and apparatus

Computing system operational methods and apparatus are described. According to one aspect, a computing system operational method includes accessing user information regarding a user logging onto a computing device of the computing system, processing the user information to determine if the user information is authentic, as a result of the processing determining that the user information is authentic, first enabling the computing device to execute an application segment, and as a result of the processing determining that the user information is authentic, second enabling the application segment to communicate data externally of the computing device via one of a plurality of network segments of the computing system.

Edgar, Thomas W.↗
NASA NTRS1985

Measurement of SIFT operating system overhead

The overhead of the software implemented fault tolerance (SIFT) operating system was measured. Several versions of the operating system evolved. Each version represents different strategies employed to improve the measured performance. Three of these versions are analyzed. The internal data structures of the operating systems are discussed. The overhead of the SIFT operating system was found to be of two types: vote overhead and executive task overhead. Both types of overhead were found to be significant in all versions of the system. Improvements substantially reduced this overhead; even with these improvements, the operating system consumed well over 50% of the available processing time.

Palumbo, D. L.↗
NASA NTRS1983

Time-critical multirate scheduling using contemporary real-time operating system services

Although real-time operating systems provide many of the task control services necessary to process time-critical applications (i.e., applications with fixed, invariant deadlines), it may still be necessary to provide a scheduling algorithm at a level above the operating system in order to coordinate a set of synchronized, time-critical tasks executing at different cyclic rates. The scheduling requirements for such applications and develops scheduling algorithms using services provided by contemporary real-time operating systems.

Eckhardt, D. E., Jr.↗
NASA NTRS1985

The embedded operating system project

The design and construction of embedded operating systems for real-time advanced aerospace applications was investigated. The applications require reliable operating system support that must accommodate computer networks. Problems that arise in the construction of such operating systems, reconfiguration, consistency and recovery in a distributed system, and the issues of real-time processing are reported. A thesis that provides theoretical foundations for the use of atomic actions to support fault tolerance and data consistency in real-time object-based system is included. The following items are addressed: (1) atomic actions and fault-tolerance issues; (2) operating system structure; (3) program development; (4) a reliable compiler for path Pascal; and (5) mediators, a mechanism for scheduling distributed system processes.

Campbell, R. H.↗
DOE OSTI2022

Generator Interconnection Cost Analysis in the Midcontinent Independent System Operator (MISO) territory

Electric transmission system operators (ISOs, RTOs, or utilities) require new large generators seeking to connect to the grid to undergo a series of impact studies before they can be built. This process establishes what new transmission equipment or upgrades may be needed before a project can connect to the system and assigns the costs of that equipment. Berkeley Lab has collected interconnection cost data from interconnection studies for the Midcontinent Independent System Operator (MISO), representing nearly 50% of all projects requesting interconnection from 2010 to 2020. Project-level cost summary data are available for download on this page. We find: -Average interconnection costs have grown as the number of interconnection requests have escalated -Projects that have completed all required interconnection studies have the lowest cost compared to applicants still actively working through the interconnection process or those that have withdrawn. -Broader network upgrade costs are the primary driver of recent cost increase. -Potential interconnection costs for wind, storage, and solar are larger than for natural gas -Larger generators have greater interconnection costs in absolute terms, but economies of scale exist on a per kW basis. -Interconnection costs vary by location Berkeley Lab will publish a series of short analytical papers of generator interconnection costs to the transmission system for MISO, PJM, SPP, ISO-NE and NYISO, which you can find at https://emp.lbl.gov/interconnection_costs.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗