Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “web-based”

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 343 records · Page 19

Document Concurrence System

The Document Concurrence System is a combination of software modules for routing users expressions of concurrence with documents. This system enables determination of the current status of concurrences and eliminates the need for the prior practice of manually delivering paper documents to all persons whose approvals were required. This system runs on a server, and participants gain access via personal computers equipped with Web-browser and electronic-mail software. A user can begin a concurrence routing process by logging onto an administration module, naming the approvers and stating the sequence for routing among them, and attaching documents. The server then sends a message to the first person on the list. Upon concurrence by the first person, the system sends a message to the second person, and so forth. A person on the list indicates approval, places the documents on hold, or indicates disapproval, via a Web-based module. When the last person on the list has concurred, a message is sent to the initiator, who can then finalize the process through the administration module. A background process running on the server identifies concurrence processes that are overdue and sends reminders to the appropriate persons.

Muhsin, Mansour↗

Tools for Administration of a UNIX-Based Network

Several computer programs have been developed to enable efficient administration of a large, heterogeneous, UNIX-based computing and communication network that includes a variety of computers connected to a variety of subnetworks. One program provides secure software tools for administrators to create, modify, lock, and delete accounts of specific users. This program also provides tools for users to change their UNIX passwords and log-in shells. These tools check for errors. Another program comprises a client and a server component that, together, provide a secure mechanism to create, modify, and query quota levels on a network file system (NFS) mounted by use of the VERITAS File SystemJ software. The client software resides on an internal secure computer with a secure Web interface; one can gain access to the client software from any authorized computer capable of running web-browser software. The server software resides on a UNIX computer configured with the VERITAS software system. Directories where VERITAS quotas are applied are NFS-mounted. Another program is a Web-based, client/server Internet Protocol (IP) address tool that facilitates maintenance lookup of information about IP addresses for a network of computers.

LeClaire, Stephen↗

Discrepancy Reporting Management System

Discrepancy Reporting Management System (DRMS) is a computer program designed for use in the stations of NASA's Deep Space Network (DSN) to help establish the operational history of equipment items; acquire data on the quality of service provided to DSN customers; enable measurement of service performance; provide early insight into the need to improve processes, procedures, and interfaces; and enable the tracing of a data outage to a change in software or hardware. DRMS is a Web-based software system designed to include a distributed database and replication feature to achieve location-specific autonomy while maintaining a consistent high quality of data. DRMS incorporates commercial Web and database software. DRMS collects, processes, replicates, communicates, and manages information on spacecraft data discrepancies, equipment resets, and physical equipment status, and maintains an internal station log. All discrepancy reports (DRs), Master discrepancy reports (MDRs), and Reset data are replicated to a master server at NASA's Jet Propulsion Laboratory; Master DR data are replicated to all the DSN sites; and Station Logs are internal to each of the DSN sites and are not replicated. Data are validated according to several logical mathematical criteria. Queries can be performed on any combination of data.

Cooper, Tonja M.↗

The Technical Work Plan Tracking Tool

The Technical Work Plan Tracking Tool is a web-based application that enables interactive communication and approval of contract requirements that pertain to the administration of the Science, Engineering, Analysis, and Test (SEAT) contract at Johnson Space Center. The implementation of the application has (1) shortened the Technical Work Plan approval process, (2) facilitated writing and documenting requirements in a performance-based environment with associated surveillance plans, (3) simplified the contractor s estimate of the cost for the required work, and (4) allowed for the contractor to document how they plan to accomplish the work. The application is accessible to over 300 designated NASA and contractor employees via two Web sites. For each employee, the application regulates access according to the employee s authority to enter, view, and/or print out diverse information, including reports, work plans, purchase orders, and financial data. Advanced features of this application include on-line approval capability, automatic e-mail notifications requesting review by subsequent approvers, and security inside and outside the firewall.

Chullen, Cinda↗

Web Program for Development of GUIs for Cluster Computers

WIGLAF (a Web Interface Generator and Legacy Application Facade) is a computer program that provides a Web-based, distributed, graphical-user-interface (GUI) framework that can be adapted to any of a broad range of application programs, written in any programming language, that are executed remotely on any cluster computer system. WIGLAF enables the rapid development of a GUI for controlling and monitoring a specific application program running on the cluster and for transferring data to and from the application program. The only prerequisite for the execution of WIGLAF is a Web-browser program on a user's personal computer connected with the cluster via the Internet. WIGLAF has a client/server architecture: The server component is executed on the cluster system, where it controls the application program and serves data to the client component. The client component is an applet that runs in the Web browser. WIGLAF utilizes the Extensible Markup Language to hold all data associated with the application software, Java to enable platform-independent execution on the cluster system and the display of a GUI generator through the browser, and the Java Remote Method Invocation software package to provide simple, effective client/server networking.

Czikmantory, Akos↗

Software for Managing Inventory of Flight Hardware

The Flight Hardware Support Request System (FHSRS) is a computer program that relieves engineers at Marshall Space Flight Center (MSFC) of most of the non-engineering administrative burden of managing an inventory of flight hardware. The FHSRS can also be adapted to perform similar functions for other organizations. The FHSRS affords a combination of capabilities, including those formerly provided by three separate programs in purchasing, inventorying, and inspecting hardware. The FHSRS provides a Web-based interface with a server computer that supports a relational database of inventory; electronic routing of requests and approvals; and electronic documentation from initial request through implementation of quality criteria, acquisition, receipt, inspection, storage, and final issue of flight materials and components. The database lists both hardware acquired for current projects and residual hardware from previous projects. The increased visibility of residual flight components provided by the FHSRS has dramatically improved the re-utilization of materials in lieu of new procurements, resulting in a cost savings of over $1.7 million. The FHSRS includes subprograms for manipulating the data in the database, informing of the status of a request or an item of hardware, and searching the database on any physical or other technical characteristic of a component or material. The software structure forces normalization of the data to facilitate inquiries and searches for which users have entered mixed or inconsistent values.

Salisbury, John↗

Software Assists in Extensive Environmental Auditing

The Base Environmental Management System (BEMS) is a Web-based application program for managing and tracking audits by the Environmental Office of Stennis Space Center in conformity with standard 14001 of the International Organization for Standardization (ISO 14001). (This standard specifies requirements for an environmental-management system.) BEMS saves time by partly automating what were previously manual processes for creating audit checklists; recording and tracking audit results; issuing, tracking, and implementing corrective-action requests (CARs); tracking continuous improvements (CIs); and tracking audit results and statistics. BEMS consists of an administration module and an auditor module. As its name suggests, the administration module is used to administer the audit. It helps administrators to edit the list of audit questions; edit the list of audit locations; assign mandatory questions to locations; track, approve, and edit CARs; and edit completed audits. The auditor module is used by auditors to perform audits and record audit results: it helps the auditors to create audit checklists, complete audits, view completed audits, create CARs, record and acknowledge CIs, and generate reports from audit results.

Callac, Christopher↗

Situational Lightning Climatologies for Central Florida, Phase 2, Part 3

The threat of lightning is a daily concern during the warm season in Florida. The forecasters at the Spaceflight Meteorology Group (SMG) at Johnson Spaceflight Center in Houston, TX consider lightning in their landing forecasts for space shuttles at the Kennedy Space Center (KSC), FL Shuttle Landing Facility (SLF). The forecasters at the National Weather Service in Melbourne, FL (NWS MLB) do the same in their routine Terminal Aerodrome Forecasts (TAFs) for seven airports in the NWS MLB County Warning Area (CWA). The Applied Meteorology Unit created flow regime climatologies of lightning probability in the 5-, 10-, 20-, and 30-n mi circles surrounding the Shuttle Landing Facility (SLF) and all airports in the NWS MLB county warning area in 1-, 3-, and 6-hour increments. The results were presented in tabular and graphical format and incorporated into a web-based graphical user interface so forecasters could easily navigate through the data and to make the GUI usable in any web browser on computers with different operating systems.

Bauman, William H., III↗

Flow Regime Based Climatologies of Lightning Probabilities for Spaceports and Airports

Objective: provide forecasters with a "first guess" climatological lightning probability tool (1) Focus on Space Shuttle landings and NWS T AFs (2) Four circles around sites: 5-, 10-, 20- and 30 n mi (4) Three time intervals: hourly, every 3 hr and every 6 hr It is based on: (1) NLDN gridded data (2) Flow regime (3) Warm season months of May-Sep for years 1989-2004 Gridded data and available code yields squares, not circles Over 850 spread sheets converted into manageable user-friendly web-based GUI

Bauman, William H., III↗

Business Systems Branch Abilities, Capabilities, and Services Web Page

During the INSPIRE summer internship I acted as the Business Systems Branch Capability Owner for the Kennedy Web-based Initiative for Communicating Capabilities System (KWICC), with the responsibility of creating a portal that describes the services provided by this Branch. This project will help others achieve a clear view ofthe services that the Business System Branch provides to NASA and the Kennedy Space Center. After collecting the data through the interviews with subject matter experts and the literature in Business World and other web sites I identified discrepancies, made the necessary corrections to the sites and placed the information from the report into the KWICC web page.

Cortes-Pena, Aida Yoguely↗

NASA Range Safety Annual Report 2007

As always, Range Safety has been involved in a number of exciting and challenging activities and events. Throughout the year, we have strived to meet our goal of protecting the public, the workforce, and property during range operations. During the past year, Range Safety was involved in the development, implementation, and support of range safety policy. Range Safety training curriculum development was completed this year and several courses were presented. Tailoring exercises concerning the Constellation Program were undertaken with representatives from the Constellation Program, the 45th Space Wing, and the Launch Constellation Range Safety Panel. Range Safety actively supported the Range Commanders Council and it subgroups and remained involved in updating policy related to flight safety systems and flight safety analysis. In addition, Range Safety supported the Space Shuttle Range Safety Panel and addressed policy concerning unmanned aircraft systems. Launch operations at Kennedy Space Center, the Eastern and Western ranges, Dryden Flight Research Center, and Wallops Flight Facility were addressed. Range Safety was also involved in the evaluation of a number of research and development efforts, including the space-based range (formerly STARS), the autonomous flight safety system, the enhanced flight termination system, and the joint advanced range safety system. Flight safety system challenges were evaluated. Range Safety's role in the Space Florida Customer Assistance Service Program for the Eastern Range was covered along with our support for the Space Florida Educational Balloon Release Program. We hope you have found the web-based format both accessible and easy to use. Anyone having questions or wishing to have an article included in the 2008 Range Safety Annual Report should contact Alan Dumont, the NASA Range Safety Program Manager located at the Kennedy Space Center, or Michael Dook at NASA Headquarters.

Dumont, Alan G.↗

Tower Mesonetwork Climatology and Interactive Display Tool

Forecasters at the 45th Weather Squadron and Spaceflight Meteorology Group use data from the tower network over the Kennedy Space Center (KSC) and Cape Canaveral Air Force Station (CCAFS) to evaluate Launch Commit Criteria, and issue and verify forecasts for ground operations. Systematic biases in these parameters could adversely affect an analysis, forecast, or verification. Also, substantial geographical variations in temperature and wind speed can occur under specific wind directions. To address these concerns, the Applied Meteorology Unit (AMU) developed a climatology of temperatures and winds from the tower network, and identified the geographical variation and significant tower biases. The mesoclimate is largely driven by the complex land-water interfaces across KSC/CCAFS. Towers with close proximity to water typically had much warmer nocturnal temperatures and higher wind speeds throughout the year. The strongest nocturnal wind speeds occurred from October to March whereas the strongest mean daytime wind speeds occurred from February to May. These results of this project can be viewed by forecasters through an interactive graphical user interface developed by the AMU. The web-based interface includes graphical and map displays of mean, standard deviation, bias, and data availability for any combination of towers, variables, months, hours, and wind directions.

Case, Jonathan L.↗

Request-Driven Schedule Automation for the Deep Space Network

The DSN Scheduling Engine (DSE) has been developed to increase the level of automated scheduling support available to users of NASA s Deep Space Network (DSN). We have adopted a request-driven approach to DSN scheduling, in contrast to the activity-oriented approach used up to now. Scheduling requests allow users to declaratively specify patterns and conditions on their DSN service allocations, including timing, resource requirements, gaps, overlaps, time linkages among services, repetition, priorities, and a wide range of additional factors and preferences. The DSE incorporates a model of the key constraints and preferences of the DSN scheduling domain, along with algorithms to expand scheduling requests into valid resource allocations, to resolve schedule conflicts, and to repair unsatisfied requests. We use time-bounded systematic search with constraint relaxation to return nearby solutions if exact ones cannot be found, where the relaxation options and order are under user control. To explore the usability aspects of our approach we have developed a graphical user interface incorporating some crucial features to make it easier to work with complex scheduling requests. Among these are: progressive revelation of relevant detail, immediate propagation and visual feedback from a user s decisions, and a meeting calendar metaphor for repeated patterns of requests. Even as a prototype, the DSE has been deployed and adopted as the initial step in building the operational DSN schedule, thus representing an important initial validation of our overall approach. The DSE is a core element of the DSN Service Scheduling Software (S(sup 3)), a web-based collaborative scheduling system now under development for deployment to all DSN users.

Johnston, Mark D.↗

The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards.

MGSS↗

Use of QuakeSim and UAVSAR for Earthquake Damage Mitigation and Response

Spaceborne, airborne, and modeling and simulation techniques are being applied to earthquake risk assessment and response for mitigation from this natural disaster. QuakeSim is a web-based portal for modeling interseismic strain accumulation using paleoseismic and crustal deformation data. The models are used for understanding strain accumulation and release from earthquakes as well as stress transfer to neighboring faults. Simulations of the fault system can be used for understanding the likelihood and patterns of earthquakes as well as the likelihood of large aftershocks from events. UAVSAR is an airborne L-band InSAR system for collecting crustal deformation data. QuakeSim, UAVSAR, and DESDynI (following launch) can be used for monitoring earthquakes, the associated rupture and damage, and postseismic motions for prediction of aftershock locations.

fault systems↗

Web Based Tool for Mission Operations Scenarios

A conventional practice for spaceflight projects is to document scenarios in a monolithic Operations Concept document. Such documents can be hundreds of pages long and may require laborious updates. Software development practice utilizes scenarios in the form of smaller, individual use cases, which are often structured and managed using UML. We have developed a process and a web-based scenario tool that utilizes a similar philosophy of smaller, more compact scenarios (but avoids the formality of UML). The need for a scenario process and tool became apparent during the authors' work on a large astrophysics mission. It was noted that every phase of the Mission (e.g., formulation, design, verification and validation, and operations) looked back to scenarios to assess completeness of requirements and design. It was also noted that terminology needed to be clarified and structured to assure communication across all levels of the project. Attempts to manage, communicate, and evolve scenarios at all levels of a project using conventional tools (e.g., Excel) and methods (Scenario Working Group meetings) were not effective given limitations on budget and staffing. The objective of this paper is to document the scenario process and tool created to offer projects a low-cost capability to create, communicate, manage, and evolve scenarios throughout project development. The process and tool have the further benefit of allowing the association of requirements with particular scenarios, establishing and viewing relationships between higher- and lower-level scenarios, and the ability to place all scenarios in a shared context. The resulting structured set of scenarios is widely visible (using a web browser), easily updated, and can be searched according to various criteria including the level (e.g., Project, System, and Team) and Mission Phase. Scenarios are maintained in a web-accessible environment that provides a structured set of scenario fields and allows for maximum visibility across the project. One key aspect is that the tool was built for a scenario process that accounts for stakeholder input, review, comment, and concurrence. By creating well-designed opportunities for stakeholder input and concurrence and by making the scenario content easily accessible to all project personnel, we maximize the opportunities for stakeholders to both understand and agree on the concepts for how their mission is to be carried out.

Boyles, Carole A.↗

Implementing distributed operations : a comparison of two Deep Space Missions

Two very different deep space exploration missions—Mars Exploration Rover and Cassini—have made use of distributed operations for their science teams. In the case of MER, the distributed operations capability was implemented only after the prime mission was completed, as the rovers continued to operate well in excess of their expected mission lifetimes; Cassini, designed for a prime mission of four years, had planned for distributed operations from its inception. The rapid command turnaround timeline of MER, as well as many of the operations features implemented to support it, have proven to be conducive to distributed operations. These features include: a single science team leader during the tactical operations timeline, highly integrated science and engineering teams, processes and file structures designed to permit multiple team members to work in parallel to deliver sequencing products, web-based spacecraft status and planning reports for team-wide access, and near-elimination of paper products from the operations process.

Larsen, Barbara↗

BEAST: Expanding Sustainable Data Infrastructure for High-Enthalpy Facilities

Reproducible, data-driven thermal protection system (TPS) research requires that experimental records from high-enthalpy testing be consistently structured, traceable, and accessible across campaigns and institutions. In practice, however, arcjet and plasma facilities data remain largely fragmented: raw diagnostics are stored in ad hoc formats, material sample histories are disconnected from test conditions, and metadata standards are absent, precluding systematic cross-campaign analysis and long-term reuse. BEAST (Backend for Experiment Analysis, Storage, and Traceability) is an open-source, web-based platform that addresses these limitations by providing a unified, queryable infrastructure for high-enthalpy ground-test data [1]. First presented at the 15th Ablation Workshop [2], BEAST has since undergone significant development. The platform ingests and structures multi-channel time-series diagnostics, facility configurations, and material property records within a common provenance model, ensuring end-to-end traceability from raw sensor acquisition to reduced experimental quantities. A versioned material library links specimen identity and processing history to the specific runs in which each sample was tested. An integrated modeling workbench enables training and evaluation of regression models directly on archived experimental data, supporting condition interpolation and the construction of empirical material response databases. Beyond its original deployment at NASA Ames Research Center, BEAST has been designed to be facility-agnostic, with ongoing efforts to extend its adoption to other facilities. Its modular architecture accommodates heterogeneous diagnostic setups and facility types, and its future open-source distribution allows institutions to build on a common data standard rather than maintaining isolated, bespoke solutions. BEAST is further integrated within a broader ecosystem of companion tools: arcjetCV [3] extracts recession rates and shock standoff distances from high-speed video using computer vision, and miniSTARscan [4] provides sub-minute, portable photogrammetric surface reconstruction of test articles before and after exposure. All tools share a common data schema, enabling seamless ingestion of surface geometry, imagery, and time-series data into a single, coherent experimental record.

Database↗