Sage Journals: Discover world-class research

Abstract

Ambitions to improve the connectivity of devices to enable automation and digital representation of processes have been around for some time. Nevertheless, some companies, especially in life science and analytical science, tend to adopt these developments rather slowly. In the field of microbial analysis of drinking and process water, for example, a large part of the work is still carried out manually, although the high number of samples per day and the low fluctuation in work processes would predestine water analysis for a higher degree of automation. Obstacles such as the risk of bottlenecks and possible downtimes after machine failure, the spatial conditions together with the low flexibility of the automated system, a lack of trained personnel, and the high acquisition costs hinder this development, however.

To lower these barriers, we have developed a system for the generation of flexibly expandable automated process lines, which handles sample handling and sample transport as a decisive step in the networking of several devices. The system allows the connection of devices that are distributed over the entire laboratory or close to each other, as well as those with a combination of both spatial situations. A functional or throughput expansion of the process can be realized by adding additional devices or storage areas to the network.

With this concept, we have established a system for the automatic processing of defined steps of a routine Legionella pneumophila screening in drinking water testing. From this starting point, the process can be extended to cover further steps, such as concentrating or plating, up to the full analytical workflow.

Keywords

laboratory automation flexibility sample transport

Introduction

Microbial Drinking Water Testing

As early as 1883, Robert Koch established the bacterial contamination of water as a criterion for the quality of drinking water and thus created the beginnings of modern drinking water analysis.¹ This parameter, now known as the heterotrophic plate count (HPC), still exists today.² Since then, however, the number of parameters that have to be monitored in compliance with the German Federal Environment Agency to ensure quality and make drinking water a safe foodstuff has risen steadily. Since the introduction of the German Drinking Water Ordinance in 1975, the number of chemical, microbial, physical, and radioactivity parameters increased from 18 to a total number of 106 in 2018.³ Considering microbiological drinking water analysis, which is the objective of the developed automation system, the Drinking Water Ordinance defines strict threshold values for the following parameters:²

Coliform bacteria and Escherichia coli [0 colony-forming units (cfu)]

Enterococcus [0 cfu]

Pseudomonas aeruginosa [0 cfu]

HPC at 22 °C and 36 °C [20–1000cfu/ml]

Clostridium perfringens (and spores) [0 cfu]

Legionella spp. [100 cfu/100 ml]

All these organisms either are potentially dangerous to human health or serve as indicator parameters, and they must therefore be monitored at a defined frequency depending on the corresponding flow rate of the water-distributing institution. On one hand, coliform bacteria and Enterococcus indicate fecal impurities in the water, which in the past led to devastating epidemics.⁴ Legionella pneumophila, on the other hand, is the main factor for the outbreak of legionellosis, an infectious disease that can range in severity from a mild, febrile illness (Pontiac fever) to rapid and potentially fatal pneumonia (Legionnaires’ disease).⁵ In German drinking water treatment, chloride is hardly used anymore for water disinfection, which additionally increases the importance of frequent screens.⁶

The more than 2500 large water suppliers (>1000 m³/d)⁷ and the even larger number of process water–using facilities, in conjunction with the sampling intervals required by law, lead to an enormous amount of samples. In 2016, >1 million⁸ official drinking and process water tests for microbial contamination, or indicator parameters in general, were carried out in Germany alone. Although the time to receive the results is rather slow, culture-based screening methods are still the state of the art for monitoring the microbial burden of drinking and process water. When testing for Legionella spp., Clostridium perfringens, and HPC, this procedure is currently the only one permitted under the Drinking Water Ordinance.

Considering the high number of samples, combined with the minimal fluctuation in the performed workflows, the demand and potential for a suitable automation strategy seem to be obvious. One system that is already commercially available is the ScanStation by Interscience S.A.R.L.⁹ (Saint-Nom la Bretèche, France), which works as an automatic incubator and real-time colony counter with a maximum capacity of 300 plates per batch. This range of functions enables the automation of at least some subprocesses in drinking water analysis. A function or capacity expansion as well as integration into an automated process chain are not possible with the currently available versions, however. Nevertheless, the field of microbial testing of drinking water is still dominated by manually performed workflows with at most a basal level of automation. This reluctance to switch to automation can be explained by the specific situation of drinking water analysis laboratories. The main issue is related to the necessary process accreditation and validation of all routine drinking water analysis laboratories in Germany [Deutsches Institut für Normung (DIN) European Standards (EN) International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 17025¹⁰]. The introduction of automated processes would require at least a revalidation process for the workflow or the whole laboratory, if this is even permitted. In addition, the high initial costs or downtimes due to the lack of robustness of the automated process would jeopardize the whole company, because a process is much more predictable when it is performed by humans in a well-established manner. Moreover, existing staff generally need to get used to the new environment and receive further training. Nevertheless, automation has great potential, especially in terms of throughput enhancement, gapless documentation, tracking and tracing of samples and results, as well as the protection of staff members due to less exposure to potentially hazardous material.

We believe that, in particular, the barriers of high initial costs, the possibility of future-proof process adaptation, and the company’s adaptation to the new technology can be addressed by maximizing the flexibility and scalability of the automation solution. This article emphasizes the need for flexibility¹¹ by developing a system that can be easily adapted in terms of functionality, throughput, and sample capacity, and that also offers opportunities for expansion or modification at a later stage. In this way, it is possible to grow into the subject of automation step by step, according to the available budget, by starting with small and simple processes instead of building up total laboratory automation (TLA) from the outset.

Flexibility of Automated Systems

In this work, we tried to transfer manually dominated processes into a certain level of automation while preserving a maximum level of flexibility to address different specific needs in the functionality and performance of laboratories in the field of microbial testing. In 1982, however, Hedberg and Jonsson already pointed out that technology has often made organizations more rigid rather than more flexible.¹² Although technology has developed much further, it is still true that an easy adaptation of existing technologies to changing needs or parameters is often difficult to obtain. Changing the container type in an established analysis procedure (e.g., from a 90 mm culture plate to one with a 120 mm diameter) can cause enormous problems because not every available device may be able to handle the new format. It is therefore important to define and formalize the essential aspects and constraints under which flexibility must be maintained.

Structuring the Definition of Flexibility

Regarding the changing external situation, De Groote defined the generic term of flexibility as the yielding of the best possible performance in the face of environmental variability.¹³ Hence, the initial starting point for the formalization of flexibility is the environment for which the technology is built. In the case of drinking and process water analysis, the intended environment will always be a laboratory with either an analytical or research orientation. The next step is to consider the possible variability within the boundaries of the previously defined environment. According to Najmabadi et al., the laboratory hardware needs to face functional, structural, and throughput changes. Therefore, they split the total flexibility (F_total) into functional flexibility F_f, structural flexibility F_s, and throughput flexibility F_v.¹⁴

Functional flexibility represents the adaptability of a system to changes in functional requirements. In the lab environment, Najmabadi et al.¹⁴ structured those into liquid-handling flexibility F_fl, transportation flexibility F_ft, and instrument feeding flexibility F_fi. Nelson and Ghods defined the feature of modularity to be important to achieve functional flexibility.¹⁵ Here, a system is divided into certain, less complex parts that fulfill distinct functions and can be removed or exchanged from the system separately.

Structural flexibility represents the ability of the system to change its configuration.¹⁴ Nelson and Ghods presumed the feature of consistency as important for the overall acceptance of the system to changes.¹⁵ The standardization of the inter- and intrasystem interfaces can achieve this consistency.

Throughput flexibility is defined as the capability of the system to react to throughput changes.¹⁴ The total flexibility of the laboratory system depends on each of the just-defined flexibilities in a functional correlation [see Eqs. (1) and (2)].¹⁴

F_{t o t a l} = f (F_{f}, F_{s}, F_{v})

(1)

F_{f} = f (F_{f l}, F_{f t}, F_{f i})

(2)

Determination of Numerical Flexibility Values

The determination of specific numeric values to characterize a system according to its flexibility can be helpful to identify the best design in the developmental phase as well as to characterize already existing systems and thus make them comparable with each other. In the work of Suh, a structured model is presented to consider the design of mechanical systems on a theoretical level.^16,17 This consideration is based on two axioms.

The first axiom is called the independence axiom. According to this, the requirements for the automated system need to be mapped from the functional domain into design parameters in the physical domain. These functional requirements are the minimum set of independent parameters that the system needs to fulfill according to the customer’s or user’s needs. The translation of the functional demands into specific design parameters represents a transition from what to how.

The second axiom is the information axiom. This axiom states that the design with the lowest information context has the highest probability of success. The information context is the sum of each probability-of-success function (p) of all parameters in a given design. Since we intended to calculate and compare the effects of individual design parameters, it was sufficient to determine the p-values and not the accumulated information context. The p-function displays the degree of how well a design parameter (dp) fulfills the corresponding functional requirement (fr).

p = (\frac{c_{r}}{s_{r}}) = \frac{c o m m o n r a n g e}{s y s t e m r a n g e}

(3)

Every flexibility parameter has its distinct probability-of-success function. One method for the determination of the p-value is the comparison of how well the design range (d_r) fits the needs of the system range (s_r). The intersection between the two is the common range (c_r). Equation (3)¹⁴ shows the probability of success written as the quotient of the c_r and s_r. In case the automated system fulfills the requirement completely, the probability of success is 1 and thus 100%. In contrast, if the design fulfills none of the requirements, p is 0, which corresponds to 0%.

When calculating the adaptation flexibility of a system to a priori unknown processes, s_r and c_r are consequently also unknown. It can therefore be difficult to calculate precise numerical values. For that reason, it is rather beneficial to display the quotient of design capability and system requirement as a function. This illustrates a clear correlation and also indicates to what extent d_r needs to be changeable and adaptable to achieve an optimal p-value.

Materials and Methods

Legionella spp. Screening According to DIN EN ISO 11731

Legionella screening was carried out according to DIN EN ISO 11731.¹⁸ Tap water samples were collected and analyzed by a routine laboratory for drinking water analysis. To reduce possible side flora, all water samples were heat-treated in a water bath (50 °C, 30 min) prior to processing. Subsequently, each sample was plated directly following membrane filtration on buffered charcoal yeast extract (BCYE) agar plates (bioMérieux, Marcy-l’Étoile, France).

Direct Plating Method

After rigorous shaking of the specimen bottle, 1 ml of the sample was spread on the culture plate with a sterile spatula.

Membrane Filtration Method

After rigorous shaking of the sample bottle, 150 ml of sample was vacuum-filtrated (Sartorius Combisart with Sartorius vacuum pump 16612, p_max = 13 mbar; Sartorius, Göttingen, Germany) using a 47 mm cellulose nitrate membrane filter (pore size 0.45 µm; Sartorius). The filter was then placed directly on the culture plate with sterile forceps (retentate side up), avoiding air bubbles. After incubation periods of 4 and 10 d (at 36 °C), the grown colonies with conspicuous Legionella characteristics were counted. If a threshold of 100 CFU/ml was exceeded, colonies were subcultured on BCYE-CYS (cysteine) agar plates (bioMérieux). Since L-cysteine is essential for the growth of Legionella, the resistance of cultivability proves the existence of these bacteria.

Equipment and Materials Used for Device Construction

All of the devices described in this study were developed in-house, using both rapid manufacturing techniques such as fused deposition modeling three-dimensional (FDM 3D) printing and classic manufacturing techniques. All system components are designed for operation on 24V direct current (DC).

Robotic-Based PetriJet Platform

We used a Raspberry Pi 4 as the device controller (https://www.raspberrypi.org/products/raspberry-pi-4-model-b/). Each axis is driven by National Electrical Manufacturers Association size 23 (NEMA 23) stepper motors controlled by Trinamic motion control module 1110 (TMCM1110) drivers. For internal data transmission, an RS485 bus system with a customized Trinamic Motion Control Language (TMCL)-based communication protocol was used. Both grippers are equipped with Arduino Nano (ATmega 328; https://store.arduino.cc/usa/arduino-nano) low-level (LL) controllers.

Track-Based Transport Rail

The rail system as a passive component consists of industry-standard metal profiles and is equipped with two custom-made 24V DC busbars that serve as the power supply for the automated guided vehicle (AGV). The AGV has a built-in Teensy3.2 LL controller and an ESP8266 Wi-Fi communication bridge.

Camera Station

The camera station is equipped with an IDS UI-1580LE complementary metal–oxide–semiconductor (CMOS) industrial camera (Imaging Development Systems, Obersulm, Germany) and allows the sample to be illuminated from above and below.

Results and Discussion

Parameter Determination

As discussed above, the overall goal of process automation in microbial testing of drinking and process water is to preserve maximum adaptability of the developed system to changes or a priori unknown parameters in the laboratory environment. We have therefore defined the customer requirements, as shown in Table 1 , and mapped them into functional requirements. The total functionality of the system, the available budget, and the throughput demands are unknown parameters that, to a certain extent, depend on the specific situation of each company or laboratory f(c) or even change as a function of time f(t). In addition, most laboratories that consider automation try to rather slowly adapt their workflows to a more automated way of processing and do not build new and fully equipped facilities from the ground up. Thus, the automated system usually needs to be installed into already existing spatial conditions and share this space with human staff members. This requires the system to be adaptable. The only fixed requirement is the need for certain process robustness and stability.

Table 1.

Customer Needs, Their Mapping into Functional Requirements, and Deduction of Physical Design Parameters.

Customer Domain (Needs)	Functional Domain (Functional Requirements)	Physical Domain (Design Parameters)
Robust process	Accuracy in handling, pick, and place	Conceptual division into close-proximity and wide-area transport
		Robotic-based	Track-based
Required functions = f(t, c)	Customized functionality → functional flexibility $\lim_{p \to 1} F_{f} (p) = m a x$	Functions are provided by modules or devices in close proximity	Functions are provided by devices or platforms distributed throughout a lab
Budget = f(t, c)	Customized extendibility → structural flexibility $\lim_{p \to 1} F_{s} (p) = m a x$	Extendibility according to the platform size	Extendibility over an entire lab
Space = f(c)	Adaptation to spatial conditions → structural flexibility $\lim_{p \to 1} F_{s} (p) = m a x$	Extendable in the scope of the platform	Extendibility from the footprint of one device to an entire lab
Throughput = f(t, c)	Adaptation to throughput → throughput flexibility $\lim_{p \to 1} F_{v} (p) = m a x$	Enhancement by parallelization	Enhancement by parallelization

f(c), Function of the particular company; f(t), function of time.

In light of these considerations, the claimed system needs to interconnect already existing or customized devices and thus allow the creation of customizable process chains. The following explanations are summarized in Figure 1 . By using existing laboratory equipment, the possible functions and processes depend only on the type and number of devices in the network. Thus, the actual task of the developed system is limited to the transport and handling of samples and materials as well as the loading of the specific process equipment. This approach is in line with the idea of gaining flexibility via component-sharing modularity.^15,19 At the communication level, the system needs to be capable of addressing all devices in the network to make centralized process control, data administration, and analysis possible (see the Management Architecture Concept section). The handling and loading of previously unknown samples hold a conflict of aims, however, since the handling units are usually specially designed for one or just a few sample container types or devices. The only possible alternative would be a handling device mimicking the human hand, since almost every device is designed or capable to be loaded manually. Such a complex mechanical element, however, would have some disadvantages in terms of robustness and speed of the process. Another obstacle is the long transport route the handling end-effector would have to travel to reach remote devices in the network. At every device side, the coordinate systems of the handling unit and the device would need to be synchronized to keep an acceptable handling accuracy. To avoid these obstacles, we divided the handling and transport function into two different approaches depending on the physical distance of the devices to be connected.

Figure 1.

Connection of devices (left) on a lab scale and (right) on a platform scale. Full arrows represent possible transportation tasks of physical objects, and dotted arrows represent the transfer of data.

For larger devices close to each other or small benchtop gadgets that can be moved easily, we use a robotic-based transportation and handling concept (see Fig. 1 , right). The system itself is a platform with a defined workspace. In this space, all devices are placed in specific positions. A handling end-effector mounted on a transport system, such as a robot arm or linear slide, takes over the transport of the samples and loads the devices. As mentioned before, the handling end-effector is usually designed for the handling of specific sample types and containers. It is reasonable to group devices that are built for the same sample formats into such a robotic platform.

When fixed equipment or platforms are located at a greater distance, a track-based transport approach connects the distributed processing stations (see Fig. 1 , left). Here, only a transport component, without a coupled handling unit, moves the samples and materials to the desired destination. Those components could be mobile robots, belts, or conveyors. The handling and loading must take place at the final destination with the advantage that many different container types can be transported by the same system without the need for an end-effector adaptation.

In both approaches, all devices could also be used in stand-alone configurations connected on the data and communication levels without any physical interconnection. Hence, the transport has to be carried out by a human, but naturally that results in only an assisted, rather than a fully automated, workflow. Here, we consider only the flexibility of automated processes, according to which the p-values for transport and instrument-loading flexibility (F_ft, F_fi) would approach zero. In contrast, by combining the robotic- and track-based approach, maximum transport and handling flexibility can be achieved (see Table 2 ). Since the system takes care of container transport and device loading, it has no liquid-handling function by itself. Such functionalities exclusively depend on the devices in the network. For this reason, the liquid-handling flexibility F_fl will not be examined further.

Table 2.

Calculated Flexibility Parameters of the Developed Robotic- and Track-Based Automation System: Probability-of-Success Value p = 1 Corresponds to 100% Compliance with the Requirements, Lower Values Indicate Restrictions.

	Stand-Alone	Robotic-Based	Track-Based	Combined
F_fl	p = Device dependent
F_ft	p = 0	$p = \frac{h a n d l . c a p a b i l i t y e n d e f f e c t o r}{n u m b e r o f c o n t a i n e r t y p e s}$	p = 1	p = 1
F_i	p = 0	$p = \frac{h a n d l . c a p a b i l i t y e n d e f f e c t o r}{n u m b e r o f d e v i c e t y p e s}$	p = 0	p = 1
F_s	p = 1	$p = \frac{n u m b e r o f i n t e g r a t a b l e d e v i c e s}{n u m b e r o f d e s i r e d c o n f i g .}$	p = 1	p = 1
F_v	p = 1	$p = \frac{p o s s i b l e t r o u g h p u t}{d e s i r e d t r o u g h p u t}$	p = 1	p = 1

In the following, we describe the actual implementation of both approaches into physical systems with a concluding application example. In this context, we also consider the flexibility parameters already introduced.

Robotic-Based Approach

With the presentation of the PetriJet platform,^20,21 we have already demonstrated the development of a robot-based platform for the automatic handling of Petri dishes. This early PetriJet version, however, allowed the integration of only one processing module at a time and had very limited space for storage available. Setting up a process with multiple steps was not possible on this platform. In addition, all culture plates had to be sealed to allow transport via a vacuum gripper. For these reasons, we have made a further development of the platform. The current PetriJet is shown in Figure 2 (pos. 1). The platform is now primarily adapted for the automation of certain steps in drinking water analysis in accordance with DIN EN ISO 11731¹⁸ (see the Application Example section). Nevertheless, as with the first platform version, the modular structure allows the workflow to be changed and thus adapted to different process requirements. Conceptually, the platform is capable of executing individual steps of a process chain, thus supporting manual work in critical subprocesses, up to the execution of the entire process chain without the need for user intervention. The range of functions is determined by the type and number of the integrated process modules (see Fig. 2 , pos. 2).

Figure 2.

Image of the automated process line for Legionella screening, consisting of (1) the PetriJet robotic platform equipped with (1.1) robotic-based transport grippers and (4) a track-based rail system. Processing devices, such as (2.2) a camera and (2.1) plate stack transfer rails, are placed in (2) the platform space; (6) samples and materials are placed on slides waiting to be processed in (3) the storage space. The (5) mobile automated guided vehicle (AGV) is powered by (4.1) conductor rails, and it detects, grips, and moves the slides via (3.1) the elevator to the desired destination.

Within the platform, which has a footprint of approximately 1608×540 mm, the samples are transported to the desired positions. Handling and transport are carried out by two electric parallel grippers specially designed for the transport of 90 mm Petri dishes (see Fig. 2 , pos. 1.1), which can also manage the opening and closing of the dish lid. The transport flexibility highly depends on the capability of these end-effectors (see Table 2 ). If the user just requires Petri dishes to be transported, the p-value reaches 1; otherwise, the value is considerably lower, and the gripper must be adapted to the new container. In the current expansion stage, the grippers are mounted on a linear-axis H-gantry, which enables transport on a single level and thus in only two dimensions. This limitation of accessibility forces a very specific location for the transfer area of each processing unit. Not every device is necessarily tolerant of this restriction. Hence, this design parameter also harms instrument-loading flexibility (F_fi). To remedy this drawback, we are going to exchange the linear slides with a robotic arm, which makes transport in a three-dimensional space possible. In Table 2 , we therefore did not consider that restriction.

The actual experimentation, manipulation, and analysis take place only at the process stations (see Fig. 2 , pos. 2). These units can be integrated into the platform, excluded, or exchanged with different units with other functions easily. Thereby, the system is capable of being adapted to different process needs by the user, with the limitation that the devices need to be loadable by one of the two handling units. These processing stations can be customer-specific devices with special functions, standard commercially available devices (in this case, a driver is required to connect to the platform software), or just containers that hold sample magazines. Currently, it is possible to implement a maximum number of 12 stations in the platform. This represents the current limitations of the system in terms of structural functionality. As long as the available space on the platform is sufficient for all desired processes, p_Fs = 1. Throughput flexibility is also affected by space limitations, because bottleneck processes can be parallelized only within the limits of the given platform size. All components of the system are connected via a common bus with a central-control software (see the Management Architecture Concept section).

A typical workflow processed on the PetriJet platform would require the user to perform the following preparatory steps:

Insert all the necessary processing stations in the platform (if used in stand-alone mode).

Create the desired workflow with all the necessary analytical steps on the graphical user interface (GUI) of the process computer.

Submit all necessary disposables, chemicals, and samples according to the process.

Start the process, and wait for the protocol.

For the implementation of the platform in a larger process line, it is possible to simply couple the platform with the track-based transport system (see the Application Example section). This enables mechanical interconnection with several other stations, devices, and storage areas. This capability also affects all flexibility parameters, as shown in Table 2 .

Track-Based Approach

To connect devices in a distributed processing workflow, we developed a physical implementation of the track-based transport approach in the form of a rail system. The transport system consists of three distinct modules: a rail system, a cargo slide, and a carrier robot (see Fig. 2 , pos. 4–6, and Fig. 3 ). In contrast to commercially available conveyor belt solutions, the system offers the particular advantages of simplicity and cost efficiency for each rail segment as well as the possibility to transport each cargo stack independently.

Figure 3.

Functional block diagram of the automated guided vehicle (AGV) inside the rail system.

The rail system can be installed in various lengths or shapes, and it forms the permanently installed transport route through which the goods are transported to the desired destinations (see Fig. 4 ). Movable slides are placed on the rail and carry the cargo. They are specially designed for each type of cargo, such as vessels, tubes, culture plates, containers, or others (see Fig. 2 , pos. 6, and Fig. 4 , pos. 2). This enables the transport of any type of container with the same system. The transport flexibility F_ft is accordingly p = 1 (see Table 2 ). The slides can be detected and transported by a carrier robot, which is freely movable within the rail system in the manner of an AGV (see Fig. 2 , pos. 5). Figure 3 shows a functional block diagram of the AGV inside the rail system. After the label on the slide has been scanned by the carrier robot, the gripper jaws close and hold the slide. When the AGV starts moving, it pulls the slide with the load. Because the AGV communicates via Wi-Fi and receives its power supply from the conductor rail via two sliding contacts (see Fig. 3 ), no further cabling is required. Thus, the robot’s reachable distance is limited only by the length of the installed rail system, which can be adapted at all times. Due to this interface consistency, the structural flexibility F_s is 100% (see Table 2 ). Also, the use of multiple AGVs in the same rail system is conceivable, but it is reasonable only when the track exceeds a certain dimension. The possibility of consistent parallelization of subprocesses by simply extending the number of devices and the number of transport robots also gives the achievable throughput a flexibility value of p = 1 (see Table 2 ).

Figure 4.

Computer-aided design (CAD) concept study of the track-based transportation system to connect several distributed devices and places. (2) A small automated guided vehicle (AGV) transports the items on a slide, moving inside (1) a rail system to (3) the desired platforms (here, PetriJet platforms equipped with modules for sample preparation, such as culture streak and nutrient media preparation) or (4) devices (here, a colony counter) and (5) the user; also see Figure 3 .

This concept of distributed processing enables workflows on the scale of an entire room or even the entire floor of a building, as illustrated in Figure 1 . As mentioned before, no end-effector is installed to enable the transfer of the load; therefore, a handling device must be available at each destination to transfer the load to the respective device (see Fig. 4 , pos. 4). This results in zero loading flexibility F_f (see Table 2 ). Moreover, it is necessary to provide certain docking or transfer positions on each device on which the cargo can be delivered. The interconnection of several robotic platforms by a track-based transport line allows a tremendous reduction of necessary handling units (e.g., robotic arms), since one unit can be used to feed several devices within its platform space.

The design of the system was inspired by the AGV’s rack retrieval and shuttle systems, which are used particularly in warehouse automation.²² Here, cargo has to be transported from storage areas such as shelves to packaging, subsequent treatment, or delivery destinations. Hence, for those tasks, such facilities share some similarities with laboratory institutions.

Management Architecture Concept

To ensure the possibility of centralized process control, data administration, and data analysis, a connection at the communication level of the devices is crucial. The capability of an easy device connection at the data transfer level can generate semiautomated or assisted workflows even without the necessity for any transportation or handling components in the entire process. Figure 5 shows a schematic illustration of the management architecture of the developed process chain system. It is structured hierarchically into the field level (FL), instrument level (IL), process level (PL), and user level (UL), each with increasing levels of abstraction. At the UL, the workflow is defined by the user via a drag-and-drop interface. Available resources can be linked together in a process flowchart. The PL schedules the generated workflow and takes care of the instrument communication and data handling. Currently, we use in-house developed software modules to display the UL and PL. Because, however, the integration of new devices into the process flow is still time-consuming and not based on existing standards, we will replace the connecting middleware with a commercially available solution. Within the framework of a joint project, we discovered the LabOperator software by Labforward²³ (Berlin, Germany) and found it was an appropriate substitute. It provides quick device integration by driver solutions for various interfaces. By using a SiLA2-compliant driver, it is also possible to integrate a nonproprietary communication standard. A graphical user interface enables a quick workflow definition.

Figure 5.

Hierarchical structure of the management architecture.

The IL consists of all available devices that fulfill the actual execution of the workflow. The field level is of interest if a device (in our case, the PetriJet platform or the AGV) is developed and built up in-house, and it is displayed only for the sake of completeness. We implemented a high-level (HL) controller (e.g., Teensy 3.2 or Raspberry Pi) in every stand-alone device that manages the communication with the superordinate control system as well as the control and processing of potential LL controllers, sensors, and actuators. The internal communication of the devices is vendor specific and does not affect the external communication. We mostly use the RS232 or (in the case of multiple bus participants) RS485 interface with a TMCL-based communication protocol.

The most critical point in the architecture is the connection between the PL and IL, because it is the interface between proprietary software. For easy implementation of new devices into the process resources, the communication interface between all devices on the IL must be standardized. We decided to use the MQTT Protocol²⁴ as an interface design because of its simplicity and payload flexibility. The protocol itself is based on a publish–subscribe pattern, which provides an alternative to traditional client–server architectures. The Process Manager software brick, together with all devices, serves as MQTT clients, either with direct implementation of the communication interface or via a driver solution. The communication between instances is handled by the MQTT Broker, whereby we used the Eclipse Mosquitto Server.²⁵ All devices subscribe to two different topics by default: a broadcast message and their identification (ID). At the start of the program, the process manager publishes an ID request via the broadcast topic. Every device replies to that call with the publishing of its unique ID and available properties. With this information, the process manager creates a topic for every ID and thus generates a communication channel for every device over which messages and data can be received from and sent to the process manager. Also, an instance is created in the process manager’s resource database that is visible and available to the user. This design works robustly for at least simple control commands. Regardless, we have not tried to send larger data packages (such as pictures) via this interface yet, although it is possible according to the literature.²⁶ When data or metadata are shared within a topic, they are collected and organized according to the sample ID by the data manager and stored in a protocol database.

We use this communication interface for its simplicity and are aware of existing standards. In further developments, we are going to exchange the MQTT-based communication with an interface such as the laboratory standard SiLA2²⁷ or the Open Platform Communications Unified Architecture (OPC UA) standard,²⁸ which is widely used in the industry.

Application Example

In the following, we demonstrate the described process automation through device interconnection using example applications from the field of drinking water analysis, in particular Legionella screening. These examples serve to illustrate the system design. Detailed results of the application studies will be presented in further publications.

The monitoring of Legionella cultures has to be performed, according to DIN EN ISO 11731.¹⁸ All work steps are usually carried out manually by laboratory staff in a shift work schedule. The screening process described in the Materials and Methods section illustrates the high number of optical analysis and sample transport steps during the investigation period. These are, in accordance with a workflow analysis in a medium-sized routine laboratory, the most time-consuming steps. Therefore, the automated process line at the current stage of development is equipped to perform these optical analyses in the Legionella screening workflow.

Figure 2 shows the entire construction with the robotic PetriJet platform (pos. 1) on top of a storage unit (pos. 3). This storage area disposes of the previously described track-based transportation rails (pos. 4). In this particular setup, the rails have two functions: to enable the transport of Petri dish magazines (pos. 6) and to store the magazines in the manner of flow rack storage. The storage space can hold up to 50 magazines, with a maximum of 20 plates per stack (∑1000 plates). For the presentation of the optical analysis in Legionella screening, we have equipped the PetriJet platform with only one camera (pos. 2.2) as a processing station.

The process described below is shown in the flowchart in Figure 6 . To run the analysis, the user loads the storage area ( Fig. 2 , pos. 3) with previously inoculated and incubated Petri dish magazines. A slide is mounted on the underside of each magazine (pos. 6), making it movable on the transport rails (pos. 4). The AGV robot (pos. 5) drives inside the rail system to the desired magazine and detects the attached label via a scanning engine. If the stack ID matches, the AGV transports the cargo in the way described above. To reach the level of the robotic platform, the AGV uses an elevator unit (pos. 3.1), which also carries the same transportation rail system. Inside the robotic platform, the AGV pulls the cargo slide to the single-plate transfer position (pos. 2.1). Here, either one of two grippers (pos. 1.1) moves every single dish to the camera process station (pos. 2.2). Following the image acquisition, the detected colonies are counted, and the dish is categorized in one of three stacks: no growth, growth, and uncertain. In particular, plates classified as uncertain must be subjected to a follow-up inspection by a trained laboratory technician. Currently, the detection of colonies does not run stably, especially with membrane-filtered samples due to the colored grid pattern. For this reason, no reliable results can be presented here. For a robust process, the algorithm must be adapted or revised, possibly with the help of external partners. When a magazine is filled with already processed Petri dishes, the AGV transports the slide back into the storage space. To reach a particular stack that is not at the rail boundary on the elevator side, the AGV must perform a rearrangement. After the analysis, the user puts the magazines back into the incubator or the autoclave for decontamination. The description shows that the platform currently just processes some small but high-value-added substeps of the entire workflow defined in the standard.

Figure 6.

Process flowchart optical analysis for Legionella spp. Blue boxes: Automatic process steps; green boxes: manual process steps; light gray box: sample processing module (possibly extendible by other processing modules). Arrows in blue boxes represent transport steps. Illustrated case represents the automatic image analysis process: The user inserts stacked culture plates in the storage area; after process start, availability of all resources is checked by the system; transport of the culture plate stack from the storage area to the PetriJet platform via a rail system; transport of single plates from stack to camera via grippers; image acquisition; colony count; protocol setting with colony count and metadata; transport of a plate via gripper into a positive stack (Legionella detected) or negative stack (plate without Legionella); transport of a stack via a rail system into a storage space; and take a new stack and repeat the process, if required.

The results shown in Table 3 illustrate a still-existing advantage in total processing time when the analysis is performed manually compared to the automated setup. The focus of this automation concept was never on increasing the processing speed, however, but on autonomous process control and thus decoupling the analytical process flow from the schedule of the human operator. Hence, by extending the functionality of the process line with additional devices, such as an incubator or a gadget for culture streak, the system can provide considerable walkaway time while running the process in its optimal parameters.

Table 3.

Comparison of Time Consumption in Optical Analyses of Legionella Samples.

Parameter	Automated Processing Time for 1 Stack (= 20 Plates) (s)	Manual Processing Time for 20 Plates (s)
Preprocessing
Culture stack provision (transport from incubator to system or bench)	30	30
Initialization and resource check	250	—
Processing
Transport stack from storage area to PetriJet	40	—
Transport plate to camera	15 per plate	3 per plate
Image acquisition	5 per plate	—
Colony count	5 per plate	Up to 20 per plate
Transport plate to stack	15 per plate	3 per plate
Transport stack from PetriJet to storage area	40	—
Total processing time per stack	880	520
Postprocessing
Unloading culture stacks and transport to incubator or autoclave	30	30

There were no problems with contamination or nonsterility during the entire test procedure, because the device never came into contact with the actual sample during the automated optical analysis. Furthermore, even culture streaks and sample concentrations in analytical laboratories for drinking and process water are usually carried out under nonsterile conditions anyway.

Another analysis that the platform can theoretically perform under the current setup without hardware changes is screening for HPC, which is the total number of growing microorganisms. The protocol is defined in DIN EN ISO 6222.²⁹ The workflow is quite similar to the Legionella testing, but here the sample and the nutrient media are mixed as a pour plate, and the media have no selective effect. Since all (under the given circumstances) cultivable microorganisms are growing during the incubation period, the image analysis of the plate pattern becomes more complex and error prone due to the differences in color, shape, size, and structure. Since image analysis has already caused problems with Legionella screening, no HPC process has run on the platform yet.

Conclusion

Processes in the field of microbial testing of drinking and process water are still hardly automated and depend heavily on manually performed operations, although the small fluctuations and high sample numbers suggest a true need for automation. Due to structures and workflows that have been established throughout decades and the lack of trained personnel in the particular companies, a radical change to a higher degree of automation in the manner of a TLA is not going to happen soon. A more promising approach is a gradual one, in which automation starts with small and easy-to-handle process steps to slowly adapt to the changes in an automated environment. For a later extension of the process in terms of functionality, speed, or capacity, the system must be flexibly adaptable.

Here, we presented a system for the generation of such flexible process lines by connecting several devices that are either located close to each other or distributed over the entire laboratory space. With this approach, we built a robotic platform as well as a track-based transportation system to partially automate the Legionella screening process in drinking water analysis. This system provides the opportunity to enlarge the automated process line step by step by including new devices at different spatial positions. Critical subprocesses can thus be parallelized to avoid bottlenecks and downtimes. A further expansion of the track system turns out to be fairly easy and cheap, since the rails are simple to construct and made of standard components.

Initial test runs with an automated process line for the optical analysis of Legionella samples showed that manual handling is still significantly faster than the automated system. Increasing the processing speed is not the purpose of the system, but the autonomous execution of a process and the logging of the results. The system is still in the conceptual stage, however, and requires a certain redesign in hardware and software to be robustly deployed outside of an academic environment. This mainly concerns the still-existing unreliable results in the colony count. After the current colony detection problems are solved, a manuscript with more comprehensive data and results will be published. Another important step will be the restructuring of the high-level communication interfaces to an already used standard such as SiLA2, which simplifies the installation of the system in an already existing infrastructure or the fast insertion of new devices into the process line.

In the longer term, we are going to further use the transportation system to create autonomously working process lines for microbial testing of drinking water, especially to expand the functions of the Legionella screening workflow by integrating new devices for culture streak or incubation. By increasing the level of automation, it will then be possible to carry out the entire screening process largely without human support.

Footnotes

Abbreviations

AGV, Automated guided vehicle; CFU, colony-forming unit; c_r, common range; dp, design parameter; F_f, functional flexibility; F_i, instrument feeding flexibility; F_l, liquid-handling flexibility; FL, field level; fr, functional requirement; F_s, structural flexibility; F_t, transport flexibility; F_total, total flexibility; F_v, throughput flexibility; GUI, graphical user interface; HI, human interface; HL, high level; HPC, heterotrophic plate count; IL, instrument level; LL, low level; MQTT, Message Queuing Telemetry Transport; OPC UA, Open Platform Communications Unified Architecture; p, probability-of-success function; PL, process level; SiLA, Standardization in Laboratory Automation; s_r, system range; TLA, total lab automation; UL, user level

Declaration of Conflicting Interests

The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The authors are grateful for the financial support of this work by The Free State of Saxony, State Ministry of Science and the Arts, grant number 100321036.

ORCID iD

Felix Lenk

References

Gensberger

E. T.

Gössl

E.-M.

Antonielli

; et al. Effect of Different Heterotrophic Plate Count Methods on the Estimation of the Composition of the Culturable Microbial Community. PeerJ 2015, 862, 1–14. https://peerj.com/articles/862/.

Trinkwasserverordnung in Der Fassung Der Bekanntmachung Vom 10. März 2016 (BGBl. I S. 459), Die Zuletzt Durch Artikel 99 Der Verordnung Vom 19. Juni 2020 (BGBl. I S. 1328) Geändert Worden Ist [Drinking Water Ordinance in the Version of the Announcement of 10 March 2016 (BGBl. I p. 459), Last Amended by Article 99 of the Ordinance of 19 June 2020 (BGBl. I p. 1328)]; 2020.

Analysen- Und Labortechnik, Schlüssel Zur Sicherheit von Trinkwasser Und Anderen Lebensmitteln [Analytical and Laboratory Techniques, Key to the Safety of Drinking Water and Other Foodstuffs]; SPECTARIS – Deutscher Industrieverband für Optik, Photonik, Analysen- und Medizintechnik: Berlin and München, 2020.

Tallon

Magajna

Lofranco

Microbial Indicators of Faecal Contamination in Water: A Current Perspective. Water Air Soil Pollut. 2005, 166, 139–166.

Bartram

Chartier

Lee

J. V.

; et al. Legionella and the Prevention of Legionellosis; World Health Organization: Geneva, 2007.

Uhl

Schaule

Establishment of HPC(R2A) for Regrowth Control in Non-Chlorinated Distribution Systems. Int. J. Food Microbiol. 2004, 92, 317–325.

Umwelt—Öffentliche Wasserversorgung Und Öffentliche Abwasserentsorgung [Environment—Public Water Supply and Public Sanitation]; Technical Series 19; German Federal Statistical Office: Wiesbaden, 2018; p 30.

Bericht des Bundesministeriums für Gesundheit und des Umweltbundesamtes an die Verbraucherinnen und Verbraucher über die Qualität von Wasser für den menschlichen Gebrauch (Trinkwasser) in Deutschland (2014–2016) [Report of the Federal Ministry of Health and the Federal Environment Agency to Consumers on the Quality of Water for Human Consumption (Drinking Water) in Germany (2014–2016)]; Federal Ministry of Health, Federal Environment Agency: Dessau-Roßlau, 2018.

Bonot

Varin

Une Solution Performante Pour Les Dénombrements En Temps Réel Des Colonies Sur Membranes Dans l’Analyse Microbiologique [High-Performance Solution for Real-Time Colony Counts on Filtration Membranes in Microbiological Analysis with ScanStation]. La Vaque 2020, 67, 46–51.

10.

International Organization for Standardization (ISO). General Requirements for the Competence of Testing and Calibration Laboratories; DIN EN ISO 17025:2018-03; ISO: Geneva, 2018.

11.

Kimler

Daly

The Stepwise Approach to “Flexible Automation.”

JALA 1998, 3, 1–4.

12.

Hedberg

Jönsson

Designing Semiconfusing Information Systems for Changing Organizations. SIGMIS Database 1982, 13, 12–25.

13.

de Groote

The Flexibility of Production Processes: A General Framework. Management Sci. 1994, 40, 933–945.

14.

Najmabadi

Goldenberg

A. A.

Emili

Hardware Flexibility of Laboratory Automation Systems: Analysis and New Flexible Automation Architectures. Clin. Lab. Med. 2007, 27, 1–28.

15.

Nelson

K. M.

Ghods

Measuring Technology Flexibility. Eur. J. Inf. Syst. 1998, 7, 232–240.

16.

Suh

N. P.

Axiomatic Design Theory for Systems. Res. Eng. Des. 1998, 189–209.

17.

Suh

N. P.

Axiomatic Design of Mechanical Systems. ASME 1995, 2–10.

18.

International Organization for Standardization (ISO). Water Quality: Enumeration of Legionella; DIN EN ISO 11731:2019-03; ISO: Geneva, 2019.

19.

Huang

C.-C.

Kusiak

Modularity in Design of Products and Systems. IEEE 1998, 28, 66–77.

20.

Vogel

Boschke

Bley

; et al. PetriJet Platform Technology: An Automated Platform for Culture Dish Handling and Monitoring of the Contents. J. Lab. Autom. 2015, 20, 447–456.

21.

Lenk

Otto

Oberthür

Automatische Inspektion von Kulturschalen mit der PetriJet-Plattform: Benchtop-Automation [Automatic Inspection of Culture Dishes with the PetriJet Platform: Benchtop Automation]. BIOspektrum (Heidelb.) 2016, 22, 476–479.

22.

Azadeh

de Koster

M. B. M.

Roy

Robotized Warehouse Systems: Developments and Research Opportunities. SSRN J. 2017. doi:10.2139/ssrn.2977779.

23.

Labforward. LabOperator; 2021. https://www.laboperator.com.

24.

Hillar

G. C.

MQTT Essentials—A Lightweight IoT Protocol; Packt Publishing: Birmingham and Mumbai, 2017; pp 8–20.

25.

Light

R. A.

Mosquitto: Server and Client Implementation of the MQTT Protocol. JOSS 2017, 2, 265.

26.

Tsai

M.-F.

Pham

T.-N.

Ching

F.-H.

; et al. An Adaptive Solution for Images Streaming in Vehicle Networks Using MQTT Protocol. In IoT as a Service; Lin

Y.-B.

Deng

D.-J.

You

; et al., Eds.; Springer International: Cham, 2018; pp 263–275.

27.

Bär

Hochstrasser

Papenfuß

SiLA: Basic Standards for Rapid Integration in Laboratory Automation. J. Lab. Autom. 2012, 17, 86–95.

28.

Gauglitz

Lab 4.0: SiLA or OPC UA. Anal. Bioanal. Chem. 2018, 410, 5093–5094.

29.

International Organization for Standardization (ISO). Water Quality: Enumeration of Culturable Micro-Organisms—Colony Count by Inoculation in a Nutrient Agar Medium; DIN EN ISO 6222:1999; ISO: Geneva, 1999.