Report on visit to Airbus Industrie - 28-29th Jan. 1993

From:         Pete Mellor <pm@cs.city.ac.uk>
Date:         15 Feb 93 16:05:54 PST
Followups:    1
Next article
View raw article
  or MIME structure


          Report on visit to Airbus Industrie - 28-29th Jan. 1993
          -------------------------------------------------------

                                                          Peter Mellor
                                                          ------------ 

1. Introduction
--------------- 

Following the distribution of the first draft of our paper ``The Airbus A320 
Electronic Flight Control System'' [1] to (among others) Andrew McClymont of 
AI's Office of Airworthiness, I received an invitation to visit AI in 
Toulouse to discuss its contents with the experts face-to-face, in order to  
shorten the process of comment and redraft. 

The following is an account of the various meetings and presentations which 
took place over two days on 28th and 29th January 1993.  


2. Programme 
------------ 

28th January: 

0830 - Welcome, Introduction and Video ``Progress in Control'' 

0915 - Presentation by Aerospatiale (AS): 

       A320/A30/A340 Flying Control System Architecture 
       EFCS Software Life Cycle 
       System Specification Method (``SAO'') 
       Software Development Methodology 
       Quality Assurance 
       Certification Aspects 

1230 - Lunch (AIB Cafeteria) 

1400 - Depart to AS - Visit System Integration Facilities 

1600 - Discussion 

1730 - Depart to Hotel 


29th January: 

0830 - Review Draft EFCS report 

1230 - Lunch at ``The Club'' 

1400 - Depart, or review outstanding items if required 


At least, that was the plan! The driver was a bit late picking us up on 
the Thursday morning, so we did not start until 0900. The discussions went 
on far longer than anyone expected, and the visit to AS started late. The 
discussion scheduled for 1600 on Thursday therefore took place on Friday 
morning, and the review of the document and discussion of points arising 
dragged on until around 1800 on Friday. 


3. People Involved
------------------ 

Peter Potocki de Montalk (Department Manager, Cockpit Avionics, AI), was the 
main host and had arranged the meeting. (His name is pronounced ``Pot-ot-ski'' 
and is of Polish origin. He is English.) Peter is the author of ``Computer 
Software in Civil Aircraft'' [2]. 

Andrew McClymont (Director, Office of Airworthiness, AI), another of the 
British ex-pats in Toulouse, and the man in AI to whom I originally sent the 
first draft of the paper [1]. 

Dominique Briere (Head of Flight Control Department, Technical Direction, 
Toulouse Plants, Aircraft Division, AS). 

Gerard Ladier (Airborne Computer Software, Test and Integration Laboratory, 
Engineering Management, A/DET/EI/LE, AS). 

Jean-Michel Nogue, Software Quality Assurance, A/DET/SY/SQIP, Aircraft 
Division, AS). 

Pascal Traverse (Design Office, Systems Safety, A/DET/SY, AS), to whom I also 
sent a copy of the first draft [1]. He is the author or co-author of several 
papers on avionics software e.g., [3], [4]. I had met him on several occasions 
in the past at meetings and workshops. 

Denis Ribot (Airborne Computer Software, Test and Integration Laboratory, 
Engineering Management, A/DET/EI/LE, AS). 


The guests were myself and: 

Daniel J. Hawkes (Head of Avionics Design, CAA) who has been heavily involved 
in the type-certification of the A320 and A340. 



4. Video: ``Progress in Control''
--------------------------------- 

This was shown to set the scene, and provide background information. It 
describes the flight characteristics of the A320/A330/A340, the protections 
provided by the EFCS, and the cockpit instruments and controls. The presenter 
was the late Gordon Corps, the British test pilot who did much of the flight 
testing of the A300-600, A310 and A320, and who sadly died of altitude sickness 
last August while returning from a visit the crash site of the A300 which came 
down near Katmandu. 

The video was full of technical detail and made a number of interesting 
points, including the fact that the EFCS provides neutral stability (the 
aircraft maintains its pitch and bank angles if the pilots take their hands 
off the controls). 

The same flight deck design is used in the A320, A330 and A340, to minimise 
retraining of pilots. 

Since the meeting, I have been provided with a copy of this video. 



5. Presentations 
---------------- 

The presentations were based on those given to the authorities in the course 
of the A340 certification. Aerospatiale has recently been more concerned with 
the development of the A340 and A330, and the presentations therefore focused 
on the systems in these later aircraft rather than the earlier A320. However, 
a lot of technical detail about the A320 EFCS emerged in discussion. Only a 
brief overview can be given in this report. 

The A340 received its type certificate on 22nd December 1992, and the A330 
is expected to be certified in March 1993. 

The A340/A330 FCPC (Flight Control Primary Computer) corresponds to the A320 
ELAC (Elevator and Aileron Computer), and the A340/A330 FCSC (Flight Control 
Secondary Computer) corresponds to the A320 SEC (Spoiler and Elevator 
Computer). 



5.1 Flight Controls System Architecture (P. Traverse)
----------------------------------------------------- 

The function of the EFCS is to move the aerodynamic surfaces in response 
to orders from the crew or auto-pilot. It is an ``Electrical'' Flight Control 
System, not ``electronic''. (This term is used since ``electronic'' systems 
have traditionally been the responsibility of radio engineers, whereas flight 
controls have been the province of mechanical engineers. It is a distinction 
based on ``turf'' or areas of technical responsibility.) 

Electrical signalling of the hydraulic actuators saves weight and cost, and 
allows digital computer control to improve ``pilotability'' and safety (e.g., 
stall and overspeed protections). (Some actuators are mechanically signalled 
in response to input from the crew.) 

The EFCS ``slaves'' the surfaces using two feedback loops, a servoloop which 
returns information on the state of the actuators and the actual positions of 
the surfaces, and an outer loop which returns information on the state of 
whole aircraft via the air data and inertial reference system (ADIRS). 

The building block of the EFCS (and many other systems on the A3xx family) is 
the Command and Monitoring fail-safe (or fail-passive) computer, which has been 
in use for around 30 years. (One of the points that was repeatedly stressed 
was that the design approach used on the A320 is ``evolutionary'' not 
``revolutionary'': the ideas have been introduced gradually over many years, 
building on experience with many models of aircraft.) 

This device consists of two channels, each with its own microprocessor, RAM, 
ROM, watchdog timer, I/O ports and power supply. The two channels are 
electrically separated and physically separated by a bulkhead. Each channel 
contains its own software, diversely developed to the same functional 
specification, and the output of the command channel is compared to the 
output of the monitor channel. Any mismatch or time-out results in a shut-down 
of the one computer. There is an asymmetry between the command and monitor 
channels due to the existence of time-dependent functions in the servoloop. 

The design is intended to ensure that the only failure mode is ``stop'', after 
which other computers in the EFCS take over the function (possibly with a 
change in the flight control laws and a degradation of automatic protection). 

The EFCS life cycle involves requirements capture resulting in an equipment 
specification, including hardware, software, and functional specifications. 
The pilot is very definitely ``in the loop'' for requirements capture, which 
is an iterative process using rapid prototyping and flight tests. Emphasis 
is placed on validation of functional requirements, which is clearly 
distinguished from verification. 

The tool used to express functional requirements is ``Specification Assiste par 
Ordinateur'' (SAO) or ``Computer Aided Specification''. This tool is far more 
powerful than I had previously realised. It allows the precise definition of 
sequences of control actions in graphical form with a library of symbols 
to represent individual actions such as integrate, switch, etc. An SAO 
spec. consists of a number of sheets, with the signals flowing from left to 
right. SAO automatically cross-refers inputs on the left of one sheet with 
outputs from the right of the sheets that feed into it, and also provides 
configuration control. The SAO functional spec. (which can be used for 
hardware or software) is the interface between the ``equipment world'' and 
the ``aircraft world''. There are no intermediate design stages: code is 
derived directly from the SAO diagrams, either by automatic generation or by 
hand. 

SAO allows the inclusion of software probes for monitoring of signals 
during execution on a test-bench. The software is flown with the probes 
in place. 

The dependability requirements for the system involve quantitative assessment 
of the hardware only (to 10^-9). Software is assessed qualitatively to 
level 1 of RTCA/DO-178A [5]. The validation of the software is done by 
specification peer reviews, system safety analysis (analysis of failure 
conditions), performance analysis, and analysis of interaction with the 
structure. The control laws are tested with a real-time simulator connected 
to a simplified pilot desk. The complete system is tested on a time-expanded 
simulator to check response to various inputs. 

The individual computer is tested on a partial test-bench with input simulation 
and monitoring of internal variables via the software probes. The ``iron bird'' 
and flight simulator are used to test the whole system before ``heavy'' 
flight tests during which 10000 EFCS parameters are recorded. 

This approach was used within AS to develop the A320 SEC and the A340 FCSC 
(Flight Control Secondary Computer) software. The A320 ELAC (hardware and 
software) was developed separately by Thompson-CSF, and was not described 
in the same amount of detail. 



5.2 FCSC S/W Development - Organisational Aspects (D. Ribot) 
------------------------------------------------------------ 

The management structure of the AS Design Management (A/DET) organisation 
was explained at various levels. The ``coal face'' is the Atelier Logiciel 
(Software Workshop) within the Test and Integration Laboratory (A/DET/EI) 
which acts as if it were an external supplier of software to the rest of the 
organisation. In particular, software quality assurance is provided externally 
to the laboratory by software quality experts within the System Design 
organisation (A/DET/SY), which is the other wing of Design Management. 

70% of the flight control software corresponds to functions defined in SAO,  
which is the part most prone to evolve during development and deals with logic, 
control laws and I/O. 

The system designer in A/DET/SY is responsible for defining the global system 
requirements, and can animate an SAO spec. in order to refine these. The 
software designer in the software workshop generates software to meet the 
requirements defined in SAO, and must do so with a lead time consistent with 
the flight test schedule. 



5.3 FCSC S/W Development - Method and Quality Assurance (G. Ladier) 
------------------------------------------------------------------- 

The Method and Quality Assurance team defines the development rules (with the 
development teams' involvement) and ensures they are followed. It participates 
in progress meetings and reviews and ``spreads the experience'' outside the 
department (e.g., to the system design teams in A/DET/SY) in order to help 
them avoid problems. They help the developers with the choice of practices 
and tools, ensure coordination of general tasks linked to the use of ADA, 
analyse metrics to do with reliability, cost and schedule of software, and 
participate as embedded software experts in the DO178 [5] review. 

Together with the development teams, they develop internal guidelines and 
standards. 

Three-monthly quality reviews are carried out. The emphasis is on quality 
before, not after, the fact. It was stated that no bugs had been found in 
the software after flight test. 



5.4 FCSC S/W Development - The FCSC Software (D. Ribot) 
------------------------------------------------------- 

The command and monitor lane teams work separately and have different managers 
both reporting to the project manager. The emphasis is on diverse development. 

To achieve diversity, the development of hardware and software for the A320 
and A340 was contracted out as follows:- 


Aircraft    Computer   Chip       H/W Development   S/W Development
--------    --------   -----      ---------------   --------------- 

A320:       ELAC       Motorola   Thompson-CSF      Thompson-CSF 
                       68000 

            SEC        Intel      SFENA             Aerospatiale
                       80186                        Atelier Logiciel

A340:       FCPC       Intel      Aerospatiale      Aerospatiale
                       80386      ADL               Atelier Logiciel

            FCSC       Intel      Sextant           Aerospatiale 
                       80186      Avionique         Atelier Logiciel


The merger of SFENA, Thompson-CSF Aviation Group, EAS and another to form 
Sextant Avionique has meant that a certain degree of diversity was lost for 
the A340 as compared with the A320. This has had to be addressed internally. 

The A320 ELAC contains 3 Motorola 68000 chips in the Command channel: 

- the main processor, which receives the pilots' commands and deals with the 
  servo controls, 

- the ARINC processor, dedicated to handling I/O on the ARINC 429 buss, and

- the co-processor, which handles the flight control laws. 

The Monitor channel has a similar internal architecture. Both channels are 
programmed in Macro-assembler (MASS), but development rules are in place to 
ensure dissimilarity. 

The A320 SEC contains 2 Intel 80186 chips and 1 Intel 8086:- 

- the main processor, which receives pilots' orders and handles the flight 
  control laws, 

- the ARINC automaton, which handles I/O on the buss, and 

- the servo-loop processor (8086) which deals with servo control. 

Again, the Monitor channel has a similar internal architecture, and both 
channels are programmed in Macro-assembler. (I *think* this is accurate. 
The SEC resembles the FCSC in some ways, and the FCSC monitor channel is 
programmed in Pascal and assembler. - To be checked!) 

The A320 FCDC is not a command and monitor computer, but consists of a 
single 68000. The SAO derived part of the program is written in C, and 
the H/W interface part is written in assembler. 

FCSC software (like SEC software) is developed on a Digital Equipment 
Corporation VAX running VMS and equipped with VS2000 and VS31000 workstations 
on an ethernet. The object code can be burned into a PROM, or rather a set of 
6 PROMs contained in an ``On-Board Replaceable Module'' (OBRM). This is simply 
slotted into the back of the FCSC (or SEC). The FCPC (and ELAC) can be 
similarly loaded with new software. The OBRM is the means of inserting new 
software into the EFCS both during development and test and in order to carry 
out field upgrades. 

The compiled FCSC code can be run in 4 emulators under the control of a 
HP9000 for initial testing, and is then conveyed in its OBRM to an FCSC 
connected to an integration rig. It undergoes further testing on this and 
subsequently on the ``iron bird'' prior to flight testing. 

The FCSC (and SEC) software operates in discrete cycles in response to a 
real time interrupt from a ``sequencer''. There is no reentrant code, and 
no parallelism. On each cycle, a given set of modules must be executed, and 
the maximum execution time for each set is computed in advance, and checked 
during testing. In 2 years of ground tests, the execution of the modules has 
never been known to overrun the cycle time. 



5.5 Aerospatiale Software Quality Assurance (J-M. Noguet) 
---------------------------------------------------------

This is performed at the Aircraft Manufacturer level, treating the software 
development organisation as if it were an outside contractor. This SQA is 
different from the QA within software development, and is intended to ensure 
compliance with specification and with relevant standards, including DO178A [5] 
and various internal standards. 

It proceeds by a series of formal reviews at different stages of the life cycle. 


5.6 Certification Aspects 
------------------------- 

There was no formal presentation on this, but during many discussions, the 
certification of the A320 was explained. The basis for certification is 
described in a thick book [6] which comprises all the relevant JAR regulations 
and the related interpretive material. The initial certification was done by 
a ``college'' of 4 authorities: those of UK, France, Germany and The 
Netherlands. 

What is certified is an *aircraft*. The systems on it are qualified in the 
course of a demonstration that they will not compromise the safety of the 
aircraft as a whole. The emphasis is on function. For example, the reliability 
of an individual SEC or ELAC is of the order of 10^-3 to 10^-4. The 
architecture of the EFCS as a whole ensures that the control of the aircraft 
can be assured to the famous 10^-9 limit. (This is with regard to hardware 
failure. No reliability number is assigned to software, nor to any other 
design aspect.) 

It was interesting to note, however, that nobody to whom I spoke believed 
that ``reliability = 1'' for any part of any system, although they are not 
aware of any method of demonstrating such high reliability figures for 
software. In fact, I was given a copy of a paper [6] which argued the 
impossibility of so doing, using arguments similar to those employed by 
Littlewood and Strigini[7], with which paper everyone was also familiar. 

One interesting aside was that the 10^-9 figure is justified within the JAA 
by an argument that I do not believe is used by the FAA. It depends on actual 
statistics, which indicate that the probability of an aircraft crash is about 
10^-7 per flying hour. Given that there may be around 100 critical systems on 
any aircraft (on the A320 there are 68) the additional factor of 10^-2 is 
applied to allow for the fact that *any one* of them may fail catastrophically. 
This justification is contained in one of the JAR interpretive documents. 



6. Visit to Aerospatiale 
------------------------ 

This included a visit to the software integration rig on which FCSC software 
is tested while being monitored by the SPATIAAL tool and generally probed in 
other ways. 

The ``iron bird'' simulators for both the A320 and A340 were active. We went 
around that for the A340. This is a rigid mock-up of the aircraft with all 
hydraulic and electrical systems laid out as on the real aircraft, and weights 
attached to provide resistance to the hydraulic actuators. The FCS is tested 
in this rig, with all the software running in its target machines, under a 
variety of simulated conditions, e.g., wind gusts, etc. (There was some 
discussion about which ``standard gust'' is currently in favour for 
simulation.) 

There was also the A340 cockpit simulator with its computer-generated view of 
Toulouse and its surroundings. I was treated to a ``flight'' in this, and 
made a pig's ear of attempting to land, when I was allowed to take over the 
controls. I didn't actually crash into the ground, but had to attempt a go 
around after the 'plane veered off the line of the runway and my attempts to 
correct it resulted in a crazy banking angle. The consensus was, however, that 
if a bit more detail had been available on the display, I would have found that 
I had just flown through the control tower! 



7. Review and Discussions 
------------------------- 

The second day was taken up with general discussions of points raised, and a 
detailed review of the draft [1]. A number of mistakes were pointed out and 
technical details clarified, many of which I have already referred to above. 

The third draft of our paper is now about to get under way. 



Glossary 
--------

ADIRS Air Data and Inertial Reference System

AI    Airbus Industrie 

AS    Aerospatiale 

EFCS  Electrical Flight Control System 

ELAC  Elevator and Aileron Computer (A320) 

FCDC  Flight Control Data Concentrator (A320 and A340) 

FCPC  Flight Control Primary Computer (A340) 

FCSC  Flight Control Secondary Computer (A340) 

SEC   Spoiler and Elevator Computer (A320) 


References
----------

[1] Dorsett R.D., Mellor P.: ``The Airbus A320 Electronic Flight Control 
    System'', available from 2nd author or from ata-watchers archives. 
    (1st draft - June 1992, 2nd draft - 26th January 1993) 

[2] Potocki de Montalk J.P.: ``Computer Software in Civil Aircraft'', 
    Airbus Industrie, Blagnac 31707, France (to appear in ``Microelectronics 
    and Computing'' and available in ata-watchers archives). 

[3] Traverse P.J.: "Dependability of digital computers on board airplanes",   
    preprints  of  "Dependable computing for critical applications," 
    IFIP WG 10.4 International  Working Conference, Santa  Barbara, 
    CA, Aug. 1989, pp 53-60.

[4] Rouquet, J.C., Traverse, P.: "Safe and Reliable Computing on board the 
    Airbus and ATR Aircraft", Proceedings of the 5th IFAC Workshop,  
    "Safety of Computer Control Systems", 1986, (SAFECOMP  '86), Pergamon Press.

[5] "Software Considerations in Airborne Systems and Equipment Certification", 
    Radio Technical Commission for Aeronautics document number RTCA/DO-178A, 
    March 1985.

[6] Butler R.W., Finelli B.G.: ``The Infeasibility of Experimental 
    Quantification of Life-Critical Software Reliability'', Comm. ACM, 1991
    (full ref. N/A). 

[7] Littlewood B., Strigini L.: "Validation of ultra-high dependability for 
    software-based systems", ESPRIT BRA Project 3092, "Predictably
    Dependable Computing Systems" (PDCS), 2nd year report, Vol. 3, 1991. 



Acknowledgements 
---------------- 

I would like to express my sincere thanks to Peter Potocki and his colleagues 
in AI and to all the people from AS for a very stimulating (if slightly 
exhausting!) two days, and to them and to Dan Hawkes for their help in 
acquiring various items of documentation to assist in the redrafting of the 
report. 
-------------------------------------------------------------------------------