Search NASA⌕ Search

SEARCH · Search NASA

Results for “software cost cost risk”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS1990

Manned versus unmanned - The implications to NASP

The assessment of unmanned approaches to experimental aerospace vehicles in general and to the NASP program in particular is summarized. Technical requirements for NASP demonstration are presented and unmanned options for satisfying requirements are discussed. The X-30 sensitivities to technical requirements are described. A correlation of the NASP program to prior flight test programs, both manned and unmanned, is also presented. It is noted that subscale vehicles may reduce risk by as much as 18 percent for approximately $200 M. It is concluded that half-scale vehicles may reduce program risk by 60 percent, while reducing X-30 costs by 40 percent. Also, an unmanned X-30 will probably cost more than a manned X-30 due to costs associated with additional software development and ground support systems costs.

Wierzbanowski, Theodore↗
NASA NTRS2005

Spinoff 2005

Topics covered include: Lighting the Way for Quicker, Safer Healing; Discovering New Drugs on the Cellular Level; Hydrogen Sensors Boost Hybrids; Today s Models Losing Gas?; 3-D Highway in the Sky; Popping a Hole in High-Speed Pursuits; Monitoring Wake Vortices for More Efficient Airports; From Rockets to Racecars; All-Terrain Intelligent Robot Braves Battlefront to Save Lives; Keeping the Air Clean and Safe--An Anthrax Smoke Detector; Lightning Often Strikes Twice; Technology That's Ready and Able to Inspect Those Cables; Secure Networks for First Responders and Special Forces; Space Suit Spins; Cooking Dinner at Home--From the Office; Nanoscale Materials Make for Large-Scale Applications; NASA s Growing Commitment: The Space Garden; Bringing Thunder and Lightning Indoors; Forty-Year-Old Foam Springs Back With New Benefits; Experiments With Small Animals Rarely Go This Well; NASA, the Fisherman's Friend; Crystal-Clear Communication a Sweet-Sounding Success; Inertial Motion-Tracking Technology for Virtual 3-D; Then Why Do They Call Earth the Blue Planet?; Valiant 'Zero-Valent' Effort Restores Contaminated Grounds; Harnessing the Power of the Sun; Water and Air Measures That Make 'PureSense'; Remote Sensing for Farmers and Flood Watching; Pesticide-Free Device a Fatal Attraction for Mosquitoes Making the Most of Waste Energy Washing Away the Worries About Germs Celestial Software Scratches More Than the Surface A Search Engine That's Aware of Your Needs Fault-Detection Tool Has Companies 'Mining' Own Business; Software to Manage the Unmanageable; Tracking Electromagnetic Energy With SQUIDs; Taking the Risk Out of Risk Assessment; Satellite and Ground System Solutions at Your Fingertips; Structural Analysis Made 'NESSUSary'; Software of Seismic Proportions Promotes Enjoyable Learning; Making a Reliable Actuator Faster and More Affordable; Cost-Cutting Powdered Lubricant NASA s Radio Frequency Bolt Monitor: A Lifetime of Spinoffs Going End to End to Deliver High-Speed Data; Advanced Joining Technology: Simple, Strong, and Secure; Big Results From a Smaller Gearbox; Low-Pressure Generator Makes Cleanrooms Cleaner; and The Space Laser Business Model.

Source record↗
NASA NTRS2013

Web Application Software for Ground Operations Planning Database (GOPDb) Management

A Web application facilitates collaborative development of the ground operations planning document. This will reduce costs and development time for new programs by incorporating the data governance, access control, and revision tracking of the ground operations planning data. Ground Operations Planning requires the creation and maintenance of detailed timelines and documentation. The GOPDb Web application was created using state-of-the-art Web 2.0 technologies, and was deployed as SaaS (Software as a Service), with an emphasis on data governance and security needs. Application access is managed using two-factor authentication, with data write permissions tied to user roles and responsibilities. Multiple instances of the application can be deployed on a Web server to meet the robust needs for multiple, future programs with minimal additional cost. This innovation features high availability and scalability, with no additional software that needs to be bought or installed. For data governance and security (data quality, management, business process management, and risk management for data handling), the software uses NAMS. No local copy/cloning of data is permitted. Data change log/tracking is addressed, as well as collaboration, work flow, and process standardization. The software provides on-line documentation and detailed Web-based help. There are multiple ways that this software can be deployed on a Web server to meet ground operations planning needs for future programs. The software could be used to support commercial crew ground operations planning, as well as commercial payload/satellite ground operations planning. The application source code and database schema are owned by NASA.

Lanham, Clifton↗
NASA NTRS2006

A Case for Developing a Ground Based Replication of the Earth, Moon and Mars Spaceflight Infrastructure

When the systems are developed and in place to provide the services needed to operate en route and on the Lunar and Martian surfaces, an Earth based replication will need to be in place for the safety and protection of mission success. The replication will entail all aspects of the flight configuration end to end but will not include any closed loop systems. This would replicate the infrastructure from Lunar and Martian robots, manned surface excursions, through man and unmanned terrestrial bases, through the various types of communication systems and technologies, manned and un-manned space vehicles (large and small), to Earth based systems and control centers. An Earth based replicated infrastructure will enable checkout and test of new technologies, hardware, software updates and upgrades and procedures without putting humans and missions at risk. Analysis of events, what ifs and trouble resolution could be played out on the ground to remove as much risk as possible from any type of proposed change to flight operational systems. With adequate detail, it is possible that failures could be predicted with a high probability and action taken to eliminate failures. A major factor in any mission to the Moon and to Mars is the complexity of systems, interfaces, processes, their limitations, associated risks and the factor of the unknown including the development by many contractors and NASA centers. The need to be able to introduce new technologies over the life of the program requires an end to end test bed to analyze and evaluate these technologies and what will happen when they are introduced into the flight system. The ability to analyze system behaviors end to end under varying conditions would enhance safety e.g. fault tolerances. This analysis along with the ability to mine data from the development environment (e.g. test data), flight ops and modeling/simulations data would provide a level of information not currently available to operations and astronauts. In this paper we will analyze the beginnings of such a replication and what it could do in terms of reducing risk in the near term for development. We will analyze the Space Shuttle Main Engine (SSME) test lab which has to a large extent accomplished this replication for the SSME and has been highly successful in analyzing hardware and software problems and changes. The cost of replicating the flight system as proposed here could be very high if attempted as an afterthought. We will describe the initial steps for the development of a replication of this infrastructure starting with the communication infrastructure. The Constellation of Labs (CofL) under the Command, Control, Communication and Information (C3I) project for the NASA Exploration Initiative will provide the initial foundation upon which to base this replication. Simply put, there is very little margin for error in high latency situations e.g. en-route to/from Mars or in an autonomous process on the Lunar far side. Any thought out approach to reduce risk and increase safety needs to be accomplished end to end with the actual systems configuration.

Bradford, Robert N.↗
NASA NTRS1991

Intelligent systems/software engineering methodology - A process to manage cost and risk

A systems development methodology is discussed that has been successfully applied to the construction of a number of intelligent systems. This methodology is a refinement of both evolutionary and spiral development methodologies. It is appropriate for development of intelligent systems. The application of advanced engineering methodology to the development of software products and intelligent systems is an important step toward supporting the transition of AI technology into aerospace applications. A description of the methodology and the process model from which it derives is given. Associated documents and tools are described which are used to manage the development process and record and report the emerging design.

Friedlander, Carl↗
NASA NTRS1985

Space station data system analysis/architecture study. Task 2: Options development, DR-5. Volume 3: Programmatic options

Task 2 in the Space Station Data System (SSDS) Analysis/Architecture Study is the development of an information base that will support the conduct of trade studies and provide sufficient data to make design/programmatic decisions. This volume identifies the preferred options in the programmatic category and characterizes these options with respect to performance attributes, constraints, costs, and risks. The programmatic category includes methods used to administrate/manage the development, operation and maintenance of the SSDS. The specific areas discussed include standardization/commonality; systems management; and systems development, including hardware procurement, software development and system integration, test and verification.

Source record↗
NASA NTRS1986

Managing Ada development

The Ada programming language was developed under the sponsorship of the Department of Defense to address the soaring costs associated with software development and maintenance. Ada is powerful, and yet to take full advantage of its power, it is sufficiently complex and different from current programming approaches that there is considerable risk associated with committing a program to be done in Ada. There are also few programs of any substantial size that have been implemented using Ada that may be studied to determine those management methods that resulted in a successful Ada project. The items presented are the author's opinions which have been formed as a result of going through an experience software development. The difficulties faced, risks assumed, management methods applied, and lessons learned, and most importantly, the techniques that were successful are all valuable sources of management information for those managers ready to assume major Ada developments projects.

Green, James R.↗
NASA NTRS1994

Design of a walking robot

Carnegie Mellon University's Autonomous Planetary Exploration Program (APEX) is currently building the Daedalus robot; a system capable of performing extended autonomous planetary exploration missions. Extended autonomy is an important capability because the continued exploration of the Moon, Mars and other solid bodies within the solar system will probably be carried out by autonomous robotic systems. There are a number of reasons for this - the most important of which are the high cost of placing a man in space, the high risk associated with human exploration and communication delays that make teleoperation infeasible. The Daedalus robot represents an evolutionary approach to robot mechanism design and software system architecture. Daedalus incorporates key features from a number of predecessor systems. Using previously proven technologies, the Apex project endeavors to encompass all of the capabilities necessary for robust planetary exploration. The Ambler, a six-legged walking machine was developed by CMU for demonstration of technologies required for planetary exploration. In its five years of life, the Ambler project brought major breakthroughs in various areas of robotic technology. Significant progress was made in: mechanism and control, by introducing a novel gait pattern (circulating gait) and use of orthogonal legs; perception, by developing sophisticated algorithms for map building; and planning, by developing and implementing the Task Control Architecture to coordinate tasks and control complex system functions. The APEX project is the successor of the Ambler project.

Whittaker, William↗
NASA NTRS1988

Artificial intelligence approaches to software engineering

Artificial intelligence approaches to software engineering are examined. The software development life cycle is a sequence of not so well-defined phases. Improved techniques for developing systems have been formulated over the past 15 years, but pressure continues to attempt to reduce current costs. Software development technology seems to be standing still. The primary objective of the knowledge-based approach to software development presented in this paper is to avoid problem areas that lead to schedule slippages, cost overruns, or software products that fall short of their desired goals. Identifying and resolving software problems early, often in the phase in which they first occur, has been shown to contribute significantly to reducing risks in software development. Software development is not a mechanical process but a basic human activity. It requires clear thinking, work, and rework to be successful. The artificial intelligence approaches to software engineering presented support the software development life cycle through the use of software development techniques and methodologies in terms of changing current practices and methods. These should be replaced by better techniques that that improve the process of of software development and the quality of the resulting products. The software development process can be structured into well-defined steps, of which the interfaces are standardized, supported and checked by automated procedures that provide error detection, production of the documentation and ultimately support the actual design of complex programs.

Johannes, James D.↗
NASA NTRSDate not supplied

Alternating Between Software Models and Real Hardware in the System Integration Lab for theIncremental Development of the Space Launch System Program Avionics

The MSFC System Integration Lab (SIL) supports avionics development of NASA’s Space Launch System—a new U.S. heavy-lift launch vehicle for NASA’s next generation of human space exploration beyond low-Earth orbit. The SIL facility allows for the incremental development of system components by either hosting real hardware in the loop and/or software models of those components. Through this functionality test teams are able to evaluate overall system performance as components are designed, built and modified. Early hardware/software integration and testing reduces risks and saves overall cost and schedule throughout a program/project life cycle. By performing early hardware/software integration, potential architecture and interface-related problems can be identified, and thus reduce associated risk as early in the design cycle as possible when problems are the least expensive to resolve while also improving the design and requirements. This presentation will illustrate the power of employing a hardware in the loop simulation system for the development of novel spacecraft avionics.

Space Launch System↗
DOE OSTI2021

INTEGRATED RISK ASSESSMENT OF DIGITAL I&C SAFETY SYSTEMS FOR NUCLEAR POWER PLANTS

Upgrading the existing analog instrumentation and control (I&C) systems to state-of-the-art digital I&C (DI&C) systems provides the foremost means to improve performance and reduce costs for existing light-water reactors (LWRs). However, qualification of digital technologies remains a challenge?especially the issue of software common cause failure (CCF), which has been difficult to address. Existing analyses of CCFs in I&C systems mainly focus on hardware failures. With the application and upgrading of new DI&C systems, software CCFs due to design flaws might become a potential threat to plant safety, considering that most redundancy designs use similar digital platforms or software in their operating and application systems. With complex multi-layer redundancy designs to meet the single failure criterion, these I&C safety systems are of particular concern in U.S. Nuclear Regulatory Commission (NRC) licensing procedures. In 2019, the Risk-Informed Systems Analysis (RISA) Pathway of the U.S. Department of Energy?s (DOE?s) Light Water Reactor Sustainability (LWRS) Program initiated a project to develop a risk assessment strategy for delivering a strong technical basis to support effective, licensable, secure DI&C technologies for digital upgrades/designs. An integrated risk assessment for the DI&C (RADIC) process was proposed for this strategy to identify potential key digital-induced failures, implement reliability analyses of related digital safety I&C systems, and evaluate the unanalyzed sequences introduced by these failures (particularly software CCFs) at the plant level. This paper summarizes these RISA efforts in the risk analysis of safety-related DI& systems at Idaho National Laboratory.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDRs approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

radio equipment↗
NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDR's approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

space communication↗
NASA NTRS2019

Agile Approach to Assuring the Safety-Critical Embedded Software for NASA's Orion Spacecraft

Human-rated missions like NASA's Exploration Mission - 1 (EM-1) and the Orion Multi-Purpose Crew Vehicle are becoming exceedingly complex in terms of software's contribution to achieving mission objectives. The increasing complexity and inherent safety critical nature of the embedded flight software imposes a unique resource challenge to assurance providers responsible for affirming that the mission is going to fly safely. Another challenge NASA and other Government agencies are facing is that more and more software is being developed using an agile development methodology, which is divergent from the typical waterfall, iterative, and incremental development methodologies assurance providers generally observe in the development of safety-critical embedded software. Orion Independent Verification and Validation (IV&V) has addressed these challenges by providing focused assurance results of critical mission capabilities prioritized by a dynamic assessment of risk level. Prior to this approach, Orion IV&V evaluated areas of risk in much broader, and more static, terms. Due to the agile software development life cycle that Orion follows, IV&V findings were often reported months out of phase with the developer thereby imposing increased rework costs. As a result of evolving the approach to adding assurance on Orion, IV&V is able to incrementally deliver high-priority assurance conclusions and more impactful issues more in phase with the developer activities, thereby increasing the value of the findings to the project. The agile IV&V approach employed by the Orion IV&V team strives to achieve a cadence of delivery that matches the pace of development. This agile approach provides increased flexibility for the assurance provider to become more efficient in reporting assurance conclusions and issues. This paper and presentation will discuss the principles which drive the design of our approach, results to date, and stimulate thinking for groups looking to add assurance to software being developed using an agile methodology.

Justin Smith↗
NASA NTRSDate not supplied

Digital Prototyping Methods to Enable Product Development Analysis Cycle Compression in Aerospace Systems

Historically, the product development life cycle (spanning from origination of a systems concept to initial delivery or fielding) for large-scale aerospace systems is 10-25 years. Examples of recent programs exhibiting this timeline are the Space Shuttle (13 years), , International Space Station (18 years), NASA Hubble telescope (16 years), USAF F-35 Strike Fighter (22 years), Missile Defense Agency THAAD (21 years), USAF V-22 Osprey (26 years), USAF B-2 Spirt (19 years), US Army RAH-66 Comanche (22 years, cancelled prior to fielding), James Webb Space Telescope (25 years), Space Launch System (10 years). This list illustrates the challenges of developing and fielding a modern integrated multi-disciplinary aerospace system. These development timelines are often preceded by significant research and development programs and followed by multiple increments, blocks, or spirals to reach planned operational capability. In the modern era of aerospace system acquisition, there is significant pressure to reduce system development timelines to meet system objectives and enable competitiveness in the current industry and landscape. Across the aerospace industry, a range of rapid acquisition and prototyping programs are seeking to achieve system development within timelines considerably less than 10 years. Notably, in September of 2019, NASA issued a solicitation for the development and demonstration of a Human Landing System (HLS) to deliver humans to the lunar surface by 2024 (5 years) and for the development and demonstration of a more sustainable HLS by 2026 (7 years). Lengthy product development cycle timelines are a product of multiple factors ranging from programmatic, sociological, technical, and systems engineering issues. New approaches in systems engineering provide new ways to enable these compressed development timelines. These approaches employ expanded application of advanced systems engineering methods and cross-cutting digital tools to accelerate system development, utilizing digital prototyping to connect maturing sub-system or component technologies into system or system-of-systems hardware prototypes. Approaches such as the use of system integrating physics relationships to reduce the number of design analysis cycle iterations and state analysis modeling to reduce necessary software testing (and improving coverage of system execution scenarios) represent steps forward in reducing the engineering time needed to field new systems. In addition to cost, schedule and performance benefits, expanded digital exploration and demonstration reduce risk in live system test and demonstration. This incremental demonstration approach, where digital prototyping and demonstration leads and informs full system test and demonstration, could be more important for space applications because of the increased difficulty of test and demonstration of space systems and architectures. The Advanced Concepts Office (ACO) at Marshall Space Flight Center merges traditional multi-disciplinary concept definition methods with modern, cross-cutting systems engineering concepts to enable iterative design and analysis of space architectures and systems through coordinated, strategic management of human capital, technical processes, and technology. This paper provides an overview of that approach, including recent examples and a strategic path forward to enabling continued reduction of aerospace system product development life cycles.

Michael D Watson↗
NASA NTRS1999

Reinventing The Design Process: Teams and Models

The future of space mission designing will be dramatically different from the past. Formerly, performance-driven paradigms emphasized data return with cost and schedule being secondary issues. Now and in the future, costs are capped and schedules fixed-these two variables must be treated as independent in the design process. Accordingly, JPL has redesigned its design process. At the conceptual level, design times have been reduced by properly defining the required design depth, improving the linkages between tools, and managing team dynamics. In implementation-phase design, system requirements will be held in crosscutting models, linked to subsystem design tools through a central database that captures the design and supplies needed configuration management and control. Mission goals will then be captured in timelining software that drives the models, testing their capability to execute the goals. Metrics are used to measure and control both processes and to ensure that design parameters converge through the design process within schedule constraints. This methodology manages margins controlled by acceptable risk levels. Thus, teams can evolve risk tolerance (and cost) as they would any engineering parameter. This new approach allows more design freedom for a longer time, which tends to encourage revolutionary and unexpected improvements in design.

Wall, Stephen D.↗
NASA NTRS1994

Technology Benefit Estimator (T/BEST): User's Manual

The Technology Benefit Estimator (T/BEST) system is a formal method to assess advanced technologies and quantify the benefit contributions for prioritization. T/BEST may be used to provide guidelines to identify and prioritize high payoff research areas, help manage research and limited resources, show the link between advanced concepts and the bottom line, i.e., accrued benefit and value, and to communicate credibly the benefits of research. The T/BEST software computer program is specifically designed to estimating benefits, and benefit sensitivities, of introducing new technologies into existing propulsion systems. Key engine cycle, structural, fluid, mission and cost analysis modules are used to provide a framework for interfacing with advanced technologies. An open-ended, modular approach is used to allow for modification and addition of both key and advanced technology modules. T/BEST has a hierarchical framework that yields varying levels of benefit estimation accuracy that are dependent on the degree of input detail available. This hierarchical feature permits rapid estimation of technology benefits even when the technology is at the conceptual stage. As knowledge of the technology details increases the accuracy of the benefit analysis increases. Included in T/BEST's framework are correlations developed from a statistical data base that is relied upon if there is insufficient information given in a particular area, e.g., fuel capacity or aircraft landing weight. Statistical predictions are not required if these data are specified in the mission requirements. The engine cycle, structural fluid, cost, noise, and emissions analyses interact with the default or user material and component libraries to yield estimates of specific global benefits: range, speed, thrust, capacity, component life, noise, emissions, specific fuel consumption, component and engine weights, pre-certification test, mission performance engine cost, direct operating cost, life cycle cost, manufacturing cost, development cost, risk, and development time. Currently, T/BEST operates on stand-alone or networked workstations, and uses a UNIX shell or script to control the operation of interfaced FORTRAN based analyses. T/BEST's interface structure works equally well with non-FORTRAN or mixed software analysis. This interface structure is designed to maintain the integrity of the expert's analyses by interfacing with expert's existing input and output files. Parameter input and output data (e.g., number of blades, hub diameters, etc.) are passed via T/BEST's neutral file, while copious data (e.g., finite element models, profiles, etc.) are passed via file pointers that point to the expert's analyses output files. In order to make the communications between the T/BEST's neutral file and attached analyses codes simple, only two software commands, PUT and GET, are required. This simplicity permits easy access to all input and output variables contained within the neutral file. Both public domain and proprietary analyses codes may be attached with a minimal amount of effort, while maintaining full data and analysis integrity, and security. T/BESt's sotware framework, status, beginner-to-expert operation, interface architecture, analysis module addition, and key analysis modules are discussed. Representative examples of T/BEST benefit analyses are shown.

Generazio, Edward R.↗
NASA NTRS2000

The Spacecraft Materials Selector: An Artificial Intelligence System for Preliminary Design Trade Studies, Materials Assessments, and Estimates of Environments Present

Institutions need ways to retain valuable information even as experienced individuals leave an organization. Modern electronic systems have enough capacity to retain large quantities of information that can mitigate the loss of experience. Performance information for long-term space applications is relatively scarce and specific information (typically held by a few individuals within a single project) is often rather narrowly distributed. Spacecraft operate under severe conditions and the consequences of hardware and/or system failures, in terms of cost, loss of information, and time required to replace the loss, are extreme. These risk factors place a premium on appropriate choice of materials and components for space applications. An expert system is a very cost-effective method for sharing valuable and scarce information about spacecraft performance. Boeing has an artificial intelligence software package, called the Boeing Expert System Tool (BEST), to construct and operate knowledge bases to selectively recall and distribute information about specific subjects. A specific knowledge base to evaluate the on-orbit performance of selected materials on spacecraft has been developed under contract to the NASA SEE program. The performance capabilities of the Spacecraft Materials Selector (SMS) knowledge base are described. The knowledge base is a backward-chaining, rule-based system. The user answers a sequence of questions, and the expert system provides estimates of optical and mechanical performance of selected materials under specific environmental conditions. The initial operating capability of the system will include data for Kapton, silverized Teflon, selected paints, silicone-based materials, and certain metals. For situations where a mission profile (launch date, orbital parameters, mission duration, spacecraft orientation) is not precisely defined, the knowledge base still attempts to provide qualitative observations about materials performance and likely exposures. Prior to the NASA contract, a knowledge base, the Spacecraft Environments Assistant (SEA,) was initially developed by Boeing to estimate the environmental factors important for a specific spacecraft mission profile. The NASA SEE program has funded specific enhancements to the capability of this knowledge base. The SEA qualitatively identifies over 25 environmental factors that may influence the performance of a spacecraft during its operational lifetime. For cases where sufficiently detailed answers are provided to questions asked by the knowledge base, atomic oxygen fluence levels, proton and/or electron fluence and dose levels, and solar exposure hours are calculated. The SMS knowledge base incorporates the previously developed SEA knowledge base. A case history for previous flight experiment will be shown as an example, and capabilities and limitations of the system will be discussed.

Pippin, H. G.↗