STARTING POINT
Why first inquiries almost always have gaps
A test stand touches many disciplines: substructure and mechanics, electrical engineering, media conditioning, measurement technology, automation, operation, evaluation and, depending on the task, more. Add building services and infrastructure. Nobody has all of that at hand. We see three patterns again and again.
1. Missing boundary conditions
Where will the test stand stand? Which media are available? Which interfaces exist? Location, media supply and interfaces are the three most common omissions. If they are missing, every bidder clarifies them with you separately and fills the rest with assumptions. Both cost time, and often the gap only shows up during installation.
2. The solution is specified in advance
Whoever specifies in the requirements which technology the test stand should use gets exactly that quoted, even if a better or cheaper solution existed. Suppliers deliver what is asked for.
One example is a hydraulic loading unit, because that is how it has always been built. In discussion it turns out that an electromechanical solution does the job more simply and more economically. If hydraulics are in the inquiry, hydraulics are built and paid for.
The same applies to very high accuracy or a function the test stand must have. Often it turns out that the accuracy is not needed for the test task, or the function is not needed at all.
So we always ask: what is the actual requirement behind this proposed solution?
3. The do-it-all machine
The test stand should cover everything from µV to kV, the media conditioning should control from -40 to +120 °C and the drive should spin to 30,000 rpm, because the test stand might be used differently one day. It is feasible, it just costs accordingly.
Behind this is usually the idea that a wider range means more safety. In measurement terms it is rather the opposite: spreading the measuring range spreads the same resolution over a larger span, and you measure less accurately where you actually test. Whoever needs both gets switchable ranges or a second sensor, plus another calibration and one more operating step. The test stand gets more expensive to buy and to run.
Reserves are not maximum values
Holding reserves makes sense; demanding maximum values, in our view, does not. The difference matters more than it sounds: space, power and interfaces for later expansion cost little today and save a new build later. Maximum values make the test stand more expensive immediately, without anyone using them. What counts is whether something is built and paid for today, or whether only the path is kept open.
THE SERVICE
What a pre-project is
The pre-project is a structured consulting phase. We clarify the test task, the solution path and the boundary conditions, separate must-have from nice-to-have requirements and record the result in writing.
Usually the result is a requirements specification. If the solution path is still open at the start, or feasibility needs clarifying, the result can also be a detailed solution description or a feasibility assessment. Which is appropriate is decided in the first conversation.
Requirements specification vs. functional specification
The requirements specification describes what a supplier has to deliver. The functional specification describes what the supplier commits to deliver. One comes from the customer side, the other from the supplier. (In German: Lastenheft and Pflichtenheft.)
NEUTRALITY
Why the requirements specification stays vendor-neutral
We write the requirements specification without naming manufacturers and without TMX-specific features as must-have requirements. You can send it to as many suppliers as you like.
THE CONTENT
What the requirements specification contains
Every requirements specification is built for its project. These sections are almost always included.
- Company and project context
- documents the purpose of the test stand and existing systems, plus background on the task and the situation, so a supplier can think their way in
- Devices under test and test task
- describe what the DUT is and what it has to do, so it is clear why it is tested this way, plus an example test sequence from setup through manual to automatic operation
- All disciplines
- substructure and mechanics, electrical engineering, media conditioning for oil, air and water, measurement technology and sensors, automation, operation and software, evaluation and reporting
- Ambient conditions
- describe buildings and rooms from test cell to control room, plus floor, foundation, doors, noise protection and ventilation
- External framework
- safety requirements, directives and standards that apply to the test stand
- Concepts for maintenance, safety, service and calibration
- define how the test stand is maintained, secured and how its measurement accuracy is verified
- Acceptance, training, documentation and delivery
- acceptance stages with design freeze, operator training, scope of documentation, delivery time and commercial terms
- Return checklist as an appendix
- every bidder submits it pre-filled with the quote; in the award meeting it is discussed point by point
Quotes only become comparable when the same requirements apply to every bidder, including those for commissioning, training, documentation and delivery time. If these items are missing from the specification, the quotes cannot be compared.
Quote review checklist
The return checklist is also available on its own, independent of a requirements specification: around 70 check points across all disciplines, from DUT fixture to warranty and payment schedule. You send the list to the bidders with the inquiry, get it back filled in and go through it point by point in the award meeting.
WORKING TOGETHER
Process and your effort
How much time you put into the pre-project is up to you. The range runs from "you take care of everything" to a joint project with your own team on your side. In the first case we also measure space, door widths and access routes on site ourselves.
It does not work entirely without you, though. You have to decide the trade-offs: low purchase price or high accuracy, surcharge for modularity and later expandability or not, high automation now or retrofit later. We ask the questions and explain the consequences; the decision stays with you.
LEVELS
Which level fits your task
We distinguish roughly three levels of pre-project, from a few days to several weeks of effort. Which one fits depends on the desired result and the complexity of the test task.
| Level | Effort | When it makes sense |
|---|---|---|
| Solution sketch or short specification | 1–5 days | First basis for further clarification, rough feasibility |
| Requirements specification | 1–3 weeks | The usual case |
| Pre-project for a test field / high complexity | 4–8 weeks | Many test stations, special development, open solution path |
The first level is the fastest entry if you don't yet know how big the task is.
For every level we estimate the effort in advance and give a fixed-price quote. You know what the pre-project costs before it starts.
From practice
Alstom · Netphen service center · 2025
End-of-line test stand for drive units
Alstom wanted to expand its test capacity for overhauled bogies and procure a further end-of-line test stand for their drive units, consisting of motor, gearbox and shaft.
The first discussions about requirements and needs showed that much was still undefined and some requirements still open. We therefore proposed a pre-project: structure everything and turn it into a requirements specification that could be sent to several suppliers.
With our experience we regularly come across solutions that are more efficient than the ones originally considered. At Alstom it was a double cabin: testing on one side, setting up on the other. That increases throughput without making the test stand significantly more expensive.
The finished requirements specification runs to 38 pages: maintenance process and existing systems, specification of all disciplines from the acoustic cabin through machine bed, ventilation and control cabinet to measurement technology, safety technology and evaluation software, plus the drive units to be tested, installation site, applicable standards and scope of delivery.
Alstom ran the entire procurement process on the basis of our requirements specification.
CAD model of the double-cabin test stand
Drawing of the ventilation system of the drive test stand
Further projects
Siemens Energy
Requirements specification for the functional testing of hydraulic governors and valves. Shows the range beyond the drivetrain.
Schmersal
Pre-project in which the solution path was open at the start. The result was a detailed solution description instead of a requirements specification.
John Deere
Requirements specification for a tilting test stand for tractor transmissions.
EXPERTISE
What test stand experience changes in a requirements specification
A requirements specification can be written cleanly without test stand experience, with solid figures and a complete structure. Whether what it describes can be built practically, and whether the effort is in proportion to the benefit, is decided elsewhere.
Namely in implementation. From our own projects we know which details count when it comes to engineering.
Christian Perdok and his team have designed test stands for 20 years and written numerous requirements specifications in that time, from drive test stands to the functional testing of hydraulic components. In the pre-project this experience decides which solution path holds and which requirement is really needed.
Christian Perdok · Managing Director, Test Stands and Automation
Without a complete specification you compare apples with oranges
You might end up with a test stand that does not cover your test task. If you are planning a test stand and are not yet sure what belongs in it: talk to us. In the first conversation we clarify which level fits your task.
Want to start smaller? We sketch your task first; within one to five days you have a basis for discussion.