\begin{frame}[typeset second]{Design Method Evaluation}
    \customslide
    {
        %notes
        \begin{itemize}
            \item Preparation Phase: the steps prior to the development Cycle
                \begin{itemize}
                    \item What elements are required to describe a feature
                    \item How should these features and their elements be defined
                \end{itemize}
            \item Development Cycle: That is performed for each feature
                \begin{itemize}
                    \item The role of design and model in the process
                    \item Select which feature to implement
                    \item Tooling required for Development
                \end{itemize}
            \item Design in General
                \begin{itemize}
                    \item System Complexity \& the role of Hardware vs Software
                    \item Development Team
                \end{itemize}
        \end{itemize}
    }
    {
        %overlay
        \begin{itemize}
            \item Preparation Phase
                \begin{itemize}
                    \item Elements of a feature
                    \item Feature Definition
                \end{itemize}
            \item Development Cycle
                \begin{itemize}
                    \item Design versus Model
                    \item Feature Selection
                    \item Development Tooling
                \end{itemize}
            \item Design in General
                \begin{itemize}
                    \item System complexity
                    \item Development Team
                \end{itemize}
        \end{itemize}
    }
\end{frame}

\begin{frame}[typeset second]{Preparation Phase}
    \customslide
    {
        %notes
        \begin{block}{Elements of a Feature}
            \begin{itemize}
                \item Case study: function/component separate.
                \item Therefore, a component feature has no functionality.
                \item The lack of functionality makes it impossible to test.
                \item To test and implement individually
                \item Feature needs: requirement, component and function
            \end{itemize}
            \begin{figure}
                \raggedright
                \includegraphics[width=60mm]{graphics/functional_relation.pdf}
            \end{figure}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Elements of a Feature}
            \begin{figure}
                \raggedright
                \vspace{1mm}
                \includegraphics[width=60mm]{graphics/functional_relation.pdf}
            \end{figure}
            \begin{itemize}
                \item Independent implementation
                \item Testable
            \end{itemize}
        \end{block}
    }
\end{frame}

\begin{frame}[typeset second]{Preparation Phase}
    \customslide
    {
        %notes
        %for the feature definition
        %used linear set of steps
        %Eventhough the problem of writing on a white board is fairly simple, it was difficult to design the current system using the linear set of steps.
        %First all requirements, then initial design.
        %Often happened: "forgot this, should have added this requirements"

        %however, the preparation phase defines the functionality of the system
        %And thus the features.
        %For the rapid iterative design method these features determine the outcome of the design process.



        \begin{block}{Feature Definition}
            \begin{itemize}
                \item The preparation phase determines 
                \item functionality of the system
                    \begin{itemize}
                        \item thus also the features
                        \item which are developed into the final product
                    \end{itemize}
                \item The simple set of steps: problem definition; requirements; initial design
                \item difficult to design this simple system with
                \item approach must also be able to determine features
                \item of complex problems.
            \end{itemize}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Feature Definition}
            \begin{itemize}
                \item Functionality of the system
                    \begin{itemize}
                        \item Features
                        \item Final product
                    \end{itemize}
                    \vspace{2mm}
                \item Approach to determine features required
                \item Must deal with complex problems
            \end{itemize}
        \end{block}
    }
\end{frame}
\begin{frame}[typeset second]{Development Cycle}
    \customslide
    {
        %notes
        \begin{itemize}
            \item Design represented as models
                \begin{itemize}
                    \item for the model to represent the design
                    \item it needs more detail than neccesary
                    \item this defeats the purpose of the variable-detail approach
                    \item as it is not possible to stop at minimal level of detail.
                \end{itemize}
            \item Centralized design 
        \begin{itemize}
            \item Where multiple models can represent parts of the design
        \end{itemize}
            \item Models are based on this design
        \end{itemize}
    }
    {
        %overlay
        \begin{block}{Design versus Model}
            \begin{itemize}
                \item Model as design
                    \begin{itemize}
                        \item Model contains too much detail
                        \item Breaks variable-detail approach
                    \end{itemize}
                \item Central design
                    \begin{itemize}
                        \item Models inherit from central design.
                        \item Multiple models represent parts of design.
                        \item Easy to apply design changes
                    \end{itemize}
            \end{itemize}
        \end{block}
    }
\end{frame}

\begin{frame}[typeset second]{Development Cycle}
    \customslide
    {
        %notes
        \begin{itemize}
            \item Feature selection showed promissing results
                \begin{itemize}
                    \item Even in this small case study
                \end{itemize}
            \item However, the current classification is vague
            \item an improved method to determine
            \item Chance of failure and implementation cost
            \item is needed
        \end{itemize}
    }
    {
        %overlay
        \begin{block}{Feature Selection}
            \begin{itemize}
                \item Showed promissing results
                \item Improve classification
                    \begin{itemize}
                        \item Chance of failure
                        \item Implementation cost
                    \end{itemize}
            \end{itemize}
        \end{block}
    }
\end{frame}
\begin{frame}[typeset second]{Development Cycle}
    \customslide
    {
        %notes
        \begin{block}{Tooling - Version Control}
        \begin{itemize}
            \item During variable detail approach
            \item difficult to organize the levels of detail
            \item Model software must be compatible with version control
                \begin{itemize}
                    \item Allow atomic commits
                    \item Make merging easy
                    \item Possible to revert changes
                    \item Link and reuse other submodels
                \end{itemize}
        \end{itemize}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Tooling}
            \begin{itemize}
                \item Version control
                    \begin{itemize}
                        \item Atomic changes
                        \item Easy merging
                        \item Revert changes
                        \item Reuse of submodels
                        \item Propagate model changes
                    \end{itemize}
                \item Central design with parametric database
                    \begin{itemize}
                        \item Propagate design changes
                    \end{itemize}
                \item Unit testing
            \end{itemize}
        \end{block}
    }
\end{frame}
\begin{frame}[typeset second]{Development Cycle}
    \customslide
    {
        %notes
        \begin{block}{Tooling - Central Design}
        \begin{itemize}
                \item All design parameters should be in a central database.
                \item Models read the design parameters from this database
                \item Together:
                    \begin{itemize}
                        \item Version control propagates model changes
                        \item Central database propagates design changes.
                    \end{itemize}
                \item Easy to make a single change and test all models.
                \item This allows for beter unit testing.
        \end{itemize}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Tooling}
            \begin{itemize}
                \item Version control
                    \begin{itemize}
                        \item Atomic changes
                        \item Easy merging
                        \item Revert changes
                        \item Reuse of submodels
                        \item Propagate model changes
                    \end{itemize}
                \item Central design with parametric database
                    \begin{itemize}
                        \item Propagate design changes
                    \end{itemize}
                \item Unit testing
            \end{itemize}
        \end{block}
    }
\end{frame}

\begin{frame}[typeset second]{General Design}
    \customslide
    {
        %notes
        \begin{block}{Complexity}
            Software enables complexity
                \begin{itemize}
                    \item Without software the SCARA and cablebot combination would not be possible
                    \item Due to the complexity, changes are likely to introduce bugs and software errors.
                    \item Behavoir is hidden, difficult to detect problems
                    \item changes are expansive and have higher chance of failure
                \end{itemize}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Complexity}
            \begin{itemize}
                \item Software enables complexity
                    \begin{itemize}
                        \item Change is likely to cause bugs
                        \item Behavior is hidden
                        \item Expensive to change
                        \item High chance of failure
                    \end{itemize}
                \item Hardware stays simple
                    \begin{itemize}
                        \item Single prototype easy to change
                        \item Relative inexpensive
                        \item Behavior is discoverable
                    \end{itemize}
            \end{itemize}
        \end{block}
    }
\end{frame}

\begin{frame}[typeset second]{General Design}
    \customslide
    {
        %notes
        \begin{block}{Complexity}
         Hardware is relatively simple.
                \begin{itemize}
                    \item Building a single hardware prototype is cheap. 
                    \item Changing hardware is easy
                    \item Weld, saw, tape or screw something on
                    \item Above all, hardware fails destructive.
                    \item It is visible when the hardware does not behave as expected.
                    \item The design method should use hardware prototyping to it's advantage.
                \end{itemize}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Complexity}
            \begin{itemize}
                \item Software enables complexity
                    \begin{itemize}
                        \item Change is likely to cause bugs
                        \item Behavior is hidden
                        \item Expensive to change
                        \item High chance of failure
                    \end{itemize}
                \item Hardware stays simple
                    \begin{itemize}
                        \item Single prototype easy to change
                        \item Relative inexpensive
                        \item Behavior is discoverable
                    \end{itemize}
            \end{itemize}
        \end{block}
    }
\end{frame}

\begin{frame}[typeset second]{General Design}
    \customslide
    {
        %notes
        \begin{block}{Development Team}
            \begin{itemize}
                \item Missed design and software experience 
                \item Also missed team members,
                    \begin{itemize}
                        \item Create discussion about design/solutions
                        \item Review your work.
                        \item Justify your decissions.
                    \end{itemize}
                \item A cyber physical system design is multidomain
                \item Requires multi-disciplinary design team
            \end{itemize}
        \end{block}
    }
    {
        %overlay
        \begin{block}{Development Team}
        \begin{itemize}
            \item Design Experience
            \item Team members
                \begin{itemize}
                    \item Discussion
                    \item Review
                    \item Justify
                \end{itemize}
            \item Multi-domain
            \item Multi-disciplinary
        \end{itemize}
        \end{block}
    }
\end{frame}