Method and specification tools for Airbus onboard systems D Bri~re*, D Ribot*, D Pilaudt and J-L Camust
A6rospatiale Avions uses a method, a language and tools to obtain detailed specifications of the Airbus onboard flight control systems under its responsibility. The origins of this workshop developed by A#rospatiale lie in the SAO (computer assisted specification) language based on a graphics formalism, known to all electronics and automation experts, which (:overs the field of flight control laws and operational logics. The possibility of automatically generating software from this formalism has allowed A~,rospatiale to develop tools for real-time simulation and critical system specification validation as early as the design stage. The specifications thus validated are then automatically translated into 'aircraft' software, guaranteeing that the behaviour of the onboard system will be identical to the behaviour observed during simulation. This method and these tools were put to the test and proven within the scope of the Airbus A340 development. The quality of the specifications thus obtained enabled a significant reduction in the number of modifications to the onboard systems and led to substantial cuts in cost and debugging times. The example of debugging the Airbus A340 fly-by-wire specifications is used to back up the paper, which will also present the future specification integrated workshop, CSAO (computer-aided specification and design), developed by A6rospatiale Avions and Vdrilog. Keywords: systems development, computer assisted specification
Within the scope of onboard system development, Aerospatiale Avions has implemented a methodology and tools enabling the detailed specification of critical systems and its validation by simulation before manufacturing the equipment. This working method was used to specify the AIRBUS A340 electrical flight control system. It allowed significant gains to be made in efficiency whilst guaranteeing the quality indispensable for this type of system. France ~A~rospatiale, V~rilog, France
AIRBUS A340 ELECTRICAL FLIGHT C O N T R O L SYSTEM The Airbus A330 and A340 flight controls represent the most recent step in a process started in the 1960s with Concorde. Aerospatiale, prime contractor for the primary flight controls in the civil transport aircraft programs developed under European cooperation, has endeavored for each new program to get the best out of both experience gained on previous programs and new technologies which have reached maturity with the constant aim of reducing weight and costs and improving dependability. With Concorde, high accuracy was required in the servo control of surface actuators on account of the supersonic flight constraints. The solution chosen was to use electrical flight control channels with a mechanical standby channel. Also, analog computers generate orders 'superimposed' on the pilot's orders to ensure handling quality and dependability. Concorde was thus the first civil fly-by-wire transport aircraft. When the first Airbus A300B aircraft were launched, the same technologies were available, but the use of electrical control channels was no longer necessary. The flight controls on this generation of aircraft were achieved by mechanical linkages, hydraulic servocontrols and analog flying aids computers. In the 1980s, digital technologies became accessible to the civil aeronautic world thanks mainly to the industrialization of microprocessors. The systems on the Airbus A310, then on the A300-600 aircraft, benefited from this, especially for the critical applications such as the automatic flight control systems (including all-weather automatic landing) and the display and warning systems. In the flight control field, a first step was made by using digital computers for controlling the 14 spoiler servocontrols and the slat and flap control servomotors to the pilot's orders. In parallel, Aerospatiale was developing experimental programs on simulators and test aircraft, Concorde then Airbus, which especially allowed the flight control law and sidestick controller concepts, used later on the A320 and the A340, to be refined.
Elsevier Science B.V. Microprocessors and Microsystems Volume 19 Number 9 November 1995
511
Method and specification tools: D Briere et al. When the A320 was launched, Aerospatiale had good command of all the technologies and methodologies allowing them to move another step forward and develop that which today has become a new flight control standard, applied to the A320, A321, A330 and A340 and tomorrow to the A319. The main lines from a functional viewpoint are as follows: a) A set of five digital computers receives the flight control orders from the sidestick controllers in manual flight control mode or from the automatic flight control computers. The first function of these computers is to transfer the pilot's orders to the control surface actuators and to permanently check for correct execution of transmission 'from the stick to the control surface'. b) Each computer controls several actuators according to a distribution defined by a safety analysis, taking into account not only the combinations of internal failures to the flight control system, but also external failures such as to the electrical or hydraulic power sources. In case of failure, the system automatically reconfigures itself. c) The flight control computers incorporate flight control laws allowing an accurate, stable and dependable response from the aircraft to the pilot's orders at all points in flight. One of the characteristics of these laws is that they include protections which avoid excursions outside of the 'nominal' flight envelope and provide optimum manoeuvre capability, if needed. For example, if the pilot gives a full pitch-up order in case of threatening traffic or terrain, he will obtain quickly the maximum lift capability of the aircraft without risk of stall. d) Loss of flight control must be extremely improbable. This objective is demonstrated with the electrical flight control channels alone. The following additional protections must however be taken: maintain ultimate mechanical standby pitch and lateral control thanks to the trim control wheel and rudder control pedals. This standby control architecture frees the sticks from all mechanical drive constraints allowing them to be installed laterally thus improving the ergonomic design of the cockpit. • two types of computers are used. They are dissimilar from both a hardware and software point of view and delivered by two different suppliers.
antee the quality indispensable for these types of systems. We can describe the steps by listing the various chronological phases which follow on from one another before a 'turnkey' system can be delivered. There are three main phases: design, manufacture and validation. Specific emphasis is placed on DESIGN as this phase is critical for the final product quality level; within this phase, it will not be possible to examine all of the steps and therefore, even more so, the tasks comprising each of the steps: only the most significant ones will be considered.
Design phase System architectural design First of all, all the functions to be fulfilled must be defined specifying the 'criticality' levels for each of these functions. From this point, the architectural design of the systems can be undertaken considering: • • • •
the the the the
constraints specific to the aircraft, technologies available, functions which can naturally be grouped together, cost, weight, dimensional and maintenance targets.
The result of this task leads to a specification for the system considered, expressed textually and including among other things: • • • •
the the the the
functional requirements, safety requirements, interface with other systems, physical characteristics.
•
e) All functions are performed by the software: • flight control laws, actuator monitoring, reconfiguration logic.
servo
control,
DEVELOPMENT STEPS The system development method was finalized some time ago at Aerospatiale and the steps that we will describe below are a permanent feature of the successive aircraft programs. We will especially underscore the innovations implemented for the AIRBUS A320 programs (entry into service in 1988) and the A340/A330 programs (entry into service in 1993/1994) in order to improve the efficiency of the development while naturally continuing to guar-
512
Equipment specification An item of equipment can be defined from two types of specifications, either a general specification, listing the functions and performance to be ensured, or a detailed specification, describing the execution algorithms of these same functions. Aerospatiale has chosen to give a detailed specification of the equipment intimately related to the operation of the aircraft, mainly the critical equipment: electrical flight control computers, autopilot, man/ machine interface, etc. Specifications were originally written in natural language; the excess richness of this type of language led to software coding errors as open to different interpretations by the program analyst. The detection of these errors in the test phase was the source of many loops and a considerable loss of time. This is why Aerospatiale developed, from the A320 program, a methodology based on a tool called SAO (Computer Assisted Specification). The specifications thus produced can be validated before the software is produced. The formalism used allows automatic software generation. We will describe this activity in more detail in the remainder of this paper.
Microprocessors and Microsystems Volume 19 Number 9 November 1995
Method and specification tools: D Briere et al. The result of this task gives a specification for the equipment considered. It consists of: -
a part specified in SAO language
• flight control laws and/or operational logics, • equipment input/output signals, -
a more conventional part concerning, among other things:
• the safety requirements, • the physical characteristics, • the environmental constraints.
conducted on the systems only represent a part of the 1200 flight hours required until the aircraft is completely certified; the fine-tuning of the aircraft is achieved with both the test crews and with the information recorded during the test flights. Several thousand parameters are recorded during each flight, either in analog mode for large passband signals or in digital mode for the others; the information flow recorded represents 200000 data items per second of flight. This information is recorded onboard the aircraft but a part is transmitted directly to the ground by telemetry allowing the tests to be analysed in real time.
SAO LANGUAGE AND SPECIFICATION VALIDATION TOOLS
Production phase Electrical flight control computers are manufactured in a specific: way by the equipment manufacturers. The application software for these computers is produced by Aerospatiale on a software workbench the main features of which are given below: For development, most of this software calls on specific methods and tools. Indeed, we have tried to get the best out of the way the specifications were produced and, in particular, the SAO tool. On the AIRBUS A340 program, an automatic code generator allows 70% of the main computer software to be obtained from the SAO specifications. This tool had to be developed with the same level of quality as used for embedded software. Thus, by simplifying the manual tasks throughout the production cycle and by (:lose coupling between system and software specification management, Aerospatiale was able to achieve the level of quality required for critical systems.
SAO language Its originality is that it is based on a graphics language which uses a symbol library and assembly rules known by all electronic engineers and automation experts. This language covers the operational logic and slave control field and is therefore well suited for electrical flight control systems. An example of a specification with the SAO formalism is given in Figure 1. This formalism allows: • rapid and unambiguous understanding of the sought operation and therefore avoids the majority of coding errors, • changes to be managed and therefore ensures the traceability of the specifications, • a coherence check to be made on each sheet then at specification level. Lastly, on the AIRBUS A340 program, SAO allows automatic coding of the electrical flight control software. This is not the least of its merits. Indeed, automatic coding offers the following advantages:
Validation phase G r o u n d tests
Distinction is made between: • tests on partial bench allowing the operation of each of the items of equipment taken separately (computers, serw)controls, etc.) to be tested and the peripheral systems simulated. • tests on integration bench which allow the operation of all the systems to be tested together. We try to make this integration bench representative of the aircraft from a geometry, wiring, power resource and from a hydraulic and electrical generation and distribution point of view. • tests on simulator allowing the flight control laws and the failure procedures to be validated in a real environment. This simulator is therefore equipped with a cockpit similar to the one on the aircraft and with a simulated view of the outside world. Flight tests
This is the ultimate phase. In an aircraft development cycle, this phase lasts for around one year, whereas the previous phases are, in general, spread over several years. The tests
• reduction in coding errors to almost zero, • elimination of unit tests, • reduction in the software production cycle, in particular the modification cycle, • possibility of validating equipment functions at design stage. This point is dealt with in the following paragraph.
Specification validation The benefits of having a first system for validating the specifications as soon as they are issued without waiting for the equipment to be manufactured, is obvious. This system was implemented at Aerospatiale on the occasion of the AIRBUS A340 program in the form of 'in-house' simulators placed at the designers' disposal. First of all, the electrical flight control laws are conceived using automatic multivariable methods. The laws obtained in transfer function form are then described in SAO formalism complying with a top-down breakdown allowing the specification to be structured. These sheets are then coded automatically and the code
Microprocessors and Microsystems Volume 19 Number 9 November 1995
513
Method and specification tools: D Briere et al.
54
32
II
AN12~] I ~
PAX ILAPOS { ~
_1/ ILASEN X627Z01 L---J
32
32
X627Z02 '
II
,
C:
I
BCOULJMC
-[~
B827Z01
~27Z02
I
8
~[-L_
X62TZ06 -J COMP A E I ~ 10deg I-- A2B
~)' CONF
32
SILRON PAX BSPAIO RAX 32
B827Z08
~ ] O 1 ~ ~
>
r
-•
S
B3
I--
rRAX
BASC BFILAIL
B627Z07 R"
X627Z05 "' BFII~SC2 BRESVL1A
II32 ~327z0e II X627Z13
???
X627Z10
X027Z04 EE3 ~
B627Z(~ -23mA
' "~
I
X627ZII
2 O m A ~
C2
FCSC
Book SERVLOOP
SURVEILLANCE D'AILERON INTERNE GAUCHE 6.2.7 I Chapter Sheet Issue ' Author
AILERON
Computer ref. : SER02
L01/001/M MOD : 1052
10 Var : 2
PAl_AND Date 23/10/91
Figure 1 SAO specification example
obtained is introduced into a real-time computer which simulates the aircraft flight mechanics. A control panel, equipped with mini-flight controls and a display of the main flight parameters, allows the simulator to be 'flown' and compliance with flight control objectives validated. If one of the objectives is not met, reiteration can be performed within a few minutes. This tool therefore allows a first validation of the flight control laws very early on in the development cycle. This is a functional check which does not take the hardware aspects of monitoring and redundancy levels into account. These aspects are taken into account by another tool which, within an 'aircraft' environment, can simulate the simultaneous operation of all the electrical flight control computers. We can thus validate: • • • • •
operations at tolerance limits without failures, operations with failures and degraded modes, inter-computer synchronizations, transient effects, slaved-control loops with servocontrols simulated.
This tool allows several hundreds of cases to be processed in one night. Here again, the automatic coding of the SAO sheets allows the modification cycle to be reduced to several hours.
514
CSAO WORKBENCH The success of the A340 system development has encouraged Aerospatiale to pursue its efforts in system engineering tools and methods, especially to specify new onboard systems and to handle new technologies (integrated modular avionics, multiplexed digital buses, etc.). A future workbench, CSAO, was defined on the basis of the joint experience gained by Aerospatiale and VERILOG who is in charge of manufacture and marketing.
CSAO product This new workbench (CSAO), based on the experience and the principles of SAO, is able to support a specification method based on: t
a hierarchical approach (top down or bottom up) fully compatible with a reusable component strategy, • graphic representation (schema blocks) like SAO with a formal semantic (LUSTRE language), • possibility of a coherence verification at each step of the specification, • automatic optimized code generation from detailed
Microprocessors and Microsystems Volume 19 Number 9 November 1995
Method and specification tools: D Briere et al.
specification according to recent results in the domain of synchronous language, • capability of formal verification and automatic test generation.
L
According to the size of the software developed with this method, it is necessary to provide powerful functionalities such as:
• configuration management well adapted to the method and the background of the users, • automatic documentation of large documents conforming to military standards (DoD2167A, GAMT1 7) and based on the SGML standard. According to this remark, CSAO will be a new Computer Aided Specification and Design workbench for embedded systems with different Motif Editors, a configuration management system, a document generator with an open architecture based on a software bus.
ASA STP
I l
! I u)
VAPS
I
8
SAO+ editors
I
)+ g31
Documentor
I I
I I
Signal base
[
Coupling
I"
TPS GRIF
!
I r II ,
Query
ii
Annotations
+ +
1 I
.Configuration Management 1 Control integration
Data integration
~'.[.
Product architecture
Dashboard
Control panel
Presentation
integration
Imporl/Export
Figure 2 AerospatialeCSAO workbench
The services provided by the CSAO workbench can be divided into two groups: • 'vertical' services devoted to specific phases of the life cycle, and even to specific formalisms, • 'horizontal' general purpose services, covering the life cycle. There is one 'sub environment' for each activity related to a certain formalism (e.g. SA/RT, SAO+, SGML). The CSAO global architecture can integrate any kind of tools, commercial or in-house. Figure 2 shows the workbench configuration envisaged by Aerospatiale. ASA, STP and Signal Data Base are related to the specific Aerospatiale choice but they can be replaced by any other tool.
CONCLUSION The highly positive results obtained by using system engineering tools coupled with automatic embedded software generators has led AEROSPATIALE to intensify this approach for future programs. The route followed for the CSAO workbench will allow reinforced integration of all the tools and extension of these techniques to cover new application fields. Lastly, the AEROSPATIALE and VERILOG association for CSAO will provide us with an industrial robust and durable tool for future aircraft programs. Its bottom-up compatibility with current SAO tools will allow them to be progressively replaced for ongoing programs.
Dominique Bri~re is head of the Aerospatiale Avions department responsible for the flight controls of the Airbus and A TR families, and prospective design studies in this field.
Vertical services The following vertical services are provided: • preliminary specification with SADT, SA/RT or OMT, for instance, • detailed specification based on synchronous schema blocks (SAO+), • automatic code generation.
Daniel Pilaud obtained his PhD in computer sciences from Institut National Polytechnique de Grenoble (1982). From 1982 until 1989, he was a researcher at the "Ecole Nationale Sup6rieure d'lnformatique et de Math~matiques Appliquees de Grenoble'. His research interests included specification implementation and valMation of real-time systems. In 1989, he joined V6rik~g. He is ~urrently rnana~er of the V(~rilog Research and Development Center of Grenoble, where the workbench CSAO is bein/4 developed.
Their choice depends on the end-user.
Horizontal services General purpose services are the following: • • • • • •
Denis Ribot used to be responsible for the development of airborne software for Airbus A320 and A3 ~O/A340 fly by-wire controls, Since 1993 he has been in charge of the A6rospatiale Avions Systems Development Workshop.
configuration management service, link and annotation services, automatic document generation and editing, the dashboard, the control panel, common signals database.
lean-Louis Camus is the project manager of the CSAO project at V6rilog. He has been working in the area of software analysis and design environnrents since 1985 at V~rik~,~. He is a graduate O)ntrol Engineer and received a PhD in Control Engineering from the Instilut National Polytechnique at Grenoble in 1980.
Microprocessors and Microsystems Volume 19 Number 9 November 1995
515