Modular Architecture in Laboratory Systems

Greater structure for laboratory processes and scale-up.

Scale-up begins in the lab. A structured and modular design of laboratory systems makes data comparable, experiments more reproducible, and the transition to production easier. Through an initial project with HiTec Zang, CTE demonstrates how proven, modular software architecture from production environments can be transferred to the lab, enabling products to be scaled up later with minimal effort.

Brief overview

added value for our customers:

Greater comparability of laboratory tests

A more efficient scale-up process

Less manual effort required for analysis and data integration

Laboratory setups are often developed incrementally. New equipment is added, experimental setups are modified, sensors are installed, and data analysis capabilities are expanded on a project-by-project basis. It is precisely this flexibility that is needed in day-to-day laboratory work. At the same time, however, this often leads to signals being renamed on an ongoing basis, causing the software to grow increasingly complex over time. As a result, data is not organized in a structured manner, and experimental results must be compiled manually, which is a time-consuming process.

The weakness of this approach becomes apparent at the latest when findings from the lab need to be transferred to pilot-scale or production. The programs and documentation from Lab Automation simply Lab Automation scaled up, and ensuring comparability across experiments, parameters, and formulas requires additional work. Integrating the data into higher-level systems or historian solutions later on is also a time-consuming process.

For companies, this means that the transition from “laboratory findings” to “production-oriented operations” takes time, carries the risk of errors, and slows down the transfer process.

Laboratory Production Architecture

This is exactly where the joint project with a customer began. The goal of the project was to adapt the proven, modular software architecture used in production facilities to a laboratory system. Laboratory data was to be available in a format and with a structure similar to that of data from production-related systems.

In line with the mini-plant concept, this means that even smaller laboratory skids with relatively simple equipment are not viewed as a single, loosely assembled unit, but are divided into functional modules and process units. Inputs and outputs are no longer simply numbered sequentially across the entire system, but are assigned to the respective modules. This makes it easier to retrieve information, evaluate it more effectively, and reuse it directly for subsequent scale-up steps.

In addition, the modular design also makes the overarching recipe and process control more transparent. The individual modules can be structured more clearly and integrated more easily into batch-compatible processes. This increases flexibility, making it easier to quickly adapt, expand, or recombine experimental procedures.

From a loose laboratory setup to a modular structure: The laboratory system is divided into modules and process units, whose I/Os are named in a manner consistent with production, thereby making them comparable to scaled modules in the production environment.

First project with HiTec Zang

For this project, CTE worked with HiTec Zang’s laboratory system for the first time. The company specializes in laboratory and mini-plant automation. With its LabVision system, HiTec Zang offers a modular laboratory automation platform that, depending on the configuration level, ranges from simple data acquisition to networked systems with numerous inputs and outputs.

The HiTec Zang portfolio includes a variety of modules designed to match the system's scale:

LabBox
Suitable for smaller systems with few I/Os, especially when signals are primarily accessible via the network (e.g., via Modbus TCP)

Lab-Manager
For larger systems, expandable with I/O cards; sensors and actuators can be easily connected via connectors

DC Manager
Also expandable like the LabManager, but designed for permanently installed systems, with installation in the control cabinet and hardwiring

For the first system, we used the DC Manager, on which our modular program runs. Functions such as dosing, temperature control, and mixing are implemented as clearly defined modules. The naming of signals, the assignment of data points, and the subsequent transfer to higher-level data structures are based on these modules. This creates a data model that can be transferred much more easily to a production-oriented context, thereby strengthening the bridge from the laboratory to piloting and production.

Designing laboratory systems with a modular approach from the outset lays the groundwork for better analysis, greater comparability, and a significantly more efficient scale-up process.

Gerhard Schnydrig • Head of Automation

Seamless integration all the way to the historian

The data from the laboratory facilities is structured in such a way that it can be integrated into a historian or a production-like data environment. This not only facilitates the evaluation of test results but also makes it easier to compare them with later pilot or production facilities. By using data structures in the initial laboratory tests that are similar to those used in later plant operations, companies can minimize data inconsistencies and ensure data consistency throughout the entire development process.

Overall, the implementation went smoothly. HiTec Zang’s lab system offers sufficient functionality to support our usual module-based program structures. At the same time, we learned two key lessons that are important for similar projects:

One of the first hurdles was working with the LabVision tool for class-based program sections. While the approach was fundamentally usable, instantiation did not go quite as smoothly as is typical with other systems. The links between the instantiated scripts and the user interface elements were not established entirely automatically and required additional manual input.

In day-to-day project work, this means that while the modular approach works, more attention needs to be paid to ensuring that the instances are properly linked and consistent.

Another challenge was establishing a flexible connection to the historian, in our case the AVEVA PI Server. While the data could be made available relatively easily via OPC UA—specifically in an ISA-88-compliant structure, as is standard in production facilities—if you take advantage of the laboratory system’s flexibility as usual and, for example, add a new measurement point, this cannot be automatically transferred to PI. The interface and mapping currently still need to be manually adjusted by the person responsible for PI—which is not yet flexible enough for us. We are therefore already discussing approaches involving generic placeholders that can be used as needed, or even a dynamic assignment of measurement points via context data.

Are you interested in a similar project?

Schedule a no-obligation consultation with Gerhard Schnydrig, Head of Automation.

Conclusion

In this project, CTE has demonstrated that even a laboratory system can be structured in a way that harnesses the benefits of a modular production architecture. The system remains flexible and adaptable during the development phase, while interfaces and data structures are designed to enable a smooth transition to pilot operations, project-based business, or even a full-scale system rollout with minimal additional effort.

The real added value lies not only in the automation of individual laboratory functions, but also in the quality and reusability of the resulting data. Designing laboratory systems with a modular approach from the outset lays the groundwork for better analysis, greater comparability, and a significantly more efficient scale-up process.

More exciting insights into our everyday life:

MTP standard for Plug & Produce principle

MTP with PCS neo

Industrial process automation according to ISA-88 standard