Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “operator support”

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 181 records · Page 10

Launch Processing System operations with a future look to Operations Analyst (OPERA)

The Launch Processing System architecture and the ground support operations required to provide Shuttle System engineers with the capability to safely process and launch an Orbiter are described. The described ground operations are the culmination of eleven years of experience and redesign. Some of the 'lessons learned' are examined, and problem areas which ground support operations have identified over the years as the Shuttle and Launch Processing Systems continue to grow in complexity are discussed. The Operational Analyst for Distributed Systems (OPERA), a proposed set of expert systems for the Launch Processing System Operational assistance, is discussed along with its extensions to prospective future configurations and components for the Launch Processing System.

Heard, Astrid E.↗

HOSC DTN Gateway Test Report

Goals of this activity: Test the Huntsville Operations Support Center (HOSC) Delay/Disruption Tolerant Networking (DTN) Gateway for operational use Current activity includes: (1) Test the Implementation of a new DTN2 gateway at the HOSC (2) Confirm integration of DTN nodes into the S-band uplink and Ku-band downlink of the ISS for limited use (3) Implement Aggregate Custody Signal to ISS platforms (4) Verify operational support for Colorado University (CU) onboard components (5) Verify ability to support Multi-Purpose End-To- End Robotic Operation Network (METERON) OpsCon-2

Pitts, Robert Lee↗

Usability of Operational Performance Support Tools - Findings from Sea Test II

Sea Test II, aka NASA Extreme Environment Mission Operations 17(NEEMO 17) took place in the Florida Aquarius undersea habitat. This confined underwater environment provides a excellent analog for space habitation providing similarities to space habitation such as hostile environment, difficult logistics, autonomous operations, and remote communications. This study collected subjective feedback on the usability of two performance support tools during the Sea Test II mission, Sept 10‐14, 2013; Google Glass and iPAD. The two main objectives: - Assess the overall functionality and usability of each performance support tool in a mission analog environment. - Assess the advantages and disadvantages of each tool when performing operational procedures and Just‐In‐Time‐Training (JITT).

Byrne, Vicky↗

Secure Remote Access Issues in a Control Center Environment

The ISS finally reached an operational state and exists for local and remote users. Onboard payload systems are managed by the Huntsville Operations Support Center (HOSC). Users access HOSC systems by internet protocols in support of daily operations, preflight simulation, and test. In support of this diverse user community, a modem security architecture has been implemented. The architecture has evolved over time from an isolated but open system to a system which supports local and remote access to the ISS over broad geographic regions. This has been accomplished through the use of an evolved security strategy, PKI, and custom design. Through this paper, descriptions of the migration process and the lessons learned are presented. This will include product decision criteria, rationale, and the use of commodity products in the end architecture. This paper will also stress the need for interoperability of various products and the effects of seemingly insignificant details.

Pitts, Lee↗

Secure Payload Access to the International Space Station

The ISS finally reached an operational state and exists for local and remote users. Onboard payload systems are managed by the Huntsville Operations Support Center (HOSC). Users access HOSC systems by internet protocols in support of daily operations, preflight simulation, and test. In support of this diverse user community, a modem security architecture has been implemented. The architecture has evolved over time from an isolated but open system to a system which supports local and remote access to the ISS over broad geographic regions. This has been accomplished through the use of an evolved security strategy, PKI, and custom design. Through this paper, descriptions of the migration process and the lessons learned are presented. This will include product decision criteria, rationale, and the use of commodity products in the end architecture. This paper will also stress the need for interoperability of various products and the effects of seemingly insignificant details.

Pitts, R. Lee↗

HL-20 operations and support requirements for the Personnel Launch System mission

The processing, mission planning, and support requirements were defined for the HL-20 lifting-body configuration that can serve as a Personnel Launch System. These requirements were based on the assumption of an operating environment that incorporates aircraft and airline support methods and techniques that are applicable to operations. The study covered the complete turnaround process for the HL-20, including landing through launch, and mission operations, but did not address the support requirements of the launch vehicle except for the integrated activities. Support is defined in terms of manpower, staffing levels, facilities, ground support equipment, maintenance/sparing requirements, and turnaround processing time. Support results were drawn from two contracted studies, plus an in-house analysis used to define the maintenance manpower. The results of the contracted studies were used as the basis for a stochastic simulation of the support environment to determine the sufficiency of support and the effect of variance on vehicle processing. Results indicate the levels of support defined for the HL-20 through this process to be sufficient to achieve the desired flight rate of eight flights per year.

Morris, W. D.↗

Definition of technology development missions for early space stations orbit transfer vehicle serving. Phase 2, task 1: Space station support of operational OTV servicing

Representative space based orbital transfer vehicles (OTV), ground based vehicle turnaround assessment, functional operational requirements and facilities, mission turnaround operations, a comparison of ground based versus space based tasks, activation of servicing facilities prior to IOC, fleet operations requirements, maintenance facilities, OTV servicing facilities, space station support requirements, and packaging for delivery are discussed.

Source record↗

STK Integrated Message Production List Editor (SIMPLE) for CEO Operations

Late in fiscal year 2011, the Crew Earth Observations (CEO) team was tasked to upgrade and replace its mission planning and mission operations software systems, which were developed in the Space Shuttle era of the 1980s and 1990s. The impetuses for this change were the planned transition of all workstations to the Windows 7 64-bit operating system and the desire for more efficient and effective use of Satellite Tool Kit (STK) software required for reliable International Space Station (ISS) Earth location tracking. An additional requirement of this new system was the use of the same SQL database of CEO science sites from the SMMS, which was also being developed. STK Integrated Message Production List Editor (SIMPLE) is the essential, all-in-one tool now used by CEO staff to perform daily ISS mission planning to meet its requirement to acquire astronaut photography of specific sites on Earth. The sites are part of a managed, long-term database that has been defined and developed for scientific, educational, and public interest. SIMPLE's end product is a set of basic time and location data computed for an operator-selected set of targets that the ISS crew will be asked to photograph (photography is typically planned 12 to 36 hours out). The CEO operator uses SIMPLE to (a) specify a payload operations planning period; (b) acquire and validate the best available ephemeris data (vectors) for the ISS during the planning period; (c) ingest and display mission-specific site information from the CEO database; (d) identify and display potential current dynamic event targets as map features; (e) compute and display time and location information for each target; (f) screen and select targets based on known crew availability constraints, obliquity constraints, and real-time evaluated constraints to target visibility due to illumination (sun elevation) and atmospheric conditions (weather); and finally (g) incorporate basic, computed time and location information for each selected target into the daily CEO Target List product (message) for submission to ISS payload planning and integration teams for their review and approval prior to uplink. SIMPLE requires and uses the following resources: an ISS mission planning period Greenwich Mean Time start date/time and end date/time), the best available ISS mission ephemeris data (vectors) for that planning period, the STK software package configured for the ISS, and an ISS mission-specific subset of the CEO sites database. The primary advantages realized by the development and implementation of SIMPLE into the CEO payload operations support activity are a smooth transition to the Windows 7 operating system upon scheduled workstation refresh; streamlining of the input and verification of the current ISS ephemeris (vector data); seamless incorporation of selected contents of the SQL database of science sites; the ability to tag and display potential dynamic event opportunities on orbit track maps; simplification of the display and selection of encountered sites based on crew availability, illumination, obliquity, and weather constraints; the incorporation of high-quality mapping of the Earth with various satellite-based datasets for use in describing targets; and the ability to encapsulate and export the essential selected target elements in XML format for use by onboard Earth-location systems, such as Worldmap. SIMPLE is a carefully designed and crafted in-house software package that includes detailed help files for the user and meticulous internal documentation for future modifications. It was delivered in February 2012 for test and evaluation. Following acceptance, it was implemented for CEO mission operations support in May 2012.

Trenchard, Mike↗

Space construction base operations in support of solar power satellite development

Development of the Solar Power Satellite (SPS) system for initial operation in the late 1990's requires substantial orbital development activities in the mid-1980's leading to a key system development decision in about 1987. A manned Space Construction Base (SCB) in low-earth orbit is needed to support the SPS orbital development program. The SPS system development issues are defined, along with a candidate development program for resolving these issues. The development hardware systems of interest for the mid-1980's include: (1) a tapered linear array microwave antenna (123 x 125.6 m 'cross') with a 57-kW/rf amplitron output, which is SCB constructed and operated in low-earth orbit initially, and, subsequently, unmanned in geosynchronous earth orbit; and (2) a SCB-constructed and -operated 9 x 14.4 m planar array antenna (358 kW/rf/) powered by a 455-kWe silicon photovoltaic solar collector.

Mckhann, G. G.↗

Proposed Classifications of Remote Operations for Nuclear Reactors Based on Physical and Cybersecurity Considerations

The incorporation of remote operations into reactor operations is a topic of high interest among advanced and small modular reactor (A/SMR) vendors, with some considering it essential to the success of their business models. However, remote operations are a concept novel to the nuclear industry. While various technical aspects of remote operations have been explored, a significant gap remains in understanding the security implications of integrating remote operations into reactor designs, particularly concerning the security requirements for remote-operations facilities and infrastructure. This report aims to address this gap by first defining classes of remote operation based on the extent of remote access to reactor control systems and grounded in the existing regulatory framework with compatible terminology. Secondly, the report outlines the physical and cybersecurity requirements applicable to remote-operations facilities and infrastructure at each defined class. These requirements are based on existing licensing frameworks provided by 10 Code of Federal Regulations (CFR) Part 50 and 10 CFR Part 52, as well as the upcoming A/SMR licensing framework in the proposed Part 53. The assessment focuses specifically on security regulations, such as 10 CFR Part 73, which includes provisions for both cybersecurity (§ 73.54) and physical security (§ 73.55). This report proposes five classes of remote reactor operations. Class 1 involves remote monitoring only, with no control over reactor systems. Class 2 allows for the remote issuance of allowlisted commands to the reactor facility. Class 3 extends control to non-safety-significant, non-safety-related, or not important to safety systems and equipment. Class 4 permits remote control of safety-significant systems. Finally, Class 5 allows remote control of safety-related systems. It is important to note that these classes were defined purely with functionality in mind, without considering the practicality or feasibility of implementation for each class under current or upcoming regulatory guidance. The intention behind this approach is to enable an assessment of which security requirements apply to each class, allowing readers to evaluate the implementation possibilities for their specific use cases. Following the definition of remote-operation classes, the report assesses the specific physical and cybersecurity requirements applicable to the remote-operations facility and infrastructure within each defined class. This includes defining the types and locations of operators that are possible at each class of operation and, based on operator type and location, as well as functionality within each class, outlining the physical and cybersecurity requirements. By detailing the security requirements by class, the report provides readers with the information needed to determine the type of security program they may need to implement for their desired concept of operation. The next contribution of this report was to assess the practicality of implementing each proposed class of remote operations based upon the security requirement assessment. In short, three of the five proposed remote-operation classes were found to possibly have a practical path forward to implementation under the U.S. regulatory framework. Class 1 remote operations are currently in use in the U.S. while Class 2 and 3 remote operations may be logistically possible to implement under the U.S. regulatory framework. The final two Classes, 4 and 5, would likely be logistically difficult, if not infeasible to implement within the current U.S. physical- and cybersecurity regulatory framework. Given the results of the feasibility assessment, an example architecture is proposed for both Class 2, remote allowlisted commands, and Class 3, remote control of non-safety systems as well as security implication assessments of each architecture. These example implementations are not meant to be prescriptive in terms of how Class 2 or Class 3 remote operations should be deployed; instead, they are intended to be informative to stakeholders on how Class 2 or Class 3 could potentially be applied in order to inform their system design. An example architecture for Class 1 remote monitoring was not provided as Class 1 in already in use in U.S. nuclear operations. Example architectures for Class 4 and Class 5 were not provided due to their assessment of being likely infeasible to implement. The final contribution is an assessment of the physical- and cybersecurity implications of introducing autonomous operations into an A/SMR. What was found was that the security implications can be separated into two cases. Autonomous operations supported by SSCs located only at the reactor site, and autonomous operations supported by SSCs outside of the reactor site. For the first case, the introduction of autonomous systems will likely not change the facility’s requirement to comply with existing cyber and physical security regulation

22 - GENERAL STUDIES OF NUCLEAR REACTORS↗

Earth Independent Medical Operations (EIMO)

Inherent in interplanetary space travel are unprecedented challenges that could threaten mission success and negatively impact crew health and performance. Return to definitive care is essentially untenable and resources will be constrained with practically no re-supply capability. Access to ground-based medical expertise will be significantly delayed under nominal conditions with exacerbation during conjunction or prolonged dust storms. Taken together, these challenges necessitate the development of a progressively autonomous medical operational support system to assist the crew medical officer (CMO). While support from ground based medical experts will remain indispensable for pre-mission planning, the approach to management of acute/emergent medical contingencies will require a gradual transition of medical care and decision making from terrestrial to space-based assets, enabling support of astronaut health and performance and reducing overall mission risk. To progressively enable EIMO, a series of meetings were convened with subject matter experts from within NASA, academia and industry to facilitate mapping of the path to support autonomous medical operations. Topics explored in these meetings included the scope of data (storage capacity, usage, transmission rate and bandwidth, computing capacity), CMO training, supply and resource management and task load balance. Recommendations from these meetings will inform the EIMO Concept of Operations and definition of the associated requirements culminating in updates to the NASA 3001 standards. The EIMO project team will work with stakeholders to conceptualize a clinical decision support system (CDSS) to assist the CMO in response to medical contingencies when terrestrial support is delayed or otherwise unavailable. The CDSS will be a system of systems that will utilize data from numerous input vectors. Successful deployment of the CDSS will facilitate medical decision making while decreasing the cognitive load leading to an improvement in task load balancing. Additional benefits of the envisioned CDSS include assistance with inventory management, locating resources, storage/retrieval of medical records, highlighting trends in recorded data, in addition to providing a consult for diagnosis and treatment. More advanced features might include passive monitoring to identify early warning signs of behavioral or medical anomalies to possibly pre-empt onset of conditions that would compromise crew health and performance.

Benjamin Easter↗

Support of Operation Icebrige Using the NASA P-3B Airborne Laboratory

The National Aeronautics and Space Administration (NASA) Wallops Flight Facility's (WFF) P-313 Orion is a medium-lift, four engine turbo-prop aircraft that has been reconfigured from a military aircraft to an Earth Science research platform. The aircraft has a long history of supporting science missions, flying on average over 200 hours per year. Examples of research missions that have been flown aboard the aircraft are remote sensing flights to study geophysical parameters including ice-sheet topography and periodic change, soil moisture content, and atmospheric aerosol constituents. Missions are conducted for the purposes of calibration/validation of various NASA and international satellites, including ICESat-1, that monitor climate change as well as process studies and the test of new prototype remote sensing instruments. Due to the recent demise of the NASA ICESat-1 spacecraft, NASA elected to fill the data void between it and the upcoming ICESat-2 using airborne measurements. This mission is called Operation Ice Bridge (OIB). These measurements are being made from a variety of aircraft, including the P-313. The aircraft is being using to conduct ice surveys of the Arctic, in particular Greenland. The aircraft has been conducting ice surveys of Greenland since 1993 for the purposes of topographic mapping of both the surface and basal topography; therefore, OIB is a natural fit for the aircraft and its crew. Additional measurements of snow depth and gravity have been made as part of OIB. This paper will provide an overview of the P-313 platform and highlight the support for Operation Ice Bridge.

Guillory, Anthony R.↗

Accelerator Physics at NSLS-II: Research Accomplishments in 2023

NSLS-II accelerator physicists provided operation support for user operations and machine start-ups, carried out routine lattice characterization, and produced regular reports on beam dynamics. The commissioning of a superconducting wiggler for the HEX beamline is complete, and the wiggler effects on beam dynamics have been studied. A Facility Improvement Project for absolute lattice characterization has been approved and funded. We implemented and tested a new orbit-based technique of lattice characterization and correction. We developed a theory to calculate the beam-induced power in ceramic vacuum chambers and a new convergence map technique for nonlinear lattice characterization. We continued working on the NSLS-II upgrade including lattice development, commissioning a low-energy complex bend prototype, analyzing beam sensitivity to various errors, implementing higher-harmonic RF cavities, studying collective effects, and assessing FEL options. We also supported lattice optimization and beam diagnostics development for the EIC project. Main research accomplishments achieved in 2023, are summarized in this report.

43 PARTICLE ACCELERATORS↗

Telecommunications and data acquisition systems support for Voyager missions to Jupiter and Saturn, 1972-1981, prelaunch through Saturn encounter

The Deep Space Network has supported the Voyager Project for approximately nine years, during which time implementation, testing, and operational support was provided. Four years of this time involved testing prior to launch; the final five years included network operations support and additional network implementation. Intensive and critical support intervals included launch and four planetary encounters. The telecommunications and data acquisition support for the Voyager Missions to Jupiter and Saturn are summarized.

Traxler, M. R.↗

Evolution of the satellite telemetry data processing facility at the Goddard Space Flight Center.

Data from scientific and application satellites managed by the NASA Goddard Space Flight Center are acquired through the world-wide Spacecraft Tracking and Data Network (STDN). These data are forwarded to a central telemetry data processing facility whose primary objective is the timely provision of the data to users in a form suitable for their analysis. In a successful evolution, a satellite data processing facility must adapt to changing support requirements while operationally supporting active spacecraft. Advances in the technology of data transmission, data storage systems, and file management make it feasible to implement a third-generation system which will be able to satisfy experimenter requirements for the next ten years.

Keipert, F. A.↗

Skylab mission planning support through the use of a hybrid simulation

The manner in which a hybrid simulation was used in support of Skylab operations in the area of dynamics and control is described. Simulation results were used in the development of acceptable vehicle maneuvers and in the verification of acceptability when the maneuvers were integrated into daily flight plans. The criterion of acceptability was based on vehicle controllability and the minimization of thruster system propellant usage. A simulation of a representative daily flight plan containing three experimental maneuvers is included, along with thruster attitude control system propellant usage tables which show predicted and actual usage for each mission. The inherent characteristics of quick turnaround and flexibility afforded by the hybrid computer proved invaluable in the operations support required throughout the Skylab mission.

Hammer, M. W.↗