Tool Overview

Laboratory protocols often require careful and precise execution of numerous procedures to achieve desired results. However, slight inaccuracies and miscalculations attributable to human-error continually arise and often lead to invalid conclusions. For this reason, we have developed an accurate workflow that executes biological protocols in a more systematic manner. The solution we propose is the Puppeteer Biological Protocol Automation Suite. Our suite centers on the execution of Puppeteer, a high-level protocol specification language used to programmatically describe biological protocols; it is executed on a liquid-handling robot with minimal user intervention. PuppetShow allows users to create protocols locally, but will eventually incorporate a “Protocol Repository” that will retain version-controlled instances of uploaded protocols. This feature will promote all forms of collaboration within the synthetic biology community, with a predominant focus on inter-laboratory protocol sharing.

Puppeteer Assembly Flow

Our assembly flow incorporates a five-layer stack as illustrated in the adjacent figure. The Assembly Planner produces an assembly plan for synthetic biological devices, with each assembly step annotated with the name of a biological protocol. Each protocol may be fully specified using PuppetShow.

The protocols are written in the high-level language called Puppeteer. The Language layer includes a Puppeteer interpreter and linker. A protocol specified in Puppeteer may contain Puppeteer instructions as well as references to previously created Puppeteer programs available in the protocol repository. The Language layer expands and translates Puppeteer protocols to a sequence of low-level commands expressed in a Common Human Robot Instruction Set (CHRIS). Any high-level language may produce CHRIS programs and any robot vendor may support a superset of CHRIS. The Hardware Layer---the external control and I/O interface of a robot---is wrapped under a Hardware Abstraction Layer (HAL). Vendor-provided software for programming the robot may be proprietary and is used to control the robot. An interface to it is provided by a software bridge, which maps protocols expressed in CHRIS to sequences of native robot instructions.

The Resource Management layer maintains resource state information and provides a standardizable high-level interface for initializing, requesting, naming, aggregating, and accessing resources to the Language layer, analogous to a ``system call'' suite. This interface supports our goal of removing the minutiae of resource management from the protocol specification language.

Demo and Download

Downloads:

Demo Video

Results

In the wet lab, we have finished implementation of an initial version of the Puppeteer stack; it is fully integrated with the Clotho platform. We have implemented basic BioBricks assembly protocols and validated them in the wet lab by assembling basic devices. We implemented two protocols central to BioBricks assembly---Restriction Digestion and Ligation---in Puppeteer. We validated the Puppeteer implementation by executing multiple trials of both protocols and verifying the result by running a gel.

Collaboration with other iGEM teams: In order to ensure reproducibility and promote collaboration, we visited the Weiss lab at MIT to set up the Puppeteer stack on their robot. We met a few of MIT’s iGem team members and coordinated with them to test the Puppeteer flow on the MIT robot. During this process, we noticed some differences between our robot deck setups and the way this setup was handled in the Puppeteer flow. We separated such settings into an easily edited settings file to ensure that Puppeteer was easily configured for different deck setups. We successfully tested the Puppeteer flow on the MIT deck and everything ran as expected. This collaborative effort with MIT’s iGem team is definitely fruitful because it made Puppeteer more robust and ensured functionality across multiple robots.

Restriction Digest: For restriction digest we digested the plasmid containing the BioBrick BBa_J52028 in order to isolate the GFP. After cutting the plasmid with EcoRI and SpeI we ran it on a one percent gel along with a ladder in order to determine the amount of base pairs for each dna part. As GFP is about 1221 bp the location in which it is located on the gel is correct. Also the backbone was about 3189 bp which is also located in the correct location on the gel.

Ligation:

The images show the verification results.

Safety practices: Aliquam in felis sit amet eros pharetra volutpat.

Future Work

Sample History Viewer
- Samples currently represent any liquid-like substance used within the laboratory environment. With the current working database implementation, output sample (e.g., a restriction digested part) information is stored with associated history. This sample history comprises the individual samples that were utilized to create the output sample (i.e, the buffers and enzymes, etc.) as well as the associated protocols that were executed. This entire flow has been implemented but is missing a viewer component that will allow users to visually explore the different histories of samples within the database.
Protocol Graph Editor
- The concept of a protocol graphs focuses on an ideal and simplistic hierarchical representation of biological protocols. The graph itself is a directed bipartite graph composed of protocol nodes, sample nodes, and connection arcs. The bipartite label implies that protocol nodes can only connect to sample nodes and vice versa (sample nodes are input(s)/output(s) to/from protocol nodes). With such a representation, complex biological protocols can be translated into a (potentially large) but scalable and useful graphical representation.
- Avi Robinson-Mosher, a postdoctoral research under Pamela Silver at the Wyss Institute for Biologically Inspired Engineering at Harvard University, has shown interest in a protocol graph editor. We have collaborated over data structures and database organization regarding the implementation and storage of protocol graphs.
Integration with eLabNotebook
- The eLabNotebook application utilizes a protocol representation to display procedural steps for wetlab convenience. Ideally, a layer of communication will coexist between PuppetShow’s database features and the eLabNotebook’s central server configuration. Generated protocol graphs and associated reports will be stored on an identifiable server. The eLabNotebook will then pull and parse the information from the server to provide accurate, up-to-date information for the laboratory environment.
Integration with Trumpet
- Trumpet already generates reconfigurable constructs in the form of Clotho “composite parts”. This data model is already adaptable to the Puppeteer assembly flow, so it will be very feasible to execute protocols from Trumpet’s output. This feature can be implemented as soon as a standard for implementation is finalized.
Protocol optimizer project
- A potential project proposal involves the algorithmic assembly of protocols. This procedure would be completed on an abstract level, where a sophisticated evaluation of available resources is used to generate optimized protocols. The available resources would comprise samples within the database, both previously-created and newly-entered, that are paired up with protocols to provide efficient output creation. The ingenuity behind this application involves the usage of historical context, which is retained in the form of sample history within the database.

Team:BU Wellesley Software/Puppetshow

From 2011.igem.org

PuppetShow