Difference between revisions of "Team:UNebraska-Lincoln/Integrated Practices 3"

 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
<!DOCTYPE HTML>
 
<!--
 
Solid State by HTML5 UP
 
html5up.net | @ajlkn
 
Free for personal and commercial use under the CCA 3.0 license (html5up.net/license)
 
-->
 
 
<html>
 
<html>
<head>
+
<link rel="stylesheet" href="https://2016.igem.org/Team:UNebraska-Lincoln/css/Safetymain?action=raw&amp;ctype=text/css"/>
<title>Elements - Solid State by HTML5 UP</title>
+
 
<meta charset="utf-8" />
+
 
<meta name="viewport" content="width=device-width, initial-scale=1" />
+
<!--[if lte IE 8]><script src="assets/js/ie/html5shiv.js"></script><![endif]-->
+
<link rel="stylesheet" href="https://2016.igem.org/Team:UNebraska-Lincoln/css/Safetymain?action=raw&amp;ctype=text/css" />
+
<!--[if lte IE 9]><link rel="stylesheet" href="assets/css/ie9.css" /><![endif]-->
+
<!--[if lte IE 8]><link rel="stylesheet" href="assets/css/ie8.css" /><![endif]-->
+
</head>
+
<body >
+
  
 
<style>
 
<style>
Line 185: Line 171:
  
  
<!-- Wrapper -->
+
<section id="wrapper">
+
<header >
+
<div class="inner" >
+
</div>
+
</header>
+
 
+
<!-- Content -->
+
<div class="wrapper">
+
<div class="inner">
+
 
<style>.image{
 
<style>.image{
 
   position: relative;
 
   position: relative;
Line 202: Line 179:
 
   position: absolute;
 
   position: absolute;
 
}</style>
 
}</style>
<section>
 
 
<style>.image{
 
<style>.image{
 
   position: relative;
 
   position: relative;
Line 210: Line 186:
 
   position: absolute;
 
   position: absolute;
 
}</style>
 
}</style>
 +
<div class="drawing board" style=" background-color: #2e3141; padding-top:50px;">
 +
<section><img src="https://static.igem.org/mediawiki/2016/0/0f/T--UNebraska-Lincoln--IHPBanner.png" align="middle" style="width:100%; height:100%; padding-bottom: 20px " alt="image"/></section>
 +
                                    <section>
 
<section>
 
<section>
 
<div class="image">
 
<div class="image">
 
<img src="https://static.igem.org/mediawiki/2016/8/89/T--UNebraska-Lincoln--IHP4.png" align="middle" style="width:100%; height:auto; transform: scale(0.8)" alt="image"/>
 
<img src="https://static.igem.org/mediawiki/2016/8/89/T--UNebraska-Lincoln--IHP4.png" align="middle" style="width:100%; height:auto; transform: scale(0.8)" alt="image"/>
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices" style="top: 0%; left: 10%; width: 10%; height: 90%;">
+
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices" style="top: 10%; left: 10%; width: 10%; height: 80%;">
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_1" style="top: 0%; left: 20%; width: 10%; height: 90%;">
+
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_1" style="top: 10%; left: 20%; width: 10%; height: 80%;">
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_2" style="top: 0%; left: 30%; width: 10%; height: 90%;">
+
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_2" style="top: 10%; left: 30%; width: 10%; height: 80%;">
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_3" style="top: 0%; left: 40%; width: 10%; height: 90%;">
+
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_3" style="top: 10%; left: 40%; width: 10%; height: 80%;">
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_4" style="top: 0%; left: 50%; width: 10%; height: 90%;">
+
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_4" style="top: 10%; left: 50%; width: 10%; height: 80%;">
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_5" style="top: 0%; left: 60%; width: 10%; height: 90%;">
+
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_5" style="top:10%; left: 60%; width: 10%; height: 80%;">
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_6" style="top: 0%; left: 70%; width: 10%; height: 90%;">
+
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_6" style="top: 10%; left: 70%; width: 10%; height: 80%;">
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_7" style="top: 0%; left: 80%; width: 10%; height: 90%;"></a>
+
   <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_7" style="top: 10%; left: 80%; width: 10%; height: 80%;"></a>
 
</div>
 
</div>
 
</section>
 
</section>
 +
<div style="transform: scale(1);margin-left:150px; margin-right:150px">                   
  
 
<h2 class="major">Safety Cases and Synthetic Biology</h2>
 
<h2 class="major">Safety Cases and Synthetic Biology</h2>
<p><font color="white">Since the inception of the project, we aimed to provide a scientifically feasible and practically safe solution to managing the nitrogen cycle. One that can be applied to the natural environment. We designed and installed a novel kill-switch that leads to the death of our machine once the concentration of nitrate is reduced below the safety level.  Over the summer, we met with scientists from local biotech companies and fellow iGEMers to discuss both the scientific and safety aspects our project design.  Based on the feedback, we became more mindful of safety and began to integrate an interdisciplinary tool to our project.  We developed safety cases, a method that is currently used to gauge the safety of critical software systems to simulate the end-results of releasing our engineered microorganisms into the environment. </p></font>
+
<br>
<p><font color="white"></p></font>
+
<h3><font color="white"><strong>How are Safety Cases Applicable to Synthetic Biology?</strong></h3>
<p><font color="white"></p></font>
+
<br>
<p><font color="white"></p></font>
+
<p><font color="white"><span style="font-weight: 400;">Limited regard has been given to develop systematic techniques to validate engineered biological systems in general. Recently, two of the 2016 UNL iGEM advisors, Dr. Cohen and Dr. Pierobon have published a paper introducing the idea of applying the aforementioned safety cases to the biological domain. There are clear parallels between software systems and synthetically engineered biological organisms (SEBO&rsquo;s). </span></p>
<p><font color="white">
+
<br>
These aspects of our project served the dual benefit of improving our design by forcing us to think critically about the mechanisms and environment of our project and allowing us to connect with and respond to the public in order to educate them and respond to their concerns.</font></p>
+
<h3><font color="white"><strong>Parallels between software systems and synthetically engineered organisms</strong></h3>
 +
<ul>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">Engineering the DNA of a microorganism is similar to designing software programs</span></li>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">DNA genetic code has precise biological function</span></li>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">SEBO&rsquo;s perform information processing</span></li>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">SEBO&rsquo;s have logical control capabilities</span></li>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">When engineered microorganisms are introduced into an environment outside of the lab, they become safety critical devices</span></li>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">There is a need for predictability in both SEBO&rsquo;s and Software Systems</span></li>
 +
<li style="font-weight: 400;"><span style="font-weight: 400;">Software systems are composed of subsystems and can be built into other systems creating systems of systems. In a very similar sense, an SEBO is a systems of systems. They are made up of BioBricks (subsystems) and are introduced into environmental systems.</span></li>
 +
</ul>
 +
<br>
 +
<p><font color="white"><span style="font-weight: 400;">One more interesting parallel to draw on is that the environment of many software systems, especially those in transportation or avionics is always changing. Both SEBO&rsquo;s and software systems must be dynamic and be able to adapt to their environments. SEBO&rsquo;s do however, have an added level of complexity. The engineered genetic code itself in engineered microorganisms is dynamic due to mutations, whereas the code in software is constant. Cohen and Pierobon suggest the development of the evolution envelope, a method to account for the mutations in safety cases. Safety timelines could potentially be used to compliment safety cases. When safety cases are designed for SB projects, potential evolution patterns can be predicted and mechanisms to mitigate their consequences can be integrated into their design.</span></p>
 +
</div>
 +
<div class="image">
 +
<img src="https://static.igem.org/mediawiki/2016/8/89/T--UNebraska-Lincoln--IHP4.png" align="middle" style="width:100%; height:auto; transform: scale(0.8)" alt="image"/>
 +
<a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices" style="top: 10%; left: 10%; width: 10%; height: 80%;">
 +
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_1" style="top: 10%; left: 20%; width: 10%; height: 80%;">
 +
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_2" style="top: 10%; left: 30%; width: 10%; height: 80%;">
 +
<a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_3" style="top: 10%; left: 40%; width: 10%; height: 80%;">
 +
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_4" style="top: 10%; left: 50%; width: 10%; height: 80%;">
 +
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_5" style="top:10%; left: 60%; width: 10%; height: 80%;">
 +
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_6" style="top: 10%; left: 70%; width: 10%; height: 80%;">
 +
  <a href="https://2016.igem.org/Team:UNebraska-Lincoln/Integrated_Practices_7" style="top: 10%; left: 80%; width: 10%; height: 80%;"></a>
 +
</div>
 
</section>
 
</section>
  
Line 244: Line 247:
 
</section>
 
</section>
  
</div>
 
  
 +
</div>
 +
</div>
 
 
 
<!-- Scripts -->
 
<!-- Scripts -->
Line 316: Line 320:
 
             });
 
             });
 
         </script>
 
         </script>
 
 
 
</body>
 
 
</html>
 
</html>

Latest revision as of 02:33, 20 October 2016

image

Safety Cases and Synthetic Biology


How are Safety Cases Applicable to Synthetic Biology?


Limited regard has been given to develop systematic techniques to validate engineered biological systems in general. Recently, two of the 2016 UNL iGEM advisors, Dr. Cohen and Dr. Pierobon have published a paper introducing the idea of applying the aforementioned safety cases to the biological domain. There are clear parallels between software systems and synthetically engineered biological organisms (SEBO’s).


Parallels between software systems and synthetically engineered organisms

  • Engineering the DNA of a microorganism is similar to designing software programs
  • DNA genetic code has precise biological function
  • SEBO’s perform information processing
  • SEBO’s have logical control capabilities
  • When engineered microorganisms are introduced into an environment outside of the lab, they become safety critical devices
  • There is a need for predictability in both SEBO’s and Software Systems
  • Software systems are composed of subsystems and can be built into other systems creating systems of systems. In a very similar sense, an SEBO is a systems of systems. They are made up of BioBricks (subsystems) and are introduced into environmental systems.

One more interesting parallel to draw on is that the environment of many software systems, especially those in transportation or avionics is always changing. Both SEBO’s and software systems must be dynamic and be able to adapt to their environments. SEBO’s do however, have an added level of complexity. The engineered genetic code itself in engineered microorganisms is dynamic due to mutations, whereas the code in software is constant. Cohen and Pierobon suggest the development of the evolution envelope, a method to account for the mutations in safety cases. Safety timelines could potentially be used to compliment safety cases. When safety cases are designed for SB projects, potential evolution patterns can be predicted and mechanisms to mitigate their consequences can be integrated into their design.