Selecting an Approach to Build Flexible, Cost-Effective ECU Production Test Systems

 Electronic control units (ECUs) were invented in the 1970s. At that time, people needed to improve fuel economy due to the oil crisis, which meant finding a way to make engines run cleaner and pollute less. Engines used a mechanical device called a distributor to control spark timing and a carburetor to control the fuel mixture. This mechanical system had minimal tuning and adjustment capabilities. The advent of the microprocessor in the 1970s provided an enabling technology capable of performing the complex high-speed calculations required for controlling spark timing and fuel mixture. In the early 1980s, ECUs became a standard component in most vehicles. As a computer designed to solve a very specific problem, the ECU is a fundamental component in an automobile.

Figure 1: Example of an Electronic Control Unit

Modern vehicles can contain over 100 ECUs with many different purposes. The most common ECUs are the following:

• Body control module—regulates the operation of many body components such as doors, latches, wipers, lights, and so on
  
• Powertrain ECU—controls the correct operation of the vehicle's drivetrain with several variations depending on whether the vehicle is hybrid, combustion, or electric
• Engine control module—operates the combustion engine functions
• Telematics control unit—tracks the vehicle by providing directions, rerouting, navigation, and so on
• ADAS ECU—controls all the advanced driver assistance systems (ADAS) functions such as lane departure, collision, and other warnings that operate as accident prevention features
• Gateway ECU—provides the “translation” of different automotive buses. 

Though each ECU has a specific purpose, they all need to be tested individually not only at different stages of their manufacturing but also as they interact through communication buses and electronic signals.

Test is often considered a non-value-added process, and a test department is considered a cost center. This makes sense in a perfect world where the manufacturing process never produces defects, system designs are always flawless, software works as intended, customers don’t need to return their products, outgoing and incoming quality problems are always zero, and testing isn’t required because nothing ever fails. But things do fail, and test is one method to guarantee minimal, measurable, repeatable, and traceable quality standards.

Test is needed for other reasons as well. Automakers (OEMs) have their own quality requirements and standards as well as long-term traceability and regulatory requirements. OEMs usually need component vendors to test the products they manufacture before shipping them to OEM car assembly facilities, where all the components are pieced and tested again to build a car. OEM facilities have labor-intensive operations and high-quality demands. Reworking because of a faulty component from a vendor is unacceptable and costly. Supplier contracts often include monetary penalties based on incoming defects directly attributable to the supplier.

At a minimum, to comply with OEM requirements, manufacturers of ECUs (Tier 1) must:

• Use thorough design validation to prove their designs meet the applicable OEM regulations and specifications 
• Conduct production validation and test to prove that the final product meets all expectations 
• Keep proof of all results for auditing and quality tracking purposes

Test engineers at the Tier 1 suppliers must comply with all requirements while meeting tight timelines to launch products. The rest of this document focuses on their challenges with ECU production (end-of-line) test.

As stated earlier, test is often considered a non-value-added process even though it improves the quality level of each phase of the manufacturing process. This belief drives test organizations to ensure that the test process is robust, thorough, fast, and cost-effective. To accomplish this, they must meet five main design challenges: reliability, throughput, flexibility, deployment, and cost.

1.   Reliability

In production, test systems likely operate 24x7 with high volumes, and downtime is costly. The tolerance for partial, late, or missed shipments is close to nonexistent. Any delays in production, from false failures to unavailable test systems to calibration issues, can contribute to downtime and thus need to be under control. Test equipment must be reliable, and this reliability comes in different forms:

• Robustness of the hardware to operate in a production environment
• Quality and stability of the test software and test sequencing
• Overall maintainability of the system
• Available services from involved suppliers and third parties

When combined, these factors contribute to the challenges that test engineers face. They must seek solutions that give them enough time to develop the test system as best they can and be confident that it will continue testing reliably throughout the life cycle of the ECU.

2.   Throughput

In the last few years, the automotive market has seen a transformation like the semiconductor industry saw decades ago. Its ability to maintain production volumes no longer matches its ability to build and deploy manufacturing facilities. This has led to the need to drastically reduce the footprint of the testers and design them with parallel test capabilities while avoiding cost increases. This new approach to test involves breaking programming paradigms, finding creative ways of setting up the tester, looking outside the usual supply chain for alternative solutions, and developing internal capabilities that were not necessary before through training and services.

3.   Flexibility

Along with large volumes, test engineers are seeing variations in the ECUs. Some brands require, for example, testing 100 percent of the products in a temperature chamber in addition to the core functional test, while others implement this in batches. Some require only summary statistics on parts of the test while others want thorough documentation on each unit tested and each test performed. One super tester cannot meet 100 percent of the requirements for all the products and brands. Test engineers need to balance flexibility with capability when designing testers that can be quickly adapted to changing requirements and additions/reductions to the test, which is a cost-saving strategy. They must design testers, in the broader sense of the word, that deliver all features (the actual hardware installed, software running, services programmed, vendor ability to react to requirements, and so on) but not necessarily at the same time.

4.   Deployment and Management

Because the production of the mainstream ECU model on the market must continue beyond its popularity (sometimes over a decade), even at low volumes, deploying testers quickly and maintaining them in the long run must be considered together. Managing the testers, upgrading their software, maintaining deployment, and monitoring what’s happening add up to a design challenge that forces test engineers to prepare for the launch date without losing sight of continued tester needs. A particularly difficult challenge is sustaining or maintaining groups that are independent and have a strong focus on operational costs that need to be transparent. The interaction between the deployment and management departments can present additional challenges when other groups such as standardization bodies need to be involved. The deployment challenge is about coordination, which, in turn, depends on effective communication. And communication depends heavily on having the right data at the right time with the right channels to deliver it.

5.   Cost

In short, everything must be accomplished at the best possible cost. However, a common saying states that it’s always possible to throw more money at a problem but it’s never possible to throw more time. These two seemingly opposite views bring up an important challenge that test engineers continue to face: finding where value and cost meet without disregarding the length of time to deploy the tester and the need to sustain it in the long term.

The true cost of a system is not limited to its purchase price. Other short-term costs include equipment, training, maintenance, upgrade, support, and connectivity options. Long-term costs, which are less obvious, depend on parameters such as development time, flexibility, scalability, reusability, modularity, and maintainability. These factors are directly related not only to the hardware and software used in the test system but also to the supplier’s ability to deliver services that fit Tier 1 needs.

Once again, the goal is to develop a production test system that:

1. Is reliable throughout its life cycle even though it was developed within a tight schedule
2. Meets throughput and production needs without sacrificing footprint
3. Is flexible enough to meet current and future test needs without sacrificing cost
4. Can be deployed and managed at multiple locations without adding unnecessary overhead
5. Meets cost expectations without compromising quality, performance, and maintainability

Given the pressure these five challenges (and the compromises among them) place on test teams, offloading test functions to an integration company or a test supplier may ease the burden. Test engineers can just oversee the tester’s design and ensure it meets the product test specification (PTS). Then they can implement the test data and system deployment and management.

However, from surveying best-in-class test organizations, NI sees a different reality. Most test managers want their teams to be involved in test development for a variety of reasons: independence, nimbleness to adapt to new test requirements and product variations, confidentiality, and so on. The common approaches to creating a new test system design include buying a turnkey system, building it all, owning the test system architecture, and owning the software architecture.

Buy turnkey (also known as vendor knows best)

The simplest approach is to pay for a turnkey system. Under certain circumstances, this may be the best solution, especially when the product is commoditized and has no expected requirement changes, the vendor relationship is strong, and so on. The main risk with this approach is the fast pace at which the automotive industry is changing. New standards will require Tier 1 auto testers to continue paying for services and upgrades to their test systems unless they develop a plan to move away from their turnkey approaches.

Build it all

At the opposite end of the spectrum are testers who build their own approaches, sometimes down to the hardware level, and use vendors only to provide isolated components like instruments. Though not particularly common, it’s a valid approach that works well when the company absolutely needs to control all its components because of the innovation that the company is introducing or the company’s market strategy.

Own the test architecture

No one knows the ECU under test better than the groups defining its design and creating the PTS document that dictates the tester’s requirements. But because of the fast-changing auto industry, this approach involves designing an architecture that delivers on flexibility but reduces the amount of rework the tester might need to meet new standards. In practical terms, this approach comes closest to the super-tester solution that delivers the best of both worlds.

The main considerations for this span from the internal test development capabilities to the right hardware or platform to build the system on to the right software to develop the test module and manage the tester.

Larger suppliers that deliver ECUs in many different domains and need standards to integrate their custom ECU requirements with aspire to this approach. It calls for heavy coordination among departments and test groups and presents its own challenges like the “scope creep” when defining it, personal preference differences on vendors and technologies, and even varied OEM restrictions.

Own the software architecture

This approach is growing more common with the convergence of core requirements. Companies that own a software architecture save resources in hardware development to focus on differentiating through software and test capabilities.

Though the challenges regarding coordination and vendor evaluation are similar, standardizing at the software level and offloading the hardware responsibilities to a handful of approved suppliers is easier, which is an advantage for a company.

The two main considerations of this approach are selecting vendors and investing in software development capabilities; however, the differentiation created by software development can quickly generate a strong return on the investment.

As expected, not one approach is best because each approach’s dependencies vary by project, company vision, existing infrastructure, budget, engineering resources, location, and so on. The selection must be based on the company’s overall flexibility, specific needs, and, most importantly, vision on standardization, competitiveness, and response to future challenges.

Also, because different approaches are better for different outcomes, a company may choose a variety of approaches based on ECU complexity or vehicle domain, manufacturing strategy, logistics, and so on. For example:

• To test ECUs in faster evolving areas such as ADAS, a stronger partnership with a vendor that can inform the strategy and provide market insight is highly valuable, so owning a test architecture and working with a vendor may be a strategic advantage
• For more unexplored areas like autonomous vehicles, a company may decide to build it all to keep the intellectual property in house
• For more commoditized ECUs that have traditional I/O and automotive bus communication, the company may decide to offload hardware responsibilities and only own the software architecture
• For lower cost ECUs with longer life cycles, committing to a turnkey system from an experienced vendor might be best

There’s no right way to choose a single approach. All companies must acknowledge this before committing to one approach for a specific situation. Then they can strive to find commonalities that generate the proven advantage standardization provides. To address important questions before committing to an approach, companies can consider the following scenario that’s growing more common.

Consider a transmission control module (TCM). This type of ECU controls the car’s transmission system so it’s always in the best possible gear to increase performance and fuel economy.

These are some of the typical inputs and outputs of a transmission control module:

Table 1: Typical Inputs and Outputs of a TCM

Abstracting the signal types, this is a more graphical representation of the same TCM.

Figure 2: Representation of the Typical Functional Blocks of a TCM

Figure 3: Simplified View of TCM Inputs and Outputs

The summary of inputs and outputs shows a list of test system core requirements: instrumentation, switching, loads, and the controller that executes the test software and test sequence.Figure 4: Core Functional Blocks of Instrumentation, Loads, and Switches to Test a Typical TCM

Given the considerable repetition of elements across different ECUs, the elements of the test system are also similar. This at least creates the ability to standardize at the hardware level. However, large standardization efforts require much more than just aligning on hardware and the use of it. They also involve corporate strategy, vendor relationships, risk management, and many other dependencies.

That’s when standardizing at the software level becomes a more reasonable and attainable aspiration. Figure 5 shows a fuller representation of what can beexpected from the production test system.

Figure 5: Common Elements of a TCM's Production Test System

To provide an initial system to perform the functions represented by the blocks in Figure 4, virtually all vendors in the ECU production test market offer Tier 1s their hardware and software. They claim that approach delivers the best compatibility while ensuring “enough” openness. Most of them also provide closed boxes that run their own firmware for stand-alone operation, though that’s not necessary during production test and adds unnecessary cost.

For this approach to work, companies need to assess their systems from the differentiation point of view. Though vendors can offer the same hardware and software to any company that needs them, the Tier 1 and, most importantly in this case, the test development group must differentiate and gain a competitive advantage. When the test system is assessed first for its software, owning the architecture for it becomes a major step in market differentiation.

When companies focus on software as the standard and offload the hardware selection to the vendor so that it comes with a proposal, the test development group can spend its time ensuring the software is adaptable and flexible for future requirements that the hardware should be able to meet anyway.

For example, test development groups can focus on building a test framework that includes a measurement and hardware abstraction layer to make it hardware agnostic, creating plug-ins to ensure that the test system can seamlessly connect to the manufacturing execution system (MES) at the facility where it will be deployed, and creating standard operator interfaces that adapt to language, ECU, type of test, reporting, and so on.

Best-in-class vendors offer openness in their products to provide a higher-level starting point for test engineers. This helps engineers concentrate on the software development instead of implementation details like the wiring of loads, instruments, and so on. As mentioned, they focus on abstraction layers, frameworks, compatibility with company-specific tools, and so on.

Figure 6: A higher level of integration helps test engineers focus on differentiating through software instead of spending time on system configuration, procurement and wiring.

Tier 1s can take different approaches to overcome the variety of challenges involved in building ECU production test systems. No approach is better than the other, but companies should view each approach from the perspective of the specific project.

One factor growing more urgent when developing these test systems is the need to differentiate to increase the perception of value and turn production test into a competitive advantage. This can be accomplished through software and a handful of trusted partners and vendors. With this combination, Tier 1 and other companies’ test engineers have a higher starting point to develop test systems and can focus on features that add value or protect their development: the ECU, the software to test it. and the integration with their manufacturing partners.

Production test does not have to be a cost-generating entity. It can provide an advantage. By changing perceptions, Tier 1s can focus on their strengths, including strong partnerships with the right vendors that are aligned with their vision.