Category Archives: Software & Testing Solutions

Powertrain Test Field

Workflow-Based Information Management for Powertrain Testing Facilities

22. October 2019 | Software & Testing Solutions

Workflow-Based Information Management for Powertrain Testing Facilities

Compared to the amount of raw measurement data generated and processed by self-driving vehicles, the amount produced during powertrain testing is quite easily manageable. However, the sheer variety of information encountered with powertrain tests and how the pieces interact place high demands on the tools used to process that information. An efficiently organized testing facility therefore needs that information to be structured and standardized sensibly and its information management tools to be networked intelligently. That is the only way to speed up information processing during the testing process and maximize the knowledge gains.

Due to the variety of information, it makes sense to divide information into domains (Figure 1). Then, the flow of information between the domains and an adequate tool chain can be specified and set up.

1: Information domains and flow in the testing process

FEVFLEX™ enables the configuration of project data, such as team definitions and availability, time frames and budgetary conditions, and allows for the transfer of this data from the ERP system and machine data acquisition systems to the first information domain – the testing assignment database. The powerful, graphical user interfaces in FEVFLEX™ enable a reliable planning and coupling of test programs and resources (test beds, measuring instruments, personnel).

A tied-in, digital order management system allows instructions prepared in writing to be issued to laboratories and workshops along with the master data so the necessary measuring tools can be prepared and the test setup be initiated. Information about the subject of testing and the testing program as well as the control unit data sets are supplied by the respective specialist department.

It is clear that reliably functioning information tools also need to promote collaboration and the exchange of information between process partners during testing assignment planning so the information can be combined efficiently and without any loss.

At FEV, our specialist departments and testing facilities do this by using the identical front end of the testing assignment database seen in Figure 2.

The inspection order data is automatically transmitted to the second information domain. FLEX Lab™ creates the configuration of the test bench automation system, MORPHEE™, where it serves as the basis for performing the tests.

2: User interface of the testing assignment and testing database

In the testing database, individual test steps, such as engine characteristic map measurement, full-load curve, or an emission cycle, are specified, depending on the test types required (Figure 2). Because the information is inherited, only deviations from the planned testing requirements need to be recorded for the subsequent steps and documentation purposes. The test bench operator selects the appropriate step from the testing database via the automation system’s interface, thus creating a connection to the measurement data.

Linking the test assignment data with associated rules, the set points actually achieved during the test, and the time-synchronous measurement data from the various measuring systems produces a complete set of data for calculating test results and for further analyses. Computations are performed as needed. The automation system calculates control deviations or significant quality criteria, e.g. measuring point stability, in real time during measurement. Once the system processes them, they are transferred to the database. Additional calculations based on a standardized list of formulas are performed after the measurement results are imported into the testing database. The results of those calculations are stored separately.

Upon conclusion of each step in testing, we have a pool of informative data available for quality assurance by the testing facility or for additional analyses, even for multiple projects, by the specialist department.

In the third domain – the operational database – the logbook functionality in FEVFLEX™, enables the logging of code-based operating states and error messages of the automation systems and measuring devices in the test field. This makes additional information available.

The test bench operator supplements that information with reports on the error patterns and root causes. If need be, the personnel also prepares 8D reports, as seen in Figure 3, which are forwarded directly to the responsible workshops or laboratories via a messaging system for further follow-up.

3: Operational database and code-based logging of operating states and error messages

This makes the operational database an important tool for supporting operations in addition to the automated productivity analysis of individual projects or entire testing facilities. In the testing facility’s organization, this is handled by various equipment managers, each of whom receives reports about error codes within their purview as well as the anomalies, errors, and the root causes contained in the reports. A powerful interface provides them with extensive information, and they can intervene quickly and selectively if a risk is encountered.
Inheriting the test assignment data links together all information from the test steps and operations. All the information can still be traced, and the preparation of component histories, i.e. load spectra, measurements, and anomalies experienced during the test phase, is simplified considerably.

Quality assurance using online plausibility checks

To verify and examine the plausibility of measurement results while testing is being conducted, the interface between the test bench and testing database offers a data transfer tool with enhanced features, as seen in Figure 5. It successively imports raw data into the testing database during the current measurement process, performing automatic analyses as it does. The test bench operator receives continuous information about the test results via the on-screen visualization (Figure 4) and can, if necessary, intervene to make manual corrections, unless they are already made automatically.

4: User interfaces and visualization of the information management system, shown here at an operator station in a control room

Besides confirming adherence to the testing rules, the plausibility checks involve ensuring the measurement results are complete and comparing the measurements to an expected but not yet critical range of values. They enable early detection of changes or malfunctions in the test item or even the testing equipment. Furthermore, the transfer tool can perform a data-driven analysis of gas travel times when measuring emissions and perform a regression analysis in order to promptly calculate and examine the plausibility of specific emission values. The results of the plausibility check are also stored in the testing database.

5: Online plausibility checks of measurement data using the data transfer tool with enhanced features

Online plausibility checks during data import thus contribute significantly to the quality assurance of testing operations.

Post-processing and reporting

Automated reporting is based on machine-readable report definition, plus standardized report templates and naming. A typical quality measure used by testing facilities is regular, at least daily, taking of reference measurements based on characteristic operating points. The status of the data on the test item and the testing conditions are kept constant at all times. This allows changes or shifting measurements over long periods of testing or after modifications or repairs to be detected quickly. The analysis feature built into the data transfer tool calls up the automated generation of a report in the evaluation tool, UNIPLOT™. The feature supplements data currently being measured with reference measurements already stored since the beginning of the test.

In addition to the quality reports, other project-specific testing reports have been defined. They are available shortly following completion of each test thanks to automatic processing of the test results to be presented. Calculations for individual projects are stored in the database as supplemental computing rules, thereby expanding the contents of the automated testing reports.

Global networking of testing facilities

If test runs are organized across locations, for instance, whenever complicated logistics for test items and components are to be avoided, but a different facility possesses the subject matter expertise, it becomes essential to have rapid and secure exchange of information within the worldwide corporate network.

It is not mandatory for the databases to be situated in the same location as the test execution site or the specialist departments. To ensure efficient testing operations while meeting quality standards, a part of the testing results must be available locally after a short time. This is made possible by replicating the data transfer tool at the local facility. The tool then performs the online plausibility checks and prepares the quality reports. At the same time, the local data transfer tool organizes the data transfer to the central database, where it starts additional alculations and preparation of the project reports, as illustrated in Figure 6. The testing facility, therefore, has a comprehensive report on quality assurance and initial analysis available to it in just a few minutes.

6: Global networking

The testing assignment database and testing database are accessed directly using a virtual desktop infrastructure. With it, the expert team can specify new testing assignments or individual test steps, which are made available to the test bench operator as orders on the books in the central testing database. To aid communication and global collaboration, FEV also uses virtual control stations. Comparable to the central control room at a testing facility (Figure 4), a virtual control station is also used to transfer information on online plausibility checks and the status of the automation and the application tool.

Test steps can be continuously assigned and complete test results then promptly communicated between an expert team and a remote testing facility via the testing database. In a series of internationally organized projects conducted at FEV, it was shown that the entire set of test results, including all automated calculations and reports for a test step, can be available worldwide in no more than 15 minutes.

FEV’s shared testing database is thus the central platform for the group’s global network of testing activities.

The necessary standardizations and information management tools were developed by FEV and are being continuously perfected. On that basis, our customers have an attractive range of products available to them – from the automation system MORPHEETM through data management in FEVFLEXTM and FLEX Lab™ to the evaluation in UNIPLOT™ for the information management in testing facilities.


Expertise and Capacity for e-testing projects

Testing Facilities

18. October 2019 | Software & Testing Solutions

Testing Facilities

In the coming year, FEV plans to open two new battery test centers – one in Germany and the other one in France. Additionally, new e-motor and e-axle test benches have been integrated into FEV’s test centers and on customer sites. Based upon long-term planning and construction experience with FEV’s own test cells and test centers, as well as in numerous customer projects, FEV provides an effective methodology for specification development, concept layout and planning for e-mobility test benches, test cells and test centers, this methodology covers hardware (test equipment, technical infrastructure, building), software (data management), logistic and operation aspects.

Based upon FEV’s long-term experience, the sustainable success for the construction of new test cells and test centers is highly influenced from quality and completeness of the specification and planning phases. Precise requirement analysis, complete specification development and well-designed concept development are the key factors which deliver the solid foundation for a successful realization of these projects. Due to the extensive experience acquired by FEV, the described project phases can be actively organized and guided in close collaboration with future users/ customers in order to ensure the development of sustainable and cost-effective solutions which cover future requirements to the highest possible degree.

The final goal is to develop a technical solution covering building construction aspects, concepts for the test cells and test benches, laboratories, workshops, the technical infrastructure including supply media and energy supply, furthermore operational and logistical issues. Due to long-term, global experience, FEV’s experts provide the right solutions. They have the in-depth knowledge and experience gained in the construction of their own test centers for the mobility of the future to support customers. They use specific calculation and simulation tools to simulate the different scenarios.

1: Questions to be asked at the beginning of a test center building project

Boosting the test center performance

In state-of-the-art test centers, the visible parts, such as the buildings, the building infrastructure and the test benches can no longer be separated from the invisible parts – the comprehensive information system with a high automation degree.

Let’s evaluate how this information system controls the workflow and use cases in a battery test center. When the battery pack, module or cells and (sub-) components are received, a bar code is created that follows the Unit Under Test (UUT) throughout the entire workflow. The UUT is taken from a safe storage room and subsequently equipped with sensors and measuring devices in a preparation area. The availability and maintenance status of resources (equipment, test benches, employees) is documented in a database, thereby supporting an efficient and effective planning and assignment of UUT and resources. After the installation of the UUT at the test bench, the test programme is executed, followed by the post processing of the measurement data being acquired via the automation system and further measuring devices. The measurement data is checked regarding plausibility and finally documented in standardized test reports. The information system allows data on the UUT, the assigned resources, the test program and test results to be logically linked throughout the workflow. The above information system is based on the FEVFLEX™ software suite.

This modular, layer-based suite features dedicated modules for managing the main workflow of a test center, starting from the test demands up to the final test reports:

  • Enterprise functionality at the layer of the overall test center:

FEVFLEX™ facilitates experiments in the field of simulation, benchmarking, and component and system test benches up to vehicle fleet tests, as well as combinations of those. At this layer, work orders are created by combining data from ERP and MES systems (e. g. customer and project data, cost centers) with information on the UUT, the test program and the availability and status of resources (equipment, test benches, employees). Tasks are planned and subsequently assigned to test benches and resources. Moreover, FEVFLEX™ allows the UUT and its (sub-) components to be defined in a Build of Material (BOM) list – well known from benchmarking contexts – thereby supporting UUT life cycle control. In the final stage of the workflow, FEVFLEX™ handles test results from any source (benchmark or simulation data and measurement data obtained from the automation system and measuring devices), which are subsequently time-synchronized and pushed to data evaluation tools.

  • Host system functionality as binding factor between test center and test benches:

FLEX Lab™ takes care of the overall data handling and parametrization of MORPHEE® automation systems at component and system test benches. At this layer, the FEVFLEX™ work orders are translated into the preparation of the automation system resulting in a base parametrization (including e.g. a measuring plan, channel limits, log lists, integration of measuring devices, test program).
Furthermore FLEX Lab™ supports the management of MORPHEE® configurations, including back-up and versioning. Launching the execution of test programs at the test bench is secured via communication between the FLEX Lab™ host system and the MORPHEE® automation system. Finally, FLEX Lab™ pushes the measurement data, which was acquired via the automation system to data evaluation tools, such as UniPlot.

2: Process managed by FEVFLEX™ in an e-mobility test center

As a final conclusion, the workflow in FEVFLEX™ is supported by SCADA remote monitoring and run-time statistics:

  • Remote monitoring supports immediate alerts and interventions in case of incidents
  • Run-time statistics support facility managers to repair weaknesses in their workflow sustainably

With the help of this comprehensive information system based on the FEVFLEX™, an effective test bench usage of 95 percent was reached in FEV’s battery durability test center.



Electrification – Software and Testing Solutions

15. October 2019 | Software & Testing Solutions

Electrification – Software and Testing Solutions

Within the next ten years, electric vehicles are expected to account for 90 percent of the market, including full-electric vehicles and various versions of hybrid vehicles. Many new test benches for e-mobility and batteries are being built. So what are the key points we need to understand for this new type of bench? How can we find our way around this new world of tests for electric or hybrid vehicles?

The list of challenges is long. First, and most importantly, are battery tests. Today’s lithium ion batteries provide an energy density 20 to 30 times inferior to gasoline, and to achieve cost parity with a petrol-driven vehicles, we have to cut their costs four-fold. This cannot be done overnight, but the calibration of the BMS (Battery Management System) must be optimized immediately, which requires precise means of optimization on the test bench. For battery test benches, a highly automated and staff-saving process is required. It must be able to react and supervise all the test benches in real time. File formats must be identical, irrespective of their source. In some centers, each device has a different file format, which affects the center’s productivity. In addition, safety is a prime concern with batteries. Great attention must be paid to extreme conditions, in which the internal chemistry in the battery can go out of control. Severe battery tests are necessary, including fire tests, overvoltage tests, crash tests or tests in which the battery goes completely discharged. While the battery is the most sensitive element to be tested, testing electric motors also presents technological issues. Upcoming motors can reach up to 25,000 rpm. In some phases, the temperature suddenly rises, to the detriment of the motor’s longevity. In this case too, the optimization of the global Energy Management System (EMS) will allow critical cases to be managed, increasing the life span of the e-motor.

FEV summarizes the keys to e-mobility test center and system development by highlighting three points: the automated management and global supervision of the processes and the test benches, using the FEVFLEX™ and MORPHEE® software suites. The standardisation of test bench solutions, or Test Cell Products. And, the calibration of the controllers and the optimization of energy management, which demands the extended use of simulation. This vision is the result of more than ten years of experience, with two test centers in Munich and Saint Quentinen-Yvelines (France), equipped with 22 test benches to test batteries, and numerous e-motor and e-axle cells.

Fevflex und Morphee testing process for e-mobility

Fully automated process
A fully automated process is a key factor in any modern test center, but it is particularly important in battery test centers. This is done through software, such as FEVFLEX™ and MORPHEE®. FEVFLEX™ is a modular software suite dedicated to manage and monitor the entire test field. (For more information on using FEVFLEX™ in an e-mobility and battery test center, see article “Expertise and capacity for e-testing projects”, pages 40). All the information sent to FEVFLEX™ is produced by MORPHEE®, FEV’s automation system. The electric revolution is only just starting. Batteries, electric motors and general vehicle architectures are set to evolve even further. In this respect, FEVFLEX™ and MORPHEE®’s upgradeability and applicability makes it a complete must. These open tools can be easily configured by the user, at no additional development cost. MORPHEE can be connected to all types of devices using the same programming interface. It produces and synchronises result files in an identical format, irrespective of the equipment used.

FEV Osiris Powermeter

Test cell products: standard solutions
2019 will be a very special year for ­FEV Software and Testing Solutions , with the launch of the test cell products and standard test bench solutions. Over the years, many benches have been built, both on FEV’s own sites and on customer sites in Europe, Asia and America, ranging from complete engineering projects, to simple automation. FEV has built on this experience to develop standard test bench solutions, or test cell products, that use FEV’s products and products from approved suppliers. Thanks to this standardization, FEV can control costs and propose shorter deployment cycles. This offer covers all the necessary dimensions of the field of electric vehicles, and the safety-related aspects in particular.

FEV proposes battery test benches covering every test case: cell benches with up to 24 cells per climate-controlled chamber, module benches with up to six modules and integrated pack benches, either in walk-in chambers, or in king-sized climate-controlled chambers.

FEV also proposes standard e-motor test benches that can be used to characterise electric motors. The key aspect of this type of test bench is its ability to test at very high speeds and in a highly-dynamic process where vibrations are taken into consideration. FEV produces state-of-the-art e-motor test benches, including dynamometers. It offers e-motor test bench solutions enabling rotational speeds of 25,000. The MORPHEE® solution used to control the bench replaces the bench controller, offering very easy connectivity with the calculators. The e-powertrain is optimized by taking several use cases (motorways, urban environments or rural areas) and several factors (voltage and current signals, frequency versus angular position and speed, transient torque management etc.) into consideration. In this case, FEV’s OSIRIS® Powermeter serves to analyse the efficiency of the e-powertrain system by measuring the power before and after the inverter and before and after the e-motor.

FEV offers unique solutions facilitating not only the optimization, but also the validation of the complete driveline. Durability tests simulating mechanical cycles (vibrations, reducer, differential) and thermal shocks (cooling, rotor thermal management) must also be conducted. In this configuration, a good solution is to test not only the e-motor, but also the complete drive chain. On the so-called e-axle test bench it is possible to test the entire system in the downstream steps of the development process and involves using both MORPHEE® and OSIRIS®, as well as FEV dynamometers and conditioning units for fluid cooling – the so-called eCoolCon™.

FEV e-CoolCon

Energy Management System optimization
The final key factor of success of an e-mobility test center is its capacity to optimize the calibration of the various calculators and the EMS (Energy Management System) of the drivetrain. This was already one of FEV’s strengths in the field of conventional engines, and it is still the case with electric or hybrid motors. FEV has achieved this by developing tools with two characteristic features: a very high level of performance and complete compatibility with one another. In the initial development phases, xMOD™, a virtual experimentation and co-simulation platform, creates a system that was complex to develop by co-simulating the different models that describe it: the electric motor, battery, driver, complete vehicle, etc. Consequently, virtual experiments can be made on the same platform in order to prevalidate the control laws. In the following step, the bench controlled by MORPHEE® – in this case the battery and BMS bench or the e-powertrain bench – is used to integrate the previously validated models by replacing the battery or e-motor model by the physical part, and by keeping all the other parts to produce the most accurate representation possible of the drivetrain in its environment. Since xMOD™ and MORPHEE® share the same DNA, the interfaces, tests and models all follow the same process, from the beginning to the end, in what FEV calls the Collaborative Framework. It should also be noted, that the exceptional simulation performances of these tools, which are 10 to 40 times faster than any other solution on the market, enable highly complex models to run on the test bench in real time.

Morphee Desk and Simulation Screenshot

Future Mobility

The Balance Between Complex Testing Tasks and Effective Development in Testing Environments

11. September 2017 | Software & Testing Solutions

The Balance Between Complex Testing Tasks and Effective Development in Testing Environments

The areas of mobility and transportation are undergoing a heavily accelerated process of change. Traditional global mega-trends encompass widely differentiated user-specific and customer-specific requirements, different laws, ever stricter environmental regulations, limited resources and the electrification of drive systems. In addition, issues such as autonomous vehicles and customized, on-demand mobility solutions are growing in importance. Coming up with solutions and products requires completely new approaches on top of the established technologies, where constant advancements are needed. Examples of such approaches include digitization, information technology and networking.

The increasing complexity and differentiation result in stricter requirements that cannot be met in acceptable time frames at an acceptable cost level using established methods and processes. New, customized and specifically designed solutions and products must be developed to overcome these challenges.

Over the past years, advanced and high-performance simulation processes have become established as a main pillar in the portfolio of vehicle and drive system development. Numerous conventional methods of testing and proving have been partially or completely replaced by computer simulation. Increasing system complexity and validation requirements today and in the future, however, require specifically tailored testing solutions to validate functional reliability, quality, etc.
The suitably powerful testing capacity available provided in today’s cutting-edge development environment is no longer limited to mere logistical and technological solutions such as test rigs and measurement systems. For services to be highly efficient, all stakeholders need to be appropriately involved in the entire process of development. Besides designing and equipping the testing environment, this includes areas such as personnel structure and expertise, methods, operational organization, highly efficient logistics, information networking, and more.

Future Testing Environment Strategies

The design of future testing environments must be based on medium-term and long-term strategic product development planning and the testing requirements derived from it. They must do more than meet the simple engineering, operational, and logistical requirements. In particular, they need to be cost-effective, have a balance between operating capacity and personnel resources (and ensure they are utilized to the greatest possible extent), and assign work sensibly between what covers their own needs and what is commissioned by customers.

Testing Environment Organization and Processes

The organization and processes of modern testing environments have changed fundamentally in recent years. In the past, workers from development departments were often very extensively involved in the testing environment operations, sometimes even having a say in how they were conducted. The testing environment staff essentially represented the facility’s capacity, resources, and operators. Responsibility for defining the testing program and performing evaluations rested with the engineering department.

Over the past few years, various tasks have been shifted from engineering to the testing environments. Today, many testing environment crews are, for the most part, independently in charge of generating all test results. It takes adequate human resources and engineering capacity to perform these additional duties. That includes making the testing environment responsible for all processes and their design as well as medium-term and long-term structural orientation and investment budgeting.

Staff: Structure and Authority

The increasing transfer of numerous duties from engineering to the testing environment’s area of responsibility is creating a need for a greater number of engineers in current personnel structures and ranges of expertise. In the past, the largest share of a testing environment’s staff by far consisted of mechanics and some electricians and foremen with very few engineers. Today, the percentage of technicians and engineers has risen sharply. Added to that are IT and other specialists of various disciplines, who take care of the sophisticated test rig automation systems, measurement systems, and various software tools.

Logistics, Plus Flows of Information, Materials, and Data

Organizing modern testing environment operations to be efficient and economical requires the implementation of processes structured to be efficient and flexible from end to end and which can be adapted to meet changing requirements. This includes information management, which encompasses the handling and distribution of all incoming, internally circulating, and outgoing information, the management of experimental and measurement data plus material flows and logistics, quality management, and more. All primary and support processes need to mesh with each other smoothly and require continuous assessment, adjustment, and optimization.

Graphic - FEV Testcenter efficiency

Working and Testing Methods

Today’s advanced testing environments already use IT-based methods and tools to a large extent for organizing processes and performing work. Examples include databases used to aid in the preparation of project-specific test rig set-up and program plans, largely standardized test rig and measurement systems, highly automated running of test programs, integrated computer simulation tools, automated evaluation of test runs, and databases used to file test results.

The FEVFLEX information management software offered by FEV is a powerful solution for managing tasks, procedures, devices, media, test objects, test rigs, measurement data, and test projects, thereby contributing sustainably to a testing center’s efficiency. In addition, FEV MORPHEE significantly lowers the variety of software applications conventionally needed on test rigs. No matter if ECU (HIL), component, engine, powertrain, vehicle, or others: MORPHEE adapts to any kind of test environment.

Further reductions in time and costs of the development process can be achieved with Online and Offline-DoE tools for virtual calibration. FEV xCAL combines best-in-class modeling algorithms with an intuitive, workflow-based interface, thus enabling virtual and efficient calibration of a wide variety of powertrains and other applications.

Structure and Equipment

Today’s high-tech testing environments provide environmental simulation systems as well as traditional equipment such as test benches for engines, transmissions, vehicles, system components, and measuring equipment. In the future, there will be more new testing systems for conducting every test necessary in the field of autonomous vehicles. In recent years, high-performance computer simulation tools have replaced conventional testing methods, with new methods and procedures for testing being created. One example of this is the real-time networking of various subsystem test rigs with the built-in simulation of the system components of an entire powertrain that are not available in physical form.

For instance, FEV and the Institute for Combustion Engines (VKA) have developed the “virtual shaft” as an important tool. The test environment consists of physically separate test benches that are linked by a real-time EtherCAT connection. Thanks to the virtual shaft, the dynamometers in both component test benches are controlled in such a way that system behavior matches that of a real mechanical shaft. This enables us to recreate interactions – such as between an engine and a transmission – as early as the prototype stage before the two components can be physically adapted. That saves valuable time in development. Other benefits mainly include a protected test environment and a high number of options for monitoring individual test objects. This way, damage to prototypes can be effectively prevented. In addition, the virtual shaft allows the testing of hybrid powertrain combinations that are not yet mechanically compatible and would otherwise have to undergo extensive adaptation.

Graphic - FEV Testcenter efficiency

Virtual wave between two testing facilites



Contact-free Measurement of Combustion Air on Engine Test Benches

28. August 2017 | Software & Testing Solutions

Contact-free Measurement of Combustion Air on Engine Test Benches

Significantly increased requirements regarding the environmental compatibility of combustion engines require more specific measures for reductions in consumption and emissions. Every modification to the engine must be examined on a test bench with regard to its impact on emissions and fuel consumption, among other things. In this context, the exact measurement of the combustion air mass flow is very important. For this purpose, FEV has developed the FEV AirRate, which is now available in an improved and completely redesigned version. The AirRate is used for the contactless measurement of gas velocity, pressure, humidity, and temperature of the combustion air on engine test benches. The air mass flow in kg/h is calculated and displayed using these parameters.

High Measurement Accuracy

The ultrasonic gas flow meter with 8 ultrasonic transducers in 4 measurement paths enables very high accuracy in measurement throughout the entire measurement area. The extremely fast response time of the system ensures reproducible air quantity measurements, even for highly dynamic processes in the induction tract. Due to the low pressure loss in the AirRate measurement section, engine behavior is not affected. Due to the large measurement range spread of the AirRate 100 and AirRate 150 measurement systems, the complete range, from single cylinder engines to heavy duty engines, can be covered with only 2 device sizes.

Compact Design in a Single Casing

The AirRate requires very little space; thanks to the compact design, the entire measurement technology fits in a single casing, and there is no need for wiring between the measuring unit and the output unit.

The flow rectifiers integrated in the device effectively reduce turbulence in the combustion air, thereby enabling the system, for example, to be installed directly behind a pipe elbow without any extension of the inflow section whatsoever. Integration in test benches, with or without combustion air conditioning, is thus very easy, as is a quick conversion for operation with or without AirRate.

Clear Operation

During the redesign, special attention was paid to an increase in measurement frequency and simple and clear operation.

Compared to the previous device, the measurement frequency has more than doubled; in addition to pressure and temperature measurements, a humidity measurement has been added for mass determination. The four-path design with a total of eight titanium ultrasonic sensors guarantees very high accuracy in measurement, even under difficult flow conditions. In addition, a plausibility check is carried out between the paths, so that the drift of a path can be detected and reported. Due to the path compensation functionality, the malfunction of an entire path can be compensated for by the device, with no loss of measurement accuracy.

The AirRate is operated via the 7” touchscreen display with easily readable graphic elements, via the web browser, or via the WiFi interface. The latter in particular enables very easy operation and settings adjustments – even in difficult and inaccessible installation conditions – through the use of a smartphone, for example.

All settings are password protected; as a result, any unauthorized or accidental incorrect adjustment of the settings is excluded. The operation surface and the web menus are available in several languages and can be expanded by the user.

Low Maintenance and Calibration Requirements

In addition to the power output (4 to 20 mA), a tension output is now also available (0 to 10 V). The series interface with the AK protocol is fully compatible with the previous version. A simple replacement is therefore possible, since the mechanical connection dimensions were maintained. The AK protocol is also available via TCP/IP in addition to the series interface.

The pressure, temperature, and humidity sensors all communicate via a digital bus protocol. This enables them to be easily replaced by factory-calibrated spare parts in case of a defect; a recalibration of the device is not necessary in this case.

The calibration interval of the AirRate is 2 years and is therefore significantly better than comparable hot film measuring devices with a 6-month calibration interval. Upon request, a DAkkS calibration of the AirRate is possible.


Connected Vehicle Validation 2.0

FEV TST: Early validation of connected vehicle systems and cyber security

28. August 2017 | Software & Testing Solutions

FEV TST: Early validation of connected vehicle systems and cyber security

Vehicle apps, smartphone connections, GPS, Bluetooth, WiFi, 4G/LTE, and soon 5G are just a few of connectivity features a modern car has: Connected Vehicle is no longer a vision but has become reality and along with it serious complexity and challenges (i.e. Cyber Security) for the integration of all these features and functions into the Smart Vehicle eco-system. As a leading development services provider, FEV has supported these developments from their formative stages and has developed unique expertise from development, implementation, integration, through validation. To support these various program development cycles or stages FEV has developed the “Telematics System Tester” (FEV TST) which has become an important tool for integrating and validating increasingly complex connected vehicle components and systems, even when used in the very early development stages. This test system enables the simulation of relevant connected vehicle components, applications as well as signals and data in a controlled environment with the ability to also replay recorded scenarios. After successfully completing several series-production development, integration, and validation projects with connected vehicles, the project results indicate that the FEV TST is able to reduce time and effort by up to 30%, which is especially relevant in the context of shortening innovation cycles. Further, tremendous benefits are achieved using this test system platform for continuous and regression testing including for Cyber Security.


“In today’s connected vehicle and certainly tomorrow’s Smart Vehicles, connectivity will be a must-have upon which not only telematics and infotainment systems rely on but also the coming autonomous driving features. Connectivity will enable the Smart Vehicle and its reliability will allow OEMs to offer a wide range of additional applications for the driver and society as a whole”, explained Stephan Tarnutzer, Vice President Electronics and Global Center of Excellence Smart Vehicle at FEV. “The vehicle of the future will be part of the Internet of Things (IoT) contributing Terra-bytes of data and receiving or consuming large amounts of data when driving from various sources both inside and certainly outside the vehicle.” For this reason, Connected Vehicle systems need to be validated on an “end-to-end” basis with a Connected System Thinking approach and methodology, where the vehicle is only one part of the system. In addition to the “standard or traditional” vehicle functions, all of the other services and communication structures must also be considered during the validation phase as well as all components outside of the car (cloud, back-end, apps, etc.). Not the least of the challenges associated with the Connected Vehicle is Cyber Security for which new threats are to be addressed and validated on a daily basis. “A system validation that meets all these demands can only be tackled successfully through the use of automated test systems or the task is overwhelming and there are not enough people to do this work manually, reliably, and consistently”, resumed Tarnutzer.



Complex Connected Vehicle Systems

The FEV TST platform makes it possible to simulate relevant signals and data in a controlled environment or to replay recorded scenarios. These signals include the vehicle communication buses, cellular network, GPS, Bluetooth, and WiFi and the simulation of Smartphone apps as well as connection to the Internet for backend services, which are necessary in order to develop the required use cases for the connected vehicle system and used for end-to-end testing. In addition, the FEV TST can simulate different scenarios for mobile network and GPS signals. For example, the influence of weak or bounced satellite signals or tower-to-tower cellular signal hand-over scenarios can already be assessed in the laboratory. “With FEV’s TST the connected system under test can be validated easily and in a short amount of time against hundreds of different scenarios and evaluated in a controlled environment”, outlined Tarnutzer. “An additional back-office application maps a simulated chain of information – for example, the data flow of a door opening command from the smartphone, over the backend, to the vehicle’s telematics unit and the vehicle’s CAN bus.”
The latest addition to the FEV TST platform is for the automation of various Cyber Security related tests involving various industry standard cyber attack tools through the numerous threat vectors present in a car (i.e. Bluetooth, WiFi, CAN, etc.) and simulated on the TST. The FEV system allows for the automation of such Cyber Security related testing and validation which is very helpful during development as well as regression testing. The TST has shown to reduce the manual testing effort related to such activities by over 50% allowing resources to be deployed for other types of testing.

Early Development

Modern connectivity systems for a car alone usually consist of over 5 different components, usually from different suppliers. Frequently, not all of these components are available at the same time during the development phase for integration and validation testing. The FEV TST can be included from the beginning in the process to support the development effort as well as test and validation. The FEV TST can be configured so that it closely simulates the real system to quickly help verify requirements for each of these components. For the Cyber Security related tasks within a development program, the TST can support such activities as well from the start and help identify cyber security implementation gaps in components early on.


FEV Makes Software Quality Measurable

Metrics-based Strategies for Quality Assurance of Automotive Embedded Software

6. August 2017 | Software & Testing Solutions

Metrics-based Strategies for Quality Assurance of Automotive Embedded Software

Digitalization and high innovative demand drive future key technologies in the automotive industry. Increasing software complexity is met by rigorous quality and safety standards, but strict resource constraints on projects are limiting time spent on quality assurance (QA). Therefore, FEV has developed a tailored, optimized QA strategy that is scientifically sound to improve efficiency and quality in software projects. Based on data derived from 13 customer projects, the impact of strategic decisions on the quality of the resulting software was examined, thus leading to a better understanding of how high quality can be achieved and quantified appropriately.


Focus of the Study

Two major subjects are the primary focus of FEV’s research. First, the aim is to analyze, formalize and then capture the quality of a software product using the appropriate metrics. The second goal is to identify how specific properties of the quality assurance strategy influence the outcome of a project.

A pragmatic approach to defining software product quality is its segmentation into intrinsic and extrinsic facets. Extrinsic quality is most often judged on the basis of the customer’s satisfaction, whereas intrinsic quality can best be quantified using established product quality models, such as that found in the ISO 25010.

Key of the Study

For the purpose of the initial study, FEV limited the scope of investigation to certain properties proposed by the ISO 25010. Relevant quality characteristics were then quantified using a set of metrics. Most notably, the requirements conformity and residual defect ratio were considered.

The data from 13 automotive software projects was gathered and analyzed in order to validate the correlation between metric and de facto product quality and to identify any relationships to specific QA strategies. Statistical models, such as correlation coefficients and ANOVA (Analysis of Variance), were considered for analysis purposes.


The research showed that customer satisfaction is strongly correlated with both requirements conformance (positive correlation) and residual defect ratio (negative correlation), which indicates a strong linear relationship between these metrics.
We make the reasonable assumption that intrinsic and extrinsic product quality strongly correlate with each other. Then, both metrics – requirement conformance and residual defect ratio – appear to be suitable indicators for intrinsic product quality, since customer satisfaction is regarded as the major marker for extrinsic quality in literature.


Lastly, the impact of different quality assurance strategies on a project’s outcome was analyzed by first surveying which test methods were applied (respectively), and then examining the relationship between these properties and the identified quality indicators. First results here are promising, and FEV is confident that it will enable the profound derivation of an effective and efficient QA strategy in upcoming projects.

Graphic - automotive software

Relevant software products characteristics and metrics evaluated.


Focus on Reusability

Enhancing Agile Automotive Software Product Line Development by Similarity Analysis

3. August 2017 | Software & Testing Solutions

Enhancing Agile Automotive Software Product Line Development by Similarity Analysis

In the automotive domain, the complexity of software functions and the demanded quality standards, e.g. CMMI, ISO 26262, are still growing, while in the meantime the expected release cycles get shorter and shorter. In addition, the vehicle starts to turn into a smart device which is able to interact with its environment and to react autonomously. As a consequence, further aspects, such as security or privacy, receive a higher prioritization.

This up-to-date scenario is a great example for the frequently changing and hardly predictable demands in today’s automotive industry.

  • Who can ensure that features which are identified as necessary today will be required in a similar form tomorrow?
  • What is the adequate time frame for long-term strategies in the context of shorter and shorter release periods?

FEV’s PERSIST (powertrain control architecture enabling reusable software development for intelligent system tailoring) was established to give first answers to these questions. This approach introduces agile methods to be able to react flexibly on requirement changes and to reduce the duration of one development cycle and project quality risks due to continuous integration. Nevertheless, the establishment and maintenance of a Software Product Line (SPL) in the context of the daily work of a supplier has to face several ongoing projects in parallel. As a consequence, an approach is required which allows the project teams to focus on the implementation of the required product, while it is possible to continuously establish and maintain a SPL in parallel with minimized effort. Therefore, it is necessary to further extend the collaboration between Agile Software Development (ASD) and Software Product Line Engineering (SPLE), resulting in Agile Software Product Line Engineering (APLE).

Software Product Line Development Focused on Application Engineering

FEV searched for a SPL development method which provides essential feedback for the SPL during daily project work but reduces the additional effort for the projects to a minimum. The method does not require long-term decisions, keeps the SPL up-to-date and identifies new potential for reusable components is needed.

The main important development artifacts used during this process are the reference architecture, project architecture, component specification, test cases and the component implementation. The proposed method follows a component-based project-first approach: This means that the main item of the software architecture is a component and any specification for a component is first raised during project development. A component will only be considered to be redesigned in a more general way, if it is proven that a corresponding demand is given and a general component is a realistic opportunity within several projects. In addition, AE shall gain most benefit from the already established product line and components which are currently developed in different projects, without being slowed down by the burden of being dependent of generalized components.


Step by Step Process

1 In the first step, a new component is specified. This is done by performing a first draft of the interface with a related functional description.

2 In addition, its position in the software architecture is estimated. This is done by considering the reference architecture of the SPL. In the context of PERSIST, components are hierarchically arranged in a set of compositions. If a suitable component can be identified, which seems to be similar or identical to the specified component, the name and location of the component will be adapted to the reference architecture. This is the first step, where the SPL supports the project development. Complex architectural decisions can often be supported by experiences from the past which are stored in the reference architecture.

3 In case the component cannot be mapped, a specific position in the project’s software architecture needs to be defined.

4 In a second step the decision made in step 3 is reevaluated by the SPL team to avoid any false negatives.

5 If the component cannot be matched, the complete implementation will be performed from scratch. The new component is added to the reference architecture after its location has been agreed on.

6 If the component specified in the context of the project can be mapped to a component an extrinsical equality regarding the reference architecture can be established. This connection cannot only be used to compare the component under development with general components of the SPL but also to compare it with other individual, but extrinsical, equal components from different projects.

In addition further analysis can be performed on structural (interfaces) and semantical (test cases, function models) level.

7 If a candidate with a similarity lower than 100% is identified, this candidate can be used by the project team to finalize their own specification and the implementation can be based on the provided development artifacts.
The project team does not spend any additional effort on implementing a reusable component which is able to fulfil the requirements of both or more similar components. The identified similarities are only used to speed up the project development.

8 In a parallel step the SPL team evaluates if the identified similarities provide enough potential for a general reusable component. Based on the amount of similar components and the degree of similarity on structural and semantical level a decision has to be made whether to implement the component based on a similar component [7] or to proceed to step [9]: If the potential is high enough, the SPL team will implement a general component which can then be reused in further projects [9].

9 The proposed steps ensure that the project teams always specify components which are as close as possible to the already established reference architecture and available components. In the best case general components can directly be reused. Additionally all derivations of the reference architecture can automatically be spotted and the degree of variation can be evaluated. Therefore the potential degeneration of an established product line can be observed continuously and a synchronization between product and product line can be performed iteratively.


Activities 1 to 5 are already well established, while for activity 6 and 8 the necessary automatization is currently being finalized. General components, which are used in several projects, have already been established, but are always based on intensive manual reviews or a proactive approach. The possibility to investigate a given reference architecture during the specification of a new component is not noticed as an additional effort. Instead the reference architecture provides helpful information to perform architectural decisions.

In the current status the reference architecture consists of 219 components, whereas 125 (57%) components have no extrinsically equal match. 94 (43%) components of the reference architecture are part of more than one project and 61 (28%) of these components are also part of at least three projects.

Method for agile soft ware product line development: The colored activities represent activities which are performed by the SPL team, while the white ones are performed during projects.


The proposed approach provides the possibility of realizing the project-driven implementation work directly in the project without losing the benefits of a corresponding SPL. Each project team can benefit from the established reference architecture to speed up architectural decisions, while the similarity analysis can provide additional foundations for the actual implementation.



FEV xMOD put into practice

Real-time simulation meets hybrid powertrain

28. June 2017 | Software & Testing Solutions

Real-time simulation meets hybrid powertrain

To ensure a reasonable development time of future complex hybrid powertrains, while maximizing their efficiency, and improving the early prediction of the vehicle behavior, advanced tools and methodologies are mandatory. Relying on its long and proven experience in testing activities, its strong expertise in developing and providing competitive testing products like MORPHEE, and on its recognized know-how in using simulation to create advanced and innovative solutions, FEV decided to merge real and virtual worlds to create and offer a Hybrid Tool Chain to overcome these challenges. This 3-step Hybrid Tool Chain is a practical solution, from the Model-in-the-Loop front-loading phase to the X-in-the-Loop validation phases, “X” standing for combustion engine, battery or electric motor for instance.

FEV´s Hybrid Tool Chain

To ensure the optimization of the development of hybrid powertrains and energy management system (EMS), and benefit from simulation-based methodologies, FEV proposes to use a dedicated HiL step, which allows a seamless transition between the MiL and EiL phases, to create the Hybrid Tool Chain. This Hybrid Tool Chain relies on FEV’s advanced co-simulation platform xMOD, a platform which combines an integration environment for various heterogeneous models, together with a virtual test laboratory, and offers a range of different functionalities, such as the integration of heterogeneous models, the protection of the model contents, when they are imported, the virtual instrumentation, or the test automation. Moreover, xMOD provides simulation functions in various simulation schemes: real-time, extended time or as soon as possible, which are really useful features for MiL, HiL and EiL environments.

The Hybrid Tool Chain in Use

In this first step of the Hybrid Tool Chain, the objective is to set-up a full hybrid vehicle model of the targeted application, and integrate it in the xMOD environment. To that purpose, FEV uses classical simulation tools and software available on the market. The vehicle modelled is a parallel hybrid with an automated manual transmission.

The simulation is made in a forward approach with a 1D model for the vehicle and drivetrain components. Cycle set points are sent to a driver model in Simulink. According to these set points the driver generates accelerator and brake targets for the vehicle supervisory system and transmission target for the gearbox and clutch. The vehicle supervisory system interprets the accelerator and braking targets, manages the energy in the battery, the torque split between the combustion engine and the electric motor, and the drivetrain mode between Electric Vehicle (EV) and Hybrid Electric Vehicle (HEV) modes.

Energy Management System

The Energy Management System (EMS) is located in the vehicle supervisory model. First it estimates the power needed to propel the vehicle and the power needed to follow the battery state of charge requirements. With this power demand, it chooses if the vehicle must run in EV mode or HEV mode according to customizable power levels. In EV mode all the torque is provided by the electric motor. As a consequence, the vehicle supervisory system passes all the torque targets from the driver, to the electric motor. In HEV mode, the torque demand is split between the electric motor and the combustion engine, to optimize the system’s efficiency. In HEV mode the torque demand is not only the torque asked by the driver to move the vehicle, but also a torque estimated to meet battery state of charge target.

Integration in xMOD platform

The integration process in xMOD is composed of 3 main steps. First, the hybrid vehicle model is tested in a fixed step co-simulation environment, to validate the functional behavior of the platform, and ensure, in the end, the real time ability. Then, the hybrid vehicle model is split into blocks that represent the different parts of the Virtual Test Bed and Engine-in-the-Loop configurations:
Block 1: “Test automation block” that sends the cycle set points and manages the information transfer between the blocks. It emulates the automation system environment that is integrated into MORPHEE at steps 2 and 3.

  • Block 1: “Test automation block” that sends the cycle set points and manages the information transfer between the blocks. It emulates the automation system environment that is integrated into MORPHEE at steps 2 and 3.
  • Block 2: “Vehicle, Driver, Energy Management System and Drivetrain models” contains all the models, except the combustion engine model.
  • Block 3: “Combustion Engine model with its test bed environment” contains the combustion engine model, and the correct inputs and outputs that are required at steps 2 and 3.

Finally, these three “blocks” are compiled with the xMOD target, and then integrated into xMOD). At this step a Human Machine Interface (HMI), or dashboard, is also created to be able to visualize the interesting variables and to have access to the relevant parameters of the system. Once this platform is set-up, the hybrid vehicle model capability to follow the driving cycle as well as the behavior of the energy management system are validated.

Using xMOD means:

  • Using a unified representation of all heterogeneous models that is simple and complete enough for them to be integrated and co-simulated, and for the model contents to be protected.
  • Abstracting the modelling language through a virtual instrumentation, such that the models can be easily understood by people other than those who created them, or by people who do not have knowledge of the languages in which they were written.
  • Focusing on using the models (they are always built in the usual modelling environments), and providing ergonomically designed features for interacting with the simulations, running the tests and using the results.

Set-Up of the Virtual Test Bed

Once this first xMOD simulation platform of the hybrid vehicle is created, the second step, called Virtual Test Bed (VTB), becomes relevant. It consists in coupling the xMOD simulation platform, to a test-bed computer, and start the preparation and the validation of the communication protocol. One of the objectives of the VTB is also to allow test bench engineers and technicians to prepare their test procedures. The VTB must thus be able to represent, in a virtual environment, the main behaviors of the engine test bench.

Benefiting from all the work performed in step 1, the following steps are fast:

  • Integration of the full hybrid vehicle model and the EMS on the 2nd computer.
  • Extraction of the combustion engine model with the test bed environment models, and integrating them in the 3rd computer.

Another advantage of the Virtual Test Bed is the possibility to develop and validate specific test procedures, before being at the real engine test bench. For instance, a specific component to master stop and start of the engine was developed, tested and validated at this HiL step. Finally, this “3 computer configuration” of the VTB allows to validate the whole communication protocol and the engine test bench procedures, to train the engine test bench team, and ensures the consistency of the simulation results, in a real time environment.

Graphic - FEV xMOD

Parallel hybrid powertrain

Set-Up of the Final EiL Environment

Due to the previous work done in steps 1 and 2, this last step is pretty fast and does not require extra human resources compared to a classical calibration test phase: At first, the standard test bench procedure to put the previously prepared engine is done. Then the engine installation validation protocol is followed up, in order to ensure the safety of the people and the protection of the engine. Then the engine can be started and the test bench automation system proper functioning is checked: control loops, and plausibility measurements for instance. Depending on the “fresh” state or not of the engine, a run-in phase can be performed. It was not necessary to do so with the engine of this study.

Finally the simulation computer can be disconnected from the VTB and directly connected to the bench automation system (via an S-Link communication protocol). The test bench procedure can be downloaded from the MORPHEE computer of the VTB, directly from the network, and uploaded on the test bench computer.

As soon as all the devices are connected, the test bench operator has access to a library containing different drive cycles. During the test cycle, MORPHEE sends the parameters related to the driving conditions to xMOD, especially the vehicle speed, and gets back from the vehicle and its driver models, the desired operating point of the engine (engine speed / engine torque). Then MORPHEE directly controls the engine speed by driving the dyno and the engine load via a simulation of pedal signals.

During the automatized test cycle, no intervention from the test bench operator is required. The engine is started and stopped automatically and all data (bench sensors, ECU data, xMOD simulated variables and parameters) are collected in the same data file.

The operator can thus focus on calibrating the EMS, thanks to the dashboards of xMOD, or can, for instance, modify the parameters of the hybrid vehicle (mass, gearbox ratios or battery capacity for instance).
One additional advantage of using this Hybrid Tool Chain, and xMOD, is also the possibility to keep, inside the xMOD computer, an engine model at the EiL step. In that case, xMOD is able to send the simulated engine variables to
MORPHEE and these values can be compared to the measurements. It makes thus a strong and reliable monitoring of the engine and the acquisition system possible in order to detect or anticipate any malfunction by comparing physical data with the engine model outputs, and thus save a lot of time and money by stopping the test procedure, as soon as an incoherence is detected.


The Hybrid Tool Chain is an already fully efficient tool chain for hybrid powertrain development. It offers a lot of additional functionalities which are required to develop and validate Advanced Driver Assistance System (ADAS) for instance. Moreover, the versatile and open xMOD co-simulation platform can allow the integration of additional models like environment or traffic models.

Graphic - FEV xMOD

MiL configuration containing 3 main blocks


The future of testing started long ago

FEV experts discuss solutions for efficient testing operations

28. June 2017 | Software & Testing Solutions

FEV experts discuss solutions for efficient testing operations

Planners and operators of testing facilities, but also manufacturers of advanced testing equipment solutions, do not have an enviable job these days. The demands made on them are too diverse: new vehicle concepts let a wide range of development tasks grow, test results have to be ever more precise and generated in ever shorter time frames, and costs have to sink at the same time. The circle in which everything runs on the core factors of efficiency, more efficiency and even more efficiency has to be figuratively squared.
Dr. Stefan Trampert, FEV Group Vice President Operations, and Dr. Jürgen Dohmen, FEV Vice President of Software & Testing Solutions, talked to SPECTRUM about the challenges and solutions for efficient testing operations as well as the future of testing.

Dr. Trampert, FEV operates nearly 200 testing facilities all over the world. To what extent do you see the effects of new vehicle concepts on day-to-day testing operations there?

Trampert: We have especially noted the increasing demand for system and component testing facilities for electric vehicles. These include on the one hand battery test capacities, but also testing systems for e-motors, electric powertrain modules and hybrid powertrains. So we are currently extending our existing capacities in all these areas. Our development center in China, which was just inaugurated last year, is already pushing its limits. Here, we will upgrade and start the planned second expansion stage right now. Within the next year additional electric car axle testing facilities and resources for developing batteries will be installed. The climactic chambers for the battery testing facility are big enough even for large-formatted underfloor batteries with significantly more than 100 kWh. There are also additional, extremely modern testing facilities being set up for electric powertrain modules and batteries in our location near Paris. At our company headquarters in Aachen, we are also setting up electric car testing facilities. The construction of additional chassis dyno test benches for vehicle testing is currently in the pipeline.

With increasing demand, the efficiency of the various testing facilities and the speed of testing and development become key factors. How is FEV set up in this regard?

Trampert: It is true that efficiency in testing operations is the linchpin for a successful development project. For this reason, we introduced around-the-clock shift operation at our development testing facilities in Aachen in early 2017. This measure, in combination with ever more extensive automation of the various testing facilities, sustainably increases the efficiency, availability and exploitable output of the test facilities. That way, we can conduct our clients’ development projects even more quickly.
In addition, we have set up a program within the FEV Group with which we are increasing efficiency in our testing facilities throughout the world. We also work with our consulting staff to offer this extensive efficiency program as a service for our clients. To do that, we have translated step-by-step optimization of a testing facility into a clearly structured project approach with six thematic clusters: These include strategic alignment of the individual testing facilities, analysis of the existing and future product program and evaluation of testing capacity that will be needed in the future. It also includes adjustment to the testing facility organization, the core competencies needed, the testing methods and the tools and testing equipment. Especially the processes within the testing operations, such as testing facility planning, setup and work planning on the day and the night shifts, shift changes, etc., are analyzed and optimized.

Dr. Stefan Trampert - testing operations

Dr. Stefan Trampert
Group Vice-President Operations

FEVFlex - testing operations

FEVFLEX supports important quality processes using an implemented 8D reporting function

Dr. Dohmen, how can efficiency in the testing facility be optimized from the product side?

Dohmen: Various software tools are assigned an important function in increasing efficiency – data management, for example: data, facts and events from ongoing operations have to be recorded in reproducible form and be retrievable at any time. FEVFLEX assumes an important interface function in the testing facility and the testing center here. It gets all the operations data for all components and automation systems.

The data is collected automatically and logged in a standardized way. An automated reporting function with all the important parameters for the testing facility, item tested, etc., ensures absolute transparency for all clients and specialized departments.

In addition, FEVFLEX supports important quality processes using an implemented 8D reporting function. That ensures that any problems with testing facility components are recorded centrally, recognized by the global device manager and the person responsible for the product, and remedied on a sustainable basis.

Dr. Jürgen Dohmen - testing operations

Dr. Jürgen Dohmen, Vice-President FEV Software & Testing Solutions


But operating data isn’t the only data that shows up. What does the handling of measurement data look like in practice?

Trampert: The interlinking of testing facilities presumes an important function in measurement data and management, particularly with personnel changes, locations throughout the world and all sorts of specialized departments. FEV uses an advanced data management system developed over the years that, among other things, works as an order interface between specialized departments and testing facility personnel and makes it possible to automatically feed test data into automation based on established specifications. The advantage of this system is especially visible if different test series that build on each other have to be run in different locations: a test engineer running a series of tests with a test vehicle at any testing location in the world can describe new test series through the test data management system and ask that they be done while he isn’t there but based on his specifications. Building on these test results, he can then start additional test series on site. In addition, the system and its interfaces make extensive functions available for testing, plausibility check and approval of measurement results from all sorts of measurement systems – and it does so quasi online.

Hardware-in-the-Loop (HiL), Engine-in-the-Loop (EiL), Software-in-the-Loop (SiL) etc.: the trend is moving more and more toward development on all levels at the same time. What role does simulation play in FEV’s product and testing world?

Dohmen: Realistic simulation of components that are physically not available is, of course, an important element in increasing speed and efficiency in the testing process and especially in the development one. And yes, the trend towards more and more “in-the-loop” solutions applies here. From the product side, we confront these challenges especially with the help of our collaborative development and validation framework based on MORPHEE automation. That makes it possible to run even complex models in “hard” real time in the testing facility. But even the physical simulation of components assumes an important role. For this purpose we have developed a so called Engine Torque Pulse Simulation solution in which the internal combustion engine in the hybrid powertrain test is being simulated by an e-motor. The behavior of an electric car engine is adjusted to that of an internal combustion one – including shifting strategies, changes in rpm and especially torsional and other vibrations. That way, varying numbers of cylinders and high-dynamics parameters relevant to interpretation can be simulated. The advantage of such a solution is the simplified operation of the testing facility. A key technology for such a simulation, in additional to electromechanics, is the high dynamic control system for the testing facility. FEV-TOM, our proven AC/PM dynamic control system, is used in combination with a real-time network and our automation.

Trampert: A capability for real-time simulation in an actual testing facility has an additional advantage: it makes it possible to simulate entire real-driving cycles in the engine testing facility. With Engine-in-the-Loop, the engine is combined with the virtual drivetrain and vehicle components along with a route and driver profile. Street driving with various shifting strategies, rpms and loads, as well as differing driver behavior, can then be done with real-time networking high dynamic test facility systems. So, in an early development stage, we can simultaneously bring in reliable and reproducible results and offer a development platform for very quick changes in parameters and components.
In perspective, that means we can even imagine being able to expand today’s usual method of online design of experiments (DoE) in the testing facility to a total vehicle online calibration in the Engine-in-the-Loop testing facility. In other words: We don’t just use the expanded automation capability of our engine testing facilities to find out about engine calibration. An automated, virtual calibration associated with expanded online DoE is also used to develop shifting strategies or the gear ratios for automatic transmissions, to set shift points and to automatically optimize a number of other vehicle or hybrid drive parameters on the basis of physical model components.

Dohmen: A key function in this regard is played by xCal, our highly efficient online and offline tool. It uses global, state-of-the-art modeling techniques that combine outstanding visualization and intuitive user operation.

Let’s take another look into the near future: To what extent will automated driving functions and driver assistance systems change the test landscape?

Dohmen: Expenditures for testing and validation for automated vehicles will exponentially grow once more. That makes completely new release strategies necessary and the need for automated and simulation solutions will continue to grow.

Trampert: Simply because of the number of test cases, virtual development environments like those of Software-in-the-Loop or Hardware-in-the-Loop must take on a major role. Every imaginable scenario must also be created and validated. Particularly challenging is excluding false positives and false negatives. Imagine there is a tractor in front of you with a 25 km/hour sign on the trailer and you want to pass it. It is relatively easy to test sensory perception of a sign and to accomplish it. Changing it into a driving strategy and a decision, however, is definitely not trivial: the 25 km/hour sign is only a maximum speed conditioned by the construction, not a general limitation on speed on this stretch of road. The tractor can, and should, be passed by the vehicle.
The emphasis on development and validation of ADAS functions in a fixed test facility, meaning neither in the entire vehicle on a test track nor in an MiL/HiL laboratory, is due to the perception of the passenger and the driver and because of their interference – sometimes unexpected – in systems that are driving automated. Common vehicle simulators with an adjusted man-machine interface and a range of functions expanded by virtual components or even hardware are perfect for that. Bidirectional, real-time coupling of the driving simulator with an engine or powertrain testing facility offers the tester realistic reactions for its autonomously driving vehicle.
If the large number of sensors used are to be brought in to perceive the environment, full vehicle tests are absolutely essential. FEV already has a test track with various road situations today and is continuing to expand it.

Dr. Trampert and Dr. Dohmen, thank you very much for your time.

Diagram - testing operations

Example: Spider diagram for regular evaluation of an efficiency program in a testing facility

Battery - testing operations

The climatic chambers for the battery testing facility in China are big enough even for large-formatted underfloor batteries that have significantly more than 100 kWh.