Abstract
National Instruments LabVIEW is a graphical programming language that has its roots in automation control and data acquisition. Its graphical representation, similar to a process flow diagram, was created to provide an intuitive programming environment for scientists and engineers. The language has matured over the last 20 years to become a general purpose programming environment. LabVIEW has several key features which make it a good choice in an automation environment. These include simple network communication, turnkey implementation of common communication protocols (RS232, GPIB, etc.), powerful toolsets for process control and data fitting, fast and easy user interface construction, and an efficient code execution environment. We discuss the merits of the language and provide an example application suite written in-house which is used in integrating and controlling automation platforms.
Keywords
Introduction
Cytokinetics is a biopharmaceutical company focused on the discovery of small molecule therapeutics that target the cytoskeleton. Since inception we have developed a robust technology infrastructure to support our drug discovery efforts. The infrastructure provides capacity to screen millions of compounds per year in tests ranging from multiprotein biochemical assays that mimic biological function to automated image-based cellular assays with phenotypic readouts. The requirements for processing these numbers and diversity of assays have mandated deployment of multiple integrated automation systems. For example, we have several platforms for biochemical screening, systems for live cell processing, automated microscopy systems, and an automated compound storage and retrieval system. Each in-house integrated system is designed around a robotic arm and contains an optimal set of plate-processing peripherals (such as pipetting devices, plate readers, and carousels) depending on its intended range of use. To create the most flexible, high performance, and cost-effective systems, we have taken the approach of building our own systems in-house. This has given us the ability to integrate the most appropriate hardware and software solutions regardless of whether they are purchased from a vendor or engineered de novo, and hence we can rapidly modify systems as assay requirements change.
To maximize platform consistency and modularity, each of our 10 automated platforms is controlled by a common, distributed application suite that we developed using National Instruments (NI) LabVIEW. This application suite described in detail below, enables our end users to create and manage their own process models (assay scripts) in a common modeling environment, to use these process models on any automation system with the required devices, and allows easy and rapid device reconfiguration. The platform is supported by a central Oracle database and can run either statically or dynamically scheduled processes.
Ni Labview background
LabVIEW, which stands for Laboratory Virtual Instrumentation Engineering Workbench is a graphical programming language first released in 1986 by National Instruments (Austin, TX). LabVIEW implements a dataflow paradigm in which the code is not written, but rather drawn or represented graphically similar to a flowchart diagram (Figure 1). 1 Program execution follows connector wires linking processing nodes together. Each function or routine is stored as a virtual instrument (VI) having three main components: the front panel which is essentially a form containing inputs and controls and can be displayed at run time, a block diagram where the code is edited and represented graphically, and a connector pane which serves as an interface to the VI when it is imbedded as a sub-VI. Figure 1a shows the front panel of an example VI and Figure 1b the block diagram or the code for the VI. In Figure 1b, VIs such as Mean.vi, Median Filter.vi, and Write to Spreadsheet File.vi are being used as sub-Vis.
Example NI LabVIEW VI. The top panel (A) shows the front panel of the VI. Input data are passed through “Controls” which are shown to the left. Included here are number inputs, a file path box, and a general error propagation cluster. When the VI runs, the “Indicator” outputs on the right of the panel are populated with output data. In this example, data include numbers (both as scalar and array), a graph, and the output of the error cluster. In the bottom panel (B) the block diagram for the VI is shown. Data propagate from left to right and start with color-coded representations of the input variables from the front panel Controls. The outer case structure executes in the “No Error” case (VIs can make internal errors or if called as a sub-VI the caller may propagate an error through the connector pane). Within the For Loop random numbers are generated and added to an array that is averaged, has a median fitter of rank 2 (VI default) applied, plotted, and written out to a delimited text file.
Unlike most programming languages, LabVIEW compiles code as it is created thereby providing immediate syntactic and semantic feedback and reducing the time required for development and testing. 2 Writing code is as simple as dragging and dropping functions or VIs from a functions palette onto the block diagram within process structures (such as For Loops, or Case Structures) and wiring terminals (passing input values, or references). Unit testing is simplified because each function is separately encapsulated; input values can be set directly on the front panel without having to test the containing module or create a separate test harness. Memory allocation/deallocation is automatically managed by LabVIEW. 3,4
The functions that generate data take care of managing the storage for the data. Associated memory is automatically deallocated if the data are no longer being used. In Figure 1b, the For Loop generates an array of random numbers with no explicit memory allocation step. The array is passed as input to each of the sub-VIs that manage memory independently. When passing data to a sub-VI, LabVIEW uses pass-by-value semantics with pass-by-reference implementation. There are also functions in LabVIEW that allow developers to manage memory explicitly.
NI LabVIEW supports multithreaded application design and executes code in an inherently parallel rather than sequential manner; as soon as a function or sub-VI receives all of its required inputs, it can begin execution. In Figure 1b, all the sub-VIs receive the array input simultaneously as soon as the For Loop is complete, and thus they execute in parallel. This is unique from a typical text-based environment where the control flows line by line within a function. When sequential execution is required, control flow can be enforced by use of structures such as Sequences, Events, or by chaining sub-VIs where output data from one VI is passed to the input of the next VI.
Similar to most programming languages, LabVIEW supports all common data types such as integers, floats, strings, and clusters (structures) and can readily interface with external libraries, ActiveX components, and .NET framework. As shown in Figure 1b, each data type is graphically represented by wires of different colors and thickness. LabVIEW also supports common configuration management applications such as Visual SourceSafe making multideveloper projects reasonable to manage. Applications may be compiled as executables or as Dynamic Link Libraries (DLLs) that execute using a run-time engine similar to the Java Runtime Environment. The development environment provides a variety of debugging tools such as break-points, probes (trace), and single-step. Applications can be developed using a variety of design patterns such as Client-Server, Consumer-Producer, and State-Machine. There are also UML (Unified Modeling Language) 5 modeling tools that allow automated generation of code from UML diagrams and state diagrams. 6 The GOOP toolkit 7 (Endevo, Stockholm, Sweden) enables full object oriented programming support for LabVIEW, including inheritance.
Over the years, LabVIEW has matured into a general purpose programming language with a wider user base. There are open source communities such as the OpenG.org that promote and share code development for LabVIEW and user forums such as LAVA (LabVIEW Advanced Virtual Architects) 8 with local chapters that organize seminars and training sessions on LabVIEW. The LabVIEW developer zone on the NI website is also a useful online resource to interact with the LabVIEW community.
Ni labview as a platform for automation and instrumentation
Our experience creating benchtop instrumentation and integrated automation systems has validated our choice of LabVIEW as an appropriate tool.
LabVIEW enables rapid development of functionally rich applications appropriate for both benchtop applications and larger integrated systems. On many occasions we have found that project requirements are initially ill defined or change as new measurements or new assays are developed. In any case, it is important to provide end users with early prototypes during development cycles so that they can acquire initial data, but build prototypes that can be easily and rapidly retooled. There are several key features of the language that make it particularly useful in an automation environment for creating applications to control and integrate instrumentation, manage process flow, and enable data acquisition.
Turnkey Measurement and Control Function
LabVIEW was originally developed for scientists and engineers and now benefits from a broad library of VIs to interface data acquisition hardware from a variety of vendors. 9,10 The language includes a rich set of process control and data analysis functions as well as COM, .NET, and shared DLL support. Out of the box, it provides turnkey solutions to a variety of communication protocols including RS232, GPIB, and TCP/IP. Control structures such as timed While Loops allow synchronized and timed data acquisition from a variety of hardware interfaces such as PCI, 11 USB, and PXI 12 .
DataSocket and VI Server
Deployment of an integrated system with multiple control computers requires the automation control application to communicate remotely with instrument drivers existing on remote computers. LabVIEW supports a distributed architecture by virtue of enabling seamless network communication through technologies such as VI Server and DSTP (data sockets transfer protocol). DSTP is an application layer protocol similar to http based on Transmission Control Protocol/Internet Protocol (TCP/IP). 13 Data sockets allow easy transfer of data between remote computers with basic read and write functions. Through VI server technology, function calls can be made to VIs residing on remote computers as though they are residing on the local computer. Both Datasockets and VI server can be configured to control accesses privileges.
Wide Range of Toolsets
NI and many third-party vendors provide a variety of LabVIEW toolsets for advanced data acquisition, data analysis, system control (PID, fuzzy logic, system design, IMAQ-Image Analysis), database connectivity, etc. Each of these toolsets/libraries provides advanced functions that can be easily incorporated into applications. 14 Users can also build and deploy toolsets. Built-in control structures such as Math-Script allow embedding Matlab (Mathworks, Natick, MA) scripts within LabVIEW code for complex mathematical analysis. LabVIEW also provides functions to embed text-based code into the block diagram. NI provides the personal digital assistant (PDA) module extension for LabVIEW that allows applications to be developed and deployed onto PDAs for remote monitoring and control. 15 LabVIEW provides tools such as the Real-Time Module and the field-programmable gate array Module to develop deterministic applications that can be run stand-alone, in a distributed fashion, or downloaded to a dedicated target to run independently. 16
Simple User Interface (UI) Implementation
In addition to common interface controls such as text boxes, menu rings, and check-boxes, LabVIEW provides a rich set of UI controls (switches, LEDs, gauges, array controls, etc.) that are pertinent to laboratory equipment. These have their origins in LabVIEWs laboratory roots and help in development of interfaces which give scientists a clear understanding of a system's state. LabVIEW supports UI concepts including subpanels (similar to the Multiple Document Interface) 17 , splitter bars, and XControls 18 (analogous to OCX controls) 19 .
Multithreaded Programming Environment
The inherent parallel environment of LabVIEW is extremely useful in the control of laboratory equipment. 20 Functions can have multiple continuous While Loops where one loop is acquiring data rapidly and the other loop processes the data at a much slower rate. Implementing such a paradigm in other languages requires triggering an independent function thread for each process and developing logic to manage synchronization. Through timed While Loops, multiple independent While Loops can be easily synchronized to process at a desired period and phase relative to one another. LabVIEW allows invoking multiple instances of the same function with each maintaining its own data space. For instance, we could drag many instances of the Mean sub-VI onto the block diagram in Figure 1b and they would all run in parallel, independent of one another. To synchronize or enforce control flow within the dataflow environment, LabVIEW also provides functions such as queues, semaphores, and notification functions.
Ni labview application example: The open system control architecture (oscar)
OSCAR is a LabVIEW-based (v7.1) automation integration framework and task execution engine designed and implemented at Cytokinetics to support application development for systems requiring robotic task management. OSCAR is organized around a centralized Oracle database which stores all instrumentation configuration information used to logically group devices together to create integrated systems (Figure 2). The database also maintains Process Model information from which tasks and parameters required to run a particular process on a system can be generated and stored to the database. When a job is started, task order and parameter data are polled by the Execution Engine which marshals tasks to each device and updates task status in the database in real time. Maintaining and persisting task information for each system has two clear benefits. It allows easy job recovery in the event of a system error, and it also provides a process audit trail that can be useful for quality management and for troubleshooting process errors or problems.
OSCAR component diagram. Each OSCAR component is distributed across the company intranet and communicates with a central database. Collections of physical devices controlled through OSCAR Instrument packages (OIP) make up systems. Users interact with systems through one of the several applications built on OSCAR. We have deployed CytoSCREEN, an application for controlling systems that run statically scheduled process models on screening systems, two applications that dynamically control integrated imaging systems, and a dynamically scheduled compound storage and retrieval system. Each application calls the RTM which marshals tasks from the database to each OIP. OSCAR has sets of tools for managing system configurations, creating Process Models, monitoring running processes, recovering error-state systems, and managing plate inventory in storage devices.
OSCAR uses a loosely coupled distributed component architecture, enabled in large part by LabVIEWs DSTP and remote VI technologies that allow system control to be extended beyond the confines of the traditional central control CPU model. Any networked computer or device can be integrated and controlled in an OSCAR system regardless of its physical location. This removes the proximity constraints of traditional integrated systemsand allows for the utilization of remote data crunchers, devices, or even systems. The messaging paradigm used shares many similarities with current Service Oriented Architectures or Enterprise Service Bus implementations without a lot of required programming overhead or middleware; a centralized server is not required to direct the XML packets across the network. An additional benefit to this loosely coupled architecture is the flexibility in front-end application design. OSCAR encapsulates and manages all functionality related to task execution and device control, which frees the developer to focus on the unique requirements of a given application. For example, an application being created for the purpose of compound storage and retrieval can be limited in scope to requirements such as inventory management and LIMS integration rather than device control, resource allocation, and task synchronization.
The OSCAR integration framework consists of multiple components that enable device and system configuration, process modeling, process execution, and process monitoring. Below are descriptions of key components of the framework.
Integration Platform
The Oscar Instrument Package (OIP) is the low level control component responsible for communicating with individual devices. It can support any number of devices on a system (including multiple independent instances of the same type of device) and communicates to the Runtime Manager (RTM) via serialized XML strings over DSTP. This allows the device controller and RTM components to exist on separate networked computers if necessary. Additionally, the OIP controller communicates with a device instance via LabVIEW remote VI calls which provide a lower level of distribution and allow the device drivers to exist on a separate networked computer from the controller. At Cytokinetics, we currently support approximately 100 device instances of 30 device types which are distributed across 10 integrated systems.
System Management
An OSCAR system is a named collection of device instances which is logically represented in the database. The interface for each device (commands and parameters) is stored in the database along with the configuration settings for each device instance (i.e., COM port, capacity). The System Manager component provides the functionality to easily manipulate this information (given appropriate permissions). When a physical device is moved from one system to another, or a processing bottleneck alleviated by addition of another similar device, system configuration information is changed without affecting the processes that may be run on the system.
Process Modeling
A process model is the logical progression of a sequence of tasks. For example, a biochemical assay might include the following steps (1) remove plate from incubator, (2) move plate to pipettor, (3) add reagent, (4) move plate to fluorescent reader, (5) read plate, and (6) move plate to waste. The Process Modeler component allows the end user to choose functions associated with devices and organize them into a sequence of logical tasks. The resulting process model is then scheduled via a static schedule optimization algorithm or saved for dynamic execution (Fig. 3). 21 A process model is not associated with a physical system, but rather a required collection of devices. This has two important benefits: (1) the scientist is free to experiment with virtual system configurations to optimize the design of a future system or the reconfiguration of an existing system, and (2) any existing process model can be executed on any system equipped with the appropriate resources.
Example OSCAR applications. The top panel (A) shows the Process Schedule Modeler, an application that graphically displays statically scheduled processes. Each horizontal band represents a task group which is the collection of required tasks used bya process; tasks are color coded by device. The bottom panel (B) shows the UI from the Automated Imaging System application. The tree structure depicts the job hierarchy for an imaging run. Jobs (here AIS_Retrieval and AIS_Imaging) are composed of task groups. As the systems runs, the tasks in the task group are executed and their status is updated in the database.
Process Execution
Process execution occurs by invoking the OSCAR RTM. The RTM is capable of running multiple differing processes on a system at the same time allowing multiple job types to be run in parallel. Additional jobs can be added or reprioritized at any time through an OSCAR application. The RTM has an application programming interface (API) which allows external applications to invoke its functionality and consists of two main components, the Task Generator Module (TGM) and the Execution Engine. External applications invoke an instance of a Process Model through the TGM at which point a set of tasks and task parameters are populated in the OSCAR database. The Execution Engine continually monitors the database for valid tasks and if a valid task is found it is sent to the appropriate device via the OIP. The OSCAR system supports running these jobs in either a static or dynamic mode. For processes which must meet strict time constraints (often due to assay requirements), or require the availability of a given resource, a static schedule is calculated and stored for reuse. The system is capable of optimizing the schedule based on actual task operation times (stored in the database) which must be estimated initially. Other types of unconstrained processes benefit more from a dynamic mode of operation where events trigger the progress of task execution as resources become available in real-time. When operating dynamically, intelligent queuing of tasks among multiple jobs allows optimal use of resources minimizing execution time while allowing for robust error handling.
Process Monitoring
All systems and jobs can be monitored remotely by a distributed application known as the Process Monitor. This application allows multiple users to monitor active jobs across all systems for status and faults and provides email notification for fault situations.
System Recovery
All plate location and task status data are updated in the database in real-time making it simple to develop a robust system recovery tool using LabVIEW database connectivity libraries. In the event of an unrecoverable fault (one in which the controlling application or system must be shut down) the system can be recovered from the point of failure using the System Recovery Utility. Using this utility, the operator can also roll the system state backward or forward as required to allow failed tasks to be retried or manually completed. Once the system is in a stable state, the RTM is reactivated and the failed process or processes will continue from that point.
Conclusion
Cytokinetics has built and maintains an automation software infrastructure using NI LabVIEW. The language has proven to be a powerful tool to create both rapid prototype applications as well as an entire framework for system integration and process execution. LabVIEW's roots in measurement instrumentation and seamless network communication protocols have allowed systems to be deployed containing multiple control computers linked only via the network. The language continues to evolve and improve as a general purpose programming language and develop a broad user base.
Acknowledgments
The authors wish to thank Daniel Pierce, Eugeni Vaisberg, and Jeffrey Finer for helpful discussions and comments to the manuscript.