SYSTEM DESIGN OF THE BARRACUDA FLIGHT CONTROL SYSTEM

A. Schönhoff, M. Friedrich, K. Harth, G. Jarasch, M. Momberg, S. Schärer, D. Wetteborn

EADS Military Air Systems
Germany

1. INTRODUCTION As the demonstrator Barracuda is operated according to

Kategorie-1 (LTF 1550 [3]) conditions, a loss of the vehicle
The first flight of the unmanned demonstrator Barracuda is not critical from certification point of view. This is differ-
on April 2nd 2006 represents a major milestone in the ent from EADS point of view and therefore tighter require-
development of unmanned aerial vehicles in Europe. ments to vehicle safety were set.

The Barracuda was developed by EADS Military Air Sys-

tems (MAS) in order to test key technologies for un- RH Rudder LH Rudder
manned military flight operations. Certification was per-
formed according to 'Kategorie 2' of the German LTF 1550
[3] but strictly obeying the restrictions according to 'Kate- RH Taileron
gorie 1'. Barracuda shall be flown only in restricted air-
space over unpopulated areas. Flap
LH Taileron
The following paper describes the development of the
Flight Control System for the Barracuda. Presented are Flap
the approach and the techniques as well as the specialties IRS/GNSS
which arose during the course of this demonstrator pro-
gram. FCC
ADS
System Design and Software Development were under-
stood as a tightly coupled and this approach contributed to Nose wheel
a great extend to the success of the project.
Fig. 1: FCS equipment locations
The vehicle architecture is dominated by off-the-shelf
2. BARRACUDA FLIGHT CONTROL SYSTEM equipments and only partly equipments were developed
for the Barracuda. Therefore concepts from both the civil
The Flight Control System (FCS) of the Barracuda pro- and the military world can be found on board. This is es-
vides the functionality which is required in order to assure pecially relevant for bus systems and redundancy man-
a safe flight. The FCS consists of three groups of sub- agement strategies.
system:
– the sensors to acquire the flight state, Following the actual development process the following
– the Flight Control Computer (FCC) [5], on which, paragraphs describe first the functional design which is
among others, the flight guidance algorithms are im- then detailed during system design down to equipment
plemented and level.
– the actuation for the control surfaces, nose wheel,
brakes and engine.
Fig. 1 gives an overview about the locations of the sub- 2.1. Functional design
system groups onboard of the Barracuda.
The functional design determines all functional aspects
The Advanced Mission Computer (AMC) [11] serves as coming from the operational concept prior to taking into
the interface to the mission control. It also connects to the account physical allocation and implementation con-
data link connection [4] to the Ground Control Station straints.
(GCS).
The following chapters present the redundancy concept,
During the course of the development the FCS received the health monitoring functionality and the autonomy con-
more functionality besides its original task flight control cept.
and flight guidance – partly due to the character of a dem-
onstrator aircraft, partly due the absence of a pilot. Due to 2.1.1. Functional overview
the absence of a pilot monitoring capability from the early
beginning an autonomy concept including an integrated For the operation of the Barracuda two main functional
health monitoring was designed in order to achieve a chains can be identified:
complete and reliable tracing of all systems in flight.
– the preparation of the aircraft prior to take-off and
– the flight itself.

Especially for the first functional chain an approach differ-
ent from a manned aircraft has to be chosen. The means
of interaction between ground staff and aircraft are limited,
since communication can only be performed via the
ground control station, ground test equipment and the
aircraft interfaces. Even the ground control station does
not represent a replacement for a cockpit as data link
bandwidth currently limits the amount of data to be made
available the GCS.
Within the Barracuda system the FCS coordinates the
system initialization of
– the navigation system,
– the air data system,
– the electrical system,
– the actuation system and
– the engine.
Only the electrical connection is established over the
Startup Panel (see Fig. 2). Engine start is also performed
from the Startup Panel and monitored by the ground staff
on an externally connected laptop displaying engine data.
Interface Panel Startup Panel
Fig. 2: Startup panel
After all systems have been powered and the actuator
movement check has been performed, the second func-
tional chain is invoked (see Fig. 8).
With the aid of the navigation system and the air data
system the flight vector is determined. From the pre-
programmed waypoints the FCC calculates the flight guid-
ance commands. The design of the flight control is ex-
plained in ref. [8].
Besides these flight guidance modules there are several
other functions required to establish a Flight Control Sys-
tem:
– Management of the real-time capability,
– Monitoring of Utility Systems
– Redundancy management
– Health monitoring
The two latter functionalities are explained in the following
chapters.
2.1.2. Redundancy concept
For an unmanned, autonomous aircraft like the Barracuda
the choice of the redundancy concept is of special impor-
tance. In case of an error the system autonomously has
– to detect the error,
– to analyze what caused the error and which subsys-
tems are affected and
– to assure that further on only error-free and valid
signals are being processed.
In the frame of the system design the system behavior in
case of an error has to be specified. Distinction between
first and second errors, depending on the degree of re-
dundancy of the specific subsystem is also required. Fur-
thermore distinction between flight critical systems which
are essential for safe conduction of flight (system kernel)
and non-essential systems has to be taken into account.
The system kernel of the Barracuda FCS is designed as
fail operative (fail-op). In the case of a first error the nomi-
nal system functionality is kept. This is guaranteed by the
shut-down of the erroneous module. After this re-
configuration the system kernel is still fail-indicative (fail-
ind). Non-essential systems are designed fail-safe. In case
of an error in these systems their functionality is no longer
used.
The Barracuda system kernel consists of the FCC, the
navigation platforms, the laser altimeters, die actuation
system (except the nose wheel) and the air data system.
Non-essential systems are the nose wheel steering and
the data link.
The essential systems are realized in triplex redundancy.
Regarding the redundancy management limitations had to
be accepted during the design phase coming from time
and cost restrictions and therefore actuation system and
air data system are realized in duplex redundancy. In order
to mitigate this limitation actuation interfaces are distrib-
uted over the three lanes of the FCC and an air data
backup solution is calculated within the FCC.
Due to the off-the-shelf approach the nose wheel steering
is simplex only. In order to be able to detect an error a
control-monitor structure is implemented which in case of
an error allows switching the nose wheel to its free castor
mode.
2.1.3. Health monitoring
The FCS health monitoring function observes all FCS
functions. Three categories of observed information can
be determined:
– Equipment data
– Information from the redundancy management
– Information the FCS software self-monitoring
Some state information are delivered by subsystems it
selves. Typically this is the case if these subsystems are
integrated within separate equipments. An example are
the navigation sensors which detect and report hardware
errors like the exceedance of temperature limits and also
functional errors like a diverging hybrid navigation solution.
Specifically system errors are not detectable with this
approach. Therefore the already mentioned redundancy
mechanisms were implemented. The chose voter-
/monitor-structures allow detecting errors which cannot be
detected and monitored on equipment level.
The 'defensive programming' approach for the software
development is in first place based on error prevention
rather than on error correction. E.g. changes of the control
flow are only enabled by 'guarded' commands. The last 2.2.1. System architecture
alternative (else- or default-case) is seen as an error since
none of the preceding conditions was met. This allows for Communication of the FCC with the subsystems is estab-
example to cover memory errors (Single Bit Upsets). lished via several digital interfaces (MIL-Std-1553B,
These errors are also handled by the health monitoring. ARINC 429, RS 485) (see Fig. 3).

Besides collecting all error information it is the health
monitoring's task to synthesize a combined error status for
each subsystem out of this information.
In order to correctly interpret error information the state of
the whole system has to be taken into account, e.g.
whether a system/subsystem is being initialized or already
in flight state. Since a large number of signals and de-
pendencies has to be covered, modeling this functionality
in a data-based approach is easier to realize and even
more important much easier to be validated and verified.
Over the FCS Bus (MIL-Std-1533B) the FCC communi-
cates with Remote Interface Units (RIU) to the Utility Sys-
tems, with the brake computer (BCU), with the navigation
platforms (inertial reference system / global navigation
satellite system; IRS/GNSS) and the air data computers
(ADC). The laser altimeters are connected to the FCC via
RS 485 and the actuation system via ARINC 429. Nose
wheel steering and the engine are controlled via analog or
discrete signals which are generated by the FCC. The
AMC is connected to the FCC via the Avionic-System-Bus
(AVS-Bus, MIL-Std-1553B).

In the Barracuda project the evaluation of the signal quality Actuation

I/O FCC I/O
was performed in the function generating this signal and Avionic System
discrete FCSBus
BC 5 times the same system,
wired in a different way (figure 7)

C2 Data Link AVSBus ARINC429 ACE MCE actuator

was not implemented within the health monitoring. The C2 Data Link
discrete
Lane 1
RS422 ACE MCE

principle here is that the signal quality can usually better BC GND analog analog

Connected to
Ethernet AMC

Nose boom
GND analog analog FCS Sensores

be evaluated with knowledge about the signal source. FTI

GND analog analog LAGLS
LAGLS
GND LAGLS

CCDL
GPS antenna

FTI - GPS I/O I/O

The evaluation of the conducted taxi trials has shown that DAU
discrete
AVSBus
FCSBus
ARINC429
BC

even an experienced test team is not fully capable of PCM buffer

discrete
Lane 2
RS422
GND analog analog ADC figure 5
monitoring all system information. This is also hampered

Connected to
Nose boom
GND analog analog ADC
transmitter
by the fact that the sampling rate of the flight test instru- GND analog analog

GND

mentation (FTI) is usually too slow to allow such a full

CCDL
IRS/GNS antenna
I/O I/O IRS/GNS antenna
monitoring. This has been overcome by the design of the Startup Panel
discrete FCSBus
BC IRS/GNS antenna

health monitor together with the autonomy concept which Engine

EEC
AVSBus
discrete
ARINC429
RS422 Utilities System
Lane 3
is described in the following chapter. Engine Power Lever analog
analog
analog
analog
GND
GND
BCU
BCU
brake

analog analog
RIU Landing Gear,
Nose Wheel Steering RIU Fuel, Hyd,

2.1.4. Autonomy concept Servovalve Feedbackpoti

ECS, EPGS

The introduction of autonomous functions is required when Fig. 3: System architecture (from [13])
situational awareness cannot be sufficiently established on
The operator interface is realized over the AMC. The AMC
ground which is the case for UAV [12]. This was the driver
communicates with the ground control station over the
to take some decisions on board already at the early dem-
command and control data link. From the GCS operator
onstrator stage of the program. Currently within the Barra-
commands (High Level Commands) are transmitted to the
cuda autonomous decisions are limited to those aspects
AMC and confirmation data sent in return.
which would endanger a safe flight.
In order to minimize development effort, the aircraft was
From this view the most critical is the acceleration of the
designed to be also used as a test rig.
aircraft during take-off shortly before rotation. When sys-
tem errors are detected in this phase a take-off abort is
automatically initiated. Since FTI and the command and
control data link have not been designed to cover safety-
critical functionality and data it cannot be assured that the
operator can detect all errors and that the required com-
mands can be transmitted to the aircraft. Nevertheless the
operator can command a take-off abort also from ground.

2.2. System design

When all functionality is fully designed and described,

definition of the subsystems and the allocation of the func-
tions to the subsystems are performed.

After an overview about the chosen system architecture
the connection to sensors and actuation to the integration
center of the system, the FCC is presented.
Fig. 4: Barracuda airframe in use as test rig
During rig operation for hardware-in-the-loop-simulation
real sensors and equipments can be bypassed and the
functions implemented within the FCC are stimulated with
simulated data. This also allows to stimulate errors and to
test system behavior in error conditions. Fig. 4 shows the
Barracuda connected to the simulation.
2.2.2. Sensors
The sensor system's task is to acquire all data required to
determine the flight state vector. The Barracuda sensor
system consists of the air data and navigation system.
The air data system (Fig. 5) hardware consists of the nose
boom with sensors for air flow angles and pressure trans-
ducers, two ADCs and a sensor to measure the air tem-
perature (total air temperature, TAT). The ADCs are con-
nected to the FCC over the FCS bus. The FCC incorpo-
rates the function for air data consolidation and an analyti-
cal backup solution to cover a sensor failure.
FCC
analog
Lane 1 FCSBus
analog
CCDL
The chosen architecture has the following features:
– The functional triplex architecture is mapped on three
identical channels with in the FCC, which together
with the corresponding channels of the sensor system
form the three lanes of the FCS. The term lane is
used synonym for channel in the following chapters.
– In order to support the off-the-shelf approach for all
other FCS equipment the FCC has to support a large
variety of interfaces like ARINC 429, MIL-Std-1553B,
RS 485 and discrete and analog inputs and outputs.
– Each of the three lanes is equipped with two micro-
controllers MPC565 to execute the application and
two additional MPC565 for interface and ARINC429
operation.
– For both intra- and cross lane communication (Intra-
Lane Data Link, ILDL and Cross-Lane Data Link,
CCDL) a MTU-proprietary, serial bus protocol in point-
to-multipoint topology is applied.
Further explanations about the FCC-hardware are given
FCS Sensores
in [4].
ADC Nose

ADC Boom
The software-/software-interface to the hardware-near
analog

analog
Lane 2 FCSBus
TAT
software which was developed by the FCC-supplier MTU
was chosen in a way that MTU implemented input-/output-
MILBUS 1553B (1)
MILBUS 1553B (2)
MILBUS 1553B (3)
CCDL

services for ARINC 429 and RS 485 with the exception of

the MIL-Std-1553B services and all built-in-tests.
Lane 3 FCSBus

2.2.4. Actuation system

Fig. 5: Air data system (from [13])
The nose wheel of the Barracuda was taken off-the-shelf
The navigation system (see Fig. 3) hardware consists of from the Alpha Jet. The control algorithm for the control of
three integrated, DGPS-supported inertial platforms and the nose wheel steering is implemented on the FCC.
three laser altimeters. The system is fully triplex-
redundant. The three navigation platforms are connected The control of the engine is realized by an electro-
to the FCC over the FCS-Bus and the laser altimeters are mechanical actuation of the thrust lever.
connected to the FCC via RS 485 links. The FCC incorpo-
rates the functions to consolidate all navigation data. Actuation
Electromechanical
FCC actuator
2.2.3. FCC 3
ARINC429
ACE
CAN
MCE RH Taileron
Lane 1 4 ACE MCE
The flight control computer's design task is to implement 7

the functional design on hardware. Therefore the FCC was CCDL

ACE MCE LH Taileron

realized triplex-redundant (Fig. 6) ACE MCE

3

4 ACE MCE RH Rudder

Lane 2
5 ACE MCE
6
ACE MCE LH Rudder
CCDL
ACE MCE
5

Lane 3 6 ACE MCE Flaps

7 ACE MCE

Fig. 7: Actuation system (from [13])

Each of the electro-mechanical actuators for the aerody-
namic control surfaces is equipped with its own duplex-
redundant position control electronic (actuation control
electronic, ACE and motor control equipment, MCE) (see
Fig. 7). It receives its position demand from the FCC over
the ARINC 429 link.

Due to the narrowing of the degree of redundancy from

Fig. 6: FCC architecture triplex to duplex two of the three FCC lanes are connected
to the two ACEs for each control surface.
2.3. Software design
The flight control software of the Barracuda implements
the described functional components of the flight guid-
ance, the signal processing algorithms, the redundancy
management as well as the health monitoring. Further-
more the software has to provide infrastructure services as
the data transfer over the various bus systems.
Constraints for the design are:
– Mapping of the functional system architecture (see
Fig. 8: Functional data flowCorrect, deterministic and
safe implementation of the digital algorithms
From these constraints the following basic design deci-
sions were derived.
As well as the computer architecture the software design is
triplex similar in a fully active configuration (no standby
lanes). All lanes are in synchronous parallel operation and
each lanes controls its own set of outputs.
In order to implement a complex digital control at high
sampling rates together with longer lasting processes a
mixed non-preemptive/preemptive, static table based
scheduling algorithm was chosen. In order to assure abso-
lute equality of the results of the three lanes in addition a
strict synchronization of the three lanes is performed.
The functional system- and subsystem-design is mapped
into the software architecture by a 'domain' concept. The
domains are reflected in the naming of parameters and
software components and also describe the work share
borders of the disciplines and developers involved. E.g.
the domain 'ADS' includes all functionality belonging to the
air data system, 'NAV' those of the navigation and 'MIL'
the service and drivers of the MIL-Std-1553B bus.
3. THE DEVELOPMENT PROCESS
For the military aircraft development the V-Model is an
exceptionally important standard [1]. This development
model is sufficiently described. The only remark in this
paper is, that the V-Model foreseen a forward-directed
course of development activities from the specification of
the whole system (in the case of a UAV the aircraft, data
link and GCS) down to equipment level and that the proc-
ess presented here implies that from the start of the de-
velopment the constraints of the software development
have to be taken into account (ref. [10]).
3.1. System development process
In general the main features of the system development
process do not differ from the classical approach of the V-
model (ref. [6]). Deviating from this approach for the defini-
tion of the term 'low-level requirement' an innovative
method of notation is chosen. This is further explained in
the description of the software development process
The following paragraphs describe the approach and
methods of the chosen approach and it is explained where
– due to the experimental character of the projects – de-
viations had to be followed. Also the applied tools are
presented.
3.1.1. Approach
As described e.g. in ref. [6] the system requirements are
derived from the top level requirements. These are refined
until a complete set of low level system requirements is
available for equipment and software specification.
Each requirement is traced back to the level above and
why and how it was derived. This traceability and the fol-
lowing step of validation cannot be fully realized in an
experimental project, since for the design some solutions
have been chosen which would actually not fully fulfill or
even violate a top level requirement but which are accept-
able on project level. Integration test show that all re-
quirements have been met.
3.1.2. Methods
Although due to the off the shelf approach for some parts
of the system the design was given prior to an analysis of
the top level requirements, for the whole FCS a complete
and consistent requirements basis was established. The
requirements are kept in a requirements data base which
will be described later. The validation was performed
within the requirements document(s).
In order to trace test coverage a verification matrix was
established in which to each requirement its mean(s) of
compliance (e.g. simulation, analysis, test or review) was
attributed and linked with to the verification result.
3.1.3. Tools
To capture system and interface requirements DOORS®
from Telelogic was used in its version 6.0. The tools for
the modeling of the low level requirements are allocated to
the tool environment of the software development envi-
ronment and are described in that paragraph.
DOORS® uses the advantages of a data bank in which for
each system a data base is created in which each data
item represent a uniquely identifiable requirement. Re-
quirements can be linked to higher levels in order to allow
a traceability analysis.
The same applies to verification evidence. Each test is
defined as a separate dataset and therefore each tested
requirement can be traced to a test case. Are all require-
ment linked to the verification matrix, the proof of a full test
coverage is automatically produced.
3.2. Software development process
The development process of the Barracuda FCC software
has to fulfill in general two sets of requirements.
On one hand the software and with it its development
process has to satisfy extremely high requirements with
respect to safety and correctness. In this context focus is
on the certifiability of the software. Although the FCS soft-
ware is not being certified at the current stage of the pro-
gram, process and software are conceptualized that a
certification according to the high requirements of the
software certification standard for airborne onboard-
Software, RTCA DO-178B (ref. [9]), is possible anytime.
On the other hand the software development has to be
able to cope with the high dynamics of an innovative proto-
type development and the resulting short development
cycles. This brings up the issues of a fast, efficient and
error-free code production and the maintainability of the
software.
For both topics a clear structure, a continuous naming of
identifiers and conformity to the software standards are
essential.
3.2.1. Application of RTCA DO-178B
The process for the development of the Barracuda FCS
software was directly derived from the certification re-
quirements. Applicable certification standard for airborne
onboard software is RTCA DO-178B. As the aircraft was
certified according LTF 1550, Kategorie 2 but under Kate-
gorie 1 conditions for the first phase of flight testing, a
dedicated certification of the FCS and therefore of the FCS
software is not required. Also due to tight budget con-
straints software verification was limited. As a full certifica-
tion Kategorie 2 is foreseen as a later program stage, the
development team decided to conduct design and coding
according to software level A.
The relaxation of the requirements to the verification ob-
jectives can be directly derived from the reduced certifica-
tion requirements for the FCS operation under Kategorie 1
conditions. Within the verification activities instead empha-
sis was laid on the development of dedicated verification
methods and the setup of a tool chain for a highly auto-
mated verification process in order to lay the foundations
for a later certification according to Kategorie 2.
The software configuration management process covers
all artifacts of system development, software development
and verification in order to allow a full traceability of all
software build standards. Instantiation of the software
quality assurance process and of the certification liaison
process was not performed as no FCS certification was
required for Kategorie 1.
For a full certification of the aircraft according to Katego-
rie 2 a certification of the FCC software according to DO-
178B, Level C is foreseen. The prerequisites for this certi-
fication were worked out in the current development phase
and will be brought to production standard prior to this
certification.
3.2.2. Software development approach
The software development approach chosen is the evolu-
tionary prototyping of software component (EPS). The
EPS differs from the conventional evolutionary prototyping
[1] that way that the prototyping is performed separately
for single software subsystems and not for the whole soft-
ware system. The software development process is
passed locally for each software subsystem, before a
integration of the whole software system is performed.
Furthermore the EPS is applied also within the system
development process, since major components of sensor
signal processing and consolidation and the digital control
are development graphically, are verified against the un-
derlying requirements and are used to validate these re-
quirements in the frame of simulations.
The enabler for the application of the EPS is the model
based software design (MBD) with automated code gen-
eration. This enables the system designers to perform
their design, verification and validation activities on an
appropriate level of abstraction and enables the software
designers to efficiently derive source code of high quality
from the model. The automated code generation moves
essential parts of software design and coding into the
configuration of the code generators, in which the rules for
mapping the model into source code are determined. For
the code generator configuration major design decisions
have to be taken which consequently determine the quality
of the generated source code. This has impacts on verifi-
ability and maintainability of the source code.
Design and coding decisions which cannot be imple-
mented within the configuration of the code generators are
made available to the system designer by a software
model standard (in addition to the DO-178B software
standards). Compliance to the software model standards
is checked at the gate into the software development
process in a computer aided model review.
With the verification process automatedly generated code
is handled similar to manually derived source code. A tool
qualification of the code generators was not performed.
3.2.3. Methods
Basic software development method is the object oriented
design, which can be characterized by the following para-
digms which directly implemented in the design of the FCC
software:
– Building of objects and classes: Common representa-
tion of state and behavior of functionality of objects
and aggregation of similar descriptions to classes.
– Abstraction: Masking of the implementation complex-
ity of parts of functions by representing them as
classes with internal states and behavior.
– Encapsulation: Functionality and data of a class are
exclusively provided by its method (functions) and ac-
cessors and mutators, i.e. no direct accessibility on
data e.g. over a global declaration.
The object oriented paradigms inheritance, polymorphism
and late binding were not taken into account as the certifi-
ability in the context of DO-178B can not be assured, and
if only with enormous effort.
Based on the object oriented design the particular soft-
ware development methods were determined for each of
the software components to be developed. The following
methods can be distinguished:
– Process-scheduler, math library, parts of the health
monitor, FTI functions, generic functions and drivers
for MIL-Std-1553B, ARINC 429, RS 485: Manual, ob-
ject based design and coding.
– Process-schedules and MIL-Std-1553B bus lists:
automated schedule planning from a process mode.
– Adjustable parameters and waypoint lists: System
design and automated code generation from Matlab®
scripts.
– Data representation layer for MIL-Std-1553B,
ARINC 429, digital and analog inputs/outputs, CCDL
and ILDL: System design and automated code gen-
eration from interface control documents (ICDs).
– Parts of the health monitor: System design and auto-
mated code generation from an abstract specification.
– Inertial, laser altimeter und air data signal pre-
processing and consolidation, flight control, autopilot,
moding, flight guidance: System design and auto-
mated code generation from data flow diagrams and
state charts.
– Software architecture and system moding: Object
based design and automated code generation from
UML models with class diagrams and state charts.
Overall about 95% of the whole FCC software was gener-
ated automatedly.
Integration of the software components was solely per-
formed on source code level. Therefore strict adherence to
the naming conventions was required up to system design.
The applied software verification methods are chosen in
accordance with DO-178B:
– Reviews: Models, ICDs and source were reviewed
and the objectives of the defined verification process
which were not covered by other verification methods
were checked.
– Analysis: Computer aided schedulability analysis were
performed to demonstrate that the computed process
schedules as well as the MIL-Std-1553B bus lists sat-
isfy their requirements; static source code analysis
were performed to check the conformity of the source
code with the software standards for the automatedly
checkable part of the rule set.
– Tests: For selected critical software components low
level tests on a pre-target (single board computer)
were conducted without code instrumentation to ana-
lyze statement and branch coverage; for the data flow
diagrams and state charts integration tests on the pre-
target were conducted including an analysis of the
structural coverage; hardware/software integration
tests were conducted on the FCC in the frame of the
system integration tests.
Target of the development phase of the Barracuda with
respect to the verification methods was to refine these
methods, but due to the already mentioned budget con-
straints it was not possible to apply all method to all soft-
ware components. In fact their application was performed
partially exclusively or the results gained from system
integration testing about the integrity of a software compo-
nent were assessed as sufficient. A full performance of the
verification activities is foreseen for a Kategorie 2 certifica-
tion.
3.2.4. Tools
Main criteria for the implementation of the process and for
the choice and configuration of commercial and self-
developed tools were:
– Fulfillment of safety and quality requirements on the
source code
– Code from the sub-processes can easily be integrated
into the whole software
– Highest possible degree of automation
– Full traceability of changes by application of tool
based configuration management
– "Single source“ approach: i.e. for each item only one
specification (e.g. model, data base module) in order
to avoid inconsistencies and errors
The development methods described in Para 3.2.3 were
implemented by applying the following tool set:
– Design of UML models and code generation with
Rhapsody (I-Logix)
– Design of data flow diagrams and of state charts with
MATLAB®/Simulink®/Stateflow® (MathWorks); code
generation with TargetLink (dSPACE)
– Specification of the data representation layer and of
the health monitor logic networks with the requirement
management tool DOORS® (Telelogic); Code genera-
tion with the DOORS® script programming language
"dxl".
Besides the two sub-process chains Simulink®/TargetLink
and Rhapsody® in which the adaptation of the code gen-
eration and the establishment of the software model stan-
dards were performed, all other sub-processes for soft-
ware generation and integration were covered with pro-
prietary tools.
The FCC software of the Barracuda was developed in the
programming language C. For safety reasons only a sub-
set of C was applied.
3.3. Software / system development synergy
Prerequisite for an efficient and error-free development of
safety critical systems and software in the described envi-
ronment are a well-defined development process and the
application of powerful methods and tools.
The process applied for the development of the Barracuda
FCS shows several advantages. In first place the transition
from a 'classical' software development towards model
based techniques is to be mentioned. The application of
model as a description creates a common language for
system and software developers.
The higher degree of abstraction for the description of
complex contexts by a model creates a better and more
intuitive understanding for not only for the developer of a
specific function. Both this advantage and the fact that
within the presented integrated development process the
models itself partially represent requirements are enabler
to assure the achievement the characteristics of good
requirements, especially unambiguousness, consistency
and completeness.
It was shown that models represent an ideal basis for inter
disciplinary discussion and reviews can be conducted
much more effective with higher quality results.
As the models were taken as the basis for an automated
generation of documentation and code, manual error-
prone steps are eliminated from the traditional process [3] BMVg, WTD 61: "LTF1550-001 - Sonderbestimmun-
chain. Traceability and consistency are implicitly given. gen bei Prüfung und Zulassung unbemannter Luft-
fahrzeuge der Bundeswehr", 2004
[4] Gottmann, T: "Auslegung des Barracuda Gesamtsys-
4. SUMMARY AND FORECAST tems", Deutscher Luft- und Raumfahrtkongress 2006,
Braunschweig
[5] Hierlwimmer, R., et al.: "Systemkomponenten für den
It could be shown that the developed architectures as well Barracuda – Entwicklung eines Flight Control Com-
as the chosen approaches, methods and tools were highly puters und der Schubdüse", Deutscher Luft- und
appropriate within the environment of the demonstrator Raumfahrtkongress 2006, Braunschweig
development program. A cost and time effective develop- [6] IEEE: "IEEE STD 1220-1998 – Standard for Applica-
ment process was implemented. tion and Management of the System Engineering
Process", IEEE, New York, 1999
A detailed quantitative assessment of the efficiency was [7] Jarasch, G., Schönhoff, A.: "Integration von UAVs in
not performed, nevertheless the advantages are obvious den kontrollierten Luftraum", Deutscher Luft- und
as the team size was much smaller than it would have Raumfahrtkongress 2002, Stuttgart
been possible with a 'classical' approach. The integrated [8] Moormann, D. et al: "Autonome Flugregelung des
approach of system and software development led to a UAV-Demonstrators Barracuda", Deutscher Luft- und
transparent development process and to an efficient con- Raumfahrtkongress 2006, Braunschweig
duction of the project. The developed procedures, meth- [9] RTCA: „Software Considerations in Airborne Systems
ods and tools will be applied in future developments. and Equipment Certification”, DO-178B, Washington
D.C., USA, 1992
The Barracuda development is not yet finalized. The suc- [10] Schönhoff, A., et al.:"Moderner Entwicklungsprozeß
cessor of the demonstrator will be used as an experimen- für sicherheitskritische Software", Deutscher Luft- und
tal platform for future agile operational systems. Raumfahrtkongress 2001, Hamburg
[11] Seitz, R., Westerbuhr, F.:"Advanced Mission Com-
puter", Deutscher Luft- und Raumfahrtkongress 2002,
5. REFERENCES Stuttgart
[12] Stütz, P., Schulte, A.: "Missionsmanagement für ein
[1] Anderson, Dorfman: “Aerospace Software Engineer- hochfliegendes, unbemanntes Luftfahrzeug im kon-
ing: A Collection of Concepts”, Progress in Astronaut- trollierten Luftraum", DGLR-Workshop T5 UAV,
ics and Aeronautics Series, V-136, AIAA, 1991 Braunschweig, 2002
[2] BMVg: "Entwicklungsstandard für IT-Systeme des [13] Wetteborn, D.: "Analyse der internen Kommunikation-
Bundes – Vorgehensmodell Juni 1997", 1997 sarchitektur eines Flugführungssystems", Studienar-
beit 2005, München

GPS / LINS
DGPS - Electronic
INS - Laser Air Data
Solution Engine
Solution Alt Computer
Control

Kalman
Filter

I/O

FCC
Navigation
Fuel
Air Data
Estimator
Navigation Airdata
Consolid. Calc/Cons.

Inertial Airdata
Consolid. Estimator
D/L AMC I/O

Operator
Display
Flight Guidance Flight Control

Actuator Control, Primarys

Emergency /
Flight- Auto- Control
autonomous
Waypoints
Guidance pilot Laws I/O Actuation
Control

Operator Initiation Auto-

Input Commands throttle Actuation
MCE for
System Functions

Start_Mission
Primarys
Moding

Health
Monitoring UCS
Emergency Actuation Actuation for
Servo
Commands Redundancy Control NWS, Engine
Rejected T/O CCDL
Go Around
Turn
... Scheduling
@50 Hz

Fig. 8: Functional data flow