Search NASA⌕ Search

SEARCH · Search NASA

Results for “hardware complexity”

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

Alternative Metrics for Evaluating the Resilence of Advanced Life Support Systems

Ensuring the safety of the crew is a key performance requirement of a life support system. However, a number of conceptual and practical difficulties arise when devising metrics to concretely measure the ability of a life support system to maintain critical functions in the presence of anticipated and unanticipated faults. Resilience is a dynamic property of a life support system that depends on the complex interactions between faults, controls and system hardware. We review some of the approaches to understanding the robustness or resilience of complex systems being developed in diverse fields such as ecology, software engineering and cell biology and discuss their applicability to regenerative life support systems. We also consider how approaches to measuring resilience vary depending on system design choices such as the definition and choice of the nominal operating regime. Finally, we explore data collection and implementation issues such as the key differences between the instantaneous or conditional and average or overall measures of resilience. Extensive simulation of a hybrid computational model of a water revitalization subsystem (WRS) with probabilistic, component-level faults provides data about off-nominal behavior of the system. The data are used to consider alternative measures of resilience as predictors of the system's ability to recover from component-level faults.

Bell, Ann Maria↗

Root-Raised Cosine Filter Implementation That Uses Canonical Signed Digits for High-Speed Digital Filter Applications

NASA Lewis Research Center's Space Communications Division has been investigating high-speed digital filters that can operate at a higher speed than those in current use for a digital modulator and demodulator (modem). Using the Canonical Signed Digits (CSD) number representation for filter coefficients is a very effective way to increase the filter's speed while reducing complexity in the digital filter hardware design. This approach is a good alternative to using an expensive parallel-processing design technique or custom, application-specific integrated circuits. Such integrated circuits may not be suitable for applications that require filter speeds faster than what application-specific integrated circuits digital signal processors can offer for a dedicated channel. When a communication channel is a dedicated, multiplication process--a costly, time-consuming process--it can be greatly simplified by a replacement of the filter coefficients with CSD numbers. A computer code written with the MATLAB software package runs the program and generates CSD-represented filter coefficients that are based on minimizing minimum mean square errors. Also, the Alta Group of Cadence's Signal Processing Workstation is used to simulate and analyze the CSD filter responses. The impulse response of the root-raised cosine filter that is used as a base model is defined. From this filter, a set of coefficients is sampled and stored in a file. For the all coefficients, the optimal CSD number for each coefficient is searched on the basis of the minimum-mean-square-errors criterion. Because the distribution of CSD numbers is not uniform, quantization errors tend to be bigger for coefficients greater than 1/2. To offset errors that occur in a region of coefficients between 1/2 to 1 and to better represent fractions with CSD numbers, an extra nonzero digit is allowed for any coefficients exceeding 1/2. This will greatly improve frequency response as well as intersymbol interference at the receiver. The frequency response of a set of collected CSD-represented filter coefficients was compared with the same filter that was conventionally implemented. Analyses show CSD-implemented filters perform as well as conventional filters. Comparison of eye diagrams and bit-error-rate curves between CSD filters and traditionally implemented filters are almost indistinguishable. However, filter complexity was reduced from almost 3.5 to 1 for CSD filters. Complete computer simulation results are available. In the near future, work will focus on building actual working digital filter hardware in a field programmable gate array (FPGA).

Kim, Heechul↗

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

Spacesuit and Space Vehicle Comparative Ergonomic Evaluation

With the advent of the latest manned spaceflight objectives, a series of prototype launch and reentry spacesuit architectures were evaluated for eventual down selection by NASA based on the performance of a set of designated tasks. A consolidated approach was taken to testing, concurrently collecting suit mobility data, seat-suit-vehicle interface clearances and movement strategies within the volume of a Multi-Purpose Crew Vehicle mockup. To achieve the objectives of the test, a requirement was set forth to maintain high mockup fidelity while using advanced motion capture technologies. These seemingly mutually exclusive goals were accommodated with the construction of an optically transparent and fully adjustable frame mockup. The mockup was constructed such that it could be dimensionally validated rapidly with the motion capture system. This paper will describe the method used to create a motion capture compatible space vehicle mockup, the consolidated approach for evaluating spacesuits in action, as well as the various methods for generating hardware requirements for an entire population from the resulting complex data set using a limited number of test subjects. Kinematics, hardware clearance, suited anthropometry, and subjective feedback data were recorded on fifteen unsuited and five suited subjects. Unsuited subjects were selected chiefly by anthropometry, in an attempt to find subjects who fell within predefined criteria for medium male, large male and small female subjects. The suited subjects were selected as a subset of the unsuited subjects and tested in both unpressurized and pressurized conditions. Since the prototype spacesuits were fabricated in a single size to accommodate an approximately average sized male, the findings from the suit testing were systematically extrapolated to the extremes of the population to anticipate likely problem areas. This extrapolation was achieved by first performing population analysis through a comparison of suited subjects performance to their unsuited performance and then applying the results to the entire range of population. The use of a transparent space vehicle mockup enabled the collection of large amounts of data during human-in-the-loop testing. Mobility data revealed that most of the tested spacesuits had sufficient ranges of motion for tasks to be performed successfully. A failed tasked by a suited subject most often stemmed from a combination of poor field of view while seated and poor dexterity of the gloves when pressurized or from suit/vehicle interface issues. Seat ingress/egress testing showed that problems with anthropometric accommodation does not exclusively occur with the largest or smallest subjects, but rather specific combinations of measurements that lead to narrower seat ingress/egress clearance.

England, Scott↗

Conical scan impact study. Volume 1: General central data processing facility

The impact of a conical scan versus a linear scan multispectral scanner (MSS) instrument was studied in terms of: (1) design modifications required in framing and continuous image recording devices; and (2) changes in configurations of an all-digital precision image processor. A baseline system was defined to provide the framework for comparison, and included pertinent spacecraft parameters, a conical MSS, a linear MSS, an image recording system, and an all-digital precision processor. Lateral offset pointing of the sensors over a range of plus or minus 20 deg was considered. The study addressed the conical scan impact on geometric, radiometric, and aperture correction of MSS data in terms of hardware and software considerations, system complexity, quality of corrections, throughput, and cost of implementation. It was concluded that: (1) if the MSS data are to be only film recorded, then there is only a nomial concial scan impact on the ground data processing system; and (2) if digital data are to be provided to users on computer compatible tapes in rectilinear format, then there is a significant conical scan impact on the ground data processing system.

Ebert, D. H.↗

Laser-Directed Ranging System Implementing Single Camera System for Telerobotics Applications

The invention relates generally to systems for determining the range of an object from a reference point and, in one embodiment, to laser-directed ranging systems useful in telerobotics applications. Digital processing techniques are employed which minimize the complexity and cost of the hardware and software for processing range calculations, thereby enhancing the commercial attractiveness of the system for use in relatively low-cost robotic systems. The system includes a video camera for generating images of the target, image digitizing circuitry, and an associated frame grabber circuit. The circuit first captures one of the pairs of stereo video images of the target, and then captures a second video image of the target as it is partly illuminated by the light beam, suitably generated by a laser. The two video images, taken sufficiently close together in time to minimize camera and scene motion, are converted to digital images and then compared. Common pixels are eliminated, leaving only a digital image of the laser-illuminated spot on the target. Mw centroid of the laser illuminated spot is dm obtained and compared with a predetermined reference point, predetermined by design or calibration, which represents the coordinate at the focal plane of the laser illumination at infinite range. Preferably, the laser and camera are mounted on a servo-driven platform which can be oriented to direct the camera and the laser toward the target. In one embodiment the platform is positioned in response to movement of the operator's head. Position and orientation sensors are used to monitor head movement. The disparity between the digital image of the laser spot and the reference point is calculated for determining range to the target. Commercial applications for the system relate to active range-determination systems, such as those used with robotic systems in which it is necessary to determine the, range to a workpiece or object to be grasped or acted upon by a robot arm end-effector in response to commands generated by an operator. In one embodiment, the system provides a real-time image of the target for the operator as the robot approaches the object. The system is also adapted for use in virtual reality systems in which a remote object or workpiece is to be acted upon by a remote robot arm or other mechanism controlled by an operator.

Wells, Dennis L.↗

Test Report: Low-Cost Access to TDRS Using TOPEX to Emulate Small Satellite Performance

This report lists the objectives and conclusions of a series of experimental contacts between the TOPEX and the TDRS satellites. These experiments are designed to verify the theoretical prediction that a spin-stabilized satellite with a broad-beam, zenith-pointing antenna can have regular, significant contacts with the TDRS and use those contacts for data services. This series of experiments is a joint project between the experimenters at New Mexico State University (NMSU), the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC), and the Jet Propulsion Laboratory (JPL). In these experiments, we show that: (1) The satellite contacts during the experiment begin and end as predicted prior to the experiment; (2) The data contact is held for the desired contact duration; (3) The data quality through the contact is high and similar to that required by actual project needs; and (4) The receiving hardware at the White Sands Complex (WSC) is able to track the signals better than expected by analysis of the antenna pattern effects alone predict. We believe that these experiments successfully demonstrate the basic concept and its validity with actual spacecraft systems.

Horan, Stephen↗

Using Pilots to Assess the Value and Approach of CMMI Implementation

At Goddard Space Flight Center (GSFC), we have chosen to use Capability Maturity Model Integrated (CMMI) to guide our process improvement program. Projects at GSFC consist of complex systems of software and hardware that control satellites, operate ground systems, run instruments, manage databases and data and support scientific research. It is a challenge to launch a process improvement program that encompasses our diverse systems, yet is manageable in terms of cost effectiveness. In order to establish the best approach for improvement, our process improvement effort was divided into three phases: 1) Pilot projects; 2) Staged implementation; and 3) Sustainment and continual improvement. During Phase 1 the focus of the activities was on a baselining process, using pre-appraisals in order to get a baseline for making a better cost and effort estimate for the improvement effort. Pilot pre-appraisals were conducted from different perspectives so different approaches for process implementation could be evaluated. Phase 1 also concentrated on establishing an improvement infrastructure and training of the improvement teams. At the time of this paper, three pilot appraisals have been completed. Our initial appraisal was performed in a flight software area, considering the flight software organization as the organization. The second appraisal was done from a project perspective, focusing on systems engineering and acquisition, and using the organization as GSFC. The final appraisal was in a ground support software area, again using GSFC as the organization. This paper will present our initial approach, lessons learned from all three pilots and the changes in our approach based on the lessons learned.

Godfrey, Sara↗

Past, Present and Future Advanced ECLS Systems for Human Exploration of Space

This paper will review the historical record of NASA's regenerative life support systems flight hardware with emphasis on the complexity of spiral development of technology as related to the International Space Station program. A brief summary of what constitutes ECLSS designs for human habitation will be included and will provide illustrations of the complex system/system integration issues. The new technology areas which need to be addressed in our future Code T initiatives will be highlighted. The development status of the current regenerative ECLSS for Space Station will be provided for the Oxygen Generation System and the Water Recovery System. In addition, the NASA is planning to augment the existing ISS capability with a new technology development effort by Code U/Code T for CO2 reduction (Sabatier Reactor). This latest ISS spiral development activity will be highlighted in this paper.

Mitchell, Kenny↗

Past, Present and Future Advanced ECLS Systems for Human Exploration of Space

This paper will review the historical record of NASA's regenerative life support systems flight hardware with emphasis on the complexity of spiral development of technology as related to the International Space Station program. A brief summary of what constitutes ECLSS designs for human habitation will be included and will provide illustrations of the complex system/system integration issues. The new technology areas which need to be addressed in our future Code T initiatives will be highlighted. The development status of the current regenerative ECLSS for Space Station will be provided for the Oxygen Generation System and the Water Recovery System. In addition, the NASA is planning to augment the existing ISS capability with a new technology development effort by Code U/Code T for CO2 reduction (Sabatier Reactor). This latest ISS spiral development activity will be highlighted in this paper.

Mitchell, Kenny↗

Test Capability Enhancements to the NASA Langley 8-Foot High Temperature Tunnel

The NASA Langley 8-Foot High Temperature Tunnel produces true enthalpy environments simulating flight from Mach 4 to Mach 7, primarily for airbreathing propulsion and aerothermal/thermo-structural testing. Flow conditions are achieved through a methane-air heater and nozzles producing aerodynamic Mach numbers of 4, 5 or 7 and have exit diameters of 8 feet or 4.5 feet. The 12-ft long free-jet test section, housed inside a 26-ft vacuum sphere, accommodates large test articles. Recently, the facility underwent significant upgrades to support hydrocarbon fueled scramjet engine testing and to expand flight simulation capability. The upgrades were required to meet engine system development and flight clearance verification requirements originally defined by the joint NASA-Air Force X-43C Hypersonic Flight Demonstrator Project and now the Air Force X-51A Program. Enhancements to the 8-Ft. HTT were made in four areas: 1) hydrocarbon fuel delivery; 2) flight simulation capability; 3) controls and communication; and 4) data acquisition/processing. The upgrades include the addition of systems to supply ethylene and liquid JP-7 to test articles; a Mach 5 nozzle with dynamic pressure simulation capability up to 3200 psf, the addition of a real-time model angle-of-attack system; a new programmable logic controller sub-system to improve process controls and communication with model controls; the addition of MIL-STD-1553B and high speed data acquisition systems and a classified data processing environment. These additions represent a significant increase to the already unique test capability and flexibility of the facility, and complement the existing array of test support hardware such as a model injection system, radiant heaters, six-component force measurement system, and optical flow field visualization hardware. The new systems support complex test programs that require sophisticated test sequences and precise management of process fluids. Furthermore, the new systems, such as the real-time angle of attack system and the new programmable logic controller enhance the test efficiency of the facility. The motivation for the upgrades and the expanded capabilities is described here.

Harvin, S. F.↗

Evolution of the Space Station Robotic Manipulator

The Space Station Remote Manipulator System (SSRMS), Canadarm2, was launched in 2001 and deployed on the International Space Station (ISS). The Canadarm2 has been instrumental in ISS assembly and maintenance. Canadarm2 shares its heritage with the Space Shuttle Arm (Canadarm). This article explores the evolution from the Shuttle Canadarm to the Space Station Canadarm2 design, which incorporates a 7 degree of freedom design, larger joints, and changeable operating base. This article also addresses phased design, redundancy, life and maintainability requirements. The design of Canadarm2 meets unique ISS requirements, including expanded handling capability and the ability to be maintained on orbit. The size of ISS necessitated a mobile manipulator, resulting in the unique capability of Canadarm2 to relocate by performing a walk off to base points located along the Station, and interchanging the tip and base of the manipulator. This provides the manipulator with reach and access to a large part of the Station, enabling on-orbit assembly of the Station and providing support to Extra-Vehicular Activity (EVA). Canadarm2 is evolving based on on-orbit operational experience and new functionality requirements. SSRMS functionality is being developed in phases to support evolving ISS assembly and operation as modules are added and the Station becomes more complex. Changes to sustaining software, hardware architecture, and operations have significantly enhanced SSRMS capability to support ISS mission requirements. As a result of operational experience, SSRMS changes have been implemented for Degraded Joint Operations, Force Moment Sensor Thermal Protection, Enabling Ground Controlled Operations, and Software Commutation. Planned Canadarm2 design modifications include: Force Moment Accommodation, Smart Safing, Separate Safing, and Hot Backup. In summary, Canadarm2 continues to evolve in support of new ISS requirements and improved operations. It is a tribute to the design that this evolution can be accomplished while conducting critical on-orbit operations with minimal hardware changes.

Razvi, Shakeel↗

Approximation of Engine Casing Temperature Constraints for Casing Mounted Electronics

The performance of propulsion engine systems is sensitive to weight and volume considerations. This can severely constrain the configuration and complexity of the control system hardware. Distributed Engine Control technology is a response to these concerns by providing more flexibility in designing the control system, and by extension, more functionality leading to higher performing engine systems. Consequently, there can be a weight benefit to mounting modular electronic hardware on the engine core casing in a high temperature environment. This paper attempts to quantify the in-flight temperature constraints for engine casing mounted electronics. In addition, an attempt is made at studying heat soak back effects. The Commercial Modular Aero Propulsion System Simulation 40k (C-MAPSS40k) software is leveraged with real flight data as the inputs to the simulation. A two-dimensional (2-D) heat transfer model is integrated with the engine simulation to approximate the temperature along the length of the engine casing. This modification to the existing C-MAPSS40k software will provide tools and methodologies to develop a better understanding of the requirements for the embedded electronics hardware in future engine systems. Results of the simulations are presented and their implications on temperature constraints for engine casing mounted electronics is discussed.

Engine↗

Approximation of Engine Casing Temperature Constraints for Casing Mounted Electronics

The performance of propulsion engine systems is sensitive to weight and volume considerations. This can severely constrain the configuration and complexity of the control system hardware. Distributed Engine Control technology is a response to these concerns by providing more flexibility in designing the control system, and by extension, more functionality leading to higher performing engine systems. Consequently, there can be a weight benefit to mounting modular electronic hardware on the engine core casing in a high temperature environment. This paper attempts to quantify the in-flight temperature constraints for engine casing mounted electronics. In addition, an attempt is made at studying heat soak back effects. The Commercial Modular Aero Propulsion System Simulation 40k (C-MAPSS40k) software is leveraged with real flight data as the inputs to the simulation. A two-dimensional (2-D) heat transfer model is integrated with the engine simulation to approximate the temperature along the length of the engine casing. This modification to the existing C-MAPSS40k software will provide tools and methodologies to develop a better understanding of the requirements for the embedded electronics hardware in future engine systems. Results of the simulations are presented and their implications on temperature constraints for engine casing mounted electronics is discussed.

Engine↗

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies.

Robert C. Dempsey↗

Designing Flight-Deck Procedures

A complex human-machine system consists of more than merely one or more human operators and a collection of hardware components. In order to operate a complex system successfully, the human-machine system must be supported by an organizational infrastructure of operating concepts, rules, guidelines, and documents. The coherency of such operating concepts, in terms of consistency and logic, is vitally important for the efficiency and safety of any complex system. In high-risk endeavors such as aircraft operations, space flight, nuclear power production, manufacturing process control, and military operations, it is essential that such support be flawless, as the price of operational error can be high. When operating rules are not adhered to, or the rules are inadequate for the task at hand, not only will the system's goals be thwarted, but there may also be tragic human and material consequences. To ensure safe and predictable operations, support to the operators, in this case flight crews, often comes in the form of standard operating procedures. These provide the crew with step-by-step guidance for carrying out their operations. Standard procedures do indeed promote uniformity, but they do so at the risk of reducing the role of human operators to a lower level. Management, however, must recognize the danger of over-procedurization, which fails to exploit one of the most valuable assets in the system, the intelligent operator who is "on the scene." The alert system designer and operations manager recognize that there cannot be a procedure for everything, and the time will come in which the operators of a complex system will face a situation for which there is no written procedure. Procedures, whether executed by humans or machines, have their place, but so does human cognition.

Degani, Asaf↗