Blog

Since 2018, our automation solution has been controlling the stage technology at Casino Bern: 21 stage podiums of varying sizes, speed-controlled, flexibly arranged for different event formats.

The operating staff controls the system via touchscreen: select axes, press the travel button. Manual up and down travel or automatic position runs to stored target positions are both possible. Axes can be grouped together with their positions continuously monitored — if the axes drift too far apart, the system establishes a safe state and stops the movement.

At the start of 2026, it was time to update the system on-site and bring the software up to the current version of our platform — so the venue can continue to benefit from support and future development.

The interesting part lies in the operator interface. In 2018, the HMI was a project-specific web application — functional, but a one-off solution for this one venue. Today, our 3D operator interface runs there: a reusable product that maps venue-specific workflows through configuration. The requirement was clear: the staff must be able to operate the system exactly as before. That has been achieved — all familiar functions are fully represented in the new interface, making the transition in day-to-day operations correspondingly unremarkable.

Since the update in early 2026, the system has been running in regular operation — without any issues.

“The transition to the new software went smoothly during live operation. Knowing that support for our system is there when we need it gives us a real sense of security.”

— Christian Schmid, Head of Facility Management, Casino Bern

That is precisely the point we care about: what in 2018 still had to be developed individually is today part of a product line. Configured rather than reprogrammed — with the same venue-specific depth.

For business owners and managing directors who notice that their projects reliably work — but somehow never get cheaper.

The Mülheimer Bridge

The Mülheimer Bridge in Cologne. Built in 1951, under renovation since 2018, originally budgeted at 188 million euros — current costs: over 370 million. When the figures became public in 2022, someone publicly asked: “Is the Mülheimer Bridge going to be gold-plated now?”

Mülheimer Brücke, Cologne – during renovation. Photo: © Raimond Spekking / CC BY-SA 4.0 via Wikimedia Commons

Understandable reaction. But the real problem is something else: what looks like a saving is often just a deferral. The bill comes — just later, and bigger.

We are not bridge builders. But we know this pattern of thinking.

The Same Pattern. Your Operation.

Imagine a control cabinet manufacturer gets the same machine type on the table for the third time. Every time, the control software is developed from scratch — because the one from the last project isn’t transferable. Every time the same risk, the same startup problems, the same hours. The machine is the same. The effort too. Nobody decided it that way. It just grew that way.

That’s the bridge that gets rebuilt every time.

The opposite of that has a name: software product lines. A shared platform from which different solutions can be assembled — through composition of proven building blocks, not through new development. What has once been developed, tested, and documented is not repeated in the next project. It is taken further.

But Our Machines Are All Different.

True. The process is always different. But the infrastructure beneath it is not.

Sensors, actuators, drives, safety circuits, HMI structure, commissioning routines, diagnostic functions — for the vast majority of machines, these are structurally the same. The process is the variable. The infrastructure beneath it is the constant. And that’s exactly where the leverage lies.

Specifically: our sensor and actuator layer is not programmed — it is configured. In a GUI, you describe your machine: which sensors, which actuators, which interconnections. The layer starts, the interfaces are created automatically, the process task controls and reads from there. No new code. The same logic, new configuration.

An example: a valve is not developed — it is described. Normally open, normally closed, optionally a status signal. What comes along automatically: error validation (did the valve actually open?), performance measurement (how long did it take?) and, over time, a wear prognosis — when will this valve likely need to be replaced? Not because someone programmed that separately. But because the logic is already there.

And before a single line of process logic is written, the technician on site can manually address, test, and validate every sensor and actuator. Valve open, valve closed, motor running, move to position — everything checkable, everything documented. What is normally the most labor-intensive chapter of a commissioning process is already done.

Getting Started Costs No More Than What You Pay Today.

The groundwork has already been done. Our software components are developed, proven, and ready for serial use — designed for reuse from the start. You don’t pay for building a platform. You use one that already exists.

What you get for that is structurally a different decision — without paying structurally more.

---

ootb automation GmbH, Cologne

Sources: Mülheimer Brücke – Wikipedia / Köln Mülheim Chronik

Most automation projects begin with the same illusion: the last project was similar — we can adapt it quickly. A few weeks later, it becomes clear that “quickly adapted” actually means “almost rebuilt from scratch”.

This is not a failure of individual engineers. It is a structural problem — and the usual workarounds don’t really solve it.

Industrial robots palletising in a bakery. Photo: KUKA Roboter GmbH / public domain via Wikimedia Commons

The familiar workarounds

Copying and adapting code is the classic approach: it works, somehow, but costs time every single time, and the bugs from the previous project come along for the ride. Libraries are a step forward, but the project itself still needs to be set up, configured, and integrated from scratch — the library takes away part of the work, not the underlying problem. Tools like the TwinCAT Automation Interface automate the creation of project configurations via script, which genuinely saves time in engineering — but the underlying software architecture remains unchanged. The code stays plant-specific, the project stays one-off.

In high-volume production this barely matters, because unit count amortises development effort. In small-batch production it hits the margin directly.

Reusability is not a given — it has to be built in

Software can only be carried over to new projects if it was designed for that from the beginning. That means clear structures, consistent versioning, plant-specific configurability instead of hardcoded adaptations. It also means the first implementation requires a little more care — with the goal that every subsequent one costs significantly less.

That is the investment. The return comes with every follow-on project built on the same foundation.

What this means economically

Less development effort per system. Shorter commissioning times. Fewer errors, because proven components are used instead of logic written from scratch each time. And in the service case: a software base that is traceable and documented — not a grown system only the original developer still understands.

For operators, this means lower lifecycle costs. For integrators, it means competitive pricing alongside higher quality. For both: fewer unpleasant surprises during the project.

Small-batch production pays off — when the software is built for it

The question is not whether automation works in small-batch production. It works wherever the economic conditions are right. The decisive variable is how much development effort each new project consumes.

Companies that use control software designed from the ground up for reusability change this variable fundamentally — not as a one-off project, but as a structural advantage that compounds with every additional system.

That is the model behind ootb automation.