Labforward, SiLA and LADS Collaborating to Enable Plug-and-Play Solutions, Break Implementation Barriers, and Craft Future-Proof Lab Automation Strategies

Related Vendor

KNF Neuberger GmbH - Business Unit LAB

We explore the significance of device connectivity as the fundamental element in implementing lab automation strategies and future-proofing laboratory operations. Through expert perspectives, we explain how device connectivity standards, such as LADS and SiLA, unify device driver development, improve data management, and promote efficient and effective lab execution workflows.

When thinking of a fully automated laboratory, one imagines a place where the work of experimentalists is executed mainly through robotics, data is analyzed automatically by AI algorithms, scientists spend their time designing novel experiments and interpreting results rather than being the workhorse behind repetitive tasks, and results are attained faster with more accuracy and precision. This vision is attractive but stands in stark contrast to the current state of most laboratories, where the majority of processes are still performed manually and documented by pen and paper. While there are many reasons for this status quo (such as insufficient resources, difficulties with change management, and inadequate digital literacy), one of the most critical roadblocks is the lack of overarching connectivity between laboratory devices.

Connectivity is the first step and fundamental basis for automation and describes the ability of devices to exchange data with each other. Historically, this was approached by using a variety of different programs and protocols, such that each device effectively uses a different language to communicate its data. As a result, the connectivity of laboratory devices is often poor: while the device has an interface to communicate with the user, the unique protocol with which that interface was designed makes it extremely challenging to develop an all-encompassing automation software guaranteed to work with every device. This forces humans, whether we realize it or not, to serve as the translator between one device and the next, in any given laboratory protocol.

Gallery

For example, let’s imagine a scientist preparing various DNA samples to pool into a library for sequencing. They use a plate reader to measure the concentrations of various DNA samples, retrieve those concentrations from the plate reader’s software, and paste them into an Excel spreadsheet. They use the table of concentrations to calculate the required dilution of each DNA sample. They then transfer those calculations to a specific format, executable by a liquid handler.

Overall, this process takes about a half hour to complete. At first glance, this may not seem overly problematic, but if this process is completed once per week for a year, suddenly the scientist has spent 26 hours just transferring data back and forth from the plate reader to the liquid handler. This is all effectively because the plate reader and the liquid handler don’t speak the same language. If this calculation is expanded across all members of a lab, and all equipment in a lab, suddenly the need for a standardized language between laboratory instruments becomes obvious: without consistently formatted and communicated data, complex automation strategies fail and humans continue repeating trivial tasks (s. Fig. 2).

To overcome these challenges, LADS, SiLA, and Laboperator, by Labforward, play key roles in standardizing the language between instruments and providing device connectivity, therefore enabling automation strategies. In this article, we outline the current initiatives for device connectivity standards and explain a path forward for lab automation.

Device Connectivity Standards

Each laboratory is a specialized environment filled with a unique and complex set of devices, configured in a set-up that specifically suits the experimental needs of that laboratory. Because of this, laboratories utilize instruments from a wide variety of models and vendors. Along with this device diversity, comes an equally large variety of data outputs and formats. In part due to this diversity, there has been little to no standardization historically across manufacturers regarding the programming of device interfaces or guidelines for how data outputs are formatted.

Often, each manufacturer develops its own protocol for their devices’ interfaces. In some cases, interfaces are not even standardized among device models within the same manufacturer. The consequences of this could be, for example, if an institute has two HPLC devices from different vendors that they want to include in an automation strategy, the devices would likely not be interoperable, hindering the automation strategy. Even if the institute had many devices from the same manufacturer, there is no guarantee that these devices would be interoperable or easily connected through an automation strategy. Additionally, this lack of consistency can lead to flawed data integrity and compliance issues.

The Language of Device Connectivity

Using the analogy of laboratory devices speaking different languages to communicate their data, the overall goal of interoperability standards is to coalesce all “device languages” into one. To accomplish this, an approach implementers of interoperability standards — like Dr. Matthias Arnold (LADS) and Dr. Tim Meyer (SiLA) — use, is to model devices and their data into generic or principal features, to guarantee interoperability. Any client that wants to use these features, can “discover” them, thanks to the self-documenting nature at the core of both standards.

For example, let’s break down a very common laboratory instrument: a PCR cycler. In principle, the role of a PCR cycler is to regulate temperatures in a cyclical user-defined program. This role is contingent upon two main abilities: the device monitors temperature and time. In other words, the essence of this device could be captured by two modules with which the user interfaces: a time module and a temperature module. Thinking more broadly, many laboratory devices contain temperature modules: Water baths, heating blocks, refrigerators, freezers, incubators, and so on. Thus, these modules underlie commonalities between devices, and these commonalities can be used as the nouns and verbs of the “device language”. The overall goal of LADS and SiLA is the same, however, they differ in technology and approach. LADS leverages OPC-UA and its module definitions while SiLA 2 uses gRPC.

Back to the language analogy, besides nouns and verbs, the “device language” still requires contextual information about how the nouns and verbs relate to each other (i.e. the ontology). For instance, the contextual relationship between time and temperature is different for a PCR cycler than it is for a cell culture incubator. In the language of device interoperability standards, this ontological information is described by standardization schemas like AnIML and Allotrope.

Laboperator's Pragmatic Approach to Device Connectivity

To contextualize this theoretical information as to its importance in lab automation, let’s take Laboperator, a laboratory execution system (LES) that automates data capture and transfer from laboratory devices and orchestrates digital workflows, and apply it to our previous example of transferring data from a plate reader to a liquid handler. Laboperator’s application programming interface (API) receives data from the plate reader, but in order for Laboperator to make use of the data, it must first be characterized and contextualized. If the plate reader adheres to an interoperability standard, this information would be clearly encoded in the device’s driver and would be accessible and utilizable to the Laboperator API as soon as a connection is established between the device and the software (hence the term “plug-and-play”). If the plate reader does not adhere to an interoperability standard, the story becomes a bit more complicated.

One benefit of using Laboperator as a digitalization platform, is its vendor-agnostic approach to device connectivity, meaning it can provide connectivity to any device, regardless of age, make, or model. However, productive use of the device on Laboperator’s interface depends on the functionality of the device’s driver, which is developed internally by Labforward. If the device is not LADS or SiLA compatible, Laboperator’s connectivity team must develop a custom device driver in order to ensure the desired data is being received in the correct format, handled accordingly (i.e. conversions or calculations may take place), and transferred. One drawback to such a tailor-made device driver is that if the device receives an update that modifies its communication interface, then the corresponding Laboperator driver must also undergo development to implement those changes. If the device is LADS or SiLA2 compatible, productive use of the driver can be established rapidly and in a straightforward manner: Laboperator’s connectivity team provides a LADS- or SiLA-compatible client driver that can connect to any LADS/SiLA device, allowing communication between the device and the Laboperator application. With LADS- or SiLA-compatible devices, communication interface updates are a non-issue, as any changes made during the update will automatically be reflected in the client driver. In conclusion, interoperability standards (regardless of LADS or SiLA) are extremely valuable in that they greatly support Laboperator’s mission, and reduce integration time from days or even weeks to hours. Overall, this accelerates the delivery of automation solutions to customers at reduced expense (s. Fig. 3).

Conclusion and Outlook

Despite these benefits, a common challenge still faced by Laboperator and standardization organizations in integrating diverse laboratory devices into unified systems, is that there is no strong driving force requiring device manufacturers to adhere to either standard. Both Dr. Arnold and Dr. Meyer expressed similar sentiments, and urge laboratory users to press device manufacturers to adopt interoperability standards. Furthermore, software platforms for device orchestration, like Laboperator, will only gain more importance as these platforms are also necessary to enable AI/ML algorithms and semantic data linking. Overall, Laboperator, SiLA, and LADS work together to serve as powerful enablers of plug-and-play solutions, remove implementation barriers, and deliver future-proof lab automation strategies for laboratories worldwide.

(ID:49720378)