Small changes and addition done in Philly

	- Full abstract
	- Reformatting from bullet points to paragraphs
	- Addition in motivation section outlining the needs and causes for businesses/manufacturers

Signed-off-by: Paul Wortman <paul.mauddib28@gmail.com>

PBDSecPaper.tex

@@ -87,14 +87,12 @@ As systems move towards more complex designs and implementations (as allowed by
 \begin{quotation}
   ``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} 
 \end{quotation}
-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 protocol standards.
+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 protocol standards. \\
 
+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.
 \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.
-	\begin{itemize}
-	\item For the IC domain standardization manifests as a flexibile integrated circuit where customization for a particular application is achieved by programming one or more components on the chip (e.g. virtualization).  PC makers and application software designers develop their products quickly and efficiently around a standard `platform' that emerged over time.  As a quick over view of these standards: x86 ISA which makes is possible to reuse the OS \& SW applications, a full specified set of buses (ISA, USB, PCI) which allow for use of the same expansion boards of IC's for different products, and a full specification of a set of IO devices (e.g. keyboard, mouse, audio and video devices).  The advantage of the standardization of the PC domain is that software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach.  If the instruction set architecture (IAS) is kept constant (e.g. standardized) then software porting, along with future development, is far easier~\cite{Vincentelli2002}.  In a `System Domain' lens, standardization is the aspect of the capabilities a platform offeres to develop quickly new applications (adoptability).  In other words, this requires a distillation of the principles so that a rigorous methodology can developed and profitably used across different design domains.
-	\item So why is standardization useful?  Standardization allows for manufacturers, system developers, and software designers to all work around a single, accepted, platform.  It is understood what the capabilities of the hardware are, what the limitations of system IO will be, along with what the methods/protocols of communication will be.  Even these preset aspects of the `standard' have their own `contractual obligations' of how they will function, what their respective `net-lists' are, and where the limtations of such standards lie.  While the act of creating a standard takes time, not only due to time of development but due to speed of adoption of wide use, it is a necessary step.  Without standarization, it becomes far more difficult to create universally used complex systems, let alone validate their correctness and trustworthiness.
-	\end{itemize}
+\item For the IC domain standardization manifests as a flexibile integrated circuit where customization for a particular application is achieved by programming one or more components on the chip (e.g. virtualization).  PC makers and application software designers develop their products quickly and efficiently around a standard `platform' that emerged over time.  As a quick over view of these standards: x86 ISA which makes is possible to reuse the OS \& SW applications, a full specified set of buses (ISA, USB, PCI) which allow for use of the same expansion boards of IC's for different products, and a full specification of a set of IO devices (e.g. keyboard, mouse, audio and video devices).  The advantage of the standardization of the PC domain is that software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach.  If the instruction set architecture (IAS) is kept constant (e.g. standardized) then software porting, along with future development, is far easier~\cite{Vincentelli2002}.  In a `System Domain' lens, standardization is the aspect of the capabilities a platform offeres to develop quickly new applications (adoptability).  In other words, this requires a distillation of the principles so that a rigorous methodology can developed and profitably used across different design domains.
+\item So why is standardization useful?  Standardization allows for manufacturers, system developers, and software designers to all work around a single, accepted, platform.  It is understood what the capabilities of the hardware are, what the limitations of system IO will be, along with what the methods/protocols of communication will be.  Even these preset aspects of the `standard' have their own `contractual obligations' of how they will function, what their respective `net-lists' are, and where the limtations of such standards lie.  While the act of creating a standard takes time, not only due to time of development but due to speed of adoption of wide use, it is a necessary step.  Without standarization, it becomes far more difficult to create universally used complex systems, let alone validate their correctness and trustworthiness.
 \end{itemize}
 
 \begin{itemize}
@@ -119,7 +117,7 @@ Work in the security realm is much more chaotic, although understakings have bee
 \end{itemize}
 
 \begin{itemize}
-\item The manufacturer's standpoint boils down to: the design should minimize mask-making costs but be 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}.
+\item The manufacturer's standpoint boils down to: the design should minimize mask-making costs but be 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}.  Companies try to drive adoptability by means of creating something that users want to interact with, but not be complicated to learn (e.g. abstraction of technology for ease of use).  Accounting for ease of use can lead to vulnerabilities in security or the development of new tools.  Automation is desirable from a `business' standpoint since customers/users enjoy the `set it and forget it' mentality for technology (especially new technologies).  Companies/Manufacturers need positive customer/user experiences, otherwise there is no desire to extend any supplied functionality to any other devices/needs on the part of the consumer.  Adoptablility tends to come from user `word of mouth' praising the functionality and ease of use of new technology/methods/devices and how the developing party reacts to system failures or user-need (branching from complaints and support requests).
 	\begin{itemize}
 	\item This is exactly why industry would love for platform-based design to become a new standard.  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).
 	\end{itemize}