Successfully Implementing EOL Test Benches: Why Preparation Is Key

Successfully Implementing EOL Test Benches

Why Preparation Is Key

In this article, you’ll learn what questions should be addressed before submitting a quote for an EOL test bench, why this preliminary work is so important, and how it leads to an EOL project that can not only be proposed but also successfully implemented. 

Would you like a quote for an EOL test system? Then you’re right to expect a clear answer: How much will it cost, what’s included, and when can we get started? In my experience, you’ll get a better answer if we don’t jump straight to discussing prices—but instead start by talking about your testing requirements. 

After all, an EOL test system isn’t an off-the-shelf solution. It has to be tailored to your product, your test bench, your cycle time, your failure patterns, and your production line. If these points aren’t clearly defined, a quote might look good at first glance—but it will end up being costly to implement later on. 

You usually don't know what you're getting until you start using it.

In fact, it’s not uncommon for the crucial questions to come up only when things get serious: during commissioning. And that’s about the worst possible time for that.

Then, suddenly, the discussion turns to what exactly constitutes a defective part, why the signal looks different than expected, whether the measurement time within the cycle is even sufficient, or why those in charge of quality, production, and the test bench have different expectations regarding the test.

That is exactly why we ask so many questions before providing a quote for Simcenter Anovis. Not because we want to make your project more complicated, but because a good quote is only good if it actually works on the real test bench later on.

In this article, you’ll learn what questions should be addressed before submitting a quote for an EOL test bench, why this preliminary work is so important, and how it leads to an EOL project that can not only be proposed but also successfully implemented.

Why a simple request often raises many questions 

Most projects start out quite unspectacularly. The customer sends an email requesting a measurement system. At first glance, it sounds like a straightforward project: clamp the part in place, start the measurement, get the result. Keep the good parts, discard the bad ones. Done. 

Perhaps it involves an electric motor, a transmission, a pump, a compressor, or another component that needs to be tested for noise or vibration at the end of the production line. Often, a test bench is already in place. Sometimes it’s still under construction. And frequently, there’s already a general idea of what needs to be tested. But...

It's usually not quite that simple. 

I have been in charge of Simcenter Anovis for over six years and handle customer inquiries, system configurations, and quotes. An important part of my job is to explain technical concepts in a way that helps everyone involved understand the big picture. 

Quality management, test bench managers, production, engineering, and purchasing all share the same goal: a reliable test system. But they view it from different perspectives. The quality manager is concerned with the risk of customer complaints. The test bench manager focuses on measurability, cycle time, and integration. Production is concerned with stable processes. Purchasing needs a solid basis for decision-making. 

And that's exactly why the groundwork is so important. 

A quote for an EOL test system is not just a price list. It marks the beginning of a collaborative discussion: What exactly needs to be tested? Under what conditions? Using which test bench? To what level of assurance? And how can we avoid costly changes to the contract later on? 

Or, to put it simply: Think about the future now. 

That's why we ask a lot of questions at the beginning: 

• What is this product? 

• What errors should be detected? 

• Are there any known good and bad parts? 

• Is the test bench already in place? 

• What sensors are installed? 

• How much time is left for measurements at regular intervals? 

• What interfaces to the system are planned? 

• What should be done with the measurement data? 

• Who ultimately decides whether the exam is passed? 

Sometimes, during a conversation, I notice that the person I'm talking to is wondering, “Why do they want to know all this? I just wanted a quote.” 

The answer is simple: Because we want to avoid a situation where what seems like a quick quote later turns into a difficult project. 

It's important to me that the person I'm talking to can rely on me. When we offer a system, it shouldn't just look good on paper. It needs to work when put to the test later on. 

The test task must be crystal clear

The most important thing is to define the audit objective clearly and precisely. And it is just as important that all stakeholders have the same understanding of this definition. 

That sounds obvious. But it isn't. 

Here’s an example: A customer says that a component sometimes makes a “strange noise.” Everyone in the room has a general idea of what that means. The quality manager might think of a risk of a customer complaint. The test bench supervisor thinks of sensors and measurement time. The production team thinks of cycle time. And the supplier thinks, “What exactly do you mean by ‘strange’?” 

At first, a test bench doesn't really know what to make of the word "funny." 

He needs a clear description. For example: 

• Does the noise occur at a specific RPM? 

• Is it a whistling, rattling, grinding, or clattering sound? 

• Is it a persistent issue, or does it only occur briefly when starting up? 

• Are there any sample parts where the defect definitely occurs? 

• Can you compare good parts and defective parts? 

• Is the noise audible to the customer, or is it only detectable by measurement? 

Only once these questions have been answered can a description be turned into a testing strategy. 

I like to compare this to taking your car in for service. If you say, “Something up front doesn’t sound right,” the mechanic might nod politely. But to find the problem, he needs to know: When does it happen? When braking? When turning? At 80? Only when the engine is cold? 

That's exactly how it works with the EOL test bench. 

Ultimately, Anovis is the tool that turns measurement signals into a reliable test decision. But even the best tool is only helpful if it is clear beforehand what problem it is supposed to solve. 

Why the test bench should be evaluated early on 

In addition to the test task, the test bench itself is the second major consideration. We should assess the test bench’s suitability for EOL measurement right at the start so that we don’t end up buying a pig in a poke. 

The point isn't to discuss every technical detail down to the last screw. But some things need to be clear early on. 

For example: 

• Are the correct sensors installed? 

• Are they in the right place? 

• Is the signal coming through clearly? 

• Are there any disruptive noises or vibrations coming from the surrounding area? 

• Is the available measurement time within the cycle sufficient? 

• Can the test bench reliably start and stop the measurement? 

• How will the system receive the result later? 

• Is there a defined interface, for example, to the PLC or via a Teco interface? 

Especially when it comes to interfaces, I find time and again that everything looks simple on a slide. In reality, however, it’s essential to clarify very precisely who sends which signal and when, and what happens if something doesn’t go as planned. 

Does the system start the measurement? Or does Anovis? Where does the serial number come from? What happens in the event of a timeout? Is a part automatically rejected if the measurement is unclear? Is raw data saved, or just the final result? 

These aren't details to be addressed later. These are the building blocks for a smooth project. 

4 Milestones from Our Practice

Through many projects, we have developed an approach that I like to describe in terms of four milestones. It is not a theoretical model to be tucked away in a drawer, but rather a practical project framework: first understand, then evaluate, then plan, and finally roll out smoothly. 

Milestone 1: Test task understood (clearly)

It's not the software that comes first—it's the testing task. 

We need to understand which quality issue needs to be resolved, which types of defects are relevant, and how these defects manifest themselves in the measurement signal. Equally important: Quality, test bench supervisors, production, and engineering must all mean the same thing when they refer to a “defective part.” 

If this common understanding is lacking, things will get difficult later on. 

Milestone 2: Test bench suitability confirmed

After that, we'll take a look at the test bench. 

Is the existing system suitable for the measurement task? Are the sensors, measurement position, cycle time, and environment appropriate? Is it clear how Anovis communicates with the system and how the results are returned? 

That's the moment when you realize whether the foundation is right—or whether you're looking at the proverbial pig in a poke. 

Milestone 3: Measurement System Configured

Only once we understand the task and the test bench can we plan the system effectively. 

Next, we’ll discuss the appropriate Anovis configuration, hardware, software, licenses, interfaces, responsibilities, and timeline. The quote is therefore not just a number, but the result of thorough preparatory work. 

For the customer, this means they receive a solid basis for decision-making. For us, it means we offer a system that is tailored to the task at hand. 

Milestone 4: Preparations for Commissioning

Commissioning doesn't start on the test bench. 

Many issues can be clarified in advance: test data, interfaces, calibration, procedures, acceptance criteria, and a well-defined SOP for commissioning the EOL test bench. Of course, there’s always some element of reality on-site—after all, a test bench isn’t a PowerPoint slide. But the better the preparation, the fewer surprises there will be during the ramp-up. 

In short: If you plan ahead, you'll be more relaxed when it's time to start operations. 

Real-World Example: When the Groundwork Is Missing 

Let’s take an example from our practice—anonymized, of course, so that I can share it here. A customer wants an EOL system for a rotating component. The requirement is: “Detect unusual noises.” 

The test bench is already in place, the schedule is tight, and really, all that's left is to add the measurement system. Sounds doable. 

However, the project then reveals that: 

• There are no clearly documented failure patterns. 

• Good and defective parts are not clearly separated. 

• The sensor position has not yet been validated. 

• The cycle time allows for only a very short measurement window. 

• The surroundings are noisier than I expected. 

• The interface to the system has not yet been fully defined. 

This becomes a problem, if not before, then certainly by the time the system goes live. That’s because the plan is to verify on-site that everything is working properly. Instead, people suddenly start trying to resolve fundamental issues. 

What exactly is a bad part? 

Which signal is relevant? 

How much variation is normal? 

Does the measurement need to be repeated? 

Who makes the decision in borderline cases? 

That takes time. And time costs money. 

A simple math example: 

Suppose an unplanned extension of the on-site commissioning results in: 

• 3 additional days 

• 2 external specialists 

• 1-day production delay 

• €1,700 in service fees per specialist per day 

• €8,000 in internal costs due to the delay 

Then we get: 

$$ \text{Additional costs} = (3 \times 2 \times 1,700.00,€) + 8,000.00,€ $$ 

$$ \text{Additional costs} = 18,200.00 € $$ 

And that's not even counting internal coordination, schedule changes, stress, and the infamous "We have to solve this quickly" mode. 

That's exactly the kind of situation we want to avoid by doing our homework. 

In an AI-generated text, a diagram representing a cost-risk chart would appear here. I think it's clear to everyone what is meant, so I'll just continue writing here.

Who or what is Simcenter Anovis?

For me, Anovis is the building block that allows us to turn acoustic and vibration measurement data into a usable test decision. 

Typical applications include, for example: 

• Electric Motors 

• Transmission 

• Pumps 

• Compressors 

• Actuators 

• other rotating or oscillating components 

Anovis helps identify anomalies in the signal, evaluate characteristics, and use that information to make a well-reasoned decision. But it’s important to note: Anovis is not a magic box that you simply plug into the test bench and that then automatically solves all problems. 

Strength comes from working together: 

• clear test task 

• appropriate test bench 

• appropriate sensor technology 

• clean interface 

• clear data concept 

• Structured Commissioning 

When these factors align, a measurement system becomes a reliable component of quality assurance. 

What’s more, the data can also be valuable later on. For example, it can be used to identify trends, highlight process changes, or anticipate maintenance needs earlier. Predictive maintenance doesn’t begin only when a machine breaks down. It often starts with good data collected during normal operation. 

Checklist

10 Critical Questions to Ask Before Starting Test Bench Projects 

Before an EOL test bench project gets underway, I believe we should answer these ten questions: 

1. What problem should be solved? 

2. Do all stakeholders have the same understanding of this audit task? 

3. Which types of defects should be reliably detected? 

4. Are there "good" and "bad" parts available for reference? 

5. Is the existing test bench suitable for this measurement? 

6. Have the sensor configuration and measurement position been determined? 

7. Is the cycle time sufficient for a stable measurement? 

8. Which interface to the system is used? 

9. What data must be stored or disclosed? 

10. What criteria must be met for successful commissioning? 

We don't ask these questions to make a project more complicated. Rather, we ask them because they help make a project simpler, more predictable, and more reliable. 

If you're currently planning an EOL project or preparing a quote for a test system, use this checklist as a starting point. It will help you address the right issues early on—before they become a major headache later on at the test bench. 

The next post in this series will take a detailed look at the first phase: “From Specifications to Solution: The Art of Requirements Analysis.” Then we’ll examine how an initial inquiry is transformed into a clear, verifiable test case.