SEARCH · Engineering Papers
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.
A standard approach to the development of computer program is provided that covers the file cycle of software development from the planning and requirements phase through the software acceptance testing phase. All documents necessary to provide the required visibility into the software life cycle process are discussed in detail.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
The notion of Timeline has been used informally in spacecraft operations software for some time, but it has not heretofore been formalized and unified either syntactically or semantically. We have formalized and unified the Timeline so that the commonality can be exploited to reduce the cost of developing and using spacecraft operations software. The Timeline can then be used as the common data structure for storage and communications between spacecraft planning and operations software elements.
Future space missions will increasingly depend on integration of complex engineered systems with their human operators. It is important to ensure that the systems that are designed and developed do a good job of supporting the needs of the work domain. Our research investigates methods for needs analysis. We included analysis of work products (plans for regulation of the space station) as well as work processes (tasks using current software), in a case study of Attitude Determination and Control Officers (ADCO) planning work. This allows comparing how well different designs match the structure of the work to be supported. Redesigned planning software that better matches the structure of work was developed and experimentally assessed. The new prototype enabled substantially faster and more accurate performance in plan revision tasks. This success suggests the approach to needs assessment and use in design and evaluation is promising, and merits investigatation in future research.
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.
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.
For all X Computational Physics Division (XCP) software under the Associate Laboratory Directorate for Weapons Physics (ALDX), the Weapons Research Services Secure Networks and Assurance Group (WRS-SNA) manages the software quality assurance (SQA) plan, requirements and guidance with respect to development processes and tools to meet the broader LANL SQA requirements. Each XCP software product is categorized into one of three software types: Safety Software, Non-Safety Risk Significant Software, and Non-Safety Commercially Controlled Software. In 2018, using LANL Form 2033, the MCNP6 code was categorized by the XCP division as Non-Safety Commercially Controlled Software, provided in Appendix A. Using WRSFORM- 0001U, the MCNP6 code was graded as a Medium Impact software product, provided in Appendix B. Given these determinations, the WRS-AD-0010U SQA plan is followed for all MCNP6 developments, documentation and code releases.
The design of a flexible, real-time software architecture for trajectory planning and automatic control of redundant manipulators is described. Emphasis is placed on a technique of designing control systems that are both flexible and robust yet have good real-time performance. The solution presented involves an artificial intelligence algorithm that dynamically reprograms the real-time control system while planning system behavior.
The basic objective of the Space Station (SS) Mission Planning System (MPS) Development Study was to define a baseline Space Station mission plan and the associated hardware and software requirements for the system. A detailed definition of the Spacelab (SL) payload mission planning process and SL Mission Integration Planning System (MIPS) software was derived. A baseline concept was developed for performing SS manned base payload mission planning, and it was consistent with current Space Station design/operations concepts and philosophies. The SS MPS software requirements were defined. Also, requirements for new software include candidate programs for the application of artificial intelligence techniques to capture and make more effective use of mission planning expertise. A SS MPS Software Development Plan was developed which phases efforts for the development software to implement the SS mission planning concept.
Current planning and scheduling software tools for International Space Station (ISS) support different flight controller teams as they plan daily space operations. Planning and scheduling tools capabilities include integrating digitized ISS state inputs, evaluating their expected future states, and propagating them over time. Extensive, custom-made computational models of operations, of objectives, and of operational constraints help ISS flight controllers identify where scheduled events violate constraints. Based on the current capabilities of these tools, this paper proposes how human performance measures could be better integrated into planning and scheduling tools for space mission operations. Future integration of human performance measures could be applied to state inputs (in this case, the astronaut’s state) and to modeling human performance operational constraints & operational objectives (i.e., assigned activities) with parameters that are relevant to human performance measures. Gaps between the state-of-the-art for human performance modeling and planning tools for future exploration missions are identified.
Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system.
The Mars Pathfinder Project GDS Team has designed software that integrates virtual reality technology with existing JPL Navigational Ancillary Information Facilities (NAIF) and image processing capabilities. The result is an interactive, workstation-based application software that provides a high resolution 3-dimensional stereo display of Mars as if it were viewed through the lander camera. This paper describes the architecture and characteristics of this science mission planning software and discusses possible uses of this software by other planetary missions.
Purpose: To quantify the ability of electronic portal imaging device (EPID) dosimetry used during treatment (in vivo) in detecting variations that can occur in the course of patient treatment. Methods: Images of transmitted radiation from in vivo EPID measurements were converted to a 2D planar dose at isocenter and compared to the treatment planning dose using a prototype software system. Using the treatment planning system (TPS), four different types of variability were modeled: overall dose scaling, shifting the positions of the multileaf collimator (MLC) leaves, shifting of the patient position, and changes in the patient body contour. The gamma pass rate was calculated for the modified and unmodified plans and used to construct a receiver operator characteristic (ROC) curve to assess the detectability of the different parameter variations. The detectability is given by the area under the ROC curve (AUC). The TPS was also used to calculate the impact of the variations on the target dose–volume histogram. Results: Nine intensity modulation radiation therapy plans were measured for four different anatomical sites consisting of 70 separate fields. Results show that in vivo EPID dosimetry was most sensitive to variations in the machine output, AUC = 0.70 − 0.94, changes in patient body habitus, AUC = 0.67 − 0.88, and systematic shifts in the MLC bank positions, AUC = 0.59 − 0.82. These deviations are expected to have a relatively small clinical impact [planning target volume (PTV) D{sub 99} change <7%]. Larger variations have even higher detectability. Displacements in the patient’s position and random variations in MLC leaf positions were not readily detectable, AUC < 0.64. The D{sub 99} of the PTV changed by up to 57% for the patient position shifts considered here. Conclusions: In vivo EPID dosimetry is able to detect relatively small variations in overall dose, systematic shifts of the MLC’s, and changes in the patient habitus. Shifts in the patient’s position which can introduce large changes in the target dose coverage were not readily detected.
The early stages of a research program designed to establish an experimental research platform for software engineering are described. Major emphasis is placed on Computer Assisted Software Engineering (CASE). The Poor Man's CASE Tool is based on the Apple Macintosh system, employing available software including Focal Point II, Hypercard, XRefText, and Macproject. These programs are functional in themselves, but through advanced linking are available for operation from within the tool being developed. The research platform is intended to merge software engineering technology with artificial intelligence (AI). In the first prototype of the PMCT, however, the sections of AI are not included. CASE tools assist the software engineer in planning goals, routes to those goals, and ways to measure progress. The method described allows software to be synthesized instead of being written or built.
Purpose: Stereotactic radiosurgery (SRS) treatments using conical collimators can potentially result in gantry collision with treatment table due to limited collision-clear spaces. An in-house software was developed to help the SRS treatment planner mitigate potential SRS conical collimator (Varian Medical System, Palo Alto, CA) collisions with the treatment table. This software was designed to remove treatment re-planning secondary to unexpected collisions. Methods: A BrainLAB SRS ICT Frameless Extension used for SRS treatments in our clinic was mathematically modelled using surface points registered to the 3D co-ordinate space of the couch extension. The surface points are transformed based on the treatment isocenter point and potential collisions are determined in 3D space for couch and gantry angle combinations. The distance between the SRS conical collimators and LINAC isocenter is known. The collision detection model was programmed in MATLAB (Mathwork, Natick, MA) to display graphical plots of the calculations, and the plotted data is used to avoid the gantry and couch angle combinations that would likely result in a collision. We have utilized the cone collision tool for 23 SRS cone treatment plans (8 retrospective and 15 prospective for 10 patients). Results: Twenty one plans strongly agreed with the software tool prediction for collision. However, in two plans, a collision was observed with a 0.5 cm margin when the software predicted no collision. Therefore, additional margins were added to the clearance criteria in the program to achieve a lower risk of actual collisions. Conclusion: Our in-house developed collision check software successfully avoided SRS cone re-planning by 91.3% due to a reduction in cone collisions with the treatment table. Future developments to our software will include a CT image data set based collision prediction model as well as a beam angle optimization tool to avoid normal critical tissues as well as previously treated lesions.
The National Aeronautics and Space Administration is developing the next set of vehicles that will take men back to the moon under the Constellation Program. The Constellation Training Facility (CxTF) is a project in development that will be used to train astronauts, instructors, and flight controllers on the operation of Constellation Program vehicles. It will also be used for procedure verification and validation of flight software and console tools. The CxTF will have simulations for the Crew Exploration Vehicle (CEV), Crew Module (CM), CEV Service Module (SM), Launch Abort System (LAS), Spacecraft Adapter (SA), Crew Launch Vehicle (CLV), Pressurized Cargo Variant CM, Pressurized Cargo Variant SM, Cargo Launch Vehicle, Earth Departure Stage (EDS), and the Lunar Surface Access Module (LSAM). The Facility will consist of part-task and full-task trainers, each with a specific set of mission training capabilities. Part task trainers will be used for focused training on a single vehicle system or set of related systems. Full task trainers will be used for training on complete vehicles and all of its subsystems. Support was provided in both software development and project planning areas of the CxTF project. Simulation software was developed for the hydraulic system of the Thrust Vector Control (TVC) of the ARES I launch vehicle. The TVC system is in charge of the actuation of the nozzle gimbals for navigation control of the upper stage of the ARES I rocket. Also, software was developed using C standards to send and receive data to and from hand controllers to be used in CxTF cockpit simulations. The hand controllers provided movement in all six rotational and translational axes. Under Project Planning & Control, support was provided to the development and maintenance of integrated schedules for both the Constellation Training Facility and Missions Operations Facilities Division. These schedules maintain communication between projects in different levels. The CxTF support provided is one that requires continuous maintenance since the project is still on initial development phases.
Purpose: To develop a flexible and standalone framework for batch calculation of radiobiological dose metrics from Dicom-RT. Methods: Software has been developed which allows (1) The calculation of DVH data from DICOM dose and structure files (DVHgenerator), (2) Calculation of a wide range of radiobiological metrics from this data (CompPlanGui). Both these tools are run via graphical user interface (GUI), making them fast and simple. Part 1 is a new tool which has not previously been published, whilst part 2 is a GUI overlay for the previously published software ‘Comp-Plan’ (Holloway et. al., Medical Dosimetry, 2012), previously reliant on command line interface. The time taken for an experienced user to evaluate a test case of 6 plans with and without CompPlanGUI was quantified. Results: The DVH-generator has been found to be faster, more robust and require far less physical memory then using alternative software solutions for the same purpose. The Comp Plan GUI significantly reduces the amount of time required to set up a base directory, eliminates code crashes arising from typographical errors, and renders the code far more accessible to non-expert users. It took an experienced user of the code around 3 minutes to set up a base directory of 6 plans compared around 8 minutes without, indicating that using CompPlanGUI reduced setup time by over 50%. Conclusion: A standalone GUI based framework has developed which allows for the batch calculation of radiobiological dose metrics directly from Dicom-RT files. As with the original code, this work will be made freely available on request, as well as via matlab file exchange.