Columnist: September 2, 1996

This month, I present an example of a neuro-fuzzy system, which consists of a dozen fuzzy rule bases driving a single neural network. In addition to looking at the system configuration, I also describe the design process that resulted in this union of fuzzy-rule-base and neural-network technologies.

The design task was to implement a replacement for a three-axis, nine-channel, linear controller responsible for driving the channels of a controlled system to their individual, commanded setpoints. The initial design team consisted of a technical lead (who doubled as the systems engineer); two programmers experienced in writing C and assembly-language code for embedded-processor systems; and a hardware engineer who was responsible for identifying the appropriate VME cards, power supplies, and other "hard" components. The project was important to the company, and the technical lead reported directly to the director of engineering. I joined them later.Figure 1 shows the system configuration: both the controller, implemented using analog electronics, and the controlled system.

Desired system operation is typical for a feedback controller. For each channel, a summing point derives an error signal by subtracting the output of the controlled system from the commanded value. The controller for that channel uses this error signal as an input. Each channel's transfer function forces the closed-loop behavior of the controlled system.

Over time, the company's service engineers had gathered operating data from fielded systems. Once compiled, this data indicated regions of nonlinearity in the operating space of the controlled system. Furthermore, the analysis showed that accounting for—rather than ignoring—these nonlinearities would result in a significant improvement in performance. A series of piecewise-linear, analog-controller prototypes initially looked promising but did not achieve the desired results.

This is when I joined the team. My initial task was to perform a feasibility study on using a fuzzy-rule-based controller to replace the linear system. Based on the results of that study, the director of engineering invited me to assist the technical lead in the detailed design of the controller. After some interaction, we settled on the configuration in Figure 2: nine fuzzy controllers (FCs), each replacing one of the nine linear controllers, and three fuzzy mappers (FMs), each of which maps controlled system outputs into values appropriate for the controllers.Figure 2 also shows the necessary addition of a differentiator (D) and an integrator (I) to each channel.

In fairly short order, the team arrived at a fuzzy-rule-based implementation that exactly simulated the linear system. By working with the rules and membership functions, we then "tuned" the 12 FCs to handle the measured nonlinearities. After successfully testing the controller under simulation on the development host system, we cross-compiled the code and downloaded it to the multiprocessor target.

We then confronted our first real problem. As we tested the controller attached to the actual (not simulated) controlled system, additional nonlinear regions surfaced. We easily handled these by further tuning the individual rule bases. However, we also discovered some completely unexpected interchannel dependencies. Actively driving one channel while holding the other eight constant occasionally resulted in activity on one or more of the nondriven channels.

The existence of interchannel coupling had not been recognized, or even observed, with the previous linear design. Why the coupling existed was not well-understood—actually, at this stage in the effort, no one understood it at all.

After much observation, analysis, and scratching of heads, we settled on another approach (Figure 3). The intent was for an additional module to decouple the channels by sensing and correcting all interchannel dependencies. For example, if the output from FC₂ cross-couples to channel 1 of the controlled system, the decoupler drives the channel 1 input appropriately to counter the effect of the interaction.

Although conceptually straightforward, the decision of how to implement the decoupler caused a flurry of political battles. Ultimately, the fact that no one really understood why interchannel coupling existed gave us the answer. The team had no expertise concerning the problem, but we certainly could gather data. We decided to use a neural-net-based decoupler, and the technical lead had the clout necessary to sell the decision to management.

First, we needed to know the extent of the coupling. Functional testing showed it was limited to fairly small regions in the input space, but we needed to pin down the region boundaries. We connected the controlled system to a test jig with nine computer-controlled channels. For each data-gathering iteration, the computer held one channel's input at a constant value and monitored its output while it wiggled the eight other inputs one after the other. If the monitored output also wiggled, the computer recorded both the input values and the strength of dependency. The computer then stepped the input to a next constant value, and the procedure repeated.

Data gathering and reduction ran for approximately 24 hours and showed that each channel was susceptible to interchannel coupling over approximately 2% of its operating range. We also got a better feel for why the dependencies had not been evident when using the linear controllers; the error inherent in assuming a nonlinear system to be linear had masked them.

The next data-gathering phase was limited to those input-space regions in which coupling occurred. This second phase consisted of determining the necessary change in input to a given channel that would counter the effects of cross-coupling from other channels. If an increase in input IN₂ cross-couples and drives OUT₁ in the same direction, then the decoupler must drive input IN₁ to counter the cross-coupling, with the intent of keeping OUT₁ constant (Figure 4).

Correcting interchannel dependencies in this manner can be dangerous. For example, the decoupler decreases IN₁ to counter an increase in OUT₁ due to a coupled increase in IN₂. This decrease in IN₁ causes a decrease in OUT₂ and a corresponding (decoupler-driven) increase in IN₂. Because of this positive feedback, both channels 1 and 2 either quickly saturate or (with the correct phase shift) oscillate. Fortunately, we were lucky—the correction of no two pairs of coupled channels resulted in system instability.

We were lucky a second time. The controlled loop necessary to remove channel interdependencies appeared mostly free of inertial effects. This meant that, although the FCs needed to work with derivative, integral, and proportional data, the decoupler needed only proportional data. This situation was fortunate, because it greatly reduced the amount of required training data, the time necessary to gather it, the size of the neural network, and the time needed to train it.

The test jig collected a full set of training data, which we used to train the neural net. We then rigorously tested the system, connected to an actual controlled system with actual loads. This testing took place more than a year ago, and I assume that the controller is still part of the company's current product line.

A reasonable question would be why a neural network alone was not used for the entire controller. Couldn't all 12 fuzzy rule bases have been eliminated? We definitely considered doing so. However, we deemed the size of a single neural net capable of providing overall control to be too large to run on the set of µPs used in the re-quired sampling interval.

Next time, I shall discuss how a neural network can be used to assist in the design of a fuzzy-rule-based system. As always, your interaction is appreciated—keep those cards and letters coming.