Architecture decides your integration hours

Overview

Executive Summary

Most liquid-handling and bioprocess labs now buy “digital” sensors as a matter of course, whether that means the Hamilton Arc family, Mettler-Toledo ISM, or Endress+Hauser Memosens. A digital sensor, though, is not automatically an OPC-UA or MQTT sensor. In nearly every architecture the probe still reaches the data layer through a chain of intermediaries: a transmitter, a converter, a gateway, a PLC, or a SCADA system. Building and validating that chain is where the integration hours quietly add up.

Our argument is that the deciding factor is the architecture pattern you adopt, not the quality of any one vendor’s sensor. To show why, we measure four patterns against the same yardstick: take six digital probes from the moment they are mounted to the point where their readings and status are live in a single OPC-UA and MQTT namespace.

• The challenge. Every probe still needs termination, protocol conversion, data modeling, and commissioning before its data is usable. In transmitter and bus/converter setups, much of that work repeats for each box and each protocol.
• The target. Plugging a probe in should make it available almost immediately. Adding a second vessel should reuse what you already built, and moving a probe between vessels should be a software change rather than a wiring job.
• The approach. The QB Systems multi-sensor architecture folds termination, power, and protocol exposure into one Power-over-Ethernet stack: QB Multisensor, QB Edge, and QB Control. Modules are discovered automatically, and their data lands in a single OPC-UA, MQTT, and Modbus model.

For the single-vessel case, the native PoE stack covers the defined scope in roughly 6 to 14 engineering hours. The transmitter-centric and bus/converter approaches we looked at land in the 10 to 30 hour range. The PoE stack is the lowest-effort option in every scenario below, though the margin varies: roughly 20% fewer hours than a well-configured Hamilton Arc converter deployment, rising to 60 to 65% fewer against multi-transmitter or custom-hub builds. The difference comes entirely from cutting repetitive per-box configuration and protocol bridging, and has nothing to do with how well a sensor measures.

Value at a glance

The table below shows, for each use case, what the consolidated PoE approach is modeled to save. The percentages are illustrative: they come straight from the engineering-hour ranges in Section 4, compared midpoint to midpoint against the alternatives. They are not measured benchmarks, and they are not cost figures.

Use Case	Objective: what is achieved	QB native PoE (modeled h)	Other architectures (modeled h)	Indicative reduction in integration hours*
A. 1 vessel, 6 sensors	Six probes live in one OPC-UA and MQTT namespace, with alarms set and commissioning signed off	6 – 14 h	10 – 30 h	~20 – 55%
B. 2 vessels, 12 sensors	Both vessels in one data plane, scaled by cloning the first vessel’s template	10 – 22 h	14 – 56 h	~20 – 60%
C. Mixed-vendor, 1 vessel	Two probe ecosystems on one host and namespace, with no custom hub to build	~12 – 20 h	~30 – 60 h	~55 – 65%
D. Probe sharing across 2 vessels	Move a probe between vessels in software, with batch data kept intact	Software reassignment, no per-swap engineering	Rewiring or controller/tag change per swap	Recurring per-swap effort removed

* Midpoints of the modeled ranges in Section 4, compared across architectures. The underlying figures are ranges, not single points. See the Methodology, Assumptions & Legal Disclaimer.

02 / The yardstick

Target Outcome & Success Criteria

For the comparison to be fair, every architecture has to clear the same bar. Here is what “done” means.

Target. Take six online digital probes on a single vessel (pH, temperature, dissolved oxygen, conductivity, dissolved CO₂, and ORP/redox) from the moment they are mounted to the point where their process value and status are live in one OPC-UA and MQTT namespace, with alarms configured and a basic commissioning check passed.

Success criteria, applied consistently to every pattern:

• All six channels acquire data and are discoverable and named in one interface.
• Process value and status/quality reach both OPC-UA and MQTT.
• Out-of-range alarms are configured.
• A power-cycle and dropout sanity check passes.
• Adding a second vessel reuses configuration instead of starting the engineering over.
• Where the workflow calls for it, probes can be reassigned between vessels without rewiring or controller code changes.

A few things sit outside these estimates, and they sit outside for every pattern equally: mechanical port fabrication, SIP/CIP validation packages, formal GMP IQ/OQ paperwork, and full calibration SOP execution. All are largely vendor-independent and would add similar effort whichever option you pick.

04 / The numbers

Comparative Use-Case Analysis

The figures below are modeled engineering-hour ranges for the scope defined in Section 2. We use ranges rather than single numbers on purpose, because site conditions and team experience vary. There are no monetary figures here; the disclaimer explains why, and lists the assumptions behind every range.

Use Case A: Standard System (1 vessel, 6 sensors)

What is to be achieved. Wire up six digital probes on one vessel (pH, temperature, DO, conductivity, CO₂, and ORP) so that every reading and its status arrive in one OPC-UA and MQTT namespace, with alarms set and commissioning verified, and with as few boxes and configuration steps in between as possible.

Why effort differs. On the PoE platform, all six probes land in one module that is discovered on connection, and the namespace is published straight from it. The other three architectures each add a stage in front of the data layer, though less than you might assume. Hamilton Arc reaches OPC-UA directly through the Arc Modbus OPC Converter, about four sensors per unit, so it needs no PLC for OPC-UA. The Mettler M800 and the E+H CM448 terminate their sensors at a transmitter and then reach OPC-UA through an upstream PLC, SCADA, or gateway. MQTT is native to none of the three, so it is added through a bridge in every case. Effort then tracks the number of boxes and configuration points more than the brand: roughly two converters or two M800 transmitters for six probes, against a single eight-channel CM448.

Use Case A — modeled integration effort (engineering hours, midpoints)

Architecture (representative example)	Integration approach	Modeled effort (1 vessel)
Native PoE platform: QB Systems	One 6-sensor module, auto-discovery, software naming, native OPC-UA/MQTT export	6 – 14 h
Transmitter-centric: E+H Memosens + Liquiline CM448	One transmitter (CM448 carries up to 8 Memosens channels), plus an upstream bridge for OPC-UA/MQTT	12 – 26 h
Transmitter-centric: Mettler-Toledo ISM + M800	M800 channels (about 4 per unit), so roughly 2 units for 6 probes, plus an upstream bridge	14 – 30 h
Serial bus + converter: Hamilton Arc	Arc Modbus OPC converters (about 4 sensors each) expose OPC-UA directly, so about 2 for 6 probes, plus the shared MQTT bridge	10 – 16 h

Outcome. The PoE stack needs the fewest hours of the options compared, with the Arc converter path close behind. Both avoid an upstream PLC for OPC-UA, so QB’s remaining edge comes mainly from a single auto-discovered module and native MQTT rather than a separately built bridge.

Use Case B: Scaled System (2 vessels, 12 sensors)

What is to be achieved. Repeat the Use Case A result on a second vessel and bring all 12 channels into one interface and one data plane, so an operator works with both vessels in a single view. Reuse the first vessel’s configuration rather than building the second from scratch.

Why effort differs. The PoE platform adds a second multi-sensor module to the same Edge and clones the first vessel’s process template; duplicating a process carries the P&ID and service settings across with it. The other architectures generally add another hardware unit and repeat the mapping and bridging for it.

Architecture (representative example)	Scaling approach	Modeled effort (2 vessels)
Native PoE platform: QB Systems	2× Multisensor and 1× Edge; clone the process template; one unified export	10 – 22 h
Transmitter-centric: E+H CM448	About 2 transmitters (8 + 4 channels), unify, plus an MQTT bridge	22 – 48 h
Serial bus + converter: Hamilton Arc	About 3 Arc OPC converters (4 sensors each, OPC-UA direct), unify, plus the shared MQTT bridge	14 – 26 h
Transmitter-centric: Mettler-Toledo M800	About 3 transmitters (4 channels each), unify, plus an MQTT bridge	26 – 56 h

Outcome. Because scaling is template-driven, the PoE effort stays fairly flat as vessels are added. Per-unit replication tends to grow roughly in step with the number of transmitters or converters.

Use Case C: Mixed-Vendor Environment (one vessel, two probe ecosystems)

What is to be achieved. Bring probes from two different vendor ecosystems onto one host and into one namespace, say three Hamilton Arc probes on Modbus alongside three Mettler-Toledo ISM probes, without standing up a custom industrial PC or PLC to stitch the protocols together.

Why effort differs. The QB Multisensor is documented to read both Hamilton sensors over RS-485 Modbus and Mettler-Toledo sensors through the ISM module or an M100 converter, so both families feed one QB Control namespace directly. The vendor-neutral route usually means a custom hub, such as an industrial PC running Kepware with its own drivers and mapping, or bridging logic inside a PLC. Either one brings driver work and ongoing maintenance with it.

Architecture	Strategy	Modeled effort	Notes
Native PoE platform: QB Systems	One platform ingests both probe families into a single namespace	~12 – 20 h	Standardized configuration path
Custom integration hub: industrial PC (e.g., Kepware)	Custom PC, protocol drivers, and tag mapping	~30 – 45 h	Adds custom-software maintenance
PLC + protocol gateway	PLC logic bridges the protocols upstream	~36 – 60 h	Highest engineering content

Outcome. Pulling the mixed probe families onto one native host avoids both the custom driver development and the separate integration layer that drive most of the effort in the alternatives.

Use Case D: Dynamic Resource Sharing (probe sharing across 2 vessels)

What is to be achieved. One acquisition unit serves two small reservoirs, and operators routinely move a probe between them. When they do, the software should reassign that probe to the right process and P&ID without any rewiring or controller code changes, and the data should stay tied to the correct batch.

Why effort differs. This one is about a capability rather than a number of hours. Two patterns show up in practice:

• Dynamic assignment (QB Systems, “Pattern B”). With QB Control’s dynamic P&ID, a probe in any slot is assigned to the right process or vessel in software, and the diagram and data links update with it. No engineering is needed per swap, and batch traceability is preserved.
• Fixed mapping (typical of transmitter-centric and fixed-address bus setups, “Pattern A”). A channel or Modbus address is bound to one process path. Moving a probe to another process usually means rewiring or a controller and tag change, and a probe plugged into the wrong port can quietly read against the wrong source.

Outcome. If your workflow really does shuffle probes between vessels often, software-defined assignment takes the recurring reconfiguration off your plate. If the installation is static, the distinction matters less, and it is worth weighing against how you actually operate.

The fine print

Methodology, Assumptions & Legal Disclaimer

1. Nature of the analysis. This whitepaper is a comparative, assumptions-based analysis of several automation architectures. The integration-effort comparisons are theoretical models built from standard industrial engineering workflows. They illustrate structural differences between a native PoE multi-sensor architecture and the transmitter-centric, bus/converter, and custom-hub alternatives. They are not a guarantee of performance, time, or cost for any specific project, and they are not a competitive benchmark study.

2. Sources of information. Everything stated here rests on publicly available information and on the assumptions set out below. QB Systems capabilities come from the QB Systems product catalogs and the QB Control User Manual. The third-party architectures are described from the respective manufacturers’ publicly available product documentation and from widely documented, standard integration patterns (such as RS-485 Modbus RTU wiring, transmitter channel counts, and converter capacities) known at the time of writing.

3. Documented assumptions. The modeled effort figures depend on the assumptions below. Change any of them and the results change:

• a. Scenario. Six online digital probes per vessel (pH, temperature, DO, conductivity, CO₂, ORP); the target end-state is validated process value and status in a single OPC-UA and MQTT namespace with alarms configured.
• b. Integration scope. “Integration effort” runs from physical mounting through validated data in the namespace, plus a basic commissioning check. It excludes mechanical port fabrication, SIP/CIP validation, formal GMP IQ/OQ documentation, and full calibration SOP execution, all of which we treat as comparable across the options.
• c. Personnel. We assume standard technician and engineer proficiency, with no pre-existing reusable code libraries. Specialized vendor experts or existing reusable assets may beat the times shown.
• d. Effort, not cost. Results appear only as engineering-hour ranges. We assert no monetary amounts, labor rates, or total-cost figures, since these vary by region, contract, and internal burden rates and cannot be stated reliably for any specific reader. The percentage-reduction figures, including the Executive Summary table, come solely from the Section 4 hour ranges, compared midpoint to midpoint, and span roughly 20 to 65% depending on which alternative is compared.
• e. Assumed unit counts (from public capacities): the Endress+Hauser Liquiline CM448 carries up to 8 Memosens channels, so six probes fit in one transmitter and twelve in roughly two; the Mettler-Toledo M800 handles about four channels per unit, so six probes need roughly two units and twelve about three; Hamilton Arc Modbus/OPC converters take about four sensors each, so six probes need roughly two converters and twelve about three. Actual counts depend on the exact models and options chosen.
• f. Ranges, not points. Each estimate is a range that reflects typical site-to-site variation; the low end assumes favorable conditions and the high end assumes extra troubleshooting or stricter requirements.
• g. No specific project. No real customer, site, or deployment is represented. The figures are illustrative.
• h. Vendor tooling that is not publicly documented. The third-party vendors analyzed here, meaning every architecture other than QB Systems, may offer additional accessories, gateways, configuration utilities, software tools, or service packages that would further reduce the effort modeled in these use cases. Where that tooling is not publicly documented, we could not evaluate it, so it is not reflected in these estimates. Real-world effort with those vendors may be lower than what we show.
• i. OPC-UA and MQTT routing. Hamilton Arc reaches OPC-UA directly through the Arc Modbus OPC Converter (about four sensors per unit). The Mettler M800 and the Endress+Hauser CM448 expose fieldbus interfaces (Profinet, EtherNet/IP, Profibus, Modbus) and reach OPC-UA through an upstream PLC, SCADA, or gateway. None of the three is MQTT-native, so MQTT is added through a bridge and is treated as an equal step for all of them. The Arc figures assume this converter path; a hand-wired RS-485 multidrop bus into a custom Modbus master is a higher-effort variant and is not the basis of these estimates.

4. Third-party trademarks. References to third-party products, including Hamilton Arc, Mettler-Toledo ISM and M800, and Endress+Hauser Liquiline and Memosens, are made for nominative and comparative purposes only. All trademarks remain the property of their respective owners. Mentioning these brands does not imply any affiliation, endorsement, or sponsorship between QB Systems or A4BEE Sp. z o.o. and the trademark holders.

5. No disparagement. This analysis is about integration architecture: the number of boxes, protocol hops, wiring topologies, and software bridges needed to reach OPC-UA and MQTT. It says nothing about the measurement accuracy, reliability, or quality of any third-party sensor or instrument. The manufacturers referenced make high-quality, industry-standard metrology equipment; the effort differences described come from integration method, not from any shortcoming in those products. Where a manufacturer offers a configuration that removes some of the steps, the effort would be lower than modeled.

6. Limitation of liability. This document is for information only and is not professional engineering, procurement, legal, or financial advice. Do your own due diligence: verify the assumptions, capacities, and effort estimates against your own facility, the current vendor documentation, and real quotations before you decide anything. A4BEE Sp. z o.o. accepts no liability for actions taken in reliance on the modeled estimates in this document.

© 2026 A4BEE Sp. z o.o. All rights reserved. QB Systems is a product brand of A4BEE Sp. z o.o. · Flexible. Innovative. Limitless.