We have argued here before that splitting a cross-domain project between suppliers has a hidden cost. We still think so. But that is not an argument for never splitting anything, and reading it that way would be a mistake we would rather correct than defend.
This cross-domain engineering case study is the other half. It is a project we deliberately split. The split was right, we would make it again, and the whole thing was decided somewhere people rarely look: at the seam between the two halves.
The machine, and what it has to decide
A manufacturer of automotive components needed test benches for its production line. Not laboratory rigs. Benches that sit in the flow and decide whether a part is good.
Physically, a bench like that is five things working together. A hydraulic loop applies the load. A motion controller drives it. Sensors measure force and position. A test pattern says what to apply and for how long. A measurement chain turns all of it into a verdict.
If the verdict is wrong in one direction you ship a bad part. If it is wrong in the other you scrap a good one. Both are expensive, and only one of them is visible.
The customer already owned the mechanical side and the domain. What they did not have was the layer that runs on top and tells them what just happened.
Why we did not try to own all of it
The hydraulic loop and its motion control went to a hydraulics specialist. That was the right call and it was not a close decision.
Our rule of thumb, then and now. Split where a discipline is mature. Split where a specialist does nothing else all day. And split where you can buy a component with a documented interface.
Hydraulic actuation is exactly that. A motion controller is a real product from a real vendor, tuned by people who tune them every week. Insisting on owning it would have bought us risk and cost the customer money. We would also have been worse at it.
The place you must not split is different. Do not split where the interaction between two domains is the product, because then the split runs straight through the thing you are selling.
What we actually owned, stated precisely
We have written before that the same team that designs RF harvesting circuits also wrote software for a hydraulic test bench. That is true, and it invites the wrong picture, so here is the precise version.
We did not design the hydraulics. We integrated with the specialist’s motion controller.
Our half was the other side of the machine. We took hardware control and measurement acquisition. We built the data model, the statistics that turn a curve into a pass or a fail, and the screen the operator reads. Plus one job that nobody assigns at the start, and that somebody always ends up doing. It is the subject of the last section.
Being loose about this is tempting because the loose version sounds more impressive. It is also the fastest way to be found out by an engineer who asks one follow-up question.
The seam is where the project gets decided
Two competent halves do not add up to a working machine. What joins them does.
Before either side built anything, the interface got written down. That document is unglamorous and it is the single highest-leverage artefact in a project like this one. What it has to settle:
- Command and authority. Who tells the machine to move, and — more important — who is allowed to stop it. Safety authority cannot be shared politely between two suppliers.
- Time. The control loop runs at its own rate. The measurement chain samples at another. A verdict compares things that were never measured at the same instant unless somebody says which clock is the reference.
- Units, ranges and signs. The least interesting failure in engineering and one of the most common. A sign convention that disagrees across a seam produces data that looks plausible and is backwards.
- What a test is. The sequence, the states it can be in, who owns that state machine, and what a partial or aborted run leaves behind.
- Faults. Who detects, who reports, what reaches the operator, and what the record says afterwards.
- The record itself. What gets stored, at what resolution, and who owns it. This one looks like an IT question at the start. It becomes the whole product later, because a verdict is only worth the evidence behind it.
None of that is exotic. All of it is expensive to discover late, because by then both halves are built and each one is correct in its own terms.
There are standard vocabularies for this kind of boundary, and in industrial automation OPC UA is the obvious one. Adopting one saves you from inventing half of the list above. It does not decide the answers for you, and the answers are the hard part.
The trick that paid for itself: build a fake machine
The practical problem with a seam is scheduling. Neither side wants to wait for the other, and the first time the two halves meet is usually the first time anybody learns anything.
So we built a simulated version of the machine side: a stand-in that speaks the agreed interface and behaves plausibly, with no hydraulics attached. Our software could then be developed and exercised against something long before the real bench existed.
Two things come out of that, and the second matters more. You stop losing weeks of calendar. And the simulator becomes an executable version of the interface document. The moment your stand-in and the real controller disagree, you have found an ambiguity in the spec, not a bug in somebody’s code.
The job nobody puts in the plan
Here is the part I would tell anyone considering a split.
When a number looks wrong on a machine like this, the expensive question is not how to fix it. It is whether the disagreement is in the measurement or in the machine. Is the part actually behaving that way, or is the chain that observes it lying to you?
That question lives exactly on the seam, which means it belongs to neither supplier by default. On a badly organised project it becomes a meeting where two vendors explain why it is not their half. Somebody has to own it, it should be written down at the start, and it is worth paying for.
We ended up owning it, because we owned the measurement chain and the interpretation. Three years later the benches are still in production and that is still the job.
So: split or not?
Split when the discipline is mature, a specialist exists, the component is real and documented, and the interface can be written down before anyone builds.
Do not split when the interaction between domains is the product itself, or when nobody will own the seam. That second condition disqualifies more projects than the first.
And there is a third option that rarely gets named, which is what actually happened here: split the work, and pay one party to own the joint. Not to police the other supplier. To own the questions that fall between them — the interface, the clock, the record, and the answer to “is it the measurement or the machine?”
About to divide a system between suppliers? The cheapest hour you can spend is the one where somebody writes down what has to cross the boundary. Spend it before either side starts building. Tell us what you are splitting and we will tell you where it will break →
Next week: power budgets — supercapacitors, MLCCs, and what duty cycling actually buys you.