Case study, application engineering
A test control platform that holds the entire life of a physical test in one record, from the order engineering raises to the result that returns to them. In production across automotive safety laboratories on three continents.
Automotive safety validation is physical work. A single test order can hold a rig or an environmental chamber for days or weeks, against capacity that does not move.
The same work existed three times over: what engineering asked for, what the laboratory scheduled, and what the rig was doing. Every duplicate record was free to disagree.
One record for the whole life of a test order, from PLM intake through planning, execution and reporting to the result returning to engineering.
Engineering, planners, technicians and quality all read the same record, across three regional environments running one shared version of the application.
The setting
Demand arrives unevenly, capacity does not move, and a validation programme that slips holds up the product release sitting behind it.
Automotive safety validation is physical work. Before a component reaches a vehicle it is pulled, heated, frozen, vibrated, aged and crashed, and each of those programmes is a test order queued against a finite amount of equipment. A single order can occupy a rig or an environmental chamber for days or weeks at a stretch.
An order is not a line item. It carries a specification, a bill of materials, a set of physical samples, media and environmental requirements, an ordered sequence of steps, and a cost category the work is booked against.
Raises the validation and waits on the answer before the product release behind it can move.
Fit the order against equipment that is finite, already committed, and occasionally out for calibration.
Run the work on the floor, in sequence, on the rig or chamber it was planned against.
Have to show afterwards what was tested and under what conditions, long after the rig has moved on.
The challenge
The same piece of work exists three times over, and in an operation without a single system covering all three, the copies drift apart in predictable ways.
What it asked for.
What it scheduled.
What is physically happening.
Orders get re-typed from the engineering system into a laboratory tool, and a number changes on the way across.
Schedules end up in a spreadsheet next to the tool, because the tool has no supported way to handle the rush job or the rig taken out for calibration.
Engineering finds out late, and finds out second-hand, because the result reaches them through a person rather than through the record.
Ask what is on rig 12 right now and that is the honest answer. The state of the floor is not a thing the systems can be asked.
Every place the same work is recorded twice is a place where the two records are free to disagree, and nobody finds out until it matters.
The mandate
Answering three of the four still leaves a spreadsheet or a phone call in the loop, and that is exactly where the divergence starts.
What has engineering asked the laboratory to do, and is the laboratory working from the current version of it?
What is scheduled, on which resource, and when does it finish?
What is physically running right now, and what state is it in?
What were the results, and does the engineering record already reflect them?
The platform is built around answering all four from one record.
The platform
A test order enters from the corporate PLM system, where engineering defines what needs validating, and leaves it the same way once results exist.
Between those two points it stays a single record that changes state, visible in the same form to everyone who touches it.
Orders arrive and results return without anyone re-typing them, so engineering and the laboratory cannot hold different versions of the same number.
The schedule takes the rush job and the calibration outage rather than being bypassed by them, so what the plan says is what the floor is doing.
Inside the platform
A test control system lives or dies on how precisely it models the work. Three areas carry most of that weight.
A long-running test is a physical commitment. Changing the reserved resource on an activity that is already on a rig invalidates the work in progress, and the cost is a repeated test and a lost week.
The platform ties editability to the state the order is in: activities under test are shielded from changes that would compromise them, and fields open and close according to whether the work they describe has started. Validation on entry catches bad values at the point they are typed.
Automatic scheduling is right for the bulk of the work and wrong for the exception, and laboratories run exceptions constantly. A planner can place an order by hand and reserve the resource, and that reservation is held by the replanning job when it next runs.
A manual placement the scheduler reverses overnight would be worse than no manual placement at all, because planners would stop trusting the schedule and go back to the spreadsheet.
Utilisation figures, actual finish week and year, partial export updates that do not clobber fields someone else edited: individually small, and together they decide whether a planner works from the system or keeps a private copy beside it.
A planning tool is only as good as the last time someone found it wrong.
Architecture
A server-rendered web application on the Microsoft stack, in continuous production use and continuous development for over a decade.
The domain logic is dense and well proven, and the architecture reflects a deliberate choice to extend it rather than restart.
Three regional production environments serve Europe, North America and Asia-Pacific from one shared version of the application, with only configuration differing between them. A test order behaves identically wherever it is raised, and a defect found in one region is a defect in all three.
On the floor
Test queues appear on screens in the laboratory itself, driven by the platform API and filtered to the plant and working area in front of them.
A technician sees what is testing, what is waiting in buffer, and an overview of the area, rotating without anyone touching it. Cards scanned from a phone or a browser move work through the states as it happens.
The effect is that the floor and the plan read from one source. A technician does not have to ask what is next, and a planner does not have to ring the laboratory to find out whether something started. The status that engineering sees is the status the rig is in.
Impact
Specific operational figures are withheld at the client's request. The difference the platform makes is in what each group can rely on.
Validation requests reach the laboratory without being re-typed, and results come back into the engineering record on their own. Test status is visible without asking, and the answer does not arrive second-hand or a week late.
A single plan that absorbs the rush job and the calibration outage instead of being bypassed by them, with manual reservations that survive automatic replanning. The published plan keeps matching the floor.
Scanning moves work through the states as it happens rather than at the end of a shift, and the next job is on the wall rather than in someone's inbox.
What was tested, in what sequence, under what conditions and against which control plan, with work in progress protected from changes that would invalidate it.
One view of laboratory load and throughput across three regions, on the same data and the same definitions everywhere.
Supported under corporate single sign-on and the same access policy as the rest of the estate, on a release cadence that does not depend on manual work.
What comes next
The sequencing follows where the operational return is, and the runtime question is scoped as an evaluation rather than a decision already taken.
Planning reserves equipment today. Adding technician availability and qualification closes the gap between a plan that works on paper and one that works on shift.
Equipment tracked with its calibration and compliance status in the same place tests are planned against it.
Laboratory throughput and execution data visible alongside the rest of operational reporting.
Less effort to establish and revise control plans, which currently sets how quickly a new validation programme can start.
Targeted rework of the highest-traffic screens, without disturbing the surrounding application.
A structured assessment of a modern runtime and container hosting, with the decision resting on measured evidence.
Personnel and equipment capabilities extend the set of constraints the platform can plan against, and that is where laboratory throughput is won or lost. The runtime question is scoped as an evaluation, because a platform carrying this much proven domain logic earns that decision through evidence.
The pattern
The platform is a working example of what a test control system covers when order intake, planning, execution and reporting sit in one record instead of across several tools.
The same pattern applies wherever physical capacity is the constraint, traceability is a requirement, and the work has to be visible to engineering and the floor at the same time.
If the same order lives in three systems and none of them agrees, the gap is usually one record wide. We can walk your intake, planning and execution path in a single session and show you where it splits.