Figure 1.
Encapsulation based synthetic biology design hierarchy.
Shown are the various layers of abstraction at which Eugene operates. DNA information forms the most basic unit on which everything else is built (e.g. the genetic code, as specified by bases G, A, T, and C). This is followed by Parts. Parts are non-reducible elements of genetic composition (e.g. promoters, ribosome binding sites, open reading frames, etc). Devices, which can contain one or more Parts, are the next level in the hierarchy. Finally, Devices are followed by a System view that contains collections of Devices. The traversal upward in the hierarchy represents an abstraction process while a downward traversal represents the refinement process. Eugene currently operates at the Part and Device levels via explicit Part and Device data types while encapsulating the DNA level as Eugene Properties.
Figure 2.
Eugene based synthetic biology design flow.
Shown here is the role that Specification, Design, Assembly, and Data can play in synthetic biology. In particular, we illustrate that Eugene is concerned with the activities at the specification level explicitly but at the same time it is designed in such a way that it develops designs that are amenable to other pieces of this design flow. Opportunities for the flow to provide feedback to earlier stages and perform iterative refinement are outlined in red.
Figure 3.
This paper is organized around three sections which reflect a Eugene design flow.
The Methods section provides an overview of how to use Eugene to create a Device using a T4 lysis Device from the MIT parts registry. The Results section illustrates design space exploration with a Cell Surface Display system from UC Berkeley's 2009 iGEM team. The Results section also details integration of Eugene with automated assembly in Clotho for a protein tagging system and simulation via SynBioSS for a repressilator design.
Table 1.
Eugene language elements overview.
Figure 4.
We illustrate both visually (SBOL visual; http://www.sbolstandard.org) and textually (Eugene code) an example Device (BBa_K112809) from the MIT registry of standardized parts.
Key to notice is the fact that the three included header files encapsulate much of the design effort leaving a single line to produce the composite Device.
Figure 5.
Illustration of the “cell surface display” Device case study.
Here are shown the three Part types (passengers, spaces, and displayers) which when combined into a Device made up the systems that we explored. As shown the displayer interacts with the outer membrane of the bacterial cell to display the passenger protein extracellularly. Table 2 in file Appendix S1 provides more information on this system.
Figure 6.
Device exploration and pruning capabilities with Eugene.
This graph shows how the number of Devices created with Eugene can change with the addition of rule statements. The change in many cases can be quite dramatic with relatively few lines of code (new rules). For example with just two lines of code the initial design space explodes from two devices to 540. Then with 13 additional lines, it drops to 135 Devices. Finally, a design space of three Devices can be achieved by a total addition of 28 lines of code while still maintaining the original information to specify 540 Devices.
Figure 7.
A heat map depicting the functionality of the cell surface display Devices, where the white constructs had the highest signal of functionality.
This data was used to determine which Devices could be considered functional and which were not. This analysis helped to drive the development of the Eugene code. The overlaid annotations reflect a reduced heat map. This shows how Devices can be removed with the targeted application of Eugene rules. The entire design space of 90 Devices is a reduction from the original heat map's 135 Devices. Each area is labeled with the rules that affect the creation of these Devices. Rules 1-4 deal with the removal of Devices while Rules 5–6 preserve the final three highly active Devices. The x-axis is displayer domain parts and the y-axis is protein/spacer combinations.
Figure 8.
Illustration of an automated assembly flow beginning with a Eugene file for a protein tagging (PT) Device with nTag and cTag Parts.
This shows the eight Parts that make up the Device and the order in which the Parts must be assembled to have a functional Device. In the Eugene import process, the Devices of interest are captured with Eugene and processed by a Clotho App (e.g. Spectacles). Later the Device construction is planned for a specific assembly protocol with the creation of an assembly graph. In the final phase, the files for a liquid handling robot are created and fed to the platform doing the assembly.
Figure 9.
High-level diagram of a repressilator as well as its Eugene implementation.
Here the relationship between LacI, TetR, and AraC and the promoters in the system is shown. This design was chosen since its behavior is well understood and can be easily decomposed into the individual Parts that make up the Device. The SynBioSS design flow with Eugene is also shown. Beginning with the Eugene XML produced by the Eugene interpreter, SimpleXML creates an array which holds the data from Eugene. After a reorganization process the data can now be transformed by SynBioSS into a reaction network in SBML or NetCDF which can then be simulated. Sample of the reaction network generated by SynBioSS Designer is also provided. These reactions describe the unregulated expression of TetR, as well as its dimerization and degradation. All rate laws are elementary and all kinetic data is in SI units unless otherwise noted. Asterisks indicate gamma-distributed reactions.