A perspective is developed on how redundancy management techniques for e ight-critical systems have matured sincetheearliestapplicationsin the1960s,driven largelybytheintroduction ofmorepowerfulcomputerresources. As this evolution occurred, the basic issues involving system architecture tradeoffs changed very little, although the hardware mechanizations of the earlier analog systems have been replaced largely with the software of the newerdigital systems.Thesebasicissuesarereviewed and howthey tend to beresolvedinpractical mechanizations is shown. The large body of literature on analytic redundancy theory developed since the 1970s is discussed in the context of its applicability to practical systems. It is shown that analytic redundancy has an important role in real-world systems but that it is not a replacement for physical redundancy, and its proper implementation requires that it be embedded within the physical redundancy structure of the system.

Practical View of Redundancy Management Application and Theory

Specific examples of generic faults involving interaction of hardware and software in flight-critical systems are described. Such faults can cause an avalanche shutdown of all redundant computer channels. The popular technique of redundant computer frame synchronization is shown to be particularly vulnerable. Architecture solutions that allow dissimilar redundancy and incorporate "brick-wall" isolation are described. Practical techniques of coping with time-skew effects in unsynchronized computer channels are given, and it is shown that they offer many simplicity advantages. HE term ''generic fault" became part of the technical language to describe design defects that elude the test and analysis procedures used to validate a redundant control system design. Although the existence of such defects can be postulated in any type of system, the generic fault concept is especially significant in the flight-critical system application because it defeats the massive redundancy strategies that designers rely on to meet safety or reliability objectives. A vision of such a fault toppling each channel of a flight-critical redundant system is a nightmare that haunts the designer and the "certifier" communities. The first part of this paper examines various classes of such faults, acknowledging that there can be no 100% certainty that a system is free of them. Specific illustrations show why their detection and correction are difficult. It is contended that redundancy architecture is a key factor in generic fault vulnerability, with redundant channel syn- chronization as a major aggravator of error mechanisms. Well-known solutions to such vulnerabilities involve concepts of channel decoupling, including the "brick wall" approaches that were popular in early analog mechanizations.1 '2 The term "brick wall" refers to extraordinary measures taken to insure the physical and electrical separation of redundant channels. Dissimilar redundancy also has its advocates,3 but both solutions preclude the advantages provided by frame (or loose) synchronization of computer channels. Such syn- chronization allows an inherent simplification of monitoring algorithms. Various degrees of synchronizati on tightness have been used. The Space Shuttle computers synchronize to sublevels of frames or tasks, 4 while some systems under development use complete microclock synchronization in massively redundant central processing unit (CPU) and memory structures.5'6 When channel decoupling and isolation (including dissimilar hardware and software mechanisms) are used to avoid generic-fault vulnerabilities, channel syn- chronization must then be abandoned. A recurring theme of this paper is that the synchronization of redundant computers opens pathways for generic faults to cause multiple channel shutdowns. In some instances these faults reside in incomplete logic designs that might not an- ticipate the multiplicity of computer resynchronization in- teractions following transient events in the power distribution system. In other instances, the generic fault could also exist in the nonsynchronized systems, but an event which triggers the fault would cause only one channel to shut down, whereas the same fault in synchronous architectures would cause multiple

Generic Faults and Architecture Design Considerations in Flight-Critical Systems

Flight experiments with a microprocessor control system have been conducted. The purposes of these tests were to provide information which will assist the development of flying qualities criteria for digital control systems and to investigate engineering characteristics of the research system. Four test pilots evaluated the effects of digital control system parameter variations on a research aircraft's longitudinal flying qualities during tracking and landing tasks. Critical ranges of sampling rate, quantization level, and time delay were identified as functions of the piloting tasks. In the subject aircraft, the limits for satisfactory control appear to be sampling rates of 4-10/s, control word lengths of 4-8 bits, and equivalent time delays of 50-250 ms, depending upon the task. Satisfactory flying qualities at lower sampling rates and resolution can be achieved with command and stability augmentation.

Flight Tests of a Microprocessor Control System

The Flight Research Laboratory at Princeton University is engaged in an experimental program to investigate a variety of approaches to digital control by actual flight test. Experimentation is being conducted with Princeton's 6-DOF variableresponse research aircraft (VRA), which is equipped for direct side-force control, direct-lift control, feedback of all motion variables, and multiple-pilot command modes. VRA avionics have been augmented by a microprocessor digital flight control system (Micro-DFCS), which uses off-the-shelf computer components capable of operating in parallel or in series with the existing variable-response system. The digital control laws operate in conjunction either with the "bare airframe" dynamics of the VRA or with the dynamics of a simulated aircraft, provided by the existing variable-response system. The initial flight control computer program CAS-1 provides three longitudinal control options: direct (unaugmented) command, pitch rate command, and normal acceleration command. The latter two options are "Type 0" systems designed by linear-quadratic control theory. Future Micro-DFCS software will provide a variety of increasingly complex control options, including "Type 1," logic, gain scheduling, coupled 3-axis control, and "CCV" command modes.

/pdf/digital-flight-control-research-using-microprocessor-58fnoirrmv.pdf

Digital Flight Control Research Using Microprocessor Technology

DC-9-80 Digital Flight Guidance System Monitoring Techniques

A digital guidance and control system flight tested in a DC-10 aircraft in the summer of 1974 confirmed that system's monitoring techniques, certifiable control law performance (including automatic landing), and automated maintenance management concepts. It also verified compatibility of the system architecture with the aircraft's guidance/navigation sensors and redundant electrohydraulic flight control actuators. System organization, in terms of redundancy and software-hard ware monitoring, is described. Computer memory and time requirements for the various control modes and other software functions are summarized. Flight results associated with autoland performance and the system's recognition and responses to inserted failures during autoland mode engagement are described.

S. S. Osder

Papers

Flight Test of a Digital Guidance and Control System in a DC-IO Aircraft