diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex
index 166566f..f2d5ffd 100644
--- a/PBDSecPaper.tex
+++ b/PBDSecPaper.tex
@@ -86,7 +86,7 @@
 
 \section{Motivation}
 \label{Motivation}
-As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult.  For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development.  An example of this abstraction simplification is the use of system-on-chip (SoC) to replace multi-chip solutions.  This abstraction solution is then used for a variety of tasks, ranging from arithmatic to system behavior.  It is an industry standard to use SoC to handle encryption/security in a secure and removed manner~\cite{Wu2006}.  Middleware describes software that resides between an application and the inner workings of the system hosting the application.  The purpose of the middleware is to abstract the complexities of the underlying technology from the application layer~\cite{Lang2003}; to act as translation software for communicating from lower level to a higher level.  This is the same sort of ``abstraction bridge'' that is required by the ``meet-in-the-middle'' methodology of PBD, along with the sort of software construct that benefits the virtualization of security component mapping.  ``However, even though current silicon technology is closely following the growing demands; the effort needed in modeling, simulating, and validating such designs is adversely affected.  This is because current modeling tools and frameworks, hardware and software co-design environments, and validation and verification frameworks do not scale with the rising demands.''`\cite{Patel2007}  Work in the security realm is much more chaotic, although understakings have been made to define the scope of security and its intricacies in a well documented manner~\cite{Benzel2005}.  Other work in the security realm includes security-aware mapping for automotive systems, explorations of dependable and secure computing, how to model secure systems, and defining the general theorems of security properties~\cite{Lin2013, Avizienis2004, Jorgen2008, Zakinthinos1997, Zhou2007}.  A key developing aspect of security is its standardization of encryption algorithms, methods of authentication, and communication protocols.
+As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult.  For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development.  An example of this abstraction simplification is the use of system-on-chip (SoC) to replace multi-chip solutions.  This abstraction solution is then used for a variety of tasks, ranging from arithmatic to system behavior.  It is an industry standard to use SoC to handle encryption/security in a secure and removed manner~\cite{Wu2006}.  Middleware describes software that resides between an application and the inner workings of the system hosting the application.  The purpose of the middleware is to abstract the complexities of the underlying technology from the application layer~\cite{Lang2003}; to act as translation software for communicating from lower level to a higher level.  This is the same sort of ``abstraction bridge'' that is required by the ``meet-in-the-middle'' methodology of PBD, along with the sort of software construct that benefits the virtualization of security component mapping.  ``However, even though current silicon technology is closely following the growing demands; the effort needed in modeling, simulating, and validating such designs is adversely affected.  This is because current modeling tools and frameworks, hardware and software co-design environments, and validation and verification frameworks do not scale with the rising demands.''`\cite{Patel2007}  Work in the security realm is much more chaotic, although understakings have been made to define the scope of security and its intricacies in a well documented manner~\cite{Benzel2005}.  Other work in the security realm includes security-aware mapping for automotive systems, explorations of dependable and secure computing, how to model secure systems, and defining the general theorems of security properties~\cite{Lin2013, Avizienis2004, Jorgen2008, Zakinthinos1997, Zhou2007}.  Security has many facets to it: failure, processes, security mechanisms, secuirty principles, security policies, trust, etc.  A key developing aspect of security is its standardization of encryption algorithms, methods of authentication, and communication protocols.
 
 \begin{itemize}
 \item Standardization is the process of developing and implementing technical standards.  Standardization can help to maximinze compatability, interoperability, safety, repeatability, or quality; it can also faciliate commoditization of formerly custom processes.  Standards appear in all sorts of domains.
@@ -101,7 +101,7 @@ \section{Motivation}
 \item Where do we gain/lose on shifting the method of design.  Development of these tools implies that there is a need to change the focus and methods of design/development~\cite{Vincentelli2007}.
 	\begin{itemize}
 	\item The advatange to this method is ease of changes in development and searching of design spaces during early design and development of those systems.  For PBD this means that a company/manufacturer is able to lower the cost and time spent in the `early development phase'; the time spent when first drawing up system designs prior to initial prototyping.  While the advantage of overcoming multiple prototpying re-designs with a series of virtualization tools will cut down on development time, it can not be forgotten that the rigorous standards and documentation need to be developed for this sort of advantage.   Once this hurdle is passed then the advantages of such a system can be reaped.  For security this means that components can be standardized from a local, network, and distributed standpoint.  These different scopes of security will be tackled in Section~\ref{Security}.  The main point here is that with standardization comes a form of `contract' that all parties can expect will be followed, thus allowing for a different manufacturers/developers to create different aspect while knowing that these different elements will come together in the final product; much like the advantages of platform-based design.
-	\item The disadvantage of using a new method is the loss in time for developing the standards, rigors, and documentation that would be used as new standards for the industry.  The other disadvantage is in the adoptability of these new methods and designs.  Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best'').
+	\item The disadvantage of using a new method is the loss in time for developing the standards, rigors, and documentation that would be used as new standards for the industry.  These sorts of costs have been felt while developing any of the current standards of security; most definitely with the development of new algorithms for encryption.  Further more, security vulnerabilities are found mainly due to incorrect implementations or due to incorrect assumptions about functionality; both of which are more easily avoidable with the use of rigorous planning and design.  The other disadvantage is in the adoptability of these new methods and designs.  Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best'').
 	\item Virtualization will help offset the time and monetary costs in the long run.  Essentially the issue boils down to how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block).  A new set of tools needs to be developed that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks.  Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks.  As with any new system, there is a need for `tunable desings' that can be centered around specific aspects (e.g. power/energy efficient systems to minimize ``power cost buildup'', or security/trust centric needs).  Functions, in this tool set, should be kept simple (e.g. decide output, \textbf{but} not how the output manifests).  The reason behind this is that the design can remain simplistic in its design and operation.  Virtualization tools lend to both the ideas of abstraction (choosing the simple output) and standardization/documentation (know what the outputs are, but not needing to know exactly how they manifest; just that they will)~\cite{Alagar2007}.  They are a much needed tool for exploring design spaces and bringing codesign of software and hardware elements.
 	\end{itemize}
 \item Hardware/Software Codesign
@@ -115,7 +115,7 @@ \section{Motivation}
 		\end{itemize}
 	\item As with any design problem, if the functional aspects are indistinguishable from the implementation aspects, then it is very difficult to evolve the design over multiple hardware generations~\cite{Vincentelli2007}.  It should be noted that there are tools that already exists for low, or high, system simulation.  New terretory is the combination of these tools to form a `hardware-to-software' virtualization tool that is both efficient and effective.
 	\end{itemize}
-\item Metropolis is one tool that is based in part on the concept of platform-based design.  Metropolis can analyze statically and dynamically functional designs with models that have no notion of physical quantities and mapped designs where the association of functionality to architectural services allows for evaluation of characteristics (e.g.~latency, throughput, power, and energy) of an implementation of a particular functionality with a particular platform instance~\cite{Vincentelli2007}.  This tool has been used for the platform-exploration of biological proteins as seen in the \textbf{CITE BIOLOGICAL PAPER THAT USED METROPOLIS} paper.
+\item Metropolis is one tool that is based in part on the concept of platform-based design.  Metropolis can analyze statically and dynamically functional designs with models that have no notion of physical quantities and mapped designs where the association of functionality to architectural services allows for evaluation of characteristics (e.g.~latency, throughput, power, and energy) of an implementation of a particular functionality with a particular platform instance~\cite{Vincentelli2007, Metropolis}.  Metropolis is but one manifestation of platform-based design as a tool.  PBD has been used for the platform-exploration of synthetic biological systems as seen in the work done by Densmore et.~al.~to create a strong and flexable tool~\cite{Densmore2009}.  Other applications include design on a JPEG encoder and use for distributed automotive design~\cite{}\textbf{ADD ALL CITING OF OTHER PBD BASED WORK HERE!!!}.
 \item Manufacturer's standpoint boils down to: ``minimize mask-making costs but flexible enough to warrant its use for a set of applications so that production volume will be high over an extended chip lifetime.''~\cite{Vincentelli2007}
 	\begin{itemize}
 	\item This is exactly why industry would love for platform-based design to pick up.  The monetary costs saved would be enough to warrent adoption of the technology, \textbf{but} the monetary costs of developing such a system (e.g. design, evalutation, validation) does not carry the same attraction (simply because companies are selfish and want to \textbf{make} money).
@@ -133,6 +133,12 @@ \section{Platford-based design}
 \item In PBD, the partitioning of the design into hardware and software is not the essence of system design as many think, rather it is a consequence of decisions taken at a higher level of abstraction~\cite{Vincentelli2007}.  For example, a lower level consideration may be heat dissipation concerns which manifests itself as size constraints at higher levels.  The types of decisions that are made at these higher levels lend to the design traits that are requirements at lower levels.  These sort of complexities in cost of design are exactly why abstraction/virtualization are required/desired.  Additional levels of abstraction (along with virtualization tools for design space exploration) aid in simplifying the design process.  ``Critical decisions are about the architecture of the system, e.g., processors, buses, hardware accelerators, and memories, that will carry on the computation and communication tasks associated with the overall specification of the design.''~\cite{Vincentelli2007}  The library of functional and communication components is the design space that we are allowed to explore at the appropriate level of abstraction~\cite{Vincentelli2007}.  There are elements of recursive behavior that need to be tackled from a virtualized tool standpoint.  In a PBD refinement-based design process, platforms shoould be defined to eliminate large loop iterations for affordable designs~\cite{Vincentelli2007}.  This refinement should restrict the design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass sucess.
 \end{itemize}
 
+\begin{figure*}
+	\includegraphics[width=\textwidth,height=8cm]{./images/recursivePBD.png}
+	\caption{Recursive PBD}
+	\label{fig:RecursivePBD}
+\end{figure*}
+
 \begin{itemize}
 \item Due to the recursive nature of platform-based design, establishing the number, location, and components of intermediate ``platforms'' is the essence of PBD~\cite{Vincentelli2007}.  ``In fact, designs with different requirements and specification may use different intermediate platforms, hence different layers of regularity and design-space constraints.  The tradeoffs involved in the selection of the number and characteristics of platforms relate to the size of the design space to be explored and the accuracy of the estimation of the chracteristics of the solution adopted.  Naturally, the larger the step across platforms, the more difficult is predicting performance, optimizing at the higher levels of abstraction, and providing a tight lower bound.  In fact, the design space for this approach may actually be smaller than the one obtained with smaller steps because it becomes harder to explore meaningful design alternatives and the restriction on search impedes complete design-space exploration.  Ultimately, predictions/abstractions may be so inaccurate that design optimizations are misguided and the lower bounds are incorrect.''~\cite{Vincentelli2007}
 \item ``The identification of precisely defined layers where the mapping processes take place is an important design decision and should be agreed upon at the top design management level.''~\cite{Vincentelli2007}
@@ -159,6 +165,12 @@ \section{Security}
 	\end{itemize}
 \end{itemize}
 
+\begin{figure*}
+	\includegraphics[width=\textwidth,height=10cm]{./images/SecurityDesignMap.png}
+	\caption{Security Design Map}
+	\label{fig:SecDesignMap}
+\end{figure*}
+
 \begin{itemize}
 \item Scopes of security/trustworthiness
 	\begin{itemize}
@@ -347,6 +359,12 @@ \section{Conclusion}
 \bibitem{Gruttner2013} Kim Gr{\"u}ttner, Philipp A.~Hartmann, Kai Hylla, Sven Rosinger, Wolfgang Nebel, Fernando Herrera, Eugenio Villar, Carlo Brandolese, William Fornaciari, Gianluca Palermo, Chantal Ykman-Couvreur, Davide Quaglia, Francisco Ferrero, and Ra{\'u}l Valencia, \emph{
 The COMPLEX Reference Framework of HW/SW Co-Design and Power Management Supporting Platform-Based Design-Space Exploration}, Microprocessors and Microsystems Volume 37, Issue 8 (November 2013)
 
+\bibitem{Densmore2009} Douglas Densmore, Anne Van Devender, Matthew Johnson, and Nade Sritanyaratana, \emph{
+A Platform-Based Design Environment for Synthetic Biological Systems}, The Fifth Richard Tapia Celebration of Diversity in Computing Conference: Intellect, Initiatives, Insight, and Innovations (2009)
+
+\bibitem{Metropolis} \emph{Metropolis: Design Environment for Heterogeneous Systems},
+url{https://embedded.eecs.berkeley.edu/metropolis/tools.html}
+
 \end{thebibliography}
 
 \end{document}
diff --git a/images/PBD.png b/images/PBD.png
new file mode 100644
index 0000000..ea6ba62
Binary files /dev/null and b/images/PBD.png differ
diff --git a/images/SecurityDesignMap.PNG b/images/SecurityDesignMap.PNG
new file mode 100644
index 0000000..cb0b5a4
Binary files /dev/null and b/images/SecurityDesignMap.PNG differ
diff --git a/images/recursivePBD.png b/images/recursivePBD.png
new file mode 100644
index 0000000..a5a2b66
Binary files /dev/null and b/images/recursivePBD.png differ