Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software management 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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Practical Application of PRA as an Integrated Design Tool for Space Systems

This paper presents the application of the first comprehensive Probabilistic Risk Assessment (PRA) during the design phase of a joint NASA/NOAA weather satellite program, Geostationary Operational Environmental Satellite Series R (GOES-R). GOES-R is the next generation weather satellite primarily to help understand the weather and help save human lives. PRA has been used at NASA for Human Space Flight for many years. PRA was initially adopted and implemented in the operational phase of manned space flight programs and more recently for the next generation human space systems. Since its first use at NASA, PRA has become recognized throughout the Agency as a method of assessing complex mission risks as part of an overall approach to assuring safety and mission success throughout project lifecycles. PRA is now included as a requirement during the design phase of both NASA next generation manned space vehicles as well as for high priority robotic missions. The influence of PRA on GOES-R design and operation concepts are discussed in detail. The GOES-R PRA is unique at NASA for its early implementation. It also represents a pioneering effort to integrate risks from both Spacecraft (SC) and Ground Segment (GS) to fully assess the probability of achieving mission objectives. PRA analysts were actively involved in system engineering and design engineering to ensure that a comprehensive set of technical risks were correctly identified and properly understood from a design and operations perspective. The analysis included an assessment of SC hardware and software, SC fault management system, GS hardware and software, common cause failures, human error, natural hazards, solar weather and infrastructure (such as network and telecommunications failures, fire). PRA findings directly resulted in design changes to reduce SC risk from micro-meteoroids. PRA results also led to design changes in several SC subsystems, e.g. propulsion, guidance, navigation and control (GNC), communications, mechanisms, and command and data handling (C&DH). The fault tree approach assisted in the development of the fault management system design. Human error analysis, which examined human response to failure, indicated areas where automation could reduce the overall probability of gaps in operation by half. In addition, the PRA brought to light many potential root causes of system disruptions, including earthquakes, inclement weather, solar storms, blackouts and other extreme conditions not considered in the typical reliability and availability analyses. Ultimately the PRA served to identify potential failures that, when mitigated, resulted in a more robust design, as well as to influence the program's concept of operations. The early and active integration of PRA with system and design engineering provided a well-managed approach for risk assessment that increased reliability and availability, optimized lifecyc1e costs, and unified the SC and GS developments.

Kalia, Prince↗
NASA NTRS1984

Power subsystem automation study

The purpose of the phase 2 of the power subsystem automation study was to demonstrate the feasibility of using computer software to manage an aspect of the electrical power subsystem on a space station. The state of the art in expert systems software was investigated in this study. This effort resulted in the demonstration of prototype expert system software for managing one aspect of a simulated space station power subsystem.

Tietz, J. C.↗
NASA NTRS1985

Development of an expert system prototype for determining software functional requirements for command management activities at NASA Goddard

The development of an expert system prototype for determining software functional requirements for NASA Goddard's Command Management System (CMS) is described. The role of the CMS is to transform general requests into specific spacecraft commands with command execution conditions. The CMS is part of the NASA Data System which entails the downlink of science and engineering data from NASA near-earth satellites to the user, and the uplink of command and control data to the spacecraft. Subjects covered include: the problem environment of determining CMS software functional requirements; the expert system approach for handling CMS requirements development; validation and evaluation procedures for the expert system.

Liebowitz, J.↗
NASA NTRS1986

Development of an expert system prototype for determining software functional requirements for command management activities at NASA Goddard

The development of an expert system prototype for software functional requirement determination for NASA Goddard's Command Management System, as part of its process of transforming general requests into specific near-earth satellite commands, is described. The present knowledge base was formulated through interactions with domain experts, and was then linked to the existing Knowledge Engineering Systems (KES) expert system application generator. Steps in the knowledge-base development include problem-oriented attribute hierarchy development, knowledge management approach determination, and knowledge base encoding. The KES Parser and Inspector, in addition to backcasting and analogical mapping, were used to validate the expert system-derived requirements for one of the major functions of a spacecraft, the solar Maximum Mission. Knowledge refinement, evaluation, and implementation procedures of the expert system were then accomplished.

Liebowitz, J.↗
NASA NTRS1989

A class Hierarchical, object-oriented approach to virtual memory management

The Choices family of operating systems exploits class hierarchies and object-oriented programming to facilitate the construction of customized operating systems for shared memory and networked multiprocessors. The software is being used in the Tapestry laboratory to study the performance of algorithms, mechanisms, and policies for parallel systems. Described here are the architectural design and class hierarchy of the Choices virtual memory management system. The software and hardware mechanisms and policies of a virtual memory system implement a memory hierarchy that exploits the trade-off between response times and storage capacities. In Choices, the notion of a memory hierarchy is captured by abstract classes. Concrete subclasses of those abstractions implement a virtual address space, segmentation, paging, physical memory management, secondary storage, and remote (that is, networked) storage. Captured in the notion of a memory hierarchy are classes that represent memory objects. These classes provide a storage mechanism that contains encapsulated data and have methods to read or write the memory object. Each of these classes provides specializations to represent the memory hierarchy.

Russo, Vincent F.↗
NASA NTRS2013

SMC Message Browser Projects

I work directly with the System Monitoring and Control (SMC) software engineers who develop, test and release custom and commercial software in support of the Kennedy Space Center Spaceport Command and Control System. (SCCS). SMC uses Commercial Off-The-Shelf (COTS) Enterprise Management Systems (EMS) software which provides a centralized subsystem for configuring, monitoring, and controlling SCCS hardware and software used in the Control Rooms. There are multiple projects being worked on using the COTS EMS software. I am currently working with the HP Operations Manager for UNIX (OMU) software which allows Master Console Operators (MCO) to access, view and interpret messages regarding the status of the SCCS hardware and software. The OMU message browser gets cluttered with messages which can make it difficult for the MCO to manage. My main project involves determining ways to reduce the number of messages being displayed in the OMU message browser. I plan to accomplish this task in two different ways: (1) by correlating multiple messages into one single message being displayed and (2) to create policies that will determine the significance of each message and whether or not it needs to be displayed to the MCO. The core idea is to lessen the number of messages being sent to the OMU message browser so the MCO can more effectively use it.

OMU↗
NASA NTRS1984

Data management

The following tasks were prioritized: software acquisition management plan; space station flight data system architectural study; space station user data system interface; automation of software development process; automation of software testing; distributed data base management; ADA (automated data acquisition) evaluation and transition and planning; network operating system software; fault tolerant computer validation methodology for onboard data management system; systems integration; artificial intelligence/expert systems; space station data network concept; space station standard interface protocols; space station data networks systems; integrated software development facility; and language trade studies.

Love, G.↗
NASA NTRS1986

Some design constraints required for the use of generic software in embedded systems: Packages which manage abstract dynamic structures without the need for garbage collection

The embedded systems running real-time applications, for which Ada was designed, require their own mechanisms for the management of dynamically allocated storage. There is a need for packages which manage their own internalo structures to control their deallocation as well, due to the performance implications of garbage collection by the KAPSE. This places a requirement upon the design of generic packages which manage generically structured private types built-up from application-defined input types. These kinds of generic packages should figure greatly in the development of lower-level software such as operating systems, schedulers, controllers, and device driver; and will manage structures such as queues, stacks, link-lists, files, and binary multary (hierarchical) trees. Controlled to prevent inadvertent de-designation of dynamic elements, which is implicit in the assignment operation A study was made of the use of limited private type, in solving the problems of controlling the accumulation of anonymous, detached objects in running systems. The use of deallocator prodecures for run-down of application-defined input types during deallocation operations during satellites.

Johnson, Charles S.↗
DOE OSTI2023

A step towards the final frontier: Lessons learned from acceptance testing of the first HPE/Cray EX 3000 system at ORNL

Summary In this article, we summarize the deployment of the Air Force Weather (AFW) HPC11 system at Oak Ridge National Laboratory (ORNL) including the process followed to successfully complete acceptance testing of the system. HPC11 is the first HPE/Cray EX 3000 system that has been successfully released to its user community in a federal facility. HPC11 consists of two identical 800‐node supercomputers, Fawbush and Miller, with access to two independent and identical lustre parallel file systems. HPC11 is equipped with Slingshot 10 interconnect technology and relies on the HPE Performance Cluster Manager software for system configuration. ORNL has a clearly defined acceptance testing process used to ensure that every new system deployed can provide the necessary capabilities to support user workloads. We worked closely with HPE and AFW to develop a set of tests that used the United Kingdom's Meteorological Office's Unified Model and 4‐dimensional variational data assimilation. We also included benchmarks and applications from the Oak Ridge Leadership Computing Facility portfolio to fully exercise the HPE/Cray programming environment and evaluate the functionality and performance of the system. Acceptance testing of HPC11 required parallel execution of each element on Fawbush and Miller. In addition, careful coordination was needed to ensure successful acceptance of the newly deployed lustre file systems alongside the compute resources. In this work, we present test results from specific system components and provide an overview of the issues identified, challenges encountered, and the lessons learned along the way.

Melesse Vergara, Verónica G.↗
NASA NTRS1976

The 727 approach energy management system avionics specification (preliminary)

Hardware and software requirements for an Approach Energy Management System (AEMS) consisting of an airborne digital computer and cockpit displays are presented. The displays provide the pilot with a visual indication of when to manually operate the gear, flaps, and throttles during a delayed flap approach so as to reduce approach time, fuel consumption, and community noise. The AEMS is an independent system that does not interact with other navigation or control systems, and is compatible with manually flown or autopilot coupled approaches. Operational use of the AEMS requires a DME ground station colocated with the flight path reference.

Jackson, D. O.↗
DOE OSTI2017

An Open Source Extensible Smart Energy Framework

Aggregated distributed energy resources are the subject of much interest in the energy industry and are expected to play an important role in meeting our future energy needs by changing how we use, distribute and generate electricity. This energy future includes an increased amount of energy from renewable resources, load management techniques to improve resiliency and reliability, and distributed energy storage and generation capabilities that can be managed to meet the needs of the grid as well as individual customers. These energy assets are commonly referred to as Distributed Energy Resources (DER). DERs rely on a means to communicate information between an energy provider and multitudes of devices. Today DER control systems are typically vendor-specific, using custom hardware and software solutions. As a result, customers are locked into communication transport protocols, applications, tools, and data formats. Today’s systems are often difficult to extend to meet new application requirements, resulting in stranded assets when business requirements or energy management models evolve. By partnering with industry advisors and researchers, an implementation DER research platform was developed called the Smart Energy Framework (SEF). The hypothesis of this research was that an open source Internet of Things (IoT) framework could play a role in creating a commodity-based eco-system for DER assets that would reduce costs and provide interoperable products. SEF is based on the AllJoynTM IoT open source framework. The demonstration system incorporated DER assets, specifically batteries and smart water heaters. To verify the behavior of the distributed system, models of water heaters and batteries were also developed. An IoT interface for communicating between the assets and a control server was defined. This interface supports a series of “events” and telemetry reporting, similar to those defined by current smart grid communication standards. The results of this effort demonstrated the feasibility and application potential of using IoT frameworks for the creation of commodity-based DER systems. All of the identified commodity-based system requirements were met by the AllJoyn framework. By having commodity solutions, small vendors can enter the market and the cost of implementation for all parties is reduced. Utilities and aggregators can choose from multiple interoperable products reducing the risk of stranded assets. Based on this research it is recommended that interfaces based on existing smart grid communication protocol standards be created for these emerging IoT frameworks. These interfaces should be standardized as part of the IoT framework allowing for interoperability testing and certification. Similarly, IoT frameworks are introducing application level security. This type of security is needed for protecting application and platforms and will be important moving forward. Recommendations are that along with DER-based data model interfaces, platform and application security requirements also be prescribed when IoT devices support DER applications.

25 ENERGY STORAGE↗
NASA NTRS1992

Ground Systems Development Environment (GSDE) software configuration management

This report presents a review of the software configuration management (CM) plans developed for the Space Station Training Facility (SSTF) and the Space Station Control Center. The scope of the CM assessed in this report is the Systems Integration and Testing Phase of the Ground Systems development life cycle. This is the period following coding and unit test and preceding delivery to operational use. This report is one of a series from a study of the interfaces among the Ground Systems Development Environment (GSDE), the development systems for the SSTF and the SSCC, and the target systems for SSCC and SSTF. This is the last report in the series. The focus of this report is on the CM plans developed by the contractors for the Mission Systems Contract (MSC) and the Training Systems Contract (TSC). CM requirements are summarized and described in terms of operational software development. The software workflows proposed in the TSC and MSC plans are reviewed in this context, and evaluated against the CM requirements defined in earlier study reports. Recommendations are made to improve the effectiveness of CM while minimizing its impact on the developers.

Church, Victor E.↗
DOE OSTI2013

BioWatch SMS Supervisor Guide

The BioWatch Sample Management System is software developed by Los Alamos National Laboratory to support the Department of Homeland Security BioWatch program. Field Operations Supervisors use the software to record, track, and manage data for the BioWatch sample collection process. This includes installing the software, creating and updating databases, assigning user IDs and passwords, editing and customizing reports, correcting data errors, recovering lost data, and troubleshooting. The BioWatch SMS Field Operations Supervisor Guide provides procedures for each task a Field Operations Supervisor performs. The reference information in this guide includes appendices of error messages and solutions, terms used interchangeably, and safety warnings along with a glossary, an index, and a list of suggested reference documents.

99 GENERAL AND MISCELLANEOUS↗
DOE OSTI2020

Production Operations Management System (POMS) for Fermilab Experiments

The Production Operations Management System (POMS) software allows production teams and analysis groups across multiple Fermilab experiments to launch, modify and monitor large scale campaigns of related Monte Carlo or data processing jobs, and currently manages the majority of production computing of experiments at Fermilab.POMS provides a web service interface that enables automated job submission on distributed resources according to customers’ requests, as well as subsequent monitoring of those submissions as well as recovery of failed submissions, debugging and record keeping.POMS interfaces with existing HEP data access, processing, movement and monitoring tools at Fermilab, including Jobsub (for job submission), SAM (for data management), and Landscape (for monitoring), and in combination with them handles the creation of intermediate datasets of files for multistage campaigns.POMS visualizes these campaigns with an interactive GUI interface. An important feature of POMS is a one-to-one connection between the GUI campaign visualizer and a text based representation of the complete campaign configuration. An extensible library of template campaign configurations is available. The templates are user modifiable and map cleanly to and from the GUI description of the campaign.This paper will discuss the current usage, history, and some technical details of POMS, as well as planned future extensions, particularly interfacing with Rucio as well as SAM for file movement.

Mengel, Marc↗
DOE OSTI2018

FY 2018 ARM Radar Plan

The fundamental objective of the U.S. Department of Energy (DOE) Atmospheric Radiation Measurement (ARM) Climate Research Facility radar facility is to provide high-quality radar observations to the scientific user community with an overarching goal of improving the treatment of clouds and precipitation in climate models. Historically, ARM has operated zenith-profiling cloud radars at millimeter wavelengths at five of its facilities. Since 2010, 16 scanning systems have been added to the radar facility. The ARM radar facility has 33 radars in its possession at three fixed sites and three mobile facilities. A breakdown of the ARM radar assets is given below: 8 Scanning ARM Clouds Radar Systems (SACR: two radars on single pedestal; six 1st- and two 2nd- generation) 7 Ka-band ARM Zenith profiling Radar (KAZR: five 1st- and two 2nd-generation) 5 X-band Scanning ARM precipitation Radar (XSAPR: four 1st- and one 2nd-generation) 3 C-band Scanning ARM precipitation Radar (CSAPR: two 1st- and one 2nd-generation) 1 W-band ARM Cloud Radar (WACR) 1 Marine W-band ARM Cloud Radar (MWACR: configured to be deployed on a stable table or scanning pedestal). Of these radars, all but six (two SACRs [accounting for four radars], one KAZR, and one 1st-generation CSAPR) have operational assignments. Therefore, the current measurement strategy involves operating 27 radars, not including radar wind profilers (RWPs). This array of instruments represents a combination of scanning and profiling radars at ARM’s sites. In addition to the scanning capabilities, the radars at each site differ in operating frequency, technology, and complexity, but all are complex systems. Some of them were custom designed and built specifically for ARM. Typically, newer systems take a few years to reach operational maturity with adequate characterization, calibration, testing, and quality control. Due to various factors, not all of the radars have achieved an operationally mature status sufficient to provide high-quality data in a research environment. In addition, these radars are often deployed in remote locations and harsh environments to meet science needs. The remoteness of such complex systems is a considerable challenge for continuous operations. Tools needed for a research-level operational radar are not readily available from vendors, and many of the necessary system management tools, both hardware and software, to manage these systems must be developed in-house for such deployments. Based on experience over the past seven years, including conclusions from the first phase of the radar plan, implemented in mid-2016, it is clear that ARM cannot support the operation of all 27 currently deployed radars and expect to provide research-quality data (including higher-order products) with the current resources. Experience from the first phase of the radar plan has provided a better indication than has been available previously of what size radar network is reasonable. A preliminary proposal for what that radar network could look like is provided here. The plan presented here uses the available resources to best support this proposed network.

ARM Mobile Facility↗
NASA NTRS2020

Integrated Demand Management: The FCA Balancing Algorithm

The Collaborative Trajectory Options Program (CTOP) is a new NextGen function that resides within the FAA’s Traffic Flow Management System (TFMS) software. CTOP was designed to be used in the United States’ national airspace to control the distribution of air traffic demand, both temporally and geographically, through a set of Flow Constrained Areas (FCAs). Each FCA is assigned capacity values that represent an estimated upper limit of manageable demand, and CTOP controls to that capacity by using Expect Departure Clearance Time (EDCT) air traffic control clearances, and/or rerouting flights to an alternate FCA or out of the CTOP completely. CTOP’s decisions about which control options best meet system and user needs are based on the Trajectory Options Set (TOS) submitted by airline operators for each flight. The FCA Balancing Algorithm (FBA) described in this document is a proposed decision support capability that generates CTOP capacity entries for FCAs controlling traffic to a common downstream constraint. The FBA provides an equitable distribution of impact, and addresses the added complexity of assigning FCA capacity values for this specific type of use case, greatly simplifying the FAA air traffic manager’s task.

IDM↗
DOE OSTI2013

BioWatch Sample Management System (SMS) Field Operator Guide

The BioWatch Sample Management System is software developed by Los Alamos National Laboratory to support the Department of Homeland Security BioWatch program. Field Operators use the software to keep track of samples and to provide information on the sample management process to other users and software programs within BioWatch. The information tracked about a sample includes the date and time the filter media is assembled in a filter holder, deployed to the field, placed in and removed from a collector, and received from the field, and identifies who performs each task. Field Operators can also use the software to prepare and print forms to document the chain-of-custody transfer of the samples. The BioWatch SMS Field Operator Guide provides easy-to-understand procedures for each task a Field Operator performs. This guide gives basic information about using the computer and other equipment, instructions about checking and editing data, and provides reference information, including appendices of error messages and solutions, words used interchangeably, and safety warnings plus a glossary and an index.

99 GENERAL AND MISCELLANEOUS↗