Try the Werk Nord control room live
Project example · Werk Nord
A beverage manufacturer calls: they want to know why their lines stop, and to trace batches quickly. We show step by step how this leads to a control room, an MES and a mobile app.
Step 1 · Enquiry
A beverage plant with five filling lines plans with paper and Excel. At the end of the shift, nobody knows exactly why a line stopped – and traceability means leafing through binders.
Decision
Instead of a long concept paper, we build a clickable prototype of the user interface early on. For Werk Nord, it was ready on the first day of the project. This way, customer and engineers talk about the same picture – not about terms that everyone understands differently.
Result One-page target vision and clickable layout prototype
Step 2 · Site survey
We walk the material flow: raw material store, tank farm, syrup room, five filling lines, goods issue. Every plant unit, every data point and every role goes on the list.
Decision
The four finished-syrup tanks are not assigned a fixed type. Changeovers go via an empty tank; each line draws from a selectable tank via a valve manifold. This costs valves, but makes planning considerably more flexible.
Result User requirements specification with 290 field devices, four recipes and five roles
Step 3 · Plan
Before any programming starts, the architecture is in place. It defines where data is generated, where the logic runs and who may operate what.
Decision
PLC connectivity, alarms, MES modules and automations run on exactly one backend. The control room servers only display and send commands there for validation. If the logic ran twice, quantities would be booked twice.
Result Architecture diagram and functional specification: five gateways, one model, one operating concept
Step 4 · Engineering
Now the user interfaces are built – with Ignition by Inductive Automation and the MES modules from Sepasoft. We generate screens, data points and translations by program, not by mouse click.
Decision
The status rules for orders are held in stored procedures in the database. The user interface only reads and calls these procedures; its database user cannot change anything directly. This way, no screen can put an order into an invalid state.
Result Around 200 screens in 7 projects, 5,011 terms in 14 languages
Step 5 · Test
A simulation plays the role of the controllers of all plant units via OPC UA, the vendor-neutral standard for data exchange in automation. This lets us test with 290 devices before a real plant is connected.
Decision
“The OEE calculation is slow” was the first assumption. Timing each sub-step showed: 86% of the time was spent on material movements. We only optimise once a measurement shows where the time actually goes.
Result Test reports with measured values; 57 of 58 batches fully booked
These six findings actually occurred while Werk Nord was being built. Each one is documented, the cause identified and the solution verified.
Finding
A mixer transferred 5,000 L of water to the tank as lemon syrup.
Cause
An aborted batch had left 2,600 L of water in the mixer. The next batch started without a level check, and setpoints were booked.
Solution
A batch only starts on a free and empty mixer. The measured actual quantities are booked, not the setpoints.
Finding
At every order change, the MES reported “Error recording OEE values” – in exactly the second of the change.
Cause
The OEE recording of the MES modules from Sepasoft writes only one row per second and per line. We ended the old run and started the new one in the same call.
Solution
Changeover in two stages: end the old run, start the new run in the next 10-second cycle. This way, each run gets its own row.
Finding
82 of 391 syrup batches over three days had no output lot. That is where traceability broke off.
Cause
A withdrawal could not be split across several lot states. Our workaround, “Blend Lot”, booked incorrectly: for tank TK01, 50,271 L against 24,213 L physically present.
Solution
First, the booking chain was repaired: after that, 57 of 58 batches were complete. Then the comparison with the vendor documentation: the intended Auto Lot Completion function instead of a custom solution, with the threshold sized to the smallest withdrawal.
Finding
Lines stood idle although orders were pending. First suspicion: a bug.
Cause
The bag-in-box line fills pure syrup and drew 31,000 of 34,324 L of syrup demand. Four syrup tanks are not enough for this order mix.
Solution
No code was “fixed”; instead, the bottleneck was proven. The scheduling board now tracks tank levels per type and reports a syrup shortage as a planning alarm.
Finding
The tag history wrote 28.6 samples per second, around 235 MB per day.
Cause
Too much was recorded, too often. On top of that came write amplification of 437 partition copies per hour.
Solution
Signals selected, tag groups and deadbands set (values are only stored above a minimum change): 2.05 samples per second, around 17 MB per day – no trend is missing.
Finding
Sepasoft Batch Procedure and the controller did not understand each other: commands and state numbers did not match.
Cause
The controller has its own state machine. That is exactly how it looks in existing plants, too.
Solution
A bridge translates commands and states at the PLI (Phase Logic Interface, the interface between batch control and plant). The first real batch ran through on the first night of the project.
We also write down where we were wrong: our diagnosis “The batch engine sets the actual quantity to zero” was wrong – the zero was written by our own bridge. This is openly recorded as an addendum in the test report.
Step 6 · Handover
A plant is only finished when the people in the plant can operate it safely. That is why we train by role and remain available after start-up.
Decision
Logging in to the control room is optional. Without logging in, you can see everything but cannot trigger anything. Every command requires a role, is validated in the backend and logged with the user. This keeps the control room open to everyone who needs to be informed.
Result Trained roles, documentation, setup scripts and a dedicated contact person
Result
In six steps, an empty project folder became an operable plant – simulated, but with everything a real project needs.
Werk Nord shows how we work: understand first, then plan, then build – and measure every finding before we fix it. Six days after the start, we demonstrated the plant to Inductive Automation and Sepasoft. Because model, screens and translations are generated by script, a second plant is essentially a copy with different master data.
