Verification & Integration Test Environment (VITE)

The Aviotech test system approach VITE covers three different phases of the development process with its architecture:

• Very early in the development process, model/ or software-in-the-loop approaches allow functional tests to be carried out in a simulated environment.
• Real-time test systems with hardware-in-the-loop simulation capability are indispensable for the laboratory integration and verification of complex embedded systems.
• In vehicle integration and testing, mobile test environments enable data recording and visualization.

The same software is used in all three phases, only the hardware environment varies. This ensures consistent operation and, in particular, the direct transferability of tests from the SiL phase to the HiL environment, for example. In any case, a VITE test environment consists of a host system for control and visualization (GVITE), the actual test system runtime SVITE and – when using SPY technology – a minimal target-side software stack.

VITE application matrix

Functionality

Individual adaptability

VITE test systems have a modular hardware design and are assembled to suit the specific application. The software is customized through configuration. This can either be done once by Aviotech or – if desired – by the customer. This enables the customer to adapt the test system independently as the project progresses or to adapt it to new applications.

Core functionality

• Central, configurable real-time data model
• Real-time logging with any horizon
• Event-based activation of logging
• Option to integrate HiL models
• Residual bus and HiL simulation: support for various IO types available, customizable via configuration (e.g. Discretes, CAN, Ethernet, AFDX, LVDT, ARINC 429, …)
• Support for distributed real-time debugging (SPY technology)
• C and Python API for accessing the test system functionality (data model, logging, …)
• Test script dialect (Python syntax) for simple and concise implementation of test cases in cycle-oriented systems. Automated execution and evaluation including reporting.
• Interface for controlling processing (model execution, IO processing, …)
• GUI functionality
• Java application for Windows/Linux, 32/64bit
• Structuring of test system data freely definable via configuration
• Seamless integration of SPY and IO functionality, live display of the target status when using SPY technology
• Live display of test system data in textual and graphical form
• Display of recorded data in textual and graphical representation, support for common data types, bit field representation, “enumerators”
• Graphical control and monitoring of test system processing
• Ad-hoc implementation of test scripts, function generators, monitors, … (Python syntax)

Architecture

GREATEN

The core of the VITE architecture is the central, real-time-capable GREATEN data model. It is configured on an application-specific basis using XML files and executed in a real-time Linux environment. Reconfiguration is dynamic, i.e. possible at runtime. GREATEN provides the basic functionality (data storage with time stamp, logging, POSIX signals for data-related events/changes) on which all other test system functionality is based:

• So-called IO daemons take over the operation of the IO interfaces for the purpose of residual bus simulation and read/write their data from/to GREATEN.
• Any HiL models read/write their data from/in GREATEN.
• The SPY debugging solution communicates via the GREATEN data model.
• Test scripts access the data via the GREATEN model and use its event and logging functionality.

GUI

Communication with the GVITE GUI is handled by a special communication daemon, which ultimately provides the GREATEN functionality for the GUI via a network connection. This is used, for example, to control the transfer of real-time data for live visualization or to start the logging functionality from the GUI. A second communication link between the GUI and the real-time test system (“supervisor”) enables GUI-based control and monitoring of any processing on the test system.