Small additions to the New Framework Section of the paper.

AADLSecPaper.tex

@@ -298,11 +298,11 @@ AADL is indeed a powerful and versatile language that has the potential to also
 %	\label{fig:RecursivePBD}
 %\end{figure}
 
-While extensions to the security-centric aspects of the AADL language have been recently released but the focus of these linguistic extensions is for system analysis and code generation while not focusing on low level element properties and how to map them to higher level system requirements.  As such, this paper proposes a security framework that can be adopted as an extension to AADL for the purpose of creating security model implementations mapped from security requirements and component specifications.  Having examined the previous work and development of the AADL language, one can see that there is concurrent effort being placed in tracking different areas of real-time embedded system design, such as error propagation, behavior of systems and components, as well as the definition and validation of requirements.  Although these extensions and annexes are not tailored specifically for security modeling needs and purposes, AADL allows for their combined use to help fill in the gaps of security requirement definition and behavior under different scenarios and conditions.  The one `disadvantage' being that users will need to learn each tool separately and will be left to discover the best method of aggregate implementation; although this is truly the advantage of AADL as its own language.  Considering the declared additions of a security annex extension to the AADL lexicon, there is an expansion for being able to describe said properties and aspects, but no movement yet towards verification of requirements and needs as seen with other annexes (e.g. RDALTE).  There is notable work towards graphical representations of these security aspects, but again there is still a gap for the generation of secure system implementations and models.
+Extensions to the security-centric aspects of the AADL language have been recently released but the focus of these linguistic extensions is for system analysis and code generation while not focusing on low level element properties and how to map them to higher level system requirements.  As such, this paper proposes a security framework that can be adopted as an extension to AADL for the purpose of creating security model implementations mapped from security requirements and component specifications.  Having examined the previous work and development of the AADL language, one can see that there is concurrent effort being placed in tracking different areas of real-time embedded system design, such as error propagation, behavior of systems and components, as well as the definition and validation of requirements.  Although these extensions and annexes are not tailored specifically for security modeling needs and purposes, AADL allows for their combined use to help fill in the gaps of security requirement definition and behavior under different scenarios and conditions.  The one `disadvantage' being that users will need to learn each tool separately and will be left to discover the best method of aggregate implementation; although this is truly the advantage of AADL as its own language.  Considering the declared additions of a security annex extension to the AADL lexicon, there is an expansion for being able to describe said properties and aspects, but no movement yet towards verification of requirements and needs as seen with other annexes (e.g. RDALTE).  There is notable work towards graphical representations of these security aspects, but again there is still a gap for the generation of secure system implementations and models.  Even more of a void can be felt for a set of automated tools for exploring the security design space.
 
 % Add in an image of the drawing from the bulletjournal on the process
 \begin{figure}
-	\includegraphics[width=\textwidth, height=10cm]{./images/aadl_security_framework.png}
+	\includegraphics[width=\textwidth, height=8.8cm]{./images/aadl_security_framework.png}
 	\caption{Visualization of Security Framework}
 	\label{fig:AADLSecFrame}
 \end{figure}
@@ -313,10 +313,11 @@ The new security framework that this paper proposes would require the following
 	\item Formalized description and definition of higher level security requirements that may come from user-defined needs or from the experience of knowledge of security experts.
 	\item Creation of a mapping process by which security requirements and secure component specifications can be uniformly compared to allow for the generation of potential secure architectural system model solutions to the given inputs.
 	\item Verification tools to validate mapping implementation solutions.
+	\item Implementation of automated tools for the purpose of thoroughly exploring the entire design space for optimizing generated designs while minimizing the amount of time spent developing said design models.
 \end{enumerate}
-Other additional aspects of this framework, that could come from the existing tools, extensions, and annexes would include code generated using the secure models.  
+Other additional aspects of this framework, that could come from the existing tools, extensions, and annexes would include code generated using the secure models.  Work towards developing these sorts of tools for secure architectures (e.g. seL4) is already one of the focuses of current AADL security annex work~\cite{AADLSecAnalysis}.
 %An advantage of this framework is that it borrows from the platform-based design model, shown in Figure~\ref{fig:RecursivePBD}, allowing for continual refinement and improvement of designs while also improving early phase development of new components and systems.  
-As can be seen in Figure~\ref{fig:AADLSecFrame} the power of this new framework comes from the mapping process used to combine the component definitions and requirements as well as the verification of the mapping instances.  However, before those aspects of the framework can be formalized, one must first have clarification of the language used to define and describe component specifications and requirements of the system.  For AADL to become the descriptive language for this sort of framework, one will need to first define a secure device library that will represent common implementations of known secure system models.  From here one will then need to produce a manner of combining existing constraint linguistics with security needs to produce comparable, quantitative security metrics for both functional and non-functional behavior and security requirements.  Lastly, one will need to develop Resolute, or other annex tools, to account for security assurances through verification and validation solutions.  Furthermore, standardization of the dialect must take place to allow for ease of communication of ideas, specifications, requirements, and expected behavior.
+As can be seen in Figure~\ref{fig:AADLSecFrame} the power of this new framework comes from the mapping process used to combine the component definitions and requirements as well as the verification of the mapping instances.  However, before those aspects of the framework can be formalized, one must first have clarification of the language used to define and describe component specifications and requirements of the system.  For AADL to become the descriptive language for this sort of framework, one will need to first define a secure device library that will represent common implementations of known secure system models.  From here one will then need to produce a manner of combining existing constraint linguistics with security needs to produce comparable, quantitative security metrics for both functional and non-functional behavior and security requirements.  Lastly, one will need to develop Resolute, or other annex tools, to account for security assurances through verification and validation solutions.  Furthermore, standardization of the dialect must take place to allow for ease of communication of ideas, specifications, requirements, and expected behavior.  Otherwise the advantages of this new security framework would not outweigh the cost and time spend learning the syntax and tools required.
 
 % Add in the table of elements and variations
 \begin{table*}[]