The Cost of Change: Flexibility and Plug and Play in Software Defined Liquid Handling

QB SYSTEMS ARTICLE

What changes at each layer (hardware, software, services, recipes, licence), on QB Modules or on the PLC you already own.

QB Systems | Version 1.2 | August 2026 Flexible. Innovative. Limitless.

The number that decides whether your automation is an asset or a constraint is not what the system cost you. It is what a change costs, and almost nobody measures it.

Watch

See it in action — QB Systems on the cost of change: flexibility and plug-and-play in software-defined liquid handling.

Executive summary

Traditional PLC and DCS platforms were built to run a fixed process at scale, and they do that well. In R&D, process development and multi-product operations, the process changes every few weeks. There, that same architecture turns every small change into an engineering ticket, a queue position and a revalidation cycle. It also fixes the process envelope at purchase, so the vendor decides how many pumps your fermentation needs. QB Control attacks both problems across five layers: hardware, software, services, recipes and the licence.

What that adds up to:

You configure the rig your process needs instead of accepting the pump count, port count and duty assignment a vendor fixed at the factory, so the process defines the equipment rather than the reverse.
Control strategy changes become a selection from a catalogue of tested services, so switching pH control from base/CO2 to base/acid is a parameter change instead of a re-engineering project.
Process definitions become versioned documents with Draft/Verified/Validated/Archived states and a full audit trail, so you gain change speed without losing change control. They export and import between similar setups. A parallel run or a design of experiments (DoE) arm starts from a proven recipe instead of being rebuilt by hand.
Perpetual or time based licensing, with entitlements you reassign yourself on a running system, plus browser based workstations, so bringing another person onto the system costs nothing and adding a vessel is a licence scope change you apply yourself, not a procurement cycle.
An OPC UA connector delivers the software, services, recipe and licence layers on your existing PLC, so you can test this entire argument without buying hardware.

What you do not get on existing hardware: auto-discovery, single-cable installation and linear scaling. Those are properties of QB Modules, and Section 9 states the boundary.

1. The cost of change is the number nobody reports

Ask your team one question: what did the last small change to process control cost, in weeks and in invoices?

Someone wants an extra feed pump on an existing rig. On a traditional platform that means:

I/O mapping and a controller code change.
An HMI update.
A scope document and a purchase order, in-house or out to an integrator.
A place in the engineering queue, behind whatever is already in it.
Retesting, then requalification.

The pump costs very little. Everything around the pump costs a great deal, and most of it is calendar time.

None of that appears on a capital line. It appears as delay, as a campaign you could not accommodate, as an experiment descoped because the rig could not be changed in time.

This is not a criticism of DCS and SCADA platforms, nor of the integrators who deliver them. These platforms were built to run large, fixed processes at scale, and they do that well. Their architecture assumes the process is settled and that the payback comes from running it reliably for years. That assumption is correct in production. It does not hold in a lab or pilot environment where the configuration changes every few weeks, and there those same strengths turn into cost.

QB Systems is built for the second case. The design goal was not to run a process more cleanly. It was to make changing the process fast, affordable and fully auditable.

2. Who decides how many pumps your process needs?

On a fixed configuration system, that decision was made when the product was specified, before your process existed, against an assumed average application rather than yours.

Take a typical case, and it is an illustration rather than a description of any particular product. The controller is specified for three peristaltic pumps. Your process needs four: a second feed, a base line and an antifoam line. You now have three options and none of them are good.

Run the process the vendor’s way and drop the fourth stream, so the science is trimmed to fit the equipment.
Buy the larger model, so a fourth pump costs a capital cycle.
Bolt on an external pump that sits outside the control system, outside the recipe and outside the audit trail, so you solve the process problem and create a compliance one.

That is the real constraint, and it is not about pumps. A product decision taken in a vendor’s engineering department became the boundary of what you are allowed to run. The same kind of limit tends to show up in several places on a fixed system:

How many pumps you get and which duty each one is allowed to serve.
How many sensor ports exist and which probe brands are permitted in them.
How many gas lines you have and which gases can be mixed.
How many vessels run in parallel, and whether they are allowed to run different processes at the same time.
Which control strategies are offered, and therefore whether pH by base/CO2 and pH by base/acid are both available to you at all.
Whether automated sampling can be added later, or whether that decision was closed at purchase.

What this changes with QB. You configure the rig your process needs, and you change it when the process changes.

Add the fourth pump because your process needs four, so the process defines the equipment instead of the equipment defining the process.
Assign duties yourself and reassign them next campaign, so a rig is a resource rather than a fixed installation.
Mix vendors at the sensor level through native Hamilton and Mettler Toledo support, so if your probe standard is one of those you keep it. Tell us early if it is not, because that is a scoping question with a factual answer.
Run different processes on different vessels at the same time, so parallel experimentation is not limited to replicates of one setup.

To be precise about the limit: the module range is finite and the Services Catalog is finite, so this is not unlimited configurability. What we do not do is fix the count, the topology and the duty assignment at the factory and then require a purchase order every time your process disagrees with that decision.

The principle underneath all of it: the vendor should supply capability, and the client should decide the process. Where a system is built the other way round, the cost is paid in descoped experiments rather than on an invoice, which is why it rarely gets discussed.

3. Flexibility runs through five layers

Flexibility is often presented as a long list of options in the software. That is one layer out of five. Flexibility only reaches your operating reality when it runs through all of them:

Hardware, so adding or moving a device is not a cabinet project.
Software, so behaviour is configured rather than coded for your site.
Services, so a control strategy is selected rather than re-engineered.
Recipes, so the process is a versioned, portable document rather than a change request.
The licence, so duration, scope and allocation are commercial choices you make and revisit, not limits fixed at purchase.

If any single layer is rigid, the whole system is rigid, because that layer becomes the bottleneck on every change.

Sections 4 to 8 describe each layer with QB Modules and QB Control together. That is the fullest version, and it is not the entry point for most facilities. If your existing PLC speaks OPC UA, four of the five layers are available without replacing hardware. Section 9 covers that route and its limits.

4. Hardware: one cable, and the system knows what you connected

QB Modules are PoE powered. One cable per module carries power and data.

One cable per module, so there is no marshalling cabinet, no I/O terminations and no loop drawings to redo when the rig changes.
A typed device profile on every module, so the system discovers what you connected and what it can do, and nobody writes controller code to make it usable.
Over 20 module types covering pumps, syringe pumps, agitators, selector valves, mass flow controllers, temperature control units and load cells, so a normal liquid handling rig is built from stock parts rather than an engineered assembly.
Native support for Hamilton and Mettler Toledo probes through QB Multisensor, so your existing probe standard does not have to change to adopt the platform.

What this changes: adding a device becomes a task instead of a project. Going from four vessels to eight is a linear addition of modules, not a step change in controller capacity, cabinet size and engineering scope.

On the words “plug and play”. In an OT context that phrase raises a fair suspicion: it sounds like the engineering was skipped. It was not skipped. It was done once, by us, inside the device profile, and it is the same released profile on every installation running the same version. Pre-engineered is not the same as un-engineered. It also means qualification starts from a supplier package rather than from site-specific logic that has to be specified and tested from scratch, though how much that shortens your timeline depends on your quality system.

The same picture on an existing PLC. Hardware is the one layer that needs our modules. The four layers above it do not. An OPC UA connector maps the devices your PLC already publishes into the Inventory module, and from the Inventory onwards the model is the same: you assign services, build recipes and run the process as you would with QB Modules, within the update rate, data quality and device coverage your address space provides.

So the difference is not what you can do with a device once it is there. It is how the device reaches the Inventory in the first place: one cable and self-announcement with QB Modules, an extra layer and work on your side with a PLC. Section 9 covers that route, what it gives you and where it stops.

5. Software: configuration instead of custom code

QB Control runs in a browser. Any device with a browser is a workstation.

No client to install and no operating system dependency, so there is no client hardware to specify, refresh or standardise over the life of the system.
Control behaviour lives in configuration, not in bespoke controller code, so reviewing a change does not require the person who wrote the original logic.
Configuration is versioned inside the platform, with the change, the time and the author recorded against the process object rather than in a separate source control system your QA team never sees.
Configuration is transferable, so a setup proven in one lab moves to another site without a rewrite.

What this changes: the platform stops depending on the one person who understands the program. When your automation engineer is on another project or has left the company, the system stays legible. For many organisations this is the quiet risk in the current setup and it is rarely on the risk register.

It also changes who can make a change. A process engineer adjusts process behaviour without writing controller logic, which matters while automation engineering capacity remains scarce and expensive across Europe.

6. Services Catalog: change the control strategy without touching code

This is the layer that attacks the cost of change most directly.

A service is a complete, parameterised control behaviour that you assign to devices. You select it, configure it, run it. QB Control ships with the Services Catalog already built and tested.

Function	Service templates available
Temperature	Set Circulator Temperature in TCU (continuous, ramp); Temperature Control by TCU (continuous, PID)
pH	pH Control by Base and CO2 (PID); pH Control by Base and Acid (PID); pH Adjustment by Base and Acid (target based)
Gas	Set Mass Flow Controller Mass Flow (setpoint); Add Gas Volume by Mass Flow Controller (totaliser)
Liquid transfer	Set Pump Flow Rate (setpoint); Transfer Volume by Pump (volume based); Liquid Transfer Mass by Pump (gravimetric); Set Centrifugal Pump RPM (setpoint)
Agitation	Set Agitator Speed (continuous, ramp)
Foam	Foam Control by Antifoam Reagent (event driven)
Valves	Set Selector Valve Position (position)
Sampling	Automated Sampling by Syringe Pump and Selector Valve (sequence)

These are examples, not the full Services Catalog. The table shows the pattern rather than the stock list: control behaviours arrive as tested, parameterised objects that you select and configure, and the catalogue grows over time. Ask for the current list when you scope a rig, because the only question that matters is whether the behaviours your process needs are already in it.

Service profiles sit on top of the Services Catalog and hold reusable parameter sets for pH control, PID tuning, temperature and heating/cooling control, gas flow, stirring and foam control. Your validated tuning becomes a named object you reuse, so nobody retypes a set of numbers and nobody has to check them again.

What this changes: switching pH control from base/CO2 to base/acid is a selection and a parameter set. It is not a scope document and a queue position. The same applies to moving a transfer from volume based to gravimetric, or adding automated sampling to a rig that did not have it yesterday.

This is also the answer to the reasonable objection that flexible systems drift. You are not writing new logic on a live rig. You are selecting from pre-built, tested behaviours. The flexibility is in the arrangement, not in the code.

7. Recipe engine: the process becomes a versioned document

The Recipe module has three boards: Designer, Batch and Executions. In the Designer you build the process from operations and services.

Standard operations (Start, Wait, End, Stop) and advanced operations (Conditional, Wait Until, Counter, Polygon, PID, Split, Merge, Manual Operation), so a recipe expresses the real process instead of the subset the tool allows.
Split and Merge for true parallel branches, so gas control, feeding and sampling run independently instead of being forced into one sequence.
Conditional and Wait Until, so the recipe responds to the process rather than to a clock.
Polygon for piecewise linear profiles, so a feed or temperature ramp is drawn once rather than assembled from steps.
Version states Draft, Verified, Validated, Archived, so what runs on the rig is a released object and not somebody’s working draft.
Export and import of recipes between systems, so a released process definition moves to a similar setup as a file rather than being rebuilt in the Designer.
Pre-execution checks run before the batch starts, so the checks in scope catch a misconfiguration before you commit material, not halfway through.
Full audit trail on every recipe transition and every run, so a released definition carries its own history rather than needing one reconstructed later.

Where this pays off hardest: DoE and parallel runs. A design of experiments campaign is one process definition executed many times with different parameters. Built by hand, that means creating the same recipe from zero for every arm, which costs development time nobody budgets and introduces the one variable you least want in a DoE: the person entering it.

Export the released recipe once and import it for each arm, so the work per run drops to changing parameters instead of rebuilding the process.
Every parallel run starts from the same released definition, so transcription is removed as a source of difference between arms.
The same file moves to another rig, or to another site running a similar setup, so a method transfers as an object instead of being reconstructed by whoever receives it.

What this changes: a process modification becomes a versioned document change with a defined review path, not a call to a third party. Process knowledge stops living in a lab notebook and in one engineer’s memory. It becomes an object you review, copy, adapt for the next campaign, move to another system and hand to a client or an auditor.

8. Licensing: the layer where flexibility usually dies

A platform can be technically flexible and commercially rigid. If every additional vessel, seat or connection triggers a licence event, the contract quietly re-imposes the constraint the technology removed.

What you choose at purchase:

Duration: perpetual or time based. Perpetual is bought once, with no recurring licence fee, so you are not renting the right to run your own process. Time based runs for a defined period, so a funded project or a fixed-term client campaign can be licensed for the time it actually runs instead of forever.
Scope: fixed and written down. The licence covers a stated number of devices and services rather than an open-ended count, so your entitlement is a number both sides can read, stated in the licence agreement rather than left to interpretation at renewal or in an audit.
Tier: three standard tiers, or a custom one. Most facilities fit a standard tier. The custom tier exists for the ones that do not, so an unusual configuration is a quotation rather than a refusal. These are licence tiers and they are separate from the support tiers below.

What you control afterwards:

Floating entitlements, allocated by you. You decide in the Inventory module which devices and services draw on the licence, and you can move that allocation later, so entitlement follows the rig you are running this quarter rather than the one you configured on day one.
Licence changes apply to a running system, in both directions. A new licence takes effect without stopping the process, and a previous licence can be reapplied the same way. So you scale up for a campaign and back down afterwards without a shutdown, and every licence change can be undone.

The rest of the commercial model:

Support sold separately in tiers (Basic, Standard, Premium), so you buy the response time you actually need and support is not a condition of continuing to run the system.
Any browser device is a workstation, so there is no client hardware to budget or refresh.
Data out through OPC UA, MQTT, REST and SQL into a database you can query. Ownership of your process data and process definitions rests with you and is stated in the licence agreement.

Two limits, stated plainly. Additional features and hardware modifications are quoted on request. The hardware module ecosystem is ours. QB Modules are single sourced from us, so the hardware layer carries genuine lock-in and you should price it into the decision.

What this changes: growth in usage does not automatically become growth in cost, because the licence is scoped, allocated and re-scoped by you rather than triggered by us. Bringing another person onto the system costs nothing. Adding a vessel may take you past your tier, and if it does, extending scope is something you apply yourself on a running system rather than a procurement cycle you wait out.

9. You do not have to replace your PLC

Everything above may read as an argument for buying new hardware. It is not, and we would rather be clear about that now than have you discover it later.

The move to software defined operation is not gated on new hardware. It is gated on one question: can your existing control layer expose its devices and values in a standard, machine readable way? If your PLC has an OPC UA server, the answer is yes.

How it works. QB Control includes a connector that handles the OPC UA integration, so this is a configured connector rather than a bespoke interface written for your site. It maps the address space your PLC already publishes onto the QB Control device model, so your existing devices appear in the Inventory module as typed entries. From there a device behaves like any other device in the platform.

What you get on hardware you already own:

The Services Catalog and service profiles, so a control strategy change is a selection rather than a PLC code change.
The recipe engine, including parallel branches, conditional logic, the four version states and recipe export and import, so process changes are versioned and reviewable.
Audit trail and run history with no record limit imposed by the software or the licence, so retention follows your policy and your storage rather than a product cap, and the compliance record improves without touching the process layer.
Role based access control over the devices your PLC exposes, so who may change a setpoint stops depending on who has the panel key.
Browser access from any device, so overseeing a run no longer ties a skilled person to a panel on the floor.
Data out through MQTT, REST and SQL, so your historian, ELN or analysis stack gets the data without a bespoke bridge.
The same licence model, including the duration and tier choice and the floating entitlements you allocate yourself in Inventory.

That is a real shift, and it stops at a clean line.

What does not change:

The physical layer stays as it is. Adding or moving a device still means wiring, I/O, PLC configuration and publishing the object in the OPC UA namespace.
Auto-discovery, single-cable installation and linear scaling are QB Modules properties. You get them where QB Modules are installed and nowhere else.

On this route four layers change, and the hardware layer keeps the change cost it has today.

One condition worth checking before anyone commits: how much benefit you get depends on what your PLC exposes, at what update rate and with what data quality. Some OPC UA servers publish a rich, well structured address space. Others publish a thin one built for a single HMI and never revisited. That is a scoping question with a factual answer, and we look at a real address space before making any claim about your system.

What this usually looks like in the end. Mixed, deliberately. QB Control as the software layer across the facility. Existing PLC hardware kept where the process rarely changes, which is where that hardware is good. QB Modules added where change velocity matters: new rigs, modified skids, the development bench, the equipment reconfigured every campaign.

Your existing investment keeps earning, and the decision in front of you gets much smaller. It stops being “replace the automation” and becomes “put a software layer over one existing rig and measure what happens”.

Saying this costs us hardware revenue on the first project. We would still rather say it. If your PLC speaks OPC UA, a good part of this architecture is available to you without buying anything from us except software.

10. What it looks like in practice

Three routes, and only one of them requires you to change hardware.

Change event	The usual route today	QB Control over your PLC (OPC UA)	QB Control with QB Modules
Add a feed pump to a running rig	I/O mapping, controller code, HMI update, integrator scope and PO, retest, requalify	PLC side wiring, I/O and publishing the object stay as today. No HMI work, no control logic written, assign a service	Connect one cable, the module is discovered, assign a service, set parameters
Switch pH control strategy	Re-engineering task, code change, revalidation	Select a different service template and profile, versioned	Select a different service template and profile, versioned
Add automated sampling	New hardware plus new sequence logic, engineered per site	The sequence comes from the sampling service. Hardware still integrated PLC side	Add the syringe pump and selector valve modules, apply the sampling service
Repurpose a rig for another process	Effectively a small project	New recipe assembled from services already mapped. No PLC work if the devices are published	New recipe assembled from existing services on the same hardware
Go from 4 to 8 vessels	Controller capacity, cabinet, licences, engineering	PLC side scaling as today. The software side does not change. Extend licence scope if the new vessels take you past your tier, applied while running	Add modules. The software model is unchanged. Extend licence scope if the new vessels take you past your tier, applied while running
Change a recipe step and release it	Change request, integrator, revalidation cycle	Draft, Verified, Validated. Versioned, audit trailed	Draft, Verified, Validated. Versioned, audit trailed
Run a DoE across parallel vessels	Build or edit the sequence per vessel, or run the arms in sequence	Import the released recipe per arm, change parameters. Identical on both routes	Import the released recipe per arm, change parameters

Read the middle column carefully, because it is the one most facilities will actually start from. Over an existing PLC every software change becomes fast and every physical change costs what it costs today. That is still a large shift, because in development and multi-product environments a large share of changes are software changes. It is not the whole shift.

The left-hand column describes the change path we have commonly met on conventional PLC, DCS and SCADA installations at lab and pilot scale. It is drawn from our own project experience, not from a measurement of any named product, and it will not hold for every platform or every installation.

We are deliberately not putting hours in that table. The numbers depend on your rig, your procedures and your QA process. The only figures worth trusting are the ones measured on your equipment. Section 14 sets out how to get them.

11. Flexible and controlled are not opposites

The most reasonable objection to everything above: if change is that easy, how is change controlled?

Separate two things that usually travel together. Rigid is not the same as controlled.

Systems that make change expensive do not stay unchanged. They accumulate a second layer around themselves: a manual step, a spreadsheet that calculates the feed, a setting adjusted at the panel and written down later, an operator who knows the workaround. That layer exists because the sanctioned route was too slow or too costly. It is also where the real data integrity exposure sits, because none of it is in the system.

The comparison that matters is not controlled rigidity against uncontrolled flexibility. It is governed flexibility against ungoverned workarounds. A change made inside the system, with a version state and an audit trail, is a better compliance position than the same change made outside it in a spreadsheet.

To be accurate about current scope: QB Control provides the technical controls an electronic records programme needs, including audit trail, access control, version states and retention, and we supply the corresponding supplier documentation. Electronic signatures under 21 CFR Part 11 Subpart C are not implemented today. Compliance itself is established by you for your intended use, because a vendor supplies capability rather than compliance. If e-signature is a hard requirement for your application today, that is a real gap and you should know it now rather than later.

With that stated, here is what makes the flexibility governed:

Role based access control, so parameter configuration stays with senior staff while execution and monitoring sit with the operator, and the permission model matches the org chart.
Recipe version states with explicit transitions, so a draft does not reach a rig through the normal execution path.
Full audit trail with no record limit imposed by the software or the licence, so the history an auditor asks for is bounded by your retention policy rather than by a product cap.
Pre-execution checks before every run, so a misconfiguration in scope is caught before material and time are committed.
Configurable rather than custom software. Customers typically categorise a configured product under GAMP 5 as Category 4, where logic written for one site sits in Category 5, so the validation effort is usually lighter and the supplier package is the same release at every site. Categorisation stays your decision for your intended use, and any bespoke extension is assessed separately.

12. You would not be first: the industry is already standardising this

Standardised, modular, plug and play automation is not a vendor idea pushed at the process industries. The industries are pushing it themselves.

BioPhorum, the cross-industry biopharmaceutical collaboration, runs a workstream called Plug and Play for Modular Biomanufacturing. Its own statement of the problem matches this article: missing standardised interfaces between equipment and automation drive long lead times, sequential validation effort and custom engineered solutions, which raise cost and limit operational flexibility. It has published a modular process equipment requirements framework, a stirred tank unit interface specification and a plug and play computerised systems validation strategy.
MTP (Module Type Package), specified in the VDI/VDE/NAMUR 2658 guideline series, is the formal industry track for modular automation with typed interfaces. It is carried by NAMUR, ZVEI and PROFIBUS & PROFINET International, which hosts the specification and certification, and it is implemented by the major automation vendors. International standardisation at IEC has been an intention rather than a completed route, so MTP today rests on the guideline series and PI certification.
The Open Process Automation Forum at The Open Group publishes the O-PAS Standard for open, interoperable process control, and ExxonMobil has run an O-PAS aligned system in live commercial production at its Baton Rouge resins finishing plant since the end of 2024. One plant, at one of the most conservative operators in the world, and the first of its kind at commercial scale.
The incumbent DCS vendors are moving the same way. Virtualised control has shipped for years, and software defined control is now reaching release, with Emerson’s DeltaV v16.LTS and its server based software defined controller announced in January 2026. The direction is not in dispute. The open question is who serves lab and pilot scale liquid handling, where the economics of the large platforms have generally been hard to justify.

None of that is a QB Systems argument. It is the direction the buyers, the standards bodies and the incumbents have already taken, so the question in front of you is timing and scope rather than whether.

13. Where we are not the right answer

QB Systems is built for lab through pilot scale liquid handling: R&D, process development, tech transfer, multi-product and multi-client operations. Large scale continuous production, plant wide distributed control and safety instrumented systems remain the domain of traditional platforms, and we say so in the first meeting rather than the third. In most facilities the realistic picture is coexistence, with QB Control covering the scale and the change rate your DCS was never designed for.

14. Try it before you buy it

Nothing above needs to be taken on trust. The decision we are asking for is not “replace your automation”. It is “run one rig differently for one quarter and measure it”.

The shortest test, and it fits inside one meeting. We come to you with a module, connect it to a running system in front of your team, and hand your engineer the keyboard for the second one. Compare that against what the same change takes on your current setup. If the difference is not obvious inside the meeting, the rest of this article is not worth your time. Where the conversation starts from hardware you already own, the equivalent first step is a review of your OPC UA address space, which tells us both how much of this you can have without buying anything.

The lowest threshold pilot, if your PLC speaks OPC UA. Point QB Control at one existing rig through the connector. No hardware purchase, no rewiring and no cabinet work. What you provide is a host for QB Control, a network path to the PLC and OPC UA server configuration, all of it through your normal change control. You get the Services Catalog, the recipe engine, the audit trail and browser access on equipment you already own, and you can measure what changes. If it does not deliver, the process equipment itself is untouched: you disconnect the software layer and revert the configuration.

How to structure the pilot:

Pick one non-critical rig or one upcoming process, not the campaign that pays the bills.
You write the success criteria before we start, in your words and your metrics, so the result is measured against your definition rather than ours.
We time the change events on your equipment. Add a device. Switch a control strategy. Build and release a recipe. Your stopwatch, your people at the keyboard, not a scripted demo.
Your QA and IT review the packages up front, so validation documentation and security architecture are settled before a decision rather than after it.
The exit is defined in writing, so stopping at the end of the pilot has a known cost and a known process.

What this means commercially

If your product mix, client base or modalities change, the cost of changing the process is now a larger line than the cost of running it. Nobody reports it upward.

Alongside it sits a second cost that never appears anywhere: the experiments and campaigns you did not run, because the equipment configuration was decided by a vendor years ago.

Moving that cost down is what lets the same footprint and the same headcount support more campaigns, faster tech transfer and the experiments you currently descope. What that is worth in your facility is exactly what Section 14 is designed to measure.

The entry point is a software layer over one existing rig. The investment required to find out is small and reversible, and the case for going further gets built from your measured numbers, not ours.

What would you measure first?

If you can put a number on what your last small process change actually cost, in weeks and in invoices, you already have the business case. We would like to see that number and show you what the same change looks like here.

Two questions worth answering before we speak:

Which change event would you want to time first on your own rig?
Does the PLC on that rig already expose an OPC UA server?

Send us those two answers and we will come back with a scoped first test rather than a deck.

Regards, Krzysztof Kaczor CEO, QB Systems / Board Member, A4BEE Sp. z o.o. krzysztof.kaczor@a4bee.com

Notes on this document

Capabilities described reflect QB Control and QB Modules as of August 2026. Scope, module availability and compliance coverage should be confirmed against current product documentation for your application. Statements about future functionality and catalogue extensions are current intentions, not commitments.

This document is provided for information. It is not an offer, forms no part of any contract, and creates no warranty as to fitness for purpose, performance, timescales, cost, compliance outcome or validation effort. The applicable quotation, licence agreement and product documentation govern in all cases. The specifics of any pilot, including success criteria, scope, cost and exit, are set out in a separate written agreement.

Comparisons with traditional platforms, fixed configuration systems, DCS, SCADA and PLC installations describe generalised patterns observed by QB Systems in lab and pilot scale bioprocess environments. They are not measurements of any specific product, vendor or service provider, are not intended to identify or denigrate any of them, and will not hold for every platform, configuration or installation.

QB Control and QB Modules are process control and data products. They are not safety instrumented systems, are not assessed or certified to IEC 61508 or IEC 61511, carry no SIL rating, and must not be used to implement safety related functions, protective layers or emergency shutdown. Independent safety systems and interlocks remain the customer’s responsibility.

Nothing here is legal, regulatory or validation advice. GAMP categorisation, the applicability of 21 CFR Part 11 and EU GMP Annex 11, and validation scope are determined by the regulated user for the intended use. QB Systems supplies product capability and supplier documentation only.

Section 12 describes independent industry initiatives, referenced from their publicly available documentation and stated as of August 2026. QB Systems and A4BEE Sp. z o.o. are not affiliated with, members of, endorsed by or certified by BioPhorum, NAMUR, ZVEI, VDI, VDE, PROFIBUS & PROFINET International, IEC, The Open Group or ExxonMobil. QB Control and QB Modules are MTP conformant but are not O-PAS conformant products. All third party names and marks are the property of their respective owners and are used for identification only.