GB2280287A - Computer control system - Google Patents

Abstract

A computer control system, especially for flight control comprises a series of computer modules FEU operating parallel and asynchronously to carry out respective ports of an overall control algorithm for a series of control functions. Each module FEU has a data transmission port I/L1, 2 etc. connected by a broadcast line to a respective input port of each other computer module. Communication between the modules is thereby achieved by any module broadcasting asynchronous data messages onto its broadcast line enabling messages to be received by any other module which requires them. <IMAGE>

Description

COPUTEK CONTROL SYSTEMS This invention relates to computer control systetns, more particularly but not exclusively to flight control computers for aircraft.

According to one aspect of the invention, there is provided a computer control system for controlling a plurality of actuators, for example a series of flight control actuators on board an aircraft, the computer control system comprising a plurality of actuator drive and monitoring units for forming signals for controlling said actuators and for monitoring the operation of said actuators, and a computer system connected to receive monitoring information from and to control the operation of said drive and monitoring units, the computer system comprising a plurality of computer modules operable for carrying out respective control law functions associated with the proper control of said actuators, for example aircraft attitude calculations such as pitch, roll and yaw calculations, each such module comprising a data transmission unit connected to a respective serial data broadcasting line which is in turn connected to a respective data receiving unit in each other module, whereby coiwnunication between modules is achieved by any of said modules broadcasting asynchronous data messages onto its data broadcasting line for this data message to be received by any other module which requires it.

Further aspects of the invention, and advantageous and preferred features of the first and said further aspects, will appear in the following description of an exemplary embodinent of the invention, the description making reference by way of example to the accompanying drawings, in which: figure 1 is a block diagram of a flight control computer system, figure 2 is a block diagram of a computer used in the figure 1 system, figure 3 is a block diagrams of an actuator drive and monitoring unit used in the figure 1 system, figure 4 is a simplified circuit diagram of an interface unit used in the figure 2 computer, figure 5 is a simplified circuit diagram of a first computing module used in the figure 2 computer, figure 6 is a simplified circuit diagram of a second computing module used in the figure 2 computer, figure 7 is a simplified circuit diagram of an actuator drive module used in the figure 2 computer, and figures 8 to 14 are respective diagrams for illustrating the operation of modules used in the figure 2 computer.

The following description is of a flight control computer based on Asynchronous Multiprocessor techniques. A quadruplex cross monitored system is used, each lane running asynchronously. Each computing lane comprises ten independent processing modules running asynchronously in parallel. The control law task is partitioned amony seven processors while two are dedicated to actuator monitoring and one to pre-flight testing. The processing module is based on the TMS 320 signal processor.

A comnon strategy is used for both inter-module and interlane comnunications. This is multiplex serial digital running at 10 Mbits/sec. Each link is single source, multisink, autonomous and fully asynchronous at the transmitter and receivers, buffered with dual port memories. The fra;ne size is selectable up to 128 words.

Fibre optic links may be used betweeii lanes and between computers and ADUs (if these are separate units).

Failure management is based on the normal accepted methods of sensor cross monitoring and consolidation. A quaruplex actuator is assumed and this is also cross monitored. Additional self test facilities are included for pre-flight test and maintenance purposes and for certain in flight monitoring functions.

The architecture of the System allows the actuator drive electronics to be packaged eit'ner within the Flight Control Computers or as one or two separate Actuator Drive Units.

A quadruplex system has been assumed - sensors, computers and actuators - except for certain sensors and actuators which are at a lower level of redundancy. There is provision for twelve servo drives per lane. One DEF STAN 0018 data bus terminal is included in each conputer; it is assumed two will interface to the avionics buses and two to the general services buses. All computers are identical in hardware and software, any lane dependency being controlled by the aircraft wiring.

The design is based on a number of identical microprocessor processing modules, each of which cornmunicates with other elements of the system using asynchronous serial digital transmission. Each processing module is a stand alone computer operatiny in parallel with, but asynchronously with respect to, the others. The total computing task is partitioned among the processors; this covers control laws, sensor monitoring, actuator monitoring and built-in testing (BIT). Additional hardware is provided for sensor interfaces, actuator drives and DEF STAN 0018 data bus interfaces.

The computer comprises three distinct sections, a main computing section and two actuator drive sections. The computing section receives all sensor data, performs voter monitoring and control laws and outputs control surface position demands to the actuator drive sections. It also includes pre-flight test (PFT) and data bus interface functions. Each actuator section provides actuator drive, loop closure and monitoring for up to six actuators. Each section has its own interlane connunications and has only fairly restricted communications with the other sections. This allows the actuator drive sections to be divorced from the Flight Control Computers (FCC) and repackayed as one or two separate Actuator Drive Units (ADU) (if the airframe configuation dictated it) without any impact on the system design. See Fig. 1. The computing section comprises: (a) A Front End Unit (FEU) This is a communications node for all sensor information coming into the computer and also for information returned from the ADUs. All data associated with that lane (from Aircraft Motion Sensor Units, Air Data Computers and sensors, inceptors and discrete switches) is interfaced in the FEU and combined into a single serial data stream. This is routed to all other lanes and is also available to all the modules in its own computing section.

(b) Processing Modules Eight processing modules are available in the computing section.

One will be dedicated to PFT functions while the others perform control law calculations, including voter/monitors. Each processor iterates its own programne at maximum speed, unrelated to any other module. Control law tasks are partitioned between the modules such that the most time critical tasks are performed by lightly loaded processors and hence at the fastest iteration rates.

Each module can have access to the outputs of any other module and to the total system sensor data (all four lanes). Where appropriate a modules outputs include control surface demands; in addition to their normal routing the outputs of these modules are taken to the actuator drives. See Fig. 2.

(c) DEF STAN 0018 Module This module has access to all data in the same way as the processing modules. This data is available for output to the data bus and data received from the bus is made available to all modules via the FEU.

The actuator drive sections each comprise: (a) Six servo drives These receive the control surface demands from the computing section, interface actuator and surface position pick-offs and provide analogue loop closure of first and second stage feedbacks. The demands and pick-off signals are transmitted to the monitor module. See Fig. 3.

(b) A monitor module This is a standard processing module. It receives control surface demands and pick-off data from the servo drives, exchanges it wit?0 the other three lanes and performs high speed cross monitoring of the computer outputs, actuators and pick-offs. It controls the actuator shut-off valve and transmits status information back to the computing section via the FEU.

A common communications method is used throughout the system.

This is serial digital at 10 Mbits/sec. Each link is single source, multi sink and is fully asynchronous at the transmitter and receivers, buffered using Dual Port Memories (DPM). In order to meet the different needs of the various links, the frame size is hardware selectable up to 128 words.

Computer Design Cosmunication System The communications format chosen is common to all communications links within the flight control system. It has been designed to suit all forms of interlane and intermodule comnuni cat i ons dictated by the choice of architecture and control law partitioning.

An important feature of the comms. is the single source, multisink broadcast approach allowing flexibility of design and expansion of the system (if necessary) with no change to format and minimal hardware change to increase data length.

The chosen format is an asynchronous digital serial transmission running at 10 tibits/sec with return to zero coding, buffered at both ends by dual port memory.

Digital phase locked loop technology is used to recover the transmission clock and a unique sequence at the beginning of each data word allows resynching of the recovered clock prior -to clocking of any data into the receivers shift register and data latch. DPLL technology dictates that the receiviny circuitry runs at 40 MHz.

To keep throughput times to a minimum the communication format is tailored to suit each requirement by hardware presetting of the data (frame) length to 16, 32, 64 or 128 words, before recycling.

One word consists of 27 bits length oryanised as follows: 2 Bits New Word Sequence 7 Bits Address Code 1 Bit Address parity 16 Bits Data 1 Bit Data parity The inclusion of address coding within the word negates the need for any frame synching and simplifies the facility for user presetting the data cycle. In addition the integrity of the communications is improved, and the possibility of incorrect loading of data into DPM reduced. Any parity errors detected will prevent over writing of data in DPM.

Inter-lane communication may use 128 word length and the intennodule comnis. 16, 32 or 64 word length.

The asynchronicity of the system calls for buffering of the communication by DPM. This in turn necessitates assignments of priorities should contentions occur.

The clockwork arrangenent of the transmission system requires readily available data - therefore the comnunications transmitter will always have priority over a microprocessor write command to the DPM in contention.

The Front End Unit (Fig. 4) This unit acts as the comnunications node for each lane of the system.

To obtain data frorn the outside world there are five fibre optic receivers taking in digital data streams from the AMSU, ADC1, ADC2, ADU1 and ADU2. Additionally there are eight analogue inputs from pilots controls that are multiplexed to make use of the single analogue to digital converter. Finally sixteen discrete inputs (eight optically isolated) complete the outside world receivers. All these data signals are latched into dual port memory and read out as required by the clockwork interlane comnunications control circuit. This consists of a TX ULA with the internal counter reset, set at 128. Instead of the address bus addressing the DPM directly as is the case for the standard communications strategy, it is used to sequentially address the sin flight' PROM.

The data held at each location in this PROM contains the dual port memory sub address and chip select code of each data word to be included in the inter-lane traffic.

Thus any necessary reconfiguring of the inter-lane data traffic is easily achieved by i.e. programning this PROM.

Additional in-lane data to yo out as inter-lane traffic is catered for by a bank of nine intermodule communication RX ULAs and associated dual port memories. Eight of these are connected to the general purpose computing modules in the lane and the remaining one to the data bus card. Thus by suitable prograimiing of the 'in-flight' PROM any data word from the intermodule corns network can also be put out as inter-lane data.

The inter-lane data is then taken to three fibre optic transmitters, one each for lanes 2, 3 and 4. Incoming inter-lane data is received by three fibre optic receivers and fed to the back plane as digital serial data transmissions together with its own inter-lane data as IlL1, IlL2, I/L3 and IlL4.

In the 1st line test mode the in-flight PROM Is substituted by another PROM which can be prograrrmed to enable substitution of air data and pilot commands by synthesised data which is put out by the PFT card and then routed onto the inter-lane traffic in the relevant time slots by this PROM This enables dynamic testing and autornatic surface response testing as necessary for 1st line tests.

Processing Module (Fig. 5) This is configured as a stand-alone computer card. The computing section consisting of a microprocessor (TMS 32010) and host circuitry, 16K x 16 EPROM containing power on PFT and flight resident software and 2K x 16 working RAM.

The board clock is an 80 MHz crystal oscillator with divider circuitry as follows: t2 = 40 MHz to run RX ULAS 4 4 = 20 MHz to run TMS 320 8 8 = 10 MHz to run TX ULAS There are eight RX ULAS and associated dual port memory, dictated by the control law partitioning. In most cases the backplane patching of these receivers (see Fig 2, FCC Architecture) is configured as four inter-lane and four inter-module receivers, although any one can behave as inter-module or inter-lane without any onboard modifications.

Additionally there are eight discrete inputs and eight discrete outputs, application of which varies with module function.

The computed data is transmitted from the board by a standard ULA TX and DPM configuration, and routed to all other modules requiring the data. On board selection of the address counter reset sets the data frame size and ensures minimum transmission cycle times for the inter-module comnunications.

Failure management circuitry on the module incorporates a watchdog timer to detect system clock and processor failure.

The timer consists of a 16 bit counter controlled by an independent 1 MHz clock giving a timing range of 65.536 mS in 1S steps. The timer is reset by the microprocessor writing to a specific address (CS13) at the end of each program cycle. The output of this counter is fed to a magnitude comparator which compares it with the 16 x 1 ROM o/p containing the correct board cycle time proyramned in ps. If the timer count exceeds the ROM value, the counter is inhibited and a module fail condition is set. An external reset line is provided to guard against lock up or power up and provide PFT control of the circuit.

Dormant failure of the watchdog timer clock is avoided by using the microprocessor to read the counter at two different tirnes within a program cycle. Interrogation of these two values by the processor will produce a module failure discrete if the values are identical, indicating a watchdog timer clock failure.

This failure discrete will also be set if the ROM checksum test fails during PFT or in flight.

Def. Stan. 0018 Module (Fiy. 6) This module provides facilities to collate status and failure information; it interfaces to a Def. Stan. 0018 data bus and to status lights on the pilot's control panels.

Voter monitor and self test status information, is received by standard module receivers and dual port memory from the four inter-lane links. Module failure discretes from their watchdog timers are received at a 16 bit latch.

The infor1nation is collated by a processor and support circuitry to produce failure information which may be transmitted onto the associated data bus via a suitable interface and/or used to drive failure warning lights in the cockpit (via a 16 bit latch) if appropriate.

Data received from the data bus is transmitted to the FEU to be put onto the inter-lane traffic by a standard module transmitter.

Actuator Drive (fig. 7) Each actuator drive module provides the system with an interface to two control surface actuators.

The drive module receives control surface position demand signals from a single processing module via an asynchronous receiver of the same design as used on the processing modules.

The data stream includes the total processing module's output and the actuator drive module includes the means of selecting the correct data. The two addresses (one for each potential drive signal) are held in two 8 bit PROMs. The incoming address is compared with the stored addresses in two 8 bit comparators; if the received data is valid and the address matches then it is latched and converted to analogue form.

The module provides for excitation and demodulation of surface, actuator and servo valve position pick-offs. The actuator and surface position signals are summed with the control surface demand signal in the servo drive amplifier to give analogue loop closure.

The demodulated feedback signals, together with servo valve position and surface demand signals, of the two drives are multiplexed to the input of a single A/D converter.

The digitized outputs are transmitted by a standard asynchronous link to the actuator monitor module.

The drive module also contains the logic and buffering to control the actuators' solenoid valves, driven by discrete outputs from the monitor module. An actuator failure signal from the monitor will cause the appropriate actuator to be isolated; a monitor failure signal will cause both actuators to be isolated.

Failure Management The system is designed to provide the following features: (a) a two fail operate capability (b) indication to pilot of any failures which reduce redundancy or affect performance (c) indication of all faults to a centralized maintenance data recording system Failure management relies on cross monitoring and this is done at two distinct points during the processing. Sensor, transducer and control failures will be detected by voter monitor (V/M) algorithms which form part of the flight resident software in the various processor modules. The processor outputs, actuators and actuator pick-offs are monitored by the actuator monitor module. All fault information will be routed to the data bus module for distribution.

Sensors and Controls Each sensor and control signal is routed to only one FCC. The inputs are received by the FEU formatted and retransmitted to the other lanes. The appropriate processing module in each FCC thus has access to all four lanes of sensor data and can perform VIM functions. These functions are spread across the processing modules, a particular sensor being handled in the processor which uses that sensor signal. The V/Ms are vital to the failure management process and are discussed in more detail below.

Since the FEU and processing modules within an FCC are largely independent, a large number of independent/dissimilar failures can be survived. In particular, no failure in any other module can prevent the FEU from supplying sensor inputs to the other lances.

Upon identification of a failure by a V/M, the faulty input will be latched out. Consolidated signals based on surviving good inputs will be used for control purposes. Fault indications will be output by the processing module for action by the data bus module.

Some sensor data will be pre-processed before reaching the FCC e.g. the AMSU and ADC data. The processors in the AMSUs and ADCs will include BIT and will generate status information. In flight this data will not be used actively for failure management but will be recorded. (A possible exception is the air data system where a combination of cross monitoring and BIT information may be used).

Any failures within an FCC will be detected elsewhere in the system, either in other lanes or at its own actuator monitor module. Some BIT functions are included in some modules e.g.

power supply monitor, watchdog timer. In the event of a fault being detected these may take local action and shut down the individual module but the overall system failure management relies on detecting the failure elsewhere. The BIT information is used for maintenance purposes.

Actuator Monitor Quadruplex actuators are assumed, having no mechnical failure isolation capability. A single hardover failure could be survived, but in order to survive two failures it is necessary to isolate a failed lane electrically. This is achieved using solenoid valves controlled by the actuator monitor module.

For integrity, each lane will be able to isolate only itself.

Each monitor module will receive control surface demand and actuator feedbacks from its own actuator drive card, and similar data relating to the other three lanes from their monitor modules via dedicated inter-lane data links.

V/M algorithms will detect failures in individual lanes.

Failures in a monitor module's own lane, due either to an actuator failure or an FCC failure, will cause it to de-energise the appropriate solenoid valve. All lanes will report the failure to their own FCC.

Failures of the monitor modules themselves will be identified by self test (e.g. ROM check sum and watchdog timer) and will cause de-energisation of all solenoids controlled by that monitor.

Voter Monitor Algorithms Voter Monitor algorithms are central to failure management.

They are required to detect and isolate faults and to produce consolidated outputs from surviving "good" inputs. Their design Inust miniinise failure transients at their output and in aircraft response.

Some of the considerations for voter monitor (V/M) design are: (a) vnchronous Lane Operation The V/Ms must accept discrepancies due to time skew effects on incoming data, resulting from asynchronous operation. Time skew discrepancies will be additional to the normal tolerances on measured variables.

Failure detection thresholds will be determined by the following: (A) Tolerances on correctly - functioning sensors/tranducers (B) The maximum rate of change of each input in normal operation (C) The magnitude of the time skews (b) Sophistication/Speed Trade-Off The magnitude of the aircraft's response to a failure transient will depend on (among other things) the magnitude of the failure transient on the V/Ms output signal and the iteration rate of the V/M.

A sophisticated algorithm may reduce the output transient but would take longer to run, i.e. the iteration rate would be reduced and the transient would persist longer. Thus there is a trade-off between V/M sophistication and speed of operation.

(c) Wait Before Disconnect Nuisance disconnects may be reduced by waiting for one or more cycles of the V/M, during which a faulty input must remain faulty, before switchiny out the input. Unfortunately a failure transient will exist at the output for the duration of the waiting period.

If a second like failure occurs during the waiting period, a two-versus-two situation may develop. For this reason it is desirable to minimise any waiting periods.

The waiting period of the V/Ms must be optimised to resist nuisance disconnects while minimising the likelihood of a two-versus-two situation.

(d) Resets Pilot resets of first failure will be allowed. Resets of second failures will not be allowed: these could result in a two-versus-two situation at the V/Ms. (NB. the use of self-test status words to resolve a two-versus-two situation may be considered).

(e) Algorithms Separate algorithms may be required to deal with four, three and two-input cases. Alternatively a self-adaptive algorithm could be used.

A different type of consolidation process will be required for discrete inputs.

(f) Power Up The V/Ms must bring good inputs on-line during power up.

If the FCS is required to survive in-flight power interrupts, provision must be made for the V/Ms to reconnect good inputs as the system recovers.

Appendix shows a typical voter monitor implementation.

Failure Indication Failure must be indicated to the pilot and to the central maintenance data system. This function will be carried out by the data bus module in each FCC.

The voter monitors will generate fail-status words, identifying the failure, which will be communicated to the data bus module via the inter-module communication system. Self-test status words for AMSUs, etc. will also be received by the data bus module. The watchdog timer on the general purpose module will produce a failure discrete which will be wired direct to the module.

The module will process the various failure indications and output them to its databus, hence to the maintenance data system (and possibly to an accident data recorder). The multifunction display drivers will also receive the failure indications and will cause the appropriate diaynostic display to be made available to the pilot.

FCS status and warning data must be available to the pilot even in the event of complete loss of the databus system. This will be achieved by dedicated warning lights, by lights on the cockpit control warning panel, and by a master attention getter.

All these will be illuminated by dedicated wiring from the module. Logic on the modules will cause the appropriate lights to illuminate.

Hardware logic associated with the warning lights will ensure that they are not illuminated by a single, faulty, databus module.

Each FCC has a databus module two FCCs interface with the avionics databus and two with the utilities bus. There is typically data exchange between the avionics and utilities buses: thus failure indications will continue to be available on both buses even after two module failures.

Amber and red warnings will be provided. Amber warnings indicate a loss of redundancy: red warnings indicate a second like failure, and may be accompanied by an audio warning.

Non-safety-critical/failures, e.g. leading edge flaps, will result in an amber warning.

Built in Test The function of fault detection, isolation and indication in flight are a normal part of multiplex system operation. They rely largely on cross monitoring and are implemented in the voter-monitor alogorithms in the flight resident software (FRS).

Built in test (BIT) is included in the systern primarily for assuriny the serviceability of the system before flight (Pre Flight Test PFT) and to aid maintenance. This is covered below.

However, certain BIT functions operate continuously in flight; these are described below.

Sensors The AMSUs and ADCs will probably include their own processing and will perform self-test routines during flight. Status words will be output which will be available to the FCC. Fault information output by the AMSUs will not be for action by the FCC since any failures will be detected and isolated by the voter monitors.

The FCC will probably use a combination of status information from the ADCs and cross monitoring techniques to select the best air data infonnation.

Computing Modules The general purpose computing modules will contain a small amount of BIT hardware in the form of a watchdog timer. This is dictated by the need to guard against dormant failures of the monitor. If the watchdog timer detects a malfunction of the processor then the solenoid valve will be deselected causing the actuator to fail soft.

Failures detected by the watchdog timers on other modules in the FCCs will result in failure discrete being passed to the module.

No other action is taken by the watchdog timer: the faulty module's outputs will be eliminated in voter monitors downstream or disconnected by the monitor module. Watchdog timers on individual modules will be pre-programme be left to V/Ms in other modules to detect a particular modules failures. ROM checksums may be implemented for executing during running of the FRS, but will slow down the execution of the FRS.

However, they may be justified in certain individual modules, e.g. the actuator monitor module.

Data Bus Module Data passing between the FCCs and the aircraft's databuses (in both directions) will be monitored for parity checks. Status words will also be checked. Both tests will be carried out in the data bus modules. The general purpose modules in the FCCs will use data from the 1553B databuses only if it has been accepted by the module.

Discrepancies will cause the FCCs to ignore the data and fail safe.

Any two modules are required to illuminate FCS warning lights.

Thus false warninys will appear only after certain like failures of two modules.

Power Supply Unit The power supply unit will consolidate the two or more independent aircraft power supplies and condition them for use by the other modules in the FCCs. Loss of individual power supplies will not cause the FCC to fail, but the failure must be reported (for maintenance action at least). In the event of a single supply failure, the power supply unit will generate a discrete which will be received by the module.

Total power supply failure in an FCC will of course result in the loss of that FCC.

The power supply unit will energise the pilot's input transducers and other controls. Failure here will be detected as the loss of an input, but BIT Is required to ensure that the failure is traced to the correct LRU (i.e. to the FCC rather than to the transducers in this case).

Power supply built-in tests will all be carried out by hardware.

Pre Flight Tests Strategy Pre-flight testing is a basic minimum of tests required to show that the FCS is serviceable for flight. Although for peacetime operations "serviceable" will mean that 100 of the flight-critical elements of the FCC are fully operational. In wartime it may be necessary to be able to fly with known failures.

Since PFT will include "active" tests of sensors, actuators, etc. it must be carefully isolated in flight. This will be achieved by a combination of weight-on-wheels interlocks and software which can only be entered on power up. It is an aim that modifications to flight-resident software should require a minimum of modification to PFT routines.

The strategy adopted for PFT is as follows: (a) Check the operation of each processor (b) Check the presence of all software (c) Check the operation of all communications links (d) Rely on local BIT for AMSU, ADC, etc.

(e) Exercise actuators (f) Monitor pilot's controls ) interactive ) with (g) Check power supply by consolidation ) pilot There is no intention to verify the correct functioning of failure management software during PFT. This will be validated on a test rig. A ROM check to ensure that the software is present and correct is considered adequate for PFT.

Processor checks PFT will be initiated automatically on power up. Each processing module will enter a small section of PFT software designed to self test the processor. This will perform the following: (a) RAM read/write check (b) ROM checksum (c) Arithmetic check Coimnunications Checks The PFT will then continue under the control of the PFT module, which will coordinate tests of the inter-module and inter-lane communications system.

Synchronization across lanes will be achieved by each PFT module outputing a word to the PFT modules in the other lanes and receiving identical words from the other PFT modules. Failure to receive words froin one or more PFT modules will cause a failure to be indicated.

The PFT modules, now synchronised, will instruct all the other modules in the FCCs to write agreed words to all of their output dual-port memory locations. Each module will then inspect its input DPMs: failure to receive the correct data-word in every DPM location will cause the modules to stop. Failure by the PFT module to receive "OK" signals from the other modules will cause a failure to be flagged.

Comns. failures will result in the PFT modules outputting a failure discrete to the modules.

PFT of AMSUs, ADCs AMSUs and ADCs will initiate their own PFT routines on power up.

Satisfactory completion of these tests will result in status words being transmitted to the modules and the PFT modules in the FCCs. Failure to receive satisfactory status words within an allotted time interval will cause the FCCs to indicate a failure.

Pilot Interactive Tests The automatic tests described above will be followed by a number of pilot interactive tests which will be coordinated by the PFT modules. The illuminated PFT button will be flashed each time a pilot action is required.

The interactive tests will include: (a) Actuator Range Checks.

The FCS will cycle the control surface actuators to check range of travel, correct operation of feedback transducers, etc.

Actuator rates will not be tested because responses may be slow at this stage due to cold hydraulic fluid. (Rate tests can be carried out during First Line Tests).

(b) Stick and Rudder Pedal Checks.

The pilot will cycle the stick and rudder pedals while the FCS checks for full input ranges. This will be carried out by the PFT modules.

(c) Power Supply Checks The pilot will switch off the individual FCS power supplies one at a tine to test the correct functioning of the consolidation hardware in the FCCs, AMSUs, etc.

Completion of Tests On completion of the pilot interactive tests, the PFT module will be powered down as a guard against its operation in flight.

Operation of the FCS reset button will then cause all the computing modules to enter the flight-resident software (FRS).

First line test software will also reside with the PFT software.

FLT will be executed if the PFT button is pressed (instead of the reset button) at the end of the interactive tests.

Choice of Processor There are three possible options for the processor used in the computing modules: (a) a general purpose microprocessor such as the 68008 or Z8002 etc.

(b) a specialized high speed processor such as the Texas TMS 320 or Fujitsu MB8764.

(c) a custom or semi-custom processor designed specifically.

The use of a specialized control instruction set (CIS) sucii as that described later herein is assumed. In either of the first two options the processor would emulate a CIS processor: the control laws would be written in CIS which would be interpreted by the processor at run time to produce calls to the set of predefined kernel routes.

At first sight this would appear to involve a large overhead in both memory requirernents and processing time. However, usually the program for each module is sufficiently small that the memory requirements are minimal in any case. Some hardware penalty may be incurred if a separate ROM is used for the instruction set routines: this may be considered desirable for integrity reasons. The overhead in processing time is also not likely to be significant since most of the instructions involve a substantial proportion of arithmetic.

General Purpose Processors There are many possible general purpose 16 bit processors which would be used within a module. Their advantages are availability and ease of use; however they are limited in performance.

The 68008 and Z8002 are the particular processors best matched to the requirement and are very similar in performance for this application. This performance may be barely adequate however.

Although one could theoretically partition the control laws in smaller segments and use more modules the gain can be offset by the additional lags due to more intermodule communications.

One problem with general purpose processors is integrity. Using military versions guarantees quality of manufacture but not integrity of design. The processors have powerful instruction sets and it would be tempting to use this to optimise the coding of the CIS. However, in order to be able to validate the implementation of the CIS to a high level of integrity, it is desirable to use as small a subset as possible of the processor's instruction set, avoiding as far as possible interrupts and flags, which are considered the most unreliable areas.

High Speed Processors A number of high speed processors are now coming onto the market, designed primarily for signal processing applications and are closer to the ideal architecture of an AMPS processor.

The TMS 320 is a particularly suitable example.

The architecture of the processor is very similar to that of a bit slice system, having all the advantages but contained in one easily supported package. It utilises hardware to implement many functions that the more general 16 bit microprocessors perform in software i.e. within the package is a hardware multiplier capable of performing multiplication in 1 200 nS cycle (+ 200 ns for latching). The processor is also internally a true 32 bit machine - its ALU being quite capable of supporting 32 bit double precision arithmetic.

The instruction set of the TMS 320 should be quite capable of producing a CIS emulation which would easily fit into the 3K of an chip ROM. This would have the great advantage of customising the chip as a CIS machine.

The disadvantage of this particular type of chip is that because of its specialist nature it has not been used very often and hence knowledge about reliability is not readily available.

Custom/Semi-Custom Processor There are two alternatives to using existing processors running CIS emulations: (a) customize an existing processor by micro-coding the CIS as the instruction set.

(b) design a new processor specifically for implementing the CIS.

The approach in (a) would give some improvement in speed but a customized Z8002, for example, would still be nowhere near as fast as a TMS 320 running an emulation. One of the aims of going to a custom chip is to improve integrity through careful design. In this case there would be little improvement since the integrity is constrained by the existing design. The design task would be difficult and expensive, with very little gain.

The second approach, outlined in (b), promises much more, it is, in fact, a natural extension of the custom communications chip/chip set. The chip could be designed to have the minimum amount of logic necessary to run the CIS as its native mode, with many of the CIS features (such as saturation) built directly into the silicon. The design task should be simpler in integrity and testability at the design stage should lead to high integrity.

The speed of the processor will obviously depend on the technology chosen, but it should be at least as good as existing signal processors. The cost of producing such a processor will be high, but so will the gains.

Processor For an EFA application current general purpose processors have barely adequate performance. The use of a fast signal processor will increase processing speed to a point where it no longer dominates total system lags; the lags due to the AMSU and asynchronous comnunications now being of the same order.

In particular the TMS 320 has the advantage that it is already being used within the AMSU's for the EAP control system; this experience should generate confidence in its integrity. It is therefore recommended at this time.

In the longer term a custom processor may give benefits and its feasibility should be pursued.

Control Law Partitioning Partitioning of a set of a set of control-laws has been done to satisfy the following: (i) Signals requiring a minimum delay must not be delayed by those for which a larger lag is not so critical.

(ii) Each module should contain if possible, a simple and easily identifiable set of controls.

It is not possible to consider the partitioning of the control laws in isolation from processing speed and required signal throughput times. The module divisions shown here are for TMS 320 processing and a target time of 3 msec throughput delay for pitch rate from gyro to actuator.

The control laws and failure management facilities have been split into the following modules: (i) Pitch (Fig. 8) - contains the signal paths of the primary pitch axis feedbacks.

(ii) Roll (Fig. 9) - contains the signal paths of the primary roll axis feedbacks and outputs these to the pitch and yaw modules to be combined into actuator drive signals.

(iii) Yaw/Nose Wheel Steering (Fig. 10) - contains the signal paths of the primary yaw axis feedbacks.

(iv) Pilot's Controls (Fig. 11) - contains the initial conditioning of pilots control inputs before feeding them to the relevant axis control module. Extra inputs which do not have such demanding delay and iteration criteria could be handled by this module.

(v) Intakes/Leading Edge (Fig. 12) - contains the signal paths of all signals providing direct input to controlling these surfaces. Intake and foreplane angle are assumed to have been consolidated at the monitor module (vi) before this point, CAS is assumed to be simplex.

(vi) Feedback monitor (Fig. 13) - this module forms a major part of the system failure management. It contains the voter monitoring processes for the actuator feedbacks and provides consolidated inner and outer loop feedbacks on its own lane.

Also it reports all detected failures to the module and provides "soft fail" control if it detects a fault in its own lane.

(vii) Air Data/Gains (Fig. 14) - this module provides gain factors to the other modules, rather than those modules calculating their own scheduled gains. The gains are calculated by "carpet plots" or "look up tables", working from consolidated data.

(viii) PFT - This is used to co-ordinate pre-flight and first line tests.

It may also be necessary to have an autopilot module.

The system architecture permits a wide choice of signal throughput times, depending upon the partitioning. It may therefore prove advisable in the future to put the pilot's controls onto the relevant axis control modules in order to use one less module. This however would increase the throughput .times of the aircraft motion feedback signals.

Timing calculations are based upon an implementation on a Z8002 processor running at 8 MHz; an alternative processor, the TMS 320, is assumed to be a factor of 10 faster. It is assumed that structural filtering is done in the AMSU's.

The CIS concept represents an integrated hardware/software approach to flight critical computing which is aimed at radically reducing the software process in terms of both coding and validation - the main problem of current high-integrity systems. The extra processing capacity provided by the AMPs multiprocessor architecture provides an ideal opportunity for the specification of a new programming language which is aimed directly at control law work.

One of the main problems involved in control law software hitherto was that, typically, algorithm design was undertaken by a different team to that which did the computer coding. This not only caused a large increase in cost but also presented timescale problems when the software required alteration. There was also the problem that, for every new processor used in the control environment, a new group of software experts was required to encode the control laws. Fundamental to the whole process was the considerable effort involved in documentation and validation.

A major consideration in the initial design of the Control Instruction Set (CIS) was the thought of limiting the role of software experts and leaving the control designers to code up their own algorithms. To achieve this, one obviously needs to define a language which is not only suitably high level such that the designer does not have to be an expert programner, but also suitably low level as to be simple, to run quickly, to be easy to implement on any micro-processor and, possibly, to form the instruction set for a custom built high-integrity micro.

Modularity is a key element in the AMPS concept. In particular, there are modular computing cards which divide into functional sub-sections of processing and I/O. All connections to the processor are memory-mapped and, so, knowledge of the working of such areas is not required by the software encoder. As far as the hardware is concerned, it does not matter (except for speed and specific support circuits) what microprocessor is running on the module. If the processor is running an emulation of a CIS-type processor, then the programmer need not even be aware of the hardware module design in any way. The only time that an experienced software expert will be required is for the machine code programming of the CIS processor emulation.

So the philosophy behind the CIS is: 1. To simplify the initial coding of control laws.

2. To reduce timescales involved in altering the laws at a later date.

3. To reduce the cost of producing the final product; and 4. To allow the control designer to write/modify his own software in an environment that is independent of the hardware specification.

The control language should behave, as follows: 1. Control algorithms will be represented by continous signal flow diagrams - composed of a small number of component elements, e.g. add, subtract, integrate, look-up etc. - which can be translated directly into the CIS by the designer himself.

2. Interactions between each instruction are minimal since no flags exist within the system and, so, the programmer need only worry about the obvious operation of each instruction.

3. Branches and jumps within the software are not allowed.

Rather than executing some of the instructions some of the time, as is normal in high level languages or machine code, the CIS always executes all instructions, the behaviour of the program being determined by the way that data flows through the software. This technique assists the checking of the required software function since there is no complex tree structure to take into account.

Within the CIS there is only one data type, represented by a 32-bit word. This is always accessed indirectly by address, at present defined to be 16 bits but this could be expanded if required. A constant is treated in exactly the same way as a variable in software, the only difference being that "constant" addresses will always be held in ROM, whereas variable addresses will be in RAM. Some consideration has been given to the possibility of fixing the field size of the instructions but although this is desirable it will only be done if size of memory is not a problem. If it were done then the job of a program sequencer would be reduced to that of a counter and no look-up would be required to calculate its increment.

The 32 bits used for each data word are partitioned as follows: 1 bit for sign 15 bits for values before the decimal point 16 bits for values after the decimal point It is hoped that this technique will solve many of the sealing problems involved in control algorithms and, at the same time, increase the accuracy of calculation. Since no flags occur within the CIS, the programmer has no way of handling overflows, but this problem is overcome by constraining all the variables to saturate in a similar way to an analogue system.

Claims (1)

1. A computer control system For control 1 ins a plurality of actuators, For

   examPle a series of flisht control actuators on board an aircraft. the coMputer control srste comprising a Pluralit^ cf actuator drive and monitoring the operation of said actuators and a coMPuter S Y5 system connected to receive monitoring information fro and to control the oPeration of said drive and monitoring units , the computer system t CM comprisins a PluralitY of computer modules operable For carrYins out respective control law functions associated with the ProPer control of said actuators, for example aircraft attitude calculations such as pitch, roll a Yaw calculations, each such module coMPrisins a data transmission unit connected to a respective serial data broadcastins line which is in turn connected to a respective data receivers unit in each other module.

   whereby communication between modules is achieved bv any of said modules broadcastins asynchronous data messases onto its data broadcassing line fci this data messase to be received by ans other module which requires it.

   Amendments to the claims have been filed as follows 1 A computer control system for controlling a plurality of actuators comprising a plurality of actuator drive and monitoring units for forming actuator control signals for controlling said actuators and for monitoring the operation of said actuators, and a computer system connected to receive monitoring information from and to control the operation of said drive and monitoring units, the computer system comprising a plurality of computer modules operable for carrying out respective control law functions associated with the proper control of said actuators, each such module comprising a data transmission unit including means for forming data serially and digitally into frames each of a preset number of predetermined bit length words and connected to a respective serial data broadcasting line which is in turn connected to a respective data receiving unit, including a dual port memory for buffering received data and a digital phase locked loop clock recovery circuit, in each other module, whereby communication between modules is achieved by any of said modules repetitively and aEynchronounly broadcasting frames of digital data messages each including a multi it address code and a frame start sequence of bits onto its data broadcasting line for this data message to be received by all other modules but acted upon only by that module having a corresponding address.