Asynchronous Flight Control Systems

Вариант № 25

Задание. Перевести данный текст на русский язык.

Примечание.В тексте содержится рисунок. Необходимо выполнить перевод слов, находящихся в нем, непосредственно под ним.

Например, processors – процессоры.

Asynchronous Flight Control Systems

Asynchronous digital fault-tolerant flight control systems arose in the 1980s. They exploit the fact that the control laws that run on them are periodic in nature and that they sample inputs and produce actuator outputs. Therefore, if the channels are allowed to drift apart (i.e. no clock synchronization), then they will never really drift more than the sample period apart (e.g. 40 ms), because once they get a full frame apart the channels are once again sampling the sensors at the same time.

Voting in an asynchronous architecture is built around the idea that the rate of change of output value is bounded and that the sensor data can be separated in time by no more the period of the sample rate. This is illustrated below

Asynchronous Flight Control Systems - student2.ru

Therefore the error between the outputs is:

Asynchronous Flight Control Systems - student2.ru

where Tf = sensor sample period, and max (df/dt) = the maximum rate of change of the output function. If the control laws are stable then the output differences will be bounded if the input differences are bounded. Using these bounds, thresholds can be set at the voters. The mid-value from the channels is used to drive the actuators and if the difference between an output and the mid-value exceeds the threshold then the channel is declared as failed.

But eventually the designers have to deal with the fact that the control laws have state variables associated with them (e.g. integrator variables). So although the input variables are re-aligned once a channel drifts a full period apart, the integrator variables are one iteration step apart! So inevitably in these architectures the designers end up using cross-channel strapping and data synchronization techniques. So this is typically handled by performing data synchronization at the application level. For example Y.C. Yeh of the Boeing Commercial Aircraft Company describes how this is done for the Boeing 777:

“The potential for functional asymmetry, which can lead to disagreement among digital computing systems, is dealt with via frame and data synchronizationand median value selection of the PFC’s output commands”.

So although the original design was built around the concept of no clock synchronization between the channels, they end up synchronizing anyway. But, instead of solving this problem at a lower level of the system in an applicationindependent way, the problem is solved at the application level while dealing with a lot of other issues. In other words, there is no separation of concerns. It is possible to defer the issue of synchronizing the channels, but eventually this issue must be at solved at some higher level of the system.

Наши рекомендации