How to Build a Test Bench - Development Guide

Date: 17 февраля 2021

In this article you will learn more about our methods for the development and design of Hardware-In-the-Loop (HIL) and Model-In-the-Loop (MIL) test benches. This document sums up overall experience of test bench creation gained by our engineers in several CS-25 certified aircrafts projects.

For your convenience, major topics are outlined below:

  1. Part 1. Development tools
    • Automation tools for test bench development and maintenance,
    • Simulation system software and hardware,
  2. Part 2. Tech benches
    • Design concepts for HIL and MIL test benches,
    • Various methods used to speed up test bench development and simplify its upgrade and operation.

Modern onboard test benches are complex tools with high requirements both for integrity and flexibility that must not only function as equipment testers or testing devices (including certification tests) but also address aspects of test bench evolution. Before we proceed it is crucial to highlight some of the test bench design aspects:

  1. Test benches are comprised of EUT, wiring, simulation system, and simulation system software,
  2. Optionally, such items as a cockpit mockup, visualization system, control panel loading systems, etc. may be present on a test bench,
  3. EUT is constantly changing as the product (aircraft design) evolves,
  4. Test requirements are constantly changing,
  5. Test bench specification does not contain every requirement; most of the functionality has to be updated/finalized online,
  6. In order to stay really useful, a test bench must be ready to update faster than EUT.

Therefore, when designing a test bench, you need to understand that:

  1. All hardware parts of the test bench (wiring, cockpit mockup, etc.) should be easy to modify,
  2. Simulation system architecture, setup of models and simulators should also be easy to modify and manage,
  3. You’re going to need tools and programming environment,

List Of Content

Part 1. Development Tools

Provided that modern avionics normally have thousands of wires and hundreds of thousands of data exchange parameters it is obvious that test bench design should start with tools selection capable of seamless connection resulting in toolchain. Based on an iterative method, we came up with the following design approach and set of tools that allow to make test benches universal, modifiable and easily manageable:

  1. dBricks ICD management tool developed by PEERSS LLC,
  2. ADS2R4 simulation environment developed by TechSAT GmbH,
  3. Simulink graphical programming tool (MATLAB-based),

If used properly, these three products can be integrated extensively to simplify most test bench design processes.

At the same time, there was no tool for developing avionics available on the market. As a result, based on our own experience and understanding of all challenges and aspects of designing complex systems, we independently developed dBricks, a universal tool that can be easily integrated with Simulink and ADS2R4.

dBricks tool is used for:

  1. Onboard EUT ICD definition,
  2. Automated mathematical models architecture definition,
  3. Test bench wiring documentation development,
  4. Automated generation of ADS2R4-readable ICD I/O configuration files.

ADS2R4 is a real-time test and simulation environment specifically designed for development, test, integration, and validation tasks with architecture that fits both integrity and flexibility.

About dBricks Tool

dBricks is a core tool that is used to streamline the complex development and integration of onboard equipment. The tool is a single database for handling the following design data:

  1. Interface control documents,
  2. Block and connection diagrams,
  3. Wiring schematics and connection tables,
  4. Harness assembly drawings and tables,
  5. Software input/output dataflow specifications.

Using the tool provides the following advantages:

  1. A single tool for handling various design data guarantees consistency between work scopes,
  2. Multiuser interface especially useful for big and diverse teams,
  3. Embedded wiring and software configuration management,
  4. Automated generation of human-readable documents (e.g. ICDs, schematics, SWSW I/O specs),
  5. Automated generation of machine-readable documents (e.g. ADS2 configuration files, network switches configuration tables),
  6. Integration with other CADs if needed.

Naturally, formats of automatically generated documents can be adjusted according to project requirements.

dBricks has API functionality to make own document generation scripts, and can also be used for database population and update.

dBricks usage especially supports rig development as follows:

  1. Automated generation of ADS2 configuration files is fast and 100% free from human-induced errors,
  2. Rig wiring can be effectively developed based on EUT (e.g. AC) wiring data stored in dBricks.

Physical Equipment Connection in dBricks

Each device description in dBricks includes a list of hardware ports.

Hardware ports are possibilities for physical connection (with the help of wires) of the device to other devices in the project. Port properties include:

  1. Name,
  2. Bus type (for example, ARINC 429 or 28V power),
  3. Direction (input, output, duplex),
  4. Linking port wires to connector contacts (pin assignment).

Fig. 1: dBricks Wiring Data Model

At the project level, device ports must be connected by the use of ‘buses’ entities. Based on pin assignment and port connection data, e.g. connection diagrams can be generated.

Fig. 2: Port Connections and Pin Allocations

In case of aircraft wiring, determination of device inner connections is followed by extensive work aimed to figure out actual implementation details: routing areas, technical connectors, wire branching points, etc. Since test benches are not intended for flight, their wiring layout can be significantly simplified. For more details see description of hardtware in the loop test benches design approach below. For now, let's just say that using dBricks and the approach described below, you can:

  1. Promptly develop wiring design documentation,
  2. Develop wiring update/modification documentation.

The second option is probably even more important than the first one: based on our experience, an aircraft model can face two to three dozen ‘major’ wiring configuration iterations even before certification.

About dBricks Dataflow Data Model

Every electronic unit has collections of functions and port contents. Device functions define the purpose and information flows of the device. Each function describes one of the possible device purposes.

Each device in an equipment system has its own function. The function is determined by the purpose itself and the possibilities of interaction with functions of other devices. In the absence of a purpose, the device becomes unnecessary. In the absence of interaction with functions of other devices, the function should not be included in the system.

Functions may contain a collection of function parameters. As first approximation, each function parameter has the following properties:

  1. Name,
  2. Direction – input, output,
  3. Unit – determines in which units the value of the transmitted parameter is measured (e.g. meters),
  4. Data type – a parameter encoding method (e.g. an integer or a floating-point number, etc.),

Ports contents are definitions of how data is transferred between devices through information ports. The content structure depends significantly on the type of bus used for the transmission. Meanwhile, there are several properties common to all data transfer standards (bus types):

  1. dBricks tool stores contents of the transmit ports, both the output of the unidirectional buses and the transmitting ports of the bi-directional buses,
  2. The transmitted data is the information outputs of device functions, i.e. output parameters of functions,
  3. Data is transmitted through data structures called containers (signals). Unlike function parameters, which have only the properties of a unit and a data type, containers can have a description characteristic of the data transfer standard used. The characteristic properties of containers may, for example, include: address, accuracy, transmission frequency, etc. Depending on the type of bus, parameter coding methods can rely on both standard data types (for example, 32-bit integers, 64-bit floating-point numbers) and non-standard coding types (for example, fixed-point numbers, non-standard-sized integers). As a result, when coding function parameters in the transport layer, an implicit data type conversion occurs. However, the settings schema allows developers, if desired, to limit possible combinations of conversions and to avoid implicit errors in data transfer.
  4. All containers used in the contents refer to function parameters to be transferred,
  5. More details can be found in user manual. Dataflow definition is made by connecting destination (input) parameters to source parameters (output). Each connection contains information on the bus used (physical layer) and the container used (transport layer).

Fig. 3: Data Flow

About ADS2-Based Simulation System

ADS2 stands for Avionics Development System - 2nd Generation. It is a real-time test and simulation environment specifically designed for development, test, integration, and validation tasks in aerospace, space, and automotive applications provided by TechSAT Gmbh.

ADS2 system is essentially comprised of the following components:

  1. Physical hardware, including crates (Windows or Linux), I/O cards, connectors, computers, workstations EUT (Equipment Under Test) connection management), etc.
  2. ADS2 Core – the distributed real-time core software system which fits all the components together. This component is required for each ADS2 node.
  3. Installation-specific, low-level support software for actual hardware of a particular installation, for instance, device drivers running on the ADS2 kernel.
  4. ADS2 GUI Tools Suite – real-time tools serving as the ADS2 graphical user interface.

A typical ADS2 system consists of mandatory standard components such as the ADS2 kernel software, optional standard components such as the I/O hardware selection and the corresponding drivers, and finally custom extensions and modules.

About ADS2 Hardware

ADS2 systems typically consist of the following main components:

  1. One or more ADS2 display systems, that is, workstation computers (Windows or Linux) serving as ADS2 user interface hosts for system configuration and control, data monitoring, test execution, and development and debugging.
  2. One or more ADS2 real-time systems that are able to fulfill both hard real-time and large-scale I/O requirements. They are equipped with
    • ADS2 real-time computing devices (ADS2 kernel)
    • Optional additional real-time CPUs for user simulations
    • I/O boards for fast avionics system I/O, such as AFDX, CAN, ARINC 429, MIL-STD-1553, RS-485, Ethernet, etc.
  3. One or multiple FAST (Future Architecture System Testing) I/O crates for provision of analog, discrete, and digital I/O interfaces - controlled via TCP/UDP (Ethernet).
  4. Optional Timemaster interfaces for time synchronization of several ADS2 systems.

The above list illustrates that ADS2 can be easily scaled from small desktop systems to large distributed systems. Note that the classification does not imply a different software implementation. All systems use the same software and hardware. It’s critical to consider this at early rig development stages. Based on our experience, the need to change system configuration always arises at an inopportune moment during operation, so do not underestimate this.

About ADS2 Software Setup

The following diagram shows the main components of the ADS2 software package.

Fig. 4: ADS2 Software Architecture

The major components are:

  1. ADS2 RT Core – Real-time core of the ADS2 software. The ADS2 kernel maintains the real-time database (CVT) on which ADS2 is primarily based and the configuration database (CDB). The ADS2 kernel is also responsible for controlling and monitoring all other ADS2 tasks as well as external applications.
  2. ADS2 I/O Drivers – Access to I/O is provided through specialized applications that are also scheduled in a specific manner by the ADS2 core. Drivers are available for most I/O interfaces common in aerospace, space, and automotive applications.
  3. ADS2 GUI Tools Suite – Set of ADS2 clients for configuration, control, visualization, acquisition, and stimulation. In this context, clients mean simulation system, line switching, EUT management, etc.
  4. ADS2 API – Common interface for external applications and simulations, which is also used by the ADS2 tools suite itself and the I/O drivers.

Defining and Exchanging Data Through CVTs in Real-Time Environment

Individual pieces of data that are used by various parts of the system and are exchanged between all different types of applications (user-provided applications as well as ADS2 internal applications) are defined in Current Value Tables (CVT). CVTs points are sets of process variables where each individual variable has a definition with a set of attributes that characterize the variable and reflect its intended use. CVTs and CVT points are the only means by which applications can exchange data between one another. CVT points are referred to by name throughout the entire system, so each point can only have a single definition at a given time. The attributes of a point are:

  1. Data type – integer, floating point, string, array data,
  2. Data access type – sampling or queuing (FIFO);
  3. Data attributes – default (initial) value, minimum and maximum value, unit, format, description, and value map (mapping between integer values and strings).

Besides the name given to a CVT point, it can also have additional aliases by which it can be referred to. Individual CVT points can be linked to one another in a way that a point A can be declared to be the source of a point B. This establishes a directed data path between these two points, thus whenever A is written also B is updated accordingly. In this case, the data types of A and B do not necessarily have to be the same; an implicit data conversion is performed (which may, however, result in loss of precision). Applications specify the data they consume and produce by means of CVT points, i.e. a set of points (respectively point names) as inputs and a set of points as outputs. This follows a typical publish/subscriber model of specifying the data interfaces of applications.

For the applications, functions of other applications are completely transparent, as well as it is transparent if other applications produce or consume the data, and what exactly they publish and subscribe to. They simply read from a point and write to a point. The ADS2 Core software takes care of transporting the data to where it is needed. When CVT points are exchanged, there is additional data besides the actual value that is transported and made available to applications: each data item carries along a timestamp that indicates when this data has been produced and a sequence number indicating how often it has been produced.

The ADS2 software itself uses CVTs to reflect certain system states and information. I/O driver applications provide certain predefined CVT points that are used uniformly in all I/O drivers to supply certain information to subscribing applications.

Fig. 5: Exchanging Data via CVT

About Accessing Hardware I/O – I/O Maps and I/O Drivers and Their Configuration

The purpose of I/O maps is to decouple applications of any kind from direct access to I/O hardware, i.e. applications never have to deal with the intricacies necessary to actually perform hardware I/O (such as memory-mapped device access, interrupt handling, etc). Instead, I/O maps provide a means of mapping I/O channels, i.e. specific data items read from or written to I/O hardware to process variables, i.e. CVT points. Applications only have to deal with process variables. The mapping of hardware I/O resources onto process variables is accomplished through a configuration item called the I/O map. I/O channels can refer to any type of I/O handled by the I/O driver applications:

  1. ARINC 429, AFDX, CAN, MIL-STD-1553, etc.,
  2. Discrete RS-232, RS-485, RS-422, etc.;
  3. Discrete I/O;
  4. Analog I/O;
  5. Ethernet-attached measurement devices.

There are two major operations performed by the I/O drivers as part of processing the mapping definitions:

  1. Engineering unit conversion (e.g. translating a 16-bit register value from an analog-to-digital converter to the logical unit that this voltage represents, e.g. temperature in degrees Celsius),
  2. Decomposing and composing messages (e.g. specifying the location of parameters in a bus message and applying EU conversion, if desired, or directly extracting the value into a CVT point or writing a value stemming from a CVT point into that location within the message).

Fig. 6: Accessing hardware through I/O maps

    The actual access to the I/O hardware is performed by I/O driver applications using the I/O map configuration information to transfer and convert the raw I/O data to CVT points and vice versa. Drivers are available for the following types of I/O devices:

  1. AFDX (ARINC 664),
  2. ARINC 429,
  3. CAN (ARINC 825),
  4. MIL-STD-1553,
  5. Analog signals,
  6. Discrete I/O,
  7. Serial I/O (RS232, RS422, RS485),
  9. Synchro/Resolver,
  10. Open number of custom devices manufactured according to specification.

Usage of dBricks for ADS2 Configuration

The dBricks tool can generate the following configuration data needed to start ADS2:

  1. CVT points list,
  2. CVT points links,
  3. I/O map.

The CVT points list is generated based on relevant equipment function parameters of dBricks (see dBricks Dataflow Data Model).

CVT points are generated for all input and output parameters of a function.

Example: The “Flight Warning Application” function of the unit “CentralComputer#1” has three input parameters and one output parameter:

  • In_IRU1_Roll
  • In_IRU2_Roll
  • In_IRU3_Roll
  • Out_Excessive_Roll_Warning

Fig. 7: CVT Configuration Example

    CVT points links are generated based on connections between parameters of functions made in dBricks. For instance, the input parameter “In_IRU1_Roll” of “Flight Warning Application” is connected to the output parameter “Out_Roll_Angle” of function “Main” of unit “IRU1”:

Fig. 8: Linking CVT Points

The I/O mapping is generated based on “ports contents” definitions. For instance, the parameter “Out_Roll_Angle” is transferred via ARINC429 label 325, coding type is BNR (fixed point), least significant bit is 11, size is 14 bits, most significant bit weight is 90, signed, refresh rate is 10ms. This description gives us enough information to create the I/O configuration file.

Fig. 9: EUT Connection Example

    In conclusion, one can create the complete configuration of a large simulation system consisting of hundreds of models and I/O channels in less than an hour.

Other ways of generating CVT and CVT mapping are also available. The one mentioned above is frequently used and illustrates the approach well.

Use of Simulink in ADS2

Simulink is a powerful software solution widely adopted by the aerospace industry. ADS2 offers convenient and simple sync with Simulink for the development of components’ computer models. When used together with dBricks for storing ICD data, it allows to create an integrated toolchain that significantly speeds up development and debugging processes.

The extensive use of Simulink together with ADS2 is possible because of the following facts:

  1. Complete ADS2 common memory with all CVT points is available in all ADS2 nodes, including Windows-based operator computers,
  2. Any CVT point can be accessed by its unique name from every node,
  3. ADS2 provides an API for C++,
  4. Simulink allows connecting external C++ code as separate blocks (a technology called S-function),
  5. S-function blocks can change their I/O parameters based on some external action,
  6. S-function code can be automatically changed by other code while using the Simulink code generation function.

This feature is needed because the C++ code that works in the Windows environment won’t work in the real-time Linux-based environment. So code that works in Windows should be replaced with code that works in Linux if we generate source code of the model for use in a real-time environment.

The process of developing real-time-ready models with Simulink is as follows:

  1. Open empty Simulink model,
  2. Put two S-function blocks (one for input and one for output) in empty Simulink model,
  3. Configure the I/O parameters of the S-function blocks with a special script. The script uses an ADS2 configuration file as source for the list of parameters to be added to the S-function block,
  4. Make or copy your Simulink model. Parameters that exchange data with other models should be connected to the S-function blocks,
  5. Test your model with the connected ADS2 environment by simply pressing the “start” button,
  6. Finish your model,
  7. Generate C++ code with Simulink code generation,
  8. Compile resulting C++ code in Linux-based real-time environment,
  9. Put final real-time model into appropriate repository for further use.

Example. Let’s say we are developing our air data system model and we want to test it in closed loop together with EUT indication and real-time AC model. The air data system model gets airspeed data from the AC model, performs some actions, and sends it to PFD. To perform testing, we start the ADS2 environment with the real-time model of the AC dynamics and the real PFD screen. We move the throttle to maximum; AC begins to speed up. The Simulink model is connected to ADS2, so the Input speed parameter value increases as well. The Output airspeed signal goes back to ADS2, then it is converted to ARINC 429 and sent to PFD. So we can see the airspeed indication produced by the air data system model directly on the EUT PFD. That means we can create and test models using advanced Simulink GUI directly inside the powerful ADS2 environment. Certainly, Simulink running on Windows does not provide real-time functionality, but it is not needed for development.

Fig.10 Simulink-to-ADS2 connection example

Part 2. Test Benches

Electronic Onboard Equipment Integration Test Bench (HIL Testing)

Based on program needs test bench can have one, several or all following purposes:

  1. Support for onboard electronic system development,
  2. Complex testing of onboard equipment including closed-loop testing with pilot or autopilot in the loop,
  3. Initial familiarization of the test pilots with onboard equipment,
  4. Certification testing including failure-resistance tests, takeoff and landing minimums evaluation tests, early ground proximity systems behavior tests, and wind shear tests, etc.
  5. Flight manual evaluation testing,
  6. Routine pilots training with FTD level 4 functionality.

Simulation System Selection

We propose to use an ADS2-based solution as the simulation system since it provides:

  1. Required scalability,
  2. Proven real-time behavior,
  3. Easy Simulink-based model design in complete closed loop,
  4. Easy connections to External Visual Projection System (EVPS),
  5. Rich GUI for rig operators,
  6. Recording functionality,
  7. Script-based formal testing.

The use of an ADS2-based solution will also reveal the full power of automated configuration generation using dBricks.

One of the most time-consuming processes of rig design is the configuration of the models’ interface and the configuration of the I/O boards. This bulky job can be done in an hour by using dBricks. The only thing that needs to be done is to link the simulated equipment ports to ADS2 I/O boards. Then all files are generated automatically and can be used as source configuration files. The typical simulation system of modern aircraft will consist of:

# Name QTY Comment
1 Real-time PC 3 — 6 Part of ADS2 solution. Runs ADS2-specific real-time operating system, Used for running compiled mathematical models of AC movement, equipment, etc., Can be used to add further interface cards needed to connect real avionics hardware.
2 Operator PC 1 Part of ADS2 solution. Runs Windows family operating system. Used for rig setup and control, Can be used for Simulink models testing as part of closed loop.
3 EVPS PC 1 — 3 Windows-based PC with good graphics adapter. Used for generation of pictures for EVPS. Connects to ADS2 data network via UDP packages.
4 FAST ADS2-controlled BOBs (Break Out Box) (FAST ADS2) 1 — 10 FAST is a Future Architecture System Testing a family of TechSAT-designed switching boards (BOBs)
5 I/O boards 10-40 A set of different interfaces I/O boards. The number of this board depends on which EUT will be installed on the Test Bench. Ordinarily this set includes following boards:
  • ARINC 429,
  • ARINC 664,
  • ARINC 825,
  • Serial I/O (RS232, RS422, RS485),
  • Discrete I/O boards,
  • Analog I/O boards,
  • Radio navigation simulation.
  • About Integration of Third-Party Systems

    Some system suppliers are concerned about their know-how and refuse to supply data needed to correctly implement simulations of their systems sufficiently good to trick relevant onboard controllers. Engine suppliers are a good example. In that case, engine suppliers also provide simulators needed on the rig. These simulators are normally connected to the rig central simulation system via Ethernet or (in the worst case) some specific interfaces like “reflective memory”. In any case, ADS2 can support any interface.

    The rig designer should pay attention that after-sales support is covered by the simulators’ delivery contract. As rig designer can’t modify or repair these simulators, a long-term (10-15 years) post-sales service and support should be ensured for externally supplied models (including upgrade, improvements, etc.). This support should also consider problems like spare parts cost, cost and time of repair, obsolescence management for installed equipment, availability of remote technical support, field rep visits, availability of customer support system, etc.

    How to Design HIL Test Bench Wiring

    Rig wiring is one of the crucial parts. Approach and tools used for wiring development and manufacturing can significantly affect rig design and development schedule. We’re using an approach that has proved effective in several projects. Its basic principles are listed below:

    • Rig wiring is not intended for flight, thus there is no need to use actual aircraft wiring Design Documentation. Moreover, the use of actual aircraft wiring can dramatically slow rig design as:
      • AC manufacturing documentation and wiring itself becomes available too late and there’s not enough time for efficient testing,
      • AC wiring is too complex to modify and maintain,
    • Breakout boxes should be used for every bus present on the rig. This approach has its advantages:
      • All harness topologies are reduced to primitives,
      • Every bus can be controlled or modified by rig users with a simple set of instruments in 5 minutes,
      • Overall rig wiring structure becomes easily maintainable and modifiable.

    Fig. 11: Assembled Wiring Harness

    • Rig specific elements like simulation adapters should be connected to relevant buses via above-mentioned BOBs,

      We suggest designing BOBs based on simple COTS, e.g. DIN-mounted WAGO 2002-1871 clamps with brake-out functionality and test ports.

    Fig. 12: BOB based on COTS Components

      The clamp solution allows for multiple connections by arranging WAGO clamps in groups as shown below:

    Fig. 13: BOB arrangement example with WAGO сlamps

    • Connection of simulation system buses should be made with the aid of two BOBs. The first BOB is a common rig BOB used for every bus. The second BOB is a software-controlled BOB of the simulation system. Although this approach seems to be over-redundant at first glance, it is more generic and maintainable than the approach with a single software-controlled BOB.

      An example schematic of a generic signal path looks as follows:

    Fig. 14: Illustration of using HW BOB and SW-controlled BOB. UUT=Unit under test

    • Special dBricks toolbox should be used for rig wiring design and control. Functions of the dBricks rig toolbox include:
      • Simple interface for configuring rig structure, equipment layout, lengths between equipment racks, etc.
      • Toolbox utilizes data entered in dBricks during ICD development phase, thus preventing 100% human-induced mistakes,
      • Rig wiring documentation is generated automatically.

    Normally, rig wiring documentation development for airliner-sized aircraft takes 1-2 man-months of work.

    How to Design a Cockpit Mockup

    Normally, the cockpit mockup should:

    1. Provide mounting space for the EUT usually placed in the cockpit,
    2. Provide convenient (if possible) access to EUT mounting places including access to wiring, mechanics, etc.
    3. Reproduce the interior layout of the cabin,
    4. Reproduce the view out of the cockpit.

    As the cockpit layout is subject to frequent changes, especially before a maiden flight, we start with the initial cockpit mockup and then proceed to the final one.

      Initial Cockpit Mockup

    The initial cockpit mockup (CM) can be designed based on the early designs of the layout. Minor changes in the cockpit layout between initial CM design and certification tests should not be addressed. The design of the initial CM should allow for access to rear panels and concealed parts of equipment. The picture below shows an example of the initial CM. Please note that all side panels can be easily removed, and overall design is modular.

    Fig. 15: Initial Cockpit Mockup

      If possible, we recommend to avoid raised platform whenever possible. However, there are two rational reasons to use raised platform for CM:

    1. EVPS requirements and need for some space below actual cockpit floor. Cylindrical EVPS normally require raising CM to a height of 1.2-1.5 meters. Collimating, spherical projection or simple display-based EVPS does not require doing so.
    2. If pedals or other controls require some space below the cockpit floor, then the CM should be placed over some false floor. Height of this raised platform in that case is normally about 50 centimeters.

    We believe that CM raising height should be lowered if possible. This directly affects safety and ease of rig use. Stairs in rig room are more dangerous than ordinal stairs as people must walk around performing their duties so not so concentrated on walking as if they travel from one building to another. Stairs also prevent using carts, wheeled chairs can fall of it, etc.

      Final Cockpit Mockup – AC certification aspects

    The final cockpit mockup (FCM) should match the real one to meet the prerequisites of the certification tests. Depending on list of tests and authorities’ approach there might be a need to make additional “final” cockpit mockup that reproduce real cockpit. We believe that a solution could be to use the real part of the fuselage – previously used, but no longer needed, for other tests (e.g. “bird strike”, static strength) – with real equipment handling racks, pilot seats, etc. For example, the FCM initially used on the Sukhoi Superjet program was initially used for testing the new production line. It could not be used in real AC as not all formal manufacturing practices were fulfilled but it matched 100% needs of test rig.

    Note: If you plan to use Final Cockpit Mockup as part to FTD Level 4 you should consider requirements that are covered in 4 CFR Part 60. Section 1b of Table B1A “Minimum FTD Requirements – General FTD Requirements QPS REQUIREMENTS” states: “The FTD must have equipment (e.g., instruments, panels, systems, circuit breakers, and controls) simulated sufficiently for the authorized training/checking events to be accomplished. The installed equipment must be located in a spatially correct location and may be in a flight deck or an open flight deck area. Additional equipment required for the authorized training/checking events must be available in the FTD, but may be located in a suitable location as near as practical to the spatially correct position. Actuation of equipment must replicate the appropriate function in the airplane. Fire axes, landing gear pins, and any similar purpose instruments need only be represented in silhouette.” We believe that even initial cockpit mockup meets these requirements.

    Fig. 16: SSJ-100 “Electronic Bird” test rig Cockpit Mockup

    Selecting External Visual Projection System

    There are plenty of COTS EVPS solutions for flight training devices and test rigs. The types of EVPS can differ greatly from simple displays to high-end collimating systems. Two use cases may require using EVPS:

    1. FTD Level 4 use,
    2. Some certification tests.

    CFR 60 Table B1A section 6.a states: “The FTD may have a visual system, if desired, although it is not required. If a visual system is installed, it must meet the following criteria...” Thus, there is no need for EVPS for FTD Level 4 use at all. Even if EVPS is installed simple display-based EVPS will meet requirements stated in sections 6.a.1-6.a.7 CFR 60.

    Most of certification tests are performed in the worst condition, that means instrumented flight rules and zero visibility. The only certification test type where the EVPS type really matters is visibility minimums evaluation. Performing these tests on the rig can save 20-40 test flights. Based on our experience, authorities did not require hi-end class EVPS system to make use Integrated Test Bench results as applicable mean of compliance. Anyway, certification authorities should be consulted if these tests are planned on the rig.

    In real life engineers almost don’t use EVPS as they are focused on equipment behavior. Test pilots are normally satisfied with simple EVPS. Supporting press releases might be a use for EVPS.

    Therefore, it makes sense to choose the mid-price solution of a cylindrical or spherical projection system as it provides:

    1. Required visual field of 120x60 degrees.
    2. Affordable initial and maintenance costs.

    EUT Placement on Test Benches

    We propose to use COTS telecommunication racks (server racks) for mounting an EUT that is normally installed outside the cockpit. The only problem with using them is cooling needed by some equipment. The problem can be solved in several ways:

    1. Design and arrange a special air-cooling system that is basically a high-pressure air fan with a silencer,
    2. Install simple low-pressure fans in special arrangements below the equipment to be cooled. There might be a problem of low performance, but it depends on the actual cooling needs,
    3. Install high-pressure fans in special arrangements below the equipment to be cooled. They have a good performance, but they can be quite noisy as well,
    4. Install special air conditioners on the back doors of the equipment racks, e.g. Rittal SK.

    Creating Power Distribution System

    PDS as described in proposal is a system that distributes EUT power. It replicates PDS used in AC.

    Conversion of 115 Volts alternating current to 28 Volts direct current and 115 Volts 400 Hertz is not a problem. A lot of COTS devices are available. Thus our proposal does not focus on that work.

    We propose to use the following approach:

    1. Initially, a special rig power distribution system mockup is used,
    2. Before the start of the certification tests, the mockup is replaced with a “real” power distribution system.

    The initial PDS mockup is made with COTS general use parts like WAGO clamps, relays, fuses, etc. All these parts are mounted on DIN rails or similar easy-access surfaces. Schematics for all connections should represent the proposed “real” PDS. Solid-state controllers can be used as is from the very beginning. Airborne PDS may not be available in time and is normally subject to many changes and updates, especially at the early stage of development. All these modifications can be completed much easier with an easily modified mockup than with an actual compact airborne power distribution device design.

    Before the certification tests start, the PDS mockup can be replaced by real EUT PBS.

    Electronic Onboard Equipment Rapid Prototyping Test Bench (MIL Testing)

    Based on program needs test bench can have one, several or all following purposes:

    1. Flight control laws evaluation,
    2. Flight deck displays and control panels initial layout evaluation,
    3. ICD dataflow testing,
    4. Equipment behavior evaluation before equipment functional requirements are transferred for SW and HW design and manufacturing,
    5. Complete system early fail-safety evaluation and testing.

    Simulation System Selection

    We propose to use ADS2-based solution for MIL test benches because of the same reasons as for HIL test benches. Typical simulation system of test bench consists of:

    # Name QTY Comment
    1 Real-time PC 1 Part of ADS2 solution.
  • Runs ADS2-specific real-time operating system,
  • Used for running compiled mathematical models of AC movement, equipment, etc.
  • Can be used for further addition of interface cards needed for connecting of real avionics hardware.
  • 2 Operator PC 1 Part of ADS2 solution. Runs Windows family operating system. Used for
  • rig setup and control,
  • can be used for Simulink models testing as part of closed loop,
  • Used for registration of data exchange and its subsequent processing/analysis.
  • 3 Control Panels and displays Displays simulation PCs 2-3 Part of ADS2 solution. Runs Windows family operating system. Identical to Operator PC but used for simulating displays and control panels
    4 EVPS PC 1 Windows-based PC with good graphics adapter. Used for generation of pictures for EVPS. Connects to ADS2 data network via UDP packages

    Development Of Mathematical Models

    Any test rig evolves as the project progresses. Therefore, nobody can propose the “complete” or “best” set of models to be developed. The good practice to keep a MIL-testing bench useful over the complete project timeline with affordable investments is to be flexible and try utilizing the Pareto-style approach. Nevertheless, we will try make an example of “initial” and an “advanced” set of models to exemplify ways to proceed.

    The initial set of models in our example support the following activities:

    1. Control system test laws development and testing,
    2. Initial PFD layout demonstration and testing.

    During initial testing phase, there is no need to implement complex models of flight control electronics that include redundancy, reconfiguration, latency, etc. There is no need for testing complex applications like FMS either. Therefore, following preliminary list of models can be used:

    # Model Name Development Means Hosting Part of Simulation System Comment
    1 AC dynamics model Simulink RTPC Simple rigid AC model. Experience shows that XPlane-alike solutions are not accurate enough to build appropriate control laws. Simple Simulink model has to be based on careful numeric aerodynamics simulation joined with wind tunnel test results.
    2 Atmosphere model Simulink RTPC Includes standard atmosphere, wind simulation, simple anomalies simulation.
    3 Simplified engine model Simulink RTPC Direct link between TLA position and thrust.
    4 Simplified flight control electronics Simulink RTPC No redundancy, no signal quorum, no extra sensors (e.g. hydraulics) handling.
    5 Simplified Flight control surfaces actuators Simulink RTPC No dependency from power source (hydraulics and electricity), no feedback from aerodynamics forces
    6 Simplified air data and attitude sensors Simulink RTPC No redundancy, no errors models.
    7 PFD simulation C++ or Python Display simulation PC No redundancy, no health control, no reconfiguration, no navigation, no TAWS or TCAS data

    The “advanced” set of models should support the following activities:

    1. Advanced flight control laws testing including redundancy, latency, faults, etc.,
    2. Autopilot laws and control logic testing,
    3. Complete flight deck environment simulation and evaluation including PFD, ND, FMS, CAS messages, synoptic pages, and control panels,
    4. ICD data flow evaluation including analysis of path each parameter should pass before it gets from source to destination,
    5. Fault results analysis,
    6. SW requirements validation before moving on to time-consuming DO178-regulated development.

    As a result, the list of the final models is much longer. The list provided below is neither complete nor accurate. However, we believe the can give an impression of the work to be done.

    Advanced list of models

    # Model Name Development Means Hosting Part of Simulation System Comment
    1 AC dynamics model Simulink RTPC
    2 Atmosphere model Simulink RTPC Includes standard atmosphere, wind simulation, simple anomalies simulation, FAA Advisory Circular-regulated anomalies.
    3 Engine model Simulink RTPC Includes mechanical part of engine.
    4 Engine control electronics Simulink RTPC Includes separate models for control and monitor channels, includes side-to-side monitor and control logics, considers that several sources of data available for any safety-critical function.
    5 Flight control electronics Simulink RTPC Includes separate models for control and monitor channels, includes side-to-side monitor and control logics, considers that several sources of data available for any safety-critical function, considers electrical power and hydraulic possible faults.
    6 Flight control surfaces actuators Simulink RTPC Dependent of all factors that can affect functionality: hydraulics and electric status.
    7 Detailed avionics sensors Simulink RTPC Separate models for separate sensors: ADC, IRU, GPS, VOR, DME, RA, ILS, etc. Contains possible failures simulation and measurement mistakes.
    8 AC systems Simulink RTPC Includes models of systems that can affect avionics behavior:Electric generation and distribution, APU, fuel, hydraulics, landing gear, nose wheel steering, doors control, fire protection, flight deck environment, etc.
    9 AC systems electronics Simulink RTPC Includes simulation of sensors, data concentrators, if any, and system controllers, if any.
    10 Display simulation C++ or Python Display simulation PC Normally consists of PFD, ND, FMS, TAWS, CAS, synoptic pages, CAS-messages, etc.Should consider real data flow, redundancy, reconfiguration, etc.
    11 Control panels and signal lamps C++ or Python Display simulation PC
    12 Minor controls C++ or Python Display simulation PC Includes landing gear lever, ground steering wheels, flap/slat control lever, spoilers control lever, etc.
    13 Central computers Simulink, C++ or Python RTPC Normally include simulation of following applications: FWS, DCA, SWS, CMS.

    For seamless transition between the initial and the advanced set of models, the following criteria for simulation systems should be met:

    1. Scalable simulation systems architecture,
    2. Use of tools for dataflow configuration control,
    3. Automated generation of model interface configurations. It includes mainly I/O parts of Simulink models and I/O code parts of models developed in C++ or Python,
    4. Careful configuration control.

    One more thing must be mentioned: if similar architecture is used for MIL and HIL test benches, many of the above-mentioned models are developed once and can be easily reused in any test benches.

    How to Design a Cockpit Mockup

    The following approach is used for MIL rig cockpit mockup:

    1. All avionics, including displays, control panels, etc. are simulated on COTS touchscreen displays. Touchscreen functionality is mostly needed for making use of control panels,
    2. Primary control levers, namely control sidesticks, pedals, and TLAs, are simulated using COTS gaming devices,
    3. All displays are mounted on a mounting rack with standard VESA-style mounting.
    4. Primary controls are fixed on special flat metallic surfaces.

    Fig. 17 Cockpit Mockup Concept

    External Visual Projection System

    Any EVPS system needs from simulation environment continuous information of AC coordinates and Euler angles. Normally that data is sent using general use Ethernet via UDP packages. ADS2 environment can be easily configured for sending UDP packages with AC coordinates. That gives connectivity with virtually any EVPS solution.


    Test bench design becomes simple when you understand why certain decisions are made. This information was compiled based on our years of work and experience in implementing successful and unsuccessful technical solutions.

    You can request this text as a formal document in pdf format by the link
  • CTP.0001.02.en Avionics Equipment Integration Test Benches. Design Proposal
  • On our website we use technical, analytical, marketing and preference cookies. These are necessary for our site to work properly and to give us information about how our site is used.