• Pharma OEM
  • Siemens SIMATIC S7
  • MQTT remote service
  • ISA-95 L0–L2

One automation platform across a lyophilizer product line

Four freeze-dryer models, each historically shipping with its own custom controller. We moved the whole catalogue onto one configurable Siemens platform — commissioning dropped from ~120 days to 56, and warranty claims fell 29%.

Two large stainless steel freeze-dryer units facing each other in an industrial hall
Lyophilizers · 4 models across the product line
Industry
Pharmaceutical downstream GMP-regulated end users
Client type
OEM lyophilizer maker European Union
Platform
S7-1200 + IOT2050 SIMATIC KTP900 panel
ISA-95 scope
L0 – L2 Wiring design to web dashboard
Installed base
~50 machines · 4 models 9 countries across EMEA
Connectivity
MQTT over TLS Outbound only

Results

47% Faster commissioning per unit — from ~120 days to 56 on average Against the model-by-model approach
29% Fewer warranty returns and claims related to hardware or software Post-platform
9 Countries where the platform runs, all serviceable remotely Same codebase, same dashboard

01 The situation

Where the project started.

The client designs and manufactures lyophilizers — freeze-dryers — for pharmaceutical producers worldwide: a small catalogue of models covering different chamber sizes and drawer configurations, which in turn required different vacuum, cooling and heating configurations for each. Historically, each machine shipped with a microcontroller-based system built specifically for that model: its own low-level program, a custom panel with physical buttons also programmed by the manufacturer, plus a series of electronic cards and modules to read sensor signals and control the actuators.

That approach held up while the product line was small, but it stopped scaling once the catalogue grew and machines started shipping to production floors on different continents, each with its own commissioning team and support expectations.

The machines were mechanically solid and well built, but the control hardware and software were always the weak point. Frequent bugs were impossible to fix once a machine was delivered, often forcing a recall back to the factory. Because the hardware was custom-built, replacement units had to be shipped from the factory to the customer, extending downtime whenever something failed. Updating a machine or adding features was just as rigid: it required a field engineer to travel to the customer site. Skyrocketing technical support costs and warranty claims finally convinced the client to look for a permanent solution.

The technical challenge

  • A different control architecture per lyophilizer model, with no shared codebase between machines that run nearly identical process sequences: freezing, primary drying, secondary drying.
  • Building and shipping a machine took close to four months, most of it spent on hardware assembly and installation plus lengthy configuration and testing. Delivery time was also highly variable, due to heavy dependence on hardware component suppliers, most of them in Asia.
  • No remote visibility into machine status once a unit left the shop floor, often to a different country.
  • The customer could not link the machine to an upper-level system such as an MES or DCS, since it had no connectivity. Configuring several machines meant manual, one-by-one intervention.
  • Every process parameter — drawer temperature ramps, vacuum setpoints, cycle sequencing and drying steps — has to meet the tight tolerances lyophilization demands, leaving no room for control-logic errors once a machine is running production batches at a pharma client's plant.

02 The approach

The architecture decisions.

Architecture diagram: a single configuration source drives the components built to read it, which run on one shared client platform, sized here in scale figures, feeding downstream outputs under a set of operating rules.

One configuration DB

Model identity lives here — not in separate code paths

Function blocks

Execute only the logic each model needs, around standard recipes

KTP900 panel

Reads the same block to show or hide controls

I/O assignment

Parameterised within defined limits, not hardwired

S7-1200 CPU + I/O modules

The necessary modules, in the same rack

KTP900 touch panel

Connected via Ethernet to the PLC

IOT2050 · MQTT client

Isolated edge gateway · outbound over TLS

4 models
~50 machines
9 countries across EMEA

The platform runs on lyophilizers installed in 9 countries, all serviceable remotely through the same codebase and the same MQTT dashboard.

Broker in GVA's private cloud

Machine status, alarms and diagnostic data

Web dashboard

Reached by our team and the client's own support engineers, without a site visit

Control changes and remote updates travel on a separate, audited channel rather than the live telemetry stream.

No inbound access is ever opened into the customer's network

The validated network's attack surface does not change

Built by GVA On the machine One configuration block, four models, one way out to the cloud

We standardised the entire product line on a single Siemens SIMATIC platform: one CPU from the S7-1200 family plus the necessary I/O modules in the same rack, and a KTP900 touch panel connected to the PLC over Ethernet. Model and machine configuration is handled in software rather than in separate programs per machine. That's a deliberate trade-off: it ties the whole catalogue to one PLC ecosystem, but it also means every technician who commissions or services a machine is working inside the same framework, regardless of which model shipped. It also makes hardware service easier, since Siemens has distributors in every country where the OEM sells, making replacement parts fast to source.

Model identity lives in one persistent configuration data block, not in separate code paths. Function blocks check that data and execute only the logic each model needs, built around standard recipes that adapt to different components. The KTP panel reads the same block to show or hide controls, and I/O assignment is parameterised within defined limits rather than hardwired. We chose this over per-model programs because adding a model becomes a configuration task, not new development.

For remote visibility we added an MQTT layer on top of the control system, publishing machine status, alarms and diagnostic data to a web dashboard that both our team and the client's own support engineers can reach without a site visit. Control changes and remote updates go through a separate, audited channel rather than the live telemetry stream — which matters once a machine is running validated processes on a regulated production floor. Machines connect outbound over TLS to a broker in our own private cloud. No inbound access is ever opened into the customer's network, so IT approval at each site is a formality, not a negotiation.

03 How it was implemented

Phase by phase, with the real durations.

  1. Assessment

    3 weeks

    Reviewed the existing controllers across every active lyophilizer model to define what could become shared code and what had to stay model-specific. Included a visit to the client's facility to see how the machines were built and operated.

  2. Platform build

    2 months

    Developed the shared S7 PLC and HMI base programs, with model configuration designed in from the start rather than added on later.

  3. Pilot model

    7 weeks

    Rolled out the new platform on the most complex model first and validated it in the field at a customer site in Germany, close to the OEM's own facility. Starting with the most complex model meant simpler ones could largely be delivered by disabling features, not building new ones.

  4. Field rollout

    14 months

    Progressive rollout covering all four models across every newly built machine. Even some older machines that came back for refurbishment were updated to the new platform.

04 Results

What it delivered.

  • Once the shared platform was live, commissioning time on a new machine dropped by 47% compared with the previous model-by-model approach: from approximately 120 days to 56 on average.
  • Warranty returns and claims related to hardware or software issues fell by 29%.
  • The platform now runs on lyophilizers installed in 9 countries, all serviceable remotely through the same codebase and the same MQTT dashboard.

The takeaway

The lesson here isn't specific to lyophilizers. Any OEM shipping more than one machine model into regulated environments faces the same fork: build a control system per project, or build one platform that every project configures into. The second option costs more discipline up front, but it's the only one that scales past a handful of units without the support team drowning in one-off systems nobody remembers how to fix.

05 FAQ

Practical questions about this project.

No — if anything it's the opposite: it reduces dependency on the customer's location rather than limiting it. Siemens is a globally established brand with many distributors around the world, and the S7 PLC family and SIMATIC KTP panels are usually available for delivery. We also work with Rockwell Automation / Allen-Bradley and several other automation component manufacturers, which lets us match almost any customer's existing platform preference.

We validate the shared platform once, as a qualified baseline covering the logic common to every model: safety interlocks, cycle sequencing, alarm handling. Each new model only needs OQ testing on its specific configuration and I/O map, not a full requalification of the underlying code.

No inbound connection is ever opened into the plant network. Each machine only dials out over TLS to our broker via an isolated edge gateway, using its own credentials and restricted topic access, so the validated network's attack surface doesn't change.

It depends on how much the new model deviates from the shared platform, but typically two to three months.

Talk to us

Same challenge on your floor?

Building or maintaining a machine line with a different control system per model? Let's talk about what a shared platform would take for your product line.