Search NASA⌕ Search

SEARCH · Search NASA

Results for “records management requirements”

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 163 records · Page 9

Proceedings of the 7th Annual Precise Time and Time Interval (PTTI) Applications and Planning Meeting

The Proceedings contain the papers presented at the Seventh Annual Precise Time and Time Interval (PTTI) Applications and Planning Meeting and the edited record of the discussion period following each paper. This meeting provided a forum to promote more effective, efficient, economical and skillful applications of PTTI technology to the many problem areas to which PTTI offers solutions. Specifically the purpose of the meeting is to: disseminate, coordinate, and exchange practical information associated with precise time and frequency; acquaint systems engineers, technicians and managers with precise time and frequency technology and its applications; and review present and future requirements for PTTI.

Source record↗

From requirements to acceptance tests

From user requirements definition to accepted software system, the software project management wants to be sure that the system will meet the requirements. For the development of a telecommunication satellites Control Centre, C.N.E.S. has used new rules to make the use of tracing matrix easier. From Requirements to Acceptance Tests, each item of a document must have an identifier. A unique matrix traces the system and allows the tracking of the consequences of a change in the requirements. A tool has been developed, to import documents into a relational data base. Each record of the data base corresponds to an item of a document, the access key is the item identifier. Tracing matrix is also processed, providing automatically links between the different documents. It enables the reading on the same screen of traced items. For example one can read simultaneously the User Requirements items, the corresponding Software Requirements items and the Acceptance Tests.

Baize, Lionel↗

A study of general aviation community noise impact and annoyance

The method involved the selection of three airports which were dominated by aircraft weighing 12,500 lbs or under and which were also undergoing a change relative to utilization. Also, there was interest in airports with different utilization levels so that effect of number of operations could be considered. In addition, there was a requirement to select airports with communities in the surrounding areas which were exposed to aircraft operations noise. Noise annoyance response data was obtained from available sources. These sources included environmental impact statements, interviews with airport managers, noise complaint information, community meetings concerned with projected changes in airport utilization, and social survey data. As a means of objectively assessing the noise impact due to aircraft operations, noise measurement and computer noise modeling determinations were obtained for each airport. Listening quality tape recordings were also obtained.

Mabry, J. E.↗

Overview of Model-Based Systems Engineering Efforts to Evolve the Airspace Research Roadmap

NASA’s Air Traffic Management-Exploration (ATM-X) UAM Airspace Subproject is conducting research that evolves UAM airspace towards a highly automated and operationally flexible system of the future. The complexity of UAM airspace evolution requires a plan to effectively organize, integrate, and communicate NASA’s research and development. The planning tool, called the UAM airspace research roadmap, or just roadmap, is key to the execution of NASA’s UAM airspace research over the next ten years. Implemented through Model-Based Systems Engineering (MBSE) methodology, the roadmap will help to prioritize and coordinate research efforts, and to integrate results that build towards NASA’s research goals of evolving UAM airspace for integration of UAM operations into the National Airspace System (NAS). This paper presents an overview of on-going MBSE efforts to meet these overarching goals. Note: Included mp4 video of presentation included in record, runtime 9 mins 57 secs.

Model-Based Systems Engineering↗

An Overview of the Microgravity Science Glovebox (MSG) Facility and the Research Performed in the MSG on the International Space Station (ISS)

The Microgravity Science Glovebox (MSG) is a double rack facility aboard the International Space Station (ISS) designed for investigation handling. The MSG has been operating on the ISS since July 2002 and is currently located in the Columbus Laboratory Module. The unique design of the facility allows it to accommodate science and technology investigations in a workbench type environment. The facility has an enclosed working volume that is held at a negative pressure with respect to the crew living area. This allows the facility to provide two levels of containment for small parts, particulates, fluids, and gases. This containment approach protects the crew from possible hazardous operations that take place inside the MSG work volume. Research investigations operating inside the MSG are provided a large 255 liter enclosed work space, 1000 watts of dc power via a versatile supply interface (120, 28, +/- 12, and 5 Vdc), 1000 watts of cooling capability, video and data recording and real time downlink, ground commanding capabilities, access to ISS Vacuum Exhaust and Vacuum Resource Systems, and gaseous nitrogen supply. These capabilities make the MSG one of the most utilized facilities on ISS. In fact, the MSG has been used for over 5000 hours of scientific payload operations. MSG investigations involve research in cryogenic fluid management, fluid physics, spacecraft fire safety, materials science, combustion, plant growth, and life support technologies. MSG is an ideal platform for science investigations and research required to advance the technology readiness levels (TRLs) applicable to the Constellation Program. This paper will provide an overview of the MSG facility, a synopsis of the research that has already been accomplished in the MSG, an overview of future investigations currently planned for operation in the MSG, and potential applications of MSG investigations that can provide useful data to the Constellation Program. In addition, this paper will address the role of the MSG facility in the ISS National Lab.

Spivey, Reggie↗

Chandra Space Flight Software: Using Software to Autonomously Operation the Largest and Most Sensitive X-Ray Telescope in the World

Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.

Crumbley, Tim↗

Space Communications Emulation Facility

Establishing space communication between ground facilities and other satellites is a painstaking task that requires many precise calculations dealing with relay time, atmospheric conditions, and satellite positions, to name a few. The Space Communications Emulation Facility (SCEF) team here at NASA is developing a facility that will approximately emulate the conditions in space that impact space communication. The emulation facility is comprised of a 32 node distributed cluster of computers; each node representing a satellite or ground station. The objective of the satellites is to observe the topography of the Earth (water, vegetation, land, and ice) and relay this information back to the ground stations. Software originally designed by the University of Kansas, labeled the Emulation Manager, controls the interaction of the satellites and ground stations, as well as handling the recording of data. The Emulation Manager is installed on a Linux Operating System, employing both Java and C++ programming codes. The emulation scenarios are written in extensible Markup Language, XML. XML documents are designed to store, carry, and exchange data. With XML documents data can be exchanged between incompatible systems, which makes it ideal for this project because Linux, MAC and Windows Operating Systems are all used. Unfortunately, XML documents cannot display data like HTML documents. Therefore, the SCEF team uses XML Schema Definition (XSD) or just schema to describe the structure of an XML document. Schemas are very important because they have the capability to validate the correctness of data, define restrictions on data, define data formats, and convert data between different data types, among other things. At this time, in order for the Emulation Manager to open and run an XML emulation scenario file, the user must first establish a link between the schema file and the directory under which the XML scenario files are saved. This procedure takes place on the command line on the Linux Operating System. Once this link has been established the Emulation manager validates all the XML files in that directory against the schema file, before the actual scenario is run. Using some very sophisticated commercial software called the Satellite Tool Kit (STK) installed on the Linux box, the Emulation Manager is able to display the data and graphics generated by the execution of a XML emulation scenario file. The Emulation Manager software is written in JAVA programming code. Since the SCEF project is in the developmental stage, the source code for this type of software is being modified to better fit the requirements of the SCEF project. Some parameters for the emulation are hard coded, set at fixed values. Members of the SCEF team are altering the code to allow the user to choose the values of these hard coded parameters by inserting a toolbar onto the preexisting GUI.

Hill, Chante A.↗

Evaluation of PBR Spent Fuel Criticality and Dose Rate Compliance for Storage and Transportation

Spent tri-structural isotropic (TRISO)–based fuels have a strong track record in storage and transportation without documented incidents. This work seeks to reduce uncertainty to aid in more informed spent fuel management of TRISO-based fuels by modeling both fresh and spent pebble bed reactor (PBR) fuel and comparing the results to the regulatory standards from 10 CFR 71. SCALE was used for all modeling due to it having fast and accurate methods for handling PBR fuel modeling, as well as having an efficient method for shielding calculations in monaco with automated variance reduction using importance calculations (MAVRIC), which utilizes the consistent adjoint-driven importance sampling (CADIS) and the forward-weighted consistent adjoint-driven importance sampling (FW-CADIS) methods. KENO-VI was used for all criticality calculations, TSUNAMI was used for uncertainty quantification on k-effective, TRITON and the Oak Ridge isotope generation code (ORIGEN) were both used for depletion of the fuel, and MAVRIC was used for shielding calculations. For criticality assessments, this study focused on the requirement that the value of the neutron multiplication factor, k-effective (k-eff), would not exceed a peak value of 0.95, including uncertainty, with 95% confidence. Criticality was initially examined by modeling fresh fuel from three different designs—HTR-10 fuel, PBMR-400 fuel, and demonstration fuel representative of a TRISO-fueled modern high-temperature gas reactor (HTGR) design, henceforth referred to as Demo HTGR—and placing them into various sized containers with conditions described in 10 CFR 71 to quantify the peak k-eff state. When the peak value of 0.95 k-eff was exceeded, mitigation methods were examined in those scenarios. Burnup credit, pebble displacement in areas of strong neutron multiplication, and random pebble replacement using pebbles of various compositions and replacement fractions were examined. In summary, the criticality of PBR fuels can be well accounted for by restricting container size, taking credit for burnup, or by displacing/replacing pebbles. Uncertainty of the k-eff due to nuclear data uncertainties was recorded at ~0.6644%Δk/k, or roughly 664% mil (pcm). The nuclear data–induced uncertainty was relatively small and should not require significant modification in the design to be accounted for. Revisions to the evaluated nuclear data file values have been shown to have a larger impact than nuclear data–induced uncertainty. For dose rate aspects, U.S. Nuclear Regulatory Commission regulations require a maximum dose rate of 10 millirem per hour (mrem/h) at 2 meters. In examining the dose rate behavior of spent PBR fuel, the representative Demo HTGR fuel was modeled exclusively due to it possessing the highest target burnup of the examined fuels. Equilibrium cycle modeling methods were used to produce a higher-fidelity discharge isotopic composition than simple assumptions, such as reflected pebbles. The discharge composition was used as a source term in the fixed-source transport shielding calculations, and dose rates were calculated at 2 m for the shortest possible cooling time. The low concentration of fuel material led to dose rates that were in line with regulatory limits, despite the high burnup when compared to traditional light water reactor fuels. In conclusion, the methods employed in this study would require more work to further verify and validate and are limited to the criticality and dose rate analyses performed.

11 - NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Managing Software Provenance to Enhance Reproducibility in Computational Research

Scientific processes rely on software as an important tool for data acquisition, analysis, and discovery. Over the years, sustainable software development practices have made progress in being considered as an integral component of research. However, management of computation-based scientific studies is often left to individual researchers who design their computational experiments based on personal preferences and the nature of the study. Here, we believe that the quality, efficiency, and reproducibility of computation-based scientific research can be improved by explicitly creating an execution environment that allows researchers to provide a clear record of traceability. This is particularly relevant to complex computational studies in high-performance computing (HPC) environments. In this article, we review the documentation required to maintain a comprehensive record of HPC computational experiments for reproducibility. We also provide an overview of tools and practices that we have developed to perform such studies around Flash-X, a multiphysics scientific software.

97 MATHEMATICS AND COMPUTING↗

Monitoring Phenology as Indicator for Timing of Nutrient Inputs in Northern Gulf Watersheds

Nutrient over-enrichment defined by the U.S. Environmental Protection Agency as the anthropogenic addition of nutrients, in addition to any natural processes, causing adverse effects or impairments to the beneficial uses of a water body has been identified as one of the most significant environmental problems facing sensitive estuaries and coastal waters. Understanding the timing of nutrient inputs into those waters through remote sensing observables helps define monitoring and mitigation strategies. Remotely sensed data products can trace both forcings and effects of the nutrient system from landscape to estuary. This project is focused on extracting nutrient information from the landscape. The timing of nutrients entering coastal waters from the land boundary is greatly influenced by hydrologic processes, but can also be affected by the timing of nutrient additions across the landscape through natural or anthropogenic means. Non-point source nutrient additions to watersheds are often associated with specific seasonal cycles, such as decomposition of organic materials in fall and winter or addition of fertilizers to crop lands in the spring. These seasonal cycles or phenology may in turn be observed through the use of satellite sensors. Characterization of the phenology of various land cover types may be of particular interest in Gulf of Mexico estuarine systems with relatively short pathways between intensively managed systems and the land/estuarine boundary. The objective of this study is to demonstrate the capability of monitoring phenology of specific classes of land, such as agriculture and managed timberlands, at a refined watershed level. The extraction of phenological information from the Moderate Resolution Imaging Spectroradiometer (MODIS) data record is accomplished using analytical tools developed for NASA at Stennis Space Center: the Time Series Product Tool and the Phenological Parameters Estimation Tool. MODIS reflectance data (product MOD09) were used to compute the Normalized Difference Vegetation Index, which is sensitive to changes in vegetation canopies. The project team is working directly with the Mississippi Department of Environmental Quality to understand end-user requirements for this type of information product. Initial focus areas are identification of time frames for pre-plant fertilizer applications (prior to start of season), side-dress fertilizer applications (during rapid green-up), and periods of plant decomposition (during and after senescence). Prototypical maps of phenological stages related to these time frames have been generated for watersheds in the northern Gulf of Mexico. Where feasible, these maps have been compared to existing in situ nutrient monitoring data, but the in situ data is temporally sparse (monthly frequency or less), which makes interpretation challenging. Future work will include integrating effects of rainfall and seeking couplings with estuarine remote sensing.

Ross, Kenton W.↗

Jitter Controller Software

Sinusoidal jitter is produced by simply modulating a clock frequency sinusoidally with a given frequency and amplitude. But this can be expressed as phase jitter, frequency jitter, or cycle-to-cycle jitter, rms or peak, absolute units, or normalized to the base clock frequency. Jitter using other waveforms requires calculating and downloading these waveforms to an arbitrary waveform generator, and helping the user manage relationships among phase jitter crest factor, frequency jitter crest factor, and cycle-to-cycle jitter (CCJ) crest factor. Software was developed for managing these relationships, automatically configuring the generator, and saving test results documentation. Tighter management of clock jitter and jitter sensitivity is required by new codes that further extend the already high performance of space communication links, completely correcting symbol error rates higher than 10 percent, and therefore typically requiring demodulation and symbol synchronization hardware to operating at signal-to-noise ratios of less than one. To accomplish this, greater demands are also made on transmitter performance, and measurement techniques are needed to confirm performance. It was discovered early that sinusoidal jitter can be stepped on a grid such that one can connect points by constant phase jitter, constant frequency jitter, or constant cycle-cycle jitter. The tool automates adherence to a grid while also allowing adjustments off-grid. Also, the jitter can be set by the user on any dimension and the others are calculated. The calculations are all recorded, allowing the data to be rapidly plotted or re-plotted against different interpretations just by changing pointers to columns. A key advantage is taking data on a carefully controlled grid, which allowed a single data set to be post-analyzed many different ways. Another innovation was building a software tool to provide very tight coupling between the generator and the recorded data product, and the operator's worksheet. Together, these allowed the operator to sweep the jitter stimulus quickly along any of three dimensions and focus on the response of the system under test (response was jitter transfer ratio, or performance degradation to the symbol or codeword error rate). Additionally, managing multi-tone and noise waveforms automated a tedious manual process, and provided almost instantaneous decision- making control over test flow. The code was written in LabVIEW, and calls Agilent instrument drivers to write to the generator hardware.

Lansdowne, Chatwin↗

Human Performance Contributions to Safety in Commercial Aviation

Every day in aviation, pilots, air traffic controllers, and other front-line personnel perform countless correct judgments and actions in a variety of operational environments. These judgments and actions are often the difference between an accident and a non-event. Ironically, data on these behaviors are rarely collected or analyzed. Data-driven decisions about safety management and design of safety-critical systems are limited by the available data, which influence how decision makers characterize problems and identify solutions. Large volumes of data are collected on the failures and errors that result in infrequent incidents and accidents, but in the absence of data on behaviors that result in routine successful outcomes, safety management and system design decisions are based on a small sample of nonrepresentative safety data. This assessment aimed to find and document “safety successes” made possible by human operators. With many Aeronautics Research Mission Directorate (ARMD) Programs and Projects focusing on increased automation and autonomy and decreased human involvement, failure to fully consider the human contributions to successful system performance in civil aviation represents a significant risk — a risk that has not been recognized to date. Without understanding how humans contribute to safety, any estimate of predicted safety of autonomous capabilities is incomplete and inherently suspect. Furthermore, understanding the ways in which humans contribute to safety can promote strategic interactions among safety technologies, functions, procedures and the people using them. Without this understanding, the full benefits of an integrated, optimized human/technology or autonomous system will not be realized. Historically, safety has been consistently defined in terms of the occurrence of accidents or recognized risks (i.e., in terms of things that go wrong). These adverse outcomes are explained by identifying their causes, and safety is restored by eliminating or mitigating these causes. An alternative to this approach is to focus on what goes right and identify how to replicate that process. Focusing on the rare cases of failures attributed to “human error” provides little information about why human performance routinely prevents adverse events. Hollnagel has proposed that things go right because people continuously adjust their work to match their operating conditions. These adjustments become increasingly important as systems continue to grow in complexity. Thus, the definition of safety should reflect not only “avoiding things that go wrong” but “ensuring that things go right.” The basis for safety management requires developing an understanding of everyday activities. However, few mechanisms to monitor everyday work exist in the aviation domain, which limits opportunities to learn how designs function in reality. This concept of safety thinking and safety management is reflected in the emerging field of resilience engineering. According to Hollnagel, a system is resilient if it can sustain required operations under expected and unexpected conditions by adjusting its functioning prior to, during, or following changes, disturbances, and opportunities. To explore “positive” behaviors that contribute to resilient performance in commercial aviation, the assessment team examined a range of existing sources of data about pilot and air traffic control (ATC) tower controller performance, including subjective interviews with domain experts and objective aircraft flight data records. These data were used to identify strategies that support resilient performance, methods for exploring and refining those strategies in existing data, and proposed methods for capturing and analyzing new data.

Null, Cynthia H.↗

Monitoring of streamflow in the Verde River by ERTS-1 Data Collection System (DCS)

The Verde River watershed in central Arizona furnishes municipal, industrial, and agricultural water to the Salt River Valley --an area that contains more than half of Arizona's population and about one-fourth of the State's irrigated land. Water-management decisions related to the operation of large multiple-use reservoirs require accurate and continuous monitoring of moisture conditions over large remote areas. The U.S. Geological Survey in cooperation with the Salt River Valley Water Users' Association installed a specially designed gaging station on the Verde River near the town of Camp Verde to evaluate near-real time streamflow data furnished by the ERTS-1 Data Collection System (DCS). On Nov. 3, 1972, the installation was equipped with a Stevens digital water-level recorder, modified for telemetry, and an ERTS-1 data collection platform operating in the digital-parallel mode.

Schumann, H. H.↗

An Overview of NASA’s Catalog of Archived Suborbital Earth Science Investigations (CASEI): Supporting FAIR and Open Access to Airborne and Field Data

Since 2019, NASA’s Airborne Data Management Group (ADMG) within the Interagency Implementation and Advanced Concepts Team (IMPACT) has worked to promote and ensure the discoverability and accessibility of the agency’s non-satellite Earth science observations. A primary component of this effort is the development of NASA’s Catalog of Archived Suborbital Earth Science Investigations (CASEI) and the vetting of key contextual details required to sustain this unique inventory of airborne and field metadata. CASEI provides information on the science objectives motivating data collection, key events/time periods in the observational record aligned with the science objectives, complementary simultaneous observations, programmatic details, and much more. The diverse set of data formats and disciplines served by CASEI have required the implementation of a common data model to organize suborbital observation metadata and efficiently connect appropriate campaigns, platforms, and instruments. The CASEI inventory provides a single entry point for users to search and browse NASA’s airborne and field data archives, regardless of which repository is responsible for their stewardship. This presentation will provide a summary of the motivations for and the development of the CASEI system. Particular attention will be granted to how CASEI facilitates discovery and reuse of these lesser-known NASA data, supporting the Open Science vision and enhancing the return on investments made to collect these unique and varied observations. An up-to-date summary of CASEI inventory content and initial metrics will be provided. Current and future avenues ADMG is pursuing to enhance both CASEI and specific components of suborbital data stewardship at various stages of the data life cycle will also be discussed.

Stephanie M. Wingo↗

2020 Postclosure Groundwater Monitoring and Inspection Report, Central Nevada Test Area, Subsurface Corrective Action Unit 443

This report presents the groundwater monitoring data collected by the U.S. Department of Energy (DOE) Office of Legacy Management (LM) from the Central Nevada Test Area (CNTA), Nevada, Site, Subsurface Corrective Action Unit (CAU) 443 in Nye County, Nevada (Figure 1). The CNTA is the site of an underground nuclear test in 1968 that resulted in residual contamination near the detonation depth of 3200 feet (ft); the contamination requires long-term monitoring. Responsibility for the environmental restoration and long-term monitoring was transferred from DOE’s National Nuclear Security Administration, Nevada Field Office, to LM on October 1, 2006. The environmental restoration and site closure process were completed in 2015 in accordance with the amended 1996 Nevada Federal Facility Agreement and Consent Order (FFACO) (State of Nevada et al. 1996, as amended) and all applicable Nevada Division of Environmental Protection (NDEP) policies and regulations. The Closure Report, Central Nevada Test Area, Subsurface Corrective Action, Unit 443 (DOE 2018), also called the Closure Report, originally was completed in January 2016 and revised in October 2018; it describes LM’s plan for long-term postclosure monitoring. This includes monitoring of the radioisotopes of interest and water elevations, inspecting the site and maintaining the institutional controls (ICs), evaluating and reporting data, and documenting the site’s records and data management processes (DOE 2018).

54 ENVIRONMENTAL SCIENCES↗

Guidance and Control Software Project Data - Volume 2: Development Documents

The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the development documents from the GCS project. Volume 2 contains three appendices: A. Guidance and Control Software Development Specification; B. Design Description for the Pluto Implementation of the Guidance and Control Software; and C. Source Code for the Pluto Implementation of the Guidance and Control Software

Hayhurst, Kelly J.↗

Guidance and Control Software Project Data - Volume 1: Planning Documents

The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the planning documents from the GCS project. Volume 1 contains five appendices: A. Plan for Software Aspects of Certification for the Guidance and Control Software Project; B. Software Development Standards for the Guidance and Control Software Project; C. Software Verification Plan for the Guidance and Control Software Project; D. Software Configuration Management Plan for the Guidance and Control Software Project; and E. Software Quality Assurance Activities.

Hayhurst, Kelly J.↗

Hanford Waste Treatment Plant Low Activity Waste Facility Stack Effluent Monitoring - Sampling Probe Location Qualification Evaluation

The Hanford Tank Waste Treatment and Immobilization Plant low activity waste (LAW) facility stack monitor locations were qualified using scale model stacks to mitigate the risk of identifying that sampling locations do not meet the qualification criteria on the full-scale stack. As required by the American National Standards Institute/Health Physics Society (ANSI/HPS) N13.1-1999 standard, the scale model and its sampling location were geometrically similar to the actual stack and the Reynolds numbers for both the actual and model stacks were >10,000. An additional criterion is that the product of the hydraulic diameter and mean velocity (DV) of the full-scale stack must be between 1/6 DV and 6 DV of the scale model stack tests. Verification tests of the LAW stacks were performed at normal operating conditions. The minimum 1/6 DV value, along with the maximum 6 DV value from the scale model testing determines the range of conditions for which the full-scale stack may be operated and remain in compliance with the stack verification criterion. Based on these DV values, the corresponding stack flow rates for each of the LAW stacks are 815–55,758 scfm for LV-S1, 980–112,078 scfm for LV-S2, 264–22,901 scfm for LV-S3, and 981–79,832 scfm for LV-C2. The remaining criteria for the stack verification to be considered valid involve the flow angle and velocity uniformity results. First, the flow angle at the full-scale stack must be =20°. Second, the velocity uniformity at the full-scale stack must be =20% coefficient of variance (COV). Finally, the velocity uniformity results for the actual and scale model stack tests must agree within 5% COV. These criteria were met through the full-scale stack tests at the LAW facility. Flow angle results were primarily less than 10°, except for one LV-S2 Fan A result, which was 13.2°; all flow angle results were within the =20° criterion. The velocity uniformity results for each test condition ranged between 1.5 COV and 9.2% COV, which were all within the range of the target % COV values from the scale model tests. Based on these stack verification test results, the four LAW filtered exhaust stack sampling locations meet the qualification criteria provided in the ANSI/HPS N13.1-1999 standard for all fan operating configurations. This includes single-fan operating conditions for LV-S1 and LV-S2, dual-fan operations for LV-S3 at both the continuous air monitor and record sampler locations, and both the single-fan as well as the dual-fan operations for LV-C2. Further changes to the system configuration or operating conditions that are outside the bounds described in this report may require additional tests or analyses to determine compliance with the standard.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗