MENU

MOST150: End-of-line testing for Quality Assurance (QA)

MOST150: End-of-line testing for Quality Assurance (QA)

Technology News |
By eeNews Europe



The ECUs of a modern car are all linked together via various networking technologies like CAN, LIN or even FlexRay for safety critical applications. In the case of infotainment and multimedia systems, MOST has established itself as the de-facto standard, distinguished by high bandwidth and electrical robustness. MOST150, its third generation, makes high demands on automotive developments and testing environments. This article puts the focus on manufacturing, burn-in/run-in test, and reliability testing of ECUs implemented with a MOST interface. The upcoming problems for hardware, industrial standards and test strategies, and the methods for dealing with them will also be discussed.

Test system must accurately simulate real environment

To test the functions of a MOST ECU, it must be installed in a realistic vehicle environment to provide the input and output information it needs to perform its control tasks. Therefore, the test system must accurately simulate the vehicle environment. In the majority of cases, an ECU with MOST interface has a number of different communication interfaces other than MOST that have to be supported. One reason could be that the ECU has to act as a gateway and/or system components are combined into one unit.

An important issue in managing the manufacturing and industrial environments is to consider the established standards used for the hardware that is simulating the MOST interface. Especially for hardware, the standards are restricted to interchangeable systems/components and to hardware setups that are easy to expand. USB and Ethernet interfaces are not suitable due to poor reliability in hostile environments and long duration tasks. An often-used standard for such measurement and simulation systems is the PXI bus (PCI eXtensions for Instrumentation). Using PXI takes advantage of a robust, PC-based, and high-performance measurement and automation system. With PXI, the benefits of low cost, performance, flexibility, and a wide range of available cards form the basis of a multiplicity of test systems. So clearly the MOST appropriate solution, where possible, is to use PXI cards to provide the MOST interface.

Among the technical facts to manage the tests of MOST communication and peripheral hardware conditions, some tests enforce simultaneous control of a quantity of DUTs (Device Under Test), e.g. reliability or long duration tests of several hours and days. To perform this method of testing, a modular structured system has to correlate with the abilities of the MOST networking architecture for the case of homogeneous DUTs.

System and architecture

Basically the first step is to have a working PXI-based MOST150 interface, which can be part of any automated test system. Goepel electronic introduced their first fully compliant MOST150 PXI6161 (oPhy) board some time ago (figure 1). It follows the forerunner, PXI3060 (MOST25 oPhy), and is conform to the current revision of the MOST specification.

Figure 1. MOST150 PXI hardware.

The PXI6161 module is part of the well established Series 61 product family, with a programmable communication controller that is supported by a PowerPC in combination with extensive on-board firmware. This relieves strain on the host PC, and valuable bandwidth for additional application is obtained, enabling complex and CPU-intensive processes to be executed on the board. Based on the INIC OS81110 and the corresponding SpyNIC, the PXI6161 is fully capable of generating and streaming MOST content. A number of additional functions are integrated, e.g. the ring break diagnosis (RBD), several trigger inputs and outputs, and the functionality for creating a parallel CAN/LIN. One module is able to be a master, a slave and/or a spy, and by using several modules in a PXI system the results are various unique MOST networks.

For implementation of test systems used for screening, end-of-line, and reliability, a mature architecture of hardware is proved. Figure 2 shows the system architecture centred on a PXI stimulus and measurement module, which accommodates all the required instruments except the DUT power supply or other resources, e.g. assemblies for fault simulation.

Figure 2. Architecture test system. For full resolution click here.

As requirements change, the modular architecture of the tester opens up the possibility of system upgrades covering a variety of communication interfaces. In addition to the obvious benefit of cost saving, the main thrust of this approach is in testing gateway functions between different communication networks. The ability of the PXI bus to trigger and synchronise its instruments is invaluable in establishing a common timing basis for these tests.

The modular hardware architecture enforces efficient software for organising all application tasks. The advantage of swapping out critical real-time communication processes to the hardware is that it allows the possibility of an easy-to-use windows based user software. In a test sequencer including various communications and verifying routines, automated quality inspections can be defined.

Regarding previous MOST25 implementations using the PXI standard, the test departments of OEMs, suppliers and test houses are able to update their hardware resources with minimum effort. To imagine what it means to change the hardware resources, figure 3 shows a marked PXI aggregate with six plugged-in MOST interfaces.

Figure 3. MOST PXI test system (six ways)

The general build-up of a system was shown theoretically and practically in figures 2 and 3. Two philosophies exist on how to handle more than one MOST network, as there are different views on technical and economic efficiencies. The first and most obvious solution is to use every MOST network to test a unique communication partner, which results in a group of MOST modules. The benefits are strictly separated hardware resources and the benefit of using iterative software tasks, which only have to be addressed by the individual hardware module.

Figure 4. MOST PXI test system strategies. For full resolution click here.

In addition, some test specifications require this philosophy of parallel networks, because it is clear, straightforward and provides some kind of redundancy. The only problem is a high degree of costs and hardware components. An alternative way of realising simultaneous testing is the substitution of several PXI boards through a MOST splitter, e.g. a hub for MOST as shown in figure 4. This is a cost effective arrangement and allows a lot of basic tests. More difficult are the software tasks, the testing of the ring break diagnosis or the limited bandwidth caused by only one simulated interface. Another problem that exists belongs to the DUTs, because still a huge number of communication units are not able to perform dynamic addressing, with the consequence of multiple equal instance identifiers. sj

About the author:

Ing. grad. Michael Schmid studied technical informatics at the academy of Gera until 2003 and has been working for Goepel electronic since then. His expertise lies in the simulation and verification of vehicle communication interfaces such as MOST, CAN and LIN and he is involved in the corresponding product development teams at Goepel.

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s