Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “scheduling software”

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
All sourcesNASA NTRSDOE OSTI
NASA NTRS2002

Lessons Learned In Developing Multiple Distributed Planning Systems for the International Space Station

The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The "pieces" are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.

Maxwell, Theresa G.↗
NASA NTRS2002

Lessons Learned in Developing Multiple Distributed Planning Systems for the International Space Station

The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The pieces are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.

Maxwell, Theresa G.↗
NASA NTRS2013

Scheduling Operations for Massive Heterogeneous Clusters

High-performance computing (HPC) programming has become increasingly difficult with the advent of hybrid supercomputers consisting of multicore CPUs and accelerator boards such as the GPU. Manual tuning of software to achieve high performance on this type of machine has been performed by programmers. This is needlessly difficult and prone to being invalidated by new hardware, new software, or changes in the underlying code. A system was developed for task-based representation of programs, which when coupled with a scheduler and runtime system, allows for many benefits, including higher performance and utilization of computational resources, easier programming and porting, and adaptations of code during runtime. The system consists of a method of representing computer algorithms as a series of data-dependent tasks. The series forms a graph, which can be scheduled for execution on many nodes of a supercomputer efficiently by a computer algorithm. The schedule is executed by a dispatch component, which is tailored to understand all of the hardware types that may be available within the system. The scheduler is informed by a cluster mapping tool, which generates a topology of available resources and their strengths and communication costs. Software is decoupled from its hardware, which aids in porting to future architectures. A computer algorithm schedules all operations, which for systems of high complexity (i.e., most NASA codes), cannot be performed optimally by a human. The system aids in reducing repetitive code, such as communication code, and aids in the reduction of redundant code across projects. It adds new features to code automatically, such as recovering from a lost node or the ability to modify the code while running. In this project, the innovators at the time of this reporting intend to develop two distinct technologies that build upon each other and both of which serve as building blocks for more efficient HPC usage. First is the scheduling and dynamic execution framework, and the second is scalable linear algebra libraries that are built directly on the former.

Humphrey, John↗
NASA NTRS1991

Solar Constant (SOLCON) Experiment: Ground Support Equipment (GSE) software development

The Solar Constant (SOLCON) Experiment, the objective of which is to determine the solar constant value and its variability, is scheduled for launch as part of the Space Shuttle/Atmospheric Laboratory for Application and Science (ATLAS) spacelab mission. The Ground Support Equipment (GSE) software was developed to monitor and analyze the SOLCON telemetry data during flight and to test the instrument on the ground. The design and development of the GSE software are discussed. The SOLCON instrument was tested during Davos International Solar Intercomparison, 1989 and the SOLCON data collected during the tests are analyzed to study the behavior of the instrument.

Gibson, M. Alan↗
NASA NTRS1997

Lessons Learned from the Clementine Mission

According to BMDO, the Clementine mission achieved many of its technology objectives during its flight to the Moon in early 1994 but, because of a software error, was unable to test the autonomous tracking of a cold target. The preliminary analyses of the returned lunar data suggest that valuable scientific measurements were made on several important topics but that COMPLEX's highest-priority objectives for lunar science were not achieved. This is not surprising given that the rationale for Clementine was technological rather than scientific. COMPLEX lists below a few of the lessons that may be learned from Clementine. Although the Clementine mission was not conceived as a NASA science mission exactly like those planned for the Discovery program, many operational aspects of the two are similar. It is therefore worthwhile to understand the strengths and faults of the Clementine approach. Some elements of the Clementine operation that led to the mission's success include the following: (1) The mission's achievements were the responsibility of a single organization and its manager, which made that organization and that individual accountable for the final outcome; (2) The sponsor adopted a hands-off approach and set a minimum number of reviews (three); (3) The sponsor accepted a reasonable amount of risk and allowed the project team to make the trade-offs necessary to minimize the mission's risks while still accomplishing all its primary objectives; and (4) The development schedule was brief and the agreed-on funding (and funding profile) was adhered to. Among the operational shortcomings of Clementine were the following: (1) An overly ambitious schedule and a slightly lean budget (meaning insufficient time for software development and testing, and leading ultimately to human exhaustion); and (2) No support for data calibration, reduction, and analysis. The principal lesson to be learned in this category is that any benefits from the constructive application of higher risk for lower cost and faster schedule will be lost if the schedule does not allow adequate time for the development of all essential systems or makes no allowance for human frailties. Another lesson to be drawn is that despite its limitations, if judged strictly as a science mission, Clementine attested that significant scientific information can be gathered during a technology-demonstration mission. In the current era of limited funds, when science missions will be infrequent, the opportunity to fly scientific instruments aboard missions whose objectives might be other than science must be seized and, indeed, encouraged. During such opportunities it would be inexcusable to do second-class science. Thus the scientific community must be actively involved in such projects from their initiation.

Source record↗
NASA NTRS1993

(abstract) FASTER -- A Tool for DSN Forecasting and Scheduling

FASTER, the Forecasting And Scheduling Tool for Earth-based Resources is a suite of software tools developed at JPL to aid in the process of allocating DSN 70 and 34 meter antennas and equipment to support deep space satellites and ground based astronomy. FASTER has been designed for use by a diverse user community, including mid-level managers, data entry and analysis teams, and project scheduling personnel. The system helps to automate many of the previously labor intensive tasks and ensure proper analysis and consistency throughout all phases of the allocation process. FASTER implements an interactive environment for both forecasting and scheduling. This paper will discuss technical aspects of the FASTER system, including forecasting and scheduling algorithms, issues related to large scale use of a scheduling and forecasting system, implications to the process in which a forecasting and scheduling system is embedded, and lessons learned and implications to similar systems.

forecasting↗
NASA NTRS1988

Dypas: A dynamic payload scheduler for shuttle missions

Decision and analysis systems have had broad and very practical application areas in the human decision making process. These software systems range from the help sections in simple accounting packages, to the more complex computer configuration programs. Dypas is a decision and analysis system that aids prelaunch shutlle scheduling, and has added functionality to aid the rescheduling done in flight. Dypas is written in Common Lisp on a Symbolics Lisp machine. Dypas differs from other scheduling programs in that it can draw its knowledge from different rule bases and apply them to different rule interpretation schemes. The system has been coded with Flavors, an object oriented extension to Common Lisp on the Symbolics hardware. This allows implementation of objects (experiments) to better match the problem definition, and allows a more coherent solution space to be developed. Dypas was originally developed to test a programmer's aptitude toward Common Lisp and the Symbolics software environment. Since then the system has grown into a large software effort with several programmers and researchers thrown into the effort. Dypas is currently using two expert systems and three inferencing procedures to generate a many object schedule. The paper will review the abilities of Dypas and comment on its functionality.

Davis, Stephen↗
NASA NTRSDate not supplied

Controlled Rest: Investigating the Use of an In-Flight Sleepiness Countermeasure

INTRODUCTION: Sleepiness is commonly reported amongst commercial airline pilots and is recognized as a safety risk due to its impact on performance. Controlled Rest (CR) refers to a short, voluntary nap opportunity taken by pilots on the flight deck as a countermeasure to unanticipated sleepiness in flight. This study explores the profile of CR use in a long-haul commercial airline. METHODS: Forty-four pilots filled in an application-based sleep/work diary and wore actiwatches for approximately 2 weeks. Complete data sets from 239 flights including sleep diaries, actigraphy, and schedules were merged and analyzed. Sleep diary entries were used to set CR intervals in the actigraphy software, which was then used to predict sleep within these intervals. All time-stamps of sleep periods and flight schedules were adjusted for home-base time of the pilots. Pearson Correlations were used to assess the influence of pilot demographics on CR use. A mixed-effects logistic regression was used to analyze the impact of schedule factors on CR. RESULTS: Pilots reported taking CR on 46% (n=110) of observed flights. Average CR attempt duration was 43.1 ± 11.0 minutes. Eighty-percent (n=106/133) of all CR attempts were estimated by actigraphy to have successfully achieved sleep with an average sleep duration during successful rest periods of 31.7 ± 12.2 minutes. Captains reported taking CR on 38% of flights (n=39/102), compared to First Officers reporting 52% (n=71/137) of flights with CR (p=0.131). Age, experience, BMI, and sleep need were not associated with the percentage of flights with CR (all p>0.244). The following schedule factors were associated with a higher frequency of CR: night (55%, n=76) vs. day flights (34%, n=34); <10h (63%, n=80) vs. >10h duration flights (27%, n=30); return (60%, n=71) vs. outbound flights (33%, n=39); and 2-pilot (69%, n=83) vs. >2-pilot flights (23%, n=27) (all p≤0.001). There was a trend for more CR on eastbound flights, but this was not significant (eastbound: 51%, n= 57; westbound: 40%, n= 44; p=0.059). Of note, 22% (n=26) of augmented flights (>2-pilots) contained both CR and Bunk Rest (in a designated rest facility). DISCUSSION: Data from this airline show that pilots commonly use CR to mitigate sleepiness in-flight, especially on flights <10h duration and during home-base nighttime flights. Future studies are required to determine generalizability of these results to other airlines.

sleepiness↗
NASA NTRS1982

Software and system level tests of a test flight mercury ion thruster subsystem

A U.S. Air Force technology spacecraft flight is scheduled to carry an Ion Auxiliary Propulsion System (IAPS) as part of its experimental payload. This paper presents the results of the successful flight-software qualification and system-level tests which were performed on IAPS. The software tests were performed with an operating engineering model ion thruster and power processing unit, and failure/off-normal recovery modes, operation with and without temperature telemetry from the thruster vaporizers, and with closed-loop control or fixed setpoint operation of the thruster vaporizers. The system-level tests cover a wide range of thermal and operating conditions with the entire system exposed to a simulated space environment.

Robson, R. R.↗
NASA NTRS1996

Software Engineering Technology Infusion Within NASA

Abstract technology transfer is of crucial concern to both government and industry today. In this paper, several software engineering technologies used within NASA are studied, and the mechanisms, schedules, and efforts at transferring these technologies are investigated. The goals of this study are: 1) to understand the difference between technology transfer (the adoption of a new method by large segments of an industry) as an industry-wide phenomenon and the adoption of a new technology by an individual organization (called technology infusion); and 2) to see if software engineering technology transfer differs from other engineering disciplines. While there is great interest today in developing technology transfer models for industry, it is the technology infusion process that actually causes changes in the current state of the practice.

Zelkowitz, Marvin V.↗
NASA NTRS1989

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and uplink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗
NASA NTRS1990

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and unlink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗
DOE OSTI2015

Use of collaboration software to improve nuclear power plant outage management

Nuclear Power Plant (NPP) refueling outages create some of the most challenging activities the utilities face in both tracking and coordinating thousands of activities in a short period of time. Other challenges, including nuclear safety concerns arising from atypical system configurations and resource allocation issues, can create delays and schedule overruns, driving up outage costs. Today the majority of the outage communication is done using processes that do not take advantage of advances in modern technologies that enable enhanced communication, collaboration and information sharing. Some of the common practices include: runners that deliver paper-based requests for approval, radios, telephones, desktop computers, daily schedule printouts, and static whiteboards that are used to display information. Many gains have been made to reduce the challenges facing outage coordinators; however; new opportunities can be realized by utilizing modern technological advancements in communication and information tools that can enhance the collective situational awareness of plant personnel leading to improved decision-making. Ongoing research as part of the Light Water Reactor Sustainability Program (LWRS) has been targeting NPP outage improvement. As part of this research, various applications of collaborative software have been demonstrated through pilot project utility partnerships. Collaboration software can be utilized as part of the larger concept of Computer-Supported Cooperative Work (CSCW). Collaborative software can be used for emergent issue resolution, Outage Control Center (OCC) displays, and schedule monitoring. Use of collaboration software enables outage staff and subject matter experts (SMEs) to view and update critical outage information from any location on site or off.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
NASA NTRS2003

Software for Planning Scientific Activities on Mars

Mixed-Initiative Activity Plan Generator (MAPGEN) is a ground-based computer program for planning and scheduling the scientific activities of instrumented exploratory robotic vehicles, within the limitations of available resources onboard the vehicle. MAPGEN is a combination of two prior software systems: (1) an activity-planning program, APGEN, developed at NASA s Jet Propulsion Laboratory and (2) the Europa planner/scheduler from NASA Ames Research Center. MAPGEN performs all of the following functions: Automatic generation of plans and schedules for scientific and engineering activities; Testing of hypotheses (or what-if analyses of various scenarios); Editing of plans; Computation and analysis of resources; and Enforcement and maintenance of constraints, including resolution of temporal and resource conflicts among planned activities. MAPGEN can be used in either of two modes: one in which the planner/scheduler is turned off and only the basic APGEN functionality is utilized, or one in which both component programs are used to obtain the full planning, scheduling, and constraint-maintenance functionality.

Ai-Chang, Mitchell↗
DOE OSTI2023

Stochastic scheduling for commercial building cooling systems: considering uncertainty in zone temperature prediction

Here, this paper presents the first attempt to address the uncertainty in zone temperature prediction with stochastic optimization. The uncertain zone temperature is a process uncertainty and has not been considered in the existing stochastic optimization for building control. To fill this gap, we proposed a novel formulation of stochastic optimization to handle process uncertainty in building control. Specifically, we first examined the accuracy of a typical linear model for predicting zone temperature. We then formulated the scheduling of the building cooling system as a stochastic optimization problem over a 24-hour look-ahead period to minimize the electricity cost of the studied building cooling system. After that, we applied the proposed stochastic load scheduling (SLS) to a direct expansion (DX) cooling system that serves a medium office building. Through simulation with a detailed building energy simulation software, EnergyPlus, we evaluated the operational cost and the thermal comfort compared with a deterministic load scheduling. The operation cost of scheduling was found to vary with the level of zone temperature prediction uncertainty. The proposed SLS can mitigate the impacts of uncertain zone temperature predictions on both operational cost and thermal comfort. The evaluation results indicate that the proposed SLS works better when the uncertainty level is more significant.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
NASA NTRS1989

AdaNET Dynamic Software Inventory (DSI) prototype component acquisition plan

A component acquisition plan contains the information needed to evaluate, select, and acquire software and hardware components necessary for successful completion of the AdaNET Dynamic Software Inventory (DSI) Management System Prototype. This plan will evolve and be applicable to all phases of the DSI prototype development. Resources, budgets, schedules, and organizations related to component acquisition activities are provided. A purpose and description of a software or hardware component which is to be acquired are presented. Since this is a plan for acquisition of all components, this section is not applicable. The procurement activities and events conducted by the acquirer are described and who is responsible is identified, where the activity will be performed, and when the activities will occur for each planned procurement. Acquisition requirements describe the specific requirements and standards to be followed during component acquisition. The activities which will take place during component acquisition are described. A list of abbreviations and acronyms, and a glossary are contained.

Hanley, Lionel↗
NASA NTRS2000

Team Training and Retention of Skills Acquired Above Real Time Training on a Flight Simulator

Above Real-Time Training (ARTT) is the training acquired on a real time simulator when it is modified to present events at a faster pace than normal. The experiments related to training of pilots performed by NASA engineers (Kolf in 1973, Hoey in 1976) and others (Guckenberger, Crane and their associates in the nineties) have shown that in comparison with the real time training (RTT), ARTT provides the following benefits: increased rate of skill acquisition, reduced simulator and aircraft training time, and more effective training for emergency procedures. Two sets of experiments have been performed; they are reported in professional conferences and the respective papers are included in this report. The retention of effects of ARTT has been studied in the first set of experiments and the use of ARTT as top-off training has been examined in the second set of experiments. In ARTT, the pace of events was 1.5 times the pace in RTT. In both sets of experiments, university students were trained to perform an aerial gunnery task. The training unit was equipped with a joystick and a throttle. The student acted as a nose gunner in a hypothetical two place attack aircraft. The flight simulation software was installed on a Universal Distributed Interactive Simulator platform supplied by ECC International of Orlando, Florida. In the first set of experiments, two training programs RTT or ART7 were used. Students were then tested in real time on more demanding scenarios: either immediately after training or two days later. The effects of ARTT did not decrease over a two day retention interval and ARTT was more time efficient than real time training. Therefore, equal test performance could be achieved with less clock-time spent in the simulator. In the second set of experiments three training programs RTT or ARTT or RARTT, were used. In RTT, students received 36 minutes of real time training. In ARTT, students received 36 minutes of above real time training. In RARTT, students received 18 minutes of real time training and 18 minutes of above real time training as top-off training. Students were then tested in real time on more demanding scenarios. The use of ARTT as top-off training after RTT offered better training than RTT alone or ARTT alone. It is, however, suggested that a similar experiment be conducted on a relatively more complex task with a larger sample of participants. Within the proposed duration of the research effort, the setting up of experiments and trial runs on using ARTT for team training were also scheduled but they could not be accomplished due to extra ordinary challenges faced in developing the required software configuration. Team training is, however, scheduled in a future study sponsored by NASA at Tuskegee University.

Ali, Syed Friasat↗
NASA NTRS1991

SEDS1 mission software verification using a signal simulator

The first flight of the Small Expendable Deployer System (SEDS1) is scheduled as the secondary payload of a Delta II in late 1992. The objective of the SEDS1 mission is to collect data to validate the concept of tethered satellite systems and to verify computer simulations used to predict their behavior. A series of tests will be performed to exercise the software modules which make up the Mission Software of the SEDS Data System. These tests will be performed by using a SEDS Signal Simulator to generate signals which will simulate the inputs normally produced by sensors and circuits in the SEDS system. The SEDS Signal Simulator will be used in the debugging and in the formal verification of the SEDS1 Mission Software. The Simulator will not only emulate normal flight conditions but also exercise all modules written to handle anticipated anomalous flight conditions, conditions that would be difficult to reproduce and control with actual SEDS hardware. The simulator will help to expedite software development and to increase the confidence of the users of the Mission Software. With little modification, the Simulator should be useful in the software development of future SEDS flights.

Pierson, William E.↗