Search NASA⌕ Search

SEARCH · Search NASA

Results for “building automation”

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 19 records

Building Automation System Replacement and Improvements during Concurrent Integration and Testing for the Spacecraft Systems Development and Integration Facility

The Spacecraft Systems Development and Integration Facility (SSDIF), the premier cleanroom for NASA Goddard Space Flight Center (GSFC), has gone through multiple iterations of changes to its building automation system (BAS). NASA flight projects require more stringent environmental controls for temperature, humidity, air exchange rates, and pressurization. This led to increasingly difficult circumstances with replacing and improving the BAS during Integration and Testing (I&T) operations. The SSDIF was partially transitioned to a new BAS during November and December of 2023. Transition occurred in a live environment, while regular I&T activities resumed for the Roman Space Telescope. This resulted in the development and execution of a comprehensive method of procedure. Strategies such as sequencing equipment transition, and using temporary controls for critical equipment, avoided detriments to cleanroom environment. While the new BAS was being built, data points on the previous system would become obsolete, leading to data gaps and uncertainties. Critical data points were distinguished and trended on the new system, providing key insights on equipment functionality, while the BAS was completed. Control hunting and environmental deviations were persistent cases with the SSDIF. In some instances, proportional-integral-derivative (PID) tuning was implemented on current logic to bring smooth PID loop hunting. In other situations, controls logic was completely altered by changing setpoints or sequences. This provided greater laminar flow, more stable pressurization, and improved temperature and humidity controls. This paper documents the transitionary procedure to a new BAS, the improvements made, and challenges faced when altering a BAS during I&T operations.

Cleanroom↗

Matrix Failure Modes and Effects Analysis as a Knowledge Base for a Real Time Automated Diagnosis Expert System

Failure Modes and Effects Analysis contain a wealth of information that can be used to create the knowledge base required for building automated diagnostic Expert systems. A real time monitoring and diagnosis expert system based on an actual NASA project's matrix failure modes and effects analysis was developed. This Expert system Was developed at NASA Ames Research Center. This system was first used as a case study to monitor the Research Animal Holding Facility (RAHF), a Space Shuttle payload that is used to house and monitor animals in orbit so the effects of space flight and microgravity can be studied. The techniques developed for the RAHF monitoring and diagnosis Expert system are general enough to be used for monitoring and diagnosis of a variety of other systems that undergo a Matrix FMEA. This automated diagnosis system was successfully used on-line and validated on the Space Shuttle flight STS-58, mission SLS-2 in October 1993.

Herrin, Stephanie↗

Automated Advisors for Remote Science Experimentation

This paper details flight results from the PI-in-a-Box project. The project is an attempt to understand the issues involved in building automated real-time advisory systems to improve the conduct of science in remote laboratory settings. This is an important problem as examples of these situations can be found throughout aerospace. A knowledge-based approach is used to facilitate real-time reactions to experiment data as it is collected by a competent, but not expert, operator. The system was flown on the Space Shuttle in October, 1993. The PI-in-a-Box system was able to outperform humans in a variety of science-related tasks. These tasks include data integrity assurance, data analysis, and scientific model validation.

Frainier, Richard↗

Planetary Exploration Reinvented

During the past 50 years, we have learned to explore and work in space. Much of what we know about the Solar System we owe to observations and sampling made by robotic spacecraft, landers, planetary rovers, and astronauts. As we look to the future, however, there is ample opportunity to reinvent planetary exploration: to develop new techniques and systems that will enhance and enable discovery.In this talk, I will describe how the NASA Ames Intelligent Robotics Group (IRG) is working to reinvent planetary exploration. First, I will present IRG's development of robots for human exploration. These robots are designed to perform work before, in parallel, and after human activity. Next, I will show how IRG is building automated planetary mapping systems to process the enormous amount of data that NASA collects from orbit. Finally, I will discuss how IRG is changing the way ground control software is created, particularly for supporting science operations.

robotics↗

Accrued Delay Application in Trajectory-Based Operations

The air traffic management system lacks integration among its elements often due to using inconsistent information, models, and metrics about the traffic. Transitioning to trajectory-based operations, whereby flights are managed by full trajectories in space and time, will enable more integration, with the help of increased automation. Building on trajectory-based operations, an "accrued delay" metric is proposed, which continuously measures the amount of delay that a flight has accumulated up to the current time, including delays incurred during the current flight and inherited from previous flights through the turnaround process. Through a time-based metering and scheduling example, we show how using accrued delay as a metric can help integrate the decision-making across multiple decision horizons, leading to more efficient and balanced access to airspace services. We show that when prioritizing flights that have already accrued high delay because of a constrained runway resource, significant gains are achieved in terms of reducing total delay and its variance. We studied the sensitivity of these gains to numerous factors, such as time-based versus distance-based horizons, horizon size, and errors in conformance to scheduled times.

delay; trajectory-based operations; time-based flo↗

Accrued Delay Application in Trajectory-Based Operations

The air traffic management system lacks integration among its elements often due to using inconsistent information, models, and metrics about the traffic. Transitioning to trajectory-based operations, whereby flights are managed by full trajectories in space and time, will enable more integration, with the help of increased automation. Building on trajectory-based operations, an "accrued delay" metric is proposed, which continuously measures the amount of delay that a flight has accumulated up to the current time, including delays incurred during the current flight and inherited from previous flights through the turnaround process. Through a time-based metering and scheduling example, we show how using accrued delay as a metric can help integrate the decision-making across multiple decision horizons, leading to more efficient and balanced access to airspace services. We show that when prioritizing flights that have already accrued high delay because of a constrained runway resource, significant gains are achieved in terms of reducing total delay and its variance. We studied the sensitivity of these gains to numerous factors, such as time-based versus distance-based horizons, horizon size, and errors in conformance to scheduled times.

Idris, Husni↗

Numerical Investigation and Optimization of a Flushwall Injector for Scramjet Applications at Hypervelocity Flow Conditions

An investigation utilizing Reynolds-averaged simulations (RAS) was performed in order to find optimal designs for an interdigitated flushwall injector suitable for scramjet applications at hypervelocity conditions. The flight Mach number, duct height, spanwise width, and injection angle were the design variables selected to maximize two objective functions: the thrust potential and combustion efficiency. A Latin hypercube sampling design-of-experiments method was used to select design points for RAS. A methodology was developed that automated building geometries and generating grids for each design. The ensuing RAS analysis generated the performance database from which the two objective functions of interest were computed using a one-dimensional performance utility. The data were fitted using four surrogate models: an artificial neural network (ANN) model, a cubic polynomial, a quadratic polynomial, and a Kriging model. Variance-based decomposition showed that both objective functions were primarily driven by changes in the duct height. Multiobjective design optimization was performed for all four surrogate models via a genetic algorithm method. Optimal solutions were obtained at the upper and lower bounds of the flight Mach number range. The Kriging model obtained an optimal solution set that predicted high values for both objective functions. Additionally, three challenge points were selected to assess the designs on the Pareto fronts. Further sampling among the designs of the Pareto fronts are required in order to lower the errors and perform more accurate surrogate-based optimization. sed optimization.

Shenoy, Rajiv R.↗

Automated Predictive Diagnosis (APD): A 3-tiered shell for building expert systems for automated predictions and decision making

The APD software features include: On-line help, Three level architecture, (Logic environments, Setup/Application environment, Data environment), Explanation capability, and File handling. The kinds of experimentation and record keeping that leads to effective expert systems is facilitated by: (1) a library of inferencing modules (in the logic environment); (2) an explanation capability which reveals logic strategies to users; (3) automated file naming conventions; (4) an information retrieval system; and (5) on-line help. These aid with effective use of knowledge, debugging and experimentation. Since the APD software anticipates the logical rules becoming complicated, it is embedded in a production system language (CLIPS) to insure the full power of the production system paradigm of CLIPS and availability of the procedural language C. The development is discussed of the APD software and three example applications: toy, experimental, and operational prototype for submarine maintenance predictions.

Steib, Michael↗

Formal Methods for Automated Diagnosis of Autosub 6000

This is a progress report on applying formal methods in the context of building an automated diagnosis and recovery system for Autosub 6000, an Autonomous Underwater Vehicle (AUV). The diagnosis task involves building abstract models of the control system of the AUV. The diagnosis engine is based on Livingstone 2, a model-based diagnoser originally built for aerospace applications. Large parts of the diagnosis model can be built without concrete knowledge about each mission, but actual mission scripts and configuration parameters that carry important information for diagnosis are changed for every mission. Thus we use formal methods for generating the mission control part of the diagnosis model automatically from the mission script and perform a number of invariant checks to validate the configuration. After the diagnosis model is augmented with the generated mission control component model, it needs to be validated using verification techniques.

Ernits, Juhan↗

Spacecraft command verification: The AI solution

Recently, a knowledge-based approach was used to develop a system called the Command Constraint Checker (CCC) for TRW. CCC was created to automate the process of verifying spacecraft command sequences. To check command files by hand for timing and sequencing errors is a time-consuming and error-prone task. Conventional software solutions were rejected when it was estimated that it would require 36 man-months to build an automated tool to check constraints by conventional methods. Using rule-based representation to model the various timing and sequencing constraints of the spacecraft, CCC was developed and tested in only three months. By applying artificial intelligence techniques, CCC designers were able to demonstrate the viability of AI as a tool to transform difficult problems into easily managed tasks. The design considerations used in developing CCC are discussed and the potential impact of this system on future satellite programs is examined.

Fesq, Lorraine M.↗

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗

Improved techniques of parallel gap welding and monitoring

Welding programs which show that parallel gas welding is a reliable process are discussed. When monitoring controls and nondestructive tests are incorporated into the process, parallel gap welding becomes more reliable and cost effective. The panel fabrication techniques and the HAC thermal cycling test indicate reliable product integrity. The design and building of automated tooling and fixturing for welding are discussed.

Mardesich, N.↗

NASA Tech Briefs, February 2007

Topics covered include: Calibration Test Set for a Phase-Comparison Digital Tracker; Wireless Acoustic Measurement System; Spiral Orbit Tribometer; Arrays of Miniature Microphones for Aeroacoustic Testing; Predicting Rocket or Jet Noise in Real Time; Computational Workbench for Multibody Dynamics; High-Power, High-Efficiency Ka-Band Space Traveling-Wave Tube; Gratings and Random Reflectors for Near-Infrared PIN Diodes; Optically Transparent Split-Ring Antennas for 1 to 10 GHz; Ice-Penetrating Robot for Scientific Exploration; Power-Amplifier Module for 145 to 165 GHz; Aerial Videography From Locally Launched Rockets; SiC Multi-Chip Power Modules as Power-System Building Blocks; Automated Design of Restraint Layer of an Inflatable Vessel; TMS for Instantiating a Knowledge Base With Incomplete Data; Simulating Flights of Future Launch Vehicles and Spacecraft; Control Code for Bearingless Switched- Reluctance Motor; Machine Aided Indexing and the NASA Thesaurus; Arbitrating Control of Control and Display Units; Web-Based Software for Managing Research; Driver Code for Adaptive Optics; Ceramic Paste for Patching High-Temperature Insulation; Fabrication of Polyimide-Matrix/Carbon and Boron-Fiber Tape; Protective Skins for Aerogel Monoliths; Code Assesses Risks Posed by Meteoroids and Orbital Debris; Asymmetric Bulkheads for Cylindrical Pressure Vessels; Self-Regulating Water-Separator System for Fuel Cells; Self-Advancing Step-Tap Drills; Array of Bolometers for Submillimeter- Wavelength Operation; Delta-Doped CCDs as Detector Arrays in Mass Spectrometers; Arrays of Bundles of Carbon Nanotubes as Field Emitters; Staggering Inflation To Stabilize Attitude of a Solar Sail; and Bare Conductive Tether for Decelerating a Spacecraft.

Source record↗

Part II: FY20 CIF Annual Report - LAPS: Lunar Autonomous Positioning System

This project concerns construction of an orbital and ground resource network that provides Position, Navigation, and Timing (PNT) services for lunar surface operations. While functionally similar to Global Navigation Satellite Systems (GNSS) for Earth, this system will instead build an automated PNT framework utilizing limited infrastructure on board orbiting assets along with a controlled number of highly accurate assets, or anchor nodes. The goal is to use advanced algorithms to autonomously coordinate on demand or as needed asset participation to achieve orbit determination and time synchronization of accuracy sufficient for end-user localization. Other proposed lunar PNT solutions, such as weak signal GPS, will not meet many mission localization requirements without additional user INS augmentation and a dedicated GNSS constellation would require prohibitive infrastructure development. This proposed effort, the Lunar Autonomous Positioning System (LAPS), instead offers a design that could be deployed in the near term and is facilitated by accessible hardware technology.

Kelley Hashemi↗

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗

Shuttle Repair Tools Automate Vehicle Maintenance

Successfully building, flying, and maintaining the space shuttles was an immensely complex job that required a high level of detailed, precise engineering. After each shuttle landed, it entered a maintenance, repair, and overhaul (MRO) phase. Each system was thoroughly checked and tested, and worn or damaged parts replaced, before the shuttle was rolled out for its next mission. During the MRO period, workers needed to record exactly what needed replacing and why, as well as follow precise guidelines and procedures in making their repairs. That meant traceability, and with it lots of paperwork. In 2007, the number of reports generated during electrical system repairs was getting out of hand-placing among the top three systems in terms of paperwork volume. Repair specialists at Kennedy Space Center were unhappy spending so much time at a desk and so little time actually working on the shuttle. "Engineers weren't spending their time doing technical work," says Joseph Schuh, an electrical engineer at Kennedy. "Instead, they were busy with repetitive, time-consuming processes that, while important in their own right, provided a low return on time invested." The strain of such inefficiency was bad enough that slow electrical repairs jeopardized rollout on several occasions. Knowing there had to be a way to streamline operations, Kennedy asked Martin Belson, a project manager with 30 years experience as an aerospace contractor, to co-lead a team in developing software that would reduce the effort required to document shuttle repairs. The result was System Maintenance Automated Repair Tasks (SMART) software. SMART is a tool for aggregating and applying information on every aspect of repairs, from procedures and instructions to a vehicle s troubleshooting history. Drawing on that data, SMART largely automates the processes of generating repair instructions and post-repair paperwork. In the case of the space shuttle, this meant that SMART had 30 years worth of operations that it could apply to ongoing maintenance work. According to Schuh, "SMART standardized and streamlined many shuttle repair processes, saving time and money while increasing safety and the quality of repairs." Maintenance technicians and engineers now had a tool that kept them in the field, and because SMART is capable of continually evolving, each time an engineer put it to use, it would enrich the Agency-wide knowledge base. "If an engineer sees something in the work environment that they could improve, a repair process or a procedure, SMART can incorporate that data for use in future operations," says Belson.

Source record↗