Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “executable files”

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 487 records · Page 27
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

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 mission of more than ten 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. Additionally, MER has benefited from the initial co-location of its entire operations team, and from having a single Principal Investigator, while Cassini operations have had to reconcile multiple science teams distributed from before launch. Cassini has faced greater challenges in implementing effective distributed operations. Because extensive early planning is required to capture science opportunities on its tour and because sequence development takes significantly longer than sequence execution, multiple teams are contributing to multiple sequences concurrently. The complexity of integrating inputs from multiple teams is exacerbated by spacecraft operability issues and resource contention among the teams, each of which has their own Principal Investigator. Finally, much of the technology that MER has exploited to facilitate distributed operations was not available when the Cassini ground system was designed, although later adoption of web-based and telecommunication tools has been critical to the success of Cassini operations.

Cassini Mission↗
NASA NTRS2011

NASA Flight Planning Branch Space Shuttle Lessons Learned

Planning products and procedures that allowed the mission Flight Control Teams and the Astronaut crews to plan, train and fly every Space Shuttle mission were developed by the Flight Planning Branch at the NASA Johnson Space Center in Houston, Texas. As the Space Shuttle Program came to a close, lessons learned were collected from each phase of the successful execution of these Space Shuttle missions. Specific examples of how roles and responsibilities of console positions that develop the crew and vehicle attitude timelines have been analyzed and will be discussed. Additionally, the relationships and procedural hurdles experienced through international collaboration have molded operations. These facets will be explored and related to current and future operations with the International Space Station and future vehicles. Along with these important aspects, the evolution of technology and continual improvement of data transfer tools between the Space Shuttle and ground team has also defined specific lessons used in improving the control team s effectiveness. Methodologies to communicate and transmit messages, images, and files from the Mission Control Center to the Orbiter evolved over several years. These lessons were vital in shaping the effectiveness of safe and successful mission planning and have been applied to current mission planning work in addition to being incorporated into future space flight planning. The critical lessons from all aspects of previous plan, train, and fly phases of Space Shuttle flight missions are not only documented in this paper, but are also discussed regarding how they pertain to changes in process and consideration for future space flight planning.

Clevenger, Jennifer D.↗
DOE OSTI2020

ESGF Future Architecture Report (V.1.1)

This document reports the findings of the Earth System Grid Federation Future Architecture Face-to-Face Meeting held in the UK 5-7 November 2019, attended by technical representatives from the ESGF partner organisations. ESGF is an International federated archive that provides access to Earth science data. It is fundamentally a distributed file management system with its main function being data dissemination through the provision of services for efficient replication and search. It has been in operation for over ten years and has undergone continuous improvements and enhancements over this time span. The Future Architecture is a major review of the software system including a fundamental reassessment of its requirements with a view to develop a new overall system architecture. This has been initiated in the light of challenges around the maintenance of the existing software legacy and a changing technology landscape and practices in the communities it serves. The work is being carried out under the oversight of the ESGF Executive Committee1,2 and is coordinated activity between ESGF and the European IS-ENES3 project.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2022

Precursor Analysis Report: Conti Ransomware Attack on the Health Service Executive of Ireland 2021

The Conti Ransomware Attack on the Health Service Executive (HSE) of Ireland 2021 Precursor Analysis Report leverages publicly available information about the attack and catalogs anomalous observables for each technique employed by the adversary. This analysis is based upon the methodology of the Cybersecurity for the Operational Technology Environment (CyOTE) program. The HSE provides public healthcare corporate services and operational services throughout Ireland, with critical functions including the acute national ambulance service, acute hospital service, and community healthcare service. On 14 May 2021, Conti ransomware encrypted 80 percent of the HSE’s Information Technology (IT) infrastructure across corporate, hospital, community, and electronic health record services. Conti is a ransomware-as-a-service operation that encrypts local files, uses double extortion against victims, and is facilitated by many intrusion tools. The attack forced the HSE to shut down its entire IT infrastructure to contain the ransomware, forcing employees to revert to pen and paper recordkeeping and leading to the cancellation of many appointments and procedures. The adversary also exfiltrated 700 GB of data, compromising the confidentiality of patients’ protected health information. Had the adversary targeted the COVID-19 cloud systems or operational technology assets, such as Internet of Medical Things medical devices or smart building management systems, the impact of the attack would almost certainly have been far more severe. Researchers and analysts identified 21 unique techniques (used in a sequence of 23 steps) likely utilized during the attack with a total of 1,185 observables using MITRE ATT&CK® for Industrial Control Systems. The CyOTE program assesses observables accompanying techniques used prior to the triggering event to identify opportunities to detect malicious activity. If observables accompanying the attack techniques are perceived and investigated prior to the triggering event, earlier comprehension of malicious activity can take place. Twenty-one of the identified techniques used during the attack on the HSE were precursors to the triggering event. Analysis identified 1,086 observables associated with these precursor techniques, 850 of which were assessed to have an increased likelihood of being perceived in the 57 days preceding the triggering event. The response and comprehension time could have been reduced if the observables had been identified earlier. The information gathered in this report contributes to a library of observables tied to a repository of artifacts, data sources, and technique detection references for practitioners and developers to support the comprehension of indicators of attack. Asset owners and operators can use these products if they experience similar observables or to prepare for comparable scenarios.

45 MILITARY TECHNOLOGY, WEAPONRY, AND NATIONAL DEF↗
DOE OSTI2021

SMC 2021 Data Challenge: Analyzing Resource Utilization and User Behavior on Titan Supercomputer

Resource utilization statistics of submitted jobs on a supercomputer can help us understand how users from various scientific domains use HPC platforms and better design a job scheduler. We explore to generate insight regarding workload distribution and usage pattern domains from job scheduler trace, GPU failure information, and project-specific information collected from Titan supercomputer. Furthermore, we want to know how the scheduler performance varies over time and how the users' scheduling behavior changes following a system failure. These observations have the potential to provide valuable insight, which is helpful to prepare for system failures. These practices will help us develop and apply novel machine learning algorithms in understanding system behavior, requirement, and better scheduling of HPC systems. There are two datasets, RUR and GPU: RUR dataset is the job scheduler traces collected from the Titan supercomputer from 01/01/2015 to 07/31/2019 (2015.csv - 2019.csv). These were collected using resource Utilization Report (RUR), a Cray-developed resource-usage data collection and reporting system. It contains the usage information of its critical resources (CPU, Memory, GPU, and I/O) of each running job on Titan during that period (https://ieeexplore.ieee.org/abstract/document/8891001). It includes ProjectAreas as additional information, every job is associated with a project ID. TheProjectAreas.csv dataset provides a mapping of the project ID to its domain science. GPU dataset has information regarding GPU failure on Titan. There have been some hardware-related issues in the GPUs in Titan that caused some GPUs to fail, sometimes irrecoverably during some job runs. This dataset provides information regarding these failures during the execution of the submitted jobs. GPUs on Titan are uniquely identified by a serial number (SN), and they are installed in a location. A GPU can be installed in a location, then removed from that location following a failure, and then re-installed in a different location after fixing the problem. If the failure can't be recovered, the GPU might be removed entirely from Titan. There are two prominent types of failures that resulted in the removal of GPUs from Titan: Double Bit Error (DBE) and Out of the Bus (OTB). The dataset (gc_full.csv) has seven attributes, we provided a short description of these attributes in the ReadMe file. To learn more about this dataset, please refer to the git repository https://github.com/olcf/TitanGPULife and the related publication (https://ieeexplore.ieee.org/abstract/document/9355319).

42 ENGINEERING↗
NASA NTRS2011

Development of Monte Carlo Capability for Orion Parachute Simulations

Parachute test programs employ Monte Carlo simulation techniques to plan testing and make critical decisions related to parachute loads, rate-of-descent, or other parameters. This paper describes the development and use of a MATLAB-based Monte Carlo tool for three parachute drop test simulations currently used by NASA. The Decelerator System Simulation (DSS) is a legacy 6 Degree-of-Freedom (DOF) simulation used to predict parachute loads and descent trajectories. The Decelerator System Simulation Application (DSSA) is a 6-DOF simulation that is well suited for modeling aircraft extraction and descent of pallet-like test vehicles. The Drop Test Vehicle Simulation (DTVSim) is a 2-DOF trajectory simulation that is convenient for quick turn-around analysis tasks. These three tools have significantly different software architectures and do not share common input files or output data structures. Separate Monte Carlo tools were initially developed for each simulation. A recently-developed simulation output structure enables the use of the more sophisticated DSSA Monte Carlo tool with any of the core-simulations. The task of configuring the inputs for the nominal simulation is left to the existing tools. Once the nominal simulation is configured, the Monte Carlo tool perturbs the input set according to dispersion rules created by the analyst. These rules define the statistical distribution and parameters to be applied to each simulation input. Individual dispersed parameters are combined to create a dispersed set of simulation inputs. The Monte Carlo tool repeatedly executes the core-simulation with the dispersed inputs and stores the results for analysis. The analyst may define conditions on one or more output parameters at which to collect data slices. The tool provides a versatile interface for reviewing output of large Monte Carlo data sets while preserving the capability for detailed examination of individual dispersed trajectories. The Monte Carlo tool described in this paper has proven useful in planning several Crew Exploration Vehicle parachute tests.

Moore, James W.↗
NASA NTRS1998

Airborne/Space-Based Doppler Lidar Wind Sounders Sampling the PBL and Other Regions of Significant Beta and U Inhomogeneities

This final report covers the period from April 1994 through March 1998. The proposed research was organized under four main tasks. Those tasks were: (1) Investigate the vertical and horizontal velocity structures within and adjacent to thin and subvisual cirrus; (2) Investigate the lowest 1 km of the PBL and develop algorithms for processing pulsed Doppler lidar data obtained from single shots into regions of significant inhomogeneities in Beta and U; (3) Participate in OSSEs including those designed to establish shot density requirements for meso-gamma scale phenomena with quasi-persistent locations (e.g., jets, leewaves, tropical storms); and (4) Participate in the planning and execution of an airborne mission to measure winds with a pulsed CO2 Doppler lidar. Over the four year period of this research contract, work on all four tasks has yielded significant results which have led to 38 professional presentations (conferences and publications) and have been folded into the science justification for an approved NASA space mission, SPARCLE (SPAce Readiness Coherent Lidar Experiment), in 2001. Also this research has, through Task 4, led to a funded proposal to work directly on a NASA field campaign, CAMEX III, in which an airborne Doppler wind lidar will be used to investigate the cloud-free circulations near tropical storms. Monthly progress reports required under this contract are on file. This final report will highlight major accomplishments, including some that were not foreseen in the original proposal. The presentation of this final report includes this written document as well as material that is better presented via the internet (web pages). There is heavy reference to appended papers and documents. Thus, the main body of the report will serve to summarize the key efforts and findings.

Emmitt, Dave↗
NASA NTRS2011

Flight Planning Branch Space Shuttle Lessons Learned

Planning products and procedures that allow the mission flight control teams and the astronaut crews to plan, train and fly every Space Shuttle mission have been developed by the Flight Planning Branch at the NASA Johnson Space Center. As the Space Shuttle Program ends, lessons learned have been collected from each phase of the successful execution of these Shuttle missions. Specific examples of how roles and responsibilities of console positions that develop the crew and vehicle attitude timelines will be discussed, as well as techniques and methods used to solve complex spacecraft and instrument orientation problems. Additionally, the relationships and procedural hurdles experienced through international collaboration have molded operations. These facets will be explored and related to current and future operations with the International Space Station and future vehicles. Along with these important aspects, the evolution of technology and continual improvement of data transfer tools between the shuttle and ground team has also defined specific lessons used in the improving the control teams effectiveness. Methodologies to communicate and transmit messages, images, and files from Mission Control to the Orbiter evolved over several years. These lessons have been vital in shaping the effectiveness of safe and successful mission planning that have been applied to current mission planning work in addition to being incorporated into future space flight planning. The critical lessons from all aspects of previous plan, train, and fly phases of shuttle flight missions are not only documented in this paper, but are also discussed as how they pertain to changes in process and consideration for future space flight planning.

Price, Jennifer B.↗
NASA NTRS2004

A DMAP Program for the Selection of Accelerometer Locations in MSC/NASTRAN

A new program for selecting sensor locations has been written in the DMAP (Direct Matrix Abstraction Program) language of MSC/NASTRAN. The program implements the method of Effective Independence for selecting sensor locations, and is executed within a single NASTRAN analysis as a "rigid format alter" to the normal modes solution sequence (SOL 103). The user of the program is able to choose among various analysis options using Case Control and Bulk Data entries. Algorithms tailored for the placement of both uni-axial and tri- axial accelerometers are available, as well as several options for including the model s mass distribution into the calculations. Target modes for the Effective Independence analysis are selected from the MSC/NASTRAN ASET modes calculated by the "SOL 103" solution sequence. The initial candidate sensor set is also under user control, and is selected from the ASET degrees of freedom. Analysis results are printed to the MSCINASTRAN output file (*.f06), and may include the current candidate sensors set, and their associated Effective Independence distribution, at user specified iteration intervals. At the conclusion of the analysis, the model is reduced to the final sensor set, and frequencies and orthogonality checks are printed. Example results are given for a pre-test analysis of NASA s five-segment solid rocket booster modal test.

Peck, Jeff↗
NASA NTRS1997

A Parallel Pipelined Renderer for the Time-Varying Volume Data

This paper presents a strategy for efficiently rendering time-varying volume data sets on a distributed-memory parallel computer. Time-varying volume data take large storage space and visualizing them requires reading large files continuously or periodically throughout the course of the visualization process. Instead of using all the processors to collectively render one volume at a time, a pipelined rendering process is formed by partitioning processors into groups to render multiple volumes concurrently. In this way, the overall rendering time may be greatly reduced because the pipelined rendering tasks are overlapped with the I/O required to load each volume into a group of processors; moreover, parallelization overhead may be reduced as a result of partitioning the processors. We modify an existing parallel volume renderer to exploit various levels of rendering parallelism and to study how the partitioning of processors may lead to optimal rendering performance. Two factors which are important to the overall execution time are re-source utilization efficiency and pipeline startup latency. The optimal partitioning configuration is the one that balances these two factors. Tests on Intel Paragon computers show that in general optimal partitionings do exist for a given rendering task and result in 40-50% saving in overall rendering time.

Chiueh, Tzi-Cker↗
NASA NTRSDate not supplied

Automating Maneuvers: Considerations for Collision Avoidance

As more space operators implement large constellations of spacecraft, automating orbit maintenance maneuvers becomes a key feature of their operations concept to ensure that the workload is manageable. However the practice of performing a maneuver without sharing the plan with other nearby spacecraft causes a risk that two spacecraft will collide, not only destroying the spacecraft involved, but creating debris that will affect all other spacecraft using that orbit regime. In order to share the maneuver plan, a predicted ephemeris file containing the maneuver must be sent to a central authority to screen against predicted trajectories of all other on-orbit objects to determine where and when close approaches may occur that need to be mitigated. Currently the screening authority used by US operators is the 19th Space Defense Squadron. However the conjunction screening process in use by the 19th was developed over 30 years ago and was not designed with automation in mind, so screenings are performed once every 8 hours, meaning that spacecraft using automated maneuvering need to allow 16 hours to share their maneuver plan via the screening process. Many operators assume that automated maneuver planning must be real-time; however this time between planning and execution to allow for screening is possible if planned for during system design. In an effort to speed up the screening process, NASA has developed a prototype system for performing near-real-time screenings. This prototype system was necessitated to support the NASA Starling mission, a constellation of 4 cubesats that planned to fly at the same altitude as the SpaceX Starlink constellation, both performing automated maneuvering. Without screening of the planned maneuvers, the two constellations risked a collision. Once converted from a prototype to an operational system, this capability will greatly help smallsats, for example those that are planning to test propulsive capabilities, by allowing fast turnaround feedback to ensure safety form collision with other objects. This paper describes the existing CA process, the prototype real-time capability, and results from the experiment that tested the prototype.

Matthew Hejduk↗
DOE OSTI2022

Enabling machine learning-ready HPC ensembles with Merlin

With the growing complexity of computational and experimental facilities, many scientific researchers are turning to machine learning (ML) techniques to analyze large scale ensemble data. With complexities such as multi-component workflows, heterogeneous machine architectures, parallel file systems, and batch scheduling, care must be taken to facilitate this analysis in a high performance computing (HPC) environment. Here, we present Merlin, a workflow framework to enable large ML-friendly ensembles of scientific HPC simulations. By augmenting traditional HPC with distributed compute technologies, Merlin aims to lower the barrier for scientific subject matter experts to incorporate ML into their analysis. As a producer–consumer workflow model, Merlin enables multi-machine, cross-batch job, dynamically allocated yet persistent workflows capable of utilizing surge-compute resources. Key features of Merlin are a flexible HPC-centric interface, low per-task overhead, multi-tiered fault recovery, and a hierarchical sampling algorithm that allows for $\mathscr{O}$(N) task execution and $\mathscr{O}$(N ln N) task queuing to ensembles of millions of tasks. In addition to Merlin’s design, we test the algorithm’s performance in an HPC center and demonstrate the ability to enqueue 40 million simulations in 100 s, with a 30 millisecond per-task overhead that is independent of ensemble size. Finally, we describe some example applications that Merlin has enabled on leadership-class HPC resources, such as the ML-augmented optimization of nuclear fusion experiments and the calibration of infectious disease models to study the progression of and possible mitigation strategies for COVID-19.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2014

Addressing the Hard Factors for Command File Errors by Probabilistic Reasoning

Command File Errors (CFE) are managed using standard risk management approaches at the Jet Propulsion Laboratory. Over the last few years, more emphasis has been made on the collection, organization, and analysis of these errors for the purpose of reducing the CFE rates. More recently, probabilistic modeling techniques have been used for more in depth analysis of the perceived error rates of the DAWN mission and for managing the soft factors in the upcoming phases of the mission. We broadly classify the factors that can lead to CFE's as soft factors, which relate to the cognition of the operators and hard factors which relate to the Mission System which is composed of the hardware, software and procedures used for the generation, verification & validation and execution of commands. The focus of this paper is to use probabilistic models that represent multiple missions at JPL to determine the root cause and sensitivities of the various components of the mission system and develop recommendations and techniques for addressing them. The customization of these multi-mission models to a sample interplanetary spacecraft is done for this purpose.

Meshkat, Leila↗
NASA NTRS1991

Transparent process migration: Design alternatives and the Sprite implementation

The Sprite operating system allows executing processes to be moved between hosts at any time. We use this process migration mechanism to offload work onto idle machines, and also to evict migrated processes when idle workstations are reclaimed by their owners. Sprite's migration mechanism provides a high degree of transparency both for migrated processes and for users. Idle machines are identified, and eviction is invoked, automatically by daemon processes. On Sprite it takes up to a few hundred milliseconds on SPARCstation 1 workstations to perform a remote exec, while evictions typically occur in a few seconds. The pmake program uses remote invocation to invoke tasks concurrently. Compilations commonly obtain speedup factors in the range of three to six; they are limited primarily by contention for centralized resources such as file servers. CPU-bound tasks such as simulations can make more effective use of idle hosts, obtaining as much as eight-fold speedup over a period of hours. Process migration has been in regular service for over two years.

Douglis, Fred↗
NASA NTRS2014

Terminal Area Simulation System User's Guide - Version 10.0

The Terminal Area Simulation System (TASS) is a three-dimensional, time-dependent, large eddy simulation model that has been developed for studies of wake vortex and weather hazards to aviation, along with other atmospheric turbulence, and cloud-scale weather phenomenology. This document describes the source code for TASS version 10.0 and provides users with needed documentation to run the model. The source code is programed in Fortran language and is formulated to take advantage of vector and efficient multi-processor scaling for execution on massively-parallel supercomputer clusters. The code contains different initialization modules allowing the study of aircraft wake vortex interaction with the atmosphere and ground, atmospheric turbulence, atmospheric boundary layers, precipitating convective clouds, hail storms, gust fronts, microburst windshear, supercell and mesoscale convective systems, tornadic storms, and ring vortices. The model is able to operate in either two- or three-dimensions with equations numerically formulated on a Cartesian grid. The primary output from the TASS is time-dependent domain fields generated by the prognostic equations and diagnosed variables. This document will enable a user to understand the general logic of TASS, and will show how to configure and initialize the model domain. Also described are the formats of the input and output files, as well as the parameters that control the input and output.

Switzer, George F.↗
NASA NTRS2011

Project Report: Automatic Sequence Processor Software Analysis

The Mission Planning and Sequencing (MPS) element of Multi-Mission Ground System and Services (MGSS) provides space missions with multi-purpose software to plan spacecraft activities, sequence spacecraft commands, and then integrate these products and execute them on spacecraft. Jet Propulsion Laboratory (JPL) is currently is flying many missions. The processes for building, integrating, and testing the multi-mission uplink software need to be improved to meet the needs of the missions and the operations teams that command the spacecraft. The Multi-Mission Sequencing Team is responsible for collecting and processing the observations, experiments and engineering activities that are to be performed on a selected spacecraft. The collection of these activities is called a sequence and ultimately a sequence becomes a sequence of spacecraft commands. The operations teams check the sequence to make sure that no constraints are violated. The workflow process involves sending a program start command, which activates the Automatic Sequence Processor (ASP). The ASP is currently a file-based system that is comprised of scripts written in perl, c-shell and awk. Once this start process is complete, the system checks for errors and aborts if there are any; otherwise the system converts the commands to binary, and then sends the resultant information to be radiated to the spacecraft.

sequencing↗
NASA NTRS1999

Potential Flow Theory and Operation Guide for the Panel Code PMARC

The theoretical basis for PMARC, a low-order panel code for modeling complex three-dimensional bodies, in potential flow, is outlined. PMARC can be run on a wide variety of computer platforms, including desktop machines, workstations, and supercomputers. Execution times for PMARC vary tremendously depending on the computer resources used, but typically range from several minutes for simple or moderately complex cases to several hours for very large complex cases. Several of the advanced features currently included in the code, such as internal flow modeling, boundary layer analysis, and time-dependent flow analysis, including problems involving relative motion, are discussed in some detail. The code is written in Fortran77, using adjustable-size arrays so that it can be easily redimensioned to match problem requirements and computer hardware constraints. An overview of the program input is presented. A detailed description of the input parameters is provided in the appendices. PMARC results for several test cases are presented along with analytic or experimental data, where available. The input files for these test cases are given in the appendices. PMARC currently supports plotfile output formats for several commercially available graphics packages. The supported graphics packages are Plot3D, Tecplot, and PmarcViewer.

Ashby, Dale L.↗
NASA NTRS2011

ISS Operations Cost Reductions Through Automation of Real-Time Planning Tasks

In 2007 the Johnson Space Center s Mission Operations Directorate (MOD) management team challenged their organizations to find ways to reduce the cost of operations for supporting the International Space Station (ISS) in the Mission Control Center (MCC). Each MOD organization was asked to define and execute projects that would help them attain cost reductions by 2012. The MOD Operations Division Flight Planning Branch responded to this challenge by launching several software automation projects that would allow them to greatly improve console operations and reduce ISS console staffing and intern reduce operating costs. These tasks ranged from improving the management and integration mission plan changes, to automating the uploading and downloading of information to and from the ISS and the associated ground complex tasks that required multiple decision points. The software solutions leveraged several different technologies including customized web applications and implementation of industry standard web services architecture; as well as engaging a previously TRL 4-5 technology developed by Ames Research Center (ARC) that utilized an intelligent agent-based system to manage and automate file traffic flow, archive data, and generate console logs. These projects to date have allowed the MOD Operations organization to remove one full time (7 x 24 x 365) ISS console position in 2010; with the goal of eliminating a second full time ISS console support position by 2012. The team will also reduce one long range planning console position by 2014. When complete, these Flight Planning Branch projects will account for the elimination of 3 console positions and a reduction in staffing of 11 engineering personnel (EP) for ISS.

Hall, Timothy A.↗