Results for “scheduling software” — Page 17

NASA NTRS1990

SURE (Science User Resource Expert): A science planning and scheduling assistant for a resource based environment

SURE (Science User Resource Expert) is one of three components that compose the SURPASS (Science User Resource Planning and Scheduling System). This system is a planning and scheduling tool which supports distributed planning and scheduling, based on resource allocation and optimization. Currently SURE is being used within the SURPASS by the UARS (Upper Atmospheric Research Satellite) SOLSTICE instrument to build a daily science plan and activity schedule and in a prototyping effort with NASA GSFC to demonstrate distributed planning and scheduling for the SOLSTICE II instrument on the EOS platform. For the SOLSTICE application the SURE utilizes a rule-based system. Development of a rule-based program using Ada CLIPS as opposed to using conventional programming, allows for capture of the science planning and scheduling heuristics in rules and provides flexibility in inserting or removing rules as the scientific objectives and mission constraints change. The SURE system's role as a component in the SURPASS, the purpose of the SURE planning and scheduling tool, the SURE knowledge base, and the software architecture of the SURE component are described.

Thalman, Nancy E.↗

NASA NTRS1991

Design and implementation of Ada programs to facilitate automated testing

An automated method utilized to test the software components of COMPASS, an interactive computer aided scheduling system, is presented. Each package of this system introduces a private type, and works to construct instances of that type, along with read and write routines for that type. Generic procedures that can generate test drivers for these functions are given and show how the test drivers can read from a test data file the functions to call, the arguments for those functions, what the anticipated result should be, and whether an exception should be raised for the function given the arguments.

Dean, Jack↗

NASA NTRS1998

Comparison of Human Modeling Tools for Efficiency of Prediction of EVA Tasks

Design of ExtraVehicular Activity (EVA) interfaces for International Space Station is important to successful assembly. This is highlighted by the recent rise in the estimate of time required for EVA during the assembly to 900 hours. The traditional method of evaluating EVA design is examination of mockups in neutral buoyancy testing. While effective, this is costly. Any tools for streamlining this process have positive cost and schedule implications for Station design. The human modelling software package Jack has been shown to be a useful tool in computer-aided design of space hardware requiring actuation in EVA. The package has been used to aid in the design of flight hardware for a Station Assembly Mission; evaluation was based on comparison of the computer simulations with neutral buoyancy simulations. When used to predict the feasibility of tasks, the software was found to be effective for reach and visibility evaluation. Some limitations have been encountered in prediction of work clearances. Another human simulator is currently being evaluated using the same hardware and comparisons to the same Neutral Buoyancy simulations. Preliminary results for ERGO, which is derived from robotics software, indicate similar strengths and weaknesses.

Dischinger, H. Charles, Jr.↗

NASA NTRS1988

Programmable control means for providing safe and controlled medication infusion

An implantable programmable infusion pump (IPIP) is disclosed and generally includes: a fluid reservoir filled with selected medication; a pump for causing a precise volumetric dosage of medication to be withdrawn from the reservoir and delivered to the appropriate site within the body; and, a control means for actuating the pump in a safe and programmable manner. The control means includes a microprocessor, a permanent memory containing a series of fixed software instructions, and a memory for storing prescription schedules, dosage limits and other data. The microprocessor actuates the pump in accordance with programmable prescription parameters and dosage limits stored in the memory. A communication link allows the control means to be remotely programmed. The control means incorporates a running integral dosage limit and other safety features which prevent an inadvertent or intentional medication overdose. The control means also monitors the pump and fluid handling system and provides an alert if any improper or potentially unsafe operation is detected.

Fischell, Robert E.↗

NASA NTRS2014

Technology Estimating 2: A Process to Determine the Cost and Schedule of Space Technology Research and Development

As a leader in space technology research and development, NASA is continuing in the development of the Technology Estimating process, initiated in 2012, for estimating the cost and schedule of low maturity technology research and development, where the Technology Readiness Level is less than TRL 6. NASA' s Technology Roadmap areas consist of 14 technology areas. The focus of this continuing Technology Estimating effort included four Technology Areas (TA): TA3 Space Power and Energy Storage, TA4 Robotics, TA8 Instruments, and TA12 Materials, to confine the research to the most abundant data pool. This research report continues the development of technology estimating efforts completed during 2013-2014, and addresses the refinement of parameters selected and recommended for use in the estimating process, where the parameters developed are applicable to Cost Estimating Relationships (CERs) used in the parametric cost estimating analysis. This research addresses the architecture for administration of the Technology Cost and Scheduling Estimating tool, the parameters suggested for computer software adjunct to any technology area, and the identification of gaps in the Technology Estimating process.

Cole, Stuart K.↗

NASA NTRS2017

SPHERES and Astrobee: Space Station Robotic Free Flyers

Free-flying space robots can be used when humans are present to off-load routine work, to increase astronaut productivity, and to handle contingencies. The International Space Station (ISS), for example, is a continuously manned orbital laboratory the size of a large house, which contains many thousands of inventory items and hundreds of diverse payloads and experiments - all of which have to be managed by 6 person crew. To help with this, NASA is developing and testing robotic free-flyers on the ISS. SPHERES (Synchronized Position Hold, Engage, Reorient, Experimental Satellites) is an ISS facility with three nano-satellites designed to research estimation, control, and autonomy algorithms. SPHERES are volleyball-sized, have their own power, propulsion and navigation systems, and work on the ISS under astronaut supervision. For more than 10 years, NASA has made SPHERES available to other U.S. government agencies, schools, commercial companies and students as a platform for science, technology development, and education. SPHERES will soon be succeeded by the new Astrobee free-flying robot. Astrobee builds on the success of SPHERES, but in addition to research, the robot will also be used for housekeeping and monitoring duties without astronaut supervision. Astrobee makes extensive use of open-source (the complete software stack is available on GitHub) and is scheduled to be installed on the ISS in late Spring 2018.

Benavides, Jose V.↗

NASA NTRS1991

Autonomous power system intelligent diagnosis and control

The Autonomous Power System (APS) project at NASA Lewis Research Center is designed to demonstrate the abilities of integrated intelligent diagnosis, control, and scheduling techniques to space power distribution hardware. Knowledge-based software provides a robust method of control for highly complex space-based power systems that conventional methods do not allow. The project consists of three elements: the Autonomous Power Expert System (APEX) for fault diagnosis and control, the Autonomous Intelligent Power Scheduler (AIPS) to determine system configuration, and power hardware (Brassboard) to simulate a space based power system. The operation of the Autonomous Power System as a whole is described and the responsibilities of the three elements - APEX, AIPS, and Brassboard - are characterized. A discussion of the methodologies used in each element is provided. Future plans are discussed for the growth of the Autonomous Power System.

Ringer, Mark J.↗

NASA NTRS1991

Autonomous Power System intelligent diagnosis and control

The Autonomous Power System (APS) project at NASA Lewis Research Center is designed to demonstrate the abilities of integrated intelligent diagnosis, control, and scheduling techniques to space power distribution hardware. Knowledge-based software provides a robust method of control for highly complex space-based power systems that conventional methods do not allow. The project consists of three elements: the Autonomous Power Expert System (APEX) for fault diagnosis and control, the Autonomous Intelligent Power Scheduler (AIPS) to determine system configuration, and power hardware (Brassboard) to simulate a space based power system. The operation of the Autonomous Power System as a whole is described and the responsibilities of the three elements - APEX, AIPS, and Brassboard - are characterized. A discussion of the methodologies used in each element is provided. Future plans are discussed for the growth of the Autonomous Power System.

Ringer, Mark J.↗

NASA NTRS2019

Schedule Factors Associated with the Use of Controlled Rest in a Long-Haul Airline

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. Forty-four pilots wore actiwatches and filled in an application-based sleep/work diary for approximately 2 weeks. After merging sleep diary, actigraphy, and schedule data, complete records were analyzed from 240 flights. Sleep was estimated during CR intervals using the Philips Actiware 6.0.9 (Bend, OR) software with wake threshold set to medium. Timing of sleep periods and flight schedules were analyzed relative to home-base time. A mixed-effects binary logistics regression was used to analyze the impact of schedule factors on CR. Preliminary analyses revealed that CR was taken on 45% (n=107) of flights. Average sleep duration within these rest periods was estimated as 24.8 ± 16.1 minutes. CR was more frequent on return flights (arriving at home-base; 58%, n=69) vs. outbound flights (departing from home-base, 31%, n=38; p<0.001). There was no difference for direction of travel (eastbound: 49%, n= 56; westbound: 40%, n= 44; northbound/southbound: 50%, n=7; p=0.272). CR was more frequent on 2-pilot flights (62%, n=81) compared to augmented crew flights (24%, n=26; p<0.001). Of note, 21% (n=23) of augmented flights contained both CR and Bunk Rest. CR was more frequent on flights <10h duration (<10h: 59%, n=78; >10h: 27%, n=29; p<0.001). Flights departing between 12:00h-19:59h (25%, n=23; p<0.026) had the lowest frequency of CR. Data from this airline show that CR is most commonly used as a countermeasure to sleepiness on return, unaugmented, <10h duration, and nighttime flights. The direction of travel did not influence the use of CR. Future studies are required to determine generalizability of these results to other airlines.

Hilditch, Cassie↗

NASA NTRS1994

A scheduling and diagnostic system for scientific satellite GEOTAIL using expert system

The Intelligent Satellite Control Software (ISACS) for the geoMagnetic tail observation satellite named GEOTAIL (launched in July 1992) has been successfully developed. ISACS has made it possible by applying Artificial Intelligence (AI) technology including an expert system to autonomously generate a tracking schedule, which originally used to be conducted manually. Using ISACS, a satellite operator can generate a maximum four day period of stored command stream autonomously and can easily confirm its safety. The ISACS system has another function -- to diagnose satellite troubles and to suggest necessary remedies. The workload of satellite operators has drastically been reduced since ISACS has been introduced into the operations of GEOTAIL.

Nakatani, I↗

NASA NTRS2017

Fast Optimization for Aircraft Descent and Approach Trajectory

We address problem of on-line scheduling of the aircraft descent and approach trajectory. We formulate a general multiphase optimal control problem for optimization of the descent trajectory and review available methods of its solution. We develop a fast algorithm for solution of this problem using two key components: (i) fast inference of the dynamical and control variables of the descending trajectory from the low dimensional flight profile data and (ii) efficient local search for the resulting reduced dimensionality non-linear optimization problem. We compare the performance of the proposed algorithm with numerical solution obtained using optimal control toolbox General Pseudospectral Optimal Control Software. We present results of the solution of the scheduling problem for aircraft descent using novel fast algorithm and discuss its future applications.

Luchinsky, Dmitry G.↗

NASA NTRS1984

Development and analysis of the Software Implemented Fault-Tolerance (SIFT) computer

SIFT (Software Implemented Fault Tolerance) is an experimental, fault-tolerant computer system designed to meet the extreme reliability requirements for safety-critical functions in advanced aircraft. Errors are masked by performing a majority voting operation over the results of identical computations, and faulty processors are removed from service by reassigning computations to the nonfaulty processors. This scheme has been implemented in a special architecture using a set of standard Bendix BDX930 processors, augmented by a special asynchronous-broadcast communication interface that provides direct, processor to processor communication among all processors. Fault isolation is accomplished in hardware; all other fault-tolerance functions, together with scheduling and synchronization are implemented exclusively by executive system software. The system reliability is predicted by a Markov model. Mathematical consistency of the system software with respect to the reliability model has been partially verified, using recently developed tools for machine-aided proof of program correctness.

Goldberg, J.↗

DOE OSTI2020

Radiological Recovery Logistics Tool - 20161

Argonne is building and testing a tool, the Radiological Recovery Logistics Tool (RRLT), that can be used during the response and recovery from a radiological or nuclear incident to effectively allocate appropriate commercial and public works equipment to mitigate, remove, and contain radiological contamination. The requirements for this tool - as well as development of the resulting software - is overseen by a steering committee of stakeholders from DHS's National Urban Security Technology Laboratory (NUSTL), the Federal Emergency Management Agency (FEMA), and the Environmental Protection Agency (EPA). One essential requirement is for RRLT to support the efficient and appropriate allocation of resources for a radiological response. Subsequent discussions between ANL and stakeholders have solidified the nature of this support to include identification of the types of resources to be allocated. The study reported in this paper has both factored fundamental concepts and connections out of this identification process and created a Knowledge Base detailing support goals, response scenarios, and efficacy information on dozens of equipment types. In short, RRLT will dynamically apply these findings to situational conditions surrounding contamination incidents. RRLT's Domain, the model of elements, ideas and relationships with which the tool will work, draws concepts from technical reports and stakeholder vocabularies to connect response goals and scenarios to types of equipment that offer utility towards those goals in those scenarios. RRLT's Knowledge Base will contain details on dozens of equipment types and facilitate the operator's discovery and consumption of these details most pertinent to a dynamically selected subset of goals. The core of its Domain Model is based on a report authored by this team. This report [1] contains a comprehensive list of proposed equipment to accomplish various missions or scenarios that might arise after a large-scale radiological contamination incident in an urban environment or critical infrastructure. The report divides potential response and recovery efforts into five support goals: Survey and monitoring of the contaminated area; Mitigation of received dose to first responders: Decontamination (gross and final) of buildings, vehicles, roadways, parks, and other surfaces: Waste management of solid waste generated during recovery operations: and Containment of wastewater and other waste generated during the response and recovery phases. RRLT's development is driven by use cases. A use case is an intention with which a user approaches the software. Use cases are grouped into delivery increments to schedule development, testing, and presentation to stakeholders. This model partitions the system into seven increments: User Arrival and Authentication, Search and Navigation, Equipment Recommendation, Plan Management, Content Management, and Expanded Access. Once a user 15 authenticated, RRLT will present the user with a dashboard that allows them to explore or search RRLT's content. The dashboard will also include a 'Plan' panel for collecting decisions and relevant observations about an incident at hand to facilitate development of an equipment list. RRLT will offer three general modes of access to items in the knowledge base: - Keyword search for direct discovery of items, - Navigation along predetermined paths from recovery goal towards equipment types, and - Interactive guidance towards equipment types by an autonomous software agent: the Equipment Recommendation Wizard. This presentation will detail progress in the development of the RRLT and also discuss opportunities for those interested in providing feedback on its content and functionality. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗

NASA NTRS2016

Exploring Cognition Using Software Defined Radios for NASA Missions

NASA missions typically operate using a communication infrastructure that requires significant schedule planning with limited flexibility when the needs of the mission change. Parameters such as modulation, coding scheme, frequency, and data rate are fixed for the life of the mission. This is due to antiquated hardware and software for both the space and ground assets and a very complex set of mission profiles. Automated techniques in place by commercial telecommunication companies are being explored by NASA to determine their usability by NASA to reduce cost and increase science return. Adding cognition the ability to learn from past decisions and adjust behavior is also being investigated. Software Defined Radios are an ideal way to implement cognitive concepts. Cognition can be considered in many different aspects of the communication system. Radio functions, such as frequency, modulation, data rate, coding and filters can be adjusted based on measurements of signal degradation. Data delivery mechanisms and route changes based on past successes and failures can be made to more efficiently deliver the data to the end user. Automated antenna pointing can be added to improve gain, coverage, or adjust the target. Scheduling improvements and automation to reduce the dependence on humans provide more flexible capabilities. The Cognitive Communications project, funded by the Space Communication and Navigation Program, is exploring these concepts and using the SCaN Testbed on board the International Space Station to implement them as they evolve. The SCaN Testbed contains three Software Defined Radios and a flight computer. These four computing platforms, along with a tracking antenna system and the supporting ground infrastructure, will be used to implement various concepts in a system similar to those used by missions. Multiple universities and SBIR companies are supporting this investigation. This paper will describe the cognitive system ideas under consideration and the plan for implementing them on platforms, including the SCaN Testbed. Discussions in the paper will include how these concepts might be used to reduce cost and improve the science return for NASA missions.

transmitters receivers↗

DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

DOE OSTI2025

Fiscal Year 2025 Software Quality Assurance Activities for the ARC Software

The continued goal of the ARC SQA project in the Advanced Reactor Technologies program of DOE is to resolve the QA gaps for the ARC software that limit, or prevent, commercialization of the software for industry users. This project started in earnest in fiscal year 2023 which saw the entire code system moved from a SVN repository to a GitLab repository and an associated software quality assurance plan (SQAP) developed and ratified. Most of the QA gaps in the ARC software were identified in collaboration with industry partners and work begin in fiscal year 2023 and continued through 2024 and 2025. The continuous integration testing was extended to RCT, DASSH, and SE2ANL. Minor changes were required to the original continuous integration methodology to make this happen. When full confidence in the methodology is complete, a report will be created to detail the automated regression testing methodology and minor reports will be created to detail the tolerance settings that have been applied to the output for each ARC code. The primary documentation that is missing includes user manuals, user guides, software verification reports, and code coverage assessments. The DASSH, SE2ANL, and SE2RCT manuals were completed this fiscal year. A review of the SE2ANL software identified that it is unrealistic to include updated correlations or different geometry models and it was scheduled for deprecation in favor of DASSH. The SE2ANL manual is essential for SE2RCT as they are similar but quite different in purpose. The only piece of software missing a manual consistent with the source code is NUBOW-3D which is a focus of the coming year. The code coverage report for DIF3D was updated and code coverage reports were created for REBUS, RCT, PERSENT, GAMSRC, and DASSH. Minor coverage issues were identified for all of these pieces of software which did not prevent the work done to transition them to the OneAPI compiler. Because SE2ANL was scheduled for deprecation, it was not transitioned, but it was successfully tested with the OneAPI compiler. This leaves SE2RCT and NUBOW-3D as the only pieces of software not transitioned to OneAPI and further work is required to get SE2RCT to work properly. The SE2RCT software transition will begin early next year while the NUBOW-3D software requires a manual before it can begin. Software verification work has been completed for DIF3D, REBUS, GAMSOR, GAMSRC, VARPOW, EvaluateFlux, and SUMMAR. The PERSENT software verification work was completed this year which was somewhat delayed because of unexpected bugs in the software. The PERSENT manual was updated to detail some of the issues and discuss the bowing reactivity worth feature added in the previous fiscal year. The RCT, DASSH, SE2RCT, and NUBOW-3D software are the only maintained pieces of software without verification reports. The software verification work for DASSH will be a focus in the upcoming fiscal year and it is hoped that some of the test cases created can serve as verification tests for SE2RCT. The NUBOW-3D work will begin when the manual and requirements report are completed. Only minor industry partner software development funds were provided this year. The DASSH software was updated to handle general axial geometry for each assembly and the NUBOW-3D software was updated to incorporate a new input format and better output. Overall progress on resolving the QA gaps has been good this year.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2022

Lifting and Dropping VMs to Dynamically Transition Between Time- and Space-sharing for Large-Scale HPC Systems

As HPC environments increasingly integrate with edge based systems, system architectures will need to handle a broader class of workloads and scheduling requirements. One result of this shift will be the need to simultaneously support bulk-synchronous parallel (BSP) and on-demand service based applications on the same infrastructure. This in turn will require that future resource management approaches utilize both space-shared as well as time-shared resource scheduling strategies. In this work we introduce the concept of "VM-lifting'' (and its inverse "VM-Dropping'') which allows dynamically switching an HPC workload between space-shared and time-shared scheduling regimes. Our work targets co-kernel based HPC system software environments, in which multiple specialized OS kernels execute natively on dedicated physical resource partitions inside a single compute node. With VM-lifting, a native co-kernel can be migrated at runtime to and from locally hosted Virtual Machine Environments due to changing scheduling requirements of the node. This allows an HPC node to be dynamically (re-)configured as either a time-shared Infrastructure-as-a-Service (IaaS) resource or a dedicated space shared resource based on the current workload demands. We have implemented this approach in the context of the Hobbes Exascale System Software stack and have demonstrated that a node can be reconfigured with minimal impact on the running applications.

Gordon, Nick↗

NASA NTRS1974

Study on Spacelab software development and integration concepts

A study was conducted to define the complexity and magnitude of the Spacelab software challenge. The study was based on current Spacelab program concepts, anticipated flight schedules, and ground operation plans. The study was primarily directed toward identifying and solving problems related to the experiment flight application and tests and checkout software executing in the Spacelab onboard command and data management subsystem (CDMS) computers and electrical ground support equipment (EGSE). The study provides a conceptual base from which it is possible to proceed into the development phase of the Software Test and Integration Laboratory (STIL) and establishes guidelines for the definition of standards which will ensure that the total Spacelab software is understood prior to entering development.

Source record↗