Automated Testing of Hardware-Dependent AUTOSAR MCAL software

  Print Print

"The most cost-effective way to build a reliable test system is to combine commercial off-the-shelf components with simple, custom-built parts "

- Petr Pomkla, NXP Semiconductors

The Challenge:
Developing a system for automated testing of peripheral software that does not require considerable investment into a specialized test hardware infrastructure and does not require continuous upgrading to satisfy arising product and test requirements during a product lifecycle.

The Solution:
Using NI R Series multifunction RIO modules and the LabVIEW FPGA Module to define custom functionality for unsurpassed flexibility and scalability.

Author(s):
Petr Pomkla - NXP Semiconductors

NXP Software

Software support for NXP microcontrollers and microprocessors is a standard part of the NXP product portfolio. Quality expectations keep increasing, particularly among automotive customers who demand software that integrates seamlessly into user applications. Customers have asked NXP for production-ready software developed according to the highest quality standards, which clearly requires a different level of testing than a sample code delivered with no warranty.

Testing Hardware Dependent Software Components (Device Drivers)

A device driver is a hardware-dependent software component that cannot be tested on an MCU core-only simulator since the external I/O signals must be properly stimulated. Some parts of the driver source code might not be reachable without proper I/O stimuli. Dependency on external signals makes testing of the device drivers different from testing middleware or application layer software. Production-ready software requires a significant amount of testing.

Manual Testing

The simplest and most common way to test the peripheral driver is to use standard bench top instruments. However, such instruments have limited functionality, and manual operation is a disadvantage. Most of the standard instruments have a control interface that operators can use to control and program such instruments; however, these solutions have limited flexibility and scalability.

Manually testing peripheral driver software works fine for small projects such as demo applications or sample code, but production-ready software requires a different amount of testing. Dedicated personnel must handle manual testing, which makes it time consuming and expensive. Manual testing is also prone to human error, which we can completely eliminate with automated testing.

Challenges of Automated Testing

Automated testing peripheral software has its own drawbacks. It requires considerable investment into a specialized test hardware and software infrastructure. The maintenance cost can skyrocket for custom-built systems since users must continually upgrade such systems to keep up with product and test requirements during an entire product lifecycle.

The most cost-effective way to build a reliable test system is to combine commercial off-the-shelf (COTS) components with simple, custom-built parts (Figure 1, Figure 2, Figure 3). The completely custom-built automated test equipment (ATE) requires a huge investment to first develop such a system. Much lower running and maintenance costs balance the higher initial investment into a COTS solution.

Figure 1. Complete NXP Automotive Software V&V ATE Gen2 automated test system with NI PXI chassis mounted in a 19” rack, custom ATE receiver, and removable ATE interface test adapter.

 

Figure 2. Detail of ATE ITA pulled from the ATE receiver, not wired.

 

Figure 3. Complete ATE ITA wired with an NXP automotive microcontroller board.

 

Choosing NI PXI and LabVIEW Platforms

The NI PXI open standard with a large selection of modular instruments backed by native support through LabVIEW software makes this our system of choice. All components work well together, and NI provides support worldwide. This reduces maintenance cost as we can easily replace or service failed hardware components through local service centers.

Designing for the Future

The best way to test a complex serial protocol driver is to use a specialized communication interface such as CAN, LIN, or FlexRay. However, there is no clear choice for SPI, I2C, SCI, I2S, GPT, PWM, ICU, and other I/O peripheral drivers. We could possibly combine logic analyzer, waveform generator, and perhaps counter/timer modules, but with very limited flexibility. Furthermore, this solution introduces the signal routing problem since the above instruments have a fixed-signal functionality.

The ultimate solution is to use the NI reconfigurable I/O (RIO) technology. The functionality can be defined by the LabVIEW FPGA Module. The user-defined FPGA-based instruments deliver unsurpassed flexibility and scalability as operators can quickly change the functionality of the existing or define a new one without touching the test hardware infrastructure

Conclusion

We combined the NI PXI-based solution with a custom-designed test system to cost effectively test any hardware-dependent software component. The entire system is scalable and easy to maintain. Using FPGA-based instruments is the only way to efficiently keep up with constantly changing requirements. The PXI-based test system using FPGA-based IP instruments is ready for the future.

Author Information:
Petr Pomkla
NXP Semiconductors
Tel: +420 739 817 017
petr.pomkla@nxp.com

Bookmark and Share


Explore the NI Developer Community

Discover and collaborate on the latest example code and tutorials with a worldwide community of engineers and scientists.

‌Check‌ out‌ the‌ NI‌ Community


Who is National Instruments?

National Instruments provides a graphical system design platform for test, control, and embedded design applications that is transforming the way engineers and scientists design, prototype, and deploy systems.

‌Learn‌ more‌ about‌ NI