A flight test experimental system for multi use

A Flight Test Experimental System For Multi Use

by

Bernd Gelhaar (bernd.gelhaar@dlr.de), Heinz-Jürgen Pausder (juergen.pausder@dlr.de)

DLR,Institute of Flight Research (Braunschweig, Germany)

1 _{Paper presented on the 27}th _{European Rotorcraft Forum, Sept.11-14, 2001; Moscow, Russia} Abstract

A new helicopter in-flight simulator is under development in Germany. The development project will be finished with delivery of the test-bed to the German Aerospace Center (DLR) in Braunschweig in 2001. The Flying Helicopter Simulator (FHS) will serve as a testbed for technology design and evaluation especially related to the critical man-machine interface. The FHS is based on an EC 135 helicopter, which is modified with a hierarchical fly-by-light control system for a safety pilot and an evaluation pilot. The development project was started in 1996 and the first fly-by-light flight is scheduled for this year.

The FHS consists of two main technology units which correspond to the flight test operational modes: A safety critical part, which is used by the safety pilot and is certified for the full flight envelope. This part is realized with a fly-by-light system.

The second part the experimental system -is designed as a modular multi-purpose system which is designed as non safety critical in the current development step but can be upgraded to a higher redundancy level. The experimental system is used by the evaluation pilot in order to conduct the defined experiments in the ex-perimental mode. Depending on the imple-mented redundancy level this mode requires to fly the testbed in a slightly reduced flight en-velope which is mainly defined by the height over ground for safety reasons.

The architecture of the experimental system has to match three major requirements:

- functionality,

- flexibility and - expandability.

The open architecture based on VME-Bus and the hierarchical design led to an experimental system which can be used for very different types of experiments while leaving most of the system unchanged.

The overall FHS and the experimental system especially are designed with a multi use

func-tionality. These are in-flight simulation, control system configurations, side stick integration, integration of a redundant experimental control system computer and head down/head up dis-play modes.

Introduction

DLR’s Institute of Flight Research has gained international recognized expertise in the field of in-flight simulation. High level experience is achieved in the in-flight simulation methodol-ogy, the simulator flight vehicle development and the operation of the testbeds. The fixed wing testbed ATTAS (Advanced Technology

Testing Aircraft System), based on the VFW

614 aircraft, has been successfully used as a flying simulator since 1986 [1]. Until 1995, DLR operated the helicopter in-flight simulator ATTHeS (Advanced Technology Testing Heli-copter Simulator) which was based on a Bo105 helicopter. The Bo105 helicopter was equipped with a full authority but non-redundant fly-by-wire/light control system for the evaluation pilot [2].

The program to develop an advanced Flying

Helicopter Simulator (FHS) was launched

in 1996 [3]. The research helicopter is being developed in a common effort of the Ger-man Aerospace Center (DLR), Eurocopter Deutschland (ECD) and Liebherr Aerospace Lindenberg. The development program is funded by the German Ministry of Defense, the DLR and the industry partners. The FHS, as a successor to the DLR’s Bo105 ATTHeS air-borne simulator has been designed as a flying simulator to support the development, demon-stration and evaluation of new flight control and cockpit technologies for users from research, industry and flight test centers.

Overall System Structure

The baseline vehicle of the FHS is an EC135 helicopter (Figure 1). To transform a basic EC135 helicopter into the Flying Simulator platform requires significant modifications. The

mechanical control system is removed and replaced by a full authority fly-by-light system. A mechanical backup control system is inte-grated for maintaining control of the aircraft in case of a total failure of the electronic system. The FHS will be operated by a three man crew consisting of a safety pilot, an evaluation pilot and a flight test engineer. The overall system is designed in a hierarchical architecture related to the role of the evaluation and safety pilot. A fault tolerant equipment design combined with a number of safety functions keeps the system protected against internal failures and distur-bances imparted from outside [4], [5].

A helicopter ground simulation facility at DLR is designed as a hardware and software-in-the-loop facility for the FHS. Objectives are

· to allow software and hardware to be

veri-fied before flight in a real-time pilot-in-the-loop environment,

· to provide pre-flight training of pilots and · to provide test preparation for the technical

specialists.

To achieve this, a fixed base simulator was built with a set of original FHS inceptors, an evaluation pilot’s display, a control and display unit (CDU) and a core system control unit. An active force feel system was installed to repli-cate the control forces in FHS. The simulator is driven by a high fidelity real-time EC135 model, with a comprehensive simulation of the 1:1 flight control system. The experimental system hardware and software is virtually identical with that of the airborne system. To allow real-time monitoring of flight tests with ACT/FHS, a mobile flight test observation unit is being built. This unit provides facilities for real-time monitoring and off-line data analysis. It consists of two modules: a real-time moni-toring station and a telemetry station.

The first flight of FHS in the mechanical back-up mode was successfully performed in August 2000. After the extensive ground tests of the electronic control system equipment, the first fly-by-light flight is scheduled for fall 2001 fol-lowed by the performance flight tests needed for certification. After finishing the development phase the FHS will come into service of DLR in 2002 and will be provided for the broad spec-trum of application.

Fig. 1: The EC135 Helicopter

The ACT/FHS Onboard System Architecture

The system architecture must fulfill the user requirements for flight experiments (full flexibil-ity, rapid configuration changes of flight ex-perimental software and exex-perimental hard-ware) and at the same time has to provide the full level of safety which is required for normal flight purposes or the use of the helicopter as a technology demonstrator, with no experimental HW/SW in the control loop. This twofoldrole of the helicopter results in a hierarchical structure which distinguishes between the categories: safety critical and non safety critical. This cor-responds to two layers of the structure (Figure 2).

The upper layer called the „core system“ is the safety critical part and is used for normal flight purposes by the safety pilot. This system has to meet the civil aircraft certification require-ments i. e. a catastrophic failure may not hap-pen before 10 9 flight hours. By using this con-trol system, which has quadruplex redundancy, the helicopter has the same behaviour com-pared to the unmodified series helicopter. The second layer is called the experimental system and is allowed to be non safety critical. Therefore it is currently developed as a sim-plex system. Nevertheless the connection be-tween the core system and the experimental system has been designed for later use of a safety critical experimental system with higher redundancy.

Flight Modes

Four main flight control modes are specified. The different control modes are selected by switching two clutches (C1,C2 in figure 3) near the actuators and two switches (S1,S2 in figure 3) in the cockpit interface computer „COS“. Figure 3 shows the architecture of the onboard system

I. Safety pilot 1:1

(S1=don't care,S2=u,C1=off,C2=off)

In the safety pilot mode the flight envelope of the FHS is virtually the same as for the opera-tional EC135. The safety pilot has direct con-trol using the fly-by-light link. The mechanical link in this mode is moved, but not used for control. Of course starting and landing is pos-sible using this fly-by-light system.

II. Evaluation pilot 1:1, experiment off. (S1=u,S2=d,C1=on,C2=off)

This is identical as I . The mechanical link is fed back to the safety pilot. So he can feel what the actuators do and can at any time engage his controls either by pushing a button or by introducing forces into the mechanical link.

In mode I and II the experimental system is not in the control loop and can be used for display and measurement purposes. In mode I and/or II the helicopter can be used for normal flight or as a technology demonstrator.

Fig.3: Control Flow Trim Trim LVDT Safety Pilot Computer Interface Evaluation Pilot

Experimental System Computer

CDU LVDT On/Off On/Off Core System Experimental System Actuator Control Electronic C2 C1 S2 S1 u d u d

III. Evaluation pilot mode experiment on. (S1=d,S2=d,C1=on,C2=off)

This is the experimental mode in which the commands from the evaluation pilot are fed through the experimental control computer. In the computer the commands are processed and modified in order to conduct the experi-ment. This may be a new control law or a flight simulation algorithm. Then the output is fed through the cockpit interface computer to the actuators. In mode III the controls of the safety pilot are backdriven giving the pilot an indica-tion of the actuator activity. He either can manually switch off the experimental system by pushing a button or he can force override by introducing forces into his controls. In both cases he gets full authority over the helicopter. IV. Mechanical emergency mode

(S1=don't care,S2=dont't care,C1=off,C2=on) The mechanical feed back link is also used for emergency cases if the redundant core system fails. In this case all the electronics of the core system are bypassed by the direct mechanical link of the safety pilot. Although the fly-by-light system has a full certification for the whole envelope of the series helicopter the mechani-cal emergency backup was left installed. While at every time during flight it is possible to switch between modes I, II and III once mode IV has been activated, the helicopter must land using this mode before the other modes can be invoked again.

The Experimental System

The experimental system (Figure 4) consists of a data management computer, a flight control computer, a graphics processor, two multifunc-tion displays, two control units and a variety of sensors and sensor interfaces. The role of the experimental system is to support the user of the helicopter with standard test environment of sensors, functions, hardware and software while allowing easily to add user specific SW and HW for a dedicated experiment.

Basic Considerations for Experimental Sys-tem Development

At the start of the project a market analysis took place to find the adequate hardware plat-form. In addition to the specific user require-ments, the following general requirements had to be met by the experimental system hard-ware and softhard-ware:

SP Mechanical backup Core System

Smart Actuators Control System Computer EP CDU FTE INS/GPS Experimental System EC135 AHRS EC135 Air Data EC135 FADEC Data Manage-ment Computer (DMC)

Air Data Boom Differential GPS Accelerometers Rotor Data Acq. Discrete Switches CDU EP Data Recording Telemetry FTE Display I-Com Downlink EC135 Radar Alt.

Additional mission equipment (e.g. Side Stick, obstacle radar,

FLIR, new sensors,...) Experimental Flight Control Computer (EC) Graphics Computer EP Display RS422 Analog Analog FPDP Analog VME PCM Analog SCSI ethernet R-mem RGB RGB A429 A429 A429 A429 M1553 A429 A429 A429 or Optical

Fig. 4: Experimental System Components

Item 1 2 3 4 5 System Type V M E Dedicat. Airborne Duplex System V M E V M E V M E K.O. Criterias Price o - o - o Flexibility of Structure + - + + + Availability of Interfaces + o ++ + ++ Degree of Integration o ++ + o + Airborne Chassis Avail. + ++ o - ++ Other Criterias Performance + o + + ++ Operating Sys. + ? + ? + Computer to Computer Coupling ++ - ++ ++ ++ Cold Start Capability ++ + - o ++ Repair Cost, Turn Around Time ++ + o o + Development Environment + o + + + Redundancy Upgrade Capability o ++ o + +

Table 1: Decision Matrix for System Selection (Legend: „++“ excellent, „+“ good, „o“ sufficient, „-“ bad, „?“ not enough information for assessment available)

- Widely used hardware standards for inter-faces like ARINC 429, MIL-BUS 1553B, FPDP, CAN-BUS,SCSI etc.

- A well known and widely used processor and bus architecture ensuring future up-grades and changes of the system.

- A widely used operating system supporting

the processor platform as well as all the different interfaces.

Different HW/SW manufacturers have been compared using a decision matrix (Table 1) [6]. The result of the selection process was a VME Bus system using Motorola processors (PowerPC) and running the operating system VxWorks (selection 1 in table 1).

This combination is world wide in use and a very large variety of interfaces is available from different hardware manufacturers. Compo-nents from Radstone (a British company) were selected and interface cards from other manufacturers were added, as long as they support the platform with driver software. Rad-stone delivers the same HW-functionalities in different build levels (Table 2). Build level 3 -the hardest air cooled level - was chosen for FHS because the next level is conduction cooled which cannot be combined with air cooled hardware.

In general one has to deal with the trade off between dedicated flight control computers which are very compact but are also rather inflexible and general purpose computers which are built somewhat larger but provide a high level of flexibility.

Data Management Computer (DMC)

The DMC receives, redistributes and stores all information from the connected base systems as well as from all subsystems of the experi-mental system. This information is not only sensor data but also calculated data from the user algorithms running on the experimental computer (EC). The DMC acts as the center of the whole experimental system. As opposed to most of subsystems the DMC has to be present to give the experimental system any functionality. It distributes the program code to all connected processors and takes care about the presence of subsystems. The most impor-tant feature of DMC is to fulfill the communica-tion requirements in terms of bandwidth and latency time. Table 3 shows the communica-tion requirements for the DMC. To meet these numbers the DMC holds two CPUs and is con-nected with the EC with a very fast shared memory technique which is implemented using a fiber optic communication channel. Thus data arriving at the DMC or the EC are avail-able at each other after a few microseconds.

. Build Stan-dard Temp. Range Vibration Notes 1 Standard Air Cooled 0 to +55ºC 0.002g²/Hz 10 to 2000Hz random Commercial Grade 2 Extended Temp. , Air Cooled -20 to +65ºC 0.002g²/Hz 10 to 2000Hz random Similar to Standard but conformally coated 3 Rugged, Air-Cooled -40 to +75ºC 0.04g²/Hz Wide temp. rugged, conformally coated 4 Rugged, Conduc-tion Cooled -40 to +75ºC Random 0.1g²/Hz 5 to 2000Hz MIL-STD-810 Designed for severe envi-ronment with restricted cooling sup-plies 5 Tactical, Conduc-tion Cooled -55 to +85ºC Random 0.1g²/Hz 5 to 2000Hz MIL-STD-810 Similar to rugged, mil temperature components. Environ-mental Stress Screening (ESS)

Table 2: Radstone “Build” Standards

In each system cycle of 5 ms the DMC ac-cumulates all system data and transfers it to the EC. Vice versa the EC gathers all experi-ment specific data which are needed for stor-age and/or telemetry and sends it to the DMC. Further the DMC has to exchange information

Interface

Type Devices Con-nected Approx.Data Rate

ARINC

429 Cockpit Interface,Radar Altimeter, Air Data Systems, Standard AHRS, Engine Sensors, CDUs 50 KB/s MILBUS 1553B ExperimentalAHRS 30 KB/s Analogue Accelerometers, Noseboom Air Data Sensors 10 KB/s FPDP Rotor Telemetry up to 96 KB/s RS-232 DGPS, Displays 20 KB/s Digital

Switches Pilot Switches <1 KB/s

SCSI-2 Data Storage 300KB/s

(magnitude) Specific Interface Telemetry System 100KB/s (magnitude) Shared Memory EC up to 500KB/s

Table 3: Communication Requirements for the DMC

with the graphics computer (GC) and the CDUs.

Experimental Computer (EC)

The experimental computer EC is the environ-ment for the users' experienviron-ments. It is a VME bus computer running a 200 MHz PowerPC. It provides a direct link to the core system (COS) via standard ARINC 429 connections with 100 kbit/s. An upgrade to an optic inter-face with 2 Mbit/s speed between them is in-stalled at the COS side and can be added later at the EC side.

As the EC is a simplex system but the core system is quadruplex (COS), one ARINC transmitter inside the EC drives all four receiv-ers of the four COS lanes. In the opposite di-rection (COS to EC) all outputs of the four lanes are received by both the EC and the DMC. Thus it is possible to get information from each individual COS lane, but in the op-posite direction all COS lanes get identical commands from the simplex EC. In future con-figurations it is possible to drive the COS by a redundant EC (duplex or quadruplex). The EC is connected to the DMC via a reflective mem-ory interface and can receive data from the basis AHRS systems via ARINC 429 directly and is connected also directly to the experi-mental Honeywell platform via MIL BUS 1553B. It also provides ARINC links to the 2 CDUs residing at the EP‘s (evaluation pilot) and the FTE’s (flight test engineer) place. In-side the EC about 10 VME slots are held free in order to provide space for additional inter-faces of user defined experiments. The soft-ware running on the EC has a cycle time of 5 ms and provides software interfaces to inte-grate user defined software.

Multifunction Display (MFD)

The two displays (Figure 5) are mounted in the console in front of the evaluation pilot and in the flight test engineer's station. The high brightness display MPRD126HB is manufac-tured by BARCO. It has a resolution of 800 by 600 pixels (SVGA) and is night vision goggle compatible. Around the screen 12 keys are arranged for inputs like mode selection. Both displays are equipped with an additional scaler input allowing to overlay video signals of any resolution by scaling them down to a free se-lectable area on the display.

Graphics Computer (GC)

Until 2000 the graphic computer driving the MFDs was a ruggedized Silicon Graphics O2 Workstation. Silicon Graphics was selected because its operating system supports the

rapid prototype development tool VAPS. Un-fortunately the Silicon Graphics hardware, especially the dual head card worked very unreliable and had to be ex- changed several times. In 2001 it was decided to use a normal PC, an INTEL Pentium III 800 MHz in combi-nation with a dual head ELSA Synergy III graphics card. This in combination with WIN-DOWS NT which is nowadays supported by VAPS showed to fulfill all requirements and runs very stable and fast. The PC was equipped with special mechanics and cooling to become airworthy.

Control and Display Units (CDU)

The pilot's station as well as the flight engineer station are equipped with airborne control and display units from Smith Industries. They have a character display with restricted graphics features and have been equipped with a user specific keyboard layout. Via 6 ARINC 429 inputs different systems can log in and then are able to communicate with the CDU using the ARINC 739 standard protocol. The EC and the DMC are connected to the CDU in this manner.

Telemetry and Data Storage

The telemetry system uses a PCM encoder residing on a PCI Mezzanine card on the CPU board in the DMC. This encoder has been developed by Hentschel Systems [7]. Table 4 shows features of this fully software param-eterized encoder. It also allows to merge audio/intercom with the PCM data stream. Video information can also be added using a combiner from Teledyne. Telemetry signal integrity is assured by using two transmitters operating in frequency diversity mode. Also polarization diversity is possible. The antenna arrangement can be selected from a variety of

Fig. 5: Cockpit View, Displays FRESH AIR FRESH AIR 10 20 HDG VS 10 20 250 200 200 200 200 200 M. 200 26000 24000 2500010 90 25000 1013

SELFUNCTION SCAL CONTROL

MPRD 126 F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 10 20 HDG VS 10 20 250 200 400 300 200 100 M. 200 26000 24000 2500010 90 25000 1013 0 10 EP ON ACT SELFUNCTION S CAL CONTROL MPRD 126 F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 10 20 HDGVS 10 20 250 200 400 300 200 100 M. 200 26000 24000 250 0010 90 25000 1013 010 Safety Pilot Evaluation Pilot Flight Test Engineer

Parameter: lower limit upper limit

Syncword: Value any any

Syncword:Length 10 Bit 64 Bit

Position of MSB first last

Bit polarity true complement

Subframelength Syncword + 1

word

1024 words

Mainframelength 1 subframe 256 subframes

Bitrate 100 KBit/sec 3 MBit/sec

Position Subfra-mecounter

after syncword last word within

frame Word:

Frameposi-tion

after syncword last word within

frame Word: Subcom-mutated yes no Word: Subframe-position

first word within frame

last word within frame

Word: Contents dataspezific dataspezific

Word: Length 8 Bit 32 Bit

Word: Parity no even/odd

Table 4: PCM Encoder Features

prepared mounting places (fin of the tail boom, upper or lower side of the fuselage, nose boom). A packet telemetry interface with its corresponding up link receiver isunder devel-opment and will be available in 2002. This will provide even more telemetry flexibility.

All data which is designated to be recorded on board is represented in digital form inside the DMC. Thus an exchangeable 1 Gbyte solid state disk is connected to the DMC via a SCSI link allowing data to be recorded with a sus-tained rate of 18 Mbytes/s (Figure 6).

Sensors

Sensors fall into two categories: Base system sensors and experimental sensors. The base system sensors are connected to the DMC by a careful isolation to ensure that the base sys-tem can not be disturbed by the experimental system.

Base System Sensors

All base sensors provide their information using ARINC 429 Bus. The isolation between these safety relevant sensors and the DMC was made by simply introducing isolation re-sistors into the link to the DMC. The same was done for the intercom.

The following avionics systems of the base helicopter are observed by the DMC:

- AHRS 2x

Two systems : SFIM APIRS 2001, Inter-face ARINC 429, update rate 128 Hz (ac-celeration, angular rate), 64 Hz (attitude, heading), etc.

- FADEC 2x

Two engine control systems providing generator speed, free turbine speed, gas

temperature, fuel flow etc. with an update rate of 40 Hz using ARINC 429 interfaces.

- Radar Altimeter

Bendix/King KRA 405B delivering height up to 2500 feet with a rate of 50 Hz, ARINC 429 Interface

- Air data unit (ADU) 2x

Two Sextant Avionique ADU 3000 systems delivering temperature, static pressure, diff. pressure, mach number, altitude, alti-tude rate, TAS, CAS using ARINC 429 in-terface.

- Intercom as an analog signal isolated by

resistors and sampled in the anlog to digi-tal converter of the DMC.

Experimental Sensors

The following additional sensors are needed for many experiments and therefore have been integrated as part of the standard experimental system [8]:

· Attitude heading and reference system (AHRS)

Honeywell H764G, update rate up to 256 Hz, MIL BUS 1553 B connection for angu-lar rates, linear accelerations, attitude and heading, altitude, vertical speed. The inte-grated GPS system adds position, altitude, timecode and figure of merit to the Mil Bus data stream.

· D-GPS system Sharp XR6 · 3-Axis accelerometer

MSA 100, ENDEVCO Corp., micromachi-ned silicon servo sensor with excellent linearity and adjustable measuring range. In this application it is adjusted to ± 10 g. · Air Data Sensor (see Figure 7)

Swivel head air data boom (Type 100510, Space Age Control Inc.). It measures pitch angle, roll angle, true airspeed and static pressure and is equipped with a tempera-ture sensor.

· Rotor telemetry with data acquisition Developed by Manner Inc., 24 channels, sample rate up to 2000 Hz. This system samples data from sensors on the rotor and transfers them into the DMC.

Cabling, EMC,Shielding, Grounding

Special emphasis was directed to the EMC (electromagnetic compatibility) characteristic of the system. All connections were made by specialists with long term experience in the field of certifiable airborne equipment. A well defined grounding concept which was devel-oped in cooperation with the helicopter manu-facturer is the basis for the cabling. Further the Institute for EMC of the Technical University of Braunschweig was involved. Double shielding for all wires and careful filtering especially of all power supply connections resulted in a com-plete system on a mockup which was carried in a radiation chamber of the Institute. While op-erating the system it was exposed with all rele-vant frequencies in the range of :

· 2.3 GHz pulsed, 2.5 ms, 150 ms, 800 V/m - > no errors

· 100 MHz..1 GHz in 25 MHz steps not pulsed, 50 V/m

- > no errors

· 1.2 .. 2.6 GHz in 50 MHz steps not pulsed, 150 V/m

-> no errors

· 0.1 .. 1GHz in 50 MHz steps not pulsed, 100..200 V/m

- > errors at about 225 MHz

· ESD continuous discharge against com-puter cases, voltage : 12 KV

- > reproducable errors

The effects at 225 MHz were badly shielded power inputs and badly filtered logic inputs to an input card. After adding a shielding cap on the main power input and after adding filters at

the I/O port of the interface card the system worked well. A final test in the chamber is planned for fall of 2001.

Software of the Experimental System

The software which has been developed for the experimental system uses the operating system VxWorks and is written in C. The soft-ware provides a collection of system services to the user. These will be programmed once and are expected to not be changed signifi-cantly in the future:

· service to all connected interfaces,

· manages boot of all connected subsys-tems,

· changes configuration depending of mal-functioning or absent subsystems,

· provides services to the user like sensor data acquisition, display, CDU operation, storage and telemetry operation, display features for the multifunction displays, · manages the interprocessor connection, · realizes a cycle time of 2 ms and

· delivers a well defined software interface for the experimentor's algorithms and modules.

"Software Changes by Parameters"

The whole software system has been designed to change the functionality by changing pa-rameters instead of changing code. Thus the code itself has to be developed and tested once. Of course the effort to develop more generic type software which gets its specific functionality by parameters is much larger than developing dedicated software. But the ad-vantage is that the code itself may remain un-changed for a long period of time. All changes in terms of signal storage, telemetry, subsys-tem presence or configuration, display features and modes are made by sets of parameters. These parameters can be edited by the user and/or are derived automatically from data-bases.

The Software Development Model

Although the experimental system – at least in this simplex stage of the system – is not safety critical and has not to be certified the RTCA-DO-178B [9] standard for development of cer-tified airborne systems has been used as the guiding standard. All procedures of the devel-opment process are observed but not all documents needed for certification are written and not all tests are performed. Additional standards used are the internal software de-velopment standards of DLR [10] and for the Fig. 7: Nose Boom with Swivel Head Air

requirements phase the software engineering standards of the ESA [11].

According to the standards used the SW de-velopment process falls into three subproc-esses (Figure 8):

· Software Planning process

In the planning process the methods and stan-dards to be used are defined:

- Quality assurance standards

- Configuration management methods

- Software development standards - Verification procedures

- Standards for requirements, design and

implementation

· Software development process This process consists of five phases

- Requirements

- Design

- Implementation

- Integration

- User documentation · Software Control process

- Tests

- Configuration - Quality assurance

- Completeness

- Traceability

All stages of the SW development process are carefully checked by a software quality assur-ance process if they conform to the standards

Fig: 9: Components in the Mock Up

Controlled Software Development Process

based upon RTCA/DO-178B, ESA- and DLR-standards

Control

Planning

Development

in each step.

Several tools are used to gain the software development process:

· VxWorks as operating system. · C as programming language. · CVS for configuration management. · Xlint as a code checker against

imple-mentation standards.

· ObjectTime as a design entry tool.

· VAPS for design and program of instru-ments to be displayed.

· ORACLE database for signal and configu-ration storage and for storage of depend-encies between requirements, design and programs.

Schedule and Development Status

During the whole development process for the experimental system a mock up (Figure 9) simulating the mechanical and electrical inter-face to the helicopter was used. With a simple simulation for necessary components, which are connected from outside with the experi-mental system the software and hardware could be tested. In October 2000 the complete system has been successfully integrated into the helicopter. Figure 10 shows a sketch of the overall onboard system. About 90 percent of all software has been finished. The software was exercised for 1 month in the helicopter envi-ronment and showed no major errors. Cur-rently the software of the experimental system software is completed. After the final EMC test the system will be ready to use in time when the helicopters core system is certified at the end of 2001.

Application Areas

In the fixed wing research and industry, the value of piloted flight demonstration has been exploited more extensively compared to the rotorcraft community. For helicopters, flying demonstrators and flying simulators become increasingly important with digital system tech-nology for active control and advanced vision sensors being part of the overall design. The tailoring of the overall dynamic response char-acteristics are allowing to fulfil the mission demands and to adapt the characteristics to the pilot’s capabilities. The pilot station design undergoes fundamental changes with the availability of the advanced technologies. An overview of the status and future directions for helicopter flight control concepts is given in [12] and the needs for airborne simulation fa-cilities are discussed. Extensive experience with the operation of flying helicopter simula-tors have particularly been made in the United States, in Canada, in Germany and also in France. Nearly in parallel the helicopter re-search and industry in US, Canada, and Ger-many are being engaged in the development of advanced flying simulators of demonstrators. External demands on the helicopter system design are the defined mission to be performed in a specified environment. For future helicop-ters the extension of the operational envelope is strongly considered. Helicopters shall be allowed to be operated in extremely bad visual environment at night and in adverse weather close to the ground over unknown terrain and obstacles. These operations have to be per-formed without any reduction of the flight safety.

The extended operational demands with a requirement to increase the flight safety dictate functional requirements which can be allocated to a well balanced design of the integrated

Factor: Workload of Pilot Factor: Degradations of Systems Factor: Limitations of Vehicle Man-Machine Interface Systems Displays Sensors Processors Effectors Vehicle Stability Controllability Sensitivity Loads Pilot Training Perceptions Reactions Decisions Man-Machine Interface

Fig. 11: Integrated System Aspects

Mission Demands Vehicle-Systems Interface Tail Rotor Actuator Main Rotor Actuators

Flight Test Eng.

-Display, Quicklook

-System Test

Evaluation Pilot EP Display

Interface Control Unit Interface Comp.

Test Control Unit Graphics Comp.

Rotor Data Acquis.

Data Management Telemetry Data Recording

Control System Comp. Spare

Safety Pilot

Air Data Senso

system elements and the baseline helicopter characteristics. To not violate the safety of flights, the capabilities of the human pilot have to be observed. Limitations of the pilot in his control task have to be considered especially within delicate and critical flight tasks and in possible degradations due to failures of the integrated systems. Figure 11 sketches the interfacing aspects. Indeed, it is necessary to use the full capabilities offered by active con-trol, digital cockpit, fused sensors and smart actuators which support the pilot to improve the performance in extended missions.

The FHS is designed with the objectives to support the system technology development and to cover the interface aspects illustrated in figure 9. The long term perspective of the FHS utilization addresses the vision oriented goal to improve the overall helicopter efficiency in the direction of

· 24h all weather helicopter and · autonomous helicopter.

Additional aspects will be covered with

· qualification and certification of new tech-nologies related to active control of the helicopter,

· improvement of mission efficiency and · overall optimization of the helicopter

plat-form with advanced control, intelligent dis-played information, and pilot assistant systems related to performance and cost trade off.

In the near future and after delivery of the FHS to DLR the activities will concentrate on fol-lowing impacts of technologies.

· In a first step the flying simulation capabil-ity will be realized with the design and im-plementation of the explicit Model Follow-ing Control System (MFCS). Based on ac-curately identified models of the basic EC135, a feedforward controller is de-signed which compensates the dynamics of the basic helicopter. Together with a feedback for disturbance rejection and feedforward error correction the command models define explicitly the response of the overall system on pilot control inputs. The MFCS approach was realized in the BO105

ATTHeS system. High model following ac-curacy will be achieved up to frequencies over 10 rad/sec and will allow to simulate the broad band characteristics of today’s and future actively controlled helicopters. · The flying simulation capability will be used

for generating an extensive database with the objective to specify the handling quali-ties requirements for future helicopters. Main direction is to extend the existing

ADS33 specification to transport type heli-copters [13]. A flight test program with an operational CH53 helicopter has been launched this year with the objective to identify deficiencies and gaps in the ADS33 for a transport helicopter and to define the needs for improvement.

· For expanding the field of application of FHS, active side sticks will be integrated. A concept study for defining user areas and system requirements has recently been finished with an evaluation of candidates. The active side sticks shall be program-mable to allow the investigation of the definition of mission oriented characteris-tics of active controllers, dual pilot aspects and carefree handling features. The inte-gration of a right hand stick is scheduled for 2002/2003 followed by the integration of a left hand stick.

· Based on the developed full envelope MFCS, advanced control laws will be in-vestigated. These include control laws in the context of a pilot assistant system. Es-pecially in the approach phase, advanced control laws are needed to augment the pilot in his piloting task. In addition, the performance of limited authority has to be investigated corresponding to the possibil-ity to realize higher order control laws. · In a German-French cooperative effort an

experimental system control computer with higher redundancy will be integrated. This duplex processor will replace the devel-oped simplex experimental computer for specific studies.

Concluding Remarks

The FHS development program was launched in 1996. After development the first flight in the electronic control mode is scheduled for fall of this year. The FHS onboard system is de-signed in a hierarchy architecture.

The modification of the EC135 helicopter and the development of the core system is being performed by industry. The experimental sys-tem has been developed by DLR.

The experimental system is designed to meet the requirements for a broad application func-tionality, with high flexibility and with features to allow future extension. The experimental system is composed of the main elements · data management computer (DMC), · experimental computer (EC), · multifunction displays (MFD), · graphics computer (GC), · control and display units (CDU),

· telemetry and data storage and · basic and experimental sensors.

The FHS will be able to cover a broad spec-trum of use for cockpit and pilot augmenting technologies, development, evaluation and de-monstration. First application programs are launched:

· development of explicit model following control systems,

· active sidestick integration, · pilot assistant features and

· integration of duplex explicit computer.

Literature

[1] Buchholz, J.J., Bauschat, J.-M., Hahn, K.-U., Pausder, H.J., “ATTAS & ATTHeS In-Flight Simulators. Recent Application Experiences and Future Programs”. AGARD-CP-577, 1996.

[2] Pausder, H.-J. et al, “Helicopter In-Flight Simulator ATTHeS – A Multipurpose Testbed and its Utilization”, AIAA/AHS Flight Simulation Technologies Confer-ence, Hilton Head Island, 1992.

[3] Pausder, H.-J., Butter, U., Gollnick V., ”ACT-Demonstrator / Flying Helicopter Simulator – An Airborne Testbed Devel-opment Project”, 22nd European Rotorcraft Forum, Brighton, 1996.

[4] Butter, U., Pausder, H.-J., Steinmaier, F., “Safety Concept of Technology Demon-strator ACT/FHS”, AHS Annual Forum, Virginia Beach, May 2000.

[5] Gelhaar, B., Butter, U., Dion, M., Pausder, J., “A New Fly By Light Research Heli-copter”, European Telemetry Conference, Garmisch Partenkirchen, 1998.

[6] Alvermann, K., Gandert, R., Gelhaar, B., Graeber, S., Oertel, C., “On Board Com-puter System”, European Telemetry Conference, Garmisch Partenkirchen, 1998.

[7] Gandert, R., “The ACT/FHS Telemetry and Data Storage System”, European Telemetry Conference, Garmisch Parten-kirchen, 1998.

[8] Schwaneck. H.-P., “The ACT/FHS Sensor Equipment”, European Telemetry Confer-ence, Garmisch Partenkirchen, 1998.

9] “Software Considerations in Airborne Systems and Equipment Certification”, RTCA DO-178B, December, 1992. [10] DLR, Hauptabteilung Qualität und

Sicher-heit: “Software Quality Standards für kleine Projekte”, April 1997.

[11] European Space Agency: “Software Engi-neering Standards”, ESA PSS-05-0, Issue 2, February 1991.

[12] Huber, H., Hamel, P., “Helicopter Flight Control State of the Art and Future Direc-tions”, 19th European Rotorcraft Forum, Cernobbio, 1993.

[13] ADS-33E-PRF, “Handling Qualities Re-quirements for Military Rotorcraft"” USAAMC, March 2000.