Rotorcraft with redundant processors using state comparison

A system and method for providing state comparison of redundant processors used, e.g. to control a rotor craft. A primary microprocessor is configured to receive input data from a position sensor and a flight condition sensor and determine therefrom a first desired control law state, and a secondary microprocessor is configured to receive input data from the position sensor and the flight condition sensor and determine therefrom a second desired control law state. The first desired control law state from the primary microprocessor and the second desired control law state from the secondary microprocessor are compared, and (a) the first desired control law state is entered when the first desired control law state and the second desired control law state match, and (b) a last known control law state is maintained when the first desired control law state and the second desired control law state do not match.

TECHNICAL FIELD

The present invention relates generally to a system and method for automated flight control in a rotorcraft, and more particularly, to a rotorcraft having redundant control processors employing state comparison between the processors for key control operations.

BACKGROUND

A rotorcraft may include one or more rotor systems including one or more main rotor systems. A main rotor system generates aerodynamic lift to support the weight of the rotorcraft in flight and thrust to move the rotorcraft in forward flight. Another example of a rotorcraft rotor system is a tail rotor system. A tail rotor system may generate thrust in the same direction as the main rotor system's rotation to counter the torque effect created by the main rotor system. For smooth and efficient flight in a rotorcraft, a pilot balances the engine power, main rotor collective thrust, main rotor cyclic thrust and the tail rotor thrust, and a control system may assist the pilot in stabilizing the rotorcraft and reducing pilot workload. Modern control systems include one or more flight control computers that can be intimately involved in mission-critical flight control and stability functions. Hence, a high degree of reliability is an essential parameter for the flight control computers.

SUMMARY

Embodiments disclosed herein may provide for a rotorcraft comprising a rotor, a pilot input device, a position sensor coupled to the input device, a flight condition sensor, and a flight control computer (FCC). The FCC may include a primary microprocessor configured to receive input data from the position sensor and the flight condition sensor and determine therefrom a first desired control law state, and a secondary microprocessor configured to receive input data from the position sensor and the flight condition sensor and determine therefrom a second desired control law state. The FCC may be configured to compare the first desired control law state from the primary microprocessor and the second desired control law state from the secondary microprocessor and to (a) enter the first desired control law state when the first desired control law state and the second desired control law state match, and (b) maintain a last known control law state when the first desired control law state and the second desired control law state do not match.

In some embodiments, the rotorcraft may be flown by sensing a pilot input condition, sensing a flight condition of the rotorcraft, and inputting the pilot input condition and the flight condition to a first hardware/software combination and inputting the pilot input condition and the flight condition to a second hardware/software combination. The method may further include determining, using the first hardware/software combination, a first control law state based on the pilot input condition and the flight condition, and determining, using the second hardware/software combination, a second control law state. The method may further include comparing the first control law state and the second control law state, and adopting the first control law state, in response to determining that the first control law state and the second control law state match, maintaining the first control law state, in response to determining that the first control law state and the second control law state match, when the first control law state is the same as an immediately previously adopted control law state, and maintaining a previous control law state and maintaining a current flight trim condition in response to determining the first control law state and the second control law state do not match.

In another aspect, the embodiments disclosed herein may provide for a computer architecture for controlling a system, the computer architecture, including a first processing lane, the first processing lane including a first microprocessor and a second microprocessor. The first microprocessor and the second microprocessor have at least one material difference, which at least one material difference may cause, in the absence of an error, a different output from the second microprocessor relative to the output from the first microprocessor when the second microprocessor and the first microprocessor receive identical input data and run identical program steps on the identical input data. The computer architecture may further include input ports configured to receive input data indicative of a condition of the system, and second processing lane, the second processing lane including a third microprocessor and a fourth microprocessor, wherein the third microprocessor and the fourth microprocessor are similar in all material respects, such that, absent an error, the fourth microprocessor and the third microprocessor will output a same result when the fourth microprocessor and the third microprocessor receive identical input data and run identical program steps on the identical data. The computer architecture may further include a comparator configured to compare an output from the first microprocessor and the second microprocessor, and a state selector configured to select or maintain a state represented by the output from the first microprocessor when the output from the first microprocessor and the second microprocessor match and to maintain a current state when the output from the first microprocessor and the second microprocessor do not match.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Illustrative embodiments of the system and method of the present disclosure are described below. In the interest of clarity, all features of an actual implementation may not be described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions may be made to achieve the developer's specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time-consuming but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.

The increasing use of rotorcraft, in particular, for commercial and industrial applications, has led to the development of larger more complex rotorcraft. However, as rotorcraft become larger and more complex, the differences between flying rotorcraft and fixed wing aircraft has become more pronounced. Since rotorcraft use one or more main rotors to simultaneously provide lift, control attitude, control altitude, and provide lateral or positional movement, different flight parameters and controls are tightly coupled to each other, as the aerodynamic characteristics of the main rotors affect each control and movement axis. For example, the flight characteristics of a rotorcraft at cruising speed or high speed may be significantly different than the flight characteristics at hover or at relatively low speeds. Additionally, different flight control inputs for different axes on the main rotor, such as cyclic inputs or collective inputs, affect other flight controls or flight characteristics of the rotorcraft. For example, pitching the nose of a rotorcraft forward to increase forward speed will generally cause the rotorcraft to lose altitude. In such a situation, the collective may be increased to maintain level flight, but the increase in collective requires increased power at the main rotor which, in turn, requires additional anti-torque force from the tail rotor. This is in contrast to fixed wing systems where the control inputs are less closely tied to each other and flight characteristics in different speed regimes are more closely related to each other.

Recently, fly-by-wire (FBW) systems have been introduced in rotorcraft to assist pilots in stably flying the rotorcraft and to reduce workload on the pilots. The FBW system may provide different control characteristics or responses for cyclic, pedal or collective control input in the different flight regimes, and may provide stability assistance or enhancement by decoupling physical flight characteristics so that a pilot is relieved from needing to compensate for some flight commands issued to the rotorcraft. FBW systems may be implemented in one or more flight control computers (FCCs) disposed between the pilot controls and flight control systems, providing corrections to flight controls that assist in operating the rotorcraft more efficiently or that put the rotorcraft into a stable flight mode while still allowing the pilot to override the FBW control inputs. The FBW systems in a rotorcraft may, for example, automatically adjust power output by the engine to match a collective control input, apply collective or power correction during a cyclic control input, provide automation of one or more flight control procedures, provide for default or suggested control positioning, or the like.

FIG. 1illustrates a rotorcraft101according to some embodiments. The rotorcraft101has a main rotor system103, which includes a plurality of main rotor blades105. The pitch of each main rotor blade105may be controlled by a swashplate107in order to selectively control the attitude, altitude and movement of the rotorcraft101. The swashplate107may be used to collectively and/or cyclically change the pitch of the main rotor blades105. The rotorcraft101also has an anti-torque system, which may include a tail rotor109, no-tail-rotor (NOTAR), or dual main rotor system. In rotorcraft with a tail rotor109, the pitch of each tail rotor blade111is collectively changed in order to vary thrust of the anti-torque system, providing directional control of the rotorcraft101. The pitch of the tail rotor blades111is changed by one or more tail rotor actuators. In some embodiments, the FBW system sends electrical signals to the tail rotor actuators or main rotor actuators to control flight of the rotorcraft.

Power is supplied to the main rotor system103and the anti-torque system by engines115. There may be one or more engines115, which may be controlled according to signals from the FBW system. The output of the engine115is provided to a driveshaft117, which is mechanically and operatively coupled to the rotor system103and the anti-torque system through a main rotor transmission119and a tail rotor transmission121, respectively.

The rotorcraft101further includes a fuselage125and tail section123. The tail section123may have other flight control devices such as horizontal or vertical stabilizers, rudders, elevators, or other control or stabilizing surfaces that are used to control or stabilize flight of the rotorcraft101. The fuselage125includes a cockpit127, which includes displays, controls, and instruments. It should be appreciated that even though rotorcraft101is depicted as having certain illustrated features, the rotorcraft101may have a variety of implementation-specific configurations. For instance, in some embodiments, cockpit127is configured to accommodate a pilot or a pilot and co-pilot, as illustrated. It is also contemplated, however, that rotorcraft101may be operated remotely, in which case cockpit127could be configured as a fully functioning cockpit to accommodate a pilot (and possibly a co-pilot as well) to provide for greater flexibility of use, or could be configured with a cockpit having limited functionality (e.g., a cockpit with accommodations for only one person who would function as the pilot operating perhaps with a remote co-pilot or who would function as a co-pilot or back-up pilot with the primary piloting functions being performed remotely). In yet other contemplated embodiments, rotorcraft101could be configured as an unmanned vehicle, in which case cockpit127could be eliminated entirely in order to save space and cost.

FIG. 2illustrates a fly-by-wire flight control system201for a rotorcraft according to some embodiments. A pilot may manipulate one or more pilot flight controls in order to control flight of the rotorcraft. The pilot flight controls may include manual controls such as a cyclic stick231in a cyclic control assembly217, a collective stick233in a collective control assembly219, and pedals239in a pedal control assembly221. Inputs provided by the pilot to the pilot flight controls may be transmitted mechanically and/or electronically (e.g., via the FBW flight control system) to flight control devices by the flight control system201. Flight control devices may represent devices operable to change the flight characteristics of the rotorcraft. Flight control devices on the rotorcraft may include mechanical and/or electrical systems operable to change the positions or angle of attack of the main rotor blades105and the tail rotor blades111or to change the power output of the engines115, as examples. Flight control devices include systems such as the swashplate107, tail rotor actuator113, and systems operable to control the engines115. The flight control system201may adjust the flight control devices independently of the flight crew in order to stabilize the rotorcraft, reduce workload of the flight crew, and the like. The flight control system201includes engine control computers (ECCUs)203, flight control computers (FCCs)205, and aircraft sensors207, which collectively adjust the flight control devices.

The flight control system201has one or more FCCs205. In some embodiments, multiple FCCs205are provided for redundancy. One or more modules within the FCCs205may be partially or wholly embodied as software and/or hardware for performing any functionality described herein. In embodiments where the flight control system201is a FBW flight control system, the FCCs205may analyze pilot inputs and dispatch corresponding commands to the ECCUs203, the tail rotor actuator113, and/or actuators for the swashplate107. Further, the FCCs205are configured and receive input commands from the pilot controls through sensors associated with each of the pilot flight controls. The input commands are received by measuring the positions of the pilot controls. The FCCs205also control tactile cueing commands to the pilot controls or display information in instruments on, for example, an instrument panel241.

The ECCUs203control the engines115. For example, the ECCUs203may vary the output power of the engines115to control the rotational speed of the main rotor blades or the tail rotor blades. The ECCUs203may control the output power of the engines115according to commands from the FCCs205, or may do so based on feedback such as measured RPM of the main rotor blades.

The aircraft sensors207are in communication with the FCCs205. The aircraft sensors207may include sensors for measuring a variety of rotorcraft systems, flight parameters, environmental conditions and the like. For example, the aircraft sensors207may include sensors for measuring airspeed, altitude, attitude, position, orientation, temperature, airspeed, vertical speed, and the like. Other sensors207could include sensors relying upon data or signals originating external to the rotorcraft, such as a global positioning system (GPS) sensor, a VHF Omnidirectional Range sensor, Instrument Landing System (ILS), and the like.

The cyclic control assembly217is connected to a cyclic trim assembly229having one or more cyclic position sensors211, one or more cyclic detent sensors235, and one or more cyclic actuators or cyclic trim motors209. The cyclic position sensors211measure the position of the cyclic stick231. In some embodiments, the cyclic stick231is a single control stick that moves along two axes and permits a pilot to control pitch, which is the vertical angle of the nose of the rotorcraft and roll, which is the side-to-side angle of the rotorcraft. In some embodiments, the cyclic control assembly217has separate cyclic position sensors211that measure roll and pitch separately. The cyclic position sensors211for detecting roll and pitch generate roll and pitch signals, respectively, (sometimes referred to as cyclic longitude and cyclic latitude signals, respectively) which are sent to the FCCs205, which controls the swashplate107, engines115, tail rotor109or related flight control devices.

The cyclic trim motors209are connected to the FCCs205, and receive signals from the FCCs205to move the cyclic stick231. In some embodiments, the FCCs205determine a suggested cyclic stick position for the cyclic stick231according to one or more of the collective stick position, the pedal position, the speed, altitude and attitude of the rotorcraft, the engine RPM, engine temperature, main rotor RPM, engine torque or other rotorcraft system conditions or flight conditions, or according to a predetermined function selected by the pilot. The suggested cyclic stick position is a position determined by the FCCs205to give a desired cyclic action. In some embodiments, the FCCs205send a suggested cyclic stick position signal indicating the suggested cyclic stick position to the cyclic trim motors209. While the FCCs205may command the cyclic trim motors209to move the cyclic stick231to a particular position (which would in turn drive actuators associated with swashplate107accordingly), the cyclic position sensors211detect the actual position of the cyclic stick231that is set by the cyclic trim motors209or input by the pilot, allowing the pilot to override the suggested cyclic stick position. The cyclic trim motor209is connected to the cyclic stick231so that the pilot may move the cyclic stick231while the trim motor is driving the cyclic stick231to override the suggested cyclic stick position. Thus, in some embodiments, the FCCs205receive a signal from the cyclic position sensors211indicating the actual cyclic stick position, and do not rely on the suggested cyclic stick position to command the swashplate107.

Similar to the cyclic control assembly217, the collective control assembly219is connected to a collective trim assembly225having one or more collective position sensors215, one or more collective detent sensors237, and one or more collective actuators or collective trim motors213. The collective position sensors215measure the position of a collective stick233in the collective control assembly219. In some embodiments, the collective stick233is a single control stick that moves along a single axis or with a lever type action. A collective position sensor215detects the position of the collective stick233and sends a collective position signal to the FCCs205, which controls engines115, swashplate actuators, or related flight control devices according to the collective position signal to control the vertical movement of the rotorcraft. In some embodiments, the FCCs205may send a power command signal to the ECCUs203and a collective command signal to the main rotor or swashplate actuators so that the angle of attack of the main blades is raised or lowered collectively, and the engine power is set to provide the needed power to keep the main rotor RPM substantially constant.

The collective trim motor213is connected to the FCCs205, and receives signals from the FCCs205to move the collective stick233. Similar to the determination of the suggested cyclic stick position, in some embodiments, the FCCs205determine a suggested collective stick position for the collective stick233according to one or more of the cyclic stick position, the pedal position, the speed, altitude and attitude of the rotorcraft, the engine RPM, engine temperature, main rotor RPM, engine torque or other rotorcraft system conditions or flight conditions, or according to a predetermined function selected by the pilot. The FCCs205generate the suggested collective stick position and send a corresponding suggested collective stick signal to the collective trim motors213to move the collective stick233to a particular position. The collective position sensors215detect the actual position of the collective stick233that is set by the collective trim motor213or input by the pilot, allowing the pilot to override the suggested collective stick position.

The pedal control assembly221has one or more pedal sensors227that measure the position of pedals or other input elements in the pedal control assembly221. In some embodiments, the pedal control assembly221is free of a trim motor or actuator, and may have a mechanical return element that centers the pedals when the pilot releases the pedals. In other embodiments, the pedal control assembly221has one or more trim motors that drive the pedal to a suggested pedal position according to a signal from the FCCs205. The pedal sensor227detects the position of the pedals239and sends a pedal position signal to the FCCs205, which controls the tail rotor109to cause the rotorcraft to yaw or rotate around a vertical axis.

The cyclic and collective trim motors209and213may drive the cyclic stick231and collective stick233, respectively, to suggested positions. The cyclic and collective trim motors209and213may drive the cyclic stick231and collective stick233, respectively, to suggested positions, but this movement capability may also be used to provide tactile cueing to a pilot. The trim motors209and213may push the respective stick in a particular direction when the pilot is moving the stick to indicate a particular condition. Since the FBW system mechanically disconnects the stick from one or more flight control devices, a pilot may not feel a hard stop, vibration, or other tactile cue that would be inherent in a stick that is mechanically connected to a flight control assembly. In some embodiments, the FCCs205may cause the trim motors209and213to push against a pilot command so that the pilot feels a resistive force, or may command one or more friction devices to provide friction felt when the pilot moves the stick. Thus, the FCCs205control the feel of a stick by providing pressure and/or friction on the stick.

Additionally, the cyclic control assembly217, collective control assembly219and/or pedal control assembly221may each have one or more detent sensors that determine whether the pilot is handling a particular control device. For example, the cyclic control assembly217may have a cyclic detent sensor235that determines that the pilot is holding the cyclic stick231, while the collective control assembly219has a collective detent sensor237that determines whether the pilot is holding the collective stick233. These detent sensors235,237detect motion and/or position of the respective control stick that is caused by pilot input, as opposed to motion and/or position caused by commands from the FCCs205, rotorcraft vibration, and the like, and provide feedback signals indicative of such to the FCCs205. When the FCCs205detect that a pilot has control of, or is manipulating, a particular control, the FCCs205may determine that stick to be out-of-detent (OOD). Likewise, the FCCs may determine that the stick is in-detent (ID) when the signals from the detent sensors indicate to the FCCs205that the pilot has released a particular stick. The FCCs205may provide different default control or automated commands to one or more flight systems based on the detent status of a particular stick or pilot control.

Moving now to the operational aspects of flight control system201,FIG. 3illustrates in a highly schematic fashion, a manner in which flight control system201may implement FBW functions as a series of inter-related feedback loops running certain control laws.FIG. 3representatively illustrates a three-loop flight control system201according to an embodiment. In some embodiments, elements of the three-loop flight control system201may be implemented at least partially by FCCs205. As shown inFIG. 3, however, all, some, or none of the components (301,303,305,307) of three-loop flight control system201could be located external or remote from the rotorcraft100and communicate to on-board devices through a network connection309.

The three-loop flight control system201ofFIG. 3has a pilot input311, an outer loop313, a rate (middle) loop315, an inner loop317, a decoupler319, and aircraft equipment321(corresponding, e.g., to flight control devices such as swashplate107, tail rotor transmission121, etc., to actuators (not shown) driving the flight control devices, to sensors such as aircraft sensors207, position sensors211,215, detent sensors235,237, etc., and the like).

In the example ofFIG. 3, a three-loop design separates the inner stabilization and rate feedback loops from outer guidance and tracking loops. The control law structure primarily assigns the overall stabilization task and related tasks of reducing pilot workload to inner loop317. Next, middle loop315provides rate augmentation. Outer loop313focuses on guidance and tracking tasks. Since inner loop317and rate loop315provide most of the stabilization, less control effort is required at the outer loop level. As representatively illustrated inFIG. 3, a switch322may be provided to turn outer loop flight augmentation on and off, as the tasks of outer loop313are not necessary for flight stabilization.

In some embodiments, the inner loop317and rate loop315include a set of gains and filters applied to roll/pitch/yaw 3-axis rate gyro and acceleration feedback sensors. Both the inner loop and rate loop may stay active, independent of various outer loop hold modes. Outer loop313may include cascaded layers of loops, including an attitude loop, a speed loop, a position loop, a vertical speed loop, an altitude loop, and a heading loop. In accordance with some embodiments, the control laws running in the illustrated loops allow for decoupling of otherwise coupled flight characteristics, which in turn may provide for more stable flight characteristics and reduced pilot workload. Furthermore, the outer loop313may allow for automated or semi-automated operation of certain high-level tasks or flight patterns, thus further relieving the pilot workload and allowing the pilot to focus on other matters including observation of the surrounding terrain.

FIG. 4illustrates flight control system201at a different level of abstraction. At its simplest, flight control system201can be considered to consist of a series of input device402feeding FCCs205, which in some embodiments can be thought of as a series of state machines running the control laws that control flight operations and which, in turn, drive actuators404to control various flight control device of hovercraft101. Sensors402can include a variety of different sensors. Sensors for sensing pilot commands can include (with reference toFIG. 2) cyclic position sensor211, collective position sensor215, pedal sensors227as well as sensors for detecting other pilot input including activation of a beep switch, activation of some other switch, touch on a touch sensitive contact surface, selection of a command menu item on a user interface, and the like. Sensors402can also include sensors207discussed above. WhileFIG. 4schematically illustrates output from sensors402being fed directly to FCCs205, one skilled in the art will recognize that in some embodiments, signal processing or logic circuitry may be interjacent sensors402and FCCs205, e.g. to convert the output of sensors402from an analog format to a digital format or to otherwise translate the format of data output by sensors402into a data format expected by FCCs205.

Actuators404may be hydraulic actuators, pneumatic actuators, mechanical actuators that include a driveshaft driven by a step motor, or the like. In the presently contemplated embodiments, actuators404include feedback elements, such as a position sensor, a hard stop position indicator, or the like (not illustrated as such elements are not necessary for an understanding of the illustrated embodiments), which in turn are another category of sensors402. Flight control devices406may include swash plate107, for adjusting the pitch of main rotor blades105, a gear box for adjusting the pitch of tail rotor blades111, a rudder, and the like.

Because flight control system201is responsible for numerous “mission critical” functions to maintain safe and expected control of hovercraft101, it is imperative that flight control system201has a high degree of reliability. Some governmental agencies impose reliability standards for mission critical type functions and systems such as flight control system201, and in particular the FCCs205upon which key components of the flight control system are implemented in the embodiments described herein. For instance, under guidelines of the United States' Federal Aviation Authority (FAA), certification of a rotorcraft requires establishing that the chances of a catastrophic failure are less than 10−9or stated another way less than one in ten billion In order to ensure such a high degree of reliability, several levels of redundancy and self-checking are built into the illustrative flight control system201and FCCs205described herein. As shown inFIG. 4, FCCs205may be implemented as several redundant FCCs,205-1,205-2and205-3. In the illustrated embodiments, each of the redundant FCCs is a mirror copy of the others and is nominally fully functioning at all times. Whereas three redundant FCCs are illustrated, as a matter of design choice two or more than three redundant FCCs could be used. Additionally, while 100% redundancy between the redundant FCCs is illustrated, in some embodiments, only a portion or portions of the FCC is replicated in a redundant portion or portions.

Operational tasks can be apportioned amongst the redundant FCCs in various ways. For example, in one embodiment, FCC205-1is the primary FCC and is responsible for all tasks, while FCCs205-2and205-3are merely back-up systems in the event that FCC205-1fails or is otherwise unable to perform operational tasks. In another embodiment, however, operational tasks are shared equally among each of the redundant FCCs205-1,205-2and205-3. In this way, the overall work load can be apportioned amongst the multiple computers, allowing each of the redundant computers to operate more efficiently and with little or no change of a single redundant FCC being overloaded in a scenario requiring inordinate tasks or processing.

Another level of redundancy is illustrated inFIG. 4, with each redundant FCC having a first processing lane408, sometimes referred to as a primary processing lane and a redundant processing lane410, sometimes referred to as a secondary processing lane. In some embodiments, primary processing lane408and secondary processing lane410are mirror images of each other. In the illustrated embodiment, however, primary processing lane408and secondary processing lane410differ, as will be discussed in more detail below.

One way in which primary processing lane408and secondary processing lane410do not differ is that each processing lane includes yet another level of redundancy. Reference is made toFIG. 5, which illustrates FCC205-1in greater detail. The following discussion applies equally to FCCs205-2and205-3. As shown inFIG. 5, each processing lane408,410has two separate processors operating in the lane. Processing lane408includes a first processor412, sometimes referred to as a command processor, and a second processor414, sometimes referred to as a monitor processor, for reasons that will be apparent in the following discussion. Likewise, processing lane410has a first or command processor416and a second or monitor processor418.

The term processor can have different meanings in different contexts, including within the confines of this disclosure. Without limiting the generality of the term processor, in the specific context of the illustration ofFIG. 5, processor refers to a microprocessor unit (typically but not mandatorily formed as a single-chip or multi-chip integrated circuit product) that, along with associated support logic, memory devices, etc., run preprogrammed instruction to perform desired operations of FCC205. Each processor412,414,416,418could be a general purpose microprocessor or microcontroller. In other embodiments, each processor412,414,416,418could be a special purpose processor, such as a digital signal processor.

In currently contemplated embodiments, processor412and processor414differ in a material way. Even though processor412and processor414are redundant processors, they are not identical processors. In order to increase the reliability of FCC205, different processors are chosen for processing lane408. In this way, an error (whether of design, or manufacture, or programming, etc.) that negatively impacts the reliability and/or performance of processor412is highly unlikely to also exist in a different processor414. In other words, if both processor412and processor414are the same product model, an inherent (albeit undetected) design or programming flaw in processor412will likewise also exist in processor414—meaning that if one processor fails under a certain set of conditions, the redundant processor will likewise fail under those conditions, thus rendering the redundancy ineffective. Similarly, if processor412and414are obtained from the same source, a latent manufacturing defect in one processor is likely to exist in the other processor, again rendering the redundancy ineffective. In order to minimize the risk of such circumstances occurring processing lane408is designed to have a first processor that is different in at least one material respect from its second, redundant processor. For instance, in one example, command processor412is a 32-bit floating point digital signal processor, such as a TSM320 series DSP available from Texas Instruments, Inc. of Dallas, Tex., and monitor processor414is a different 32-bit floating point processor, such as a Share DSP available from Analog Devices, Inc. of Norwood, Mass. In this embodiment, processors412and414are similar enough to be compatible, but are obtained from different sources (manufacturers) and hence have different designs and architecture implementation details. In other embodiments, the processors could differ in other material ways, such as different product families from the same manufacturer, or processors having different but compatible architectures, whether from the same or different sources. In yet other embodiments, the processors could have similar hardware components, but have significantly different software components, such as the compilers by which the respective processors decode instructions. One skilled in the art will recognize other respects in which the redundant processors can differ, while still being compatible, in such a way to avoid duplication of inherent defects, such as design, programming, or manufacturing flaws.

In some embodiments, redundant processing lane410could also include redundant processors416,418that differ in a material aspect. In the illustrated embodiment, however, redundant processing lane410is designed with two processors416,418that are “identical,” meaning for the purpose of this discussion that, in the absence of an error or defect, the same result will always be output from the first processor and the second microprocessor when the first processor and the second processor receive identical input data and run identical program steps on the identical input data. Although processors416,418might be identical to one another, to avoid the duplication of defect concerns discussed above, in a preferred embodiment, processors416and418differ in a material respect from one or both of processors412and414. For instance, processors416and418could be 32-bit floating point DSPs obtained from a different source, such as from Motorola, Inc. of Schaumburg, Ill.

One skilled in the art will recognize improved system reliability is provided by implementation of redundant processing lanes408and410, each of which including a redundant processors412,414and416,418, respectively. For instance, in one contemplated embodiment, processing lane408is considered the primary processing lane and handles the computational functions of FCC205. In the event that processing lane408fails—which is unlikely given that processing lane408itself has redundant processors—computation functions can be routed to secondary processing lane410without any loss of performance or functionality. Similarly, a switch-over can be implement if processors412and414, for instance, differ from one another by above a certain threshold, as discussed further below.FIG. 4also illustrates redundant busses and I/O circuitry420by which control signals generated by the processing lanes can be communicated, e.g., to actuators404.

Returning attention now to processing lane408, even though processor412is designated as a primary processor and processor414is designated as a monitor processor, in the design of the illustrated system, both processor412and processor414are fully functioning at all times. In other words, processor412and processor414are on “parallel paths” in the flow of data and commands within FCCs205. As a result of this configuration, a surprising and unintended consequence of using different processors412,414has been identified. As stated previously, both processor412and processor414receive identical input data (e.g., from sensors402) and run identical programs (e.g., the control laws by which fly-by-wire control signals are generated). Under these circumstances, one would expect identical results to be output from two processors running identical programs using identical input data, and under most circumstances, this is the case. Because processors412and414differ in at least one material respect, however, there are circumstances (rare, but statistically significant) under which the processors will output different results even when running the same programs on the same input data. As an example, pilot inputs, such as movement of the collective, the cyclic, etc., must be measured with a high degree of accuracy in order to ensure that the fly-by-wire system is highly responsive to pilot input. Similarly, flight characteristics such as attitude and changes in attitude of the three axes, the position of the various actuators404, and the like must also be measured with a high degree of accuracy. Hence, input data from the sensors (whether received directly from the sensors or received via intervening logic that reformats or otherwise modifies the sensor data) is input to FCCs205and hence to processors412,414with a high degree of accuracy. All or most of the computations that processors412,414perform on the data is likewise performed to a high degree of accuracy, and these computations may be performed simultaneously and in real-time on numerous different input values. While at a gross level (e.g., nearest integer or tenth of integer), one would expect all commercial processors to provide the same results when operating on the same input data, at the levels of accuracy required by FCCs205, instances arise where differences between the processors412,414can cause differences in the calculation results at the Nth degree of accuracy. When this occurs, processors412and414might output different results, which is referred to herein sometimes as a processor mismatch. Conventionally, a processor mismatch would be considered an error condition.

In a previously contemplated implementation of FCCs205, the outputs of command processor412and monitor processor414were both considered, meaning that under circumstances such as those described in the preceding paragraph, one processor might direct one action be taken while the other processor directs a different action be taken. In this event, FCCs205would declare primary processing lane408unreliable and switch processing authority over to secondary processing lane410. While this ability to switch over to a redundant path is a keystone for reliability, switching over un-necessarily (i.e. under conditions that do not truly reflect an error in the primary path) reduces the system's overall redundancy capability.

The present inventors have recognized that mismatches (of the type described above) between processor412and processor414occur only at the “margins” of the expected computational windows of these processors and that furthermore these “marginal” conditions are likely quite transitory. In other words, these processor mismatches arise because at the Nth decimal place of processing the input values the processors perform slightly differently. Note, however, that the input values represent real-world conditions such as the position of the pilot controls, the pitch of the craft, etc., and these real-world input conditions do not remain static for long at the Nth decimal place of accuracy. Hence, the inputs values that caused the processor mismatch are likely to be transitory and the processor mismatch is likely to resolve itself in short order if the processors are allowed to continue operating. If, on the other hand, any processor mismatch is considered to be an error condition and results in a switchover to a redundant system (processing lane), than the opportunity for the transient condition to be resolved is lost. In order to improve the overall reliability and performance of FCCs205, the presently disclosed embodiments are configured as follows. A first processor of a redundant processor pair is considered the command processor, such as processor412. A second processor of the redundant processor pair is considered the monitor processor, such a processor414. Both command processor412and secondary processor414receive (the same) input values and perform (the same) computations thereon to generate a desired output value or command. Assuming a typical condition, both command processor412and monitor processor414will generate the same output command. This output command will be acted upon by FCCs205, e.g., by generating appropriate control signals to activate actuators404to control flight control devices406. These output commands are generated for each time frame of FCCs205. In a non-limiting example, the frame rate is likely many frames or hundreds of frames per second. At a next time frame, command processor412may output the same command value as that generated in the previous frame. If monitor processor414likewise outputs the same value as the command processor, this command will continue to be acted upon. On the other hand, if monitor processor414outputs a different value than the command processor, a processor mismatch condition has arisen. In the event of a processor mismatch condition, FCC205will continue to act upon the previous output command, that being the most recent output command for which both command processor412and monitor processor414agreed. FCCs205will continue to act upon the previous output command until the processor mismatch condition is resolved, e.g., the command processor and the monitor processor otherwise output a same command value (in which case that same command value will be acted upon).

Similarly, consider the event wherein after the steady state, command processor412outputs a new command value, different from the previously generated command value (i.e., due to changes in pilot input, flight conditions, etc.). If monitor processor414also outputs the new command value, then the new command value will be acted upon by FCCs205. On the other hand, if monitor processor414continues to output the previous command value (or outputs some other command value that does not match the new command value being output by processor412), then a processor mismatch condition has arisen. In such a case, FCCs205will continue to act upon the previous output command, that being the most recent output command for which both command processor412and monitor processor414agreed. The mismatch condition will continue until the processors again output the same command value, in which case that same command value will be acted upon.

In summary, it is contemplated that command processor412and monitor processor414will output the same command value under most circumstances and FCCs205will implement that command. In the event of a mismatch condition, FCCs205will not change state, but will maintain the last state for which both command processor412and monitor processor414were in agreement. This is true regardless of whether command processor412has a changed output value, monitor processor414has a changed output value, or both processors have a changed output value.

The above discussion can be put in the context of flight control system201. As discussed above, flight control system201operates as a series of inter-related feedback loops running certain control laws to implement the various functions. The control laws can be implemented as state machines, wherein a state can be defined for various flight parameters and the state can change depending upon the input values from sensors402, etc. In an embodiment, command processor412functions as such a state machine, receives various input values from sensors402, etc., and outputs a state value in response thereto. Likewise monitor processor414also receives the input values and also outputs a state value corresponding thereto. The computed state value controls the manner in which FCCs205control flight control devices406, respond to pilot input commands, etc. As an example, if input from the various sensors indicate that hovercraft101is on the ground (e.g., sensors on the landing gear indicate weight on all wheels), then flight control system201will be in a GROUND state. On the contrary, if input from the sensors indicate hovercraft101is in flight (e.g., sensors on the landing gear indicating in air, etc.), then flight control system will be in a different state, such as perhaps a RATE state, a HEADING state, or some other state corresponding to the flight conditions. In the GROUND state, the hovercraft responds differently to sensor feedbacks than it would in a state indicating actual flight such a RATE or HEADING.

FIG. 6illustrates an example of the methodology for detecting and handling processor mismatch in an embodiment FCC205-1. In this embodiment, a state is determined for each of four axes of pilot input commands and governs how each axis responds to sensor feedback and pilot inputs. These four axes are COL, which is a state based upon flight conditions and inputs from the collective assembly219, LAT, which is a state based upon flight conditions and lateral inputs (roll) from the cyclic control assembly217, LON, which is a state based upon flight conditions and longitudinal inputs (pitch) from the cyclic control assembly217, and PEDAL, which is a state based upon flight conditions and inputs from the pedal assembly221. In a first step602, various inputs from sensors402and from collective assembly219are received at command processor412, from which command processor412determines the appropriate state condition for the COL input axis. This same input information is also received at monitor processor414and monitor processor414likewise determines the appropriate state condition for the COL input axis, as shown at606. The output command from command processor412is delayed by one frame as shown at604. One skilled in the art will recognize that a frame delay can be accomplished using a hardware buffer or the like, or could be accomplished in software using memory addressing Frame delay604is implemented in order to synchronize the outputs from command processor412and monitor processor414for comparison, which occurs at block608. Stated another way, the monitor processor calculates the state in one frame, which calculation is then sent to the command process in the next frame; the command processor must look back its previous frame in order to compare its calculation from the same frame as that received from the monitor processor. As an example, each processor can determine an appropriate state for the COL axis based upon the current flight conditions and the pilot input commands, as well as possibly other inputs such as commands from another control law loop (e.g., a higher level loop such as a flight director loop, auto-pilot loop, or the like). The determined state can be represented in various ways, such as an integer value corresponding to the state, a true/false value, a Boolean value, an alphanumeric string, or the like. In a currently contemplated embodiment, each relevant state has an integer value associated with it, and hence processor412and processor414each output an integer value corresponding to the state that the processors have determined to be the appropriate state for the relevant axis and control law loop.

As stated above, the state value, in this case integer value, output from command processor412is compared to the state value output from monitor processor414. In the illustrated embodiment, this comparison function is performed by command processor412. This is the reason for delay block604, to ensure that the comparison is for the same frame for each processor. In other words, there is a one frame delay for monitor processor414to determine the appropriate state value and output it to command processor412. Hence, in frame N, command processor412receives the state value from monitor processor414for frame N−1. Delay block604ensures that the state value output by command processor412at time frame N−1 is compared to the state value output by monitor processor414for the same time frame, in this case frame N−1. In other embodiments, the comparison function represented by block608could be performed in some other manner, including using special purpose logic hardware, or by some other processor of FCCs205.

The results of comparison step608are evaluated, as represented by decision block610. For instance, if it is determined that both processors are outputting the same state value, than the COL state from command processor412is considered valid and is acted upon, as indicated by line612and the state for the COL axis is updated, as indicated at block614. Note that updated does not necessarily mean a change in the state. For instance, if both command processor412and monitor processor414agreed in the prior frame that the COL state should be GROUND and also agree in the current frame that the COL state should be GROUND, then the “updated” state for COL remains unchanged. On the other hand, if both processors agreed in the prior frame that the COL state should be GROUND, but both now agree the COL state should be a HEAVE state, then the updated COL state614will be HEAVE. In the event that comparison step608results in a processor mismatch condition then as indicated by No branch616of decision block610, COL state614is not updated, and the system loops around to re-evaluate whether the processor mismatch condition is resolved in the next frame. Continuing with the example above, if command processor412and monitor processor414agreed in a previous frame that the COL state should be GROUND, and in the current frame one of the processors (but not both) now determines the COL state should a different state, the COL state will not be updated. This is true whether it is primary processor412or monitor processor414that outputs the new state value. Processing lane408will hold the current value for the COL state until either the processor mismatch is resolved by the processor falling back into synchronization or else an external processing branch (either hardware or software) determines that the processor mismatch has continued for an unacceptable period of time.

For instance, in some embodiments, a No decision in block610(indicating processor mismatch) might set a flag or error condition warning and also trigger a timer to start. If the processor mismatch condition has not been resolved within some acceptable period of time then a decision may be made, external to processing lane408, that the processor mismatch condition is not a mere transitory occurrence arising from the differences between processors412and414, but rather is a legitimate error condition requiring attention or remediation. Such remediation could include, among other things, switching functional operation over to secondary processing lane410. In some instances, a threshold in the difference in the result between two processors could be the determinant for a legitimate error condition, as opposed to a transient condition. In other instances, a combination of both duration and difference threshold could be employed.

In another embodiment, entrance into path616(indicating a No decision in block610) could cause a counter to increment (or decrement) and to continue to increment (or decrement) each time processing loops back through path616. Once the counter has incremented (or decremented) to either a defined value (or zero) this would indicate that the processor mismatch is a legitimate error condition requiring attention or remediation. One skilled in the art will recognize other manners in which processing during a processor mismatch condition could be monitored.

In some embodiments, other actions might be taken in response to a processor mismatch condition being detected at block610. For instance, some flight control systems might have a default state that is at least temporarily entered when a processor mismatch is detected. For example, every input axis has an AUG OFF state in which most high level (e.g., outer loop) control law functions are suspended. Flight control system201could, in some embodiments, set the appropriate axis into an AUG OFF state (or some other state) when detecting a processor mismatch, although care should be taken to ensure that such a method does not increase pilot workload or the likelihood of a negative impact on the system performance resulting from unexpected entry into an AUG OFF or other state. In other embodiments, detection of a processor mismatch could result in a signal being sent, e.g., to a pilot, or to some monitoring process that tracks statistical information such as frequency of processor mismatches, duration of such processor mismatches, trends in state transitions that are more likely to cause mismatch, etc. The results of the monitor process could be used to more effectively evaluate and respond to future processor mismatch conditions or to more quickly differentiate between a transitory (non-problematic) processor mismatch and a genuine error condition.

FIG. 6also shows a similar methodology is employed when determining a state for each of the other input axes. As an example, FCCs205receive various inputs relating to flight conditions as well as the longitudinal position of cyclic stick231from cyclic control assembly217, in order to determine the appropriate state condition for the LON input axis. As shown at618, command processor412receives the various input information and from that computes an appropriate state condition value. This same information is likewise received by monitor processor414and as shown at620monitor processor414also computes an appropriate state for the LON axis. The state values output by command processor412and monitor processor414are compared, block622, using a frame delay624to synchronize the outputs from the two processors. Similarly to the COL state analysis, a decision block626determines for the LON state whether to update the LON state628if the two processors agree or whether to maintain the current LON state if the two processors disagree. Likewise, a similar methodology is employed for the LAT state and for the PED state, as also shown inFIG. 6.

While the illustrated embodiment shows a microprocessor mismatch methodology for two processors determining a state condition relating to four axes of pilot input commands, one skilled in the art will recognize the same methodology could be employed in numerous other contexts whenever redundant processors are employed in a manner that their respective outputs can differ for reasons that are not related to actual errors in processing—such as when the processors' outputs differ in a transitory manner arising from rounding errors that are quickly resolved or the like. One example would be calculation of stick detents (i.e., whether a pilot is exerting control over the craft through, e.g., the cyclic and/or collective) based upon calculations applied to stick sensor data. The above-described processes are not limited to these examples, however.

The processes for the four input axes are illustrated as separate “paths” inFIG. 6. This is for simplicity of illustration only. In actual implementations, these various processes will be performed more or less simultaneously with an updated state value being computed in each frame for each of the four input axes.

An advantageous feature of the methodologies described herein is that transitory processor mismatches that occur only at the margins of computations and that are not indicative of a true error condition can be accepted without impacting system performance or reliability and without causing un-necessary switchovers to redundant processing lanes. The result is improved reliability and robustness of the system.